DEV Community: Micky Irons

Your Product, Our Substrate

Micky Irons — Fri, 04 Sep 2026 16:41:51 +0000

There is a specific way a good software company loses a deal it should have won. The product is right, the demonstration goes well, the buyer wants it, and then the security questionnaire asks where the AI inference happens. The answer is a cloud API, the buyer is a bank, a hospital trust or a defence supplier, and the deal quietly stops progressing.

The problem is not the product

This is worth separating carefully, because the instinct is to assume the product needs more features. It usually does not. What has happened is that a dependency the vendor treated as an implementation detail has become the buyer's primary objection, and it sits at a layer the vendor did not think they were selling.

The vendor is now caught between three bad answers. Strip the AI features out and lose the differentiation they were built for. Tell the customer the data is fine in the cloud, which is a legal argument the vendor is not qualified to win and does not want to own. Or build their own inference stack, which means becoming an infrastructure company in order to keep being an application company.

The fourth answer

The fourth is to license the substrate. The product stays the vendor's: their interface, their workflow, their brand, their roadmap, their customer relationship. What changes is what sits underneath the AI features. Instead of an outbound call to a shared cloud endpoint, the inference runs on a sovereign runtime deployed inside the customer's own estate, grounded on that customer's own records.

From the end customer's point of view, the questionnaire answer changes from a paragraph of assurances to a demonstration: disconnect the network and the product still works. That is a materially different conversation, and it is usually a shorter one.

A vendor should not have to become an infrastructure company in order to keep being an application company.

What the substrate has to do to be worth licensing

Not every arrangement described as an on-premise option actually solves the vendor's problem. Some simply move the operational burden onto the vendor and call it sovereignty. The useful test is whether these are true.

The inference runs on the customer's hardware with no call home, and that can be demonstrated with the network physically disconnected.
Entitlement is bound to the customer's hardware, so licensing is enforced without a phone-home check that reintroduces the dependency.
The audit record is inherited rather than implemented, so every consequential action the product takes is already hash chained, signed and checkable off box.
Permissioning and sensitivity tiering exist below the product, so the vendor is not asked to invent a governance model for someone else's regulated data.
The vendor keeps their own product surface. If the substrate imposes its interface on the customer, the vendor has not licensed infrastructure, they have become a reseller.

Where the line sits commercially

The arrangement only works if the boundary is explicit at the start rather than discovered during renewal. The workable split is that the vendor owns their product and their customer relationship, the substrate remains Mickai intellectual property and is licensed, and the knowledge layer built from the end customer's data belongs to that end customer. Three parties, three clear holdings, written down before the first deployment.

The alternative, leaving it implicit, produces the argument every OEM relationship eventually has: who owns the improvement, who owns the data, and who the end customer belongs to. It is cheaper to answer those in a contract than in a dispute.

The honest limits

This is not free of work for the vendor. Their product has to be able to run where the customer's estate is, which for a pure cloud application is a real engineering change rather than a configuration flag. Support becomes a shared responsibility with a boundary that has to be agreed. And a sovereign deployment has a capital cost that a per-seat cloud product does not, which changes the vendor's pricing conversation as well as their architecture.

What it removes is the largest item: the vendor no longer has to build, secure, certify and maintain an inference substrate to sell into regulated markets. That was never the product they wanted to build. It was the toll on the road to the customers they wanted to reach.

Originally published at mickai.co.uk.

What You Actually Own When You Commission An AI System

Micky Irons — Fri, 04 Sep 2026 16:40:29 +0000

When an organisation commissions a bespoke AI system, the contract usually specifies who owns the code. That is one of at least six things that change hands, and it is rarely the one that determines whether the organisation is genuinely independent at the end.

The six, named

Each of these has an owner whether or not anyone wrote it down. Where it is not written down, the default tends to favour the supplier, not because of bad faith but because the supplier is the party holding the artefact.

1. The application

The software built to the specification. This is the part contracts handle well and the part that matters least in isolation, because an application without the layer beneath it is not independently operable.

2. The model

Whatever performs the inference. If it is an external API, nobody in the room owns it and the commercial terms can change under both parties. If it runs locally, the question becomes whether the organisation may continue running it if the relationship ends, and on what terms.

3. The tuned knowledge

The most commonly overlooked item. When a system is grounded on an organisation's records, indexes, embeddings and retrieval structures, that derived layer encodes the organisation's own knowledge in a form it did not previously possess. It is genuinely valuable and frequently unaddressed, and the organisation should hold it.

