DEV Community: Mir Arshad Ali Talpur

Cloud Hosting Is the Data Hostage Model, and It Has No Place in the AI Era

Mir Arshad Ali Talpur — Fri, 11 Sep 2026 13:41:08 +0000

The thesis, stated plainly: cloud hosting did not just happen to make customer data hard to leave with. The architecture was built around continuous delivery and operational convenience, and one of its natural side effects was that data became hard to move. That side effect quietly became part of the retention story, whether or not any individual vendor set out to build it that way. I call this the Data Hostage Model, not as an accusation against any one company, but as a description of what the architecture structurally produces. It worked well for two decades. I don’t think it is the right foundation for the AI era, and this piece explains why, in three stages. First, why the model won the Application Era and where its logic starts to strain. Second, why AI agent operational data is a category of information that shouldn’t be built on that logic in the first place. Third, why VPC deployment and licensing, not data leverage, are the more durable way forward, and why that is the direction we are building ZizkaDB at Zizka AI.

Part One: Understanding the Data Hostage Model, Not Just Naming It
A disagreement worth having in public
A while back I asked the CEO of Aiven a direct question: what’s the actual path forward for open source companies to monetize? His answer, in essence, was that cloud hosting eventually wins. However you start, the managed-cloud model is where sustainable open source businesses end up.

I think he’s largely right about what happens in practice, and I respect the case. Aiven has built a genuinely large business on a real premise: take strong open-source data infrastructure, run it so customers don’t have to, and get paid for the operational burden you take off their plate. By their own account, a meaningful part of why customers stay isn’t the software itself, it’s the trust built up over years of handling security, patching, and uptime reliably. That’s a legitimate insight, and it has earned real revenue and real customer goodwill.

I don’t disagree with the diagnosis. I disagree that this is the model to build the next decade on. And I think the AI era is exactly when that disagreement starts to matter in practice, not just in principle.

How the model actually works
Here is the mechanic worth naming plainly, without dressing it up and without overstating it either. The code is free, so nobody pays for the software directly. What gets sold instead is operational convenience: someone else runs it, patches it, keeps it online. To deliver that convenience, the vendor has to hold the data. And once the data is sitting inside someone else’s infrastructure, wired into someone else’s dashboards and backup systems, leaving stops being a quick decision. It becomes a migration project.

That gap between deciding to leave and actually being able to leave is not necessarily a deliberate trap. Most vendors building this way are optimizing for reliability and product velocity, not for lock-in as an end in itself. But the gap is real, and it functions as retention whether or not anyone intended it to. A customer who stays because switching would take months of engineering time and a customer who stays because the product earns it every quarter look identical on a retention chart. The Data Hostage Model, as an architecture, doesn’t distinguish between those two customers. That’s the part worth being honest about.

This worked well, and reasonably, for most application data, because the tradeoff was worth it. A production Postgres cluster or a Kafka pipeline isn’t usually sensitive in a way that makes centralized hosting feel risky. The value was real operational convenience, and the cost was a manageable amount of trust extended to a vendor with every incentive to keep that trust intact.

What the arrangement depends on, though, is trust standing in for verification. You trust the vendor is patching on schedule. You trust they aren’t looking at your data. You trust their security posture. You don’t independently verify most of it, you take their word, backed by their reputation and their SLA. That was a reasonable trade for the Application Era. I think it gets harder to justify once the data in question is no longer just sitting there.

Why AI agents change the calculus
Here’s the shift: AI agents don’t just store your data, they act on it, autonomously, in production, making decisions that have real consequences. Approving a refund, calling a tool, escalating a support ticket, taking an action on someone’s behalf. When something goes wrong, the question isn’t just whether the data was secure. It’s whether you can see, step by step, why the agent did what it did, and explain that to a regulator, an auditor, or a customer who was affected.

That’s a materially different requirement than uptime and patching. It’s evidentiary, not just operational. And evidentiary needs are hard to satisfy through a trust relationship alone. They’re better satisfied by being able to inspect the chain yourself, on your own infrastructure, without waiting on a vendor’s support queue at the exact moment you need an answer.

This isn’t a hypothetical concern. Regulation is already moving in this direction. The EU AI Act is pushing toward exactly this kind of demand: agent behavior needs to be explainable and auditable, not just monitored by whoever happens to be hosting it. An answer like the AI just made a mistake is becoming less acceptable, in a legal sense as much as a product sense.

It’s not only regulation. It’s the practical reality that the operational logs of an AI agent, the decisions, the tool calls, the causal chain of why something happened, are often more sensitive than the application data sitting next to them, because they reveal how your system reasons, what it has access to, and where it can go wrong. Centralizing that inside a third party’s cloud is a bigger ask than centralizing a database backup ever was, and it’s worth treating it as a genuinely different category rather than assuming the old model still applies.

Even Aiven has visibly moved in this direction itself, offering deployment directly into a customer’s own cloud account for data residency and private networking. I read that as a useful signal: when a company whose business is built on centralized hosting starts building a path for customers to keep infrastructure in their own account, it suggests the market is already asking for more control than the original model assumed it would want.

The reframe: from control to verification
Here’s the reframe at the center of this piece. In the Application Era, the thing that mattered most was control: control over infrastructure, control over reliability, control over how convenient it was to stay. Trust was largely a story built on top of that control, earned by vendors who exercised it responsibly over time.

In the AI era, I think the thing that matters most shifts toward verification: not just trusting that data is handled responsibly, but being able to check, directly, on infrastructure you own, without needing to take anyone’s word for it. That’s a more durable form of trust, because it doesn’t depend on a vendor’s continued good behavior. It’s trust that holds up on its own.

This is the direction we’re building in at Zizka AI. ZizkaDB exists to answer the question an AI agent’s operators need answered under pressure: why did the agent do that, what did it know when it acted, has its behavior drifted. We believe that answer needs to be verifiable on infrastructure the customer controls, not something requested from a vendor’s dashboard after the fact. That’s why the product is open source under AGPL from the start, with self-hosting as a first-class option rather than an enterprise add-on.

To be clear, this isn’t a claim that cloud-hosted vendors are acting in bad faith, or that Aiven’s approach is wrong for the problems it was built to solve. It’s an argument that the category of data involved in AI agent operations, more sensitive, more regulated, more consequential when something breaks, deserves a different default than the one the Application Era settled on.

Cloud hosting won the last era on a genuine insight about trust. The rest of this piece is about what trust needs to look like when the systems being trusted are the ones making decisions.

Part Two: Why Agent Operational Data Deserves a Different Default
The assumption worth questioning
Here’s an assumption that sounds reasonable and, I think, doesn’t hold up well under scrutiny: an AI agent’s logs are just another kind of data, so they can be hosted the same way any other database has always been hosted.

That assumption applies the Application Era’s default to a new category of information without checking whether the category actually fits. It fits reasonably well for rows in a customer table. It fits for a Kafka topic full of order events. It fits less well for the record of why an autonomous system decided to do what it did, and the difference is worth taking seriously.

What agent operational data actually is
Application data is mostly inert until something queries it. A row in a Postgres table sits there. It doesn’t reveal how your business reasons, only what it recorded. If a vendor holds it and something goes wrong, you’ve lost some convenience, not much else.

Agent operational data is different in kind. It’s the trace of a decision process: what the agent knew at the moment it acted, which tool it called and why, what context shaped that choice, how the outcome might have differed if one earlier step had gone differently. It’s the reasoning of a system standing in for a human making judgment calls. That distinction matters, because it means agent operational data carries three properties application data usually doesn’t.

First, it’s diagnostic of failure. When an agent makes a bad call, the operational record is often the only way to understand what actually happened. Losing easy access to that record costs more than convenience, it costs your ability to explain yourself when it matters most.

Second, it reveals business logic. A causal chain showing how an agent decided to approve a refund, or escalate a ticket, or skip a policy check, is close to a readable trace of your internal decision rules, more like source code than a customer record.

Third, it’s often legally significant in a way most application data isn’t. Under emerging regulation like the EU AI Act, being able to explain and audit an autonomous decision is close to a requirement, not a nice-to-have. That turns agent operational data from a debugging convenience into something you may need to produce, under time pressure, to a regulator or an affected customer.

None of these three properties apply cleanly to a typical managed database workload. All three apply directly to what an agent observability and audit layer holds. Treating them the same by default is where the model starts to strain.

A conflict of interest worth naming
There’s a second issue underneath the first, and it’s less about sensitivity and more about incentives. Many observability tools for AI agents, cloud-hosted by design, aggregate data across customers to improve their own product, benchmark performance, and inform future features. That’s a normal part of how SaaS businesses grow, not evidence of bad intent. But it does create a structural tension worth naming: the party holding the record of your agent’s failures is often the same party whose product improves by learning from failures across its entire customer base.

Even with good contracts and good intentions, that’s an arrangement customers can’t fully verify from the outside. Nobody worries much that a hosted Postgres backup is teaching a vendor about their business. It’s reasonable to think more carefully about that when the data in question is the causal record of how your AI agents make decisions, since that record is more revealing, and more valuable to more parties, than a typical backup.

The verification problem
There’s a third issue that I think gets the least attention. If the reason you need agent operational visibility in the first place is that the agent’s own reasoning isn’t fully transparent, then the system you use to audit that agent should ideally not be another layer you have to take on faith. If your audit layer is itself a closed, cloud-hosted service, you’ve moved the transparency problem up one level instead of resolving it. It becomes harder to independently confirm that logging is complete, that nothing was dropped, that the causal chain you’re shown is the full and accurate one.

Many tools in this space, including well-regarded ones built around span-based tracing, are genuinely useful for performance debugging but weren’t designed to solve this specific problem: proving, independently, on infrastructure you control, that a causal chain is complete and unaltered. Explicit causal lineage, the ability to trace backward from an outcome to the exact decision that produced it, is a stricter requirement than watching a trace of spans in a dashboard, and it holds up best when nobody else needs to be trusted to have captured it faithfully.

Where this points
Put these three factors together, evidentiary weight, a real conflict of interest, and the verification problem, and the conclusion isn’t that cloud hosting is unusable for agent operational data. It’s that defaulting to the same architecture used for application data, without adjusting for what this data actually is, is a mismatch worth correcting. What matters most here isn’t a vendor’s assurances. It’s the customer’s own ability to verify, on their own terms, at the exact moment something has already gone wrong.

This is why, at Zizka AI, ZizkaDB wasn’t designed as a cloud-first product with self-hosting added later as an afterthought. It was built the other way around: self-hosting under an open license as the default, with managed cloud offered as a convenience for teams who want it, not as the direction the architecture quietly steers everyone toward. The causal lineage, the explicit decision chains, the drift baselines, all of it is designed to be inspected on infrastructure the customer actually owns, because that’s the version of this that holds up once the stakes are taken seriously.

The Application Era’s model was built for data that mostly just sits there. Agent operational data doesn’t just sit there, it explains and, when needed, testifies. That difference is enough, on its own, to justify a different default for where it lives.

Part Three: The Case for VPC Deployment and Licensing
Naming the actual choice
Every company building AI agent infrastructure eventually has to answer one question honestly, whether or not it shows up in the marketing: does the business get stronger when it’s harder for a customer to leave with their data, or does it get stronger some other way. Most architecture decisions end up answering this question implicitly, whether the founders intended to or not.

Much of the software industry’s last two decades leaned toward the first answer, often without anyone deliberately choosing it. Retention got built, in part, by making data portability inconvenient, not solely by making the product good enough that leaving would feel like a loss. That’s the pattern I’ve been calling the Data Hostage Model throughout this piece. It’s not a claim that any individual vendor set out to trap customers. It’s an observation that a business whose retention depends partly on data being hard to move has a quiet, structural incentive to keep it that way, regardless of intent.

This section makes the case for the second answer, as an actual architecture and an actual pricing model, not just a values statement.

Why VPC deployment is more than a compliance feature
VPC deployment, running the software inside infrastructure the customer owns and controls, tends to get framed as a compliance checkbox. Data residency, sure. Something for the security review, sure. That framing understates what it actually does.

