Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability

The European instruments that apply to a large enterprise or a public authority in 2026 are written for legal entities, management bodies, providers, deployers and manufacturers. None of them mentions the security architect. Yet every one of them can be met only if someone turns its articles into boundaries, controls, tests and records that run, and in most organisations that someone is the architect. This chapter reads the AI Act, NIS 2, DORA and the Cyber Resilience Act as engineering constraints, article by article, and says what each expects of architecture and of named people. It then separates two things that are easily confused: the accountability the instruments place on management bodies, and the professional responsibility of the architect who equips those bodies to discharge it.

The chapter concerns three of the four shifts. It belongs to Shift 1, from documents to code, because an article is enforceable only when it becomes a versioned mapping to a control, a test and an evidence record. It belongs to Shift 2, from gatekeeper to boundary designer, because the architect cannot review every system against every article and designs the controls and decision rights that let the lowest competent tier decide. It belongs to Shift 3, from periodic to continuous, at machine speed, because the reporting clocks run in hours and days and are met only by pipelines that classify incidents and assemble reports as they happen. Everything legal below is attributed to the instrument and article and framed as an architectural implication, not legal advice.

Articles of the AI Act, NIS 2, DORA and the Cyber Resilience Act mapped through the architect to controls, tests and evidence, with the management body's accountability shown separately

Figure 18.1: The architect maps articles to catalogue controls, each with a test and an evidence record, while accountability for approval and oversight stays with the management body and with named control owners.

Regulation as a design input

An engineer reads a regulation for structure: which components must exist, which records must be kept, which decisions must be reversible and by whom. AI Platform and Security, Chapter 3, set out the method for an AI platform as a chain of four links: the legal source, the platform capability that satisfies it, the codified artefact that configures it, and the evidence it produces (169, Nordqvist, 2026). This chapter takes the chain into the architect's catalogue and adds a fifth element, the person: every chain ends in a named owner, because the instruments address people and bodies, not tools. Four reading rules keep the method honest.

  • Read the addressee. The AI Act attaches duties to roles, provider and deployer, and to a risk class; NIS 2 attaches them to essential and important entities and to their management bodies; DORA to financial entities and their management bodies; the Cyber Resilience Act to manufacturers, importers and distributors of products with digital elements.
  • Read the verb. An article that says approve, oversee or be trained describes a person's act. An article that says ensure, keep, implement or notify describes a property that architecture can provide and a test can check. The architect works mostly on the second kind and equips people for the first.
  • Read the date. The instruments apply in stages. Law in force on a stated date is observable; supervisory practice that has yet to form is expected, and this chapter labels it so.
  • Read the limit. The architect proposes a reading of an article as an architectural property and records it as a decision with a reviewer. Whether the reading is legally right belongs to counsel, the data protection officer and the competent authority.

Not every instrument applies to every system, and the first mapping decision is therefore scope. Hansa Mutual is a financial entity within DORA in its EU entities and a deployer and provider under the AI Act; Nordvik Region is a deployer of a high-risk system under the AI Act and falls within the national transposition of NIS 2 to the extent that regional government entities are in scope, which Article 2 of the Directive leaves partly to Member States (6, European Union, 2022). Neither is a manufacturer under the Cyber Resilience Act for its internal systems, but both buy such products every day.

The AI Act

Regulation (EU) 2024/1689, the AI Act, was amended in July 2026 by Regulation (EU) 2026/1744, the Digital Omnibus on AI (1, European Union, 2024) (2, European Union, 2026). The amendment moved the application of the high-risk obligations of Annex III to 2 December 2027 and those for high-risk systems embedded in Annex I products to 2 August 2028, as AI Governance, Chapter 3, records (168, Nordqvist, 2026). The dates are observable law. The controls take longer to build than any plausible delay, so the architect treats them as the order of work, not a reason to wait. Five articles matter most to the architect.

Article 4, AI literacy. Providers and deployers must take measures to support a sufficient level of AI literacy among the people who operate and use AI systems on their behalf; the Commission's questions and answers explain how it expects the duty to be met (4, European Commission, 2026). The wording was adjusted by the Digital Omnibus on AI, but the architectural implication is stable: literacy is role-specific and must be evidenced. AI Governance, Chapter 14, concluded that the evidence is a competence framework with individual records checked at the readiness gate (168, Nordqvist, 2026). The architect's contribution is the record structure and the gate, not the course.

