Review data protection for an AI phone assistant

Describe why the assistant is needed. Callback intake, appointment management, conversation analysis and model training are different purposes. The information needed for a return call does not automatically justify additional analysis or indefinite storage of the complete conversation.

The GDPR includes purpose limitation, data minimisation and storage limitation principles. An appropriate legal basis must be determined for the actual processing. Special categories such as health information require additional consideration. Official GDPR text, particularly Articles 5, 6 and 9

A narrow task description helps: collect a name, confirmed contact method and concise request. Do not make unrelated personal information a standard requirement. The necessary fields depend on what the organisation will actually do with the resulting request.

Assess these five data-object categories separately and document which ones the actual workflow creates or retains.

“We do not store recordings” can be true while extensive transcripts remain indefinitely. Conversely, temporary audio processing without a retained sound file can still involve personal data. Describe the real objects and their lifetime rather than only what is visible in the product interface.

Include technical logs, exception queues and exports. A record removed from the main application may remain in a support ticket or automatically generated email. Those copies belong in the assessment as well.

Controller and processor. Identify which party determines the purposes and essential means and which processes data on behalf of another. Required agreements must cover the actual service. GDPR Article 28 addresses processing on behalf of a controller; a marketing brochure is not such an agreement.

Subprocessors. Request a traceable list of subprocessors and their functions. Ask who provides telephony, speech recognition, the language model, speech output, hosting and support. One European data centre in an architecture diagram does not establish that every processing step occurs there.

Support access and suppliers' own purposes. Review maintenance and support access, along with possible use for suppliers' own purposes. A “no training” commitment needs to apply to the relevant information, products and contractual configuration. Resolve ambiguity instead of extending one general statement to every underlying service.

EU transparency duties. Informing callers that an AI answers is separate from assessing whether audio can be recorded. The European Commission explains Article 50 transparency duties for certain AI systems, applying from August 2026. Those duties do not grant a general right to record a conversation.

Germany. In Germany, confidentiality of non-public spoken communication is also relevant; Section 201 of the Criminal Code is an important primary reference. The actual notice, consent arrangement where applicable, and alternative channel need appropriate legal review.

Switzerland and Austria. For Switzerland, the federal data-protection authority explains the interaction of privacy and criminal law for recordings, including particular exceptions. Do not extend those exceptions automatically to arbitrary quality-review or training purposes. Austria also requires its own assessment; a German announcement is not a universal DACH legal template.

Synthetic case: A service business wants to collect callbacks outside office hours. The operational result needs a name, confirmed number, request and preferred availability. A permanent audio recording is not part of that stated business output.

Procurement therefore first checks whether the service can deliver the task without retaining audio, and what transcript or log material still exists. A concise summary goes to the responsible team. Detailed personal information unnecessary for the callback is not deliberately copied across multiple destinations.

This example does not legally approve any particular supplier. It shows how purpose affects technical configuration. Adding recorded quality review later is a separate decision that requires assessment and suitable information for the people affected.

Roles. Someone maintaining opening hours does not automatically need access to all conversations. Separate configuration, request handling and technical support where possible. Document roles and review them when staff change.

Identity. Recognised caller ID is not sufficient identity evidence for private disclosures. An assistant should not choose the first matching contact where several records share a number. Changes and account information require a suitable predefined verification process.

Technical permissions. Restrict technical actions too. An integration creating callback tasks does not necessarily need access to every customer field or organisation-wide deletion rights. Assess permissions against authorised actions rather than accepting every default permission requested by a connector.

Third-party callers. Test ambiguous and third-party calls as part of that assessment. A person calling on behalf of a family member, tenant or colleague may have a legitimate request, but the appropriate handling depends on the task. The model should follow the organisation's process rather than infer authority from conversational confidence.

Create a synthetic contact and trace its information through the workflow. Then check what can be deleted, what expires under an agreed schedule and what must remain in a business application for another justified requirement.

Examine the main record, transcript view, recording, export, notification and exception queue. Ask how backups are handled and how restoration avoids routinely reintroducing information already deleted. Request concrete retention periods and named responsibilities.

Access and correction also need a practical route. If the assistant misstates a name or request, staff should be able to correct the operational record. An inaccurate summary should not spread through several applications as if it were verified customer information.

A short data-flow record for an AI phone assistant documents these points:

• purpose
• data objects
• suppliers
• locations
• access
• retention
• authorised actions

Add unresolved questions and a responsible person for each one. Where risk warrants it, assess whether further measures such as a data-protection impact assessment are required.

Concrete answers matter more than general compliance labels. Ask to see the relevant product settings and how changes to subprocessors or processing arrangements are communicated. After material product changes, the record needs to match the system actually operating.

The useful next step is a joint review by the business team, technical support and the relevant privacy or legal function. A bounded purpose and visible data flow give that review a concrete foundation.

These pages cover the service overview and the related decisions for data protection with an AI phone assistant:

• AI phone assistants: functions and boundaries
• Use an AI phone assistant with your existing number
• Measure AI phone assistant quality in operation
• 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.