The key points
- Know exactly what data the feature sends to a model.
- Choose configurations where content is not retained for training.
- Get the data-handling position in writing.
- Sensitive data may warrant processing in your own infrastructure.
What should you ask about data?
What the feature needs to read, which provider processes it, whether the provider retains it or uses it for training, where it is stored and who can access the logs. Vague answers are a warning. The questions are simple, and a supplier who has built these systems before should answer them plainly.
- What data does the feature read?
- Which provider processes it, and where?
- Is it retained or used for training?
- Who can see conversation logs and activity logs?
How do you reduce the risk?
Send only what the task needs, mask or exclude what it does not, and choose provider settings where content is not retained for training. Keep logs of what the system did so it can be audited. Limit what any agent can read and write to what its task requires.
When should data stay in your own infrastructure?
When the data is sensitive enough that sending it to an external provider is not acceptable, for example certain personal, financial or regulated records. Then the design changes: the feature may run against models you host, or work from a narrower slice of data. It is a trade-off between capability, cost and risk, and it is better made at the start than discovered after launch.
AI data-handling checklist
- What exactly will be sent to the model?
- Is it retained, or used for training?
- Where are logs stored, and who can read them?
- Which data must never leave your infrastructure?
- Is the position confirmed in writing?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.