AI Governance Engineer
GitHub

Run AI risk as controls you can test.

For the people who own security, operational risk and the second and third lines: where AI risk sits in the framework you already run, what is new about it, and how to show the controls work.

Who this is for.

You already run a risk register, a control library, supplier reviews and incident response. AI replaces none of them. It adds sources of risk they were not built for (prompt injection, agents acting beyond their mandate, drift, poisoned data or memory) and reporting clocks that run in parallel. This route places AI risk in the loop you know, then walks the controls, the threats and the incident path.

  • CISOs and security leads
  • Heads of risk and ERM
  • Model risk managers
  • Internal audit
  • Third-party risk managers

On the learning path, start at Eval harness, Agent registry or Threat modelling.

New to the field? Read AI governance explained: the definition, the frameworks and where engineering fits.

Three questions you bring.

Each one answered in brief here, and in full in the Body of Knowledge.

  1. Where does AI risk sit in the framework we already have?

    In the same register and the same loop (identify, assess, treat, monitor), with AI-specific risk sources, a likelihood-by-severity matrix whose bands trigger gates, and residual risk accepted by a named person with an expiry.

    The loop: identify, assess, treat, monitor

  2. Which threats are new, and what contains them?

    Agents bring goal hijack, tool misuse, identity and privilege abuse, memory poisoning, cascading failures and rogue agents; the OWASP agentic list names ten 1. Each maps to a control that holds at runtime and a pattern that builds it.

    Ten agentic threats and their controls

  3. When it fails, who do we tell, and by when?

    One event can start several clocks at once: a serious incident under the EU AI Act (Art. 73) 2, a personal data breach under the GDPR (Art. 33) 3, and a significant incident under NIS2 4 or a major ICT-related incident under DORA 5. Each has its own trigger, recipient and deadline, so the incident record needs a timestamp per regime.

    The overlapping clocks

Your route through the site.

In reading order: chapters at the section that matters, then the patterns, tools, templates, datasets and figures that turn them into work.

Place the risk

  1. Risk, defined for engineers Chapter 13 · Hazard, harm, likelihood and severity, in terms a gate can read.
  2. The risk loop on the stack Figure · The identify, assess, treat, monitor loop, drawn on the five layers.
  3. The matrix and the S5 override Figure · The likelihood-by-severity matrix and the catastrophic-severity override.
  4. Risk appetite, compiled into gates Chapter 13 · From an appetite statement to data a pipeline enforces.
  5. Risk register entry schema Template · The register row as an evidence record, with an acceptor and an expiry.

Control it

  1. Agentic threats mapped to controls Reference · ASI01 to ASI10, each with the control that contains it and the pattern that builds it.
  2. Adversarial Red-Team Suite Pattern · Red teaming as a repeatable suite whose findings become eval cases.
  3. Kill Switch / Circuit Breaker Pattern · A tested way to stop one agent or endpoint without stopping the fleet.
  4. Agent control profile Tool · The control profile of one agent, written down and kept.
  5. Vendor / Model Due-Diligence Gate Pattern · No third-party model in production without answered questions on file.
  6. Vendor due-diligence request Tool · Build the due-diligence request for one supplier and export it.
  7. Harms atlas Reference · Each harm with its failure mode, the control that catches it and real incidents.

Respond and assure

  1. The overlapping incident clocks Chapter 17 · The AI Act, GDPR, NIS2, DORA and others, side by side.
  2. The overlapping incident clocks Figure · The same clocks on one timeline.
  3. Incident clock Tool · Work out which clocks one incident starts, and their deadlines.
  4. Incident Pipeline Pattern · From detection to report to a new eval case.
  5. Incident record schema Template · One record, many reports.
  6. The three lines and internal audit Chapter 12 · What each line owns for AI, and what internal audit tests.
  7. Incident cases Reference · Public failures read as post-mortems: which control would have caught them.
  8. Maturity self-check Tool · Score the five layers and find the floor before an auditor does.

