Insights

An AI governance framework for a 20 to 200 person organisation

By , Founder & Lead Advisor. . 18 minute read.

Most organisations in Mauritius with between 20 and 200 staff are already using AI. Somebody in sales drafts proposals with a chatbot. The accounts team has turned on the assistant inside the accounting package. A supplier has quietly added a recommendation engine to the ordering portal. None of this was approved as an “AI project”, and none of it appears on any list.

That is the situation this framework is written for. It assumes there is no compliance department, no data team, and no budget for a governance function. It assumes the managing director or a board member wants a structure that is light enough to run, and solid enough that it will not need to be rebuilt if a client, a regulator or a certification body asks to see it later.

The framework builds on the founder’s earlier piece on faaleh.com, Minimum Viable AI Governance Framework for SMEs, which sets out the five smallest artefacts a small team can keep: a use case register, data and access rules, a risk classification, an accountability map and a review rhythm. If you have none of those, start there. This article is the level above it: the same logic, but with named roles, defined inventory fields, a risk classification tied to the Mauritian context, a review cadence a board can hold management to, and a deliberate mapping to ISO/IEC 42001 so that the work is not wasted if certification becomes relevant.

Key questions this answers:

  • What does governance look like when nobody’s job title contains the word “compliance”?
  • Who owns AI in a small organisation, and what does each role actually do?
  • What must be in the AI system inventory?
  • How do you classify risk without a risk department?
  • How often should each part be reviewed, and by whom?
  • What makes the whole thing audit-ready later, without doing the audit work now?

Governance without a compliance function

In a large firm, AI governance tends to be a committee, a policy suite and a second-line team that checks the first line. In a 45-person company, that model does not exist and should not be imitated. What can exist is a small set of decisions that are written down, owned by named people, and revisited on a schedule.

Governance in this setting is four things. First, a list of what the organisation actually uses, because you cannot govern what you have not counted. Second, a person accountable for each item on that list. Third, a proportionate view of which items matter, so that the limited time available for this goes to the right places. Fourth, a rhythm: a monthly check by the owners and a quarterly look by the executive who signs off.

Everything else, including policies, training and templates, exists to support those four things. If a document does not help someone answer “what do we use, who owns it, how much does it matter, and when did we last check”, it is probably not needed yet.

The practical implication is that AI governance in an SME is a management routine, not a compliance programme. That is also the framing in the FAIR Guidelines, which state that private sector responsibility “applies regardless of organisational size” and that expectations “should be applied proportionately, recognising differences in capacity, scale and impact”. The FAIR Guidelines are non-binding, and we return to their status below, but the proportionality principle is the right one to adopt.

Who owns AI in a small organisation

The single most common failure in SME AI governance is diffuse ownership. Everyone is “using AI”, so nobody is responsible for it. The remedy is to name a small number of roles and attach them to existing people. None of these are new hires. In a 20-person firm, two people can hold all of them; in a 200-person firm, they will be spread across five or six.

Role Who typically holds it What they are accountable for
Accountable executive Managing director, or a director delegated by the board Approving the AI policy and risk appetite; signing off high-tier systems; receiving the quarterly review; answering to the board and to external parties
AI system owner (one per system) The manager of the function that uses the system Keeping the register entry accurate; ensuring the intended use is respected; checking outputs before consequential action; raising incidents
Reviewer A second person who does not own the system, often the finance manager, operations manager or HR lead Independent check of high-tier and medium-tier systems at the review cadence; challenging classification; confirming that controls are actually operating
Data protection contact The officer designated for data protection compliance issues (see below) Advising on whether a system processes personal data, whether a DPIA is needed, and whether an automated decision falls under the Act
IT or security lead Internal IT person, or the outsourced IT provider under a named contact Access control, account provisioning, vendor security terms, logging and retention for AI tools

Three points on this table.

The accountable executive must be a single person. A board can oversee, but a committee cannot be accountable. This mirrors the FSC’s guidance for its licensees, which calls for “clearly defining responsibility for the AI system across its entire life cycle”, and the FAIR Guidelines’ expectation that for every AI system there is clarity about “who is responsible for authorising the use of the AI system, who oversees its operation and performance, and who is accountable for addressing risks, errors or harm”. Neither document binds a distribution company or a law firm, but both describe the structure that regulators and certifiers expect to see.

