Search for an AI governance framework and most of what comes back was written for a bank or a government department: committees, risk taxonomies, model inventories and a long document to approve before anything else happens. A business of 50 to 500 people needs the same thinking at a fraction of the weight, because the people who would run it also run everything else.
What follows is how we set one up at that size. It has six parts, each small, and each one already has an article of its own in this Briefing.
The six parts
1. Someone owns it
One named person owns AI governance, usually whoever already owns operations or risk, working with whoever runs IT and whoever leads on data protection. They decide what gets approved, they own the policy and its review date, and they report to the leadership team monthly for the first six months and quarterly after that.
2. Written rules
The business needs an AI policy that records the decisions, and a one-page acceptable use section that turns them into what a person may do. What an AI policy should contain sets out the first and AI acceptable use policy the second. Because your leadership makes the decisions in them in one sitting, whoever writes the documents up is recording a position already agreed.
3. A register
The register is a single list of every AI tool in use: what it is for, the account type, the owner, the vendor's terms on training and retention, and who approved it and when. It is the document most other questions are answered from, including most of a client's security questionnaire.
4. Controls that make the rules true
Each rule needs a control behind it, and four controls do most of the work:
- Sign-in to approved tools through your company identity, so personal accounts are not the easy option.
- A restriction on which outside apps people can connect to their work accounts.
- A permissions review before any tool is connected to your files.
- A named point at which a person reviews output before it leaves.
AI and data protection adds the checks for personal data.
5. People who know the rules
People get short, role-based training on the tools they use and the rules they work to, and it is refreshed whenever either changes. AI literacy sets out what each group needs, and the first month with Copilot shows what it looks like on the work your people already do.
6. Evidence and review
This part is a record of what was approved and why, and a route for reporting incidents that people know and use. Alongside them sit a test of each new use against how the work was done before, and a review date that gets kept. Someone pasted client data into ChatGPT covers the incident route, and why AI pilots stall covers the before-and-after that tells you whether a use is worth keeping.
What changes between 50 and 500
The six parts stay the same at both sizes, but each one gets heavier as the business grows.
| At around 50 people | At around 500 | |
|---|---|---|
| Owner | One person spending a few hours a month | Leads a small group that includes IT, data protection and someone from the teams using the tools |
| Register | A spreadsheet rather than a governance platform | Feeds the asset and supplier records of an ISO 27001 system, if you run one |
| Approvals | An email to the owner | A written test and a record of each decision |
| Training and assessments | An hour with the acceptable use page | Impact assessments routine for anything touching personal data at scale |
Somewhere in between, most businesses find that the owner needs that group to share the decisions, and that is the moment to form it.
How it maps to the frameworks clients name
When a client asks which framework you follow, it helps to say how yours lines up with the ones they know. The NIST AI Risk Management Framework sets the work out as four functions, Govern, Map, Measure and Manage, and NIST has published a profile of it for generative AI. Ownership and written rules sit under Govern, the register under Map, the before-and-after tests under Measure, and the controls and incident route under Manage.
| Part of the framework | NIST function |
|---|---|
| Ownership and written rules | Govern |
| A register | Map |
| The before-and-after tests | Measure |
| Controls and the incident route | Manage |
The NIST framework for a business of your size goes through it function by function. ISO 42001 covers the same ground as a certifiable management system, and ISO 27001 covers the information security half of it.
Using those frameworks as a reference is sensible. Adopting one wholesale at 50 people usually produces a document too long for anyone to follow, so take the structure from it and keep your own version short.
A first 90 days
This is the order we run it in, because each step builds on the one before.
- Weeks one and two: find out what is already in use, on which accounts, reaching what, and name the owner.
- Weeks three and four: leadership settles the decisions in one half-day, and the policy, the acceptable use page and the first version of the register follow.
- Weeks five to eight: company sign-in for approved tools, outside app connections restricted, the permissions review for a first team, and that team trained on their own work.
- Weeks nine to twelve: test the first team's work against the before, record what was learned and decide what widens next and what gets tidied first.
At the end of it you hold a framework in daily use, with evidence for each part, which is what a client, an insurer or an auditor will ask to see.
Where this fits
Those 90 days follow the order Track runs in: the readiness snapshot and Govern first, then Adopt with your first team. How long each step takes depends on your business, and how this is scoped explains what is fixed and what is quoted. After that, keeping the framework current, from the register to the review dates, is the governing part of Trackside.