Evidence, Assurance and Audit

The controls of Chapters 8 to 10 are worth only as much as the evidence that they operated. This chapter, which closes Part III, shows how to make an AI system auditable continuously rather than when an auditor arrives. It applies the evidence as code discipline from Architecture as Code (Chapter 15A) (66, Nordqvist, 2025) to models, prompts and data, and maps the resulting artefacts to the obligations that Regulation (EU) 2024/1689, the AI Act, places on providers and deployers of high-risk AI systems: technical documentation under Article 11 and Annex IV, record-keeping under Article 12, post-market monitoring under Article 72 and serious incident reporting under Article 73 (1, European Union, 2024). The same chain serves the audit-trail expectations of Regulation (EU) 2022/2554, DORA (3, European Union, 2022). If the pipeline that delivers a model also produces the proof that it did so correctly, documentation, audit and conformity assessment become outputs of the architecture rather than separate projects.

Evidence chain from sources of truth through build, policy gate and signing to the evidence store, generated documentation and its audiences

Figure 11.1: The evidence chain links version-controlled sources through a policy gate to a signed evidence store, from which documentation is generated for auditors and authorities (the table below).

Step Contents
Sources of truth Code and prompts; data and features; policies and tests; AI Decision Records
Pipeline Build and evaluate; policy gate; sign and attest
Evidence store Evidence manifest; signed artefacts; logs and traces
Generated documentation Annex IV technical file; post-market monitoring report
Audiences Internal audit; notified body; market surveillance authority

Table for Figure 11.1: What each step of the evidence chain contains.

From attestation to evidence

Most organisations I have worked with can describe their AI governance in a slide deck; far fewer can answer, within an hour, the auditor's question: which version of which model was serving decisions on a given date, what data it was trained on, what evaluation results justified its release, and who approved it. The answer usually exists, distributed across a tracking server, a wiki, email threads and the memory of two engineers. That is attestation, a person asserting that a control operated, not evidence, a machine-generated artefact that demonstrates it.

Architecture as Code (Chapter 15A) (66, Nordqvist, 2025) defined evidence as code through four characteristics: deterministic capture by automated checks, traceability to commits and change requests, reuse across regulatory frameworks under the principle of assure once, comply many, and version control so that historical attestations remain discoverable. AI systems stretch each of these, because capture must cover datasets and prompts, traceability must span third-party foundation models of partly opaque provenance, and version control must cope with large, sometimes legally sensitive artefacts.

The architectural response is to treat every release of an AI system as the production of an evidence bundle, and to design the pipeline so that a release without a complete bundle cannot reach production. The bundle contains the hashed identity of the model, datasets and prompts, the evaluation report with its thresholds, the risk classification and the decision record that authorised the release, the results of the governance gates of Chapter 9, and a cryptographic attestation binding all of these to one pipeline run. Raji et al. (57, Raji et al., 2020) describe a comparable set of artefacts for internal algorithmic audit; the difference here is that the pipeline produces them as a side effect of delivery rather than an audit team assembling them afterwards.

The evidence chain

Figure 11.1 shows five stages. The sources of truth are the repositories for code and prompts, data, policies and tests, and the AI Decision Records. The pipeline builds, evaluates, gates and signs. The evidence store holds the manifest, signed artefacts and operational logs. Documentation is generated from the store, so that any auditor can trace a statement back to a signed artefact.

Two design decisions make the chain trustworthy. First, evidence is written once and never edited: artefacts sit in an append-only object store with retention locks, and each manifest references the previous one so that the history forms a chain. Second, signing happens inside the pipeline with an identity bound to the pipeline run, not with a key an engineer holds. The Sigstore and SLSA mechanism that Architecture as Code applies to container images works equally for a model file or a rendered Annex IV document.

The evidence manifest

The manifest ties the chain together and lives in version control beside the system. The example shows a manifest for a document classification model that a social insurance authority uses to route incoming claims.

apiVersion: evidence.aiarch.example/v1
kind: EvidenceManifest
metadata:
  system: claims-routing-classifier
  release: 2026.10.3
  pipelineRun: gh-run-18834412
  riskClassification: high-risk-annex-iii-5a