Deploying inside a customer’s own VPC changes who’s structurally capable of what. It removes the vendor’s role as the single point of access to the most sensitive data the system produces, because there’s no centralized copy to protect or misuse. It reduces how much a customer has to trust a vendor’s internal access controls, since there’s no vendor-side copy for those controls to govern. And it directly addresses the conflict of interest and verification problems described earlier, because there’s nothing aggregated across customers to learn from, and nothing standing between the customer and their own evidence.

For AI agents specifically, this matters even more. If the causal record of your agent’s decisions lives inside your own infrastructure, inspectable directly, you don’t need anyone to vouch for its completeness. You can verify it yourself, exactly when a regulator, a customer, or your own team needs an answer. That’s a different kind of confidence than an uptime guarantee, and it’s closer to what the AI era actually requires.

This is why VPC deployment sits at the center of how we think about ZizkaDB, not as an enterprise tier layered on top of a cloud-first product, but as the default posture the system is designed around from the start. Self-hosting under an open license, with managed cloud available for teams who prefer the convenience.

Why the current playbook is hard to walk away from
It’s worth being honest about the tension here rather than glossing over it. The dominant open-source monetization model, hosting the code in the cloud and charging for the operational burden taken off a customer’s hands, works partly because it reproduces some of the dynamics described above, usually without deliberate intent. Once a customer’s data and workloads are running in a vendor’s cloud, switching away carries real friction, and that friction is part of what makes retention numbers look strong to investors.

It’s understandable why founders build this way. It works, it’s well understood, and there’s a clear, well-validated playbook, including from people who’ve executed it very well and who genuinely believe, with good reason, that trust is a real part of why their customers stay. But it’s worth being clear-eyed that some of that retention reflects switching cost as much as product quality, and that the two are easy to conflate if you’re not looking closely.

What licensing actually charges for
If VPC deployment removes the vendor’s structural leverage over customer data, the business model has to be built around something else: the software and the expertise behind it, sold directly, rather than sold indirectly through the cost of leaving.

A license-based model charges for what a customer is genuinely getting: production-grade software, the specific engineering behind causal lineage and drift detection and reliable operation at scale, ongoing improvements, and support when something breaks. None of that requires holding the customer’s operational data as leverage. It requires the software being good enough, and the support being responsive enough, that renewing feels like an easy decision rather than a forced one.

This is a harder business to build, at least early on. Data leverage is an effective retention mechanic, and giving it up means the product and the relationship have to earn renewal on their own. I think that trade is worth making, for two reasons. First, because in a category where the underlying data is increasingly sensitive and regulated, customer tolerance for centralized control is likely to keep declining, regardless of what any individual vendor prefers. Second, because a business built on genuine product quality tends to be more durable over time than one built primarily on switching cost, even if it grows more slowly at first.

The valuation question this raises
There’s a broader implication worth mentioning, briefly, because it extends beyond any single company’s product decisions. A meaningful share of current valuations in software, and increasingly in AI infrastructure, are priced partly on the assumption that data gravity will keep customers locked in, the way it did through the social media and SaaS eras. If the AI era genuinely shifts what customers value from control toward verification, some of that valuation logic may be resting on an assumption that doesn’t hold as firmly going forward. A moat built on switching cost is only as strong as customers’ willingness to accept it, and that willingness looks like it’s declining faster for AI agent operational data than it ever did for a CRM record or a social graph.

I’m not raising this to predict a market correction or to single out any particular company. I’m raising it because it should change what founders optimize for now, while this category is still being defined, rather than later, once the market has already reassessed the difference between durable product advantages and data leverage that looked like one for a while.

Where this leaves the argument
The first part of this piece described the Data Hostage Model for what it is: an architecture that produces retention partly through switching cost, often without anyone deliberately designing it that way, and asked whether that’s the right foundation to keep building on. The second part argued that AI agent operational data is a category of information poorly suited to that model, given its evidentiary weight, the conflicts of interest it creates, and the verification problem it raises. This final part has made the case for what follows from both: VPC deployment as the architecture, because it removes structural leverage rather than just asking customers to trust that it won’t be misused, and licensing as the business model, because it charges for what’s actually valuable, the software and the expertise behind it, rather than for the inconvenience of leaving.

This is the direction we’re building ZizkaDB in at Zizka AI. It’s likely a slower path to revenue than the alternative. I think it’s the more honest one, and the one more likely to hold up as the systems being trusted are increasingly the ones making the decisions.

The Article is originally published in medium and can be accessed via this link : https://medium.com/@MirArshadTalpur/cloud-hosting-is-the-data-hostage-model-and-it-has-no-place-in-the-ai-era-6d3fc8f26dd3?postPublishedType=initial

Causal Lineage, Session Replay, and the Missing Layer in Enterprise AI

Mir Arshad Ali Talpur — Tue, 08 Sep 2026 11:21:31 +0000

Why the next wave of AI adoption in Europe depends on infrastructure that can explain itself

Zizka DB — EU AI Adoption
For the last two years, the conversation around enterprise AI has been dominated by capability. Bigger models, longer context windows, more agentic workflows. What has lagged behind is a much less glamorous but far more consequential category: the infrastructure that lets a business actually understand what its AI systems did and why. In Europe in particular, that gap is not a nice to have. It is the reason pilots stall before they reach production.

This is the problem ZizkaDB was built to solve, and it is worth walking through why each of its core capabilities, causal lineage, session replay, and drift detection, maps so directly onto what European enterprises need before they will trust an AI system with anything that matters.

The limits of a trace
Most observability tools for AI agents give you a trace. A trace is a record of events: a call went out, a response came back, latency was this many milliseconds, tokens cost this much. That is useful for debugging performance problems. It is close to useless for answering the question that actually matters after something goes wrong: why did the agent decide to do this particular thing, at this particular moment, given what it knew.

A trace shows you the sequence. It does not show you the reasoning chain, the state the agent was actually operating on, or how one decision fed into the next. When a customer gets the wrong answer, or a compliance officer asks how a specific output was produced, a pile of spans does not answer that. Someone has to reconstruct the story by hand, usually under time pressure, usually without confidence that the reconstruction is even accurate.

Causal lineage: from what happened to why it happened
This is the core idea behind causal lineage, and it is the feature that separates ZizkaDB from a conventional tracing tool. Instead of storing flat, disconnected events, ZizkaDB links each decision an agent makes back to the specific inputs, tool calls, and prior state that produced it. Every event carries a parent, so you can walk backward through an agent’s behavior the same way you would walk backward through a chain of custody.

For a European enterprise, this is not an engineering convenience. It is closer to a legal requirement in spirit, even where it is not yet one in letter. Under frameworks like the EU AI Act and existing sector rules in finance and healthcare, organizations are expected to be able to explain automated decisions, not just log that they happened. Causal lineage turns explainability from a manual, after the fact investigation into something the system produces as a byproduct of normal operation. When a regulator or an internal auditor asks how a decision was reached, the answer already exists. Nobody has to reconstruct it from memory or guesswork.

Session replay: turning an incident into evidence
The second piece is session replay, and its value becomes obvious the moment something goes wrong in production. Without it, an incident review usually looks the same way everywhere: a user reports a bad answer, someone pulls up logs that show fragments of activity, and the team spends hours trying to piece together what the agent actually knew at the time it acted. Often the honest conclusion is that nobody can say for certain.

Session replay removes that uncertainty. It lets a team reconstruct an agent’s session end to end and see exactly what the agent had access to, what it retrieved, and what path it took to its final output. That is the difference between saying we believe this is what happened and saying here is exactly what happened, and here is the evidence.

For enterprises operating under audit obligations, this is the raw material that compliance is actually built from. An audit trail is not a dashboard. It is a reconstructable record that can be handed to a third party and stand on its own. Session replay is what makes that possible for AI systems in the same way transaction logs make it possible for financial systems.

Drift detection: an honest response to a probabilistic technology
The third capability addresses a problem that is more cultural than technical. A lot of AI vendors, particularly in vertical markets like legal and insurance, have tried to win over cautious European buyers by promising consistency: the system will always behave this way, the accuracy is guaranteed. That promise does not hold up, because the underlying models are probabilistic. Behavior shifts when a prompt changes, when a model is upgraded, when the data the agent is retrieving changes shape.

ZizkaDB does not try to paper over that reality. Its drift detection continuously compares current agent behavior against an established baseline and flags meaningful shifts, so a change in behavior is caught and documented rather than discovered by a customer weeks later. This is a more honest position than promising determinism, and it is also a more useful one. It gives a business the ability to say, with evidence, that it monitors for behavioral change and responds to it, which is a far stronger compliance posture than a marketing claim of guaranteed accuracy that nobody can actually back up.

Why self-hosting matters as much as the features
There is one more piece that is easy to overlook if you are only thinking about features: deployment model. ZizkaDB is available as a fully open source, self-hosted stack, not only as a managed cloud product. For a European enterprise, this matters for reasons that have nothing to do with cost. It means audit trails, decision lineage, and session data can live entirely inside the organization’s own infrastructure, under its own data residency and access controls, rather than inside a third party’s cloud in a jurisdiction the compliance team has to separately evaluate.

Combined with causal lineage and session replay, this turns ZizkaDB into something closer to a compliance foundation than a debugging tool. The enterprise keeps full control of the evidence its AI systems generate, which is precisely the condition European regulators and internal governance teams have been asking for.

The real barrier was never AI itself
None of this is really about making AI smarter. It is about making AI systems accountable in a way that matches how European institutions already operate. Enterprises here are not rejecting AI because they doubt its usefulness. They are withholding trust from systems that cannot explain themselves, cannot be reconstructed after the fact, and cannot demonstrate that someone is watching for when their behavior changes.

Causal lineage answers why a decision was made. Session replay proves what actually happened. Drift detection shows that behavior is being watched honestly rather than promised away. Together, these are not add on features. They are the missing layer that turns an AI pilot into something a European enterprise can actually put its name behind.

That is the layer ZizkaDB is building. And it is likely to be the layer that determines which AI vendors actually succeed in this market, and which ones stay stuck in procurement.

If your team is running production agents and cannot yet answer the question why did it do that, that gap is worth closing before the next incident forces the question.

The article is originally published in Medium and can be viewed here:https://medium.com/@MirArshadTalpur/causal-lineage-session-replay-and-the-missing-layer-in-enterprise-ai-c1ba194f4f09?postPublishedType=initial

Europe Doesn’t Have an AI Problem. It Has a Trust Problem.

Mir Arshad Ali Talpur — Wed, 02 Sep 2026 15:01:36 +0000

Europe has no shortage of AI talent, research output, or ambition. What it has struggled with is turning pilots into production. While American and Asian enterprises push agentic AI into core workflows, European boards keep AI projects in a permanent proof-of-concept holding pattern. The irony is that the regulation many blame for this, the EU AI Act, may end up being the thing that finally gives European enterprises the confidence to industrialize AI at scale. This is also the bet a young infrastructure company, Zizka AI, is making with its product ZizkaDB.

Why Enterprise AI Adoption Has Been Slow in the EU
The gap isn’t a lack of appetite. Surveys show the opposite: the majority of CEOs list accelerating AI among their top three priorities, and most large organizations already use AI in at least one business function. The blockage sits between experimentation and deployment, and it comes down to a handful of compounding factors.

Regulatory uncertainty, not regulation itself, is the real drag. The AI Act has been amended repeatedly over the past two years, most recently through the Digital Omnibus on AI, which pushed back high-risk compliance deadlines and reshaped documentation and conformity-assessment requirements. Formal political agreement was reached in May 2026, endorsed by Parliament in June, and the Omnibus entered into force in July 2026, but businesses were told throughout that the August 2026 deadline remained legally live until publication. For a legal and compliance team, that kind of moving target is worse than a strict rule: it’s very hard to build a governance program against a deadline that keeps shifting underneath you.

Compliance is perceived as a cost center, not infrastructure. Legal teams see documentation, conformity assessments, and registration obligations; engineering teams see a checklist bolted onto a system that was never built to be inspected. Most agent stacks generate logs, not evidence. When something goes wrong, a chatbot gives a wrong refund policy, an agent skips a required approval step, teams can see that it happened but not why, which is precisely the kind of causal explanation regulators, auditors, and increasingly customers expect.

