Regulatory Requirements as Engineering Constraints

This chapter turns European regulation into the engineering requirements an AI platform has to meet, following each obligation from its instrument and article to the platform capability that satisfies it, the codified artefact that configures that capability, and the evidence the capability produces. It states each obligation only as far as the platform needs it; AI Governance, Chapter 3 gives the full legal treatment (73, Nordqvist, 2026). Everything here is architectural implication, not legal advice.

Regulation is translated into engineering requirements, and each requirement is met by a platform capability

Figure 3.1: Regulation becomes engineering requirements, and each requirement is met by a platform capability that every AI system on the platform reuses. The table gives the mapping.

Instrument Engineering requirements Platform capabilities
AI Act Risk and data governance; logging and traceability; oversight and transparency Evaluation and lineage gates; audit log store; approval and disclosure services
GDPR Risk and data governance; security and incident reporting Evaluation and lineage gates; gateway, SBOM and incident pipeline
NIS 2 and DORA Security and incident reporting Gateway, SBOM and incident pipeline; audit log store
Cyber Resilience Act Security and incident reporting Gateway, SBOM and incident pipeline; audit log store

Reading regulation as an engineer

Platform engineers read regulation to establish structure. The requirement in Article 12 of the AI Act that high-risk systems "technically allow for the automatic recording of events" over their lifetime is, read as an engineer, a requirement for an append-only event store with a retention policy, a schema that identifies the system version, and an access path for the people who must read it (1, European Union, 2024).

If the platform offers each capability once, rather than forty projects building forty logging pipelines, a team meets the obligation by declaring that its system uses it, as Architecture as Code argued for infrastructure (72, Nordqvist, 2025). Every requirement below is therefore written as a chain:

  1. Legal source: the instrument and article.
  2. Platform capability: the shared service or pipeline stage that satisfies it.
  3. Codified artefact: the version-controlled file that configures it for one system.
  4. Evidence produced: the record, written without manual effort, that proves the capability operated.

A requirement that cannot be written as all four links is not ready to be built; the missing link is usually the evidence.

Deciding which requirements apply

The risk classification of AI Governance, Chapter 8 performs the legal analysis (73, Nordqvist, 2026); its result should reach the platform as data, in three keys.

The first key is the risk tier, because it decides which capabilities are mandatory (1, European Union, 2024). Practices prohibited by Article 5 are refused at intake. High-risk systems under Article 6 and Annex III, such as those for access to essential public benefits or life and health insurance pricing, carry Articles 9 to 15. Article 50 transparency duties apply whatever the tier, and every system carries horizontal duties such as AI literacy under Article 4. Classification follows purpose, not technology. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the application date of the Annex III obligations to 2 December 2027 (23, European Union, 2026); because the capabilities take longer to build, the date changes the order of work, not its content.

The second key is the role defined in Article 3. An organisation that builds and runs its own system is both provider and deployer, and Article 25 is the clause platform teams most often miss: a deployer that makes a substantial modification to a high-risk system, or repurposes a system into a high-risk use, inherits the provider's obligations (1, European Union, 2024). The role is recorded in an AI Decision Record (Chapter 5), and the platform reads it from there.

The third key is whether the system integrates a general-purpose AI model, whose obligations, for most organisations in this book, are a supplier-evidence problem rather than a build problem.

High-risk requirements as platform capabilities

Articles 9 to 15 bind the provider of a high-risk system, and each is cheapest to meet as a shared capability that the system declares and uses (1, European Union, 2024).

Article 9 risk management becomes a risk register held as code and linked to the evaluation pipeline, so that a model, data or prompt change re-opens the affected risks; ISO/IEC 42001 supplies the management-system frame (24, ISO/IEC, 2023). Article 10 data governance becomes a data pipeline with data contracts, lineage capture, a bias examination stage and a datasheet per dataset (42, Gebru et al., 2021); Chapter 6 builds it. Article 11 and Annex IV require technical documentation kept up to date, and Article 18 requires it to be kept for ten years; an architecture repository generates the Annex IV document from records the other capabilities already hold, such as the model card (41, Mitchell et al., 2019) and the decision records, with every section carrying the commit reference of its source (Chapter 5).

