Compliance you can verify, not just believe

A bank runs 50,000 client-advisory conversations a day through an LLM. Under the EU AI Act it is required to keep an automatic, inspectable log of every one of them — and under GDPR it is required not to retain the personal data those conversations are saturated with. Both obligations are mandatory. Both are in force today.

That bind isn't unique to banks. If you deploy any high-risk AI system in the EU, you're caught between two laws that point in opposite directions.

The EU AI Act (Articles 12 and 19) says you must keep automatically-generated logs of every high-risk AI interaction — a durable record an auditor can inspect.

GDPR says you must not retain personal data you don't need.

Log everything. Keep nothing. Those can't both be satisfied by a normal logging pipeline, because a normal log of AI prompts is full of personal data. We call this the Article 12 Paradox, and it's the actual reason CloakLLM exists.

The resolution

There's exactly one way to satisfy both obligations: strip the personal data before it ever reaches a log. Detect the PII in a prompt, replace it with reversible tokens, and write a hash-chained audit record that contains zero original PII — only hashes, token counts, and the structural evidence a regulator wants.

That's CloakLLM's core: detect, tokenize, and write tamper-evident, no-PII audit logs, with the EU AI Act's specific obligations (Article 12 record-keeping, Article 19 auto-logs, Article 4a bias-detection, Article 50 content-labeling) built into the structure. It runs as middleware in front of your LLM calls, so the protection happens before prompts leave your infrastructure.

This is the mature, load-bearing part of the product — heavily tested, shipped across many releases, and in real use (the packages pull ~1.9k downloads a week). None of it depends on anything exotic.

And the detection itself is measured, not asserted. The number that matters is character-level scrub rate — what fraction of the sensitive characters actually get removed before anything is logged — measured on a deliberately messy benchmark: PII in the formats people actually write, not the clean ones test suites prefer. A credit card with spaces (4111 1111 1111 1111). A German IBAN broken into groups (DE89 3704 0044 0532 0130 00). An IPv6 address. Names and addresses in several languages.

On that hard set, CloakLLM's default detector (regex + NER, no cloud calls) scrubs ~94% of the planted PII — and 100% of the common contiguous formats (emails, SSNs, single-string cards, IPv4, API keys). That 94% is honest, not flattering: the benchmark exists precisely because it once caught us leaking. When it found that space-grouped cards and IBANs were only partially removed, the fix shipped the same day and the benchmark became a release gate every future version must pass. That is the posture of this entire piece — measure the promise, publish the number, fix what leaks. Don't ask anyone to take "it detects PII" on faith.

The part most compliance buyers miss: you don't have to trust the vendor

Here's the property that should change how you evaluate compliance tooling.

Most of it is a black box. You send your data somewhere, and a vendor tells you it's compliant. You're trusting their word, their security, and their data handling — often the very data-retention problem you were trying to avoid.

CloakLLM is the opposite. It produces artifacts that verify on their own:

• No-PII audit logs — anyone can confirm the log contains no original personal data.
• Hash chains — anyone can recompute the SHA-256 chain and detect tampering.
• Ed25519 signatures and KeyManifests — anyone can verify them with standard crypto.
• RFC 3161 trusted timestamps — anyone can verify them with OpenSSL, not just CloakLLM's own code.

When a regulator asks "prove these logs weren't backdated, contain no PII, and weren't tampered with," you don't answer "our vendor says so." You hand over evidence that checks out independently. That is a fundamentally stronger position — and it means you don't have to trust CloakLLM's implementation to trust the result.

It also changes what your provider can be compelled to hand over. If a US government subpoena reaches your LLM provider under the CLOUD Act, what it yields is tokens — [PERSON_0], [EMAIL_0] — not your customers' personal data. That is a structural property of stripping PII before the prompt ever leaves your infrastructure, not a contractual promise a vendor can quietly revise. No data-processing agreement can offer that; only architecture can.

Why this beats the alternatives

• Build it yourself. You'd write PII detection, tokenization, tamper-evident no-PII logging, and EU-AI-Act-structured reporting. That's more unaudited code that you wrote — and you'd still need a security review.
• A closed compliance SaaS. A black box. Usually involves sending your data to a third party. You can't audit it, you can't self-host it, and you're back to trusting a vendor's word.
• CloakLLM. Open-source (MIT), self-hosted (no data leaves your infrastructure), purpose-built around the specific articles, producing independently-verifiable evidence. The security audit any serious compliance posture needs is cheaper and actually possible — because the code is open.

The honest boundary — and why stating it is the point

Here's what we'd say plainly to any buyer, because saying it plainly is what makes a compliance product credible:

CloakLLM is the infrastructure layer that makes compliance achievable and provable. It is not a legal guarantee or a compliance certificate. No software is that. Any serious EU AI Act program involves your own legal and security review regardless of the tooling you choose.

For the newest, most security-sensitive features — like the RFC 3161 trusted-timestamping crypto — the prudent path before you lean your entire regulatory defense on them is to commission an independent cryptographic audit and use an eIDAS-qualified Time-Stamp Authority (so the timestamp carries legal presumption of accuracy under eIDAS Article 42). That crypto is already differentially tested against OpenSSL — both SDKs must reach the same accept/reject verdict as a reference implementation, across a committed corpus — which is strong, independent corroboration; it just isn't a substitute for a formal third-party audit. That's not a knock on CloakLLM. It's standard prudence for any compliance stack — and CloakLLM being open, self-hosted, and verifiable is precisely what makes that prudence cheap to exercise. You can't audit a black box; you can audit this.

The bottom line

You use CloakLLM for EU AI Act compliance because:

1. It solves the real, hard problem — the Article 12 Paradox — with a mature, tested core.
2. It produces evidence you don't have to take on faith; your auditor verifies it with standard tools.
3. It's open-source and self-hosted, so it's auditable and your data never leaves — in a way no closed alternative is.

Compliance you can verify beats compliance you're asked to believe. That's the whole pitch — and it's the kind of pitch that gets more convincing the more honestly you state its limits.