Introduction: Putting AI to Work in Cyber Defence

For most of the last decade, security teams in European enterprises and public authorities met artificial intelligence as a feature in a product they had bought, or as a new kind of system they had been asked to protect. The first three volumes of The Transformed Architecture followed that order. Architecture as Code made architecture executable, so that decisions, policies and evidence live in version control and are validated continuously (71, Nordqvist, 2025). AI Governance made the governance of AI executable and proportionate to how AI is used (72, Nordqvist, 2026). AI Platform and Security built the platform on which AI runs and secured it, and concluded that AI is now both a target and a source of threat (73, Nordqvist, 2026).

This book turns the question around. If attackers already use AI to find weaknesses, write convincing lures and run parts of an intrusion faster than a person can, defenders cannot afford to treat AI only as something to protect. They must put it to work: in the red team that emulates the adversary, in the testing of their own AI systems, in the blue team that detects and responds, and in the loop that turns each finding into a control that has been shown to work. AI Red Team is about doing that in large European organisations, under European law, and without losing the discipline the earlier volumes established.

Why this book, and why now

Three developments have changed the defender's position in a short time, and each is documented rather than forecast.

The first is the speed of exploitation. Mandiant's analysis of time-to-exploit found that the average time taken to exploit a vulnerability, before or after a patch was released, fell to five days in 2023, and that a growing share of the vulnerabilities it tracked as exploited (97 of 138 in 2023) were exploited as zero-days, before a patch was available (44, Charrier & Weiner, 2024). AI Platform and Security, Chapter 18, traced how AI-assisted vulnerability discovery compresses that window further (73, Nordqvist, 2026), and the Five Eyes agencies likewise state that AI is shortening the time between vulnerability discovery and exploitation (39, Five Eyes agencies, 2026). A defence organised around a monthly patch cycle and a weekly change advisory board is therefore structurally too slow for the most exposed part of its estate.

The second is the move from AI as an aid to attackers towards AI as an operator. By late 2025 Anthropic reported disrupting what it described as the first AI-orchestrated cyber-espionage campaign, in which a model carried out a large part of the operational work under human direction (52, Anthropic, 2025). In 2026 Google's threat-intelligence group described the evolution "from prompting to autonomy" in adversarial use of AI (48, Google GTIG, 2026), and the Five Eyes cyber-security agencies urged leaders to act on the shift AI brings to cyber risk (39, Five Eyes agencies, 2026). The United Kingdom's National Cyber Security Centre had already assessed that AI would almost certainly increase the frequency and intensity of cyber threats up to 2027 (37, NCSC, 2025), and the ENISA Threat Landscape 2026 records an increasing use of AI by cybercriminals, State-nexus groups and information manipulation sets (34, ENISA, 2026).

The third development is on the defender's side, because the same capabilities help defenders too. DARPA's AI Cyber Challenge showed AI systems finding and patching vulnerabilities in real open-source software at competition scale (59, DARPA, 2025). Anthropic's assessment of its Mythos Preview model and its Project Glasswing programme showed both how strong the capability had become and why its release had to be managed carefully (61, Carlini et al., 2026) (60, Anthropic, 2026).

An attacker needs one path that works; a defender must close many while the exploitation window narrows. AI does not remove that asymmetry, but if defenders explore their own estate at machine speed, under control, they can close many weaknesses before attackers find them. AI as an active part of cyber defence therefore does not mean handing the security operation to a model. It means that AI does work people cannot do at the required speed or scale, inside boundaries people set, at a level of autonomy that matches the consequences of a mistake, and with evidence of what it did.

What the series has already established

The book builds on the earlier volumes' conclusions, recorded in SERIES_FOUNDATIONS.md; the most important are summarised here.

From Architecture as Code the book takes the conviction that security belongs in the codebase (71, Nordqvist, 2025). Threat models, policies and evidence are versioned artefacts, and a finding is finished not when it is discovered but when the remediation pull request is merged. AI agents can take part in engineering work provided that "agents draft; humans approve". The closing chapter left an open problem that runs through this book: version control records what changed, but not whether the reasoning behind a change was sound.