Article 9, risk management system. For a high-risk AI system the provider must run a continuous, iterative risk management process across the life cycle, which identifies and analyses known and reasonably foreseeable risks, adopts measures to address them and tests the system against defined metrics (1, European Union, 2024). Read as architecture, Article 9 demands a risk file that is a living artefact: it is re-opened by a change of model, data or prompt, and each risk names the control and the test that treat it. This is the same risk-as-code discipline as Architecture as Code (Chapter 9C), where risk is a versioned record with an owner and expiring exceptions (167, Nordqvist, 2025). The architect owns the join between the risk file and the control catalogue, so that a risk without a control is visible as a gap rather than as a paragraph.

Article 14, human oversight. A high-risk system must be designed so that natural persons can oversee it effectively. Article 14(4) lists what the system must enable the assigned persons to do: understand its capacities and limits, remain aware of automation bias, interpret its output, decide not to use it or to disregard, override or reverse its output, and intervene or interrupt it through a stop procedure (1, European Union, 2024). This book builds on the conclusion of AI Governance, Chapter 10, that oversight must be designed, not declared, with an interruption path, an override log and the authority to use them (168, Nordqvist, 2026). For the architect Article 14 is a requirement on the boundary: the stop procedure must lie outside the system it stops, the stop path of Chapter 10.

Article 15, accuracy, robustness and cybersecurity. High-risk systems must achieve an appropriate level of accuracy, robustness and cybersecurity throughout their life cycle. Article 15(5) requires resilience against attempts by unauthorised third parties to alter use, outputs or performance by exploiting vulnerabilities, and names measures against data poisoning, model poisoning, adversarial examples and confidentiality attacks (1, European Union, 2024). AI Platform and Security, Chapter 16, concluded that security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance, and agent containment through identity, permission and egress (169, Nordqvist, 2026). Article 15 makes that an obligation, and the threat model and containment profile of Chapters 6 and 7 make it demonstrable.

Article 26, deployer obligations. A deployer of a high-risk system must use it in accordance with the instructions for use, assign human oversight to natural persons who have the necessary competence, training and authority, ensure that input data under its control is relevant, monitor operation, inform the provider and authorities of risks and serious incidents, keep the logs under its control for at least six months, and inform workers and the people subject to decisions (1, European Union, 2024). Public authorities that deploy such systems must also carry out a fundamental rights impact assessment under Article 27 and register their use under Article 49. The phrase "under its control" is the architectural hinge: a deployer cannot keep logs that a supplier writes only to the supplier's own environment, so the requirement belongs in the contract and in the data flow (Chapter 20).

Article 26 applies to high-risk systems only, and classification follows purpose, not technology. The Commission's draft classification guidelines are not final (3, European Commission, 2026), so the architect records each classification with its reasoning and re-opens it when final guidelines appear, which is expected. A deployer that substantially modifies or repurposes a system can also become its provider, so the architect watches the line between configuring a procured system and changing it.

NIS 2

Directive (EU) 2022/2555, NIS 2, is a directive: its obligations reach organisations through national transposition, and the details differ by Member State (6, European Union, 2022). Three articles carry the architect's work.

Article 20, governance. The management bodies of essential and important entities must approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation and can be held liable for infringements (Article 20(1)). Their members must follow training that lets them identify risks and assess risk-management practices, and the entity must offer similar training to employees (Article 20(2)) (6, European Union, 2022). Article 20(1) leaves the liability rules for public institutions and officials to national law (6, European Union, 2022). The architectural implication is that approval needs something to approve: a body cannot approve measures that exist only as a policy library, or oversee implementation without evidence that arrives regularly in a form it can read.

