PCI SSC highlights AI security in payment environments

On 7 October 2026, PCI SSC issued a statement on AI security in payment environments. The information supplement it links to was introduced on 15 September. The Council identifies it as guidance, with official PCI standards taking precedence in a conflict. The October statement does not create a standalone mandatory AI standard.

Risk follows the action a system is permitted to take

Compare two payment assistants. One explains an order status; the other can change acceptance settings or issue refunds. Using the same underlying model does not make the risks identical. Data access, authority and the consequences of a wrong action matter.

The substantive discussion therefore concerns the integration. Which record enters the request? Who sees the response? Can the model's output directly change a financial operation? Those questions describe a traceable path of data and actions, unlike a broad promise of secure AI.

A useful test is a customer email requesting a refund while including unrelated instructions. The system should handle the legitimate request within its authority rather than treating all external text as a command from the service owner. This is an editorial integration-test example, not a new rule quoted from the supplement.

PCI SSC says AI should be considered like other technology when determining applicable requirements. Introducing a model does not move a process outside data and access controls. Qualified specialists should assess the particular environment and scope.

The practical outcome is an ability to reconstruct events: what information the system received, which action it proposed, who authorized it and how it can be stopped if wrong. The October statement is not a new certification deadline. Its value is a reminder that autonomy in a payment tool requires an equally specific account of responsibility.

What payment teams should check

A practical starting point is an inventory of every place where models already operate near payment data: support, fraud screening, dispute handling, internal assistants for developers and analysts. Such tools often appear inside teams without separate approval, and they are the ones to surface first.

• Which AI tools receive cardholder data or access systems where that data is stored.
• Which actions a model can take on its own and which require human confirmation.
• How the service owner's instructions are separated from text that arrives from customers or external sources.
• Whether prompts, responses and executed actions are logged, and who reviews those logs.
• How the feature is switched off after a failure, and whether a manual mode exists for refunds and support.
• What contracts with model providers say about retention, processing and reuse of data.

Risks and limitations

Guidance does not replace a compliance assessment and should not be used as a ready-made audit checklist. External model services are a distinct risk: if a request containing payment data goes to a provider, the environment's boundary changes, and the contract and data path need review. These questions are best raised with a QSA or internal compliance before launch rather than after the first incident.

Sources: PCI SSC statement; PCI SSC information supplement introduction