Article 12 requires automatic recording of events over the system's lifetime, and Article 19 requires providers to keep the logs for at least six months. The capability is an append-only audit log fed by the AI gateway and the orchestration layer, using the OpenTelemetry semantic conventions for generative AI so that traces share one shape (34, OpenTelemetry, n.d.), configured by a logging profile and checked for integrity (Chapter 21). Article 13 instructions for use are published by a release step with each version. Article 14 requires that natural persons can oversee the system effectively; the capability is an oversight service with approval gates, override recording and a stop control any system can bind to, evidenced by regular stop-path tests (Chapter 11). For Article 15 accuracy, robustness and cybersecurity, the capability is an evaluation pipeline with fixed acceptance thresholds plus the security controls of the gateway and runtime, scoped with the help of the OWASP Top 10 for Large Language Model Applications (27, OWASP, 2025) and MITRE ATLAS (28, MITRE, n.d.), and developed in Chapters 16, 17 and 20.

The requirements-to-capability matrix

Table 3.1 gives the artefact and evidence for these and the remaining obligations.

Legal source Platform capability Codified artefact Evidence produced
AI Act Art. 9 Risk register as code, linked to evaluation gates Per-system risk file Register history, gate results per release
AI Act Art. 10 Data pipeline with contracts, lineage and bias examination Data contract, datasheet Lineage graph, bias report per training run
AI Act Art. 11, Annex IV Architecture repository generating documentation Model card, decision records Generated Annex IV document with commit references
AI Act Art. 12, 19 Append-only audit log fed by gateway and orchestration Logging profile Logs, retention configuration, integrity checks
AI Act Art. 13 Release step publishing instructions for use Instructions template Versioned instructions, distribution record
AI Act Art. 14 Oversight service with approval, override and stop Oversight configuration Approval and override records, stop-path tests
AI Act Art. 15 Evaluation pipeline and gateway security controls Evaluation suite, gateway policy Evaluation and adversarial test reports
AI Act Art. 26 Deployer monitoring, log retention, oversight rota Deployment profile Monitoring alerts, retained logs, rota
AI Act Art. 50 Disclosure and content-marking services Channel disclosure setting Disclosure configuration, marking test results
AI Act Art. 72, 73 Monitoring plan and incident pipeline Monitoring plan, incident classification rules Monitoring reports, incident records and reports
AI Act Art. 53, 55 Model intake process Model intake record Intake record, registry gate result
CRA, NIS 2 Art. 21, DORA Supply-chain, vulnerability and resilience controls SBOM and ML-BOM, vulnerability policy SBOMs, scan results, test reports
GDPR Art. 25, 32, 35 Privacy defaults, security controls, DPIA trigger Data protection profile DPIA reference, minimisation tests

Table 3.1: Requirements-to-capability matrix for an AI platform.

Deployer and transparency obligations

Article 26 requires deployers of high-risk systems to use them according to the instructions for use, assign competent oversight, monitor operation and inform the provider of risks and serious incidents, keep the logs under their control for at least six months; public authorities must also register their use (1, European Union, 2024). Each clause maps to a capability, from a deployment profile pinning the permitted version to an oversight rota and a retention rule. The phrase "under their control" matters architecturally: if a procured system writes logs only to the supplier's environment, the deployer cannot retain them, so the contract should require logs to land on the deployer's platform.

Article 50 applies whatever the tier (1, European Union, 2024). People must be told when they interact with an AI system, unless it is obvious (Article 50(1)); synthetic content must carry a machine-readable mark (Article 50(2)); and AI-generated text published to inform the public on matters of public interest must be disclosed unless it has undergone human review under editorial responsibility (Article 50(4)). The capabilities are a disclosure component in every conversational channel, a content-marking step and a publication workflow that records human review.

Post-market monitoring and serious incidents

Article 72 requires providers of high-risk systems to run a proportionate post-market monitoring system, under a plan that forms part of the technical documentation. Article 73 requires serious incidents, as defined in Article 3, to be reported to the market surveillance authority of the member state where they occurred, in general within fifteen days of awareness and sooner for the gravest categories (1, European Union, 2024).

For Article 72 the capability is the observability stack of Chapter 21, with the monitoring plan written as configuration the stack reads. For Article 73 the capability is an incident pipeline that classifies each AI-related incident against every regime that may apply at once, starts the right clocks and assembles the report from logs and the evidence store. Its classification rules decide whether an incident is serious under Article 73, major under DORA or significant under NIS 2. Deployers need a reduced form: Article 26(5) requires them to inform the provider first, so their runbook must name the provider's contact and channel.