Article 21, cybersecurity risk-management measures. Entities must take appropriate and proportionate technical, operational and organisational measures, on an all-hazards basis, and Article 21(2) lists the minimum: risk analysis and information-system security policies, incident handling, business continuity and crisis management, supply-chain security, security in acquisition, development and maintenance including vulnerability handling and disclosure, policies to assess the effectiveness of measures, basic cyber hygiene and training, cryptography, human-resources security, access control and asset management, and multi-factor authentication (6, European Union, 2022). Article 21(3) requires entities to consider the vulnerabilities specific to each direct supplier and the quality of its products and secure-development practices. For an organisation that buys most of its systems this is a procurement article before it is a technical one. Commission Implementing Regulation (EU) 2024/2690 applies the measures in detail to certain digital-infrastructure and ICT-service entities, among them managed security service providers, and ENISA's guidance explains it (7, European Commission, 2024) (8, ENISA, 2025). A public authority meets it from the other side: it is a good statement of what to write into the contract with its managed security service provider.

Article 23, reporting. A significant incident must be notified to the national CSIRT or competent authority in stages: an early warning without undue delay and in any event within 24 hours of becoming aware, an incident notification within 72 hours, an intermediate report on request and a final report not later than one month after the incident notification (Article 23(4)) (6, European Union, 2022). Read as a log requirement, Article 23 demands that the organisation can establish the moment of awareness, classify the incident and assemble the facts for each stage from records it already holds. This book builds on the conclusion of AI Platform and Security, Chapters 17 and 21, that the reporting deadlines are design constraints on the logs and that AI incident handling adds an AI classification step (169, Nordqvist, 2026).

DORA

Regulation (EU) 2022/2554, DORA, applies directly to financial entities, which include insurance and reinsurance undertakings, and has applied since 17 January 2025 (9, European Union, 2022). The EIOPA Opinion on AI governance and risk management addresses insurers' use of AI and expects existing sectoral governance and risk-management requirements to be applied to AI in proportion to the risk (20, EIOPA, 2025). Four articles matter to the architect.

Article 5, governance and organisation. The management body defines, approves, oversees and is responsible for the arrangements related to the ICT risk-management framework, bears ultimate responsibility for managing ICT risk, and must keep its knowledge and skills up to date, including through regular training (Article 5(2) and 5(4)) (9, European Union, 2022). Of the four instruments DORA is the most explicit that responsibility cannot be delegated downwards. AI Governance, Chapter 13, and AI Red Team, Chapter 6, drew the same conclusion for AI: neither NIS 2 Article 20 nor DORA Article 5 lets responsibility pass to a tool, so every machine identity has an owner, operators and an authority who are named people (168, Nordqvist, 2026) (170, Nordqvist, 2026).

Article 6, the ICT risk-management framework. The framework must protect all information and ICT assets, be documented, be reviewed at least yearly and after major incidents, and have its oversight assigned to a control function with an appropriate level of independence (9, European Union, 2022). Commission Delegated Regulation (EU) 2024/1774 specifies the tools and policies, among them asset management, identity and access, change management and logging (10, European Commission, 2024). The control catalogue is the framework in executable form, and a model, prompt or agent configuration is an ICT asset whose change is an ICT change.

Article 17, incident management. Financial entities must establish an ICT-related incident management process covering detection, logging, categorisation, classification, roles, communication plans, reporting to senior management and the management body for major incidents, and response procedures (Article 17(3)) (9, European Union, 2022). Articles 18 and 19 classify incidents and require initial, intermediate and final reports for major ones, with the time limits set in regulatory technical standards (209, European Commission, 2025).

Article 28, ICT third-party risk. Financial entities must manage ICT third-party risk as an integral part of ICT risk, keep a register of information on all contractual arrangements with ICT third-party service providers (Article 28(3)), assess providers before contracting, and have exit strategies for services that support critical or important functions (9, European Union, 2022). The templates for the register are set by an implementing standard (210, European Commission, 2024), and critical ICT third-party providers are subject to Union oversight, with the first designations made in November 2025 (11, ESAs, 2025). Every model provider, inference host and vector-database service an insurer uses is an ICT third-party service provider, and it belongs in the register before it is used. The architect connects the register to the model registry so that the second cannot admit a provider the first does not know.

The Cyber Resilience Act

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), imposes cybersecurity requirements on products with digital elements placed on the Union market, and the obligations fall on manufacturers, importers and distributors (12, European Union, 2024). An organisation that builds software only for its own use does not place a product on the market and is mostly outside the Act as a manufacturer. It is inside the Act as a buyer, because the products it procures will carry the manufacturer's duties, and the architect uses those duties as the standard for supplier requirements.

