AI risk register template — 15 risks to enumerate before you ship

A risk register is the shortest useful governance document you can write. It is a plain list of things that could go wrong, with a one-line mitigation for each. Before you ship an AI feature, spending an hour writing one out will save you weeks of firefighting later.

Here are 15 concrete AI risks to enumerate, each with a mitigation you can drop straight into your governance tool.

The 15 risks

• →Bias in outputs — evaluate the model on subgroup metrics before every release and track them over time
• →Model drift — set up a scheduled evaluation job that compares live performance to a fixed reference set
• →Hallucination — require retrieval grounding for factual tasks and add a confidence threshold below which the system refuses to answer
• →Prompt injection — sanitize untrusted inputs, isolate system prompts, and never let user content instruct tool use directly
• →Data poisoning — hash and version training data, restrict who can add to the training corpus, and run integrity checks before ingestion
• →IP leakage in outputs — filter outputs against a known IP corpus and add explicit prompts against reproducing copyrighted material
• →PII leakage in outputs — apply a PII detector to model outputs and redact before returning them to the user
• →Jailbreaks — maintain an evolving red-team suite and run it on every model version before deployment
• →Unauthorized fine-tuning — restrict who can trigger training, require signed pull requests for training data changes, and log every fine-tuning job
• →Supply-chain compromise on a base model — pin base model versions by hash, evaluate on a security suite after every base-model update
• →Energy cost drift — monitor tokens-per-request and GPU minutes, alert when they cross a defined budget
• →Evaluation regression — block deployment on any eval metric drop beyond a defined tolerance, and require sign-off to override
• →Silent quality degradation — sample production outputs for human review at a fixed rate and log dissatisfaction signals from users
• →Third-party API outage — have a graceful degradation path for every external model dependency, ideally a fallback provider or a cached response
• →Over-reliance and automation bias — surface confidence scores in the UI and require human approval for high-stakes actions

How to use the list

For each risk that applies to your system, assign an owner, a severity, and a review date. Anything left without an owner is not a risk in your register — it is a wish. Anything without a review date is a snapshot that will go stale within a quarter.

How Zilonex Govern helps

Zilonex Govern ships this list as a starter risk register that you can clone for any new AI system. Each risk is linked to its mitigation controls, and evidence collection is wired in so that when you run your quarterly review, you already have the metrics and logs at hand.