AI and PCI DSS: Keeping Card Data Out of Models

The best PCI DSS outcome for an AI system is not being compliant in scope — it is not being in scope. Cardholder data reaches AI systems almost entirely through prompts, transcripts, and logs, and all three are preventable. This guide covers how, drawing on FISTA Solutions' AI agents work. This article is general guidance, not legal advice.

How does card data reach AI systems?

Through the paths nobody designed for it to take.

Path	Why it happens
Chat messages	Customers type card numbers to support
Call transcripts	Numbers read aloud, then transcribed
Support tickets	Pasted into a free-text field
Document uploads	Statements and invoices with full numbers
Prompt logs	Raw input stored for debugging
Provider retention	Prompts kept outside your environment

What is the right design?

Detect and redact before the model call, and never log the raw input.

That means pattern detection at the boundary where user input enters the system, redaction applied before anything is stored or transmitted, and logging of the redacted text only. Systems that log raw input for debugging and redact afterwards have already created the exposure, because the log is the store.

What about voice channels?

They are the harder case. A customer reading a card number aloud produces audio and a transcript, both of which can contain the data.

The practical approaches are pausing recording during payment capture, routing payment steps to a separate flow that never reaches the transcription pipeline, and redacting the transcript before it is stored. All three need designing rather than adding.

What about model provider retention?

It matters more than teams expect. If a provider retains prompts, data sent in a prompt has been transmitted and stored outside your controls.

Confirm retention and processing terms before sending anything that could contain card data, and prefer arrangements with zero retention for these paths. A redaction step that occasionally misses is a different risk when the provider keeps the prompt for thirty days.

What evidence do you need?

Evidence that redaction runs before model calls, logs demonstrating raw card data is not stored, provider retention terms, network and access controls around any in-scope component, and scope documentation showing where the assessment boundary sits.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes input sanitisation to the boundary and makes logging a design decision rather than a default. Most teams log requests wholesale for debugging; that habit is what pulls AI systems into scope.

The discipline worth adopting is logging structured, redacted events rather than raw payloads, everywhere, not only in payment paths. It costs a little debugging convenience and removes an entire class of compliance problem.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Logging raw prompts for debugging. Redacting after storage rather than before. Assuming voice channels are outside the question. And sending potentially card-bearing prompts to a provider with default retention.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

What if the system genuinely must handle card data?

Then it is in scope, and the standard applies: network segmentation, access control, encryption, logging and monitoring, vulnerability management, and testing.

An AI component in a cardholder data environment inherits all of it, including change control and the requirement to justify what the component does. That is workable and considerably more expensive than staying outside, which is why the first question is always whether it is necessary.

What should you do first?

Search your prompt logs for card number patterns. Most organisations that have not designed for this find matches, and that search takes minutes.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: input redaction applied before model calls rather than after storage, structured redacted logging rather than raw payloads, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and SOC 2 Type 2.