The Global Risks Forum (GRF)
When an AI system causes harm, someone must be able to find out what happened and answer for it. Oversight relies on documentation, logging, audit, incident reporting and authorities with the powers and skills to use them. Accountability is spread across developers, deployers, boards and regulators, and can dissolve between them. This page sets out how AI oversight holds or fails, the records that show it, and who holds each decision.
GRF · In development · service level R0
AI oversight is the set of duties, records and authorities through which developers and deployers of AI are held to account for its effects. It depends on documentation and logging, regulators with capacity, and incident reporting. Legislatures, regulators, boards and courts hold the decisions.
For ai oversight and accountability, in GRF's situational-awareness reading, the map opens on population density, night lights and flood water with night lights tonight from NASA GIBS, framed on East Asia; 3 further NASA layers wait in the list.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Connected activity, for this page
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
Latest available
NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth
Loading the latest NASA imagery.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
For ai oversight and accountability, in GRF's situational-awareness reading, the map opens on population density, night lights and flood water with night lights tonight from NASA GIBS, framed on East Asia; 3 further NASA layers wait in the list.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place; claim ceiling INTEGRATED.
Layers and dates
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
AI oversight and accountability · Algorithm register · Quarter 2
| Benefit fraud flagging | Social agency | High | Missing | Partial |
| Permit triage | Planning | Limited | Done | Yes |
| School placement | Education | High | Done | Yes |
| Chat assistant | Tax office | Minimal | Done | n/a |
Roles, validation and human review. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
A model developer, a fine-tuner, an integrator and a deploying organization each shape a system's behaviour. When obligations attach to only one of them, the others can point elsewhere after harm.
Without technical documentation, logs and change records, auditors and regulators cannot reconstruct how a system reached an output. Record-keeping duties make later oversight possible.
Market surveillance, data protection and sector regulators need technical staff, access to systems and powers to test them. Thin capacity turns rules into self-assessment.
Failures surface through complaints, journalism and litigation rather than reporting. Mandatory incident reporting and shared incident databases let patterns be seen across deployments.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Serious incident | Under the EU AI Act, an incident or malfunction of an AI system that leads to death, serious harm, serious disruption of critical infrastructure or breach of fundamental rights obligations. |
| Market surveillance authority | A national authority that checks products on the market comply with law and can order corrective action. |
| AI management system | An organization's policies, processes and controls for developing or using AI, as specified in ISO/IEC 42001. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Designated AI supervisory or market surveillance authority | yes or no, with legal basis | on change | National legislation and notifications | OFFICIAL |
| Technical staff in AI-relevant authorities | full-time equivalents | annual | Authority annual reports | REPORTED |
| Serious incidents reported under AI rules | count by sector | annual | Authority records | OFFICIAL |
| Publicly recorded AI incidents | count by harm type | monthly | Incident databases | REPORTED |
| Enforcement actions concerning AI systems | count by authority and type | annual | Regulator enforcement registers | OFFICIAL |
| Organizations certified to ISO/IEC 42001 | count | annual | Certification body records | REPORTED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| OECD.AI Policy Observatory | National AI policies, governance bodies and the AI Incidents Monitor | Free, OECD terms |
| AI Incident Database | Crowd-sourced records of harms involving AI systems | Open, licence to check |
| European Data Protection Board and national authority decisions | Decisions on automated processing and AI-related complaints | Public, EU and national reuse terms |
| Stanford AI Index Report | Data on AI development, policy and incidents | Free to read, licence to check |
| Regulator annual reports | Staffing, priorities and enforcement of authorities supervising AI | Public records, terms per authority |
AI and Digital Governance prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Legislatures | Which obligations attach to developers, deployers and providers of general-purpose models | Comparative regimes and evidence from incidents |
| Market surveillance and sector regulators | Which systems to inspect and what powers to use | Incident records, risk categories and enforcement practice |
| Boards of deploying organizations | Who owns AI risk and what assurance they require | Governance practice and management system standards |
| Courts | Who is responsible for harm caused with an AI system | Records and expert evidence presented by parties; the page serves context only |
Accountability tends to dissolve gradually. Each actor in a long chain of developers, integrators, operators and managers can reasonably point to another as responsible, until no one is.
People tend to defer to automated outputs, especially under time pressure, so human review can become a formality.
Developers, vendors, integrators and users each own part of the system and none owns the outcome.
Models degrade as the world changes, and without monitoring the degradation goes unnoticed.
Structured analysis of risks to rights and outcomes before deployment. Limits: can become paperwork if not tied to decisions.
Testing by people independent of developers, using AI evaluation and assurance engineering. Limits: tests show performance on test data, not in every real situation.
Reviewers with the authority, time, information and training to override. Limits: costly, and hard to sustain at scale.
Logs of inputs, outputs and decisions, with performance tracked over time. Limits: only useful if someone reviews them.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.