Does an LLM deployment join the PCI DSS scope automatically?

The deployment joins the scope when any of the three flows (direct input, retrieval, tool call) carries cardholder data through the deployment. The scope is defined by the data flow, not by the system's category. A deployment that never sees cardholder data stays out of the scope, and the enterprise's evidence is the gateway control that prevents the data from reaching the LLM.

What is the prompt-side redaction pattern for PCI?

The gateway's classifier runs a PCI-DSS-aware pattern set against every prompt before the LLM sees it. The pattern set covers PAN, CVV, expiration date, and cardholder name in the presence of a PAN. The classifier redacts matches with a placeholder that preserves the prompt's structure. The audit record captures the pre-redaction hash and the redaction action.

How does the response-side control satisfy Requirement 10?

Requirement 10 asks for logging and monitoring of access to cardholder data. The response-side control captures every response that carried a cardholder data pattern and the redaction that fired before the caller received it. The record set is per-request, tied to the caller identity, and stored in a tamper-evident log. The QSA reviews the log as evidence of the logging control.

How does the pattern interact with the model provider's logging?

The model provider's enterprise agreement describes the provider's log retention window and the enterprise's ability to disable logging. The enterprise's evidence file includes the agreement, the provider's SOC 2 attestation, and the enterprise's gateway records. For PCI, the enterprise agreement plus the gateway redaction is the pattern that keeps cardholder data out of the provider's logs.

What are the audit records the QSA reviews at the gateway?

The QSA reviews the per-request records that include caller identity, classifier verdict, redaction action, and pre-redaction hash. The records answer the "who called," "what was the traffic," and "did the control fire" questions. The pre-redaction hash lets the QSA verify the redaction fired against a specific pattern without the log storing the raw cardholder data.

How does PCI DSS 4.0 relate to the EU AI Act for the same deployment?

The two regimes apply to overlapping traffic. PCI DSS applies to traffic that touches cardholder data. The EU AI Act's Article 12 applies to traffic through high-risk AI systems. A gateway record that captures identity, classifier verdict, and redaction serves both regimes. The gateway's record schema is the common substrate the compliance team maps to each regime's specific evidence requirement.

PCI DSS 4.0 AI Controls: Where an LLM Deployment Touches the Cardholder Data Environment

PCI DSS 4.0's future-dated requirements became effective March 31, 2025, and the second wave of enforcement is now in the QSA's audit workflow. The 12 requirements describe the cardholder data environment and the controls that apply to systems that store, process, or transmit cardholder data. The specification does not name LLMs, agents, or AI systems. An LLM deployment that touches cardholder data joins the CDE anyway, because the CDE is defined by the data flow, not by the system's category. I want to walk through the PCI DSS 4.0 requirements that apply, the flows that pull the LLM into scope, and the gateway-layer evidence a QSA accepts.

The three flows that pull an LLM into scope

An LLM deployment joins the CDE when any of three flows carry cardholder data through the deployment.

Flow one, the direct-input flow, is the flow where a caller submits cardholder data in the prompt. A customer-support agent asks the LLM to help draft a refund message and includes the card number in the context. The card number is now in the model provider's traffic and possibly in its logs.

Flow two, the retrieval flow, is the flow where the RAG pipeline pulls a document that contains cardholder data from the enterprise's document store into the LLM's context. The RAG retrieval populates the prompt with the document contents. The card number is now in the prompt.

Flow three, the tool-call flow, is the flow where an agent calls a downstream system that returns cardholder data in the tool's response. The tool response is now in the agent's context, and the next model call carries the response back through the LLM.

Any of the three flows pulls the LLM's inbound and outbound traffic into scope for the CDE. The controls that apply to the traffic are the PCI DSS controls the QSA reviews.

The PCI DSS 4.0 requirements that apply

Six of the 12 requirements produce direct evidence requirements at the LLM boundary.

Requirement 1 (network security controls) applies to the network segment the LLM traffic traverses. The segment carrying LLM traffic to the model provider has to enforce the CDE's segmentation rules. Egress from the CDE to a non-CDE destination is only permitted when the destination is explicitly authorized.

Requirement 3 (protect stored account data) applies to the model provider's logging and the enterprise's audit records. Cardholder data cannot be stored in the model provider's logs unless a written agreement covers the storage and the provider meets the PCI DSS storage controls. The enterprise's audit records at the gateway have to redact the cardholder data or store it under the same PCI DSS controls that apply to the primary systems.

