NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations

Every security programme needs a complete map of what it is trying to achieve; a programme that starts from the tools it owns or the last audit finding tends to invest in the SOC and neglect recovery. This book uses the NIST Cybersecurity Framework (CSF) 2.0 as its map (19, NIST, 2024). This chapter explains what the framework's Functions, Categories, profiles and tiers mean in practice, what the NIST Cyber AI Profile adds, how CSF outcomes map to the obligations a European organisation actually carries, and how an organisation records its current and target position as code.

A European organisation already answers to NIS 2, often to DORA, increasingly to the Cyber Resilience Act and the AI Act, and frequently to ISO/IEC 27001, so a US framework is only worth adding if it reduces that work. CSF earns its place as a common vocabulary of outcomes into which European obligations and ISO/IEC 27001 controls are mapped once, so that one control, assessed once, produces evidence for every regime that relies on it.

In CSF terms the chapter opens the Category with which the framework itself opens: GV.OC Organizational Context, whose outcomes include understanding the organisation's mission, stakeholders, dependencies and legal, regulatory and contractual requirements (19, NIST, 2024). Chapter 5 treats GV.OC in depth as part of risk strategy; this chapter handles the part every later chapter depends on: stating which obligations apply, and recording how each CSF outcome serves them.

CSF 2.0 and the three AI focus areas feeding the CSF profile as code, with European obligations and ISO/IEC 27001 as inputs

Figure 3.1: CSF 2.0 and the three AI focus areas feeding the CSF profile as code, with European obligations and ISO/IEC 27001 as inputs.

CSF 2.0 in brief

Functions, Categories and Subcategories

The CSF Core is a hierarchy of outcomes. At the top are six Functions: Govern, Identify, Protect, Detect, Respond and Recover. Version 2.0, published in February 2024, added Govern and placed it at the centre, because the other five depend on a risk strategy, roles, policy and oversight that someone has to own (19, NIST, 2024). Below the Functions sit 22 Categories, each identified by a Function prefix and a short code, such as GV.OC Organizational Context, PR.AA Identity Management, Authentication, and Access Control, or RC.RP Incident Recovery Plan Execution. Below them sit 106 Subcategories (GV.OC-03, DE.CM-01), each a single outcome statement.

For an architect, the Core matters because it describes outcomes, not controls: DE.CM-01 says that networks and network services are monitored to find potentially adverse events, but not which sensor or detection rules. It is also sector-neutral, so the same outcome applies to a regional authority and an insurance group, though the controls differ.

Profiles and tiers

An Organizational Profile describes an organisation's cybersecurity posture in terms of the Core's outcomes (19, NIST, 2024). A Current Profile records which outcomes the organisation achieves today; a Target Profile records those it has chosen to prioritise, given its mission, risk appetite, obligations and expected changes. The gap between them produces an action plan with owners and priorities. Community Profiles are baselines that a sector or technology community prepares as a starting point for Target Profiles; the NIST Cyber AI Profile is one of them.

Tiers characterise how rigorously the organisation governs and manages cybersecurity risk: Tier 1 Partial, Tier 2 Risk Informed, Tier 3 Repeatable and Tier 4 Adaptive (19, NIST, 2024). Tiers are not a maturity score for each Category, and the framework encourages progression to a higher Tier when risks or mandates are greater or when a cost-benefit analysis indicates a feasible and cost-effective reduction of risk, not as an end in itself. Confusing the two produces a familiar anti-pattern: a heat map with a number from one to four in every Category, presented to the board as "CSF maturity". In this book, therefore, a profile entry records the achievement of outcomes on a documented internal scale, and a Tier describes the organisation's risk-management practice as a whole.

A framework, not law

CSF is voluntary and creates no obligation for a European organisation. That is its strength here: it provides a neutral map into which European law can be mapped without importing anything that competes with it. Where this book says that an organisation "must" do something, the obligation comes from a European instrument or from the organisation's own policy, never from CSF. NIST's spelling is kept inside Category names because they are proper names.

