Review chatbot data, suppliers and deletion

Task. Describe the task first. General opening hours normally require neither a customer number nor a date of birth. A personal status enquiry requires an appropriate identity and permission check. An optional contact request needs different information from a binding contract change.

Separate purposes. Separate service handling, quality analysis, marketing and possible use of conversations to improve models. These purposes are not automatically interchangeable. The German supervisory authorities' AI and privacy guidance provides selection and usage criteria, rather than a complete requirements catalogue. Assess the applicable legal basis and any special categories of personal information separately.

Consent. A mandatory “I agree to everything” checkbox does not resolve the purpose question. Have the appropriate basis and notice determined for each processing activity. Where a feature relies on consent, its operation must also support withdrawal and the relevant consequences.

The table is an inventory structure for chatbot data: six locations, the information each may hold and the question to resolve.

This is an inventory structure, not a claim that every provider stores every category. Establish actual behaviour and reconcile it with contracts and settings. An error log may contain a full customer request even when the main application shows only a short summary.

EU. For EU processing, relevant GDPR requirements include purpose, transparency, security, processor arrangements and, where applicable, international transfers. Whether a supplier acts solely on instructions or also for its own purposes must reflect the real service.

Switzerland. In Switzerland, the FDPIC explains responsibility when outsourcing. That responsibility does not disappear when work is delegated. Review subprocessors, processing locations and assistance with individuals' rights there too. A Swiss company may also fall within relevant EU rules; a single DACH marketing statement does not determine legal scope.

Provider list. Request an up-to-date list of involved providers, storage and support locations, and explicit terms for training and retention. “We do not train on your data” does not establish whether information is retained for abuse detection or technical logs. Sources checked on 26 September 2026.

Germany and Austria. Germany's section 25 TDDDG addresses storage and access on end devices, subject to specified exceptions. The Austrian Data Protection Authority also explains the distinction between strictly necessary and other cookies. Assess widget loading and embedded analytics as well as subsequent conversation text.

Testing. Labelling a feature “necessary” is not itself a technical or legal justification. Test network connections and storage before opening the chat, after rejecting optional features and after starting a conversation. Swiss offerings require assessment under the relevant Swiss framework rather than simply copying the German classification.

A fictional customer contacts a general appointment service and uploads a medical report without being asked. The appointment request did not require it. The bot should not automatically distribute that report to sales, general analytics and a broadly accessible knowledge base.

The planned exception process limits access, prevents unnecessary onward transmission and routes the matter to the appropriate responsible person. That person determines handling, retention or deletion under the applicable rules. A warning in the chat can help, but cannot prevent every inappropriate upload and does not replace this process.

The acceptance case also checks whether the attachment already reached logs or tickets. Deleting it only from the visible chat would overlook those copies. Record where the test information travelled and which controls actually stopped further use.

Define retention by purpose rather than keeping every conversation indefinitely for possible future analysis. Service records, technical logs and anonymous statistics may have different requirements. Anonymisation must actually remove the relevant identifiability; replacing a customer number does not automatically make a record anonymous.

Use a test record to exercise access, correction and deletion procedures. Can the team find related tickets, exports and provider-held copies? Is it clear what remains necessary, why and when backups expire? Record the observed result and close gaps before broad release.

Provide service staff with a route for requests they cannot fulfil directly. They should not promise immediate deletion from every backup when the documented process does not support that promise.

The approval package for chatbot data protection should cover these points:

• purpose
• data flow
• provider roles
• required agreements
• access controls
• notices
• retention
• incident handling

Assess whether a data protection impact assessment is required. That decision depends on the processing risk, rather than the AI label alone.

Assign an owner for changes to models, subprocessors and capabilities. A new CRM connection can alter the data flow more substantially than a rewritten greeting. Privacy therefore belongs in ongoing maintenance, supported by an understandable contact route and verifiable technical settings.

These pages cover the service overview and the related decisions for chatbot data protection:

• AI chatbots for customer service
• Plan a WhatsApp chatbot for business service
• Secure chatbot identity checks and business actions
• The EU AI Act for SMEs: questions before introducing AI

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.