AI Risk Register Template: A Simple One to Start With

An AI risk register is a short shared document with one row per AI agent that records what could go wrong, who owns that risk, which control limits it and when it will be reviewed next. You can start with those four columns on a single page and add detail only when a real decision needs it. The template below gives you the fields, a way to fill them in and a review rhythm that a small team can keep.

Key takeaways

• Keep one row per agent, because risk attaches to what an agent can read, write, send and decide.
• Four fields do most of the work: risk, owner, control and review date. Everything else is optional.
• Write each risk as a concrete sentence and give it a named person as owner, not a team.
• A control only counts if you can point to evidence that it works, such as a log, a test or a sampled review.
• A register is useful only if it is reopened, so set a date on every row and agree on events that trigger an early review.

What is an AI risk register, and why keep it small?

An AI risk register is a living list of the ways your AI agents could cause harm or disappoint, paired with the decisions you have made to limit that. It is the same idea as a risk register in finance or operations, applied to software that can read information, draft messages and sometimes take actions.

Frameworks such as the NIST AI Risk Management Framework describe risk work in broad functions: set up governance, understand the context, measure, and manage. That structure is sound, but a company with a handful of agents does not need a program to begin. It needs a page that people actually open.

Large registers fail in a predictable way. They are built once, filled with generic risks copied from a checklist, and never read again. A small register with specific rows tends to survive because each row describes something the owner recognises from daily work.

Why one row per agent? Two agents can run on the same underlying model and still carry very different risks. One summarises internal meetings. The other emails customers about their invoices. The model is the same, but what each one can reach and do is not, and that is what the register should describe.

What goes in each row of the template?

Copy these fields into a spreadsheet or a shared document. The first four are the core. The last three are worth adding once the first rows feel natural.

• Risk: one sentence in the form "If this happens, this harm reaches this person or system." Be specific about what the agent touches.
• Owner: one named person who can decide to accept, reduce or stop the risk. A team name is not an owner.
• Control: the specific measure that limits the risk, such as a narrower permission, an approval step, a data restriction or a monitoring check.
• Review date: a calendar date, not "quarterly". Someone should be able to look at the row and see when it is next due.
• Agent and role: the agent's name plus one sentence on its job, so the row makes sense to a newcomer.
• Evidence: where a reviewer can verify the control works, for example an access list, a log extract, a test result or a sampled set of outputs.
• Status: open, accepted, reduced or closed, in the owner's words.

Two habits keep the template honest. First, write the risk as something that could be observed, not as a mood. "The agent may be unsafe" cannot be reviewed. "The agent could quote an outdated refund policy to a customer" can. Second, make the control something a person could switch on or off. "Be careful" is a hope, not a control.

How do you fill in the register, step by step?

You can complete a first version in one working session with the people who actually use the agents. Use this sequence.

• Step one, list every agent, including informal ones. Include assistants that individuals set up on their own, because those carry real risk too. The article on finding shadow AI without punishing anyone covers how to surface them calmly.
• Step two, describe each agent's reach. Write down what it can read, what it can write or send, which tools it can call and which actions cannot be undone.
• Step three, draft risks with three questions. What is the worst plausible wrong output? What information could leave the place it belongs? Which action would be hard to reverse?
• Step four, assign an owner to every risk. If nobody wants it, that is itself a finding. The piece on who is accountable when an agent makes a mistake helps you settle the question before an incident forces it.
• Step five, choose a control for each risk and prefer controls built into the system over reminders to staff. A permission that does not exist cannot be misused. An approval step is stronger when it sits in the workflow, as described in where your AI agent should stop and ask.
• Step six, record the evidence. Write down where you would look to confirm the control is working today.
• Step seven, set the review date and read the whole page aloud in a short meeting. Rows that nobody can explain out loud need rewriting.

What does a filled-in row look like? An illustrative scenario

The following is illustrative, not a real case. Imagine a services company with a support agent that drafts replies to billing questions. It can read a customer's invoice history and it prepares drafts that a team member sends.

Here is one row for that agent.

• Agent and role: Billing reply drafter. Prepares draft answers to invoice questions for a team member to review and send.
• Risk: If the agent quotes an outdated payment term, a customer receives a wrong commitment in writing.
• Owner: The support lead.
• Control: Drafts are never sent automatically. The agent reads the current terms document only, and the support lead is the sole editor of that document.
• Evidence: Send settings show no automatic sending. The terms document has a change history that the support lead checks.
• Review date: The first Monday of next month, or sooner if the terms document changes.

