DEV Community: Micky Irons

Why AI Must Be Tested in the Real Environment

Micky Irons — Fri, 25 Sep 2026 20:01:35 +0000

AI that works in a pilot fails in the real environment because the pilot removed the four things that decide the outcome: messy real data, enforced permissions, restricted networks and ordinary staff. Put those back and most systems struggle. Evaluate on representative files, under real identities, on hardware you own.

What is actually different between a pilot and the real environment?

Four things change: the data, the permissions, the network and the people. A pilot usually removes all four. Someone assembles a tidy folder of documents, runs it through a hosted system on an open connection, and presents the output to a room that already wants it to work.

None of that survives contact with the organisation. The real corpus is decades deep and inconsistently scanned. The real permission model says that several people in that room are not entitled to see half of it. The real network sits behind a proxy that strips the headers the vendor's client library expects. The real users are busy, sceptical, and paid to do something other than help a pilot succeed.

I build the Mickai Sovereign Intelligence Operating System (SIOS), which runs on hardware the customer owns. I mention that because it shapes my view. When the software runs inside your building, you meet all four problems in the first week instead of the ninth month. That is uncomfortable, and it is the only honest sequence.

Why does real data break a system that handled the demo set?

Because demo sets are curated and real corpora are not. The gap is rarely about model quality. It is the distance between the files someone chose to show you and the files that actually exist on your estate.

Real documents are photocopies of faxes. They carry handwritten margin notes that reverse the clause above them. They exist in three versions, two of them superseded, none of them clearly labelled. Tables run across page breaks. Headers repeat mid-document. A scanning artefact turns a decimal point into a comma and a figure moves by a factor of a hundred.

A system evaluated on twenty clean PDFs learns nothing about any of that. Worse, it produces a number that feels like evidence. A high score on the sample becomes "accurate" in the business case, and the first time anyone runs it across the shared drive the figure collapses, because the shared drive is where the real distribution lives.

The remedy is dull. Evaluate on files drawn at random from the live store, including the ones nobody wants to show you. If that cannot be done because the data is not permitted to leave the building, that is not an obstacle to the evaluation. It is the most important finding of the evaluation.

What happens when permissions enter the picture?

Retrieval ignores entitlements unless somebody builds entitlements into retrieval. In a pilot, the person running it usually holds administrator rights, so everything is visible and nothing is tested.

Then it goes live, and a junior analyst asks a perfectly reasonable question. The system answers it correctly, using a board paper they were never allowed to open. Nothing was hacked. The index simply had no idea who was asking.

That is not an abstract governance point. The obligations sit in the UK GDPR and the Data Protection Act 2018, and the ICO guidance on AI and data protection is clear that access control and data minimisation apply to an AI system exactly as they apply to anything else, with a data protection impact assessment likely to be needed where personal data is processed at scale.

So test under real identities. Give three people at three entitlement levels the same question and compare what comes back. If the three answers are identical, the system is enforcing nothing, and your pilot has proved the opposite of what you believe it proved.

Why do network constraints decide more outcomes than accuracy does?

Because the best system in the world is useless if your data is not allowed to reach it. Many regulated environments do not permit outbound traffic from the segment where the interesting material sits, and no amount of model quality changes that rule.

Pilots hide the problem by running somewhere convenient: a laptop on guest wifi, a tenancy stood up for the trial, a sandbox with a firewall exception written specifically for it. The exception expires. The production segment has an egress proxy, TLS inspection and a standing rule that nothing leaves. Sites lose connectivity as a matter of routine: a plant, a vessel, a depot or a forward location works offline by default, not as an edge case.

The NCSC guidelines for secure AI system development treat the whole pipeline, including everything the system talks to, as part of the attack surface. If you are an FCA-regulated firm, the operational resilience rules ask you to know which services your important business services depend on and what happens when one becomes unavailable. A capability that stops the moment a third party's data centre is unreachable is a dependency you do not control.

The evaluation question is therefore not only whether the answer is right. It is whether producing the answer required anything to leave. Disconnect the network during the test. If the system stops, you have learned precisely what you would be buying.

What do real staff do that a pilot never sees?

They paste. They paste the wrong thing into the wrong box at ten to five on a Friday. They ask questions shaped like their job rather than shaped like your prompt guidance. They accept a plausible answer because they are behind, and a plausible answer is exactly what a confident system produces when it is wrong.

A pilot staffed by five enthusiasts measures enthusiasm. A real environment contains people who do not want the tool, people who will try to break it, and people who will trust it far more than you intended. All three are useful. The sceptic finds the edge cases nobody scripted. The over-truster shows you where a named human has to stand in the path, because that is precisely where an unchecked action would have caused damage.

That is why consequential actions in SIOS wait for a named person to approve them. Not a role, not a service account, a person, recorded at the moment of approval. It is slower. It is also the difference between an incident you can explain to a regulator and one you cannot.

How do you run an evaluation that actually tells you something?

Run it where the work happens: your hardware, your files, your identities, your staff. Everything else is a demonstration wearing the word evaluation.

A workable shape looks like this. Take several hundred documents drawn at random from the live store rather than selected by the vendor. Have your own subject matter experts write down the correct answers before they see any output, otherwise you will grade on plausibility rather than accuracy. Run the same questions under three entitlement levels. Run once connected and once disconnected. Log every consequential action and confirm a named person approved it. Then export the record and verify it somewhere else entirely.

That final step matters more than it sounds. In SIOS, every consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The record is tamper-evident: altering an exported record makes verification fail, and that failure is the signal you need. An auditor can check the export offline with the public key, using tools that are not ours. If a vendor's audit trail can only be verified inside the vendor's own product, you do not have an audit trail. You have a claim.

What should you ask before you commit to anything?

Ask where the evaluation will run, and insist on your own hardware. Ask what happens when the connection drops. Ask to watch the same question answered for three people with different entitlements. Ask who approves a consequential action, by name, and where that approval is recorded. Ask how an auditor verifies the record with the vendor absent from the room.

For our part: Mickai LTD is a UK company, number 17166618, held privately by me. MICKAI is a registered UK trade mark, UK00004373277. We hold 104 filed UK patent applications carrying 2,340 claims, filed and not granted, with me as named inventor. SIOS ships with 63 studios, 14 production-ready at launch and 49 in development, alongside 50 specialised models. The closed beta is open and one regulated company is onboarding as a design partner.

I would rather you tested all of that inside your own building than took my word for any of it. We are not against the companies that build the compute or cloud layer, and cloud remains sensible for work that is not regulated. What I will argue with is the assumption that a regulated organisation has to ship its data offsite and accept a supplier's account of what happened to it. A pilot that flatters the software tells you nothing you can act on. A test that runs in the real environment, with the real constraints in place, tells you whether the thing works.

Frequently asked questions

Why do AI pilots succeed when production deployments fail?

A pilot removes the four things that decide the outcome: messy real data, enforced permissions, network restrictions and ordinary users. Remove all four and almost any system looks capable. Put them back and most do not cope. Test with real files, real entitlements, real network rules and real staff, on hardware you own, before committing to anything.

How many documents should an AI evaluation actually use?

Several hundred at minimum, drawn at random from the live store rather than selected by a supplier. Twenty curated PDFs tell you nothing about the distribution you actually hold. Include the poor scans, the superseded versions and the handwritten annotations, because those are the files that produce confident wrong answers once the system is live.

Can an AI system respect our existing access permissions?

It can, but only if entitlements are enforced at retrieval rather than bolted on afterwards. Test it directly: ask three people at three clearance levels the same question and compare what comes back. If all three receive the same answer, nothing is being enforced, and the index will eventually surface a document to someone not cleared for it.

Does AI have to run in the cloud?

No. The Mickai Sovereign Intelligence Operating System runs on hardware the customer owns, is capable of running offline, and sends no data out. Cloud remains sensible for work that is not regulated. The point is that a regulated organisation should not be obliged to ship sensitive material offsite and accept a supplier's account of what happened to it.

What evidence should a buyer require from an AI supplier?

An exportable record of what the system did, verifiable without the supplier present. In SIOS every consequential action is sealed in the Open Audit Record under ML-DSA-65, published by NIST as FIPS 204 in 2024. It is tamper-evident: altering an export makes verification fail. An auditor checks it offline with a public key.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

From Documents to Decisions You Can Defend

Micky Irons — Fri, 25 Sep 2026 20:00:52 +0000

Keep the chain intact. Read the documents where they already sit, on hardware you own, and make every extracted statement cite its source document, version and page. Then have a named person approve anything consequential, and seal that approval in a tamper-evident audit record an external auditor can verify offline.

Why is the document pile the hardest part of the decision?

Because that is where the evidence sits, and evidence is what has to survive a challenge. The analysis is rarely the bottleneck. In most regulated organisations the answer already exists somewhere: in a contract, a survey report, a superseded policy version, a scanned form filed in 2014.

What breaks is the chain. Someone finds the relevant pages, reads them, writes a summary, and the summary goes into a paper. The paper says the contract permits assignment. Nine months later a regulator, a counterparty or an internal auditor asks which contract, which clause, which version, and who read it. The link is gone. The person has moved teams. The summary is now the only artefact, and it cannot be checked without redoing the whole job from scratch.

So the real question is not whether a machine can read your documents. Plenty of things can read documents. The question is whether the reading leaves behind something another person can follow backwards, years later, when everyone involved has moved on.

What does a decision you can defend actually mean?

It means you can produce three things on demand: the evidence that was used, what the system did with it, and which named person accepted the result. Defensible is not the same as correct. Correct decisions still go wrong and defensible ones still get challenged. The difference is that a defensible decision can be examined rather than asserted.

