AI security and the RGPD (Spain's GDPR): what to demand from your provider before signing

Taking on an AI system without first auditing its security measures and GDPR compliance is like signing a tenancy agreement without viewing the flat. Once the system starts processing data about customers, employees or suppliers, the legal responsibility falls on you, even if a third party built the technology. A security failure, a leak or a misuse of personal data can cost you fines of up to €20 million or 4% of annual global turnover under the GDPR (RGPD in Spanish, the EU General Data Protection Regulation). The fine makes no distinction as to whether the fault was yours or your supplier’s: the Spanish Data Protection Agency (AEPD, Agencia Española de Protección de Datos) will open proceedings against you first.

This article gives you a technical and legal checklist for assessing an AI supplier before you sign the contract. We cover the mandatory GDPR clauses, the security measures you should demand, how to verify real compliance and which warning signs justify ruling out a supplier. It is written for SME managers, sole traders (autónomos, the Spanish term for self-employed professionals) and founders who are about to commission AI automation, WhatsApp chatbots or phone agents and need to know what to ask before it is too late.

This page is for information only and is not binding advice. Each case is tailored after a diagnosis.

TL;DR

• The GDPR makes you the data controller even if you subcontract the AI; the data processing agreement is mandatory and must include specific clauses on security, auditing and breach notification.
• Demand verifiable documentation of the supplier’s technical measures: encryption at rest and in transit, auditable logs, role-based access control, encrypted backups and a disaster recovery plan.
• If the system processes special categories of data, makes automated decisions or monitors on a large scale, you need a Data Protection Impact Assessment (DPIA) before starting.
• Servers outside the EU require additional safeguards (standard contractual clauses, certifications) and an analysis of international transfers following Schrems II.
• Warning signs: the supplier refuses to show you the processing agreement before you sign, does not document its security measures, stores passwords in plain text or uses AI models without disclosing their location and subcontractors.
• Before signing, validate certifications (ISO 27001, ENS, SOC 2), ask for references from clients in regulated sectors and check that the supplier has professional indemnity insurance.

Why security and the GDPR are not optional in AI

European regulation makes no distinction between “AI” and “traditional software” when it comes to data protection. If your AI system processes personal data (names, phone numbers, emails, IP addresses, cookies, voice transcripts, purchase history), you are required to comply with the GDPR from day one. A customer service chatbot, a phone agent that qualifies leads or an automation that syncs your CRM with WhatsApp processes personal data in every interaction.

The difference from traditional software is that AI systems tend to involve more players: the platform provider, the language model provider (OpenAI, Anthropic, Google), the infrastructure provider (AWS, Google Cloud, Hetzner), and telephony or messaging subcontractors. Each link in that chain can be a point of leakage. If a subcontractor leaks a WhatsApp conversation or a log containing customer data, the initial penalty falls on you as data controller, even though you can later claim against the supplier.

In addition, the European AI Regulation (AI Act), which came into force in 2024 and is being applied in phases until 2026, introduces further obligations for high-risk AI systems (staff management, credit assessment, essential services). Even if your customer service chatbot is not high-risk, the supplier must document the model’s traceability, the training data and the measures against discriminatory bias. Demanding that documentation before signing can help you reduce the risk of future penalties.

Legal responsibilities: who answers if something goes wrong

The GDPR distinguishes two roles: data controller and data processor. The controller decides what data is collected, for what purpose and for how long. The processor handles the data on the controller’s behalf, following its documented instructions. In most AI projects for SMEs, you are the controller and the supplier is the processor.

That means that if the system leaks data, you answer to the individuals affected and to the AEPD, even if the breach was caused by the supplier. You can then claim damages from the supplier if it breached the processing agreement, but the administrative fine reaches you first. That is why it is critical to:

• Sign a data processing agreement before the system processes its first piece of data.
• Include clauses requiring immediate breach notification (the processor must alert you within 24 hours).
• Define the minimum technical measures required (encryption, logs, access control) and periodic audits.
• Agree a liability arrangement that shares the cost of penalties according to the cause of the breach.

If the supplier acts as a joint controller (deciding with you what data to collect or how to use it), you are both jointly and severally liable before the AEPD. If it is an independent controller (using the data for its own purposes, such as improving the AI model), it is liable separately. Clarifying these roles in the contract avoids surprises.

What the contract should include (GDPR and technical clauses)

Article 28 of the GDPR requires the processing agreement to include, as a minimum:

• Identification of the controller and processor, with contact details for each party’s DPO (data protection officer), if there is one.
• Subject matter, duration, nature and purpose of the processing.
• Types of personal data (names, emails, phone numbers, voice transcripts, IP addresses) and categories of data subjects (customers, leads, employees).
• Obligations of the processor: process the data only on documented instructions, guarantee staff confidentiality, apply technical and organisational measures (encryption, logs, access control), notify breaches within 24 hours, cooperate in audits, and return or destroy the data at the end of the contract.
• Subcontracting arrangements: the processor may not subcontract without your prior written authorisation. If it does, it must impose the same obligations on the sub-processor and answer to you for its compliance.
• Audits: the right to inspect the processor’s premises, systems and documentation, with reasonable notice and under a confidentiality agreement.
• Return or destruction of data: at the end of the contract, the processor returns all data and copies, or destroys them in a certifiable way, unless a legal rule requires them to be retained.
• Limitation of liability: if the contract includes a limitation of liability clause (typical in SaaS), make sure it does not cover GDPR breaches, gross negligence or intentional security breaches.

Beyond what is mandatory, it is worth adding:

• Specific technical measures: AES-256 encryption at rest and TLS 1.3 in transit, auditable logs kept for 12 months, multi-factor authentication for administrative access, daily encrypted backups with 30-day retention, and a disaster recovery plan (RTO < 4 hours, RPO < 1 hour).
• Availability and performance SLA: if the system goes down, how long the supplier takes to restore it and what compensation you receive.
• Regulatory change clause: if the GDPR or the AI Act change, both parties renegotiate the contract within a reasonable timeframe.
• Professional indemnity insurance: the supplier must hold a policy covering at least €1 million in claims arising from data breaches or GDPR non-compliance.

If the supplier sends you a generic SaaS contract without these clauses, ask for a specific data processing annex. If it refuses, rule it out.

Technical measures you should demand (encryption, logs, access, backups)

The GDPR requires technical and organisational measures appropriate to the risk. “Appropriate” does not mean the same for an online shop as for a clinic processing health data, but there is a minimum required of any AI system that handles personal data:

• Encryption: AES-256 for data at rest (databases, backups, logs), TLS 1.3 for data in transit (APIs, webhooks, connections to AI models). If the supplier uses encryption in transit but not at rest, any unauthorised access to the server exposes all the data in plain text.
• Access control: multi-factor authentication (MFA) for administrative access, role-based access control (RBAC), and audit logs showing who accesses which data and when. If the supplier gives its developers direct access to production without MFA, that is a warning sign.
• Auditable logs: a record of all critical operations (creation, viewing, modification and deletion of personal data, administrative access, configuration changes) with timestamp, user, IP and action. Minimum retention of 12 months. Logs must be immutable (write-once) and encrypted.
• Backups: daily encrypted copies, stored in a different geographical location from the main system, with retention of at least 30 days. Documented restore tests every quarter. If the supplier does not take backups or does not test them, a ransomware attack can destroy your data with no possibility of recovery.
• Data isolation: if the supplier offers a multi-tenant SaaS, each client should have its own isolated schema or database, not just logical segregation through SQL filters. A configuration error in a filter can expose one client’s data to another.
• Disaster recovery plan: documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective), with automated failover procedures if the system is critical. A WhatsApp chatbot that handles orders in real time cannot be down for 48 hours.
• Secrets management: passwords, API keys and tokens never in source code or in plain-text environment variables. Use of secrets managers (AWS Secrets Manager, Vault, 1Password) and periodic rotation.

