AI governance for small teams without a compliance function
Most published AI governance guidance is written for organisations with a risk function, a data protection officer and an internal audit team, and applying it at thirty people produces either paralysis or a document written to be ignored. The great majority of it can be skipped, and saying which parts is more useful than adding another framework. What cannot be skipped is small: a list, an owner, a gate and a route for complaints. That is achievable in a week and it is genuinely most of the value.
What can a small team safely skip?
Almost all of the apparatus. You do not need an AI ethics board, a principles charter, a maturity assessment, a certification programme, a tiering scheme with five levels, a separate AI risk register, or a quarterly governance forum. Each of these exists to coordinate people who do not otherwise speak to each other, and in a small organisation they already do. Installing coordination machinery where coordination is not the problem produces overhead and no control.
You can also skip the formal impact assessment template for anything that does not touch personal data or affect a person's access to something. Using a model to draft copy, summarise notes, generate images for internal use or write code needs an acceptable use rule and nothing more. Applying an assessment process to those uses trains everyone to treat the process as a formality, which is exactly what you cannot afford when a use case arrives that genuinely needs it.
What you cannot skip is anything that scales with the consequence of the decision rather than with the size of the organisation. A ten-person company running automated candidate screening carries the same obligations as a large one, and regulators have shown no inclination to treat headcount as a defence. Small does not mean lower risk. It means fewer things at risk, which is a different and much more manageable proposition.
What is the irreducible minimum?
Four things. A list of every AI system in use with a named owner. One person accountable for AI decisions, with the authority to stop a deployment. A gate: a short written check that anything touching personal data or affecting a person must pass before it goes live. And a route by which an affected person, or an employee, can raise a problem and get a human answer.
The list is the foundation and it takes an afternoon at this size. Pull the card statements and the identity provider application list, ask each team lead what they use, and write it down with two columns: what it does, and whether it affects a person. That last column is the entire risk classification you need until you have dozens of systems, and adding tiers before then costs more in argument than it saves in judgement.
The gate is the part that fails without deliberate placement. It has to sit in a workflow that already exists, which in a small team usually means the moment before something is shown to customers or connected to production data. Write the check as five questions on one page, and require a name and a date on it. If it lives anywhere other than a step people already take, it will be skipped, and everybody will be sincerely surprised.
What does the whole thing look like on two pages?
Five short artefacts, none of which needs external help to draft. Together they take a working week to produce for an organisation with a handful of AI uses, and they will answer the substantial majority of what a customer, an insurer or a regulator asks for.
| Artefact | Contains | First draft | Update trigger |
|---|---|---|---|
| AI register | System, purpose, owner, supplier and version, data sent, affects people yes or no | An afternoon | New tool, tool retired, quarterly verification |
| Acceptable use rule | What may be pasted into which tools, what may never be, and the approved list | One page, one hour | New tool approved, or an incident |
| Pre-launch check | Five questions covering purpose, personal data, who is affected, testing, fallback | One page | When a question turns out not to have caught something |
| Supplier note per AI vendor | Model behind it, training and retention terms, notice of change, exit terms | Half a day per supplier | Renewal, or supplier announcement |
| Incident and complaint route | Who is told, how fast, who can stop the system, how an affected person reaches a human | Half a page | After any incident, without exception |
Do you need an AI governance tool?
Not until the register stops fitting comfortably in one view, which for most organisations means somewhere past thirty or forty systems. Governance platforms are good at evidence collection, control mapping across multiple frameworks, and producing reports for auditors. If you have no auditor and no second framework, you are buying a filing system for records you could keep in a shared spreadsheet, and paying for it in licence cost and in the effort of keeping a tool populated.
There are two situations where tooling earns its place earlier. The first is when you are answering the same questionnaire repeatedly for enterprise customers and the reuse saves real time. The second is when evidence has to be collected automatically from systems rather than typed in by a person, because manual evidence collection is the thing that reliably lapses.
The tooling that does pay off early is technical rather than administrative: version control for prompts and configuration, logging of inputs, outputs and model versions with a retention period long enough to reconstruct a decision, and a scheduled run of a small evaluation set. Those three cost engineering days rather than licence fees, and unlike a governance platform they change what you can actually do when something goes wrong.
What about staff using AI tools on their own?
This is the largest real exposure at small scale, and it is not solved by prohibition. Blocking tools moves the usage to personal devices where you have neither visibility nor recourse, and the employees most likely to route around a block are the ones doing the most valuable work. The workable approach is to make the sanctioned route faster than the unsanctioned one.
Concretely: provide a paid account on one general assistant with business terms, so that the default option is one where inputs are not used for training and the terms are known. Publish a short list of what must never be pasted anywhere, phrased in terms of specific data rather than categories, since instructions to protect confidential information are interpreted charitably by people in a hurry. And run a same-day approval route for new tools, staffed by one named person, so that asking is genuinely easier than not asking.
Then check the result rather than assuming it. Egress logs or the identity provider list will tell you within an hour whether the sanctioned tool is the one being used. If it is not, the problem is with the sanctioned tool or the approval route, not with the staff, and the policy response will fail for the same reason it failed the first time.
When do you need more than this?
Five triggers, and each one is specific enough to watch for. You start making or materially influencing decisions about people, in hiring, credit, insurance, education, housing or access to a service. You begin selling an AI feature under your own name rather than deploying someone else's, which changes your legal role and brings a much heavier set of obligations. You enter a regulated sector, or your customers do and pass their obligations down the contract.
The fourth trigger is scale of a particular kind: the number of people affected by an automated decision grows past the point where you could review them individually if something went wrong. That threshold matters more than revenue or headcount, because it is the point at which an undetected error stops being recoverable by hand.
The fifth is your first incident, which will teach you more about what your governance is missing than any assessment. Treat the review afterwards as the main deliverable rather than the fix, and change exactly the things the incident showed to be absent. Governance built that way is invariably smaller, better targeted and more likely to be followed than governance assembled in advance from a framework, and it has the considerable advantage of being demonstrably about a real problem.
Common questions
- Does a small company need AI governance?
- It needs the parts that scale with consequence rather than with organisation size. A list of AI systems with named owners, one accountable person able to stop a deployment, a short pre-launch check for anything touching personal data or affecting people, and a route for complaints to reach a human. Ethics boards, maturity assessments, multi-tier classification schemes and quarterly governance forums exist to coordinate people who do not otherwise talk, and are overhead in a small team.
- What is the minimum viable AI governance?
- Four controls. An AI register listing every system, its purpose, its owner, the supplier and version, what data is sent to it, and whether it affects people. One named accountable person with authority to stop a launch. A written gate placed inside a workflow people already follow, before anything touches production data or customers. And a complaint route where an affected person can reach a human. This is achievable in a week for most small organisations.
- Do you need an AI governance platform?
- Rarely before the register outgrows a single view, which for most organisations is somewhere past thirty or forty systems. Platforms are good at evidence collection, mapping controls across multiple frameworks, and producing auditor reports. Without an auditor or a second framework, that is a paid filing system. Version control for prompts, logging of inputs, outputs and model versions, and a scheduled evaluation run deliver more for less and cost engineering time rather than licence fees.
- How should a small company handle staff using AI tools?
- Make the sanctioned route faster than the unsanctioned one, because blocking tools moves usage to personal devices where there is no visibility. Provide a paid account on one general assistant with business terms so the default option has known handling of inputs. Publish a short list of specific data that must never be pasted anywhere. Run a same-day approval route for new tools with one named owner. Then check egress or sign-in logs to see whether it worked.
- When does a small organisation need more formal AI governance?
- On five triggers: it starts making or influencing decisions about people in hiring, credit, insurance, education, housing or service access; it begins selling an AI feature under its own name, which changes its legal role; it enters a regulated sector or inherits obligations through customer contracts; the number of people affected by automated decisions exceeds what could be reviewed by hand if something went wrong; or it has its first incident.
- Are small companies exempt from AI regulation?
- No. Obligations follow the use case rather than organisational size, so a ten-person company running automated candidate screening carries substantively the same duties as a large one. Some regimes reduce financial penalties for small and medium enterprises and offer simplified documentation routes, but they do not remove the underlying requirements. Being small means fewer systems in scope, not lower obligations for the systems that are.
