Does an AI assistant fall into PCI DSS scope just because customers might paste a card number?

Scope under PCI DSS follows cardholder data: systems that store, process or transmit it are in scope, as are systems connected to or able to affect the security of that environment. The question is not whether you intended the assistant to handle payment data but whether it does in practice. If a support chat accepts free text from cardholders, card numbers arrive, and the components that receive, log, index or forward that text are handling cardholder data regardless of what the design document says.

Can we store card numbers in chat transcripts if they are encrypted?

The primary account number may be stored only where there is a documented business need and it is rendered unreadable by an approved method, with the associated key management, access control and retention requirements applying to every copy. In practice most support and analytics transcript stores have no such business need, which makes the compliant answer redaction before storage rather than encryption after it. Separately, sensitive authentication data — full track data, card verification codes and PINs — must not be retained after authorisation even in encrypted form.

What about the model provider — are they a service provider under PCI DSS?

If a third party handles cardholder data on your behalf, or could affect the security of that data, they are treated as a third-party service provider and you are expected to manage them accordingly: due diligence before engagement, a written agreement addressing responsibility for the data, a documented allocation of which requirements each side meets, and monitoring of their status. Most general-purpose model APIs are not offered as PCI-validated services, which means the compliant design is to keep the data away from them rather than to paper over the gap.

Does redaction before the API call solve the problem?

It is the right control and it is rarely sufficient on its own, because the redaction has to happen before every copy, not just before the outbound call. Request logs, error traces, replay buffers, evaluation datasets, prompt-caching layers and the raw transcript written for the human agent are all copies that typically precede the model call. A redaction step placed immediately before the API boundary can leave every one of them holding the original.

Are embeddings of a card number still cardholder data?

Treat them as in scope. An embedding is a derived representation produced deliberately from the underlying text, it lives in a store you control, and research on inversion attacks has repeatedly shown that text can be recovered from vectors to a meaningful degree. A vector index is also the component most likely to sit outside the segmented payment environment, replicated to analytics infrastructure, and excluded from the retention job that cleans the transcript database.

We are a SaaS vendor, not a merchant. Why does this reach us?

Because your customers are merchants and their obligations flow to you contractually. Enterprise payment-adjacent deals routinely require an attestation of compliance, a responsibility matrix and incident notification terms, and a vendor who cannot produce them is either removed from the data path or removed from the deal. The commercial cost of being in scope usually arrives long before any assessor does.

PCI DSS and AI: What Happens When Cardholder Data Reaches an LLM in 2026

Scope Is a Fact, Not a Decision

The foundational move in any PCI DSS programme is scoping: identify every system component that stores, processes or transmits cardholder data, plus everything connected to or capable of affecting the security of that environment, and then either secure it or segment it out. Merchants spent a decade shrinking that footprint — hosted payment fields, iframes, tokenisation, redirect flows — precisely so the card number never touched their own infrastructure.

AI features reversed the direction of travel. A support copilot, a chat assistant, a call summariser or a fraud triage model exists to read the messy, unstructured record of what customers actually said. That record contains card numbers, because customers read them off the card when they are confused about a charge, and no amount of interface design stops them. The moment the assistant reads that text, the assistant is processing cardholder data, and so is everything upstream and downstream of it.

The Two Storage Rules People Conflate

There are two distinct prohibitions and teams routinely apply the weaker one to both. The primary account number may be stored, but only with a documented business justification and only rendered unreadable — with the key management, access restriction and defined retention that follow from that. The other rule is absolute: sensitive authentication data, meaning full track data, the card verification code and the PIN or PIN block, must not be retained after authorisation. Encryption does not create an exception.

This matters for AI systems specifically because the CVV is exactly what a confused customer reads out alongside the card number, and because a transcript store is retention by default. Nobody decided to keep it. The conversation was simply written down, and the retention policy for support history was set years earlier by someone thinking about disputes.

Every Place the Data Lands Before the Model Sees It

The usual remediation is a redaction step in front of the model API. It is necessary and it is placed too late. Enumerate what already holds the raw string by the time that call is made:

The transcript of record. Written for the human agent, retained for dispute handling, replicated to the data warehouse, and frequently the source for the analytics team's exports.
Application and gateway logs. Request bodies captured at debug level, error traces that serialise the payload, and the observability vendor holding a year of them outside your segmentation boundary.
Evaluation and fine-tuning datasets. Real conversations sampled to measure quality. This is the copy most likely to be shared broadly inside the company and least likely to be covered by a retention job.
Prompt caches and replay buffers. Infrastructure added for latency and cost, holding verbatim prompt text for a window nobody documented.
Vector stores. Embeddings of support history built for retrieval, typically hosted separately, rarely segmented, and derived directly from the text you were trying to keep out.
Screen recordings and session replay. A pixel-level copy of the customer typing the number, held by a third party with its own masking configuration that someone has to have got right.

Detection Is Harder Than the Regex Suggests