subjects:
  - type: model
    uri: oci://registry.internal/models/claims-routing@sha256:4f1c...
  - type: dataset
    uri: s3://evidence-store/datasets/claims-2026q3@sha256:a81d...
  - type: prompt-bundle
    uri: git://prompts/claims-routing@7c0ff2a
evaluations:
  - suite: evaluation/claims-routing.suite.yaml
    report: s3://evidence-store/reports/eval-18834412.json
    gate: passed
controls:
  - id: AIA-ART-11
    artefact: s3://evidence-store/techdoc/claims-routing-2026.10.3.pdf
  - id: AIA-ART-12
    artefact: s3://evidence-store/checks/logging-18834412.json
  - id: AIA-ART-14
    artefact: s3://evidence-store/checks/oversight-18834412.json
  - id: DORA-ART-17
    artefact: docs/runbooks/claims-routing-incidents.md
approvals:
  - role: model-risk-owner
    record: adr/ADR-0142-claims-routing-release.md
attestation:
  format: in-toto
  signature: s3://evidence-store/attestations/18834412.sig
retention:
  technicalDocumentationYears: 10
  logsMonthsMinimum: 6

Content hashes make the manifest prove what was released rather than what was intended. Every control maps to an obligation and to an artefact that demonstrates it, which is assure once, comply many applied to the AI Act and DORA together. The retention block records the chosen periods so that the archive enforces them without anyone remembering.

Technical documentation generated from the repository

Article 11 of the AI Act requires the provider of a high-risk AI system to draw up technical documentation before the system is placed on the market or put into service, and to keep it up to date (1, European Union, 2024). Read as an outline, the contents that Annex IV lists look like a writing task; read as an architectural specification, they are queries against the architecture repository of decision records, model and system cards, evaluation results and policies. The following mapping has proved workable.

Annex IV section Repository source Generated how
General description and intended purpose AI Decision Record, system card Rendered from the decision record template
Elements and development process Pipeline definition, model card, datasheets Extracted from pipeline metadata and registry
Data used and evaluation methods Data contracts, evaluation suite and reports Rendered from the suite and the latest passed report
Monitoring, functioning, and control Observability configuration, oversight checklist Rendered from alerting rules and oversight tests
Risk management system Risk register as code Filtered to the system
Changes through the lifecycle Git history, release manifests Changelog from tagged releases
Post-market monitoring plan Monitoring plan Rendered with current alert thresholds

Generated documentation cannot diverge from the system: a changed threshold appears in the next build and in the pull request diff. A documentation stage runs after the evaluation gate, renders the sources through an Annex IV template, attaches the result to the manifest as control AIA-ART-11, signs it and archives it under a ten-year retention lock, which meets the Article 18 duty to keep documentation available to national competent authorities for ten years with no additional process. The template holds the prose that does not change between releases, such as the intended purpose and the oversight model; everything that can change is injected. Reviewers approve template changes as they approve code, which gives the legal and compliance functions a seat in the pull request rather than at the end of the project.

Worked example: model card and system card

Two sources carry most of the descriptive weight: the model card, which describes one model as the organisation uses it (46, Mitchell et al., 2019), and the system card, which describes the whole system around it. For a system built on a third-party foundation model the distinction matters, because the organisation cannot document the vendor's training but must document how it configured, evaluated and constrained the model.

Illustrative example. Hansa Mutual's retrieval-augmented generation (RAG) assistant for policy-wording questions, whose risk register entry Chapter 8 shows, is not high-risk, but Hansa Mutual documents every AI system the same way so that one chain serves all its supervisors. The model card, model/claims-wording-llm version 1.4.0, names the vendor model under contract VND-2025-118, hosted in a dedicated EU tenancy and not fine-tuned; the intended purpose of answering claims handlers' questions about home and motor wording with the clause cited; two out-of-scope uses, deciding coverage and use by policyholders or brokers; golden-set results of 0.94 answer correctness and 0.97 citation precision in Swedish, German and English; the known weakness on scanned pre-2015 policies; and register entry RISK-2026-031. For the vendor's training it points to the documentation supplied under Article 53(1)(b), under which general-purpose AI model providers inform downstream providers, instead of guessing (1, European Union, 2024). The system card, ai-system/claims-wording-assistant, adds the index, the AI gateway, a grounding check that blocks uncited answers, the statement that the handler decides coverage, and alert thresholds. The out-of-scope list and the human-role statement are the two sentences an auditor will test first, so an internal audit should sample real interactions against them.