From AI Governance the book takes the principle that governance is effective when it is codified, evidenced and proportionate to the usage mode and the risk (72, Nordqvist, 2026). It takes the six usage modes, the insistence that human oversight be designed rather than declared, and above all the lesson of the July 2026 OpenAI–Hugging Face incident (64, OpenAI, 2026): govern every agent as a well-meaning insider, because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences.

From AI Platform and Security the book takes the platform itself (73, Nordqvist, 2026). A platform is under control when every model call and tool call passes a policy point outside the model and evidence is a by-product of normal operation. Prompt injection is a property of the architecture rather than a defect to be patched, and containment of agents must not depend on their intent. Its Chapter 18 ended with four commitments against AI-enabled adversaries, the last of which, the use of AI for defence under oversight, is where this book begins. The open questions it inherits, such as how to keep AI-enabled adversary emulation safe and when a defensive AI may act without per-action approval, return in Chapter 28.

NIST CSF 2.0 with an AI focus

Cyber defence is wider than the security operations centre, where AI is most visible: it starts with governance and risk strategy, depends on knowing what the organisation owns and what threatens it, relies on protective controls, and only then detects, responds and recovers. To leave no part out, this book is organised by the NIST Cybersecurity Framework (CSF) 2.0 (19, NIST, 2024).

CSF 2.0 organises cybersecurity outcomes into six Functions: Govern sets and monitors risk strategy and policy, Identify understands current risks, Protect applies safeguards, Detect finds possible attacks, Respond acts on incidents, and Recover restores assets and operations. Recover is the most neglected Function and the one where AI can change the most, by making recovery fast, verified and continuously rehearsed, so it has a part of its own. Below the Functions sit 22 Categories, such as ID.RA Risk Assessment or DE.AE Adverse Event Analysis, and below them Subcategories that describe concrete outcomes. Because CSF describes outcomes rather than controls or products, it suits a book about architecture. It is a framework, not law; Chapter 3 maps its outcomes to NIS 2, DORA, the Cyber Resilience Act, the AI Act and ISO/IEC 27001.

The AI focus comes from NIST's Cyber AI Profile, published as an initial preliminary draft in December 2025, which organises the AI dimension of every CSF outcome into three focus areas (20, NIST, 2025). The book adopts them as its AI perspective on each Category:

  • Securing AI systems: the organisation's own AI, including the security AI it introduces, as something to protect and contain, building on AI Platform and Security.
  • AI-enabled cyber defence: AI as a tool for achieving the Category's outcomes faster, more completely or at greater scale.
  • Thwarting AI-enabled attacks: how the Category must change when attackers use AI.

The parts follow the Functions, as the figure below shows. Part I lays the foundations (Chapters 2 to 4); Parts II to VII cover Govern, Identify, Protect, Detect, Respond and Recover in turn; and Part VIII verifies and closes the loop with security chaos engineering (Chapter 25), purple teaming and measurement (Chapter 26) and the conclusions (Chapters 27 and 28). The repository page CSF_COVERAGE.md shows the chapter responsible for each Category.

The six CSF Functions and the three AI focus areas, resting on the foundations of the earlier volumes

Figure 1.1: The six CSF Functions and the three AI focus areas, resting on the foundations of the earlier volumes.

Usage modes: from human judgement to machine identity

The earlier volumes distinguish six usage modes of large language models, because the way AI is used, not the brand of model, determines its risks, controls and governance (72, Nordqvist, 2026) (73, Nordqvist, 2026). In the lower modes AI supports a manual process and a person makes the judgement. In the highest mode AI runs with an identity and permissions of its own, and the problem changes in kind: the question is no longer whether a person is misled by a poor suggestion, but what a privileged machine identity does when it is wrong, manipulated or compromised.

Two features of security work sharpen every mode. Much of what security AI reads, from log lines to malware samples, is written by the adversary, so any field an attacker can influence is a channel for prompt injection. Moreover, security AI has access to sensitive telemetry and, in the higher modes, the authority to change the estate, which makes it a target in its own right.

