PCI DSS and AI systems in the CDE | what changes

Does PCI DSS apply to AI systems in the cardholder data environment?

PCI DSS applies to an AI system in the same way it applies to any other technology in or connected to the cardholder data environment (CDE). If an AI assistant, copilot or model-serving component stores, processes or transmits card data, or could affect the security of systems that do, it is in scope. The PCI SSC's information supplement *Security Considerations for AI Systems*, published on 15 September 2026, reinforces this position: AI should be treated as no different from any other technology when scoping applicable requirements. The supplement is guidance, not mandatory requirements, and the PCI standards take precedence where the two differ. Read the supplement for direction on scoping and risk, but do not treat it as a replacement for the requirements themselves.

The first practical step is to confirm what the AI component touches. Ask which prompts, logs, retrieval stores, vector databases, plugins and API keys can reach card data, and whether any model endpoint, training pipeline or support tool runs on in-scope systems or shares a network segment with them. Record each component in the inventory that Requirement 12.5.1 expects, with its function, and bring it into the Requirement 12.3.4 technology review cycle. Where an AI tool is a third-party service, confirm in writing what data it receives and retains, because that determines whether the provider is a service provider whose responsibilities must be documented.

Responsibility is split clearly. Your organization owns its controls and decides the scope. An implementation partner such as DeployOpen can prepare systems, network segmentation, logging, access configuration and evidence, but it does not validate compliance. Only a Qualified Security Assessor (QSA) can issue the Report on Compliance (ROC) or the Attestation of Compliance (AOC) for your assessment. Cost and timeline cannot be stated here because they depend on how many AI components are in scope, how they connect to the CDE and how much evidence already exists. Ask any partner for a written scope, and ask your QSA early how they plan to assess AI components.

How to scope an AI tool like any other system component

The PCI SSC's AI supplement says AI should be scoped like any other technology, so the glossary definition of a system component decides what is in scope. Each card below covers one AI pattern that often lands inside or next to the cardholder data environment, and what to record about it for Requirement 12.5.1 and your segmentation and data-flow evidence.

Models hosted on in-scope infrastructure

A model that runs on a server, virtual machine or container that connects to the CDE is a system component in its own right, whatever it is called. Record the model, the host, its network paths and its function in the inventory, such as classifying transactions or summarizing support tickets. Ask your QSA whether a hosted model that never receives account data still counts as connected to the CDE, and document the answer with the network evidence that supports it.

Inference servers and model gateways

Inference servers and gateways sit in the request path, so they often receive prompts that contain account data and return outputs that can be stored. Treat them as in-scope components when they handle cardholder data or can affect its security. Check which segments they reach, whether their logs keep prompts, and whether administrative interfaces are reachable from outside the environment.

Vector stores holding retrieved records

Vector databases built from transaction notes, tickets or documents can hold PAN in embeddings, metadata or original text. The embedding itself is not a safe place to assume card data is absent. Confirm during scoping whether the store ingests payment data, which retrieval paths can return it, and how the store's storage is protected under the requirements for stored account data.

Agent tools with API access to card data

An AI agent that calls internal APIs to look up payments, refund orders or reset customer records extends the CDE through every tool it can invoke. Each tool, its service account and its endpoints belong in the inventory with a stated function. Map which tool calls reach systems holding account data, and record the access limits that stop an agent from reaching beyond the task it was built for.

Prompt and output logs containing PAN

Prompt logs, traces and conversation histories are often the first place a PAN appears outside the payment system. A log that stores prompts is a system component that holds account data, and it needs to be scoped and protected like one. Check whether debugging tools capture full inputs, whether retention limits apply, and whether analysts can read the logs. Illustrative example: a support chatbot that logs every message can make the log store part of scope.

Developer copilots with repository and secret access

Coding assistants that read repositories, terminals or CI secrets can reach payment code, configuration and keys, which makes the developer workstation and its tokens part of the review. Inventory the copilot, the accounts it runs under and the repositories it indexes. Ask your QSA how secret access is limited, and confirm the boundary before the next assessment cycle, because the requirement for inventory and annual technology review applies to these tools too.

Who owns what when AI runs in a payment environment

Your organization remains accountable for PCI DSS compliance, whatever tools or partners it uses. The entity that stores, processes or transmits cardholder data owns the controls, the scoping decisions and the risk responsibilities that come with an AI system touching the cardholder data environment (CDE). The PCI SSC's AI supplement says AI should be treated as no different from any other technology when scoping applicable requirements, so the decision to bring an AI tool into the CDE is a normal change that your team must govern.

