What European leaders need to know before making the AI Act their only compass
Many European organisations treat the EU AI Act as their single reference for AI governance — but compliance and risk reduction are not the same thing. This post explains why NIST, ISO and the EU AI Act work best combined, why most AI incidents come from how people use AI rather than the models themselves, and offers a five-step roadmap to turn regulatory obligations into an operational security programme.
A pattern is emerging across European executive committees: AI is no longer a pilot project, it’s infrastructure. Copilots, autonomous agents, generative SaaS applications, adoption is accelerating faster than the governance structures meant to contain it. That gap is exactly where the risk sits.
Many European organisations have made the EU AI Act (full text on EUR-Lex) their single point of reference. That’s a strategic miscalibration. The regulation sets legal obligations for in-scope AI systems, which is necessary, but it’s only one piece of the puzzle. Regulatory compliance and actual risk reduction are two different things. An organisation can check every documentation box and still suffer a data leak, insider misuse, or an AI-amplified phishing campaign.
Three frameworks, three purposes: not a choice, a combination
This isn’t about choosing between the NIST AI RMF, ISO standards, and the EU AI Act. Each answers a different question:
|
Framework |
Focus |
Best use |
|
NIST AI RMF |
Risk management framework |
Structuring AI risk assessment and oversight |
|
ISO/IEC 23894 and 42001 |
Governance and management systems |
Building repeatable processes and accountability |
|
EU AI Act |
Regulation |
Meeting legal obligations for in-scope systems |
For a group operating in Europe but exposed to international clients or subsidiaries, the most robust approach is to use NIST as the operational backbone, ISO for governance maturity, and the EU AI Act for specific legal obligations, without turning these into three separate compliance silos.
The risk doesn’t live in the model, it lives in how it’s used
This is the point executive committees underestimate most often. AI discussions tend to focus on accuracy, explainability, and model bias. These are real concerns, but in practice, most incidents arise from the interaction between employees, sensitive data, and AI tools. An employee uploads customer records to a public AI tool. Poorly segmented Microsoft 365 content suddenly becomes discoverable through a copilot. An attacker crafts a far more convincing phishing campaign with the help of generative AI.
AI risk is fundamentally a human risk, a data risk, and a communications risk, not just a technology risk.
Where governance frameworks fall short
No framework, however rigorous, covers the full picture on its own.
Human behaviour is the first gap. Employees continue to share sensitive information with AI tools, approve fraudulent requests, or bypass approved processes, even when a policy exists on paper.
Data exposure is the second. AI amplifies existing data governance weaknesses. Many organisations only discover access control gaps after AI has made them exploitable at scale.
AI-powered attacks follow closely. Phishing, business email compromise (BEC), and impersonation are growing more sophisticated and more frequent.
Shadow AI closes the list. Without visibility into actual usage, leadership doesn’t know which tools are circulating across the organisation, what data is flowing through them, or whether internal policies are actually being followed.
A five-step roadmap, to build with the CISO
- Establish a baseline framework: combine NIST, ISO, and EU AI Act requirements into a single structure rather than three parallel programmes.
- Map real-world usage: inventory approved AI systems, copilots, agents, and third-party integrations, and identify who owns each one.
- Prioritise by business impact: a prompt containing public information carries a very different risk than one containing customer records or intellectual property.
- Connect every governance objective to an operational control: data classification, access management, DLP, usage monitoring.
- Measure risk reduction, not compliance activity: track concrete indicators such as reduced data oversharing, AI-related data loss incidents, or fewer excessive access permissions.
The message for the executive committee
AI governance isn’t decided solely in the boardroom or in compliance documentation. It plays out in how teams use AI day to day, how data moves across the organisation, and how well leadership anticipates the ways attackers will exploit those same tools.
For European leadership, the challenge for the coming quarters isn’t choosing the right framework. It’s turning regulatory obligations into an operational security programme, one that is measurable, actionable, and aligned with business priorities.
FAQ
Q1. Is complying with the EU AI Act enough to manage AI risk?
No. Compliance and risk reduction are not the same thing. The EU AI Act sets legal obligations for in-scope systems, but it doesn’t address how employees use AI, data exposure, shadow AI, or AI-powered attacks. Pair it with the NIST AI RMF and ISO standards, and connect each governance objective to an operational control.
Q2. How do the NIST AI RMF, ISO 42001 and the EU AI Act work together?
They answer different questions. Use NIST as the operational backbone for risk assessment and oversight, ISO/IEC 23894 and 42001 for governance maturity and repeatable processes, and the EU AI Act for legal obligations on in-scope systems — as one combined structure rather than three separate silos.
Q3. What is shadow AI and why does it matter for governance?
Shadow AI is the use of AI tools without leadership visibility or approval. Without knowing which tools are circulating and what data flows through them, an organisation can’t confirm its policies are being followed or measure its real exposure.
Q4. Where do most AI security incidents actually come from?
Rarely the model itself. Most arise from how AI is used — the interaction between employees, sensitive data and AI tools. Examples include staff uploading customer records to public AI tools, over-permissioned Microsoft 365 content surfaced through a copilot, and AI-assisted phishing.