Best Practices and Lessons Learned

Chapter 20 catalogued how AI programmes fail; this chapter distils the book into the practices that prevent those failures. The pieces built in Chapters 1 to 20 are reassembled in the order in which a programme meets them, from intake to retirement, and then viewed through the three tensions named in Chapter 1: speed versus control, autonomy versus accountability, and innovation versus sovereignty. The chapter closes with a practice checklist that belongs in version control and the twelve lessons I would hand to a chief architect starting an AI programme tomorrow.

The six lifecycle stages of an AI system from intake to retirement, with the three tensions that cut across them

Figure 21.1: The practice map arranges the book's practices by lifecycle stage and shows the three tensions that cut across all of them (the table below).

Stage Practices
Intake Declared intent; risk classification; portfolio priority
Design Reference architecture; data contract; oversight mechanism
Build Prompts as code; promotion pipeline; signed provenance
Assure Evaluation pyramid; generated evidence; governance gates
Operate Drift monitoring; post-market duties; cost and energy
Retire Retirement criteria; archive and revoke; register update

Table for Figure 21.1: Practices by lifecycle stage.

The three tensions are speed versus control (make control fast), autonomy versus accountability (bound autonomy in code) and innovation versus sovereignty (keep options open). They are resolved through the practice checklist, the evidence manifest and the portfolio register respectively.

From catalogue to practice

A best practice is a remedy that has been generalised. Each practice points to the chapter where it is codified, so the chapter repeats little; it organises. Where a practice is primarily engineering, the chapter states the governance requirement, which is what a forum or a gate checks, and leaves the method to the platform teams.

Two external frameworks provide the skeleton. ISO/IEC 42001 (32, ISO/IEC, 2023) describes an AI management system as a plan-do-check-act cycle, and the NIST AI Risk Management Framework (36, NIST, 2023) describes four functions: govern, map, measure and manage. The lifecycle stages below are compatible with both: intake and design are where you map, build and assure where you measure, operate and retire where you manage, and governing runs across all six. Where the AI Act, Regulation (EU) 2024/1689 (1, European Union, 2024), assigns an obligation to a stage, the practice names the article, as in the mapping of Appendix A.

Practices by lifecycle stage

Intake

Intake practices cost little and prevent the most expensive failures. Record the intended purpose, the prohibited uses and the affected population in an AI Decision Record before anybody opens a notebook, following the declared intent principle of Chapter 4. Classify the system against the AI Act risk tiers using the decision tree of Chapter 8, and record the reasoning so that it can be re-evaluated when scope changes, because a chatbot that starts as an information service becomes a high-risk AI system under Annex III the moment it influences access to a public benefit.

Hansa Mutual's motor claims unit, for example, first asked for "something like a chatbot that reads the claim file and tells them what to do". Its completed intake record, UC-2026-052, turned that into a summarisation tool for about 180 adjusters with three explicit prohibitions (no payment recommendations, no fraud scoring, no health or injury claims), a provisional classification with the conditions that would reopen it, and a falsifiable value hypothesis: file review from 26 to 15 minutes with no increase in reopened claims.

Prioritise with a portfolio, not a queue: the portfolio register of Chapter 16 exists so that candidates are chosen on value, risk and platform fit rather than on who asked first. Public authorities add a legal-basis check, because an administrative decision supported by AI must rest on a mandate in law and Article 22 of the GDPR constrains fully automated decisions with legal effect.

Design

The governance task at design is to make sure the design decisions are taken and recorded, not to take them all itself. The design must cover the retrieval, guardrails, integration and oversight around the model; a data contract declares lawful basis, retention and quality expectations before the data is used; and the sourcing decision is taken with the sovereignty posture of Chapter 6 and the vendor assessment of Chapter 7 in hand.

