Operationalizing AI Governance: Approval Criteria, Risk Triggers and Vendor Checks That Keep Teams Moving

Most organizations now have an AI policy. Far fewer have a way to say yes to a new AI use quickly, consistently and with a record of why. Requests pile up in a privacy inbox, security runs its own questionnaire, procurement runs another, and the business team either waits or quietly signs up for a tool anyway. The fix is not more policy. It is an operating model: clear approval criteria that let low-risk uses move fast, defined boundaries that flag when a use needs deeper review, and vendor checks that fit the same flow. This guide shows how to build that model using frameworks most teams already reference, including the NIST AI Risk Management Framework, ISO/IEC 42001, the EU AI Act’s deployer duties and the US federal government’s own AI governance memo.

Why AI approvals stall

Governance programs usually slow down for the same reasons. Nobody knows which requests need full review, so every request gets it. Each function asks its own questions in its own format. Decisions are made in meetings and not written down, so the next similar request starts from scratch. And the criteria for “no” are unclear, which makes reviewers cautious and requesters frustrated.

The frameworks do not ask for that. The NIST AI Risk Management Framework, released in January 2023 and now being revised, is voluntary and organizes work into four functions: Govern, Map, Measure and Manage. Its Govern function is about policies, roles and accountability, and its companion Playbook suggests actions rather than a single fixed process. ISO/IEC 42001:2023 sets requirements for an AI management system built on the Plan-Do-Check-Act cycle, and like other management system standards it expects controls proportionate to the risks an organization identifies. Neither tells you to review a meeting-notes summarizer the same way as a hiring model.

Even the US federal government, which has some of the most prescriptive internal AI rules, builds in proportionality. OMB memorandum M-25-21, issued April 3, 2025, applies minimum risk management practices only to “high-impact” AI, defined as AI whose output “serves as a principal basis” for decisions or actions with a legal, material, binding or significant effect on rights or safety. It tells agencies to streamline approvals for closely related uses with similar risk profiles, lets limited pilots proceed with certification, and allows documented waivers. The memo binds federal agencies, not companies, but its structure is a useful template.

Build approval criteria people can apply themselves

Good criteria are written so a requester can predict the outcome before submitting. A practical way to get there:

1. Start with an inventory. You cannot tier what you cannot see. Record each AI use, its owner, the tool or model, the data it touches, and who is affected by its output.
2. Define three lanes. A fast lane for pre-approved tools and low-risk uses, a standard lane for uses needing a short documented review, and an enhanced lane for uses that hit a defined trigger.
3. Publish the fast-lane list. Name approved tools and the uses allowed with each, for example drafting internal documents with no confidential data in an enterprise-licensed assistant. Approval should be immediate, with a log entry.
4. Use one intake form. Combine privacy, security, legal and procurement questions into one short form, with follow-up questions that appear only when an answer calls for them.
5. Set decision owners and time limits. Each lane needs a named approver and a target turnaround. Enhanced reviews should go to a cross-functional group with authority to approve, add conditions or decline.
6. Record reasons. Store the decision, conditions and rationale so similar requests can reuse them. This is the “streamline closely related uses” idea in practice.
7. Reassess on change. Trigger a fresh review when the model, vendor, data, purpose or user population changes materially, and on a fixed cycle for enhanced-lane uses.

Organizations that grew their programs through spreadsheets and email often hit limits at step four or six. Our piece on breaking past homegrown AI governance looks at where those processes typically break.

Define the boundaries that trigger more scrutiny

Boundaries are what make the fast lane safe. They should be concrete enough that a requester can tell whether one applies. Common triggers include:

• Consequential decisions. The output is a principal basis for decisions about employment, credit, insurance, housing, education, healthcare or access to essential services.
• Regulated categories. The use may fall within EU AI Act Annex III high-risk categories or a prohibited practice, or under state AI or automated decision-making rules.
• Sensitive data. Special category or sensitive personal data, children’s data, biometrics, precise location or confidential client data is involved.
• Autonomy. An agent can take actions, call tools, send communications or spend money without a human approving each step.
• External exposure. Outputs go directly to customers or the public, or the system interacts with people who may not know it is AI.
• Training and retention. A vendor may use your inputs to train models, or retention terms are unclear.
• Novelty. The use is new to the organization, with no similar prior approval to compare against.

