AI Risk Management and Classification as Code

This chapter turns AI risk management from a periodic workshop into an executable part of the delivery pipeline. Chapter 3 mapped the risk-based structure of the AI Act, and Part II examined the suppliers on which an organisation's AI depends. Part III begins here because classification decides which of the Act's obligations apply to a given system, including those a supplier must help the organisation meet. The chapter shows how to express the risk classification of Regulation (EU) 2024/1689 (the AI Act) as a decision tree that a policy engine can evaluate, how to keep the risk register in version control, and how to re-run both whenever a model, a dataset, or an intended purpose changes. Readers who know Risk as Code from Architecture as Code (Chapter 9C) will recognise the method; what changes is that the risks arise from data, probabilistic behaviour, and fundamental rights rather than from misconfigured infrastructure alone (66, Nordqvist, 2025).

AI risk pipeline from use case intake through classification, impact assessment, register, gate, and continuous re-evaluation

Figure 8.1: The risk pipeline classifies every use case, attaches impact assessments and register entries, evaluates them against the risk appetite at the deployment gate, and re-runs the classification when the system changes.

Why AI risk management needs its own discipline

Classical IT risk management assumes that a system does what its code says and that a control, once implemented, stays implemented; neither holds for AI. A model's behaviour is a statistical property of its training data, so a risk absent at release can appear after retraining, and the harms that matter, such as discrimination or wrongful denial of a benefit, land on individuals outside the organisation. Two frameworks structure the problem: ISO/IEC 23894:2023, which adapts the ISO 31000 risk process to AI (33, ISO/IEC, 2023), and the NIST AI Risk Management Framework, which organises the work into Govern, Map, Measure, and Manage (36, NIST, 2023).

ISO/IEC 23894 names AI-specific sources of risk, such as automation, opacity, and risks that emerge across the lifecycle, and the NIST generative AI profile, NIST AI 600-1, adds risks such as confabulation, information integrity, harmful bias and homogenisation, and value-chain risks arising from components the organisation did not build (37, NIST, 2024).

For providers of high-risk AI systems, Article 9 of the AI Act requires a continuous, iterative process throughout the lifecycle that identifies known and reasonably foreseeable risks to health, safety, and fundamental rights, evaluates them under intended use and reasonably foreseeable misuse, and adopts measures whose residual risk is acceptable (1, European Union, 2024). A risk assessment produced once and never re-opened therefore does not satisfy the obligation; the process has to be wired to the events that change the system.

The AI Act classification as a decision tree

The AI Act assigns obligations by risk tier, and the tier follows from a small number of questions about the system and the organisation's role. Encoding them needs a precise use-case descriptor and rules the legal function has signed off. The descriptor is the AI Decision Record: a version-controlled record, kept for every AI system, that states its intended purpose, user population, data, model, usage mode and the organisation's role, and that changes through reviewed commits. The rules are a policy in the repository.

The tree runs as follows. First, confirm that the system meets the definition of an AI system in Article 3(1). Second, test for prohibited practices under Article 5, such as manipulative techniques, exploitation of vulnerabilities, social scoring, and emotion recognition in workplaces and educational institutions; a prohibited practice ends the evaluation. Third, test for the high-risk category under Article 6: safety components of products under the legislation in Annex I, and systems used in the eight Annex III areas of biometrics, critical infrastructure, education, employment, access to essential services and benefits, law enforcement, migration, and justice and democratic processes (1, European Union, 2024).

Fourth, consider the derogation in Article 6(3): an Annex III system is not high-risk where it poses no significant risk of harm to health, safety or fundamental rights, and it performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing or influencing the human assessment, or performs a preparatory task. The derogation never applies where the system profiles natural persons, and a provider relying on it must document the assessment. Fifth, test for transparency obligations under Article 50, which apply regardless of tier. Sixth, identify whether the organisation acts as provider or deployer, because Article 25 can turn a deployer into a provider.

Worked example: risk-tiering questionnaire

Illustrative example. The tree is easiest to apply as a questionnaire at intake that asks the policy's questions in the same order. Nordvik Region completed the following one for its benefits-triage system, which ranks incoming applications for financial assistance so that caseworkers handle the most urgent first.

# Risk-tiering questionnaire: ai-system/benefits-triage

Owner: Head of Social Services, Nordvik Region | Completed: 2026-05-12
Reviewed by: Legal counsel (AI Act) and Data Protection Officer