And a second row for the same agent.

• Risk: If a customer pastes unrelated personal details into a message, the agent could store them in its notes.
• Owner: The operations manager.
• Control: Memory is limited to a short list of approved fields, and anything outside the list is discarded.
• Evidence: A periodic look at stored notes for a small sample of customers.
• Review date: Set at the same monthly meeting.

Notice what the rows do not contain: no scoring formula, no colour codes, no long justification. Each row names a concrete event, a person and a measure that can be checked. If the owner later wants likelihood and impact ratings, they can add columns without rebuilding anything.

Which risks should a first register cover?

You do not need to invent risks from nothing. Use this list as prompts when drafting rows, and keep only the ones that apply to the agent in front of you.

• Wrong or invented answers: the agent states something false with confidence, in front of a customer or in an internal decision.
• Data exposure: information moves to a person, tool or log that should not have it. The guide to data minimization for AI agents is a useful companion here.
• Excess permissions: the agent can do more than its job needs. The OWASP authorization guidance centres on least privilege, and the same idea applies to agent tool access.
• Hidden instructions in content: a document, web page or email contains text that tries to steer the agent. The OWASP Top 10 for LLM Applications lists this as prompt injection, and it is a good prompt list for the whole register.
• Stale context: the agent keeps relying on a policy, price list or client detail that has changed. See how to stop stale context from misleading an agent.
• Silent change: a model update, tool change or edited instruction alters behaviour without anyone deciding it should.
• Unclear ownership: nobody can say who approves changes, who is told about incidents or who can switch the agent off.

For each prompt, ask whether it is real for this agent. A drafting agent with read-only access has little exposure to some of these, and writing "not applicable, because it cannot send or edit" is a perfectly good entry. It shows the question was asked.

How often should you review it, and what should trigger an early review?

The review date is the most neglected field and the most valuable one. Without it, the register becomes a record of good intentions. Choose the date by how much damage the risk could cause and how fast the agent's surroundings change. An agent that can contact customers or touch financial records deserves a nearer date than one that summarises internal notes.

Also agree on events that trigger an early review, whatever the calendar says.

• A new tool, data source or channel is connected to the agent.
• The model, instructions or knowledge the agent relies on are changed.
• A mistake, complaint or near miss involving the agent occurs.
• The owner leaves the company or changes role.
• A policy, contract or regulation that the agent's work depends on changes.

At each review, the owner answers three plain questions. Is the risk still described correctly? Is the control still in place, and does the evidence show it? Has anything happened that changes the status? Then they set the next date. If a review keeps producing no changes, lengthen the interval for that row. If it keeps producing surprises, shorten it and look at why.

A short reviewing session also doubles as an evaluation point. Where a control relies on output quality, sample real outputs and compare them against what the owner would accept. Guides on evaluation, such as the OpenAI evals guide and Anthropic's writing on evaluating agents, explain how to make that sampling repeatable as the number of agents grows.

How does Be Human's managed approach handle the register?

A first Be Human engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Those four decisions map directly onto register rows: the tools and memory describe the reach, the approval boundaries are controls, and the success criterion gives the owner something to check. During managed operations, monitoring, recurring evaluations and permission reviews produce findings, and those findings update the relevant rows and review dates. The company keeps the owner names and the approval decisions, since those are business choices. Service is remote, in English and Portuguese.

Frequently asked questions

How many risks should each agent have in the register? Start with the few that you could describe from memory, usually two to four per agent. If you cannot name a control or an owner for a risk, it is not yet ready to be a row. Add more only when a real event or review shows a gap.

Who should own the register itself? Choose one person to maintain the document and run the review meeting, often an operations or compliance lead. That person does not own every risk. Each risk keeps its own owner, who is closest to the work and able to decide what to do about it.

Do we need a register if we only use a chat assistant? Yes, but a very small one. Even one row is useful if it states what information staff may paste in, who checks the answers before they leave the company and when the practice is next reviewed. An acceptable use policy can then carry the detailed rules.

How does a risk register relate to regulation? A register is not a legal compliance document, but it gives you organised facts to bring to a lawyer or adviser. Which rules apply depends on where you operate and what the agent does with personal data or decisions about people. Ask qualified counsel to confirm that, and keep the register as the working record of your controls.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.