Mode In cyber defence Characteristic vulnerability Who judges, with whose identity
Mode 0 Ambient AI Vendor AI in security products Invisible decisions; some features act automatically, so the vendor has chosen an autonomy level The vendor's model
Mode 1 Conversational assistants An analyst asks for help with a log or query Telemetry pasted outside; plausible but wrong analysis; injection through pasted content A person, in their own session
Mode 2 Embedded workplace assistants AI in ticketing or SIEM that summarises incidents Inherits the user's permissions; injection through documents and mails A person, through delegated access
Mode 3 Agentic work tools Coding agents that write detections or run tools Acts with the engineer's credentials beyond the task; the July 2026 incident began here A person reviews, but the agent acts with the person's identity in between
Mode 4 Built AI applications A triage assistant the organisation builds and runs The organisation is the provider; attacker-controlled alert fields reach the model A person acts; the service has its own read-only identity
Mode 5 Autonomous production agents A SOC agent that contains hosts and revokes sessions A privileged well-meaning insider that can be manipulated or have its credentials stolen The agent, within codified bounds, with its own identity

The usage mode and the autonomy level describe different things. The mode describes how the AI is deployed: where it runs, whose identity it uses and what it can reach. The level describes who decides each action. Modes 1 and 2 normally sit at Level 0 or 1, while Mode 5 is where Levels 2 and 3 live and where containment that does not depend on intent becomes essential. Mode 0 is the trap, because a security product may already act at Level 3 or 4 without the organisation deciding it. Every chapter in Parts II to VII therefore asks how its subject differs across the modes, and Chapter 6 shows how mode and level are decided together.

Red, blue and purple across the Functions

A red team emulates real adversaries, under authorisation, to find out whether the organisation can prevent, detect and respond to them. CSF places improvements identified from tests and exercises under Identify, so adversary emulation (Chapter 12) and red teaming of the organisation's own AI (Chapter 13) sit in Part III, using the vocabularies of MITRE ATT&CK and MITRE ATLAS (10, MITRE, n.d.) (11, MITRE, n.d.). Yet every other Function is tested in the same way, for example whether approvals resist synthetic media (Protect) or whether the SOC sees an AI-accelerated intrusion (Detect), and the blue team, with AI inside it, appears in every Function too.

Three red threads tie the Functions together. The first pairs the usage modes with the autonomy levels defined in Chapter 6: Level 0 Advisory (the AI suggests; a person decides), Level 1 Assisted (the AI drafts; a person executes), Level 2 Supervised (the AI executes each action after approval), Level 3 Bounded (the AI executes pre-approved, reversible actions within a codified playbook, and a person can stop it) and Level 4 Autonomous (no per-action approval). The level belongs to a capability in a context, not to a model, and Level 4 is never used for offensive or irreversible actions. The second thread is the purple loop: every finding ends as a verified control, and the CSF profile is updated to show it (Chapter 26). The third is security chaos engineering: the organisation injects the conditions a control exists for and checks the outcome, and Chapter 25 describes the platform and its safety boundaries.

Rules of the book

A book about using offensive techniques for defence must be explicit about its limits. Four rules apply throughout.

The book is defensive. It describes adversary behaviour at the level needed to design controls, detections, tests and exercises, normally by MITRE ATT&CK and ATLAS technique. It contains no exploit code, malware, payloads, prompt-injection or jailbreak strings, phishing templates, evasion techniques or step-by-step intrusion instructions; its code examples are detections, evaluation-harness configurations, policy rules, rules-of-engagement manifests and evidence records.

Every offensive activity is authorised and scoped. No exercise runs without written rules of engagement naming the systems in scope, the permitted techniques, the stop conditions and the people who can invoke them (Chapter 7). Activities run only against the organisation's own or contracted systems, and Chapter 19 explains why hacking back is not active defence.