| #   | Question                                   | Answer                                       | Basis                  |
|-----|--------------------------------------------|----------------------------------------------|------------------------|
| Q1  | Is it an AI system?                        | Yes. A gradient-boosted model scores each application. | Article 3(1)  |
| Q2  | Does any use fall under Article 5?         | No. The score orders the queue for one benefit only. | Article 5(1)(c)  |
| Q4  | Used in an Annex III area?                 | Yes: eligibility for public assistance.      | Annex III point 5(a)   |
| Q5  | Only a narrow or preparatory task?         | No. The ranking determines how long an applicant waits. | Article 6(3) |
| Q6  | Does it profile natural persons?           | Yes. It evaluates applicants' circumstances. | Article 6(3); GDPR Art. 4(4) |
| Q7  | Interacts with people or generates content?| No. Caseworkers see a score.                 | Article 50             |
| Q8  | What is our role?                          | Deployer. We neither rebrand nor modify it.  | Articles 3(4) and 25   |
| Q9  | Is the deployer a body governed by public law? | Yes.                                     | Article 27(1)          |

Resulting tier: HIGH (Q4 yes, Q5 no, Q6 yes).
Obligations triggered: Article 26 deployer duties, Article 27 FRIA,
Article 49(3) registration, Article 86 explanations, GDPR Article 35 DPIA.

Every answer carries a reference, so a reviewer challenges the basis rather than the conclusion. Q6 is asked separately from Q5 because the profiling exclusion in Article 6(3) overrides every derogation ground and is the answer most often missed when a team describes its system as "only prioritising" (1, European Union, 2024). Chapter 10 shows the fundamental rights impact assessment that this answer triggers.

Encoding the tree as policy

The following Rego policy evaluates a use-case descriptor and returns a tier with its reasons. It uses the same Open Policy Agent dialect that Architecture as Code uses for infrastructure guardrails, so the same engine, test harness, and review workflow apply (40, Open Policy Agent, n.d.).

package ai.risk.classification

import rego.v1

prohibited_practices := {"social_scoring", "subliminal_manipulation",
    "vulnerability_exploitation", "workplace_emotion_recognition",
    "untargeted_facial_scraping"}

annex_iii_areas := {"biometrics", "critical_infrastructure", "education", "employment",
    "essential_services", "law_enforcement", "migration", "justice_democracy"}

prohibited if input.practice in prohibited_practices

# Article 6(3): narrow procedural tasks are exempt unless profiling occurs.
derogation_applies if {
    input.annex_iii_area in annex_iii_areas
    input.task_type in {"narrow_procedural", "preparatory", "pattern_detection"}
    not input.performs_profiling
}

high_risk if {
    not prohibited
    input.annex_iii_area in annex_iii_areas
    not derogation_applies
}

transparency_duty if input.interacts_with_natural_persons

tier := "prohibited" if prohibited
tier := "high" if high_risk
tier := "limited" if {
    not prohibited
    not high_risk
    transparency_duty
}
tier := "minimal" if {
    not prohibited
    not high_risk
    not transparency_duty
}

deny contains "High-risk system lacks a FRIA reference" if {
    high_risk
    input.deployer_is_public_body
    not input.assessments.fria
}

Because the policy reads a descriptor, not the system, require a named owner to sign the descriptor, so that a misleading one is an auditable act. Because it encodes an interpretation, store the approving legal review beside it and re-approve it when Commission guidelines or harmonised standards arrive. The interpretation will change; the mechanism should not.

Worked example: use-case descriptor and policy decision

Illustrative example. Nordvik Region also runs an internal staff assistant, a retrieval-augmented generation (RAG) service that answers caseworkers' questions about internal guidance and drafts routine correspondence. Its descriptor sits in the system's AI Decision Record directory.

{
  "descriptor_id": "UCD-2026-022",
  "system": "ai-system/staff-assistant",
  "decision_record": "AIDR-0211",
  "intended_purpose": "Answer staff questions about internal guidance and draft routine letters for human review",
  "excluded_uses": [
    "Recommending or deciding eligibility for any benefit",
    "Assessing the performance or behaviour of staff"
  ],
  "annex_iii_area": null,
  "task_type": "general_assistance",
  "performs_profiling": false,
  "interacts_with_natural_persons": true,
  "role": "deployer",
  "deployer_is_public_body": true,
  "signed_by": "head-of-digital-services",
  "signed_on": "2026-04-03"
}

