Personal data in chatbots: lawful grounds, retention and sharing with AI
Names, phone numbers, delivery addresses, messenger IDs and support histories can be personal data. A business needs to know both what its bot requests and where each message goes: a CRM, an error log, a backup or an external AI service. A single consent button does not describe that entire journey.
This article offers a practical approach to designing that process. Legal sources were checked on 28 September 2026. It helps you prepare system requirements and questions for counsel; it does not replace legal advice for your particular circumstances.
Which data should you account for?
Data can be personal even without a name if it can identify a particular person. Examples include a user ID linked to orders or a support message containing an address. Ukraine’s Parliamentary Commissioner for Human Rights explains the definition and grounds for processing.
Before launch, map the data flow. For each field, record its use case, purpose, source, recipient and storage location. Include attachments, analytics, technical logs and managers’ manual exports. Information that is not requested by a form may still arrive in a free-text message.
Identify health information and other special categories separately. Do not reuse an ordinary contact collection flow for them: review the applicable grounds and restrictions with counsel.
Ukrainian law, GDPR and Bill No. 8153
Ukrainian law and GDPR have distinct conditions for applicability. Law No. 2297-VI is a core framework for Ukrainian businesses. GDPR may also apply, including to processing in the context of an EU establishment’s activities, or to offering goods or services to people in the EU or monitoring their behaviour there. A customer’s citizenship or the bot’s availability from the EU alone is not enough to reach that conclusion. The EDPB guidance on GDPR Article 3 explains these criteria.
| Instrument | What to address in the project |
|---|---|
| Ukraine’s Law No. 2297-VI | Define the purpose, grounds, individuals’ rights and safeguards for the particular processing |
| GDPR | Assess applicability, the parties’ roles and requirements for the relevant operations |
| Bill No. 8153 | Track it as proposed legislation; do not present proposed provisions as current law |
At the review date, the official record for Bill No. 8153 shows preparation for its second reading; it passed the first reading on 20 November 2024. Recheck before release. Do not put an effective date into a contract when that date has not been established.
Consent, notices and processing purposes
First establish a lawful ground for each purpose; consent is one possible ground. Legislation also provides other grounds, including those related to performance of a transaction or a legal obligation. An “I agree” button does not by itself make every collection of data lawful. For GDPR, see the European Commission’s explanation of lawful grounds.
Consider a retailer’s bot accepting a delivery request. The team separately describes the data required to fulfil the order and the use of the contact for promotional messages. An order should not automatically be treated as marketing permission.
Provide a clear processing notice and an accessible link to the full policy. Where consent is the chosen ground, provide an affirmative action, record its time and the wording version, and offer a withdrawal method. Retain evidence for a defined purpose rather than an indefinite “everything allowed” flag.
Seven decisions for chatbot architecture
Translate legal requirements into system rules that can be tested. The decisions below are engineering recommendations; the appropriate combination depends on the company’s risks and processes.
- Fewer fields. Request a callback contact first and order details at the relevant step. Every required field should have a reason.
- Separate roles. A manager sees the cases they need; only designated staff can export the whole database. Check former employees’ access.
- Document access checks. Possession of a phone number or messenger ID does not prove authority to read any CRM record. Sensitive actions require an authorisation check.
- Controlled integrations. Specify allowed fields for each API. Do not send a full profile when a request ID is sufficient.
- Protected secrets. Store API keys separately from content and user messages; restrict service account permissions.
- Logs without unnecessary content. An operation ID, timestamp and error code are often enough for diagnosis. Full message text should not automatically appear in every log.
- Managed deletion. Assign an owner and verify that deletion reaches every relevant system rather than simply removing a row from the admin panel.
Document field mapping and failure handling alongside the chatbot-to-CRM integration flow. The Commissioner’s standard processing procedure also addresses allocating access to data.
Retention periods and individual requests
There is no single universal retention period for all chatbot data. Set periods according to purpose, necessity and legal obligations; GDPR’s storage limitation principle reflects this approach.
Create a register covering data categories, the event that starts the retention period, a deadline or review rule, an owner and a deletion method. Document backups separately: their renewal cycle and the steps after restoration to prevent deleted records returning to active use.
Access, correction and deletion requests need a contact channel, identity verification and a responsible employee. Do not promise to erase everything instantly after one message: some data may need to be retained on another lawful ground. Determine response deadlines and exceptions under the applicable law.
Messengers, storage and AI providers
Your own server does not remove every external processing point. Messages, attachments, notifications, hosting and AI APIs may involve different suppliers. Add them to the data map and review the contracts and settings for the specific service you select.
For documents, consider an authenticated portal and a minimal chat notification. Labels such as “Mini App” or “secure link” provide no guarantee by themselves: test authorisation, link expiry and access by another user.
Before sending an AI request, select only the necessary fields, remove unnecessary identifiers and check the cleaning result. Replacing a name with a token does not guarantee anonymity if context or a lookup table can identify the person again.
Determine whether the supplier retains requests, who can access them, whether they are used for training, how deletion works and where processing occurs. Where international transfers occur, review their legal conditions separately. The European Commission explains processor contracts and transfers outside the EU. Technical threats are covered in our article on AI chatbot security.
What to test before launch
Use test data and involve the process owner, a technical specialist and counsel:
- Trace a request from its first message to the CRM and identify every copy of its data.
- Open a record under different roles and test prohibited actions.
- Check the notice, consent recording where required, and withdrawal.
- Submit a test access or deletion request and track its completion.
- Inspect logs, failed-message queues, AI requests and restoration from a backup.
- Assign an incident contact and a process for involving counsel and the responsible suppliers.
When choosing a platform, check these capabilities before signing the contract. Our comparison of ready-made and custom CRM systems can help you include them in requirements and support costs.
Conclusion
Start with a data map and processing purposes. Then agree on lawful grounds, access, retention, suppliers and request procedures. Select one working use case for the pilot and test it from end to end. This gives legal decisions a concrete technical implementation and tells the team what it needs to maintain after launch.
Frequently asked questions
No. Consent is one possible lawful ground. Determine the appropriate ground for each purpose and inform the individual about processing. Assess order fulfilment and marketing separately.
It depends on the particular processing, including an EU establishment’s activities, offering goods or services to people in the EU, or monitoring their behaviour there. A customer’s citizenship alone does not settle the question.
As of 28 September 2026, the official record shows preparation for the second reading. Do not treat its proposed provisions as current law; check its status again before launch.
Review the purpose, lawful ground, data scope, provider terms and any international transfer. Remove unnecessary data; masking alone does not guarantee anonymity.
No. You also need access controls, protected integrations, retention rules, backups and an incident response process. Some information may still pass through a messenger or another supplier.
Base it on the purpose and applicable legal obligations. Set separate rules for requests, logs and backups, and test the technical implementation of deletion or review.
Sources
- Ukraine’s Law No. 2297-VI on Personal Data Protection
- Ukrainian Commissioner: definitions, grounds and individual rights
- Official parliamentary record for Bill No. 8153
- EDPB: GDPR territorial scope
- European Commission: lawful grounds for processing
- European Commission: GDPR principles
- European Commission: organisational obligations
- Ukrainian Commissioner: standard personal data processing procedure
Personal data consultation for your business chatbot
In 15 minutes with a BotLabs implementation specialist, discuss one business process: which data your bot sends to CRM and AI systems and who can access it. Outline technical checks and questions for your legal counsel before making changes.
Data flows.
Next checks.
15 minutes with an implementation specialist: one process, CRM and AI transfers, and questions for counsel.
