The questions asked by the person who connects the data

Which databases and ERPs does it connect to?

To SQL Server, PostgreSQL, Oracle, SAP HANA, MySQL, MariaDB and SQLite. There is no connector per ERP: the connector is per database engine.

That means it works with any ERP, CRM or in-house system that stores its data in one of those engines, which covers a good share of the business software installed in Spain. Sapioverse reads the schema, documents it and works on top of it; it needs no custom integration per vendor.

If your ERP is a cloud service that gives no access to its database, or if the data is spread across several systems and spreadsheets, there is a prior step: getting it into a queryable database. The product does not solve that on its own, and we say so before selling anything: that is exactly what the data services cover.

Can it modify or delete data?

No. It only reads.

Every generated query goes through a validator before it runs: only reads are allowed (SELECT and WITH), and any statement that writes, deletes or changes the structure is rejected. The restriction does not depend on the model behaving well: it is a check in the code, sitting in front of the database.

Even so, we always recommend connecting with a database user that has read-only permissions. Two locks are better than one, and you control the second one.

Does it make the numbers up?

No. The figures are not written by the model: they come from a query executed against your database.

The model does two things: translate your question into a query and write the summary from the result that comes back. The numbers you see in the answer and in the chart are the ones your database returned.

The real failure mode is a different one, and we would rather spell it out: faced with an ambiguous question, the model can misread it and query something other than what you meant. The figure would be right and the question wrong. That is why the generated query stays visible, and why the system asks you to clarify when a question allows more than one reading.

What information goes to the model?

The structure, the business context and small samples of data. Not the whole database.

Specifically, to write the query the model receives the table and column names, the business context you have loaded and a small sample of example rows. To write the summary it also receives a sample of that query's results: without seeing the data, it could not describe it.

This is the part worth reading carefully if you work with personal or sensitive data. It is set out in the privacy policy, along with the list of providers and where each thing is processed.

Do you train models with my data?

No.

The account we call the models from is configured with zero retention: what is sent is neither stored nor used for training. On top of that, every request carries that condition stated explicitly, so it does not rest on an account setting alone.

Nor do we reuse one client's data for another: the business context you load stays tied to your organization and does not leave it.

Do I have to open my database to the internet?

With the local agent, no. There are two ways to connect, and the first one opens no ports at all.

With the local agent. You install a program on a machine in your network that can already see the database. That agent is always the one starting the connection, outbound, to ask whether there is pending work. There is no inbound connection into your network: no ports to open, no database to publish, no firewall to touch. It is explained step by step in how to connect your database.

With a direct connection. Our server reaches the database, and here too there is no need to leave it open to everyone: the usual setup is a read-only user with access limited to our IP address, so it stays closed to any other origin.

And if your policy does not allow exposing the production database by either route, the usual alternative remains: replicate to an intermediate database, which also keeps analytical queries from competing with the system in use.

We have hundreds of tables. How does it know which one is sales?

Because you tell it. Every table and every column carries its business context in writing.

It is not a list of synonyms: it is your own rule. That cancelled invoices do not count as a sale, that channel DI means distributor, that the net amount excludes shipping. That layer is what makes the number come out right, and without it any tool gets the syntax right and the result wrong.

If your database is already documented with COMMENT, it is imported from there when the schema syncs: you document once, in your own database, and it serves everything else.

If we stop being customers, what do we take with us?

The code. The processes you build transpile to readable Python and SQL.

The ETL builder is visual, but what it generates underneath is not a proprietary format: it is a script your team can read, version and run on its own machine. It is not a courtesy export prepared for the day you leave, it is the same code that runs in production.

The business context you have written is yours too, and it comes out as plain text.

Does this replace our data team?

No. What it clears out of the way is the request queue, not the person handling it.

Someone has to connect the sources, decide how they are modelled and write the rules. Your team still does that, and it is the part that brings judgement. What stops reaching them is the "can you pull me an Excel of this?" at seven on a Tuesday, which is work that interrupts and teaches nothing.

The questions that do require judgement keep coming, and they tend to arrive better framed: whoever asks has already seen the data before escalating.

Do you have SOC 2 or ISO 27001?

No, neither of them. And we would rather say it here than in the final meeting.

They are audits carried out by an independent third party. They cost tens of thousands of euros and require months of watching that the controls actually work, not a weekend of paperwork. A company our size does not have them yet, and claiming otherwise would be easy to check.

While we are at it, something you can use to assess anyone: a seal is not an audit. There is no official GDPR seal, and anyone showing one should also be able to show the report behind it. Ask for it, from us and from everyone else.

If your procurement policy requires a certification before you can sign, that is a legitimate requirement: tell us in the first conversation rather than the last, and we will tell you whether it makes sense to carry on.

Who else handles our data?

Three providers, and we give you their name and country.

• IONOS (European Union): hosts the website and email.
• OpenRouter (United States): receives each query and routes it to the model.
• The model providers it routes to (Google Vertex, Azure OpenAI, AWS Bedrock), in the United States: they write the query and draft the summary.

Transfers to the United States rely on the European Commission's standard contractual clauses, module 2. We can give you the data processing agreement before anything is connected, and a copy of those safeguards if your legal team asks for it; the detail is in the privacy policy.

And what we cannot promise you today: prior notice if the specific model provider handling a query changes. That notice does not reach us either. We have asked in writing and, until there is an answer, we would rather you knew than promise you something we do not control.

What measures are in place, specifically?

These. Each one can be checked, and each answers a different way things can go wrong.