Most AI governance material is written for organizations with a risk function, a legal team, and someone whose job title contains the word “compliance”. A fifty-person company has none of those, and copying that material produces a document nobody reads and no control anybody applies.
Governance at this scale is not a framework. It is a small number of decisions about authority — who may use what, on which information, and who answers if it goes wrong — written down in a form that fits on a few pages and can actually be enforced.
This covers AI systems across the business: the tools finance, support, HR and sales are already using. Where the output is content you publish, the editorial side — ownership, disclosure, approved sources — is covered separately in AI content governance.
Start with an inventory, because you already have one
Before writing any policy, find out what is in use. In practically every organization that has not looked, the answer is more than leadership expected, and the gap between belief and reality is the single most useful finding.
Practical ways to build the list without a discovery tool:
- Expense and card statements — individual subscriptions are usually paid this way.
- Your identity provider's list of applications people have signed into with a work account.
- Browser extensions deployed on managed devices.
- Asking, without consequence attached. If the first response to disclosure is disciplinary, the inventory will be wrong.
Record for each: what it is, who uses it, what information goes into it, who pays, and whether anyone reviewed the terms. That table is the beginning of governance; several organizations find the exercise alone eliminates duplicate spend.
An approved list, and a route onto it
The list matters less than the route. A list with no way to add to it is bypassed within a month, and the bypassing is invisible.
A workable route for a smaller organization is one page and one owner: who to ask, what they will want to know (what it does, what data it needs, what it costs, who else has it), and how long an answer takes. If a decision takes three weeks, people will use the tool and ask afterwards.
Three states are enough — approved for stated uses, approved with conditions (say, no customer data), and not approved, with the reason recorded so it is not re-litigated quarterly.
Decide what data may go in
This is the rule people most need and most often lack. It works best expressed in the organization's own categories rather than abstract classifications:
- Freely usable — already public, or internal with no personal or commercial sensitivity.
- Approved tools only — internal business information, non-sensitive customer detail.
- Never — personal data of the kind you have obligations over, credentials, contract terms under NDA, anything a client contract prohibits sharing with subprocessors.
Two practical notes. Make it specific to your business — “no PHI” is meaningful in a clinic and useless in a print shop. And check your client contracts before writing the third category: it is common to find a confidentiality clause that already answers the question, and rather less common for anyone to have read it recently.
Access: AI inherits the permissions of whoever runs it
The most consequential technical point, and the least intuitive. An assistant connected to your document store can see everything the connecting account can see. Where permissions have accumulated over years — as they have almost everywhere — that is usually far more than anyone intends.
The practical consequence is that deploying an AI system over a shared drive is an access-control project first. Before connecting anything: review what the service account or the pilot users can actually reach, and tighten it. Organizations routinely discover at this point that everyone can read the payroll folder.
Prefer scoped, purpose-specific access over a broad connection, and prefer connections that respect existing per-user permissions over ones that index everything under a single privileged account.
Vendor review: five questions
You do not need a formal third-party risk programme. You need five answers, in writing, before approval:
- Is our data used to train their models? If yes, that is usually disqualifying for anything beyond the freely-usable category. Check the business terms, not the consumer ones.
- Where is data processed and retained, and for how long?
- Who are the subprocessors? The model provider behind the product is often a different company from the vendor.
- Is there a data processing agreement, and does it match what you actually need?
- What happens on exit? Can you get your data out and confirm deletion?
Keep the answers with the inventory entry. When a client or insurer asks — and increasingly they do — that file is the answer.
Human accountability
For each approved use, one line: who checks the output, before what, and to what standard. “Someone reviews it” is not a control.
The standard is the part usually left implicit and it is where the value sits. Reviewing a drafted email for tone is different from verifying that a figure in a client report is correct, and the second takes real time that has to be budgeted. Where the review is nominal — where a person is clicking approve on volumes they could not possibly check — the organization has accountability on paper and none in practice, which is a worse position than having neither.
Acceptable use, in one page
Staff need something short enough to read: which tools are approved, what may and may not be entered, when a human must check the output, and who to ask. Written as guidance rather than prohibition, because a policy that forbids everything useful gets ignored and drives use underground where you cannot see it.
Say plainly that people will not be penalised for asking. The organizations with the worst shadow-AI problems are usually the ones that announced a ban and did nothing else.
Where this usually breaks
Three failure patterns account for most of it, and each has a cheap remedy if caught early.
The policy nobody can apply. A document written from a template, full of terms like “appropriate safeguards” and “proportionate oversight”, which tells an account handler nothing about whether they may paste a client email into a summarising tool. The test is whether someone can read it once and answer a real question. If not, it is decoration.
Governance owned by nobody, or by everybody. Where responsibility sits with “the leadership team”, no decision gets made, because there is no single person a request can be sent to. One name, with a deputy, is worth more than a committee.
Rules that outran the business. An organization writes a serious framework in a burst of enthusiasm, nobody has time to maintain it, and within a year the inventory is stale and the approved list names two products that were replaced. Stale governance is more dangerous than none, because it produces confident answers that are no longer true.
What to do in the first month
If none of this exists yet, the order that works is deliberately unambitious:
- Week one. Build the inventory. Do not write any policy yet — you do not know what you are governing.
- Week two. Name the owner, and agree the three data categories with whoever understands your client obligations.
- Week three. Write the one-page acceptable-use note and the approval route. Circulate both, and say explicitly that nobody is in trouble for what the inventory found.
- Week four. Review the vendor terms for whatever is already handling real business data, and tighten the access on anything connected to a shared document store.
That is the whole of it at this scale. Everything beyond it — formal risk registers, model cards, assurance programmes — is work a larger organization does because it has obligations and staff that you do not.
The one area to treat differently
Most AI use in a smaller business is low-stakes and the controls above are proportionate. Two categories are not, and are worth naming so they do not get swept into the general policy.
Anything touching employment decisions — screening applicants, ranking candidates, scoring performance, scheduling in ways that affect pay. Several jurisdictions now regulate automated decision-making in employment specifically, obligations attach whether or not you built the tool, and an applicant is far more likely than a customer to ask how a decision was reached. The safe default for an organization without legal support is that these tools are not approved.
Anything that scores or profiles a customer — creditworthiness, eligibility, risk pricing. Same reasoning: the decision has to be explicable, and “the system suggested it” is not an explanation that survives a complaint.
Neither is a prohibition on using AI in HR or customer operations generally. Drafting a job advertisement and screening applicants are very different acts, and the policy should say which is which.
What an auditor, insurer, or client will ask for
Increasingly this arrives as a questionnaire, and the answers are the same handful of artifacts:
- The inventory — what AI systems are in use and for what.
- The approved list and the approval route.
- The data rules.
- Evidence of vendor review for anything touching regulated or client data.
- Who is accountable, by name.
- Evidence the arrangement is reviewed.
None requires a platform. All of them are documents, and an organization that has them can answer in an afternoon rather than a fortnight.
Review, and keep it proportionate
Twice a year is enough for most smaller organizations, plus a review whenever a new tool is approved or a vendor materially changes its terms. The review asks three things: is the inventory still accurate, has anything changed in the vendors' terms, and has anything gone wrong that the rules did not anticipate.
Finally, the thing worth saying explicitly: a forty-person business should not build an AI ethics committee, adopt a formal risk taxonomy, or attempt certification against a management standard because a much larger organization does. The appropriate artifact set is an inventory, a one-page policy, a short approval route, and a named owner. If governance takes more than a couple of days a year to maintain at this scale, it has been over-built, and over-built governance decays faster than none because nobody can sustain it.
The risk appetite these controls implement is a leadership decision, covered in setting an AI strategy; the point in an adoption sequence at which governance has to be settled is covered in the practical sequence for adopting AI.
Need to establish AI governance without building a bureaucracy? Schedule an AI & Technology Readiness Assessment — governance is one of the dimensions it reviews — or read more about our Virtual CIO and IT consulting services.