PCI DSS and AI: Protecting Cardholder Data in AI Systems

Artificial intelligence is arriving in payment environments faster than most compliance programmes can document it. Fraud-detection models score transactions in real time. Customer-service chatbots answer billing questions. Analytics teams feed transaction histories into machine-learning pipelines. Developer copilots suggest code that reads and writes to systems handling cardholder data. Each of these capabilities is useful, and each can quietly pull account data into places PCI DSS was never designed to reach. As a Qualified Security Assessor practice, we see the same pattern repeatedly: an AI feature is adopted for speed or cost, and nobody stops to ask where the cardholder data now flows. This post sets out how to keep cardholder data safe when you use AI and large language models in and around your payment environment, and how to build governance that will stand up to an assessor and a regulator.

Where AI shows up in and around the cardholder data environment

The first difficulty is visibility. AI rarely announces itself as a payment system. It appears as a helpful layer bolted onto processes you already run, and those processes often sit close to, or inside, the cardholder data environment (CDE). Common places we find it include:

• Fraud and risk scoring. Models that consume transaction attributes, and sometimes the primary account number (PAN) itself, to decide whether to approve or decline.
• Customer-service chatbots and virtual agents. Assistants that read order histories, take disputes, or help a cardholder locate a charge, frequently backed by a large language model (LLM).
• Analytics and reporting. Data-science pipelines that ingest transaction records to forecast revenue, detect churn, or segment customers.
• Developer copilots and code assistants. Tools embedded in the software delivery lifecycle that may see source code, configuration, test data, and occasionally live records.
• Operational automation. Ticket summarisation, log triage, and content generation that touch systems logging payment activity.

None of these is inherently unsafe. The risk is that AI components introduce new data flows, new storage locations, and new third parties, and that these are invisible to a scoping exercise that only looks for traditional databases and web servers. If you cannot draw the AI on your data-flow diagram, you cannot assess it.

The new ways cardholder data leaks into AI systems

Cardholder data does not need to be deliberately loaded into a model to end up there. It leaks through ordinary use. The leakage points that matter most are:

• Prompts and chat transcripts. A support agent or customer types a PAN into a chat window to “check a card”. That prompt is now data in transit and, very often, data at rest in a conversation history.
• Model and application logs. LLM applications log inputs and outputs for debugging and quality monitoring. If a PAN reached the prompt, it is now in a log, which is one of the classic ways sensitive data spreads beyond its intended boundary.
• Retrieval and vector stores. Retrieval-augmented generation embeds documents into a vector database. If those documents contain account data, that data is now stored, indexed, and searchable in a system your CDE inventory never mentioned.
• Fine-tuning and training data. Transaction records used to train or fine-tune a model become embedded in that model and its training corpus, which are difficult to redact after the fact.
• Third-party AI vendors. When you call a hosted model, your prompt leaves your environment entirely. Whatever the vendor does with it, retention, logging, or further training, is now partly outside your direct control and must be governed contractually.

The common thread is that AI systems copy data readily and remember it in ways that are hard to reverse. That is precisely the behaviour PCI DSS is written to constrain.

How PCI DSS scoping applies to AI components

PCI DSS scoping does not change because a system is described as “AI”. The rule is unchanged: any system component that stores, processes, or transmits account data (cardholder data or sensitive authentication data) is in scope. Equally, components that are connected to the CDE, or that could impact the security of the CDE, are also in scope even if they never touch a PAN directly.

Applied to AI, this means a chatbot that can receive a PAN in a prompt is in scope because it transmits and may store account data. A vector store holding embeddings derived from cardholder data is in scope because it stores that data. An AI vendor that processes your prompts is a service provider handling account data. And an AI administration console with a network path into the CDE can be security-impacting even if it never sees a card number. The safest posture is to treat every AI component that could plausibly touch account data as in scope until a documented analysis proves otherwise. For a refresher on the current requirement set that all of this maps to, see our note on the PCI DSS v4.0.1 future-dated requirements now in force, and our PCI DSS hub.

Mapping PCI DSS requirements to AI controls

The existing requirements already give you most of what you need to control AI. The table below maps the requirements we lean on most heavily when assessing AI-enabled payment environments to the controls we expect to see.

