The short answer
PCI DSS v4.0.1 contains no requirement about artificial intelligence, and unlike ISO 27001 it does not have to be interpreted into relevance. It already says the thing that matters: sensitive authentication data must not be stored after authorisation, even encrypted — and the standard states directly beneath that requirement that it is not eligible for the customised approach. No risk analysis softens it.
So the useful question is not whether your AI tooling is “PCI compliant”. It is whether account data can reach it. If it can, you have created a storage location you cannot enumerate, in a system absent from your scope document, operated by a party you never assessed. If it genuinely cannot, you should be able to explain why without using the word “policy”.
The requirement with no escape hatch
Requirement 3.3.1: “SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.” Four lines below it, under Customized Approach Objective, the standard says: “This requirement is not eligible for the customized approach.”
That second sentence is what makes PCI DSS different in kind from a management system standard. ISO 27001 asks you to identify a risk, decide, and write the decision down; a documented decision to accept a risk can pass an audit. PCI DSS v4.0 introduced the customised approach so that entities could meet a control objective by other means — and then put roughly two dozen sub-requirements, this one among them, beyond its reach. There is no targeted risk analysis under 12.3.1 that makes retaining a card verification code acceptable.
Sensitive authentication data, per the standard’s own definition, is full track data (magnetic-stripe data or the chip equivalent), the card verification code, and PINs or PIN blocks. If one of those lands in a prompt and the provider retains inputs for abuse monitoring, the violation happened at submission. Encryption in transit is irrelevant here — the requirement says “even if encrypted”.
The primary account number is treated differently, and that difference gets misread as leniency. PAN may be stored, but 3.5.1 requires it rendered unreadable anywhere it is stored and 3.4.1 requires it masked when displayed. “Rendered unreadable inside a third party’s prompt log” is not a control you can evidence.
Scope is the whole argument
Nearly every disagreement about AI tools and PCI DSS is actually a scoping disagreement, and the standard’s definition is less forgiving than people expect. Requirements apply to the cardholder data environment — components, people and processes that store, process or transmit CHD or SAD, plus components with unrestricted connectivity to them — and, separately, to “system components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data.”
“System components” is defined to include cloud components and software, so an assistant is a candidate on its face. The bar for excluding one is high: to be out of scope, a component must be segmented such that it “could not impact the security of cardholder data and/or sensitive authentication data, even if that component was compromised.”
Apply that honestly to a coding assistant with repository access on the laptop of a developer who also writes the code that runs in the CDE. Then read 12.5.1, an inventory of in-scope system components, and 12.5.2, scope documented and confirmed at least once every 12 months and on significant change. If your scope document does not mention AI tooling, one of two things is true: it is genuinely out of scope and you can say why, or your scope is wrong.
How account data actually reaches a model
Not by someone typing a card number into a chat window. In practice:
- A pasted stack trace with the request body still in it.
- A log line copied in for debugging, from a service that logs more than it should.
- A test fixture built by copying a production row, now sitting in the repository the assistant indexes.
- A support export open in another editor tab, pulled in as context by an extension whose settings nobody read.
- A screenshot of a failing checkout, pasted into a multimodal chat.
- An agent with shell or database access, running a query and then reasoning over the output.
The last one changes the shape of the problem, because nobody pasted anything. What your IDE extension sends covers the context-collection mechanics; the nine-point check covers the human path.
Note 3.4.2 while you are here: when using remote-access technologies, technical controls must prevent copy or relocation of PAN except for personnel with documented, explicit authorisation. The standard means RDP and VPN. Whether an assistant that reads a screen and reproduces its contents elsewhere counts is arguable — but hold a deliberate position on it rather than improvising one when an assessor asks.
The provider you never assessed
If account data can reach the tool, the provider is a third-party service provider and the five sub-requirements of 12.8 apply: a list of all TPSPs with the service each provides (12.8.1); written agreements including their acknowledgement of responsibility for account data (12.8.2); an established due diligence process before engagement (12.8.3); a programme to monitor each TPSP’s PCI DSS compliance status at least once every 12 months (12.8.4); and a record of which requirements each party is responsible for (12.8.5).
Most model providers have no Attestation of Compliance, which makes 12.8.4 unsatisfiable as written. A signed DPA is not a substitute — that is a GDPR instrument and it says nothing about account data under the card brand rules. This pushes you back to the only clean answer available: architect so that account data cannot reach the tool, and document that as the reason there is no TPSP entry. Whatever the provider does claim needs reading rather than trusting — how to judge an AI provider lists what to ask for.
The requirement that describes this accident precisely
12.10.7 requires incident response procedures “to be initiated upon the detection of stored PAN anywhere it is not expected”, including determining what to do if PAN is discovered outside the CDE — “its retrieval, secure deletion, and/or migration into the currently defined CDE” — and identifying whether sensitive authentication data is stored alongside it.
Read that against a prompt sitting in a provider’s retention window. Retrieval: no. Secure deletion: you can file a request and receive an assurance. Migration into the CDE: not applicable. The requirement exists, it plainly applies, and the tooling does not let you perform it. Write the procedure anyway, and make the first step revoke-and-reissue, because that is the part you control.
Two requirements that catch AI-written code
6.2.3 — bespoke and custom software is reviewed prior to release. Authorship is irrelevant. Software developed for the entity’s own use is in scope whether a person or a model typed it, and “the model generated it” is not a review. 6.2.2 covers training for software development personnel, which now has to include what these tools do with what they are shown.
6.4.3 and 11.6.1 — payment page scripts. 6.4.3 requires every script loaded and executed in the consumer’s browser on a payment page to be authorised, its integrity assured, and inventoried with written justification. 11.6.1 requires a change- and tamper-detection mechanism on those pages. Both are among the future-dated requirements that became effective on 31 March 2025. If an assistant adds a script tag to a checkout page, you have just created something that needs a written justification in an inventory — and this pair is also why an AI browser extension running on a payment page is a live question rather than a theoretical one.
Where this genuinely collides
PCI DSS assumes you can enumerate where account data lives and demonstrate its deletion. That assumption holds for databases and backups. It does not hold for a model provider, which offers a retention policy rather than an enumerable location, and which may run abuse-monitoring pipelines that outlast a user-initiated delete — read your provider’s terms rather than assuming either way.
Zero-retention endpoints are the closest thing to a fix, and they are contractual rather than verifiable: you get a term in an agreement, not a mechanism you can test. Nobody has solved this. An assessor who accepts a zero-retention clause is accepting a supplier assurance — a normal thing to do, and worth naming as what it is.
What you should be able to hand an assessor
- A scope statement that mentions AI tooling, saying in or out, with the reasoning and a date.
- A data-flow diagram showing why account data cannot reach it, or where it can.
- Configuration evidence — exclusion patterns and disabled telemetry committed to the repository, rather than a policy asserting that people will be careful.
- The acceptable use policy. 4.2.2 requires PAN secured with strong cryptography whenever it is sent via end-user messaging technologies, and v4.0.1 updated its good-practice guidance on using acceptable use policies for end-user technologies. The requirement names email and instant messaging; treating a chat interface as the modern case is cheaper than arguing it is not.
- A TPSP record, or a documented reason there is not one.
- An incident procedure for a PAN found in a prompt, per 12.10.7.
- Training records covering what the tools transmit beyond what was typed.
The scope statement is the one that fails most often, because it is the one nobody owns.
What PCI DSS will not do for you
It will not tell you which tool to approve, and it has nothing to say about your source code leaking, your intellectual property, or whether the generated code is any good. Those are real risks that are simply not this standard’s business. It also predates the failure modes specific to these systems: there is no requirement for prompt injection, and mapping it to the secure development requirements under 6.2 is defensible — but that reasoning is yours, not the standard’s, and you should present it as yours.
Requirement numbers and quoted text here are from PCI DSS v4.0.1, the only version the PCI SSC has supported since v4.0 was retired on 31 December 2024; checked 30 July 2026. A request for comments on the next iteration ran from 3 June to 20 July 2026, so expect movement. Check anything here against your own copy of the standard, and treat your QSA’s interpretation as governing over any reading of mine.
Where to start
Find out whether account data can reach the tools your people already use, and do it by looking rather than asking: search your repositories for card-shaped strings, read the context settings on the extensions that are actually installed, and check whether anyone has wired an agent up to a database. Then write the scoping decision down with a date on it. The decision itself is usually defensible. The absence of one never is.