Player data and cloud AI: what leaves the device
A DUE-DILIGENCE MAP, NOT LEGAL ADVICE
The moment an NPC calls a cloud API, the player’s words stop being yours to control. Whatever they typed leaves the device, crosses the network, and lands on a server owned by whichever company runs the model you picked. From that point, that provider’s terms govern the data, not your privacy policy and not your intentions when you built the feature.
This holds whether the NPC is a companion, a shopkeeper, or a support tool you bolted on for testing. If the call leaves your own infrastructure, the mental model is the same: what the player typed is now travelling under someone else’s terms of service, and you chose those terms the day you picked the provider.
What actually leaves the device?
Chat text is the obvious payload: whatever the player typed into the box, sent close to verbatim unless you intercept it first. The context you attach around that text is often the bigger leak. A companion NPC that “remembers” the player needs some of their history in the prompt, so teams pack in the player’s chosen name, recent save state, current location, sometimes a real display name pulled from a platform account. Anything you put in the prompt travels with the request, whether the player typed it or not.
Attachments carry further. A screenshot for visual context or a voice clip for a speech-to-text pass is a separate thing that left the device and became a line in someone else’s server log, on top of the text itself.
Why do players type personal things into the chat box anyway?
Players do not read your data-handling docs before they type. A dialogue box that accepts free text reads as private the way a diary does, so players tell an NPC their real name, a breakup, a location, whatever feels relevant to the scene they are playing. A text box with no visible limit reads as safe to fill with anything, and players will fill it with anything.
Design your pipeline to expect that from the first call your game makes, not after a support ticket teaches you the hard way. A player who tells a bartender NPC their real address for immersion is using the chat box exactly as it invites them to be used.
What do you have to disclose?
If your game sends player input to a third-party API, say so in your privacy policy, plainly, before a player has to go looking for it. State which feature does this, what category of data it involves, and that a third party processes it. A line that only says “we use AI to enhance gameplay” does not meet that bar in any market that actually enforces disclosure.
Store pages add a separate layer on top of the legal one. Steam’s content survey and similar platform forms ask about AI features directly, and platform rules covers what each store wants declared. A privacy policy and a store disclosure answer different questions, and shipping requires both, not whichever one you remembered first.
How do you cut down what you send?
Send the game context, not the player profile. An NPC conversation needs the local quest state, the last few lines of dialogue, and the character’s persona; it rarely needs the player’s account email, their platform display name, or their full save file. Build the prompt from a narrow, purpose-built context object instead of passing your existing player-state struct straight into the API call, because every field that struct carries travels with it.
Strip identifiers before the call, not after. A player ID that only your own server needs to resolve should stay on your server; the model call gets a session token or nothing at all. If a bug report ever needs to reconstruct a conversation, keep that mapping in your own logs, where you control retention, instead of trusting the provider’s logs to hold the link for you.
Does your provider train on what you send it?
Check this before a single production message goes out, because a default-on training policy means every player’s chat becomes training data for someone else’s model unless you opt out. That policy is usually tier-gated: a free or hobby tier often trains by default, and a paid or enterprise tier turns it off, sometimes behind a toggle you have to find and flip yourself. Reading tool terms covers how to find that clause and what the common phrasing looks like.
Whatever answer you get, write it down with the date. Provider policies change between your integration and your launch, and “we checked it a few months back” is not a policy you can point to later.
Who is logging this, and for how long?
Two logs exist here and you only control one. Your own server, if the call passes through it, can log requests and responses; set a retention window on that log the way you would for any other player data, and delete on schedule. The provider’s log is the one you do not control, so check its retention period, whether it feeds abuse monitoring or training, and whether you can request deletion on a specific player’s behalf if someone asks.
Route the call through your own server rather than straight from the client when you can afford the extra hop. That gives you one place to log, redact, and rate-limit before the request reaches the provider, instead of trusting a client binary to behave.
What if your game attracts kids?
Say it plainly: children’s data is regulated almost everywhere that has a data protection law at all, and cloud AI chat is exactly the feature that turns a casual privacy policy into a legal exposure. A free-text chat box is a different product when a meaningful share of your players are under 13, or under 16 in some regions, than when your audience is adults.
If your art style, marketing, or store category points at a young audience, do not treat cloud AI chat as a feature you ship first and clean up legally later. Get real legal review before launch, specific to that feature. The review costs less than a regulator finding the gap on its own.
Which regional rules actually apply to you?
This section is a map for what to ask a lawyer, not a substitute for asking one.
GDPR-class rules, meaning rules built on the same shape as the EU’s General Data Protection Regulation, apply based on where your players are, not where your studio is incorporated. A small team based outside Europe can still fall under the EU or UK version the moment a player there opens the app. California and Brazil run their own versions with different thresholds and different names, and more jurisdictions add similar rules most years.
The common thread across these regimes is simple to state even where the enforcement detail is not: tell people what you collect, tell them why, give them a way to ask what you hold and have it deleted, and do not collect more than the feature needs. A game that already follows that thread for its own player database usually just needs to extend the same practice to cover the AI provider as one more processor in the chain.
Going deeper
A local-model fallback is a privacy feature before it is a cost feature. If the model runs on the player’s own device, the data-transfer problem above does not apply to those calls at all, because nothing left the device to begin with. Adding LLM-driven dialogue to NPCs covers the local-versus-cloud tradeoff on latency and cost; privacy is a third column worth adding to that comparison yourself.
A redaction layer in front of the API call catches what a policy alone will not. A pass that strips patterns that look like emails or full names out of the prompt before it leaves your server is cheap to build and cuts your exposure on the cases players create by typing personal details into an NPC unprompted.
Once you incorporate, or once the project earns real money, ask your AI provider whether they offer a data processing agreement. A DPA turns your handling of player data through their service into a documented, auditable relationship instead of an assumption resting on a terms-of-service page. A provider willing to sign one on request is usually a provider that takes the obligation seriously in the first place.
Lay out your specific mix of provider, region, and audience age in the AI Game Dev Org Discord if any of this still leaves you unsure — people there have already worked through most of these combinations.