Fragmentation across 27 member states adds friction on top of the EU-level rules. Even as Brussels tries to harmonize standards, national implementation, sectoral overlaps (like the Machinery Regulation), and inconsistent guidance from standardization bodies have left many enterprises unsure which rulebook applies to their specific use case, especially for anything touching finance, health, energy, or HR.

Risk aversion is rational, not just cultural. EY has found that most C-suite leaders now rank AI regulatory non-compliance as their top AI-related risk, ahead of cost or performance concerns. In a market where a poorly governed AI system can trigger real penalties, waiting and watching is often the economically sensible move, even if it’s strategically costly.

Put together: European enterprises aren’t AI-skeptical. They’re evidence-poor. They lack the operational tooling to prove, to a regulator or to themselves, what their AI systems actually did and why.

How the AI Act Could Actually Industrialize AI, Not Just Constrain It
It’s easy to read the AI Act purely as a brake. But regulation has industrialized entire sectors before by doing something enterprises can’t do for themselves: creating a common, enforceable definition of trustworthiness. Pharmaceutical manufacturing didn’t scale despite GMP standards, it scaled because of them, since a shared bar of evidence let hospitals, insurers, and regulators trust products from companies they’d never audited directly.

The AI Act is starting to play a similar role, and the recent Omnibus amendments push it further in that direction rather than away from it:

Longer, staged runways for high-risk systems (with separate fixed deadlines for different high-risk categories) give enterprises time to build governance as real infrastructure instead of a rushed compliance sprint.
Expanded regulatory sandboxes, including an EU-level sandbox, let companies test AI systems, including agentic ones, in supervised real-world conditions rather than guessing at what compliant looks like.
Simplified obligations extended from SMEs to small mid-caps widen the on-ramp beyond just the largest players, which matters because Europe’s AI economy is disproportionately mid-market.
A single horizontal framework, however imperfect in its rollout, is still a more industrializable target than 27 divergent national approaches. It’s the difference between building one audit pipeline and building twenty-seven.
The common thread across almost every one of these provisions, transparency, human oversight, technical documentation, post-market monitoring, is that they all reduce to the same underlying requirement: an enterprise has to be able to reconstruct and explain what its AI system did. That’s not a legal nicety. It’s an engineering problem. And it’s the same problem that separates AI demos from AI that a bank, hospital, or logistics operator can actually run in production.

Where ZizkaDB Comes In
This is the layer Zizka AI is building for with ZizkaDB, an open-source (AGPL-3.0) and managed-cloud operational database purpose-built for production AI agents. Rather than treating logging as an afterthought bolted onto an agent framework, ZizkaDB is designed around the questions the AI Act effectively forces every deployer to answer:

Causal lineage, not just logs. ZizkaDB records each agent step with an explicit parent-child chain, so a team can call a why() query and walk backward from a bad outcome, a wrong answer, a skipped policy check, to the exact user message, tool call, or context state that caused it. That’s the difference between having logs somewhere and being able to produce, on demand, the decision trail an auditor or regulator would ask for.
Time-travel state snapshots. Instead of only knowing an agent misbehaved, teams can isolate the exact context window the agent was working from at that moment, which is essential for diagnosing drift after a prompt or model change, one of the more common failure modes in production agent fleets.
Drift baselines and behavioral alerts. ZizkaDB compares live agent behavior against a baseline and flags regressions, giving teams a way to catch a silently-changed system before customers do, directly supporting the kind of post-market monitoring the AI Act expects from providers and deployers of higher-risk systems.
Human-in-the-loop interception points, so governance can trigger before a risky action executes rather than being reconstructed afterward from a postmortem.
Deployment flexibility that matches EU procurement realities. Self-hosted open source for organizations that need data sovereignty, or managed cloud for teams that want to move faster, matters in a region where data residency and sovereignty concerns are their own adoption blocker, separate from the AI Act itself.
None of this is marketed as AI Act compliance software, and it shouldn’t be reduced to that. It’s infrastructure for making agents debuggable and reliable, full stop. But the overlap with what the Act increasingly demands is not a coincidence. As Zizka AI’s own team has put it, the industry has spent enormous engineering effort trying to force fundamentally probabilistic models to behave like deterministic APIs. That effort is largely wasted; models will keep drifting as weights update and context accumulates. The more tractable goal is what they call constrained reliability through auditability: accepting that AI systems are probabilistic, and building the operational tooling to observe, explain, and govern them anyway.

The Bigger Picture
Regulation and industrialization aren’t opposites, they’ve historically been sequential. The AI Act’s early years looked chaotic because Europe was trying to write the rulebook and build the technology at the same time, with each amendment cycle adding uncertainty rather than removing it. But as the framework stabilizes, longer timelines, clearer sandboxes, harmonized obligations, the enterprises that win won’t be the ones that lobbied hardest against it. They’ll be the ones that already built the operational plumbing to answer why their AI did what it did before anyone asked.

That’s the bet behind tools like ZizkaDB: that in Europe, the fastest path to enterprise-scale AI isn’t around the AI Act, but through it, with an audit trail as the foundation, not an afterthought.

This article reflects the regulatory landscape as of early September 2026. The AI Act’s implementation timeline continues to evolve; readers should confirm current deadlines via the European Commission’s AI Act Service Desk before making compliance decisions.

The article is originally published in medium and can be accessed via this link :https://medium.com/@MirArshadTalpur/europe-doesnt-have-an-ai-problem-it-has-a-trust-problem-c0ee81ad7bef

Open Source Isn't a Business Model Choice Anymore. It's the Only Option.

Mir Arshad Ali Talpur — Sat, 29 Aug 2026 13:35:57 +0000

A few weeks ago, on the sidelines of an event at La Felicita (Station F), I got into a conversation with the CEO of Aiven about open-source business models. His take was clear and, frankly, well-earned: the managed cloud is the correct way to monetize open source. Let the community build the moat, put a hosted layer on top, and sell the operational convenience.

He's not wrong. That model has minted real companies. But I think it's already starting to look like the previous era's answer to a question the AI era isn't asking anymore.

The moat that keeps collapsing

Here's the pattern, and it's not subtle if you look at it in sequence.

MongoDB relicensed its server from AGPL to the Server Side Public License in October 2018, a little over a year after going public. The trigger was AWS DocumentDB, a compatible managed service competing directly with MongoDB's own cloud offering. Debian, Red Hat, and Fedora dropped the package, and by 2021 the Open Source Initiative had gone on record saying SSPL doesn't actually meet the Open Source Definition.

Elastic followed in January 2021, dual-licensing under SSPL and its own Elastic License, again in direct response to AWS launching a competing managed service, this time OpenSearch, forked straight from the codebase Elastic had just locked down.

HashiCorp was next, moving Terraform and its other tools from MPL 2.0 to the Business Source License in August 2023. The company framed the move as protecting continued investment in the community while keeping the products freely available, but the practical effect was the same: commercial competitors got restricted, and the community forked Terraform into OpenTofu almost immediately. Eighteen months later, HashiCorp itself was acquired by IBM and stopped being an independent company.

Redis did the same dance in 2024.

Four different companies, four different boardrooms, the same move, the same trigger every time: a hyperscaler builds a managed version of your open project, captures the revenue you were counting on, and you respond by taking rights away from your own community.

The part everyone skips over

What's more interesting than the relicensing itself is what happened next. In August 2024, Elastic added AGPLv3 back alongside SSPL, specifically so Elasticsearch could be called open source again. Redis did the same thing in May 2025, adding AGPLv3 as an option starting with Redis 8. Two of the four companies that walked away from open licensing walked straight back to it within two years. No clear evidence has emerged that the license changes actually improved revenue for any of them, and the one company that never reversed course, HashiCorp, is the one that no longer exists as an independent company.

That's the tell. The open-core bet wasn't really that open source doesn't work as a business model. It was that these companies were worried a bigger company would out-execute them on hosting. And when the fear turned out to be manageable, or the acquisition happened anyway, the license restriction had bought nothing but community backlash and a permanent asterisk next to the company's name.

Why we're not making that bet with ZizkaDB

We built ZizkaDB under AGPLv3 from day one, and our primary deployment model is VPC-based: we run the software inside the enterprise's own cloud, not ours. No managed multi-tenant layer holding customer data as the thing that makes us sticky.

I know the standard objection. If you don't control the data, how do you build a moat? The prevailing wisdom in AI right now is almost the inverse of the open-source-cloud thesis: the more data flows through you, the stronger you get. Every relicensing decision above was, underneath the legal language, an attempt to protect a moat built on being the only place your data could go.

I think that's precisely the wrong instinct for AI infrastructure, and Europe is where you can see why fastest. The EU AI Act is pushing enterprises toward auditability, data residency, and the ability to actually explain what a system does with their information. A vendor whose pitch is trust us with your data and trust our binary is fighting the regulatory current, not riding it. A vendor whose infrastructure runs inside the customer's own environment, in the open, isn't just compliant. It's the more honest sell.

There's also a simpler, less philosophical reason. The moment your differentiation depends on customers being unable to leave, you've told them exactly what you think your product is worth without the lock-in. Every company on that relicensing list eventually discovered that a locked license didn't stop AWS, didn't stop the fork, and didn't stop the acquisition. It just spent the trust of the community that had built the product's early value in the first place.

Radical transparency as the actual moat

So here's the bet we're making instead: in an AI infrastructure market that's about to be flooded with vendors asking enterprises to hand over their data for the privilege of using AI, the company that says run this yourself, inspect the code, keep your data where it already lives has a moat that doesn't depend on legal restriction at all. It depends on being genuinely good enough that customers choose to stay, and on being positioned exactly where regulation is heading rather than one license change behind it.

We'll keep evolving how we protect ZizkaDB's IP. That's a legitimate business need, not something I'm waving away. But the mechanism for capturing value can't be that the customer's data is the leash. That's not a technology decision. It's a bet on what enterprises will tolerate in a market where the alternative, genuine data control, is now actually on the table.

The AI era needed new infrastructure. I think it needs a new answer to who gets to hold the data, too. And increasingly, open source with the data staying put isn't one option among several. It's becoming the only credible one.

Use our Open-source database here : https://github.com/Zizka-ai/ZizkaDB

Slow AI Adoption in the EU (Enterprises) and How ZizkaDB Is Solving This

Mir Arshad Ali Talpur — Mon, 24 Aug 2026 15:36:24 +0000

According to the IBM Global AI Adoption Index (research conducted by Morning Consult on behalf of IBM), the EU has the lowest AI adoption rate, at around 28%, compared to the Americas (US + LATAM) at 38%, APAC at 45%, and China at 58%. This is not merely a business question for AI companies. It carries broader nuances that need to be discussed and understood, and then solved, rather than simply blamed on the EU’s conservativeness, its supposed unwillingness to experiment, or the general pace of business in Europe.

First, we need to understand and accept that the EU represents roughly 24% of the global economy and is the largest single market with the highest combined purchasing power. Without the EU, no company can truly claim to be a global company.

In recent years, EU policymakers have been deliberately pushing for European digital sovereignty, and there is enormous enthusiasm among the population here. I sit at Station F in Paris, arguably the innovation hub of Europe, or the mini San Francisco of the EU, and here I meet many founders who are equally excited not just about AI in general, but about building native solutions for Europe. The work happening here is moving at an unprecedented pace. On top of that, governments in Germany, Spain, and France are pushing hard, the EU has opened up grant funding, and Ursula von der Leyen (President of the European Commission) has publicly floated the idea of Europe becoming the first AI continent. All of this points in one direction: the EU has the potential, the market, and the appetite for adoption.

But the most important piece of the puzzle is the EU AI Act. We all know, and many of us have mocked, the EU’s tendency to regulate new technologies. During the API-led era, this was often dismissed as unnecessary intervention. But GDPR eventually became a global standard, and today, regulation is not just necessary, it is a genuine business moat. AI cannot, and should not, be left unregulated. We cannot rely on the goodwill of a handful of people (the leaders of a few frontier model companies) to decide where the world goes next. The strongest check and balance against that is continental-scale regulation. I have zero doubt that the EU AI Act is not only a well-constructed piece of regulation, but that it will become the global gold standard for AI governance in the coming years.