Requirement 4 (protect cardholder data in transit) applies to the traffic between the enterprise and the model provider. The traffic has to run under TLS 1.2 or higher with the cipher suites the DSS permits. The certificate validation has to fail closed on a certificate error.

Requirement 6 (develop and maintain secure systems) applies to the software that composes prompts, the RAG pipeline, and the tools the agent calls. The software has to follow the DSS's secure development lifecycle. The gateway's software also joins the SDLC scope.

Requirement 8 (identify users and authenticate access) applies to every caller that reaches the LLM through the enterprise's gateway. The identity resolution the gateway performs is the artifact the QSA accepts as evidence of the identification.

Requirement 10 (log and monitor all access to system components and cardholder data) applies to every LLM call that touches cardholder data. The per-request audit record at the gateway is the artifact the QSA accepts as evidence of the logging control.

The scoping test the QSA runs

The QSA's scoping test asks whether the LLM deployment stores, processes, or transmits cardholder data. Processing includes any operation that interprets or transforms the data. Transmitting includes any operation that carries the data across a network boundary.

An LLM that receives a card number in a prompt processes the number, because the model's forward pass interprets the token sequence that contains the number. The LLM that sends the number back to the caller in a response transmits the number. The LLM that stores the number in a cache or in a session log stores the number.

The QSA's test does not depend on whether the enterprise intended the LLM to see cardholder data. The test depends on whether the LLM actually saw it. A prompt-side filter at the gateway that redacts cardholder data before the LLM sees it removes the LLM from the processing scope for that request, and the DSS evidence is the gateway's redaction record.

The gateway-layer evidence pattern

The gateway evidence pattern produces two artifacts the QSA accepts.

The first artifact is the prompt-side redaction record. The record captures the request identifier, the caller identity, the classification verdict on the prompt, and the redaction the gateway applied before the prompt reached the LLM. The pre-redaction hash of the cardholder data pattern is stored in the record instead of the raw number. The auditor can prove the redaction fired without the audit log itself storing the raw cardholder data.

The second artifact is the response-side redaction record. The record captures the same tuple for the response direction. The response that contained a cardholder data pattern was redacted before the caller received it. The record proves the response-side control fired.

The two records satisfy Requirement 10's logging obligation for the LLM boundary and reduce the LLM's scope for Requirement 3's storage obligation, because the cardholder data itself does not persist in the log.

The pre-existing PCI DSS controls that do not translate

Some PCI DSS controls apply only to systems the enterprise operates directly. Requirement 2 (secure configurations) applies to the gateway, not to the model provider's infrastructure. Requirement 5 (protect against malicious software) applies to the enterprise's endpoints, not to the model.

The controls that do not translate to the model provider's infrastructure are the controls the enterprise addresses by keeping cardholder data out of the model provider's environment. The prompt-side redaction pattern is the mechanism that produces the exclusion.

The interaction with the model provider's BAA-like agreement

Model providers offer enterprise agreements that describe the provider's logging and retention behavior. OpenAI's enterprise agreement, Anthropic's enterprise agreement, and AWS Bedrock's enterprise terms each describe the log retention window and the enterprise's ability to disable logging.

For PCI DSS, the enterprise agreement is the evidence that the provider's logs do not store cardholder data past the DSS's retention limit or that the provider does not store the data at all. The enterprise's compliance file includes the agreement, the provider's SOC 2 or ISO 42001 attestation, and the enterprise's own gateway audit records that prove the redaction fired.

DeepInspect

This is the gap DeepInspect closes at the LLM boundary. DeepInspect sits inline between users or agents and the LLM APIs they call. The gateway's classifier runs a PCI-DSS-aware pattern set (PAN, CVV, expiration date, cardholder name in the presence of a PAN) against every prompt and every response. The classifier redacts the patterns before the LLM sees the prompt and before the caller sees the response.

The audit records land in a hash-chained log that captures the caller, the request, the classifier verdicts, and the redaction actions. The QSA accepts the record set as evidence for Requirement 8 and Requirement 10 at the LLM boundary. The pre-redaction hash pattern preserves traceability without the log itself storing cardholder data.

Book a technical deep dive at deepinspect.ai.