4. The training and grounding data

The source records were the organisation's to begin with, which makes ownership feel settled. The live questions are different: was any of it copied outside the perimeter during development, does the supplier retain a copy for support or improvement, and what obligations survive termination.

5. The audit trail

The record of what the system did. Under most regimes this is the organisation's evidence and its retention obligation, so it needs to be held by the organisation and verifiable without the supplier's participation. An audit trail only the vendor can interpret is not evidence, it is a dependency.

6. The right to leave

Not an asset, but it behaves like one. If continuing to operate requires a licence that can be withdrawn, a key that must be renewed by a third party, or an endpoint that can be switched off, then whatever the other five clauses say, the organisation is a tenant.

Where the line should sit

Suppliers who build on their own platform have a legitimate interest in keeping the platform. The workable split is not complicated, and stating it plainly at the outset removes most of the friction later: the organisation owns the system built for it and the knowledge layer built on its data, while the underlying platform and its intellectual property remain the supplier's and are licensed to the organisation.

What makes that split acceptable rather than merely tidy is what the licence permits. A licence that allows continued operation on the organisation's own hardware, offline, without a call home, is materially different from one that requires periodic contact with a vendor server. The first is ownership with a supplier attached. The second is a subscription wearing a bespoke coat.

If the system stops working when the supplier does, the organisation did not commission a system. It rented one with extra steps.

Questions worth asking before signing

These are unglamorous and they are answered quickly by a supplier who has thought about them. Hesitation on any of them is itself informative.

If we end this relationship, what specifically stops working, and on what timescale?
Who holds the indexes and embeddings built on our records, and can we export them in a usable form?
Does any of our data leave our infrastructure at any point, including during development and support?
Can we verify the audit record without your participation, and can you demonstrate that today?
Does the system require network contact with you to keep running, and what happens if that contact is refused?
What survives termination: which licences, which obligations, which copies?

Why this is worth doing early

None of these questions is difficult at the scoping stage and all of them are difficult eighteen months in, when the system is load bearing and the answers have consequences. The organisations that end up genuinely independent are not the ones that negotiated hardest. They are the ones that named all six items before the work started, while both parties could still choose a different arrangement without anything breaking.

Originally published at mickai.co.uk.

The Build You Do Not Have To Do

Micky Irons — Fri, 04 Sep 2026 16:39:18 +0000

Ask a team what it will take to build an AI system that runs inside a regulated customer's estate, and the estimate usually covers the application. The application is rarely the expensive part. The expensive part is everything that has to exist before the application can be written, and it is almost always discovered rather than planned.

The inventory

Here is what a team building this from nothing has to produce before the first feature of their actual product. None of it is optional in a regulated deployment, and none of it is what the team set out to build.

An inference runtime that runs where the customer is

Not an API client. Something that loads and serves models on hardware the team does not control, with predictable resource behaviour, on machines that vary between customers. This includes the unglamorous parts: model packaging, memory management, graceful degradation on smaller hardware, and behaving sensibly when the estate is smaller than the sales conversation implied.

A knowledge layer over the customer's records

Ingestion across formats nobody standardised, indexing, retrieval that returns the right passage rather than a plausible one, and a re-index path for when the customer's data changes, which is continuously. Then the harder half: making retrieval respect permissions, so the system cannot surface a record to someone who should not see it.

Permissioning and sensitivity tiering

Native to the data layer rather than checked at the interface. If permissioning lives in the application, then every new application re-implements it, and one mistake exposes records the organisation is legally obliged to protect. This is the item most often deferred and most expensive to retro fit.

An audit record that is worth producing

Not logging. A record that a regulator or an auditor will accept: hash chained so alteration is detectable, signed so authorship is provable, with a checkpoint held somewhere the machine cannot rewrite, and verifiable by someone who does not trust the vendor. Building this properly is a specialist cryptographic exercise, and building it improperly is worse than not claiming it.

Entitlement and licensing that survive the air gap

A way to know the software is being used within terms, on a machine with no outbound connection. Every naive answer to this either fails open, which the finance team will not accept, or calls home, which the customer will not accept.

An update path

Shipping a fix to software running inside estates the team cannot reach, without breaking the audit chain, without requiring the customer's network to open, and while supporting more than one version in the field. This is the item teams forget entirely until the first serious bug.

What the inventory actually costs

The honest figure is not a number, it is a shape. Each item above is a small team and a long tail of maintenance, and crucially each one is a place where a mistake is discovered by a customer's security review rather than by a test. The cost is not only the build; it is that the team's attention is spent on infrastructure for the period in which they were supposed to be establishing a product.