Design human oversight as a mechanism, not a paragraph. Article 14 of the AI Act requires that high-risk AI systems be designed so that natural persons can oversee them, intervene and halt them, which architecturally means an interruption path, a role with authority, a log of overrides and an interface that shows what the system did and why (Chapter 10). For agents, approve the permission manifest, which states the tools and data an agent may use and the actions that need human approval, before the first tool is connected; for personal data, run the DPIA at design time and, for public bodies and private entities providing public services deploying high-risk AI systems, the FRIA required by Article 27.

Require a threat model, a guardrail policy written as code and a cost estimate before build, because security and cost retrofits are harder than designs. The threat model can start from published catalogues such as the OWASP Top 10 for LLM applications (38, OWASP, 2025) and MITRE ATLAS (42, MITRE, n.d.).

Build

The governance requirement at build is traceability. Everything that determines behaviour, from code and prompts to evaluation sets, guardrail configuration, model references and infrastructure, is versioned, reviewed and promoted through evaluation gates, so that any production output can be traced to an approved configuration. The ML Test Score of Breck and colleagues (54, Breck et al., 2017) helps find the gaps between a working notebook and a deployable system.

Build on the platform, which makes the second system cheaper than the first and keeps controls and evidence uniform. Propagate identity through every integration so that each action is attributable to a person or a service with declared authority. Require signed provenance for models and datasets, as SLSA does for software artefacts from Build level 2 upwards (45, OpenSSF, n.d.), and keep the architecture repository current, because the technical documentation of Article 11 and Annex IV is generated from it.

Prompts deserve the same discipline. Nordvik Region's staff assistant first ran with a workshop prompt asking the model to answer "as well as you can" and "be friendly", which nothing can be evaluated against. The reviewed version, recorded under AIDR-0211, states the source boundary, the refusal for questions about a named person's eligibility, the handling of expired guidance and of instructions embedded in retrieved text, and a length limit, each mapped to a test case. The prompt is one control among several, however: the gateway's guardrails and the retrieval permissions remain the security boundary.

Assure

Assure is where the organisation shows that the system does what the record says. Evaluate at every level, from data tests and model metrics through behavioural tests and red teaming to human evaluation against governed golden datasets, with acceptance criteria as code. Where a model acts as a judge, calibrate it against human judgement, because judge models show position, verbosity and self-enhancement biases (64, Zheng et al., 2023).

Generate the evidence rather than collecting it. The evidence manifest of Chapter 11 names every artefact that supports a claim, and the documentation pipeline builds the Annex IV technical file from the repository. Run the internal algorithmic audit framework of Raji and colleagues (57, Raji et al., 2020) before an external party asks, and keep the gates of Chapter 9 in the pipeline so that approval is a recorded event with evidence attached. Conformity assessment under Article 43 is then a destination the architecture was designed to reach, rather than an exercise in reconstructing evidence from memory.

Operate

Operate is where probabilistic systems reveal their nature. Monitor data drift and concept drift as separate signals, trace agent actions comparably across systems, treat sampled human review as a quality signal, and set service level objectives for quality as well as latency. The OpenTelemetry semantic conventions for generative AI give such traces a common vocabulary (41, OpenTelemetry, n.d.).

Run the post-market monitoring of Article 72 and the serious incident reporting of Article 73 as runbooks with owners and timers, keep the logs Article 12 requires for the periods Article 19 specifies, and give deployers' Article 26 monitoring duties the same operational treatment. Re-evaluate risk (Chapter 8) whenever a model, prompt, data source or operating context changes, triggered by a pipeline signal rather than a calendar reminder.

Retire

Retirement is the stage most programmes forget. Every AI Decision Record states retirement criteria, such as a performance floor, a review date or a legal change that invalidates the purpose, and these are monitored like drift. When one is met, retirement enters the portfolio register as a planned change with an owner and a budget. Archive what is needed to explain past decisions, remove credentials, tool permissions and gateway routes, and update the inventory and, for public bodies, the algorithm register, because a retired system that still has a live service account is an unbounded agent waiting for an instruction.

