OBVELO

Personal data stays with you, the question goes to the model

The gateway sits between your application and the model provider. It finds personal data in the text, replaces it with tokens like [Person 1], passes the request on, and puts the real values back into the answer. The model never sees a name.

Three steps, and one field to change

1. Open an account

An e-mail address and a plan. Confirmation arrives by mail; you mint the key yourself in the panel.

2. Change the API address

The same protocol as your model provider's. Your credentials pass through the gateway to them — we never bill their traffic on our contract.

3. Check what went out

The console shows the masked text exactly as it left your infrastructure.

What "sovereignty" means here, concretely

Sub-processors in the EU and EEA only, written into the register of processing activities before deployment. The image carrying the name model has no network access — not "does not use it", but has no permission for it, and that is checked by a test on every change.

The data plane stores nothing from the content of a request: dictionaries and patterns travel with the call, transcripts are never written, logs carry no content. The control plane — this shop — stores contract data: the account, the plan, usage in numbers. It never sees content.

The gateway is a risk mitigation and control point, not a certificate of compliance. We do not sell the sentence "100% GDPR" and will not write it in any document — compliance depends on what you do with the data, not on one component in a pipeline.

One account, many systems, different rules

A key is a system, not a person. Give the helpdesk, the contract robot and the assistant in your CRM a key each, and pin a different rule profile to each key — its own jurisdictions, its own selection of detection rules, its own tool allowlist.

The profile belongs to the key, not to a header. That distinction is the whole point: a profile selected by a request header is selected by whoever is calling, so any system could claim any other's rules simply by naming them. Pinned to the credential, it cannot. Without this, one key has to carry the strictest rules any of those systems needs — and that is how a privacy control ends up being switched off by the person who wanted it to work.

What the audit journal can tell you — and what it cannot

Every governed action is written down without any content: which account, which key, which tool, allowed or refused, how long it took. Tool names appear because they are your own schema; arguments, results and token maps never do.

The journal names the key, never the label you gave it. The label is your free-text field and you may well have typed a person's name into it; keeping that in our logs would make it personal data we hold on your staff. You resolve the key id in your own panel, where the mapping stays yours.

Said plainly, because the opposite is what gets sold: this answers who sent this and who approved this action. It does not answer who caused a leak. A leak is by definition something we did not recognise, and nothing can record what it never saw. Anyone promising you that answer is selling you data-loss prevention, which this deliberately is not.

Two documents, masked separately, never get mixed up

Two people in your organisation mask two different case files at the same moment, and later an agent puts both into one thread. Each token carries a namespace unique to the session that minted it, so the first file's [Person 1] and the second file's are never confused for one another.

Without that, restoring the merged thread can put one client's name over another client's matter — not a leak, but a record that is wrong about who did what, and one that looks entirely successful from the outside. The namespace is sized so that a collision is far less likely than winning a lottery and being struck by lightning as one event.

Pricing

Billing is per character — engine cost grows linearly with the length of the text, so the unit is the same in every plan. The hard limit is on by default: overage is bought deliberately.

No seat limit on any plan. Put your whole organisation on one account — we never count people, because we charge for characters, so a colleague costs exactly what they send and nothing for existing. What a plan does limit is gateway keys, and that is a different question: a key is a system, not a person. Give the helpdesk, the contract robot and the assistant in your CRM a key each and they can carry different rules — one key for all three means the strictest rules any of them needs apply to every one of them.

Plan Per month Characters included Overage / million Requests / min Gateway keys Included Browser extension
Loading the price list…

Prices exclude tax. The rate depends on the buyer's country and VAT number, which you give in the panel.

Open an account

We send one message with a confirmation link. The link is one-time and expires; it carries no key and no password, because mail between servers is not a channel those may travel on.

The enterprise plan is on a contract rather than from the panel — write to us. Every example here is fictional.