General-purpose AI models as supplier evidence

Articles 53 and 55 place documentation, downstream-information, copyright and training-summary duties on the providers of general-purpose AI models, with a partial exemption for open-source models and further duties for models with systemic risk (1, European Union, 2024). The Commission's guidelines clarify their scope (205, European Commission, 2025), and the General-Purpose AI Code of Practice gives model providers a recognised route to demonstrate compliance (14, European Commission, 2025).

A high-risk system built on such a model therefore depends on the model provider's disclosures for parts of its Article 11 and Article 15 evidence, so a model intake process ingests that evidence, with the platform's own evaluation, and a registry gate refuses to promote a model whose intake record is incomplete. For open-weight models the documentation may be thin, so the platform's own evaluation carries more weight (Chapter 10).

Security and resilience: the Cyber Resilience Act, NIS 2 and DORA

Article 15 is the AI-specific security layer; these instruments are the general layer beneath it.

The Cyber Resilience Act

Regulation (EU) 2024/2847, the Cyber Resilience Act, imposes essential cybersecurity requirements and vulnerability-handling duties, including a software bill of materials, on manufacturers of products with digital elements; a high-risk AI system that is such a product and meets them is deemed to meet the cybersecurity requirement of Article 15 (7, European Union, 2024). Its reporting duties have applied since 11 September 2026 (Chapter 18). A platform built from such products must ingest suppliers' SBOMs and advisories; the capability is a supply-chain service that generates and stores bills of materials, extended to models and datasets through the CycloneDX ML-BOM (31, OWASP, n.d.) standardised as ECMA-424 (135, Ecma, 2025), and matches them against advisories.

NIS 2

Directive (EU) 2022/2555, NIS 2, requires essential and important entities to take cybersecurity risk-management measures under Article 21, including supply-chain security, and to report significant incidents under Article 23 within 24 hours, 72 hours and one month (4, European Union, 2022). The AI-specific additions are that model and hosting providers are suppliers under the supply-chain measure, and that prompt injection, data poisoning and agent misuse are incident classes the process must recognise.

DORA

Regulation (EU) 2022/2554, DORA, requires financial entities to run an ICT risk-management framework with change management (Article 9), to classify and report major ICT-related incidents (Articles 18 and 19), to test their digital operational resilience, and to keep a register of information on every contractual arrangement with an ICT third-party service provider (Article 28) (3, European Union, 2022). For an insurer, every model provider and inference host is such a provider, so the platform records each model, prompt and configuration change as an ICT change, tests failover to a fallback model, and populates the register of information from the model registry so that no provider is used before it is registered.

Data protection: the GDPR as pipeline constraints

Article 25 of Regulation (EU) 2016/679 requires data protection by design and by default (2, European Union, 2016). On a platform the defaults outweigh any project's intentions, so the gateway redacts identifiers in prompt logs, and the logging profile resolves the tension with AI Act Article 12 by keeping the required events while minimising the personal data inside them. Article 32 requires security of processing appropriate to the risk; the platform links its controls to the processing record so that one test result serves the GDPR, NIS 2 or DORA, and AI Act Article 15 at once.

Article 35 requires a data protection impact assessment before processing likely to result in a high risk to individuals. On a platform this is a pipeline trigger: a profile declaring personal data or decisions about individuals must reference a completed DPIA before the deployment gate opens. Article 26(9) of the AI Act expects deployers of high-risk systems to use the provider's instructions for use in that assessment (1, European Union, 2024).

The platform requirements catalogue

The catalogue turns the four-link chain into one artefact the pipeline reads: each entry names an article, its control, the condition under which it applies and the gate that blocks a release when the evidence is missing. The excerpt is illustrative; a full catalogue runs to some sixty entries.

