Where your website content goes when you train an assistant
You cannot make honest claims about data handling until you can draw the path.
Before any policy language is written, somebody should be able to draw where content goes. Most teams cannot, and that is why privacy pages end up vague or, worse, confidently wrong.
The path, step by step
- A crawler fetches your pages, or you upload files.
- Text is extracted and split into chunks.
- Each chunk is sent to an embedding model, which is usually a third party API.
- The returned vectors are stored, along with the chunk text, in an index.
- A visitor asks a question. The question is sent to the embedding model.
- Matching chunks are retrieved from the index.
- The question and the chunks are sent to a language model, usually a third party API.
- The answer comes back and is stored in the conversation log.
The three crossings that matter
Steps three, five and seven leave your infrastructure. Everything else is internal. Those three crossings are what any honest privacy statement has to describe.
Notice what is being sent at each. Step three sends your content. Step five sends the visitor's question. Step seven sends both together. That last one is the widest exposure and it is the one people describe least accurately.
Two separate data subjects
This is the distinction that gets collapsed and should not be. There are two kinds of data here with different owners and different sensitivities:
**Your content.** You published it, usually publicly. Sending it to an embedding API is low sensitivity for a public marketing site. It gets more complicated if you upload internal documents.
**Visitor questions.** These come from a third party who did not choose your vendors. They can contain personal information, and visitors routinely type things into chat boxes that they would not put in a form. The sensitivity here is materially higher and it is not yours to be relaxed about.
The questions this forces
Once the path is drawn, a set of questions become unavoidable, and each one needs a real answer before it can appear on a website:
- Which providers receive data at each crossing?
- Is provider training on submitted data disabled, and is that contractual or a setting?
- How long does each provider retain what it receives?
- How long do you retain conversation logs?
- Which geography does processing happen in?
- What is the deletion path, and how long does it take end to end?
- Who can see conversation logs internally?
Why unknown is an acceptable answer, publicly
Many teams treat these as questions that must be answered before launch, so they invent answers or copy a competitor's. Both are worse than saying the work is in progress.
A published statement that says which providers you use and that retention terms are being finalised is verifiable and honest. A statement claiming a specific retention period nobody has confirmed is a claim that will be checked eventually, and being wrong about data handling is a different category of wrong from a marketing exaggeration.
What we are not claiming
Since this is our own site, the same standard applies to us. Creobot is in development. Our model providers are not finalised, our retention periods are not finalised, and our subprocessor list is not published yet. We are not claiming any certification, and we will publish specifics before general availability rather than approximating them now.
About the author
Vishal, CTO, Creoglyph. Writes about the systems view: retrieval, routing, reliability, data boundaries and deployment.