The question is not whether the team could build it. It is whether the eighteen months spent building it are the eighteen months the company has.

The adoptable half

The reason to draw the inventory out explicitly is that all six items are generic. None of them is specific to the organisation, none of them is where the product's value sits, and all of them have already been built by anyone operating in this category properly. They are exactly the layer that should be adopted rather than rebuilt.

What is not adoptable is the part above the line: the process specific to the organisation, the judgement encoded into it, the interface the users actually touch. That part cannot be bought from anyone, which is precisely why it deserves the whole of the team's attention.

How to use the list

Take it into the next build-or-adopt conversation and price each of the six honestly, including the maintenance tail and the cost of getting the audit record wrong. Then compare that against the cost of licensing a substrate where all six already exist and are inherited by whatever is built on top. The comparison is usually not close, and it is far more useful than a debate about model quality, which is the argument these conversations tend to have instead.

Originally published at mickai.co.uk.

Putting A Model Inside Someone Else's Product

Micky Irons — Fri, 04 Sep 2026 16:39:07 +0000

When a company asks whether their software can be powered by someone else's models running on someone else's substrate, the conversation usually starts with capability. That is the least interesting part. The questions that determine whether the arrangement is still working in two years are unglamorous, and they are worth putting on the table in the first meeting rather than the fourth.

Whose version is it

A product ships on a release cycle. A substrate improves on its own. If those two are coupled, every substrate improvement becomes a regression risk in someone else's product, and every product release becomes a negotiation.

The workable answer is that the vendor pins a substrate version, tests against it, and moves when they choose. That means the substrate has to support more than one live version in the field at once, which is a commitment made at the architecture level rather than promised in a meeting. Ask to see how an existing deployment is pinned before believing it.

What happens when it is wrong

Every model is wrong sometimes. The question is what the surrounding system does about it, because that is what the end customer experiences and what the vendor gets the support call about.

Does a low-confidence answer degrade visibly, or does it return something confident and wrong?
Is there a path that stages the action for a person instead of executing it, and is that the default rather than an option?
When the system declines to answer, does the product have somewhere sensible to put that, or does it surface as an error?
Can the vendor reproduce a specific past answer months later, from the record, without the substrate supplier's help?

The last one matters more than it sounds. If reproducing an answer requires the supplier, then every serious end-customer complaint becomes a three-party investigation, and the vendor has lost control of their own support process.

Entitlement without a phone home

Licensing an embedded substrate has an obvious tension. The supplier needs to know it is being used within terms. The end customer bought the deployment precisely so that nothing leaves their estate. A licence check that calls out reintroduces the dependency the arrangement existed to remove.

Binding entitlement to the customer's hardware resolves it: the licence is enforceable locally, verifiable at audit, and requires no outbound connection. It is a small design decision that decides whether the sovereignty claim survives contact with the commercial terms.

A sovereignty claim that a licence check can break was never a sovereignty claim. It was a deployment preference.

Audit inheritance

If the substrate carries a tamper evident record, everything built on it should inherit that automatically rather than each product implementing its own logging and hoping it satisfies a regulator. Inheritance is the difference between the vendor being able to say the product is auditable and the vendor having to build an audit feature.

It also changes what the vendor can sell. An application that can produce a signed, offline-verifiable record of what it did is a different proposition to one that produces a log file, and the vendor did not have to build the difference.

The support boundary

Draw it explicitly and draw it early. The vendor supports their product. The substrate supplier supports the substrate. The hard cases are the ones that look like both, and the only workable arrangement is a named escalation path with a response commitment on each side, agreed before the first joint customer rather than during the first joint incident.

Why any of this is affordable

The reason a vendor can consider this at all is that the substrate is finished rather than notional. The sovereign operating system, the inference runtime, the orchestration, the permissioning and the audit record already exist and already carry fourteen production ready studios, with a further forty nine in development on the same platform. The vendor is adopting something load bearing rather than co-developing a foundation, and the mechanisms underneath sit behind 104 filed UK patent applications carrying 2,340 claims.

None of that removes the five questions above. It just means they are the only questions left, which is a considerably better position than the one that starts with building an inference stack.

Originally published at mickai.co.uk.

Monitoring Machines Without Sending The Readings Away

Micky Irons — Fri, 04 Sep 2026 16:38:47 +0000

