Organizations that run a purpose-built AI governance platform are 3.4 times more likely to reach high effectiveness in governing their AI than those relying on spreadsheets and policy memos, according to a February 2026 Gartner press release. The document that decides whether an AI use case gets a green light sits right at the center of that gap. An AI approval form is the intake and sign-off gate where a proposed use case, or a model heading into production, is reviewed against risk, data, and compliance criteria before anyone ships it. Built well, it converts scattered yes/no decisions into an auditable record that maps cleanly to ISO/IEC 42001 and the NIST AI Risk Management Framework. This article gives you the field-by-field template, the risk tiers that route each review, and the control mappings auditors look for.
What an AI approval form actually does
An AI approval form is a decision gate, not a survey. Its job is to stop an AI system from reaching users until a named person has confirmed it meets your organization’s risk, data, and compliance bar. Everything else, the fields, the routing, the sign-offs, exists to make that decision defensible months later when someone asks why you approved it.
Two gates hide inside one form, and conflating them is the most common design mistake. The first gate is the use-case approval: a team proposes using AI for a purpose, and you decide whether that purpose is acceptable at all. The second is the model review: a specific model or system has been built or procured for an approved use case, and you verify it performs safely before launch. A use case can be approved while its first model fails review. Keeping the two distinct is what lets you say yes to the idea and no to the implementation without restarting the whole process.
In ISO 42001 terms, the form operationalizes the AI management system: it is where impact assessment, life-cycle controls, and accountability requirements become a single repeatable action. The completed record is also your cheapest audit evidence. An approval form filled in at the time of decision is worth more to an auditor than a polished policy written after the fact, because it shows the control actually ran.
Every AI approval request should include a completed AI risk assessment to evaluate business, compliance, and operational risks.
The fields every AI approval form needs
Strip an effective form down and the same fields appear, whether you govern three AI systems or three hundred. Group them so the reviewer can move from context to risk to decision without jumping around. The order below is the order a reviewer should read in.
Use-case intake fields
- System or use-case name and owner. A named accountable owner, not a team. Accountability with no name attached is the first thing auditors probe.
- Intended purpose and scope. What the system is for, who it affects, and what it must never be used for. This single field drives risk classification.
- Build, buy, or fine-tune. Whether you developed it, procured it, or adapted a vendor model. Procured systems shift some obligations to the supplier but never remove your own.
- Data sources and sensitivity. Training, fine-tuning, and input data, including any personal or special-category data and its lawful basis.
- Affected individuals and decisions. Whether outputs influence people in employment, credit, healthcare, or other consequential contexts. This is what pushes a use case into a higher tier.
Risk and control fields
- Risk tier. The routing decision, covered in the next section.
- Human oversight plan. Who can review, override, or shut down the system, and how. A checkbox saying ‘human in the loop’ is not an oversight plan.
- Transparency and disclosure. Whether users are told they are interacting with AI and how outputs are explained.
- Logging and record-keeping. What the system records, where logs live, and how long they are kept.
- Post-deployment monitoring trigger. The metric or event that forces a re-review after launch.
Decision fields
- Reviewer findings and conditions. What was checked, what was flagged, and any conditions attached to approval.
- Approver, decision, and date. The signature line: approved, rejected, or approved-with-conditions, by whom, when.
- Next review date. Approval is never permanent. A model that was safe last quarter may not be after a data drift or a vendor update.
| What most teams get wrong: They treat the form as a one-time questionnaire. The fields that matter most over time are the next-review date and the monitoring trigger, because they turn a static approval into a living control. Leave them blank and your register quietly fills with systems nobody has looked at since launch. |
Risk tiers: routing a use case to the right level of review
Not every AI system deserves the same scrutiny. A model that drafts internal meeting notes should not sit in the same queue as one that screens job applicants. A tiering field routes each use case to a proportionate review, which is the only way an approval process survives contact with real volume.
The EU AI Act gives you a ready-made spine for this. It sorts systems into prohibited, high-risk, limited-risk, and minimal-risk categories, with high-risk defined by Article 6 and Annex III of Regulation 2024/1689, covering uses like recruitment, credit scoring, and education. Even if you are a US-only deployer with no EU exposure, that classification logic is a sound model for internal tiering because it ties scrutiny to real-world consequence rather than technical complexity.
One timing note worth flagging for any EU-facing reader: under the Digital Omnibus political agreement reached in May 2026, high-risk obligations for stand-alone Annex III systems were deferred from August 2026 to 2 December 2027, and product-embedded systems to 2 August 2028, though formal adoption was still pending as of mid-2026. The architecture did not change; the clock did. Penalties of up to 7% of global turnover remain.
A workable internal model uses three tiers:
| Tier | Trigger | Review depth | Approver |
|---|---|---|---|
| Tier 1 – Low | No effect on people; internal productivity only | Self-attestation against a short checklist | Team lead or AI governance lead |
| Tier 2 – Elevated | Affects customers or staff but not consequential decisions | Full form + documented model review | Governance function + system owner |
| Tier 3 – High | Consequential decisions (hiring, credit, health, legal) | Full review + bias/accuracy testing + executive sign-off | CISO / CDO / Chief AI Officer or risk committee |
Set the tier at intake, but let the model review escalate it. A use case can look like Tier 2 on paper until testing reveals the model behaves unpredictably on a subgroup, at which point it earns Tier 3 oversight. The tier is a hypothesis the review confirms or corrects.
The model review gate: what to verify before production
Use-case approval asks whether you should. The model review asks whether this build actually performs. It is a separate checklist because a perfectly acceptable purpose can be served by a model that is biased, brittle, or impossible to monitor. Run it before the first real user, and again whenever the model materially changes.
Anchor the review in the four functions of the NIST AI RMF (Govern, Map, Measure, Manage). The Measure function in particular gives you the evaluation backbone: accuracy, robustness, and bias are not optional fields, they are the evidence that the model meets the bar the use case set.
A defensible model review confirms, at minimum:
- Performance against a stated threshold. Accuracy, precision, or whatever metric matches the use case, measured on data that resembles production, not the training set.
- Bias and fairness testing. Disaggregated performance across the groups the system affects. A single headline accuracy number can hide a model that fails one subgroup badly.
- Robustness and failure behavior. How the model behaves on edge cases, adversarial inputs, and out-of-distribution data, and what it does when it is unsure.
- Explainability fit. Whether the level of explanation matches the stakes. A Tier 3 system needs more than ‘the model said so.’
- Logging and monitoring readiness. That the system actually emits the records the form promised, before launch rather than after the first incident.
| Audit-room reality: Most compliance teams build their first AI register in spreadsheets. That works until the third audit, when the auditor asks for the version history of a model review and there isn’t one. The model that passed review in March is not the model running in June, and a spreadsheet cannot tell you which version you actually approved. |
Mapping approval fields to ISO 42001, the EU AI Act and NIST AI RMF
Here is the part most templates skip, and the reason auditors lose patience with home-grown forms: every field should trace to a control. When a reviewer can point at a field and name the ISO clause, EU AI Act article, and NIST function it satisfies, the form stops being paperwork and becomes conformity evidence. The mapping below is indicative; confirm exact control identifiers against the current standard texts before you publish your own version.
Field-to-control mapping
| Approval form field | ISO/IEC 42001:2023 | EU AI Act (2024/1689) | NIST AI RMF 1.0 |
|---|---|---|---|
| Intended purpose & scope | A.5.2; A.6.2.2 | Art. 11 + Annex IV | MAP 1.1, 2.1 |
| Risk tier / classification | Clause 6.1; A.5.2 | Art. 6 + Annex III | MAP 1.5 |
| Data sources & governance | A.7.2–A.7.5 | Art. 10 | MAP 4.1; MEASURE 2.10 |
| Human oversight plan | A.9.2 | Art. 14 | GOVERN 3.2; MANAGE 4.1 |
| Accuracy / performance (review) | A.6.2.4 | Art. 15 | MEASURE 2.3, 2.5 |
| Bias / fairness testing (review) | A.6.2.4; A.7.4 | Art. 10; Art. 15 | MEASURE 2.11 |
| Transparency & disclosure | A.8.2 | Art. 13; Art. 50 | GOVERN 4.2 |
| Logging & record-keeping | A.6.2.8 | Art. 12 | MEASURE 2.x |
| Approver sign-off & roles | Clause 5.3; A.3.2 | Art. 17 (QMS) | GOVERN 2.x |
| Post-deployment monitoring | A.6.2.6 | Art. 72 | MANAGE 4.1 |
The payoff of mapping once is that a single completed form feeds three frameworks at the same time. A US deployer leaning on the NIST AI RMF today can pursue ISO 42001 certification later without rebuilding its evidence, because the form already carries both references. This is also where a dedicated platform earns its place: Govern365.ai’s AI model registry attaches each approval record to its applicable ISO 42001 clauses and EU AI Act risk category automatically, so the mapping is maintained as systems change rather than re-done by hand before every audit.
Who signs off: roles, RACI and escalation
A form with no clear approver is a suggestion box. The fastest way to stall an approval process is to leave ‘who decides’ implicit, because every ambiguous case then escalates to whoever is least busy, not whoever is accountable. Assign roles at the tier level so the routing is automatic.
A simple RACI keeps it honest. The system owner is responsible for completing the form and the model review. The governance or compliance function is accountable for the integrity of the process and consulted on every tier. Executives, the CISO, CDO, or Chief AI Officer, are accountable approvers for Tier 3 and informed on lower tiers. Legal and data protection are consulted whenever personal data or consequential decisions appear.
Escalation paths matter because the interesting cases are the disputed ones. Define in advance who breaks a tie when the owner wants to ship and the governance lead wants more testing. In a US context this has become more pointed: federal policy shifted toward deregulation after Executive Order 14110 was rescinded in January 2025, yet durable obligations did not vanish. NIST AI RMF references persist in agency and sector guidance, and state laws such as the Colorado AI Act (effective 30 June 2026) still impose duties on deployers. Your internal sign-off authority is, increasingly, the control that holds when external mandates are in flux.
Why the spreadsheet version eventually breaks
A spreadsheet is a fine place to start and a dangerous place to stay. It captures a decision but not the chain of custody around it: who edited what, which model version was reviewed, whether the next-review date ever fired. The form works; the system of record fails.
This is the structural problem behind a fast-growing market. Gartner projects AI governance platform spending will reach $492 million in 2026 and pass $1 billion by 2030 as regulation expands to roughly 75% of the world’s economies, per the same February 2026 analysis. The spend reflects a simple realization: governing AI at scale needs version history, automated routing, and a live link between each approval and its controls, none of which a shared file provides.
Three failure modes show up almost universally as the count of AI systems grows. Approvals drift out of date because no trigger forces a re-review. Evidence is scattered across documents, so assembling an audit package takes weeks. And the mapping between systems and controls rots, because a spreadsheet cannot tell you that a vendor model update just changed your risk posture. A purpose-built workflow closes those gaps by making the form, the registry, and the control map a single connected record rather than three things someone has to reconcile.
Mistakes that surface in the first audit
Patterns repeat across first audits, and almost all of them trace back to a form that captured a decision without capturing its evidence. Knowing them in advance is the cheapest way to avoid a non-conformity.
- Approval without a named owner. A team is listed, so no individual can answer for the decision.
- A risk tier with no rationale. The box is ticked ‘low’ with nothing explaining why, which an auditor reads as an unexamined assumption.
- Model review merged into use-case approval. The two gates collapse into one, so there is no record that the actual model was tested.
- No version history. The reviewed model and the live model differ, and nothing documents the change.
- Dead next-review dates. Every system was approved once and never revisited, which signals the control is theater.
Before approving third-party AI solutions, complete an AI vendor risk assessment questionnaire to assess supplier risk and compliance
Fix these at the form level and most audit findings disappear before they start, because the evidence an assessor wants is the same evidence a good approval form already collects.
Frequently asked questions
What is an AI approval form?
An AI approval form is a governance document that gates a proposed AI use case or a model heading into production. It captures the intended purpose, data, risk tier, human oversight plan, and approver sign-off so a named person decides, on the record, whether the system meets your risk and compliance bar before launch.
What fields should an AI approval form include?
At minimum: system name and owner, intended purpose and scope, data sources and sensitivity, affected individuals, risk tier, human oversight plan, transparency approach, logging, monitoring trigger, reviewer findings, the approver and decision, and a next-review date. The owner, risk tier, and next-review date are the fields auditors scrutinize first.
What is the difference between use-case approval and model review?
Use-case approval decides whether an AI purpose is acceptable at all. Model review verifies that a specific built or procured model performs safely for that purpose, testing accuracy, bias, and robustness. A use case can be approved while its first model fails review, which is why the two gates stay separate.
How do you classify AI risk on an approval form?
Tier by real-world consequence, not technical complexity. A common model uses three tiers: low (no effect on people), elevated (affects users but not consequential decisions), and high (drives hiring, credit, health, or legal outcomes). The EU AI Act’s Article 6 and Annex III high-risk categories offer a sound spine even for US-only deployers.
Does an AI approval form satisfy ISO 42001 or the EU AI Act?
Not on its own, but it is core evidence. A well-designed form maps each field to specific controls, such as ISO 42001 Annex A life-cycle controls, EU AI Act Articles 10 to 15, and NIST AI RMF functions. The completed record then becomes conformity evidence across all three frameworks from a single source.
How often should AI approvals be reviewed?
Set a next-review date on every approval and a trigger that forces re-review sooner. Tier 3 systems typically warrant review at least quarterly or on any material model change; lower tiers can run annually. A model that passed review last quarter may behave differently after data drift or a vendor update.
Can a spreadsheet work as an AI approval form?
For a handful of systems, yes. It breaks as volume grows because it cannot hold version history, route approvals automatically, or keep a live link between each system and its controls. Most teams move to a dedicated workflow once assembling an audit package starts taking weeks instead of hours.
Bringing it together
An AI approval form is the smallest governance artifact that does the most work. Get the fields, the risk tiers, and the two gates right, and a single completed record answers the question every framework and every auditor is really asking: who decided this was safe, on what basis, and when. Map each field to its controls once, and that record serves ISO 42001, the EU AI Act, and the NIST AI RMF at the same time.
Start small. Take the field list above, separate the use-case gate from the model review, and add a next-review date to everything you have already deployed. When the spreadsheet starts to strain, Govern365.ai, by the Global AI Certification Council, runs the whole workflow with the control mapping built in. Start your 14-day free trial and turn your approval form into living audit evidence.
