In most automations, far less than people assume. A step that classifies a ticket needs the ticket text; it does not need the customer payment history sitting in the same record. A step that extracts invoice fields needs the invoice; it does not need the supplier bank details to be included in the prompt.
Minimisation at ingestion is the single highest-value control, and it is a design decision rather than a policy statement. It also tends to improve results, because a prompt carrying only relevant fields is a better prompt.
Where is it processed? Which region, which sub-processors, and can the region be pinned. For EU personal data this is a legal question, not a preference.
What is retained, and for how long? Prompts and outputs are data. Ask what is stored, where, and how it is deleted.
Is it used for training? It should not be, and the answer should point at a contractual term rather than a reassurance.
Who can see it? Access model, logging, and whether the vendor staff can read your content in support scenarios.
What happens if we leave? What you get back, in what format, and what is destroyed. Ask before signing, not at the end.
Three recur often enough to plan for. First, a legal basis for the processing must exist and be documented — usually legitimate interest or contract, and it is your determination to make as controller, not ours. Second, if the automation makes a decision with legal or similarly significant effect on a person, Article 22 constrains fully automated processing, which is one of several reasons meaningful human review is built in by default rather than as an option.
Third, deletion has to work end to end. A request that removes a record from the source system but leaves it in a vector index or a log is not satisfied. Whatever is built has to be able to forget, and that is a design requirement from day one, not a later feature.
For anything that searches your documents, the retrieval layer must inherit your existing access model. A system that can answer any question from any document is an access-control failure with a friendly interface, and it usually surfaces the first time someone asks about a colleague salary.
This is also why we prefer to build against an access model that already exists. Inventing one during an automation project means the project now owns a permissions design, which is a much bigger commitment than it first appears.
Your infrastructure and region where it matters. Processing pinned to region; no data movement to convenience the build.
No training on your content. Configured at the provider level and stated contractually.
Full access logging. Who or what read which record, when, and for which step.
Human review on anything consequential. Refunds, account actions, payments, clinical or legal outputs stay with a person by design.
Documented data flows. A diagram of what moves where, handed over with the build — which is also what your DPO will ask for first.
We work to GDPR-compliant, SOC 2-ready practices. Where a client needs a formal attestation from us rather than from our infrastructure providers, we say so plainly rather than implying a certification we do not hold.