Start this week.

  1. Enter your AI systems in the enterprise risk register as rows of their own, each with an owner and a residual rating. Risk register entry schema
  2. Write the severity scale down and map each band to a gate and to the reporting clocks it starts. A severity scale mapped to the clocks
  3. Run one red-team session against your most exposed system and file every finding as an eval case. Adversarial Red-Team Suite
  4. Send your main AI suppliers the due-diligence questions and file the answers. Vendor due-diligence response
  5. Drill the kill switch on one agent or model endpoint and record how long the stop took. Kill Switch / Circuit Breaker

The obligations that matter most.

The duties a risk and security function owns or tests: the risk management system, robustness and cybersecurity, post-market monitoring, incident reporting, and the risk and control frameworks that audit reads.

Obligation Applies Evidence
EU AI Act Art. 9 risk management system AIGE-OBL-EUAIA-ART9 Deferred · Risk register as code; threat models; linkage to FRIA and eval results
EU AI Act Art. 15 accuracy, robustness and cybersecurity AIGE-OBL-EUAIA-ART15 Deferred · Eval gate; adversarial red-team suite; robustness and security controls; regression evals
EU AI Act Art. 72 post-market monitoring AIGE-OBL-EUAIA-ART72 Deferred · Continuous assurance telemetry; monitoring plan; drift and performance signals
EU AI Act Art. 73 serious-incident reporting AIGE-OBL-EUAIA-ART73 Deferred · Incident detection and triage pipeline; reporting-clock automation; evidence capture
ISO 23894 · ISO/IEC 23894:2023 guidance on AI risk management AIGE-OBL-ISO23894-RISK Voluntary Risk register as code; AI risk taxonomy; linkage to EU AI Act Art. 9 and the NIST AI RMF
NIST AI RMF · MANAGE AIGE-OBL-NISTRMF-MANAGE Voluntary Runtime guardrails; incident pipeline; continuous assurance
CSA AICM · AICM v1.1: 247 control objectives across 18 domains AIGE-OBL-CSA-AICM Voluntary Control catalogue mapped to policy-as-code and evals; crosswalk to ISO 42001 / NIST AI RMF
OWASP Agentic · Top 10 for Agentic Applications 2026 AIGE-OBL-OWASP-AGENTIC Voluntary Agent threat model; adversarial evals; runtime guardrails; kill switch
ETSI EN 304 223 baseline cyber-security for AI models and systems AIGE-OBL-ETSI-304223 Voluntary AI-system security controls across the lifecycle; supply-chain and AIBOM checks; runtime hardening

Every obligation in the register

Sources

  1. [1] OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10, from agent goal hijack to rogue agents). OWASP GenAI Security Project. 2025-12-09. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (verified: primary)
  2. [2] Regulation (EU) 2024/1689 (Artificial Intelligence Act), consolidated text of 27 July 2026 (Art. 73 reporting of serious incidents). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng (verified: primary)
  3. [3] Regulation (EU) 2016/679 (General Data Protection Regulation) (Art. 33 notification of a personal data breach). Publications Office of the EU (EUR-Lex). 2016-04-27. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng (verified: primary)
  4. [4] Directive (EU) 2022/2555 (NIS2) (Art. 23 reporting obligations for significant incidents). Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (verified: primary)
  5. [5] Regulation (EU) 2022/2554 (DORA) (Art. 19 reporting of major ICT-related incidents). Publications Office of the EU (EUR-Lex). 2022-12-14. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng (verified: primary)

Other routes.

  1. For engineers ML, platform, MLOps, application and security engineers who build and run AI systems.
  2. For legal counsel and DPOs In-house counsel, data protection officers, privacy and compliance leads, and contract managers.
  3. For executives and boards Board members, executive committees, and chief AI, data and technology officers.
  4. For the public sector Public bodies and operators of public services: CIOs, service owners, procurement and oversight.
  5. For SMEs and start-ups Small and medium-sized companies and start-ups, most of them buying more AI than they build.
  6. AIGP candidates The public AIGP body of knowledge read against this site. Not affiliated with or endorsed by IAPP.
  7. Certifications Certifications and assessments in AI governance, and what each one evidences.

Start at the top of the route.

Step 01 is Risk, defined for engineers. Each step after it builds on the one before.

Open step 01 All routes