When Nordvik Region replaced its travel-allowance claim scorer, the first request was a service desk ticket to "switch off the old model", which would have stopped traffic and left everything else running. The decommissioning record it now requires covers the identities and grants that outlive the model:

# portfolio/retirements/NR-ALG-2022-011.yaml
system: NR-ALG-2022-011
name: Travel-allowance claim scoring
retirement_trigger: Replaced by NR-ALG-2026-009 (AIDR-0203)
owner: Head of Payroll Services
planned_date: 2026-11-30
steps:
  - {id: R1, action: Route all traffic to replacement, evidence: gateway-route-diff}
  - {id: R2, action: Disable service account svc-tas-scoring, evidence: iam-audit-log}
  - {id: R3, action: Revoke tool and database grants, evidence: grant-report}
  - {id: R4, action: "Archive model, lineage, and evaluation results", evidence: archive-manifest}
  - {id: R5, action: Retain decision logs until appeal periods close, evidence: retention-policy}
  - {id: R6, action: Update AI inventory and public register status, evidence: register-commit}
archive:
  retain_until: 2031-12-31
  reason: decisions remain explainable for the appeal and audit period
sign_off: [system-owner, data-protection-officer, security-officer]

Across the usage modes

The six stages apply in full to systems the organisation builds. For the other usage modes of Chapter 2 the organisation buys or is handed the capability, so practice shifts from build and assure towards intake, configuration and operation.

Usage mode Where practice concentrates Defining practices
Mode 0 Ambient AI Intake and operate Detect supplier-enabled features; register, configure or disable each
Mode 1 Conversational assistants Intake and operate One sanctioned service behind the gateway, data loss controls, literacy before access
Mode 2 Embedded workplace assistants Design and operate Permission and labelling clean-up before enablement, audit log review
Mode 3 Agentic work tools Design and operate Sandboxed execution, scoped short-lived credentials, approval for irreversible actions
Mode 4 Built AI applications All six stages AI Decision Record, evaluation gates, generated evidence, retirement criteria
Mode 5 Autonomous production agents All six, design and operate strengthened Permission manifest, spend limits, kill switch, promotion from Mode 4 as a new decision

The checklist below is written for Modes 4 and 5. For Modes 0 to 3 the organisation acts as a deployer, and the practices are those of a careful buyer: know what is switched on, decide who may use it, and control what it can reach.

Practices for the three tensions

Speed versus control

The organisations that resolve this tension make control fast. Forsgren, Humble and Kim (70, Forsgren et al., 2018) showed that elite performers deploy more often with lower change failure rates, and that lightweight, automated approval outperforms heavyweight external review. An AI programme therefore encodes its controls as pipeline gates, policy as code and golden paths: a team on the golden path never waits for a meeting, and a team that leaves it meets a time-boxed exception process. Measure lead time from intake to production for compliant use cases and treat a rising number as a governance defect.

Autonomy versus accountability

Autonomy is granted, bounded and revocable. The permission manifest, tool allow-list, approval gates and spend limits express the bound in code, and propagating the identity on whose behalf an agent acts keeps accountability through delegation. Human oversight under Article 14 is an interruption path with authority rather than a reviewer who rubber-stamps. Expand autonomy in steps justified by evaluation evidence and recorded in the AI Decision Record, and contract it automatically when monitoring shows the evidence no longer holds.

Innovation versus sovereignty

Sovereignty is a set of architectural options kept open, not a refusal to use what is available. The posture of Chapter 6, applied per workload, makes explicit where data may reside, which jurisdictions may reach it, whether weights must be inspectable and what the exit path is. Open-weight models, European cloud providers and the EuroHPC AI Factories (25, EuroHPC JU, n.d.) widen the option set; the EU model contractual AI clauses (18, European Commission, 2023) and the exit strategies of Chapter 7 keep it open after signature. Innovate at the edges, where experimentation is cheap, and keep the core, which holds personal data and decisions with legal effect, on infrastructure the organisation controls.

Keeping governance and platform decisions consistent