GV.OC Organizational Context: where the profile starts

GV.OC has five Subcategories, and they are the inputs every other Category needs (19, NIST, 2024):

Subcategory Outcome in brief What it means for a profile with an AI focus
GV.OC-01 Mission is understood and informs risk management Which services the programme protects first
GV.OC-02 Stakeholders' needs and expectations are understood Supervisors, residents or policyholders, employee representatives
GV.OC-03 Legal, regulatory and contractual requirements are understood and managed The obligation register mapped into the profile
GV.OC-04 Services that external stakeholders depend on are understood Services whose disruption triggers reporting duties
GV.OC-05 What the organisation depends on is understood Model providers, hosting, MSSPs and other dependencies of security AI

GV.OC-03 is the bridge between CSF and European law. Its outcome is achieved not by a list of laws on an intranet page but when each applicable requirement is linked to the outcomes and controls that meet it, with an owner and evidence, which is what the mapping and the profile as code below provide.

The AI focus: three focus areas

What the Cyber AI Profile adds

The Cyber AI Profile is a CSF 2.0 Community Profile for artificial intelligence, published by NIST as an initial preliminary draft in December 2025 (20, NIST, 2025). It adds no Functions or Categories; instead it reads the existing outcomes through three focus areas, which NIST names Securing AI System Components, Conducting AI-Enabled Cyber Defense and Thwarting AI-Enabled Cyber Attacks and which this book calls:

  • Securing AI systems. The organisation's own AI systems, components and supply chain are assets to protect, including the security AI it introduces, which becomes a high-value target the moment it is given access to alerts, logs and response tools.
  • AI-enabled cyber defence. AI is a means of achieving CSF outcomes faster, more completely or at greater scale.
  • Thwarting AI-enabled attacks. The outcomes must hold against attacks that are faster, cheaper, more numerous and more convincing than before.

The focus areas are not three programmes but three questions to put to every Category. For DE.AE Adverse Event Analysis, for example, securing AI systems asks whether the organisation can analyse adverse events in its AI estate, such as an unusual sequence of tool calls by an agent; AI-enabled cyber defence asks whether AI can correlate events so that analysts keep pace; and thwarting AI-enabled attacks asks whether the analysis holds when the content the analysing AI reads was written by the adversary to steer it.

Its status and how much weight it can carry

Because the Cyber AI Profile is a preliminary draft that may change (20, NIST, 2025), the book adopts only the three focus areas, its most stable contribution. For a more detailed treatment of AI risk, chapters draw on the NIST AI Risk Management Framework (AI RMF 1.0), with its four functions Govern, Map, Measure and Manage (16, NIST, 2023), and on European law, which is binding where NIST guidance is not. An organisation should record the version of the Cyber AI Profile it used, so that a later revision becomes a reviewed change rather than a silent drift.

The focus areas and the earlier volumes

The first focus area builds on the conclusion of AI Platform and Security, Chapter 25, that a platform is under control when every model call and tool call passes a policy point outside the model and containment holds whatever anyone intends (73, Nordqvist, 2026); the profile records, Category by Category, whether those properties hold, above all for security AI.

AI Governance concluded that the usage mode, not the brand, sets the governance (AI Governance, Chapters 2 and 25) (72, Nordqvist, 2026). An assistant that explains a log entry (Mode 1 Conversational assistants) and an investigation agent with its own identity (Mode 5 Autonomous production agents) both serve AI-enabled cyber defence but create very different entries under securing AI systems. Chapter 6 develops the usage modes and autonomy levels for security AI; the profile records the mode and level of each AI-enabled capability, so that the target for the Category can be judged against the risk the capability actually carries.

Mapping CSF to European obligations

This section shows where the requirements of NIS 2, DORA, the Cyber Resilience Act and the AI Act land in the CSF map. The aim is architectural, not legal: the statements are attributed to the instrument and article and are not legal advice, and the national transposition and competent authority decide how they apply to a given entity.