Logging obligations and record retention

Article 12 of the AI Act requires high-risk AI systems to allow, by design, the automatic recording of events over their lifetime, serving risk identification, post-market monitoring under Article 72 and the deployer's monitoring under Article 26 (1, European Union, 2024). Article 19 requires providers to keep the logs under their control for a period appropriate to the intended purpose and for at least six months, and Article 26(6) places the same minimum on deployers, unless other Union or national law provides otherwise, in particular Union law on the protection of personal data. Providers and deployers that are financial institutions keep the logs as part of the documentation they maintain under Union financial services law (Articles 19(2) and 26(6)).

For a system built on a large language model (LLM), the log must capture enough to reconstruct why an output was produced. Our working minimum per inference is the model and prompt bundle versions, a hash of the input, the retrieved documents or features, the guardrail decisions, the output with its score where available, and any human override. For agentic systems the record adds the sequence of tool calls and their parameters, with the identity under which each ran, because the decision is spread across steps.

This creates a tension with Article 5 of the GDPR, which requires data minimisation and storage limitation. The resolution is to separate the record of events from their content. The event record, which proves the system operated within its declared bounds, is kept for the regulatory period in append-only storage; content containing personal data is pseudonymised at ingestion, held under shorter retention, and linked to the event record by a reference that permits reconstruction only under a documented access procedure. The OpenTelemetry semantic conventions for generative AI already treat prompt and completion content as optional (41, OpenTelemetry, n.d.). Retention is enforced by configuration, such as retention locks and a pipeline check that fails on misconfiguration, which are themselves evidence.

Across the usage modes

The evidence an organisation can produce depends on who runs the system and who holds the logs. Articles 12, 19 and 26(6) apply to high-risk systems, so the statutory logging duties fall mainly on Modes 4 and 5; for the other modes the question is what the organisation can show its auditors at all.

Mode Evidence available Who controls it Main gap
Mode 0 Ambient AI Release notes, administration settings, contract terms Supplier Little or no per-use record
Mode 1 Conversational assistants Usage and audit logs where the tier provides them, policy acknowledgements Supplier, exported on request Prompt content often not retained; nothing for shadow use
Mode 2 Embedded workplace assistants Suite audit logs, label and access events Tenant Shows what was accessed, rarely why
Mode 3 Agentic work tools Session transcripts, commits, permission configuration Organisation, partly on workstations Local transcripts not collected
Mode 4 Built AI applications The full evidence chain of this chapter Organisation Provenance of third-party models
Mode 5 Autonomous production agents As Mode 4, plus tool-call traces, approval and stop records Organisation Reconstructing long chains of actions

For Modes 0 to 2 the evidence is largely what the supplier lets the organisation export, so the right to export audit logs, their format and retention belong in the contract that Chapter 7 describes. In those modes the strongest evidence of a control is often its configuration and the signed policy acknowledgement; capture both in the evidence store like any other artefact.

Internal algorithmic audits

Raji et al. (57, Raji et al., 2020) proposed an end-to-end framework for internal algorithmic auditing in five stages, scoping, mapping, artefact collection, testing and reflection, producing documents such as the design checklist and the remediation plan. ISO/IEC 42001 adds the management-system view: clause 9 requires performance evaluation, including internal audit at planned intervals, and clause 10 requires improvement based on the findings (32, ISO/IEC, 2023).

Evidence as code changes the economics of internal audit. When artefact collection reads from a signed store rather than interviewing engineers, auditors can spend their time on questions that need judgement: whether the intended purpose is still the actual purpose, whether the evaluation suite still measures what matters, and whether the overseers have the competence and authority that Article 26(2) of the AI Act requires (1, European Union, 2024). We recommend three practices. Give the audit function read-only access to the store and repositories, to preserve independence; raise findings as issues with a required remediation record, so that they share the lifecycle of defects; and record the audit itself as evidence for the next one.

Worked example: evidence-pack index

An evidence pack is generated by query for one system and period; its index lists each audit question, the artefacts that answer it and their hashes, so that nothing can be swapped after issue.