An organisation running an estate of instruments or machinery usually has more monitoring data than it can read and fewer options for what to do with it than it expects. The obvious answer, stream the telemetry to a cloud service that watches for abnormalities, runs into a problem that has nothing to do with the quality of the detection: the readings themselves are often not free to send.

Telemetry is more sensitive than it looks

Operational readings are treated as boring because they are numerical, and that intuition is usually wrong. A sequence of measurements from an instrument estate can disclose a great deal.

Utilisation, which is commercially sensitive when a competitor can infer capacity, throughput or margin from it.
Fault and failure history, which frequently sits under warranty, service or maintenance contract terms that restrict disclosure to third parties.
Location, movement and duty cycle, which in defence, energy and transport contexts is operationally sensitive on its own.
Indirect subject data, where the pattern of usage maps to identifiable individuals even though no identifier appears in the feed.
Configuration and calibration, which reveals how a regulated process is actually run rather than how it is documented.

None of that is exotic. It is why procurement teams in regulated sectors ask where monitoring data will be processed long before they ask how accurate the detection is, and why an otherwise strong monitoring proposal can fail on a question the engineering team considered secondary.

Detection is the easy half

Finding an anomaly in a signal is a well understood problem with a deep literature and a great many workable methods. The hard part in an operational setting is not detection. It is what happens in the twenty minutes after the flag.

Somebody has to decide whether to intervene. That person needs to know what the system saw, what it compared the reading against, whether the same pattern has appeared before, and what happened last time. A flag without that context is an interruption rather than information, and an estate that produces interruptions gets its alerting turned down until it produces nothing at all. Most monitoring deployments do not fail loudly. They fail by being quietly ignored.

A system that flags an exception without showing its evidence has moved the work rather than done it.

Evidence changes the architecture

Requiring the evidence alongside the flag is not a reporting feature bolted on at the end. It constrains the design from the beginning, because the system has to retain what it compared against, record the reasoning at the moment of the decision, and be able to reproduce that later without the underlying data having moved or changed.

This is where the sovereign architecture earns its place rather than merely satisfying a procurement question. If the readings stay on the organisation's own hardware, the history the system reasons over is complete and locally held. If every consequential action is written to a tamper evident record, the reasoning behind a flag can be produced months later for a regulator, an insurer or a counterparty, and can be checked without asking the vendor to vouch for it.

The offline test

For estates in genuinely constrained environments, isolated operational technology, secure facilities, remote sites with intermittent connectivity, there is a simple test worth applying to any monitoring proposal. Disconnect the network and see what still works.

A system that depends on a cloud endpoint stops detecting, or worse, silently queues and then floods when the link returns. A system designed to run offline continues to watch, continues to record, and can still verify its own audit trail with the cable out. That is not a resilience feature. It is a statement about where the intelligence actually lives.

What a build like this involves

The engineering is not mysterious, but the sequence matters, and it starts further back than teams expect.

Establish what normal looks like from the organisation's own history, rather than importing a generic baseline that will misfire on this estate.
Agree what counts as an exception with the people who will act on it, before building the detector, so the threshold is an operational decision rather than a statistical one.
Build the evidence path at the same time as the detection path, because retro fitting it means retaining data that was already discarded.
Run supervised alongside the existing process, with a person clearing every consequential action, until the exception rate and the false positive rate are both understood.
Only then decide what, if anything, is allowed to act without a person in the loop.

A necessary limit

Where a monitoring system's intended use falls under a device, clinical or safety regime, the classification and its approvals sit with the operator. Building a capable system and holding a regulatory clearance are different things, and a supplier that blurs them is not one to commission. The honest position is that the engineering can be built and evidenced now, and the regulatory pathway is the operator's to run, with the supplier supporting the evidence rather than claiming the clearance.

The general principle holds across sectors. Watch the estate, flag the exception, show the evidence, and keep all three inside the building. Most of the difficulty is in the third and fourth of those, which is exactly why they are worth specifying before anyone starts building.

Originally published at mickai.co.uk.

Buy The Platform, Build The Application

Micky Irons — Fri, 04 Sep 2026 16:38:37 +0000

If an organisation needs an AI system that does something specific to it, the decision that determines the outcome is made before any code is written: whether the team is building an application or building a platform. Almost every bespoke AI project that disappoints has quietly signed up for the second while budgeting for the first.

The three options, and why each disappoints

An organisation with a process worth automating has three conventional routes, and each fails in a way that is predictable enough to plan around.