AI that acts is contained. Everything AI Platform and Security concluded about containment applies to security AI: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, a stop path outside the system it stops, recorded approvals and detection from telemetry rather than self-report (73, Nordqvist, 2026). The July 2026 incident showed that an agent in a security-testing context can exceed its mandate in ways its operators did not anticipate, and Chapter 12 treats the incident as a design input.

Every finding ends as a verified control. A red-team report that lists weaknesses and is then filed has failed, however accurate it is. Following Architecture as Code, the remediation is the point of the exercise, and every closed finding carries evidence of a re-test.

These rules are what makes AI-enabled red teaming acceptable at all: supervisors, works councils and boards will accept it only if they can see the mandate, the boundaries and the evidence.

The book is also open about how it was made. Most of its prose was drafted by specialist AI agents working under briefs, rules and automated checks that the author wrote, and every change reached the manuscript only after the author had reviewed and approved it, an arrangement that sits at Level 1 Assisted on the scale of Chapter 6. The judgements are the author's, and so is the responsibility. About the Author describes the arrangement.

The European setting

European law shapes both what defenders must do and what they may do. Chapters 3 and 7 treat the instruments in detail; this outline shows why they matter from the start.

The NIS 2 Directive requires essential and important entities to take appropriate and proportionate measures to manage cybersecurity risk, including policies for assessing their effectiveness, incident handling and vulnerability handling, and sets reporting obligations for significant incidents (3, European Union, 2022); Commission Implementing Regulation (EU) 2024/2690 specifies those measures further for several categories of digital entity (4, European Commission, 2024). An organisation in scope must therefore be able to show that its measures are effective, and continuous, AI-assisted testing is one of the strongest ways to produce that evidence.

The Digital Operational Resilience Act (DORA) requires financial entities to maintain a digital operational resilience testing programme, and requires those identified by their competent authorities to carry out threat-led penetration testing at least every three years (2, European Union, 2022). The TIBER-EU framework of the European Central Bank structures such tests, with threat intelligence, a red team, a blue team that is not told in advance, and a control team within the tested entity that leads and manages the exercise (13, ECB, 2025). Chapter 12 shows how adversary emulation including AI-enabled techniques extends threat-led testing.

The Cyber Resilience Act requires manufacturers of products with digital elements to handle vulnerabilities throughout the support period and to report actively exploited vulnerabilities (5, European Union, 2024). The AI Act applies to security AI as to any other AI system (1, European Union, 2024). Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, which makes adversarial testing part of compliance for those systems, and Article 55 requires providers of general-purpose AI models with systemic risk to perform adversarial testing. In addition, a security tool that monitors employees' behaviour raises questions of data protection and labour law (9, European Union, 2016), particularly where works councils have rights of consultation or co-determination; in Germany, Section 87(1) no. 6 of the Works Constitution Act covers technical devices designed to monitor behaviour or performance, which the Federal Labour Court reads as devices objectively suitable to collect or record such information, whatever the employer intends (76, Germany, n.d.) (77, BAG, 2024).

Two further features recur: sovereignty over security data, which often contains personal data, so that Chapter 4 treats model location as a design decision with legal consequences; and national supervision of European obligations, so that a multinational tests and reports under several regimes at once. As in the earlier volumes, statements about law are attributed to the instrument and article and framed as architectural implications, not legal advice.

Two organisations

Two fictional organisations run through the series, and this book follows their security functions. Their full profiles are in EXAMPLE_ORGANISATIONS.md, including the security operations profile added for this book.

Nordvik Region is a regional public authority in a Nordic member state of the European Union, with about 6,000 employees serving about 450,000 residents. Its AI estate includes a procured benefits-triage system classified as high-risk, an internal staff assistant, a citizen-service assistant built on open-weight models hosted on reserved capacity in a Nordic data centre, and a correspondence classifier. Its security function is small: a chief information security officer and a security unit of fourteen people, six of them analysts who work office hours. A European managed security service provider monitors the estate out of hours. The Region has no red team, buys an annual penetration test, and reports significant incidents to the national CSIRT under the national transposition of NIS 2. Its question is how to use AI to stretch a small team without giving up sovereignty over security data or accountability to the public. It starts cautiously, with a SOC triage assistant at Level 1 Assisted on its own reserved capacity, because alert data contains personal and health data, with AI red-teaming of its citizen-service and staff assistants, and with its first threat-led exercise, run by a contracted tester under rules of engagement RoE-NR-2027-001.

