Open the website of any Artificial Intelligence vendor. At the bottom of the homepage, or on the "Security" page, you will almost always find the same three acronyms - "GDPR compliant," "ISO 27001 certified," "AI Act ready." These are serious certifications, requiring real investment and ongoing processes, and today they represent a threshold for entry into the enterprise market. They are, however, the starting point, not the finish line.
Among the questions a company asks when it seriously evaluates an AI vendor, there’s not just "do you have these certifications," but also a much blunter one. "What do they concretely mean for the management of my customers' data, when something goes wrong at 3 a.m.?"
There is a profound difference between "being compliant" and "making compliance verifiable." Certifications attest to the former; a third party, at a given moment and over a given perimeter, has verified the presence of a system of controls. What actually happens every day in production, however, is not captured in a PDF stamp. It lives in the logs, in the retention policies, in the contracts with sub-processors, in the incident response runbooks. If a vendor cannot, or will not, show you these things, the certification remains a label on the box. Let's try to translate each acronym into recognizable architectural choices.
GDPR in operational terms
The GDPR has applied for eight years. For anyone selling cloud services in Europe, it is no longer a talking point, but a minimum standard for entry. Compliance is decided entirely on the operational details.
Data residency and sub-processors
The first question is geographic. Where does conversation data physically live? In which data centers? Replicated where? Over its lifecycle, an AI Agent platform touches at least four categories of data: the conversation transcript, metadata, the semantic embeddings used by RAG systems, and technical logs. For each one, a mature platform can answer with the name of a region and a provider.
There is then a point that almost no one puts in writing: no AI vendor is truly "independent." Language models are often delivered by third parties such as OpenAI, Anthropic, Google, and specialized Speech-to-Text and Text-to-Speech providers. Each of these is, under the GDPR, a sub-processor. In a mature posture, they are listed by name, with the processing region, their role in the data flow, and the contractual basis.
Retention, the right to erasure, and the propagation of deletions
Conversations are personal data. Even when the user has not identified themselves, the transcript often contains elements that make them identifiable in combination with other data. The retention policy of a mature platform is explicit, configurable per workspace, and applied by default, with distinct retention periods for the different categories: transcripts, embeddings, and aggregated metrics.
Deletions are effective, not merely logical, and they leave a documentary trail: in the event of an inspection, the DPO must be able to demonstrate that the deletion took place. Data held in backups exits by natural expiry, according to the declared retention windows. For the right to erasure, a mature platform handles data-subject requests with traceable evidence and pairs this with automatic deletion when the configured retention expires, so that exercising the right does not depend on an opaque, case-by-case process.
Breach notification within 72 hours
Article 33 of the GDPR requires the controller to notify a data breach within 72 hours. The vendor, in its role as processor, must detect the incident and report it to the controller with enough margin to meet those 72 hours. In practice, this is a contractual commitment on the order of a few hours, backed by an operational detection infrastructure. The most mature vendors can state how their SOC (Security Operations Center) is structured, their historical mean time to detection, and the first contact alerted within the client's team.
ISO 27001 in operational terms
ISO/IEC 27001 is an international standard for information security management systems. Its current version, ISO/IEC 27001:2022, organizes 93 controls into four categories. Holding the certification means that an accredited third party has verified that the organization has a functioning ISMS (Information Security Management System). But "functioning" is a subtle word.
ISO 27001 does not certify a product; it certifies a management system. An AI Agent platform can be certified across the entire perimeter that delivers the service (development, infrastructure, operations, support), or over a reduced perimeter. The first step, for the buyer, is to request the Statement of Applicability (SoA) and read exactly what the scope is. In a SaaS platform, a SoA that excludes software development or cloud infrastructure makes the certification largely irrelevant. The cycle, moreover, provides for an initial audit, annual surveillance audits, and full recertification every three years. The certificate you see on the website may therefore be up to three years old, mitigated by the intermediate surveillance audits, which by definition are lighter than the initial certification or the recertification.
There is then a question that few people ask, and that separates serious vendors from the rest. What happens in the event of a breach during the validity period? An incident does not automatically invalidate the certification; there is a procedure: notification to the certification body, root cause analysis, corrective actions, and demonstration in the subsequent audit that the controls have been strengthened. It is entirely possible, and legitimate, for a certified vendor to have had an incident. What makes the difference is transparency - what happened, what was done, what changed.
The AI Act in operational terms for buyers
The AI Act, formally Regulation (EU) 2024/1689, entered into force on August 1, 2024, and applies in phases. The prohibited practices and the AI literacy obligations have been in force since February 2, 2025; the obligations on General-Purpose AI models since August 2, 2025. The provisional political agreement on the "Digital Omnibus" of May 7, 2026 - pending formal adoption and publication in the Official Journal - moves the enforcement of the high-risk systems under Annex III to December 2, 2027, and the watermarking obligations for synthetic content under Article 50(2) to December 2, 2026. The disclosure obligation toward end users under Article 50(1), which directly concerns conversational AI Agents, remains applicable from August 2, 2026. The dates shift; the substantive obligations do not.
For anyone buying an AI Agent solution, there are three concrete areas to oversee.
Risk classification
The AI Act provides for four levels: prohibited practices; high risk (systems that make decisions on access to credit, hiring, education, access to essential services, and other areas under Annex III); limited risk (systems that interact with people, subject to transparency obligations); and minimal risk. An AI Agent that handles support requests, bookings, or commercial follow-ups typically falls under limited risk. But if the same Agent makes binding decisions on the provision of an essential service or on access to credit, the regime changes radically. Primary responsibility for classification and conformity assessment lies with the provider of the system, which produces the necessary technical documentation; the deployer, in turn, must verify and document the risk category of the system it adopts, especially when its own use may alter that classification.
Transparency obligations toward end users
Article 50(1), applicable from August 2, 2026, requires that users be informed they are interacting with an Artificial Intelligence system. The AI Agent must be able to declare its nature in a configurable way, in both voice and text channels, with wording consistent with the brand's policy. This is a configuration that the vendor exposes, and that remains active even when the Agent is cloned into new workspaces or languages.
Technical documentation
If the system falls under high risk, the deployer must be able to access detailed documentation - a description of the system, the intended purpose, the training and validation datasets, the metrics, the mitigation measures, and the human oversight procedures. Part of this documentation, in particular the model cards, is maintained by the model providers; what a serious AI Agent vendor guarantees is the precise declaration of the models used and system documentation tied to the individual solution, not a generic document for the entire platform.
Privacy-by-design in the architecture
Regulatory principles do not stop at policies; they are embodied in technical choices. Privacy-by-design means that data confidentiality is a structural property of the system, not a control applied after the fact. There are three areas where the difference emerges clearly.
1. PII detection and data minimization
In a typical conversation with an AI Agent, the user spontaneously mentions their tax ID, IBAN, policy number, address, and phone number. A mature platform recognizes the presence of this sensitive data through dedicated guardrails and lets the Agent react - for example, by blocking or rerouting the flow. There is then a principle that makes the difference: users' complete messages stay confined within the vendor's infrastructure, and only the fragments strictly necessary for processing reach the model providers. When sensitive data nonetheless passes through the model, it is essential that the sub-processor be covered by an explicit DPA and that the flow be documented. This is the principle of data minimization, central to the GDPR, which rewards those who reduce the data exposed to the lower levels of the pipeline.
2. Workspace isolation between clients
A mature multi-tenant SaaS platform guarantees that one client's data never ends up, not even by mistake, in another client's workspace. This is a non-trivial technical requirement, involving isolation at the level of the database, the vector store, the cache, logging, and the development and test environments. For the most regulated clients (banking, healthcare, public sector), options for dedicated tenancy or private cloud deployment are also available.
3. Granular access control
The question is straightforward. Who on the vendor's team can see my users' conversations? On mature platforms, the answer is precise - defined roles, traced access, and an immutable audit log. Ideally, there is a mode in which even the vendor's support team cannot see the content of transcripts without the client's explicit, traceable, and time-limited authorization.
Auditability and the Trust Center as operational tools
Auditability is the point at which policies become verifiable. A system that does not allow itself to be audited asks to be taken at its word, and in the enterprise scope, that is not enough. Four components characterize serious auditability - a complete log of conversations, accessible to the client and exportable in a structured format; distributed tracing of API calls to external systems; an export function for regulatory inspection in the event of a request from an authority; and controlled access to audit trails, with immutability and tracking of privileged access.
All of this configures a precise requirement for the vendor - to make available, in a single location and on a self-service basis, the information that security, privacy, and data governance teams look for in the early phases of evaluation.
This is the function of the Trust Center. A mature Trust Center aims to cover a set of recognizable areas - active certificates with their scope and validity dates, the scope of the ISO certification, the list of sub-processors with region and role, a data residency map, default retention policies, the shared responsibility model, incident response procedures and notification times, a declaration of the models used, and a downloadable standard Data Processing Addendum.
When a vendor does not have a public Trust Center, or has one that refers every piece of information back to sales, it is an important operational signal. It means that every enterprise sale will require a private Q&A cycle lasting weeks, and that the vendor has not yet industrialized its own security posture.
The traits of a truly enterprise-ready platform
Everything above converges into a few traits that distinguish the platforms that have done their homework from those that are still studying. These are the traits that allow a security team to close an evaluation in two or three weeks, rather than three or four months.
The first is geographic transparency. For each category of data, the vendor can say where the data lives, who processes it, and what option exists for staying within a European perimeter. Answers with proper names, not formulas like "secure cloud."
The second is the specificity of the documentation. The ISO Statement of Applicability covers development, infrastructure, and operations, and the AI System Card is tailored to the individual use case, not generic.
The third is the depth of privacy-by-design: PII detection through guardrails, data minimization toward the model providers, multi-tenancy described with the level of isolation applied, and a mode in which even the vendor's support team does not access the content of transcripts without the client's traceable authorization.
The fourth is auditability by default. Accessible logs, available API tracing, and immutable audit trails.
The fifth is the incident response posture. A commitment to notification in hours, not in formulas, a named contact, and structured post-mortems shared with the impacted clients.
When these five traits are present, the conversation between the vendor and the security team stops being a laborious extraction of documents and becomes a check for consistency. This is the difference between a vendor that is ready for the enterprise and one that merely claims to be.
Security is not a separate chapter; it is a layer of the architecture. The acronyms (GDPR, ISO 27001, AI Act) are the shared vocabulary, but the real value lies in the engineering choices through which those words become system behaviors in production - PII redaction configured, isolated workspaces, auditable logs, declared sub-processors, an accessible Trust Center. The speed with which a vendor gets approved by the security team is itself a metric of maturity. For the buyer, the difference is between having an AI project in production next year or staying stuck in procurement limbo.
FAQ
What is the difference between "GDPR compliant" and being GDPR compliant in practice?
"GDPR compliant" is a vendor's self-declaration. Real compliance is measured by verifiable operational choices - where the data lives, who the sub-processors are, how effective the retention is, how fast notification is in the event of a breach, and how the right to erasure works. A vendor can declare itself compliant and, under technical scrutiny, turn out to be incomplete on one or more of these points.
Does the AI Act also apply to an AI Agent used only for customer service?
Yes, under the limited-risk regime. AI Agents for customer service typically fall under Article 50(1), which imposes disclosure obligations - the user must know they are interacting with an Artificial Intelligence system. The obligation is applicable from August 2, 2026, and was not postponed by the Omnibus of May 7, 2026, which instead deferred only Article 50(2), concerning the watermarking of synthetic content, to December 2, 2026. The regime changes significantly only if the Agent makes binding decisions in areas under Annex III, such as access to credit or the provision of essential services.
How long does a security audit of an AI vendor take on average?
It depends almost entirely on the vendor's preparedness. With a populated Trust Center, available technical documentation, and a dedicated point of contact, a security/legal evaluation closes in two or three weeks. The part that depends on the vendor - answering the questionnaires and providing the evidence - closes in a few days when the Trust Center is populated; the rest depends on the buyer's internal timelines. Without a Trust Center, with fragmentary documentation and non-standardized processes, the same process can take three or four months.
