A Comprehensive Guide to the EU AI Act

The EU AI Act is now law. If you build, deploy, or use AI systems that touch EU citizens, this regulation applies to you – regardless of where your company is based. We’ve spent the past year testing AI systems against this framework during security engagements, and the gap between what the Act requires and what most organizations actually have in place is staggering.

This guide cuts through the noise. No filler, no generic compliance checklists. We focus on the parts that matter most from a security and risk perspective – the parts where we’ve seen real organizations stumble.

What the EU AI Act Actually Does

Adopted in 2024, the EU AI Act is the first legally binding AI regulation in the world. It creates a risk-based classification system with four tiers – unacceptable, high, limited, and minimal risk – and imposes obligations that scale with how dangerous a system can be. The model is similar to GDPR: extraterritorial reach, heavy fines, and a phased enforcement timeline.

The Act applies to providers (who build AI systems), deployers (who use them), importers, and distributors. If your AI system is used in the EU or affects EU residents, you’re in scope. This isn’t optional and it isn’t advisory.

Enforcement and Implementation Timeline

Enforcement is already underway. Here are the key dates:

Date	What Takes Effect
2 February 2025	Prohibited AI practices are banned (already in force)
June 2025	Transparency obligations for general-purpose AI models become enforceable
June 2026	Full enforcement for most general provisions and limited-risk systems
June 2027	Compliance deadline for high-risk AI systems (Articles 9-15)

The prohibited practices ban is already active. If you’re running a social scoring system, using subliminal manipulation techniques, or deploying untargeted facial recognition scraping, you’re already in violation. The window for preparation is closing fast.

Risk Classification: The Core of the Act

Everything in the Act flows from how your AI system is classified. Get this wrong and you’re either over-investing in compliance for a low-risk tool or – far worse – under-complying for something that regulators consider high-risk.

Unacceptable Risk – Banned Outright

These AI practices are prohibited with no exceptions:

• Social scoring systems by governments
• Subliminal or manipulative AI techniques that cause harm
• Exploitation of vulnerable groups (children, disabled persons)
• Untargeted scraping for facial recognition databases
• Real-time remote biometric identification in public spaces (with narrow law enforcement exceptions)
• Emotion recognition in workplaces and educational settings

High Risk – Heavy Obligations

High-risk systems face the most demanding requirements under the Act. These include AI used in biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential services (credit scoring, insurance), law enforcement, migration and border control, and administration of justice.

For high-risk systems, providers must implement risk management systems (Article 9), data governance (Article 10), technical documentation (Article 11), automatic logging (Article 12), transparency and information provision (Article 13), human oversight mechanisms (Article 14), and accuracy, robustness, and cybersecurity measures (Article 15).

From a security perspective, Article 15 is where things get interesting. The Act requires that high-risk AI systems are “resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.” That’s a direct mandate for adversarial robustness testing – the kind of work we do daily.

Limited and Minimal Risk

Limited-risk systems (chatbots, emotion recognition, deepfake generators) primarily face transparency obligations – users must know they’re interacting with AI. Minimal-risk systems (spam filters, recommendation engines, AI-assisted games) are largely unregulated under the Act.

Agentic AI: The Act’s Biggest Blind Spot

This is where the EU AI Act shows its age despite being brand new. The Act was primarily designed for systems that take an input, process it, and produce an output. Agentic AI – systems that plan, use tools, make decisions, and take actions autonomously – breaks that model in fundamental ways.

We’ve tested agentic AI systems during red team engagements where a single LLM-based agent could browse the web, execute code, query databases, send emails, and modify files – all without human approval for each step. The EU AI Act doesn’t clearly address how to classify, monitor, or audit that kind of behavior.

Five Regulatory Gaps

1. No clear definition of agency. The Act defines “AI systems” broadly but doesn’t distinguish between a static classifier and an autonomous agent that chains multiple tools together. A fraud detection model and an AI agent that autonomously investigates and responds to security incidents are treated the same way – which makes no sense from a risk perspective.

2. Static risk classification doesn’t work for dynamic systems. The Act classifies systems by intended use at deployment time. But agentic systems can change their behavior based on context – an agent designed for customer support might escalate to accessing internal databases or executing actions its developers never anticipated. The risk level shifts at runtime, not at deployment.

3. Accountability is blurred. When an AI agent chains together five different tools from three different providers and makes a harmful decision, who’s responsible? The agent’s provider? The deployer? The tool providers? The Act’s provider/deployer distinction assumes cleaner boundaries than agentic architectures actually have.

4. Human oversight requirements assume a human can keep up. Article 14 requires human oversight for high-risk systems, but an agentic system making dozens of decisions per second across multiple tool calls can’t realistically be overseen in real time by a human. Oversight needs to be reimagined as guardrails, approval thresholds, and automated anomaly detection – not a human reviewing each action.

5. Logging requirements weren’t designed for this. Article 12 requires logging key events, but agentic AI produces massive volumes of dynamic logs – task flows, internal reasoning chains, tool selections, feedback loops. Traditional logging doesn’t capture causal reasoning, which makes post-incident forensics extremely difficult.

What to Do About It Now

