Enforcement of the EU AI Act began on August 2, 2026. Not in 2027, not "eventually" — now. If you're building AI agents in the EU and treating this as a next-year problem, the timeline has already moved underneath you.
This piece is for the person who owns the consequences if something goes wrong — the founder who shipped the agent, the CISO answering to a board, the compliance lead staring down an audit. Not the person who wrote the code. The person who has to answer for it.
Here's what actually applies today, what's moved, and — the part almost everyone gets backwards — what order to do it in.
What's live right now
Three milestones of Regulation (EU) 2024/1689 are already in force:
Prohibited practices — banned since February 2, 2025. Social scoring, manipulative techniques that cause harm, untargeted scraping of facial images. If your agent does any of these, this isn't a compliance question; it's a legal one.
GPAI obligations and the Article 70 framework — general-purpose AI providers owe transparency about training data, copyright policy, and system capability, and the EU's AI Office has had enforcement powers over GPAI providers since August 2025. August 2, 2026 marked enforcement going live at EU and national level, with national authorities now active.
Article 50 transparency duties — applicable now. Anyone deploying an AI system that interacts with humans must make the AI interaction clear; synthetic content must be identifiable. For agent builders, this is the clock that's already running: if your agent takes actions on a user's behalf, discloses data, or generates content, transparency duties apply to you today — not in December 2027.
What's moved
The high-risk regime — the strict obligations most people picture when they hear "AI Act": risk assessment, logging, human oversight, conformity assessment — now applies from December 2, 2027. The deadline moved; some coverage still cites the older date.
If your agent is a safety component or operates in a regulated domain (employment decisions, credit, critical infrastructure, access to essential services), that's your hard deadline. If it's not, the high-risk regime may not apply to you at all — but Article 50 and GPAI obligations still can, depending on how your agent is built and deployed.
Two more dates worth knowing: synthetic-content marking obligations land December 2, 2026, and national penalty frameworks are already live in several member states.
The pattern that fails
Here's the sequencing mistake we keep seeing, and it's understandable, because it's how compliance has worked for decades: treat the regulation as the deadline, security as the engineering detail. Audit comes due → scramble to produce evidence → discover the system underneath was never actually tested → manufacture paperwork that describes a system you wish you had.
It fails because an audit is easy when the system going in was already secure, and brutal when you're manufacturing evidence for a system you never tested. There's no memo you can write in November 2027 that substitutes for a year of actually knowing what your agent does under adversarial pressure.
There's also an uncomfortable truth the Act has made explicit: for anyone shipping an agent with real tools attached — anything that can move money, access records, take an action — being able to prove you tested it is now the minimum bar. Not a differentiator. The minimum bar. The Act having real teeth shouldn't be controversial; customer safety and basic accountability for deployed agents should have been the floor from day one.
Security first. The paperwork follows.
The order of operations that works is the opposite of the scramble:
1. Find out what's actually wrong with your agent. Adversarial testing, before anyone external looks at it. Prompt injection, indirect injection through ingested content, tool misuse, scope escalation — the attack classes that apply to agents specifically, not just chatbots.
2. Close what you find. Prioritize by consequence: what can touch money, records, or irreversible actions.
3. Let the evidence pack write itself. What you tested, what you found, what you fixed, when. That's the documentation the Act's logging and transparency provisions actually want — and it's a byproduct of the work, not a separate track you fund later.
Don't start with the Article 9 checklist. Start by finding out what's actually wrong. The evidence pack basically writes itself once you've done that honestly.
What an evidence pack looks like when testing came first
Concrete, not aspirational:
- Test inventory: attack classes covered, probe methodology, date ranges
- Findings log: what was found, severity, the observed behavior that produced each finding
- Remediation trail: what was closed, what was accepted as a risk and why
- Residual posture: what's tested and passing as of the audit date, in plain terms
That's the shape of what an auditor asks for under the logging and transparency provisions — and every line of it is generated as a byproduct of actually testing.
What Orithos does here — and doesn't
Honesty section, because this space has enough inflated claims: Orithos doesn't make anyone compliant. Nothing does — no tool, no platform, no vendor. Compliance is a property of your system and your process, certified by authorities, not purchased.
What Orithos provides is the evidence a builder needs: what you tested, what you found, what you fixed. The paperwork follows from that. If you run an agent with real tools attached and want to know what's actually wrong before someone else finds out, that's the job.
The EU AI Act didn't create the need to test agents. It just made the consequences of not knowing visible.