The Flight Mode Test For Enterprise AI

Yes, enterprise AI can run fully offline on premises with no internet connection, and the honest way to prove it is to disconnect the machine and keep working. Put the host in flight mode and run a real task end to end: if the system still answers, still writes to its audit record and returns the same results, it was never depending on a remote service. Anything that stalls, degrades or silently queues work was reaching outside your building all along. The machine either keeps working with the cable out or it does not, and that is a question you can settle on your own hardware.

• Flight mode is a physical test, not a policy claim. No exemptions, no allow-list, no fetch window.
• The model is rarely what breaks. Telemetry, licence checks, auto-updaters and cloud fallbacks are.
• A system that degrades quietly offline is more dangerous than one that fails loudly.
• Mickai runs a capable model on hardware the customer owns, over loopback only, with no outbound path by default.
• Deterministic engines mean the disconnected result and the connected result are the same.
• Offline is a trade: ambient external data becomes a deliberate, staged connection a person approves.

What exactly is the flight mode test?

It is deliberately physical. Take the machine that runs the system, disable every network interface (wireless off, cable out, no tethered phone), then do a full session of ordinary work on it. Draft the document. Query the private knowledge base. Run the report. Approve the action. Seal the record.

Two rules keep it honest. Nothing gets an exemption: no opening for a licence server, no window to pull a model down first. And the tasks are the ones your team actually performs, not the path a vendor picked for the demo.

What usually breaks when you pull the cable?

Almost never the model. The failures cluster in the plumbing around it. Telemetry and crash reporting block on a socket that will never open. Licence validation phones home and fails closed after a grace period you did not choose. Cloud fallbacks route the request to a hosted endpoint the moment local inference is slow or a context limit is hit.

Then come the quieter ones: fonts pulled from a content network, an identity provider needing a round trip to refresh a token, a component that fetches what it needs the first time it runs. Together they turn an offline claim into an offline aspiration. The worst outcome is not a crash but a system that keeps answering while quietly dropping a capability.

Why does on-premises not mean offline?

On-premises describes where the hardware sits. Offline describes where the data can go. They are different claims, and a great deal of enterprise software satisfies the first while quietly failing the second.

A system can run entirely on your own rack and still open outbound connections for authentication, model updates, usage analytics and support diagnostics. Collectively they are a path out of your building, and that path is what your security team and your regulator are asking about. Mickai is a sovereign intelligence operating system: a capable model runs on hardware the customer owns, over loopback only, with no outbound path by default.

Which parts of the system still need a network?

In Mickai, none by default. The model runs on hardware the customer owns and talks over loopback only, so the disconnected case is the ordinary case rather than a degraded mode. Private retrieval over the owner's own documents happens on the owner's hardware, which is why a query still returns an answer with every interface disabled.

Fourteen studios are production-ready and forty-nine are in development, sixty-three in total. Entitlement is hardware-bound and decided locally, so nothing waits on a remote lookup, and identity is issued rather than federated: each organisation holds its own signing key and ledger, with seats granting or revoking studios individually. The patent estate spans that architecture: 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, working towards examination.

How do you prove what happened during an offline run?

Watching a firewall is good evidence. A record you can verify afterwards is better. Every consequential action is sealed into the Open Audit Record, an append-only, hash-chained, tamper-evident log. Each entry carries an index, a timestamp, the actor, a typed action, the target and a SHA-256 of its payload, signed with FIPS 204 ML-DSA.

The point of that design is cold verification. Anyone can check the chain offline with the operator public key alone, so interference with the sequence is detectable to whoever verifies it. That property rests on custody of the operator signing key: whoever holds it could rewrite entries and sign them again. Signed checkpoints written off the box, together with anti-rollback, make truncation detectable as well.

Deterministic engines produce every number, so identical inputs give identical results whether the box is connected or sealed in a room.

What is the trade-off of going fully offline?

You own the change cycle. There is no silent overnight patch, which is the security property you wanted and also work: anything new on the machine is there because a person put it there, on a schedule your team sets. Capability does not shift underneath a live case.

You also give up ambient external data. If a workflow genuinely needs a market feed or a public register, that becomes a deliberate, staged and logged connection with a person approving it, rather than a standing permission nobody remembers granting. Consequential actions are staged for a human to approve or refuse anyway, so an outbound request is simply one more of them.

Frequently asked questions

Can I run the flight mode test myself?

Yes, and that is the point. Disable the interfaces, run a representative session of real work, then watch for stalls, silent quality drops and anything that starts working again once you reconnect. Add a packet capture on the host if you want the evidence in writing. No specialist tooling and no vendor cooperation are required.

Will my licence stop working if the machine never sees the internet?

It should not, and with Mickai it does not. Entitlement is bound to the hardware and decided locally, so nothing depends on a remote lookup. Any system that fails closed after a grace period is telling you the licence check is a live network dependency.

What happens to updates if the machine stays disconnected?

Nothing changes on the machine unless a person decides it should, and consequential actions are staged for a human to approve or refuse. The trade is that keeping the system current becomes your responsibility rather than a vendor's background process. Ask any supplier how a disconnected machine is meant to be maintained, and whether the answer needs an open outbound path.

What if a vendor tells me their offline mode is already certified?

Ask to run the test yourself, on their system, with your workflows and nobody smoothing the path. Certification describes a process at a point in time. Flight mode describes the machine in front of you today.

How can I try this on my own hardware?

We run a selective closed beta at mickai.co.uk/beta for organisations that want to put the test to a real deployment, with their own data and network policy. Not every applicant is accepted. If your security review starts by pulling the cable, we would like to hear from you.