The pipeline stores the decision, tier: limited, beside the descriptor with the policy version and commit. The excluded_uses list carries most of the weight: the assistant stays limited-risk only while nobody uses it to recommend eligibility or to assess staff, which would move it into Annex III points 5(a) or 4(b). Naming them makes drifting into them a visible change of intended purpose, which re-runs the classification.

Across the usage modes

The tree classifies a use, not a technology, so the usage mode changes what is classified rather than fixing the tier (see the usage-mode matrix).

Mode Unit of classification Typical tier and role Dominant risk sources
Mode 0 Ambient AI Each supplier feature Minimal; deployer where used under the organisation's authority Features enabled without review
Mode 1 Conversational assistants The tool and its permitted uses Minimal or limited; deployer Data leakage, shadow AI
Mode 2 Embedded workplace assistants The tenant deployment Minimal or limited; deployer Permission sprawl, indirect prompt injection
Mode 3 Agentic work tools The tool, its permissions and skills Minimal; deployer Excessive agency, skill supply chain
Mode 4 Built AI applications Each system and its purpose Any tier; deployer or provider Data, model, drift, fairness
Mode 5 Autonomous production agents Each agent and its delegated authority Any tier; often provider Loss of control at scale

The low tiers in Modes 0 to 3 hold only while the permitted uses hold: an assistant used to filter job applications falls in Annex III point 4(a), and Article 25(1)(c) makes the deployer that repurposed it its provider (1, European Union, 2024). Give every Mode 1 to 3 tool a descriptor with excluded_uses, and run the full tree for each system and agent in Modes 4 and 5.

Impact assessments as pipeline inputs

Impact assessment tells you what could go wrong for whom. The pipeline treats each assessment as a structured artefact with an identifier, an owner, a date, and a review period that the register references and the gate checks.

The data protection impact assessment (DPIA) is required under Article 35 of Regulation (EU) 2016/679 (the GDPR) where processing is likely to result in a high risk, and Article 35(3)(a) names systematic and extensive evaluation based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based (2, European Union, 2016). The fundamental rights impact assessment (FRIA) under Article 27 of the AI Act applies to public bodies, private entities providing public services, and deployers of Annex III systems for creditworthiness and for life and health insurance pricing; Chapter 10 works through its content. Because Article 27 allows the FRIA to build on an existing DPIA (1, European Union, 2024), a shared schema pays off.

ISO/IEC 42005:2025 provides a broader method covering impacts on individuals, groups, and society and integrating with ISO/IEC 23894 (35, ISO/IEC, 2025), and the Assessment List for Trustworthy AI (ALTAI) offers a lighter self-assessment (13, AI HLEG, 2020). Our practice is to run ALTAI at intake, commission the DPIA and FRIA during design, and use ISO/IEC 42005 as the method for both, so that the identified risks flow straight into the register.

The risk register as code

A spreadsheet register has no current version, no link from entry to control, and no way for a machine to detect a stale entry. In the repository, each entry is instead a YAML document validated against a schema, reviewed through a pull request, and linked by identifier to the system, controls, evidence, and assessments it depends on. The entry below is for a benefits eligibility decision-support system.

id: RISK-2026-014
system: ai-system/benefits-eligibility-support
classification: {tier: high, basis: "Annex III point 5(a)", role: deployer}
hazard: "Systematically lower scores for applicants with incomplete digital records"
harm_categories: [fundamental_rights, non_discrimination]
inherent_rating: high
controls:
  - CTRL-FAIR-003   # subgroup evaluation in promotion gate
  - CTRL-OVR-001    # caseworker override with recorded reason
  - CTRL-MON-007    # weekly disparity monitoring
residual_rating: medium
owner: head-of-casework
assessments: {dpia: DPIA-2025-031, fria: FRIA-2026-004}
review:
  period_days: 180
  last_reviewed: 2026-09-15
  triggers: [model_version, training_data_window, intended_purpose, drift_alert]
status: accepted_within_appetite

The controls field is the hinge: each identifier resolves to a policy, a pipeline stage, or a procedure elsewhere in the repository, so an auditor can walk from the risk to the control to the evidence that it ran, which Chapter 11 treats in depth. The review.triggers list names the events that force re-evaluation, and the pipeline reads it.

Worked example: register entry for a generative AI risk

Generative systems need the same schema with two additions: a link to the external risk catalogue the hazard comes from, and a record of the upstream components the organisation did not build.

Illustrative example. At Hansa Mutual, claims handlers use a RAG assistant that answers questions about policy wording. It is not high-risk under the AI Act, but the group risk function holds every AI system to the same register discipline in all seven markets.