The first is to buy a cloud product and bend the process to fit it. This works, genuinely, for the work organisations have in common. Payroll is payroll. Where it fails is precisely where the value sits, in the process that is specific to that organisation, because the product was built for the average of its market and the organisation is not average. The second cost is structural: the data leaves the building on every query, which for a regulated operation converts an engineering decision into a compliance one.

The second is to commission a systems integrator. The application gets built to specification, which solves the fit problem. What the integrator cannot supply is the layer underneath. The model comes from somewhere, usually a hyperscaler API. Governance is assembled per project. The audit trail is whatever logging the team had time for. So the organisation ends with a bespoke application sitting on someone else's substrate, and the sovereignty question it was trying to answer is exactly where it started.

The third is to build in house. This is the most honest of the three and the most expensive, because before writing a line of the thing that was actually wanted, the team is hiring machine learning engineers, choosing an inference runtime, designing a permissioning model, and arguing about how to log decisions defensibly. Eighteen months later there is an impressive platform and a thin application on top of it. The platform was never the point.

The line in the wrong place

What all three share is that the boundary between platform and application has been drawn in the wrong place, or not drawn at all. In mature software categories nobody argues about this. A bank building a trading interface does not first write an operating system. The operating system, the database and the network stack are settled, and the engineering effort goes into the part that is specific to the bank.

Enterprise AI has not reached that settlement yet. Most organisations attempting a bespoke system are still assembling the substrate as part of the project, which is why the projects cost what they cost and take as long as they take.

The bespoke part should be your application. If it is also your infrastructure, you are not commissioning a system, you are funding a platform business.

What has to be true for the substrate to count as finished

Not every stack that calls itself a platform removes the problem. A useful test is whether the following are already built, already running, and inherited by anything constructed on top, rather than being decisions the project still has to make.

An inference runtime that executes on hardware the organisation controls, so the deployment question is settled before the application exists.
A private knowledge layer, built on the organisation's own records, so the system reasons about that organisation rather than about the internet's average of it.
A permissioning and sensitivity model that is native rather than retro fitted, so a new application inherits governance instead of requesting it.
An audit record that captures consequential actions and can be verified by someone outside the vendor relationship.
A working application layer above it, proving the substrate carries real software rather than a demonstration.

That last one matters more than it looks. A platform with no applications on it is a hypothesis. Mickai runs fourteen production ready studios on the sovereign operating system with a further forty nine in development, and that is the evidence that the substrate carries weight. A bespoke build is then the same exercise the studios already went through, aimed at one organisation's problem instead of a common one.

What changes in the economics

When the substrate is finished, the shape of a bespoke engagement changes. The expensive, uncertain, long-duration work has been done and amortised across everyone using the platform. What remains is the part that could never have been bought anyway: understanding the process, specifying it, building against a stable interface, and proving it works.

It also changes what the organisation is left holding. In the integrator model the deliverable is an application with dependencies the organisation does not control, so the maintenance question begins on day one. When the platform is a licensed, sovereign product that continues to develop, the bespoke application inherits improvements to the substrate without being rebuilt for them.

The question to ask a vendor

There is a single question that separates the two models, and it is worth asking early, because the answer determines everything downstream.

If you disappeared tomorrow, what stops working, and how would I know?

A vendor building on someone else's cloud cannot answer that well, because the honest answer involves a third party neither of you controls. A vendor supplying a sovereign platform can answer it precisely: the system runs on your hardware, the audit record verifies without contacting us, and you can test both by unplugging the network. That test takes an afternoon and tells you more than any architecture diagram.

Where this does not apply

Bespoke is the wrong answer more often than it is the right one. If the requirement is genuinely common, a catalogue product will be faster, cheaper and better supported, and any vendor worth commissioning will say so before taking the work rather than after. The case for building is narrow: a process specific enough that no product models it properly, combined with a constraint on where the data may sit that rules out the cloud options. Where both hold, the only remaining question is whether you are building the application or the platform underneath it.

Originally published at mickai.co.uk.

An AI audit record you can verify with the network unplugged, and where it stops

Micky Irons — Thu, 03 Sep 2026 18:11:29 +0000

I have spent a long time building the least glamorous part of an AI system: the record of what it did.

While most of the attention went to wrapping models, I was working on the thing every regulated buyer eventually asks for and almost no stack can produce. Not "is the model clever enough". That question is nearly always answered. The one that kills deployments is this:

Show me what the system did, on whose authority, over which documents, and prove that record has not been edited since.

I have watched pilots die on that question. Not on capability. On evidence.

