An emulation is an authorised attack on one's own estate, and the law has views on every word of that sentence: who may authorise, who may be the tester, which systems may be touched, what happens to personal data, which people must be told and which must not, and what must be reported if the exercise goes wrong. This chapter sets out that frame for the two stages it constrains most directly, P1 Target, where the scenarios and the rules under which they may run are chosen, and P2 Emulate, where adversary behaviour is run by people, AI-assisted tooling or a pipeline. It also marks where the instruments reach P3 Observe, P4 Improve and P5 Verify, because the duty to remedy and to assess effectiveness does not stop when the window closes.
Each statement below is attributed to an instrument and an article and read as an architectural implication: what a manifest, a policy decision point, a register or a contract has to contain so that the organisation can show it acted within the frame. None of it is legal advice, and national law decides where the chapter names a national example. The article numbers were checked against the official texts when the chapter was written; the practical guide makes that check a recurring control, because the text moves.
The chapter builds on conclusions that earlier volumes recorded: that in public authorities legality comes before capability (AI Governance, Chapter 17; F31) (88, Nordqvist, 2026); that reporting deadlines are design constraints on the logs (AI Platform and Security, Chapters 17 and 21; F46) (89, Nordqvist, 2026); that regulation places duties on named people and cannot be delegated to a system (The Transformed Security Architect, Chapter 18; F78) (92, Nordqvist, 2026); that co-determination and data-protection law govern the monitoring of staff (AI Boss, Chapters 13 and 23; F86) (93, Nordqvist, 2026); and the mapping of the instruments onto the blue team as clocks, records and named people (AI Blue, Chapter 19; F106) (94, Nordqvist, 2026). The chapter does not repeat the clocks; it adds the regulation of testing, testers, exercise data and exposed staff, and the criminal-law line that authorisation draws.
Primary topics explored
- Which regime applies to whom
- DORA and threat-led penetration testing
- TIBER-EU and the national frameworks
- NIS 2
- The AI Act
- The Cyber Resilience Act
About AI Purple
AI Purple is Book 9 of The Transformed Architecture. It takes the loop between the red team and the blue team as its subject and asks what happens when AI sits on both sides of the table: the five stages of the loop (target, emulate, observe, improve, verify), rules of engagement and safe emulation, continuous emulation, the independence principle, coverage as a claim that needs evidence, the loop's own AI and how to defend it, operating models, decision rights, regulation, 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 and AI Blue.
Chief information security officers, heads of security operations, red-team leads, penetration testers, SOC managers, detection engineers, purple-team coordinators and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 21: Regulation as Constraint: DORA, TIBER-EU, NIS 2, the AI Act, the GDPR and Employee Rights in AI Purple gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Loop in the Organisation” and is one of 33 drawn from the manuscript.