apiVersion: platform.example.org/v1
kind: PlatformRequirementsCatalogue
metadata: {name: ai-platform-requirements, version: 2026.11.0, owner: platform-architecture}
spec:
  requirements:
    - id: REQ-AIA-12
      source: AI Act Art. 12 and 19
      appliesWhen: {riskTier: high, role: provider}
      control: audit-log-profile
      evidence: [log-retention-config, integrity-check]
      gate: pre-deploy
    - id: REQ-AIA-14
      source: AI Act Art. 14
      appliesWhen: {riskTier: high}
      control: oversight-service-binding
      evidence: [oversight-config, stop-path-test]
      gate: pre-deploy
    - id: REQ-AIA-26-LOGS
      source: AI Act Art. 26(6)
      appliesWhen: {riskTier: high, role: deployer}
      control: deployer-log-retention
      parameters: {minRetentionDays: 183}
      gate: pre-deploy
    - id: REQ-GPAI-INTAKE
      source: AI Act Art. 53
      appliesWhen: {integratesGpaiModel: true}
      control: model-intake-record
      gate: registry-promotion
    - id: REQ-DORA-REGISTER
      source: DORA Art. 28
      appliesWhen: {sector: financial, market: [EU]}
      control: register-of-information-sync
      gate: registry-promotion
    - id: REQ-GDPR-35
      source: GDPR Art. 35
      appliesWhen: {personalData: true, decisionsAboutPersons: true}
      control: dpia-reference
      gate: pre-deploy

When the harmonised standards of CEN-CENELEC Joint Technical Committee 21 are published (20, CEN-CENELEC, n.d.), the organisation adds clause references to existing entries, so a legal change becomes a reviewed change to data.

Across the usage modes

The usage modes of Chapter 2 change how much of the catalogue falls on the organisation's own platform; each system's classification still decides.

Mode Requirements that fall on the organisation's platform What the platform mainly does
Mode 0 – Ambient AI Article 4 literacy; Article 50(4) if generated text is published; GDPR Article 32 Inventory and configuration control of supplier features
Mode 1 – Conversational assistants As Mode 0, plus GDPR Articles 25 and 35 for personal data in prompts Approved tenant, data-loss controls, usage logging
Mode 2 – Embedded workplace assistants As Mode 1, plus Article 26 if used for an Annex III purpose Purpose control, connector permissions
Mode 3 – Agentic work tools As Mode 1, plus NIS 2 Article 21 or DORA change management Sandboxing, credential scoping, SBOM of generated changes
Mode 4 – Built AI applications Articles 9 to 15 if high-risk, Article 50, Articles 72 and 73, model intake, GDPR The full catalogue
Mode 5 – Autonomous production agents As Mode 4, with Article 12 logging and Article 14 oversight applied to every tool call The full catalogue, with action-level logging and stop controls

Practical guide: deriving the platform requirements for a new AI system

Purpose. Produce, before design starts, the platform controls a new system must use and the evidence it must produce, so that compliance is designed in rather than reviewed in.

Roles. The system owner; the AI architect, who runs the derivation; the platform owner; the data protection officer; legal or compliance; and, in financial entities, the ICT risk function.

Steps.

  1. Write the intended purpose in two or three sentences, naming the decision or output, the people affected and the markets served.
  2. Record the classification from AI Governance, Chapter 8, and the AI Act role, testing the Article 25 triggers, in an AI Decision Record.
  3. Add flags for general-purpose model use, personal data, decisions about individuals, sector and markets outside the EU, then run the catalogue gate in dry-run mode to list the applicable requirements and missing evidence.
  4. Where a capability does not exist, record the gap and decide whether the system waits or the platform builds it; never let a project build a private substitute without a decision record.
  5. Set retention with the data protection officer: the longest period any applicable rule requires, with six months as the AI Act floor for logs and ten years for the provider's technical documentation.
  6. Open the DPIA where Article 35 is triggered and, for public authorities, the fundamental rights impact assessment under Article 27; then commit the profile, decision record and gap list to the architecture repository.

Definition of done. Every applicable requirement has a bound capability or a recorded gap with owner and date, and the platform owner has signed off. Repeat it when purpose, model, data or markets change, and at least annually.

Worked example: two systems through the catalogue

Illustrative example. Nordvik Region's benefits-triage system. Nordvik uses a benefits-triage system provided by TriageSoft under tender NR-2026-117 to rank about 40,000 applications a month by urgency. The system is high-risk under Annex III point 5(a) and Nordvik is its deployer, with the Article 27 fundamental rights impact assessment and registration as additional duties (1, European Union, 2024). Its profile returned deployer log retention, the oversight binding (AIDR-0011), input-drift monitoring, the provider-notification step, and the DPIA and FRIA-2026-002 references. Because TriageSoft retrains the ranking model quarterly inside Nordvik's own platform, as the tender required, the logs are under Nordvik's control and its Article 26 evidence does not depend on the supplier's goodwill.

