A court clerk's office trained a case-category classification model on a data scientist's laptop entirely outside any AWS service, and now needs it hosted in production for clerks to use. What is the right way to get it into service?
Select an answer to reveal the explanation.
Short Explanation
A model trained on a laptop isn't stuck there — it just needs to be packaged the way the hosting service expects. Wrap the trained artifact in a container that speaks SageMaker's interface, and SageMaker AI hosting takes it from there. The training location doesn't matter; the packaging does.
Full Explanation
SageMaker AI hosting accepts externally trained model artifacts as long as they're packaged into a container that implements the interface SageMaker expects for serving predictions, so a laptop-trained classifier can move straight into managed, scalable hosting without ever having been trained inside AWS. Bedrock Custom Model Import is scoped to foundation models being brought into Bedrock's managed FM inference, not traditional classifiers like a case-category model, so it's the right idea applied at the wrong layer here. Insisting the model be retrained inside SageMaker before deployment misunderstands the platform: SageMaker hosting is decoupled from SageMaker training, and plenty of artifacts trained elsewhere are deployed to it every day, so retraining would waste effort that adds no value. Running the model on a data scientist's personally managed EC2 instance trades away managed scaling, patching, and monitoring for a one-off setup that becomes a single point of failure and an operational risk once clerks depend on it. Scope note: confirm the container's inference logic matches the exact preprocessing the model expects, since a mismatch here is a common source of silent production errors. Operational check: run a held-out validation batch through the deployed endpoint and compare predictions against the original laptop environment's output.