Superintelligence Risk Register: A Template Companies Can Use

The most useful way to handle superintelligence risks for business is a risk register: a short list of specific risks from more capable AI, each with a named owner, a control that already exists and a review trigger that says when to look again. It does not depend on predicting when advanced AI will arrive. It tracks what your own agents can reach, decide and change as the models underneath them improve.

Key takeaways

• A register entry has four required parts: the risk, one named owner, one working control and one review trigger.
• Track risks you can act on (access, data, dependence, oversight, drift) rather than debating timelines.
• Review triggers should be events, such as a model change or a new tool, with a calendar interval only as a fallback.
• Start with six to eight entries. A short register that is reviewed beats a long one that is filed.
• Every control needs evidence someone can inspect, such as a log, an evaluation result or a permission list.

Why keep a register for risks that have not fully arrived?

More capable models change a company's risk profile even when nothing inside the company changes. An agent that once drafted emails may, after a model update, plan multi-step work, call tools and act across several systems. If its permissions, memory and approvals were designed for the earlier version, the gap between what it can do and what you intended it to do grows quietly. A register makes that gap visible and puts a person's name next to it.

A register is also different from a strategy paper. A strategy paper argues about what might happen. A register answers a narrower question: if this specific thing goes wrong, who notices, who acts and what is already in place? That framing matches how the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizes the work, as governing, mapping, measuring and managing risk. The register is a small, working version of that cycle, sized for a company that does not have a dedicated risk department.

If you have no AI policy at all yet, a lightweight governance start for mid-sized companies is a reasonable companion. The register can then become its living part, the place where policy meets actual agents.

What fields does each register entry need?

Keep the template small enough that people will fill it in. Six fields are enough:

• Risk: one sentence describing what could go wrong, in business terms rather than technical ones.
• Owner: one person, named by role, who can change the control and is accountable if it fails. Not a committee.
• Control: the specific measure in place now, such as a permission scope, an approval step, an evaluation or a tested backup.
• Evidence: where someone can verify that the control works, such as a log, a report or a test result.
• Review trigger: the event that forces a fresh look, plus a fallback calendar interval.
• Status: in place, partial or missing.

Two rules keep the template honest. First, the owner must be someone with authority over the control. An owner who can only escalate is a messenger, not an owner. Second, if you cannot name a control that exists today, write the status as missing. That is useful information, not a failure of the exercise. A register full of green entries on the first pass usually means the controls were described rather than checked.

Which risks belong in the first version?

The seven entries below are written as lines you can copy and adapt. Delete the ones that do not apply and add two that are specific to your business.

• Risk: the agent gains capability or tool access beyond what its permissions were designed for. Owner: operations lead. Control: least-privilege permissions and written approval boundaries. Review trigger: any model change, new integration or new type of action.
• Risk: staff stop checking outputs, and the agent's errors flow into decisions. Owner: the department head who uses the agent. Control: sampled human review of outputs and a named approver for consequential actions. Review trigger: review samples are skipped, or approvals become automatic in practice.
• Risk: confidential know-how or personal data leaks through memory, prompts or connected channels. Owner: security or legal lead. Control: scoped memory, access logs and data handling rules for each channel. Review trigger: a new data source, a new channel or new contractor access.
• Risk: hidden instructions in emails, documents or web pages steer the agent into misusing its tools. Owner: security lead. Control: treat outside content as untrusted and enforce authorization on the tool side, not only in the prompt. Review trigger: the agent is connected to any new source of outside content.
• Risk: behavior drifts after a model or prompt update and nobody notices. Owner: the agent operator. Control: recurring evaluations on real task samples, plus monitoring of logs. Review trigger: any provider update, or an evaluation result below the agreed threshold.
• Risk: dependence on one vendor makes the agent's memory and configuration hard to move. Owner: technology or procurement lead. Control: exportable memory and configuration, with a backup and restore that has been tested. Review trigger: contract renewal, a deprecation notice or a material change in vendor terms.
• Risk: new rules on AI or personal data apply to a use case you already run. Owner: legal lead. Control: an inventory of agent use cases and data types, checked against the rules that apply to you. Review trigger: entering a new market, handling a new category of personal data, or a regulator publishing guidance.

