I treat pilot success as a reason to consider production - not permission to launch. Before release, I check four gates: test coverage, user exposure, support ownership and failure limits.
A pilot asks, “Does this work within set limits?” Production asks, “Can we run and support this safely at the approved scale?” Here’s the difference.
Quick Comparison
| Decision gate | Pilot | Production |
|---|---|---|
| Test coverage | Check core tasks with a bounded sample | Test the whole workflow, including permissions, peak load, failures and recovery |
| User exposure | Invite trained users; limit data and actions | Approve user groups, permissions and each rollout stage |
| Support ownership | Name a pilot lead and contact hours | Assign service, support and incident owners, with backup cover |
| Failure limits | Set learning targets and stop conditions | Set service limits, alerts and rollback triggers based on potential harm |
Zero failures in 200 test cases do not prove reliability. I look at failure severity, missed errors and support workload - not just average accuracy.
My release rule is simple: approve the scope, record who accepts remaining risks, and choose whether to scale, restrict, fix or stop. More users, data or autonomy means another approval decision.
::: @figure 
{AI Pilot vs Production: Four Approval Gates}
:::
Episode 61 - Audit AI deployment controls: approvals, gates, and rollback readiness (Task 8)
Approval Gates: Pilot Evidence vs Production Requirements
Assign approval authority by risk, not project size. A low-risk internal assistant may need business and technical approval. Systems that affect employment, finance, health, safety, rights or customers may need formal approval from risk, legal, privacy, security and executive teams. Each approver signs off only on their remit.
The gates below set out the evidence and sign-off duties for pilots and production services.
| Evidence area | Pilot approval evidence | Production approval evidence | Accountable approver |
|---|---|---|---|
| Scope | Hypothesis, invited users, representative tasks and a fixed end date | Approved user population, service boundaries and rollout plan | Business owner; senior risk owner for higher-impact use |
| Controls | Bounded data, least-privilege access, human review and reversible changes | Validated integrations, enforced identity and access controls, segregation, security controls and privacy safeguards | Technical owner, with security and privacy authorities as applicable |
| Ownership | Named pilot lead and technical owner, with limited decision rights | Named service owner, engineering owner, support owner and incident lead | Executive or service owner proportionate to risk |
| Support ownership | Pilot team handles questions and defects during agreed hours | Service desk, escalation path, service-level targets, on-call cover and supplier responsibilities | Service owner |
| Observability | Basic quality, usage, cost and risk measurements | Continuous monitoring of quality, latency, availability, cost, incidents, drift, abuse and support demand | Service owner with risk and security oversight |
| Release authority | Pilot sponsor authorises the experiment | Formal change or release authority accepts residual risk and authorises operation | Pilot sponsor; production release authority and authorised risk owner |
Pilot sign-off proves the experiment is controlled - not that the service is ready to scale.
Pilot Approval: A Controlled Experiment
Before granting access, record the baseline, target outcome, permitted inputs and outputs, data sources, prohibited uses, duration, success thresholds and stop conditions. Define go-or-stop criteria for quality, adoption, cost, risk and delivery effort. Base failure thresholds on the consequences of failure, rather than a fixed rate.
| Permitted during the pilot | Excluded unless separately approved |
|---|---|
| Invited access for trained participants | Unrestricted customer or public access |
| Read-only or sandbox integrations | Production writes, payments or irreversible transactions |
| Synthetic, anonymised or tightly bounded data | Unapproved personal, special-category or confidential data |
| Human review before actions with material consequences | Unsupervised high-impact decisions |
| Reversible configuration and versioned prompt changes | Silent changes to models, prompts or retrieval sources |
| Time-limited experiments with a fixed end date | Open-ended use without a renewal decision |
Production sign-off shifts the focus from proving value to proving safe operation.
Production Approval: A Supported Service
Require validated end-to-end integrations, tested authentication and authorisation, security and privacy review, relevant UK legal and regulatory checks, and retention and deletion rules. Complete a data-protection impact assessment where required.
Approve a budget in £ that covers usage, infrastructure, monitoring, support and planned improvement - not just model charges. Monitoring must track quality, latency, availability, cost and incidents, with alert thresholds, response times and named responders.
Version-control models, prompts, retrieval content, policies, tools and configuration. Keep change approvals and enough information to reproduce a decision. Before launch, require tested recovery and rollback, incident playbooks and explicit risk acceptance.[3][4]
Document every gate decision: scope, evidence reviewed, assumptions, unresolved risks, conditions, approver names, decision date and review or expiry date. Record an explicit outcome - go, restrict, fix or stop - and name who may accept each remaining risk. If no authorised person accepts a material risk, restrict or stop the deployment.[2][5]
Match Test Evidence to User Exposure
Higher exposure needs stronger evidence. The same pilot may support different release decisions depending on who uses it, which data it touches and how much autonomy it has. Restricted access reduces harm, but doesn’t excuse safety, privacy or security defects. Before extending access, assess the proposed exposure against test results, remaining risks, monitoring coverage and readiness to roll back.[9][10][11]
| Exposure level | Evidence needed for approval | Condition for expansion |
|---|---|---|
| Restricted live pilot: invited users, bounded data and actions | Representative task results, permission checks and a suspension drill | Failures, overrides and incidents stay within agreed limits |
| Restricted rollout: approved cohorts and controlled integrations | Regression, integration, permission, failure-path, load, recovery and data-boundary tests; service monitoring | Service and risk owners review live results before increasing access |
| Full production: approved service scope and normal volumes | Reliability evidence, safe fallback, support ownership, auditability, user training and continued monitoring | The service stays within approved limits |
Match test depth to the exposure level - not the pilot label.
Test Coverage: Pilot Checks vs Production Tests
Test the whole workflow, including what users misunderstand and what happens when dependencies fail. For every test, record the dataset, system version, expected result and actual result. Report quality by task, group and severity: an overall average can hide harmful failures affecting a small group.[12]
| Test type | Pilot evidence | Production evidence | Owner | Gate impact |
|---|---|---|---|---|
| Representative data | Approved sample covering core tasks | Stratified cases covering operating conditions and relevant vulnerable groups | Evaluation and data leads | Coverage gaps restrict scope; unsafe data use blocks release |
| Task quality | Accuracy, completeness and refusal behaviour | Targets by task, group and severity; uncertainty reported where practical | Product owner | Minor gaps may be fixable; material errors block expansion |
| Human oversight | Observed reviews and disagreement logs | Override outcomes, escalation quality and reviewer effectiveness | Service owner | Ineffective oversight blocks reliance on human approval |
| Usability | Observed task completion and confusion | Accessibility, training and error-recovery validation | Product owner | Minor friction is fixable; unsafe critical journeys block release |
| Safety | Harmful-output, refusal and escalation tests | Red-team tests, safe-failure checks and incident-response validation | Risk owner | Serious unsafe behaviour blocks every gate |
| Privacy | Minimisation, lawful processing and leakage checks | Validated access, retention, deletion and audit trails | Data-protection lead | Unlawful processing or disclosure blocks release |
| Misuse | Adversarial prompts and suspension checks | Abuse detection, rate limits and response tests | Security lead | Uncontrolled material abuse risk blocks expansion |
| Regression | Recheck critical flows after changes | Automated critical tests on every material release | Engineering owner | Critical regression failures block deployment |
| Integration and permissions | Pilot connections and least-privilege roles | Identity, APIs, downstream actions and segregation tests | Engineering and security leads | Unauthorised access or unsafe actions block release |
| Failure paths and recovery | Manual fallback and suspension drill | Outage, timeout, rollback and data-reconciliation tests | Operations owner | Unsafe fallback or unreliable recovery blocks production |
| Load, latency and cost | Measurements within pilot limits | Peak, sustained and degraded-load tests; cost per successful task | Platform and finance owners | Breached approved limits prevent scale |
| Data boundaries | Attempts to access unapproved records | Cross-user isolation, export and system-boundary tests | Data and security leads | Boundary breaches block release |
| Staged release | Restricted activation and disable test | Phased activation, live dashboards and rollback-trigger tests | Service owner | Breached thresholds pause or reverse expansion |
A pilot issue is fixable only if it is limited, detectable and reversible without unacceptable harm.
Confusing help text may qualify; another customer’s information appearing in an answer does not.
Human review counts as a control only when reviewers can reliably spot the problem and prevent the action. Removing that review changes the evidence required.
Test evidence applies only to the users, permissions and data actually approved.
User Exposure: Invited Access vs Approved Rollout
Limit access by user, action, volume and data. Use permissions and feature flags to enforce workflow, transaction-value and data limits. Participant instructions alone aren’t enough. Require human approval before high-impact external outputs, and test suspension controls against privacy alerts, unsafe actions and unexpected spend.[8][9]
Higher exposure also requires named people responsible for support and authorised to stop the service.
| Access decision | Invited pilot | Approved production rollout |
|---|---|---|
| Eligible users | Named, trained participants | Approved groups mapped to documented roles |
| Permitted actions | Bounded workflows, transaction limits and restricted data | Explicitly authorised actions; no automatic grant of broader write access |
| Human approval | Before high-impact outputs leave the controlled workflow | Retained where risk requires it; autonomy separately authorised |
| Expansion authority | Pilot lead recommends changes within the approved scope | Named accountable decision-maker authorises expansion with relevant risk approvals |
| Failure handling | Suspension control and manual fallback | Tested fallback, alerts and monitoring of failures, overrides and complaints |
Set entry and stop conditions for each rollout stage before admitting users. Compare live outcomes with pre-release tests, including abandonment, fallback use, support demand and the stage’s approved failure limit. Reassess the evidence whenever exposure increases.[10][12]
Set Support Duties and Failure Limits
Once test coverage and exposure are set, the final two gates are support ownership and failure limits. Both are conditions for approval, not tasks to leave until after launch. Record who responds, when they respond, which channel they use, and what triggers restriction or suspension.[13][2]
Support Ownership: Pilot Leads vs Service Owners
| Responsibility | Limited pilot | Production service |
|---|---|---|
| Business ownership | Pilot lead gathers feedback and prioritises issues | Service owner owns service outcomes and priority decisions |
| Technical ownership | Named lead coordinates technical fixes | Technical owner owns reliability, security, releases and rollback |
| User support and coverage | Monitored feedback channel, named contact and agreed pilot hours | Agreed support hours, backup cover, alert ownership, and response and restoration targets |
| Escalation and incident authority | Named contact can pause the pilot immediately | Incident leads have documented authority to suspend, release and roll back |
| Improvement duties | Maintain issue and override logs | Track incidents and fixes, maintain runbooks and fund maintenance |
Named owners need the means to detect and respond to failures in time. Small teams can combine roles, but must document each duty separately, including backup cover, an escalation route, working hours and the maximum concurrent workload. High-impact changes need independent review.[14][6][7]
Before production approval, rehearse at least one high-severity incident and check that alerts reach the responsible person.[13]
Failure Rates: Pilot Thresholds vs Production Limits
Before testing starts, define what counts as a failure, the denominator, the measurement period and the severity. Set quality targets, failure limits and correction-workload limits based on potential harm, workflow criticality, user exposure and legal duties - not pilot results alone.[14][6][2]
| Measure | Pilot learning threshold | Production service limit |
|---|---|---|
| Unsafe, unlawful or privacy/security failure | Log every event and its severity; severe failures trigger suspension | Separate critical threshold; severe failures block release regardless of average quality |
| Materially incorrect outcome | Incorrect drafts ÷ reviewed drafts, with sample size and test dates | Materially incorrect actions ÷ all eligible cases over a stated rolling period, split by task and affected group |
| Unavailable service | Failed attempts ÷ all eligible attempts during pilot hours | Availability service-level indicator (SLI) measured against an agreed service-level objective (SLO) and error budget |
| Delayed outcome | Cases exceeding the workflow’s time limit ÷ eligible cases | Defined delay limit and measurement window, with alerts and escalation |
| Correction workload | Corrections ÷ reviewed outputs, plus correction time | Maximum correction rate, reviewer workload and unresolved backlog |
Zero observed failures do not prove reliability. A 200-case pilot cannot rule out rare failures. Use targeted high-impact tests and report sampling uncertainty.[14]
Route reviews using measured accuracy, severity, reviewer agreement and missed-error rates - not model confidence alone. Sample high-confidence outputs too.[14][12][6]
A 99.9% SLO allows 0.1% unreliability and turns reliability into a release rule.[1]
Use these limits, alongside support readiness, to decide whether to release.
Gate Decisions: Scale, Restrict, Fix or Stop
| Decision | Required evidence | Decision owner | Exposure change |
|---|---|---|---|
| Scale | Targets met; support, alerts, runbooks and rollback tested; no unresolved severe incidents | Service owner with business approval | Increase users, cases or workflow scope gradually |
| Continue with tighter controls | Promising results, but uncertainty, workload or specific failures call for added controls | Pilot or service owner, with risk approval | Keep or reduce exposure; add mandatory review, narrower permissions or restricted users |
| Remediate and retest | Target, trend or support measure missed; risk can be controlled and cause is understood | Technical and service owners | Freeze expansion; fix prompts, data, model, process or controls and repeat tests |
| Stop or suspend | Severe failures, failed fallback, missed alerts or inadequate support capacity | Named suspension authority, with senior escalation | Disable the feature or service, notify affected users, and investigate |
Conclusion: Evidence Needed for Release and Expansion
Pilot success informs production approval; it does not replace it. Each of the four gates - test coverage, user exposure, support ownership and failure limits - needs evidence that matches the proposed deployment.
Before production, put controls and monitoring in place, name the support owner, test recovery and provide a human fallback.
Expansion needs separate approval, using the same gates at a higher level of exposure. Require sustained performance over an agreed observation period, trained support capacity, acceptable unit cost and no unresolved critical incidents. Record the evidence reviewed, the accountable decision-maker, any conditions and the next review date.
Hokstad Consulting supports AI strategy, transformation and custom agent implementation.
Final approval and risk acceptance remain with the client’s authorised owners.
FAQs
How much testing is enough before production?
Prove reliability and measurable business value before production. Complete at least three safe, successful cycles before scaling pilots. Automated tasks must achieve a first-time test pass rate of at least 95%.
Test routing thresholds on 20–50 representative tasks, covering successes, failures and edge cases. Then validate them against a larger holdout dataset.
Block release if any mandatory check fails. Fix the issue and run a full retest. Check security, data protection and readiness to operate, and confirm that logs let you reconstruct incidents.
How do I set acceptable AI failure limits?
Set acceptable AI failure limits using labelled evaluations and measurable business outcomes, not model confidence scores. Base these thresholds on business risk and legal requirements. For automated tasks, aim for a first-time test pass rate of at least 95%. For high-usage systems, target an error rate of 0.1–1.0%.
Use schema validation and evidence verification to trigger escalation. Limit retries to three to five attempts before requiring human oversight. High-stakes actions must have formal sign-off and rollback plans.
Can a small team safely support production AI?
Yes - with clear accountability, risk-based controls and enough support capacity. Define the business owner, service owner and risk approver roles. Match oversight to the level of risk: post-action audits for low-risk work, threshold-based approvals for medium-risk tasks and human sign-off for high-risk actions.
Before launch, check that training, runbooks, monitoring, circuit breakers and escalation routes are in place. Give each agent a named owner and an access profile. Keep records detailed enough to reconstruct a test run or simulated incident.