AI risk management should be practical, not designed to frighten teams away from using the tools at all. The goal is safer, clearer, more accountable adoption; risk shows up wherever AI touches data, a decision, a customer, an employee, or a public communication. That means even a simple generative-AI use case deserves some basic controls, not just the obviously high-stakes ones.

The four practical risk categories

Privacy risk: sensitive data entered into a tool that wasn't built or approved to handle it. Accuracy risk: an output accepted without review, on the assumption that a confident-sounding answer is a correct one. Bias risk: a system that produces systematically unfair outcomes for some group of people, often without anyone noticing until a pattern has already caused harm. Vendor risk: dependency on an external platform whose data handling, uptime, or pricing the business doesn't fully control.

These four categories aren't unique to Mauritius, but a couple of them have a genuine local dimension worth naming precisely rather than gesturing at.

Where this connects to real law, not just good practice

Mauritius's Data Protection Act 2017 already applies to a specific slice of AI risk, independent of any newer AI-specific policy. Under Section 38, individuals have a right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or significantly affects them. This is directly relevant to the bias and accuracy risks above wherever a system is making, not just supporting, a decision about a specific person: screening, scoring, or eligibility use cases in particular. What the National AI Strategy actually says for SME owners covers this scope in full, including that it applies specifically to solely-automated decisions, not to every AI system a business uses.

Matching controls to risk level

Controls should scale with what's actually at stake. A low-risk internal draft doesn't need the same scrutiny as a tool supporting hiring decisions or financial recommendations: treating both identically either slows down harmless work or under-governs the case that actually matters. Useful controls include an approved-tool list, clear data rules, human review before consequential output goes out, a use-case register, basic vendor due diligence, and a defined escalation path when something goes wrong. The minimum viable AI governance framework for SMEs covers how to build these without overengineering them.

Accountability has to be a person, not a system

AI cannot be accountable; only a person or a defined function can be. Every AI use case should have a named owner responsible for monitoring its performance, risk, and value, and where a tool affects customers, employees, or financial outcomes, that ownership needs to be explicit and written down, not assumed.

Risk checklist

  • Classify each use case by risk level before deployment, not after
  • Identify what sensitive data the tool will touch
  • Check vendor terms for data handling and retention
  • Require human review for anything consequential
  • Assign a named owner to every use case
  • Track errors and incidents, not just successes
  • Review outputs periodically for bias, especially in screening or scoring contexts
  • Reassess whether a tool is still behaving as expected: don't treat initial approval as permanent