I’ve long argued that a market correction is overdue, especially given the phenomenon large language models have created. And to be clear, by correction I don’t mean financial valuations or the rally happening across Silicon Valley’s venture market. I mean a correction in how we use these systems, a move away from treating the generative capabilities of LLMs as magic, and toward using them scientifically for actual enterprise processes.
The arrival of open-weight and open-source models has pushed the technology forward and proven something important: we don’t actually need as much infrastructure or capital to build large language models as we once assumed (we still need a lot, but that’s a separate debate). And now, with the EU AI Act moving toward full enforcement, the argument that “AI hallucination is just something we live with” is no longer acceptable when it comes to enterprise use or compliance.
At the same time, the push toward vertical AI has gotten a little absurd. Nearly every startup today is being built on top of an AI layer without any real consideration of what that layer actually is or what it owns. Vertical AI founders pitch their products as though they’ve discovered something entirely new, when in reality most are simply applying a general-purpose layer to a specific problem, without much scientific rigor behind the claim. That’s a conversation for another day, though. Today I want to focus on the EU AI Act itself: what it is, and how it’s going to shape the future of AI.
Making Sense of the EU AI Act
I’ve spent the last few months trying to wrap my head around the EU AI Act, and I want to walk you through what I’ve learned, not as a lawyer, but as someone who’s genuinely curious about where AI regulation is headed and what it means for the rest of us.
What Exactly Is the EU AI Act?
At its core, the EU AI Act is the world’s first comprehensive, horizontal law regulating artificial intelligence. It entered into force back on August 1, 2024, and instead of treating AI as one single thing to be regulated uniformly, it takes a risk-based approach. The law sorts AI systems into four buckets: unacceptable risk (banned outright), high risk (heavily regulated), limited risk (subject to transparency rules), and minimal risk (largely left alone).
What struck me most when I first read about it is how the EU chose to regulate based on use case rather than the underlying technology. A facial recognition system used to unlock your phone is treated very differently from the same technology used for real-time biometric surveillance in a public square. That second use is banned outright, along with practices like social scoring, subliminal manipulation, and exploiting vulnerabilities of specific groups like children or people with disabilities. Those prohibitions have actually been in force since February 2025, so they’re not some distant future concern, they’re already law.
The High-Risk Category Is Where Things Get Real
The part of the Act that businesses lose sleep over is the “high-risk” category. This covers AI used in things like hiring, credit scoring, law enforcement, migration and border control, critical infrastructure, education, and medical devices. If your AI system falls into this bucket, you’re looking at obligations around risk management, data governance, technical documentation, human oversight, and conformity assessments before you can even put the system on the market.
Here’s where I think the story gets interesting, and honestly a bit messier than most explainers let on. The original timeline required these high-risk obligations to fully kick in by August 2, 2026. But over the course of 2025 and into 2026, it became clear that the EU itself wasn’t ready. Key guidance documents, harmonized technical standards, and the transparency code of practice for AI-generated content were all running behind schedule, and a number of member states hadn’t even finished designating their own national regulators.
So the EU did something pragmatic: it introduced what’s being called the “Digital Omnibus on AI,” which passed through political agreement in May 2026 and formally entered into force on July 27, 2026. The upshot is a genuine breathing-room extension. Standalone high-risk systems under Annex III, think biometrics, employment, education, and border control tools, now have until December 2, 2027, to comply, a full sixteen-month reprieve from the original deadline. High-risk systems that are embedded in regulated products, like medical devices or lifts, get pushed to August 2028.
But August 2026 Still Matters
I want to be careful not to give the impression that the whole law just got shelved, because it didn’t. There’s a real trap here that I think a lot of companies are going to fall into: even though the high-risk compliance deadline moved, the transparency obligations under Article 50 are still on schedule. That means chatbots still need to disclose that users are talking to an AI, and synthetic or manipulated media, deepfakes, AI-generated images, audio, and video, still need to be clearly labeled. Legacy generative AI systems already on the market are required to embed machine-readable watermarks in their outputs, with the C2PA content credential standard emerging as the dominant technical approach. Some major players, like Adobe Firefly and OpenAI’s tools, already support this. Others are going to have to scramble.
There’s also a newer prohibition worth flagging: as of December 2026, the Act extends its bans to cover “nudifier” apps, AI tools that generate or alter sexually explicit content of real people without their consent, along with anything that produces child sexual abuse material. That’s a direct response to a very real and growing harm, and I think it’s one of the more unambiguously good parts of this law.
And general-purpose AI model providers aren’t off the hook either. If you’re a company putting a foundation model on the market, penalty enforcement around GPAI obligations is already active. If you haven’t implemented the GPAI Code of Practice or some equivalent compliance framework, you’re exposed right now, not in some hypothetical future.
The Clauses I’d Actually Bookmark
If you only have time to learn a handful of article numbers, these are the ones I keep coming back to:
Article 5 — Prohibited Practices. This is the outright-ban list: social scoring, subliminal manipulation, exploiting vulnerabilities of children or people with disabilities, and real-time remote biometric identification in public spaces (with narrow law-enforcement exceptions). These have been enforceable since February 2, 2025.
Article 6 — Classification Rules for High-Risk Systems. This is the article that decides whether your product even falls into the “high-risk” bucket in the first place, which determines almost everything else you owe under the Act.
Article 50 — Transparency Obligations. The chatbot-disclosure and AI-content-labeling rule I mentioned above. This is the one still landing on schedule even as the high-risk deadlines slide.
Articles 53 and 55 — Obligations for GPAI Model Providers (and those with “systemic risk”). Article 53 sets baseline duties like technical documentation and copyright policies for any general-purpose model; Article 55 adds heavier requirements — model evaluation, adversarial testing, incident reporting, cybersecurity — once a model crosses the systemic-risk compute threshold (currently pegged around 10²⁵ FLOPs in Annex XIII).
Article 52 — Systemic-Risk Classification Procedure. The process piece: how a model gets designated (or contests being designated) as posing systemic risk, and how the Commission maintains its public list of these models.
Article 4 — AI Literacy. Easy to overlook, but it obligates providers and deployers to ensure staff and anyone operating AI systems on their behalf have a sufficient level of AI literacy — a soft obligation that’s already shaping internal training programs.
Article 88 — Enforcement Powers Over GPAI Providers. Worth knowing because it’s the article that gives the Commission teeth, documentation requests, evaluations, and the ability to demand mitigation measures, and those enforcement powers only became fully active on August 2, 2026, a year after the underlying obligations themselves.
Press enter or click to view image in full size
None of these are static texts sitting in a vault, either — the Commission keeps layering guidelines and delegated acts on top of them (its GPAI Guidelines from July 2025 are a good example), so “reading the article” is really the starting point, not the finish line.
Why This Matters Beyond Europe
Here’s my honest take: even if you’re not an EU-based company, this law is going to shape how AI gets built globally, the same way GDPR reshaped data privacy practices well beyond Europe’s borders. Companies that want access to the EU’s roughly 450 million consumers will build compliance into their products from the start rather than bolting it on later. That tends to mean documentation, audit trails, and human oversight become default engineering practices, not afterthoughts.
I also think the delays tell us something important: regulating a fast-moving technology is genuinely hard, even for the people writing the rules. The EU isn’t backing off its ambitions, but it’s acknowledging that standards bodies, national regulators, and companies all need more runway to get this right. As of mid-2026, fewer than a third of member states had even fully designated their enforcement authorities, which tells you the infrastructure to enforce this law is still being built in real time.
Where I Land on This
I don’t think the EU AI Act is perfect, and I suspect we’ll see more “omnibus” style adjustments before the high-risk provisions are fully in force in December 2027. But I do think it represents a serious, structured attempt to put guardrails on AI without banning innovation outright. For anyone building or deploying AI systems, the message right now isn’t “relax, the deadlines moved.” It’s “the deadlines moved because the underlying complexity is real, so use the extra time wisely.” The transparency rules are live. The prohibitions are live. And the high-risk rules, even if delayed, are coming.
If there’s one thing I’d want you to take away, it’s this: the EU AI Act isn’t a single deadline you can mark on a calendar and forget about. It’s a rolling, evolving framework, and staying on top of it is going to be an ongoing part of how AI gets built for years to come.
Why We Built ZizkaDB Around This
All of this raises an obvious practical question: if the Act keeps asking for logging, traceability, human oversight, and documentation, what does that actually look like in your stack? This is exactly the question that led me to build ZizkaDB. I didn’t want to build another memory or logging layer and then retrofit compliance onto it later, I wanted the AI Act’s requirements baked into the architecture from day one, so that builders and corporates using it are working with a system that’s compliant by design rather than by patchwork.
To be upfront about the limits of what I’m claiming here: ZizkaDB isn’t we make you compliant” in a box. No single tool can honestly promise that, and I’ve been careful to design and describe it as something that complements formal risk management and notified-body assessments, not a replacement for them. What it does instead is give you the underlying evidence layer that a lot of the Act’s obligations quietly depend on:
Logging and traceability (Articles 12 and 26(5)–(6)). ZizkaDB’s agents log every event continuously, and full sessions can be reconstructed as complete timelines. Log retention is configurable per tenant, which matters if you’re a deployer who has to demonstrate ongoing monitoring, whether you’re self-hosting or running a managed deployment.
Evidence for risk assessment and post-market monitoring (Articles 12(2), 72, and 79). This is one I find genuinely useful: a causal lineage feature (why()) alongside behavioral baselines and drift signals, which gives you something concrete to point to when you’re investigating an incident or feeding a post-market monitoring process, instead of reconstructing what happened from scattered logs after the fact.
Transparency for deployers (Article 13). Dashboards, APIs, SDKs, semantic search, and point-in-time retrieval (at()) mean agent behavior stays inspectable rather than locked inside an opaque, vendor-managed memory store — which is exactly the kind of black-box problem Article 13 is trying to prevent.
Human oversight (Articles 14 and 26). Operators can inspect full action chains, reconstruct system state at any point in time, spot behavioral drift, and intervene based on actual evidence rather than screenshots or manual notes, which is a meaningfully different starting point than trying to bolt oversight on after an incident.
Technical documentation and conformity evidence (Article 11, and Articles 8–9 and 17). The logged histories become auditable evidence you can hand to your compliance or legal team to support technical documentation, without ZizkaDB pretending to be the risk management system or conformity assessment itself.
Accuracy, robustness, and cybersecurity (Article 15). Tenant isolation, scoped API keys, tamper-evident event checksums, and self-hosted or VPC deployment options all strengthen the operational integrity side of the system, which is a real and often underweighted part of Article 15.
Personal data alongside the AI Act (GDPR). Because none of this exists in a vacuum separate from data protection law, ZizkaDB is operated by an EU entity with a published privacy policy, supports forget() erasure across events and vectors, offers marketing opt-out controls, and gives you self-hosting options if data residency is a requirement for your organization.
Want to use ZizkaDB? its opensource and you can download from here :https://github.com/Zizka-ai/ZizkaDB
Interested in Cloud version? it also offers 1 month free trial: https://db.zizka.ai
Press enter or click to view image in full size
ZizkaDB — EU AI Act Compliant
I’ll be direct about the caveat here: this article mapping is meant as a starting point for a conversation with your legal team, not an exhaustive compliance checklist, and ZizkaDB says as much itself. But given how much of the AI Act, from Article 12’s logging duties to Article 79’s monitoring obligations, really comes down to “can you show your work,” having a system that’s built to keep that evidence trail intact by default feels like a genuinely sensible foundation rather than a marketing flourish. If you’re a builder trying to figure out where to start turning the Act’s abstract obligations into actual infrastructure, this is the kind of tool I’d want sitting underneath my stack.
Note : This article is originally published in Medium can be tracked here :https://medium.com/@MirArshadTalpur/eu-ai-act-second-big-blow-or-a-move-toward-sanity-3dea3586dbf3
Top comments (1)
the point that the act is a rolling framework is useful. for a practical implementation, i would map each claimed obligation to a control, an owner, an evidence record, and a review date. keep the legal source and version next to the mapping, because guidance and deadlines can change. that makes the system useful to a legal review without turning a logging tool into a compliance promise.