Scope decisions: Decide whether an AI assistant, model endpoint, retrieval store or agent can reach account data or systems that can affect the CDE, and document the reasoning.
System component inventory: Record each AI component in the inventory required by Requirement 12.5.1, with its function or use.
Technology reviews: Include AI libraries, model services and vendor tooling in the technology review required by Requirement 12.3.4, including vendor end-of-life announcements.
Vulnerability management: Monitor and act on findings frequently, as the supplement recommends, and approve remediation plans at senior management level.
Risk review and acceptance: Own the risk decisions and any approved deviations, including the choice of defined or customized approach.

Before your assessment, confirm which owner signs off each of these items and where the evidence is kept.

Keeping vulnerability management current for AI components

AI model servers, containers and frameworks bring new software into the cardholder data environment, and they change faster than a typical payment system. The cards below cover the review cadence, scanning and patching workflows, the Requirement 6 and 11 evidence an assessor will ask for, and the vendor questions to settle before deployment.

Continual vulnerability monitoring cadence

The PCI SSC's AI supplement stresses frequent, if not continual, vulnerability monitoring because AI-powered tools can find weaknesses faster than periodic scans. Set a documented cadence for each AI component, such as model servers, inference gateways and agent runtimes, and agree who reviews new advisories for them. Confirm with your assessor how the cadence fits your existing scan schedule so the evidence is consistent.

Scan and patch workflow for model servers

Model servers, inference containers and AI frameworks such as Python libraries, CUDA drivers and orchestration agents each carry their own patch stream. Build one workflow that pulls images, scans them before deployment, tracks findings to a named owner and records the patch date. Illustrative example: a model server image rebuilt weekly with a patched base layer, with the scan report stored beside the change ticket.

Container and image inventory

Requirement 12.5.1 expects an inventory of in-scope system components with each one's function. For AI workloads, record container images, model artifacts' runtime dependencies, GPU hosts and framework versions, not only the virtual machines beneath them. Ask your platform team whether the inventory updates automatically when a new image is deployed, because a stale list is a common assessment finding.

Requirement 6 patching and change evidence

Requirement 6 covers secure development and the patching of known vulnerabilities, including critical updates applied within defined timeframes. Keep change records that link each AI framework update to its test results, approval and rollback plan. Confirm with your assessor which records they will sample for AI components, since model and prompt changes may be treated as changes to the environment.

Requirement 11 scans and penetration tests

Requirement 11 requires internal and external vulnerability scans and penetration testing on defined schedules, with rescans after significant changes. External scans for internet-facing AI endpoints may need an Approved Scanning Vendor, while internal scans can come from your team or a qualified provider. Confirm which scans your assessor expects for each AI endpoint and whether the penetration test covers prompt injection and agent tool misuse.

Requirement 12.3.4 technology reviews

Requirement 12.3.4 requires hardware and software technologies to be reviewed at least every 12 months, including vendor end-of-life announcements and a remediation plan approved by senior management. Add every AI framework, model runtime and vector database to that review, and record the end-of-life dates your vendors publish. Ask each AI vendor how long they will issue security fixes for a version before the review decides to upgrade or retire it.

How an AI-touched environment moves through a PCI DSS assessment

This sequence takes an AI-touched payment environment from a defined scope to an assessor-issued report, with each step producing the record the next one depends on. Organizations own the controls and evidence, while the QSA tests them and issues the ROC or the SAQ with its Attestation of Compliance.

