PCI DSS 4.0 and AI Systems: Compliance Requirements for AI in Payment Processing

PCI DSS 4.0 became the mandatory standard on March 31, 2025, when version 3.2.1 was officially retired. Every organization that stores, processes, or transmits cardholder data must now comply with the updated requirements. That deadline has passed. If you are not on 4.0 yet, you are already out of compliance.

What many organizations have not fully worked through is how their AI systems fit into PCI DSS scope. The standard does not mention artificial intelligence, machine learning, or large language models by name. It does not need to. PCI DSS applies to any system component that stores, processes, or transmits cardholder data, or that could affect the security of the cardholder data environment (CDE). AI systems that touch payment data are system components.

This matters because AI introduces risks that PCI DSS was not designed to address directly. A fraud detection model trained on transaction data might memorize and reproduce cardholder information. An LLM-based customer service agent with access to payment records could leak card numbers through prompt injection. An AI system making automated payment decisions introduces new access control and audit logging requirements.

The controls are in PCI DSS 4.0. The challenge is applying them correctly to AI systems that behave differently from traditional software. This guide walks through exactly where AI systems intersect with PCI DSS scope, which requirements are most affected, and how to implement compliant AI systems in payment processing environments. For broader AI compliance context, see our compliance readiness guides.

Key Takeaways

• PCI DSS 4.0 applies to AI systems that process, store, or transmit cardholder data, even though the standard does not mention AI explicitly
• Fraud detection models, LLM customer service agents, transaction monitoring systems, and automated payment decision systems all fall within scope
• AI introduces PCI-relevant risks that traditional system assessments may miss: model memorization, prompt injection data leakage, excessive agent permissions, and training data containing cardholder data
• Requirements 3, 6, 7, 8, 10, 11, and 12 have the most direct applicability to AI systems in the CDE
• Organizations should supplement PCI DSS assessments with AI-specific security testing to cover vulnerabilities that standard QSA assessments may not evaluate

Where AI Systems Touch PCI DSS Scope

Understanding which of your AI systems are in scope is the first step. PCI DSS scope is determined by whether a system component stores, processes, or transmits cardholder data, or is connected to systems that do. Here are the most common AI system types that fall within PCI DSS scope.

AI-Based Fraud Detection Systems

Fraud detection is the most established use of AI in payment processing. These systems analyze transaction patterns, cardholder behavior, merchant risk profiles, and dozens of other signals to score transactions in real time.

These systems are unambiguously in PCI DSS scope because they process cardholder data as part of their core function. The transaction data flowing through the fraud detection pipeline includes card numbers (often truncated or tokenized, but not always), transaction amounts, merchant identifiers, timestamps, and cardholder verification data.

PCI DSS implications specific to fraud detection AI:

• Training data. If the model was trained on raw cardholder data, the training environment and data storage are in scope. Even if you truncated or tokenized the data for training, the preprocessing pipeline that handled raw data is in scope.
• Model memorization. ML models can memorize training examples. A fraud detection model trained on millions of transactions could, under certain conditions, reproduce specific cardholder data from its training set. This is a data storage risk even though the data is stored in model weights rather than a database.
• Feature engineering pipelines. The code and systems that extract features from raw transaction data are in scope. These pipelines often handle unmasked cardholder data before it is tokenized or truncated for model input.

LLM-Based Customer Service Agents

Organizations are deploying LLM-based chatbots and virtual agents for customer support, including support related to payments, billing, and account management. When these agents have access to payment information, they enter PCI DSS scope.

Common scenarios that bring LLMs into scope:

• Account lookup. The agent can look up a customer's account, which includes stored payment methods, recent transactions, or billing history.
• Payment processing. The agent can initiate, modify, or cancel payments on behalf of the customer.
• Dispute handling. The agent processes chargeback requests or payment disputes, which involve cardholder data.
• RAG with payment data. The agent uses retrieval-augmented generation where the retrieval corpus includes documents containing cardholder data, transaction records, or payment processing logs.

LLM agents introduce unique PCI DSS risks. Prompt injection could cause the agent to reveal cardholder data in its responses. The model's context window may contain payment information that could be extracted through adversarial prompting. The agent's tool-use capabilities might allow it to access payment systems beyond its intended scope.

AI Transaction Monitoring and Risk Scoring

Beyond fraud detection, organizations use AI for transaction monitoring, merchant risk scoring, anti-money laundering (AML) screening, and regulatory compliance monitoring. These systems often process or have access to cardholder data as part of their analysis.

Systems in this category include:

• Transaction anomaly detection. Models that identify unusual transaction patterns for compliance or risk management purposes.
• Merchant risk scoring. AI systems that assess merchant risk levels based on transaction patterns, chargeback rates, and other signals.
• Behavioral analytics. Systems that build behavioral profiles of cardholders to detect account takeover or unauthorized use.

Automated Payment Decision Systems

AI systems that make or influence payment decisions are in scope when they interact with cardholder data:

• Automated approval/decline systems. AI that makes real-time authorization decisions based on risk scores, behavioral signals, or policy rules.
• Dynamic authentication. Systems that determine whether a transaction requires additional authentication (3D Secure step-up, for example) based on AI risk assessment.
• Credit decisioning. AI models that influence credit line adjustments, payment terms, or account standing based on transaction behavior.

Key PCI DSS 4.0 Requirements for AI Systems

PCI DSS 4.0 contains 12 top-level requirements organized into 6 goals. Not all requirements are equally relevant to AI systems. Here is a detailed breakdown of the requirements that matter most and how they apply to AI.

Requirement 3: Protect Stored Account Data

Requirement 3 controls how cardholder data is stored, retained, and disposed of. For AI systems, this requirement has implications that go beyond traditional database storage.

3.1 Processes and mechanisms for protecting stored account data are defined and understood. This must include AI systems. Your data retention policy should explicitly address cardholder data used in AI training, feature engineering, and model development. Document which AI systems process or store cardholder data, in what form, and for how long.

3.2 Storage of account data is kept to a minimum. This applies to training datasets, feature stores, data lakes, and any other storage used by AI pipelines. If you are retaining raw transaction data for model training that you no longer need, Requirement 3.2 requires you to dispose of it. Implement data minimization in your AI pipelines: use tokenized or truncated data wherever the full PAN is not required.

3.3 and 3.4: PAN display and rendering. If an AI agent displays or communicates PAN data (for example, reading a card number back to a customer or displaying it in a chat interface), PAN masking requirements apply. The first six and last four digits are the maximum that can be displayed, and only to personnel with a legitimate business need.

3.5: PAN is secured wherever it is stored. This includes storage within AI model weights. If a model has memorized PANs from its training data, those PANs are "stored" in the model. This is a novel interpretation that QSAs are beginning to apply. Mitigations include:

• Training on tokenized or truncated PANs instead of full PANs
• Testing models for memorization of cardholder data before deployment
• Applying differential privacy techniques during training to reduce memorization
• Implementing output filtering that detects and blocks PAN patterns in model outputs

3.7: Cryptographic key management for stored account data. If cardholder data used by AI systems is encrypted, key management requirements apply to the encryption keys used by the AI pipeline. This includes keys used for encrypting training data at rest, tokenization vault keys, and any encryption used in model serving infrastructure.

Requirement 6: Develop and Maintain Secure Systems and Software

Requirement 6 covers the secure development lifecycle for all system components. AI systems are system components.

6.2: Bespoke and custom software is developed securely. Your AI development process must follow secure software development practices. For AI systems, this means:

• Secure coding practices for ML pipeline code, model serving infrastructure, and AI agent logic
• Code review for training scripts, data preprocessing code, and inference pipelines
• Vulnerability management for ML frameworks, libraries, and dependencies (TensorFlow, PyTorch, LangChain, etc.)
• Separation of development and production environments for model training and deployment

6.3: Security vulnerabilities are identified and addressed. This includes AI-specific vulnerabilities. Your vulnerability management program should cover:

• Known vulnerabilities in ML frameworks and libraries (CVE monitoring for PyTorch, TensorFlow, ONNX, etc.)
• AI-specific vulnerabilities such as prompt injection, model extraction, and adversarial input susceptibility
• Third-party model vulnerabilities when using pre-trained or fine-tuned models from external sources

6.4: Public-facing web applications are protected against attacks. AI model endpoints exposed to the internet are public-facing web applications. This means:

• Web application firewall (WAF) protection for model inference endpoints
• Protection against AI-specific attacks (prompt injection, adversarial inputs) in addition to traditional web attacks
• At minimum, automated technical solutions that detect and prevent web-based attacks, reviewed at least every 12 months

6.5: Changes to all system components are managed securely. Model updates, retraining, and deployment changes must follow your change management process. This includes:

• Change approval for model deployments and updates
• Testing before production deployment (accuracy, security, bias)
• Rollback procedures for model deployments
• Documentation of model changes, including training data changes, hyperparameter adjustments, and architecture modifications

Requirement 7: Restrict Access to System Components and Cardholder Data

Requirement 7 enforces least privilege access controls. For AI systems, this has specific implications.

7.2: Access to system components and data is appropriately defined and assigned. AI agents, automated systems, and ML pipelines need formally defined access privileges. Each AI component should have access only to the specific data and systems it needs.

