AI governance is the set of rules, named owners and records that decide which AI systems your company uses, for what, and who answers for each. An AI governance framework is how you make that routine. For a company of 50 to 750 people, it does not need an ethics board or a 60 page policy. It needs eight working parts, and most of them fit in a spreadsheet and a calendar.
This is the version we recommend to mid-sized companies. Think software firms, manufacturers, healthcare and financial businesses that use AI in a dozen places and build it in one or two. It assumes you have a CTO or head of engineering, someone who handles data protection, and no appetite for bureaucracy.
What AI governance is, and what it is not
Governance answers three questions on demand. What AI do we run, and where. Who is accountable for each system. How do we know it still behaves the way we approved. If you can answer those in ten minutes, you have governance. If the answer lives in a policy PDF nobody has opened since it was signed, you do not.
It is not the same as AI ethics, which is about values. It is not the same as compliance either, which is about specific legal duties. Governance is the operating layer underneath both. When the EU AI Act asks you to classify a system, or a customer's procurement team asks how you control model changes, governance is where the answer comes from.
It also covers AI you did not build. Meeting transcription, the assistant inside your CRM, the copilot in your office suite, the chatbot an agency added to your website. In the companies we work with, these bought features usually outnumber the systems engineering built.
The framework on one page
Large company frameworks assume a chief AI officer, a risk function and a standing committee. At 50 to 750 people, the same three or four people end up doing all of it. So the framework has to be small enough that they actually keep it current. A framework nobody maintains is worse than none, because it gives management a comfort the facts do not support.
The 750 figure is not arbitrary. The Digital Omnibus on AI entered into force on 27 July 2026. It gave small mid-caps, under 750 employees and up to €150 million turnover, relief alongside SMEs. That relief covers simplified technical documentation, proportionate quality management and priority access to regulatory sandboxes. It mostly matters if you provide a high-risk system. The signal still applies to everyone else: govern in proportion to your size, not in imitation of a bank.
| Component | What it is | Minimum version | Who owns it |
|---|---|---|---|
| AI use register | A list of every AI system and AI feature in use, built or bought | A shared spreadsheet, one row per system, updated whenever something changes | CTO or head of engineering |
| Named owners | One accountable person per system | A name in the register, never a team or a committee | The business lead whose process the system serves |
| Risk classification | The EU AI Act tier plus your own impact rating | A paragraph of written reasoning per system | The owner drafts it, the DPO or counsel confirms borderline cases |
| Approval step | A gate before any new AI use goes live | A one page request and a 30 minute review for anything above green | A review group of two or three people |
| Vendor and data rules | Which data classes may go to which tools and providers | An allow list, a signed DPA per vendor, an EU region where one exists | DPO or security lead |
| Logging and evaluation | A record of what each system did, and a test that it still works | Inputs, outputs, model and prompt versions logged; an eval set run on every change | The engineering lead for each system |
| Incident handling | What counts as an AI incident, and who acts on it | AI cases added to your existing incident process, plus a kill switch per feature | Whoever owns incident response today |
| Review cadence | Scheduled re-checks of the whole set | Register review each quarter, framework review once a year | CTO, reporting to management |
Everything in the heavyweight frameworks is an elaboration of these eight. Start here, and add depth only where a regulator, a customer or your own risk appetite asks for it.
Start with the register and the owners
The register is the backbone. Classification, approvals, reviews and incidents all point at a row in it. Keep it boring: a spreadsheet, or a table in the tool you already use for internal documentation. A dedicated governance platform can come later, if ever. These columns are enough for most companies:
- System name and one sentence on what it does.
- Owner, by name.
- Built or bought, plus the vendor and the model behind it.
- Who uses it: staff, customers, or the public.
- What data it touches, and whether that includes personal or special category data.
- Where processing happens: EU region, another region, or your own infrastructure.
- Risk tier, with a link to the classification reasoning.
- Date approved and date last reviewed.
- Logging and eval status: yes, partial or no.
To find the bought systems, ask finance which AI subscriptions are being paid for. Then ask IT which AI features are switched on inside tools you already license. Expect the first version to be longer than anyone predicted.
Owners matter more than the format. An owner is one person who knows what the system does, signs off changes to it, and can answer an auditor's or a customer's question without escalating. Committees do not own things. When a system has three owners, nobody notices that its vendor swapped the underlying model last month.
Risk classification and a light approval step
Classify the use case, not the model. The same language model is minimal risk when it summarizes internal meeting notes and high risk when it ranks job applicants. That is how the EU AI Act works, and it is a sensible way to run your own risk thinking too.
Use two lenses. The first is the AI Act tier: prohibited, high risk, limited risk with transparency duties, or minimal. Most business software, such as internal copilots, document search and support assistants, lands in limited or minimal. High risk covers the areas listed in Annex III, including employment, education, credit scoring, biometrics and critical infrastructure. Those obligations now apply from 2 December 2027. The second lens is your own impact rating. Does the system touch customers, personal data, money, or decisions about people?
Then route new requests by color, so the approval step costs minutes in most cases:
- 01Green: an approved tool, no personal data, internal use only. The requester adds a row to the register, and that is the approval.
- 02Amber: personal data, customer-facing output, or a new vendor. A 30 minute review with the owner, the DPO or security lead, and one engineer.
- 03Red: anything near an Annex III area, or anything that makes or shapes a decision about a person. A full review, a written classification, and sign-off from counsel before it goes live.
Vendor rules, data rules, logs and evals
Most AI risk in a mid-sized company arrives through vendors, so the vendor rules do a lot of work. Define your data classes: public, internal, confidential, personal and special category. For each class, list which tools and providers may receive it. Then hold every AI vendor to the same minimum: a signed data processing agreement, an EU region where one exists, no training on your data, and a published sub-processor list.
Logging and evaluation are where governance stops being paperwork and becomes engineering. For every system you built, log the input, the output, the model version, the prompt version, the user, and what anyone did with the result. Pin model versions. A provider updating the model behind an alias changes your system's behavior without a deploy on your side.
Evaluation is the other half: a fixed set of test cases, scored automatically, run on every prompt or model change. Our rule here is blunt. An AI feature in production without an eval suite is a demo. The eval suite is also the only honest answer when someone asks whether the system still works the way it did on the day you approved it.
For bought tools you cannot log the internals. You can still keep the vendor's documentation, switch on whatever audit log the product offers, and record which AI features are enabled for which teams.
Incidents and the review cadence
Define an AI incident before you have one. A workable list: a wrong output that reached a customer or drove a decision, personal data sent somewhere your rules do not allow, harmful or discriminatory output, a successful prompt injection, and an unexplained cost spike. Add these to the incident process you already run rather than building a parallel one. If you are in scope of NIS2 or DORA, an AI failure can be a reportable incident like any other. It needs the same clock and the same people.
Every system you built should have a kill switch: a flag that turns the AI feature off and falls back to the manual process. Test it once. A switch nobody has ever flipped tends to fail on the day you need it.
Review on a schedule and on triggers. Each quarter, spend an hour on the register. Is every row current, does every system still have an owner, did any vendor change its terms or its models? Re-review a single system whenever its vendor, model, data or purpose changes. Once a year, check the framework itself against what the business now does with AI, and give management a one page summary.
NIST AI RMF and ISO/IEC 42001: when you need the heavyweight version
Two frameworks come up in every conversation about AI governance. Both are good. Neither is where a company of 200 people should start.
The NIST AI Risk Management Framework (AI RMF 1.0) was released in January 2023 and is voluntary. It organizes the work into four functions: Govern, Map, Measure and Manage. NIST added a Generative AI Profile in July 2024 and has said the framework is being revised. It is free and well written, and it works best as a checklist to borrow from. The eight components above map onto it cleanly. Owners and reviews are Govern, the register and classification are Map, logs and evals are Measure, and incidents and vendor controls sit mostly under Manage.
ISO/IEC 42001, published in December 2023, specifies an AI management system. It is certifiable, and it follows the same management system structure as ISO 27001, so a company that already holds 27001 will recognize the shape. Certification means a real investment of internal time plus an external audit, and it has to be maintained.
You probably need 42001 in three cases. Enterprise or public sector customers ask for it in procurement. AI is the product you sell, not a tool you use. Or you already run ISO 27001, so the extra step is smaller. You probably do not need it when you use AI internally in a handful of places and nobody is asking. A 42001 certificate also does not, by itself, make you compliant with the EU AI Act. It shows you run a management system. The Act asks about specific systems and how they are used.
If certification does become a sales requirement, the eight components give you a head start. They do not give you a finished certification.
What to do in the first 30 days
- 01Week one: build the register. Ask engineering, finance and IT. Accept that it will be incomplete.
- 02Week two: name an owner for every row, and classify each system with a paragraph of reasoning.
- 03Week three: write the data class rules and the vendor minimum, then check existing vendors against them.
- 04Week four: confirm logging and a kill switch exist for every system you built, agree the approval routes, and book the first quarterly review.
That is a month of part-time work for two or three people, not a program. Logging, version pinning and evaluation are the parts teams postpone. They are also the parts you cannot reconstruct later, because last quarter's outputs are gone if nobody recorded them.
If you want an outside view, the EU AI Act classification and GDPR position for your use cases are part of our AI readiness assessment. A five day review covers a single AI feature already in production. We also build the logging and eval pieces ourselves, which is the point of taking advice from people who build.