PCI DSS & AI Compliance

Overview

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements established by the PCI Security Standards Council to protect cardholder data. The standard applies to all organizations that store, process, or transmit cardholder data, regardless of size or transaction volume. Version 4.0 was published in March 2022, version 4.0.1 replaced it at the end of 2024, and the requirements that version 4.0 marked as future-dated became mandatory on 31 March 2025. Version 4 introduced a more flexible, outcome-based approach to security controls and new requirements for authentication, encryption, and continuous monitoring.

For AI systems in financial services, PCI DSS becomes relevant whenever training data includes or is derived from payment card information. Fraud detection models, transaction risk scoring, customer behavior analytics, and payment optimization all potentially interact with cardholder data. The standard's twelve core requirements cover network security, data protection, vulnerability management, access control, monitoring, and security policy, and each has direct implications for how AI training pipelines handle payment card data.

Organizations are assigned compliance levels based on transaction volume, and Level 1 merchants (over 6 million transactions annually) typically require an annual on-site assessment by a Qualified Security Assessor (QSA). Smaller organizations generally complete an annual Self-Assessment Questionnaire (SAQ) and must maintain ongoing compliance. The consequences of non-compliance extend beyond fines: organizations can lose the ability to process card payments entirely.

AI-Specific Requirements

PCI DSS Requirement 3 mandates the protection of stored account data through methods such as encryption, truncation, tokenization, and hashing. For AI training data, this means that primary account numbers (PANs) must be rendered unreadable wherever they are stored, and sensitive authentication data must not be stored after authorization at all. If training datasets contain transaction records with full PANs, those PANs must be protected or, better, removed, truncated, or tokenized before the data enters the training pipeline. Organizations must also implement key management procedures for any cryptographic keys used to protect cardholder data.

Requirement 7 restricts access to cardholder data to individuals whose job requires it, implementing the principle of least privilege. For AI development teams, access to datasets containing cardholder data should be limited to those working on payment-related models with a documented business need. Requirement 10 mandates logging and monitoring of all access to system components and cardholder data, so AI training pipelines in scope must keep detailed audit trails of who accessed cardholder data, when, and for what purpose.

PCI DSS v4 introduced requirements particularly relevant to AI systems. Requirement 6.3.2 mandates an inventory of bespoke and custom software, which includes custom AI models that process cardholder data. Requirement 12.3.1 requires targeted risk analyses for each requirement that offers flexibility in how it is met. For AI systems, this means documenting the specific risks that cardholder data faces within the ML pipeline and justifying the controls implemented to address them. Organizations must also meet Requirement 11's vulnerability scanning and penetration testing obligations for AI system components that are in scope.

How Ertas Helps

The most useful rule for PCI DSS is to keep cardholder data away from Ertas entirely. Ertas Studio trains on Ertas's cloud GPUs, so anything in a training dataset is uploaded to Ertas and stored so runs can be repeated. Remove, truncate or tokenize PANs and other cardholder data before upload, so neither the training set nor Ertas falls inside your cardholder data environment (CDE). Fraud and risk tasks can often learn from tokenized or truncated values, and Data Craft, Studio's dataset builder, lets you edit and approve each example before training. You can delete uploaded datasets at any time.

At inference, the model may see live transaction data. Export it as GGUF or safetensors and run it in your own environment, inside or outside the CDE as your scoping requires, and that data never reaches Ertas. You own the model, and its version stays fixed until you retrain, so you can list it as one known item in the bespoke and custom software inventory Requirement 6.3.2 asks for. The adaptive model endpoint and enterprise builds can run the model in your own cloud or on-premise.

Scoping and segmentation, Requirements 3, 7, 10 and 11 for the systems where the model runs, targeted risk analyses, and your annual assessment stay with you.

Compliance Checklist