Ask the supplier for a technical document detailing each of these measures. If it replies with generalities (“we use industry best practice”), insist on specifics: encryption algorithm, backup frequency, server location, access policy.

How to audit the supplier before signing (checklist)

Before signing, check:

1. Certifications and standards: ISO 27001 (information security management), ENS (Esquema Nacional de Seguridad, Spain’s National Security Framework, if the supplier works with public administrations), SOC 2 Type II (audit of security and availability controls). Certifications do not guarantee GDPR compliance, but they are an indicator of maturity.
2. Up-to-date privacy policy: it must mention the GDPR, identify the controller and the DPO, explain the legal basis for each processing activity, and set out international transfers and data subjects’ rights. If the policy dates from 2018 or earlier, it may be out of date.
3. Record of processing activities: the supplier must have an up-to-date record (mandatory if it has more than 250 employees or processes special categories of data). Ask for a copy, at least of the activities that affect you.
4. References from clients in regulated sectors: if the supplier works with clinics, law firms, accountancy practices or financial institutions, it has been through stricter audits. Ask for reference contacts and ask them about security incidents.
5. Data Protection Impact Assessment (DPIA): if your project involves automated decisions, special categories of data or large-scale monitoring, ask the supplier to help with the DPIA or to provide its own if it has already done one for similar cases.
6. Proof of concept with synthetic data: before connecting the system to your real CRM or database, run a test with fictitious data and review the logs, access and traces. If you see plain-text data in logs or URLs, that is a warning sign.
7. Draft processing agreement: the supplier must send you the contract before the commercial signature, not after. If it says “let’s sign first and I’ll send you the GDPR annex afterwards”, refuse.

If the supplier passes these filters, ask for a technical meeting with its DPO or head of security. Ask about the breach notification procedure, the average incident response time, the business continuity plan and its record of penalties (if it has had any).

Servers, subcontractors and international transfers

The GDPR allows personal data to be transferred outside the European Economic Area (EEA) only if the destination country offers an adequate level of protection or if additional safeguards are applied. Following the Schrems II ruling (2020), which invalidated the Privacy Shield between the EU and the US, transfers to the US require standard contractual clauses approved by the European Commission and a case-by-case analysis of the risks.

If your supplier uses servers in the US (AWS us-east-1, Google Cloud us-central1, Azure East US) or subcontracts US AI model providers (OpenAI, Anthropic, Google Gemini hosted in the US), you need:

• Standard contractual clauses (SCC) signed between you and the supplier, and between the supplier and each subcontractor outside the EEA.
• Transfer Impact Assessment (TIA): an analysis of whether the laws of the destination country (for example, FISA 702 or Executive Order 12333 in the US) allow government access without safeguards equivalent to the GDPR, and what additional technical measures the supplier applies to mitigate this (end-to-end encryption, anonymisation, data minimisation).
• Documentation of subcontractors: a list of all sub-processors (hosting provider, AI model provider, telephony provider if it is a voice agent), with their geographical location and the type of data they process.

If the supplier uses servers in the EU (Hetzner Germany, OVH France, AWS eu-west-1 Ireland) and AI models hosted in the EU (Anthropic Claude via AWS eu-west-1, Mistral, in-house models), the international transfer rules do not apply, but it is still obliged to document subcontractors and apply the security measures.

Some compliant alternatives:

• Suppliers that offer EU data residency (all data and logs are stored and processed exclusively on EU servers).
• On-premise or private cloud AI systems (isolated VPC) where you control the infrastructure and the supplier only delivers the software.
• Open-source AI models (Llama, Mistral) deployed on your own European infrastructure, with the supplier acting as integrator.

If the supplier cannot document where its servers are, which subcontractors it uses or how it manages international transfers, it is not a viable option under the GDPR.

Warning signs: when NOT to hire

Rule out the supplier if it:

• Refuses to sign a data processing agreement before starting, or tells you that “the GDPR is covered in the terms of service”.
• Does not document its security measures or replies with generalities when you ask about encryption, backups or logs.
• Stores passwords in plain text or uses weak hashing algorithms (MD5, SHA-1 without salt). If a developer can see your password, they can see all the data.
• Has no professional indemnity insurance covering data breaches or GDPR penalties.
• Uses AI models without disclosing their location: if you do not know whether the model is in the US, China or the EU, you cannot assess the international transfer risk.
• Does not take backups or does not test them regularly. Ransomware destroys your data in minutes.
• Offers prices well below the market with no technical justification. Security and compliance have a cost; a supplier charging much less than the competition may be cutting corners on encryption, audits or redundant infrastructure.
• Has no verifiable references from clients in production, or refuses to give them “for confidentiality reasons” (it can give you contacts with prior consent).
• Asks for administrator access to your CRM, database or control panel without MFA, access auditing or a time limit.

If you spot two or more of these signs, look for another supplier. The initial saving does not make up for the risk of an AEPD penalty or a class action from customers affected by a leak.

Frequently asked questions

Who is responsible if an AI chatbot leaks customer data?

It depends on the contract. If you are the data controller and the supplier acts as processor, you answer to the individuals affected and to the AEPD, but you can claim against the supplier if it breached the processing agreement. If the supplier is a joint or independent controller, it shares the responsibility. That is why it is critical to define roles and obligations in writing before signing.

Which GDPR clauses should the contract with an AI supplier have?

As a minimum: identification of the controller and processor, purpose and duration of the processing, types of data and categories of data subjects, the processor’s obligations (encryption, logs, breach notification), subcontracting arrangements, audits, return or destruction of data at the end, and a limitation of liability aligned with the GDPR. All in writing, before the system processes its first piece of data.

Can I use an AI system without carrying out an impact assessment (DPIA)?

It depends on the risk. If the system makes automated decisions about people, processes special categories of data (health, ethnic origin) or monitors on a large scale, the DPIA is mandatory. In practice, any chatbot or voice agent that handles customer data justifies at least a light-touch assessment. Consult a DPO or legal adviser before starting.

How do I verify that the supplier complies with the GDPR before signing?

Ask for certifications (ISO 27001, ENS, SOC 2), documentation of its technical measures (encryption, backups, logs), an up-to-date privacy policy, a record of processing activities, and references from clients in regulated sectors. If it refuses to show you the processing agreement before signing or does not document its measures, rule it out.

What happens if the supplier uses servers outside the EU?

You need additional safeguards: standard contractual clauses approved by the European Commission, certification under an adequacy framework (if one exists), or supplementary technical measures (end-to-end encryption, anonymisation). Following Schrems II, transfers to the US and other third countries require case-by-case analysis. Demand documentation of the safeguards applied from the supplier.

Is it mandatory to have a DPO if I use an AI system in my company?

Not always. A DPO is mandatory if you are a public authority, if your core activity involves regular and systematic monitoring on a large scale, or if you process special categories of data on a large scale. An SME using a chatbot for basic customer service is not usually required to have one, but appointing a DPO (internal or external) makes compliance easier and reduces risk. Consult a legal adviser for your specific case.

Next step

If you need to audit an AI supplier before signing, go through the checklist in this article and download the GDPR clause template from the legal section. If you already have an AI system in production and want to check that it complies, request a free technical and legal diagnosis that includes a contract review, an assessment of security measures and a prioritised action plan. If you are looking for a supplier that complies by design, see our services for AI automation, voice agents and WhatsApp chatbots, all with European infrastructure, a processing agreement included and a pre-deployment security audit.