AI governance decides and the platform carries the decisions out, but the two drift apart: a forum raises an evaluation threshold the platform never receives, or a waiver outlives the configuration it excused. Four practices keep them consistent.

First, keep one record system: forum decisions, waivers, risk acceptances and AI Decision Records live in the same repository under stable identifiers, so that a decision minute such as Hansa Mutual's DEC-2026-031 in Chapter 13 cites the records it affects. Second, make the link machine-checked: a pipeline job verifies that every threshold, data class and approved model in the platform's policy modules traces to a governance decision, and reports a dangling reference in either direction as a failed gate. Third, define which platform changes reopen governance: a change of model provider, hosting jurisdiction, data source or tool permission reopens the classification of Chapter 8, may change the sovereignty posture of Chapter 6 and, for a public authority, the algorithm register entry of Chapter 17, so name those triggers in the decision-tier policy of Chapter 13. Fourth, review the two sides together in one management review pack. In Nordvik Region a proposed change to AIDR-0211 is routed automatically to the data protection officer and the approving forum; in Hansa Mutual the market liaisons of Chapter 12 receive every platform change that alters the evidence an entity presents to its supervisor.

The practice checklist as code

The checklist gathers the practices in machine-readable form. Each item names the stage, the obligation or principle it serves, the evidence that demonstrates it and the chapter that explains it; a pipeline stage evaluates it against the evidence manifest of Chapter 11 and reports to the production readiness review.

# ai-practice-checklist.yaml
apiVersion: ai-architecture.example.org/v1
kind: PracticeChecklist
metadata:
  name: enterprise-ai-baseline
  version: 1.0.0
  review_cycle_days: 90
items:
  - {id: intake-declared-intent, stage: intake, basis: [AI Act Art. 9, Principle 1],
     evidence: ai-decision-record, chapter: 4}
  - {id: intake-risk-classification, stage: intake, basis: [AI Act Art. 6, Annex III],
     evidence: classification-policy-result, chapter: 8}
  - {id: design-data-contract, stage: design, basis: [GDPR Art. 5, GDPR Art. 6],
     evidence: data-contract, chapter: 3}
  - {id: design-human-oversight, stage: design, basis: [AI Act Art. 14],
     evidence: oversight-checklist, chapter: 10}
  - {id: design-agent-permissions, stage: design, basis: [Principle 4, Principle 7],
     evidence: agent-permission-manifest, chapter: 4}
  - {id: assure-evaluation-gates, stage: assure, basis: [AI Act Art. 15],
     evidence: evaluation-report, chapter: 13}
  - {id: assure-technical-documentation, stage: assure, basis: [AI Act Art. 11],
     evidence: documentation-build, chapter: 11}
  - {id: operate-logging-retention, stage: operate, basis: [AI Act Art. 12, AI Act Art. 19],
     evidence: retention-policy, chapter: 11}
  - {id: retire-criteria-monitored, stage: retire, basis: [Principle 5],
     evidence: ai-decision-record, chapter: 16}
  - {id: governance-platform-consistency, stage: operate, basis: [ISO/IEC 42001 Cl. 9.3],
     evidence: decision-trace-report, chapter: 21}

Regulated sectors add items for DORA, NIS 2 or sector law, and public authorities add the FRIA and the algorithm register entry of Chapter 17, in the same file, so that it remains the single statement of what "ready" means.

Twelve lessons learned

