# AI data privacy and security questions

> Before letting AI touch customer or employee data, ask six groups of questions: how data is handled and what is minimised or masked before it leaves your systems, which model providers receive it and on what terms, who and what can access it, how long prompts, outputs and logs are retained, whether every action is logged well enough to reconstruct, and where a person reviews the output. Ask for evidence, not assurances: a data flow diagram, the provider's written terms, an access list, a retention setting you can see, and a sample log.

Source: https://risendigital.io/guides/ai-data-privacy-and-security-questions  
Publisher: Risen Digital  
Updated: 2026-09-21

## At a glance

- **The core question:** Where does the data go, who can see it there, how long does it stay, and can you prove all three?
- **Ask about the provider:** Every AI feature sends something to a model provider. Ask which one, under what terms, and whether your data is used for training.
- **Evidence beats assurance:** A diagram, a contract clause, an access list and a sample log tell you more than any answer in a meeting.
- **Keep people in it:** Human review is a control, not a cost. Ask where it sits and what triggers it.
- **Not legal advice:** This guide describes what to ask and check. Which rules apply to your data is a question for your own counsel.

Whether you are buying an AI product, hiring a partner or building in house, the same questions apply. They are not about which technology is used. They are about where your data goes, who can see it, how long it stays, and whether you could reconstruct what the system did. This guide gives you the questions, what a good answer sounds like, and how to verify it rather than take it on trust.

![An open filing cabinet drawer full of paper records](https://risendigital.io/images/experience/file-cabinet-1600.jpg)

## Why do these questions matter before AI touches your data?

An AI feature moves data through more hands than a normal one: your system, the vendor, the model provider, their logs, and any tools the model calls. Each hop is a place where data can be seen, kept or used in ways you did not intend.

When a person types a customer's name into a support tool, the data stays in that tool. When an AI feature handles the same case, the customer's name, the conversation and possibly related records are assembled into a prompt and sent to a model provider, who returns an answer that may be logged by the vendor, stored in your system and shown to a reviewer. None of that is wrong. All of it needs to be known and chosen.

The questions below work for three situations: a product you are buying, a partner you are hiring, and a system your own team is building. The answers you want are the same in each case. What changes is who has to produce them. Ask them early, before a pilot puts real data through a system nobody has examined, because it is much harder to add a boundary after the data has already crossed it.

## What should you ask a vendor or your own team?

Work through the six areas below. For each question, note the answer and what evidence backs it. An answer without evidence is a follow-up, not a tick.

_Interactive on the web page: The questions, grouped by what they protect. The checklist has five groups covering six areas. Data handling: what data is sent, what is minimised or masked first, whether it leaves your region, and whether any is used to train models. Model providers: which providers are used, under what written terms, whether they retain prompts, and what happens if the provider changes. Access control: who and what can read the data and the outputs, how access is granted and removed, and whether the AI's permissions are narrower than a person's. Retention and deletion: how long prompts, outputs and logs are kept, whether you can set that, and how deletion is proven. Auditability and human review: whether every action is logged with what the AI saw and decided, whether a case can be reconstructed, and where a person reviews output and what triggers escalation. A system that can answer every question with evidence is ready for real data; one that cannot should get test data only._

## How do you verify the answers rather than take them on trust?

Ask for the artefact behind each answer: a data flow diagram, the provider's terms on the account in use, the access list, the retention setting, a sample log and a description of the review step.

| Claim | Ask for | What it proves |
| --- | --- | --- |
| We only send what is needed | A data flow diagram and the field list per feature | Someone has actually traced the data, and you can check the minimisation |
| The provider does not train on your data | The provider's terms for the exact account tier being used | The commitment is contractual, not a sales answer |
| Access is tightly controlled | The current access list and the date it was last reviewed | Access is a maintained list rather than an intention |
| Data is deleted after a period | The retention setting on screen, for the product and the provider | The period is configured, and you can see if it changes |
| Everything is logged | The full log for one real case | The log exists, is readable, and contains what you would need |
| A person reviews the output | The review queue and the escalation rule in writing | Review is a step in the process, not an occasional glance |

> **Answers that should worry you** We use enterprise-grade security, with nothing behind it. We are not sure which provider that feature uses. The logs are handled by the platform. Retention is standard. Each is a sign the question has not been asked internally, which is the real risk.

## What if the AI is being built by your own team or a partner?

The same questions apply, and you are the one who must be able to answer them. Decide the boundaries before the first prompt is sent, and build the logging and the review step in from the start rather than adding them later.

1. **Classify the data the feature will touch** List the fields and documents involved and mark which are personal, sensitive or contractual. This list decides everything that follows.
2. **Minimise before sending** Replace names and identifiers with tokens where the task does not need them, and strip fields the model never uses. The prompt should contain the least data that still gets the job done.
3. **Choose the provider on its terms, not its demo** Read the business terms for retention, training use and region. Use a business account, not a personal one, and record which account each feature uses.
4. **Give the system narrow credentials** Its own identity in each connected tool, read-only where possible, with write access added per action as the need is proven.
5. **Log first, then build the feature** Every prompt, every retrieved document, every tool call and every output, with a case identifier, in a store you can query and that follows your retention rules.
6. **Design the review step and the stop switch** Decide what a person sees before an output goes live, what triggers escalation, and who can pause the whole system. Test both before real data flows.

## Frequently asked questions

**Q: Does a model provider keep the data we send it?**  
A: It depends on the provider and the account terms. Some retain prompts briefly for abuse monitoring, some offer no retention on business tiers, and consumer accounts often have different rules from business ones. Read the terms for the specific account being used and ask for the answer in writing.

**Q: Is it safe to send customer data to an AI model?**  
A: It can be, if you know what is sent, have minimised it, understand the provider's terms, control who can see the prompts and outputs, and can delete and reconstruct the record. Safe is the result of those controls, not a property of the model. Whether you are permitted to send particular data is a question for your own counsel.

**Q: What is data minimisation in an AI system?**  
A: Sending the model only what the task needs. A request to categorise a support email does not need the customer's account number or address, so those are stripped or replaced with tokens before the prompt is built. Less data leaving your system means less to protect, retain and explain.

**Q: What should be in an audit log for an AI feature?**  
A: For each case: the input it received, the documents or records it retrieved, the prompt it was given, any tools it called with their arguments and results, the output, who reviewed it and what they changed. Enough to replay the case and explain the outcome to the person it affected.

**Q: Should we run AI on our own infrastructure instead?**  
A: Hosting a model yourself removes the provider from the data path but adds the work of running, securing and updating it. For most businesses the better first step is a provider with strong written terms, minimised prompts and good logging. Self-hosting is worth considering when the data must never leave your environment and you have the team to run it.

## Related pages

- [AI readiness checklist](https://risendigital.io/guides/ai-readiness-checklist)
- [How to choose an AI development partner](https://risendigital.io/guides/how-to-choose-an-ai-development-partner)
- [LLM integration patterns](https://risendigital.io/guides/llm-integration-patterns)
- [Conversational AI for business](https://risendigital.io/guides/conversational-ai-for-business)