Sovereign AI for charities and non-profits

Charities can run their CRM, finance, email, documents and meetings on one operating system they own, with donor and beneficiary data kept inside the building. Every studio shares the same local data, and one assistant works across all of it. That is the product: not a set of subscriptions you rent, but a sovereign operating system you hold.

The problem with renting your charity's tools

Most non-profits run on borrowed ground. The CRM sits with one vendor, finance with another, email and documents with a third, chat and meetings with a fourth. Donor records, beneficiary case notes, safeguarding files and grant reporting are spread across accounts you do not control, on servers you cannot see, under terms that change when the vendor decides.

For a charity this is not only a cost problem. It is a duty-of-care problem. You hold data on vulnerable people, on donors who trusted you with their details, on grant conditions that restrict how information is used. When that data lives in someone else's cloud, you are trusting a supply chain you did not build and cannot inspect.

We built the alternative. The studios a charity needs, running on a sovereign operating system, on hardware the charity owns.

The studios a charity actually runs

A non-profit does not need a hundred tools. It needs a handful that work together and never leak. On our operating system these are studios, not separate apps, and they share the same data.

Our CRM. Donors, members, volunteers and beneficiaries in one record system. Gift histories, contact preferences, case notes and consent status live locally. When a fundraiser looks up a supporter and a caseworker looks up a beneficiary, both are reading the same governed data, not two copies drifting apart in two clouds.

Our finance system. Restricted and unrestricted funds, grant budgets, gift aid, supplier payments and the reporting a trustee board expects. The numbers sit next to the donor records that produced them, so a grant report ties back to real gifts without an export-and-reconcile ritual.

Our email system. The charity's mailboxes, on the charity's hardware. Appeals, supporter replies and internal mail stay in the building. No third party parses the contents to improve a product.

Our document system. Policies, board papers, safeguarding files, grant agreements and impact reports. Documents live beside the records they describe, and access follows the same rules as everything else.

Our meetings platform. Trustee meetings, team calls and volunteer briefings run on the charity's own system. Recordings and notes, where you choose to keep them, stay local.

Our chat and collaboration. Day-to-day coordination for staff and volunteers, in one place, on the same operating system as the work it refers to.

Eighty-seven studios are built on this one operating system. A charity switches on the ones it needs and leaves the rest. They are studios on a single OS, sharing the organisation's own data, not a shelf of apps you have to wire together.

One assistant across all of it

Across every studio there is one assistant. It works against the charity's own data, on the charity's own hardware. Ask it to draft a grant report and it reads the finance studio and the CRM. Ask it to find lapsed monthly donors and it queries the records directly. Ask it to summarise a safeguarding case for a trustee, and it stays inside the access rules that already govern that file.

The assistant describes and drafts and finds. It does not send your data anywhere to do so. The intelligence works for the studios, on the data in the building, and every action it takes is written down.

Donor and beneficiary data stays in the building

This is the heart of it. On our operating system the data does not leave.

The system is air-gapped by default. It runs without an outbound connection. For a charity holding safeguarding records or grant-restricted information, that is the difference between a promise and an architecture. You are not trusting a policy document that says the vendor will behave. The data physically cannot go where there is no route.

Every action is written to an Open Audit Record. Not just who logged in, but what was done: which record was read, which report was generated, which field was changed, by which user or by the assistant. When a funder asks how beneficiary data was handled, or an auditor asks who accessed a donor file, the answer is a record, not a reconstruction.

Private deployment is the baseline here, and plenty of vendors offer a private tenancy. Our value sits beyond that: action-level auditing, air-gapped operation by default, and the whole software stack rather than a single model you have to integrate into someone else's product.

What it saves against the subscription stack

Charities feel every pound of software cost, and much of it is per user per month, every month, forever. The way to see the number is to cost your current stack honestly.

Take the published list prices of the tools you rent. A common bundle for a non-profit office is a productivity suite for email, documents and meetings, a CRM, and a chat platform. Read each vendor's own published per-user-per-month list price, multiply by your number of staff and active volunteers, and multiply by twelve.

The method, stated plainly:

annual cost = users x price per user per month x 12