Each lesson is a sentence a steering committee can test itself against.

  1. Architect the system, not the model. The model is one replaceable component; the value and the risk live in the whole.
  2. Fund the platform before the fifth pilot. Without a gateway, an evaluation service and guardrails, no pilot reaches production.
  3. Make the sanctioned path the fastest path. Shadow AI is a demand signal; answer it with enablement rather than prohibition.
  4. Declare intent before data. Without purpose, prohibited uses and affected populations, classification, lawful basis and oversight cannot be designed.
  5. Treat prompts, evaluation sets and policies as code. Anything that determines behaviour belongs in version control with review, evaluation and rollback.
  6. Evaluate continuously; never approve by demonstration. Without a baseline, a system cannot be said to have regressed or improved.
  7. Bound autonomy in code and expand it with evidence. Permission manifests, allow-lists and spend limits are the security boundary; the model's instructions are not.
  8. Generate evidence; do not collect it. Documentation built from the repository stays true; documentation assembled by hand decays.
  9. Design human oversight as a mechanism with authority. An interruption path, an override log and a role that may halt the system are what Article 14 describes; a reviewer without those is decoration.
  10. Keep sovereignty as an option set, not a slogan. Decide per workload where data resides, who may reach it and how to exit.
  11. Treat cost and energy as architectural constraints. Routing, caching and right-sizing designed in are cheap; retrofitted, they are a programme of their own.
  12. Define retirement on the day of approval. A system without retirement criteria becomes the model nobody retires.

Most of these lessons carry over from the Architecture as Code discipline (66, Nordqvist, 2025): state what the system should be, keep that statement under version control, and make the pipeline show that reality matches it. AI programmes simply forget them more often, under more pressure.

Nordvik Region and Hansa Mutual

For Nordvik Region the practices that matter most strengthen a deployer and a public body. Its staff-assistant prompt (AIDR-0211) and its decommissioning record show intent, evaluation and retirement written into artefacts that can be disclosed and archived. Its priorities are procurement that carries evidence and exit, transparency records generated from operations, oversight caseworkers can exercise, and literacy for about 6,000 staff.

For Hansa Mutual the priorities make a builder safe at scale and across borders. The motor claims intake shows the first: state the decision, the data and the markets before building. The others follow from its footprint: one group policy with national overlays expressed as data, evidence that projects per supervisor, a notification path per jurisdiction, and tight containment for its Mode 3 and Mode 5 agents. Chapter 23 draws these threads together for each organisation.

Summary

By lifecycle stage, the practices run from declared intent and classification at intake, through designed oversight, versioned prompts, evaluation gates and generated evidence, to monitoring and deliberate retirement. By tension, they resolve speed against control by making control fast, autonomy against accountability by bounding autonomy in code, and innovation against sovereignty by keeping options open and recording the trade-offs.

The checklist turns the chapter into an artefact a pipeline can evaluate, and the twelve lessons into a conversation a steering committee can have, while keeping governance and platform decisions consistent makes sure the two halves stay one programme.

This chapter closes Part V. Chapter 22 opens Part VI and asks which of these practices will change as the technology and the regulatory calendar evolve.

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. International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. ISO. (32, ISO/IEC, 2023)
  3. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. (36, NIST, 2023)
  4. Breck, E., Cai, S., Nielsen, E., Salib, M. & Sculley, D. (2017). The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. Proceedings of the 2017 IEEE International Conference on Big Data. (54, Breck et al., 2017)
  5. Raji, I. D., Smart, A., White, R. N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. & Barnes, P. (2020). Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing. Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency. (57, Raji et al., 2020)
  6. Nordqvist, G. Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
  7. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. (70, Forsgren et al., 2018)
  8. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. OWASP GenAI Security Project. (38, OWASP, 2025)
  9. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (42, MITRE, n.d.)
  10. OpenTelemetry Authors. OpenTelemetry Documentation, including the Semantic Conventions for Generative AI systems. Cloud Native Computing Foundation. (41, OpenTelemetry, n.d.)
  11. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA). (45, OpenSSF, n.d.)
  12. Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E. P., Zhang, H., Gonzalez, J. E. & Stoica, I. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Advances in Neural Information Processing Systems 36 (NeurIPS 2023). (64, Zheng et al., 2023)
  13. EuroHPC Joint Undertaking. AI Factories. (25, EuroHPC JU, n.d.)
  14. European Commission. EU model contractual AI clauses to pilot in procurements of AI. Public Buyers Community, Procurement of AI community, 2023 (updated 2025). (18, European Commission, 2023)