Two weeks ago, the EU Council and Parliament reached a provisional deal that pushed the AI Act's biggest enforcement wave back by sixteen months. That sounds like a win for everyone behind on compliance. It is not. The August 2, 2026 deadline still triggers a long list of obligations, and the part of the law that moved still becomes binding on December 2, 2027. Eighty days is a short window if your AI inventory is still a guess and your transparency wiring is still a wishlist.
This is the map we use at StudioMeyer to think about the law, the dates, and the engineering work that has to happen between now and the end of next year. We host AI products in Frankfurt and we build memory systems for European customers. We have written this once for ourselves, and we are writing it again here because most of the things published about the AI Act this month are either too legal to be useful or too vague to be wrong. We also offer dedicated advisory engagements for teams that want help mapping their systems to the law, so the second half of this article describes how we approach that work in practice.
The deadlines that already happened
The Act ( became enforceable. Social scoring, manipulative subliminal techniques, untargeted facial image scraping, biometric categorisation that infers sensitive attributes, and emotion recognition in workplaces and schools are all banned outright. The fine for breaking these rules is up to €35 million or 7 percent of global annual turnover, whichever is higher. On the same date, the AI literacy obligation in Article 4 turned on, requiring providers and deployers to make sure their staff understand the systems they ship and use.
On 2 August 2025, the rules for general-purpose AI models in Articles 51 to 56 became binding. Foundation model providers ( published on 10 July 2025 is the Commission's preferred route to demonstrate compliance and reduce administrative burden, and most major providers have signed it.
If your team uses Claude or GPT-4 through an API, you do not inherit the model provider's obligations. You inherit the obligations of being a deployer or, more often, a provider of the system you built on top.
The shift that happened on 7 May 2026
For the past year, every compliance article ended with the same sentence: 2 August 2026 is the date the rest of the Act becomes enforceable. That sentence is now partly wrong.
On 7 May 2026, the and . And every obligation that is not on the postponement list still hits in August.
What still triggers on 2 August 2026
The deployer-facing parts of plus AI embedded in regulated products. If your system makes or shapes decisions in employment, credit, education, essential services, law enforcement, biometrics, justice administration, or migration, you are likely high risk. The obligations are heavy. Documented risk management (Article 9), training data governance (Article 10), Annex IV technical documentation (Article 11), automatic logging with at least six months of retention (Article 12), transparency to deployers (Article 13), human oversight that allows intervention and override (Article 14), and demonstrated accuracy, robustness, and cybersecurity (Article 15). For deployers in this tier, a fundamental rights impact assessment is required before first use (Article 27).
Limited risk is the chatbot tier. Your obligation is Article 50 transparency, which is short to read and not short to implement well. Tell the user they are talking to AI at the start of the conversation, give them a path to a human if the conversation goes off the rails, and label any AI-generated content the system emits.
Minimal risk is everything else. Spam filters, recommendation engines that do not touch protected decisions, autocomplete, and the long tail of internal tooling. No specific AI Act obligations, although GDPR and sector law still apply.
The boundary case that catches most teams is the AI agent that takes actions on a user's behalf. A customer support chatbot is limited risk. The same chatbot wired to a CRM that can refund payments, send emails, or delete records is closer to high risk. The classification follows the consequences, not the model.
What this means for AI agent builders
We build agents for a living. The Article 14 and Article 15 requirements are the ones that change how you write code, not just how you write policy.
Article 14 requires that an operator can interrupt the agent. In our base agent class, that translates to iteration limits, hard timeouts, and a kill switch the operator can fire mid-execution. Tool calls that do anything irreversible (sending email, moving money, deleting data, calling an external API that costs real money) need an explicit human approval step. The phrase the Act uses is "effective human oversight", and effective is doing the heavy lifting.
Article 12 requires automatic logging of events over the system's lifetime. That means every tool call, every LLM round-trip, every decision branch, every input the agent saw, and every output it produced. Logs must be retained long enough to support post-market monitoring and incident reporting (Articles 72 and 73), and deployers must keep their copies for at least six months under Article 26.
Article 15 requires robustness. Input validation that catches prompt injection, output validation that stops hallucinated data from propagating, resource limits that prevent token-bombing and runaway loops, and adversarial testing against known agent failure modes. None of this is novel security engineering. The change is that for high-risk agents, it is now legally required, with documentation.
Germany: the Bundesnetzagentur takes the wheel
For teams in DACH, the practical question is who knocks on your door if something goes wrong. On 11 February 2026, the inside the BNetzA has been operational since July 2025 and is one of the few live SME compliance support channels in the EU. And BaFin retains sector-specific authority for high-risk AI directly tied to regulated financial activities, so banks and insurers will face two supervisors, not one. The KI-MIG is still going through Bundestag and Bundesrat, with second and third readings expected before the summer recess.
How we keep our own AI products compliant
We run our products on European infrastructure. under MIT, so customers can read what we do with their data before they sign anything. Multi-tenant isolation runs at row level with explicit tenant IDs threaded through every query, and a static test in CI breaks the build if a handler forgets to include the tenant filter.
The memory product itself is built around an audit trail. Decisions, learnings, and entity observations carry a source, a date, and a confidence score. That is useful for the AI engineer who wants to know why a memory was stored, and it is the same shape of artefact the AI Act asks for when it talks about traceability and post-market monitoring. We did not build it for compliance. We built it because we got tired of memories that lied to us. The compliance fit is a bonus.
Every chatbot we ship discloses its nature on first contact, and the Article 50 transparency wiring is shared across our products through a single library. We also maintain a . The map is easier to draw with two pairs of eyes on it.
Originally published on .
SOCIAL SHARE CARD GENERATOR