Security and data, as they are today.

No AI provider reads your documents by default.

A new organisation permits none. The first attempt to read a document fails, and names the organisation and the model. Authorisation is an operator command that records who decided, when, and on what stated basis. There is no fallback to a second provider if the first is refused, and a configuration that is merely absent never becomes consent. The Gemini API and Vertex AI are two subprocessors, and each is authorised separately.

In the demo, document text is sent to Google’s Gemini API over HTTPS. Whether that traffic falls under terms that exclude training depends on which Google surface and contract the API credential belongs to. Nothing in our system establishes or enforces that. The demo has one credential and one endpoint.

This is a gap in our own diligence. It is no finding about Google. Closing it means obtaining the provider’s terms for the specific surface we use, recording them, and making the deployment prove it is on that surface. It is on the list of conditions below, and it is not optional before real documents.

Where the model runs

The Gemini API endpoint the demo uses offers no EU pin. A European inference region needs a different integration. For the pilot that integration is now built: a pilot’s API reads through Vertex AI’s EU endpoint and refuses to start on any other AI surface. No customer document has been sent to it; in our own tests it has received public documents only.

We will not claim that a customer’s documents are processed in the EU before any has been.

The pilot’s AI provider: Vertex AI in the EU, as verified on 20 October 2026

What this section says about Google is Google’s documentation as we read it on 20 October 2026. What it says about ELARID describes our code on that date. None of it is assumed to stay true: a page, a model’s status or the terms can change after that date.

• A subprocessor of its own. Vertex AI and the Gemini API serve the same Gemini models under different terms. The Gemini API sits under its own Additional Terms of Service. Vertex AI is a Google Cloud service under Google Cloud’s terms. ELARID lists them as two subprocessors and authorises each separately. Since 22 April 2026 Google documents Vertex AI under a new name, the Gemini Enterprise Agent Platform.
• The EU endpoint, never the global one. Every call goes to Google’s EU multi-region endpoint. It is the only Vertex AI address the integration can build, and no setting names another. Google’s documentation says that this endpoint strictly covers data residency within EU member states, and that a request to a global endpoint may be processed in any Google Cloud location around the world.
• The model, as verified. The integration names one model, gemini-3.7-flash, which Google lists as supported for machine-learning processing in the EU multi-region. Google lists its retirement date as 28 January 2027, with gemini-3.8-flash as the replacement, also listed for the EU multi-region. After the retirement date a call to the model fails. Moving to the replacement is a deliberate change in our code, never a silent one.
• What we do not use. Google guarantees EU processing only for what it lists. ELARID makes one kind of call: a prompt, with the whole PDF attached when a document has scanned pages, and the JSON shape the answer must take. It uses none of the capabilities, features or consumption options that Google’s page marks as not supported there. It uses no grounding, function calling, code execution, tuning, batch inference or Live API, and it creates no context cache of its own. Google’s console sits outside the jurisdictional boundary and is never used with client documents.
• What Google’s page does not settle. It lists capabilities, and says nothing about kinds of input. It is silent, either way, on a PDF sent with the request, which is how a scanned page is transcribed.
• What every call records. The record of each AI call names the provider, where processing was promised (EU, or unpinned for a surface that promises nothing), the model requested, and the model version that answered, recorded only when the response states it. The version is never inferred from the model’s name. The database refuses a row that claims EU for any provider but Vertex AI.
• Not here yet. What Google’s contract says about training and retention is recorded when the contract exists. It will not be taken from a web page alone, and it is not recorded before then.

Google’s pages behind this section

Each date is the one the page itself carries.

• Data residency. The EU multi-region, the models listed for EU processing, and the global endpoint. Dated 15 October 2026.
• Supported capabilities. What is and is not covered on the multi-region endpoints. Dated 15 October 2026.
• Locations. The EU endpoint and its location. Dated 19 October 2026.
• Model versions. Release, retirement and replacement. Dated 19 October 2026.
• Release notes. The new name, from 22 April 2026. Dated 15 October 2026.
• Gemini API Additional Terms of Service. The terms of the Gemini API. Dated 28 April 2026.
• Google Cloud Service Specific Terms. The terms for Vertex AI as a Google Cloud service. Dated 12 October 2026.

The pilot’s separation of managed storage from compute is what narrows it.

Reads are recorded, before they are answered

The product records every time it serves a person one of your documents, a quoted passage of one, or what was read from one: the findings, the evidence trace, the guarantee position, an evaluation, a document read again. The record says who, what, when and which request. It is written before the answer leaves. A read that cannot be recorded is not served.

If you ask who at ELARID looked at your file, we answer from that record. It sits in the audit trail, which the application can add to and cannot change or delete. It outlives an erasure, because that is when it is asked for.

It records what was served, which is more than what was looked at, and never less. The portfolio page reads every project’s findings to say what is waiting where, so opening it records each project as served. A page shown again or refreshed records again.

What it does not hold

Lists of your projects. Lists of the documents a project holds, with their names and the issuer, number and date read from each. Lists of a document’s processing stages. The answer to an upload, which reads the file back to the person who just provided it (who provided it is recorded on the file itself). A read made outside the product, by an operator at a database prompt or by the nightly backup, is not a person at a screen and is not in the record.

Encryption at rest for the database is still on the list of conditions. We would rather have this section read badly now than have you discover it later.

Deletion