That framing is not mine. The accountability principle in UK data protection law requires an organisation to demonstrate compliance, not simply to achieve it, and the ICO's guidance on accountability and governance treats documentation as the demonstration itself (ICO). The Data Protection Act 2018 sits behind that (legislation.gov.uk). For firms under the FCA, the SYSC record-keeping and governance obligations push in the same direction (FCA Handbook).

The practical consequence is a design choice. A document system for regulated work has to be built as an evidence system that happens to answer questions, not as a question-answering system that happens to touch evidence. Those two things look similar in a demonstration and behave nothing alike under scrutiny.

Can the documents be read without leaving the building?

Yes, and for regulated material they should be. The common pattern is to send the document to someone else's inference cluster, take the answer back, and accept a contractual promise about what happened in between. That is a fair trade for a marketing brochure. It is a poor trade for a client file, a defence contract or a member record.

I am not arguing against the cloud. The companies building the compute and cloud layer are doing hard work, and for non-regulated workloads renting that capacity is the sensible answer. What I object to is the assumption that a regulated organisation has no other option: that it must ship its most sensitive material offsite and take a vendor's word for what happened to it.

The Mickai Sovereign Intelligence Operating System (SIOS) runs on hardware the customer owns. It is offline capable, with no data egress. For document reading that means optical character recognition, layout parsing and the language model all run on the same machines, inside the same network boundary, under the physical controls the organisation already operates. Local OCR has read scanned PDFs in our own controlled internal testing, including poor-quality scans. That is our own testing on our own files, not an independent benchmark, and it is not a substitute for running it on yours. The NCSC's cyber security design principles set out making compromise difficult, including reducing the attack surface a system exposes (NCSC). Not moving the document anywhere is the plainest version of that.

What happens between a scanned page and an answer?

Four steps: extraction, structuring, retrieval and attribution. Extraction turns pixels into text and keeps the coordinates. Structuring works out that this block is a table, that one a signature panel and this one a clause heading, so a question about payment terms does not come back with the header of page one. Retrieval finds the passages that bear on the question. Attribution is the step most systems skip: every statement in the output carries a pointer back to the document, the version, the page and the region it came from.

Attribution is what makes review possible without repeating the work. A reviewer does not have to trust the summary. They open the cited page and look at it.

I should be straight about the state of this. The reading components work. The full extraction and ingestion integration inside SIOS, meaning the pipeline that takes an organisation's live repositories, ingests them continuously, versions them and wires them through to every studio that needs them, is still being completed. That is engineering still in progress, and I would rather say so than let a buyer find out later. If anyone tells you their ingestion is finished, ask them to run it on your files rather than their sample set.

What does the Open Audit Record prove, and what does it not?

Every consequential action in SIOS is sealed in an Open Audit Record, signed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024 (NIST). Export the record and an auditor verifies it offline with a public key, using tools that are not ours. That last point matters more than the cryptography. Verification that depends on the vendor's own software is not verification.

What it proves is narrow and precise. The record has not been altered since it was sealed. Edit a line, move a timestamp, remove an entry, and verification fails. The OAR is tamper-evident. It is not tamper-proof, it does not prevent attacks, and it does not guarantee compliance with anything. It makes silent alteration detectable, which is a different and more honest claim than making alteration impossible.

What it does not prove is that the answer was right. A signed record of a bad extraction is a bad extraction, sealed. The gain is that the bad extraction is now visible, attributable and reviewable, instead of being laundered into a summary nobody can trace.

Where does a person still have to sign?

At every consequential action. The system reads, extracts, retrieves and drafts. It does not decide. Anything with a consequence, releasing a document, filing a return, amending a record, sending a response, waits for a named person to approve it, and that approval becomes part of the sealed record.

This is a deliberate limit and it is the one people argue with most. The case for autonomy is throughput. The cost of autonomy in a regulated setting is that you lose the human you need to be able to point at. I would take a slower process with an accountable name attached over a fast one where the honest answer to "who decided this" is "the system did".

How would you start without betting the organisation on it?

Pick one bounded corpus and one recurring question. Not the whole estate. One document type, one team, one question that costs a person several hours and gets asked every week: supplier contract terms, planning conditions, policy exceptions, claims correspondence.

Then run it against material where you already know the answer, and measure three things yourself: time taken, error rate against a human baseline you established, and whether the citations actually land on the right page. Do not take a number from me or from anyone else selling you something. Measure it on your own files, on your own hardware, with your own people checking the output.

For the record on who is saying this. Mickai LTD is a UK company, Companies House 17166618, held privately by me. MICKAI is a registered UK trade mark, UK00004373277. We hold 104 filed UK patent applications carrying 2,340 claims, filed and not granted. SIOS spans 63 studios, 14 production-ready at launch and 49 in development, supported by 50 specialised models. The closed beta is open, with one regulated company onboarding as a design partner.

Frequently asked questions

Can SIOS read scanned PDFs, or only documents that already contain text?

Local OCR has read scanned PDFs in controlled tests on our own hardware, including poor-quality scans. The reading components run on the customer machines with no data egress. The wider extraction and ingestion integration inside SIOS, which connects live document repositories and versions them continuously, is still being completed.

What happens if someone alters the audit record?

Verification fails. The Open Audit Record is sealed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. It is tamper-evident, not tamper-proof: it does not prevent an attack and does not guarantee compliance. It makes alteration detectable by an auditor verifying the exported record offline, with tools that are not ours.

Does the system make decisions on its own?

No. It reads, extracts, retrieves and drafts. Every consequential action waits for a named person to approve it, and that approval forms part of the sealed record. The limit is deliberate. In a regulated setting you need an accountable human name attached to the outcome, not a log entry saying the system proceeded on its own.

Do our documents leave our network at any point?

No. SIOS runs on hardware the customer owns and is offline capable, with no data egress. Optical character recognition, layout parsing and the model all execute inside your own network boundary, under the physical and access controls you already operate. Nothing is sent to an external inference endpoint for processing.

How do we test this against our own documents?

Choose one bounded corpus and one recurring question, then run it on material where you already know the answer. Measure the time taken, the error rate against a human baseline you set yourself, and whether every citation lands on the correct page. The closed beta is open, with one regulated company onboarding as a design partner.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

Four Questions Before You Let AI Act On Its Own

Micky Irons — Fri, 25 Sep 2026 20:00:08 +0000

Ask four things. Who approved this action, and were they named? What did the system see before it acted? What did it change, exactly? And can you prove all three of those six months later to someone who does not trust you? If any answer is missing, the action should not run unattended.

What does it actually mean to let an AI system act on its own?

It means the system changes something outside itself without a person checking first. Drafting a summary is not acting. Sending the email, moving the money, filing the return, updating the record, closing the ticket, provisioning the account: those are actions, and they have consequences that outlive the session.

The distinction matters because most of the governance in regulated organisations was built for the first category and is now being asked to cover the second. A review process that assumes a person reads the output before anything happens does not survive contact with a system that has already acted by the time the output arrives. I have spent the last stretch of my working life building the Mickai Sovereign Intelligence Operating System (SIOS) around that gap, and the four questions below are the ones I would put to any vendor, including me.

Who approved the action, and can you name them?

Every consequential action should stop and wait for a named person. Not a role, not a service account, not a policy signed off eighteen months ago by someone who has since left.

Named approval does three things at once. It gives the organisation a person who understood the action at the moment it happened, which is what an investigation actually needs. It gives that person the ability to say no, which is the only control that stops a bad action rather than describing it afterwards. And it puts the decision inside the accountability structures your regulator already recognises, rather than in a parallel structure invented for AI.

The usual objection is speed. If a person has to approve everything, why automate at all? Because "consequential" is a line you draw, not a property of the technology. Reading two hundred contracts and extracting the termination clauses is not consequential. Serving notice on one of them is. Draw the line properly and the approval step costs seconds on a small number of actions, while the work that fills the rest of the day runs unattended.

What did the system see before it acted?

You need the inputs, not a summary of the inputs. Which documents, which records, which version of each, and which instructions were in force at the time.

This is where most audit trails quietly fail. They record that an action was taken and by which process, but not the evidence the decision rested on. Six months later, when someone asks why the system did what it did, the honest answer is a reconstruction. Reconstructions do not hold up well in front of a regulator, a court, or an internal audit function that has been told to be sceptical.

There is a second reason to capture inputs. Retrieval pulls context from wherever it is pointed, and that context can be stale, wrong or hostile. If a file in a shared folder contains text written to steer a model, you want that text in the record so you can find it later. An input log is a security control as much as a compliance one. The NCSC's guidelines for secure AI system development make the same point about knowing what goes into a system and protecting the supply chain around it (https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development).

What did it change, and can you put it back?

You want the change recorded as a difference: the state before, the state after, and the specific fields or files that moved. Not "updated customer record" but the actual delta.