Common access control issues with AI systems:

• AI agents with broad database access. An LLM-based customer service agent should not have access to the full cardholder database. It should query through a constrained API that returns only the data needed for the current interaction, with PAN masking applied.
• Training pipelines with production access. Model training environments should not have direct access to production cardholder data. Use data export processes that apply tokenization or truncation before data reaches the training environment.
• Model serving accounts with excessive privileges. The service account running your fraud detection model should have read access to transaction data and write access to scoring results. It should not have access to modify cardholder records, database schemas, or system configurations.

7.2.5: Access for application and system accounts is appropriately assigned and managed. This directly applies to AI agent service accounts and automated ML pipeline accounts. Each must:

• Have the minimum privileges required for its function
• Be reviewed periodically to ensure privileges are still appropriate
• Have interactive login capability disabled (these should be service accounts, not user accounts)
• Use unique credentials, not shared accounts

Requirement 8: Identify Users and Authenticate Access

Requirement 8 deals with user identification and authentication. AI agents and automated systems introduce new considerations.

8.2 and 8.3: User identification and strong authentication. When AI agents access systems containing cardholder data, they must be uniquely identified. This means:

• Each AI agent instance should have a unique service account identity
• Authentication credentials should be managed through secrets management systems with rotation policies
• Multi-factor authentication (MFA) applies to administrative access to AI systems within the CDE
• API keys for model endpoints should be unique per consumer and rotated regularly

8.6: Use of application and system accounts is strictly managed. AI agents and automated ML processes use application/system accounts. PCI DSS 4.0 requires:

• Interactive login for these accounts is disabled
• Account use is limited to the specific application or system
• If the account can be used for interactive login, MFA is required
• Account credentials are rotated periodically and upon suspicion of compromise

One area that needs careful attention: AI agents that use tool-calling or function-calling to interact with payment systems. Each tool interaction should be authenticated and logged, not just the initial agent session. If an AI agent calls a payment API 50 times during a customer interaction, all 50 calls should be authenticated with the agent's service credentials and logged individually.

Requirement 10: Log and Monitor All Access

Requirement 10 requires comprehensive audit logging. AI systems demand particular attention here because their behavior is less predictable than traditional software.

10.2: Audit logs are implemented to support the detection of anomalies and suspicious activity. For AI systems in the CDE, audit logs must capture:

• All access to cardholder data by AI systems (model inference requests, training data access, feature extraction queries)
• All actions taken by AI agents (tool calls, API requests, database queries, payment operations)
• Model prediction decisions that affect cardholder data (fraud scores, approval/decline decisions, risk ratings)
• Administrative actions on AI systems (model deployments, configuration changes, access control modifications)
• Authentication events for AI system accounts

10.3: Audit logs are protected from destruction and unauthorized modifications. AI system logs must be tamper-proof. This is particularly important for model decision logs, which may need to be produced during disputes, investigations, or regulatory inquiries. Ensure logs are:

• Written to append-only storage or a centralized log management system
• Protected by access controls separate from the AI system itself
• Retained for at least 12 months (per 10.7), with at least 3 months immediately available for analysis

10.4: Audit logs are reviewed to identify anomalies or suspicious activity. Reviewing AI system logs requires understanding what constitutes anomalous AI behavior:

• Unusual query patterns against model endpoints (potential model extraction or adversarial probing)
• AI agent actions outside expected behavioral patterns (potential prompt injection exploitation)
• Spikes in model prediction errors or confidence score anomalies (potential adversarial inputs or model degradation)
• Unexpected data access patterns by training pipelines or feature engineering processes

Implement automated monitoring for these AI-specific anomalies in addition to standard log review processes.

Requirement 11: Test Security of Systems and Networks Regularly

Requirement 11 covers security testing, including vulnerability scans and penetration testing.

11.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed. Your vulnerability scanning program must cover AI system components. This includes:

• Infrastructure hosting model serving, training, and data pipelines
• ML frameworks and library dependencies (scan for known CVEs)
• Model API endpoints (authentication, authorization, input validation)
• Container images used for model serving

11.4: External and internal penetration testing is regularly performed. Penetration testing of AI systems within PCI DSS scope should include AI-specific attack vectors:

• Prompt injection testing for LLM-based agents with access to payment data
• Model extraction testing for proprietary fraud detection or risk scoring models
• Data extraction testing to verify models do not leak cardholder data from training
• Agent tool-use testing to verify AI agents cannot escalate privileges or access data beyond their scope
• Adversarial input testing for models making payment decisions