PAN detection is usually implemented as a pattern match plus a Luhn checksum, which is a reasonable baseline and misses a large class of real inputs. Customers space digits in groups, separate them with dashes or full stops, split them across consecutive messages, spell them out in words, send a photo of the card, or say them aloud to a voice bot whose transcription inserts spaces in unpredictable places. A voice channel adds a second problem: the audio recording persists independently of the transcript, and redacting one does nothing to the other.

The practical stance is defence in depth rather than a perfect detector: mask aggressively at ingestion, apply the same detector on every write path rather than one, refuse to index anything that trips it, and monitor the detector's own hit rate so that a silent regression is visible. A detector that suddenly stops firing is indistinguishable from customers who suddenly stopped pasting.

The Vendor Chain and What Your Customers Will Ask For

PCI DSS treats third parties who handle cardholder data on your behalf, or who could affect its security, as service providers to be managed: due diligence before engagement, written agreements acknowledging responsibility, a documented split of which requirements each party is meeting, and ongoing monitoring of their compliance status. Applied to an AI stack that means the model provider, the vector database, the observability platform, the session-replay vendor and the transcription service — a chain that is usually four links deep and assembled by engineers, not procurement.

For vendors selling into payment-adjacent buyers, the enforcement mechanism is commercial long before it is regulatory. Security review will ask for a responsibility matrix, an attestation, evidence of segmentation and an incident notification commitment. "Our model provider does not train on our data" answers a different question than the one being asked, and reviewers have learned to notice.

A Design That Keeps the Model Out of Scope

Redact at the ingestion boundary — before the transcript write, before logging, before any downstream fan-out — not immediately before the model call.
Replace detected PANs with a token or a last-four reference so the assistant can still do its job, and keep the mapping inside the existing payment environment.
Treat the vector index as in scope until proven otherwise: same segmentation, same access control, same retention, and a rebuild path if the source is purged.
Never sample raw production conversations into evaluation sets without running the same detector, and hold eval data to the same retention clock as the transcripts.
Handle voice separately. Transcript redaction does not touch the recording, and the recording is the higher-fidelity copy.
Write the responsibility matrix before the security questionnaire arrives, and check it against the actual subprocessor list rather than the one on the trust page.
Reconcile public claims. A marketing page saying you never store payment information is a statement your logs have to be able to support.

Frequently Asked Questions

Our payments run through a hosted field, so we were out of scope. Did the AI feature change that?

It can, and this is the most common way a carefully minimised scope grows back. Hosted fields keep the card out of your checkout, but they do nothing about the support channel, the voice line or the conversation history that a new assistant was built to read. Scope reduction achieved on the payment path does not survive a second path being opened somewhere else in the product.

Is a local or self-hosted model safer here?

It removes one third party from the chain, which is real but narrow. The storage prohibitions, the segmentation requirements, the logging exposure and the vector-store question are all unchanged, because they are about your infrastructure rather than the provider's. Self-hosting helps most where the concern is a contractual data-handling gap and least where the concern is retention.

How do we handle a card number that has already been written to a transcript store?

Treat it as a defined remediation rather than a cleanup script: identify the affected records and all replicas including backups and derived indexes, purge or tokenise, document the business justification for anything retained, and review whether sensitive authentication data was involved because that changes the severity materially. Backups are the step most often skipped and the one most likely to be asked about.

Does PCI DSS say anything specific about AI?

The standard is written in terms of system components, data flows and processes rather than named technologies, which is why it applies cleanly without needing an AI clause. The practical effect is that there is no special AI carve-out to argue for and no AI-specific safe harbour to rely on — an inference endpoint that receives a PAN is a system component that transmits cardholder data, assessed like any other.

Can we rely on the model provider's zero-retention setting?

It is worth having and it is not a compliance conclusion. Retention settings frequently carve out an abuse-monitoring window, apply to some endpoints and not others, and depend on flags being set correctly on every call path including the one added last week. Verify the setting per endpoint, confirm it in the agreement rather than the documentation, and keep the redaction in place regardless.

Who finds this first — an assessor or someone else?

Usually neither. It surfaces through an enterprise security questionnaire that asks where transcripts are stored, through an incident affecting a logging or observability vendor, or through an engineer running a detector across the warehouse for an unrelated reason. That last one is the cheapest version, which is a good argument for running it deliberately.

Check What Your Site Claims About Payment Data

Trust pages and security sections make absolute statements — never stores card details, fully PCI compliant, no payment data leaves our environment — that were written before the assistant, the transcript store and the vector index existed.

See every security, privacy and compliance claim on your site in one pass. Run a free scan and check each against what your data flows actually do.

This article is general information and not legal or assessment advice. PCI DSS requirements are version-specific and their application depends on your merchant level, acquirer requirements and actual data flows. Confirm scoping conclusions with a qualified security assessor and your acquirer before relying on them.

The Model Was Never in Scope. Then a Customer Pasted Their Card Number.