The AI system owner is the load-bearing role. It sits with the person closest to the use, not with IT, because the risk is in how outputs are used, not in the software. A recruitment screening tool is owned by the HR lead. A pricing assistant is owned by the commercial manager.

The data protection contact is not optional in the way the others are. Legal requirement: section 22(2)(e) of the Data Protection Act 2017 lists, among the measures a controller must implement to demonstrate compliance, “designating an officer responsible for data protection compliance issues”. Most organisations already have someone in that seat, often the finance or administration manager. The AI framework simply gives that person a defined place in the review.

What must be in the AI system inventory

The inventory, or AI system register, is the foundation. Without it, every other component has nothing to attach to. The fields below are the minimum Consultaix recommends for an organisation of this size. They are deliberately few, because a register that takes an hour to update will not be updated.

Field What to record Why it matters
System ID A short reference (AI-001, AI-002) Lets the risk register, incidents and reviews point to one entry
System name and vendor The product, the supplier, and whether it is a standalone tool or a feature inside another system Vendor changes and embedded features are the most common untracked risks
Business purpose One sentence: what it is used for and by which team Defines the intended use; anything outside it is a change requiring review
Owner Named person, not a department Accountability
Users Roles or teams with access, and roughly how many people Scale is a risk factor
Data used Categories of input: public, internal, commercial, personal, special categories Drives the data protection questions
Personal data? (Y/N) Whether any personal data of customers, staff or third parties is input or output Triggers the Data Protection Act analysis
Decision role Assists a human, recommends to a human, or decides automatically The single most important field for risk
Affected parties Who is affected by outputs: internal staff only, customers, applicants, the public Drives the tier
Risk tier Low, Medium or High (see below) Sets the controls and review frequency
Approval Who approved, on what date Evidence that use was authorised
Contract or terms Where the vendor terms sit; data location; whether inputs are used for training Needed for the transfer analysis under the Act and for vendor governance
Last review date and next review date Dates The cadence, made visible
Status Proposed, approved, in use, suspended, retired Lifecycle tracking

Two observations from practice. First, the “Decision role” and “Affected parties” fields do most of the work. An organisation that records only those two fields accurately has already done most of its risk classification. Second, the inventory should include AI features embedded in existing software, not only tools bought as “AI”. The assistant in the CRM, the fraud flag in the payment gateway and the auto-categorisation in the accounting system all belong on the list.

Best practice: treat the register as a living document with one owner (usually the accountable executive’s delegate) and a rule that nothing is used in production until it has an entry. The FAIR Guidelines describe appropriate record-keeping as “a practical requirement for accountability”; the register is the simplest form of that record.

Classifying risk proportionately

A small organisation does not need a scoring model. It needs a three-tier classification that anyone can apply in five minutes and that a reviewer can challenge. Consultaix recommends the following tiers, which are consistent with the indicative tiers in the FAIR Guidelines (low, medium, high, with a separate category of uses that may be unacceptable) and with the thresholds in the Data Protection Act.

Tier 1: Low

The system assists an individual with a task, a human reviews everything before it leaves the organisation, no personal data of customers or staff is input, and an error would be embarrassing rather than harmful.

Examples: drafting internal documents, summarising public reports, translating marketing copy, suggesting spreadsheet formulas, scheduling assistance.

Controls: register entry, a one-page acceptable use rule, user awareness. Annual review.

Tier 2: Medium

The system influences a decision or a customer-facing output, but a named person makes the final call and can override it. It may process personal data, but does not make or materially shape decisions about individuals on its own.

Examples: a chatbot answering customer questions from an approved knowledge base; a tool that drafts responses to supplier disputes; an assistant that ranks leads for follow-up; a demand forecasting feature that a planner adjusts before ordering.

Controls: everything in Tier 1, plus a named owner, documented intended use, a check that vendor terms cover data handling, transparency to affected parties where an output goes outside the organisation, and a record of overrides. Quarterly review.

Tier 3: High

The system makes, or substantially determines, decisions that significantly affect individuals: recruitment, credit, pricing to individuals, disciplinary matters, eligibility for a service. Or it processes special categories of personal data, or operates at a scale where an error would affect many people before anyone noticed.

Examples: automated screening of job applications; automated credit limits for customers; a tool that decides which claims or complaints are escalated; anything within a regulated activity.

Controls: everything in Tier 2, plus sign-off by the accountable executive, an impact assessment before go-live (a DPIA where the Act requires it, an AI impact assessment otherwise), meaningful human review of individual outcomes, a route for affected people to challenge a result, testing for bias on the relevant groups, incident logging, and a monthly owner check with a quarterly reviewer check.