Standard penetration testers may not have the expertise to conduct AI-specific tests. Consider supplementing your annual PCI penetration test with a specialized AI security audit that covers these AI-specific attack surfaces using frameworks like MITRE ATLAS.

11.5: Network intrusions and unexpected file changes are detected and responded to. If your AI system infrastructure is in the CDE, file integrity monitoring (FIM) and intrusion detection/prevention apply. For AI systems, extend FIM to cover:

• Model artifact files (detect unauthorized model replacements)
• Training data files (detect data poisoning attempts)
• Configuration files for model serving and pipeline orchestration
• AI agent system prompts and tool definitions

Requirement 12: Support Information Security with Organizational Policies

Requirement 12 addresses organizational governance. AI systems need explicit coverage in your policies.

12.1: A comprehensive information security policy is established. Your information security policy should explicitly address AI systems within PCI DSS scope. This includes:

• AI acceptable use policies for systems with access to cardholder data
• AI development and deployment policies
• AI vendor and third-party model risk management
• AI-specific incident classification and response procedures

12.3: Risks to the cardholder data environment are formally identified, evaluated, and managed. Your risk assessment must include AI-specific risks:

• Model memorization of cardholder data
• Prompt injection attacks against LLM agents with payment access
• Adversarial manipulation of fraud detection or risk scoring models
• AI supply chain risks (compromised pre-trained models, backdoored frameworks)
• Data poisoning attacks against training pipelines

12.8: Risk to information assets associated with third-party service provider relationships is managed. If you use third-party AI models or AI services within your CDE, those providers are in scope as third-party service providers. This means:

• Written agreements specifying the provider's PCI DSS responsibilities
• Due diligence on the provider's PCI compliance status
• Monitoring of the provider's compliance status annually
• Maintaining an inventory of which PCI DSS requirements are managed by which party

This is especially relevant for organizations using third-party LLM APIs (OpenAI, Anthropic, Google) within payment processing workflows. If cardholder data is sent to a third-party model API, that provider is a service provider under PCI DSS.

AI-Specific Challenges in PCI DSS Compliance

Beyond mapping requirements to AI systems, several AI-specific challenges deserve detailed attention.

Training Data Containing Cardholder Data

If you train models on datasets that include cardholder data, the entire training pipeline is in PCI DSS scope. This includes:

• Data extraction and export. The process of pulling transaction data from production systems for training purposes.
• Data storage. Where training datasets are stored, including data lakes, object storage, and local development machines.
• Training infrastructure. The compute environment where models are trained, including GPU clusters, cloud ML services, and notebook environments.
• Model artifacts. The resulting trained models, which may have memorized cardholder data from the training set.

Best practices for handling cardholder data in AI training:

• Tokenize before training. Replace PANs with tokens before data leaves the CDE. Train models on tokenized data whenever possible. The model can learn transaction patterns without seeing actual card numbers.
• Truncate and hash. If tokenization is not feasible, truncate PANs and hash them with a strong, keyed hash function. This preserves pattern recognition capability while eliminating full PAN exposure.
• Minimize training data scope. Only include the fields the model actually needs. A fraud detection model may need transaction amounts, timestamps, merchant categories, and behavioral signals without needing the full PAN.
• Implement training environment controls. Treat the training environment as part of the CDE. Apply network segmentation, access controls, encryption, and logging.

Model Memorization Risks

Large ML models, especially neural networks and language models, can memorize training examples. If cardholder data is in the training set, the model may be able to reproduce it under certain conditions.

This creates a unique PCI DSS challenge: the cardholder data is "stored" in model weights, not in a database. Traditional data-at-rest protections (field-level encryption, tokenization) do not apply to model weights in the same way.

Mitigations for model memorization:

• Differential privacy. Training with differential privacy guarantees (using frameworks like Opacus for PyTorch or TensorFlow Privacy) limits how much any individual training example can influence the model. This provably bounds memorization risk.
• Memorization testing. Before deploying a model, test whether it can reproduce cardholder data from its training set. Use extraction attack techniques (canary insertion, prefix probing) to evaluate memorization.
• Output filtering. Implement post-processing filters that detect PAN patterns (Luhn-valid sequences of 13 to 19 digits) in model outputs and redact or block them.
• Regularization. Standard ML regularization techniques (dropout, weight decay, early stopping) reduce memorization as a side effect of preventing overfitting.

AI Agent Access to Payment Systems

AI agents with tool-use capabilities introduce access control challenges that traditional access management was not designed for:

• Dynamic access patterns. An AI agent's access to payment systems depends on the user's request and the agent's reasoning. The same agent might query account balances, initiate refunds, or modify payment methods depending on the conversation. Each of these requires different authorization levels.
• Context-dependent permissions. The appropriate level of access depends on the customer's identity verification status, the transaction type, and the business rules in effect. AI agents need permission systems that evaluate context, not just identity.
• Prompt injection privilege escalation. An attacker using prompt injection might manipulate an AI agent into executing payment operations that the user is not authorized to request. The agent's service credentials may technically allow the operation even though the user should not have access.

Implementing compliant AI agent access:

• Use a permission proxy. Instead of giving the agent direct database or API access, route all agent actions through a permission proxy that validates each action against the user's authorization level, the action type, and business rules.
• Implement action-level logging. Log every action the AI agent takes, including the user context, the agent's reasoning (to the extent it can be captured), and the outcome. This satisfies Requirement 10 and provides an audit trail for disputes.
• Set action limits. Hard-code limits on the agent's capabilities. An AI agent should not be able to process a refund above a certain amount, access more than one account per session, or perform bulk operations, regardless of what instructions it receives.

Third-Party AI Model Risks

Using third-party AI models or APIs within your payment processing environment creates PCI DSS third-party risk management obligations.

Key considerations:

• Data transmission. If cardholder data is sent to a third-party model API for processing, the API provider is a service provider under PCI DSS. Verify their PCI compliance status and establish written agreements.
• Data handling by the provider. Understand how the third-party provider handles your data. Do they log inputs? Do they use your data for training? Do they retain it? These questions have PCI DSS implications.
• Model security. A compromised third-party model could produce manipulated outputs (incorrect fraud scores, wrong risk ratings) or exfiltrate data through model outputs. Your security controls need to account for this.
• Shared responsibility. Clearly document which PCI DSS requirements you handle and which the provider handles. Use the provider's Attestation of Compliance (AOC) and responsibility matrix to verify coverage.

Practical Implementation Guide

Here is a step-by-step approach to securing AI systems within PCI DSS scope.

Step 1: Inventory AI Systems in the CDE

Create a complete inventory of every AI system that stores, processes, or transmits cardholder data, or is connected to systems that do. For each system, document:

• System name and purpose
• Type of AI technology (ML model, LLM, rule-based AI, etc.)
• What cardholder data it processes (full PAN, truncated PAN, tokenized data, metadata only)
• How it connects to other systems in the CDE
• Who owns and operates it
• What third-party components or services it uses

Step 2: Define Scope Boundaries

Based on your inventory, define clear scope boundaries. Apply network segmentation to isolate AI systems that process cardholder data from AI systems that do not. The goal is to minimize the number of AI systems in PCI DSS scope while ensuring all in-scope systems are identified.

Step 3: Apply Data Minimization

For every AI system in scope, evaluate whether it needs the level of cardholder data access it currently has. Can PANs be tokenized? Can data be truncated? Can feature engineering be redesigned to work without raw cardholder data? Every data element you remove from AI processing reduces compliance scope and risk.

Step 4: Implement AI-Specific Controls

Layer AI-specific controls onto your existing PCI DSS control framework:

• Model memorization testing before production deployment
• Output filtering for PAN patterns in model outputs and AI agent responses
• Prompt injection defenses for LLM-based agents with payment access
• Model access controls based on least privilege
• AI agent action logging at the individual action level
• Model integrity monitoring (file integrity for model artifacts)

Step 5: Update Policies and Procedures

Extend your existing PCI DSS policies to explicitly cover AI systems:

• Add AI systems to your asset inventory procedures
• Include AI-specific risks in your risk assessment methodology
• Add AI system deployment to your change management process
• Include AI-specific incidents in your incident response plan
• Add AI vendors to your third-party risk management program

Step 6: Test AI-Specific Vulnerabilities

Supplement your annual PCI DSS penetration test with AI-specific security testing. This should include prompt injection testing, model extraction testing, data extraction testing, and agent behavior testing. Standard penetration testing firms may not cover these areas. Consider engaging a firm with specific AI security audit expertise.

Step 7: Prepare for Assessment

When your QSA or ISA assesses your AI systems, they need to understand:

• What AI systems are in scope and why
• How cardholder data flows through AI pipelines
• What AI-specific controls are in place
• How AI-specific risks are assessed and managed
• What testing has been performed on AI-specific attack vectors

Prepare documentation, evidence, and system demonstrations that address these points. If your assessor is not familiar with AI-specific risks, provide them with context on threats like model memorization, prompt injection, and adversarial inputs so they can properly evaluate your controls.

For a broader view of how AI governance fits into compliance programs beyond PCI DSS, see our guides on SOC 2 for AI Systems, ISO 42001 certification, and our overview of enterprise AI governance frameworks.