What Happens When Chatbot Data Is Sent to a Third-Party AI Provider?

💡 Summary: Key Takeaways

• Not storing chatbot data in your own systems does not make data sent to a third-party model disappear. If the user's message reaches the model provider, processing and, in many cases, transfer still need to be assessed.
• “We do not use customer data for model training” is not enough on its own. Legal role, purpose, retention, subprocessors, security measures, international transfers, and user notices require separate review.
• Masking can be a useful control, but it is not always anonymisation. If the context can still identify the person, the information may remain personal data.
• Health, financial, children's, or other sensitive data changes the threshold. The same chatbot architecture may be acceptable for one hotel use while requiring a much more demanding assessment in medical tourism.

A guest starts a conversation with a hotel chatbot by asking about room types. Then they provide dates. Next comes: “My spouse is sensitive to gluten. Will there be suitable options at breakfast?” The same architecture at a medical-tourism company may receive a very different message: “My name is Ayşe. I previously had this operation. Can I send you a photo?”

The company may not store any of these conversations in its own database. It may even tell the user, “We do not retain your messages in our system.”

That statement may be true and still incomplete.

If the chatbot sends the conversation to OpenAI, Anthropic, Gemini, a China-based model service, or another third-party provider to generate an answer, the data has left the company's system. The user's name, telephone number, email address, booking details, travel plans, health complaint, or photograph no longer exists only inside the company's application.

This is where the GDPR and Türkiye's KVKK become relevant. Whether the company stores the data matters. But not storing it in the company's own system does not change the fact that it is sent to a third-party provider. The purpose, provider, conditions, and safeguards of that transmission need a separate assessment.

This is the data-protection part of the EU AI Act series. The subject is not the EU AI Act itself. But as the previous article explains, even a chatbot considered low risk under the EU AI Act can raise serious questions under the GDPR and KVKK when it processes personal data.

See the data flow first

The first mistake in a chatbot project is often to begin with model selection. Data protection has a similar mistake: asking “Which provider is safer?” before mapping the data flow.

Start by writing down where the conversation travels.

Which channel does the user come from? A website, landing page, WhatsApp, Instagram DM, and a call-centre interface are not the same. Does the message first reach the company's server? Is there a CRM, live-chat tool, automation platform, or messaging provider in between? Which model API receives it next? Where is the model's answer logged? Who can access it for debugging, quality control, security, or abuse review?

Without that map, “We are GDPR compliant” says very little.

The GDPR's core principles are lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, security, and accountability. They apply to processing, not only to records kept in a database.

KVKK similarly requires personal data to be processed for specified, explicit, and legitimate purposes; to remain relevant, limited, and proportionate to those purposes; and to be retained only for the period required by law or by the purpose of the processing. The Turkish authority's guide to generative AI and personal-data protection also stresses that controllers should consider these risks throughout the lifecycle.

The practical question is simple: What information does the chatbot genuinely need to answer? Does everything the user types need to reach the model? Does the system have to use a full booking number, complete telephone number, or medical history verbatim? These are product-design questions.

What role does the model provider hold?

Under the GDPR, a company that determines the purposes and means of processing may be the controller, while a party processing data on its behalf may be a processor. If two parties jointly determine purposes and means, joint controllership may arise. The distinction between data controller and data processor under KVKK creates a comparable operational question.

When a company uses a model API to serve its customers, the company will often determine the purpose of the chatbot. Depending on the contract, product, and data-use terms, the model provider may act as a processor.

That should not be assumed. The contract and product settings need to be read.

As of 31 August 2026, OpenAI says that it does not use business and API customer data for model training by default. It describes retention of API inputs and outputs for up to 30 days, subject to stated exceptions, together with zero-data-retention options for eligible customers.

Anthropic similarly says that it does not use inputs and outputs from commercial products and its API for model training by default. Its Claude API retention documentation separately describes zero-data-retention arrangements and feature- or model-specific exceptions.

That information is valuable. It does not answer two other questions by itself.

First, not using data for training does not mean that the data is not processed. Limited processing or retention may still occur for safety classification, abuse detection, technical operation, troubleshooting, support, or legal obligations.

Second, every product and feature may not operate under the same data regime. A consumer chat interface, API, file upload, batch processing, tool use, code execution, search integration, and fine-tuning may create different retention and access outcomes.

“We use OpenAI” or “We use Anthropic” is therefore not a compliance assessment. The company needs to know which product, contract, setting, endpoint, processing region, and data category are involved.

Masking is not anonymisation

The cleanest way not to send personal data is not to collect it. That is not always easy in a chatbot.

Users type their names and telephone numbers. In a hotel context, they may disclose flight times, children's ages, or allergy information. Medical-tourism conversations may go much further: medical history, photographs, medication, surgery details, reports, symptoms, and expectations can all appear in one exchange.

Three concepts should not be confused.

Anonymisation means that the information can no longer be related to a person. If that level is genuinely achieved, the data may fall outside the data-protection regime. In conversational text, however, multiple contextual clues can make true anonymisation difficult.

Pseudonymisation means separating or replacing information that directly identifies a person. Under the GDPR, it is an important security and risk-reduction measure, but it does not by itself stop the information from being personal data. The European Data Protection Board's approach to pseudonymisation reminds organisations that data remains personal when it can be reconnected to a person using additional information.

