Chapter 9 — Keeping AI out of PCI Scope

Opening scene — Elena samples the archive

At 8:23 on a Tuesday morning in an unremarkable office park outside Charlotte, Elena Rodrigues — a Qualified Security Assessor, thirteen years on the audit side, employed by one of the four accreditation firms whose reports the payment card brands recognize — sets down her coffee and opens the read-only login the client’s IT team provisioned for her the previous Friday. She is here for the annual PCI DSS Report on Compliance for a mid-market e-commerce retailer whose subscription service takes about 40% of its payments over the phone.

She spends the first hour on documentation. The network diagrams. The data flow diagrams. The inventory of systems that touch cardholder data. Then, at 9:31, she does what a QSA does at every voice-payments audit. She samples the call recording archive.

She picks a call at random from the previous month. The audio quality is good. She fast-forwards to the point in the recording where the customer service rep would have asked for a credit card. And there it is — the customer, reading her Visa number one digit at a time, sixteen digits, then the three-digit CVV, then the expiration date. All of it, recorded, sitting in an archive that the client’s own diagrams do not describe as a cardholder data environment. She picks another call at random. Same thing. And another. The pattern is consistent.

Elena writes a single line in her notes: “Full PAN captured in unredacted call recordings retained for 400+ days across approximately 2M interactions per year. AI-driven transcription pipeline appears to consume same recordings for downstream summarization and QA.” She takes another sip of coffee. This audit is not going to end well.

In the world of payments, the systems that touch a credit card get regulated harder than the systems that don’t — and modern AI has a chronic habit of touching things it wasn’t supposed to.

9.1 What PCI DSS v4.0 actually says

PCI DSS — the Payment Card Industry Data Security Standard — is a specification maintained by the PCI Security Standards Council, the joint industry body founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB. Version 4.0 was released in March 2022, with a transition period that ended in March 2025. As of 2026, every merchant that stores, processes, or transmits cardholder data is expected to be compliant with 4.0 (or its 4.0.1 point release from mid-2024).

Version 4.0 introduced several changes that matter specifically for AI-heavy contact centers. The Standard now explicitly recognizes “customized approaches” — a merchant can demonstrate that a control’s intent is met through means other than the specifically-prescribed technical mechanism, subject to documented risk analysis and QSA sign-off. Authentication requirements have tightened: MFA is required for all non-console access to the CDE, not just administrative access. And logging requirements now explicitly cover “all system components,” including cloud services and third-party components.

The critical concept, and the one that determines whether an AI system is subject to all of this or not, is scope. A system is in scope if it stores, processes, or transmits cardholder data, or if it is connected to a system that does. The single most valuable operational move a merchant can make is to reduce scope — to keep as many systems as possible out of scope for as long as possible. The default trajectory of a modern AI-powered contact center is to accidentally suck systems into scope. The engineering work is to prevent that from happening.

9.2 The “LLM Scope Rule” — how AI accidentally sucks systems into PCI scope

There is a piece of PCI folklore that has emerged in the last two years as auditors have grappled with LLM-powered contact centers. It doesn’t have an official name in the Standard, but the practitioners call it the “LLM Scope Rule.” It states, informally: any system that can, in the course of its normal operation, come into contact with cardholder data is in scope for PCI DSS — even if it wasn’t designed to.

There are variants — the memory of the conversational agent that persists across turns, the log lines emitted by the orchestration layer, the debugging traces the engineering team enabled during the pilot and forgot to disable in production. Each is a distinct vector into scope, and each has caused an actual finding in an actual audit in the last twenty-four months.

The financial impact of scope creep is not subtle. A merchant that runs its PCI compliance program on a scope of six systems and then discovers, at audit, that the scope is actually twenty-three systems will spend the next audit cycle scrambling to retrofit controls onto systems that were never designed to have them. The QSA is not going to soften the finding. The acquiring bank is not going to waive the remediation timeline. And the annual cost of the compliance program goes from mid-six-figures to mid-seven-figures, largely in perpetuity, until the scope gets reduced.

9.3 Why post-call redaction fails audits

For years, the standard approach to keeping cardholder data out of contact center records was post-call redaction. The pipeline records the whole call. A post-processing step scans the transcript for anything that looks like a credit card number, redacts it, and stores the redacted version. This approach fails PCI DSS v4.0 audits.

The problem is transient data. Between the moment the customer speaks the card number and the moment the redaction script runs — even if that gap is only seconds — the unredacted card number exists in some form in the system. It exists in the audio recording file, in the raw transcript, in the memory of the transcription service, in the working buffers of any AI component that operated on the call in real time, and in the temporary storage of the message-queuing system. Every one of those transient states is a place where cardholder data existed in the clear.

The auditor’s question is not “does the data exist in the final storage location?” The auditor’s question is “does the data exist anywhere in your systems, at any point in its lifecycle, in unencrypted form?” Post-call redaction fails the second question.

Real-time redaction is a partial improvement but has its own failure modes. A real-time transcription-and-redaction pipeline sees a stream of tokens coming out of the ASR system. It has to identify a card number as it is being spoken, before the full number is emitted, in order to prevent the number from reaching downstream systems. Get the timing wrong — miss the first two digits, misidentify the sequence as a phone number, or hesitate one digit too long — and the data has leaked.