How the tiers meet the law

Legal requirement: section 38(1) of the Data Protection Act 2017 gives every data subject “the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or significantly affects him”. Section 38(2) sets out the exceptions (necessary for entering into or performing a contract, authorised by a law that lays down suitable safeguards, or based on explicit consent), and section 38(5) requires the controller, in the contract and consent cases, to implement “suitable measures to safeguard the data subject’s rights, freedoms and legitimate interests”. Any system whose decision role is “decides automatically” and whose affected parties include individuals is therefore Tier 3 by default, and the data protection contact must be involved before it goes live.

Legal requirement: section 34(1) of the Act requires a controller or processor to carry out an assessment of the impact of envisaged processing operations, prior to processing, where those operations “are likely to result in a high risk to the rights and freedoms of data subjects”. Section 34(2)(a) names “a systematic and extensive evaluation of personal aspects relating to individuals which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the individual or significantly affect the individual” as one such operation. Section 34(3) sets out what the assessment must contain. In practice this means that many Tier 3 systems that touch personal data will need a DPIA. The Data Protection Office publishes a guide to completing its DPIA form and states that the form is submitted online through its eDPO system.

Best practice: the FAIR Guidelines are explicit that their indicative risk tiers “do not create legal classifications or prohibitions” and that “no single factor is determinative”. Consultaix’s advice is to use the tiers to allocate attention and to let the data protection contact make the statutory calls separately.

The important discipline is that the tier is set by the use, not by the tool. The same large language model can be Tier 1 when it drafts a memo and Tier 3 when it screens CVs. The register therefore records systems by use, and a tool used for two purposes gets two entries.

The review cadence

Governance that is not scheduled does not happen. The cadence below is designed so that the total time for a 45-person organisation is roughly one hour a month for the owners, two hours a quarter for the reviewer and accountable executive, and half a day a year for the whole.

Activity Frequency Who What is checked
Owner check, Tier 3 systems Monthly Each system owner Outputs still fit intended use; overrides and incidents logged; no unapproved change in vendor behaviour
Owner check, Tier 2 systems Quarterly Each system owner As above
New tools sweep Monthly Register keeper Any new tool, subscription or embedded feature that appeared since last month is added and tiered
Reviewer check Quarterly Reviewer, with the data protection contact Sample of Tier 2 and all Tier 3 entries; classification still right; controls actually operating; DPIAs current
Executive review Quarterly Accountable executive Reviewer’s report; incidents; decisions to approve, suspend or retire; risk appetite still appropriate
Board report Twice a year, or as the board directs Accountable executive Register summary, Tier 3 list, incidents, changes in law or guidance, next period’s plan
Full framework review Annually Accountable executive with reviewer Whether roles, tiers, templates and policy still fit the organisation; training refresh

Two triggers sit outside the calendar. A material change to a system’s purpose, scope or vendor behaviour triggers a re-classification, which the FAIR Guidelines also recommend (“changes to system purpose, scope or behaviour should trigger a review of accountability arrangements”). And any incident (a wrong output that reached a customer, a data disclosure, a complaint about an automated outcome) triggers an owner report to the accountable executive within the week.

What makes it audit-ready later

ISO/IEC 42001:2023 is the international standard for an AI management system. It is voluntary. Most organisations of the size discussed here will never seek certification, and should not build a governance framework on the assumption that they will. But a number will one day face a client questionnaire, a tender clause or a group policy that asks whether their AI governance is “aligned with ISO/IEC 42001”, and the cheapest way to be ready for that question is to have built the framework in the standard’s shape from the start.

ISO/IEC 42001 follows the same harmonised structure as ISO 9001 and ISO/IEC 27001, with requirement clauses grouped into seven families: context of the organisation, leadership, planning, support, operation, performance evaluation and improvement. The mapping below is in general terms; it is not a substitute for reading the standard, and Consultaix does not reproduce clause text here.

