Isolation: two layers, and both test themselves
Isolation between client companies does not rest on a WHERE clause hand-written into every query. It lives in two independent places: row-level security policies in the database, which the engine applies even if the application code gets it wrong, and a separate collection per company in the vector store, which is a different system with its own boundary.
Both layers have automated tests that try to cross the boundary and fail the build if they succeed. Those tests existing is, to us, the only security claim that means anything: anyone can say their data is isolated.
Inside each company the same idea repeats: every department has its own knowledge space, likewise enforced in the database. It isn't a cosmetic filter in the interface, which is exactly where most corporate assistants leak.
People's data doesn't go into the search index
Employee and client records (ID numbers, financial data, sick leave situations, contact details) are not vectorised and do not pass through semantic search. They are outside that circuit entirely. Every access checks the exact permission on the server, query by query.
The reason is that semantic search finds what is most relevant to a question, which is not the same as what the person asking has permission to see. They are two different criteria and the second one doesn't come as standard. The cheap way to solve it is never to put in there what must not come out.
That doesn't mean the chat can't use them. Someone with permission can ask Savia IA for a value from a record, or ask it to change one, and the chat does it with the same permission check and leaves a trace of who asked. At that moment the value passes through the model that writes the answer (Anthropic, listed in the DPA), like any other answer. Someone without permission gets a no.
What our team sees when it logs in to fix something
This is where most vendors go vague, so here's the detail. When someone from Savia IA needs to enter a client account to resolve an incident, there are two modes and neither is silent.
Own identity. The agent logs in as «Savia IA Support» with admin permissions, for configuration tasks: departments, documents, settings. In this mode they cannot use the chat at all: the system refuses.
Impersonation. The agent takes a specific person's session to reproduce a fault exactly as they see it. In this mode they see exactly what that person sees, including their conversations. We say it in those words because it's what is needed to fix a fault that only happens to one person, and because we'd rather you heard it from us than as a surprise.
What bounds that access:
- It expires on its own after 60 minutes. There is no day-long support session.
- It appears in your own company's audit log, not only in ours, with the name of whoever logged in, who they impersonated and the reason. You can see it yourself.
- Employee and client records stay out regardless, even when impersonating someone who does have permission to see them. There is a dedicated automated test for this. One caveat: if that person previously asked the chat for a value from a record, the answer is still in their conversation, and whoever impersonates them sees the whole conversation.
- It cannot change passwords in any mode.
- It doesn't seed the memory. What happens in a support session is not captured as knowledge nor attributed to the impersonated person.
It's set out in clause 4 of the DPA and in clause 8 of the Terms.
The EU AI Act
Savia IA is a provider of a limited-risk AI system. Your company, by using it, is the deployer. These are two different sets of obligations and it's worth having that written down before signing, not after.
What falls to us. Disclosing that you're interacting with an AI: the chat says so on screen. Documenting the purpose and limits of the system, which are in the Terms. And listing the AI providers involved, which are in the DPA one by one.
What falls to you. Human oversight of the decisions you make from the answers and, where applicable, informing worker representatives. Separately from the AI Act, article 64.4.d of the Spanish Workers' Statute already requires companies in Spain to inform the works council about algorithms that may affect working conditions.
AI literacy. Article 4 of the Regulation requires providers and deployers to ensure their staff have a sufficient level of AI competence. The guided adoption phase of the rollout covers that obligation on your side, and is documented as such.
What is deliberately left out. Annex III classifies as high risk those systems intended to evaluate the performance or behaviour of workers, or to support recruitment, promotion, disciplinary or dismissal decisions. Savia IA is not designed for that and the Terms expressly exclude it. It isn't only a clause: employees' personal data is outside the search index by design, which is what that use would require.
If your requirement is that nothing leaves your house
There is a deployment option with AI models running locally, inside your infrastructure. In the standard option, the providers involved are listed with name, country and transfer mechanism in the DPA, with the commitment not to train on your data.
On the way out
On termination, or whenever you ask, everything is deleted across the three layers (database, vector index and files) within a maximum of 30 days, and a dated record of the deletion remains. No copies except where legally required.
The paperwork, in full
No commercial summary replaces the document. All three are published and can be read in full before talking about price: Terms of Service, Privacy Policy and Data Processing Agreement.
If something is missing, or if your legal department has a question this page doesn't answer, write to us at hola@saviaia.es and we'll answer it in writing.