Where your ledger data goes when you ask a question

"Where does our data go?" is the first question a finance team asks about an AI assistant, and it usually receives an answer about hosting. Hosting is the smaller half of the answer.

This page follows one question through the whole path, and names what moves at each step.

The path of one question

You ask: which customers are over their credit limit?

1. The question reaches the platform. It is stored with your conversation.
2. The assistant writes a query. A table, a filter, a set of fields. The query is text. It contains no data from your system.
3. The platform runs the query. It runs through your own connection to Business Central, with your own delegated credentials. Business Central decides what you may read.
4. Rows come back. They are stored with the conversation, encrypted.
5. The platform renders a block. A table, a value or a chart, built from those rows.
6. Rows go to the model as a tool result. This is the step people do not expect, and it is the step that makes the answer real.
7. The model writes the sentence. On a Controller seat, the platform checks each figure in it against the rows from step 4.
8. You read the answer.

What is sent to the model?

Three things: your question, the conversation so far, and the rows that this turn needed.

The rows are the honest part of the answer. A tool result becomes part of the next request, so the records a query returned do reach the model. An assistant that claimed otherwise would either be wrong or would be answering from a training set, which is worse.

The amount is bounded. A result too large to carry back is reduced to a few rows and a note that says so.

What is not sent?

Your database. No standing copy of your Business Central tenant exists in the platform, and there is no nightly synchronisation. A question reads when you ask it, through your connection. Reports are the part you control: a report may cache its results for as long as its refresh setting allows, and it keeps the snapshots and extracts you schedule.

Anything the question did not ask for. The query decides the scope. A question about credit limits does not carry your payroll.

Data you cannot see. The query runs with your permissions, so the rows that reach the model are rows you are allowed to read. A colleague asking the same question may get a different result, and that is correct.

Does your data train a model?

No. UNI4C does not fine-tune a model on customer conversations, and no pipeline exists that would carry them toward training.

This is worth separating from a promise not to train. A promise depends on conduct. The absence of a pipeline is a property of the system.

What does the model provider keep?

Prompts go only to model endpoints in the EU. Scaleway serves models from France. Requesty's EU router serves the default models, GPT-6 Sol and Gemini Flash-Lite, on EU-only routes.

A provider may cache the opening part of a prompt, so the next turn of the same conversation costs less. The copies UNI4C keeps itself, the conversation and the rows inside it, are stored encrypted and follow your retention window.

Where does each part run?

Conversations, tool results, attachments, generated files and stored credentials are encrypted with authenticated encryption. A tampered ciphertext is rejected rather than decrypted.

How does this compare with Copilot in Business Central?

Microsoft makes three statements about Copilot. It inherits your data permissions and cannot read more data than you already have access to. For customers within the EU Data Boundary, data does not move outside that boundary. And Microsoft does not read your prompts or use your data to train AI models without your explicit permission.

Those are strong statements and they hold. The difference is not the standard of protection. It is the shape of the question the two products answer. Copilot works inside Business Central. A separate assistant reads across systems, so its data path crosses more boundaries and has to be described in more detail.

What to ask any vendor

Six questions. The answers are more revealing than a certification page.

1. Does a copy of our data exist in your platform, or do you read on demand?
2. Which rows reach the model, and what happens to a result that is too large?
3. Does the model provider keep anything between turns?
4. In which country does inference run?
5. Who holds the credential that reads our ERP: our user, or your service account?
6. How long do you keep the conversation and the rows inside it, and who sets that?

A vendor who answers all six in specifics has thought about the problem. A vendor who answers with a region name and a compliance badge has answered one question out of six.