A third variant is worth naming because some vendors are still selling it: the “the AI won’t retain sensitive information” claim. Some LLM vendors have marketing pages that describe their models as trained not to retain or repeat sensitive information observed in conversation. This is true in the sense that the model is unlikely to gratuitously repeat a card number in unrelated later responses. It is false in the sense that satisfies PCI. The card number was in the input context. Once it was in the input context, it was processed by the model. Once it was processed by the model, it existed in the vendor’s infrastructure. That is what “processed” means in PCI DSS terminology.

9.4 Network-level DTMF masking

DTMF stands for Dual-Tone Multi-Frequency. Those are the specific pairs of audio tones your phone generates when you press the 1, 2, 3, or any other key on the keypad. Each key produces two simultaneous tones from a specific pair of frequencies — the 1 key produces a 697 Hz low tone and a 1209 Hz high tone; the 5 key produces 770 Hz and 1336 Hz. The dual-tone design was chosen in the 1960s by Bell Labs engineers because it is nearly impossible for human speech to accidentally produce the exact tone pairs.

The security problem with basic DTMF payment is that the tones themselves, if captured in the call recording, are trivially decodable. Anyone with a copy of the recording can extract the card number by running the audio through a free open-source DTMF decoder. A call recording that includes the customer entering their card via keypad is functionally equivalent to a recording of them reading the card number aloud.

The customer hears their own keypad tones as usual (played by their local phone). The agent hears silence or a soft beep. The recording contains silence or a soft beep. The transcription service transcribes silence or a soft beep. The AI components downstream never see the card number, in any form.

The vendors that ship this capability as a specific product line include Semafone (now Sycurio), PCI Pal, Eckoh, PayGuard, and — increasingly — the major CPaaS platforms as native features. Twilio exposes it as a specific SIP header. Genesys ships a native “secure pause” that combines DTMF masking with recording suppression. Amazon Connect requires you to combine its recording controls with a third-party DTMF masking service, because Amazon has not (as of this writing) shipped its own.

9.5 Pause-and-resume architectures — the modern standard

The full architectural pattern that has now become the industry standard is called pause-and-resume, and it wraps DTMF masking in a workflow that keeps every AI component of the contact center outside the CDE.

The elegance of this architecture is that it isolates the cardholder-data-touching moment to a single, tightly-controlled component — the network-level DTMF handler, often provided by a third party whose entire business is being in PCI scope on your behalf — and it keeps every other component of the contact center out of scope entirely. The AI, the recording, the CRM, the QA tool, the reporting warehouse: all outside.

Several vendors sell this architecture as a service. Sycurio’s Digital Voice+, PCI Pal’s Agent Assist, Eckoh’s CallGuard, and newer entrants like PayGuard and Aeriandi all offer pause-and-resume patterns with variations on how DTMF is masked and how the tokenization is handled. Genesys Cloud has a “secure flow” primitive. Five9’s Payment Capture is similar. NICE CXone ships a native payment capture module.

The variants worth knowing about are the ones that handle the voice-only case. Some customers refuse to use the keypad — particularly older customers and customers using cordless phones with unreliable keypad detection. For those customers, the pattern needs a different mechanism: voice masking (real-time ASR that identifies card-number speech and suppresses it, with all the accuracy limits from Section 9.3) or transfer-to-IVR (the agent transfers to an automated IVR that collects the card via DTMF, then transfers back). Most modern implementations offer both, with pure DTMF as the preferred path and voice or IVR as fallbacks.

What to take with you from Chapter 9

PCI DSS v4.0 is the payment card industry’s specification for how any system touching cardholder data must be secured. It is not a law, but it might as well be — the consequence of failing an audit is escalating fees and, ultimately, loss of the ability to accept card payments, which is functionally the end of the business for anyone who takes them. Every AI-powered contact center inherits a version of those obligations that is particularly easy to get wrong.

The single most important concept in PCI is scope. Every system that touches cardholder data — even briefly, even accidentally — is in scope for the full weight of the Standard. Every system that stays out of scope escapes it. The engineering discipline of PCI compliance is scope reduction: keeping the cardholder-data-touching moment isolated to a single, purpose-built component and keeping everything else — the AI, the CRM, the recording, the analytics — outside that boundary.

Post-call redaction does not achieve scope reduction. The unredacted data existed in the pipeline; that alone is enough to trigger scope. Real-time redaction is better but has accuracy failures that auditors will not accept in a payment context. The modern standard is pause-and-resume architecture with network-level DTMF masking — a pattern that prevents cardholder data from ever entering the AI-facing portion of the pipeline, that isolates the payment step to a specialized component, and that returns to the CRM only a non-sensitive token.

The commercial impact is measured in six-figure annual PCI compliance savings, the elimination of the specific class of breach that credit-card-in-transcripts creates, and — critically — the freedom to attach any AI you want to your call flows without worrying that the AI has just dragged your entire contact center into scope. The cost is a straightforward three-to-six-month implementation project plus small per-call fees to a specialist vendor. Part 5 turns from a specific compliance regime to the broader question of trust — Guardian Agents, voice biometrics, deepfake detection, and the multi-layer trust architectures that a mature AI-powered contact center layers on top of everything else.