Management as Code for AI Programmes
Chapter 15 ended with an adoption dashboard whose numbers someone has to act on. This chapter gives them a home by extending Management as Code to the AI portfolio. Architecture as Code (Chapter 19) argued that management intent, governance routines, and decision frameworks should be expressed as executable, version-controlled artefacts, and Chapter 23 of that volume showed how codified management interacts with culture and leadership (66, Nordqvist, 2025). AI programmes test that argument hard, because the value of an AI use case is uncertain until measured, the risk changes whenever the model or the data changes, and the organisation must report on both to boards and supervisory authorities. The chapter therefore shows how to run the portfolio as a register, track value, fund platforms and use cases, and steer and report on evidence produced by pipelines rather than on slides.
Figure 16.1: The portfolio control loop for AI programmes, closing from strategic intent through delivery and evidence to steering, which updates the register and reports to the board. Exceptions and waivers are records with an expiry date that return to the register; the supervisory authority receives incident and registration information from the evidence store.
Why AI portfolios need Management as Code
A conventional IT portfolio tracks projects with budgets, milestones, and status colours. An AI portfolio tracks hypotheses about where a probabilistic capability will create value, each of which may be disproved by evaluation, undermined by drift, or invalidated by a change in regulatory classification. Three properties follow. The portfolio changes faster than quarterly reviews can follow. Its state depends on technical evidence, such as evaluation scores, override rates, and cost per transaction, as much as on budget consumed. And it is itself a regulated artefact, because the inventory of AI systems that Chapter 9 described is the same list the steering committee funds and the same list from which high-risk systems must be registered under the AI Act.
Management as Code answers all three: a register in a repository changes as often as the use cases do, pipelines write evidence next to budget figures, and a schema lets one register serve governance, funding, and regulatory reporting.
The use-case portfolio as a version-controlled register
The portfolio register is a directory of files, one per use case, validated in the same pipeline that validates the AI Decision Records, the version-controlled records of architectural decisions about each AI system that extend Nygard's architecture decision records (78, Nygard, 2011), and the algorithm register entries of Chapter 17. Intake is a pull request: a business unit opens one, the platform team and the governance functions review it, and the merge is the approval.
# portfolio/use-cases/UC-2026-031.yaml
id: UC-2026-031
name: Claims correspondence drafting assistant
business_owner: Head of Claims Operations
state: scaling # proposed | discovery | pilot | scaling | operating | retired
value_hypothesis:
statement: >
Drafting first replies to routine claims correspondence with an assistant
reduces handling time without increasing complaint rates.
baseline: {handling_time_minutes: 14.2, complaint_rate: 0.021}
target: {handling_time_minutes: 9.0, complaint_rate: 0.021}
review_date: 2027-03-31
acceptance_criteria:
- {metric: handling_time_minutes, condition: "<= 9.5"}
- {metric: complaint_rate, condition: "<= 0.021"}
- {metric: override_rate, condition: "between 0.05 and 0.20"}
risk:
ai_act_class: limited # Article 50 transparency applies
decision_record: adr/AIDR-0147.md
funding:
model: platform_plus_use_case
platform_charge_monthly_eur: 4200
use_case_budget_eur: 310000
tranche_gate: evidence/UC-2026-031/tranche-3.json
evidence:
evaluation: evidence/UC-2026-031/eval-latest.json
retirement_criteria:
- Complaint rate exceeds baseline for two consecutive months
- Platform model deprecated without approved replacement
Three design choices matter. The state field is a closed vocabulary whose transitions the pipeline enforces against the evidence. The value hypothesis has a baseline and a target, which makes it falsifiable and therefore manageable. And the retirement criteria are written at intake, when nobody is yet attached to the system.
Lifecycle states and the evidence that moves them
| State | Entry evidence | Exit trigger |
|---|---|---|
| Proposed | Intake pull request with hypothesis and baseline | Review decision |
| Discovery | Data access confirmed; legal basis identified | Feasibility report |
| Pilot | AI Decision Record; evaluation plan; DPIA or FRIA where required | Acceptance criteria met or failed |
| Scaling | Pilot evidence; production readiness review | Adoption targets met |
| Operating | Monitoring and drift jobs live | Retirement criteria triggered |
| Retired | Decommissioning record; data disposition confirmed | Archived |
The pipeline enforces this state machine. A steering committee may still move a use case without the evidence, but it must record an exception with an owner and an expiry date, so that management retains discretion without losing accountability (Chapter 9).
Worked example: portfolio exception record
Illustrative example. The claims correspondence assistant above is Hansa Mutual's. Its handling-time target was met in the pilot, but the complaint rate, a lagging indicator, needs three months of data the pilot could not produce. The AI Governance Board allowed the move to scaling regardless, and the decision exists as this file.
# portfolio/exceptions/EXC-2026-012.yaml
id: EXC-2026-012
use_case: UC-2026-031
transition: {from: pilot, to: scaling}
criterion_not_met:
metric: complaint_rate
reason: Fewer than 90 days of post-pilot complaint data available
granted_by: ai-governance-board
granted: 2026-09-11
expires: 2026-12-11
compensating_controls:
- Scaling limited to two of five claims regions until expiry
- Automatic rollback to pilot scope if complaint_rate > 0.024 in any week
closure_condition: complaint_rate <= 0.021 over 90 days, verified by evidence job
on_expiry: revert_state_unless_closed
The on_expiry field matters most: a lapsed exception reverts the use case rather than silently becoming permanent, and the pipeline reads expires to list exceptions approaching expiry on the board's generated agenda.
Managing the portfolio across the usage modes
A portfolio that records only Mode 4 and Mode 5 systems leaves much of the spending and exposure of the other modes of Chapter 2 (usage-mode matrix) outside management view. Each mode therefore gets an entry type at the grain at which it can be managed, as the table at the end of this chapter summarises. Mode 0 ambient AI enters as a supplier-feature entry per licensed product, with an owner but no value hypothesis, because nobody chose it. Mode 1 and Mode 2 tools enter as capability entries with a seat count, the data-protection configuration on which approval depended, and an annual adoption review instead of tranche gates. Mode 3 entries link the permission profile, because their risk lies in what the tool may do, and a Mode 5 entry adds the agent's mandate.
A use that changes mode returns to intake. Hansa Mutual's claims triage assistant, which recommended a route for a handler to confirm, and the claims-triage agent that acts on the core claims system are one line of business but two decisions (AIDR-0024). Supplier release notes and permission changes are therefore intake events.
Value hypotheses and benefit tracking
AI business cases are often written to secure funding and never consulted again; a benefits register updated once a year from numbers the project team supplied is theatre, not tracking. Instead, make the value hypothesis an executable assertion. Its metrics are produced in production by the observability stack that already serves oversight and drift detection, compared with the baseline automatically, and written to the evidence directory, so that the register shows whether each operating use case's hypothesis is currently supported.
Two refinements matter. First, distinguish leading from lagging indicators: handling time moves within weeks, whereas the complaint rate lags by months, so a use case judged on the leading indicator alone is declared a success before its dis-benefits appear. Second, record dis-benefits, such as staff time correcting outputs and the compute cost metered per use case, because a hypothesis that names only the upside is half a hypothesis.
Attribution, counterfactuals, and double counting
Measured benefit is credible only if the organisation can say what would have happened without the system. Staged rollouts provide comparison groups, because units still waiting for a system give a baseline over the same period. Prefer measured to self-reported benefit, since surveys overstate the time assistants save, and claim each benefit once: when two assistants claim the same handling-time reduction, one register entry owns it and the other references it.
Worked example: benefit realisation record with a staged comparison
Illustrative example. Nordvik Region rolled out its internal staff assistant (AIDR-0211) first to about 2,400 staff and then to about 3,200. The second wave gave the Region a comparison group for one quarter.
# portfolio/benefits/UC-2026-061-2026Q2.yaml
use_case: UC-2026-061 # internal staff assistant
benefit_owner: Head of Administrative Services
method:
design: staged_rollout_comparison
treatment: wave 1 units, about 2,400 staff
comparison: wave 2 units before access, about 800 staff
period: {from: 2026-04-01, to: 2026-06-30}
measures:
- metric: drafting_time_minutes_per_standard_letter
treatment: 21.5
comparison: 27.0
classification: measured
- metric: self_reported_hours_saved_per_week
treatment: 2.1
classification: estimate # not used in the benefit figure
dis_benefits:
- {metric: second_line_queries_per_month, change: "+6 %"}
result:
hypothesis_supported: true
limits: Comparison units differ in case mix; effect may be overstated
next_review: 2026-12-31
The survey figure is kept but excluded from the benefit, the distinction a public auditor will ask about.
Objectives and key results for AI
Objectives and key results (OKRs) give the portfolio its direction, and Architecture as Code (Chapter 19) showed how OKRs can be expressed as code and linked to the artefacts that deliver them (66, Nordqvist, 2025). The AI-specific hazard is activity-based key results: "deploy twenty AI use cases by year end" rewards counting and produces twenty pilots and no production systems. Key results for AI should therefore pair an outcome with a constraint, such as a reduction in handling time with complaint rates held, or a cost per transaction within a bound, so that the programme cannot meet the target by sacrificing what it was meant to protect.
Forsgren, Humble, and Kim (2018) made the same argument for software delivery: output measures reward the wrong behaviour, whereas outcome measures paired with stability measures predict organisational performance (70, Forsgren et al., 2018). Key results should also be computed from the evidence directory, because a key result that needs a manual count will be measured once.
Funding models: platform versus use case
Skelton and Pais (2019) distinguished platform teams, which reduce the cognitive load of stream-aligned teams, from the stream-aligned teams that deliver business outcomes (69, Skelton & Pais, 2019). The distinction maps onto funding, because the AI platform is a shared capability whose value appears in the use cases that consume it. Funded as a project, it is cancelled when the first use case disappoints; funded as a product with a stable budget, it accumulates the reusable components that let the tenth use case cost a fraction of the first.
The model that works in large organisations is therefore a hybrid. The platform is funded centrally as a product. Use cases are funded in tranches by the business units that own them, each released against evidence: discovery against confirmed data access and a legal basis, pilot against an approved AI Decision Record, scaling against acceptance criteria met. A platform charge in the register makes the shared cost visible beside the benefit. The tranche model fits Mode 4 and Mode 5; conversational and embedded assistants are licensed per seat and are better funded as a platform service with an annual adoption review.
Autonomous production agents add a consumption envelope per period and a cost per completed action, with a hard cap enforced at the gateway. Evaluation and assurance are paid by the platform, so that nobody saves money by testing less, while exit is paid by the use case through a provision set at intake.
Hansa Mutual's platform is funded at group level and charged to the national entities. Because DORA Article 5(2)(g) requires each EU entity's management body to allocate and periodically review the budget for digital operational resilience (3, European Union, 2022), the register's funding fields show each entity what it pays for.
Public authorities face annual appropriations, which sit awkwardly with continuous platform funding. The practical response is to secure the platform as a standing operating cost with a multi-year mandate, and to size each use-case tranche to fit within a budget year.
Steering committees that consume evidence
Under Management as Code, the steering committee's agenda is a query on the register and the evidence directory: changed states, failing acceptance criteria, exceptions approaching expiry, incidents above a severity threshold, and tranches awaiting release. The decisions are pull requests, with the committee's approval recorded as the merge.
ISO/IEC 42001 requires top management to review the AI management system at planned intervals, considering performance, monitoring results, and corrective actions (32, ISO/IEC, 2023). A committee that runs on generated evidence satisfies that requirement as a by-product; one that runs on slides must reconstruct the evidence for the auditor afterwards.
The portfolio and the decision forums
Chapter 13 routes each AI decision to one of four tiers by risk class, and the portfolio register is the object the forums share. Most state transitions should be taken by tier 1 pipeline gates when the evidence meets the acceptance criteria, while the tier 3 governance board decides exceptions and tranches above its threshold. The register records which tier decided each transition, so that decisions taken too low for the risk show in the data. Where consultation duties apply, moreover, an entry cannot move to scaling until each consultation with employee representatives is recorded.
Worked example: AI Governance Board decision rights as code
Illustrative example. Hansa Mutual keeps the terms of reference of its AI Governance Board in governance/forums/ai-governance-board.yaml, shown in Chapter 13. The file below, kept beside it, makes the board's rights executable: which decisions it takes, which it delegates, the approvals each requires, and when it must escalate. The repository's ownership rules then reject a merge that lacks a required approval.
# governance/forums/ai-governance-board.decision-rights.yaml
forum: ai-governance-board
decision_rights:
- decision: approve_intake
scope: "ai_act_class in [minimal, limited] and budget_eur <= 150000"
delegated_to: ai-portfolio-office
- decision: approve_intake
scope: "ai_act_class == high or budget_eur > 150000"
decided_by: ai-governance-board
required_approvals: [chief-risk-officer, data-protection-officer]
- decision: grant_exception
decided_by: ai-governance-board
max_duration_days: 90
required_fields: [owner, expires, compensating_controls, on_expiry]
- decision: release_tranche
scope: "tranche_eur > 500000"
decided_by: ai-governance-board
required_consent: chief-risk-officer
- decision: classify_ict_incident
delegated_to: incident-manager
note: DORA Art. 18 classification runs on the incident clock, not the board's
escalation:
to: executive-board # the management body for DORA purposes
when:
- residual risk exceeds risk appetite statement RA-2026-04
- a decision would depart from the ICT risk management framework
enforcement:
repository_rules: .github/CODEOWNERS
pipeline_check: scripts/check_decision_rights.py
The classify_ict_incident entry makes explicit that a regulatory clock is never subordinated to the board's calendar, a point the section on regulatory reporting develops.
Reporting to boards and supervisory authorities
Boards want to know whether the AI programme creates value, controls its risks, and complies; supervisory authorities want evidence of the last two. Both can be served from the same register if the report is a projection rather than a composition, generated by the pipeline from measured hypotheses, incident records, and passed gates, and stamped with the commit it was generated from. Anyone who questions a figure can check out that commit and recompute it, which reports assembled by hand cannot offer.
What the management body must be able to show
Two instruments make oversight of AI a legal duty of the management body. DORA Article 5(2) makes the management body of a financial entity responsible for defining, approving, and overseeing the ICT risk-management framework, and Article 5(4) requires its members to keep their knowledge up to date (3, European Union, 2022). NIS 2 Article 20 requires the management bodies of essential and important entities to approve and oversee the measures of Article 21, makes them answerable for infringements, and requires their members to follow training (4, European Union, 2022). The report is therefore evidence of oversight: each duty needs a computed indicator, a decision recorded as a merge, and a training record.
Worked example: monthly AI risk report to the management body
Illustrative example. Hansa Mutual's management body receives a monthly AI risk report rendered by the pipeline; the chief risk officer adds the commentary and approves the pull request that publishes it.
# AI risk report to the management body: October 2026
Hansa Mutual. Generated from portfolio@b41e9d0 on 2026-11-03.
## 1. Position against risk appetite (RA-2026-04)
| Indicator | Appetite | Oct 2026 | Trend |
|--------------------------------------------|----------|----------|--------|
| High-risk AI systems with incomplete deployer evidence | 0 | 0 | stable |
| Open exceptions past expiry | 0 | 0 | stable |
| Agents with write tools lacking approval gate | 0 | 0 | stable |
| Models with unresolved drift alert > 14 days | <= 1 | 2 | worse |
| AI spend on critical-function ICT services without exit plan | 0 % | 6 % | worse |
## 2. Incidents and near misses
- INC-2026-118 (minor, not reportable under DORA Art. 19): claims RAG assistant
cited a superseded policy wording for 41 hours; 312 drafts affected, all
reviewed by adjusters before sending. Ingestion now rejects documents
without a validity date.
## 3. Items outside appetite
- Drift: UC-2025-007 (fraud triage) retraining scheduled for 2026-11-14;
UC-2026-004 (subrogation scoring) moved to shadow mode pending review.
- Exit plans: the document-extraction service (6 % of AI spend) lacks a tested
exit plan under DORA Art. 28(8). Plan due 2026-12-15.
## 4. Decisions requested
1. Note the two items outside appetite and the remediation dates.
2. Approve retirement of UC-2025-019 (motor glass triage) on 2026-12-31.
## Chief Risk Officer's commentary
The exit-plan gap is the item I would ask the management body to follow most closely.
The report leads with the computed risk appetite table, because that is what the management body is accountable for, and confines narrative to one signed commentary, so the reader can tell what the pipeline measured and what a person judged.
Group and entity reporting
A multinational group cannot meet its duties with one report. Every EU financial entity's management body carries the DORA Article 5 responsibility for its own ICT risk (3, European Union, 2022), and Solvency II requires an effective system of governance in each insurance undertaking as well as at group level (184, European Union, 2009). The design that works is one register with several projections, each selecting the systems an entity depends on and stating whether each obligation applies as law or as group policy, with a reconciliation check across levels.
Worked example: entity report profiles
Illustrative example. Hansa Mutual generates its entity reports from the same register as the group report; two of its entities are shown.
# reporting/profiles/entities.yaml
source: portfolio/ # one register for all levels
group:
recipient: executive-board # management body for DORA purposes
entities:
- entity: NO
recipient: hansa-no-board
scope: {applies_in: [NO], include_platform_dependencies: true}
obligations:
AI_ACT: group_policy # until incorporated into the EEA Agreement
DORA: per_eea_incorporation_status
SOLVENCY_II: law
- entity: UK
recipient: hansa-uk-board
scope: {applies_in: [UK], include_platform_dependencies: true}
obligations:
AI_ACT: group_policy
DORA: not_applicable # UK operational resilience regime instead
UK_GDPR: law
reconciliation:
check: every system in an entity report appears in the group report
on_failure: block_publication
The obligations map separates law from group policy for each board.
Across the usage modes
Modes 4 and 5 are reported system by system; Modes 0 to 3 are reported in aggregate, because the management body governs them through policy and configuration rather than individual approvals.
| Mode | Register entry | Example indicators | Funding basis |
|---|---|---|---|
| Mode 0 Ambient AI | Supplier feature | AI features enabled, reviewed, disabled | Bundled in licences |
| Mode 1 Conversational assistants | Capability | Seats, literacy coverage, shadow-AI findings | Per seat |
| Mode 2 Embedded workplace assistants | Capability | Oversharing findings, leakage incidents | Per seat |
| Mode 3 Agentic work tools | Capability with permission profile | Permission exceptions, agent-caused incidents | Per seat or consumption |
| Mode 4 Built AI applications | Use case | Hypotheses supported, drift alerts, FRIA status | Tranches and platform charge |
| Mode 5 Autonomous production agents | Use case with mandate | Actions outside mandate, stops | Consumption envelope |
For Hansa Mutual the aggregate rows are not optional, because supplier features switched on inside licensed software are part of the ICT third-party risk that DORA Article 28 governs (3, European Union, 2022).
Regulatory reporting
Some reporting duties run faster than any steering cycle. Under Regulation (EU) 2024/1689, the AI Act, providers of high-risk systems must operate post-market monitoring under Article 72 and report serious incidents to market surveillance authorities under Article 73, with deadlines measured in days, and deployers that identify a serious incident must inform the provider without delay under Article 26(5) (1, European Union, 2024). Financial entities under Regulation (EU) 2022/2554, DORA, must classify ICT-related incidents and report major ones under Article 19, again within short time limits laid down under Article 20 that run from hours to days (3, European Union, 2022). An AI incident at a bank may trigger both.
Incident reporting therefore cannot wait for a committee: the pipeline classifies the incident record against each regulation's thresholds and notifies the roles in the decision-rights model with a draft notification. The committee reviews what was reported; it does not decide whether to report. Separating the obligation, fixed in law, from the discretion that belongs to management is the core of Management as Code applied to regulated AI.
Nordvik Region and Hansa Mutual
Hansa Mutual's register spans every usage mode. The group report goes to the executive board in Hamburg, and each entity board receives a projection labelling each obligation as law or group policy: the AI Act is law in the EU entities and group policy in Norway, pending EEA incorporation, and in the United Kingdom and Switzerland, under their own regimes. A use case reaches scaling in Germany, the Netherlands or Sweden only when the works council or union consultation for that market is recorded.
Nordvik Region steers a smaller portfolio under political accountability. The regional executive committee decides deployments that affect residents' rights, and the register entry links to its public minute; benefits are measured in caseworker time and service to residents; and funding follows annual appropriations, which makes the platform-versus-use-case model a budget negotiation as much as a design. Its portfolio reports are public documents that elected members and residents must understand, whereas Hansa's must reconcile one group portfolio with the duties of several regulated entities.
Summary
AI portfolios change too often, depend too much on technical evidence, and carry too many regulatory duties to be managed from slide decks. Management as Code makes the portfolio a version-controlled register whose entries carry falsifiable value hypotheses, closed lifecycle states, evidence links, and retirement criteria written at intake. Value is tracked against baselines with dis-benefits named and survey estimates kept apart from measured benefit; key results pair outcomes with constraints; and the platform is funded as a product, use cases in evidence-gated tranches.
Steering runs through the forums of Chapter 13. Reports are projections of the register anchored to a commit, designed as evidence that the management body met its duties under DORA Article 5 and NIS 2 Article 20, and a group projects the same register into one report per entity. Incident reporting runs on the pipeline's clock rather than the committee's.
The register does not yet tell the forum whether to keep paying for each use case; Chapter 16A answers that by treating cost as rigorously as value. Chapter 17 then closes Part IV with the public sector: legal basis, transparency, algorithm registers that are the public counterpart of the portfolio register, and fundamental rights impact assessment.
Sources
- Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
- Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. Portland, OR: IT Revolution Press. ISBN 978-1-942788-33-1. (70, Forsgren et al., 2018)
- Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland, OR: IT Revolution Press. ISBN 978-1-942788-81-2. (69, Skelton & Pais, 2019)
- European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
- International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO, December 2023. (32, ISO/IEC, 2023)
- European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
- European Parliament and Council of the European Union (2009). Directive 2009/138/EC on the taking-up and pursuit of the business of Insurance and Reinsurance (Solvency II) (recast). Official Journal of the European Union, L 335, 17 December 2009. (184, European Union, 2009)
- European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
- Nygard, M. Documenting Architecture Decisions. Cognitect blog, 15 November 2011. (78, Nygard, 2011)