AI Data Protection: What to Send to an AI and What to Keep

Send an AI service only the minimum data it needs to do its job, and keep identity, health, payment and confidential business data out of the request. This guide shows how to sort your data, mask what is risky, and check your vendor before launch.

The default rule: if the task does not need it, do not send it

Most data leaks in AI projects are not attacks. They are convenience. A developer pastes the whole customer record into a prompt because it is easier than choosing three fields.

We see this often in the field. A support chatbot gets the full order history, address and phone number, when it only needed the order status. The answer is the same, but the exposure is much larger.

Treat every request as a disclosure to a third party. Ask one question before each field goes out: would the answer get worse without it? If not, remove it.

Sorting your data into three groups

Before any code is written, list the data your product touches. Then place each item in one of three groups. This takes an afternoon and prevents months of argument later.

The first group is data that can go out freely, such as public product descriptions or published blog text. The second is data that can go out only after masking. The third is data that never leaves your systems.

Personal data and Turkish law: what to watch

In Turkey, personal data is governed by the Personal Data Protection Law (KVKK). Names, phone numbers, email addresses and identity numbers are personal data. Health data and biometric data fall under the stricter special category.

Sending such data to a provider that processes it abroad can count as a cross-border transfer. That has its own conditions. We are not lawyers, so confirm your exact obligations with your legal counsel or the KVKK Authority guidance.

One practical point: your privacy notice should describe that an AI service is part of the processing. A notice written before the integration is often out of date afterwards.

Masking before the request leaves your server

Masking means replacing identifying details with placeholders before the text reaches the AI. A message such as "Ayşe Demir, 0532..., wants a refund" becomes "[CUSTOMER], [PHONE], wants a refund".

Do this on your own server, not in the browser and not at the provider. Once raw text has left, you cannot pull it back.

Test your masking with real, messy text. Customers write phone numbers with spaces, dots and typos. A rule that catches only the clean format will miss many of them.

• Mask names, phone numbers, emails, addresses and identity numbers
• Strip file metadata from uploaded documents
• Remove secrets such as tokens and passwords from logs and prompts
• Re-insert real values only after the answer returns, on your side

Questions to put to your AI vendor

Not all providers treat your data the same way. Some use submitted content to improve their models by default. Others allow you to switch that off, or never do it on business plans.

Read the data processing terms, not just the pricing page. Look for where data is stored, how long it is kept, and who can access it.

• Is our data used to train models, and can we opt out in writing?
• Where is data processed and stored?
• How long are prompts and answers retained?
• Can we request deletion?
• Is there a signed data processing agreement?

Keys, logs and access: the quiet leaks

Even with clean prompts, leaks happen elsewhere. API keys committed to a code repository are a classic case. Keep them in server-side environment variables and rotate them if you suspect exposure.

Logs are the second weak point. Teams store full prompts and answers for debugging, then forget them. Log only what you need, mask it, and set an expiry.

Finally, limit who inside your company can read these records. Debugging access for everyone is convenient and hard to defend later.

Test with fake data first, then go live in small steps

Run the first version with invented records. Check what actually leaves your server by looking at the outgoing requests, not by trusting the design document.

Then release to a small group. Review a sample of requests every week for the first month. Mistakes show up quickly when someone is actually looking.

Write down the rules in one page: what is sent, what is masked, what is never sent, and who approves changes. A short, living document beats a long policy no one reads.

Start with a data list this week

Your next step is small. List every field your product could send to an AI, and place each in the free, masked or never group.

Then add masking on your server, review your vendor terms, and move keys out of code. If the integration touches health, legal or financial data, involve your legal advisor before launch.

If you want a second pair of eyes on your integration design, our team can review the data flow with you.