Deletion is an operator command. There is no background job and no self-service button. It runs under a database role that exists only to delete. That role can see and destroy customer data, and it holds no power to change the schema. Those are two different authorities, and we keep them apart.

The command takes the organisation identifier typed back by hand, removes stored objects first, and reads each key back to confirm it is gone. Only then does it record what it removed. If even one object survives, the run does not report success. Running it twice is safe. It refuses to start on a storage bucket that keeps earlier versions of an object, because there a key reads back as gone while a copy is still stored. Our buckets are to be created without versioning, and the command checks that before it starts.

What remains afterwards is a receipt: counts by table, who asked, who ran it, and when. It holds no content.

What survives an erasure today

• Stored files: nothing. Until 23 September 2026 the prompt sent to the model, which carries your document’s text, was stored as an object the erasure could not reach. We found it by checking, and it is fixed. The record of each model call now names the document version it read, so the erasure follows that link, removes the object and reads the key back like any other. A second such field was found by the check we built afterwards, before anything had written to it, and was closed the same way.
• Files rejected by the malware scanner. When a single project is erased, they are kept for the organisation and their content hash only, so they cannot be told apart per project. Ending the engagement erases them.
• The receipt and the audit record of the erasure itself. This is deliberate. Deleting the record of a deletion is how a deletion becomes unprovable.

The whole deletion window

We cannot yet state the whole deletion window in days. The honest sentence has four parts, and on a pilot the last three are planned and not yet running.

Live systems

Removed when the command reports success: immediately.

Database provider’s history

Kept for up to 7 days. That is a setting of ours, and the provider’s default is one day. Until then an erased row can still be restored, by us.

Copies under our control

Deleted within 30 days. A pilot’s daily backup can be restored for 20 days, and every copy of it is gone within about 28, which is within 30 even when two nights’ backups fail.

The nightly backup is what deletes the old copies. If it stopped, nothing would delete them until it ran again, and its stopping is what the alert reports. The mechanism is built and has run only against local stand-ins. The backup storage’s own snapshot plan, which that number counts on, has not yet run.

A branch that a database restore leaves behind is deleted by hand once the restore is accepted. If we restore an earlier backup, the erasures recorded in the newest backup are listed and run again. An erasure made after the newest backup, if the live database is lost at the same moment, is in no copy. We keep the line that runs it again outside the server and run it by hand.

Not yet stated

How long the database provider’s internal backups persist after its history window, where its own documents disagree. How long the AI provider keeps the page text we send it. We will put both questions in writing when the pilot’s contracts are signed, and publish the answers as the providers give them.

Backup and restore

Today nothing has been restored on real infrastructure, and the product is not hosted. Hosted, the demo’s backup would be a snapshot of the whole server. That is one failure domain: application, database, documents and queue together. The recovery point would be up to roughly a day. A snapshot of a running database is crash-consistent. It is not a clean backup.

Built for the pilot, and rehearsed only against local stand-ins on 11 October 2026: a daily backup of the database and the documents to a Storage Box in another city, encrypted, restorable for 20 days and deleted within 30.

While the server runs and reaches our mail provider, a failed or missing backup sends an alert to a person. Nothing checks from outside the server yet.

A scripted restore brings a backup back into a scratch database and scratch storage. It checks every table’s row count and every document’s size and checksum against what was backed up. It opens every document with the key and compares it with the SHA-256 fingerprint the database records. It lists the erasures to run again. On our machine, against the stand-ins, it took seconds. On real infrastructure it has not run.

Before any real document is accepted, the pilot brings four things: a managed database with point-in-time recovery, object storage in a separate failure domain, an automated backup of the database and the documents kept off the server, and a rehearsed restore. A rehearsed restore is one we have actually performed and timed. A configured restore does not count. A pilot instance refuses to start until the day of that rehearsal is recorded.

When a pilot ends

Your documents and everything derived from them are erased on request or at the end of the engagement, by one command that runs the erasure above for every project, and more. You receive the receipt.

What that leaves is stated here because you should not have to ask. Closing an engagement erases the data and revokes everyone’s access. Your organisation remains as an administrative record: an identifier, a name, a creation date, and nothing else.

It is kept because the erasure receipt and the audit trail both point at it, and a record that proves a deletion happened cannot outlive the thing it points at if that thing is removed. So the choice is between keeping a name and losing the proof, and we keep the proof. With it stay the records that point at it and hold none of your content: the memberships, marked revoked; the audit trail, reads included; our recorded decisions about which providers may process your data; and the receipts.

One command covers the whole engagement, with one receipt that says all three things: data gone, access revoked, administrative record remaining. Access ends first, so nothing can be uploaded while the files are deleted. Then everything stored under your organisation goes: the files of every project, files the scanner refused, and anything an interrupted upload left, each one read back to confirm it is gone. Then every project’s records go, in one transaction that checks nothing of your organisation is left behind before it commits.

Removing a person’s access takes effect on their next request. Membership is read from the database on every call, so a revocation does not wait for anything to expire. Membership is revoked and kept, so who had access, and until when, stays answerable afterwards.

That ends their access to your organisation. It does not end their session: they remain signed in, as a person who is now a member of nothing. Ending sessions outright is a separate operator action, and it exists. One person’s sessions, or every session in the deployment, can be ended at once, with a stated reason that is recorded and cannot be left blank. It is the answer to what we do if a token leaks. It does not disable the account. Stopping somebody from signing in again is a different authority, and we keep the two apart so that an incident response does not quietly lock a person out.