How Sovereign AI Integrates With Your Existing Systems

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.