Hansa Mutual's claims-triage agent and underwriting-support model. Hansa built its claims-triage agent (AIDR-0024) on a vendor model and runs it in Mode 5 against the core claims system; it also built an underwriting-support model for life and health products, and is a financial entity under DORA. The underwriting model is high-risk under Annex III point 5(c), whereas the agent's classification record places it outside the high-risk tier. The UK and Swiss entities sit outside the AI Act and DORA, and Norway awaits incorporation of the AI Act into the EEA Agreement (241, EFTA, n.d.). Beyond what the law requires, the group added to the agent's profile, as policy, the Article 12 logging profile and Article 14 oversight binding, because an agent with write access to production needs action-level logs and a stop control whatever its legal tier. The market overlay labels each requirement as law or group policy per entity; the UK pack cites UK GDPR and the UK's principles-based approach (242, DSIT, 2023), and the Swiss pack the revised data protection act (244, Swiss Confederation, 2020).

Nordvik Region and Hansa Mutual

For Nordvik Region the requirements are concentrated and the leverage is the contract: as a deployer under one jurisdiction it needs log retention under its control, oversight binding, input monitoring, provider notification, Article 50(1) disclosure for its citizen-service assistant, and the DPIA and FRIA triggers. NIS 2, as transposed nationally, adds incident-reporting duties to the extent the Region falls within scope (4, European Union, 2022).

For Hansa Mutual, by contrast, the requirements are broad and the leverage is the platform. It needs the full catalogue, including the DORA register of information and resilience testing (3, European Union, 2022), and the market overlay lets one release serve seven jurisdictions without pretending the law is the same everywhere.

Summary

Regulation reaches an AI platform as engineering requirements, each best written as a chain of legal source, platform capability, codified artefact and evidence. Three answers decide which requirements apply: risk tier, role as provider or deployer, and whether the system integrates a general-purpose AI model.

For high-risk systems, Articles 9 to 15 of the AI Act become a small set of shared capabilities, from a risk register linked to evaluation gates to an oversight service with a stop path. Article 26 adds deployer duties, of which log retention under the deployer's control is most often lost in procurement; Article 50 adds disclosure and marking; Articles 72 and 73 make monitoring and incident classification platform services; and general-purpose model obligations arrive as supplier evidence. The Cyber Resilience Act, NIS 2, DORA and the GDPR add constraints on the same pipelines, and a requirements catalogue holds it all as data that gates evaluate. Chapter 4 builds the reference architecture that hosts them.

Sources

  1. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2, published at aig.geon.se. (73, Nordqvist, 2026)
  2. 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)
  3. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1, published at aac.geon.se. (72, Nordqvist, 2025)
  4. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (23, European Union, 2026)
  5. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO, December 2023. (24, ISO/IEC, 2023)
  6. Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H. & Crawford, K. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), pp. 86–92. (42, Gebru et al., 2021)
  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. (41, Mitchell et al., 2019)
  8. OpenTelemetry Authors. OpenTelemetry Documentation, including the Semantic Conventions for Generative AI systems. Cloud Native Computing Foundation. (34, OpenTelemetry, n.d.)
  9. OWASP Foundation. OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project. (27, OWASP, 2025)
  10. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (28, MITRE, n.d.)
  11. European Commission (2025). Guidelines on the scope of the obligations for general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act). Annex to C(2025) 5045 final, 18 July 2025. (205, European Commission, 2025)
  12. European Commission. The General-Purpose AI Code of Practice. European AI Office, 10 July 2025. (14, European Commission, 2025)
  13. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (7, European Union, 2024)
  14. OWASP Foundation. CycloneDX Machine Learning Bill of Materials (ML-BOM).. (31, OWASP, n.d.)
  15. Ecma International (2025). ECMA-424: CycloneDX Bill of Materials Specification, 2nd edition. Ecma International, December 2025. (135, Ecma, 2025)
  16. 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)
  17. 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)
  18. European Parliament and Council of the European Union. 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, 4 May 2016. (2, European Union, 2016)
  19. CEN-CENELEC. Joint Technical Committee 21 – Artificial Intelligence.. (20, CEN-CENELEC, n.d.)
  20. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (241, EFTA, n.d.)
  21. Department for Science, Innovation and Technology and Office for Artificial Intelligence (2023). A pro-innovation approach to AI regulation (CP 815). UK Government, 29 March 2023. (242, DSIT, 2023)
  22. 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. (244, Swiss Confederation, 2020)