The week after the pilot demo is when the truth arrives.
The output looked good in the conference room. The sponsor wants to expand access. The team wants credit for progress. Someone asks whether the AI system can now be used by real operators, with real data, inside the real workflow.
That is the moment to slow down. A production AI system is not a pilot with more users. It is a workflow with boundaries: what it can read, what it can draft, what it can recommend, what it can change, who approves, what gets logged, what happens when it is wrong, and who keeps it healthy after launch.
NIST’s AI Risk Management Framework frames AI risk management across design, development, use, and evaluation. OWASP’s 2025 Top 10 for LLM and Gen AI Apps names the risks production systems actually face: prompt injection, sensitive information disclosure, supply chain weakness, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. IBM’s 2025 Cost of a Data Breach report adds the governance pressure: the average breach cost is $4.4 million, and among organizations with AI-related incidents, 97 percent lacked AI access controls and 63 percent lacked AI governance policies. Metacto’s Continuous AI Operations is the operating response: monitoring, evals, tuning, incidents, runbooks, and monthly reviews.
A production gate is not bureaucracy
The gate protects the workflow. If the system will touch customers, employees, money, regulated data, CRM, ERP, tickets, or approvals, it needs production controls before it gets production trust.
The seven proofs before production
Use this checklist when the pilot sponsor says, “This is working. Can we roll it out?”
Production AI readiness checklist
Do not let a pilot graduate because it produced a good answer once. It graduates when each proof has an owner and artifact.
Proof: Workflow proof
- What must be true
- The system supports a named workflow with a trigger, owner, review step, and completed action.
- Evidence to request
- Workflow map, recent examples, baseline, and target metric.
Proof: Context proof
- What must be true
- The system can cite or expose the records, documents, policies, and examples behind the output.
- Evidence to request
- Source list, retrieval examples, freshness rules, and source-of-truth decisions.
Proof: Permission proof
- What must be true
- Access is limited by role, data type, action, and approval state.
- Evidence to request
- Scopes, auth model, service accounts, secrets handling, and denied-action list.
Proof: Review proof
- What must be true
- Humans know what they approve, edit, reject, escalate, and sign.
- Evidence to request
- Review UI, rubric, escalation rules, and decision log.
Proof: Evaluation proof
- What must be true
- The workflow has test cases for expected outputs, edge cases, regressions, and failure modes.
- Evidence to request
- Eval set, acceptance thresholds, test cadence, and owner.
Proof: Monitoring proof
- What must be true
- Quality, adoption, cost, latency, incidents, and business movement are visible after launch.
- Evidence to request
- Dashboard, alert thresholds, runbook, and review cadence.
Proof: Operating proof
- What must be true
- Someone owns support, incident response, tuning, and expansion decisions after launch.
- Evidence to request
- Named process owner, technical owner, support path, and monthly operating review.
Where pilots usually fail the gate
The most common failure is invisible context. The AI output looks fluent, but the reviewer cannot see whether it used the latest policy, the correct customer record, the right contract clause, or a stale spreadsheet. That is not a model problem first. It is a context design problem.
The second failure is authority. A system that can draft a CRM update is different from a system that can write to CRM. A system that can summarize an invoice exception is different from one that can approve payment. Metacto’s AI Agents & Workflows treats that distinction as a core design choice: AI should receive only the authority the workflow can justify.
The third failure is operations. A pilot can survive with one enthusiastic builder watching every output. Production cannot. If no one knows how regressions are detected, how prompts or context changes are evaluated, how users report issues, or how rollback works, the pilot is not ready. A production packet should make the same operating muscles visible that Metacto uses in Continuous AI Ops, including incident runbooks and drift reviews before expansion.
Risks to catch before production
These risks are where governance has to be embedded into the workflow. Policies do not help if access, logs, approval, and rollback are missing at the point of action.
Overbroad access
Catch early
Signal: The agent inherits more permissions than the workflow requires.
Control: Limit scopes by role, action, data type, and approval state.
Unlogged action
Catch early
Signal: No one can reconstruct what the agent saw, produced, recommended, or changed.
Control: Log sources, outputs, reviewer decisions, tool calls, and write-backs.
No rollback path
Catch early
Signal: The team can spot a bad output but cannot quickly undo the downstream action.
Control: Define rollback, owner, severity, and response cadence before launch.
Use the risk checklist as a conversation with the sponsor. If the answer to “Who owns this after launch?” is “the AI team,” ask again. The operating owner should be the leader who owns the workflow outcome, with technical support responsible for the system.
The Metacto production standard
Metacto’s point of view is simple: production AI needs the same seriousness as production software, plus the additional controls that come from probabilistic output and tool-using agents.
That does not mean every workflow needs an enterprise governance program before it ships. It does mean the controls should match the consequence of the action.
- A read-only internal research assistant may need source citations, access boundaries, and usage monitoring.
- A customer-facing support workflow needs stronger evaluation, escalation, brand review, and incident response.
- A finance, compliance, HR, or revenue write-back workflow needs role-based permissions, approval logs, rollback, and auditability.
The production gate should scale with risk. It should not disappear because the demo was impressive.
What to require before expansion
Before adding more users or adjacent workflows, require a short production packet:
- The workflow map and baseline.
- The context contract and source-of-truth rules.
- The permission model and denied actions.
- The human review rubric.
- The eval set and acceptance thresholds.
- The monitoring dashboard and incident runbook.
- The owner list and operating cadence.
If the team can produce those artifacts, the pilot is becoming a system. If it cannot, expansion will mostly scale uncertainty.