Article 13, obligations of manufacturers. Manufacturers must design, develop and produce products in accordance with the essential requirements of Annex I, Part I, and must handle vulnerabilities in accordance with Annex I, Part II. They must exercise due diligence when integrating third-party components, including open-source components, and must determine a support period, which is in general at least five years (12, European Union, 2024). Annex I asks, among other things, for products delivered without known exploitable vulnerabilities, secure-by-default configuration, protection against unauthorised access, minimised attack surface, security-relevant logging, and in Part II a software bill of materials, remediation of vulnerabilities without delay, regular testing, a coordinated vulnerability disclosure policy and security updates provided free of charge.

Article 14, reporting. A manufacturer must notify actively exploited vulnerabilities and severe incidents that affect the security of its product: an early warning within 24 hours of becoming aware, a notification within 72 hours and a final report, after a corrective measure is available for a vulnerability or within one month for an incident, through a single reporting platform to the designated CSIRT and ENISA (12, European Union, 2024) (13, European Commission, 2026). The reporting obligations apply from 11 September 2026; most other obligations apply from 11 December 2027. (Observable.)

Two implications follow. The SBOM and vulnerability-handling requirements of Annex I are the minimum a procured product should provide, and for AI-enabled products the discipline extends to models and datasets through the ML-BOM (169, Nordqvist, 2026). And a high-risk AI system that is also in scope of the CRA and meets its essential requirements is, under Article 12 of the Cyber Resilience Act, deemed to meet the cybersecurity requirement of Article 15 of the AI Act in so far as the declaration of conformity shows it (12, European Union, 2024), so one piece of supplier evidence serves two instruments and belongs in every tender.

Personal accountability and the architect

The instruments distribute accountability along three lines, and a mapping that blurs them misleads the people who rely on it.

The entity and its management body. NIS 2 Article 20 and DORA Article 5 place approval, oversight and ultimate responsibility on the management body, and Article 20(1) states that members can be held liable. The AI Act places the deployer's duties on the organisation, and public authorities carry the additional duties of Articles 27 and 49 (6, European Union, 2022) (9, European Union, 2022) (1, European Union, 2024). The management body cannot delegate this accountability to a committee, a supplier, a tool or an architect; it can delegate tasks, with evidence.

The control owner and the oversight person. Below the body, accountability becomes concrete in named people: the system owner who answers for a system's operation, the oversight persons Article 26(2) of the AI Act requires, the operators and the authority of a machine identity (AI Red Team, Chapter 6), and the owner of each catalogue control (170, Nordqvist, 2026). The architect makes sure the role exists, the name is real and the person has the competence and authority the article requires. A control whose owner is a team alias or a retired role is a failed control, whatever its test says.

The architect's professional responsibility. The instruments do not name the architect, and this book does not claim that they create personal legal liability for the architect; that depends on national law and employment terms. Professional responsibility is different, and the role charter of Chapter 4 defines it: the architect answers for the soundness of the design advised, the faithfulness of the mapping from article to control, the honesty of the evidence classification, and the escalation of a risk the architect cannot accept. The charter writes down what the architect decides, what the architect advises on and what only the management body can accept.

The architect equips the management body to discharge duties that stay with it, and owes it five things.

  1. Decision-ready information. A management body that must approve measures needs a short account of what exists, what is verified, what is failed, what is declared without evidence and which decisions it is asked to take. Chapter 19 treats the one-page report.
  2. Training from the organisation's own estate. Article 20(2) and Article 5(4) require training. The architect contributes scenarios such as an agent exceeding its mandate or a supplier failing, so that the body practises the decisions it will face.
  3. Risks and exceptions put as decisions. A residual risk reaches the body as a decision with an option, an owner and an expiry, not as a heading in a report. Chapter 17 covers exceptions as expiring records.
  4. Evidence of operation. The body is told which controls are verified by tests that ran, which are declared by an attestation and which have failed, using the classification of Chapter 9. Reporting a declared control as verified is the one failure the architect cannot allow.
  5. A record of advice. When the architect advises against a decision, the advice is dated and kept with the decision record.