NIS 2 Article 21 and Implementing Regulation 2024/2690

The NIS 2 Directive requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems, based on an all-hazards approach (3, European Union, 2022). Article 21(2) lists ten minimum measures, from risk analysis and incident handling through business continuity, supply chain security, vulnerability handling, effectiveness assessment, cyber hygiene and training, and cryptography, to access control, asset management and multi-factor authentication. Article 20 makes the management body responsible for approving and overseeing the measures, and Article 23 sets out staged reporting of significant incidents, starting with an early warning within 24 hours.

Article 21(2) thus touches every Function, with supply chain security landing in GV.SC Cybersecurity Supply Chain Risk Management and the effectiveness assessment in ID.IM Improvement, while Article 20 corresponds to GV.RR Roles, Responsibilities, and Authorities and GV.OV Oversight.

Commission Implementing Regulation (EU) 2024/2690 specifies these measures for a defined set of digital entities, among them cloud, managed service and managed security service providers (4, European Commission, 2024). Its annex is far more concrete than the Directive, and ENISA's technical implementation guidance adds examples of how each requirement can be met and evidenced (8, ENISA, 2025). Two consequences follow. An entity outside the Regulation's direct scope can still use its annex as a well-founded description of what "appropriate and proportionate" looks like. Moreover, an MSSP that runs a customer's out-of-hours monitoring is subject to the Regulation itself, which gives the customer a concrete basis for its expectations under GV.SC.

DORA

The Digital Operational Resilience Act applies to financial entities from January 2025 and is, for them, the sector-specific act that NIS 2 Article 4 allows to take precedence where its requirements are at least equivalent (2, European Union, 2022). Its structure maps closely to the CSF Functions: Article 5 places ultimate responsibility for ICT risk management on the management body (Govern), and Articles 8 to 14 follow identification, protection, detection, response and recovery, learning and communication. Articles 17 to 19 on incident management, classification and reporting map to RS.MA, RS.AN and RS.CO; Articles 24 to 27 on resilience testing, including threat-led penetration testing, map to ID.IM; and Articles 28 to 30 on ICT third-party risk map to GV.SC. A financial entity can therefore use its CSF profile as the index of its DORA framework, provided the mapping is done at the level of requirements and Subcategories rather than by matching headings.

The Cyber Resilience Act

