Enterprise AI governance does not need invented rules. Two useful reference points already exist: ISO/IEC 42001, an international AI management-system standard, and NIST's voluntary AI Risk Management Framework. They play different roles: ISO/IEC 42001 sets out requirements an organisation can implement and be certified against; the NIST AI RMF is non-certifiable guidance offering a structured way to think about AI risk. ISO/IEC 42001 and the NIST AI RMF approach AI governance differently, but they overlap on several core disciplines: governance and accountability, contextual risk assessment, measurement, ongoing risk management and lifecycle thinking.
Two reference frameworks, four governance disciplines
| Governance discipline | ISO/IEC 42001 | NIST AI RMF | Practical enterprise question |
|---|---|---|---|
| Governance & accountability | Requires establishing, implementing and maintaining an AI Management System with defined roles and responsibilities | "Govern" function: organisational accountability and policy structures for AI risk | Who is accountable for this system, and is that written down anywhere? |
| Context & risk | Provides a structured approach to managing AI-related risks and opportunities within the management system | "Map" function: establish context and identify risk for a specific AI system before deployment | Have we actually assessed risk for this system in its specific context, or assumed it's fine? |
| Measurement | Requires continual improvement of the AI Management System over time | "Measure" function: analyse and track risk using quantitative and qualitative methods | How would we actually know if this system stopped working as intended? |
| Response / lifecycle management | Applies across the lifecycle of AI-based products and services an organisation provides or uses, including ongoing maintenance | "Manage" function: allocate resources to treat risk, document residual risk, respond to incidents | What happens, specifically, when something changes or goes wrong? |
For an SME, a lighter version of this exists: five components a small team can maintain without a dedicated risk function. This article is for organisations where that scale genuinely isn't enough: more complex data flows, formal audit expectations, or a dedicated risk or compliance function already in place.
Accountability that survives contact with a real incident
The starting discipline is simple to state and hard to enforce: a statistical model does not hold accountability. A named human or function does. Before an AI system touches a consequential decision (hiring, credit, pricing, safety), the organisation should be able to answer, in writing, who is accountable if that decision turns out to be wrong. This is what a governance-and-accountability discipline is asking for structurally; it doesn't require a "legal charter" theatre, just a genuine, checkable answer.
Risk treatment proportionate to context and impact
Not every AI use case deserves the same scrutiny. A system drafting internal reports and a system making automated decisions about individuals' credit, employment, or legal status sit at different points on any reasonable risk spectrum, and treating them identically either over-governs the low-risk case or under-governs the high-risk one. Organisations often operationalise this through internal risk tiers, a practitioner framework for applying the underlying principle, not a specific classification scheme either standard prescribes. What matters is that the treatment is proportionate to context and impact, however an organisation chooses to structure that internally.
Where a decision about a person is made solely through automated processing, including profiling, that is not just a governance best-practice question in Mauritius. It is a Section 38 question under the Data Protection Act 2017; see what the National AI Strategy actually says for SME owners for the full scope of that obligation.
Human oversight as a risk control, not a universal rule
For high-impact use cases, meaningful human oversight is often an appropriate risk control. The appropriate form of oversight should depend on the system, its context, the consequences of error, and any applicable legal requirements, not a single universal rule applied identically everywhere. A system that drafts a recommendation for a credit officer to review and approve is a different governance case than one that auto-approves or auto-rejects without review, and the right level of oversight follows from that difference rather than from a blanket policy.
Governance continues after deployment
An AI system's behaviour can change after deployment for several distinct reasons, not one generic "drift." Model drift refers to the model's own performance degrading as real-world patterns diverge from what it was trained on. Data drift refers to changes in the input data itself. Performance can also degrade for reasons unrelated to either: infrastructure changes, integration issues, or a shift in the operating context the system was designed for. Governance that stops at initial approval misses all of these. The practical principle is straightforward even if the causes aren't uniform: governance continues after deployment. Define what "working as intended" looks like, check against it on a genuine schedule, and have a documented, proportionate response when something changes, not a single alarming rule, but a real, repeatable process.
What this doesn't cover
This article describes the structural shape credible governance takes, informed by two real reference frameworks; it is not a certification guide, and it doesn't replace a genuine ISO/IEC 42001 gap assessment or legal advice for a specific regulated sector. Organisations in heavily regulated industries (financial services, healthcare) have obligations beyond what's described here.