Where an agent proposes, drafts or acts under a mandate, the accountable person remains a named human. At Level 3 Bounded, human approval moves from the single action to the playbook and the decision record, so accountability concentrates on whoever approves the playbook (170, Nordqvist, 2026). The architect makes sure that person is identified, knows the autonomy line and can withdraw the playbook. An AI-drafted mapping from article to control is a proposal, and the architect verifies it against the text of the article before it enters the catalogue (Chapter 14).

From article to control

The control catalogue of Chapter 9 is the home of the mapping: each entry carries an identifier, an owner, a configuration, a test, an evidence source and a field naming the obligations it satisfies. Architecture as Code (Chapter 10) called the principle assure once, comply many: write the control once, map it to many obligations, and let the evidence serve all of them (167, Nordqvist, 2025). The mapping changes when a regulation changes, and a supervisor or auditor reads it first.

Practical guide: Turning an article into a control

Purpose. To convert one article into a catalogue control with a test and an evidence record that survive audit review and a change in the text.

Roles. The security architect leads; the control owner accepts ownership; counsel or the data protection officer confirms the reading.

Steps.

  1. Identify the addressee and the verb. Quote the article, name who it binds (entity, management body, provider, deployer, manufacturer) and underline the verb. If the addressee is the management body and the verb is approve or oversee, the output is an information requirement, not a control.
  2. State the property. Write one sentence of the form "X holds for Y, checked every Z." If no test can fail, the property is not yet an engineering statement.
  3. Search the catalogue first. Reuse a control that already satisfies the property and add the article to its mapping; write a new one only when none does. Duplicate controls are the usual cause of conflicting evidence.
  4. Write the test. The test must fail when the property is false, run on every relevant change and additionally on a schedule not longer than the article's own cycle (for a reporting clock, daily; for a yearly review, monthly check that the review is scheduled). A test that cannot fail does not count.
  5. Name the evidence and its keeper. State what the test or the operation produces, where it is stored, how long it is kept and who can read it. Classify the control as verified, declared or failed.
  6. Record the reading and the triggers. Write the interpretation as a short decision record with the reviewer's name, and set review triggers: a change of the article, a new guideline, a major incident, a change of scope. Assign a review date no longer than twelve months away.

Worked line. The table shows the six steps for one article.

Step Result for NIS 2 Article 23(4)(a)
Addressee and verb Essential or important entity; notify an early warning
Property Within 24 hours of awareness, the entity can submit an early warning, checked quarterly by exercise and on each change to the incident pipeline
Catalogue search Existing incident classification control reused; new control for the awareness timestamp
Test Replay of a synthetic incident asserts the awareness timestamp and a generated early-warning draft in under four hours
Evidence Signed replay result, pipeline version, name of the approver
Reading and triggers Reviewed by counsel; triggers are national transposition guidance, a pipeline change and any significant incident

Definition of done. The article appears in the mapping file with a control identifier, an owner, a passing test, an evidence location and a review date; someone other than the author has read the entry; and the coverage report lists the article as verified or, honestly, as declared.

The four-hour default leaves most of the 24 hours for human judgement; adapt it to the organisation's risk appetite and incident volume.

Worked example: Hansa Mutual's article-to-control mapping

This illustrative mapping belongs to the group catalogue of about 180 controls and covers the claims-triage agent (Mode 5, AIDR-0024), which routes claims for the German, Dutch, Swedish and Norwegian entities through the Polish service centre. Annex III, point 5(c), concerns risk assessment and pricing for life and health insurance, not claims routing, so the agent is recorded as not high-risk. The mapping treats AI Act Article 26 as conditional for the agent; it applies today to the underwriting-support model, which shares the same oversight service.

apiVersion: catalogue.hansa.example/v1
kind: RegulatoryMapping
metadata:
  id: MAP-HM-CLAIMS-TRIAGE-01
  decision: AIDR-0568
  system: claims-triage-agent
  reviewer: group-legal-counsel
  review_by: 2027-10-31
  triggers: [model-change, tool-change, guideline-change, major-incident]
scope:
  law: [DE, NL, SE]
  group_policy: [NO]
  local_regimes: {UK: local-security-officer, CH: local-security-officer}
