EU AI Act Article 12 hits Aug 2. Vanta wants $50K. I shipped a $79 audit log + OSS verifier.
EU AI Act Article 12 hits Aug 2. Vanta wants €50K. I shipped a $79 audit log + OSS verifier.
I built a tamper-evident audit log for AI decisions because every compliance lead I talked to said the same thing: "Legal's been asking, we don't have it, and we don't know what good looks like."
Here's the wall they're walking into.
August 2, 2026, ten weeks from today, Article 12 of the EU AI Act enters full enforcement. Every organization deploying a high-risk AI system in the EU has to maintain automatic per-event logs (Article 12 §1), retain them for at least six months (Article 19 §1), and surface them on demand to the supervisory authority. The fines are up to €15M or 3% of global turnover for non-compliance with high-risk obligations. Stacked on top of GDPR.
The part that surprised me when I read the text: the obligation lands on the deployer, not the vendor. If you bought an AI system and put it into production for an EU user, you owe the logs. Not your vendor. You. Even if your vendor doesn't generate them, or won't share them, you're liable for producing them in an audit.
What the enterprise market is doing about it: Vanta added an EU AI Act module to its platform last year. The quoted cost for a single deployer to get audit-ready on one high-risk system sits around €50,000 a year. Drata, OneTrust, and the bigger GRC consultancies are in the same range. The math doesn't work for a 30-person AI shop that just deployed one customer-facing LLM feature. There are thousands of those companies, and they need something.
What I built
Praxa (https://praxa.piposlab.com) is the deployer-side audit log for AI decisions.
-
SDK. A three-line wrapper you put around your model call. You instantiate Praxa with an agent ID, then call .log({ input, output, score, rationale }) after each decision. Every call appends to a per-agent SHA-256 hash chain. Each entry hashes the canonical event plus the previous entry's hash, so editing or deleting anything breaks continuity from that point forward. Standard pattern (git uses it, blockchain uses it), nothing I invented.
-
The wedge: open-source verifier on npm. @piposlabs/praxa-verify is MIT-licensed, zero dependencies, about 150 lines of TypeScript. Your auditor exports the chain from the dashboard and runs:
npx [@piposlabs](/piposlabs)/praxa-verify chain.json
The verifier and our production hasher share the exact same canonicalize() and a locked known-answer test, so they cannot quietly drift apart. If they did, your audit evidence would be worthless, and the verifier would fail noisily on the next run.
-
In-browser tamper demo, no signup. praxa.piposlab.com/playground. Five sample AI hiring decisions in a hash chain. Edit any score, or hit "tamper this record", and the verifier runs in your browser and shows you exactly where the chain stops matching. Five seconds, no account, no API key. The whole point of the product, made visible.
-
Evidence packs. Auto-generated reports mapping your log entries to the Article 12 §1(a)-(c) record-keeping requirements and the Article 26 deployer obligations. Same logs, framed for the auditor.
Pricing
Free up to 10,000 logged decisions a month. Starter is $79/mo for 100,000. Business is $249/mo for 1M plus the SOC 2 evidence pack scaffold. The free tier is real: the playground + the verifier + 10,000 decisions a month is enough for a small deployer to actually use this for their first six months of compliance, without paying anything.
Three findings that changed the build
I'm shipping today, so these are design and interview learnings, not customer cohort data.
-
The "I don't deploy AI" objection is the most expensive thing to break. Every team I talked to who'd shipped a ChatGPT-powered support reply, a Claude-powered code review, or an LLM-driven hiring screen genuinely thought the Act didn't apply to them because they "don't build AI." They deploy AI. The Act's Article 3(4) definition is broader than the popular intuition: a deployer is anyone using an AI system "under its authority" in a professional context. Half the launch-week inbound will be "wait, does this apply to me?", and that's why the playground has no signup gate.
-
The auditor URL was the real moat. I expected the SDK to be the moat. Two conversations with external auditors changed my mind. They didn't care which library generated the logs. They cared whether the audit URL was signed, version-pinned, timestamped, and verifiable by someone who has no reason to trust the vendor. The open-source verifier shipped specifically so the auditor doesn't have to trust Praxa: they run npx and compare hashes themselves. That changes how procurement-friendly the product feels.
-
Hash chain crypto is not a moat. AuditKit ships a near-identical hash chain as MIT open source. VeritasChain is an open standard. The crypto is a 100-line pattern any senior engineer can write in an afternoon. So the product is the packaging on top of the open hash-chain pattern: a three-line SDK call, an auditor-grade evidence pack, $79/mo instead of $50,000/yr. Distribution and packaging, not technology.
Where this goes wrong
Two honest limitations worth naming.
The evidence packs are jurisdiction-specific (EU first). The audit log mechanism is universal, but the evidence pack mapping is wired to EU AI Act + GDPR Article 5(1)(e). NYC LL144 wants bias audits, not crypto logs, and Warden AI owns that vertical. Colorado's SB 26-189 just got gutted to notice-only on 2026-05-14, and we removed the Colorado-specific copy the day after.
No customers yet. This is the launch. I'm shipping today. The "what I learned" section is from regulation reading and interviews, not customer cohort numbers. I will have the first real engagement numbers in the next 30 days, and I am happy to come back and share them whether they look good or not.
Try the playground
Five seconds, no signup, you tamper an audit chain in your browser and the verifier flags it:
→ praxa.piposlab.com/playground
If you want to verify that our chain serialization is honest, the OSS verifier is on npm:
npx [@piposlabs](/piposlabs)/praxa-verify chain.json
I would love feedback from anyone deploying AI inside the EU, anyone who has worked through an AI Act audit as a deployer or as an auditor, or anyone advising at a CNIL / BfDI / Garante. The open question I have is whether Member State authorities will cite Article 12 in their first 2026 enforcement actions, or wait for the higher-stakes Article 6 obligations to land in 2027. If you have been on either side of that conversation, I would love to know how you are calibrating.
Ten weeks of work, $79/mo, EU AI Act Article 12 deadline ten weeks from today.
Alex (Pipo Labs)
This is strong because you made the compliance problem visible instead of selling abstract “AI governance.”
The best part is the playground. A lot of tools in this space ask buyers to trust a dashboard, but your demo shows the actual evidence failure: change one record, the chain breaks, the verifier catches it. That is the kind of thing a compliance lead, auditor, and engineer can all understand quickly.
Praxa is a solid name, but I’d think carefully about whether it carries the full seriousness of the category you are entering. This is not just an audit-log utility. It is deployer-side AI compliance infrastructure: logs, evidence packs, verifier, auditor trust, and production accountability.
For that direction, Davoq .com would give the product a harder systems/security frame. It feels more like infrastructure that sits behind regulated AI decisions, not just a lightweight compliance add-on.
The product already has a strong wedge: $79/mo, open verifier, no signup demo, and a deadline-driven compliance problem. The brand should probably feel as durable as the evidence layer you are selling.
The 150-line verifier is the part I think the IH crowd will care about most: if the auditor has to trust Praxa to verify Praxa's own logs, the evidence is worth nothing. So we shipped canonicalize() + the verifier as the same code path under different distribution: production hashes events with it, the OSS package on npm verifies with it, and a known-answer test fails the build if they ever diverge. That's the only reason a SaaS-priced compliance product can produce evidence that an external auditor will sign off on without bringing their own tooling.
Thank you, this is one of the most useful comments we've gotten. You read it exactly right: the whole bet was making the evidence failure visible instead of pitching abstract governance, and the playground is the wedge precisely because anyone can break a record and watch the verifier catch it without taking my word for anything.
The naming point is fair and I won't pretend I haven't wrestled with it. Where I've landed for now: I'm betting the verifiability itself earns the seriousness more than the name does, since anyone can check the chain themselves. But I'm keeping the question open. Curious what made the systems framing land for you in your own work?