Now let’s return to the actual subject of this article: why is AI adoption comparatively slower in the EU, despite everything discussed above?

Understanding the European Mindset
To answer that, one first needs to understand the mindset of the general population, because that mindset is a real reflection of how enterprises operate in any given part of the world. Europe is skeptical. Europe is calculated. Europe values sustainability. Europe prefers scientific, verifiable solutions over what often feels like probabilistic magic.

This brings me to three core problems that need to be discussed, along with their underlying causes. In the second half of this article, I’ll explain how Zizka AI, a genuinely European-native company, started in Málaga, Spain, and now being built at Station F in Paris, is trying to solve these problems.

Auditability
Frontier models are, by design, black boxes, and it’s a basic fact of machine learning that everything they produce is probabilistic. Auditability, then, is not a nice-to-have, it is a baseline requirement for enterprise adoption. American companies such as LangChain, Arize Phoenix, and others built observability solutions that served the US market well and helped those companies scale globally. But the underlying problem remains unsolved for EU markets, because observability is not the same thing as auditability. In the EU, enterprises want to know what is happening, why it is happening, how it is happening, and whether the state that produced a given outcome can be replayed and recreated. Existing observability tools were never built to provide that level of detail, and so auditability remains an open question for most AI vendors operating in Europe.
Reliability
It is basic mathematics of machine learning that LLMs are probabilistic systems, and they can never be made fully deterministic, no matter how many layers of patching are applied on top. We tried RAG (Retrieval-Augmented Generation). Then we moved on to agent memory and long-context architectures. Now companies like Google are experimenting with newer approaches to try to constrain model behavior. But the underlying reality is a scientific one: the mathematics behind LLMs cannot simply be patched away by a layer sitting on top of the model.

The recent push from Silicon Valley toward vertical AI companies, promising that a given AI product will reliably handle healthcare, legal work, or any other specific vertical, is, in my view, largely used to justify the extraordinarily high valuations placed on frontier model companies, and it is backed by exactly these kinds of unscientific patches. When challenged on this, the usual response is either that we should fear a possible dangerous future, or some version of the AGI narrative, both of which are fundamentally unscientific arguments. The EU does not operate on belief in magic. It operates on science and evidence.

Compliance This is a distinctly European problem, because in the EU, compliance is not a nice-to-have feature, it is a necessity. Some might argue this acts as a hindrance to innovation, and that’s partially true. But in the specific case of AI, compliance is actually a guarantor of sustainable, long-term growth. Under the EU AI Act, companies are legally liable for compliance, and non-compliance carries fines of up to €35 million or 7% of global annual revenue, whichever is higher.

This isn’t just a legal mandate, compliance is embedded in the DNA of European enterprises, markets, and people, and it cannot simply be bypassed with bullish arguments about speed or first-mover advantage. Unfortunately, many Silicon Valley AI companies don’t pay much attention to this reality, and on the other side of the world, the degree of state intervention and control behind Chinese AI models makes them equally suspect to European buyers, for different reasons.

The Solution: How Zizka AI Is Addressing These Problems
Having laid out the problems and their root causes, let’s move on to the solution, and specifically, how a genuinely EU-native company is trying to address each of them.

Solving Auditability Zizka AI built ZizkaDB specifically to tackle this challenge. Its creators understood that the database layer is the only place from which complete auditability of agentic workflows can actually be constructed, and they built a genuinely distinctive solution around that insight.

Beyond the general observability features that most tools offer, ZizkaDB’s standout capability is what it calls causality lineage (db.why()). This lets a user trace exactly why a given event happened. Every event in the system is tied to a parent ID and a child ID, so the full causal chain can be reconstructed, not only through query-level debugging, but also through a straightforward visualization on the dashboard, where the entire chain of events leading to a particular outcome can be inspected at a glance. You can see an example of this in the real dashboard screenshot below.

zizkadb — causal lineage
The second pillar of auditability is the ability to recreate agentic state, in other words, to replay a session and reconstruct exactly what state the agent was in at any given point in time. ZizkaDB builds this natively as well, both through a terminal-level query (db.at()) and through a dedicated dashboard visualization, shown in the screenshot below.

These auditability features, purpose-built for the realities of the EU market, make ZizkaDB a natural choice for enterprises based in Europe that are evaluating AI adoption, and they address the auditability gap in a far more rigorous and sophisticated way than existing observability tooling.

Solving Reliability Most attempts to solve this problem, largely coming out of Silicon Valley’s vertical AI companies, rely on promises, or on overconfident language in product documentation, asserting that their AI won’t create reliability issues. What’s missing is a solid, scientifically grounded methodology behind that claim.

ZizkaDB takes a different starting point: the hypothesis that agentic drift is an inherent, unavoidable part of agentic AI workflows, and therefore cannot be patched away. The only realistic approach is to measure and pre-determine the fluctuations in agentic behavior over time, what the team calls agentic drift, and then visualize that drift on a dashboard, so engineering teams can decide for themselves how much behavioral drift they’re willing to tolerate.

Rather than chasing the arguably unachievable goal of making agents fully deterministic, the approach favored by many US companies, ZizkaDB is built around the core principle of human-in-the-loop decision-making. It surfaces the data on model behavior and drift, and leaves the decision of whether and how to act on that data to the humans responsible for the system, rather than pretending the model can be made perfectly predictable on its own.

Solving Compliance As discussed above, compliance is a challenge baked into the DNA of EU companies. As a genuinely EU-native company, Zizka AI has made this a core focus area. They’ve built out complete EU AI Act compliance mapping, working through the regulation article by article, and have published a detailed page walking through exactly how ZizkaDB addresses each relevant requirement.

Zizka AI’s founder, Mir Arshad Ali Talpur, argues that in the AI era, compliance is the real moat, and the entire foundation of ZizkaDB’s product strategy rests on this EU-compliance-first approach.

Press enter or click to view image in full size

Zizkadb EU AI ACT Compliance
https://db.zizka.ai/eu-ai-act

Radical Transparency Beyond solving these three core issues, Zizka AI has gone a step further, pursuing radical transparency to build trust with an otherwise skeptical European enterprise market. The company follows an open-core model, publishing all of its code publicly on GitHub, allowing developers to inspect it, test it, and adapt it freely. However, the code is released under an AGPLv3 license, which means enterprises need a commercial license from Zizka AI to use it in a compliant way, and cloud giants like AWS or GCP cannot simply fork the codebase and offer it as their own managed service. This isn’t just a gesture toward transparency, it’s also a deliberate and sensible business strategy that protects the company’s long-term position while still keeping the core technology open and inspectable.

https://github.com/Zizka-ai/ZizkaDB

Momentum
ZizkaDB’s adoption is currently growing at roughly 25% week-over-week, an early but strong signal of the kind of hyper-adoption that suggests the product is resonating with exactly the enterprise buyers it was designed for.

Causal Lineage and Session Replay with ZizkaDB

Mir Arshad Ali Talpur — Sun, 23 Aug 2026 11:41:44 +0000

If you've shipped an LLM agent to production, you know the failure mode: a customer says the bot gave a wrong answer, you open your logs, and you see a wall of spans that tell you what happened but not why. The prompt changed three deploys ago. The agent skipped a tool call. A retrieval step pulled a stale document. Nothing in a flat trace tells you the causal chain that led to the bad output.

ZizkaDB is an open-source operational database built specifically for this problem. Instead of storing spans like a tracing tool, it stores agent decisions as a graph, where each event points to the event that caused it, plus session-level replay and drift detection against a baseline. This post walks through the two features that make it different from a generic tracing setup: causal lineage (why()) and session replay, with working code.

Why not just use a tracer?

Distributed tracing tools (Langfuse, LangSmith, Phoenix) give you a span tree: this call started, this call ended, here's the latency. That's useful for performance debugging. It's much weaker for behavioral debugging, where the question isn't how long did this take but what earlier decision caused this one. ZizkaDB models that explicitly by making every logged event optionally declare its parent_id, turning a session into a directed acyclic graph of decisions instead of a list of timestamps.

Setup

Self-hosting is one script:

bash
git clone https://github.com/Zizka-ai/ZizkaDB
cd ZizkaDB
bash scripts/quickstart.sh

This pulls the pre-built images, starts the API on localhost:8000, and opens a dashboard at localhost:3001 with no signup required for local dev. If you'd rather skip the clone entirely:

bash
curl -fsSL https://raw.githubusercontent.com/Zizka-ai/ZizkaDB/main/scripts/quickstart-remote.sh | bash

Install the Python SDK:

bash
pip install "zizkadb-sdk>=0.2.7"

The SDK is stateless by design: you pass agent, session_id, and event_id explicitly on every call rather than relying on hidden global state. That matters once you're running multiple agents or worker processes against the same store.

Logging events with parent links

Here's the core primitive. Every call to db.log() returns an event_id, and you pass that as parent_id on whatever event it caused:

python
import asyncio
from zizkadb import ZizkaDB

async def main():
async with ZizkaDB(host="http://localhost:8000") as db:
user_msg = await db.log(
agent="support-bot",
session_id="session-4821",
event="user_message",
data={"text": "How long do refunds take?"},
)

    retrieval = await db.log(
        agent="support-bot",
        session_id="session-4821",
        event="tool_call",
        data={"tool": "search_policy_docs", "query": "refund window"},
        parent_id=user_msg.event_id,
    )

    response = await db.log(
        agent="support-bot",
        session_id="session-4821",
        event="assistant_response",
        data={"text": "Refunds take 30 days."},
        parent_id=retrieval.event_id,
    )

asyncio.run(main())

Three events, two causal edges: the tool call was caused by the user message, and the response was caused by the tool call. That chain is the whole point. It's what lets you ask why the agent said this and get an actual answer instead of a timestamp-sorted guess.

Causal lineage: why()

Given any event_id, why() walks the parent chain backward and returns the decision path that produced it:

python
result = await db.why(response.event_id)
result.print()
assistant_response "Refunds take 30 days."
↑ caused by
tool_call search_policy_docs("refund window") → outdated_faq_chunk.md
↑ caused by
user_message "How long do refunds take?"

This is the difference between a span tree and a lineage graph in practice: instead of scanning a trace for the surrounding calls and inferring causation yourself, you get the causal chain directly. In the incident this is modeled on, why() on the bad response is what surfaces that search_policy_docs returned an outdated FAQ chunk instead of the current policy doc: the actual root cause, not just a tool being called.

Session replay

why() traces one decision. Session replay reconstructs the entire session: every message, tool call, and response in order, with the state the agent had at each point.

python
session = await db.replay(agent="support-bot", session_id="session-4821")

for event in session.events:
print(f"{event.timestamp} {event.event} {event.data}")
14:01:58 session_start {}
14:02:09 user_message {"text": "How long do refunds take?"}
14:02:11 tool_call {"tool": "search_policy_docs", "result": "outdated_faq_chunk.md"}
14:02:12 assistant_response {"text": "Refunds take 30 days."}

The dashboard renders this same data as a timeline you can step through, which is where it's genuinely faster than grepping logs: you see exactly what the agent knew, including which documents it retrieved and which tool results it had, at the moment it generated the wrong answer. That's time travel over logged state rather than replaying UI interactions the way session-replay tools for web apps do; here the format is per-event input/output data.

Catching it before a customer does: drift baselines

Lineage and replay are for root-causing an incident you already know about. baseline() is for catching the regression before that. Once you have enough sessions logged, you snapshot known-good behavior and compare new sessions against it:

python
baseline = await db.baseline(agent="support-bot", label="pre-prompt-v2")

after deploying a new prompt version

drift = await db.check_drift(agent="support-bot", against="pre-prompt-v2")

if drift.flagged:
for change in drift.changes:
print(f"Drift on {change.topic}: {change.summary}")

In the ZizkaDB docs' worked example, this is exactly what flags the refund-policy regression: check_drift reports that refund answers changed shape after the prompt v2 deploy, pointing you at why() for the specific session before a customer files a ticket.

