How to run an AI model approval process before production.

Approve the use as well as the model.

A model is a component, and the risk sits in what it is used for. Our enterprise AI governance framework separates two decisions: whether a model or platform is acceptable to the organization at all, and whether a specific use of it is. The first is rare and deserves depth. The second comes up constantly and has to be fast.

NIST's AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, January 2023) starts its Map function with context. MAP 1.1 asks that intended purposes, context-specific laws, norms and expectations, and the settings where the system will be deployed are understood and documented. Context belongs to the use: the same model gets a new one every time a team finds a new job for it.

The request: five questions on one form.

One form for every request, short enough that teams fill it in instead of working around it. It asks for five things:

• The use. What the workflow does, in a sentence, and where the output goes: read by a person, sent to a customer, written into a system.
• The users. Which team runs it, and who outside that team will see its output.
• The data class. The highest class of data the workflow sends to the model, and the model's ceiling under your AI data classification policy.
• The model and version. Vendor, model name and the exact version or deployment identifier, so the approval refers to something fixed.
• Who is affected by an error. The person or group who bears a wrong output: an employee, a customer, an applicant, the public.

Tiers in an AI model approval process, set by consequence.

The tier comes from the answers, the last one above all. Three tiers are enough to start. In the AI RMF, GOVERN 1.3 asks for processes that set the needed level of risk management by the organization's risk tolerance, and MAP 1.5 asks that risk tolerances are determined and documented. The tiers are where that tolerance becomes concrete.

Results on your own cases means the team runs the model on real examples from the workflow, with the expected answer written down first, and records where it fails. The review step names who checks which outputs before they take effect; our post on human-in-the-loop AI workflows covers running it.

For systems the EU AI Act (Regulation (EU) 2024/1689) classes as high-risk, Article 9 describes a risk management system run as a continuous, iterative process across the system's lifecycle, and Article 9(8) has testing carried out against prior defined metrics and probabilistic thresholds before the system is placed on the market or put into service. Whether it applies to you is a question for counsel. Writing the pass mark down before the test is worth copying at the high tier either way.

Who decides, and by when.

GOVERN 2.1 in the AI RMF asks that roles, responsibilities and lines of communication for AI risk are documented and clear to everyone involved. For approval, that means each tier has a named decider and a time limit, and a request that passes its limit goes to the decider's manager the next day. We would set them like this:

• Low. The requesting team's lead approves against the approved-model list and the data rules, and records it the same day. No meeting.
• Medium. One named reviewer from IT or security decides within a week, with the evidence attached to the request.
• High. A small panel decides within a month: the business owner, the data protection lead and the security lead. The business owner signs, because the business answers for the outcome.

The register: one entry per approved use.

Every approval ends in a register entry. GOVERN 1.6 in the AI RMF asks for mechanisms to inventory AI systems; the register is that inventory, kept at the level of each use.

For the model itself, start from what the vendor publishes. Model cards, proposed by Mitchell and colleagues in "Model Cards for Model Reporting" (2019), are short documents that accompany a trained model with the context it is intended for, its evaluation procedures and its results across conditions. Where a vendor publishes one, attach it to the entry next to your own results. Each entry holds:

• Use and owner. What the workflow does, and the named person who answers for it.
• Model and version. The exact identifier approved, and the date.
• Tier and conditions. The data-class ceiling, the review step, and what must be logged.
• Evidence. The test cases and results the decision rested on, attached in full.
• Re-review date. When the entry is checked again even if nothing has changed.

What sends a model back for review.

An approval holds for the model, data, users and error level it was granted for. GOVERN 1.5 in the AI RMF asks for ongoing monitoring and periodic review, with the frequency decided in advance. Write the triggers into the conditions, so re-review does not depend on someone remembering. Re-review runs the same checks as the first go-live; our AI production readiness checklist lists them.

• A new model version. A vendor update behind the same name counts. NIST AI 600-1, the Generative AI Profile (July 2024), notes that errors in third-party generative AI components can have downstream impacts on accuracy and robustness.
• A new data source. A newly connected system, or a higher data class, changes what the model sees.
• A new user group. The same workflow handed to customers, or to another team, changes who bears an error.
• A rise in errors. Corrections, complaints or failed checks above the level recorded at approval.

Do it yourself, or bring us in.

The route above needs no new software: a form, a register, a short list of approved models and a calendar of re-review dates. A platform or risk lead with the authority to say no can set it up and run it.

Where it decays is after go-live, when models change under existing approvals and nobody connects the change to the register. Outside help fits there: with managed AI operations, the engineers who built your agents keep them running, watch for failures, and move you to a better or cheaper model without breaking what already works.

Frequently asked questions.

Keep reading.