Illustrative example. Nordvik Region generated the index below for the first internal audit of its benefits-triage system after go-live. Paths and hashes are fictional and shortened.

evidence_pack:
  id: EP-2026-011
  system: ai-system/benefits-triage
  period: {from: 2026-09-01, to: 2026-10-31}
  requested_by: internal-audit
  generated_by: tools/evidence/pack.py@3a9f1c2
  store_query: "system=benefits-triage AND produced_at IN period"
  sections:
    - id: A
      question: "Is the system used per its intended purpose and instructions? (Article 26(1))"
      artefacts:
        - {path: provider/instructions-for-use-v3.2.pdf, sha256: "07bd...e912"}
        - {path: reports/usage-by-function-2026-10.json, sha256: "c3a2...1f07"}
    - id: C
      question: "Does human oversight operate as designed? (Article 14, Article 26(2))"
      artefacts:
        - {path: oversight/design-v1.2.yaml, sha256: "2b7f...93aa"}
        - {path: metrics/override-rate-weekly.json, sha256: "6d02...7e51"}
        - {path: tests/runtime/stop-switch-2026-09-28.json, sha256: "17c5...d4f0"}
    - id: D
      question: "Are logs complete and retained for at least six months? (Articles 12 and 26(6))"
      artefacts:
        - {path: storage/retention-lock-config.json, sha256: "3f9b...c120"}
  pack_signature: s3://evidence-store/packs/EP-2026-011.sig

The index follows audit questions because the auditor reasons from obligations, and an empty section is itself a finding. The store_query and the generator commit make the pack reproducible: a second auditor can regenerate it and compare hashes.

Worked example: internal audit test procedure

The test procedure says what the auditor does with the artefacts; write one per control and version it like the control.

Illustrative example. The procedure below tests Nordvik Region's caseworker override control (CTRL-OVR-001), which the oversight design in Chapter 10 specifies. Sample sizes and tolerances are fictional defaults that internal audit should set from its own methodology.

# Audit test procedure: TP-AI-014 - Caseworker override with recorded reason
Control: CTRL-OVR-001 | System: ai-system/benefits-triage
Obligations: AI Act Article 14(4)(b) and (d); Article 26(2)
Evidence pack sections: C, D | Owner: Head of Internal Audit

## Design test
D1. Confirm in oversight/design-v1.2.yaml that a reorder requires a reason
    code, never_auto_accept is true and override-rate alerts are configured.
D2. In the test environment, confirm a reorder cannot be saved without a reason.

## Operating effectiveness test
O1. Sample 40 ranking reviews at random and all reorders (cap 60).
O2. For each reorder: reason code present, actor is a trained senior caseworker.
O3. For each sampled acceptance: review time >= 45 seconds (tolerance 2 of 40).
O4. Recompute the weekly override rate from raw events; it must match
    metrics/override-rate-weekly.json exactly.
O5. Compare agreement on the 5% blind sample with agreement on scored cases.
O6. Interview 3 overseers on the stop function; record answers verbatim.

## Evaluation
Deficient: any reorder without reason or by an untrained actor; O4 mismatch.
Findings are raised as issues labelled audit-finding with owner and due date.

Steps O4 and O5 carry the most value. Recomputing the override rate from raw events tests the metric pipeline as well as the control, so a broken dashboard cannot hide a broken control, and comparing agreement on blind and scored cases is the only direct measure of automation bias in the procedure. The interview stays deliberately human, because whether an overseer has the competence and authority that Article 26(2) requires is not something an event log can show (1, European Union, 2024).

Conformity assessment and notified bodies

Before a high-risk AI system is placed on the market, Article 43 of the AI Act requires a conformity assessment (1, European Union, 2024). For most Annex III systems the provider follows the internal control procedure in Annex VI, verifying for itself that its quality management system under Article 17 and its technical documentation meet the requirements of Chapter III, Section 2. A notified body is involved under Annex VII where the system is a biometric system under Annex III and harmonised standards have not been applied in full, and for safety components of products covered by the sectoral legislation in Annex I. The provider then draws up the EU declaration of conformity under Article 47, affixes the CE marking under Article 48 and registers the system in the EU database under Article 49.

