A 2024 IBM Institute for Business Value study of more than 2,500 executives found that 80% say trustworthy AI is a top priority, yet only 24% have a fully operational AI governance program. The gap is rarely about awareness. It is almost always about approval. Who signs off on a new model? Who can override a high-risk classification? Who is accountable when an AI system makes a decision that ends up in court? In most organizations, the answer is everyone and no one. This guide breaks down a working AI governance approval framework — by risk tier, by role, and by regulatory regime — so you can stop running approvals through whoever happens to be in the meeting.
Why AI approval needs its own governance lane
Most enterprises already have approval processes for software, vendors, and data. The instinct is to bolt AI onto one of those tracks and call it done. That instinct is wrong, and the regulators have made it expensive.
AI systems behave in ways traditional software does not. Models drift. Training data ages. A vendor’s frontier model retrains overnight and the system you certified last quarter is, technically, no longer the system you certified. The EU AI Act recognizes this directly: high-risk systems require ongoing post-market monitoring, not a one-time launch sign-off. ISO/IEC 42001:2023 builds the same logic into Clause 8.3, which requires controlled change management for AI systems across their lifecycle. If your approval process ends at go-live, you are out of step with both standards.
There is also a legal exposure problem. The NIST AI Risk Management Framework emphasizes that accountability must be assignable to specific individuals, not abstract committees. When the FTC, a state attorney general, or a class action plaintiff asks who approved this, “the AI committee” is not a defensible answer. A name is.
| What most teams get wrongTreating AI approval as a single checkpoint at deployment. By the time a model is in pre-production, the decisions that actually matter — use case fit, training data lineage, risk classification, fallback behavior — have already been locked in. Approval gates need to start at intake, not at launch. |
The four approval tiers every AI governance program needs
Risk-based tiering is the only approval model that scales. A chatbot that suggests internal HR articles does not need the same scrutiny as a model that decides who gets a mortgage. Yet many organizations route both through the same committee, which means the committee either rubber-stamps everything or becomes a bottleneck for the things that genuinely matter.
The four tiers below align with how the EU AI Act, ISO 42001, and NIST AI RMF think about risk, expressed in language operating teams can actually use.
| Tier | Examples | Approval owner | Required artifacts |
|---|---|---|---|
| Tier 1 — Minimal risk | Internal search, code completion, summarization of non-sensitive docs | Business unit lead + AI governance reviewer | Use-case registration, basic data classification |
| Tier 2 — Limited risk | Customer-facing chatbots, content generation with human review, marketing personalization | AI governance committee (delegated) | Risk assessment, transparency notice, fallback plan |
| Tier 3 — High risk | Hiring, credit, insurance, education access, biometrics, critical infrastructure | AI governance committee + executive sponsor + legal | Conformity assessment, DPIA, bias testing, post-market monitoring plan |
| Tier 4 — Prohibited or unacceptable risk | Social scoring, manipulative subliminal techniques, real-time biometric ID in public spaces (per EU AI Act) | Hard stop — no internal approval pathway exists | Documented refusal and rationale |
Notice that Tier 4 has no approval pathway. This matters. A common failure mode is creating an “executive override” route for prohibited use cases. Under Article 5 of the EU AI Act, prohibited practices are not approvable at any level. Your governance documentation should make that explicit, in writing, before someone senior asks for an exception.
How to assign a use case to a tier without arguing about it for three weeks
Tiering disputes burn weeks. The fix is a deterministic intake questionnaire that maps answers to tiers before a human gets involved. Six questions cover most of the decision space:
- Does the system make or materially influence a decision about a person’s access to employment, credit, education, housing, healthcare, or essential services?
- Does it process biometric data, emotional inference, or characteristics protected under federal or state anti-discrimination law?
- Is the output user-facing, and could a reasonable user mistake it for content produced by a human expert?
- Does it operate in a regulated sector with sector-specific AI rules — for example, EEOC guidance on hiring tools, or NYC Local Law 144?
- What is the blast radius if the model is wrong — one user, one team, the whole customer base, or the public?
- Can a human reasonably review and override each decision before it takes effect?
Two or more affirmative answers to questions 1 through 4 push the use case to Tier 3 by default. The committee can downgrade with a written rationale, but the burden of proof sits on the downgrade, not the upgrade. This single inversion eliminates most tiering arguments because it removes the incentive to lobby for a softer tier.
Who actually sits in the room: roles and decision rights
An approval framework is only as strong as the role definitions behind it. “The AI committee approves” tells you nothing about what happens when the General Counsel and the Chief Data Officer disagree. The matrix below assigns decision rights using a modified RACI, with one rule: every decision has exactly one Accountable owner. Not two. Not a co-chair arrangement. One name.
| Decision | Accountable | Consulted | Informed |
|---|---|---|---|
| Use case fit and tier assignment | AI Governance Lead | Business sponsor, Legal, Privacy | CIO, Risk |
| Training data approval | Chief Data Officer | Privacy, Security, Legal, Procurement | Model owner |
| Tier 2 deployment sign-off | AI Governance Committee Chair | Model owner, Security, Privacy | Executive sponsor |
| Tier 3 deployment sign-off | Executive Sponsor (CTO, CDO, or CAIO) | AI Governance Committee, Legal, Risk, CISO | CEO, Audit Committee |
| Production incident response | Model Owner | AI Governance Lead, Security, Comms | Affected business units |
| Decommissioning | Model Owner | Compliance, Records, Procurement | Users, downstream systems |
A few patterns are worth pointing out. The Chief Data Officer owns training data approval, not the model owner. This is deliberate. Model owners have a built-in incentive to access more data; the data owner’s job is to push back. Splitting that authority prevents the most common audit finding in early-stage AI programs: training datasets that nobody can fully account for.
Tier 3 sign-off requires an executive sponsor by name. In US enterprises this is increasingly the Chief AI Officer where the role exists, the CTO or CDO where it does not. The point is that the signature creates personal accountability, which is what makes the approval defensible in a regulatory inquiry.
The AI governance committee: composition that holds up under scrutiny
Most committees fail one of two ways. They are too small and dominated by engineering, or they are too large and dominated by nobody. A committee of seven to nine voting members tends to work. A useful composition for a US enterprise:
- Chair — typically the AI Governance Lead or Chief AI Officer
- Legal counsel with regulatory experience (EU AI Act, FTC, state AI laws)
- Privacy lead or Data Protection Officer
- CISO or delegate
- Chief Data Officer or delegate
- Business representative from a high-AI-usage function (often Marketing, HR, or Operations)
- Independent technical reviewer — internal AI ethics lead or an external advisor
- Risk or Internal Audit observer (non-voting, present for all Tier 3 decisions)
Quorum should be set so that no decision can proceed without Legal and the technical reviewer present. That single rule prevents the most common failure mode: a committee approves a model in a meeting where nobody on the call could actually evaluate the model.
Mapping approvals to ISO 42001, the EU AI Act, and NIST AI RMF
If your organization operates in the US, the EU, or both, your approval process needs to satisfy three different vocabularies for what is essentially the same set of controls. The good news is that they overlap heavily. The framework below shows how a single approval workflow can produce evidence for all three.
| Approval activity | ISO/IEC 42001 reference | EU AI Act reference | NIST AI RMF function |
|---|---|---|---|
| Use case intake and impact assessment | Clause 6.1.2, A.5.2 | Article 9 (risk management), Article 27 (FRIA) | MAP 1, MAP 2, MAP 3 |
| Training data governance | Clause 7.1.5, A.7.2 – A.7.6 | Article 10 | MEASURE 2.10, MANAGE 2 |
| Model evaluation and bias testing | Clause 8.3, A.6.2.4 | Article 15 | MEASURE 2.11, MEASURE 2.12 |
| Documentation and technical file | Clause 7.5, A.4.6 | Article 11, Annex IV | GOVERN 1.4, MAP 4 |
| Post-deployment monitoring | Clause 9.1, A.6.2.6 | Article 72 (post-market monitoring) | MEASURE 4, MANAGE 4 |
| Incident reporting | Clause 10.2 | Article 73 | MANAGE 4.3 |
Two practical implications. First, the Fundamental Rights Impact Assessment under Article 27 of the EU AI Act is not optional for high-risk public-sector deployments and many private-sector ones, including financial services and insurance. If your US-headquartered organization sells into the EU, you inherit this obligation. Second, post-market monitoring under Article 72 is where most US programs are weakest. Approving a model and then walking away is not a defensible posture under any of the three frameworks.
Govern365.ai’s compliance dashboard maps each approval artifact to the corresponding clause across ISO 42001, the EU AI Act, and NIST AI RMF, so a single sign-off produces evidence in three formats simultaneously. For organizations preparing for ISO 42001 certification while also subject to EU AI Act conformity assessment, this collapses what would otherwise be three parallel evidence trails into one.
Approval gates across the AI lifecycle: a working sequence
The single most useful change a governance program can make is to stop treating approval as a thing that happens at deployment, and start treating it as a sequence of gates across the lifecycle. The sequence below is what a mature US enterprise approval process looks like in practice. Each gate has an owner, a required artifact, and a defined go/no-go criterion.
Gate 1 — Use case intake (week 0)
Owner: AI Governance Lead. The intake questionnaire from earlier in this article runs here. Output: a tier classification and a documented use case description with intended purpose, foreseeable misuse, and affected populations. No data acquisition, no procurement, no engineering work begins until this gate clears. Skipping this gate is the single largest source of shadow AI in regulated industries.
Gate 2 — Data and design review (weeks 1–4)
Owner: Chief Data Officer (data) and Model Owner (design). For Tier 2 and above, this is where training data lineage is documented, retention is assigned, and consent or lawful basis is confirmed. The deliverable is a data sheet — modeled on the standard datasheets-for-datasets format — and a system architecture that identifies all third-party model dependencies, including foundation model providers.
Gate 3 — Pre-deployment evaluation (weeks 4–10)
Owner: Independent technical reviewer. Bias testing, robustness testing, security testing including prompt injection where relevant, and a documented evaluation against the intended purpose. For Tier 3, an external review is strongly recommended; some sectoral regulators effectively require it. The output is an evaluation report that names the tests, the results, and the residual risks the committee is being asked to accept.
Gate 4 — Deployment authorization (week 10–12)
Owner: AI Governance Committee (Tier 2) or Executive Sponsor (Tier 3). This is the gate everyone thinks of as “approval.” In a well-run program, it is the least dramatic gate, because the substantive decisions happened at gates 1 through 3. The committee’s job here is to confirm that residual risks are acceptable, that monitoring is in place, and that incident response procedures are documented.
Gate 5 — Post-deployment review (90 days, then quarterly)
Owner: Model Owner with AI Governance Lead oversight. Performance, drift, complaint volume, and incident logs are reviewed against the assumptions documented at Gate 4. A material change in any of these triggers a re-approval back to the appropriate gate. This is where most programs break: the calendar entry slips, then disappears. Treat it as a hard control, not a best effort.
| Pro tip from auditAuditors do not test whether your approval process exists. They test whether the documented process matches what actually happened. The most common ISO 42001 nonconformity is a gap between policy and practice — Gate 4 was approved, but Gates 2 and 3 have no signed evidence. Use a single source of truth for evidence, not three different SharePoint folders. |
Common failure modes and how to design around them
Five failure patterns appear in almost every early-stage AI governance program. Each has a structural fix.
1. The committee approves everything because saying no is hard
Fix: require a formal “reject” or “defer” outcome on at least 15% of submissions in the first year. This is not a quota for the sake of it. It surfaces the use cases where the committee is functioning as a rubber stamp because the alternative is uncomfortable. If your reject rate is zero, your committee is not a control.
2. Shadow AI: business units deploy without going through approval
Fix: combine network-level discovery (logs of API calls to known model providers) with a quarterly attestation requirement signed by each business unit lead. Discovery alone misses self-hosted models. Attestation alone misses things people forget. Both together close most of the gap.
3. Vendor AI: an existing tool ships an AI feature in a routine update
Fix: amend procurement and renewal templates to include AI-specific clauses — model provenance, training data warranties, change notification, audit rights. The contract is the only durable control over a vendor’s roadmap. Add an annual vendor AI attestation to the third-party risk management program.
4. Approval theater: documentation looks complete but nobody read it
Fix: at every committee meeting, one randomly selected reviewer must verbally summarize the risk assessment of one randomly selected submission. The summary is captured in the minutes. This single ritual changes reviewer behavior more than any policy document.
5. The model owner leaves and the model becomes orphaned
Fix: the AI model registry must require a named primary owner and a named backup, both of whom must be current employees. Quarterly automated checks flag orphaned models for re-approval or decommissioning. An orphaned model in production is a known finding under ISO 42001 Clause A.6.2.5.
Operationalizing approvals without burying the program in spreadsheets
The framework above is a process design problem, not a tooling problem — until you try to run it. At that point, three things tend to break simultaneously: evidence ends up in too many places, the same risk assessment gets written four different ways for four different frameworks, and the committee minutes drift out of sync with the model registry.
This is where a purpose-built AI governance platform earns its place. Govern365.ai was built specifically for this problem: a single AI model registry that holds use case classification, owner assignment, lifecycle stage, and approval history; risk assessment templates pre-mapped to ISO 42001, the EU AI Act, and NIST AI RMF; an audit evidence vault that links every artifact to the gate at which it was produced; and dashboards that surface overdue post-deployment reviews before they become audit findings.
The point is not that you need a tool to do this work. Some organizations run perfectly defensible programs in spreadsheets and SharePoint. The point is that as the model count grows past roughly twenty production systems, the manual approach starts to fail in predictable ways — version drift, missing evidence, inconsistent risk language across submissions. A platform pays for itself the first time an auditor asks for the evidence file on a model someone deployed eighteen months ago.
Frequently asked questions
Who has the final authority to approve a high-risk AI system?
In a well-designed governance program, an executive sponsor holds final authority for high-risk (Tier 3) systems — typically the Chief AI Officer, CTO, or CDO depending on the organization. The AI governance committee provides the recommendation; the executive provides the named, accountable signature. Distributing this authority across a committee dilutes accountability and weakens the program’s defensibility under regulatory scrutiny.
Is an AI governance committee legally required in the United States?
No federal US law currently mandates an AI governance committee, but several functionally require equivalent oversight. The EEOC has issued guidance on AI in hiring, NYC Local Law 144 requires bias audits for automated employment decision tools, and Colorado’s AI Act (effective 2026) imposes risk management obligations on developers and deployers of high-risk AI. A documented governance committee is the most efficient way to satisfy these overlapping obligations.
How is AI approval different from a standard change advisory board?
A change advisory board approves changes to known systems with stable behavior. AI approval has to account for systems whose behavior is probabilistic, drifts over time, and may depend on a third party’s training updates. AI governance also requires bias testing, fairness assessment, and impact assessment on affected populations — none of which appear in a typical CAB process. Running AI through an unmodified CAB is one of the most common audit findings under ISO 42001.
Should generative AI tools follow the same approval process as predictive AI?
Yes, with adjustments. The same tiering logic applies, but the controls differ. Generative AI requires additional review for prompt injection risk, training data provenance, output watermarking or transparency, and intellectual property exposure. Foundation model dependencies — what happens when the underlying model is updated by the provider — require a vendor change notification clause that does not appear in predictive AI approvals.
How often should approved AI systems be re-reviewed?
Tier 1 systems: annually. Tier 2: semi-annually. Tier 3: quarterly, plus immediate re-review on any material change to the model, training data, intended purpose, or deployment context. Re-review is also triggered by incidents, complaints exceeding a defined threshold, or upstream changes from a vendor. ISO 42001 Clause 9.1 requires this monitoring; treating it as a calendar reminder rather than a hard control is one of the most common findings in early-stage certifications.
Who is accountable when an AI system causes harm?
Accountability sits with the named executive sponsor who approved the deployment, not with the model owner who built it or the committee that recommended it. This is why named approvals matter. The EU AI Act, NIST AI RMF, and ISO 42001 all reinforce this principle: harm allocation requires a documented chain from decision to person. “The committee approved it” is not legally durable; “the Chief AI Officer signed the deployment authorization on March 4, 2026” is.
Can the approval process be automated?
Tiering and intake routing can be largely automated. The substantive review at Gates 2, 3, and 4 cannot. Automation works for evidence collection, control mapping, deadline tracking, and cross-framework reporting. It does not replace the human judgment required to weigh residual risk against business benefit. The right design uses automation to free the committee from administrative work so it can focus on the decisions that matter.
The bottom line
A defensible AI governance approval process is not a committee, a document, or a tool. It is a sequence of named decisions — by tier, by gate, by individual — with evidence that links each decision to the framework clause it satisfies. The organizations that pass their first ISO 42001 audit and survive their first regulatory inquiry are the ones that built this sequence early, before the model count outran the manual process.
Start with one thing this week: pull your current list of production AI systems and identify which ones do not have a named, current accountable owner. That gap is your first finding. Closing it is your first win.
Govern365.ai, by the Global AI Certification Council, gives compliance teams a single source of truth for AI approvals, evidence, and cross-framework reporting. Start your 14-day free trial at govern365.ai and see what your approval process looks like when the spreadsheets are gone.
