From AI pilot to production. The model is one layer in four.
A pilot proves a model can do a task. Production proves you can rely on it.
A pilot shows that a model can perform a task on prepared examples. Production shows that an organization can depend on it every day, with failures visible, contained and reversible. The gap between the two is rarely the model. It is architecture, testing and operations, and it can be specified in advance.
Four layers, with versioning across all of them.
The pattern is vendor-neutral: any model provider, or a self-hosted model, can sit behind it. Its purpose is to keep the model replaceable and its output checkable.
Pilot to production · Reference pattern
Four layers, one of them is the model.
Scroll the diagram sideways to see all of it.
Read the diagram as text
- The existing application stays the system of record. It hands a case to the workflow and receives only validated writes back.
- Workflow logic is ordinary deterministic software: it sequences steps, applies rules, holds state, retries safely and guarantees idempotency.
- The controlled AI capability is the single gateway to any model: versioned prompt templates, input filtering, output schema validation, rate and cost limits, and a provider abstraction.
- The model itself is a provider service or a self-hosted model, interchangeable behind the gateway.
- Proposals and their evidence go to the reviewer loop: a queue, decisions, overrides and the stored evidence. Decisions return to the workflow.
- Monitoring and version control span the chain: quality, latency, cost, override rate and drift are measured; prompts, models, rules, indexes and evaluation sets are versioned.
The existing application stays the system of record. The AI never writes to it directly. The workflow logic is ordinary deterministic software that sequences steps, applies rules, holds state and guarantees that a retry never acts twice. The controlled AI capability is one gateway for every model call: versioned prompt templates, input filtering, output schema validation, rate and cost limits, and an abstraction that lets you change provider. The evidence and reviewer loop puts proposals in front of people with their evidence and records what they decide.
Across the whole chain sit monitoring (quality, latency, cost per case, override rate, drift) and version control of every component that can change behavior: prompts, models, rules, retrieval indexes and the evaluation sets themselves.
Seven tests, thresholds written before the run.
Each test has a measurement and a threshold agreed with the process owner before testing starts. Setting thresholds after seeing results is how weak systems get approved.
| Test | What is measured | How the threshold is set |
|---|---|---|
| Accuracy on labelled cases | Field-level or decision-level precision and recall on a held-out set that reflects real volume, hard cases included. | Against the measured manual error rate, field by field. |
| False positive and false negative burden | How many items are wrongly flagged (reviewer time) and wrongly passed (downstream cost). | From reviewer capacity and the cost of a missed error. The two are traded against each other explicitly. |
| Response time | End-to-end latency at the median and the 95th percentile, retries included. | From the process: overnight batch, or a customer waiting. |
| Cost per case | Model calls, infrastructure, and reviewer time per case. | Below the baseline cost per case, at expected volume. |
| Failure and retry handling | Injected timeouts, malformed outputs, duplicate inputs, a provider outage. | Zero partial writes, zero double actions, every failed case visible in a queue. |
| Privacy | Actual payloads sent to the model, log contents, retention settings, retrieval permissions tested with test users. | Only specified fields leave the application; no user retrieves a document they cannot open. |
| Rollback | A rehearsed return to the previous version, and to manual processing. | Completed within an agreed time with no lost cases. |
No test makes a system safe in absolute terms. Passing these tests shows that the risks you measured are within limits you chose, on the cases you tested. Production brings cases you did not test. Monitoring is how you find them.
Every change reruns the evaluation set.
- Override rate is the best early warning. When reviewers start correcting more, something has drifted: the inputs, the model, or the process.
- Sampled review of passed items, not only flagged ones, catches confident errors that never reach a queue.
- Change control: any change to a prompt, model version, rule or index reruns the evaluation set, and the result is stored with the version register before release.
- Provider changes count as changes. A model version retired or updated by the provider triggers the same rerun.
- Periodic re-evaluation adds new labelled cases from reviewer corrections, so the test set keeps pace with reality.
Good engineering first; legal classification confirmed separately.
If a system falls within a high-risk category of the EU AI Act, obligations such as risk management, record-keeping, human oversight, and accuracy and robustness documentation apply to it. According to the European Commission's overview, consulted on 22 October 2026, an amending regulation in force since 27 July 2026 set those obligations to apply from 2 December 2027 for the high-risk uses listed in Annex III, and from 2 August 2028 for AI embedded in regulated products.
Many operational SME workflows, such as invoice intake or internal document search, will not be high-risk. But classification depends on the purpose of the system and must be confirmed with counsel, not assumed. The practices in this guide are sound engineering in either case, and they produce much of the evidence a high-risk regime would ask for. The NIST AI Risk Management Framework offers a voluntary structure for the same work through four functions: govern, map, measure and manage.
What this guide does not do.
- It does not give legal advice or determine whether the EU AI Act applies to your system.
- The regulatory dates above come from the Commission's overview on the date shown and may change; check the source.
- It does not prescribe thresholds. Thresholds depend on the process, its volume and the cost of errors.
- It covers decision-support workflows with human review, not fully autonomous systems acting without one.
- NISTAI Risk Management Framework, AI RMF 1.0, released 26 January 2023.
- NISTGenerative Artificial Intelligence Profile, NIST AI 600-1, released 26 July 2024.
- European CommissionAI Act: regulatory framework for AI. Consulted 22 October 2026 for the application timeline.
- CNILIntelligence artificielle : le guide, for the personal data aspects of testing and logging.
Engineer with a doctorate in IT and systems from Sorbonne University. Leads the Applied AI practice. Full profile.