The regulation will catch up eventually, but you can’t wait for it. If you’re deploying agentic AI:

• Define internally what “agentic behavior” means in your context and identify which capabilities trigger higher compliance needs
• Conduct dynamic risk assessments that account for autonomy level, environmental interactions, and escalation paths – not just intended use at deployment
• Build kill-switches, approval workflows, and outlier detection into your agent architecture from day one
• Implement structured, event-driven logging that captures decision states, external triggers, and escalation points – not just inputs and outputs
• Use AI Bills of Materials (AIBOMs) to track dependencies and updates across your agent’s toolchain

Security Threats and the Act

This is where the EU AI Act intersects directly with what we do at FORTBRIDGE. The Act doesn’t just require ethical AI – it mandates security. High-risk AI systems must be resilient to manipulation, maintain integrity and availability, and undergo continuous risk monitoring. These aren’t aspirational goals; they’re compliance requirements with real fines attached.

The Threats the Act Targets

The Act specifically addresses several threat categories that we regularly test for during AI security engagements:

Adversarial inputs. Crafted inputs that manipulate AI decisions – classification evasion, misclassification attacks, perturbation-based exploits. We’ve seen production image classifiers fooled by single-pixel changes that a human would never notice. The Act requires resilience against these attacks, which means adversarial testing isn’t optional anymore.

Prompt injection. For LLM-based systems, this is the big one. Direct prompt injection (overriding system instructions), indirect prompt injection (embedding malicious instructions in data the model processes), and jailbreaking (bypassing safety guardrails) are all attack vectors that the Act implicitly requires you to defend against. In our testing, we’ve found that most LLM deployments are vulnerable to at least one form of prompt injection – the defenses are often superficial keyword filters that can be trivially bypassed.

Data poisoning. Corrupting training datasets to influence model behavior. This is especially dangerous for systems that continuously learn from new data, since the poisoning can happen gradually and be nearly impossible to detect without proper data governance.

Model extraction and inversion. Reconstructing training data or model logic from outputs. If your high-risk AI system leaks PII from its training data through carefully crafted queries, that’s both a GDPR violation and an EU AI Act violation.

Alignment with Security Frameworks

The Act’s security requirements map directly to frameworks that the security community already uses:

MITRE ATLAS documents real-world adversary tactics targeting AI systems across development, deployment, and inference. The attack techniques catalogued in ATLAS – model evasion, poisoning, access misuse via APIs – are precisely the threats the Act requires high-risk systems to withstand. If you’re building a compliance program, ATLAS gives you a concrete threat model to test against.

OWASP Top 10 for LLM Applications covers the most critical vulnerabilities in LLM deployments: prompt injection, training data leakage, over-permissioned tool use, insecure plugins, and inadequate output sanitization. We use this as a baseline during every LLM security assessment, and the overlap with EU AI Act requirements is significant. If your LLM-based system fails against the OWASP LLM Top 10, it almost certainly fails to meet the Act’s robustness requirements too.

NIST AI Risk Management Framework provides a structured approach organized around four functions – Govern, Map, Measure, Manage. While the EU AI Act is legally binding and NIST is voluntary, they share foundational principles. Organizations operating in both the EU and US should use NIST as a complementary strategic layer on top of EU AI Act compliance.

Practical Security Measures

Based on our experience testing AI systems, here’s what actually works for meeting the Act’s security requirements:

• Adversarial testing during development – not just functional testing. Fuzz your models with adversarial inputs. Red team your LLMs with prompt injection attacks. Test your classifiers against evasion techniques. Do this before deployment, not after an incident.
• Strict access controls on AI APIs – limit what authenticated users can do, rate-limit queries, and monitor for patterns that suggest model extraction attempts.
• Training data validation – verify dataset integrity, scan for poisoned samples, and implement provenance tracking for data sources.
• Runtime anomaly detection – monitor model inputs and outputs for statistical deviations that could indicate adversarial activity or drift.
• Incident response playbooks specifically for AI failures – model misbehavior is different from a traditional application vulnerability. Your IR process needs to account for model rollback, retraining decisions, and downstream impact assessment.

Transparency and User Rights

The Act mandates that AI-generated content is labelled as such. Chatbots must disclose they’re AI. Deepfakes and synthetic media must be clearly marked. Emotion recognition and biometric systems must explicitly notify users. These labelling requirements are critical in political communication, journalism, and consumer engagement, where AI-generated content can be used to manipulate.

For generative AI providers specifically, the obligations include disclosing that content was AI-generated, publishing summaries of training datasets (including copyrighted material usage), and implementing safeguards against generating illegal content. High-impact general-purpose models face additional requirements: notifying the EU AI Office, submitting to systemic risk evaluations, and reporting serious incidents.

Individuals affected by AI decisions have the right to be informed when AI is involved, understand the decision logic in plain language, access explanations for high-risk AI decisions, and challenge or appeal those decisions. These rights extend GDPR’s automated decision-making protections into the broader AI context.

Fines and Enforcement

The penalty structure is designed to hurt:

