Can a Bank Use AI on Customer Data Without Sending It to a Third Party?

Yes. A bank can run AI over customer data entirely inside its own perimeter, on hardware it owns, with no outbound path to any external service. This is true for one architectural reason: when inference happens locally and the network offers no egress route, the data never leaves the bank, so there is no third party in the decision path to receive it. The design has three parts: local inference on bank-owned hardware, an inbound-only perimeter that routes nothing out, and a signed record of every access.

The most widely used AI assistants are cloud-hosted, so running them over customer records sends those records to infrastructure the bank does not control. DORA has been in force since January 2025, GDPR governs every personal record, and NIS2 raises the bar on operational resilience. Each pushes banks to know exactly where regulated data goes.

How does a bank run AI without sending data out?

The AI runs where the data already lives. Mickai is a Sovereign Intelligence Operating System, a SIOS, that performs inference offline on operator-owned hardware. The models sit inside the bank's own estate. No prompt, no embedding and no record is transmitted to an external endpoint, because there is no external endpoint configured to receive one.

The perimeter is the control. A zero-egress inbound perimeter lets authorised requests reach the system while denying the system any outbound route. The absence of an outbound path is enforced at the network layer, not asserted in a policy document.

What counts as a third party in this picture?

A third party is any organisation, other than the bank and the customer, that receives, stores or processes the data. A cloud AI service is a third party, and so is the infrastructure provider beneath it. The legal weight of a third party comes from what it can be compelled to do and what it can see.

Remove the third party from the decision path and you remove the party that could be ordered to disclose, the party that could suffer a breach, and the party whose staff could view the records. The risk does not move to a contract. It stops existing in that path.

Which rules make this design the safer one?

Several duties point the same way.

• GDPR requires a lawful basis and data minimisation for every personal record processed. Records that never leave the bank have the smallest possible processing footprint.
• DORA, in force since January 2025, holds banks accountable for the resilience of their ICT arrangements, including third-party dependencies. Fewer external dependencies means fewer of those arrangements to govern.
• The US CLOUD Act lets a US-headquartered provider be compelled to produce data it holds, wherever that data sits. A data-processing agreement is a contractual promise, not a technical barrier, so it creates exposure that a local design avoids.

The EU AI Act high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. None of these rules is met by architecture alone. A local design supports the duties they impose and reduces the surface a bank has to defend.

What can an auditor actually check?

An auditor should not have to trust a description. Two tests make the claim falsifiable.

• The egress test: attempt an outbound connection from the inference host to any external address. It should fail. If a packet cannot leave, customer data cannot leave with it.
• The ledger test: pick any access to a customer record and follow its signature chain. Every action is written to a post-quantum signed audit ledger, sealed with ML-DSA, the signature standard in FIPS 204. Identity is hardware-attested and bound to that chain, so the record shows which attested device and operator acted, not merely a username.

Because the ledger signatures are verifiable offline, an auditor can confirm the chain has not been altered without contacting any vendor. The mechanisms described here sit within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD. These are patent pending, not granted.

“The strongest privacy control is not a promise that data will not leave the bank, but an architecture in which it cannot.”

How is this different from a cloud service with a data-processing agreement?

A data-processing agreement allocates liability. It does not change where the data physically goes. With a cloud AI service, the records still travel to systems the bank does not run, and the protection rests on the provider honouring its terms and resisting lawful orders. That is a promise about behaviour.

Local inference changes the physics, not the paperwork. The records stay put. Where several models must agree before an output is trusted, that cross-model consensus also runs inside the perimeter, so it is never exposed outside the bank.

What does this change under DORA third-party risk?

DORA treats critical ICT third parties as a supervised risk. When AI inference has no external provider in its decision path, there is no third-party ICT arrangement for that function to place under continuous monitoring, exit planning or concentration analysis. The duty to govern the system does not disappear; it moves inside the bank, where control already sits, removing one external point of failure.

Where does the architecture stop short of a guarantee?

Architecture supports compliance. It does not deliver it. A zero-egress design reduces the risk that customer data reaches a third party, but a bank still needs governance, a lawful basis, human oversight and its own controls to meet a regulator's test. We do not claim it satisfies any regulation on its own, and no honest vendor should. Certification such as ISO/IEC 42001 is earned by the operator, not conferred by the software.

Frequently asked questions

Can a bank use a public cloud AI assistant on customer data safely?

Public cloud AI assistants are hosted on infrastructure the bank does not control, so running them over customer records sends those records outside the bank's perimeter. A data-processing agreement can allocate liability, but it does not stop the data leaving or shield it from a lawful order to the provider. For regulated records, a local design that keeps the data inside the bank removes that exposure rather than insuring against it.

Does keeping AI on-premises satisfy GDPR?

No architecture satisfies GDPR by itself. Keeping processing local supports data minimisation, giving a smaller processing footprint. The bank still needs a lawful basis, defined retention, human oversight and the rest of its controls. On-premises design reduces risk; it does not replace governance.

How can an auditor prove the data never left?

Two checks make it falsifiable. First, attempt an outbound connection from the inference host; in a zero-egress design it should fail. Second, follow the signature chain on any customer-record access in the audit ledger, which is signed with ML-DSA under FIPS 204 and verifiable offline. Together they show both that data could not leave and that every access is recorded.

What is a zero-egress perimeter?

It is a network boundary that accepts authorised traffic inbound while denying the enclosed systems any route out. Requests can reach the AI. The AI cannot reach the internet. Because the restriction is enforced at the network layer, the guarantee does not depend on the software behaving well.

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

No. The high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat the deferral as time to build the architecture properly, not as a reason to wait.