AI governance for a small business should answer simple operational questions: what is being used, for which purpose, with which data, under whose authority and what happens when it fails.
The goal is not to copy a bank's committee structure. It is to make every AI use case visible, owned, testable, reversible and reviewable.
Start with one AI use-case register
NIST AI RMF Core organises risk work through Govern, Map, Measure and Manage. A register gives those functions a concrete object.
- business purpose and intended users;
- named business and technical owners;
- model, vendor, version and connected tools;
- data sources and sensitivity;
- outputs, external actions and affected people;
- risk tier, approval status and review date;
- tests, incidents, limitations and retirement plan.
Name an owner who can stop the system
Every use case needs a business owner accountable for its purpose and consequences, plus a technical owner for architecture, access, monitoring and change.
The owner must be able to pause the workflow, revoke access, accept a residual risk or retire the use case. A contact who only forwards incidents is not an owner.
The ICO governance toolkit recommends designated senior, technical and operational responsibilities and management sign-off for AI risks.
Publish a short acceptable-use and data policy
Employees need clear examples, not a vague instruction to use AI responsibly. State which products are approved, which accounts to use, which data classes are allowed and which actions require review.
Connect the policy to a practical company data protection architecture: classification, minimum context, role-based access, retention and deletion.
Provide an exception path. Otherwise people will either block useful work or bypass the policy silently.
Check vendors and contracts before sensitive use
Record the exact service and tier, processing location, retention, training use, deletion, security controls, sub-processors, incident notice, portability, termination and responsibility split.
Review connected plugins and data sources separately from the base model. The complete system includes identity, storage, retrieval, observability and every tool that can create a side effect.
A vendor questionnaire is evidence collection, not automatic approval. Compare the answers with the intended data and consequence.
Assign a risk tier and launch gate
For high-impact workflows, define meaningful human oversight before the consequence, not after it.
- Low: internal assistance, no sensitive data, no external action.
- Moderate: business records or customer communication, reversible changes.
- High: sensitive data, significant decisions, money, safety, rights or irreversible actions.
Require evidence before production
Each use case needs acceptance criteria and a representative test set. Measure task success, unsupported claims, unsafe refusals, data leakage, cross-tenant access, tool errors, latency, cost and human corrections where relevant.
Include adversarial and failure cases. Averages can hide a severe but rare path.
The NIST AI RMF Playbook offers suggested actions for the framework outcomes; it is a resource to adapt, not a universal checklist that every small company must copy in full.
Control prompts, models, data and tools as changes
A model upgrade, system-prompt edit, new retrieval source, permission change or added connector can alter the risk even when the interface looks identical.
Version these components, record who approved the change, rerun relevant tests and preserve a rollback. Emergency fixes still need a retrospective review.
Define a reapproval trigger for material changes instead of waiting for the next annual policy meeting.
Build security boundaries outside the prompt
Use least-privilege service accounts, deterministic authorisation, schemas, output validation, rate limits, network restrictions and human approval for privileged actions.
Treat direct and indirect prompt injection as architecture risks. A system prompt can guide behaviour but cannot replace access control.
Keep an audit trail of tool calls and approvals without turning general logs into a permanent copy of sensitive payloads.
Prepare incident, appeal and retirement procedures
Define who receives an alert, which connector can be disabled, how queued actions stop, which credentials are revoked, what evidence is retained and who communicates with affected parties.
Where AI contributes to a consequential decision, provide correction and appeal routes. Record the final human decision and its evidence.
Retirement is part of governance. Remove credentials, scheduled jobs, indexes, stored files, vendor access and documentation references when a use case ends.
Run a short recurring review
A quarterly review may be sufficient for stable, low-risk use cases; high-risk or rapidly changing systems need a cadence based on actual risk. Review incidents, overrides, test drift, vendor changes, cost and unused access.
The ICO AI and data protection risk toolkit provides practical support for identifying risks to individuals. Legal duties vary by jurisdiction and sector.
The EU AI Act is one legal framework that may apply depending on the system, role and market. Governance should map relevant law, not make a generic compliance claim.
How I keep the publishing workflow governed
The blog automation uses one Trello card per article as its operational register. The card records the topic, owner-facing status, slug, language URLs, image, sources, internal links, API identifier and factual checklist result.
The workflow moves through backlog, active work, review and published states. A public release requires explicit approval for the article or batch, and the same pages are checked again after publication.
This is lightweight governance: no committee, but there is visibility, ownership, evidence, change history and a defined response when a check fails.
Questions and answers
Does a small business need an AI committee?
Usually not for every decision. It needs named owners, a register, risk-based approval and access to privacy, security or legal expertise when the use case requires it.
Should employee experiments be registered?
Define a low-friction experimental route. Experiments with only public or synthetic data may use lighter controls, but sensitive data and external actions should not bypass review.
How many risk tiers are enough?
Three are often operationally useful: low, moderate and high. The labels matter less than clear criteria and mandatory controls for each tier.
When must an AI use case be reassessed?
After material changes to model, prompt, data, tool permissions, purpose, users, scale, law, vendor terms or observed failures.
What is the minimum first week deliverable?
Create the register, list current tools, name owners, block prohibited data, identify high-impact actions and set an incident contact and kill switch.