What is an AI risk register and how do you maintain one?

An AI risk register records the risks a specific system carries, the control applied to each, the person who owns that control, and the date the entry was last tested. Review frequency should follow consequence tier rather than a single calendar rule: critical systems affecting rights or eligibility warrant quarterly review, and lower tiers annually. Most AI governance effort is spent before deployment. The approval is the visible event, the paperwork is produced for it, and attention moves on. Yet almost everything that goes wrong does so afterwards, when the data drifts, the use widens, the vendor changes a model, or the person who understood the system leaves.

How often should AI systems be reviewed after launch?

An AI risk register records the risks a specific system carries, the control applied to each, the person who owns that control, and the date the entry was last tested. Review frequency should follow consequence tier rather than a single calendar rule: critical systems affecting rights or eligibility warrant quarterly review, and lower tiers annually. Most AI governance effort is spent before deployment. The approval is the visible event, the paperwork is produced for it, and attention moves on. Yet almost everything that goes wrong does so afterwards, when the data drifts, the use widens, the vendor changes a model, or the person who understood the system leaves.

What does responsible AI look like inside a UN agency?

An AI risk register records the risks a specific system carries, the control applied to each, the person who owns that control, and the date the entry was last tested. Review frequency should follow consequence tier rather than a single calendar rule: critical systems affecting rights or eligibility warrant quarterly review, and lower tiers annually. Most AI governance effort is spent before deployment. The approval is the visible event, the paperwork is produced for it, and attention moves on. Yet almost everything that goes wrong does so afterwards, when the data drifts, the use widens, the vendor changes a model, or the person who understood the system leaves.

How can UN agencies deploy generative AI securely?

An AI risk register records the risks a specific system carries, the control applied to each, the person who owns that control, and the date the entry was last tested. Review frequency should follow consequence tier rather than a single calendar rule: critical systems affecting rights or eligibility warrant quarterly review, and lower tiers annually. Most AI governance effort is spent before deployment. The approval is the visible event, the paperwork is produced for it, and attention moves on. Yet almost everything that goes wrong does so afterwards, when the data drifts, the use widens, the vendor changes a model, or the person who understood the system leaves.

The AI Risk Register and What Happens After Launch

Last updated: 2026-08-15

An AI risk register records the risks a specific system carries, the control applied to each, the person who owns that control, and the date the entry was last tested. Review frequency should follow consequence tier rather than a single calendar rule: critical systems affecting rights or eligibility warrant quarterly review, and lower tiers annually.

How to maintain an AI risk register, how often AI systems should be reviewed after deployment, and what responsible AI looks like day to day inside a UN agency.

The AI Risk Register and What Happens After Launch

Most AI governance effort is spent before deployment. The approval is the visible event, the paperwork is produced for it, and attention moves on. Yet almost everything that goes wrong does so afterwards, when the data drifts, the use widens, the vendor changes a model, or the person who understood the system leaves.

What an AI risk register is, and is not

The register is not a list of general AI risks. A document explaining that AI systems may exhibit bias is a briefing note, not a control.

An AI risk register records, for one specific system: each identified risk, what happens if it materialises, the control applied, the named person who owns that control, how the control is verified, and when it was last tested. The final two columns are what make it a register rather than an inventory of worries.

It sits alongside the AI model register rather than replacing it. The model register answers "what do we run and who owns it". The risk register answers "what could go wrong with this one and what have we done about it".

Keep one register per system, not one per organisation. Organisation-level AI risk registers list generic concerns and are reviewed by nobody, because no individual recognises their system in them.

Give every entry a verification method. A control with no way to check that it is working is an intention. "Human reviews all rejections" becomes a control when it is paired with "sample of 20 rejections audited monthly by the business owner".

Record the date last tested, and treat a stale date as a finding. Controls decay silently. The gap between a control existing on paper and functioning in practice is usually measured by how long since anyone looked.

How often to review after launch

A single review cadence applied to every system produces both waste and blind spots. Frequency should follow consequence tier, using the risk tiering criteria.

Tier 4, critical. Affects rights, safety, eligibility or livelihood, hard to reverse. Quarterly review, with a named accountable owner at director level and a pre-agreed stopping condition. Between reviews, monitoring runs continuously against the stopping condition.
Tier 3, significant. Affects individuals materially but with appeal and correction routes. Semi-annual review.
Lower tiers. Annual review, and re-tier rather than review more often if the use widens.

Three events should trigger a review regardless of the calendar: the model or vendor version changes, the use case widens beyond what was approved, or an incident occurs. The second is the one most often missed. A system approved to draft text and later used to decide something has changed tier without anyone filing a change.

What responsible AI looks like day to day

Inside an operating agency, responsible AI is not a values statement. It is a small number of things being true on an ordinary Tuesday.

Every AI system in production appears in the model register with two named individuals against it. Each has a written stopping condition and someone who accepts the authority to act on it. Risk entries carry a verification method and a date. Someone reviews a sample of the system's outputs on a schedule, and that sample includes the cases the system found hardest rather than a random draw. Staff have an approved tool and know the five things they must never enter into it, which is covered in LLM security in public institutions. And when something goes wrong, the first move is containment rather than diagnosis, following the incident triage sheet.

None of this requires a new committee. Most of it requires that existing decisions have names attached.

Deploying generative AI securely in an agency

For generative systems specifically, the sequence that works is: decide where inference may happen for each data classification; provide a sanctioned tool so that unapproved use has no reason to exist; ground answers in institutional sources rather than model memory where accuracy matters; keep irreversible actions behind human confirmation; and log at a gateway so there is a record to review.

The governance around that sequence is set out in the AI governance playbook, and the institution-wide view in AI governance in the United Nations.

Written by Shahzad Asghar, Head of Data and Digital Solutions at UNESCWA. See all articles, the playbooks, and the templates.