Sovereignty is not a policy promise: it is the consequence of architecture decisions you can audit. This page is the list of those decisions, in the order an auditor would check them, and it ends where every privacy page should begin: at what you can verify without taking our word for it.
Audit the schema: sovereignty you can verify
SazAI’s platform tables hold structure, measurements, relationships, and lineage. They do not hold the content of your documents. Raw text lives in your organization’s own schema. The application reaches it only through your organization’s own database roles, and the database itself filters every row by its owner. It stays there for as long as the document exists and never enters the platform tables.
This is not internal policy, it is a property of the design, and it is verifiable in the most direct way there is: read the definitions of the platform tables and look for the column that would hold your document’s text. It does not exist. What they keep are names, as structure: the file name, including the names of its outputs and the name you give a document you write; a workbook’s sheet names, because formulas refer to them; and the labels you give your glossaries and keys. You do not need to trust a privacy page if you can audit the schema, and that is the proof we like offering most, because it does not pass through us.
The practical consequence matters to anyone working under LGPD: aggregate analysis of platform usage happens without exposing content, because the content is not there to expose. Corporate glossaries live in your organization’s own schema, because terminology is an asset and no other organization’s role can read it.
What leaves your control zone
In a SazAI installed on your own infrastructure, the entire system runs inside it, and the only external destination for processing is the language model you chose and contracted, which can sit inside your own zone. The application does not fetch third-party libraries at runtime, does not load fonts from external servers, and does not depend on anyone else’s cloud to function. Every external runtime dependency is a place where a piece of your traffic, or the information that it exists, leaves your network; a system without those dependencies does not need to promise it will not leak through them.
Two boundaries are part of the claim, not footnotes to it.
The first is identity. Federated sign-in today passes through a cloud identity provider. For an installation that uses that sign-in, a second external destination exists besides the model, and the sentence above is literal in only two situations: API-key authentication, or the identity provider sitting inside your zone. Bringing the provider inside the zone is direction declared on the platform roadmap, not something delivered today.
The second is the difference between running and building. At runtime, the system is closed. Building the image downloads dependencies, like any software built this century. Mixing the two questions would turn a true claim into a technical lie the first time an auditor opened the build file.
The core does not know who you are
The engine that reads and writes documents is blind to authentication, billing, and permission: it receives already-validated identifiers and executes. What decides what you can see is a layer above, crossed on every operation. A permission failure cannot turn into a leak between organizations through an internal path in the engine, because the engine does not know another organization exists.
Isolation between clients is not assumed: it is tested with probes that actively try to cross the boundary, including in production, with the result recorded. Files stay inside your organization’s space, separated by tenant and by user, with access validated on every operation. Sharing between users exists and is explicit: a shared vault is read-only, with the source identified on screen.
Deletion as record, not as forgetting
When you delete a document, the sensitive fields are erased in the record itself, not flagged as hidden, and the deletion is recorded as an event in sequence. The document stops existing for every surface that shows content, and the history keeps its name, marked as withdrawn; derivatives are handled together with the original instead of becoming orphans. The system does not erase the memory that it erased, and that is what makes it possible to prove afterward that the deletion happened, and when.
Said as a form, because it is the whole model in one line: deletion erases the working half and leaves a headstone in the permanent half. What survives is a record without content: an identifier, a date, an organization, the document’s name and what was done with it, marked as withdrawn. It is not a retained copy of your document, it is proof that it was removed. That is what produces the sentence a buyer can check alone in the schema: we know where your document passed through and what was done to it, and we do not know what it said.
Today’s reach has a limit, stated plainly: backup copies made before the deletion still contain the content, for a retention window of up to seven days, and a disaster restore from one of them would reintroduce content already deleted. The mechanism that closes that is defined, since a restore can replay the deletions recorded after that copy’s date, and it is not built yet. Until it is built and measured, this page will not say that deletion reaches the backup copies.
You can remove everything at once and deactivate your account yourself, from the menu of your vault, with the same reach described above. The name is the correct one. It erases your content, and your name and email from SazAI’s records, and deactivates the account; what stays has no content, no name and no email in it: that an account existed and when, that this erasure happened, and a record of the account’s activity with no name attached, such as the kinds of files, the languages, the amounts, the actions taken and the dates, which we keep for billing and audit. It closes your account, not your organization: if you are its last member, the organization stays, with none of your content in it, until it is closed separately.
Portability: what leaves with you
Your files were always yours, and handing them back is nobody’s credit to claim. What matters is what was built on top of them: the organization, the relationships between original and derivatives, the measurements, the history. That body of knowledge is materialized as a vault of plain text files linked to one another: queryable from outside, exported on request, and functional away from here, in an ordinary notes tool, on your own computer or your own server.
The same knowledge is reachable through a programming interface and through the protocol AI agents use to connect tools, so your own agents can query the vault without going through our interface. A product that is only useful from inside itself holds you through dependency; this one prefers to hold you through value.
Two things stated before you find them out: language switching belongs to our display layer, so you take the vault away in the language it was written in; and portability does not yet have a published demonstration that anyone can reproduce without talking to us. Until then, it is a due-diligence conversation: ask for the export in an evaluation, open the result in your own tool, and verify it with your own hands.
The boundary, declared by us
Translating and examining require sending text to a language model, and what happens on the other side depends on the contracted provider, not on our architecture. The provider’s retention regime is a matter of contract with them, and the correct answer for a privacy area is the contract, not a sentence of ours. In an installation of your own, the provider is your choice.
Anything the AI assistant you connect to SazAI Corpus reads from it, document text included, goes to that assistant’s provider (OpenAI for ChatGPT, Anthropic for Claude), under that provider’s terms, not ours.
The AI assistant you connect to SazAI Corpus, such as ChatGPT or Claude, can also show, when it asks for them, the names your documents record about the people, and the machines, that worked on them:
- who created each file, who last saved it, the manager and the company it names, and a PDF’s author;
- who made each tracked change in a Word document, who wrote each comment in a Word, Excel or PowerPoint file, and who wrote each annotation in a PDF;
- who signed a PDF, and the contact details the signature gives;
- the people a Word, Excel or PowerPoint file lists as its co-authors, with the account it records for each, such as an email address;
- the printer named in a Word, Excel or PowerPoint file, and the software each step of a PDF’s edit history names;
- the value of any custom property added to a file, because it can hold a name.
This is on. When the assistant retrieves any of these, they are sent to it, whether or not its answer repeats them. They are what the file declares, not identities anyone verified. This paragraph is pending legal review.
And what this page does not claim, on purpose: we are not certified against any standard, and our history of decisions and records serves as evidence of control without us claiming it closes a specific formal requirement in your sector. Bring the requirement and the answer comes item by item, case by case. The receipt for each delivery, and where it ends, is in trust.
What we measure on public pages
The public sites (sazai.app and ui.sazai.app) use Google Analytics 4 to understand which pages are visited, which areas draw interest, and where visitors come from: page views, clicks on product sections, language, and device type. Measurement is off by default and activates only after you accept the consent notice. All requests flow through our own domain; IP addresses are anonymized; we do not use advertising features or cross-site tracking.
If you decline, or simply ignore the notice, nothing is measured. The pages work identically either way.
What we never do in the vault
The authenticated product, your vault, carries zero analytics. No tracking scripts, no beacons, no third-party requests. The only cookies present are the session cookies that keep you signed in. On sazai.app, product usage is accounted for by our own internal metering, which exists for billing and capacity: it records actions, never content, and never leaves our infrastructure.
Your account and identity
Sign-in runs through our identity provider (Zitadel), optionally through your organization’s Microsoft account. We hold the minimum: your name, email, and the tenant your invite binds you to. Access to a vault is granted by invitation only.
Cookies
| Cookie | Purpose | Surface |
|---|---|---|
| Consent choice | Remembers whether you accepted or declined measurement | Public pages |
| Session | Keeps you signed in | Vault |
| Preferences | Language and theme choice | All surfaces |
No advertising cookies. No cross-site identifiers.
Infrastructure
SazAI runs on Amazon Web Services (United States). All traffic is encrypted in transit; tenant workspaces are isolated from one another. For organizations that require it, SazAI is also offered as a dedicated, self-contained installation on the client’s own infrastructure, with the properties described at the top of this page.
Your rights under the LGPD
The Lei Geral de Proteção de Dados (Law 13.709/2018) grants you the right to access the data we hold about you, correct it, delete it, receive it in portable form, and revoke consent at any time. Revoking measurement consent is immediate: decline on any public page. For anything else, write to contact.
Privacy requests: ask@sazai.app. Last updated: 2026-10-16.