Here is how we built the answer, and where its limits actually are.

The order matters more than the components

The instinct is to build the AI product, then bolt governance on. That order cannot work, because the evidence layer determines what the rest of the system is even allowed to do. If the model can already reach the network and act on its own initiative, no amount of downstream logging turns that into an auditable system. You are writing a description of events after the fact and asking people to trust the describer.

So we inverted it. The evidence and governance layer came first, and the model was placed inside it.

Practically, that means:

A capable model runs on hardware the customer owns, over loopback only.
No outbound network path is enabled by default.
Consequential actions are not executed on the model's own initiative.

That last point is the one engineers tend to argue with, so let me be specific about it.

Staged actions, and refusals as first-class events

A consequential action is staged. It is proposed, held, and presented to a named person who approves or refuses it. Nothing happens until that decision exists.

The part people miss: a refusal is recorded as a first-class event, not discarded. If you throw away refusals, your audit trail quietly becomes a record of things that succeeded, which is a very different and much less useful artefact. When an auditor asks "did this system ever try to do X", a log of successes cannot answer. A log that includes what was proposed and declined can.

The record itself

Every consequential action is sealed into an append-only, hash-chained record. Each entry carries:

its position in a total order
a timestamp
the acting identity
a typed action
the target
a SHA-256 digest of the payload

Each entry commits to the hash of the entry before it. The chain is signed using FIPS 204 ML-DSA, the post-quantum digital signature standard.

The property that follows: alter one field anywhere in that history and the hashes stop lining up and the signature stops verifying. You cannot quietly edit entry 400 of 900 and leave the rest intact, because 401 committed to what 400 used to be.

Verification needs only the record and the operator public key. No API call. No vendor dashboard. No network. An auditor can sit in a room with the machine disconnected from everything and satisfy themselves about what happened.

Where this actually stops, said plainly

I would rather describe this accurately than oversell it, because the overselling is what gets found out in a technical review.

The record is tamper-evident, not tamper-proof. Nothing about a hash chain prevents someone with sufficient access from destroying the whole thing, or from writing a new valid chain from scratch. What it does is make alteration of history detectable rather than deniable.

And that property rests on one assumption: the operator keeps custody of the signing key. If the key is compromised, an attacker can forge a chain that verifies. Post-quantum signatures do not change that. Any system claiming that its audit log "cannot be altered" is either being loose with language or has not thought about key custody.

That is the honest boundary. Inside it, the guarantee is genuinely useful.

Identity is issued, not federated

Each organisation holds its own signing key and its own ledger. Entitlements are issued locally, and seats grant or revoke capabilities individually.

The consequence is architectural rather than cosmetic: no supplier sits in the trust path for identity, entitlement or the audit record. Verification does not require anything from us. That is deliberate, because a trust path that runs through the vendor is exactly what a sovereignty requirement is trying to eliminate.

What is actually shipping

Being concrete about state, because vapour is easy to write:

Mickai ships as an operating system with a studio for each area of work. Sixty-three are specified. Fourteen are production-ready today, forty-nine are in development. They run on fifty registered knowledge bases that retrieve over material the customer holds, without that material leaving the estate.

On the IP side, since people ask: Mickai LTD is the applicant on 104 filed UK patent applications carrying approximately 2,340 claims, filed at the UK IPO and working towards examination. They are filed and pending, not granted, and I will not describe them otherwise.

The beta

The design partner beta is open at mickai.co.uk/beta.

It is selective, and the page runs a hardware capability check in your browser before an application is accepted, because the deployment only works where the hardware does. If your organisation's binding constraint is that the data genuinely cannot leave your infrastructure, that is the case this was built for.

If you think the threat model above is wrong, or that the key-custody caveat undermines the whole approach, I would genuinely like to hear it. That argument is more useful to me than agreement.

More at mickai.co.uk.

Why Banks Need On-Premise AI for AML and Financial-Crime Detection

Micky Irons — Wed, 26 Aug 2026 15:52:22 +0000

The Growing Threat of Financial Crime

In today's digital age, financial crime is becoming more sophisticated and harder to detect. Banks and financial institutions are under increasing pressure to identify and prevent money laundering, fraud, and other financial crimes. Traditional methods, such as manual reviews and rule-based systems, are no longer sufficient. The complexity and scale of transactions require advanced, automated solutions that can process vast amounts of data in real-time. This is where on-premise AI solutions come into play.

The Limitations of Cloud-Based Solutions