Framework component Clause family it evidences What a certifier would eventually look for
The one-page scope statement (which teams, which systems, which sites) and the list of interested parties (customers, staff, regulators, the Data Protection Office) Context That you know what your AI management system covers and who cares about it
The accountable executive, the approved AI policy, the role table Leadership Top management commitment, a policy, and assigned responsibilities
The three-tier classification, the risk register, the DPIA and impact assessment records, the objectives set at the annual review Planning Risk assessment, risk treatment, impact assessment and measurable objectives
Training records, the acceptable use rule, the register itself as documented information Support Competence, awareness, communication and control of documents
The register’s intended use and approval fields, vendor terms, the Tier 3 controls, incident logging Operation Operational planning and control across the AI system lifecycle, including third parties
The owner checks, the quarterly reviewer report, the executive review and board report Performance evaluation Monitoring, internal audit and management review
Incident follow-up, corrective actions recorded at the quarterly review, the annual framework review Improvement Nonconformity handling and continual improvement

The point of the mapping is not to make a small firm speak ISO language. It is to make sure that when the firm does something sensible, such as recording who approved a system, it does it in a form that will count as evidence later. The gap between this framework and certification is real: an internal audit programme, a formal statement of which of the standard’s controls apply, a management review with minutes, and an external audit. But it is a gap of formality, not a change of direction. For a fuller discussion, see the companion piece on ISO/IEC 42001 for small and non-technical organisations.

The Mauritian context, labelled correctly

Boards ask, reasonably, what they are actually obliged to do. The honest answer is that in Mauritius today, the binding obligations that touch AI use in a typical SME come almost entirely from the Data Protection Act 2017, with sector rules on top for licensed firms. The rest is guidance.

Legal requirement: the Data Protection Act 2017 applies to any organisation that processes personal data as a controller or processor. The provisions most relevant to AI use are section 21 (the principles relating to processing, including that personal data are “processed lawfully, fairly and in a transparent manner” and are accurate), section 22 (the controller’s duty to adopt policies and implement appropriate technical and organisational measures and to be able to demonstrate compliance), section 31 (security of processing), section 33 (the record of processing operations), section 34 (data protection impact assessment), section 36 (transfer of personal data outside Mauritius, relevant because most AI tools are hosted abroad) and section 38 (automated individual decision making). These section numbers were checked against the Act text linked in the Sources. Whether a given system triggers a given section is a question for the data protection contact and, where needed, legal advice.

Best practice: the FAIR Guidelines for the Development and Use of Artificial Intelligence, published by the Ministry of Information Technology, Communication and Innovation, are non-binding. The document states that the Guidelines “do not create legal obligations and do not replace existing laws or regulatory powers”. They are written for a broad set of actors: the text lists public sector institutions first, and also names “private sector organisations, including micro enterprises, SMEs, start-ups and large firms”, while noting that expectations should be applied proportionately. The Guidelines also state that they are intended to inform future procurement standards, contractual requirements and, where justified by risk, legislation. For an SME, the sensible reading is that FAIR describes the direction of travel and the vocabulary that public bodies and larger counterparties will use in their own requirements.

Best practice: the FSC’s Fintech Series Guidance Notes No. 4, Principles for the Responsible Use of Artificial Intelligence in Financial Services (September 2025), sets out nine principles described in the document as “non-binding”, and is addressed to FSC licensees in insurance, wealth management and non-banking financial institutions. It is not relevant to an unlicensed business, but a licensed one should read this framework alongside it.

Consultaix recommendation: build to the Act, borrow the structure from FAIR and ISO/IEC 42001, and treat sector guidance as an overlay for the firms it covers. That order reflects where the obligations actually sit.

A worked illustration: a 45-person distribution company

The following is a hypothetical illustration constructed for this article. It is not a client, and the systems, people and figures are invented to show how the framework applies.

Consider a Port Louis based importer and distributor of food and household products with 45 staff: a managing director, a finance manager, a sales manager with eight representatives, a warehouse and logistics team of twenty, a small customer service desk, an HR and administration officer, and an outsourced IT provider. The company has no compliance function. Its board is the managing director and two family shareholders.

An initial sweep produces a register of seven entries.

ID System and use Owner Personal data Decision role Affected parties Tier
AI-001 General-purpose chatbot used by sales and management for drafting proposals and emails Sales manager No (rule: no customer data pasted in) Assists Internal Low
AI-002 Demand forecasting feature in the inventory system, used to suggest reorder quantities Warehouse manager No Recommends, planner adjusts Internal, indirectly suppliers Medium
AI-003 Customer service chatbot on the website, answering delivery and product questions from an approved knowledge base Customer service lead Yes (names, order numbers) Recommends, escalates to human Customers Medium
AI-004 Route optimisation in the delivery app Logistics supervisor Yes (driver locations) Recommends, dispatcher can override Staff Medium
AI-005 CV screening feature in the recruitment portal, proposed for the next hiring round HR officer Yes (applicant data) Would rank and filter applicants Applicants High
AI-006 Automated credit limit suggestions in the accounting package for trade customers Finance manager Yes (sole trader customers are individuals) Recommends, finance manager decides Customers High
AI-007 Transcription and summary tool used for management meetings Managing director Yes (staff names, discussion) Assists Internal Low

