The open-source engine has been doing its job for a while now: 31 country rulesets, deterministic detection of structured identifiers, no network calls, running wherever you put it. It is good at the things a rule can describe — a BSN with a valid checksum, an IBAN, a Steuer-ID.

It is, by construction, useless at the things a rule cannot describe. A name is not a pattern. Neither is an address embedded in a sentence, or a sickness mentioned in passing in a case note. That is the gap euRedact Cloud closes, and it is now running in closed alpha — built, deployed, and processing real documents end to end.

This post is a status update, not a launch. There is no signup link that gives you an API key today, and we should be straight about the size of the alpha: the group running documents through it is small, and most of those documents are still ours. That is what this stage honestly looks like, and we would rather say it than imply a customer list we do not have.

What has changed is that the thing exists. It is built, it works, and it has stopped being honest to describe it as "coming soon" without saying what it actually is.

What it does that the SDK can't

The cloud tier adds a neural detection layer for contextual and unstructured PII — the categories no pattern can catch. Names, addresses, the free-text mentions of health information that make a case file a special-category document under Article 9.

The architecture is the part worth explaining, because it is the part we would want to know about if we were evaluating someone else's redaction API.

Structured PII never reaches the model. The open-source engine runs first, on your side, exactly as it does today. Everything it can resolve — the identifiers, the account numbers, the checksummed national IDs — is resolved locally and removed before anything is sent. What crosses the wire is a document that has already had its most sensitive, most immediately identifying content taken out of it.

Only what the rules could not resolve is sent to the model, and the model is asked a narrow question: what did the rules miss?

That ordering is not an optimisation. It is the difference between a service that sees your raw documents and one that sees a partially redacted version of them. We built it that way because we did not want to be a company that holds a corpus of European personal data, and the cheapest way to guarantee that is to never receive it.

Where it runs

Inference runs on European infrastructure in France. Document text does not leave the EU, and there is no US-operated service anywhere in the path a document takes — not for hosting, not for compute, not for the model.

That claim is only worth as much as the architecture behind it, so: the service runs on a single public entry point, with the database and the GPU nodes on a private network with no public address at all. The machines that run the model cannot be reached from the internet, and there is exactly one door into the whole system.

Zero data retention

This is the part we care most about, so we will be precise about it.

Zero data retention is the default. Not a premium tier, not a support ticket, not a checkbox you have to find. Every account gets it on day one, and your document text is destroyed as part of the same operation that returns your result. Not deleted overnight. Not expired out of a cache. Not "retained for up to 24 hours for quality purposes". The row that held your text is emptied at the moment the answer leaves the building, and after that there is nothing left to leak, subpoena, index, or accidentally train on.

An account that actively wants a short retention window — to retry a failed call, or to look at what came back from a bad one — can switch one on, and it is then swept on a timer. That is a decision you make deliberately. It is not a default you have to discover and undo.

And not in a backup either

This is the question a data protection officer asks second, and it is where most zero-retention claims quietly come apart. Deleting a row from the live database means nothing if last night's snapshot still holds it: "erased on delivery" becomes true of production and false of the copy sitting in a bucket, for however long that bucket keeps things.

So, plainly: document text is erased on delivery, is never written to any backup, and no provider-side snapshot of it exists.

Our managed database provider's own snapshots are switched off, deliberately. A volume snapshot has no notion of a table — it captures whatever was in flight and keeps it for the provider's retention window, which would have made everything above a statement about the live system only. Our own backup excludes the table that holds document text: the schema is dumped, the rows are not. What gets backed up is the business — metering, accounts, keys, the audit trail. A document is never the business.

There is no "deleted within N days" here, because there is no N.

What we do keep

One thing survives, and we would rather name it than have you find it: the usage record. Counts, token totals, timestamps, whether the call succeeded — the numbers an invoice is computed from and the fleet is sized against. It describes the call, not its contents. There is no document text in it, no detected entities, and nothing in it from which what you sent could be reconstructed.

That separation is structural rather than a matter of discipline: the usage rows are written to outlive the jobs they describe, precisely so that deleting the document changes nothing about our ability to bill correctly. The two were never the same record.

Put it together with the architecture above and the guarantee compounds:

The open-source engine strips structured PII before anything is sent, so the identifiers never leave your infrastructure at all.
What does get sent is a partially redacted document, held only as long as it takes to answer.
By default that is zero: the text is gone when your response is.
And it was never copied anywhere else on the way — no snapshot, no dump, no second home.

So the honest answer to "what do you hold about our customers?" is: how much they used, and nothing about what was in it.

Can you actually check that?

Not from the outside — and you cannot with anyone else either. Nobody can prove a negative about someone else’s database across an API, and a vendor who offers you a "deletion confirmed" endpoint has given you a string, not a guarantee. So rather than claim verifiability we do not have, here is precisely what you get.

The erase is not a separate step that could fail on its own. Emptying your text and recording your result as delivered happen in the same database transaction. They commit together or not at all. There is no ordering of events in which you received an answer and the text outlived it, because the two are one write.

There is no second copy to go looking for. A deletion claim usually needs a footnote about backups. This one does not, because the backup was built to exclude the table in the first place — the absence is a property of what we back up, not a promise about what we remember to clean.

Your setting is readable, not just stated. The console reports your workspace’s retention mode back to you, and if an operator ever changes it, that lands in an append-only audit table enforced by a database trigger — a row nobody here can quietly delete, us included.

And the part that actually counts legally: Article 28 gives you, the controller, the right to audit us, the processor. That right will be written into the DPA rather than left implied. Verification of a deletion claim is contractual and evidential — it always has been, for every processor you use. Anyone selling you an API call instead is selling you a feeling.

What we do on our own side: a test in our suite submits a unique string through the entire system, then greps every log line and every text column of every table to prove it did not survive. We wrote it for ourselves, before a customer or an auditor asked. Today it runs against a test database in CI. Running it against production on a schedule and publishing the result with a timestamp is the strongest thing we could hand you short of an audit, and it is the next thing we intend to build.

What's actually left

Most of the platform is built and running: the gateway, the queue, the metering, the customer console, the retention enforcement, the audit trail. Adding inference capacity is booting another machine; nothing needs reconfiguring when we do.

There is still technical ground to cover. Some of it is hardening, some of it is the unglamorous work of being sure rather than fairly confident, and we would rather spend that time now than explain later why we did not. That work is in progress.

Alongside it sits the legal surface:

The data processing agreement. Ready to sign is not the same as drafted. If you are going to send us documents, your legal team needs a DPA that survives their review, not ours.
The sub-processor list. Published, specific, and kept current. We have been through our own estate to work out exactly which companies can touch customer data and which cannot — it is a shorter list than we expected, and we would rather publish the short accurate version than a long defensive one.
The records of processing, and an incident response plan written before it is needed rather than during.

None of this is exciting and all of it has to exist before we can responsibly take a paying customer's documents. We are working through it now. When it is done, we will say so here.

The demo may get real

Today the demo on our homepage and on /demo runs the open-source engine in your browser. Nothing is sent anywhere — which is honest, and also means it only ever shows you half the product. It cannot find a name, because the rules engine cannot find a name.

We are considering wiring that demo to the actual inference stack, so that what you type gets the full treatment and you can see the neural layer catching what the rules miss, with each detection labelled by which stage found it. That is the most direct way we can think of to show the difference rather than describe it.

It is not a promise, and the reasons are not only technical. A public endpoint pointed at a GPU has a cost profile and an abuse profile we would want to be comfortable with. It also means strangers pasting whatever they like into a box that reaches real inference — and what that makes us, and what we owe the people whose data might end up in that box, is a question we are working through with our lawyers rather than guessing at. Some of the same paperwork above has to land first.

The plumbing exists. We would like to do it. We would like to do it correctly more.

If you want to be in the alpha

The alpha is closed and deliberately small. We are not trying to scale it; we are trying to find the documents that break it.

If you work with European documents at volume — case files, claims, HR records, support transcripts, anything where a name in a sentence is a compliance problem — put yourself on the list. The form asks for an email and nothing else; when we come back to you, the first thing we will ask is what you would want to run through it.

The ones we are prioritising are the awkward ones: multilingual, badly OCR'd, full of the kind of formatting that makes a clean benchmark look optimistic. If that describes your documents, say so when we reply and you will move up the list.

In the meantime the open-source engine is there to use, free, and will stay that way. The cloud tier is an addition to it, not a replacement for it.