What enterprise procurement, IT and legal teams need to know before deploying or approving Agentic AI in CX

Key points:

• The buying committee’s job is not to block Agentic AI deployment, but to define the conditions under which it’s safe to approve
• In a well governed deployment, personal data is redacted at the orchestration layer before the prompt is built, so that direct identifiers are not passed to the model. Redaction reduces risk; it does not take the processing outside GDPR
• ISO/IEC 27001:2022 and SOC 2 Type 2 are the minimum certification baseline; ask for the reports, not just the claims
• Emplifi’s pre-LLM redaction layer, SOC 2 Type 2 report and ISO/IEC 27001:2022 certification are documented and available for review, so the evidence a buying committee needs can be produced rather than described

A new request lands on your desk: the CX team wants to deploy Agentic AI.

Before you can approve it, you need to know:

• What the system can do without human approval
• Where customer data goes
• What happens when it makes a mistake
• And what the vendor will actually commit to in writing

This article answers those questions specifically for enterprise CX deployments so that your team can walk into a vendor evaluation with a clear framework, and walk out with a decision.

Why Agentic AI in CX is a governance question, not a capability question

It’s easy to see why the CX team wants to implement Agentic AI. It can reduce cost-to-serve, improve response times, and free skilled agents for higher-value work. Analysts puts the gap between assisted and self-service resolution at nearly sevenfold.

The question for IT and legal is whether the vendor has built the controls that make enterprise deployment safe. There’s a stark difference between a vendor who’s bolted on compliance as a checklist item and one who’s designed governance into the architecture from the start.

The five questions below are designed to surface that difference quickly:

The five questions IT and legal should ask every Agentic AI vendor

Let’s look at each question in more detail:

Question 1: What can the AI do without human approval, and where is that boundary enforced?

This is the foundational question, and the answer should be very specific.

A governed Agentic AI platform operates on a tiered authority model:

• Routine, low-risk actions (answering a product question, checking an order status, confirming a delivery) resolve autonomously
• Sensitive or bounded actions (a fee waiver below a configured threshold, a basic account update) execute within hard limits the brand sets in advance
• High-stakes actions (a large refund, a legal-risk response, anything involving financial advice) pause for human review before anything executes

That boundary should be enforced in the orchestration layer rather than in the model’s instructions. A limit expressed only in a system prompt is a limit the model can be argued out of.

There is a second reason to draw this boundary carefully, and it is one that vendor demonstrations rarely cover.

Where the agent decides something about a customer with no meaningful human involvement, and that decision produces legal effects for them or similarly significantly affects them, Article 22 GDPR is engaged.

A refused refund, a suspended account or a withheld goodwill payment can each fall within that description depending on the amount and the context.

Article 22 permits the processing only where it is necessary for entering into or performing a contract, authorised by Union or Member State law, or based on the individual’s explicit consent, and in the contract and consent cases the controller must provide the safeguards in Article 22(3): the right to obtain human intervention, to express a point of view, and to contest the decision.

Ask the vendor how the platform supports those safeguards in the workflow, not merely whether a human could in principle intervene.

For instance, let’s look at Emplifi’s authority model, which works as follows:

• The brand configures which action types are autonomous, which are bounded, and which always require human sign-off
• Those configurations are set before go-live and are applied by the orchestration layer rather than by the model
• Human approval for public-facing statements is configurable by the brand and is required by default
• Containment is automated, but the brand’s voice is not

The question to ask the vendor: Show me exactly where in the system the boundary between autonomous action and human-required action is enforced, and show me what happens at that boundary.

Question 2: Where does customer data go when it is entered into an AI prompt?

The correct answer is that direct identifiers should not reach the model, at least not in their original form. The fuller answer is more nuanced, and a legal reviewer should insist on it.

Redacted conversation text can still be personal data. If the individual remains identifiable from the surrounding content, from the case record, or by combination with other data the vendor holds, the processing stays within scope of GDPR and the vendor remains your processor in respect of it.

Redaction is a risk reduction measure and a strong one. It’s not a route out of the regime, and any vendor who presents it as one has misunderstood either the technology or the law.

In a properly governed deployment, an orchestration layer sits between the incoming message and the AI model.

That layer intercepts each message, applies detection rules to identify personal data, and passes the redacted text to the model. Detection is rule and model based, so it is not infallible: test the control against a sample of your own conversation data before go-live, and monitor it afterwards.

For multi-region deployments, ask the vendor specifically where data is processed and stored, which transfer mechanism covers any transfer outside the EEA, whether that is an adequacy decision, the Commission’s Standard Contractual Clauses, or binding corporate rules.

Where the Clauses are relied on, ask to see the transfer impact assessment that supports them.

For UK personal data the UK International Data Transfer Agreement or the UK Addendum to the EU Clauses is required, and the EU Clauses alone will not do. Ask too whether client data is used to train their models and get that commitment in writing.

Here’s how Emplifi answers this question:

Emplifi operates a pre-LLM redaction layer that processes incoming messages before they reach the AI model.

