The EU AI Act generates a lot of anxiety. Teams read through the text, see phrases like "high-risk AI system" and "conformity assessment" and "post-market monitoring obligations," and immediately reach for their legal counsel.
That anxiety is understandable but mostly misplaced. The EU AI Act, at its core, is asking for things that any serious production AI system should be doing anyway. The challenge isn't understanding what's required, it's translating regulatory language into engineering decisions.
Here's how to do that.
In 30 seconds
The EU AI Act is not solved with a legal memo. It's solved with per-request runtime controls. If you can map risk, evidence, and oversight into operations, you can execute without drama.
What you'll get from this article:
- How to classify use cases in a practical way
- What high-risk actually requires in operations
- A direct matrix to move from theory to implementation
Start with risk classification
The first thing the EU AI Act asks is: what category does your AI system fall into?
The Act defines four risk levels:
Unacceptable risk, banned outright. Real-time biometric surveillance in public spaces, social scoring systems, AI that exploits vulnerabilities to manipulate behavior. If you're building one of these, you have bigger problems than compliance.
High risk, the category that requires the most work. This includes AI systems used in critical infrastructure, employment decisions, credit decisions, healthcare, law enforcement, border control, and administration of justice. If your system touches any of these areas, the Act imposes significant requirements.
Limited risk, systems that interact with users in ways that require transparency. Chatbots must disclose they're AI. Deepfakes require labeling. The requirements here are manageable.
Minimal risk, everything else. Spam filters, AI-powered playlists, most B2B tools. Largely unregulated beyond existing law.
Most enterprise AI systems that handle sensitive domains (healthcare, finance, legal, HR) fall into the high-risk category. That's where the work is.
Quick matrix: system type and minimum obligations
| System type | Typical risk | Recommended minimum obligations |
|---|---|---|
| General informational chatbot | Limited / minimal | AI disclosure, basic logging, content guardrails |
| Support assistant with personal data | Limited / high (depending on use) | PII handling, per-request audit trail, tenant-specific policies |
| Scoring/recommendation for hiring or finance | High | Risk management, structured evidence, human oversight, override controls |
| Clinical assistant with health data | High | PHI/PII controls, human review, full traceability, strict data governance |
What high-risk actually requires
For high-risk systems, the EU AI Act requires six things that map cleanly to engineering controls:
1. Risk management system Ongoing identification and mitigation of risks throughout the system's lifecycle. In practice: a documented process for identifying what can go wrong, and controls that address each risk.
Engineering translation: Threat modeling for your AI pipeline. What are the ways this system could cause harm? Document them. Build controls that address them.
2. Data governance Training data must be relevant, representative, and free from errors that could create discriminatory outcomes. For systems using third-party models, this shifts to ensuring the inputs you send are appropriate and that you're using models for their intended purposes.
Engineering translation: Input validation. PII handling. Documentation of which models you use and for what.
3. Technical documentation Detailed documentation of the system's design, capabilities, limitations, and intended use.
Engineering translation: Architecture documentation. Model cards for each model you use. Documented capabilities and explicit out-of-scope use cases.
4. Logging and record-keeping The system must log events with sufficient detail to enable post-hoc investigation and demonstrate compliance.
Engineering translation: Structured audit trail. Every request logged with timestamp, inputs (or hashes), outputs, rules evaluated, decisions made.
5. Transparency to users Users must be informed they're interacting with an AI system, and receive enough information to understand its capabilities and limitations.
Engineering translation: UI disclosures. Error messages that explain when the system can't help. Documentation users can access.
6. Human oversight High-risk systems must be designed to allow human oversight, including the ability to override or shut down the system.
Engineering translation: Circuit breakers. Admin controls to disable features or restrict outputs. Escalation paths for edge cases the system can't handle.
The runtime layer is where compliance lives
Here's the insight that changes how you think about EU AI Act compliance: most of these requirements aren't about how you build the model. They're about how you operate it.
Risk management, logging, oversight, data governance, these are operational concerns. They happen at runtime, for every request.
This means compliance isn't a one-time certification exercise. It's something your pipeline either does or doesn't do for every request that flows through it.
A request that processes health data needs to be evaluated against HIPAA and EU AI Act requirements. A request that makes a hiring-related recommendation needs to be flagged as high-risk and logged with additional detail. A request that a human reviewer needs to examine needs to generate an alert, not just an audit record.
Practical starting points
If you're trying to move from "we should probably look at EU AI Act compliance" to "we have controls in place," here's where to start:
Week 1: Classify your AI use cases by risk level. Be honest about which ones touch high-risk domains. Document the list.
Week 2: Audit your current logging. For high-risk use cases, do you have a complete audit trail? Can you answer "what did this request look like, what did the model return, and what happened as a result?"
Week 3: Implement input controls. For high-risk use cases, add PII detection, prompt injection scanning, and compliance policy evaluation to the request pipeline.
Week 4: Document everything. What models you use, for what purposes, with what limitations. This documentation is both a compliance requirement and a useful forcing function.
If classification is uncertain, temporarily assume the stricter risk tier and narrow later with evidence.
The Checklist
For each AI use case in your system:
- Risk level classified (unacceptable / high / limited / minimal)
- For high-risk: risk management process documented
- Input validation and PII handling in place
- Structured audit trail logging every request with sufficient detail
- User-facing transparency in place (AI disclosure, capability documentation)
- Human oversight mechanism exists (admin controls, circuit breakers)
- Technical documentation covers design, capabilities, and limitations
What to do this week
- Classify each AI use case and assign a technical owner.
- Define minimum controls per risk level in one internal table.
- Validate in logs that every request leaves enough evidence for audit.
The EU AI Act isn't trying to stop you from building AI. It's trying to ensure that AI systems operating in high-stakes domains are designed and operated responsibly. Most of what it requires, you should be doing anyway.