id: RISK-2026-031
system: ai-system/claims-wording-assistant
classification:
  tier: limited
  basis: "Article 50 - interacts with natural persons; not in Annex III"
  role: provider_and_deployer   # built in-house on a vendor model
applies_in:                     # regimes vary by jurisdiction
  - {entity: DE, regimes: [ai_act, gdpr, dora]}
  - {entity: PL, regimes: [ai_act, gdpr, dora]}   # claims service centre for several markets
  - {entity: NO, regimes: [gdpr], pending: [ai_act, dora]}   # EEA: applies once incorporated
  - {entity: UK, regimes: [uk_gdpr, uk_operational_resilience]}
  - {entity: CH, regimes: [ch_fadp, finma_expectations]}
catalogue_refs: [nist-ai-600-1:confabulation, nist-ai-600-1:value-chain-and-component-integration]
hazard: >-
  Assistant cites superseded wording, or wording not in the retrieved sources,
  and a claims handler relies on it in a coverage decision
upstream_components:
  - {component: foundation-model/vendor-llm-2026-06, provider_contract: VND-2025-118, change_notice_days: 30}
  - {component: index/policy-wording-v7, data_contract: DC-WORDING-004}
inherent_rating: high
controls:
  - CTRL-RAG-002    # retrieval restricted to wording in force on claim date
  - CTRL-RAG-005    # answer blocked unless every sentence is grounded in a cited passage
  - CTRL-EVAL-011   # weekly golden-set run on 400 wording questions
  - CTRL-VND-003    # vendor model change triggers re-evaluation before cut-over
residual_rating: low
key_risk_indicators:
  - {name: ungrounded_answer_rate, threshold: 0.01}
  - {name: superseded_wording_citations, threshold: 0}
review:
  period_days: 90
  triggers: [model_version, index_rebuild, intended_purpose, kri_breach, vendor_change_notice]
status: accepted_within_appetite

The catalogue_refs field links the hazard to the NIST generative AI profile, so that affected entries can be found by query when the catalogue is revised (37, NIST, 2024). The upstream_components block makes a vendor change notice a re-evaluation trigger, applies_in records the different instruments in each entity, and the key_risk_indicators connect the entry to production monitoring, so a breach re-opens it without anyone having to notice.

Continuous re-evaluation when models and data change

Article 9 requires regular systematic review and updating (1, European Union, 2024). In an Architecture as Code practice, "regular" is implemented as "triggered": a change to a model card, data contract, prompt configuration, or AI Decision Record is a commit to which the pipeline reacts.

The pipeline watches for six classes of change. A new model version, including a silent update behind an API, or a new training data window invalidates every entry with the matching trigger. A change to the intended purpose or user population re-runs the classification entirely, because the tier may change. A drift alert, which compares the distribution of live inputs and outputs and the measured quality with those at release (62, Gama et al., 2014), re-opens the related entries, as does a security incident whose category matches a hazard and a regulatory change that affects a cited article. Mode drift belongs on the same list: when a prompt becomes a shared skill in an agentic tool, or a skill becomes a production agent, treat the move as a change of intended purpose, because the use has moved from Mode 1 towards Mode 5 even if the model has not.

The pipeline then downgrades the entry to review_required, assigns it to the owner, and blocks promotion until the owner reaffirms or revises the residual rating. An entry whose last_reviewed date plus period_days has passed is stale, and the gate treats stale entries as open risks. This mirrors the drift detection Architecture as Code applies to infrastructure (66, Nordqvist, 2025).

Substantial modification deserves particular attention. Article 3(23) defines it as a change not foreseen in the initial conformity assessment that affects compliance or modifies the intended purpose, and Article 25 makes a deployer who substantially modifies a high-risk system its provider (1, European Union, 2024). A fine-tuning run, a changed decision threshold, or a new input feature can each cross that line, so encode the organisation's definition as a rule over the diff between two model cards.

Worked example: substantial-modification rule

Illustrative example. The rule compares the production model card with the proposed one. Changes the provider declared in advance in its change plan, which the conformity assessment therefore covered, pass; anything else on the watched list blocks promotion and opens a legal review.

package ai.risk.substantial_modification

import rego.v1

watched := {"intended_purpose", "user_population", "input_features",
    "base_model", "fine_tuning_dataset", "output_type"}

changed contains field if {
    some field in watched
    object.get(input.previous, field, null) != object.get(input.proposed, field, null)
}