ai_act_classification: {high_risk: false, record: AIDR-0024}
mappings:
  - article: DORA Art. 6(2)
    property: Every model, prompt and tool configuration of the agent is a registered ICT asset
    control: CTRL-ICT-006
    test: asset-inventory-reconciliation
    cadence: daily
    evidence: signed-inventory-diff
    owner: head-of-group-ai-platform
    status: verified
  - article: DORA Art. 17(3) and 19
    property: An agent incident is classified and clocked within the incident pipeline
    control: CTRL-INC-004
    test: synthetic-incident-replay
    cadence: quarterly
    evidence: signed-replay-result
    owner: incident-response-lead
    status: verified
  - article: DORA Art. 28(3)
    property: No model provider is callable unless present in the register of information
    control: CTRL-ICT-028
    test: gateway-denies-unregistered-provider
    cadence: per-release
    evidence: gateway-policy-test-report
    owner: head-of-group-ai-platform
    status: verified
  - article: AI Act Art. 26(2), 26(5), 26(6)
    applies_if: ai_act_classification.high_risk
    property: Named oversight persons, monitoring and six-month log retention
    control: CTRL-OVR-002
    test: oversight-rota-and-retention-check
    cadence: monthly
    evidence: rota-record-and-retention-config
    owner: polish-centre-operations-lead
    status: declared   # pre-built; not verified until the condition is met

The condition on the Article 26 entry records that the control is built and does not yet apply, so a change of classification starts a review rather than a project. The declared status is honest: a condition not yet met is not evidence of operation.

Worked example: Nordvik Region's mapping to tender requirements

Nordvik buys the benefits-triage system from TriageSoft under tender NR-2026-117. It is a high-risk system under Annex III, point 5(a), and the Region is its deployer. The architect maps the articles that fall on the Region to requirements on the supplier, because the controls sit in the supplier's system. The excerpt is illustrative; Chapter 20 develops the full annex as code.

apiVersion: procurement.nordvik.example/v1
kind: TenderRequirementMapping
metadata:
  tender: NR-2026-117
  supplier: TriageSoft
  decision: AIDR-0513
  owner: security-architect
requirements:
  - id: REQ-LOG-01
    source: [AI Act Art. 26(6), NIS 2 Art. 21(2)(b)]
    text: Event logs of the ranking service are written to the Region's platform and retained at least 183 days
    evidence: retention-config-export
  - id: REQ-OVR-01
    source: [AI Act Art. 14(4)(d), 14(4)(e)]
    text: The system exposes an interruption interface and an override record that the Region operates without the supplier
    evidence: quarterly-stop-test-report
  - id: REQ-INC-01
    source: [NIS 2 Art. 23(4), AI Act Art. 26(5)]
    text: The supplier notifies the Region within 12 hours of becoming aware of an incident affecting the service
    evidence: signed-notification-test
  - id: REQ-VUL-01
    source: [NIS 2 Art. 21(2)(e), 21(3), CRA Annex I Part II]
    text: SBOM per release, coordinated disclosure policy, remediation without delay
    evidence: sbom-and-advisory-feed
  - id: REQ-CRA-01
    source: [CRA Art. 13, 14]
    text: From the date the Act applies to the product, the supplier meets the manufacturer duties and reports exploited vulnerabilities to the Region at the time it reports them to the authorities
    evidence: declaration-of-conformity-and-reporting-procedure

The twelve-hour default in REQ-INC-01 leaves the Region half of the NIS 2 early-warning period; adapt it to the supplier's ability and the Region's risk appetite.

Across the usage modes

The AI Act attaches duties to the role (provider or deployer) and the risk class, not to the usage mode. The mode still determines where each duty can be met and what the architect designs (169, Nordqvist, 2026).

Mode Duties that bite most Where the architect acts
Mode 0 Ambient AI AI Act Article 4; NIS 2 Article 21(3) and DORA Article 28 for the vendor feature Inventory of vendor AI features; supplier evidence; contract clauses
Mode 1 Conversational assistants Article 4; GDPR for personal data in prompts Approved tool, use rules, data classification at the gateway
Mode 2 Embedded workplace assistants Article 4; Article 26 if used for an Annex III purpose; Article 25 repurposing Scope limits; register of information entry for the provider
Mode 3 Agentic work tools Article 4; NIS 2 Article 21(2)(e) for what the tool produces Containment of the tool; identity is the person's; review of output
Mode 4 Built AI applications Articles 9, 14, 15, 26 for high-risk systems; CRA if placed on the market Risk file, oversight design, logs, threat model, tender annex
Mode 5 Autonomous production agents Article 14 oversight where high-risk; DORA Articles 5, 6 and 17 Interruption path and override log, named owner, playbook approver, stop path