Worked example, using the method rather than a quoted figure: if a charity runs 40 users across a productivity suite, a CRM and a chat platform, and you sum the published per-user-per-month list prices of those tools, the annual bill is that combined monthly price times 40 times 12. Put your own vendors' current published prices into that sum and you have your figure. Many charities qualify for non-profit discounts on some of these tools, so use the price you actually pay, and the assumption is that you count active users, not dormant seats.

The point is structural. Rented tools charge you every year for the right to keep using your own data. Owning the operating system and the studios changes what you are paying for. We state no MICKAI price in this article. What we are showing is the comparison you can run yourself, and the fact that the recurring per-seat meter is the thing being replaced.

Why this fits a non-profit specifically

The focus of the product is the regulated small and mid-sized organisation, and charities sit squarely inside it. They carry regulatory weight beyond their size: safeguarding duties, funder conditions, data-protection obligations, and a trustee board that is personally accountable. They rarely have a large IT function to manage a sprawl of vendor relationships.

One operating system, owned outright, with one assistant and one audit trail, is a simpler thing for a small team to govern than a dozen separate subscriptions. The studios are built. They run on hardware the charity owns. The data stays where the duty of care requires it to stay.

Our patent estate stands behind the platform: 104 filed UK patent applications covering 2,340 claims. Those are filed applications, part of the record, not the headline. The headline is the product a charity can run today.

What we do not claim

We name no customers and no distribution partner. We hold no certifications and we do not present any as held or in progress. We do not quote a MICKAI price. What we will put in front of a charity is the working system: the studios, the assistant, the local data, the audit record, and the method to compare it against what you rent now.

If your donor and beneficiary data matters enough to protect properly, it matters enough to keep in the building. That is what a sovereign operating system is for.

FAQ

Where does our donor and beneficiary data live? On hardware your charity owns, inside your own building or your own rack. The studios read and write to your data. Nothing is copied to a vendor to make the system work, and the assistant runs against that same local data.

Do we still pay a subscription per user per month? No MICKAI per-seat subscription is how we frame the model here. The point is the comparison: you own the operating system and the studios rather than renting each tool. We show the method for costing your current stack so you can run the sum for your own headcount.

Can it work without an internet connection? Yes. The system is air-gapped by default. It runs on your own hardware and does not need an outbound connection to function, which matters for safeguarding records and grant-restricted data.

Is this certified to a standard like ISO or SOC 2? We hold no certifications and we do not claim any as held or in progress. What we can show is the architecture: local data, an Open Audit Record of every action, and air-gapped operation by default.

We are a small charity. Is this only for large organisations? The focus is the regulated small and mid-sized organisation. A small team runs the same studios a large one does, on one operating system, with one assistant across all of it.

How is this different from a private cloud tenancy? Private deployment is the baseline, not the differentiator. Our value sits beyond it: action-level auditing, air-gapped operation, and the whole software stack rather than a model you have to integrate into someone else's tools.

Frequently asked questions

Where does our donor and beneficiary data live?

On hardware your charity owns, inside your own building or your own rack. The studios read and write to your data. Nothing is copied to a vendor to make the system work, and the assistant runs against that same local data.

Do we still pay a subscription per user per month?

No MICKAI per-seat subscription is how we frame the model here. The point of the article is the comparison: you own the operating system and the studios rather than renting each tool. We show the method for costing your current stack so you can run the sum for your own headcount.

Can it work without an internet connection?

Yes. The system is air-gapped by default. It runs on your own hardware and does not need an outbound connection to function, which matters for safeguarding records and grant-restricted data.

Is this certified to a standard like ISO or SOC 2?

We hold no certifications and we do not claim any as held or in progress. What we can show is the architecture: local data, an Open Audit Record of every action, and air-gapped operation by default.

We are a small charity. Is this only for large organisations?

The focus is the regulated small and mid-sized organisation. A small team runs the same studios a large one does, on one operating system, with one assistant across all of it.

How is this different from a private cloud tenancy?

Private deployment is the baseline, not the differentiator. Our value sits beyond it: action-level auditing, air-gapped operation, and the whole software stack rather than a model you have to integrate into someone else's tools.