Where a trigger involves personal data, connect the AI review to existing assessments instead of creating a parallel one. Knowing when a DPIA or PIA is required helps avoid duplicate work. The EU AI Act points the same way: Article 26(9) tells deployers of high-risk systems to use provider information when carrying out a GDPR data protection impact assessment.

Know what deployers actually owe under the EU AI Act

Most companies are deployers, not providers, of AI. The Article 26 deployer obligations for high-risk systems map neatly onto an approval checklist: use the system according to the provider’s instructions, assign competent human oversight, ensure input data under your control is relevant and representative, monitor operation and report risks and serious incidents, keep logs for at least six months, inform workers before workplace use, and tell people when a high-risk system is used in decisions about them.

Timing matters. Under the consolidated text after the Digital Omnibus on AI, high-risk obligations for Annex III systems apply from December 2, 2027, and for products covered by Annex I from August 2, 2028. The AI literacy duty in Article 4 already applies, as amended to require providers and deployers to take measures supporting staff literacy without guaranteeing any specific level. Building Article 26 checks into your enhanced lane now means the evidence exists before regulators ask for it.

Put vendor management inside the same flow

Most AI reaches an organization through suppliers: a model API, an AI feature switched on in an existing SaaS product, or a new specialist tool. Treat vendor review as part of AI intake, not a separate queue, and align it with your existing third-party risk management process.

• Ask AI-specific questions. Which models are used and where are they hosted? Are customer inputs used for training? What evaluations, red-teaming and incident processes exist? Can logs be exported?
• Write it into the contract. Cover training restrictions, data retention and deletion, sub-processor and model-change notice, incident notification timelines, audit or assurance rights, and the information you need to meet your own deployer duties.
• Watch for feature drift. Vendors add AI to products you already approved. Require notice of material AI changes, and re-run intake when one arrives.
• Use evidence, not promises. Certifications such as ISO/IEC 42001, model documentation and published risk guides help. For example, vendor guidance on open-weight AI risk for enterprises can inform questions when teams want to self-host models.

M-25-21 recognizes the same reality: where agencies cannot access a vendor’s code, models or data, it points them to alternative test methods, such as querying the service and observing its outputs, or giving the vendor evaluation data and obtaining the results. Private-sector teams can use the same approach.

Make it work across teams

Governance becomes a business enabler when each function knows its role and nobody has to re-ask questions another team already answered. A simple split works for many organizations. The business owner describes purpose, users and expected benefit. Privacy covers personal data, notices and assessments. Security covers access, data flows and agent permissions. Legal covers regulatory classification and contracts. Procurement runs the vendor and commercial steps. A small AI governance group, often chaired by privacy, risk or a designated AI lead, owns the criteria, resolves enhanced-lane cases and reports to leadership.

Measure the program the way the business will judge it: median time to decision per lane, share of requests approved in the fast lane, number of conditions imposed and later verified, and incidents or complaints linked to approved uses. Surveys suggest the effort pays commercially; one widely cited example is the EY survey linking responsible AI governance to winning deals. Then test whether conditions are actually followed, ideally through a year-round AI audit portfolio rather than a single annual review.

Frequently asked questions

How many lanes should an AI approval process have?

Three is a practical default: pre-approved, standard and enhanced. More lanes add debate about which one applies, while fewer usually push too many requests into full review.

Who should have final say on a high-risk AI use?

A named, cross-functional group with real authority, not a single reviewer. Record who approved, what conditions apply and when the decision will be revisited.

Do we need ISO/IEC 42001 certification to run this model?

No. Certification is optional. The standard’s management-system structure is still useful for organizing policies, roles, risk assessment and continual improvement, whether or not you certify.

How should we handle pilots?

Allow limited, time-boxed pilots with a named owner, no high-risk triggers or appropriate safeguards, and a required review before any wider rollout.

Fast by design, careful by exception

The goal of AI governance is not to review everything equally. It is to make the routine easy and the risky visible. Organizations that publish their criteria, define their triggers and fold vendors into one flow find that most requests clear quickly, and that the reviews they do run are better because reviewers have time to do them properly.