Is SOC 2 enough for an AI agent platform?

No. SOC 2 Type II is a meaningful baseline that tells you a vendor's internal controls were independently audited and working over a defined period. It does not cover how the model provider handles your data, or how transcripts are retained and deleted. It says nothing about whether agentic actions produce an audit trail your regulator accepts, or whether your configuration is compliant. Treat it as the entry requirement, not the answer.

What does the EU AI Act require of chatbots and AI agents?

Article 50 transparency obligations became enforceable on 2 August 2026. Systems that interact directly with people must inform those people they are dealing with an AI. For a conversational agent, that notice comes before or at the very beginning of the conversation. Generative outputs must be marked in a machine-readable format so they are detectable as AI-generated. Systems placed on the market before 2 August 2026 have until 2 December 2026 for the marking and detection requirements.

Does GDPR allow customer conversations to be processed by an LLM?

Yes, with the right arrangements in place. You need a signed DPA with the platform, and the model provider documented as a subprocessor. You also need an appropriate transfer mechanism if data leaves the EU, plus configuration that matches your retention obligations. The detail that catches people out is that retention and training defaults vary by provider and by tier, so a general assurance is not sufficient. Get the specific terms for the specific model in writing.

What are the biggest security risks with AI agents?

OWASP's AI Agent Security Cheat Sheet lists thirteen categories. Four matter most in customer-facing deployments. Prompt injection, including instructions hidden in documents or tickets the agent retrieves. Tool abuse and privilege escalation through over-scoped credentials. Memory poisoning, where false information persists across sessions. And excessive autonomy on high-impact actions like refunds and account changes. Denial of wallet, where an attacker drives up your inference costs, is worth rate limiting for.

What is ISO/IEC 42001 and do vendors need it?

ISO/IEC 42001 is the management system standard for artificial intelligence, covering how an organization governs AI development and deployment. It is not yet a standard procurement requirement the way SOC 2 and ISO/IEC 27001 are, but it is appearing in AI vendor reviews and it is a reasonable question to ask. A vendor that has started the process is signaling where they expect the bar to settle.

Should we require the ability to choose our own LLM?

For regulated deployments, yes. Model choice determines your data handling terms, and those terms change. A platform that locks you to one model locks you to whatever that provider decides about retention, training and residency. Being able to switch models turns a compliance problem into a configuration change instead of a replatform.

AI Agent Security and Compliance: A 2026 Enterprise Guide

For most enterprise software purchases, security review happens late. A vendor gets shortlisted on features and price, then legal and IT are looped in to check boxes.

For AI agent platforms, that order breaks.

AI agents touch customer data at scale. They connect to CRMs, order management systems, billing platforms, and helpdesk tools. They process personal information across every channel a customer uses, store conversation history, and take action on live accounts. That is not a peripheral data risk. It is the core of what the product does, which means compliance has to shape the shortlist rather than validate it.

There is also a date on the calendar now. As of 2 August 2026, the EU AI Act's transparency obligations are enforceable, and they apply directly to systems that talk to people. If you are evaluating an AI agent builder this quarter, that changed the requirements list while you were building it.

This guide covers what SOC 2 and GDPR actually tell you, and what the AI Act now requires. It also covers the security risks a standard compliance review will not catch, and the questions to get answered in writing before you sign.

Why AI Agent Compliance Is Harder Than Standard SaaS

Most enterprise SaaS reviews follow a familiar pattern. Request the SOC 2 Type II report, review the GDPR Data Processing Agreement, check the subprocessor list, verify data residency options. Those steps are necessary. For AI platforms they are not sufficient, because four things fall outside what that checklist was designed to catch.

LLM Data Handling

When your agent processes a customer query using a large language model, that query passes through the model provider's infrastructure. Depending on the provider and the tier you are on, the data may be retained for a period, logged for abuse monitoring, or used to improve models. You need to know which model your agent runs on, what the terms are for that specific model, and whether those terms fit your obligations.

Subprocessor Exposure

An AI agent platform does not only have its own data practices. It inherits the practices of every model provider, cloud vendor, and integration partner in its stack. A GDPR-compliant platform running on a model configured outside GDPR terms still leaves you exposed. The chain is only as good as its weakest contract.

Conversation Data Retention

Platforms store transcripts for analytics and quality review. Four things are exposure points here: the retention window, the access controls on who can read transcripts, the deletion path when someone exercises their right to erasure, and the handling of sensitive details that surface mid-conversation. Health information, payment details and identifying data end up in support conversations whether or not you designed for it.

Agentic Actions and Audit Trails

When an agent updates a record, issues a refund, or changes a subscription, that action has to be logged in a form an auditor will accept. For financial services, healthcare and insurance, the question is not whether the vendor holds a certificate. It is whether the audit trail architecture satisfies your specific regime. This is where agentic systems diverge most sharply from a chatbot that only answers questions.

