Security and compliance

What you should ask an AI vendor. Answered before you ask.

This page is for the person who has to approve the purchase: technical leadership, the data owner or whoever signs. It's written with concrete names and no adjectives: what separates one company's data from another's, what exactly my team sees when it logs in to fix something, and which box of the EU AI Act this service falls into.

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 me, 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 records (ID numbers, financial data, sick leave situations) 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.

What my 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 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 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. I say it in those words because it's what is needed to fix a fault that only happens to one person, and because I'd rather you heard it from me 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 mine, with the name of whoever logged in, who they impersonated and the reason. You can see it yourself.
  • Employee records stay out regardless, even when impersonating someone who does have permission to see them. There is a dedicated automated test for this.
  • 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 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 me. 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 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 me at contacto@robertnicuta.com and I'll answer it in writing.