Is deployment the same as model serving?

Not always. Serving predictions is one technical activity; deployment can include broader integration and readiness work.

Must an AI deployment run in the cloud?

No. It can operate locally, on devices, or in other suitable environments.

Does deployment require retraining?

No. A release may change packaging, configuration, or integration while using the same trained model.

AI Glossary / MLOps and deployment / Intermediate

Deployment

Definition

Deployment is the process of placing an AI system or component into its intended operating environment and making it available for use. It connects a developed capability with the software, data, people, and procedures that use its outputs. In this broad lifecycle sense, deployment includes more than uploading a model file or starting a prediction server.

What it means

A model may perform well during development while the surrounding application is still unready for real use. Deployment addresses that transition: where the system runs, how it receives inputs, who uses outputs, and what happens when it cannot complete its task.
The operating environment could be a scheduled batch process, an online service, an embedded device, or an internal application. Some platforms use model deployment more narrowly for a network-accessible prediction endpoint. Naming the intended environment prevents confusion between that narrower product meaning and the broader deployment lifecycle.
Deployment is also distinct from training. It may use a previously trained model without changing the model's learned parameters.

How it works

Identify the intended use, system version, required inputs, output interface, and operating responsibilities. Prepare the software environment and integrations, then test the complete path with representative conditions.
Choose a release approach suitable for the system. A team may begin with a limited pilot, run a candidate without exposing its outputs to users, or introduce it to a defined portion of eligible activity. These approaches answer different questions and need clear success and stop criteria.
After making the system available, observe both technical behavior and whether users can accomplish the intended work. Preserve enough version and configuration information to investigate outcomes and support an appropriate fallback. Ongoing operation continues after the initial release event.

Three practical examples

A nightly demand forecast can be deployed as a scheduled job whose validated outputs feed a planning dashboard.
A text-assistance tool can be introduced to an internal support team with clear controls for reviewing suggestions before use.
A visual-inspection model can be integrated into a device application, with testing of its actual input format and behavior when required resources are unavailable.

Think of it this way

Think of opening a new workshop. Owning working tools is only one part of readiness; people also need power, supplies, clear procedures, and a way to handle breakdowns. Deployment similarly brings an AI capability into an operating context. The analogy does not capture software versioning or statistical model behavior, but it explains why a functioning component is not the whole service.

Worked example

Consider an invented internal suggestion tool intended to help staff handle 500 requests during a pilot. The team defines two separate observations: technical completion and suggestion usefulness. A request counts as technically completed only if the application returns a usable response in the required format.
During the pilot, 480 requests complete technically and 20 do not. Technical completion is 480/500 = 96%. Among the 480 completed responses, staff judge 360 suggestions useful under a predefined review rule. Conditional usefulness is 360/480 = 75%.
Across all attempted requests, useful completed suggestions are 360/500 = 72%. Reporting only the 75% figure would omit technical failures from the denominator. Reporting only 96% would say little about whether the returned content helped.
The team reviews the 20 failures separately from the 120 completed but unhelpful suggestions. The first group may expose integration or runtime problems; the second may expose model or workflow issues. Those possibilities require investigation rather than being established by the counts alone.
These invented measurements do not define acceptable release thresholds. They show why deployment evaluation should connect component behavior to the complete user task and state each metric's denominator.

Illustrative case study

In a fictional inventory project, a forecast runs successfully in testing but is delivered after planners have already finalized their daily decisions. Its numerical quality does not make the deployment useful at that time.
The team revisits the operating schedule, input availability, and dashboard handoff. It tests whether the forecast arrives before the decision deadline and clearly marks missing or delayed results.
The case illustrates that deployment success depends on the application context. A model can produce a valid output while the overall workflow fails to provide value when it is needed.

Common misconceptions and mistakes

Do not equate deployment with a public launch. An internal or limited operational release can also be a deployment.
Do not treat a successful startup or a passing health check as proof that the full user task works. Include input handling, meaningful outputs, and downstream integration.
Do not assume a rollback of model weights reverses every consequence of a release. Data formats, external writes, and user actions may require separate handling.
Do not assume deployment ends the need for evaluation. Operating conditions, dependencies, and user behavior can change. Finally, avoid treating one platform's endpoint terminology as the only valid meaning of deployment.

Business use

Deployment planning clarifies who owns the transition from an experiment to a supported capability. Useful decisions include the intended audience, release scope, operating requirements, support ownership, and how evidence will determine whether to expand or revise use.
Connect technical measures with task outcomes. A service's availability matters, but so do output relevance, timeliness, and the work required from users. Document the released model, application, configuration, and dependencies together so that a later investigation can identify the system that actually produced an output.

Check your understanding

A forecasting job finishes without errors but its results arrive after the planning deadline. Is technical completion enough to establish deployment success?

Answer: No. The deployed workflow must meet its intended timing and use requirements as well as execute correctly.

Related terms

Model Deployment
model serving
release management
production environment
pilot
integration testing
model monitoring
and rollback

Learn next

Map one AI output from input collection to the user's decision. Identify the owner, timing requirement, and failure behavior at every handoff. Use that map to define a small, observable deployment evaluation.

Sources

Sources: NIST AI RMF 1.0, Appendix A, deployment and operation tasks: https://airc.nist.gov/airmf-resources/airmf/appendices/app-a-descriptions-of-ai-actor-tasks/ Hopsworks dictionary, narrower model-deployment terminology: https://www.hopsworks.ai/dictionary/model-deployment

Previous: Dependent variable Next: Deployment Bias