AI is moving quickly across the accounts receivable management industry.

According to TransUnion’s latest Debt Collection Industry Report, AI and machine learning adoption among collection organizations increased from 73% in 2024 to 93% in 2025. The technology is showing up in quality and compliance monitoring, consumer communications, scoring, treatment strategies, voice applications, and negotiation support.

That makes the conversation increasingly practical. What tools are being used? What information can they access? Where does that information go once it enters the tool?

When payment data is involved, there’s one more question worth asking: what do the existing payment-data standards already say?

AI may be new. Many of the rules governing payment data are not.

This article is meant to help operators understand some of the published standards relevant to that conversation. It’s educational, not legal or compliance guidance, and it isn’t a determination of PCI DSS scope for any particular environment. Your compliance counsel, Qualified Security Assessor (QSA), and other advisors are the right people to evaluate how the requirements apply to your specific systems and workflows.

PCI DSS scope is based on the environment, not the technology label

PCI DSS v4.0.1 describes scope in terms of the cardholder data environment and the system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data. The standard also includes system components, people, and processes that could impact the security of that data.

That language matters when organizations start adding AI tools to existing workflows. PCI DSS doesn’t need to name large language models, transcription systems, or copilots specifically for the underlying scope questions to stay relevant.

The work is understanding the environment itself:

What information can the tool reach?

Where does that information come from, and where does it go?

What other systems does the tool interact with?

Whether a particular AI application falls within PCI DSS scope is an assessment question, and it belongs to your QSA. But the fact that a technology is new doesn’t make the existing framework any less applicable to it.

Recorded calls are a useful example

Most agencies record calls. Some of those calls include a consumer reading a card number out loud.

That situation isn’t new, and the standards have addressed it for years. PCI DSS Requirement 3.3.1 covers the retention of sensitive authentication data after authorization. The Council’s information supplement on protecting telephone-based payment card data, version 3.0 from November 2018, looks at call recording environments specifically. It includes the point that where recordings contain card verification code data, that data should be securely deleted or otherwise rendered unrecoverable once authorization is complete.

Agencies with mature telephone payment programs have been working with this for a long time, and many use pause-and-resume. The same supplement notes that a properly implemented pause-and-resume solution could reduce PCI DSS applicability by taking call recording and storage systems out of scope. It’s also clear that pause-and-resume doesn’t reduce applicability to the agent, the agent desktop environment, or other systems in the telephone environment.

What transcription changes isn’t the requirement. It’s the workflow around it. Audio that was practically difficult to search becomes text that’s easy to search, and that text may live somewhere different from the original recording.

That’s the pattern worth noticing more broadly. AI often doesn’t introduce a new category of data. It introduces new uses for data the organization already has, and those new uses can sit in a different relationship to existing requirements than the original process did.

PCI SSC has addressed AI directly

The PCI Security Standards Council has begun publishing material specifically about AI.

In September 2025 the Council published AI Principles: Securing the Use of AI in Payment Environments, stating that AI systems must be deployed and managed in compliance with applicable PCI SSC requirements.

That framing is worth sitting with for a second. Rather than building a separate payment-security regime for AI, the Council is applying familiar security principles to another kind of technology entering the payment environment.

Among the topics the AI Principles address: limiting the sensitive information available to AI systems, sanitizing data used with AI, protecting credentials and other high-impact information, logging AI activity, and considering risks such as prompt injection and data poisoning. The Principles also point toward payment tokens, single-use PANs, and appropriately protected card data in cases where full account information isn’t required.

The larger takeaway is fairly straightforward. Introducing AI doesn’t replace the payment-data controls already in place. It adds another system, workflow, or vendor relationship that may need to be understood within them.

Tokenization can meaningfully reduce exposure

Tokenization belongs in this conversation because it can limit how much cardholder data is available to downstream systems.

The Council’s guidance is more specific than simply calling a system “tokenized.” It explains that certain conditions have to be met for tokenized systems to be considered outside PCI DSS scope, including conditions around whether the original PAN can be recovered from a token, and how systems with de-tokenization capability are separated from systems that only use tokens. (That guidance dates to 2011, with separate product security guidance following in 2015.) The Council is also clear that tokenization doesn’t eliminate the need to maintain and validate PCI DSS compliance, though it may simplify validation efforts.

That distinction is useful when thinking about AI. If an application doesn’t need full payment-card information to do its job, architecture that limits what it can access may change the scope conversation in a meaningful way. The surrounding environment still matters, though. Tokenization on its own isn’t a universal answer.

Vendor terms are part of the conversation too

PCI standards are one source. The terms and documentation published by the technology provider are another.

OpenAI’s customer documentation, for example, instructs users not to enter, upload, or share cardholder data as defined by PCI DSS through ChatGPT inputs, including conversations, files, and custom GPTs. That’s useful information for an organization thinking through how employees use a general-purpose AI tool.

It’s also worth not assuming that every product or implementation model operates under identical terms. A ChatGPT workspace, an API implementation, and a third-party platform built on another company’s model can represent very different arrangements.

The same principle applies well beyond any single provider. When a new tool enters a workflow that could involve payment information, its documentation, contractual terms, and data-handling practices become part of understanding the complete environment. PCI DSS already includes requirements around third-party service providers, including maintaining awareness of those relationships and understanding how responsibilities are divided between an organization and its providers. Those questions haven’t gone away. They’re newly relevant in places where teams may not have needed to ask them before.

The useful question probably isn’t “Is AI compliant?”

That question is broad enough to be difficult to answer.

AI can describe an employee using a general-purpose chatbot, or a deeply integrated application running inside a controlled technology environment. Those are very different situations, and they don’t raise the same questions.

A more useful conversation starts with the actual flow of information: what data the tool needs, what it can access, what happens to that information once it’s there, and which systems and vendors are involved. Those questions don’t assume AI is inherently risky, and they don’t assume any particular implementation is compliant or noncompliant. They bring the conversation back to what payment-security standards have always cared about, which is the data and the environment around it.

AI is changing quickly. That part is obvious. The responsibility to understand where payment information goes, who can access it, and which requirements apply is a much more familiar kind of work.

At Payment Savvy we spend our days on the payment side of ARM, so we pay close attention to where new technology meets the data and requirements already surrounding a transaction. As the industry keeps adopting AI, we think understanding that intersection is only going to matter more.

If you’d like more conversations like this one, subscribe to the Monthly Rewind. We send one email a month covering the payment topics we think are worth understanding, without turning them into a sales pitch.