Before a company engages a chatbot provider, procurement, IT, and data protection teams typically review six areas: contract and GDPR, hosting and data location, certifications, AI-specific considerations, integration into existing systems, and ongoing operations. Each area can be clarified with a few targeted questions. Difficulties usually arise elsewhere: with promises that sound good but lack supporting evidence. This checklist organizes the questions and shows how to identify a reliable answer.
At a Glance
Contract and GDPR: DPA with a complete list of subprocessors, notification obligations, audit rights.
Hosting: Location, third-country transfers, encryption, key management, deletion.
Certifications: Who exactly is certified—the provider or their data center?
AI-specific: External language models, training with customer data, grounding in sources, labeling.
Integration: Single sign-on, user management, roles, and logging.
Operations: Availability, support, penetration tests, export upon contract termination.
What Is Meant by "Bot Management"
The term is used in two ways. In IT security, bot management refers to defending against automated access to websites, such as scrapers, credential stuffing, or DDoS attacks. In customer service, it refers to managing proprietary chatbots: who maintains content, who approves changes, and how operations are monitored. This checklist addresses the second meaning: the compliance of the chatbot provider and their platform.
The Checklist across Six Areas

1. Contract and GDPR
Is there a Data Processing Agreement (DPA) pursuant to Art. 28 GDPR, including an annex detailing data categories, data subjects, and subprocessors?
Is the list of subprocessors complete, including registered offices and purposes?
How quickly does the provider report a data breach, and how do they handle inquiries from authorities?
Are the technical and organizational measures (TOMs) available as a document?
Are audits at the provider possible, and under what conditions?
How to recognize a good answer: The DPA is provided without asking, the list of subprocessors is short and specific, and reporting deadlines are stated in the contract.
2. Hosting and Data Location
Where are the data processed and stored, including backups?
Is data transferred to third countries?
How is data encrypted in transit and at rest?
Who manages the keys, and can the company bring their own?
Can the company define its own retention and deletion periods?
How to recognize a good answer: A specific location, a clear statement regarding third-country transfers, and retention periods configured directly in the system by the company.
3. Reading Certifications Correctly
Certificates are the area where phrasing most frequently promises more than it actually delivers. Three questions help when reviewing them.
Who is certified? An ISO 27001-certified data center means that the data center operator has an audited information security management system. It says little about the application running on it. Ask whether the provider itself is certified or aligns with the standard.
What is the scope? A certificate applies to a defined scope. Have them demonstrate whether the platform you are using is included.
What evidence exists in lieu of a certificate? Penetration tests, security concepts, availability reports, and the infrastructure operator's attestations can also support an assessment if they are transparently labeled for what they are.
How to recognize a good answer: The provider clearly states what is certified and what is not, and provides the data center's evidence as such.
4. AI-Specific Questions
Are the language models hosted by the provider itself, or are requests routed to an external AI provider?
Is customer data used to train models, including across different customers?
Does the chatbot answer exclusively from approved sources, and can every answer be traced back to the source?
Is the AI disclosure requirement implemented in accordance with Art. 50 of the EU AI Act?
How does the provider classify its system under the EU AI Act, and what documentation does the operator receive?
How to recognize a good answer: An unambiguous statement regarding external AI providers and model training, backed contractually.
5. Integration into Existing Systems
A chatbot accesses company systems and data. Therefore, it must meet the same requirements as any other application in the landscape.
Does the platform support Single Sign-on via SAML or OAuth?
Can user management be integrated with the existing directory via SCIM?
Are there distinct roles for administration, content editing, live agents, and analytics?
Are all changes recorded in an audit log?
Is it documented which data flows to the CRM, ERP, or ticketing system?
How to recognize a good answer: Integration with identity providers is standard, and the audit log is comprehensive, with no administrative backdoors outside of logging.
6. Operations and Exit
What availability does the SLA guarantee, and what happens if it is not met?
What are the support hours, and what are the response times?
Are penetration tests conducted on a regular basis?
How are updates deployed, and are there separate environments for testing and production?
What does the company receive upon contract termination, and how is data deletion confirmed?
How to recognize a good answer: An SLA with service credits, and a clearly defined offboarding process including data export and a certificate of deletion.
How Mercury.ai Answers the Checklist
Area | Mercury.ai’s Answer |
|---|---|
Contract and GDPR | DPA pursuant to Art. 28 GDPR with annex; subprocessor per DPA is AWS. TOMs available upon request. Mercury.ai notifies of data breaches without undue delay, and handles authority requests within two business days at most. Audits are agreed on a contractual basis. |
Hosting | Exclusively AWS Frankfurt, no transfers to third countries. TLS 1.3 and AES-256, key management via AWS KMS and HSM, optionally managed exclusively by the customer. Retention and deletion periods are configured by the customer directly. |
Certifications | The data centers used are certified according to ISO 27001; Mercury.ai aligns with the standard. We provide AWS certificates upon request, clearly designated as evidence from the infrastructure operator. |
AI-specific | Self-hosted, licensed Mistral models; no calls to external AI providers; no model training using customer data. Responses generated strictly from approved sources, traceable back to the source. AI disclosure enabled by default in the chat widget. |
Integration | Single Sign-on via SAML or OAuth, user provisioning via SCIM, roles for administration, editing, live agents, and analysts, comprehensive audit log without unlogged access pathways. |
Operations | SLA with at least 99% uptime and service credits, regular penetration testing, separate environments for staging, testing, and production. Data export and confirmation of deletion upon contract termination upon request. |
Details are available in the Security Paper on the EU AI Act. For the documentation operators must maintain themselves, see the article on The AI Act in Chatbot Operations. To learn how query data moves through the platform, read Where Customer Data Flows in an AI Chatbot.
Conclusion
A chatbot provider's compliance review covers six areas, and a few targeted questions suffice for each. The most time is saved by scrutinizing certificates and commitments to verify their exact scope. A provider that is transparent about what it offers—and what it does not—will clear the assessment much faster than one whose claims require decoding first.
Are you preparing to assess a chatbot provider? Talk to us.

About the Author
Dr. Hendrik ter Horst
Chief Product Officer @Mercury.ai
Dr. Hendrik ter Horst is Chief Product Officer at Mercury.ai. He holds a PhD in Computer Science from the CITEC Institute at Bielefeld University, with a focus on machine information extraction and data processing. For ten years, he has been working on dialogue-based AI systems, overseeing the conception, implementation, and validation of AI-powered applications from initial idea to production deployment.





