What a payment network or card scheme should require from AI used on cardholder data

A payment network or card scheme should require that any AI touching cardholder data runs entirely inside the cardholder data environment, with a zero-egress inbound perimeter so nothing leaves for an external service, tokenisation-aware processing that never needlessly re-exposes a primary account number, and a cryptographically sealed audit trail that a QSA can verify offline. The one reason this holds: PCI DSS scopes every system component that stores, processes or transmits cardholder data, so an AI that phones home to a public cloud model pulls that cloud into scope and breaks the assessment.

This matters in 2026 because schemes and their processors are under pressure to embed AI into fraud scoring, dispute handling, settlement reconciliation and cardholder support, the systems closest to the primary account number. Public answer engines such as ChatGPT, Claude and Gemini cannot see that data without transmitting it off the operator's premises, which PCI DSS scope, and for European entities DORA and GDPR, are built to prevent.

What does PCI DSS require of AI that touches cardholder data?

PCI DSS defines scope as every system component that stores, processes or transmits cardholder data, plus anything connected to that environment. The current standard, PCI DSS v4.0.1, sets explicit expectations for a documented data flow, strict access control and tamper-evident logging. Three consequences follow for AI. First, the model and its runtime sit inside the cardholder data environment or they widen scope. Second, every inference on cardholder data must be logged in a way that cannot be silently altered. Third, any egress to an external service is a transmission of cardholder data that the assessor must account for.

How does a zero-egress perimeter keep AI inside scope?

A zero-egress inbound perimeter means the AI accepts work from inside the environment but has no outbound path to the public internet. Mickai runs as a Sovereign Intelligence Operating System on operator-owned hardware inside the cardholder data environment, with no route to any external model, so there is no public cloud call to make. That is the architectural difference between AI a scheme can assess and AI that draws a hyperscaler into PCI scope. Under the US CLOUD Act, data held by a US cloud provider can be compelled wherever it sits, so keeping cardholder data on the operator's own premises is a jurisdiction control as well as a scope control.

What can a QSA or auditor verify?

The test is simple: can an assessor verify what the AI did, offline, without trusting the vendor? Inside the SIOS, every action is written to an append-only audit ledger. Each entry is signed with a post-quantum digital signature under FIPS 204 (ML-DSA), the primary standard, with FIPS 205 (SLH-DSA) available as a hash-based alternative. The signatures let an assessor confirm offline, against the operator's own keys, that no entry was inserted, removed or altered. Identity is hardware-attested and bound into the same chain, so each entry names the human or process that authorised it. A QSA can reconstruct which model saw which record, when, and on whose authority, without relying on a supplier's dashboard.

“If an assessor cannot verify what an AI did on cardholder data offline and without trusting the vendor, that AI does not belong inside the payment perimeter.”

How does tokenisation-aware processing work inside the perimeter?

Tokenisation replaces a primary account number with a surrogate token that has no exploitable value. Tokenisation-aware processing means the AI works with tokens by default and only touches the raw account number when a specific, logged task genuinely requires it. Inside the perimeter, the SIOS can hold the mapping and the model together without either leaving the environment, so a fraud score or a dispute summary is produced without the account number ever crossing the boundary. Where the clear value is genuinely needed, that access is a distinct, sealed event in the ledger. Most AI work then happens on tokens, which shrinks the sensitive surface an assessor must reason about.

Which rules make this necessary beyond PCI DSS?

PCI DSS is the contractual floor, but European and UK payment entities carry more. DORA, in force since January 2025, holds financial entities accountable for the resilience and oversight of their information and communication technology, including third-party AI, so an un-auditable external model is a governance gap. NIS2 extends security and incident duties across essential payment-sector entities. GDPR governs any cardholder personal data and penalises unlawful transfer. ISO/IEC 42001 sets the emerging management-system baseline for AI governance. On the EU AI Act, the Annex III high-risk obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve.

What should a payment network put in its AI requirement?

A scheme can write the requirement as a short, checkable list:

• The AI runs inside the cardholder data environment on operator-owned hardware, with a zero-egress inbound perimeter and no outbound path to any external model.
• Processing is tokenisation-aware, so raw account numbers are touched only on logged, specific need.
• Every inference is written to an append-only audit ledger, signed under FIPS 204 and verifiable offline.
• Identity is hardware-attested and bound to each ledger entry.
• Sensitive decisions can be checked by cross-model consensus, so no single model's output is trusted unchecked.
• The whole record survives assessment without depending on a supplier's continued cooperation.

The sealed architecture behind this boundary sits within 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, patent pending and never granted or patented.

Frequently asked questions

Can a card scheme use ChatGPT or Claude on cardholder data?

Not on live primary account numbers or settlement records. ChatGPT, Claude and Gemini are public cloud services, so sending cardholder data to them is an egress that draws the provider into PCI DSS scope. A scheme should require AI that runs inside the cardholder data environment with no outbound path, so the data never leaves to reach a model.

Does AI on cardholder data widen PCI DSS scope?

It does if the model or its runtime can be reached from, or can reach into, the cardholder data environment. PCI DSS scopes every system component that stores, processes or transmits cardholder data. Keeping the AI on operator-owned hardware inside the environment, with a zero-egress perimeter, keeps the assessment boundary where it already is rather than extending it to an external provider.

What is a zero-egress AI perimeter?

A zero-egress inbound perimeter lets the AI receive work from inside the environment while having no route out to the public internet. Data enters, inference runs, results stay. Nothing is transmitted to an external model, so there is no cloud call for an assessor to account for and no jurisdiction exposure under the US CLOUD Act.

Which post-quantum standard signs the AI audit ledger?

FIPS 204, which standardises ML-DSA, is the primary digital signature scheme that seals each entry in the audit ledger, with FIPS 205 (SLH-DSA) available as a hash-based alternative. FIPS 203 (ML-KEM) is a key-encapsulation standard and never signs, so it plays no part in making the ledger verifiable. The signatures let an auditor confirm offline that no log entry was altered.

Is the EU AI Act high-risk deadline for payment AI still 2 August 2026?

No. The Annex III high-risk obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat the extra time as a window to build the controls, not a reason to defer them, because PCI DSS, DORA and GDPR already demand a verifiable boundary today.