Confirm scope and build the component inventory
The organization, with its QSA or internal assessor, decides which systems store, process or transmit cardholder data or could affect the security of the cardholder data environment. Every AI tool in that boundary is treated like any other technology, so model endpoints, vector stores, inference servers, agent runtimes, coding assistants and the cloud services hosting them are listed as system components. The inventory records each component's function or use, which is what Requirement 12.5.1 asks for. The step is done when the scope statement and inventory are signed off by the people accountable for the payment environment.
Document data flows including prompts and outputs
Engineering and the payment owner map how card data, account data and related identifiers move into and out of each AI component. The map should show prompts, retrieved context, tool calls, model outputs, logs, fine-tuning or evaluation datasets and any data copied into chat or support tools. Each flow is tagged with the data it carries and the systems that can read it. The step closes when the diagram and its written narrative agree with what the systems actually do, which the team confirms by tracing sample transactions end to end.
Re-check the scope boundary for AI components
Using the data flows, the team decides which AI components are in scope, which connect to the cardholder data environment, and which can only affect its security. An AI tool that can call a payment API, read logs with account data or change firewall rules falls within scope even if it never stores a card number. The output is a documented decision for each component, with the reasoning and any segmentation or tokenization relied upon. Where the team relies on segmentation, the QSA will expect evidence that the boundary was tested.
Test controls on AI components
Each in-scope requirement is applied to the AI components as it would be to any other system: access control and multi-factor authentication for model and admin consoles, hardening of inference servers and containers, encryption of stored and transmitted account data, logging of administrative and data access, and change control for prompts, models and configuration. Vulnerability scanning and patching cover the AI stack, and the team tracks vendor end-of-life notices for model-serving software. The step ends when a tester has run each control against the component and recorded the result, including any gaps and the remediation plan approved by senior management.
Collect evidence for each requirement
The organization gathers the artifacts that show each control operated over the assessment period: configuration exports, access reviews, scan reports, logs, change tickets, policy approvals, training records and vendor agreements covering AI services. Evidence is labeled by requirement and by AI component so the QSA can trace each claim to a source. The step is complete when the evidence index covers every in-scope requirement and an internal reviewer has confirmed that each artifact is current and accurate.
Complete QSA testing of the AI environment
The QSA independently tests the controls, interviews the people who run the AI components, samples transactions and reviews the scope and data-flow decisions. Where the organization used a customized approach or compensating controls, the QSA evaluates whether the stated objective is met. The QSA may also use the assessor guidance on the use of AI during assessments, but the judgment and the findings remain the assessor's. The step ends with the QSA's findings and a list of any items to remediate before the report can be finalized.
Issue the ROC or SAQ with an Attestation of Compliance
If the organization requires a Report on Compliance, the QSA completes it on the PCI SSC template and signs the Attestation of Compliance. If the organization qualifies for a Self-Assessment Questionnaire, the organization completes the SAQ and its own Attestation of Compliance, with the scope and evidence retained for review. In both cases the document states how AI components were scoped and tested. The output is the signed report or attestation, which the organization shares with the payment brands or acquirer that require it. Certificates are not recognized as validation, so the signed attestation is the deliverable to confirm before work starts.

AI in software lifecycles: Secure SLC v2.0 and Requirement 6

If you sell payment software or build custom code that touches cardholder data, the Secure SLC Standard v2.0 changes what your assessor will ask about AI. The PCI SSC released version 2.0 on 28 September 2026, its first major revision, aligned with v2.0 of the Secure Software Standard. The revision adds a Sensitive Asset Identification Document and requirements on digital tools used in a vendor's lifecycle, including AI. For a software vendor, that means the AI coding assistants, code review bots, test generators and build agents your developers use are now part of the lifecycle your validation covers. Start by listing every AI tool that touches source code, build pipelines, test data or release artifacts, and record which products, versions and vendors each team uses. Confirm with your Secure SLC assessor how they expect that list to be presented and whether the Sensitive Asset Identification Document should name the code repositories and data sets those tools can reach.

If you are a merchant or a non-vendor company that builds its own payment code, the relevant requirement is Requirement 6, which covers secure development of bespoke and custom software, code review and the handling of vulnerabilities in your own applications. Requirement 6 does not name AI tools, but the duties it sets apply to whatever writes or reviews the code. An AI coding assistant that proposes changes to a checkout, a payment API or a card-handling module is part of the development process, so its output needs the same review, testing and approval as code written by hand. Record which assistants are allowed, which repositories they can read, whether prompts or code snippets leave your environment, and who signs off on AI-generated changes before they reach production. Ask your QSA how they will test this during the assessment, and keep the inventory current as tools are added or changed.

Governance for AI in the lifecycle should sit inside the processes you already run for secure development rather than in a separate AI policy. Vendors should extend the Sensitive Asset Identification Document and their threat model to cover AI tools and the data they can access, and merchants should add AI tools to their change management and code review records. Any AI use in an assessment, such as an assessor's own tools, is governed separately by the PCI SSC's guidance on integrating AI in PCI assessments, so do not assume that guidance changes your obligations. Because the PCI SSC's AI supplement is guidance and the PCI standards take precedence, treat Secure SLC v2.0 and Requirement 6 as the controlling texts when you decide what to inventory and review. Implementation partners can help build the inventory, configure the review gates and prepare the evidence, but the organization owns the decisions, and only the assessor issues the validation result.

Risks that bring AI into PCI DSS scope unexpectedly

AI rarely enters a payment environment through a planned project. It arrives through staff tools, logs, vendor APIs, data stores and agents that were granted access for convenience. Each risk below is a way cardholder data or a payment system can pick up AI in scope without anyone deciding so, along with the control response and evidence an assessor would look for.