REST, if you're not in Python or TS

Everything above also has a plain REST API, useful if your agent runtime isn't Python or TypeScript:

bash
curl -s -H "Authorization: Bearer zizkadb_dev_local" \
-H "Content-Type: application/json" \
-d '{
"agent": "support-bot",
"session_id": "session-4821",
"event": "tool_call",
"data": {"tool": "search_policy_docs"},
"parent_id": "evt_9f2a"
}' \
http://localhost:8000/v1/events

Swagger docs are served at http://localhost:8000/swagger on self-hosted instances. There's also first-party support for LangChain (ZizkaDBCallbackHandler), CrewAI (ZizkaDBCrewLogger), and an MCP server for Cursor/Claude Desktop if you want lineage and replay available as tools inside your editor rather than only in the dashboard.

Where this fits

If you already have a tracer for latency and cost, you probably don't need to rip it out. What ZizkaDB is solving is a narrower, sharper problem: when an agent's behavior is wrong, not just slow, why() and session replay get you from customer complaint to root cause without reading logs. The parent_id graph is the whole mechanism, and it's simple enough to bolt onto an existing agent in an afternoon: three extra db.log() calls in the example above is most of the integration work.

Repo: ZizkaDB (AGPL, self-host free). Managed cloud with a hosted dashboard is at db.zizka.ai if you'd rather not run Docker.

Vertical AI Founders, You Are Going Through 3 Existential Crises (And Most of You Don’t Know It Yet)

Mir Arshad Ali Talpur — Fri, 21 Aug 2026 12:46:23 +0000

If you’re building a vertical AI company or shipping AI agents for a living, you’ve probably felt it. That low hum of unease underneath the demo-day highs and the “we just closed our first enterprise pilot” LinkedIn posts.

You should trust that feeling. It’s not imposter syndrome. It’s your business model telling you something true.

Here are the three crises every vertical AI founder is quietly sitting on right now, and why pretending they don’t exist is the riskiest move you can make.

You’re Building on Someone Else’s Land Strip away the branding, the onboarding flow, and the pitch deck, and what do you actually have?

A product powered by someone else’s LLM, wired into someone else’s CRM APIs, wrapped in a UI you built. That’s it. That’s the moat.

Which means you’re replaceable on both ends:

The CRMs you integrate with sit on the one thing you don’t have, proprietary, first-party data. The moment they decide it’s worth the engineering effort, they can ship a better version of your product natively, with zero integration friction and full data access you’ll never get through an API.
The model providers are moving up the stack. Anthropic and others aren’t just selling raw intelligence anymore, they’re shipping SDKs, agent frameworks, memory systems, and orchestration tools that quietly absorb the exact “glue work” most vertical AI startups charge for.
Here’s the uncomfortable part. Your existence is permitted, not earned. You get to operate in the gap between “the model provider hasn’t built this yet” and “the incumbent hasn’t bothered to build this yet.” That gap can close on someone else’s roadmap decision, not yours.

And worse, every customer you sign, every workflow you validate, every ROI case study you publish is market research you’re doing for them, for free. You’re not competing with the giants. You’re de-risking their next feature.

You’re Selling Determinism, Built on Probability Walk into any enterprise sales call and listen to your own pitch. “Our agent will handle X, Y, and Z, every time, reliably, so your team can trust it in production.”

Now go read the paper your entire product is built on top of. LLMs are probabilistic systems. They sample from a distribution. They don’t execute, they predict, token by token, and mostly get it right.

“Mostly” is not a word enterprise procurement teams like.

You’ve built a business that sells deterministic outcomes on top of a fundamentally non-deterministic substrate. That’s not a rounding error, it’s a category mismatch between what you’re promising and what the underlying technology can guarantee.

This shows up as:

Silent drift. The same prompt, the same workflow, quietly producing different behavior over weeks as the underlying model gets updated upstream, outside your control.
Edge cases your evals didn’t catch, because you can’t enumerate every input an open-ended agent might see in production.
The 2 a.m. Slack message from a client whose “automated” workflow just did something it was never supposed to do.
Your system will fail in ways that are hard to reproduce and harder to explain to a non-technical buyer who was sold on certainty. Planning for that, architecturally, contractually, and in how you set expectations, isn’t pessimism. It’s the difference between a company that survives its first major incident and one that doesn’t.

The EU AI Act Isn’t a Footnote, It’s a Filter You can build from San Francisco, Bangalore, or Lagos and still not escape this one.

The EU represents roughly a quarter of global GDP. No company gets to call itself “global” while quietly avoiding the world’s most heavily regulated, highest-scrutiny consumer and enterprise market. And unlike GDPR, which mostly punished companies for what they did with data, the EU AI Act regulates what your system is allowed to do. How it’s classified, what documentation it needs, what transparency it owes users, and what risk category it falls into before you ever sign a contract.

Here’s the number that should keep you up at night. Non-compliance can cost up to 7% of global annual revenue.

Now put yourself in your enterprise buyer’s shoes. They’re not evaluating whether your product is good. They’re evaluating whether buying it exposes their balance sheet to a fine that dwarfs the value of the deal. No procurement team signs off on that risk for a vendor who can’t clearly answer questions about risk classification, documentation, and compliance posture.

If your current architecture and go-to-market can’t answer “how are you EU AI Act compliant?” in a straight sentence, you don’t have an enterprise-ready product yet. You have a demo with a sales team attached.

So What Now?
None of this means vertical AI is a bad business to build. It means the founders who survive won’t be the ones with the flashiest demo. They’ll be the ones who treated these three crises as design constraints from day one, not fire drills after a customer or regulator forces the issue.

That’s exactly the gap Zizka DB was built to close.

Enter Zizka DB, the Operational Database for Agentic AI
Zizka DB (built by the team at zizka.ai, based at Station F in Paris, backed by AWS Startups and Basecamp accelerator programs) is pitching itself as exactly the kind of infrastructure layer vertical AI founders need underneath their agents, an operational database that makes AI agents auditable, reliable, and EU AI Act compliant.

Here’s how it maps directly onto the three crises above.

Fixing Crisis #1, Owning Something the Giants Don’t Have
Zizka DB isn’t trying to out-model the model providers. It’s building the layer underneath the agent, the record of what actually happened, which is precisely the kind of infrastructure that doesn’t get commoditized by a bigger LLM release. Their architecture leans on time-tested, boring-in-the-best-way engines (PostgreSQL, Redis, Qdrant, pgvector, and Ollama) wrapped in their own ZDB core, rather than being a thin skin over someone else’s API.

Just as importantly, the distribution model is designed to build a moat the usual way, through community and trust, not a rented API key:

A free, AGPL-licensed open-source core driving inbound leads and community-led development.
A cloud-managed tier for small teams.
Design partnerships and enterprise deployments (including in-house VPN deployment) once trust is established.
That’s a company building its own layer of the stack, not renting someone else’s and hoping the rent stays low.

Fixing Crisis #2, Making Probabilistic Systems Operationally Survivable
Zizka DB doesn’t pretend it can make LLMs deterministic, nobody honestly can. Instead, it attacks the actual problem. When your agent inevitably drifts, can you see it happening, explain it, and roll it back before it costs you the client?

Their approach centers on three primitives:

db.why(), causal lineage tracing, so you can reconstruct why an agent did what it did, not just that it did it.
db.at(), point-in-time, replayable session retrieval, essentially time travel for agent behavior, letting teams reconstruct system state and replay a session end-to-end.
Drift detection against a stored behavioral baseline, catching memory drift and hallucination risk before it becomes a production incident, rather than discovering it from an angry customer.
On the competitive landscape slide from their deck, Zizka DB claims to be the only tool in the observability space offering true causal lineage and time-travel replay together, scoring 5/5 on their comparison criteria against Laminar, Langfuse, and Arize Phoenix, none of which currently offer both capabilities natively.

There’s a cost angle here too. Agentic loops and long context windows quietly burn tokens (“token bleed,” in their words), and Zizka DB’s design layer is built to visualize and identify where that tokenization cost is coming from, turning an invisible line item into something you can actually manage.

Fixing Crisis #3, Compliance as a Feature, Not an Afterthought
This is where Zizka DB’s positioning gets sharpest. It’s pitched as the only auditing tool in this space with pre-designed EU AI Act compliance, mapped directly to specific articles rather than a generic “we take compliance seriously” line.

EU AI Act RequirementHow Zizka DB Addresses It

Art. 12–26(5)(6), Automatic logging & traceabilityContinuous event logging by every agent, full session timeline reconstruction, configurable retention, self-hosted/VPN deployment

Art. 12(2), 72–79, Risk assessment & monitoringCausal lineage via db.why(), stored behavioral baselines, memory drift signals, incident investigation support

Art. 13, Transparency for deployersDashboard APIs & SDKs, point-in-time retrieval via db.at(), full query/search, no opaque, vendor-managed memory black box

Art. 26, Human oversight & controlFull inspection of action chains, instant system-state reconstruction, early drift identification, evidence-based intervention

For a founder trying to sell into the EU, that’s the difference between a compliance conversation that stalls a deal and one that closes it, because the audit trail and human-oversight mechanisms the regulation demands are already built into the data layer, not bolted on after a legal review flags the gap.

Why This Matters Beyond One Product
Whether or not Zizka DB ends up being your answer, it’s a useful signal for where the category is heading. The vertical AI founders who make it through these three crises will be the ones who stop treating auditability, drift management, and compliance as later-stage checkboxes and start treating them as the actual product foundation, the layer that makes everything built on top of an LLM defensible, explainable, and sellable to an enterprise buyer who’s rightly nervous about all three of the crises above.

If you’re a vertical AI founder feeling any of the three crises in your gut, it’s worth a look: db.zizka.ai/eu-ai-act.

The article is originally published in medium and can be viewed here: https://medium.com/@MirArshadTalpur/vertical-ai-founders-you-are-going-through-3-existential-crises-and-most-of-you-dont-know-it-b3d86a386d37

How you can make your AI Agents EU AI ACT compliant !

Mir Arshad Ali Talpur — Mon, 17 Aug 2026 13:02:47 +0000

The problem: agents that no one can explain
Enterprises and vertical AI companies are shipping autonomous and semi-autonomous agents into production faster than they can explain what those agents actually do. An agent calls a tool, retrieves a document, and gives an answer, and three weeks later, when a customer disputes that answer, the only artifact left behind is a wall of unstructured application logs. Nobody can say why the agent made that specific call, what it knew at that moment, or whether the same question would produce the same answer today.

This is the gap ZizkaDB is built to close. It positions itself not as another observability or tracing tool, but as an operational database for AI agents, a system of record that stores every agent decision, tool call, and outcome as a causally linked event, so that behavior can be replayed, traced, and audited after the fact rather than guessed at.

The product’s own framing is blunt about this distinction: “Don’t observe, audit your AI agent.” Traces tell you a span happened. ZizkaDB tells you why it happened, what the system looked like when it happened, and whether it’s still happening the same way.

Three functions that turn logs into audit trails
ZizkaDB’s core value sits in three tightly related capabilities: causal lineage, point-in-time state retrieval, and full session replay. Together they answer the three questions every enterprise compliance or engineering team eventually asks about a misbehaving agent: why, what did it know then, and can we watch it happen again.

Causal lineage why() Every event an agent produces (a user message, a tool call, a retrieved document, an LLM response) is logged with a parent_id that links it to the event that caused it. This turns a flat log stream into a causal graph. Calling why() on any decision walks that graph backward and returns the actual chain of causes which prompt version was active, which document chunk was retrieved, which tool ran, and in what order rather than a plausible-sounding LLM-generated explanation after the fact.

This is the difference between an agent telling you why it did something (which can be confabulated) and a database proving why it did something, because the chain was recorded as it happened and is tamper-evident (ZizkaDB uses checksum-backed events to make the decision history difficult to alter retroactively).

Point-in-time state at() Agent behavior isn’t just about the current prompt or the current tool set it’s about what the system looked like at the moment a decision was made. ZizkaDB’s at() function is a form of time travel: it reconstructs the exact state of a session (which policy document was in context, which prompt version was live, which baseline the agent was operating against) at a specific timestamp or event.

