AI governance: 4 risk levels and who approves each use
Most boards cannot say how many AIs the company uses or which decisions they influence. AI governance is the system that answers this: an inventory of use cases, risk classification, named owners, an approval cycle, monitoring, contracts and training.
AI governance is the set of decisions, roles and routines that lets the board know which AI systems the company uses, which decisions they influence and who answers for each one. Ask at your next leadership meeting how many AIs the company uses today and you will hear different answers from the CIO, legal and the sales director, because each one knows a piece. NIST, the US government standards institute, published the AI Risk Management Framework in January 2023 for voluntary use, and listed among the outcomes of its governance function the existence of mechanisms to inventory AI systems (NIST, 2023). In December of the same year, ISO published ISO/IEC 42001, which it presents as the world’s first AI management system standard (ISO, 2023). In a mid-sized company, governance that works has a use case inventory, a four-level risk matrix, a small committee, an owner per case, an approval cycle with deadlines, an incident route and minimum clauses with vendors, all of it supported by training for whoever holds each role.
At Iasbeck&Co we implement CRM and AI agents in B2B operations, and I wrote this piece for the board, legal, IT and HR. The rules for employees are in AI usage policy, and the status of the European law and of Brazil’s bill PL 2338/2023 is in AI regulation. Here I cover the level above, how the company decides, approves, monitors and shuts down each use. This is management guidance and does not replace legal advice.
What is AI governance and how does it differ from a usage policy?
The usage policy tells the salesperson what they can paste into a tool and what they must review before sending. Governance tells the company who approves an agent that answers customers on its own, with what criteria, for how long, and who orders it switched off when the error rate climbs. The team reads the policy, and leadership runs governance, with a meeting, a register and an indicator.
The unit of governance is the use case, which I define as a concrete task done with AI, on defined data, with a result someone consumes. The same corporate assistant can summarize the minutes of an internal meeting and, in the next room, rank résumés for the recruiter. The tool is the same and the risk is different, because in the second case the AI influences a decision about a person, and whoever governs by tool loses that difference.
The logic repeats what the company applies to data, with an owner, a rule and a routine, so the AI committee needs to talk to whoever runs data governance. An agent that reads a database with no owner inherits every problem in that database.
NIST AI RMF and ISO/IEC 42001: which references to use?
NIST AI RMF 1.0 organizes AI risk management into four functions. Map establishes the context in which each system operates, Measure analyzes and tracks risks with quantitative and qualitative methods, Manage allocates resources to treat the mapped and measured risks, and Govern is the cross-cutting function infused throughout the other three (NIST, 2023). Within Govern, the document calls for an inventory of systems (GOVERN 1.6), a process to decommission them without increasing risk (1.7), documented roles (2.1), trained personnel (2.2), executive leadership responsible for risk decisions (2.3) and policies for third-party risks (6.1). In July 2024, the institute published NIST AI 600-1, a profile that applies the same model to generative AI (NIST, 2024).
ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and it applies to organizations of any size that develop, provide or use AI-based products and services (ISO, 2023). A management system, in ISO vocabulary, is the set of policies, objectives and processes the organization uses to pursue those objectives. My reading for the mid-sized Brazilian company: use NIST, which is free, as the working roadmap, and treat ISO 42001 as the reference for the day a large customer asks for formal evidence of governance.
How do you build the inventory of AI uses and tools?
The inventory has two layers. The first lists tools and vendors, with contract, licenses, who pays and where the data sits. The second lists the use cases, where the risk lives, and each tool can appear in several. To find what exists, cross finance (card subscriptions and reimbursements), IT (apps using corporate login), the CRM administrator (agents and automations switched on) and an anonymous survey of the teams, which brings self-provided use to the surface.
One more source is the one almost nobody checks: the AI features built into systems the company already pays for. CRM, service platform, ERP and meeting recorder gained assistants and agents in recent updates, and some of them come switched on by default. In the inventories I follow, this built-in AI tends to be the part nobody listed, because nobody bought anything new.
For each case, record name, area, owner, tool, data read, what the case produces or executes, who is affected (customer, candidate, employee or only the team), risk level and the dates of approval and next review. Agents go in with the fields I described in AI agents. A spreadsheet handles up to a few dozen cases, as long as it has an owner and a review on the committee calendar.
How do you classify the risk of each AI use case?
I classify each case with five questions: does the result affect someone outside the team, does the AI decide or only suggest, does the content leave the company without review, is there personal or sensitive data, and is the error easy to undo. The answers lead to one of four levels, with proportional requirements. The European AI Act and Brazil’s PL 2338 use the same risk-based logic, with their own high-risk lists that legal should check. The matrix below is the instrument I bring to the committee’s first meeting.
| Level | Examples | Human review | Record | Test before go-live | Who approves |
|---|---|---|---|---|---|
| 1. Low | Summary of an internal document, draft of a post, market research | The user checks what they keep | Tool in the approved catalog | Tool assessment | The team, under the usage policy |
| 2. Moderate | Follow-up drafted by an agent, ticket reply, call summary in the CRM | A person approves before it leaves the company | Case in the inventory with owner, data and actions | A few dozen real cases compared with the team’s work | Case owner and IT |
| 3. High | Résumé screening, support to performance reviews, automatic discount or credit, agent that acts without item-by-item approval | The AI recommends and a person decides, with a record of who decided | Full sheet, decision history and a channel to contest | Error and bias test by group, before go-live and at each review | Committee, with legal and data protection officer opinion |
| 4. Prohibited | Emotion recognition on employees, dismissal decided by AI, sensitive data in a tool with no contract | Not applicable | Published list | Not applicable | Only the board changes the list |
When in doubt between two levels, the case goes to the higher one. The classification follows the scope, so an agent that moves from drafting to sending on its own goes back to the committee, even with the same tool. At level 3, someone must be able to explain to the affected person why the decision came out that way, which connects to the review of automated decisions under Brazil’s data protection law (LGPD) that I detailed in AI and LGPD.
Roles and responsibilities: who owns what in AI governance?
I translate the NIST requirement of responsible executive leadership into a named sponsor on the board. Below the sponsor sit a small committee and an owner per case, with IT, legal and HR in defined roles. The table separates who answers, who approves and who executes, because confusion among those verbs produces most of the ownerless cases.
| Role | Answers for | Approves | Executes |
|---|---|---|---|
| Board and sponsor | Risk appetite, budget, prohibited list | Changes to the prohibited list | Quarterly review of the dashboard |
| AI committee (IT and security, legal and data protection officer, HR, a business leader, RevOps) | Matrix, inventory, review calendar | Level 3 cases and reclassifications | Monthly meeting and post-incident review |
| Case owner (leader of the area that consumes the result) | Result and quality of what the AI produces | Level 1 and 2 cases in the area, with IT | Sheet, 90-day review, shutdown request |
| IT and security | Technical vendor assessment, access, logs | New tools in the catalog | Configuration and technical shutdown |
| Legal and data protection officer | Legal basis, contracts, transparency, incidents with personal data | Clauses and opinion at level 3 | Contract and incident review |
| HR | Training and AI that affects candidates and employees | Use in recruiting and performance, with the committee | Training path |
The committee must fit in a one-hour meeting per month. If it approves every case, it becomes a queue and sends the teams back to their own tools; so levels 1 and 2 are settled in the area, with IT, and the committee keeps level 3, reclassifications and incidents. The case owner comes from the business: IT configures and protects, and the sales director is the one who knows whether the agent’s follow-up serves the customer.
How does the approval cycle for a new use case work?
The cycle starts with a one-page sheet the future owner fills in, with the baseline of the indicator from the request onward, because without it nobody can say later whether the case delivered, as I detailed in AI ROI. IT and the owner propose the level with the matrix. At level 1, IT confirms the tool is in the catalog and the case enters the inventory. At level 2, IT assesses the vendor, the owner runs the test and both approve with a review date. At level 3, the case goes to the committee with the test, the legal opinion and the design of who decides and how the affected person contests.
Every approved case starts as a pilot, with limited scope and a shutdown criterion written before go-live, such as “correction rate above 20% for two months” or “any send outside permission”. At the 90-day review, the owner presents indicator, corrections, incidents and cost, and the committee keeps, reclassifies or shuts it down. The deadline is also a rule: I propose a few days for level 1, up to two weeks for level 2 and the committee’s monthly cycle for level 3, published alongside the sheet.
Monitoring and incidents: what to track once AI is in production?
In the Manage function, NIST describes post-deployment monitoring plans, with user input, appeal and override, decommissioning, incident response and change management (NIST, 2023). In the operation, this becomes a monthly dashboard per case with the correction rate (the share of AI output the reviewer edited or rejected), complaints tied to the case, the month’s cost and the result of a sample audited by the owner. At level 3, the committee also looks at results by group, to see whether screening drops one profile more than the others.
An AI incident needs a written definition: improper content that reached a customer, personal data sent to a tool outside the catalog, a decision contested by an affected person and an agent that acted outside its permission. On the route, the owner pauses the case, IT preserves the records, the committee assesses the cause and the data protection officer decides whether the case must be reported to Brazil’s data protection authority (ANPD) and the data subjects, as LGPD requires for security incidents involving personal data. The review ends with a recorded decision, and shutting down becomes routine: cases with no owner, cases that missed the indicator in two reviews and discontinued tools leave the inventory with a date and deletion of the data at the vendor.
Vendors and AI contracts: what to review before signing?
Part of the risk lives in the contract. The vendor can swap the model behind the tool and change the behavior of a case that worked, use subcontractors to process the data and switch on new features without notice. At levels 2 and 3, legal and the data protection officer check these questions before signing or at the next renewal.
| Clause | Question for the vendor |
|---|---|
| Model training | Does what we send train or improve models, and how do we turn that off? |
| Location and subcontractors | In which countries is the data processed and which third parties, including model providers, take part? |
| Retention and deletion | How long do you keep prompts, files and responses, and how do you prove deletion? |
| Incidents | How quickly do you report an incident involving our data? |
| Model changes | Do you give notice before swapping the model or switching on new AI features? |
| Records | Do we have access to usage logs for internal audit? |
| Liability | Who answers for infringement of third-party rights in generated content? |
For each level 3 case, the owner also writes how the area works if the vendor goes down, because a team that forgot how to operate without the AI stops when the vendor fails.
Training: who needs to learn what
NIST treats training of personnel and partners as an outcome of governance itself. The board learns to read the dashboard and decide risk appetite. The committee applies the matrix and assesses vendors, owners fill in the sheet and run the 90-day review, and level 2 and 3 reviewers learn what to check before approving. HR coordinates the path and makes sure anyone using AI on candidates and employees can explain and review the result. To measure, track the cases with an owner and an up-to-date review, and the sheets that arrive complete on the first attempt.
Common mistakes in AI governance
Governing the tool instead of the use case
Approving or blocking an entire tool releases the high-risk use along with the low-risk one, or blocks both. Classify the case and use the tool catalog as a prerequisite.
A committee that approves everything
In the projects I lead, teams stop asking for approval when the answer takes longer than buying a tool on the card. Delegate levels 1 and 2 and publish the deadlines.
An inventory done once
An inventory built for an audit and forgotten describes the company of six months ago. Give it an owner, a monthly review and a rule: a case outside the inventory is an unapproved case.
Forgetting the AI built into contracted systems
Features that arrive through updates in the CRM, service platform and ERP go into production with no sheet and no owner. Ask about active AI features at every renewal and every relevant release note.
Approving without a shutdown criterion
An approved case with no exit condition keeps running by inertia, even as the indicator worsens. Write the criterion on the sheet and demand the decision at the 90-day review.
30-day roadmap for leadership
- Days 1 to 5: name the sponsor and the committee. The board picks the sponsor, forms the committee and publishes the first list of prohibited uses.
- Days 6 to 12: build the inventory. Cross finance, IT, the CRM administrator and the anonymous survey, and ask each system owner for the active AI features.
- Days 13 to 17: classify the cases. Apply the matrix, give each case an owner and pause level 3 cases with no owner or no human review.
- Days 18 to 22: publish the approval cycle. Share the sheet, the deadlines per level and the request channel, with a date to regularize whatever is outside the inventory.
- Days 18 to 25: review contracts. Legal checks the clauses with level 2 and 3 vendors, starting with those that process personal data.
- Days 23 to 27: switch on monitoring. Define the monthly dashboard, write the incident definition and test the route with a simulated case.
- Days 28 to 30: train and schedule the review. Train the committee and owners on the matrix and the sheet, present the classified inventory to the board and schedule the quarterly review.
The roadmap puts the structure in place, and the people who fill in the sheet, review what the AI produces and decide when to shut it down are the ones who make governance run. That is the work of the in-company applied AI training, with groups for the board, the committee, case owners and sales, marketing, CS and HR teams, built on the company’s processes, which delivers the prompt library by area and the agent architecture, with what each agent reads, what it executes and who approves, the basis for the inventory and the risk classification.
Frequently asked questions
What is AI governance?
It is the set of decisions, roles and routines through which the company knows which AI systems it uses, classifies the risk of each use case, approves new ones, monitors those in production and shuts down those that no longer serve. It includes inventory, risk matrix, committee, case owners, monitoring, vendor contracts and training.
What is the difference between AI governance and an AI usage policy?
The usage policy sets the rules for employees, such as approved tools, permitted data and review before sending. Governance is the leadership process that decides which use cases exist, at what risk level, who approves and how the company monitors and responds to incidents. The policy is one of the pieces of governance.
Does the company need ISO/IEC 42001 certification?
No Brazilian law requires the standard today. For most mid-sized companies, NIST AI RMF works as a free roadmap to build governance, and ISO/IEC 42001 becomes the reference when large customers start asking for formal evidence of AI management in contracts or due diligence.
Who should lead AI governance in the company?
A sponsor on the board, who answers for risk appetite, supported by a small committee with IT and security, legal and the data protection officer, HR, a business leader and RevOps. Each use case has an owner in the area that consumes the result, and IT configures and protects without deciding business risk alone.
How do you classify the risk of an AI use case?
Ask whether the result affects someone outside the team, whether the AI decides or only suggests, whether the content leaves without review, whether there is personal or sensitive data and whether the error is easy to undo. The answers lead to one of four levels, from low to prohibited, each with its own requirements for human review, record and testing, and when in doubt the case goes to the higher level.
How do you prepare the team for AI governance?
Train by role: the board learns to read the dashboard and decide risk appetite, the committee applies the matrix and assesses vendors, owners fill in the sheet and run the review, and reviewers learn what to check before approving. Track how many cases are in the inventory with an owner and an up-to-date review, and how many sheets arrive complete on the first attempt.
Want to bring this to your team?
The topics in this article also become in-company training: designed from a diagnosis of your operation, with real cases from your team and a deliverable that stays with the company.
More writing on the same subject.

Training results: how to measure in 4 levels and 90 days
A satisfaction survey measures the class and leaves the board without knowing whether the pipeline changed. How to measure the results of sales, CRM or AI training across the four Kirkpatrick levels and Phillips ROI, with a baseline, a comparison group and a 90-day dashboard.
18 min readRead more
CRM data model: how to design it in 7 decisions
A CRM configured without a design piles up fields nobody can explain and reports the board does not trust. The seven decisions of the data model, from objects to naming, the document that records who fills in what and when, and how to validate the design with every team before configuring.
19 min readRead more
Customer health score: 6 signals and how to calibrate
A health score warns of cancellation months ahead when it combines usage, relationship, tickets, payment, sponsor and NPS with weights taken from past cancellations. How to calibrate it, what CS does in each band and how to build the score in the CRM.
18 min readRead more