The fourth entry follows a pattern documented in the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/), which is a good reference for your security owner. The third and sixth entries connect to larger topics: protecting company know-how as agents grow more capable and avoiding vendor lock-in with business agents each go deeper on what the control should contain.

How do you write review triggers that actually fire?

Calendar-only reviews fail because the world changes between the dates. A model can be updated on a Tuesday, a new tool connected on a Wednesday, and the next scheduled review may be weeks away. Triggers work better when they are tied to events that someone already sees. Use this as a checklist when you write them:

• Tie triggers to change events: a new model version, a new tool, a new data source, a new group of users or a vendor notice.
• Tie triggers to signals: a drop in evaluation results, a rising number of corrected outputs, or unusual access in the logs.
• Say who is notified. The trigger goes to the owner by name, not to a shared inbox.
• Add a fallback interval so quiet entries still get looked at. For permission-related entries, a quarterly rhythm fits well, and the quarterly permission review describes the steps and evidence.
• Record the outcome every time: unchanged, control adjusted, or risk escalated.

Signal-based triggers need something to measure. That means logs and traces that show what the agent did, which is the territory of observability; the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains the concepts clearly. It also means evaluations that reflect real work. Anthropic's article on [demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a practical read for whoever will build yours. Without these, a trigger such as evaluation result below threshold has nothing to fire on.

What does one trigger look like in practice? An illustrative scenario

This is an illustrative scenario, not a report of a real case. A distribution company runs an agent that drafts replies to supplier emails and updates notes on open orders. Its provider announces a new model version with stronger tool use. That announcement is a review trigger on two register entries: capability beyond designed permissions, and drift after an update.

The agent operator runs the company's saved set of past supplier emails against the new version and compares the results with the current one. Drafting quality is similar. However, the new version is more eager to propose edits to order records, an action that sits outside the approved list. The owner decides to keep the current version for now, adds an approval step for any record update, and re-runs the comparison before switching.

The owner then updates the register: control adjusted, evidence attached (the comparison results and the new approval rule), next review set. Nothing dramatic happened, and that is the point. The register turned a vendor announcement into a small, documented decision by a named person before anything reached production.

How do you keep the register alive, and where does managed operations fit?

Most registers fail after the first meeting because nobody owns the routine. A simple plan keeps it going:

• Draft the first version from the seven entries above. Remove what does not apply and add two of your own.
• Confirm each owner agrees to the role. An owner who learns about the entry later will not act on it.
• For every entry, find the existing control and its evidence. Mark anything you cannot find as missing.
• Place each trigger where changes are already approved or announced, so it fires without extra effort.
• Hold a short monthly review of open and missing items, and a fuller review each quarter.
• Keep one executive accountable for the register as a whole, usually the person who sponsors the AI work.

In a Be Human engagement, the register is tied to the work of managed operations. The first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion, which gives most entries an owner and a control from the start. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review and incident response, so the evidence behind each control is produced as part of the routine, and improvements follow a controlled change process instead of ad hoc edits.

To find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Do we need a risk register if we only use simple AI tools? A short version is still worth having. Even simple tools touch company data and influence decisions, so each one deserves an owner and a rule for when to revisit it. With only a few tools, three or four entries may be enough.

Who should own the register as a whole? One executive should be accountable for it, ideally the sponsor of your AI work, while individual entries belong to the people who control the relevant systems. The executive does not fix every risk. Their job is to make sure each entry has an owner, a working control and a recent review.

How often should the register be reviewed? Review entries when their trigger fires, and use a fallback interval for the rest. A monthly check on open items and a fuller quarterly pass work for most mid-sized companies. If your agents change often, shorten the interval for the entries about permissions and drift.

How is this different from a standard IT risk register? It uses the same discipline but covers risks that are specific to agents: they act, they remember, they read outside content and their behavior can change when a model is updated. The review triggers are therefore tied to model and tool changes as well as to calendar dates. If you already have an IT register, add these entries to it rather than building a parallel document.

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