Architecturally, conformity assessment is a consumer of the evidence chain. Whether the assessor is internal or a notified body, it asks for the documentation, the quality management system operating, test results against declared metrics and controlled change. Design the quality management system itself as code, therefore: the procedures Article 17 requires become pipeline stages, policy rules and runbooks that an assessor can read and then observe executing.

Post-market monitoring and serious incident reporting

Article 72 of the AI Act requires providers of high-risk AI systems to establish a post-market monitoring system that actively and systematically collects, documents and analyses performance data throughout the system's lifetime, based on a plan that forms part of the technical documentation (1, European Union, 2024). Article 73 requires providers to report serious incidents to the market surveillance authority of the Member State where the incident occurred, immediately after establishing a causal link or its reasonable likelihood and in any case within fifteen days of becoming aware of it, with shorter deadlines for incidents involving death or widespread infringement; the deployer must inform the provider when it becomes aware of one (Article 26(5)).

Fifteen days is short for an organisation that has never classified a model's behaviour against Article 3, which has three implications. The post-market monitoring plan should be version-controlled, with the same thresholds that drive the production alerts. The incident process should include an AI-specific classification step for every production incident touching an AI system, recording the answer and reasoning whatever the outcome. And the data for a report, including the Article 12 logs, the model version and the evaluation history, should be retrievable by the incident manager without engineering assistance. A public authority that has built or substantially modified its decision support is often both provider and deployer, answering to a market surveillance authority, to citizens and to its audit office; one chain serves all three only if it was designed for them before go-live.

Worked example: deployer obligations checklist

A deployer's obligations are spread across several articles and easily lost between procurement, operations and legal, so a checklist with an evidence reference per item lets the deployment gate and internal audit check them alike.

Illustrative example. Nordvik Region is deployer of its benefits-triage system and a vendor is provider. The checklist paraphrases the obligations as architectural checks and is not legal advice.

deployer_obligations:
  system: ai-system/benefits-triage
  regulation: "Regulation (EU) 2024/1689"
  provider: "TriageSoft (fictional)"
  items:
    - {ref: "Art. 4", check: "Staff using the system have AI literacy training",
       evidence: training/ai-literacy-2026.csv, status: met}
    - {ref: "Art. 26(2)", check: "Oversight assigned to competent, trained persons with authority",
       evidence: oversight/design-v1.2.yaml, status: met}
    - {ref: "Art. 26(6)", check: "Logs under deployer control kept at least six months",
       evidence: storage/retention-lock-config.json, status: met}
    - {ref: "Art. 26(7)", check: "Workers' representatives informed before use",
       evidence: hr/consultation-2026-07.pdf, status: met}
    - {ref: "Art. 27", check: "FRIA completed and results notified",
       evidence: assessments/FRIA-2026-002.md, status: met}
    - {ref: "Art. 25", check: "No rebranding, substantial modification or purpose change that makes us provider",
       evidence: policies/substantial-modification.rego, status: met}
  last_verified: 2026-08-28
  verified_by: ai-governance-forum

The last item is the one most often missing. Article 25 can turn a deployer into a provider, and the substantial-modification rule in Chapter 8 is the evidence that the organisation checks for it on every change rather than once at procurement (1, European Union, 2024).

DORA and audit trails in financial services

Financial entities in the European Union operate under Regulation (EU) 2022/2554, DORA, which has applied since 17 January 2025 and governs ICT risk management, incident reporting, resilience testing and third-party risk (3, European Union, 2022). DORA does not mention AI, but an AI system in a bank or insurer is an ICT system, and an external foundation model provider falls under its third-party rules. The overlap with the AI Act is substantial, so one set of artefacts can serve both.

Evidence artefact AI Act obligation DORA obligation
Signed release manifest with model and data hashes Article 11 documentation, Article 18 retention Article 9 protection and prevention, change management
Event logs with retention lock Article 12 record-keeping, Article 19 retention Article 10 detection, Article 17 incident evidence
Evaluation reports against declared thresholds Article 15 accuracy and robustness Articles 24 to 27 resilience testing
Incident classification record Article 73 serious incident reporting Articles 17 and 19 incident management and reporting
Vendor assessment for foundation model provider Article 25 value chain Article 28 third-party risk, register of information