The managing director takes the accountable executive role. The finance manager, who already holds the data protection designation, becomes the data protection contact and also the reviewer for systems she does not own. The HR officer is reviewer for AI-006, since the finance manager owns it.

The classification exercise produces three decisions. AI-005 is not approved in its proposed form: automated ranking and filtering of applicants would be a decision “based solely on automated processing” that significantly affects individuals, so the HR officer redesigns the process so that the tool sorts by stated criteria but every application is read by a person before any rejection, and applicants are told that software is used. The data protection contact records the reasoning, concludes that with human review of every outcome the section 38(1) right is respected, and considers separately whether the profiling involved is extensive enough to require a DPIA under section 34, recording her conclusion either way. AI-006 stays as a recommendation tool, with the finance manager confirming that every credit limit is decided by her and that the register says so. AI-003 needs its vendor terms checked for where transcripts are stored and whether they are used for model training, and a line is added to the website chatbot’s opening message saying that it is automated and how to reach a person.

The cadence is set. The warehouse manager and customer service lead check their Medium systems quarterly. The finance manager checks AI-006 monthly, and the HR officer checks AI-005 monthly during hiring rounds. The finance manager, as reviewer, reports to the managing director each quarter, and the managing director gives the two shareholders a one-page summary twice a year.

Total effort in the first quarter is roughly two days spread across five people, most of it in the initial sweep and the AI-005 redesign. Thereafter it is about an hour a month across the organisation. Nothing was bought. What the company now has is a register, a risk register, two recorded decisions with reasoning, and a rhythm. If a supermarket group later asks in a supplier questionnaire whether the company has AI governance aligned with recognised standards, the answer is yes, and the evidence exists.

Template: AI system register

Copy this into a spreadsheet. One row per system and use. Columns can be added; Consultaix recommends not removing any.

System ID System name Vendor / product Embedded in Business purpose Owner Users (roles, approx. number) Data categories used Personal data (Y/N) Special categories (Y/N) Decision role (assists / recommends / decides) Affected parties Risk tier Approved by Approval date Vendor terms location Data location / transfer outside Mauritius (Y/N) Inputs used for vendor training (Y/N/unknown) DPIA required (Y/N/not yet assessed) Last review Next review Status
AI-001
AI-002

Template: AI risk register

One row per identified risk. A system can have several risks; a risk can apply to several systems. Keep the scale simple: Low, Medium, High for both likelihood and impact, and let the reviewer challenge the ratings rather than argue about numbers.

Risk ID Linked system ID(s) Risk description (what could go wrong, for whom) Risk category (accuracy / privacy / bias / security / vendor dependency / legal / reputational) Likelihood (L/M/H) Impact (L/M/H) Existing controls Additional treatment required Treatment owner Due date Residual rating (L/M/H) Accepted by Date accepted Last reviewed Status (open / treated / accepted / closed)
R-001 AI-005 Applicants rejected on the basis of automated ranking without human review; section 38 right engaged; reputational harm Legal, bias
R-002 AI-003 Customer chatbot transcripts containing personal data stored outside Mauritius under vendor terms that permit training use Privacy, vendor dependency
R-003 AI-002 Forecasting feature over-orders perishable stock after a change in the vendor’s model; planner stops checking suggestions Accuracy

The three example rows are from the illustration above and should be deleted before use.

Where Consultaix fits

Consultaix’s AI Governance Advisory service builds this kind of proportionate framework with the organisation’s own people, informed by ISO/IEC 42001, the FAIR Guidelines and the Data Protection Act 2017, and keeps it at a size the organisation can actually run. Where the starting point is unclear, the AI Readiness Assessment scores governance alongside strategy, data, capability and execution, and places the organisation on the Consultaix AI Adoption Ladder so that the governance work matches the stage of adoption. The Fractional Advisor model suits organisations that want the quarterly reviewer role held by someone outside the business.

Sources