AI governance is not an extra board for every tool question. It is the operating model a business uses to decide which AI may be used for what purpose, who reviews the risk, who approves deployment and how decisions remain traceable.
A practical AI governance framework needs five elements: a complete AI inventory, risk-based classification, named owners, documented approval and change workflows, and continuous monitoring. Smaller businesses can run this with one coordinator, a cross-functional review group and a small set of standard records; not every use case needs its own governance board.
What AI governance means in practice
Governance translates objectives, laws and risk appetite into repeatable decisions. The NIST AI Risk Management Framework organises this work into Govern, Map, Measure and Manage. ISO/IEC 42001 describes a management system that establishes and continually improves policies, objectives and processes for responsible AI.[1][2]
A lean operating model
| Role | Accountability | Evidence |
|---|---|---|
| Executive sponsor | Risk appetite, budget and escalation limits | Governance mandate |
| Use-case owner | Purpose, value, data and process outcome | Use-case record |
| Domain reviewer | Output quality, failure impact and human check | Test and acceptance record |
| IT, privacy and security | Access, vendors, data flows and controls | Technical review |
| AI coordinator | Inventory, classification, reviews and incidents | Register and decision log |
Four internal risk tiers
| Tier | Example | Approval | Control |
|---|---|---|---|
| 1 · low | Ideation without confidential data | Pre-approved tool | Sampling |
| 2 · limited | Internal summaries | Use-case owner | Source review |
| 3 · elevated | Customer content or personal data | Cross-functional review | Four-eyes principle |
| 4 · critical | Employment, credit or safety decisions | Executive and formal review | Monitoring and audit |
This internal tiering does not replace legal classification under the EU AI Act. It is an operational routing mechanism: the greater the potential harm, data sensitivity and decision influence, the stronger the testing, evidence and oversight.
The six-step approval workflow
Define purpose
State the problem, supported decision, intended user and measurable benefit.
Record system and data
Capture vendor, model, integrations, data types, locations and affected groups.
Classify risk
Assess impact, likelihood, reversibility, autonomy and applicable legal role.
Select controls
Define access, input rules, citations, human approval, tests, logging and stop criteria.
Pilot and accept
Test representative cases and approve only against pre-agreed quality thresholds.
Monitor change
Incidents and changes to model, vendor, data or purpose trigger a documented review.
Minimum evidence set
- AI policy and acceptable-use rules
- AI inventory with owner and status
- Use-case record and business objective
- Risk and control matrix
- Test and approval record
- Incident and escalation path
- Supplier assessment
- Role-based training evidence
Evidence should reconstruct the decision: who approved what, based on which assumptions, with which controls and review date. If nobody can keep the record current, it is too heavy.
Human oversight that is actually effective
A human in the loop is only a control when that person has enough time, information, competence and authority. Define which outputs require review, which sources must be visible, what triggers a stop, and who may override the system. Routine rubber-stamping is not meaningful oversight.
How to classify a tool
The product name does not determine the risk tier. Classification comes from data, decision influence, reach and autonomy. The same writing assistant can be low risk for public marketing drafts and materially higher risk when used in employee assessment.
| Dimension | Lower risk | Higher risk |
|---|---|---|
| Data | Public or synthetic | Personal, confidential or specially protected |
| Decision influence | Idea or non-binding draft | Selection, access, price, assessment or safety |
| Autonomy | No action without review | System publishes or acts |
| Reach | Small internal group | Many customers, workers or affected people |
| Reversibility | Error is visible and easy to correct | Impact is hidden or difficult to reverse |
Review cadence and governance metrics
Governance should run at the cadence of the operation. A monthly review of new tools and incidents, a quarterly portfolio review and an event-driven review after material change are a workable starting point for many SMEs. The schedule must be owned and booked, not merely described in a policy.
- Production systems with a named owner
- Use cases with a current classification
- Open controls and overdue reviews
- Quality and security incidents by system
- Users with current role-based training
- Systems without demonstrated business value
Three common governance decisions
Marketing draft
An approved business account processes public product information and a person reviews the copy before publishing. Standard rules, sampling and one owner may be proportionate.
Internal knowledge assistant
The system retrieves internal sources. Permission enforcement, citations, freshness, logging and conflicting knowledge must be tested before approval.
Candidate screening
The system influences access to employment. It requires formal legal and domain assessment with strong data, quality and oversight controls; a generic tool review is insufficient.
Frequently asked questions
Does every company need an AI governance board?
No. An accountable coordinator and named reviewers are often sufficient for an SME. A standing board becomes useful when the portfolio is large, critical or cross-functional.
Is ISO/IEC 42001 mandatory?
No. It is a voluntary standard, but it can provide structure for an AI management system and credible evidence to customers.
Who approves an AI system?
The business owner owns the outcome. Elevated-risk use cases should also involve IT/security, privacy or legal expertise and accountable leadership.
How often should the AI inventory be reviewed?
At least quarterly and whenever the provider, model, data, purpose or risk context changes.