Many financial institutions have turned to cloud-based AI solutions for their AML and financial-crime detection needs. However, these solutions come with significant limitations. One of the primary concerns is data residency and sovereignty. Cloud providers often have their own data centers and may store data in regions outside the institution's jurisdiction. This can pose a risk under regulations such as the CLOUD Act, which allows foreign governments to access data stored in the US. Additionally, cloud services may be subject to outages, data breaches, and other technical issues, which can disrupt operations and compromise security.

Why On-Premise AI is Superior

Sovereignty and Control

On-premise AI solutions, such as Mickai's Nemesis studio, provide banks with full control over their data. These solutions run on the institution's own hardware, ensuring that all data remains within the institution's premises. This aligns perfectly with the regulatory requirements for data residency and sovereignty, reducing the risk of data breaches and compliance issues. Nemesis is designed to be air-gapped by default, meaning it does not connect to the internet unless explicitly configured to do so. This further enhances security and privacy.

Tamper-Evident Logging

Nemesis offers tamper-evident logging, a critical feature for financial institutions. Every action taken by the system is recorded and sealed into the Open Audit Record (OAR). This ensures that any attempt to alter the logs can be detected and reported. The OAR is append-only, hash-chained, and sealed with post-quantum cryptography (ML-DSA-65). This provides a robust audit trail that can be verified against a signed off-box checkpoint. The tamper-evident nature of the OAR helps ensure the integrity of the data and the actions taken, which is crucial for maintaining trust and compliance.

Real-Time Transaction Monitoring

One of the key challenges in AML is the ability to monitor transactions in real-time. Nemesis is designed to handle this task efficiently. It can process large volumes of transactions and flag suspicious activities in real-time. This allows banks to take immediate action and prevent potential financial crimes before they cause significant damage. The system's ability to detect false positives is also critical, as false positives can lead to unnecessary investigations and disrupt business operations. Nemesis uses advanced machine learning models to minimize false positives, ensuring that only genuine suspicious activities are flagged.

Compliance and Proving Data Integrity

Compliance is a critical aspect of AML and financial-crime detection. Banks must be able to prove that their data is accurate and has not been tampered with. The Open Audit Record (OAR) provides a way to do this. By sealing every action into the OAR, banks can produce a verifiable log that can be used to demonstrate compliance. This is particularly important under regulations such as the EU AI Act and DORA, which require robust data governance and transparency. The OAR ensures that any audit can be conducted with confidence, as the data remains tamper-evident.

Cost and Vendor Lock-In

Another benefit of on-premise AI solutions is the reduction in vendor lock-in and cost. Cloud-based solutions often come with subscription fees, data transfer costs, and other hidden charges. On-premise solutions, such as Nemesis, can be deployed on existing hardware and do not require ongoing subscription fees. This can lead to significant cost savings over time. Additionally, on-premise solutions are not tied to a specific vendor, reducing the risk of vendor lock-in. Banks can choose the best tools and solutions for their needs without being constrained by a single provider.

Conclusion

In conclusion, on-premise AI solutions like Mickai's Nemesis studio offer banks a robust, secure, and compliant way to detect and prevent financial crime. By providing full control over data, ensuring tamper-evident logging, and offering real-time transaction monitoring, these solutions address the growing challenges faced by financial institutions. Banks can benefit from enhanced security, reduced costs, and greater control over their operations. As the threat of financial crime continues to evolve, on-premise AI solutions will play a crucial role in helping banks stay ahead of the game.

By adopting on-premise AI, banks can ensure that their data remains secure, compliant, and trustworthy. This is not just a matter of compliance; it is a matter of maintaining the integrity of the financial system.

Running a datacentre-class model on one workstation, offline

Micky Irons — Tue, 25 Aug 2026 23:58:51 +0000

Most guides on running large language models locally start from the same assumption: you need a lot of expensive GPU memory, or you don't get to run a big model at all. That framing quietly rules out most of the organisations that have the strongest reason to keep their intelligence on their own machines. Banks, hospitals and government teams can't send their most sensitive data to someone else's cloud and trust a policy page, and they usually can't buy a rack of the newest accelerators either.

I want to walk through the approach we took to break that trade-off, because the engineering idea is simple once you see it, and it changes what "run it yourself" actually costs.

The real constraint is memory, not compute

A big mixture-of-experts model has a lot of parameters, but only a small fraction of them fire for any given token. The weights still have to live somewhere, and that "somewhere" is what people reach for expensive GPU memory to solve. The compute you need per token is modest. The memory footprint is the wall.

