In brief
- Production readiness is evidenced operational capability, not the end of a successful demo.
- Quality limits and critical failures must be defined and tested with representative cases.
- Applicable privacy, AI, transparency and content-right requirements must be evidenced and signed off before release.
- Monitoring covers model behaviour, data, tools, security, cost and human corrections.
- Owners, support, incident response, rollback, change and retirement must be established before launch.
Are purpose and quality sufficiently evidenced?
The audience, permitted use and out-of-scope uses are documented. A versioned test set covers normal cases, exceptions, risks and deliberately unanswerable tasks. Minimum thresholds and critical exclusions reflect failure impact rather than one average score.
- A specific workflow, user group and success criterion
- Representative evals with domain review and regression tests
- Visible evidence, uncertainty and explicit refusal rules
- Documented limits and a safe route to human handling
Are data, access and actions controlled?
The data flow is understood for every component and environment. Identities and permissions are enforced outside the model. External content and tool results are treated as untrusted; sensitive actions are technically constrained and subject to approval where necessary.
- Permitted data, retention, deletion and provider terms clarified
- Least privilege for users, services, sources and tools
- Protection against prompt injection, data leakage and unauthorised action
- Security, privacy and abuse testing before release
Has the legal and contractual release gate been passed?
Technical readiness does not establish that a particular use is permitted. Before release, accountable owners determine which laws, contracts and internal policies apply to the intended purpose, affected people, data, regions and sector. An unresolved mandatory requirement blocks the release rather than becoming an undocumented operating risk.
This gate is AI governance applied to one concrete system and version. It should be repeated when the purpose, data, model, provider, users or level of automation changes materially.
- Applicability and use
- Document the intended and excluded uses, jurisdictions, affected people and any sector, employment or customer-specific requirements.
- Privacy and DPIA
- Confirm purpose, data minimisation, notices, processor terms and whether a data protection impact assessment is required before processing begins.
- AI role and risk
- Where relevant, identify the organisation's AI role, classify the use and complete the resulting risk-management and conformity obligations.
- Transparency and rights
- Provide required notices, human contact or review, contest routes and disclosure or marking of AI-generated content where applicable.
- Data and content rights
- Verify permission to use personal and confidential data, source material, prompts, outputs and any training or evaluation content.
- Evidence and sign-off
- Retain contracts, assessments, test evidence, mitigations, version and accepted residual risks, followed by named business and control-function approval.
Can the solution be operated reliably?
Production needs measurable service objectives, capacity planning and defined behaviour when dependencies are slow, limited or unavailable. Changes to model, prompt, data source or tool are versioned and released only after testing.
- Step 1
Observe
Capture latency, failures, tool paths, quality signals, cost and unusual usage.
- Step 2
Constrain
Set quotas, budgets, timeouts, retry limits and safe degradation.
- Step 3
Respond
Test runbooks, alerting, incident roles and communication.
- Step 4
Roll back
Be able to return to a known version or a manual process.
Are ownership and introduction defined?
A named team owns product value, domain quality, technology and operations. Users understand purpose, limits, permitted data and the reporting route. Launch is phased so new failures can be detected before the solution reaches a broad audience or receives greater permissions.
- Named business, technical and operational owners
- Staffed support, escalation and accountable approval roles
- Joint review of usage, quality, fully loaded cost and value after launch
- Defined criteria for expansion, pause and complete retirement
Example: a document assistant before production launch
The prototype extracts contract data convincingly. Before production, the team adds a representative test set, role and tenant separation, logs, cost limits and a review queue for uncertain fields. Document-processing outages return cases to the manual process. Model and prompt versions can be rolled back; business and IT jointly own support and monthly quality review. Before approval, the accountable function also confirms that provider and processing contracts match the data flow, any required DPIA and risk classification are complete, and the release has documented sign-off. Only then does a limited user group go live.
What to remember
Release an AI solution only when quality and limits are evidenced, legal and contractual requirements are signed off, and an accountable team can operate its data, security, reliability, change, cost and incidents in practice.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed