Architecture & security
Where your data lives. And what does not leave it.
This page is written for a security officer. The full journey of a file, what stays with you, what leaves, the key, the logs, the telemetry. Answered in advance, and verifiable.
01
The journey of a file, end to end.
here
stand-in identities
The substitution is reversible and consistent: the same person keeps the same stand-in name across every piece of a file, which lets the AI reason correctly without ever knowing the real identity. It is reversible de-identification, what the GDPR calls pseudonymisation: the data remains personal information, under your control, and only what is necessary travels. The elements needed for reasoning may stay readable (event dates, amounts, context), while the protected identifiers are replaced before sending.
02
Where each thing lives. And what is transmitted.
03
The questions a security officer asks. Straight answers.
Where is the original data stored?
On the client’s machine or server, never elsewhere. The document, the index, the lexicon and the log live on your disks, under your backups, under your jurisdiction, wherever you are.
Where is the mapping table?
At your site, with your data. It is what restores the real identities. It never leaves the machine and is never sent to the AI.
Is there a central AIDataVeil server?
No, and it is not even reachable. No remote service is required to process your files. The product runs within your walls.
Is there telemetry?
None. An internal guard refuses by default any destination outside a whitelist. That list contains only the AI provider you choose and the local loopback. A call to us would be blocked by the product itself.
What do the logs contain?
Technical metadata, never content. Method, category, count, status, timestamp. Not an excerpt, not a real value, not even a substituted one.
Can the vendor administer the machine?
No. No remote access, no account with us, no admin channel. Updates arrive as a signed package you install yourself, or with us, on site.
What communications go out?
One, necessary: to the AI provider you choose, and it carries only the protected version. That destination is documented and controlled; any other is refused.
What if the engine fails?
Nothing leaves. The product is closed by default: if protection cannot be guaranteed for a send, the send is refused, never let through “just in case”.
Can a stand-in name betray the real identity?
No. It is derived by a cryptographic computation (HMAC) from the value and your organization’s key: without that key, there is no way back from the fake to the real, nor to guess the fake for a given name. The only way back is the mapping table, which stays with you. Fake phone numbers and emails are drawn from ranges reserved for fiction, which can belong to no one. One honest limit: a plausible fake number can, by pure chance, match a stranger’s. That is true of every generator in the world.
What if an employee bypasses AIDataVeil?
What does not pass through the veil is not protected. That is why it sits in front of your existing tools instead of adding one: the protected path becomes the normal, everyday path. The rest belongs to your usage policy, and the technical register shows you what went through the veil.
04
Don’t take our word. Verify.
The software is signed
It arrives as a container sealed by digital signature. Its integrity is verified offline, before installation, with a public key. You prove that what runs is what we delivered.
The outbound is bounded
A guard refuses by default any destination outside the list: AI provider and local loopback. Not a policy; a mechanism, active at every call.
The attestation is defensible
On request, a signed certificate states what left: in counts by category, never in values, with the measured leak rate. It verifies without us, with a public key.
The rest, we show you on your own files.
A technical demonstration, with your people, on texts that look like yours. You leave with the full reference architecture.
Request a demonstration