PCI DSS 4.0 and the Cardholder Data Question When You Use AI

PCI DSS 4.0 and the Cardholder Data Question When You Use AI

PCI DSS 4.0 became the only active standard on March 31, 2025, when version 3.2.1 officially retired. Most of the structural changes landed in March 2024, but a batch of requirements that had been classified as "future-dated best practices" flipped to mandatory this year. If you are running AI tools anywhere near payment card data, several of those newly mandatory requirements deserve close attention, because the Council wrote them in a way that does not map neatly onto how modern AI pipelines actually work.

What Changed in the 2025 Enforcement Wave

The PCI Security Standards Council grouped about 64 new requirements into PCI DSS 4.0. Roughly 13 of those were future-dated to March 31, 2025. The ones most relevant to AI-adjacent workflows include:

• Requirement 6.4.3: All payment page scripts that are loaded and executed in the consumer's browser must be managed, authorized, and integrity-checked. This matters if you have any AI-driven chatbot, recommendation engine, or dynamic content tool running on a page that also handles card input.
• Requirement 11.6.1: A change-and-tamper detection mechanism must alert on unauthorized modifications to HTTP headers and payment page content. Again, if an AI tool injects or modifies content on those pages, you need to account for it.
• Requirement 12.3.2: A targeted risk analysis must be performed for each PCI DSS requirement where the entity uses a "customized approach." Many organizations are leaning on customized approaches to justify novel AI architectures, and each one now needs a documented, formal risk analysis.
• Requirement 5.4.1: Mechanisms to detect and protect personnel against phishing attacks. Relevant because AI-generated phishing is part of the threat model the Council explicitly contemplated in its 4.0 guidance documents.

The full list is longer, but these four create the most friction when AI tools are in the mix.

Where AI Touches Cardholder Data (Even When You Think It Does Not)

The classic assumption is that your AI tools never see a primary account number (PAN), so PCI DSS does not apply to them. That assumption breaks down in a few common scenarios.

Customer service AI. If you have an AI-powered support tool, whether it is a chatbot, a ticket summarizer, or a call transcription system, customers will paste card numbers into it. They will read card numbers aloud. Your system will ingest that data whether you asked for it or not. Under PCI DSS 4.0 Requirement 3.4.1, the PAN must be rendered unreadable anywhere it is stored, and under 3.4.2, you cannot even allow it to be copied from a display for personnel in certain roles. If your AI tool logs those conversations, stores embeddings, or caches prompts, you may have cardholder data sitting in places your QSA has never assessed.

Document processing AI. Financial services firms increasingly use AI to process invoices, receipts, contracts, and correspondence. Any of these can contain full or partial card numbers. If the AI model processes the document, generates a summary, or stores it in a vector database, the cardholder data environment (CDE) just expanded to include that entire pipeline.

Training data. This one is less obvious but potentially more damaging. If any model was fine-tuned or trained on datasets that included cardholder data, even inadvertently, you have a problem under Requirement 3.1.1, which mandates that all account data storage locations are documented and limited to what is needed. A model's weights are not a "storage location" in the traditional sense, but a QSA doing a customized approach review could reasonably argue that they are.

Scope Creep Is the Real Risk

PCI DSS 4.0, Requirement 12.5.2 now requires that PCI DSS scope be documented and confirmed at least every 12 months, and also after any significant change to the in-scope environment. Deploying an AI tool that touches payment workflows is a significant change. If you did not re-scope when you deployed it, you are already non-compliant with 12.5.2.

The financial consequences are not abstract. Visa's Global Brand Protection Program can levy fines starting at $50,000 per month for Level 1 merchants found non-compliant after a breach. Mastercard's compliance programs have similar structures. And those are just the card brand fines; they do not include the forensic investigation costs (typically $200,000 to $500,000 for a mid-size merchant) or the liability shift that follows.

The scope question also intersects with Requirement 12.8, which governs third-party service providers (TPSPs). If your AI vendor processes, stores, or could impact the security of cardholder data, they are a TPSP under PCI DSS 4.0. You need a written agreement acknowledging their responsibilities (12.8.2), you need to monitor their compliance status (12.8.4), and you need to maintain information about which requirements each TPSP manages versus which ones you manage (12.8.5). Most AI vendor contracts do not address any of this.

Practical Steps That Actually Help

Rather than trying to retrofit PCI compliance onto an AI deployment after the fact, a few structural decisions made early can save significant pain.

• Strip before you send. Implement a pre-processing layer that detects and redacts or tokenizes PANs, expiration dates, CVVs, and cardholder names before data reaches the AI model. Regex-based detection for card numbers is well-established (Luhn check plus BIN range validation), and adding it to an ingestion pipeline is straightforward.
• Isolate the AI from the CDE. If the AI tool never receives cardholder data, it stays out of scope. Network segmentation (Requirement 1.3.1 and 1.3.2) is your friend here. Put the AI processing in a segment that has no connectivity to systems that store or transmit cardholder data, and validate that segmentation with penetration testing per Requirement 11.4.6.
• Audit your AI vendor as a TPSP. Request their Attestation of Compliance (AOC) or their SAQ. If they cannot provide one and they handle data that could include cardholder information, you have a gap. Document it, remediate it, or find a different vendor.
• Log everything. Requirement 10.2.1 expanded the list of auditable events. AI interactions that touch or could touch cardholder data need to generate logs that include user identification, event type, date and time, success or failure, and origination. Make sure your AI platform supports this level of logging natively.

The Customized Approach Trap

PCI DSS 4.0 introduced the "customized approach" as an alternative to the traditional "defined approach" for meeting requirements. It is tempting to use this for AI systems, because many of the defined approach requirements were written with conventional software architectures in mind. But Requirement 12.3.2 now mandates a targeted risk analysis for every customized approach implementation, and your QSA has to independently derive testing procedures to validate your approach. In practice, this means more assessor time, higher assessment costs, and greater scrutiny. Use the customized approach where you genuinely need it, not as a shortcut to avoid re-architecting a non-compliant AI pipeline.

How FirmAdapt Addresses This

FirmAdapt's architecture was designed to keep sensitive data out of AI processing paths by default. The platform applies detection and redaction of cardholder data, along with other regulated data types, before content reaches any AI model. This means the AI layer stays outside your CDE, which simplifies scoping, reduces your TPSP obligations, and keeps your segmentation clean under Requirements 1.3.1 and 1.3.2.

FirmAdapt also maintains audit logs at the level of granularity that Requirement 10.2.1 expects, covering user identification, event types, timestamps, and data lineage. For organizations using FirmAdapt as part of their payment-adjacent workflows, this means the AI tooling supports your PCI DSS 4.0 compliance posture rather than undermining it. The platform carries its own compliance documentation, so your QSA has what they need without a drawn-out vendor assessment process.