Can hedge funds run AI on proprietary models and trade data without leaking alpha to a cloud vendor?

Yes. A hedge fund can run advanced AI over its own models, positions and material non-public information without any of it reaching a cloud vendor, by running the AI on hardware the fund owns rather than sending data to an external service. The deciding factor is architecture, not policy. When both the models and the inference stay inside the fund's perimeter, there is no outbound path for alpha to leak, so a vendor promise not to train on your data becomes beside the point.

This matters because the assurance most cloud AI services offer, we do not train on your data, answers the wrong risk. It says nothing about a fund's trading models, signals and open positions transiting a third party's infrastructure, sitting in retained logs, or falling under foreign legal reach. In 2026, with DORA live, the real question is not whether AI helps but whether using it hands your edge to someone else's data centre.

Why does "we do not train on your data" not protect a fund's alpha?

The pledge covers one narrow use. It does not stop the data leaving. When a prompt containing an open position or a proprietary signal is sent to a cloud service, the material has already left the fund's control. It sits in transit, in memory, and often in retained logs on infrastructure the fund does not own. Model weights that encode a strategy, if fine-tuned in a vendor environment, are exposed in the same way. Alpha leaks through custody, not through training. Whoever holds the data can be compelled, breached, or simply observant.

“A vendor pledge not to train on your data protects nothing if the data still leaves your control; only keeping the models and the positions inside the fund removes the path by which alpha escapes.”

How does sovereign AI keep models and positions inside the fund?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on hardware the fund owns, inside the fund's own network. Sovereign models perform inference locally, so a proprietary trading model never leaves the building and a prompt containing an open position never crosses the boundary. The perimeter is zero egress: connections are inbound only, and the system has no outbound route to a vendor, no telemetry and no phone-home. Where one model is not enough, cross-model consensus runs several sovereign models side by side and compares their outputs, raising reliability without any external call. Every action is bound to a hardware-attested identity, so the system can prove which machine and operator did what.

What can an auditor or regulator actually check?

Sovereignty is only credible if it is verifiable. Every action in the SIOS is written to an append-only audit ledger, and each entry is sealed with a post-quantum digital signature. The signing standard is FIPS 204 (ML-DSA) as primary, with FIPS 205 (SLH-DSA) available, both secure against a future quantum computer. An auditor can take the ledger offline and verify the signatures independently, with no need to trust Mickai and no live connection. Holding only the public keys, can a third party confirm that the record is complete and unaltered? With a signed ledger, the answer is yes.

Which rules make this necessary?

Several regimes push in the same direction. DORA, in force since January 2025, holds financial entities responsible for the operational and concentration risk of their information and communication technology third parties, cloud AI included. NIS2 extends security and incident duties to essential and important entities across the supply chain. GDPR governs any personal data in the pipeline. The US CLOUD Act is the sharpest point: it can compel a US-based provider to produce data it controls, wherever in the world that data sits, precisely the exposure a fund accepts when its models run in a vendor's cloud. ISO/IEC 42001 sets an auditable standard for managing an AI system, which sovereign architecture makes far easier to satisfy.

The EU AI Act adds a timing point that is often misread. 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 the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve: funds that architect for sovereignty now meet the obligations calmly rather than retrofitting under pressure.

How does this reduce DORA third-party risk?

DORA's heaviest burden is third-party risk: register your ICT providers, assess their concentration, plan for their failure, and give regulators oversight of them. Running AI inside the fund removes the third party from that chain. There is no external AI provider to register, no concentration risk in a shared cloud tenancy, and no vendor exit plan to maintain. The signed audit ledger supplies the evidence trail supervisors ask for. Sovereignty does not only protect alpha; it shrinks the regulatory surface a fund has to manage.

What should a fund test before trusting a sovereign deployment?

Claims of sovereignty should be tested, not taken on faith. A fund can run a short set of checks:

• Cut the network. Does inference still work with the machine fully offline? It should.
• Watch the wire. With monitoring on the perimeter, is there any outbound traffic during a session? There should be none.
• Verify the ledger. Can an independent party confirm the signed audit trail using only public keys?
• Attest the identity. Is each action tied to a specific, hardware-attested machine and operator?
• Own the models. Do the model weights sit on storage the fund controls, with no fine-tuning in anyone else's environment?

A system that passes all five keeps the alpha where it belongs. This architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending.

Frequently asked questions

Is running AI on our own hardware as capable as a cloud service?

Modern sovereign models run on operator-owned hardware, and for most trading, research and document tasks a fund needs, they are capable. Where a single model is not enough, cross-model consensus compares several sovereign models to raise reliability. The trade is not capability for security. It is convenience for control.

Does "we do not train on your data" mean our data is safe with a cloud AI provider?

Not on its own. That pledge addresses only whether your inputs train the vendor's model. It does not stop your prompts, positions and signals transiting and being stored on the vendor's infrastructure, where they can be logged, breached or legally compelled. The exposure is custody, not just training.

Can a US cloud provider be forced to hand over our trading data?

Yes. The US CLOUD Act can compel a US-based provider to produce data it controls regardless of where that data is stored. A fund whose models and positions run in such a provider's cloud accepts that reach. Running the AI on the fund's own hardware removes the provider, and with it the point of compulsion.

What is the current EU AI Act deadline for high-risk AI?

The high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027. Embedded high-risk systems under Annex I move to 2 August 2028, while the Article 50 transparency duties are largely unchanged. We treat this as a window to build sovereign, auditable systems before the duties bite.

How does sovereign AI help with DORA compliance?

DORA makes financial entities responsible for their ICT third parties, cloud AI included. Running AI inside the fund removes that third party: there is no external provider to register, no shared-tenancy concentration risk, and no vendor exit plan to maintain. A post-quantum signed audit ledger gives supervisors a verifiable evidence trail.