Deltas make reversal possible. Any organisation running automated action at scale will eventually run a bad one, and the difference between an incident and a crisis is whether you can enumerate exactly what was touched and restore it. That is operational resilience in the ordinary sense the FCA uses, which is about keeping important business services running and recovering when something breaks (https://www.fca.org.uk/firms/operational-resilience).

Deltas also make scope provable. When a supervisor asks how many clients were affected, the answer should be a number you can produce from the record, not an estimate you defend under pressure.

Can you prove all of this six months later?

Proof means an independent party can verify the record without trusting you, your logging stack or your supplier. Internal logs written by the system that took the action are evidence of intent, not evidence of fact, because whoever controls the system controls the log.

This is why Mickai seals every consequential action into an Open Audit Record (OAR). Each entry carries the named approver, the inputs, the change and the time, signed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024 (https://csrc.nist.gov/pubs/fips/204/final). An auditor can export the record, take it away and verify the signatures offline against a public key, using tools that are not ours.

Be clear about what that buys you. The OAR is tamper-evident, not tamper-proof. Someone with sufficient access can still alter or delete an entry. What they cannot do is alter one and have it still verify: tampering makes verification fail. You do not get prevention, you get detection, and detection is the property that makes a record worth producing in a dispute. Any supplier who tells you their audit log is unbreakable is selling you a feeling.

Which UK rules make these four questions mandatory rather than optional?

None of them name the four questions. All of them assume you can answer them.

The accountability principle in UK data protection law requires you to demonstrate compliance rather than assert it, and the ICO's guidance on AI and data protection sets out what that demonstration looks like in practice (https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/). UK GDPR and the Data Protection Act 2018 also place conditions on decisions taken solely by automated means where those decisions have legal or similarly significant effects (https://www.legislation.gov.uk/ukpga/2018/12/contents). If a named person approved the action, you are in a different and simpler position than if nobody did.

In financial services, the PRA's supervisory statement on outsourcing and third party risk management (SS2/21) expects firms to retain oversight and accountability rather than delegate them away with the process (https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss). Wherever the model runs, the responsibility stays with you.

How should this change the way you buy?

Turn the four questions into acceptance criteria and make the supplier demonstrate each one on your data, not on a stage.

Ask them to show you an approval that was refused, and what the record says about it. Ask for the input set behind a single action, by document and version. Ask for a before and after on a record the system changed. Then ask for an export and verify a signature yourself, offline, with software you chose. If any of those four is a roadmap item, you are being asked to take a vendor's word for what happened to your data.

That assumption is the one worth arguing with. The cloud remains valuable for a great deal of work, and I have no quarrel with the organisations building the compute and hosting layers. The quarrel is narrower: a regulated organisation should not have to rent its intelligence, ship its evidence offsite and accept a summary as proof. SIOS runs on hardware the customer owns, offline capable, with no data egress, because these four questions are much easier to answer when the answers never leave the building. The closed beta is open, with one regulated company onboarding as a design partner.

Frequently asked questions

What is the Open Audit Record?

It is the signed record Mickai writes for every consequential action. Each entry holds the named approver, the inputs the system saw, the change it made and the time it happened, sealed with ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024. An auditor can verify an exported record offline with a public key, using tools that are not ours.

Is a tamper-evident audit record the same as a tamper-proof one?

No, and the difference matters. Tamper-proof would mean the record cannot be altered, which no software can honestly promise to someone holding administrative access. Tamper-evident means alteration is detectable: change one entry and its signature no longer verifies. You do not get prevention. You get certainty about whether the record you are reading is the record that was written.

Does requiring a named approver make automation pointless?

No, because approval applies to consequential actions only. Reading, extracting, comparing, drafting and summarising run unattended. Sending, filing, paying, provisioning and deleting stop and wait for a person. Most of the volume sits in the first group, so the approval step costs seconds across a small number of decisions while the bulk of the work continues without interruption.

Do these questions apply to AI that only drafts and never acts?

Partly. A drafting system does not need approval gates on its output, because a person is already the one acting on it. It still needs an input record, because the draft may rest on stale, wrong or deliberately planted source material, and you will want to know which documents it read. Systems that draft this year tend to act the next.

Who is accountable when an autonomous AI system gets something wrong?

Your organisation. UK regulators consistently place responsibility with the regulated firm rather than its suppliers, and outsourcing a process does not outsource the obligation that sits behind it. That is the practical reason to insist on named approval and independently verifiable records: when the question arrives, you need a person who decided and evidence they can stand behind.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

AI for Essential Services: What UK Regulation Requires

Micky Irons — Fri, 25 Sep 2026 19:59:36 +0000

Essential services regulation treats an AI system as part of the service itself. Under the NIS Regulations 2018 and the NCSC Cyber Assessment Framework, operators must show the system is secure, resilient and accountable. In practice that means AI running on hardware you own, working offline, with every consequential action signed and independently verifiable.

What does essential services regulation actually require of an AI system?

It requires you to treat the AI as part of the service, not as a tool sitting beside it. The Network and Information Systems Regulations 2018 oblige operators of essential services to take appropriate and proportionate technical and organisational measures to manage risk to their network and information systems, and to prevent or minimise the impact of incidents on continuity of service. Nothing in that wording carves out a system because it happens to use a model.

So the first question is not what the AI can do. It is where it sits. If it informs a dispatch decision, a maintenance priority, a network configuration or a safety judgement, it is inside the regulated boundary. And your competent authority does not assess your supplier. It assesses you. When someone asks why the system recommended what it recommended on the night of an incident, "we have logged a ticket with the vendor" is not an answer you can give twice.

I have watched procurement teams treat an AI purchase as a software purchase, with a security questionnaire bolted on at the end. In this sector it is closer to adding a new asset to the estate. It needs an owner, a risk assessment, a documented failure mode and a decommissioning plan, on day one.

Which rules apply when AI touches critical national infrastructure?

Work out which of three layers you sit in, because they stack. The first is the NIS Regulations 2018, covering operators of essential services in energy, transport, drinking water and digital infrastructure, each with its own competent authority named in Schedule 1: the Secretary of State for Energy Security and Net Zero, acting jointly with the Gas and Electricity Markets Authority for electricity; the Secretary of State for Transport; the Secretary of State for Environment, Food and Rural Affairs for drinking water in England; and Ofcom for digital infrastructure.

The second layer is sector security law. For telecoms that is the Telecommunications (Security) Act 2021 and the regulations made under it, enforced by Ofcom, which set duties out in far more specific terms than NIS does, down to how you handle privileged access and the security of equipment and suppliers.

The third layer is data protection. If the system touches personal data, UK GDPR accountability applies, a data protection impact assessment is likely to be mandatory, and Article 22 constrains decisions taken solely by automated means where they have legal or similarly significant effects on a person. The ICO is the regulator there, and its guidance on AI and data protection is the practical starting point.

The Government has also set out plans to widen the NIS regime through the Cyber Security and Resilience Bill, with more attention on managed service providers and on supply chain. I would not design an essential services deployment on the assumption that today's perimeter is the final one.

How does the NCSC Cyber Assessment Framework change an AI deployment?

The CAF is where an abstract duty becomes a set of questions someone will score you against. It has four objectives: A, managing security risk; B, protecting against cyber attack; C, detecting cyber security events; D, minimising the impact of incidents. Under each sit contributing outcomes, and an assessor marks every one of them achieved, partially achieved or not achieved.

Run a remote AI service through that honestly. Objective A asks whether you understand and control your assets and your supply chain dependencies, which is difficult when the model, the weights and the inference stack all belong to someone else and can change without notice. Objective C asks whether you can detect and investigate events on your own systems, which is hard when the logs live in another tenancy and reach you summarised. Objective D asks whether you can continue the service through disruption, which is an awkward conversation when the intelligence layer is reachable only over the internet.

Moving the system onto hardware you own does not score well automatically. It does put every one of those outcomes back inside your control, where you can evidence them rather than point at somebody else's certificate. The NCSC and its international partners have published guidelines for secure AI system development, and they are written on the assumption that you know what is in your system. That assumption is only true if you hold it.

Why does offline operation matter more than features here?

Because an essential service is judged on its worst day, not its average one. Water is pumped, trains are signalled and networks are restored during the outage, not after it. If the AI layer stops when the link stops, then either it was never load-bearing, in which case it is hard to justify the spend, or it was, in which case you have added a single point of failure to a service the public relies on.

This is the plainest test I know to put to any vendor: pull the network cable, then see what still works. Our answer is that the Mickai Sovereign Intelligence Operating System runs on hardware the customer owns, is capable of operating fully offline, and moves no data off the estate. That is not a privacy flourish. It is a resilience property, and in this sector resilience is the requirement.

Features are straightforward to add later. A dependency on somebody else's availability is very hard to remove later.

What can an auditor actually check after the fact?

An auditor can check that every consequential action was recorded, that the record has not been altered since, and that a named person approved it, without us in the room. This is where most AI deployments in regulated settings come apart, because a chat transcript is not evidence. It can be edited, it proves nothing about who approved what, and it does not survive a serious challenge from an inspector or a court.

We record every consequential action in an Open Audit Record. Each entry is sealed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024, and the NCSC has been clear that organisations running long-lived systems should be planning their migration to post-quantum cryptography now rather than at the deadline. The record is tamper-evident, and that word is chosen carefully. Nobody can stop a determined party altering a file. Altering it makes verification fail, which is the property you actually need. An auditor can export the record and verify it offline, with a public key, using tools that are not ours. That last clause is the one that counts: evidence you have to trust us to validate is not evidence.

Consequential actions also wait for a named person to approve them. That gives you the accountability trail the CAF governance outcomes and UK GDPR both expect, and it keeps the human decision where the regulation assumes it already is.

What does a sensible first deployment look like?

Narrow, and on your own estate. Pick one workload where the current cost is analyst time rather than control authority: incident write-ups, asset documentation, supplier assurance questionnaires, drafting regulatory returns. Prove the audit record end to end, with your own auditor, before the system goes anywhere near an operational decision. Then widen it deliberately, one workload at a time, with the failure mode written down before each step.

SIOS ships as 63 studios, 14 of them production-ready at launch and 49 in development, with 50 specialised models behind them. Start with one studio, one team and one measurable task. Our closed beta is open, and one regulated company is onboarding as a design partner.

None of this is an argument against the companies that build the compute or the cloud layer. For work that is not regulated, renting capacity is often the right call and we are not trying to talk anyone out of it. What I do not accept is the assumption that a water company, a rail operator or a network provider must ship its operational data offsite and take a supplier's word for what happened to it. That is a commercial arrangement presented as a technical necessity.

Mickai LTD is a UK company, Companies House 17166618, held privately by its founder. MICKAI is a registered UK trade mark, UK00004373277. The architecture behind SIOS is covered by 104 filed UK patent applications carrying 2,340 claims, filed and not granted. I set all of that out for one reason: in essential services you are buying a dependency, and you are entitled to know exactly what you are depending on.

Frequently asked questions

Do the NIS Regulations 2018 apply to an AI system?

They apply to the network and information systems an operator of essential services relies on, and an AI system used in that service is one of them. There is no exemption for machine learning. If the system informs an operational decision, it sits inside the regulated boundary and the same security and continuity duties apply.

How is AI assessed under the NCSC Cyber Assessment Framework?

Against the same contributing outcomes as any other system, across the four CAF objectives: managing security risk, protecting against attack, detecting events, and minimising incident impact. An assessor marks each outcome achieved, partially achieved or not achieved. Remote services tend to struggle on asset and supply chain understanding, on event detection, and on operating through disruption.

Can AI run fully offline in a utility or transport environment?

Yes, if it was built for it. SIOS runs on hardware the customer owns and is capable of operating with no external connection and no data leaving the estate. The test to put to any vendor is simple: disconnect the network and see which capabilities survive. In essential services that answer matters more than the feature list.

What evidence does a regulator accept about an AI decision?

Something checkable without the vendor in the room. Every consequential action in SIOS is written to an Open Audit Record and sealed with ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024. An auditor can export that record and verify the signatures offline with a public key, using third-party tools.

Does an AI system need human approval in critical national infrastructure?

In practice, yes, for anything consequential. UK GDPR Article 22 restricts decisions taken solely by automated means with legal or similarly significant effects, and CAF governance outcomes expect a named owner for risk decisions. SIOS holds consequential actions until a named person approves them, and records who approved what, when.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

From Data to Answers, Without the Data Leaving

Micky Irons — Fri, 25 Sep 2026 19:59:24 +0000

Staff can get answers from company data without that data leaving, if the model, the index and the permissions all sit on hardware the organisation owns. Retrieval happens locally, answers cite approved sources, entitlements are applied before ranking, and every consequential action is sealed in a record an auditor can verify offline.

What actually leaves the building when someone asks an AI assistant a question?

More than the question. A hosted assistant grounded in your own documents sends three things out: the prompt, the passages it retrieved from your material to ground the answer, and usually the preceding turns of the conversation. The retrieved passages are the sensitive part. A colleague typing "what did we agree on termination with this counterparty" is not sending a question offsite. They are sending the clause.

Copies then accumulate in places nobody on the deal team ever sees: the embedding index, request logs, caches, retry queues, and sometimes evaluation sets. Under the Data Protection Act 2018 and UK GDPR you remain the controller for all of it, and the ICO's security guidance expects you to know where personal data sits and who can reach it. A contractual promise that a vendor will not train on your data is a promise about training. It is not a statement about where the bytes went.

Why is the data boundary an architectural line rather than a policy?

Because a policy describes intent and an architecture describes what is possible. If a system can send your documents to a third party, then everything that stops it is a promise: a configuration flag, a contract clause, an access review, a person remembering. Promises degrade quietly and they degrade under deadline pressure.

Put the model, the index, the retrieval layer and the audit record on hardware the organisation owns, with no route to a third-party endpoint, and the property stops depending on behaviour. The NCSC's cyber security design principles make the same argument in a different register: make compromise structurally difficult, rather than instructing people to avoid it. I would rather defend a boundary a network diagram can show than a boundary a policy document asserts.

That is the line the Mickai Sovereign Intelligence Operating System is built around. It runs on the customer's own hardware, it is offline capable, and there is no data egress.

What is a company brain, and how is it different from a chatbot over a search box?

A company brain is four things held together: a model that reads, an index of your own material, the permission model of the systems that material came from, and a record of what was done with it. Remove any one of the four and you have something else, usually something that will embarrass you in an audit.

We build with 50 specialised models rather than one general one, because the material a firm actually argues about is domain-shaped. Contract language, engineering change notes, incident reports and board minutes each have their own conventions, and a model shaped for one reads the others badly.

The real difference from a search box is accountability for an answer. Search returns documents and leaves judgement with the reader. An assistant produces a claim. So the claim has to carry its sources, the version of each source, the date, and the identity of the person who asked. Without that, you have introduced an unattributable statement into a regulated process, and you have no way to reconstruct why a decision was made.

How do you stop it answering from documents the person is not allowed to read?

You apply entitlements before retrieval, not after it. The common failure is to index everything into one flat store, retrieve the best passages for the question, then filter at display time. By then the leak has already happened: the model has read material the person cannot see, and the answer it writes is shaped by it even when no sentence is quoted directly.

The correct order is to identify the person, resolve their entitlements from the source systems, restrict the candidate set to what they may lawfully read, and only then rank and answer. Entitlements are re-checked at answer time, because a person's access changes and a cached index does not notice. If someone may not open a file, they may not receive a paraphrase of it, a figure derived from it, or a hint that it exists.

This also disciplines the corpus, which is the unglamorous benefit. Material with no owner and no access model is material nobody should be answering from, and the exercise of connecting a company brain tends to find quite a lot of it.

What counts as approved knowledge, and who decides?

Approved knowledge is the subset of your material that a named person has signed off as current and answerable, with a review date attached. Everything else stays searchable by whoever owns it, but it does not get to speak for the organisation.

In practice that is three states. Draft: visible to its author and immediate team, never used to answer across the firm. Approved: carries an owner, a version and a review date, and can ground an answer. Superseded: excluded from retrieval, retained in full, still reachable when somebody needs to reconstruct what the policy was in March.

This is the dull part and it decides whether the system is trusted in month six. The failure mode of an internal assistant is rarely a dramatic invention. It is quietly answering from a procedure that was replaced two years ago, fluently, with nothing on the face of the answer to tell the reader that the grounding is stale.

How do you prove to an auditor that the data never left?

You give them something they can check without trusting you. Every consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports a record and verifies the signatures offline, with a public key, using tools that are not ours.

Be precise about what that buys, because the category is routinely oversold. The record is tamper-evident. Nothing physically prevents somebody altering an exported file. What the signature does is make the alteration fail verification, so "this is what happened" stops resting on our word or on our logs.

Alongside it, consequential actions wait for a named person to approve them before they run, and the approval is part of the record: who, when, and on what evidence. For firms inside the FCA's operational resilience expectations, that is the difference between describing a control and demonstrating one. The approach sits behind 104 filed UK patent applications carrying 2,340 claims, filed and not granted, owned by Mickai LTD.

Where does the cloud still earn its place?

Most places. I am not arguing against the companies that build the compute and cloud layer, and a regulated organisation that hauls everything back on-premises because of one class of data has overcorrected at real cost. Public-facing content, bulk non-regulated workloads, elastic capacity for work that is not sensitive: the economics there are good and the risk is manageable. The NCSC's cloud security guidance is a sensible way to make that call deliberately rather than by default.

The argument is narrower than the usual framing. It is with the assumption that a regulated organisation has no option but to rent its intelligence, ship its most sensitive material offsite, and accept a supplier's account of what happened to it afterwards. Draw the line by data class. Some work belongs inside the building, and for that work the boundary should be structural rather than contractual.

What does a first deployment actually look like?

Smaller than people expect. One department, one narrow corpus with a real owner, hardware sized for that workload, and a fortnight of asking the system questions the team already knows the answers to, because that is how trust gets earned and how the gaps in your own document estate surface.

The platform ships 14 production-ready studios at launch, with 49 more in development towards 63 in total. The closed beta is open and one regulated company is onboarding as a design partner. My advice is to start where the data boundary is already costing you something: the workflow where a useful tool is banned, or allowed only with a redaction step that somebody does by hand. Get that one working properly, and the second department will ask to be next.

Frequently asked questions

Does keeping data inside mean staff lose access to public information?

No. The boundary applies to your own material, not to the wider world. Public research, published guidance and open datasets can be brought inside deliberately, reviewed and added to approved knowledge. What changes is the direction of travel: information comes in under review, rather than your documents going out under a contract you cannot inspect.

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

A dedicated tenancy narrows who else sits on the hardware. It does not change who operates it, where the logs land, or whose account you rely on for what happened. Running on hardware you own changes the trust model itself: the operator is you, the record is yours, and an auditor can verify it without asking a supplier for permission.

What stops the assistant answering from a policy that has been replaced?

Version state. Approved knowledge carries an owner, a version and a review date, and superseded material is excluded from retrieval while being retained for audit. Answers cite the source and version used, so a reader can see at a glance whether the grounding is current rather than trusting the fluency of the reply.

Is the Open Audit Record tamper-proof or tamper-evident?

No, and we do not claim it is. It is tamper-evident. Each consequential action is sealed with ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024. Anyone can alter an exported record, but the alteration makes verification fail, which is the property an auditor actually needs in practice.

Which organisations is this built for?

Regulated ones: finance, law, defence, public sector, manufacturing, energy and professional services. The common factor is obligation rather than size. If you have to evidence where data went, who approved an action and what that action was based on, the boundary has to be architectural rather than contractual. The closed beta is open now.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

Keeping Oversight as AI Scales Across a Business

Micky Irons — Fri, 25 Sep 2026 19:59:06 +0000

You keep oversight by making it structural, not procedural. Every consequential action waits for a named person to approve it, every approval and refusal is written to a signed record, and permissions decide who may approve what. Sampling reviews fail at scale. A complete, independently verifiable record does not.

Why does oversight break down when AI moves from one team to the whole organisation?

Oversight breaks because the method that worked in a pilot does not survive multiplication. In a pilot, one team watches one system and a person reads most of what it produces. That is genuine supervision. Run the same method across forty teams and several thousand actions a day and it becomes a spot check wearing the clothes of control.

I have watched this sequence run in the same order more than once. The pilot succeeds. The organisation approves a wider rollout. Review meetings that once covered every case start covering a sample. The sample shrinks, because the people running it are measured on throughput. Within two quarters nobody can answer a plain question: who approved this, and what did they see when they approved it?

The root cause is that the oversight was procedural. It lived in a meeting, a rota, a spreadsheet of reviewed cases. Procedures degrade under load. Structure does not, because the system will not proceed without it.

So the question is not how to supervise more. It is what to make structural, so supervision does not depend on one person's diligence on a busy Thursday.

What does per-action approval actually mean in practice?

It means the system stops before a consequential action and waits for a named person. Not a role, not a queue, not a service account: an identified individual who saw the specific action and said yes.

In the Mickai Sovereign Intelligence Operating System, every action is classified before it runs. Drafting a summary, retrieving a document, comparing two versions of a contract: reversible and internal, so they run. Sending an external communication, writing to a system of record, releasing a payment instruction, changing a permission, moving data across a boundary: consequential, so they hold.

When an action holds, the approver sees three things. What the system intends to do. What it relied on to decide that. What follows if it proceeds. The approval then carries the approver's identity, the time, and the exact content approved. If that content changes afterwards, the approval is void and the action holds again.

That rule matters more than it sounds. Most oversight theatre comes from approving something in general and letting the specifics drift afterwards.

Per-action approval has a cost. It puts a person in the path of work that would otherwise be instant. The honest position is that you choose where to pay that cost. Which actions count as consequential is a business decision, set by the organisation rather than by us, and the threshold itself is an auditable setting. Change it, and the change is recorded with the name of whoever made it.

Is sampling enough, or do you need a complete record?

Sampling tells you about the sample. A complete record tells you about the population. At pilot volumes the difference is academic. At organisational scale it is the entire argument.

Think about what a regulator, an auditor or a claimant's solicitor actually asks for. They do not ask whether your process is sound on average. They ask about one decision, on one date, affecting one person or one counterparty. If you sampled, and that decision fell outside the sample, you do not have a weak answer. You have no answer.

This is why the Open Audit Record in SIOS is complete rather than representative. Every consequential action produces an entry: the action, the inputs it relied on, the studio that produced it, the person who approved or refused it, and the time. Nothing is summarised away, and nothing is dropped when volume rises.

Sampling still has a job. It is how you spot quality drift and workflows that have quietly stopped working. It is a management tool, not an evidential one.

The ICO's guidance on AI and data protection is direct about accountability having to be demonstrable, with records of processing and of decision logic forming part of that demonstration (ICO). Where a decision produces legal or similarly significant effects, UK GDPR rights on automated decision-making call for meaningful human involvement rather than a nominal sign-off (ICO). "We reviewed ten per cent" says nothing at all about the other ninety.

How do roles and permissions stop approval becoming a rubber stamp?

They stop it by fixing who may approve what inside the system, rather than inside a training deck. A person can approve only actions that fall within their own authority. Outside it, the action escalates or fails. It is not designed to proceed silently, and any escalation is written to the record with the name of whoever handled it.

Two separations do most of the work. The person who configures a workflow should not be the person who approves its outputs. The person who approves an action should not be the person able to edit the record of that approval. Neither is new. Both are ordinary segregation of duties, applied to a system working at a pace no rota can follow.

For firms in scope of the FCA's Senior Managers and Certification Regime, accountability is already mapped to named individuals with documented responsibilities (FCA). Approval rights should mirror that map rather than invent a parallel one that nobody has signed.

The practical cause of rubber stamping is volume plus ambiguity. An approver facing four hundred near-identical requests with no context will click through them, and would be irrational not to. The fix is to hold only what genuinely warrants holding, and to give the approver enough context to make a real judgement in seconds. Fewer, richer decisions produce better oversight than many empty ones.

How do you prove oversight happened months later, to someone who does not trust you?

You hand them a record they can verify without you. That is the only form of proof that survives an adversarial setting: a dispute, an investigation, a claim, a change of supplier.

Every Open Audit Record entry is sealed with ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024 (NIST). Entries are chained, so an entry's position in the sequence is covered by the seal along with its contents. Export the record, hand over the public key, and the other side verifies it offline using standard tooling that is not ours and that we cannot influence.

Be precise about what that gives you. The record is tamper-evident, not tamper-proof. Nobody can stop a sufficiently privileged person from altering bytes on a disk. What the seal provides is that any alteration makes verification fail, visibly, at an identifiable point in the chain. That is the property worth having. A record that claims it cannot be changed is asking you to trust the claim. A record that reveals when it has been changed asks you to trust nothing.

Traceability of this kind is treated as part of secure operation rather than an optional extra in the NCSC's guidelines for secure AI system development (NCSC), and the accountability duties behind it sit in the Data Protection Act 2018 (legislation.gov.uk).

All of it runs on hardware the organisation owns. The system is offline capable, with no data egress, so the evidence of oversight lives in the same building as the decisions it describes.

What should you ask a vendor before scaling AI across the business?

Ask five questions, and insist on demonstrations rather than assurances.

Which actions stop for a human, and who decides that list? If the vendor decides, you have outsourced your own risk appetite.
Is the audit record complete or sampled? Name a single action on a single day and watch how it is retrieved.
Can a third party verify an exported record with the vendor absent and the system switched off?
Do approval rights map to your existing accountability map, and can anyone approve their own configuration?
Where does the data physically sit while all of this happens?

A vendor that answers all five without hedging is offering oversight. One that answers with a dashboard is offering visibility, which is a weaker and quite different thing.

None of this is an argument against the cloud. For work that is not regulated, renting compute remains a sensible way to buy it, and the companies building that layer are doing hard engineering well. The argument is narrower. Where a decision has to be defended years later, oversight cannot be a report you receive. It has to be a property of the system, and the record of it has to be yours.

Mickai LTD is a UK company, Companies House 17166618, held privately by its founder. SIOS ships with 63 studios, 14 production-ready at launch and 49 in development, supported by 50 specialised models. The architecture behind the approval and audit design sits inside 104 filed UK patent applications carrying 2,340 claims: filed, not granted. The closed beta is open, with one regulated company onboarding as a design partner.

Frequently asked questions

What counts as a consequential action?

A consequential action is one that changes something outside the system or is hard to reverse: sending an external communication, writing to a system of record, releasing a payment instruction, changing a permission, or moving data across a boundary. Your organisation sets that list, not the vendor, and any change to the list is itself recorded against a named person.

Does per-action approval slow the business down?

It slows the actions you chose to slow, and nothing else. Reversible internal work runs without interruption. The cost is real, so the answer is to hold only what genuinely warrants a decision and give the approver enough context to judge it in seconds. Holding everything produces rubber stamping, which is slower and worth considerably less.

Can you keep human oversight if the system runs offline?

Yes, and offline operation makes it easier. SIOS runs on hardware the organisation owns, with no data egress, so approvals, refusals and the audit record all stay inside your own boundary. Nothing depends on a supplier's availability or retention policy. The evidence of oversight sits in the same place as the decisions it describes.

Is a complete audit record the same as application logging?

No. Logs are written for engineers, are usually rotated or sampled, and can be edited by anyone with sufficient access. The Open Audit Record is written for evidence: complete, chained, and sealed with ML-DSA-65, published by NIST as FIPS 204 in 2024. It is tamper-evident, meaning alteration makes verification fail rather than being prevented.

Who verifies the record, you or us?

You do, or a third party you choose. Export the record, take the public key, and verify the signatures offline using standard tooling that is not ours. We cannot influence the result. That matters most in exactly the situation where our word would count for least: a dispute, an investigation, or a change of supplier.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

A Demo Is Not a Handover: Why AI Pilots Stall

Micky Irons — Fri, 25 Sep 2026 19:58:53 +0000

Because a demo proves a model can produce an output, and a deployment must prove the whole system: real data under real permissions, integration with systems of record, evidence of what happened, and a named owner after the vendor leaves. Those four things are rarely in scope when the demo is built.

I have sat in both chairs. I have given the demo, and I have been the person who had to make the thing work on the Monday after everyone agreed it was impressive. The two jobs have very little in common, and the distance between them is where enterprise AI budgets quietly disappear.

What does a demo actually prove?

A demo proves one narrow claim: given clean input and a well-chosen question, a system can produce an output that a person recognises as useful. That is worth knowing. It is also a small fraction of what a deployment has to be true about.

Demos are built backwards. You already know the answer you want on the screen, so you choose the documents that produce it, you phrase the question the way the system handles best, and you run it on a machine with no network policy, no access control and no retention rules. None of that is dishonest. It is simply a different exercise. A demo is an argument about capability. A deployment is an argument about an organisation.

The failure is not that the demo misled anyone. It is that everyone in the room assumed the remaining work was engineering measured in weeks, when most of the remaining work is not engineering at all.

Why does real data break what the demo hid?

Because demo data is curated and production data is archaeology. Point the same system at the actual file share and you meet scanned documents with no text layer, four spellings of the same counterparty, a decade of superseded templates and the spreadsheet everyone knows is the real system of record.

That is the easy half. The harder half is that real data carries obligations. If personal data is in scope you need a lawful basis, a defined purpose, a retention position and a record of how you reached each of those, and you need to be able to show the reasoning rather than assert it. The ICO's guidance on AI and data protection is clear that accountability sits with the organisation deploying the system, not with whoever supplied the model (ICO). The underlying duties come from the Data Protection Act 2018 (legislation.gov.uk).

Nobody asks those questions of a demo, because a demo touches nothing that matters. They all arrive in week one of a deployment, usually from a person who was never invited to the demo.

Who is allowed to see what, and can you prove it afterwards?

A demo runs as one user with unrestricted access. A deployment runs as hundreds of users whose entitlements already exist in other systems, and the assistant has to inherit them exactly.

In my experience this is the most common reason a working pilot gets stopped. If the system can read a folder that the person asking cannot, you have not built an assistant: you have built a search box over your access controls. Entitlements live in the directory, in the matter management system, in the case system, in the finance ledger, each with its own idea of what a user is. Reconciling them is slow, political and unglamorous, and it cannot be deferred. The NCSC's guidelines for secure AI system development run from secure design through to secure operation and maintenance, which is a useful reminder that access is a lifecycle question and not a task for the week before go-live (NCSC).

Why does integration eat the timeline?

Because the value sits behind systems that were never designed to be read by software, and touching them is a controlled change. The demo read a folder. The deployment has to read the document management system, write back to the ledger, respect a freeze window and pass a change advisory board.

Each connection brings a service account somebody must own, a rate limit, a test environment three versions behind, and a supplier whose contract says nothing about AI. In a regulated firm, every one of those is a change request with a named approver and a queue in front of it. I would rather tell a buyer that at the start than have them discover it in month four with the budget already committed.

What evidence does an auditor need that a demo never produces?

An auditor needs a record: what was asked, which data was used, what the system did, who approved it, and proof that the record has not been altered since. A demo produces a screen and somebody's memory of it.

This is the part we built first rather than last. In the Mickai Sovereign Intelligence Operating System, every consequential action is sealed in an Open Audit Record under ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024 (NIST). The record is tamper-evident: alter it and verification fails. An auditor can export a record and verify it offline with a public key, using tools that are not ours. That last clause is the whole point. Evidence you can only check inside the supplier's own product is not evidence, it is a claim.

The other half is approval. Consequential actions wait for a named person to approve them. A system that acts and then explains is a very different object from a system that proposes and waits, and only one of the two survives a serious conversation about control.

Who owns the system once the vendor goes home?

In most stalled deployments, nobody does. That answer has to exist before the pilot starts, and it has to name a person in the business, not a team in IT.

Ask where the model runs. Ask who can restart it at three in the morning, who approves a change that affects a regulated output, and what happens if the supplier stops trading. Firms stay accountable for their own resilience even where a critical third party is involved: the FCA is explicit that the critical third party oversight regime does not change the accountability of firms (FCA). An exit position you could actually execute follows from that. Renting intelligence from an endpoint you cannot inspect makes every one of those questions harder to answer honestly.

That is why SIOS runs on hardware the customer owns, offline capable, with no data egress. Not because the cloud is bad: it stays valuable for work that is not regulated. It is because ownership of the running system is the thing that turns a demo into a deployment, and you cannot own what you can only reach through somebody else's endpoint.

What should you ask for instead of a demo?

Ask for two weeks on your data, in your environment, under your rules. Concretely: run it against a real corpus including the ugly parts nobody cleaned; run it as three genuine users with their existing entitlements and confirm each sees only what they should; take one consequential action and make it wait for a named approver; export the audit record and verify it with a tool the supplier did not write; name the internal owner and the exit position before anyone signs anything.

If a supplier cannot survive that, the demo was the product.

We are building for the organisations that have to answer those questions anyway: finance, law, defence, public sector, manufacturing, energy and professional services. SIOS has 63 studios, 14 production-ready at launch and 49 in development, with 50 specialised models behind them. Mickai LTD is a UK company (Companies House 17166618), held privately by me. MICKAI is a registered UK trade mark, UK00004373277, and we hold 104 filed UK patent applications carrying 2,340 claims, filed and not granted. The closed beta is open, with one regulated company onboarding as a design partner.

None of that makes a deployment easy. It makes the hard parts visible early, which is the only version of easy available here.

Frequently asked questions

Why do so many AI pilots stall before production?

Because a pilot tests capability and production tests the organisation. Real data is messy and carries legal obligations, user entitlements live in other systems, integrations are controlled changes, and someone internal has to own the result. A pilot that skipped those four is not nearly finished: it has not started the part that takes the time.

How long should a proper AI evaluation take?

Long enough to run on real data under real permissions, which usually means weeks rather than an afternoon. Two weeks on your own corpus, as three genuine users with their existing entitlements, tells you more than six polished demos. If a supplier needs your data cleaned before they can start, you have already learned something useful.

What is the Open Audit Record and why does it matter?

It is the evidence layer in SIOS. Every consequential action is sealed under ML-DSA-65, the post-quantum signature scheme published by NIST as FIPS 204 in 2024. The record is tamper-evident: alter it and verification fails. An auditor can export it and check it offline with a public key, using tools we did not write.

Does running AI on our own hardware really change the risk?

It changes who holds the risk. When the system runs on hardware you own, offline capable with no data egress, your data does not leave your estate and you control restarts, updates and exit. The cloud remains sensible for work that is not regulated. The difference matters most when a regulator asks where the data went.

What should be agreed before a pilot starts?

A named internal owner, the exact data in scope and its retention position, the entitlement model the system must inherit, which actions require a named human approver, how audit records are exported and verified independently, and what happens on exit if you walk away. Settling this before the pilot is far cheaper than settling it afterwards.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

What does people-led AI mean in practice?

Micky Irons — Fri, 25 Sep 2026 19:58:35 +0000

People-led AI means a named person approves every consequential action before it takes effect, and the record shows who approved what, when and on what evidence. The system retrieves, drafts and proposes at full speed. A human decides. Accountability stays with that person, because it cannot be transferred to a model.

I have the same conversation with regulated buyers most weeks, and it stalls at the same point. Everyone can see what the technology drafts. Nobody can say who is answerable once a draft becomes an action. People-led AI is the answer we built into the Mickai Sovereign Intelligence Operating System, and it is an architectural commitment rather than a slogan. The system does the preparation. A named person authorises anything consequential. The record of that authorisation outlives the supplier, including us.

Why can accountability not transfer to a model?

Because there is nobody to hold. Accountability in UK regulation attaches to organisations and, in financial services, to named individuals under the Senior Managers and Certification Regime. A model cannot hold a senior management function, cannot be interviewed by a supervisor and cannot be sanctioned.

Data protection works the same way. The controller remains responsible for an outcome however it was produced, which is why the ICO's guidance on automated decision-making and profiling turns on whether human involvement was meaningful rather than whether a human was technically present. Someone who clicks approve without seeing the evidence has not supplied oversight. They have supplied a signature.

So the buying question is not whether a system is capable enough to act alone. It is who signs, and whether that person could defend the decision a year later. If they cannot see what the system was about to do, why it proposed that, and what it relied on, the accountability is fictional. Our design starts by refusing that fiction.

What counts as a consequential action?

An action is consequential when it leaves the organisation or changes a record that other people rely on. Sending a client communication. Filing a submission. Amending a case or customer record. Releasing a document to a third party. Granting access to a system. Committing money. Each of those waits for a named approver before it takes effect.

Everything upstream runs at full speed. Retrieval across internal documents, extraction, comparison, summarisation, drafting, analysis: none of it needs permission, because none of it is visible outside the team and all of it is reversible. The test I apply when we classify a new action in a studio is deliberately plain. If this turned out to be wrong, would somebody outside this room be affected, or would we have to explain ourselves to a regulator, a client or a court? If the answer is yes, it waits.

That line is worth drawing explicitly during procurement, because it is where systems differ most and where suppliers describe themselves most vaguely. Ask where it sits in anything you are evaluating, and ask who is able to move it.

How is an approval recorded so it can be checked later?

In the Open Audit Record. Every consequential action is sealed to it using ML-DSA-65, a parameter set of the post-quantum signature scheme NIST published as FIPS 204 in 2024. The sealed entry carries the action, the inputs it relied on, the model version that produced it, the hardware identity it ran on, the named person who approved it and the moment they did.

What matters is what happens afterwards. An auditor exports the record and verifies it offline with a public key, on a machine we have never touched, using tools that are not ours. An audit trail you can only read inside a supplier's console is a claim about the past. A record a third party can verify without that supplier is evidence about the past. Those are different things, and only one of them holds up in a dispute.

The OAR is tamper-evident, and that word is chosen carefully rather than out of modesty. Nothing about it stops a determined administrator altering a file. Altering the file breaks the signature, so verification fails and the alteration announces itself. Tamper-evidence is the honest property to claim, and it is the one an auditor can actually test.

Does putting a person in the loop slow the work down?

Less than buyers expect, because approval is the only step the person keeps. The system reaches the decision point with the draft written, the sources cited, the exceptions flagged and its reasoning stated in plain terms. The approver reads a prepared case instead of assembling one. Related items queue together, so somebody clears a batch in a single sitting rather than being interrupted repeatedly through the day.

Set that against how regulated teams work now, where a qualified professional does the assembly as well as the judgement, and in the teams I work with the assembly takes far longer than the judgement does. We are removing the assembly. We are deliberately not removing the judgement. The same rule holds across all 63 studios in SIOS, the 14 that are production-ready at launch and the 49 in development: prepare completely, then stop and ask.

How is this different from full autonomy?

The difference is ordering, and ordering is everything. A fully autonomous agent acts and leaves you to reconstruct the reasoning afterwards. People-led AI puts the decision before the effect, so no reconstruction is needed. Autonomy fails open, because the action has already landed by the time anyone notices. This fails closed, because nothing consequential happens while a person is absent and the work waits instead.

It also differs from the weaker versions of oversight now in circulation. A reviewer who cannot see the evidence is a rubber stamp. A log the supplier can regenerate is not an audit trail. A system that pauses for approval only when its own confidence is low has decided for itself where accountability applies, which is exactly the judgement a regulated organisation cannot delegate. I would rather build a system that proposes and waits than one that acts and explains afterwards, because only the first of those leaves a person in a position to say no.

The test of people-led AI is simple: when something goes wrong, a named person can be identified, and the evidence they saw can be reproduced by somebody who has no reason to trust us.

What does UK guidance expect of human oversight?

It expects oversight to be real, informed and documented. The ICO's guidance on AI and data protection places responsibility on the organisation deploying a system rather than on whoever supplied the model. Its position on solely automated decisions with legal or similarly significant effects rests on meaningful involvement by a person with the authority and the information to change the outcome, and the Data (Use and Access) Act 2025 changes how that regime works without removing the expectation that a person can intervene. The NCSC's guidelines for secure AI system development push the same way, treating logging, provenance and the ability to investigate an incident as design requirements rather than later additions.

None of that is satisfied by an interface with an approve button on it. It is satisfied when the approver sees the evidence, when the approval is bound to their identity, and when the whole sequence can be produced months later in a form somebody else can check. Sector rules add their own weight: firms supervised by the FCA and the PRA carry individual accountability, and every organisation processing personal data carries duties under the Data Protection Act 2018. The common thread is that a named human stays answerable.

What should a buyer ask a supplier to prove?

Five questions separate architecture from marketing. Which actions require human approval, and who is able to change that list? Is the approver's identity cryptographically bound to the action, or only written into a log? Can the audit record be verified offline, by us, using tools you do not supply? What exactly breaks if the record is altered? And can the whole system run on hardware we own, with no data leaving the building?

We built SIOS so that each of those answers is demonstrable rather than asserted. It runs on the customer's own hardware, offline capable, with no data egress, and 50 specialised models sit behind the studios. Mickai LTD is a UK company (Companies House 17166618) holding 104 filed UK patent applications that carry 2,340 claims across this architecture, filed and not granted, with the audit record and the approval model among them. The full architecture is set out at /sovereign-ai, and the closed beta at /beta is open, with one regulated company already onboarding as a design partner.

None of this makes AI simpler to adopt. It makes the accountability legible, which is the condition a regulated organisation has to meet before anything else is worth discussing.

Frequently asked questions

Does people-led AI mean a person has to check every output?

No. Retrieval, drafting, extraction, summarisation and analysis run without interruption, because that work is reversible and stays inside the team. Approval is reserved for consequential actions: anything that leaves the organisation, changes a shared record, grants access or commits money. The aim is to remove the assembly work, not the professional judgement.

Can an AI system be held accountable for a decision instead of a person?

No. Under UK regulation accountability attaches to the organisation and, in financial services, to named individuals under the Senior Managers and Certification Regime. A model cannot hold a senior management function, be questioned by a supervisor or be sanctioned. Data protection duties also stay with the controller, whatever produced the output.

What is the difference between human in the loop and people-led AI?

Ordering and evidence. Human in the loop often means a person could intervene in principle. People-led AI means the consequential action cannot take effect until a named person approves it, and that the approval, the evidence they saw and the model version are sealed into a record an auditor can verify independently later.

How do I prove to an auditor that a person approved an action?

Export the Open Audit Record and verify it offline with a public key, using tools the supplier does not provide. Each entry is sealed with ML-DSA-65, published by NIST as FIPS 204 in 2024, and carries the action, its inputs, the model version, the hardware identity and the named approver. Altered entries fail verification.

Does people-led AI still work if the system runs offline?

Yes, and it is designed that way. The Mickai Sovereign Intelligence Operating System runs on hardware the customer owns, offline capable, with no data egress. Approvals, identities and the sealed audit record are all local, so an air-gapped installation loses no oversight and the record still verifies on a separate machine.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

How Sovereign AI Integrates With Your Existing Systems

Micky Irons — Fri, 25 Sep 2026 19:58:22 +0000

On-premise AI integrates through explicitly configured connections: each system is named, scoped and approved before anything is read. Nothing is discovered automatically. Connections run inside your network to your identity provider, file stores, databases and line-of-business applications. In fully air-gapped sites, data moves on controlled media instead, and everything still works offline.

The integration question usually decides whether an on-premise system gets bought. Everything else can be settled on paper. Whether it will actually talk to the case management system, the document store, the ERP and the directory that already runs your building is an engineering question, and IT leads are right to press it first.

I will answer it the way I would in a technical session: what connects, how the connection is made, what happens when there is no network at all, and what it leaves behind in your audit trail. Mickai is a Sovereign Intelligence Operating System (SIOS), running on hardware you own, offline capable, with no data egress. That changes the shape of the problem. Integration stops being a data export exercise and becomes ordinary internal networking, inside a boundary you already control and already monitor.

Does sovereign AI replace the systems we already run?

No. It sits beside them and reads from them under permission you grant. Nothing is migrated, nothing is re-platformed, and your systems of record stay exactly where they are.

This is the part buyers most often get wrong when they first scope it. They assume that owning the intelligence layer means a rip-and-replace programme touching every application in the estate. It does not. What changes is that a local model can read from those systems, draft against them and hand work back, without any of the content leaving the building. A first deployment should connect to three or four systems, not thirty. You pick the ones where the work actually is, prove the pattern, then widen it on your own schedule.

How does an on-premise system connect to the applications we already use?

Through connections that a named administrator configures explicitly, one at a time. There is no discovery mode, no crawler, and no default access to anything.

Each connection is defined by four things: the endpoint it may reach, the credential it uses, the scope that credential is limited to, and the person who approved it. Anything not on that list is refused, because the perimeter denies by default in both directions. This matters more than it sounds. A system that can enumerate your network has a blast radius nobody can state in a risk paper. A system that reaches a fixed, named list of endpoints is one your security team can reason about, segment and monitor with the tooling they already run. That is the model the NCSC sets out in its secure design principles: make the compromise of one component hard to turn into the compromise of everything else.

Typical first connections are the identity provider, a file share or document store, a database read replica, mail and calendar, and one or two line-of-business applications over the APIs they already expose. All of it stays inside your network segment. None of it traverses the public internet, because there is no outbound path with which to traverse it.

What if we are fully air-gapped?

Then nothing connects live, and the system still works. An air-gapped deployment takes data in as controlled batch imports on approved media, and hands evidence back out the same way.

Defence and parts of the public sector already run this way for other systems, so the process is familiar: an export is produced in the connected estate, scanned and signed, moved across the gap under a documented procedure, then verified before it is loaded. Software and model updates arrive on the same path, as signed offline packages checked before they run. The point for an IT lead is that air-gapped is not a degraded mode here. The system is built to run with no outbound connection at all, so the only thing the gap changes is the cadence at which fresh data arrives, from continuous to whatever your transfer procedure allows. Air-gapped operation is the assumption the architecture starts from, not a mode bolted on afterwards.

Does our data have to be copied into the model?

No. Documents and records are read where they sit, and any index built to make retrieval fast lives inside the same boundary as the source, on your hardware, under your backup and deletion policy.

Your material is not used to train anything unless you decide it should be, and if you do, that training runs locally on your own machines and the resulting weights are yours. When a record is deleted at source, the derived index entry goes with it, because both sit on kit you own. This is what data protection by design looks like in engineering rather than in a policy document: minimisation, purpose limitation and a straight answer to "where is it" become properties of the architecture instead of promises in a contract (ICO). The duties in the Data Protection Act 2018 and UK GDPR are far easier to evidence when the data never moved.

How does it fit our identity provider and existing permissions?

It inherits them. The system authenticates against the directory you already run, over the protocols you already use, and never gives a person more access than they already have.

Integration here means SAML or OIDC for sign-on, and LDAP or Kerberos where that is what the estate runs. Groups and roles map across, so the permission model your organisation spent years getting right is the permission model the assistant obeys. If someone cannot open a document in the source system, retrieval returns nothing for them, rather than a summary of something they were never entitled to see. Test that during acceptance with a deliberate negative case: a restricted folder, a user outside the group, and a question whose answer sits inside that folder. The correct result is that the system finds nothing and says so.

What about systems with no modern API?

Then you connect at whatever level the system does support, which is usually more than people expect. A read-only database view, a scheduled export onto an internal file share, an SFTP drop or a fixed report format are all ordinary integration surfaces, and all of them work.

Where a system offers nothing, the fallback is the document itself. A great deal of what regulated organisations run on still arrives as PDFs, scanned forms, spreadsheets and letters, and reading those accurately is a first-class capability rather than a workaround. The fastest path to value is often not an API project at all: point the system at the shared drive where decades of contracts, policies and case files already live, and let people ask questions of them.

What does integration leave in the audit record?

A verifiable record of every consequential thing that happened, including which system supplied which record and which named person approved the action.

Each consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor can export a record and verify it offline with a public key, using tools that are not ours. The record is tamper-evident. Altering an entry does not become impossible, it becomes detectable, because verification fails. We signed with a post-quantum scheme rather than a classical one because audit evidence has to outlive the cryptography protecting it, which is the substance of NCSC guidance on preparing for post-quantum cryptography.

Consequential actions also wait for a named person to approve them before they execute. Nothing consequential happens because a model decided on its own that it should. For firms working to FCA and PRA expectations on operational resilience and third-party risk, that is the useful half of integration: the evidence of what a system did with your data is produced by the system, not reconstructed by hand afterwards.

Who does the integration work, and how long does it take?

Your team and ours together, and it is measured in weeks rather than quarters. Integration is one stage of a deployment planned at eight to sixteen weeks end to end, and it is rarely the long pole.

The work splits cleanly. Your side supplies the endpoints, service accounts, scopes and approvals, because only you can say what a connection should be allowed to see. Our side configures each connector and proves it against a test case before it goes near production data. The sizing conversation worth having early is a short one: name the three systems where the work actually lives, say what a user of each is entitled to see, and say whether the site is connected or air-gapped. Those three answers settle most of the integration plan.

Mickai LTD is a UK company, Companies House 17166618, held privately by its founder, Micky Irons. MICKAI is a registered UK trade mark, UK00004373277. The design is covered by 104 filed UK patent applications carrying 2,340 claims, filed and building toward examination, not granted. SIOS comprises 63 studios in total, 14 production-ready at launch and 49 in development, backed by 50 specialised models. The closed beta is open, with one regulated company onboarding as a design partner.

Frequently asked questions

How does on-premise AI integrate with existing business systems?

Through explicitly configured connections. An administrator names each endpoint, credential, scope and approver before any data is read, and anything outside that list is refused. Typical first connections are the identity provider, a document store, a database read replica and one or two line-of-business applications, all inside your own network segment with no outbound path to the internet.

Can an air-gapped AI system still integrate with our data?

Yes. With no live connection, data arrives as controlled batch imports on approved media and evidence leaves the same way. Software and model updates travel as signed offline packages, verified before they run. Air-gapped is not a degraded mode: the system is designed to run with no outbound connection, so only the refresh cadence changes.

Does integration require copying our data into the AI?

No. Records are read where they sit, and any retrieval index lives inside the same boundary as the source, on hardware you own, under your own backup and deletion policy. Your material trains nothing unless you decide otherwise, and when a record is deleted at source, the derived index entry goes with it.

How does on-premise AI handle our existing user permissions?

It inherits them from the directory you already run, using SAML, OIDC, LDAP or Kerberos. Groups and roles map across, so the system never grants a person more access than they already hold. If someone cannot open a document in the source system, retrieval returns nothing for them rather than a summary of it.

What happens if one of our systems has no modern API?

You connect at whatever level it does support: a read-only database view, a scheduled export onto an internal file share, an SFTP drop or a fixed report format. Where a system offers nothing at all, the documents themselves become the integration surface, because PDFs, scanned forms, spreadsheets and letters are read directly.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

AI for Professional Services Firms: Confidentiality First

Micky Irons — Fri, 25 Sep 2026 19:57:51 +0000

A professional services firm can use AI without risking client confidentiality by keeping the work inside a boundary the firm controls: run the system on hardware you own, scope retrieval to each engagement so conflicts walls hold, require a named person to approve anything consequential, and keep a tamper-evident record an auditor can verify independently.

What actually happens to client data when a firm uses a hosted AI tool?

It leaves your control, and it may leave the country. When a fee earner pastes a draft share purchase agreement, a client board pack or a set of management accounts into a hosted assistant, that material travels to infrastructure someone else owns, is processed under terms your firm did not write, and may be retained or routed through sub-processors you have never assessed.

That is a data protection problem before it is an AI problem. Under the UK GDPR and the Data Protection Act 2018 your firm remains the controller for client personal data and carries accountability for every processor in the chain. The ICO guidance on AI and data protection is specific about what that requires: a lawful basis, transparency, and a documented assessment of the risk before deployment rather than after it.

It is also a confidentiality problem that sits entirely outside data protection. Most of what a professional services firm handles is commercially sensitive rather than personal: deal terms, financial models, dispute strategy, tender pricing, drawings that have not been filed. A data processing agreement covers none of it. Your duty of confidence to the client does, and that duty does not soften because the disclosure was convenient.

Does your engagement letter actually permit it?

Usually not, and this is the cheapest thing to check first. Standard confidentiality wording permits disclosure to named individuals, to identified subcontractors, and to advisers the client has approved. A general purpose hosted assistant is none of those, so using one is a disclosure you never obtained permission for.

There are two honest routes out. You renegotiate terms with every client, name the processor, and accept that some clients will refuse. Or you keep the processing inside your own boundary, in which case no disclosure to a third party occurs and the question does not arise. The second route is the one that scales, because it does not require you to go back to a thousand clients and ask.

Clients in regulated sectors are increasingly writing their own restrictions into your terms rather than waiting for yours. I have read supplier questionnaires that ask where model inference physically happens, which sub-processors touch the material, and whether the firm can produce evidence after the fact. A firm that cannot answer those three is at a disadvantage before the evaluation starts.

How does an AI system stay on the right side of a conflicts wall?

It has to inherit the barriers you already operate, and it has to prove that it did. An information barrier works because access is scoped to a matter and denied by default everywhere else. The moment you index every document in the firm into a single retrieval store, you have built a machine that will cheerfully summarise the other side's file.

The control is boring and it works. Retrieval scope is bound to the engagement, not to the user's curiosity. Identity comes from the directory you already run, so retrieval runs under the user's own permissions: material a person is not cleared to open is not put in front of them. Every retrieval is recorded together with the documents that were in scope at the time.

That last part matters more than most firms expect. When a conflict allegation arrives eighteen months later, the useful answer is not that your policy prevented it. The useful answer is a record showing which files were reachable, by whom, on what date.

What will an insurer, a regulator or a client's auditor want to see?

Evidence, not assurances. Assume your professional indemnity insurer will ask how AI is used in the delivery of advice, and assume that being able to show your working will matter at renewal.

This is the part we built the system around. In the Mickai Sovereign Intelligence Operating System, every consequential action is sealed in an Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The record is tamper-evident: altering it makes verification fail. An auditor can export a record and verify it offline with a public key, using tools that are not ours, which is the only kind of proof worth offering.

Consequential actions also wait. Nothing reaches a client, a court, a regulator or a counterparty until a named person approves it, and that approval is part of the sealed record.

What changes when the system runs on hardware the firm owns?

The boundary moves back to where your professional duty already sits. SIOS runs on hardware the customer owns, is capable of running entirely offline, and does not send data out. Whatever the system reads stays on your equipment, which means the confidentiality analysis becomes the same one you already apply to your document management system.

I want to be careful about what I am arguing. I am not against the companies that build the compute and the cloud layer, and for a great deal of work the cloud remains the right answer. What I am against is the assumption that a regulated firm must rent its intelligence, ship privileged material offsite, and take a vendor's word for what happened to it afterwards.

The system ships as studios: focused workspaces for drafting, document reading, research, review, records and scheduling. There are 63 in total, 14 production-ready at launch and 49 in development, drawing on 50 specialised models we call brains. A firm switches on the few that match its work rather than buying a platform most of which it will never open.

Which work should a firm hand over first?

The work that is high in volume, low in ambiguity, and reversible before it reaches a client. Reading a bundle of contracts and producing a schedule of the key terms. Pulling figures out of a client's records into a working paper that cites the source page for every number. First-pass drafting from your own precedent bank rather than from the open internet. Preparing a record of a meeting and the actions agreed in it. Checking a tender response line by line against the requirements matrix.

The pattern underneath all of those is the same. The system reads and assembles, and a qualified person decides. That is also how liability stays where your regulator and your insurer expect it to sit, with the named individual who signed the advice rather than with a supplier's terms of service.

What I would not start with is anything that goes straight out of the door. Advice to a client, a statutory filing, an audit opinion, a signed certificate: put those behind an approval step on day one and keep them there long after the system has earned some trust. Most of the cost in professional work is the reading that comes before the judgement, not the judgement itself. That is the part worth giving away.

Where should a firm start?

With one workflow, one named owner and a written boundary. Take a single task from the list above, put a partner's name against it, and write down exactly what material is permitted to leave your premises. In most firms the correct answer to that last question is nothing at all.

Then write the evidence requirement into procurement before you evaluate anything. Ask any supplier to produce a record of one specific action, exported, and verified using a tool the supplier does not control. The NCSC guidelines for secure AI system development are a sensible structure for the rest of the assessment, and an ICO data protection impact assessment belongs before deployment, not alongside it.

Mickai LTD is a UK company, number 17166618, held privately by me. MICKAI is a registered UK trade mark, UK00004373277. We hold 104 filed UK patent applications carrying 2,340 claims, filed and not granted, with me as the named inventor. The closed beta is open, and one regulated company is onboarding as a design partner. If your firm's problem is that the work is confidential and the tools are not, that is the problem the system was built for.

Frequently asked questions

Can a professional services firm put client documents into a public AI chatbot?

Not without permission. Pasting client material into a hosted assistant is a disclosure to a third party, and most engagement letters do not cover it. You also take on accountability under the UK GDPR and the Data Protection Act 2018 for a processor you have never assessed. Keep the material inside a boundary your firm controls.

Do we need to change our engagement letters before using AI on client work?

It depends where the processing happens. If client material leaves your infrastructure, treat it as disclosure to a third party, update your terms, and name the processor and the location. If the system runs on hardware you own and nothing leaves the building, no third-party disclosure occurs and existing wording usually holds. Take your own legal advice.

How do you prove what an AI system actually did on a client matter?

With a record the client's auditor can verify without trusting you. In SIOS every consequential action is sealed in an Open Audit Record signed under ML-DSA-65, the post-quantum scheme NIST published as FIPS 204 in 2024. It is tamper-evident: any alteration makes verification fail. The record exports and can be checked offline with a public key.

How does AI respect conflicts of interest and information barriers?

By inheriting the barriers you already run rather than working around them. Retrieval is scoped to the engagement, identity comes from your existing directory, and access is denied by default. Retrieval runs under the user's own permissions, so material they are not cleared to open is not put in front of them, and every retrieval is recorded with the documents that were in scope.

What should a firm ask an AI supplier during procurement?

Three things. Where does inference physically happen, and which sub-processors touch the material? Can you export a record of one specific action and have it verified with a tool you do not control? Who approves output before it reaches a client? The NCSC guidelines for secure AI system development cover the rest of the assessment.

Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.

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.