It’s designed to identify and remove basic categories of personal data and to pass the redacted text forward. Redaction events are logged.

Where Emplifi transfers personal data outside the EEA it relies on an adequacy decision or on the Commission’s Standard Contractual Clauses, and it concludes data processing agreements meeting the requirements of Article 28(3) GDPR with its sub-processors.

Client data is encrypted in transit and at rest. Emplifi does not use client data to train AI models except where the client has expressly instructed it to do so.

Both certifications (ISO/IEC 27001:2022 and SOC 2 Type 2) are available on request via the Trust Center.

The question to ask the vendor: Where is the DPIA that will show exactly where is PII identified, and what happens to it at each step with a data flow diagram from intake to model response?

Question 3: What is the audit trail, and can compliance actually read it?

Every autonomous action must produce a record. That record should be human-readable, timestamped, and tamper-evident, so that any alteration after the fact is detectable.

It should show what the agent did, which policy governed the decision, and what the inputs and outputs were.

This is what a regulator will ask for when something goes wrong, and it’s what your own legal team needs to defend a decision post-incident.

Emplifi writes a timestamped log with a human-readable rationale for autonomous actions. Compliance and legal teams can review a decision after the fact, including the policy the agent was operating under at the time. Logs are retained in a controlled environment with access controls and change logging applied.

The question to ask the vendor: Show me an example audit log entry from a live deployment. Is it human-readable without technical interpretation? Can you filter by action type, agent, case, and time window?

Question 4: What happens when the AI makes a mistake?

Two things need to be true: the mistake should be recoverable, and it should have been tested for before anything went live.

The standard test before any Agentic AI deployment goes live is shadow mode.

Shadow mode is a pre-go-live testing method in which the Agentic AI processes a live case queue without taking any actual action. Its decisions are logged and compared against what the human team actually did over the same period, producing an accuracy dataset compliance can evaluate before any autonomous action reaches a customer.

The length of the shadow period should be set by case volume and case mix rather than by the calendar, and should run long enough to produce a statistically meaningful sample across every case type the agent will handle.

When the agent operates live, confidence thresholds govern the escalation process. If the agent’s confidence in a proposed action falls below a configured threshold, the case escalates to a human automatically, rather than proceeding.

If a significant incident occurs, the response needs to be immediate. An enterprise deployment must allow the relevant team lead to halt all autonomous workflows instantly, without taking the broader platform offline. The availability and response time of that control belong in the contract, not in the support process.

The question to ask the vendor: What is your shadow mode process, how long does it run before go-live, and what does the accuracy comparison output look like?

Question 5: What are the contractual commitments?

Vendor claims are not contractual commitments. Before signing, legal should request and review the following specifically:

• Data Processing Addendum (DPA): Should specify what data the vendor processes, for what purpose, on what legal basis, the retention periods that apply, the current sub-processor list and how changes to it are notified and objected to, and what happens to the data on termination
• SLA commitments: What uptime is guaranteed, how is downtime measured, and what remedies apply
• Breach notification timelines: Under Article 33 GDPR, a controller must notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. A processor’s obligation under Article 33(2) is to notify the controller “without undue delay”, which is not a fixed period. Your contract should convert it into a specific number of hours, and that number needs to leave you time to assess and file. Note also that the Data Omnibus, the second half of the Commission’s digital simplification package published on 19 November 2025, would move the controller deadline to 96 hours and raise the reporting threshold to high risk. Unlike the AI Omnibus, which is now in force, the Data Omnibus remains in negotiation (and had not been adopted at the time of writing) so 72 hours remains the operative figure.
• GDPR Article 17 (right to erasure): The right is qualified rather than absolute, and Article 17(3) preserves processing that remains necessary for, among other things, compliance with a legal obligation or the establishment, exercise or defence of legal claims. Where the right does apply and the AI has processed the individual’s data, what is the vendor’s process for removing that data from every system, including backups, logs and any fine-tuning data, and within what period?
• Liability and indemnities: Is the liability cap proportionate to the volume and sensitivity of the data being processed, is there a separate and higher cap or an uncapped carve-out for data protection and confidentiality breaches, and does the vendor indemnify you against third-party intellectual property claims arising from model output?
• EU AI Act role allocation: Does the contract state expressly who is the provider and who is the deployer of the AI system, and does the vendor commit to supplying the technical information and instructions for use that you need in order to meet your own obligations?
• Audit rights: Does the DPA give you the right to audit the vendor’s compliance posture, or is it limited to third-party certifications?

Emplifi’s SOC 2 Type 2 report and ISO/IEC 27001:2022 certification is available on request via support@emplifi.io. 

The question to ask the vendor: Send us your standard DPA, and confirm in writing your breach notification SLA and your process for handling Article 17 requests where AI has processed the relevant data.

The EU AI Act layer: who is the provider, and who is the deployer?

GDPR is no longer the only regime in play, and any brief written for a 2026 buying committee that stops at GDPR is out of date.

