The EU AI Act: What Security Teams Actually Need to Do

Most coverage of the EU AI Act is written for lawyers and policy teams. This one is for the security engineer who just got forwarded an email asking "are we compliant?" — and needs to know what technical work that question actually implies. The short answer: the Act turns several things you should already be doing into things you can be fined for not documenting.

The AI Act is the EU's risk-based regulation for artificial intelligence. It sorts systems into tiers — prohibited, high-risk, limited-risk, and minimal-risk — and layers separate obligations on top for general-purpose AI (GPAI) models, including the most capable ones deemed to carry systemic risk. It applies extraterritorially: if your AI system's output is used in the EU, the Act can reach you regardless of where your company sits. For security teams, the important shift is that "we have an AI policy" is no longer sufficient. You will be asked for evidence.

The adversarial-testing duty

The provision that lands squarely on security teams is the expectation of adversarial testing. For high-risk systems, the Act requires appropriate testing to identify the most suitable risk-management measures and to ensure consistent, safe performance. For general-purpose models with systemic risk, providers are expected to perform and document model evaluation including adversarial testing — commonly understood as red teaming — to identify and mitigate systemic risks.

In plain terms: you are expected to actively try to break your own AI systems, record what you found, and show what you did about it. This is not a one-off certificate. It is a continuous obligation, because the models, the prompts, and the threat landscape all keep moving. A red-team result from last quarter says little about the fine-tuned model you shipped last week.

Evidence is the deliverable

The recurring theme across the Act's high-risk obligations is documentation. Compliance is demonstrated through artefacts, not intentions. The evidence a security team is realistically on the hook to help produce includes:

• A risk-management record — the identified risks of your AI system, how you tested for them, and the measures you took. This is a living document, updated across the system's lifecycle.
• Technical documentation describing the system, its intended purpose, its data, and its known limitations, in enough detail for an authority to assess conformity.
• Logging and traceability — high-risk systems must log events over their lifetime so behaviour can be reconstructed. For security, that means a tamper-evident audit trail of AI activity.
• An accurate inventory — you cannot document, test, or govern AI systems you don't know you're running. Discovery of shadow AI is the unglamorous foundation the rest of the evidence sits on.
• Post-market monitoring — a plan for watching real-world performance and reporting serious incidents.

Notice how much of this maps onto controls security teams already recognise: asset inventory, testing, logging, incident response. The Act is, in large part, asking you to apply mature security discipline to AI systems specifically — and to keep the receipts.

The timelines are already live

The Act entered into force in 2024 and applies in staggered phases, so "we'll deal with it later" has quietly stopped being an option for the earliest obligations:

• Feb 2025Prohibited practices banned, and AI-literacy obligations for staff began.
• Aug 2025General-purpose AI model obligations — including evaluation and, for systemic-risk models, adversarial testing — took effect.
• Aug 2026Broad application of the Act, with high-risk system obligations phasing in.
• 2027Extended transition for high-risk AI embedded in regulated products.

Exact dates and scoping have nuance, and enforcement guidance continues to evolve — treat this as a map, not legal advice. But the direction is unambiguous: the obligations that touch security work are switching on now, not in some distant future.

Where to start this quarter

You don't need to solve the entire Act at once. A pragmatic security-led sequence: build a current inventory of the AI systems, agents, and models actually in use; classify which of them could fall into high-risk or GPAI scope; stand up adversarial testing for the ones that do; and make sure logging and evidence collection are running so the documentation writes itself over time. Every one of those steps is good security practice regardless of the regulation — the Act just makes them auditable.

The EU AI Act rewards teams that can show their work. If you can produce a live AI inventory, a record of adversarial testing, and a tamper-evident log on request, you are most of the way to defensible compliance — and you've meaningfully reduced real risk in the process.