What Happens After the Model Is Trained (the Part Most Projects Skip)

The unglamorous half

A trained model is a file. Everything between that file and a business using it is engineering: an API in front of it, a queue when load spikes, a cache so the same question is not paid for twice, a fallback for when the provider is down, a log of what it was asked, and an alert when its answers start drifting from what it was trained on. This is the work that decides whether an AI project survives its first year, and it is the work missing when a data-science engagement ends with an impressive notebook and nothing in production.

What gets built and run

• Model-serving APIs with authentication, rate limiting, queuing and graceful degradation
• Cloud AI deployment on AWS, Azure or Google Cloud, plus self-hosted GPU deployment where data must stay in-house
• Inference cost control — caching, batching, model routing and hard spend ceilings per tenant and per feature
• Monitoring — latency, error rate, token spend, and drift in both inputs and predictions
• Versioned rollout — shadow, canary and instant rollback, because a model change is a deployment

Retrofitting AI into systems already in service

A frequent brief, and rarely a rewrite. The pattern is to put the AI behind an interface the existing application already understands, so the change is additive and reversible — including feature switches per tenant, so AI can be enabled for one client and not another, and a rollback that returns previous behaviour without a release.

Maintenance is a contract, not a favour

Models degrade, providers deprecate endpoints and change prices, and dependencies acquire vulnerabilities. Ongoing support is quoted as its own agreement with a defined response time, rather than left as an assumption that someone will look at it. Where you would rather run it yourselves, the handover includes the runbooks.