The GDPR (the regulation text on EUR-Lex) splits the roles: the controller decides why and how is processed, and the processor processes it on the controller’s behalf under a data processing agreement (DPA). Processing needs a lawful basis, such as a contract or legitimate interests, and people have rights such as access and erasure. Separately, personal data may leave the European Economic Area only under a Chapter V transfer mechanism, such as an adequacy decision (the EU-US Data Privacy Framework covers certified US companies) or standard contractual clauses with a transfer impact assessment.
In a deployment the customer is usually the controller and your company a processor, so the design questions are concrete: which region stores prompts, logs and embeddings, whether calling a hosted model in another region is a transfer, and whether every vendor in the path is an approved sub-processor. Draw the data path and show everywhere a deletion request has to reach, including vector indexes, evaluation sets, caches and backups, instead of treating deletion as one database row.
Personal data trained into fine-tuned weights cannot be reliably erased short of retraining, so keep it in retrieval, where a delete removes it. Ask whether the model provider keeps prompts for abuse monitoring and for how long, because those copies fall under deletion and residency too. Remote access counts too: if engineers at your company’s US entity can read EU logs, the data has been transferred to that entity, even if nothing is stored outside the EEA. The EDPB guidelines on transfers say so: remote access from outside the EEA by another entity, even just viewing data on a screen for support, is a transfer, while an employee of the same company working abroad is not. Leave the legal judgment to the customer’s data protection officer and say which controls your design provides. Data residency is the related design requirement; a planned EU and US residency prompt will practice both.