Learn AI /Data and Infrastructure /Deployment
Deployment
- Starter
- Data and Infrastructure
- Managers & front offices
- Programme & data teams
Also called: going live, in production.
Back to the milestone you came from
In five seconds
What it is
Deployment means putting an AI system into real use so people or software can send it live inputs and receive live outputs.
In plain words
Deployment is the step where an AI model stops being a test project and becomes a live tool that real people or software use.
An everyday example
A shipping company tests a new tool that compares a delivery against its manifest. In the office, it works on sample lists. To use it at the loading dock, the team installs it on a tablet, connects it to the barcode scanner, sets who can use it, and decides what happens if the network fails. Once it is live, drivers scan boxes and the tool returns match, mismatch or needs human review in real time.
A manifest checker usually follows clearer rules than many AI systems. Real AI deployment can involve uncertain outputs, changing data patterns, scaling to many users, and version management. Also, some deployed systems keep learning offline and are updated later, while the tablet story sounds more fixed than that.
Remember thisA model is deployed only when it is connected to live work and operated as a service, with access controls, monitoring, human review, fallback and rollback.
Understand it
Understand it
Why it matters
For non-specialists, deployment is the point where an AI idea becomes an operational service with cost, risk and accountability. A model that looked impressive in testing can fail in practice if it is slow, expensive, insecure, hard to monitor or exposed to different data than expected. Decisions about deployment affect procurement, privacy, staffing, fallback procedures, user trust and whether humans stay in control. If you approve or use an AI system, you need to ask not only 'How accurate was it in testing?' but also 'Where will it run, who can access it, how will it be watched, and what happens when it is wrong or unavailable?'
From tested model to live service
Show the main steps that turn a model from a tested artefact into a monitored service people or software can use safely.
01
1. Start with a tested model
A model has already been built and checked on test data, but it is not yet available in a real workflow.
Draw a rectangle labelled 'Tested model' with a small file icon and a note 'works in testing'.
02
2. Place it on infrastructure
The model is put on a server, cloud service or device with enough compute and storage to run it.
Draw a second rectangle labelled 'Run environment' with server or device icons; connect from step 1 with an arrow.
03
3. Connect inputs and outputs
Forms, apps, databases or other software are linked to the model through an endpoint so requests can be sent and answers returned.
Draw a third rectangle labelled 'Connected to workflow' with arrows in from an app/database icon and arrows out to a result panel.
04
4. Add controls
The system gets authentication, rate limits, logging, fallbacks and, where needed, human review before action is taken.
Draw a fourth rectangle labelled 'Controls and safeguards' with small shield, speedometer and human-check icons.
05
5. Go live and monitor
Real users or systems start using it. Teams watch speed, failures, cost and changes in data so they can update or roll back if needed.
Draw a fifth rectangle labelled 'Live service' with a small dashboard beneath showing latency, error rate and traffic.
An ordered diagram with five boxes connected left to right. Read from a model that worked in testing to a live service that receives requests and is watched over time. Each box names one practical step in deployment rather than model training.
On click or keyboard focus, each step expands to reveal its explanation; a final toggle highlights the difference between 'hosting only' and 'full deployment'.
Describe this without the diagram
This diagram explains deployment as a five-step process. First, there is a tested model that works in evaluation but is not yet connected to real work. Second, it is placed on infrastructure such as a server, cloud service or device so it can run. Third, live inputs and outputs are connected through an endpoint, letting apps or other systems send requests and get results. Fourth, controls are added, including authentication, rate limits, logging, fallbacks and human review where needed. Fifth, the system goes live and is monitored for speed, failures, cost and changes in real-world data. The key message is that deployment means operationalising a model, not only storing it somewhere.
With reduced motion: A static five-box sequence shows the same process without animation: tested model, run environment, connected workflow, controls and safeguards, and live service with monitoring.
A model can work well in a test notebook and still not be ready for real use. Deployment is the stage where that model is connected to the systems, devices or websites that people actually use. Inputs might be text from a form, an image from a camera, or rows from a database.
During deployment, the model runs on infrastructure such as a server or device. It may be embedded in an application or connected through an endpoint, a network address plus rules for exchanging requests and responses. Rules are also added for security, speed, logging and human oversight.
A deployed system must receive and check inputs, run the model, return outputs, and cope with failures or heavy traffic. Teams often watch latency, meaning delay, cost, and distribution shift, which means real-world data no longer looks like the data used earlier.
The result is a working service, not just a model file. Hosting covers the systems and services that keep the model available to receive requests, run and return outputs reliably and securely. Deployment is broader: it also includes workflow integration, controls, monitoring, updates and rollback.
How “Putting a manifest checker onto the loading dock” maps onto the real thing
| In the story | In the AI system |
|---|---|
| sample lists tested in the office | model evaluation before real-world use |
| tablet and barcode scanner at the loading dock | live infrastructure and connected input systems |
| drivers scanning boxes and getting results | real requests sent to a deployed service |
| plan for network failure and human review | fallbacks, monitoring and operational controls |
A worked example
An information management officer supporting conference services in Bonn must put a trained classifier into the facilities ticketing application before the next room-booking round opens. It will suggest whether each live request concerns room setup, building access, equipment or another issue, with service-desk staff confirming the label.
Starting from: New ticket text and existing non-sensitive routing fields from the approved ticketing system.
- The officer packages the trained model with its software dependencies and installs it on approved production infrastructure.
- The ticketing application sends each new request to an authenticated model endpoint and receives a suggested category.
- Rate limits protect the service from traffic spikes, while failed or low-confidence requests fall back to the general queue.
- Logs record response times, errors and model versions without retaining unnecessary ticket content.
- Before each update, staff test the new version and keep the previous version available for rollback.
Result: The classifier now handles live requests inside the ticketing workflow. Staff retain the final routing decision, service performance is monitored, and requests continue to reach the general queue if the model is unavailable.
In a United Nations workplace
At a shared services centre, a knowledge management officer is finalising the note for the file after a bilateral. The centre is deploying a model inside the approved records application to suggest metadata and access markings before the note is uploaded to the portal. The live service must return suggestions to the officer while leaving clearance and filing decisions with staff.
Deployment is the point at which the trained model meets the actual workflow. The release needs approved hosting, authenticated access, a connection to the records application, logging, monitoring, fallback behaviour and a tested way to restore the previous version if the update misbehaves.
Before you try thisA note for the file may contain confidential or politically sensitive material. It must not be entered into an external or otherwise unapproved AI service. The production environment must be approved for the material concerned, access must be restricted and logged, and the officer must verify every suggested marking before clearance.
Where you may hear it
- A vendor demo during a procurement meeting
- An ICT governance board reviewing a production release
- A go-live readiness meeting with the service owner
- An incident review after a model endpoint fails
- A change-control discussion before a model update
Avoid confusion
Avoid confusion
Often confused with
Model hosting
The systems and services that keep an AI model available so it can receive requests, run on computing hardware, and return outputs reliably and securely.
Endpoint
A network address where software sends requests to a service and receives responses according to an API's rules.
Cloud computing
Using on-demand computing services over a network, instead of relying only on machines you manage directly.
Common misconceptions
Common misconception: If a model scored well in testing, deploying it is just a technical formality.
Correction: Testing uses limited conditions. Real use adds messy inputs, traffic spikes, integration problems, user behaviour, security requirements and changing data. Deployment is where many practical failures appear, so operational planning matters as much as model quality.
Common misconception: Deployment and hosting mean the same thing.
Correction: Hosting usually refers to where the model runs. Deployment is wider. It includes connecting the model to real inputs and outputs, setting controls, monitoring behaviour, and managing updates or rollback if something goes wrong.
Common misconception: Once an AI system is deployed, it will keep working the same way.
Correction: Real-world conditions change. Users may send different kinds of inputs, organisations may change processes, and traffic may grow. A deployed system needs monitoring and maintenance because performance, cost and risk can shift over time.
Quick check
Which description best matches deployment?
Deployment is broader than storing or testing a model. It means making the model available in real use, linking it to inputs and outputs, adding operational controls, and monitoring what happens after it goes live.
Go deeper
Go deeper
The simple version
Deployment is the step where an AI model stops being a test project and becomes a live tool that real people or software use.
The technical version
Deployment is the operational release of a trained model into a production environment. It typically includes packaging the model and dependencies, provisioning compute, exposing an endpoint or embedding the model in an application, connecting live data flows, enforcing authentication and rate limits, enabling logging and observability, defining fallback behaviour and human review, and managing versioning, rollback and updates. In practice, deployment is about reliable inference under real conditions, not just whether the model can run once on a developer's machine.
Reviewed external resources
Primary sourceAI Risk Management Framework (opens in a new tab)NIST
This link gives a risk-management framework for designing and operating AI systems responsibly and suits managers, risk teams and implementers.
Intermediatelink checked 2026-07-31
Primary sourceOECD AI Principles (opens in a new tab)OECD
This link gives high-level principles for trustworthy AI governance and suits leadership, policy readers and programme teams.
Intermediatelink checked 2026-07-31
EncyclopaediaSoftware deployment (opens in a new tab)Wikipedia
This link gives a broad software background on deployment and suits readers who want a general introduction before focusing on AI-specific issues.
Intermediatelink checked 2026-07-31
VideoVideo explanations: Deployment (opens in a new tab)YouTube search
This search-results page gives many video explanations of deployment and suits readers who prefer to compare different teaching styles rather than read one source.
search results, not one pagelink checked 2026-07-31
DiscussionCommunity discussion: Deployment (opens in a new tab)Reddit search
This search-results page gives community discussions and practical experiences about deployment and suits readers who want informal questions, examples and troubleshooting themes.
search results, not one pagelink checked 2026-07-31
Where this came from
Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.
The one thing to remember
A model is deployed only when it is connected to live work and operated as a service, with access controls, monitoring, human review, fallback and rollback.