An AI risk register that survives has six columns and about nine rows. Two of those columns appear in none of the templates you will find: how you would find out, and what the first hour looks like. The fifteen-column version is not more rigorous. It is a document that needs a compliance team to stay alive.
Every template on the first page of results was built for an organization with a chief information security officer, a data protection officer, named model owners, and a platform to hold it together. This one is for the person at a company of 50 to 500 people who bought the AI licenses and has been asked, as a second job, to show that someone is managing the risk.
What the template industry hands you
Search the term and the results are uniform: governance platforms, browser-security vendors, consultancies, a training provider selling a certification. The artifact is the same every time. Twelve to fifteen columns: risk ID, system, data sensitivity, lifecycle stage, likelihood, impact, inherent and residual scores, controls, treatment decision, owner, evidence, framework mapping, review date. Scored on a five-by-five grid and pre-loaded with thirty generic risks.
The best of them is genuinely good. One works through three examples: bias in a hiring model, hallucination in a customer-facing chatbot, drift in a fraud-detection model. A company of 120 people owns none of those. It owns ChatGPT seats, a Microsoft Copilot rollout, Claude in a few teams, and an AI feature that appeared in its help-desk product without anyone approving it.
Your exposure is behavioral, not architectural. MIT’s AI Risk Repository reached version 4 in December 2025 and now holds more than 1,700 risks drawn from 65 published frameworks. Its published meta-review of that literature found that most risks emerge after a model has been trained and deployed (65%) rather than before (10%). For a company that buys rather than builds, that later share is effectively all of it. A builder’s template spends fourteen columns on a model you will never touch and none on the paralegal with a deadline.
Whether anyone requires one at all
Settle this before spending a week on it, because most pages imply an obligation that does not reach you.
The EU AI Act has the only hard language. Article 9(1): “A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems.” Article 9(2) adds that it is “a continuous iterative process planned and run throughout the entire lifecycle,” requiring regular systematic review. That is a register in all but name.
It is also written in the passive voice, which matters. Article 16(a) scopes those requirements to providers of high-risk systems, defined in Article 3(2) as whoever develops a system, or has one developed, and places it on the market under their own name. Duties on deployers sit in Article 26 and are narrower. Timing moved too: Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, deferred the Annex III high-risk obligations to 2 December 2027. The separate duty in Article 4, applicable since 2 February 2025, asks for something else entirely: AI literacy among staff operating AI systems.
Everything else is voluntary or conditional. The NIST AI Risk Management Framework, published as AI 100-1 in January 2023, is explicitly voluntary; its Map function is where a register lives, and its Govern 2.2 subcategory names personnel training as a control in its own right. ISO/IEC 42001:2023 requires a risk assessment and a system impact assessment, but only if you seek certification. SOC 2 has no AI criterion at all, which is why the questions your auditor asks vary so much between firms.
So a US company of 150 people with no EU establishment is compelled by none of it. Keep a register anyway, for a better reason than compliance.
Six columns, not fifteen
One page, nine rows, six columns, with one row filled in.
| What could happen | Where | Owner | What stops it today | How we would find out | First hour |
|---|---|---|---|---|---|
| Someone pastes a client document into a personal AI account to hit a deadline | Any assistant, personal login | VP Operations | Business tenant for all staff; data categories taught in October | The person tells us, or a connector request appears in the admin console | Establish what was pasted and whether the account retains it; delete what can be deleted; decide within the week whether a client contract requires notice |
Nine columns are gone. Risk ID, because nine rows have names. Inherent and residual scores, because the difference between a 16 and a 12 at this size is invented. Lifecycle stage, because you have no lifecycle.
Treatment decision and status go too, because the owner and control columns say it already. So does framework mapping, because mapping to a regulation that does not bind you is theater. And evidence, because here the control description is the evidence.
If a certification process ever needs the formal shape, you can derive it in an afternoon from a register that is current. You cannot derive anything from fifteen columns that stopped being true in March.
The two columns nobody includes
Likelihood, impact and controls are on every template. Detection and response are on none, and for a company that buys its AI rather than building it, they do most of the work.
How we would find out. Write the honest answer, including when it is “we would not.” That blank is the most valuable cell on the page. A risk with no detection route is one you have agreed to learn about from a client. The realistic routes here are narrow, and that is fine. A person tells you. An admin console shows a connector request. An expense report shows a subscription. A client asks a question you cannot answer. Scanning everyone is expensive and counterproductive, which is the argument in enforcing a policy without surveillance.
First hour. One or two sentences on what the owner does immediately. Contain the data. Decide whether it is a notification event under a contract or a regulation — a counsel question, cheap to ask early. Fix the condition that produced it. This is the only part anyone reads under pressure.
Then compute the output no template computes. Read each row aloud and name the judgment a human has to make for the control to hold. “Recognizes that this document is covered.” “Notices that the output asserts a number that was never in the source.” “Knows this product sends content to a vendor you have no agreement with.” Those sentences are your training agenda, and they are why a register at this size is a capability document before it is a compliance one — the argument running through the safe AI use playbook.
Nine entries for a company that builds nothing
Start here and cut what does not apply. These are deployer risks.
- Confidential client material entered into a personal AI account. The most common real incident at this size.
- Regulated or personal data entered into a product with no agreement covering it. Health, financial, or employee records in a consumer tier.
- Unverified output sent to a client, a regulator, or a board. A number, a citation, or a clause nobody checked.
- A tool in use that nobody approved. The subscription on someone’s personal card.
- A vendor changes data handling, or swaps the model behind a product, without notice. Your controls were written against last quarter’s behavior.
- An AI feature switched on inside software you already pay for. Nobody procured it; it arrived in a release note.
- Contractor and freelancer use outside your tenant. Your policy covers employees; your exposure does not.
- AI-assisted screening introduced by a functional team. Hiring and performance are where a company this size quietly becomes a deployer of a system regulators treat as high-risk.
- An assistant or connector granted broader system access than its task needs. The permission nobody revisited.
Thirty rows is a decision to let twenty go stale.
The four readers who decide the format
Templates never name a reader, which is why they settle no formatting question. Yours has four.
| Reader | What they want from it | How often |
|---|---|---|
| A client’s security questionnaire | That a named person owns AI risk, and that the list exists | Per deal, increasingly |
| An insurance renewal | Controls, and an honest answer about incidents | Annually |
| An auditor or certification process | The link from a stated control to evidence it operates | During fieldwork |
| Whoever is handling hour one of an incident | Detection route and first-hour steps | Rarely, urgently |
The first two arrive on a form, and what those forms now ask is in what your insurer and clients ask about your AI controls. Each wants a different cut of the same nine rows, which argues for one current page over four separate documents.
Scoring when there is no risk function
A five-by-five grid produces twenty-five cells and, across nine rows, false precision. Use three bands, each tied to a decision you are willing to make this quarter:
- Accept. Noted, owned, reviewed. No work scheduled.
- Fix this quarter. A named change with a date: a seat purchase, an admin setting, a policy sentence, a session.
- Stop until fixed. The activity does not continue in its current form.
If a row cannot be sorted into one of the three, the description is too vague to act on. Rewrite it rather than adding a column. McKinsey’s state-of-AI survey work found the average number of AI risks organizations actively mitigate rose from two in 2022 to four in 2026 — modest, and still more than a stale thirty-row spreadsheet delivers.
Where the entries come from, free
Two public catalogs beat anything gated behind an email address, and neither appears on most pages selling templates.
The Deployer AI Risk Register, published by MindXO at version 1.0 in July 2026, is an open catalog of 82 deployment risks plus 61 MITRE ATLAS security sub-risks, consolidated from the MIT repository, ISO/IEC 23894 and 42001, and the EU AI Act, under a Creative Commons license. It is also 143 entries, roughly sixteen times what you should carry — read it once and subtract.
The MIT AI Risk Repository is the academic spine underneath most of this, and MIT is careful to say it is not a definitive source of truth. Take the vocabulary, then write your rows in your own words, because a row your staff cannot repeat governs nothing. Whether any of this needs a platform is answered in AI governance tooling for mid-market companies.
The review that survives a calendar
Quarterly review is the standard recommendation and the wrong cadence for a document whose subject changes monthly. Vendors revise data-handling terms, products ship AI features, and staff adopt tools faster than a quarterly rhythm can track. Attach it to a meeting that already exists: twenty minutes on a monthly operations agenda, three questions.
- What AI product is in use that was not on this page last month?
- Did any row’s detection route get tested, by an incident or a client’s question?
- Which “fix this quarter” item has a date that has passed?
Then re-date the page. One review date for the whole document, not per-row dates: at nine rows you review the page, not the rows. That is also why the per-row review date, the field that goes stale on every real register, is one you can drop. Your recorded incident count will rise in the first month or two. That is the detection column working, not the risk increasing.
What this costs
| Line item | Market range | Note |
|---|---|---|
| Writing the first version | An internal half-day, or roughly $1,000–3,000 of counsel time | One page, not forty |
| Monthly review | 20 minutes on an existing agenda | The only recurring cost that matters |
| Business AI seats | Roughly $20–30 per seat per month | Most rows reference a tenant you control |
| AI governance platform | Low to mid five figures annually | For a named obligation, not nine rows |
| An applied AI enablement session | Roughly $2,000–15,000 in the open market | Varies with group size and material |
The ordering is the argument. A company that buys a governance platform before issuing business accounts and teaching five data categories has bought a dashboard for a problem it has not addressed. At nine rows, a shared document with version history is the audit trail.
Frequently asked questions
What is an AI risk register, in plain terms?
A one-page list of what could go wrong with the AI your company uses, with a named person against each item, what currently stops it, how you would find out, and what that person does in the first hour. Everything beyond that is formality added for readers you may not have.
Is an AI risk register legally required for a US company?
Usually not. Article 9 is scoped by Article 16(a) to providers of high-risk AI systems, and the Annex III deadline moved to 2 December 2027 under Regulation (EU) 2026/1744. NIST’s framework is voluntary and ISO/IEC 42001 applies if you seek certification. A US company of 50 to 500 people using general-purpose assistants is typically outside all of it, and still gets asked for the register by clients and insurers.
What is the difference between an AI risk register and an AI inventory?
The inventory lists the AI products and features in use. The register lists what could go wrong and who owns each item. The inventory comes first, because you cannot register a risk for a tool you have not found.
How many entries should a mid-market register have?
Around nine, and under fifteen. The constraint is not thoroughness but how many rows a part-time owner can keep accurate. Stale entries are worse than missing ones, because they get quoted on questionnaires.
Who should own it when there is no risk function?
One named person for the page, usually the COO, VP Operations, or chief of staff, and a named person per row. Never a committee, never a department. The failure at this size is vacancy: operations assumes IT owns it and IT assumes legal does.
How often does it need to be reviewed?
Monthly, in twenty minutes, on an agenda that already exists, plus immediately after any incident or any vendor change to data handling.
Where can we get a list of AI risks to start from without paying?
The Deployer AI Risk Register is free under a Creative Commons license and catalogs 82 deployment risks plus 61 security sub-risks. The MIT AI Risk Repository holds more than 1,700 risks from 65 frameworks. Both are reading material for subtraction, not registers to adopt.
How does the register connect to training?
Every row names a judgment a person has to make for the control to hold. The KPMG and University of Melbourne global study of roughly 48,000 people across 47 countries found 48% had put sensitive company information into public AI tools and 66% had relied on output without checking it, while only 47% had received any AI training. Those judgments are what an applied session teaches, and they are the controls your register rests on.
Key takeaways
- Six columns and roughly nine rows survive at this size. Fifteen columns need a compliance function you do not have, and a stale register is worse than a short one.
- Two columns matter most and appear on no template: how you would find out, and what the owner does in the first hour. A blank detection cell is the most useful thing on the page.
- Article 9 binds providers of high-risk systems, so a US mid-market deployer is unlikely to be covered. Keep the register for the four readers who ask for it.
- Scope it to risks your own staff can cause. MIT’s meta-review of the risk literature found 65% of risks emerge after a model is deployed, against 10% before.
- Score in three bands tied to decisions — accept, fix this quarter, stop until fixed. Review monthly on an existing agenda, with one date for the whole page.
- Each row rests on a human judgment. Naming those judgments turns the register into a training agenda, which is the point of treating enablement as the work rather than license distribution.
If you want a second opinion on your nine rows, or on which judgments a ninety-minute applied session should cover, book a free AI-readiness call. We will read your register, name the row with no detection route, and say what it would take to close it.
Dirk Jan van Veen, PhD