Hansa Mutual is a mutual insurance group headquartered in Hamburg, with about 9,500 employees, insurance entities in Germany, the Netherlands, Sweden, Norway, the United Kingdom and Switzerland, and a claims and operations service centre in Poland. Its AI estate includes a claims assistant, a claims-triage agent acting on the core claims system, an underwriting-support model classified as high-risk, and an IT-operations agent with write access to production, all on a shared group platform in Frankfurt. Its security function is large: a group CISO, a 24/7 security operations centre in Hamburg and the Polish service centre, a red team of five, a threat-intelligence cell, a detection-engineering team that manages detections as code, and an incident-response team. Its German entity has been identified for threat-led penetration testing under DORA, run under the TIBER-DE framework. Hansa's challenge is to give AI bounded autonomy at machine speed, for example letting its SOC investigation agent isolate a workstation without waiting for approval, while proving to supervisors in seven jurisdictions, to works councils in three, and to its management body that people remain in command.

Worked example: a programme charter for AI-enabled defence

Before adopting any security AI capability, an organisation needs a mandate for the programme. The illustrative charter below, which Nordvik Region's CISO presented to the regional director, names the scope in CSF terms, the boundaries and the decision rights.

# Illustrative: Nordvik Region, programme charter for AI-enabled defence
kind: ProgrammeCharter
id: NR-SEC-PROG-2027
owner: chief-information-security-officer
sponsor: regional-director
approved: 2027-01-18
scope:
  framework: NIST-CSF-2.0
  functions: [govern, identify, protect, detect, respond, recover]
  aiFocus: [secure-ai-systems, ai-enabled-defence, thwart-ai-enabled-attacks]
  initialCapabilities:
    - id: NR-SEC-001
      name: SOC triage assistant
      usageMode: 4              # built AI application, read-only service identity
      autonomyLevel: 1          # Assisted: AI drafts, analyst executes
      hosting: self-hosted-reserved-capacity
      decisionRecord: AIDR-0301
    - id: NR-SEC-002
      name: AI red-teaming of citizen-service and staff assistants
      decisionRecord: AIDR-0302
    - id: NR-SEC-003
      name: exposure prioritisation for internet-facing services
      usageMode: 4
      autonomyLevel: 0          # Advisory
boundaries:
  defensiveOnly: true
  offensiveActivityRequires: signed-rules-of-engagement
  outOfScope: [third-party-systems, hack-back]
  maxUsageMode: 4             # no autonomous agents with own identity yet
  maxAutonomyLevel:
    offensive: 2
    irreversibleActions: 1
  securityDataLeavesEuEea: false
decisionRights:
  raiseAutonomyLevel: ciso-with-security-board
  stopAnyCapability: [ciso, duty-security-officer, mssp-shift-lead]
evidence:
  manifest: evidence/security-ai/manifest.yaml
  reportTo: regional-board

The charter caps the usage mode and the autonomy by type of action rather than by product, so that a later decision to raise the triage assistant to Level 2 must be argued against a recorded ceiling. It names who can stop any capability, including the managed service provider's shift lead, because the July 2026 incident showed that an alert is useless if it reaches people who do not hold the stop decision. Finally, the regional board receives reports generated from the evidence manifest. Hansa Mutual's charter has the same structure but different values: more capabilities, a ceiling of Level 3 Bounded for reversible containment in the SOC, decision rights through the group AI governance board, and an evidence profile for each market.

Nordvik Region and Hansa Mutual

