Controls are part of the product
A pilot becomes operational when real users, business data, and consequential decisions enter the system. At that point, model accuracy is only one part of the approval decision. The organization also needs to know who may use the system, which actions require review, how failures are detected, and who can authorize a change.
Defining these controls before the pilot prevents a common failure mode: a compelling demonstration that cannot pass security, legal, risk, or operational review.
A minimum control set
The exact depth should reflect the use case and its consequences, but six control areas should have named owners.
- Decision rights: identify the business owner, technical owner, risk approver, and final production authority.
- Access and data controls: define identity, permissions, approved sources, retention, and sensitive-data handling.
- Evaluation thresholds: establish task-specific quality, safety, reliability, latency, and cost acceptance criteria.
- Human oversight: specify which outputs are reviewed, overridden, escalated, or prohibited from autonomous action.
- Incident response: define detection, containment, notification, investigation, and recovery responsibilities.
- Change control: version prompts, models, tools, data sources, and evaluation results so releases are reviewable and reversible.
Tie control evidence to release decisions
Each control should produce evidence: access logs, evaluation reports, approvals, incident exercises, change records, or monitoring dashboards. Release gates should reference that evidence rather than rely on a subjective view that the system feels ready.
NIST AI RMF and ISO/IEC 42001 both support this lifecycle approach. For organizations operating in or serving the European Union, the EU AI Act may add use-case-specific obligations, so legal classification should happen early rather than at the final production review.