Since 2 August 2026, the transparency obligations in Article 50 of the EU AI Act have applied. A CX agent that interacts directly with customers is squarely in scope: under Article 50(1) the provider must ensure the system is designed so that the individual is informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person in the circumstances of use.

The obligation bites on systems already on the market, not only on new deployments, and Article 99(4) sets administrative fines of up to EUR 15 million or 3 per cent of total worldwide annual turnover, whichever is higher.

Making the disclosure is the easy part. Allocating the roles is where deployments go wrong.

In a typical CX deployment, the vendor is the provider of the AI system and the brand is the deployer, and their obligations differ. The allocation is not permanent.

Article 25(1) converts a deployer into a provider in three situations, all of them concerned with high-risk systems:

• Putting your own name or trade mark on a high-risk system
• Substantially modifying one
• Or, most relevant here, modifying the intended purpose of a system that was not high-risk so that it becomes high-risk

That third limb is the one that catches CX teams. Point a general customer service agent at credit eligibility triage or at screening job applicants and you have not merely changed a workflow, you have quite possibly made your own organization the provider of a high-risk AI system, with the conformity assessment obligations that follow.

Confirm the allocation in the contract, and re-confirm it whenever the use case moves.

Most CX use cases are not high risk under Annex III, but that’s a conclusion to be reached rather than assumed.

Agentic AI used in creditworthiness assessment, in decisions about access to essential private services, or in an employment context will be caught.

The AI Omnibus, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, moved the application date for standalone Annex III high-risk systems from 2 August 2026 to 2 December 2027, and for AI embedded in regulated products under Annex I to 2 August 2028.

That’s time to prepare, not a reason to defer the classification exercise, and it left Article 50 untouched. The Article 4 AI literacy obligation, which falls on providers and deployers alike, has applied since 2 February 2025 and is frequently overlooked.

Ask the vendor:

• Are you the provider of this system?
• How is Article 50 met in the standard configuration?
• Can the disclosure be disabled by a customer?
• And what technical documentation and instructions for use will you give us to support our own position as deployer?

A vendor who has thought about the AI Act will answer in a sentence each. A vendor who has not will offer to come back to you.

How to structure the internal approval process

The sequence of the internal approval process matters.

Starting with governance architecture and working toward contractual commitments is much faster than reviewing the contract before you understand what you’re buying.

Step 1: Data flow and PII handling first. Before anything else, request the data flow diagram and confirm how PII is handled at the point of model interaction. This is the highest-risk area and the most likely source of a GDPR compliance gap. If this step produces concerns, they need to be resolved before the rest of the review proceeds.

Step 2: Governance model and audit trail second. Once data handling is confirmed, review the authority model, including what the agent can do autonomously, what the escalation triggers are, and what the audit log looks like in practice. Request a sample log from a live deployment.

Step 3: EU AI Act classification third. Classify the system before you look at the paper. Decide whether your organization is a deployer or, because of how you have branded or configured the system, a provider. Confirm that the Article 50 disclosure is present in the configuration you actually intend to run, and record the classification and the reasoning. This takes an afternoon, and it is the document you will want to produce if a supervisory authority ever asks.

Step 4: Certifications and security posture. Request the SOC 2 Type 2 report and the ISO/IEC 27001:2022 certification scope document. For regulated industries, confirm whether the platform’s scope covers your specific deployment context.

Step 5: Contractual review last, with the above as context. Legal review of the DPA is faster and more accurate when you already understand the data flow, governance model, and certification posture. The DPA review should confirm what the earlier steps uncovered.

Questions to ask the vendor security team directly:

• Who is your Data Protection Officer, and how do we contact them?
• What is your incident response process and our contractual breach notification SLA?
• Can you provide a reference contact at an existing enterprise customer in a regulated industry?
• What is your process for handling a GDPR Article 17 erasure request where AI has processed the relevant data?
• Are you the provider of this AI system under the EU AI Act, and what documentation will you give us to support our obligations as deployer?
• Which sub-processors have access to our data, in which countries are they located, and how will we be notified of changes to that list?

Final thoughts: Make Agentic AI safe to deploy by asking the right questions

The right outcome here is a yes, but with the right conditions attached.

The five questions above give you those conditions. A vendor who can answer them specifically, in writing, has built governance into the product. One who can’t has built it into the marketing.

Emplifi’s Trust Center and security documentation are there when you’re ready to check.

For a technical walkthrough of the Emplifi platform, a copy of the DPA, a demo or please contact support@emplifi.io.

This article is general information about enterprise procurement and AI governance practice. It is not legal advice and it does not create a lawyer-client relationship. Regulatory positions stated here are current as at the date of publication. Organisations should take their own advice on their specific circumstances.

You may also be interested in:

What is content orchestration in the age of Agentic AI? The complete guide for enterprise CX teams

The social media manager’s guide to Agentic AI: what it actually changes about your workflow

Implementing Agentic CX: A step-by-step guide to AI customer service