Can Customers Ask Me to Delete Their AI Chat Data?
Customers can request erasure of AI chat data. Learn the EU GDPR conditions, response deadline, identity checks, exceptions and handling of connected copies.
Yes. Where EU GDPR applies, customers can ask you to erase personal data in their AI conversations. The right is subject to conditions and exceptions, so you must assess the request rather than either deleting everything automatically or rejecting it because the data came from a chatbot.
For a business using Niwa on its website, the request needs an owner in the business. That person should know how the site's conversation records relate to the AI provider, messaging service, support inbox and any booking or order record created during the exchange.
Recognise a request in ordinary language
A customer does not need to cite GDPR Article 17 or find a special form. "Please remove the personal information from my conversation" can be a request even if it arrives by email, phone or another route.
Give your staff a process for recognising the meaning in the languages they support. Do not depend on one English unsubscribe phrase to detect a privacy request. If the request is unclear, ask a focused question about which information the person means.
Record the date received and the scope. Under GDPR Article 12, respond without undue delay and within one month. A permitted extension of up to two further months depends on complexity and number of requests; tell the person within the first month and explain the delay. It is not a default extra period for every request.
Confirm identity proportionately
Avoid deleting or disclosing another person's records. Use information you already hold where it is sufficient, such as the relevant authenticated account or a verified contact route.
If you have reasonable doubts about identity, request only the additional information needed to confirm it. Do not demand a passport for every ordinary chat deletion. A visitor who never gave their name may need help identifying the relevant session without collecting excessive new data.
Keep the identity check separate from the substantive decision. Completing a check does not create a reason to retain a transcript that no longer has a lawful purpose.
Decide whether erasure applies to each record
GDPR Article 17 includes grounds such as data no longer being necessary, withdrawal of consent where no other legal ground applies, and unlawful processing. It also contains exceptions, including certain legal obligations and the establishment, exercise or defence of legal claims.
Consider a fictional shop customer who asks to delete a product chat after buying an item. The shop may need to keep particular order or accounting information under applicable law. That does not automatically justify keeping unrelated personal remarks in the full chat transcript.
Separate what must remain from what can be removed. If you rely on an exception, document its actual basis and limit it to the information needed. Do not invent a retention obligation because the conversation might someday be useful.
Locate the copies that your workflow created
Use the data map to check the WordPress records, authorised exports, support messages and connected services. If a conversation produced a booking, examine the booking record separately under its own purpose and requirements.
Where processors handle the relevant information on your behalf, use the agreed assistance and deletion process. Article 19 also requires communication of erasure to recipients unless this proves impossible or involves disproportionate effort; if requested, inform the person about those recipients.
Do not assume deleting a visible chat in one dashboard handles supplier logs, stored application state or copies in an inbox. Ask for confirmation appropriate to the service and retain a minimal record of the action.
Account for backups and restored systems
Backups may have a defined overwrite cycle. Explain what happens to the customer's information there rather than saying it is instantly gone when the live record is removed.
The ICO's UK erasure guidance discusses backup handling, including putting data beyond use until replacement where immediate overwriting is not available. That is useful operational guidance in its UK context, not a blanket exemption from EU obligations.
Plan what happens after a restoration so erased data does not quietly return to ordinary use. Include the relevant export and backup owners in the procedure. A deletion process that only checks the main database can miss the places your team actually works.
Give a clear response and retain a small audit record
Explain what you erased, what remains where applicable, why it remains and what will happen to any backup copies. If you do not take action, GDPR Article 12 requires the relevant reasons and information about complaining to a supervisory authority and seeking a judicial remedy.
Keep enough evidence to demonstrate how the request was handled. That record should not unnecessarily recreate the entire conversation you have just deleted.
Deleting chat records is also different from removing information from a trained model. If you have allowed identifiable data into a training process, investigate that handling with the supplier. Do not promise to "untrain" a model through a normal transcript-delete button.
Prepare the procedure before the first request
Review the Niwa safety guidance and the records your installation actually creates. The Niwa setup information gives product context, but your business still needs a verified handling process and responsible staff.
Test the procedure with a fictional conversation. Confirm that staff can locate the record, apply a justified decision and explain the result. Discuss the required data workflow with Niwa if you are preparing a website assistant or adding connections to an existing WordPress installation.
EU legal references checked on 9 October 2026. Other jurisdictions can provide different rights and response deadlines.