The subject differs by autonomy level too. Article 14(4) requires that the assigned person can disregard, override, reverse or interrupt the system. At Level 0 Advisory through Level 2 Supervised that is met by the design and quality of the approval; at Level 3 Bounded by the interruption path and the withdrawal of the playbook, because no per-action approval exists to reverse. Level 4 Autonomous is never used for irreversible actions, and a high-risk system is no candidate for it, because Article 14 presupposes a person who can intervene.

Where instruments overlap and conflict

The instruments overlap more than they conflict, and the architect's leverage lies in treating the overlap as one design. The reporting clocks are the clearest case.

Instrument and article Trigger First report Next Final
NIS 2 Article 23(4) Significant incident 24 hours, early warning 72 hours, notification One month after notification
DORA Articles 19 and RTS Major ICT-related incident Initial notification, within hours of classification and no later than 24 hours from awareness Intermediate report Final report, about one month
AI Act Article 73 Serious incident Within 15 days of awareness, sooner for the gravest cases Follow-up as needed Complete report after investigation
CRA Article 14 Actively exploited vulnerability or severe incident 24 hours, early warning 72 hours, notification 14 days after a fix or one month, by type
GDPR Article 33 Personal data breach 72 hours to the supervisory authority Further information in phases Not fixed

Table 18.1: Reporting clocks that one incident can start at once. Each clock starts at awareness, and each audience, content and threshold differs.

The deadlines come from the instruments and the technical standards beneath them (6, European Union, 2022) (209, European Commission, 2025) (1, European Union, 2024) (12, European Union, 2024) (5, European Union, 2016). One incident in a claims system can start the DORA, the GDPR and, if the cause is a vulnerability in a procured product, the CRA clocks, and may start an AI Act clock if a high-risk system is involved. The design answer is one incident pipeline with one awareness timestamp, one classification step that evaluates every regime and one evidence record from which each report is assembled, which AI Platform and Security, Chapter 3, described as the incident pipeline that starts the right clocks (169, Nordqvist, 2026).

Three overlaps and conflicts recur.

  • One control, several articles. The oversight service that meets Article 14 of the AI Act also supports DORA Article 5, because it shows a trained, identified human in command. The audit log that meets Article 12 and Article 26(6) also serves NIS 2 Article 21(2)(b) incident handling and DORA Article 17. The catalogue records this once, with several mappings.
  • Supplier duties in a chain. The AI Act provider, the NIS 2 direct supplier, the DORA ICT third-party provider and the CRA manufacturer are often one company facing four sets of expectations. A consolidated supplier requirement, as in the Nordvik example, asks once and receives evidence once.
  • Retention against minimisation. Logs must be kept for at least six months under the AI Act, while the GDPR requires minimisation of personal data. The resolution is a logging profile that keeps the required events and minimises the personal data inside them.

Some conflicts cannot be designed away. Definitions of incident and thresholds differ between regimes, supervisory interpretations differ between Member States, and the UK and Swiss entities of a multinational sit outside the EU instruments while a group baseline spans them. The architect records each as an open interpretation in the mapping, names who resolves it and sets a review trigger. Hiding unresolved questions, not recording them, is the failure.

The dates above are observable law. Supervisory practice on how these instruments apply to agents that act in production is expected to develop through guidance and enforcement, and no consolidated position yet exists. Whether the Union will consolidate the reporting regimes into a single channel is speculation, and this chapter does not rely on it.

Nordvik Region and Hansa Mutual

Nordvik falls within the national transposition of NIS 2 and is a deployer of the high-risk benefits-triage system. Its architect maps NIS 2 Article 21 and AI Act Articles 14 and 26 to tender requirements, as the excerpt above shows, and to the oversight design for the caseworkers, which keeps decisions with accountable officials. The architect also prepares the regional executive committee's training under NIS 2 Article 20, using the Region's own estate and the July 2026 incident as scenarios, and records the mapping as AIDR-0513. The leverage is the contract, because most controls sit in suppliers' systems, and the mapping and its evidence must survive public-access requests and archiving.