This matters enormously for incident response. In the worked example ZizkaDB uses on its own site: a customer is told refunds take 30 days when policy says 14. Without lineage and time-travel tooling, a team has to guess whether this was a prompt bug, a stale document, or a one-off hallucination. With at(), the team can reconstruct the exact retrieval and prompt state at that moment and see, directly, that the agent pulled an outdated FAQ chunk after a prompt v2 deploy a two-minute root cause instead of an open-ended debugging session.

Session replay Causal lineage and point-in-time state converge in session replay: the ability to reconstruct an entire conversation or agent run, end to end, as a sequence of linked events user input, tool calls, retrieved context, intermediate reasoning steps, and final output in the order they actually occurred. This is not a reconstructed narrative; it’s the literal recorded event chain, replayable in the dashboard or pulled via SDK/API/MCP.

For engineering teams, replay collapses “can you send a screenshot, we’ll check the logs” into “here is the exact decision trail.” For compliance and audit teams, it produces something closer to a flight recorder for an AI system: a durable, queryable account of what the agent did and on what basis.

Layered on top of these three primitives, ZizkaDB also supports behavioral baselining and drift detection (comparing current agent behavior against an established baseline to catch silent regressions a prompt tweak that quietly changes decisions, or a tool call that starts skipping a policy check without anyone noticing) and forget(), which deletes matching events and their vector embeddings together by metadata filter, supporting data-subject erasure requests.

Why this matters for enterprises and vertical AI companies
Vertical AI companies those building agents for regulated or high-stakes domains like healthcare, finance, insurance, and legal face a structural problem: the value of their product depends on the agent taking autonomous action, but the liability exposure of that same autonomy depends on being able to prove, after the fact, that the action was reasonable and traceable to the operator’s actual policy at the time. Generic observability tools (traces, spans, vector stores) were not built to answer “why,” “what did the system know,” or “what changed” as first-class, queryable primitives ZizkaDB’s own comparison against tools like LangSmith, Mem0, and Pinecone is built around exactly this gap: those tools log events or store embeddings, but don’t natively support causal lineage, point-in-time state reconstruction, or cross-agent behavioral baselines.

For enterprises deploying agents at scale across many teams, the same primitives support a fleet-level view: cross-agent queries and ranking that let a platform or AI-governance team see which agents are drifting, which are stable, and where to focus review rather than treating each agent as an isolated black box.

Mapping ZizkaDB to the EU AI Act
Regulation (EU) 2024/1689 , the EU AI Act , entered into force in August 2024, with obligations phasing in through 2026–2027 depending on a system’s risk classification. It imposes record-keeping, traceability, transparency, and human-oversight duties on providers and deployers of AI systems, obligations that are difficult to satisfy when an agent’s decision history exists only as scattered, unstructured application logs. ZizkaDB’s own compliance page frames its role carefully: it supplies the operational evidence the Act expects, without claiming to be a compliance program in itself.

The mapping ZizkaDB publishes against specific articles looks like this:

EU AI Act requirement

Relevant articles

How ZizkaDB’s functions support it

Automatic logging & traceability

Art. 12, Art. 26(5)–(6)

Continuous event logging and full session reconstruction, with configurable per-tenant retention on self-hosted or managed deployments

Evidence for risk assessment & post-market monitoring

Art. 12(2), Art. 72, Art. 79

Causal lineage (why()), behavioral baselines, and drift signals help detect anomalies and support post-market monitoring

Transparency for deployers

Art. 13

Dashboards, APIs, SDKs, semantic search, and point-in-time retrieval (at()) make agent behavior inspectable rather than opaque

Human oversight

Art. 14, Art. 26

Operators can inspect full action chains, reconstruct system state at any point, identify drift, and intervene with evidence rather than screenshots

Technical documentation & conformity evidence

Art. 11, Arts. 8–9, 17

Logged histories feed technical documentation and compliance reporting — complementing, not replacing, formal risk management or notified-body assessment

Accuracy, robustness & cybersecurity

Art. 15

Tenant isolation, scoped API keys, tamper-evident checksums, and self-hosted/VPC deployment options

Personal data alongside GDPR

GDPR

EU-entity operation, forget() erasure across events and vector embeddings, marketing opt-out, self-hosting for data residency

Two structural facts reinforce this mapping.

First, ZizkaDB is open source and self-hostable (AGPL-3.0, with an Enterprise VPC license for organizations that need single-tenant deployment, an SLA, and support), meaning organizations with strict data-residency or auditability requirements can run the entire system inside their own infrastructure rather than trusting a third-party vendor’s memory store.

Second, the company itself is an EU entity (ZIZKA AI S.L., based in Málaga, Spain), which simplifies GDPR alignment for the managed cloud option.

What ZizkaDB is not
To its credit, ZizkaDB is explicit about the limits of what a database can do.

Its own FAQ states plainly that no single tool grants full AI Act compliance: the platform provides record-keeping, traceability, and human-oversight evidence, not a substitute for risk classification under Article 6 and Annex III, a Quality Management System, or a formal conformity assessment. An organization’s actual obligations depend on whether it is a provider or deployer and how its system is classified, determinations that still require qualified legal counsel. ZizkaDB’s role is to make sure that when that legal and governance work happens, the underlying operational evidence, what the agent did, why, and under what state. actually exists and is queryable, rather than being reconstructed from memory or absent entirely.

The practical picture
Integration is deliberately lightweight: a Python or TypeScript SDK, a REST API, or an MCP server that plugs into tools like Claude Desktop or Cursor without app code changes. Events are logged with agent, session_id, and parent_id, which is what makes lineage and replay possible later the causal graph is built from how events are logged, not inferred after the fact. Self-hosting via Docker Compose is free and open source; managed cloud and single-tenant Enterprise VPC deployments add a hosted dashboard, fleet-level views, and formal support and SLAs for organizations that need them.

For enterprises and vertical AI companies operating under the EU AI Act, or simply trying to run agents in production without debugging blind, the underlying bet ZizkaDB is making is straightforward: audit trails have to be built into the agent’s operational data layer from day one, because they cannot be reconstructed convincingly after an incident has already happened.

Originally Published in medium and can be viewed here :
https://medium.com/@MirArshadTalpur/how-you-can-make-your-ai-agents-eu-ai-act-compliant-1e132e9e4a52

The EU AI Act Is Now a Business-Blocking Risk for Vertical AI, Here’s the One Fix That Closes the Gap

Mir Arshad Ali Talpur — Fri, 14 Aug 2026 12:08:44 +0000

This is not a read it when you get time policy update. If you run a vertical AI company shipping agents into finance, healthcare, legal, insurance, or any regulated workflow, the EU AI Act (Regulation (EU) 2024/1689) is already an active blocker on your pipeline, whether you’ve noticed it yet or not. Enterprise security reviews are asking for it right now. Procurement teams are gating contracts on it right now. And most vertical AI stacks have no real answer.

The question every regulated buyer, auditor, and eventually regulator will ask is brutally simple: can you prove what your agent did, why it did it, and that a human could have stepped in? If the honest answer is not really, it’s scattered across logs, you don’t have a compliance gap, you have a revenue-blocking emergency, and it compounds every week you don’t fix it.

Why This Hits Vertical AI Harder Than Horizontal Tools
A general-purpose chatbot answering trivia questions carries very different risk than an agent approving a loan, flagging a fraud case, or recommending a clinical pathway. The Act’s obligations scale with risk classification, and a large share of vertical AI use cases — the exact ones that make vertical AI valuable in the first place , fall into higher-scrutiny categories.

The Act entered into force in August 2024, and it’s phasing in on a schedule that just hit a major checkpoint. As of August 2, 2026, transparency obligations are applicable, providers must disclose when someone is interacting with an AI system, and AI-generated content needs to be identifiable. High-risk obligations (Annex III the tier covering credit, hiring, healthcare, and similar use cases) were originally due this same date, but the EU’s Digital Omnibus, which entered into force on July 27, 2026, pushed that specific deadline to December 2, 2027.

That’s not a reason to relax. It’s a shorter runway with a harder wall at the end of it: transparency duties are live now, GPAI obligations have applied since August 2025, and the high-risk clock is still running toward a fixed date that regulators have shown no appetite to move again. Enterprise buyers in regulated industries aren’t waiting for the legal deadline — procurement and security questionnaires are already assuming you can answer these questions today.

What’s Actually at Risk and It’s Not Theoretical
For an AI agent company, non-conformity isn’t an abstract legal line item sitting in a future filing cabinet. It is actively costing you deals right now, and it gets worse the longer it’s ignored:

Lost enterprise deals. Regulated buyers (banks, insurers, healthcare systems) increasingly require documented traceability and human-oversight evidence before they’ll sign, no evidence, no contract.
Opaque agent memory as a liability, not a feature. If your agent’s decision history lives only in scattered application logs, you can’t reconstruct why it acted, which is exactly what Article 12 record-keeping and Article 14 human-oversight duties expect you to produce on demand.
Slower incident response. Without causal lineage between an agent’s inputs, tool calls, and outcomes, debugging a bad decision or proving to a regulator it wasn’t systemic takes days instead of minutes.
Compliance work competing with product work. Founders end up building bespoke logging, audit trails, and erasure tooling in-house instead of shipping features, which is a slow bleed on a startup’s most scarce resource: engineering time.
None of this requires a worst-case fine to hurt. The drag shows up earlier, in sales cycles and engineering roadmaps, long before any enforcement action would.

The Core Problem: Agents Don’t Log Themselves
Most AI stacks were never designed with regulatory traceability in mind. Vector stores hold embeddings, not causal chains. Application logs capture requests, not decisions. When a regulator, auditor, or enterprise security team asks “show me why the agent did that, and show that a human could have stopped it,” most vertical AI companies currently can’t answer cleanly, not because they’re non-compliant by intent, but because the infrastructure to answer wasn’t built.

This is the gap that turns a promising vertical AI company into a stalled one and it’s exactly the gap ZizkaDB was built to close.

The Fix: ZizkaDB Is the Infrastructure Layer You’re Missing
If your agent stack has no causal event log, no human-oversight tooling, and no clean erasure path, you are not a little behind , you are one enterprise security questionnaire away from a stalled deal. ZizkaDB exists to close exactly that gap, fast, without asking you to rebuild your product around a compliance program. Its architecture maps directly onto the operational demands the Act creates:

Automatic logging & traceability (Art. 12, Art. 26) every agent decision, tool call, and outcome is stored as a causally-linked event, so sessions can be reconstructed into a complete timeline instead of pieced together from scattered logs.
Evidence for risk assessment & monitoring (Art. 12(2), Art. 72, Art. 79) causal lineage, behavioral baselines, and drift signals support incident investigation and post-market monitoring.
Transparency for deployers (Art. 13) dashboards, APIs, SDKs, and point-in-time retrieval make agent behavior inspectable rather than locked inside an opaque, vendor-managed memory store.
Human oversight (Art. 14, Art. 26)operators can inspect full action chains and reconstruct system state at any point, intervening based on evidence rather than screenshots or manual notes.
Security & robustness (Art. 15) tenant isolation, scoped API keys, tamper-evident event checksums, and self-hosted or VPC deployment options.
GDPR alongside the AI Act a forget() function erases matching events and their vector embeddings together, with self-hosting available for organizations that need strict data residency.
It’s open-core, model-agnostic, and works whether you self-host (Python, npm, MCP, LangChain, CrewAI SDKs) or run on managed cloud — so the same traceability posture holds regardless of deployment mode.

Be clear-eyed about what savior means here: no single tool grants AI Act compliance, and anyone who tells you otherwise is selling you something dangerous. What ZizkaDB actually does is remove the single biggest blocker — the missing operational evidence, so your legal team, risk classification, and conformity assessment have something real to work with instead of nothing. Without that evidence layer, none of the rest of your compliance program has a foundation to stand on. That’s why it’s the fix that has to happen first, and fast.

