How Payment Processors Keep AI Inside PCI DSS 4.0 Scope Without Exporting Cardholder Data

Payment processors keep AI inside PCI DSS 4.0 scope by running the model on their own hardware inside the existing cardholder data environment, so cardholder data is scored where it already lives and never leaves. Because no cardholder data is transmitted to a third party, no new service provider enters the assessment and the audit does not grow. The reason is simple: PCI DSS scope follows the data, and analytics performed in place adds no new data flow to review.

In 2026, fraud scoring and transaction analytics are moving to AI faster than assessments can absorb them. The default cloud pattern sends cardholder data to a hosted AI service, which extends the cardholder data environment to that provider, adds another party to manage, and enlarges every subsequent audit. Processors that keep the model on-premise avoid that expansion entirely, and they keep the data under laws they control.

Why does sending cardholder data to a cloud AI enlarge your PCI DSS scope?

PCI DSS scope covers every system that stores, processes or transmits cardholder data, plus every system that can affect the security of those systems. A hosted AI service that receives a primary account number processes cardholder data by definition. Under Requirement 12.8 it becomes a third-party service provider inside your scope. You must inventory it, obtain its Attestation of Compliance, hold a written responsibility matrix, and monitor its standing. The transmission itself falls under Requirement 4, which governs cardholder data crossing open networks. Every one of these adds evidence to gather and controls to test. The assessment grows in proportion to the number of parties that touch the data.

How does on-premise AI keep cardholder data inside the existing CDE?

The model runs on operator-owned hardware already inside the cardholder data environment. Cardholder data is read, scored and discarded in place. No primary account number crosses the boundary, so no new data flow is created. Because nothing is exported, no third-party service provider is added, and the AI hosts sit inside a segment you already assess. Good segmentation keeps the rest of your estate out of scope. The AI does not enlarge the boundary. It sits inside it.

We built Mickai as a Sovereign Intelligence Operating System, a SIOS that runs entirely offline on hardware the operator owns. Fraud scoring, transaction analytics and case review all happen inside the perimeter. The perimeter permits no outbound egress, so cardholder data has no route off the machine.

What can a QSA actually check to confirm no cardholder data left the CDE?

Each of the following is a checkable artefact an assessor can quote, not an assurance to take on trust:

• The data-flow diagram required under Requirement 1 shows no cardholder-data path leaving the environment toward any AI service.
• The third-party service provider inventory under Requirement 12.8.1 does not list a cloud AI provider.
• Firewall and segmentation rules under Requirement 1 block outbound connections from the AI hosts to public networks.
• The audit logs under Requirement 10 record no egress from the AI segment.
• Penetration and segmentation testing under Requirement 11 confirm the boundary holds.

Which PCI DSS 4.0 requirements make this necessary?

The pattern is consistent across the standard. Requirement 3 protects stored account data. Requirement 4 demands strong cryptography for cardholder data on open networks, and if the data never leaves, this requirement has no new flow to cover. Requirement 10 logs and monitors all access. Requirement 11 tests security regularly. Requirement 12.8 governs third-party service providers, and keeping AI in-house removes an entry there. Every requirement that scales with parties and data flows stays flat when the data stays put.

“Scope follows the data, so the safest way to keep AI inside PCI DSS 4.0 is to keep the cardholder data exactly where it already sits.”

How do you prove the AI itself did not become a new attack surface?

Keeping data in place is necessary but not sufficient, because the AI host now sits inside the environment and must meet the same controls. We bind every action to a hardware-attested identity and seal it into an append-only audit ledger. That ledger is signed with post-quantum digital signatures, FIPS 204 (ML-DSA) as the primary standard and FIPS 205 (SLH-DSA) alongside it, so the record stays verifiable even against a future quantum adversary. Decisions can be tested by cross-model consensus, so no single model's output is trusted blindly. The result is an audit trail an assessor can verify offline. The sealed-ledger and sovereign-runtime methods described here sit within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, patent pending.

How do the CLOUD Act, DORA and the EU AI Act change the calculation?

The US CLOUD Act lets US authorities compel US-headquartered providers to produce data wherever it is stored, so cardholder data held in a US cloud AI service is reachable by a foreign jurisdiction. DORA, in force since 17 January 2025, holds financial entities responsible for the resilience of their critical third parties, and a hosted AI service is one more such party. NIS2 extends security duties to essential and important entities. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. On-premise AI answers all of these at once: the data stays in your jurisdiction, under your control, inside a boundary you can evidence.

Frequently asked questions

Does running AI on-premise remove it from PCI DSS scope entirely?

No. The AI host sits inside the cardholder data environment and stays in scope, because it processes cardholder data. What it avoids is enlarging the scope. No third-party service provider is added and no new external data flow is created. The assessment stays the size it already was.

Can we use a public cloud AI service for fraud detection under PCI DSS 4.0?

You can, but sending cardholder data to a hosted service makes that provider a third-party service provider inside your scope under Requirement 12.8, and the transmission falls under Requirement 4. That enlarges the audit and places cardholder data under the provider's jurisdiction. Tokenising or stripping the data first limits the obligation, but it does not remove it.

What is the difference between hosted AI and on-premise AI for cardholder data?

A hosted AI receives cardholder data across a network, so the data leaves the cardholder data environment and a new party joins the assessment. On-premise AI runs on operator-owned hardware inside the environment, so the data never leaves and no new party is added. The controls you must evidence differ accordingly.

How does an auditor verify no cardholder data is exported to an AI service?

An auditor checks the data-flow diagrams, the third-party service provider inventory, the firewall and segmentation rules, and the audit logs. If none show cardholder data leaving toward an AI service, and segmentation testing confirms the boundary, the claim holds. These are checkable artefacts, not assurances.

Does keeping AI on-premise help with DORA and the CLOUD Act as well?

Yes. Data that never leaves your hardware is not reachable by a foreign provider under the US CLOUD Act, and it removes one critical third party from your DORA resilience obligations. The same architecture answers PCI DSS, DORA and data-residency duties together.