Hansa is subject to DORA in its EU entities, runs the high-risk underwriting-support model and operates the claims-triage agent in production. Its architects map DORA Articles 6, 17 and 28 and AI Act Articles 9, 14, 15 and 26 through the group control catalogue, with the mapping recorded as AIDR-0568, and brief the executive board in Hamburg as the management body under DORA Article 5. Where the AI Act or DORA does not apply by law, in Norway, the United Kingdom and Switzerland, the group applies its controls as group policy while the local security officers keep the local mapping, so the mapping records, entry by entry, whether an obligation is law or policy. The leverage is the platform: a control in the shared platform serves every market.

Neither manufactures products for the market, so both use the CRA's Articles 13 and 14 and Annex I as the standard they ask suppliers to meet.

Summary

European regulation is addressed to entities, management bodies, providers, deployers and manufacturers, and the security architect turns its articles into controls that run. The AI Act's Articles 4, 9, 14, 15 and 26 ask for evidenced literacy, a living risk file, designed oversight with a stop procedure, demonstrable cybersecurity and logs under the deployer's control. NIS 2 Articles 20, 21 and 23 ask for a trained, approving management body, measures that begin in procurement, and reporting clocks that are log requirements. DORA Articles 5, 6, 17 and 28 add ultimate responsibility in the management body, a framework that treats models and agent configurations as ICT assets, incident management and a register of every provider. The Cyber Resilience Act's Articles 13 and 14 and Annex I set the standard a procured product should meet.

The chapter concerns Shift 1, from documents to code, because the mapping, the control, the test and the evidence are version-controlled artefacts, and the six-step method turns an article into a line of the catalogue. It concerns Shift 2, from gatekeeper to boundary designer, because the architect does not stand at every system's gate but writes the mapping, the consolidated supplier requirement and the decision rights that let others decide within them. It concerns Shift 3, from periodic to continuous, at machine speed, because the reporting clocks run in hours and days and are met by one incident pipeline with one awareness timestamp, not by a meeting.

The chapter separated accountability from responsibility. The management body keeps approval, oversight and ultimate responsibility under NIS 2 Article 20 and DORA Article 5, and neither passes to a tool or to an architect. The architect's professional responsibility is the soundness of the design, the faithfulness of the mapping, the honesty of the evidence classification and the escalation of risk the architect cannot accept. What the architect owes the body is decision-ready information, training drawn from its own estate, risks put as decisions, evidence of operation and a record of advice.

Nordvik maps the instruments to tender requirements and the oversight design, because its leverage is the contract; Hansa maps them through a catalogue and a platform, because its leverage is the platform. Chapter 19 turns to the audiences who rely on the result: how the same architecture and the same evidence are communicated honestly to boards, supervisors, auditors, engineers and suppliers.

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 (2026). 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. (2, European Union, 2026)
  3. European Commission (2026). Draft Commission guidelines on the classification of high-risk AI systems. (3, European Commission, 2026)
  4. European Commission (2026). AI literacy: questions and answers. (4, European Commission, 2026)
  5. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). (5, European Union, 2016)
  6. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (6, European Union, 2022)
  7. European Commission (2024). Commission Implementing Regulation (EU) 2024/2690. (7, European Commission, 2024)
  8. European Union Agency for Cybersecurity (2025). Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
  9. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
  10. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774. (10, European Commission, 2024)
  11. European Supervisory Authorities: EBA, EIOPA and ESMA (2025). European Supervisory Authorities designate critical ICT third-party providers. (11, ESAs, 2025)
  12. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act). (12, European Union, 2024)
  13. European Commission (2026). Cyber Resilience Act – Reporting obligations. (13, European Commission, 2026)
  14. European Insurance and Occupational Pensions Authority (2025). Opinion on Artificial Intelligence governance and risk management. (20, EIOPA, 2025)
  15. European Commission (2025). Commission Delegated Regulation (EU) 2025/301 (time limits and content of major ICT-related incident reports under DORA). (209, European Commission, 2025)
  16. European Commission (2024). Commission Implementing Regulation (EU) 2024/2956 (templates for the DORA register of information). (210, European Commission, 2024)
  17. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  18. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  19. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  20. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)