Built in Spain, Building at Station F
ZizkaDB is operated by ZIZKA AI S.L., headquartered in Málaga, Spain, a detail that matters more than it might seem. Being an EU-based entity, under EU data protection law, from day one is a structural advantage for a compliance-adjacent product: it’s easier to trust an AI Act tool that was built inside the same regulatory environment it’s designed to support, rather than bolted on from outside it. The team is now also building at Station F in Paris, Europe’s largest startup campus, putting the product in close proximity to the enterprise and regulatory ecosystem it serves.

The Takeaway: Fix This Before It Fixes Your Roadmap for You
This isn’t a someday problem. Transparency obligations are live as of this month, GPAI rules have applied for a year, and even with the high-risk deadline now deferred to December 2027, that’s less runway than it sounds like once you factor in the time real traceability infrastructure takes to build and prove out. Enterprise buyers are already gating deals on it, and every vertical AI company without an evidence layer is quietly losing ground to competitors who have one. Waiting until 2027 to react means reacting after the deals are already lost.

If you’re building agents for regulated industries and you don’t currently have a causal, auditable, human-inspectable record of what your agents did and why, treat that as the single most urgent gap in your stack today, not next quarter.

For agent-first companies, that infrastructure doesn’t have to be built from scratch, and it doesn’t have to take months. ZizkaDB was built specifically to close this gap, fast enough to matter.

Want to know how it works ?

See the video here

https://youtu.be/UWDiF81J0Pw

The article was originally published in medium and can be viewed here : https://medium.com/@MirArshadTalpur/the-eu-ai-act-is-now-a-business-blocking-risk-for-vertical-ai-heres-the-one-fix-that-closes-the-9d7ecfa62a48?sharedUserId=MirArshadTalpur

The Vertical AI Bubble: We Keep Forgetting That LLMs Roll Dice

Mir Arshad Ali Talpur — Tue, 11 Aug 2026 15:48:46 +0000

I’ve spent the last year watching an entire generation of vertical AI startups get funded, launched, and celebrated. AI for law firms. AI for insurance claims. AI for radiology. AI for accounting. AI for customer support in a specific niche of healthcare billing. Every pitch deck looks the same: take a foundation model, wrap it in a narrow workflow, add some proprietary data, call it a moat, and raise a Series A at a valuation that assumes this thing behaves like software.

That last part is where I think we’ve collectively lost the plot. It’s the reason I’ve become genuinely worried we’re building a bubble on a foundation that doesn’t hold the weight we’re putting on it.

The Quiet Assumption Everyone Is Making
Every vertical AI product, no matter how it’s marketed, is quietly making a bet: that if you constrain a large language model tightly enough, with prompts, fine-tuning, retrieval, guardrails, evals, you can make it behave deterministically enough to run a business process. Approve the claim. Flag the contract clause. Code the diagnosis. Reconcile the ledger.

The word enough is doing an enormous amount of work in that sentence, and I don’t think most people building these companies have sat with what it actually means.

Traditional software is deterministic. Give it the same input, you get the same output, every time, forever, unless someone changes the code. That’s the property that made SaaS investable in the first place. You could underwrite reliability. You could say a system does X and mean it categorically, not statistically.

LLMs don’t have that property. They are, structurally, probabilistic next-token predictors. Even at temperature zero, even with the same prompt, the same weights, the same everything, you are sampling from a distribution over possible outputs, not executing a fixed procedure. Most of the time the sample looks like the procedure. Some of the time it doesn’t. Critically, you often can’t tell which is which just by looking at the output. A wrong answer can be just as fluent and confident as a right one.

Why This Matters More in Vertical Than in Horizontal
For a general chatbot, this is a minor annoyance. If I ask a general-purpose assistant to summarize an article and it makes a small factual slip, I read it, I notice something’s off, I double check, life goes on. The failure mode is visible and low stakes.

Vertical AI is different by design. The entire pitch is removing the human from the loop in a specific, repeatable business process, because that’s where the margin is. Underwriting insurance policies. Approving or denying medical claims. Drafting legal filings. Auto-coding invoices. Triaging patients. The value proposition is explicitly that you should trust the system to make the judgment call so a human doesn’t have to.

But you can’t have it both ways. You can’t sell the idea that you removed the human because the model is reliable enough to be trusted, while also being honest that the underlying technology is probabilistic and will occasionally produce a confidently wrong answer that looks exactly as polished as a correct one. That tension doesn’t go away because you fine-tuned on fifty thousand examples of your domain. It gets quieter, not smaller. The failure rate might drop from 8% to 1%, but at scale, across millions of insurance claims or legal documents, 1% is a catastrophic number of wrong, confidently stated decisions. Worse, it’s a 1% you often can’t predict in advance, because it isn’t correlated with the kinds of inputs a human would flag as hard.

The Bubble Mechanics
Here’s how I think the bubble actually inflates, step by step.

Step one: the demo works. Vertical AI demos are almost always built on cherry-picked or lightly adversarial-tested examples. Probabilistic systems are extremely good at looking deterministic in a demo, because you’re implicitly sampling from the part of the distribution where the model is confident and correct. Nobody demos the failure mode on purpose.

Step two: the pilot works, mostly. Early customers run it on a limited slice of real data, with a human reviewing outputs for now. The error rate looks acceptable because the review step is quietly absorbing the probabilistic tail. The pitch to investors and to the customer’s leadership is that the review step is temporary, a bridge to full autonomy.

Step three: the humans get removed, or their review gets rubber-stamped. This is where the economics of the vertical AI thesis actually kick in. The human-in-the-loop step is expensive, and it’s the thing standing between the current valuation and the ten-times-cheaper-than-a-human-analyst valuation everyone is underwriting. So it gets thinned out. Review sampling drops from 100% to 10% to spot checks. Fatigue sets in, and rubber-stamping becomes the norm, the same way it does with any repetitive QA task performed on a system that’s right the overwhelming majority of the time.

Step four: the tail event happens at scale. These aren’t independent coin flips reviewed one at a time by a careful human anymore. They’re a probabilistic system operating with a thinned safety net across a huge volume of consequential decisions. Somewhere in there is a wrongly denied medical claim, a hallucinated case citation in a legal filing, a misclassified transaction that cascades through a ledger. It isn’t a bug in the traditional sense. It’s the expected behavior of a probabilistic system finally showing you its distribution.

Step five: the moat turns out to be thin. Once trust cracks, through a lawsuit, a regulatory inquiry, a viral failure story, the vertical AI company discovers that its actual defensibility was never the model, since everyone has access to roughly the same foundation models, and was never really the proprietary data either, which turns out to matter less than advertised for general reasoning tasks. The moat was the appearance of reliability. Appearance is not a moat once the illusion is punctured.

I think we are somewhere between step two and step three across a huge number of vertical AI companies right now, and I think this is exactly the mechanism that will separate the ones that survive from the ones that don’t over the next few years.

But the Models Are Getting Better
They are. I’m not arguing that LLMs are stagnant or that this is a permanent ceiling. I use these systems every day and the trajectory is real. But better in this context usually means the distribution shifts so that correct outputs are more probable and errors are rarer, not that the system becomes deterministic. Those are fundamentally different claims, and vertical AI marketing consistently conflates them.

Even a model that’s right 99.9% of the time is still a probabilistic system, not a deterministic one, and the businesses being built on top of it need to be architected as if failures are a certainty at scale, not as an embarrassing edge case to be quietly patched later. A 99.9%-accurate system processing ten million claims a year is still generating ten thousand wrong decisions a year, delivered with exactly the same confident tone as the correct ones.

There’s also a subtler problem. Improvements on benchmarks don’t necessarily transfer to the narrow, high-stakes, out-of-distribution edge cases that vertical products actually live or die on. A model can get dramatically better at general reasoning while still failing in eerily consistent ways on the specific messy, ambiguous, adversarial inputs that show up in real insurance claims or real contract redlines, which are exactly the inputs a vertical AI company was supposedly built to handle better than a generalist model.

The EU AI Act Is the Bill Coming Due
If everything above is the slow-motion mechanism, the EU AI Act is the thing that pull the timeline forward violently, at least for anyone operating in or selling into Europe. When I read it closely, I keep coming back to the same conclusion: for a lot of vertical AI as currently built, this regulation isn’t a compliance cost. It’s closer to a death warrant.

Here’s why, and it comes back to the exact same probabilistic-versus-deterministic tension.

Most vertical AI use cases fall straight into high-risk. Credit scoring, insurance underwriting and claims, employment decisions, medical triage, law enforcement-adjacent tools, access to essential services. This is almost a checklist of the categories vertical AI startups have been racing into for the last two years, and it’s almost exactly the high-risk AI system list under the Act. That’s not a coincidence. Those are the domains with the biggest, most attractive inefficiencies to automate. They’re also precisely where regulators decided the stakes were too high for trust-us-the-eval-scores-were-good.

High-risk systems don’t get to be black boxes anymore. The Act’s requirements read like a direct rebuttal to how most of these products are actually built. A documented risk-management system covering the entire lifecycle, not a one-time eval before launch. Training data governance, meaning provenance, bias examination, and gaps, that most teams fine-tuning or doing retrieval on scraped or licensed domain data simply cannot fully reconstruct after the fact. Technical documentation detailed enough for a regulator to reconstruct why the system produced a given output. Automatic logging sufficient to trace decisions after the fact. Human oversight that’s real and structurally capable of overriding the system, not a rubber-stamp UI. Accuracy, robustness, and cybersecurity levels that have to be disclosed, not just claimed in a pitch deck.

Every one of those requirements assumes you can explain, reconstruct, and audit a specific decision after the fact. That assumption is trivially true for deterministic software: you look at the code path and the logs and you’re done. It’s not straightforwardly true for a large language model. You can log the prompt and the output. You generally cannot produce a causal account of why the model landed on one token sequence instead of another, because that reasoning is distributed across billions of parameters shaped by training data you often don’t fully control and can’t fully inspect. Explainability research is real and improving, but it’s nowhere near mature enough to satisfy reconstruct-this-specific-high-stakes-decision-for-a-regulator as a routine operational capability.

This is the same probabilistic problem, just wearing a legal costume. My whole argument so far is that vertical AI companies have been selling the appearance of determinism built on top of a genuinely probabilistic substrate. The EU AI Act, in effect, forces that gap into the open and puts a legal price tag on it. You can’t paper over the fact that the model is probabilistic and you don’t fully know why it said what it said with better UX or a confident dashboard, when a regulator or a plaintiff’s lawyer is asking you to produce the audit trail for a specific denied claim or a specific rejected loan. Saying the model thought this was the most likely correct answer, based on patterns in training data you can’t fully enumerate, doesn’t satisfy an auditability requirement. It’s a restatement of the exact problem the requirement exists to catch.

The penalties are sized to be existential, not incidental. Fines for the most serious violations run up to the higher of a fixed cap in the tens of millions of euros or a percentage of global annual turnover, the kind of number that isn’t a line item, it’s a company-ending event for a startup still burning venture money. For a vertical AI company whose entire go-to-market has been trust our model’s judgment instead of a human’s, that liability profile changes the unit economics of the business overnight. Suddenly the cost isn’t just inference and fine-tuning. It’s building, and proving to a regulator, an entire scaffolding of logging, human oversight, and documentation around a system that was pitched, and priced, as if it didn’t need one.

The uncomfortable fork this creates. I think this regulation forces every vertical AI company operating in high-risk categories into one of two positions, and neither is comfortable. Either they genuinely rebuild around the fact that the core decision-making component is irreducibly probabilistic, which means heavy human-in-the-loop by design, not by pretense, real logging and explainability infrastructure built in from day one, and honestly accepting that some categories of decision may never be fully delegable to the model at all. That’s expensive, slows down the we-replaced-the-human pitch, and undercuts the exact margin story that got them funded. Or they keep operating the way they do now and quietly accept regulatory risk as a cost of doing business, a bet that works until the day it very publicly doesn’t, in a jurisdiction with both the will and the fine schedule to make an example of someone.

Either way, raise fast, automate the human away, worry about compliance later, which has basically been the vertical AI playbook, doesn’t survive contact with a regulatory regime built explicitly to demand something a probabilistic system cannot, by its nature, fully supply: a complete, reconstructable account of why it produced one specific output rather than another.

