Evaluating Chatbot Vendors: DPA, Subprocessors, and Third-Country Transfers

A chatbot vendor may showcase an impressive demo, an EU hosting region, and a pre-packaged Data Processing Agreement (DPA)—yet crucial questions remain unanswered. That is because processing extends far beyond the visible chatbot widget. Frequently, model APIs, hosting providers, vector databases, error analytics, support tools, email services, and backups are actively involved in delivering the service. For website operators, what truly matters is a verifiable processing chain, not a privacy buzzword on a sales page.

This checklist provides a structured approach for vendor evaluation prior to procurement and go-live. It serves as practical guidance, not legal advice. Roles, legal bases, information obligations, and transfer mechanisms must be evaluated for your specific use case; in cases of elevated risk, special categories of data, or unresolved contractual terms, data protection officers or qualified legal counsel should be consulted.

Understand the Data Flow First, Then Evaluate the Contract

The central question is not merely "Where is the server located?", but rather: Which personal data reaches which legal entity, when, for what purpose, and for how long? A visitor might enter names, email addresses, customer numbers, or free-form text in the chat. In addition, IP addresses, timestamps, device information, session identifiers, conversation histories, user ratings, and technical logs are generated. Even an ostensibly anonymous conversation can become personally identifiable through the combination of multiple attributes.

Therefore, sketch a simple data flow map before reviewing contracts. It should include at least the browser widget, chatbot platform, knowledge base, model providers, analytics and logging tools, support access points, backups, and deletion paths. For each stage, record the operator, country, purpose, data categories, retention period, and potential remote access. For instance, a claim of "EU hosting" does not clarify whether a support team outside the European Economic Area (EEA) can access live production logs.

Determine Data Protection Roles by Purpose

Whether a vendor acts as a data processor or as an independent controller for specific purposes depends on their actual operations. The EDPB Guidelines 07/2020 on the concepts of controller and processor clarify these distinctions. A vendor might process conversation logs on documented instructions, yet claim controller status for its own security, billing, or product development purposes. Ensure that every purpose, its corresponding role, and its legal basis are explicitly mapped. A DPA does not automatically cover a vendor's independent processing activities.

Reviewing the DPA: Required Content Must Match Real Operations

Article 28 of the GDPR mandates that controllers use only processors providing sufficient guarantees to implement appropriate technical and organizational measures. The contract must explicitly define the subject matter, duration, nature and purpose, categories of data, categories of data subjects, and the rights and obligations of the controller. Furthermore, it must cover documented instructions, confidentiality commitments, security measures, assistance with data subject rights, deletion or return of data, and information and audit rights.

Compare the DPA not just against a standard template, but against your data flow map and the actual plan purchased. A well-constructed contract clearly describes live chat operations, model training or knowledge base indexing, logging, support access, and optional features. Vague catch-all phrases like "service improvement" should be broken down into specific data points, purposes, opt-out mechanisms, and assigned roles.

• Instructions: Is it explicitly stated that content and metadata are processed solely for the customer's documented purposes? What specific configuration qualifies as an instruction?
• Model Usage: Are prompts, responses, or uploaded files utilized for general AI model training or overall product improvement? If not, is this restriction contractually and technically verifiable? If yes, the legal basis and role allocation must be evaluated separately.
• Deletion: Are there clear retention schedules for chat histories, logs, vector indexes, backups, and support copies? What happens upon contract termination?
• Security: Are access controls, multi-tenant isolation, encryption, auditing, vulnerability management, and incident handling clearly specified?
• Assistance: Does the DPA practically govern data exports, rectifications, deletions, access requests, security incidents, and Data Protection Impact Assessments (DPIAs)?
• Verification: Are audit reports, certifications, or third-party attestations readily available, and do they cover the exact services and locations utilized?

Certificates and audit reports offer valuable assurance, but they do not replace evaluating actual data flows or negotiating applicable contractual terms. Even a standardized DPA is only as robust as its filled schedules and alignment with technical reality.

Subprocessors: Verify Names, Functions, and Change Management

Under Article 28(2) of the GDPR, a processor must not engage another processor without prior specific or general written authorization. Under general written authorization, the processor must inform the controller of any intended changes concerning the addition or replacement of subprocessors, giving the controller an opportunity to object. The European Commission Q&A on Standard Contractual Clauses emphasizes that generic categories are insufficient: individual subprocessors must be named explicitly.

Demand an up-to-date, exportable list detailing legal entities, country locations, specific services rendered, and affected data streams. Verify whether an entity is purely a contracting party or actively processes data across multiple global locations. Pay close attention to model and embedding providers, cloud hosting, vector stores, CDNs, monitoring platforms, error logging tools, support desks, email services, and backup facilities. For each subprocessor, identify whether data is stored, merely transmitted, or accessible to human support personnel.

Evaluate the change management process carefully: How are customers notified, how long is the notice period, and what actionable recourse exists in the event of a justified objection? A notification sent on the day of deployment offers little value without contractual or technical options. Confirm whether alternative configurations, feature toggles, or orderly termination with complete data export are permitted. Subprocessors must be bound by equivalent data protection obligations; the primary processor remains fully liable to the controller for the performance of its subprocessors' obligations.

Third-Country Transfers: Verify Mechanisms and Practical Effectiveness

