Free tools · 7 minutes · Last reviewed 24 August 2026
AI governance framework builder: who decides, who owns it, what gets checked
An AI governance framework is the written answer to four questions: who decides what AI gets used, who owns each category of information going into and out of the tools, what has to be approved before it happens, and what gets reviewed and how often. At a 20 to 50 person company that is about a page and a half, not a compliance programme. Answer eight questions here and this assembles one from ten blocks, sized to your headcount, your industry and whether your tools draft or act. The result appears as plain text on this page, ready to copy. No email, no sign-up.
Every block below is printed in full, with the reasoning, before you answer anything. Read the default framework, disagree with it, and use the builder only if you want the tailored version.
Written and last reviewed on 24 August 2026 by Ashutosh Upadhyay, founder of Cognio Labs. No lawyer has reviewed this and it is not legal advice. Have your own counsel read it before you adopt it, particularly the vendor, logging and escalation blocks and anything touching personal data.
Build your framework
Eight questions: headcount, industry, whether your tools draft or act, how many people can approve spend, whether anyone owns data today, EU or UK personal data, customer data exposure, and who is asking you to report. Answer for the company you have, not the one on the org chart.
8 questions · plain text on the page · no email · nothing leaves your browser
What an AI governance framework is at 20 to 50 people
Strip the word governance out and the job is simple. Someone decides what gets switched on. Someone owns each pile of information that goes out or comes in. Some actions need a person to press the button. Some things get logged and read. That is the whole framework, and at your size it fits on a page and a half.
Nobody we talk to uses the phrase. Founders and ops leads say AI policy, guardrails, shadow AI, who approves this, can we roll this out. They search for governance because that is what the results are labelled. So the document you write should say the plain thing: this is who decides, this is who owns it, this is what gets checked.
The test of a framework is not its length. It is whether every name in it is a person who knows their name is in it.
Why the search results are glossaries instead of frameworks
When we checked the top results for this term in August 2026, eight of the first nine were vendor explainer pages — what governance means, why it matters, a diagram with four pillars. One was an actual artifact you could use. Google's own People Also Ask box on that search asks where to find a template for an AI governance framework, which is a fairly direct signal that the pages ranking are not answering the question being asked.
So this page is the artifact rather than the definition. The full default text sits below, in HTML, before the builder is touched.
The part people get wrong: nobody owns the boundary
The only time a client has asked us to build this from scratch, the trigger was not a clever attack or a model behaving strangely. An employee had access to something they should not have had. That led to something being published that was a problem. Access at the boundary first, publication second.
What was missing was not a rule. It was a name. There has to be a named stakeholder for each piece of information going out of the platform and each piece coming in — customer records, anything published under the company name, code and credentials, financial data, and the standing connections that somebody wired up months ago and nobody has looked at since. Almost every framework we read sets rules for what people may do and leaves the boundary unowned. Nothing gets checked there, because checking is nobody's job.
That is Block 3 below. If you take one thing from this page, take the table and fill in the names.
We are not attaching numbers to that story, because we do not have numbers we can publish. It is first-hand observation from our own client work, anonymised, not research.
The eight questions, and what each one changes
Nothing is scored and nothing is sent anywhere. Each answer switches specific paragraphs on inside specific blocks.
- How many people work here?
Sets the weight of the whole document. Under 50 people, a framework with a committee in it becomes a file nobody opens, so the builder keeps one decision-maker, one deputy and about a page and a half. Over 200 it stops trying to be short.
Options: Fewer than 20 · 20 to 50 · 50 to 200 · More than 200
- Are you in a regulated or contract-bound industry?
Pushes whole categories of work up a tier and forces the person who holds the regulatory or contract relationship into the decision-rights block by name, instead of leaving them to find out later.
Options: No — general commercial work · Healthcare or health data · Financial services · Legal, accounting or another privileged profession · Public sector, education or anything with a tender process
- Do your AI tools draft, or do they take actions?
Decides whether the approval and logging blocks are two lines or the longest part of the document. Drafting-only companies do not need per-action approval; anything that writes to a system or sends outward does.
Options: Drafting only — a human sends everything · Mostly drafting, plus automations that write into our systems · They send email, update records, move files or money
- How many people can approve spend on a new tool today?
Sets the spend block and the shape of decision rights. If anyone with a company card can switch on a subscription, the framework starts with a ceiling and an alert rather than with principles.
Options: One person · Two or three · Every department head · Anyone with a company card
- Does anyone own your data today?
Decides whether the named-owners block is presented as a review or as the first job. If nobody owns data now, that table is the only part of the framework worth doing in week one.
Options: No — nobody owns it · Informally, one person everyone asks · Yes, a named owner with it in writing · A team owns it, no individual named
- Do you hold personal data about people in the EU or UK?
Adds the written-processing-contract gate to vendor review, a longer retention line to logging, and the 72-hour clock to escalation. Skipping it because you are not an EU company is the common error.
Options: No · Yes · Not sure
- Does customer data reach the AI tools?
Moves work between tiers and adds rows to the information-in-and-out table. Support tickets and email threads count, which is where most companies discover the answer is yes.
Options: No — internal and public material only · Sometimes, by accident — tickets, email threads, call notes · Yes, deliberately. It is the point.
- Is anyone asking you to report on this?
Adds a one-page reporting extract at the end — tiers, owners, incidents since the last meeting, spend — so the framework produces the answer instead of a scramble the week before the meeting.
Options: No — this is for us · Investors have asked · We report to a board · Customers send us security questionnaires
The ten blocks, in full, with the reasoning
This is the default framework as it stands before you answer anything: every block, its base text, why it is written that way, and the conditions that add to it. Square brackets mark the decisions only you can make.
1. Decision rights: who says yes to AI
Why this block is written this way: Most frameworks open with principles. Principles do not answer the question that actually arrives on a Tuesday, which is whether the sales lead can plug the CRM into a tool she found. Name the person who answers that, give them a deadline, and write down the short list of things nobody else can do. A slow no is what pushes people onto personal accounts, so the response time is part of the rule, not a nicety.
One named person decides what AI tools and AI-driven work get switched on here: [NAME, ROLE]. Their deputy, for when they are away, is [NAME, ROLE]. Anyone can propose a tool or an automation. Proposals go to [NAME] in [#channel or inbox] and get an answer within [2] working days. If the answer is no, it comes with a reason and, where possible, an approved alternative. Four things nobody else can do without [NAME]: sign an AI vendor contract, connect a company system to an outside model, point an automation at a customer-facing channel, or give a tool standing access to a shared drive or knowledge base. Tier 1 work (Block 2) is approved by [NAME] alone. Tier 2 needs [NAME] plus the owner of the information involved. Tier 3 needs [NAME] plus [SECOND NAME, ROLE].
What gets added, and when
- Fewer than 20 people: At this size there is one approver and one deputy, and no standing meeting. The deputy exists so that a two-week holiday does not create a fortnight of shadow tool adoption.
- 50 people or more: Add one named contact per department who screens proposals before they reach [NAME], and a monthly 30-minute review where the approver, the data owner and one engineer go through what was approved, what was refused and what is running.
- Regulated or privileged work: The person who holds the regulatory or client-contract relationship is one of the two names on Tier 3 decisions. Not consulted afterwards. Named in the approval.
- Public sector, education or tender-driven work: Keep a dated record of every approval decision and its reason. Tender questionnaires ask how decisions were made, and a list of dated decisions answers that faster than a policy document does.
2. Three risk tiers, and what each one requires
Why this block is written this way: Tier the work, not the tool. The same chat tool is Tier 1 when someone drafts a blog post in it and Tier 3 the moment it is wired to send. Three tiers is the most a company under 200 people will actually apply; five tiers turns into an argument about which tier something is in, which is time not spent naming an owner. The dividing lines below are reversibility and reach, because those are what determine how bad a bad day gets.
TIER 1 — LOW. Drafting, summarising, research and code suggestions. No customer or personal data goes in, nothing is written into a system, nothing leaves the company automatically. Requires: an approved tool, and a human who reads the output before it goes anywhere. No paperwork, no approval per use. TIER 2 — MEDIUM. Anything that touches customer or personal data, or writes into a system we own — CRM, ticketing, repository, drive, database. Requires: a named owner, credentials scoped to that one job and nothing more, a log (Block 6), and a named person who can switch it off. Reviewed monthly. TIER 3 — HIGH. Anything that sends something outside the company under our name, moves or commits money, changes access or permissions, or feeds a decision about a person — hiring, credit, pricing for a named customer. Requires: a human approves each action for the first 30 days. After that, either per-action approval stays, or a hard cap plus a daily read of the log. Nothing in Tier 3 runs unattended in its first 30 days. Ever. Rule of thumb when the tier is unclear: ask what it takes to undo it. If undoing it means emailing someone to apologise, it is Tier 3.
What gets added, and when
- Drafting only: You have no Tier 3 work today, so keep Tier 3 written down anyway and treat crossing into it as a decision someone makes on purpose. Companies do not decide to start acting; they discover they already are, because a tool shipped a send button.
- Tools already take actions: Inventory what is already running before you tier anything. List every automation, what credentials it holds, and what it can reach. The list is almost always longer than the person who asked for it expects, and the surprises are the ones nobody owns.
- Customer data reaches the tools: Support tickets, email threads and call notes are customer data. Any workflow that reads them is Tier 2 at minimum, including the ones people describe as just summarising.
- Health data or privileged material: Anything touching protected health information or privileged client material starts at Tier 3 regardless of what it does with it. The material, not the action, sets the floor.
- EU or UK personal data: No Tier 2 or Tier 3 work involving personal data of people in the EU or UK starts before the written vendor contract in Block 7 is in place. Not in parallel. First.
3. Named owners for information going out and coming in
Why this block is written this way: This is the block people skip, and it is the one we would keep if we could only keep one. The only time a client has asked us to write governance from scratch, the trigger was an employee having access to something they should not have had, and that leading to something being published that was a problem. Access at the boundary, then publication. Almost every framework sets rules for what people may do and never names a person against each category of information crossing the boundary in either direction. Nobody owns the boundary, so nothing gets checked at it. Write the table with human names in it. A row that says Ops is a blank row.
INFORMATION LEAVING THE PLATFORM Each category has one named person, not a team. Customer records and anything identifying a person ....... [NAME] Anything published under the company name ................ [NAME] Code, credentials and infrastructure detail .............. [NAME] Financial, payroll and commercial terms .................. [NAME] Standing connections — a drive, inbox, repo or knowledge base wired into a tool and left connected ................ [NAME] INFORMATION COMING IN Documents and knowledge bases fed into a tool ............ [NAME] Model output that reaches customer-facing work ........... [NAME] Third-party data pulled in by an automation .............. [NAME] New tools and integrations added by anyone ............... [NAME] For each row the owner answers three questions and writes the answer down: who can send or add this, what may never cross, and how often the row gets checked ([quarterly] by default). ACCESS IS THE REAL GRANT. What a person or a tool can read is the thing you are actually deciding. Review access to every source in this table [quarterly], and on the day anyone changes role or leaves — not at the next scheduled review. The rows that go stale fastest are the standing connections. They were approved once, months ago, by someone who has since changed jobs.
What gets added, and when
- Nobody owns data today, or a team owns it: Fill this table before you write any other block. A team name in a row means the row is unowned; pick the person who would be called at 9pm and put their name in it. If you do nothing else from this framework in the next month, do this.
- One person informally owns it: Write their name down and tell them. Informal ownership works right up until the week they are on leave, which is also when it is discovered.
- Customer data is deliberately in scope: Split the outbound customer row in two: data used to produce something internal, and data that reaches a third party. They are different risks and usually different owners.
- EU or UK personal data: Add a column recording where each category is processed and stored, and which vendor contract covers it. You will need that column the first time anyone asks a question about it, and reconstructing it later takes days.
4. Approval before anything irreversible
Why this block is written this way: Reversibility is the cleanest line we know to draw, and it survives contact with tools that did not exist when the framework was written. Draft freely; press send deliberately. The failure mode is not a model saying something odd, it is a model saying something odd at 200 recipients with nobody in between.
A tool or automation may draft any of the following. A named human performs the action: - Sending anything outside the company under our name - Publishing anything publicly - Deleting or overwriting records - Changing permissions, access or credentials - Moving money or committing spend - Contacting a customer directly - Anything with a legal or contractual effect Where per-action approval is genuinely impractical because of volume, the substitutes are all three of: a hard cap on actions per run, a daily read of the log by the named owner, and a kill switch that [NAMES] can pull without asking anyone. Every automation above Tier 1 has an off switch that a non-engineer can reach, and the person who owns it knows where it is. Test that once a quarter. An off switch nobody has used is a claim, not a control.
What gets added, and when
- Tools already take actions: For the first 30 days of any new Tier 3 automation, the approving human reads what it was going to do before approving, not after. Approval by habit arrives around week three, which is why the 30-day clock resets whenever the underlying model or prompt changes materially.
- Drafting only: This block is short for you today. Keep it, because the first tool that offers to send on your behalf will present it as a convenience and will not present it as a tier change.
5. Spend: who can switch it on, who can raise it
Why this block is written this way: Run cost is the line that surprises people, not build cost. Anything on a loop — schedules, polls, retries, always-on assistants — spends money while nobody is watching it, and the invoice arrives a month after the decision that caused it. A ceiling set before switch-on costs a minute. A ceiling set after the invoice costs the programme, because by then the conversation is about whether to stop rather than how to size it.
Every automation gets a monthly ceiling before it is switched on, not after: [$X] per automation, [$Y] per department. Alerts fire at 50%, 80% and 100% of the ceiling, to the named owner and to [NAME]. Only [NAMES] can raise a ceiling, and raising one is written down with the reason. Anything that runs on a loop is listed with its schedule, its trigger and its owner. Once a month, [NAME] reads that list and switches off anything nobody has used. Idle loops are the most common source of spend with no output attached. New automations report their first-week cost to the owner before the ceiling is treated as settled. The estimate before you run it is usually wrong in one direction or the other.
What gets added, and when
- Several people can approve spend: Start here rather than with decision rights. Put a company card policy line in place this week: no new AI subscription without [NAME] on the request. It is the cheapest control in this document and the one most likely to be missing.
- One approver: Name a deputy with the same authority up to [$X]. A single approver is clean until they are in a two-week negotiation, at which point people stop asking rather than wait.
6. What gets logged, and for how long
Why this block is written this way: Logging exists so that a question asked in November about something that happened in August has an answer. Two rules make the difference. Log the reference, not the payload, where personal data is involved, so the log does not become a second copy of the thing you are protecting. And put the log somewhere the named owner can read without asking an engineer, because a log that requires a ticket to read is a log nobody reads.
For every Tier 2 and Tier 3 automation, record: - What ran, and when - On whose behalf it ran - What it read (source and reference, not a copy of the content) - What it wrote or sent, and to whom - What it cost Retention: [90] days minimum. [12] months where customer or personal data is involved, or longer where a customer contract says so. Where the content includes personal data, log the reference — record ID, ticket number, file path — rather than the content itself. Reading cadence: Tier 3 daily for its first 30 days, then weekly. Tier 2 monthly. The named owner reads it, not the person who built it. Logs live in [LOCATION], readable by the named owner without engineering help.
What gets added, and when
- EU or UK personal data: Record where each log is stored and who can read it, and set retention deliberately rather than by tool default. A log kept forever because nobody chose a number is its own exposure.
- Regulated or privileged work: Check your existing retention obligations before setting these numbers. Your sector rules almost certainly already specify a period, and having two different numbers in two documents is worse than either.
- Drafting only: You do not need per-action logs yet. Keep the admin-console usage export from your approved tools and look at it once a quarter. That is enough to see what is actually being used.
7. Vendor and model review
Why this block is written this way: Vendor terms change faster than annual reviews, and a model version change is a change even when the vendor calls it an improvement. Two questions get missed in nearly every review we see: what breaks if this vendor disappears, and what this costs at three times current use. Both are cheap to ask before you sign and expensive to answer afterwards.
Before a tool is approved, [NAME] answers seven questions in writing: 1. Who is the vendor, and what is their business model? 2. What happens to what we send — is it used for training, and how long is it retained? 3. Where is the data processed and stored? 4. Is there a written contract covering processing where personal data is involved? 5. What breaks if this vendor disappears or triples its price? 6. What does this cost at three times current use? 7. Who at the vendor do we contact in an incident, and how fast do they answer? Approved vendors are re-checked every [6] months. Terms change more often than that. Model changes are treated as changes. If the model behind a Tier 3 automation is updated, that automation returns to per-action approval for [one week] before going back to its normal mode. Free tiers used from personal accounts are not approved tools, including free tiers of tools we pay for elsewhere.
What gets added, and when
- EU or UK personal data: Question 4 becomes a gate rather than a question. A vendor handling personal data on your instructions needs a written processing contract in place before approval, and GDPR Article 28 sets out what that contract has to contain.
- Healthcare or health data: Add the sector-specific agreement your counsel requires before the tool is approved, not as a follow-up task. This is one of the points where a lawyer is cheaper than a generator.
- Customers send security questionnaires: Keep the seven answers per vendor in one file. Most questionnaire questions about AI are these seven in different words, and a maintained file turns a two-day scramble into an hour.
8. Incident escalation: who gets told, in what order
Why this block is written this way: The damage in the case we saw was not caused by a clever attack. It was caused by ordinary access nobody had checked, and it became a real problem at the moment something went out. Speed of escalation is the only variable you control once that has happened. Write the order down in advance, because deciding who to tell while it is happening is how an afternoon turns into a week.
An incident is any of: information reaching somewhere it should not have; output produced on a wrong basis reaching someone outside the company; an automation acting outside its scope; or a tool being used with data it should never have seen. Order, same working day: 1. Switch it off. Revoke the access or credential involved. 2. Tell the named owner of the affected category (Block 3). 3. Tell [NAME, decision rights holder]. 4. Tell [NAME, legal or contract owner] if a customer, a contract or personal data is involved. Then write down, before memory decays: what ran, what it touched, who saw the output, and when each of those was discovered. Nobody investigates quietly first. The delay is the damage. Reporting an incident that turns out to be nothing carries no consequence here, and that sentence stays in the document because it is the one that determines whether you hear about the next one. Within [5] working days: what changed as a result. Usually an access rule, not a policy line.
What gets added, and when
- EU or UK personal data: Where personal data is involved, GDPR Article 33 sets a 72-hour notification window to the supervisory authority from becoming aware of a breach. Put the clock, the authority and the person responsible for the assessment in the document by name — and get counsel to confirm what applies to you.
- Regulated or privileged work: Your existing sector incident procedure outranks this block. Reference it here by name rather than writing a second, competing procedure.
9. Review cadence, and what forces an early review
Why this block is written this way: Annual reviews leave the document wrong for most of the year, because tools and vendor terms move faster than that. The triggers matter more than the calendar. The one people forget is a person leaving: when someone named in Block 3 goes, several rows become fiction on their last day.
Full review every [3] months for the first year, then every [6] months once the tool list stops moving. Early review is forced by any of: - A new tool or automation entering Tier 2 or Tier 3 - Any incident, including one that turned out to be nothing - A person named in Block 3 changing role or leaving - A vendor changing its terms, pricing or model - Headcount crossing [50] - A new customer contract with AI or data terms in it - A new obligation from a regulator or a major customer The next review date sits at the top of page one. A document with no visible next review date stops being read within a quarter. Each review answers one question first: which names in Block 3 are now wrong?
What gets added, and when
- Board or investor reporting: Align the review with the meeting cycle so the framework produces the update instead of the meeting producing a scramble. One page: tier list, named owners, incidents since the last meeting, spend against ceilings.
- Fewer than 20 people: Thirty minutes, one person, a calendar reminder. Formality here buys nothing; the reminder is what does the work.
10. What we are deliberately not doing at this size
Why this block is written this way: This is the block that keeps the rest of the document alive. Every hour spent on an ethics charter is an hour not spent filling in the names in Block 3, and the names are what would have prevented the only incident we have first-hand knowledge of. Write down what you are skipping and why, so that skipping it is a decision on the record rather than an oversight someone finds later.
We are not doing the following, on purpose: - An AI ethics committee. We have one named decision-maker and a deputy. - A charter of principles. Principles do not tell anyone what to do on Tuesday. - A separate risk register. Block 3 is the register. - A governance tool or platform. This is a document and a table of names. - Model cards for models we did not train. - Bias audits of foundation models we do not control. We test our own outputs on our own cases instead. - A formal management system with an audit programme and certification. Each of these comes back the moment a customer contract, a tender or a regulator requires it. Until then they consume the attention that this framework needs to stay accurate. Reviewed at each cycle: has anything on this list become a requirement rather than a preference?
What gets added, and when
- Customers or investors are asking: Add the one-page extract: three tiers, the owner table, incidents since the last report, spend against ceilings, next review date. That page answers most of what a questionnaire asks without building a management system to produce it.
- Over 200 people, or tender-driven work: Several of these stop being optional at your size or in your procurement process. Treat this framework as the working layer underneath a formal programme, not as a replacement for one.
Which parts of NIST AI RMF, ISO 42001 and the EU AI Act to skip at this size
The big frameworks are good work. They were written for organisations with a CISO, a risk function and a compliance budget, and copying them at 30 people produces a document that is impressive on a Friday and inaccurate by March. Here is what we take from each and what we leave, with the reason.
| Framework | Who it was built for | What to take | What to skip at 20 to 50 people |
|---|---|---|---|
| NIST AI RMF 1.0 | Organisations with a risk function, able to run measurement and testing on each system they deploy. | The GOVERN idea: accountability structures are part of managing AI risk. Block 1 and Block 3 are that idea reduced to names. | The full MAP and MEASURE cycle per system, formal metric selection, testing and evaluation programmes, and profile crosswalks. At 30 people you will produce documents nobody reads or checks. |
| ISO/IEC 42001 | Organisations that need a certificate — because a customer, a tender or a parent company asked for one. | The habits: a named owner per area, a review cycle, and a record of decisions. You get those from Blocks 1, 3 and 9 without the system around them. | The management system itself — statement of applicability, documented control objectives, internal audit programme, management review minutes, certification. Start it when a contract requires it, and budget for a consultant when you do. |
| EU AI Act | Anyone placing AI systems on the EU market or using them in the EU, with obligations scaled to how the system is classified. | The classification question. Read Article 6 and decide, in writing, whether anything you run is in scope as high-risk. Most internal drafting and summarising is not. | Building conformity assessment, technical documentation and post-market monitoring machinery before you have established anything you run is high-risk. Get the classification answered by counsel first, then act on the answer. |
| Enterprise AI governance programmes | Companies with a CISO, a GRC function and a compliance budget. | Tiering, logging and incident escalation. Blocks 2, 6 and 8 are the small version of all three. | Committees, charters, dedicated tooling and quarterly attestation. A page and a half that is accurate beats forty pages that were accurate in March. |
One caution on the EU AI Act row. Skipping the machinery is not the same as deciding the Act does not apply to you. Read the classification rules in Article 6, write down your conclusion with a date on it, and put that question in front of counsel if anything you run touches employment, credit, education or anyone's access to a service.
Governance is easier where the work is written down
The strongest signal we know that a role suits an agent is that it already has clearly determined KPIs and clearly determined SOPs, for work that is mostly digital. That is a build signal, but it turns out to be a governance signal too. If a job already has a written procedure and a number attached to it, tiering it takes ten minutes and the owner is obvious — it is the person who owns the KPI.
Where nothing is written down, governance gets hard for the same reason automation does: there is no agreed version of what good looks like, so there is nothing to approve against and nothing to check the output against. If you find yourself unable to fill in Block 3, the missing thing usually is not a governance decision. It is that nobody has written down how the work is done.
When this is premature, and when you need ISO 42001 or a lawyer instead
Do not write this if nobody at your company uses AI tools for work yet. You will produce a document about a situation you have not met. Find out what is in use first, with one anonymous question to the team, then write against what you find. And if you are five people who can see each other work, take two blocks — named owners at the boundary, and approval before anything irreversible — and leave the other eight until headcount or customer data forces them.
Go to a consultant for ISO 42001 in one case: a customer contract, a tender or a parent company requires the certificate. That is a management system with an audit programme, and no builder on a website produces one. Budget accordingly and start early.
Go to a lawyer, not a builder, in four cases. When a customer contract restricts sending their material to third parties and you need to know whether a model vendor counts. When a regulator can ask you to defend this document line by line. When an incident has already happened and the question is your notification obligations rather than your framework. And when anything you run feeds a decision about a person's job, credit or access to a service.
The honest limit of this page: it cannot read your contracts, it does not know your regulator, and no lawyer has reviewed a word of it. It gets you from nothing to a draft that names the right things, which is a real saving on a lawyer's hour and is not a substitute for one.
One more thing worth saying plainly. A framework does not stop anything by itself. If your tools sit on personal accounts with no admin visibility, no logs and no way to revoke access when someone leaves, you have written a document about a system you cannot see. Fix the accounts first. The framework is how you keep them fixed.
Who wrote this, and how to check it
Written by Ashutosh Upadhyay, founder of Cognio Labs, and last reviewed on 24 August 2026. We build and run AI agents for companies of roughly 20 to 50 people, which is where the block structure comes from — it is the set of questions we end up asking on every build, in the order they usually bite.
What is first-hand: the boundary-ownership story, the KPI and SOP signal, and the judgement about what a company this size will actually maintain. What is not: any legal interpretation. Where this page points at NIST, GDPR or the EU AI Act, the sources are linked below so you can read the original rather than our summary of it. Nothing here has been reviewed by a lawyer, and the page says so in four places on purpose.
What to do after you have the framework
Fill in the names in Block 3 this week. Then write the employee-facing document, since the framework decides who is accountable and the policy tells staff what they may put into a tool.
- AI acceptable use policy generator — the employee-facing half. Eight questions, eleven clauses, same no-email rule.
- AI agent security and governance — scoped credentials, logging and the failure modes behind Blocks 4, 6 and 8.
- AI readiness scorecard — if you could not fill in Block 3, start here instead.
- How we build and run AI agents for companies — the governance layer above is part of what we set up when we run a build, rather than a document we hand over at the end.
- All free tools — the rest of what we publish without a form in front of it.
Frequently asked questions
What is an AI governance framework?
An AI governance framework is the written answer to four questions: who decides what AI gets used here, who owns each category of information going into and out of the tools, what has to be approved before it happens, and what gets checked and how often. At a 20 to 50 person company that is about a page and a half. It sits above an acceptable use policy, which tells employees what they may and may not do; the framework tells the company who is accountable for what.
What should an AI governance framework include?
Ten blocks cover it at this size: decision rights with one named approver, three risk tiers based on reversibility and reach, named owners for information going out and coming in, approval before anything irreversible, spend ceilings and who can raise them, what gets logged and for how long, vendor and model review, incident escalation order, review cadence with the triggers that force an early one, and a written list of what you are deliberately not doing yet. Every block below is printed in full on this page with its default text.
Do we need NIST AI RMF or ISO 42001 at 20 to 50 people?
Not usually. NIST AI RMF and ISO 42001 are written for organisations with a risk function, a security lead and a compliance budget, and the parts that carry weight at 30 people are the accountability structures rather than the measurement programmes. Take the GOVERN idea from NIST, take the habits of named ownership and review cycles from ISO 42001, and skip the management system until a customer contract or a tender asks for the certificate. When that day comes, budget for a consultant, because certification is not a document exercise.
Who should own AI governance in a small company?
One named person with the authority to say no and the deadline to say it fast, plus a deputy for when they are away. It is usually an operations or finance lead rather than an engineer, because most of the job is deciding and reviewing rather than building. What does not work is a team name in the owner column. When a row says Ops rather than a person, that row is unowned and nothing gets checked at it.
How is a governance framework different from an AI acceptable use policy?
The policy faces employees and answers what you may put into a tool, what you must never paste, and who to ask for a new one. The framework faces the company and answers who decides, who owns each boundary, what needs approval and what gets reviewed. You need both, and the framework should come first, because the policy is only enforceable if someone owns enforcing it. Our free AI acceptable use policy generator produces the employee-facing document.
What are AI risk tiers and how do we set them?
Tier the work, not the tool. Tier 1 is drafting and summarising with no customer data and no system writes, and needs only an approved tool plus a human reading the output. Tier 2 touches customer or personal data or writes into a system you own, and needs a named owner, scoped credentials, a log and an off switch. Tier 3 sends outside the company, moves money, changes access, or feeds a decision about a person, and needs per-action human approval for at least the first 30 days. When the tier is unclear, ask what it takes to undo the action.
When is an AI governance framework premature?
If nobody at your company is using AI tools for work yet, you would be writing about a situation you have not met. Find out what is actually in use first. And if you are five people who can see each other work, two blocks matter — named owners for information crossing the boundary, and approval before anything irreversible. The other eight can wait until headcount or customer data forces them.
Does the EU AI Act apply to a small company using AI internally?
It depends on what you run and where, and this page cannot answer it for you. The practical step is to read the classification rules in Article 6 and write down, with a date, whether anything you operate falls in the high-risk categories. Most internal drafting and summarising does not. Employment, credit and education uses are where small companies most often find they need advice, and that is a question for counsel rather than for a builder on a website.
Sources
- NIST, AI Risk Management Framework (AI RMF 1.0) — GOVERN is the first of its four functions and treats accountability structures as a named part of managing AI risk. Blocks 1 and 3 are that idea reduced to a table of names. NIST does not prescribe the table, and does not say to skip anything; the skipping advice on this page is ours.
- OWASP GenAI Security Project, LLM02:2025 Sensitive Information Disclosure — why sensitive information reaching a model through ordinary use is treated here as a named top-ten risk rather than an edge case, and why Block 6 logs references instead of payloads.
- GDPR Article 28 (Processor) — what a written contract with a vendor processing personal data on your instructions has to contain. Question 4 in Block 7 exists because of it.
- GDPR Article 33 (Notification of a personal data breach to the supervisory authority) — the source of the 72-hour clock in Block 8 for companies handling EU or UK personal data.
- EU AI Act, Article 6: Classification Rules for High-Risk AI Systems — read before assuming the Act does or does not reach what you run. That link is the AI Act Explorer's reproduction, which is easier to read; the authoritative text is Regulation (EU) 2024/1689 in the Official Journal. Use the Official Journal version with counsel before relying on it.
- The boundary-ownership story and the KPI and SOP signal come from our own client work at Cognio Labs, anonymised, with no numbers attached because we do not have numbers we can publish. First-hand observation, not research.
Want the framework pressure-tested?
Thirty minutes, no pitch. Bring your draft and we will tell you which block will not survive your actual setup — it is usually Block 3, and usually the standing connections row. Including when the answer is that you should fix your accounts before you hire anyone.