What the EU AI Act Changes as of August 2026

The AI Act is the first regulation written for this category, and two dates matter for anyone buying an agent platform.

Article 50 transparency obligations became enforceable on 2 August 2026. Providers must design systems that interact directly with people so those people know they are dealing with an AI. For a conversational agent, the Commission's guidance is that notice comes before or at the very beginning of the conversation. There is a narrow exception when the AI nature is obvious to a reasonably observant person, and the guidance reads it tightly: it applies where almost no doubt is left. Providers of generative systems also have to mark outputs in a machine-readable way so they are detectable as AI-generated. Systems already on the market before 2 August 2026 have a transition period to 2 December 2026 for the marking and detection piece. The full Article 50 text is worth reading with your legal team rather than summarized.

The high-risk deadline moved, and this is where plans go wrong. The Digital Omnibus was agreed provisionally on 7 May 2026. It deferred Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I obligations from August 2027 to August 2028. Two failure modes follow. Teams who built a roadmap around an August 2026 high-risk deadline are now working to a date that no longer exists. Teams who heard "the AI Act got delayed" and stopped reading have missed that Article 50 was not deferred at all.

Ask vendors how they handle AI disclosure at the start of a conversation, whether it is configurable per channel and per language, and what they mark in outputs. If a vendor cannot answer that in August 2026, that tells you something.

What SOC 2 Type II Actually Tells You

SOC 2 is an auditing framework from the American Institute of Certified Public Accountants. A Type II report confirms that a vendor's controls for security, availability, processing integrity, confidentiality and privacy were operating effectively across an observation window, commonly three to twelve months. A Type I is a point-in-time snapshot and a much weaker signal.

Type II is a meaningful baseline. It tells you the vendor has been independently audited and that stated controls were in place and working. It also tells you there is a documented framework for incidents, access management and data protection.

What it does not tell you is how your data flows through their system. SOC 2 audits the platform's internal controls. It does not certify that your deployment is compliant with every regulation that applies to you. The report says the vendor's house is in order. It says nothing about whether the way you configured your agent introduces risks their controls never contemplated.

When you read one, go straight to:

Audit scope. Which systems and services are included, and which are not.
Subprocessors. Which third parties fall under the audited controls and which are handled separately.
Incidents and exceptions. Whether controls failed during the period, and how that was remediated.
Trust Services Criteria covered. Security is standard. Availability, confidentiality and privacy signal broader coverage.

Two adjacent standards are worth asking about. ISO/IEC 27001 covers information security management and is a routine procurement ask outside the US. ISO/IEC 42001 is the newer AI management system standard, and it is starting to appear in AI vendor reviews as the thing that comes after SOC 2. A vendor working toward it is telling you something about where they think the bar is going.

If your customers include EU residents, or you operate in the UK or another GDPR-adjacent jurisdiction, your platform is a data processor and that creates specific obligations.

Data Processing Agreement. You need a signed DPA before the vendor can lawfully process personal data for you. It should cover data categories, processing purposes, the technical and organizational measures protecting that data, and the procedure for data subject requests.
Data residency. Personal data originating in the EU has to stay in the EU or in a jurisdiction with an adequate framework, or move under Standard Contractual Clauses. Your platform needs EU residency as a configuration available today, not a roadmap item. If you run multilingual support across regions, confirm residency holds for every region you serve, not just the primary one.
Right to erasure. A deletion request has to reach the agent platform and actually complete there. Transcripts, stored customer context, and anything cached for personalization must be removable, with a documented process and a stated response time.
Sensitive data in conversation. People volunteer things you did not ask for. Ask whether the platform can detect and mask personal information before it is stored or sent to a model, and where that masking happens in the pipeline.
Model-specific obligations. This is where AI platforms diverge from ordinary SaaS. If a model is processing customer data, the model provider is a subprocessor. Retention and training defaults differ by provider and by tier, and zero-retention terms are generally negotiated into an enterprise agreement rather than granted on pay-as-you-go. Do not accept a general assurance that "we don't train on your data." Ask which provider, which tier, which contract, and get it in writing.

Get started

See how leading teams design, test, and deploy AI agents at scale.

Book demo

The Security Risks a Compliance Review Will Not Catch

Certifications describe a vendor's controls. They do not describe how an agent fails once it is live and connected to your systems. Those failures have their own literature now, and the OWASP AI Agent Security Cheat Sheet is the most practical version of it. It names thirteen risk categories. Four of them account for most of what goes wrong in a customer-facing deployment.

Prompt injection. An attacker plants instructions the model treats as legitimate. Direct injection comes through the conversation itself. Indirect injection is the harder one: instructions hidden in a document, a support ticket, or a web page your agent retrieves. Any content your agent reads is untrusted input, including content from your own systems if customers can write to them.

Tool abuse and privilege escalation. Agents act through tools, and tools carry permissions. An agent with broad API credentials can be talked into using them. Scope permissions per tool rather than per agent, and separate high-trust tools from ones that touch customer-supplied data.

