Two moments have to be separated, and the word “data” blurs them. During generation, what you WRITE — your description, and the text of the files you attach — is transmitted to a model provider in order to produce the specification and the code; the providers are named in the privacy policy. Afterwards, once the application is running, nothing leaves: the delivered code carries no artificial-intelligence client among its dependencies, and the configuration file written on the server holds no API key. Which means your customers, your service calls, your members — everything you will enter later — structurally cannot reach a model. The only material that goes out is what you wrote to describe your need.
What goes to a model, and when
Generation needs to understand your trade: your description is what tells it, so it is transmitted to a model provider, together with the text of any files you add. The privacy policy names them — Anthropic, OpenAI, xAI and Google — and states that such processing may take place outside the European Union, framed by the European Commission's standard contractual clauses. This is not something to read between the lines: it is the raw material of the generation, and there is no version of the product where your description stays with you while still producing an application that looks like yours.
That transfer has an end. It happens during generation, to produce the specification and then the code, and it only happens again at the next generation — when you relaunch, when you ask for a change. In between, nothing happens. There is no continuous syncing, no usage feed back to a model, no background analysis of what your application contains.
What never goes there: the data you will enter afterwards
The deployed application is an ordinary piece of software, and that is checkable in three places in the delivered code. Its dependency list contains no artificial-intelligence client — only Next.js, React, Prisma and display libraries. The configuration file written on the server at deployment is four lines long: the database address, two technical secrets and a build number; no API key appears in it. And the figures on your dashboard are computed by deterministic queries against your database, never by a model asked to read your rows.
The consequence is the one that matters for the worry that comes up most — model training. Even taking the least favourable assumption, the material concerned could only ever be your initial description: the sentence where you explain that you run a workshop, with service calls and customers. Never the contents of your customer records, the history of your interventions or the list of your members, since those rows have, at no point, a path towards a model.
Attachments: two routes, only one goes through a model
An attached file does not always follow the same route, and the distinction is clear-cut in the code. A spreadsheet, a CSV, a PDF or a text file are read ON THE SERVER, by ordinary extractors: no model looks at the file itself. A photo or a screenshot, on the other hand, really is sent to a vision model, whose whole job is to describe it — that is the only way to make sense of a paper form or a photographed table.
One point has to be said plainly, because it changes a practical decision: the text extracted from a file does join the context sent to the model, up to twelve thousand characters per file. A spreadsheet attached to show your data structure therefore leaves, as text, alongside your description. If that file holds real personal data, good practice fits in one sentence: attach the header row and a few anonymised example rows. The generator needs the SHAPE of your columns, not your customers' names.
What is guaranteed, and what is not
A concrete guarantee first, and it is written into the code: when you attach a CSV to start with your real rows, those rows are placed into your database by deterministic matching — delimiter detection, mapping between your headers and the fields, typed conversion — and no model takes part in that step. The reason is spelled out at that very place in the code: the user's data is not to be reinvented. A model asked to “complete” a table of members would produce rows that are plausible and false, which is the only genuinely unacceptable outcome.
What this page does not claim to guarantee, next: each model provider's internal policy on reusing what is transmitted to them. That belongs to their contractual commitments, not to this product's behaviour; the privacy policy names them and describes how transfers are framed, and that is where to go and look. What the product does guarantee is the PERIMETER — what leaves, when, and above all what never leaves. It is precisely because that perimeter is narrow that the training question does not bear on your customer file.