Shadow AI tools receiving card data

Staff paste order records, refund disputes or customer messages into general-purpose AI assistants to draft replies or summarize cases. If a prompt contains a primary account number or card verification code, the assistant's provider may store or process that data outside your environment. Control response: publish an approved AI tool list, block unapproved AI domains on managed endpoints, and train staff on what must never be pasted. Evidence: the approved tool list, egress filtering records and training completion records.

Logs and traces retaining PAN

AI application frameworks often record full prompts, tool inputs and model responses for debugging, evaluation or observability. A trace that captures a PAN turns the log platform, its backups and its access list into system components that must meet storage and access requirements. Control response: mask or tokenize card data before it reaches the model, set retention limits on trace stores, and restrict who can query them. Evidence: redaction rule configuration, retention settings and log access reviews.

Third-party AI APIs as service providers

When a payment flow calls an external model API to classify transactions, detect fraud or draft merchant messages, that provider can store, process or transmit account data and so may fall within the service provider definition. Control response: confirm during procurement whether the provider receives card data, keep a written responsibility matrix, and request its PCI DSS attestation where it is available. Evidence: the contract, the responsibility matrix and the provider's current attestation of compliance.

Retrieval stores indexing transactions

Retrieval-augmented systems copy documents into vector databases and search indexes so a model can answer questions. If transaction records, settlement files or support tickets with PAN are ingested, the index becomes a copy of cardholder data that is often less controlled than the source system. Control response: exclude card fields at ingestion, restrict indexing to tokenized data, and include the index in the data inventory. Evidence: ingestion pipeline rules, data flow diagrams and the stored data inventory entry.

Agents with broad credentials

An AI agent given a service account that can read payment databases, query the card vault or call settlement APIs has far more reach than the task requires. Such an agent also makes actions that no human reviewed, which complicates access reviews and audit trails. Control response: give each agent a dedicated identity with least privilege, require human approval for payment-affecting actions, and log every tool call. Evidence: the agent identity inventory, access control configuration, and log samples showing attributed tool calls.

AI-assisted call and chat transcripts

Speech-to-text and chat summarization tools can capture card numbers and verification codes that customers read aloud or type. The transcript, the summary and the vendor's processing pipeline may each hold data that the original call recording did not. Control response: pause or mask recording during payment capture, suppress verification codes before any transcription, and confirm vendor retention. Evidence: suppression test results, transcription vendor terms and retention settings for transcripts and summaries.

Questions buyers ask about AI and PCI DSS

Is an AI tool in our call center in scope for PCI DSS?

It is in scope if it can store, process or transmit cardholder data, or could affect the security of the systems that do. An AI assistant that listens to live payment calls, transcribes them or stores recordings can touch account data even when agents never read card numbers aloud. The PCI SSC's AI supplement says AI should be treated as no different from any other technology when scoping. Start by mapping every data flow the tool touches, including recordings, transcripts, logs, vendor-side storage and any integration with the payment system. Your QSA makes the final scoping call, so bring that data-flow map to the first scoping discussion.

Does using a hosted LLM API make the model provider a service provider?

It depends on whether the provider stores, processes or transmits cardholder data for you, or could affect the security of your cardholder data environment. If prompts or outputs contain account data, the provider may fall within PCI DSS scope as a service provider, and you would need its responsibility matrix and current validation evidence. If you strip account data before sending anything to the API and the provider cannot access payment systems, the answer may differ. Confirm the provider's data retention, logging and training terms in writing, and ask your QSA how the arrangement affects your third-party service provider duties under Requirement 12.

What does a PCI DSS assessment add for AI systems?

An assessment checks AI components the same way it checks other system components, so the AI tools must appear in your inventory, risk review and vulnerability management processes. Assessors look for a current inventory of in-scope components with each one's function, a periodic review of hardware and software technologies with a remediation plan, and evidence of frequent vulnerability monitoring. They may also ask how AI-assisted tooling is used during the assessment itself, which the PCI SSC covers in separate guidance on integrating AI into assessments. Expect questions about access controls, logging and the data the models retain.

Is the PCI SSC's AI supplement mandatory?

No. The supplement, Security Considerations for AI Systems, is informational guidance, not a set of mandatory requirements. The PCI standards take precedence where the two differ. It still matters in practice because it explains how to scope AI under existing requirements and how to defend traditional systems against AI-enabled attacks, which assessors may use as a reference. Read it alongside the standard's requirements, and record in your scope documentation how you applied its guidance to each AI component.