So we stopped treating GPU memory as the thing that has to hold the whole model. Instead, the model sits in ordinary system RAM, which is cheap and plentiful on a normal workstation or server, and only the parts each request actually needs get streamed onto the GPU. The GPU does the maths. The RAM holds the model. You size the machine on the resource you already have, not the one that costs the most.

The result is that a model most people assume needs a datacentre will serve from a single workstation-class box. It isn't instant, and I won't pretend it is: streaming experts off system memory costs latency. For a lot of real work, that's a trade worth making, because the alternative isn't "faster in the cloud", it's "not on your own hardware at all".

Offline is a property you can test, not a promise

Running locally only matters if it stays local. It's easy to say a component is air-gapped and much harder to make that something a reviewer can check. The inference engine we run refuses any outbound connection. It's loopback only, and an independent adversarial review confirmed the egress guard holds. That's the difference between "trust us" and "here's the test you can run yourself".

If you're building anything in this space, I'd push for the same standard. Make the no-egress claim falsifiable. Bind the listener to loopback, block outbound at the process, and let someone try to break it before you ship it.

Prove what ran, not just that it ran

The last piece is accountability. When an autonomous system takes an action on regulated data, "it worked" isn't enough. You need to be able to prove, later, which model ran, on which machine, on which inputs, and what it did.

We seal each session into an append-only, hash-chained record and verify it against a signed checkpoint held off the box. That makes it tamper-evident: an attacker can delete a file or refuse a verifier, but they can't silently alter the record and have it still verify. I'm careful with the language here. It's tamper-evident, not tamper-proof. The honest claim is that tampering shows, not that it's impossible.

Why this matters

Put the three together and you get something specific: a capable model, running on hardware a normal organisation already owns, fully offline, with a record of exactly what happened that survives an audit. That's the foundation the rest of our system is built on, and it's the part that turns sovereign AI from an infrastructure project into something you actually run on your own terms.

None of this needs the newest hardware or a cloud contract. It needs a change of assumption: that the limit is memory, not compute, and that "sovereign" has to be testable, not asserted. If you're weighing up local inference for work you can't send elsewhere, that's the lens I'd start from.

I'm Micky Irons, founder of Mickai. We build a Sovereign Intelligence Operating System that runs on your own hardware. Our patents are filed, not granted, and I'd rather be precise about that than impressive.

Why We Filed 104 Patent Applications on the Mechanism, Not the Model

Micky Irons — Thu, 20 Aug 2026 13:30:06 +0000

The durable inventions in a sovereign AI system are not the models. They are the ways trust is enforced offline. That is what our filed estate protects.

We filed 104 patent applications with 2,340 claims because the lasting inventions in SIOS are not the AI models, they are the mechanisms that enforce sovereignty and trust offline. Models age out every few months. The enforcement that proves auditability, binds licensing to hardware, seals agent orchestration, and verifies a ledger against a signed checkpoint endures across model generations. That is what we protected.

Originally published on mickai.co.uk. This is a cross-post; the canonical version, with the full body, footnotes and references, lives on the mickai.co.uk article page.

Hardware-Bound Offline Licensing

Micky Irons — Thu, 20 Aug 2026 13:29:20 +0000

How SIOS binds a per-seat licence to the machine itself, enforces its own expiry with no network, and refuses cloned drives and rolled-back clocks.

You stop it by binding the licence to the machine hardware and letting the licence enforce its own expiry with no internet. In SIOS the seat is tied to a hardware-rooted machine identity and carries a rollback-resistant offline timer, so cloning a drive to another machine, swapping in a forged key, or winding back the system clock all fail closed.

Originally published on mickai.co.uk. This is a cross-post; the canonical version, with the full body, footnotes and references, lives on the mickai.co.uk article page.

The Honest Way to Prove an Audit Log Was Not Altered, Offline

Micky Irons — Thu, 20 Aug 2026 13:28:18 +0000

Why we build tamper-evidence instead of promising the impossible, and how a signed off-box checkpoint turns a hash chain into proof you can trust without a network.

You prove it with a signature an attacker cannot forge, anchored outside the ledger. A hash chain shows the record is internally consistent. A checkpoint (genesis, length, head hash, Merkle root) signed by an Ed25519 key and held off-box lets a verifier confirm the live chain is exactly the one that was attested, and no older. No internet required.

Originally published on mickai.co.uk. This is a cross-post; the canonical version, with the full body, footnotes and references, lives on the mickai.co.uk article page.