Skip to content

PCI DSS When an AI Assistant Can See a Payment Flow

9 min read · updated August 11, 2026

PCI DSS does not have an AI section and does not need one. The moment a model can receive a primary account number, the model provider, your prompt logs and your observability stack are system components in scope, and the assessment you were passing last year no longer describes your environment.

Scope is decided by connectivity, not intent

The Payment Card Industry Data Security Standard is issued by the PCI Security Standards Council; version 4.0 was published in March 2022, version 4.0.1 in June 2024, and the requirements that were future-dated in v4.0 became mandatory on 31 March 2025. Its scoping rule is the part people get wrong. The cardholder data environment comprises the people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data — and any system component that is connected to or could impact the security of the CDE. Requirement 12.5.1 obliges you to maintain an inventory of those components, and 12.5.2 to confirm the scope at least annually.

An assistant that can call an internal API returning an order record is therefore not out of scope merely because you did not intend it to see a card number. If the path exists, the scoping question is whether it could carry cardholder data, and the answer has to be demonstrated rather than asserted. The Council’s standards and its scoping information supplement are in the PCI SSC document library.

This page is not legal or compliance advice, and it is not a substitute for your QSA. Scope determinations are fact-specific and your acquirer’s expectations may be stricter than the standard. Get the scope confirmed by somebody who will sign the report.

The data that may never be stored

PCI DSS splits card data into two categories with different rules, and conflating them is the fastest way to a finding.

  • Cardholder data — the primary account number, plus cardholder name, expiration date and service code where they accompany it. The PAN may be stored if it is rendered unreadable: Requirement 3.5.1 accepts one-way hashing with a keyed cryptographic hash of the entire PAN, truncation, index tokens, or strong cryptography with key management. Requirement 3.4.1 restricts display to at most the first six and last four digits for anyone without a documented business need to see more.
  • Sensitive authentication data — full track data, the card verification value (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks. Requirement 3.3.1 prohibits retaining SAD after authorisation, even encrypted. There is no compliant way to keep it, which means there is no compliant prompt log that contains it.

Prompts and logs are storage

This is the specific point that makes AI assistants different from the integrations PCI DSS was written for, and it is worth being blunt about. A prompt is a string that you send somewhere and that several systems keep. In a typical deployment the same PAN can come to rest in at least six places: your application log, your tracing or observability backend, the request body captured by an API gateway, the model provider’s own request logs, any abuse-monitoring retention the provider applies, and the conversation history you persist to give the assistant memory. Every one of those is storage of cardholder data, and every one of those systems is in scope.

The conversation history deserves particular attention because it is the feature that makes the assistant useful. A session in which the customer typed their card number to correct a failed payment produces a transcript you now hold indefinitely, replicated into whatever you use for evaluation and prompt improvement. Requirement 3.2.1 says data storage is minimised by a retention policy with a defined retention period and a process for secure deletion — and Requirement 9.4.6 extends the same idea to media. Retention that exists because nobody chose a value is not a retention policy.

The requirements that change your design

Beyond scoping and storage, four requirements have direct design consequences for an assistant.

  • Requirement 6.2 — bespoke and custom software must be developed securely, with review of custom code and training for developers. Prompt templates and tool definitions are software for this purpose; they decide what the model can reach.
  • Requirement 7 — access is restricted by business need to know and by least privilege. An assistant that executes tools inherits whatever the service credential can do, so the credential, not the prompt, is the access control. A prompt instruction not to reveal card numbers is not a control and will not be accepted as one.
  • Requirement 10 — audit logs must record user access to cardholder data and be protected from alteration. If the assistant retrieves a record on a customer’s behalf, that is an access event with an identity behind it, and “the service account” is not an identity.
  • Requirement 12.8 — third-party service providers with access to cardholder data are managed by written agreement, due diligence before engagement, a programme to monitor their compliance status, and a written acknowledgement of their responsibility for the security of the data. Ask your model provider for its attestation of compliance, note what happens when it has none, and keep the answer — that file is part of the evidence you will be asked for.

The architecture that keeps the model out of scope

The practical answer is the same one that has worked for a decade with call-centre systems: do not let the sensitive value reach the component you do not want to assess. Tokenise at the edge, so the assistant works with a surrogate value that has no exploitable relationship to the PAN. Give its tools an interface that returns a masked PAN and a token, never the full number. Redact on the way in as well as the way out, because customers paste card numbers into chat windows unprompted and a filter that only inspects model output will not catch it.

Segmentation still has to be demonstrated rather than claimed; Requirement 11.4.5 requires penetration testing of segmentation controls at least annually for merchants and every six months for service providers. The reward for doing this properly is that the model provider stays outside the CDE and your SAQ eligibility survives — which, for most teams, is worth considerably more than the feature that a raw PAN would have enabled. The same containment logic is what the HIPAA minimum necessary standard asks for with health information, and building it once satisfies both.