The AI demo works. Production approval should still wait
A working demo is not proof of approval.
Fluent answers can still hide weak operations. A successful pilot doesn't establish a release standard, and more usage doesn't create a business case.
Before a company gives an AI system production access, more autonomy, or more budget, leadership should require an evidence packet for one specific workflow.
That packet should answer a simple question: what proof shows this system can do acceptable work, stay inside its boundaries, and fail in ways the company can detect and contain?
Private evals are the measurement half of that answer. Runtime permissions, approvals, isolation, and rollback are the control half. One without the other leaves a hole. Measurement without controls tells you after the fact that the system crossed a line. Controls without measurement tell you very little about whether the work is actually good.
Leaders should require both.
The approval standard should come from the workflow
Most AI discussions still start in the wrong place. They start with the model, the vendor, or the feature list.
Leaders need to start with the work.
Start by defining the output the AI will handle and the failures that matter, then specify which exceptions require a person, which systems the AI can change, and what evidence will prove the result acceptable.
Tooling can be bought.
The company-specific definition of acceptable work can't be bought.
A vendor can provide orchestration, tracing, model access, and dashboards. It can't define an acceptable variance explanation for finance, identify the exceptions operations must escalate, or decide which failures should block release for risk.
Those decisions belong inside the company because the company owns the consequence.
Require five lines of release evidence
A release decision does not need a giant operating memo. It needs a compact standard that makes approval legible.
Line | Minimum evidence to require | Why it matters |
|---|---|---|
Task quality | Versioned cases, expected outcomes, and pass or fail criteria for acceptable work | Good prose can still hide bad work |
Security hard fails | Explicit tests for unauthorized actions, missing approvals, boundary violations, and prohibited tool use | One unsafe action can outweigh many correct answers |
Evaluator validity | Proof that the scorer or judge was checked against human review where judgment matters | A weak judge creates fast false confidence |
Cost and latency | Run cost, completion time, retry burden, and review burden kept on their own line | A workflow can be correct and still uneconomic |
Business outcome | Named measure, review window, and accountable owner for the real result | The company is funding an outcome, not a demo |
The separation matters because a single blended score hides the tradeoffs leaders need to see. Cheaper models may miss more edge cases, stricter policies may increase escalations, and apparent efficiency can disappear once reviewer load wipes out the gain.
Approve only when those tradeoffs are visible.
Name the owners before release
Shared ownership is how AI problems survive past the pilot.
Minimum ownership is not complicated. Every consequential workflow should have a business owner, a technical owner, a domain reviewer, and, when the workflow can create material harm, a security or risk owner.
The business owner defines acceptable work and the business result that should change. Technical ownership covers the system, versions, traces, and rollback path, while the domain reviewer checks the work against the real operating standard. When a failure can create material harm, the security or risk owner decides what is non-negotiable.
Name them before approval.
Before approval, name who can stop the workflow, who can approve expansion, and who answers for a false pass.
If nobody owns the release gate, the release gate does not exist.
Buy the tooling, build the standard
Many teams lose the plot by treating build versus buy as the core decision. Most companies should buy as much plumbing as they reasonably can, including the runner, trace store, labeling queue, or observability layer.
What they still have to build is the standard.
The company still has to define the workflow and build the case set. Its standard must separate task quality from security hard fails, set the boundary between model judges and deterministic checks or human review, name the business outcome, and define the failures that block release.
Purchasing software doesn't remove that work. It makes the judgment more urgent because a bought tool can speed up the loop without making the judgment for you.
Reviewer capacity is part of the business case
A release packet is incomplete if it ignores reviewer economics.
The easiest way to hide operating cost is to pretend review will somehow fit inside the day. It usually shows up later as queue delay, manager drag, or invisible rework.
Leaders should require one simple capacity model:
Reviewer hours per week = runs per week × escalation rate × minutes per review ÷ 60
Then ask whether the current team can absorb that load, what happens when traffic doubles, which cases need domain review instead of general review, and what queue age makes the workflow unusable.
This doesn't require a fabricated benchmark. It requires an honest input model.
If a workflow needs 400 runs a week, 15 percent escalation, and 12 minutes per review, that is 12 reviewer hours every week before rework, calibration, or incident analysis. That load belongs in the approval decision.
AI doesn't remove operating labor by declaration. It changes the labor profile in a way the company can support, or it creates a hidden tax.
Start with one workflow: define acceptable work, build the release gate, name the owners, and measure reviewer load before expanding autonomy or budget.
Bring one AI workflow. Leave with its acceptance standard, release gates, owners, and 30-day evaluation plan.