AI Operations · Whitepaper

Chapter 23 · Operations in the Organisation

Regulation as Constraint

DORA, NIS 2, CER, the AI Act, the GDPR and the Data Act

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 10 November 2026
Build number 2026.11
it-operations site-reliability-engineering ai-governance architecture-as-code ai-agents
Figure 23.1: Seven instruments land on the five operations functions and leave the organisation with controls, evidence and clocks. The mapping table later in the chapter gives the articles per function.
Figure 23.1: Seven instruments land on the five operations functions and leave the organisation with controls, evidence and clocks. The mapping table later in the chapter gives the articles per function.

European regulation reaches operations as clocks, records, tests and named people. It does not describe an operations loop and says little about how far a machine may act; it states outcomes an operations organisation must be able to show: services that continue, incidents recorded and reported within hours, recovery that has been tested, providers that can be left, and a management body that answers for all of it. This chapter maps the instruments to the five functions of the loop at the level of the article, and it concerns all five: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain. It covers DORA (Regulation (EU) 2022/2554), NIS 2 with two national forms, the CER Directive, the AI Act, the GDPR, the Data Act and, at the edge, the Cyber Solidarity Act, and closes with the rules on working time and co-determination that govern the people who run the loop. Every article number was read against the live text on EUR-Lex, or in the gazette of the member state concerned, on 10 November 2026. The statements are organisational and architectural implications and not legal advice.

The chapter builds on conclusions of the earlier volumes: AI literacy is evidenced in competence records, and Articles 14 and 26(2) of the AI Act still demand competent oversight (AI Governance, Chapter 14, F25) (296, Nordqvist, 2026); reporting deadlines are design constraints on the logs (AI Platform and Security, Chapters 17 and 21, F46) (297, Nordqvist, 2026); duties fall on named people and management bodies and accountability cannot be delegated to a system (The Transformed Security Architect, Chapter 18, F78) (300, Nordqvist, 2026); monitoring and scoring of workers falls within co-determination and data-protection law, and agreements govern classes of change (AI Boss, Chapters 13 and 23, F86) (301, Nordqvist, 2026); one incident can open several clocks, and AI drafts while a person classifies and sends (AI Blue, Chapter 19, F106) (302, Nordqvist, 2026); and a register that maps each obligation to a control and to evidence with an age is re-verified every six months (AI Purple, Chapter 21, F135) (304, Nordqvist, 2026). Chapter 4 defines the autonomy budget and the observer principle used here, and Chapter 14 gives the reporting clocks in detail.

A row of the mapping has five parts: the instrument and article, the duty in the words of the text, the function or functions that perform it, the control, and the evidence that the control works, with an age. A duty does not belong to one function (Chapter 4): a restore test serves DORA Article 12, NIS 2 Article 21(2)(c), GDPR Article 32(1)(c) and the CER resilience measures at once. The mapping therefore starts from the control and the evidence and lists the instruments each serves.

Primary topics explored

  1. How to read the mapping
  2. Who is in scope
  3. DORA, article by article
  4. NIS 2: Articles 20, 21, 23 and 24
  5. The CER Directive
  6. The AI Act: Articles 4, 12, 14, 26, 72 and 73

About AI Operations

AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.

Who should read this

CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 23: Regulation as Constraint: DORA, NIS 2, CER, the AI Act, the GDPR and the Data Act in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Operations in the Organisation” and is one of 35 drawn from the manuscript.