Memory poisoning. Agents that carry state across sessions can have that state corrupted. A false fact written into memory during one conversation gets treated as ground truth in the next. This is closely related to how hallucinations propagate, except the bad input persists deliberately.

Excessive autonomy on high-impact actions. The refund, the account change, the data export. Decide which actions require a human approval step before the agent ships, not after the first incident. OWASP also flags denial of wallet, where an attacker drives a reasoning loop to burn your inference budget. Rate limits and cost alerts are cheap insurance.

OWASP's recommended controls map onto things you can ask a vendor about directly. Input validation on retrieved content. Per-tool permission scoping. Session isolation for memory, approval gates on high-impact actions, and structured logging of every decision. That last one is where agent observability stops being an engineering nicety and starts being the evidence you hand an auditor.

The Questions to Ask Every AI Agent Platform Vendor

Get written answers before you shortlist.

On SOC 2 and certifications:

Do you have a current SOC 2 Type II report? What is the audit period and which Trust Services Criteria does it cover?
Which systems and services are in scope? Is any part of the platform excluded?
Do you hold ISO/IEC 27001? Are you pursuing ISO/IEC 42001?
Who are your material subprocessors, and are they covered by your controls or audited separately?
What is your incident notification process, and what are the response SLAs?

On GDPR and data:

Do you provide a signed DPA as a standard term?
Do you offer EU data residency? Is it a configuration option or gated behind a plan tier?
Which model providers do you use, what are the data terms for each, and can we choose or bring our own?
How do right-to-erasure requests flow through, including transcript and stored-context deletion?
Can you detect and mask personal, financial and health information before it is stored or sent to a model?

On the AI Act:

How does the platform disclose to end users that they are interacting with AI, and is it configurable per channel and language?
What outputs do you mark as AI-generated, and in what format?

On agent security:

How do you handle untrusted content retrieved from documents, tickets and web pages?
Can permissions be scoped per tool rather than per agent?
Which actions can be gated behind human approval, and how is that configured?
What is logged for every agent decision, and how long is it retained?

On your own regulatory context: if you are in financial services, healthcare or insurance, ask about the framework that governs you by name. HIPAA, DORA, FCA. SOC 2 and GDPR are the floor.

How Model Choice Shapes Your Compliance Posture

Model flexibility is the least-discussed compliance dimension in this category and one of the most consequential.

Providers differ on retention, on training use, on residency guarantees, and on what any of it costs. Your agent's compliance posture is set by whichever model is running underneath it. Platforms that lock you to a single model lock you to that model's terms. If those terms stop fitting your obligations, you are either carrying exposure or you are migrating.

Platforms that let you choose the model, or bring your own, let you treat compliance as a selection criterion alongside quality and cost. That matters more over time than it does on day one, because the terms move. A provider changes a default, a regulator issues guidance, you expand into a new region. Being able to switch is the difference between a configuration change and a replatform.

For enterprise AI deployments with real regulatory weight, model flexibility is a procurement criterion. This is also the practical gap between a code framework and a platform. When you compare agent frameworks, governance and audit trails are left for you to build. That is fine until a security review asks who approved a change.

How Voiceflow Handles Enterprise Security and Compliance

Here is our actual posture, so you can check it against the list above rather than take a claim about priorities.

Certifications. SOC 2 Type II, ISO/IEC 27001:2022, HIPAA, and GDPR. Current reports and live control status are published at trust.voiceflow.com, and the details are on our security page.

Data protection. Encryption at rest using customer-managed keys, and end-to-end encryption in transit over TLS and mTLS. Data is backed up across regions with point-in-time recovery. PII masking is available so sensitive details can be stripped before storage.

Model choice. Voiceflow is model-agnostic. OpenAI, Anthropic, Google, or your own. When a provider's terms change, that becomes a configuration decision instead of a migration project.

Audit trails and change control. Observability traces every agent decision back to the step that produced it. Environments give you dev, staging and production with version pinning, so changes are promoted rather than pushed. That is the answer to "who changed this, when, and who approved it."

What we are not. We are not a security product, and no platform certificate covers how you configure your agent. Scoping tool permissions, deciding which actions need human approval, and validating retrieved content are still your decisions. What we can do is make them configurable rather than something you build.

For regulated deployments we walk through the security architecture, the subprocessor list and the compliance documentation as part of the evaluation, not after it. Teams running Voiceflow in production include Turo, StubHub International, Sanlam Studios and Trilogy, across customer service automation, contact center and enterprise chatbot deployments.

If you are earlier in the process, the 90-day path from pilot to production sequences the security review where it belongs. The ROI framing for enterprise CX covers the business case it is attached to. For grounding, our knowledge base keeps answers tied to source documents you control, and teams building on Snowflake and similar data platforms can keep that data where it already lives.