For Nordvik Region, the book is a path to doing more with the same fourteen people, keeping security data on infrastructure it controls and every capability at a level its small team can supervise; its constraints are capacity, procurement lead times and public-access rules, and its advantages a single legal regime and a clear public mandate. For Hansa Mutual, it is a path to AI at machine speed with bounded autonomy, AI-enabled techniques in its threat-led testing, and red teaming of its own agents as rigorous as of its network; its constraints are the number of legal regimes, works-council consultation and supervisory scrutiny, and its advantages engineering depth and a shared group platform.

How to read this book

The book can be read from beginning to end, but readers with a specific role will find shorter paths. CISOs and heads of security operations should read Parts I and II, then Chapter 18, Part VII and Chapters 25 and 26; Chapter 3 doubles as a map for building the organisation's own CSF profile. Red-team leads should read Chapters 6 and 7, then Part III, especially Chapters 12 and 13, and Chapter 26. Blue-team leads, detection engineers and threat-intelligence analysts should read Chapters 2, 4 and 6, then Parts V to VII and Chapter 26. Security and AI architects should read Chapters 3, 4 and 13, Part IV and Chapter 25, and use Appendix A. Risk, compliance and internal-audit functions should read Chapter 3, Part II, and Chapters 24 and 26.

Each narrative chapter names a problem, describes a response that can be codified, tested and audited, gives practical guides and worked examples, and shows how the subject plays out for the two organisations. Outlooks are labelled as observable, expected or speculation, as in the earlier volumes.

Summary

Attackers use AI to find weaknesses faster and run parts of intrusions at machine speed, and the time between disclosure and exploitation has collapsed. Building on the earlier volumes' conclusion that AI is both a target and a source of threat, this book treats AI as an active part of cyber defence.

It follows NIST CSF 2.0 through all six Functions and 22 Categories, each treated through the three focus areas of the NIST Cyber AI Profile. Red teaming, with AI and of AI, runs through every Function, as do three red threads: the usage modes with the autonomy levels, the purple loop, and security chaos engineering. Four rules keep the book defensive: techniques are described for controls and tests, never as tooling; every offensive activity is authorised and scoped; AI that acts is contained; and every finding ends as a verified control. European law both requires defenders to test and monitor and shapes how they may do so.

Nordvik Region and Hansa Mutual will show what this looks like for a small public authority and for a multinational insurer. Chapter 2 begins with the threat they face: what the evidence shows about AI-enabled attackers, and what it means for the capabilities a defender must build.

Sources

  1. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
  4. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
  6. 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). (3, European Union, 2022)
  7. European Commission. Commission Implementing Regulation (EU) 2024/2690. (4, European Commission, 2024)
  8. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). (5, European Union, 2024)
  9. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
  10. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
  11. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (13, ECB, 2025)
  12. European Union Agency for Cybersecurity. ENISA Threat Landscape 2026. (34, ENISA, 2026)
  13. National Cyber Security Centre. Impact of AI on cyber threat from now to 2027. (37, NCSC, 2025)
  14. Five Eyes cyber security agencies. The AI shift in cyber risk: why leaders must act now. (39, Five Eyes agencies, 2026)
  15. Charrier, C. and Weiner, R. How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (44, Charrier & Weiner, 2024)
  16. Google Threat Intelligence Group. GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI. (48, Google GTIG, 2026)
  17. Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign. (52, Anthropic, 2025)
  18. Defense Advanced Research Projects Agency. AI Cyber Challenge marks pivotal inflection point for cyber defense. (59, DARPA, 2025)
  19. Anthropic. Project Glasswing: Securing critical software for the AI era. (60, Anthropic, 2026)
  20. Carlini, N., Cheng, N., Lucas, K. et al. Assessing Claude Mythos Preview's cybersecurity capabilities. (61, Carlini et al., 2026)
  21. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  22. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  23. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  24. 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). (9, European Union, 2016)
  25. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), § 87 Mitbestimmungsrechte. (76, Germany, n.d.)
  26. Bundesarbeitsgericht. Beschluss vom 16. Juli 2024, 1 ABR 16/23 (Headset-System). (77, BAG, 2024)