DEV Community: Mir Arshad Ali Talpur

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.