Chapter V of the GDPR applies to transfers of personal data to third countries and onward transfers. A transfer occurs not only through permanent storage, but also through remote administrative access, support views, or operational queries initiated from outside the EEA. Consequently, every step on your data flow map must be assigned a destination country, recipient, and transfer mechanism.

1. Adequacy Decisions: Consult the continually updated European Commission list to verify if the relevant country, sector, and recipient entity are covered. For targeted frameworks, mere corporate registration in a jurisdiction is insufficient.
2. Appropriate Safeguards: In the absence of an adequacy decision, legal safeguards under Article 46 GDPR must be established. The European Commission Standard Contractual Clauses (SCCs) are most commonly adopted. The module, selected parties, annexes, transfer descriptions, and technical safeguards must align with actual operations.
3. Effectiveness Assessment: Executing SCCs does not complete the assessment. The final EDPB Recommendations 01/2020 outline a risk-based approach: map transfers, identify transfer tools, assess local laws and practice, implement supplementary measures if necessary, complete formal steps, and re-evaluate at regular intervals.

Supplementary technical measures must address the specific risk profile. For instance, encryption is effective only when key management, access privileges, and processing requirements are properly aligned. An AI model provider that must process plaintext and can itself access the keys presents a fundamentally different risk profile from an encrypted backup destination. Generic marketing claims such as "AES-256 encrypted" or "GDPR compliant" do not substitute for this analysis. Derogations under Article 49 GDPR are not a suitable basis for routine, recurring SaaS processing operations.

Practical Example: EU Hosting with Global Service Dependencies

Consider a chatbot that maintains its primary database in Frankfurt. However, chat responses are generated by a US-based AI model API, crash logs are routed to an analytics service, and a global support team can inspect transcripts during escalations. In this scenario, stating "Data stored in the EU" describes only a fraction of the data processing lifecycle.

A rigorous due diligence process answers four specific questions: What content leaves the EEA during model invocation? Are prompts stored or used for other purposes? Do crash logs capture raw plaintext, identifiers, or minimized technical parameters? Under what specific conditions can support personnel outside the EEA access conversation transcripts? Only after resolving these points can transfer tools, supplementary measures, and residual risks be assessed.

Technically, website operators can mitigate risk significantly: disable unnecessary logging fields, sanitize inputs prior to external API calls, set brief retention schedules, isolate public bots from internal systems, partition knowledge bases by tenant, and require approval and logging for support access. For guidelines on cleanly segregating public bots from customer portals, see Public AI Chatbot vs. Customer Portal. For document management, our checklist on Document Validation, Privacy, and Handoff complements the vendor review process.

Decision Matrix: A Traffic Light Approach

Evaluation Point	Green	Yellow	Red
Data Flow	Complete, up to date, and plan-specific	Individual access points or locations unresolved	Relying solely on marketing claims of EU hosting
DPA	Purposes, data types, timelines, and assistance clearly defined	Adjustments required prior to go-live	Lacks binding instructions or deletion commitments
Subprocessors	Named list with locations and functions	Impractical change management process	Uses generic categories or undisclosed chains
Third-Country Transfers	Mechanism, scope, and assessment documented	Supplementary measures pending verification	Claims "EU server" eliminates all transfer considerations
Operations	Owner assigned, review schedule set, exit tested	Verification documents lack recurring review	No ongoing oversight post-contract execution

A yellow flag does not necessarily rule out a vendor, but it requires an assigned owner, a clear deadline, and verifiable acceptance criteria. A red flag within a core processing chain should block production rollout until the contract, platform configuration, or vendor selection is remediated. Be sure to document accepted residual risks and the decision-maker responsible.

Go-Live Checklist for Website Operators

• The data flow map and role designations by purpose are fully approved.
• The DPA and annexes accurately reflect the subscription tier, active features, processed data categories, and retention limits.
• All subprocessors are explicitly named along with their operating country, specific function, and notification workflow.
• Every third-country transfer is backed by a validated mechanism and necessary supplementary safeguards.
• Model training and vendor self-use restrictions are confirmed contractually and configured appropriately in settings.
• Logging behaviors, support access controls, data export pathways, deletion routines, and offboarding procedures have been functionally tested.
• Privacy notices and chat interfaces inform users clearly; UI design discourages unnecessary submission of sensitive data.
• Requirements for a Data Protection Impact Assessment (DPIA) have been reviewed for the specific deployment scenario.
• An operational owner is assigned to monitor subprocessor updates, transfer legal developments, platform feature releases, and security assurances.

Additionally, align your setup with our foundational overview AI Chatbots and the GDPR and the guide to Privacy-Preserving Chatbot Analytics. This ensures procurement, technical implementation, and ongoing management are treated as a unified process.

Maintaining Oversight Post-Contract Execution

Vendor due diligence is an ongoing operational commitment rather than a static compliance file. Establish a periodic review schedule alongside event-driven audits. Triggers for re-evaluation include subprocessor additions, model vendor substitutions, new feature rollouts, altered data hosting locations, security incidents, expiring compliance certifications, or legal changes affecting adequacy decisions. Archive current subprocessor lists and executed contract versions with timestamps to maintain clear auditability over time.

The operational benchmark is straightforward: Can your team explain, for every relevant data flow, who processes what data and why, where processing takes place, how long data is retained, what safeguards apply, and how offboarding is executed? When these answers are verified, marketing statements yield to a defensible procurement decision. If core processing links remain unknown, the chatbot should not process live visitor data.