EU AI Act Compliance: What Security Teams Must Do Now
EU AI Act Compliance: What Security Teams Must Do Now
Most compliance conversations I’ve sat through follow the same arc: leadership gets nervous about a new regulation, legal drafts a policy, someone in IT gets handed a checklist, and six months later nothing has materially changed in how the systems actually operate. The EU AI Act is going to follow that same arc at a lot of organizations — and the ones that treat it as a documentation exercise are going to get caught flat-footed when enforcement lands.
The EU AI Act has been in force since August 2024. Prohibitions on unacceptable-risk AI took effect in February 2025. Obligations for high-risk AI systems — which is where most enterprise AI in regulated industries sits — become enforceable in August 2026. That’s not distant. If you’re in financial services, healthcare, critical infrastructure, or HR technology, you have roughly a year to get your house in order. This post is about what “getting your house in order” actually requires from a security and governance perspective, not from a legal one.
TL;DR: The EU AI Act imposes specific technical and operational requirements on high-risk AI systems — not just policies. Security teams need to treat conformance the same way they treat SOC 2 or ISO 27001: a documented, auditable program with real controls, not a checkbox exercise.
What “High-Risk” Actually Means in Practice
The Act defines high-risk AI systems across Annex III categories. If your organization uses AI for any of the following, you’re in scope:
- Biometric identification or categorization
- Credit scoring or insurance risk assessment
- HR decisions (resume screening, performance evaluation, termination recommendations)
- Benefits administration or public services access decisions
- Critical infrastructure management
- Law enforcement and border control applications
For most enterprise financial services or healthcare organizations, at least one of these applies. The practical implication: you can’t simply drop a third-party AI tool into these workflows and call it done. The Act places obligations on both providers and deployers. Even if you’re using a vendor’s model, if you’re the one deploying it in a high-risk context, you carry significant responsibility.
I’ve spent the last two-plus decades watching organizations discover this same dynamic in other regulatory contexts — PCI DSS, HIPAA, SOX. The pattern is identical: “we use a compliant vendor” is never sufficient. Your controls, your documentation, your audit trail.
The Five Technical Requirements That Will Trip You Up
Reading through the actual regulation text rather than summaries, five requirements stand out as the ones most likely to cause pain for security and IT teams:
1. Risk management system — Article 9
The Act requires a documented, continuous risk management process for high-risk AI systems. Not a one-time assessment. Continuous. This means you need monitoring, incident logging, and a feedback loop that updates your risk profile as the model’s behavior or the deployment context changes. If your current AI governance is a policy document and a vendor questionnaire, that’s not a risk management system.
2. Data governance — Article 10
Training, validation, and test data must meet specific quality criteria. Bias assessments are required. For organizations using fine-tuned models or retrieval-augmented generation against internal data, this creates a documentation obligation most teams haven’t thought through. What data did you use? Where did it come from? What bias checks did you run? If you can’t answer those questions, you have a gap.
3. Technical documentation — Article 11
Before deploying a high-risk AI system, you need a complete technical documentation package. The Act specifies what this must include: system architecture, training data characteristics, performance benchmarks, intended purpose, known limitations, and cybersecurity measures. For most enterprise AI deployments I’ve seen, that documentation simply doesn’t exist. Vendors provide some of it; deployers fill in the rest. The gap between “what the vendor provided” and “what Article 11 requires” is usually substantial.
4. Logging and audit trail — Article 12
High-risk AI systems must log activity automatically, to the extent technically feasible. Specifically: when the system was used, the input data characteristics, and the output that informed a human decision. If you’re using AI to assist in credit decisions or HR screening and you have no logs, you’re not just out of compliance — you can’t defend a discrimination claim, either.
5. Human oversight — Article 14
This is the one that gets glossed over most often. The regulation requires that high-risk AI systems be designed so that humans can “fully understand the capacities and limitations” of the system and can intervene or override outputs. That’s not just a UI requirement — it’s an architectural one. If your AI workflow doesn’t preserve a clear human decision point with meaningful context about what the AI recommended and why, you need to redesign it.
Where NIST AI RMF Fits In
If you’re a US-based organization asking “what does the EU AI Act have to do with me,” the answer is: your EU customers, partners, and subsidiaries bring you into scope. But more practically: the NIST AI Risk Management Framework (AI RMF), published in January 2023, maps almost directly onto the EU AI Act’s requirements. If you’ve implemented NIST AI RMF’s four core functions — Govern, Map, Measure, Manage — you’ve done roughly 60–70% of the work required for EU AI Act conformance.
The key gap is that NIST AI RMF is voluntary. The EU AI Act is not. Organizations that adopted NIST AI RMF as a governance framework are better positioned than those starting from scratch, but they still need to formalize documentation, close the audit trail gaps, and address the specific Annex III applicability determinations.
For US-headquartered enterprises, I’d treat NIST AI RMF implementation as the foundation and EU AI Act compliance as the external audit layer that validates whether the foundation is actually working.
A Practical Compliance Readiness Checklist
This isn’t a legal compliance checklist — get an attorney for that. This is a technical readiness checklist for security and IT teams.
Inventory
- Identify every AI system in production and classify it against EU AI Act Annex III
- Document which systems are developed internally versus deployed from vendors
- Determine for each: are we provider, deployer, or both?
Documentation
- Draft or obtain Article 11 technical documentation for each high-risk system
- Document data sources, preprocessing steps, and bias assessment results for training data
- Record intended purpose, known limitations, and performance benchmarks
Controls
- Confirm automated logging is in place for all high-risk AI system interactions
- Verify logs capture: timestamp, input characteristics, output, human decision made
- Review workflow design to ensure human oversight points are meaningful, not cosmetic
Risk Management
- Establish a recurring review cadence for each high-risk system (not just at deployment)
- Define what constitutes a material change triggering a full re-assessment
- Assign named accountability for each system’s ongoing compliance
Vendor Management
- Issue updated vendor questionnaires specific to AI Act obligations
- Require Article 11 documentation from AI vendors for systems you deploy
- Update contracts to clarify provider versus deployer responsibilities
What Enforcement Actually Looks Like
The EU AI Act establishes national supervisory authorities in each member state and a new European AI Office at the EU level. Fines for non-compliance with high-risk system obligations are up to €30 million or 6% of global annual turnover, whichever is higher. For context, that’s a higher fine ceiling than GDPR.
Enforcement will almost certainly follow the same early pattern GDPR did: a handful of high-profile cases to establish precedent, then accelerating regulatory attention. GDPR enforcement was uneven in its first two years and then became very consistent. I’d expect the same here. The organizations that waited for “real” enforcement before taking GDPR seriously paid more than the ones that moved early — both in remediation costs and in regulatory attention.
The Practical Reality for Regulated Industries
If you’re in enterprise financial services, healthcare, or HR technology, you’re not facing the EU AI Act in isolation. You’re also managing existing regulatory frameworks — FFIEC guidance on model risk management, HIPAA, SOX — that already impose documentation and oversight requirements on decision-making systems. The good news is that AI Act compliance can be layered onto existing model governance programs. The bad news is that most of those programs weren’t designed with the velocity of AI deployment in mind.
The average bank’s model risk management framework was built for quarterly risk rating model updates. It is not built for a retrieval-augmented generation system that is effectively updating its behavior every time the underlying index refreshes. That gap between existing governance cadence and actual AI system behavior is where compliance problems will emerge.
Key Takeaways
- The EU AI Act’s high-risk system requirements become enforceable August 2026. Regulated industries have roughly a year.
- “We use a compliant vendor” is not sufficient. Deployers carry independent obligations.
- Five technical requirements need security team ownership: risk management, data governance, technical documentation, audit logging, and human oversight architecture.
- NIST AI RMF implementation provides a strong foundation but doesn’t close the EU AI Act gap on its own.
- Existing model risk management programs in regulated industries need significant velocity upgrades to cover modern AI deployment patterns.
- Start with an AI system inventory and Annex III classification. You can’t prioritize what you haven’t mapped.
Comments