How long does it take to prepare AI systems for a PCI DSS assessment?

No timeline is supplied for this work, so ask your QSA and implementation partner for a scope-based estimate. The main drivers are how many AI tools touch payment data, how well your data flows and inventories already exist, whether AI components need segmentation or new access controls, and how much logging and vulnerability evidence must be produced. Ask each provider to list which activities are one-time, such as scoping and architecture changes, and which recur, such as inventory reviews and vulnerability monitoring. Request the estimate in writing, tied to the agreed scope.

What does our internal team need to contribute?

Your team owns the controls, so it must supply the knowledge the assessor will test. That includes the owners of each AI tool, the people who approve access and model changes, the staff who review vulnerability reports and the people who maintain the inventory. Plan for data-flow documentation, vendor contracts, configuration records and log samples. An implementation partner can prepare systems, controls and evidence, but it cannot replace these people's accountability for day-to-day operation after the assessment ends.

Can an implementation partner run the PCI DSS assessment for us?

No. Only a Qualified Security Assessor (QSA) can complete a Report on Compliance, and an Internal Security Assessor (ISA) can support an internal assessment within the rules set by the PCI SSC. A partner can help you prepare systems, document controls, build evidence and remediate gaps, but it cannot issue the assessment or the Attestation of Compliance. Keep consulting and assessment work with separate firms where possible, and ask any QSA you consider to confirm its independence from your remediation work.

Confirm the scope before you buy AI tooling for payment systems

Before you buy an AI tool that will touch payment data or payment systems, confirm its role in the cardholder data environment (CDE) with three parties: your acquirer or payment brand, your Qualified Security Assessor (QSA), and the vendor. The PCI SSC's information supplement on AI systems says AI should be scoped like any other technology, so the question is not whether the tool is AI but whether it stores, processes or transmits account data, or could affect the security of systems that do. Ask the vendor to name every component the tool connects to, and confirm with your QSA whether that connection brings it into scope. Record the answer in your system component inventory with its function, as Requirement 12.5.1 expects.

Put four questions to the vendor in writing. First, how long does it retain prompts, outputs, logs and any uploaded files, and can you configure or delete that retention? Second, where are its sub-processors and model hosts located, and which ones can access that data? Third, do the models ever see a primary account number (PAN), even in a fragment, a screenshot or a support ticket? If the answer is yes, the tool is almost certainly in scope and you should plan the controls around it, such as masking or tokenization before the data reaches the model. Fourth, what is the vendor's patch and vulnerability cadence for the platform and its model-serving components? The supplement stresses frequent, if not continual, vulnerability management, so a quarterly patch promise is a finding to discuss, not a detail to skip.

Ask your acquirer whether the tool needs to be listed in your validation documentation, and ask your QSA how they will test it during the assessment. Also confirm whether the vendor's own software development follows the Secure SLC Standard, since that bears on how the tool was built. Treat these answers as the basis for a contract clause on data retention, breach notice and change notification, and schedule a review of the tool at least every 12 months under Requirement 12.3.4, including any vendor end-of-life announcements. If a vendor cannot answer these questions, the gap is a scoping risk you carry, not one the vendor absorbs.

How DeployOpen prepares AI systems for a PCI DSS assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including AI tools that touch payment data or payment systems. We prepare systems, controls and evidence for the assessment, while the organization owns its controls and an independent QSA issues the Report on Compliance or Attestation of Compliance.

How we scope

Map every AI tool, model host, data pipeline and integration that touches the cardholder data environment in the written scope
Apply the same scoping logic used for any other technology, documenting which AI components store, process or transmit account data
Confirm with your QSA which systems fall in scope before build work starts, and record that agreement in the scope document

How we build

Configure AI platforms and their supporting systems to the requirements that apply to them, with hardening and access controls documented
Set up vulnerability scanning and patch tracking for AI components so monitoring can run at the frequency your risk review sets
Test the deployed environment, including security testing of AI interfaces and APIs, and record remediation against each finding

How we hand over

Deliver a component inventory listing each AI system's function or use, aligned with the inventory expected under Requirement 12.5.1
Provide network and data-flow diagrams, configuration baselines and the policies and procedures that cover the AI systems
Hand over an evidence index mapping each control to its artifact, so your QSA or internal assessor can test it directly

How we support

Support the annual technology review and end-of-life tracking that Requirement 12.3.4 expects, with a remediation plan approved by senior management
Review changes to AI models, integrations and hosting for scope impact and update documentation when a significant change occurs
Offer ongoing support, upgrades and continuous testing as a retainer, with scope for each retainer agreed in writing