changed contains "decision_threshold" if {
    abs(input.proposed.decision_threshold - input.previous.decision_threshold) > 0.02
}

unforeseen := changed - {f | some f in input.change_plan.predetermined_changes}

deny contains msg if {
    some field in unforeseen
    msg := sprintf("Unforeseen change to %s: legal review required before promotion", [field])
}

deny contains "Deployer change may make the organisation a provider under Article 25" if {
    input.role == "deployer"
    count(unforeseen) > 0
}

The rule does not decide that a change is a substantial modification, which remains a legal judgement; it decides that a human must make the judgement, and records why. A change plan that declares, for example, quarterly retraining on a rolling data window turns routine retraining into a foreseen change, while a new input feature still stops the line.

Risk appetite statements as data

A risk appetite statement is a board-level declaration of how much risk the organisation will accept. In most organisations it is a paragraph that influences nothing; expressed as data, it becomes the threshold set against which the gate evaluates register entries.

risk_appetite:
  version: 2026.2
  approved_by: director-general
  approved_on: 2026-06-10
  rules:
    - {tier: prohibited, decision: never}
    - {tier: high, decision: conditional, requires: [fria, dpia, named_oversight_role, subgroup_evaluation], max_residual_rating: medium}
    - {tier: limited, decision: conditional, requires: [disclosure_to_users, content_marking], max_residual_rating: high}
    - {tier: minimal, decision: allowed, max_residual_rating: high}
  escalation: {residual_above_threshold: executive_risk_committee, stale_entries_tolerated_days: 30}

Versioning matters: the repository history shows the appetite in force when a system was approved, and when the appetite tightens, re-running the gate lists the systems that no longer fit, the portfolio view a chief risk officer wants and rarely has. No committee meets at deployment: its work happened when it approved the policy, the appetite, and the legal interpretation, which the pipeline then applies identically every time.

Nordvik Region and Hansa Mutual

Nordvik Region classifies once and against one regime: the benefits-triage system is high-risk, and the staff assistant (AIDR-0211), which informs no decision about residents, is not. Its harder questions sit outside the AI Act: public-access and archives law turn its risk assessment into a public document, so the register entry has to be written to be read by residents and journalists.

Hansa Mutual classifies the same system several times, which is why its register entry carries an applies_in block. Its underwriting-support model for life and health products is high-risk under Annex III point 5(c) in the EU entities (1, European Union, 2024), yet the Swiss subsidiary assesses the same model against the revised Federal Act on Data Protection (190, Swiss Confederation, 2020). The group therefore keeps one tiering policy and one risk appetite, and lets each entity's overlay add obligations but never remove a group control. Hansa's distinctive risk is that a control satisfied in Hamburg is assumed to be satisfied everywhere.

Summary

AI risk management becomes reliable when it stops being an event and becomes a pipeline. The AI Act's classification becomes a decision tree over a signed use-case descriptor, evaluated by a Rego policy, and the tier drives which impact assessments the gate demands. The register lives in the repository, linking hazards to controls, controls to evidence, and entries to the events that re-open them, so that Article 9's continuous risk management is met by triggered re-evaluation rather than by scheduled meetings, and a versioned risk appetite becomes the threshold the gate enforces.

A classification and a register are inputs to a management system, not the system itself. Chapter 9 builds that system: it codifies ISO/IEC 42001 as an operating model, turns model approval, data use, and deployment into policy as code keyed by the risk tier assigned here, and describes the AI inventory and governance gates that consume the register.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (2, European Union, 2016)
  3. High-Level Expert Group on Artificial Intelligence (2020). Assessment List for Trustworthy Artificial Intelligence (ALTAI) for self-assessment. European Commission. (13, AI HLEG, 2020)
  4. International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management. ISO. (33, ISO/IEC, 2023)
  5. International Organization for Standardization and International Electrotechnical Commission (2025). ISO/IEC 42005:2025 Information technology — Artificial intelligence — AI system impact assessment. ISO. (35, ISO/IEC, 2025)
  6. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. (36, NIST, 2023)
  7. National Institute of Standards and Technology (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. (37, NIST, 2024)
  8. Open Policy Agent Contributors (2025). Open Policy Agent Documentation. Cloud Native Computing Foundation. (40, Open Policy Agent, n.d.)
  9. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
  10. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (190, Swiss Confederation, 2020)
  11. Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M. & Bouchachia, A. (2014). A survey on concept drift adaptation. ACM Computing Surveys, 46(4), Article 44. (62, Gama et al., 2014)