3.3 Model Sources: Managed APIs, Open Source, and Custom Models
Key Takeaways
- A model source decision should start with use-case fit, risk, data sensitivity, team skill, cost, latency, customization needs, and operating responsibility.
- Managed AWS AI services are often the simplest option when the task matches a known capability such as translation, transcription, document extraction, moderation, personalization, or fraud detection.
- Open source and third-party models can add flexibility, but they introduce licensing, security, hosting, patching, evaluation, and governance responsibilities.
- Custom models are justified when the business needs domain-specific behavior, proprietary data learning, or control that managed APIs cannot provide.
Start with the source of capability
When a project says it needs AI, the first architecture decision is often where the model capability should come from. The options include managed AWS AI services, foundation model APIs through Amazon Bedrock, models available through SageMaker JumpStart or other catalogs, open source models that the organization hosts, third-party services, and custom models trained on organization data. The practitioner skill is to understand tradeoffs, not to implement every path.
A managed API is attractive when the task is common and well served by an AWS service. Amazon Translate can translate text. Amazon Transcribe can convert speech to text. Amazon Polly can generate speech. Amazon Textract can extract text and structure from documents. Amazon Comprehend can analyze text for entities, sentiment, key phrases, and related NLP tasks. Amazon Rekognition can analyze images and video. Amazon Personalize can support recommendations. Amazon Fraud Detector can support fraud risk use cases.
Amazon Bedrock provides access to foundation models and related capabilities for generative AI use cases.
Managed services reduce the need to collect training data, train models, host infrastructure, and patch model-serving stacks. They still require governance. A practitioner should ask whether the service supports the language, region, data class, latency, volume, accuracy target, and compliance requirements. A service can be technically easy and still be the wrong choice if it sends data through an unapproved workflow or cannot meet business quality requirements.
| Model source | Best fit | Main practitioner concern |
|---|---|---|
| Managed AWS AI API | Standard task with limited customization needs | Confirm service capability, pricing, data handling, and quality |
| Amazon Bedrock foundation model | Generative AI, summarization, Q and A, drafting, agents, RAG | Control hallucination, prompt injection, grounding, cost, and safety |
| SageMaker JumpStart or catalog model | Faster start with prebuilt model choices | Evaluate license, performance, hosting, and customization needs |
| Open source model | Need transparency, portability, or specialized model choice | Own security, licensing, evaluation, patching, and serving |
| Custom SageMaker model | Domain-specific prediction or proprietary learning need | Requires ML skills, data readiness, MLOps, monitoring, and cost control |
| No ML or rules | Deterministic or low-value problem | Avoid unnecessary model risk and operating cost |
Managed API judgment
Managed AI services are often strongest for clear, bounded tasks. If a company needs to extract fields from invoices, Textract may be a better first review than training a custom computer vision model. If a support team needs sentiment or entity extraction from tickets, Comprehend may be worth evaluating before custom NLP. If the task is transcription, Transcribe is usually more appropriate than building speech recognition from scratch.
The practitioner should still insist on a proof of fit. Test representative data, not only clean demos. Include edge cases, languages, document formats, accents, image quality, and noisy inputs. Review pricing based on expected volume. Confirm IAM controls, encryption, logging, and retention. If outputs influence customers, money, safety, employment, credit, health, or legal outcomes, add human review and governance.
Open source, marketplace, and custom paths
Open source models can be useful when the organization needs more control, wants to run workloads in its own AWS account, or needs a specialized model not offered as a managed API. That control comes with responsibilities. The team must evaluate licenses, provenance, known vulnerabilities, model weights, dependency updates, hosting cost, scaling, monitoring, and whether the model was trained on appropriate data. A practitioner should not assume open source means free or safe.
Custom models may be justified when the business has proprietary labeled data and a task that managed services cannot solve well. Examples include predicting failure of a specific industrial asset, ranking internal leads based on company-specific behavior, classifying specialized medical coding notes for internal review, or forecasting demand in a unique supply chain. Custom work can create competitive advantage, but it also requires data scientists, ML engineers, security review, MLOps, and ongoing ownership.
SageMaker AI supports custom ML workflows, including notebooks or Studio environments, training jobs, model registry, endpoints, batch transform, monitoring, and pipelines. For a business analyst or product manager, the important question is not how to configure every setting. The question is whether the added control is worth the added responsibility compared with a managed service or a no-code option such as SageMaker Canvas.
Decision workflow for model source
- Define the task and risk level.
- Check whether a managed AWS AI service already fits the task.
- If generative AI is needed, evaluate Amazon Bedrock model choice, grounding, guardrails, and cost.
- If managed options are not enough, review SageMaker JumpStart, open source, or marketplace models with licensing and security review.
- Choose custom training only when proprietary data, domain behavior, or control requirements justify the lifecycle burden.
- Build a pilot with representative data, baseline metrics, human review, and monitoring.
- Reject ML if deterministic rules meet the requirement with lower risk.
This workflow helps prevent overbuilding. A team should not train a custom model to translate common customer emails when Translate meets quality, cost, and governance needs. It also should not force a managed API into a domain where the service cannot meet quality or compliance requirements. Service selection is a risk and ownership decision.
Questions to ask before approval
Before approving a model source, ask who owns quality after launch, what happens when the model is wrong, how sensitive data is protected, whether outputs are explainable enough for the decision, what cost grows with usage, and whether the organization can exit or replace the model. For generative AI, add questions about hallucination, prompt injection, grounding, content safety, and user feedback. For custom or open source models, add questions about patching, license obligations, model cards or documentation, vulnerability scanning, and retraining plans.
The right answer is rarely the most complex model. The right answer is the smallest capability source that meets the business goal with acceptable accuracy, safety, cost, governance, and operational responsibility.
A company needs to convert recorded support calls into text and search the transcripts. Which model source should usually be evaluated first?
Which concern is especially important when adopting an open source model?
When is a custom model most justified?