Compute to Data: Send the Model, Not the Records

Run the model where the records already are. Moving sensitive records to a vendor cloud creates copies, transfers and jurisdiction questions that no contract fully closes, while moving a capable model onto hardware the organisation owns creates none of them. Mickai runs on the customer's own machines, over loopback only, with no outbound path by default, and private retrieval over the owner's own documents happens on that same hardware. Because nothing is transferred, residency becomes a question about where a machine sits.

• Records that never move cannot be intercepted in transit or compelled from a supplier.
• A capable model runs on hardware the organisation owns, over loopback only, with no outbound path by default.
• Private retrieval over the owner's own documents runs on the owner's hardware, inside the same boundary as the files.
• Identity is issued rather than federated, and seats grant or revoke studios individually.
• Consequential actions are staged for a person to approve or refuse, then sealed into the Open Audit Record.
• Residency becomes a question of geography and hardware rather than a question of contract.

Why does moving records to a model create the problem?

Every hosted arrangement begins with a copy. A document leaves the system that owns it, crosses a network, lands in someone else's storage, and is processed and cached there. From that point two authoritative versions of the same material sit under two different sets of rules. A contract can say the copy was deleted. The copy still existed.

Each consequence stacks. A transfer puts a copy within reach of another jurisdiction, and which rules then apply turns on the parties, the contract and where the business is established. Caching creates lifetime, because nobody outside the supplier can say how long a fragment survives in a log, a queue or a backup. Sub-processing creates a chain of custody you did not choose. None of this is caused by the AI. It is caused by the direction of travel.

What does compute to data look like in practice?

The model is installed inside the same network boundary as the data it reads, on hardware the organisation owns. Inference is served over loopback, so the interface and the engine speak to each other on the machine itself. There is no outbound path by default, so a prompt or a document fragment has no route out.

Someone opens a studio and asks a question of a contract set or a case file. The difference sits underneath: local files, local retrieval, local engine. Nothing is uploaded, because with no outbound path enabled by default there is nowhere to upload to.

Where does retrieval over your own documents happen?

Any useful answer has to reach the material itself, and whatever is derived from that material carries the sensitivity of the material. That is the question to put to any supplier. What gets derived from your documents, where does it live, how long does it survive, and who else can reach it? If the derived working material sits with a supplier, the sensitive content effectively sits there too.

So the reading happens where the files are. Private retrieval over the owner's own documents runs on the owner's hardware, inside the same network boundary as the source, with no outbound path by default. Fifty registered brains, twenty-five domain and twenty-five operational, keep knowledge in named, separable bodies rather than one undifferentiated pool.

How do you control which people can use which studios?

Identity is issued, not federated. Each organisation holds its own signing key and its own ledger, so the people who can use the system are the people that organisation admitted, with no third-party directory in the path. Licences bind to hardware, so an entitlement sits with a specific machine.

Seats grant or revoke studios individually, so a team that needs one studio is given that studio and nothing else, and access can be withdrawn the same way. Consequential actions are then staged for a person to approve or refuse before anything takes effect, and each one is sealed into the Open Audit Record.

Does running the model on site actually change data residency?

A residency clause describes an intention. It states where a supplier undertakes to keep your data and which sub-processors are permitted. That is useful, and it remains a promise about infrastructure you do not control.

When the model runs on your machine in your building, residency is answered by pointing at the machine. There is no transfer to authorise and no sub-processor to disclose. Keeping the records in place does not settle every legal question by itself, and it does remove the transfer that raises most of them.

How do you prove to an auditor that nothing left?

An assertion is worth little on its own. Every consequential action is written 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, and the record is signed with FIPS 204 ML-DSA, the post-quantum signature standard. Alteration is detectable to anyone who runs the verification.

Verification is cold and offline: an auditor needs the record and the operator public key, and no call to us. Signed checkpoints written off the box, together with anti-rollback, make truncation detectable. That detection rests on custody of the operator signing key, because whoever holds that key could rewrite entries and re-sign them. Deterministic engines produce every figure, so identical inputs give identical results.

Frequently asked questions

Can I use AI on data that is not allowed to leave my premises?

That constraint is the starting assumption of the design, not an exception to it. The model, the private retrieval over those documents and the audit record all sit inside the customer boundary, and with no outbound path enabled by default the data has no route off site.

Does keeping everything local mean settling for a weaker model?

Capability follows the model and the hardware it runs on, not the postcode of a data centre. A capable model runs on hardware the customer owns, sized to the work. It also holds an advantage a hosted service does not: direct access to the organisation's own material, on the organisation's own hardware.

What happens to my prompts and documents after a session ends?

They stay where they were. Prompts are processed locally and documents are read from local storage, and with no outbound path enabled by default there is no route into an external queue, cache or training pipeline. What persists sits on the organisation's own disks, the Open Audit Record included, under its own control.

How is this different from a private cloud or a dedicated tenancy?

A dedicated tenancy is still someone else's estate. The records are transferred, the operator keeps administrative reach, and residency stays a matter of contract. Compute to data removes the transfer itself, which retires the question rather than mitigating it.

Can I start with one department before committing the whole organisation?

Yes, and that is usually the sensible route. Studios are entitled individually per seat, so one team can work in one studio while the rest of the estate carries on unchanged. Fourteen studios are production-ready today, with forty-nine more in development. Organisations that want to try this on their own hardware can apply to the selective closed beta at mickai.co.uk/beta.