Violation	Penalty
Use of prohibited AI practices	Up to €35 million or 7% of global annual turnover
Non-compliance with high-risk AI obligations	Up to €15 million or 3% of global annual turnover
Supplying incorrect or misleading information to authorities	Up to €7.5 million or 1% of global annual turnover

For context, 7% of global turnover would mean a fine of over $17 billion for a company like Google. These aren’t theoretical numbers – the EU has shown with GDPR that it’s willing to impose massive fines (Meta was hit with €1.2 billion in 2023).

Enforcement is handled by the newly established EU AI Office (for general-purpose and high-impact models) and National Supervisory Authorities in each member state (for everything else). These bodies will conduct market surveillance, investigate complaints, and issue fines and corrective actions. Regulatory sandboxes will also be available for startups and SMEs to test AI systems with regulatory guidance before going to market.

Beyond fines, non-compliance carries operational risks: systems can be pulled from the EU market, violations may be publicly disclosed, and a single enforcement action can trigger broader audits across your entire AI portfolio.

How the EU AI Act Compares Globally

The EU isn’t regulating AI in isolation. Here’s how the Act stacks up against other major frameworks:

Feature	EU AI Act	U.S. (EO + NIST)	UK	Canada (AIDA)	China
Legally binding	Yes	No (voluntary)	No	Pending	Yes
Risk classification	Mandatory 4-tier	Organization-defined	No	Yes (less detailed)	Partial
Enforcement and fines	Yes (up to 7%)	No centralized enforcement	No	Pending	Yes
Transparency mandates	Yes	Best practice only	Encouraged	Yes	Yes
Human oversight required	Yes	Yes (recommended)	Yes (recommended)	Yes	Partial

The practical takeaway: if you comply with the EU AI Act, you’ll largely satisfy requirements in other jurisdictions too. It’s the strictest framework on the planet right now. The US relies on voluntary self-regulation through NIST, the UK uses a sector-specific approach with no centralized AI law, and Canada’s AIDA is still working through parliament. China has binding rules but they’re focused on state interests and content control rather than individual rights.

For multinational companies, the smart move is to align with the EU AI Act as your baseline and layer on jurisdiction-specific requirements as needed.

Preparing for Compliance

Here’s a practical compliance roadmap based on what we’ve seen work during security assessments and compliance readiness engagements:

Step 1: Inventory and classify. Document every AI system in your organization – in development and in production. Map each system’s intended use, operational context, and user base. Classify it against the Act’s four risk tiers. This sounds straightforward but most organizations we work with discover AI systems they didn’t even know they had – embedded ML models in third-party tools, AI features activated by default in SaaS platforms, shadow AI projects in individual teams.

Step 2: Build a cross-functional governance team. This isn’t a legal-only task. You need engineers (model design, data handling), product managers (intended use, deployment oversight), legal and compliance (interpreting obligations), security (risk management, adversarial testing), and ethics/HR (fairness, bias, workforce impact). Create clear ownership and get executive sponsorship.

Step 3: Documentation and logging. For high-risk systems, you need comprehensive technical documentation covering system architecture, training data sources, risk management procedures, decision-making logic, data governance policies, human oversight protocols, and event logging mechanisms. Even for lower-risk systems, basic documentation reduces liability. Consider implementing AI Bills of Materials (AIBOMs) and model cards.

Step 4: Security testing. This is where most organizations have the biggest gap. The Act requires that high-risk AI systems are resilient to adversarial attacks – but most organizations have never run an adversarial test against their AI models. Red team your LLMs for prompt injection, test your classifiers against evasion attacks, validate your training data pipeline against poisoning, and verify that your model APIs don’t leak training data through inference attacks.

Step 5: Ongoing monitoring and audit readiness. Compliance isn’t a one-time project. Implement real-time monitoring for model behavior, set up alerts for anomalies, maintain version control for models and documentation, and conduct internal compliance audits at least quarterly. When the regulators come knocking – and they will – you need to be ready immediately, not scrambling to assemble documentation.

How FORTBRIDGE Can Help

We’re a penetration testing and security consulting firm, not a compliance consultancy. What we bring to EU AI Act readiness is the offensive security perspective – we test whether your AI systems actually withstand the attacks the Act requires them to survive.

Our AI security services include:

• LLM red teaming – systematic prompt injection testing, jailbreak attempts, data extraction attacks, and safety guardrail bypass testing against the OWASP LLM Top 10
• AI model adversarial testing – evasion attacks, poisoning resistance evaluation, and robustness testing aligned with MITRE ATLAS attack techniques
• API security assessments for AI endpoints – authentication, authorization, rate limiting, and model extraction prevention testing
• Agentic AI security reviews – tool permission auditing, escalation path analysis, and autonomous action boundary testing
• EU AI Act readiness assessments – mapping your current security posture against Articles 9-15 requirements and identifying gaps before regulators do

If your organization deploys AI systems in the EU – whether that’s an LLM-powered chatbot, a high-risk HR automation tool, or an autonomous agent architecture – the security requirements in the EU AI Act aren’t suggestions. They’re obligations with real fines behind them. Better to find the vulnerabilities in a controlled test than during a regulatory audit or, worse, after an incident.

Get in touch with us today to test and strengthen your AI infrastructure.

About Post Author