Why I Think This Has to Be Solved in the Open
I don’t want to end on pure doom, because I don’t think the answer is that vertical AI is impossible. I think the answer is that the infrastructure layer everyone skipped, the boring, unglamorous plumbing of actually recording and reconstructing what an agent did and why, is exactly what closes the gap between a probabilistic model and an auditable system. This is the layer I’ve been spending my own time on, and I want to be upfront that what follows is me talking about my own project, not a neutral third-party recommendation.

I’m the founder of ZizkaDB, an operational database built specifically for AI agents, and the EU AI Act is the reason it exists in its current form. Rather than pretending the underlying agent is deterministic, it takes the opposite approach: treat every agent decision, tool call, and outcome as a causally linked event, so instead of a single opaque output you get a reconstructable chain of why the system landed where it did, queryable after the fact, not reconstructed from memory, screenshots, or application logs that were never designed for this.

It maps directly onto the specific articles I’ve described as the hard part in this piece, not as a marketing gloss but as a point-by-point correspondence. Continuous event logging and session reconstruction against Article 12’s automatic logging and traceability duties. Causal lineage and drift detection feeding the kind of ongoing risk assessment and post-market monitoring Articles 72 and 79 expect, rather than a one-time launch eval. Dashboards and point-in-time state retrieval giving deployers the transparency Article 13 requires and the human oversight Article 14 assumes is actually possible. Tamper-evident event checksums speaking to Article 15’s accuracy and robustness requirements rather than just the audit-trail ones. You can see the full mapping here.

But here’s the part I want to be honest about, and it’s the actual reason the project is open source. I don’t think this is a problem any single team or company gets to solve alone. Auditability for probabilistic systems isn’t a feature you bolt onto a product roadmap, it’s infrastructure, in the same sense that logging, observability, and version control are infrastructure. Nobody expects a single company to own the one true observability standard for distributed systems, and I don’t think anyone should expect that for agent auditability either. The moment this becomes proprietary, closed, single-vendor infrastructure, it becomes exactly the kind of black box the EU AI Act is designed to distrust, and it puts every company depending on it at the mercy of one vendor’s roadmap, pricing, and continued existence, for a compliance obligation that isn’t going away.

That’s why ZizkaDB is built as an open-core engine on time-tested, well-understood pieces like Postgres, pgvector, and Qdrant, under an AGPL-3.0 license, with the full source available on GitHub. You can self-host it entirely inside your own infrastructure, which matters enormously for anyone thinking seriously about data residency and not wanting their causal decision logs living in someone else’s cloud. It’s model-agnostic by design, because the point was never to lock you into a particular LLM provider. The point is to give you a durable, inspectable record layer no matter which model happens to be making the decisions underneath.

To be fair to where the real work still is: no single tool, mine included, makes an AI system compliant. There’s still real governance work, risk classification, a quality management system, a genuine conformity assessment, that no database can substitute for, and I’d be doing exactly the thing I criticized earlier in this piece if I pretended otherwise. What I do think is that the auditability problem underneath all of that governance work is too large, too foundational, and too urgent to be solved by any one vendor behind a paywall. It needs to be solved the way the internet’s actual infrastructure got solved, in the open, with the people who have the problem contributing to the tool that fixes it, not waiting for a single startup to get it exactly right on the first try.

That, to me, is the difference between vertical AI companies that survive contact with the EU AI Act and the ones that don’t. Not better models. A better, shared, inspectable paper trail for the imperfect ones we already have.

What I Think Actually Survives This
I don’t think the answer is to stop building vertical AI. I think the answer is being honest about what kind of system you’re actually building, and designing around the probabilistic reality instead of marketing around it.

The companies I find myself more optimistic about are the ones that treat the LLM as a fast, cheap, fallible component, permanently probabilistic, never fully tamed, and design the rest of the system around that fact instead of around the wish that it weren’t true. Hard constraints and verifiable checks on the decision boundaries that matter most. Human review calibrated to actual risk rather than vibes. Honest reporting of confidence and error rates instead of a dashboard that implies certainty. The value they’re selling isn’t that they replaced the human. It’s that they made the human dramatically more leveraged, and they know exactly where the model’s judgment needs a second set of eyes.

The companies I’m worried about are the ones whose entire cap table is quietly betting that probabilistic, if you squint, will keep behaving like deterministic long enough for them to reach the next round. That bet works fine for a while, because most of the time, the model is right. That’s exactly what makes it dangerous. It’s the most-of-the-time businesses that make bubbles, right up until the tail shows up.

I don’t know exactly when this particular bubble pops, or whether it pops all at once or leaks out slowly through a hundred smaller stories that never quite make national news. But I’m fairly confident of the mechanism, because it isn’t really about AI at all. It’s the oldest story in finance: you can price a system as if it’s reliable for a surprisingly long time, and the market only really finds out it wasn’t when the tail event finally arrives.

The technology isn’t the problem. The pretending is.

EU AI Act: Second Big Blow, or a Move Toward Sanity?

Mir Arshad Ali Talpur — Fri, 07 Aug 2026 14:29:33 +0000

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

Auditability vs. Forced Determinism : Future of Agentic AI

Mir Arshad Ali Talpur — Wed, 05 Aug 2026 10:11:51 +0000

Why AI Agents Need the Right Goal, Not an Impossible One
Writer’s Note:

This Article is for those who are building Vertical AI Solutions, for those who believe in science and specially for those who believe LLMs with all these generative powers are still scientific inventions and they fall under rules of mathematics and science

The Illusion of the AI Hype Cycle
Almost every AI startup right now is promising some version of reliable, production-ready agents.

Look at the last few YC batches, close to 90% of the companies are AI-driven, and most of them are vertical AI companies: they don’t build the underlying model, they build a layer on top of one, applying it to a specific industry or workflow.

Marketing budgets are massive, seed rounds are enormous, and the narrative is being scripted largely by frontier LLM providers whose hundred-billion-dollar valuations depend on keeping the hype alive.

I’m a founder building infrastructure in this exact market, and this piece is really about the bet we made, and why we made it instead of chasing the more marketable promise everyone else is selling.

Here’s the question nobody in this market wants to answer directly: has anyone built a core AI primitive that is actually deterministic, the same output for the same input, every time, the way traditional APIs have always worked?

No. And no amount of RAG, added context, or agentic optimization on top of the model changes that.

A History of Patching a Fundamental Flaw
A History of Patching a Fundamental Flaw
When ChatGPT launched, it unleashed incredible generative capabilities.

I will never discredit that — it remains one of the most astonishing technical breakthroughs of our era.

However, as the industry attempted to move from impressive consumer demos to mission-critical enterprise workflows, the core weakness of LLMs became glaringly obvious: their inherent unpredictability.

To solve this, the industry went through rapid layers of band-aids:

Vector Databases: Tools like Pinecone and Chroma brought semantic search into the spotlight.

While useful, vector databases are fundamentally logical evolutions of traditional databases — they simply store mathematical embeddings and allow similarity queries.

Retrieval-Augmented Generation (RAG): RAG was hailed as the ultimate cure for LLM hallucinations and memory limits. The promise was simple: restrict the LLM to your custom data boundaries.

In practice, enterprises quickly learned that RAG merely reduces hallucinations; it does not eliminate them.

Agentic Optimizations: Chaining reasoning steps, adding tool calls, orchestrating multi-agent workflows, these make agents more capable, but every added step is another probabilistic decision, not a step toward predictability.

Observability & Open Knowledge Frameworks: Today, market interest has shifted to observability frameworks, knowledge graphs, and initiatives like Google’s Knowledge Graph solutions.

Every single one of these top-layer solutions attempts the exact same impossible task: forcing a probabilistic system to behave deterministically.

Vertical AI companies are the clearest example of this pattern at scale — they stack RAG, context, and agentic workflows on top of a foundation model, hoping the combination will feel deterministic enough for their customers to trust.

It never quite gets there, because the layer isn’t the problem. The model underneath it is.

[ Traditional Software ] → Input + Deterministic Code → 100% Predictable Output

[ Generative AI Agent ] → Input + Probabilistic LLM → Variable / Evolving Output

Why You Cannot Force Determinism on an LLM
Can a wrapper, an observability tool, or a RAG pipeline fundamentally alter the underlying nature of an LLM? No. The math simply doesn’t allow it.

LLMs are Math, and the Math is Probabilistic At their core, no matter how many hundreds of billions of parameters they have, LLMs perform next-token prediction. They select the statistically most probable answer given a prompt. Probability, by definition, is non-deterministic.
Models Continuously Evolve Frontier models are updated, fine-tuned, and retrained constantly. If a model’s underlying parameters or alignment weights change over time, its outputs will inevitably drift, even when presented with identical inputs. Stack a multi-step agent chain with tool calls and accumulating context on top, and the drift compounds with every added layer instead of canceling out.

If a system relies on probability and undergoes continuous learning, expecting it to produce rigid, 100% deterministic results is a mathematical contradiction.

No stack of tooling on top changes that, it can only ever manage the consequences of it.

The Path Forward: From Determinism to Auditability
Does this mean we should abandon AI agents? Absolutely not.

AI is fundamentally reshaping market dynamics, and its leverage is undeniable.

However, we need to change our approach. Instead of wasting resources attempting to force non-deterministic models into rigid boxes, we must accept their probabilistic nature and focus on Constrained Reliability through Auditability.

You cannot control what you cannot track inside a black box.

If you accept that AI agents will drift, evolve, and occasionally make unexpected decisions, the enterprise requirement shifts from predictability to strict auditability and governance.

And auditability only works as a continuous process, not a one-time fix. A model that drifts today will drift differently tomorrow, after the next fine-tune, after context windows grow, after agent chains get longer.

A one-time audit tells you what happened yesterday. What’s actually needed is a standing process that watches every execution, indefinitely: continuous auditability, paired with human oversight that can intervene before an unexpected decision reaches production, and a feedback loop that keeps improving the system as it evolves.

Run that consistently, and the agent doesn’t become deterministic — it stays sound and reliable anyway, in the way that actually matters to an enterprise: you always know what it did, why it did it, and you catch the moments it goes wrong before they cause damage.

This is the exact realization that shaped what we built.

How ZizkaDB Solves the AI Reliability Problem
This realization is why we built ZizkaDB.

Source (Github , Cloud)

Rather than promising an impossible magic fix that claims to make LLMs 100% deterministic, ZizkaDB is an open-source operational database built specifically for AI agents — providing the continuous state management, behavioral tracing, and auditing infrastructure needed to run autonomous agents safely in production, not as a one-off check but as a standing process.

Here is how ZizkaDB tackles the core enterprise agent problem:

Causal Lineage & Context Memory (why() and at()) Standard loggers only capture raw input and output, leaving you guessing when an agent makes an erroneous decision. ZizkaDB tracks causal lineage natively (using functions like db.why()).

It allows developers to walk backward through an agent’s execution tree to reveal the exact root cause, parent event, and system state at any point in time.

Parameter Snapshots & Drift Tracking AI agents change behavior over time as prompt context expands and data accumulates. ZizkaDB records parameter snapshots, context windows, and environmental parameters at execution time.

When an agent’s output drifts, you can isolate and inspect the exact temporal context that caused the deviation.

Deep Internal Auditing & Human Oversight Instead of treating the agent execution pipeline as a black box, ZizkaDB logs every tool call, context injection, and reasoning step. It integrates seamlessly into production loops with native SDKs for Python, TypeScript, LangChain, CrewAI, and MCP.

This visibility allows teams to trigger real-time human oversight before unintended decisions reach production environments — and to keep refining the system continuously as the underlying model keeps changing.

Conclusion
We do not need more over-hyped promises of 100% autonomous, flawless AI agents.

What we need is pragmatic, robust infrastructure that recognizes AI for what it is: a powerful, probabilistic engine that requires active, continuous governance, not a one-time fix.

You cannot make an AI agent strictly deterministic, no matter how many layers you stack on top of it.

But with ZizkaDB, you can make it auditable, manageable, and trustworthy enough for the enterprise.

Explore the open-source runtime on GitHub or sign up for instant deployment on ZizkaDB Cloud.