The Cyber Resilience Act sets horizontal cybersecurity requirements for products with digital elements placed on the EU market (5, European Union, 2024). Manufacturers must meet the essential requirements of Annex I, covering both product properties and vulnerability handling, and Article 14 requires them to report actively exploited vulnerabilities and severe incidents. The reporting obligations apply from September 2026, and most of the rest from December 2027. Most organisations meet the CRA first as buyers of security products, for which it gives a European basis for procurement requirements under GV.SC. Article 12 links to the AI Act: a product that is also a high-risk AI system is deemed to comply with the cybersecurity requirements of AI Act Article 15 where it fulfils the essential requirements of Annex I (Part I for the product, Part II for the manufacturer's processes) and the achievement of the level of protection that Article 15 requires is demonstrated in the EU declaration of conformity; the accuracy and robustness requirements of Article 15 remain unaffected.

The AI Act

The AI Act carries cybersecurity obligations that a CSF profile must reflect (1, European Union, 2024). Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and names AI-specific vulnerabilities to address, including data poisoning, model poisoning, adversarial examples and confidentiality attacks. Article 26 sets the duties of deployers of high-risk AI systems, including human oversight by competent people, monitoring and keeping logs. Article 55 requires providers of general-purpose AI models with systemic risk to perform adversarial testing, and Article 4, as replaced by Regulation (EU) 2026/1744 (the Digital Omnibus on AI, in force from 27 July 2026), requires providers and deployers to take measures to support the development of AI literacy among their staff, without guaranteeing any specific level for any individual (75, European Union, 2026).

In the CSF map these obligations land mostly under the first focus area: Article 15 under PR.PS Platform Security, PR.DS Data Security and ID.RA; Article 26 under GV.RR and DE.CM Continuous Monitoring; and Article 4 under PR.AT Awareness and Training. Article 55 falls on the providers of the largest models, so a deployer's profile records the evidence it asks them for and the testing of its own compound system (AI Platform and Security, Chapter 20) (73, Nordqvist, 2026). Because security AI often processes personal data and may monitor employees, the profile also links to the GDPR and national labour law under GV.OC-03.

Assure once, comply many

The table summarises the mapping by Function, as a starting point for the requirement-level mapping.

CSF Function NIS 2 and Regulation 2024/2690 DORA Cyber Resilience Act AI Act
Govern Art. 20; Art. 21(2)(a), (d) Art. 5, 6, 28–30 Supplier obligations as procurement criteria Art. 4, 26; Art. 55 evidence from providers
Identify Art. 21(2)(a), (e), (f), (i) Art. 8, 13, 24–27 Vulnerability information from manufacturers Art. 9 risk management; Art. 15
Protect Art. 21(2)(e), (g), (h), (i), (j) Art. 9 Annex I product properties Art. 15
Detect Art. 21(2)(b) Art. 10 Art. 14 notifications as input Art. 26 monitoring and logs
Respond Art. 21(2)(b); Art. 23 Art. 11, 17–19 Art. 14 reporting by manufacturers Art. 73 serious incidents
Recover Art. 21(2)(c) Art. 11, 12, 14 Not applicable Not applicable

The point is the principle that Architecture as Code called "assure once, comply many": a control is written once, mapped to every obligation it serves, and linked to evidence that it is enforced (Architecture as Code (Chapters 10 and 11)) (71, Nordqvist, 2025). CSF supplies the neutral layer between the two. NIS 2 Article 21(2)(j) and DORA Article 9 both map to PR.AA, the organisation's control for phishing-resistant multi-factor authentication maps to PR.AA once, and one assessment produces evidence for both regimes.

AI Governance added that evidence is a by-product of delivery, and that an attestation is a person asserting while evidence is machine-generated (AI Governance, Chapter 11) (72, Nordqvist, 2026). In a CSF profile that distinction becomes a field: every claimed outcome is either linked to machine-generated evidence or marked as attested, with the person and the date. A profile in which most Protect and Detect outcomes are attested has not yet been tested.

CSF and ISO/IEC 27001

Many European organisations already run an information security management system (ISMS) certified to ISO/IEC 27001, with its reference controls in Annex A (30, ISO/IEC, 2022) and guidance on them in ISO/IEC 27002 (31, ISO/IEC, 2022). ISO/IEC 27001 is a certifiable management system; CSF is a map of outcomes. The division of labour follows:

  1. The ISMS is the management system. Risk assessment and treatment, the Statement of Applicability, internal audit and management review stay in the ISMS; an organisation with a working ISMS should not build a second risk process for its CSF profile.
  2. The control catalogue is shared. Controls are defined once and reference both the Annex A controls they implement and the CSF Subcategories they help achieve.
  3. The CSF profile is the outcome view that the management body and supervisors read, and Clause 4 of the ISMS, on context, is written once and also feeds GV.OC.

Because Annex A does not address AI-specific threats in detail, the gaps the focus areas reveal go back into the ISMS risk treatment as ordinary risks, keeping a single risk process.

Profiles as code

A profile kept in a spreadsheet is a snapshot that decays from the day it is presented, whereas a profile kept as code is a reviewed record whose history shows who changed what and why, and which automated checks keep consistent. It also makes the evidence chain of AI Platform and Security useful to the security programme, because the profile can link to evidence produced by the gateway, the containment profile and the evaluation harness by control identifier rather than by screenshot (73, Nordqvist, 2026).

Practical guide: Building a current and target CSF profile with an AI focus

Purpose. Produce a first current and target profile, read through the three AI focus areas, mapped to the applicable European obligations and kept as code.

Roles. The CISO owns the profile; the compliance function owns the obligation register; control owners supply the current state and evidence; the AI governance function supplies the AI inventory with usage modes; and the management body approves the target.

Steps.

  1. Scope the profile and record the scope in the file.
  2. Build the obligation register from NIS 2 as transposed nationally, DORA, the CRA and the AI Act, marking per entity whether an obligation is law or group policy.
  3. Record the current state per Category on a documented internal scale, with links to evidence or an attestation; use Subcategory granularity where obligations attach.
  4. Apply the three focus areas: the AI systems in scope, the AI-enabled capabilities with their usage mode and autonomy level, and the AI-enabled threats that change the target.
  5. Set the targets from mission, obligations and risk appetite, with a date, and set them deliberately unevenly: concentrate where the obligations and threat are greatest and progress is possible.
  6. Analyse the gaps, recording for each its owner and the action that closes it in the programme backlog.
  7. Codify and check. Commit the profile, add a pipeline check that enforces owners, evidence or attestation and obligation references, and require review for every change to a target.
  8. Publish the views generated from the same file, such as a management summary and an obligation view per regime.

Default values to adapt. Review the full profile every six months and on any trigger: a significant incident, a new AI system in Mode 4 or Mode 5, a change in obligations or a red-team finding that contradicts a claimed outcome. Treat an attestation older than twelve months as expired, and allow at most three Categories with targets more than two steps above their current state in any one year.

Definition of done. All 22 Categories have a current state, a target and an owner, with entries for the focus areas that apply; every obligation maps to at least one Category; the pipeline check passes; and the management body has approved the target.

Worked example: CSF profile as code for Hansa Mutual

The illustrative excerpt below shows two Category entries from Hansa Mutual's profile HM-CSF-2027, each with current and target state on Hansa's internal scale of 0 to 4, the three focus areas, the obligations it serves with the entities where each applies, the controls and the evidence.

# Illustrative: excerpt from Hansa Mutual's CSF profile HM-CSF-2027
profile: HM-CSF-2027
scope: group, all seven markets
cyber_ai_profile_version: NIST IR 8596 initial preliminary draft
scale: hansa-0-4                 # internal scale, documented in the repository
categories:
  - id: GV.OC
    name: Organizational Context
    owner: group-ciso
    current: 3
    target: { level: 4, by: 2027-12-31 }
    focus_areas:
      securing_ai_systems: AI estate inventory linked to obligation register
      ai_enabled_cyber_defence: HM-SEC-001 and HM-SEC-002 recorded with mode and level
      thwarting_ai_enabled_attacks: exploitation-window assumption reviewed quarterly
    obligations:
      - { ref: DORA Art. 5, applies_in: [DE, NL, SE, PL], status: law }
      - { ref: AI Act Art. 4, applies_in: [DE, NL, SE, PL], status: law }
      - { ref: AI Act Art. 4, applies_in: [NO, UK, CH], status: group-policy }
    controls: [CTRL-GOV-001, CTRL-GOV-004]
    evidence: [evidence/gv-oc/obligation-register-review-2027-q1.json]
    gap: { action: PRG-2027-012, note: entity obligation views generated from one file }
  - id: DE.AE
    name: Adverse Event Analysis
    owner: head-of-soc
    current: 3
    target: { level: 4, by: 2027-09-30 }
    focus_areas:
      securing_ai_systems: agent tool-call telemetry correlated in the group SIEM
      ai_enabled_cyber_defence: HM-SEC-001, Mode 5, Level 2 Supervised
      thwarting_ai_enabled_attacks: alert content treated as untrusted input
    obligations:
      - { ref: DORA Art. 10, applies_in: [DE, NL, SE, PL], status: law }
    controls: [CTRL-SOC-012, CTRL-GW-007]
    evidence: [evidence/de-ae/triage-time-2027-q1.json]
    gap: { action: PRG-2027-031, note: case for Level 3 Bounded under review }

The DE.AE entry records the investigation agent's usage mode and autonomy level, so that a reviewer can see that the case for Level 3 Bounded is part of the gap, not an assumption already made. A small Rego policy in the pipeline, in the Policy as Code style of Architecture as Code (71, Nordqvist, 2025), fails the merge when a Category has no owner, claims an outcome without evidence or attestation, has a gap without an action, or lacks an entry for one of the three focus areas.

How the book follows the Functions

Parts II to VII follow the six Functions, each chapter responsible for named Categories, and Part VIII closes the loop.

Part Function Chapters Categories
II Govern 5 to 8 GV.OC, GV.RM, GV.RR, GV.PO, GV.OV, GV.SC
III Identify 9 to 13 ID.AM, ID.RA, ID.IM
IV Protect 14 to 17 PR.AA, PR.AT, PR.DS, PR.PS, PR.IR
V Detect 18 to 19 DE.CM, DE.AE
VI Respond 20 to 21 RS.MA, RS.AN, RS.CO, RS.MI
VII Recover 22 to 24 RC.RP, RC.CO
VIII Verification and improvement 25 to 28 ID.IM, GV.OV

In Part I, Chapter 2 also contributes to ID.RA and Chapter 4 to PR.PS and PR.IR. Chaos engineering experiments in each chapter link every Category to continuous evidence (Chapter 25), and Chapter 26 feeds findings back into the profile. Used in reverse, the table names the chapter to read first where a gap is largest.

Nordvik Region and Hansa Mutual

Nordvik Region keeps its profile, NR-CSF-2027, as code in the same repository as its programme charter, with each Category mapped to the national transposition of NIS 2, so that the evidence the Region gathers for the competent authority is the evidence the profile links to. Its targets are deliberately uneven: ambitious for GV.OC Organizational Context, ID.AM Asset Management and the Detect Categories, where the SOC triage assistant NR-SEC-001 and its MSSP make progress possible, and modest where it lacks specialist capacity. Because its MSSP, under framework agreement NR-2025-044, is within the scope of Implementing Regulation 2024/2690, the Region uses the Regulation's annex and the ENISA guidance as the basis for what it expects of the provider under GV.SC. Public-access rules lead it to separate a publishable summary from the classified gap analysis.

Hansa Mutual's profile, HM-CSF-2027, is mapped to DORA, NIS 2 and the UK and Swiss regimes through one control catalogue, with market overlays for national variations, including the AI Act being law in the EU entities and group policy in Norway, the United Kingdom and Switzerland. Its ISO/IEC 27001 controls are referenced rather than duplicated. The difference is one of breadth, not method: Nordvik maps one framework to one national regime, while Hansa needs a single catalogue precisely because it answers to several.

Summary

NIST CSF 2.0 gives a European organisation a complete map of cybersecurity outcomes without importing a US compliance regime. It describes what must be achieved, not how; profiles express where the organisation stands and intends to be; and tiers describe its risk-management practice as a whole, not the maturity of each Category.

The NIST Cyber AI Profile, still a preliminary draft, adds three focus areas through which every Category should be read. GV.OC Organizational Context is where that reading starts, because the organisation must state which obligations apply before it sets targets. Mapping CSF outcomes to NIS 2, Implementing Regulation 2024/2690, DORA, the Cyber Resilience Act and the AI Act, with ISO/IEC 27001 as the management system alongside, lets the organisation assure a control once and show compliance many times.

The profile belongs in version control, where it is reviewed, checked in the pipeline and distinguishes evidence from attestation. It becomes the coverage map that the rest of the book fills Category by Category. Chapter 4 provides the common picture those Categories rest on: a reference architecture for AI-enabled cyber defence.

Sources

  1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  3. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). (16, NIST, 2023)
  4. 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)
  5. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
  6. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
  7. 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)
  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. 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)
  10. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. (30, ISO/IEC, 2022)
  11. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. (31, ISO/IEC, 2022)
  12. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  13. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  14. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
  15. 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). (75, European Union, 2026)