Financial services law may demand longer retention than the AI Act's six-month minimum for logs, and Articles 19(2) and 26(6) accommodate this by treating the logs of financial institutions as part of the documentation kept under that law, so the manifest's retention block should be derived from a policy that resolves the strictest applicable requirement rather than hard-coded per system.

Worked example: incident classification record

In a financial entity the incident record also carries the DORA classification, since Article 18 of DORA requires ICT-related incidents to be classified against criteria that include the clients affected, duration, geographical spread, data losses, criticality of the services affected and economic impact (3, European Union, 2022).

Illustrative example. Hansa Mutual's claims-wording assistant cited superseded policy wording for three days after an index rebuild. The record is fictional.

incident_classification:
  incident_id: INC-2026-0457
  system: ai-system/claims-wording-assistant
  detected_by: kpi_alert/superseded_wording_citations
  summary: "Index rebuild dropped validity dates; superseded wording cited in 37 answers"
  containment: "Index rolled back to v6; assistant restricted to home products"
  ai_act:
    article_73_applicable: false
    assessment: "Not a serious incident under Article 3(49); recorded for completeness"
  dora:
    clients_affected: "Up to 37 claims; handlers verified wording in 35 cases"
    duration_hours: 72
    geographical_spread: "Sweden only"
    major_incident: false
  root_cause: "Rebuild job lacked a schema check for validity dates"
  register_update: "RISK-2026-031 re-opened; residual rating raised to medium pending CA-1"
  reviewed_by: [model-risk-owner-claims, ict-risk-function]

Recording the negative AI Act assessment shows that the classification step ran and gives a supervisor reasoning to review. The register_update field closes the loop to Chapter 8, where the key risk indicator that detected the incident is defined.

Nordvik Region and Hansa Mutual

Nordvik Region, as a deployer, relies on the supplier's technical documentation and conformity assessment and adds its own evidence of use: logs kept under Article 26(6), oversight records, FRIA-2026-002 and its registration as a public-authority deployer under Article 49 (1, European Union, 2024). Its auditors are internal audit, the national audit office and, in practice, the public, because much of the evidence pack can be requested under public-access rules.

Hansa Mutual's model card and incident record show the provider side, and its chain must satisfy several supervisors at once. The Solvency II governance requirements of Article 41 apply to insurance and reinsurance undertakings within the scope of the Directive (184, European Union, 2009), DORA applies to the EU entities (3, European Union, 2022), and the United Kingdom and Swiss supervisors review the same systems under their own expectations. The group therefore generates one evidence manifest and projects it per market: a pack for each EU supervisor in its language and format, and packs for the United Kingdom and Swiss supervisors that replace the AI Act mappings with national ones. Nordvik's assurance answers one auditor and the public; Hansa's answers many supervisors, each of whom sees only its own entity.

Summary

Assurance for AI systems is an architectural property, not a documentation exercise. When the delivery pipeline also produces signed, retained evidence of what was delivered, how it was evaluated and who approved it, every auditor's question has an artefact for an answer, and the evidence manifest binds those artefacts together.

Mapped to the AI Act, Annex IV documentation becomes a set of queries against the repository, rendered and signed on every release; Article 12 logging becomes a telemetry design that separates events from content; internal audit and conformity assessment become consumers of the evidence store; and Articles 72 and 73 become a monitoring plan whose thresholds are the production alerts and an incident process with an explicit AI classification step. For financial entities, the same artefacts satisfy DORA.

However, every control in Part III names a role: an owner, an approver, an overseer, an auditor. Chapter 12 therefore opens Part IV with organisational design for AI: the operating models, team structures and allocation of accountability that decide who holds those roles and whether they can carry them.

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 (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (3, European Union, 2022)
  3. International Organization for Standardization and International Electrotechnical Commission (2023). ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO. (32, ISO/IEC, 2023)
  4. 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 (FAT* '20). (57, Raji et al., 2020)
  5. Nordqvist, G. Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
  6. 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)
  7. Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D. & Gebru, T. (2019). Model Cards for Model Reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency (FAT* '19), pp. 220–229. (46, Mitchell et al., 2019)
  8. OpenTelemetry Authors. OpenTelemetry Documentation, including the Semantic Conventions for Generative AI systems. Cloud Native Computing Foundation. (41, OpenTelemetry, n.d.)