Requirement 12.3.1 deserves particular attention. Adopting a new AI capability is exactly the kind of change that should trigger a documented risk analysis, and we walk through how to structure one in our Targeted Risk Analysis guide.

A practical set of guardrails

Requirements tell you what to achieve. The following checklist is how we recommend you achieve it in practice. Treat it as a minimum baseline for any AI feature that operates in or near the CDE.

• Minimise the data. Start by asking whether the AI feature needs account data at all. Most fraud, analytics, and support use cases can run on tokens, masked values, or derived attributes rather than the raw PAN.
• Tokenise or mask before AI. Where a card reference is genuinely required, substitute a token or truncated value before the data reaches the model, so the real PAN never enters the prompt, the transcript, or the training set.
• Block PAN from prompts and logs. Deploy input and output filtering that detects and strips card data before it is sent to a model or written to a log. Assume users will paste card numbers into chat, and design for it.
• Isolate AI systems from the CDE where possible. Keep AI components on segmented networks with tightly controlled connections, so an AI tool cannot become an unmonitored bridge into your payment systems.
• Contractually bind AI vendors. Use written agreements under Requirement 12.8 that address account data handling, retention, sub-processing, and whether your data may be used to train shared models. If a vendor cannot commit, do not send them cardholder data.
• Govern the lifecycle. Version models and prompts, review them before release, monitor them in production, and retire them cleanly. Include AI changes in your change-management and Targeted Risk Analysis processes.

Pairing PCI DSS with ISO/IEC 42001 for defensible AI governance

PCI DSS gives you strong technical controls over cardholder data. What it does not do, because it was never intended to, is govern the wider behaviour of an AI system: how models are selected, how their risks are assessed, how bias and reliability are managed, and how accountability is assigned across the organisation. This is where a management-system standard earns its place.

ISO/IEC 42001 is the international standard for an AI management system, and it can be certified. It provides the governance structure, roles, risk processes, and lifecycle controls that surround your AI use, while PCI DSS protects the account data that AI use might touch. Together they let you demonstrate two things at once: that cardholder data is controlled to the payment industry’s standard, and that your AI is managed responsibly to an international benchmark. That combination is what makes AI use in a payment environment defensible rather than merely functional.

This pairing is Cianaa’s differentiator. As an independent QSA practice that also assesses ISO/IEC 42001, we can look at an AI-enabled payment feature through both lenses in a single engagement, so your technical controls and your governance tell a consistent story.

Frequently asked questions

Can I send cardholder data to an AI model or chatbot?

Avoid it wherever you can. If a feature can run on a token, a masked value, or a derived attribute, use that instead of the real PAN. Where account data is genuinely required, minimise the volume, tokenise or mask before the data reaches the model, and treat every component that touches the data, including the model, its logs, and any vector store, as in scope for PCI DSS. Never send sensitive authentication data to an AI system, and never let it be stored after authorisation.

Does using a hosted AI service make my provider a PCI DSS service provider?

If the service could store, process, or transmit account data on your behalf, then yes, it is a third-party service provider under Requirement 12.8. You must perform due diligence, hold a written agreement covering their responsibility for that data, and understand their retention and training practices. If they cannot meet those obligations, do not route cardholder data to them.

Is prompt injection really a PCI DSS concern?

It is. Requirement 6 covers secure development, and prompt injection is a known way to make an AI feature disclose data or perform actions it should not. If an injected instruction can coax a model into revealing account data or reaching into a connected system, that is a security-impacting defect, and your development and testing processes should address it.

Do I need a Targeted Risk Analysis before adopting AI?

Adopting a new AI technology is exactly the kind of change that should trigger a Targeted Risk Analysis under Requirement 12.3.1. Document what data the AI will see, where it runs, which third parties are involved, and how you will control the risks before you deploy it, not after.

How Cianaa can help

Cianaa is an independent PCI QSA practice serving New Zealand and Australia, and we also assess ISO/IEC 42001 AI management systems. We can scope your AI-enabled payment environment, map your controls to the current PCI DSS requirements, run the Targeted Risk Analysis, and pair it with responsible-AI governance so your use of AI is both compliant and defensible. To discuss your environment with a Principal Assessor, get in touch with our team.