Masking is a practical product control. “Ayşe Yılmaz” can become “Customer 123.” A system may send only the last four digits of a telephone number, an age range instead of a complete birth date, or a booking type instead of a hotel room number. This supports data minimisation and can reduce re-identification risk and the effect of a breach.

But if the rest of the conversation identifies the person, masking is not anonymisation.

Consider: “I will stay for two nights from 10 September, arrive from Istanbul at 23:40, and my spouse has a gluten sensitivity.” Removing the name may not prevent the message from being matched with the booking system. In medical tourism, statements such as “I had this operation three years ago, I am travelling from this country, and I previously contacted this doctor” may be enough to identify someone.

The better question is therefore not simply whether masking is used. It is: Which personal data does the model genuinely need for the task, and how are unnecessary details systematically excluded?

Can local preprocessing help?

Yes, in many cases. It is not a complete solution by itself.

Before sending the conversation to a third-party provider, a company can pass it through a local model or a rule-based layer. That layer can try to detect names, telephone numbers, email addresses, identity numbers, booking references, health terms, or photographs. It can then send only the necessary context to the main model.

For the hotel example, the model may need to know only that “The guest is asking whether gluten-free breakfast options are available.” The guest's name, telephone number, and booking code may be unnecessary.

Healthcare is more difficult. Some health information may be necessary for an answer to be useful. The prospective patient may also describe a highly specific situation that identifies them on its own. Local preprocessing can still help, but claiming that “we no longer send personal data” would be risky.

The local layer creates value in three places.

First, data minimisation: only necessary information reaches the main model.

Second, policy enforcement: the system can stop the conversation or hand it to a person when it detects children's data, payment details, identity numbers, or health photographs.

Third, evidence: the company can show which data was prevented from leaving and which conditions triggered a human handoff.

The layer is itself a processing activity. It can fail, keep logs, or miss personal data. It should therefore be designed and tested as a privacy gateway in the product architecture.

International transfer may be unavoidable

If the third-party model provider processes data outside Türkiye or the EU, international-transfer questions arise.

Under the GDPR, transfers of personal data to third countries or international organisations are subject to Chapter V of the GDPR. Adequacy decisions, appropriate safeguards, standard contractual clauses, and, where necessary, transfer-impact assessments may become relevant.

Following amendments that took effect on 1 June 2024, Türkiye's international-transfer framework includes adequacy decisions, appropriate safeguards, standard contracts, binding corporate rules, and limited occasional-transfer cases. When the standard-contract route is used, notifying the authority within five business days is also part of the process.

“The provider is GDPR compliant” is not enough. The company needs to know the legal mechanism for its own transfer, the parties' roles, data categories, subprocessors, technical and organisational measures, and retention period.

The supply chain matters too. A model provider may operate on another cloud provider's infrastructure. Some features may be processed in different countries. Some products may offer a data-residency or regional-processing option; others may not.

The procurement question therefore extends beyond a feature list: Can the provider supply the information and contractual commitments needed to complete your data-protection file?

Health and sensitive data change the threshold

A hotel chatbot and a medical-tourism chatbot should not receive the same data-protection assessment.

Health data is special-category personal data under KVKK. The authority's explanation of special-category personal data states that it requires stricter protection and is subject to limited processing conditions. The GDPR also places health data within a more demanding special-category regime.

In medical tourism, a person often provides more than contact information. They describe symptoms, share photographs, discuss previous operations and medication, and explain expectations or sometimes their psychological state. These details may appear inside a sales process, but they are not lightweight data from a data-protection perspective.

The following decisions should therefore be made before a healthcare chatbot goes live:

• At which point can a user obtain general information without sharing health data?
• When is clear and separate information required?
• Which data should never be sent to the main model?
• Through which channel should photographs, reports, and medical histories be collected?
• Which answers remain general information, and which should be handed to a healthcare professional?
• Can the model provider meet the contractual, security, and transfer requirements for special-category and health data?

These are not only legal-risk questions. Poor direction, false expectations, a missed handoff, or unnecessary data collection can also damage a prospective patient's trust.

The next article in the series therefore treats AI in healthcare separately. It adds the boundary of medical devices, triage, diagnosis, treatment, human oversight, and medical-tourism operations to the data-protection questions discussed here.

What should the user be told?

A transparency notice should say more than “This chatbot uses AI.”

The user should be able to understand who processes their messages, for which purpose, whether the messages are sent to a third-party provider, which data categories should not be shared, how long the data is or is not retained, how to exercise their rights, and how to continue with a person when necessary.

Putting this information in small text below the chatbot is rarely enough as product behaviour. The warning should appear before the user enters personal or sensitive information. The system should guide users when payment-card data, identity numbers, health photographs, or children's data appears and stop the conversation when necessary.

Good product design and data protection meet at the same point: the user should know what they are telling whom.

A practical company checklist

Before connecting a chatbot to a third-party AI provider, it is useful to answer the following questions:

This table is not a complete legal file. It makes the real system visible.

One of the most dangerous sentences in a chatbot project is: “We do not store the data.”

Perhaps you genuinely do not. But if the user's message reaches a third-party model, the company's data-protection question has not ended. It has moved elsewhere.

A better starting sentence is:

Which data leaves the system during this conversation, does it genuinely need to leave, and what evidence shows that we are managing it?

This article provides general information and does not constitute legal advice for a specific system or company.