Mikka is the AI platform we built for ourselves. It runs on a small machine in our own office, it makes decisions about where our data is allowed to go, and it has been quietly doing real work for us for months.
We are not writing about it because it is a product. It is not for sale, and most of it never will be. We are writing about it because it is the clearest answer we can give to a question we get asked often, in different forms: if AI is genuinely risky, why does Black Chili use it so much? And if it is safe enough for us, why do other organisations need help governing it?
The honest answer is that AI is neither something to avoid nor something to use carelessly. It is something to use deliberately. Mikka is what that looks like when we apply it to ourselves rather than just recommend it to other people.
Why we built something rather than just bought something
There is no shortage of AI tools we could have bought off the shelf. Most of them would have done a reasonable job of the tasks we wanted help with: drafting, summarising, content scheduling, sorting through the dozens of small ideas that occur to anyone running a business and then disappear before they get written down.
What we could not buy off the shelf was the thing that mattered most to us: a clear, enforced answer to the question of what happens to sensitive information before it goes anywhere near a cloud AI provider. Not a policy that says staff should be careful. Not a setting buried in an admin panel that somebody configured once and nobody has checked since. An actual mechanism, running on hardware we control, that looks at a request and decides where it is allowed to go.
That mechanism is the part we built. Everything else – the cloud AI tools, the automation platform that wires it all together, the chat interface – is largely off-the-shelf. The part that matters, the part that makes the rest of it safe to use the way we use it, is ours.
How Mikka actually works
Mikka runs on a Mac Mini in our office, not in someone else’s data centre. At its centre is a classification gate: before any request reaches a cloud AI provider, it first passes through a small language model running locally, using Ollama, which is open-source software for running AI models on your own hardware rather than someone else’s.
That local model has one job: decide whether the content in front of it is safe to send to a cloud provider, or whether it needs to stay on this machine. Client-identifying information, anything that touches our day-to-day security work, anything we would not want leaving the building – that gets caught and handled locally. Everything else goes on to whichever cloud AI tool is the right fit for the task.
The detail that mattered most to us when we built this was what happens when it goes wrong. If the local model is unavailable for any reason, the gate does not wave requests through by default. It fails closed: nothing passes until the gate is working again. The safe failure mode is to do less, not to quietly drop the safeguard and carry on. That single design choice is, in miniature, most of what we mean when we talk about AI governance with clients.
From there, Mikka does ordinary, slightly unglamorous things. It pulls together a morning briefing from email and calendar. It listens for ideas dropped into a chat channel, works out which part of the business they belong to, and files them so they do not get lost. It handles a chunk of our content scheduling. None of this is exotic. What is different is that all of it sits behind a gate that was designed before any of the rest of it was built.
Built where the stakes are lowest, first
We operate under more than one brand, and they do not all carry the same level of risk. Black Chili, our security and AI assurance consultancy, is where new ideas go first. Nothing reaches the parts of the business that carry more commercial or professional weight until it has run cleanly here for a good stretch.
This is not a technology decision. It is a governance decision, applied to our own tools the same way we would recommend it for anyone else’s. New AI capability gets proven somewhere the consequences of a mistake are manageable, before it gets anywhere near the parts of the business where a mistake would actually cost something. It is the same logic behind piloting a new AI tool with a small team before rolling it out everywhere – just applied to software we wrote ourselves rather than software we bought.
The discipline of not automating everything
One of the more useful things Mikka has taught us has nothing to do with AI models at all. It is a simple test we apply to every new idea for what Mikka should do next: does this genuinely remove something from the to-do list, or does it just create an equivalent amount of work in a different shape?
Plenty of plausible-sounding automation ideas fail that test. An automated outreach system that drafts messages nobody would actually want to receive does not save time, it just moves the time spent from writing to fixing. A system that needs constant tuning and correction is not an improvement on doing the task directly, even if it looks impressive in a demo.
The ideas that survive are the ones where the answer is clearly yes – a morning brief that means starting the day already caught up, rather than spending the first hour getting there. That discipline, choosing not to automate something because it would not actually help, is as much a part of using AI responsibly as any technical control. It is also, frankly, the discipline most AI rollouts skip, because doing more with AI feels like progress even when it is not.
What this looks like from the outside
We do not expect anyone to be especially interested in our morning briefing automation. What we think is genuinely useful, for anyone thinking about AI governance in their own organisation, is what Mikka demonstrates about the relationship between the two halves of that phrase.
“AI” and “governance” are not in tension. The governance is what makes confident AI use possible in the first place. We can point a capable AI assistant at our email, our ideas, our content pipeline – some of it touching information we care about protecting – precisely because we built a layer that decides what that assistant is and is not allowed to see. Take the gate away and the same setup would be reckless. With it, it is just useful.
That is the same shape as the advice that runs through everything else on this site: the goal is not to avoid AI, and it is not to adopt it without thinking. It is to build the structure that lets you use it confidently – a secure AI gateway for staff, an AI control layer that enforces the rules automatically, a clear answer to the AI sovereignty question of where your data actually goes. Mikka is those ideas, built, running, and doing real work every day rather than sitting in a slide deck.
Where this goes next
Mikka is still growing. The next piece of work is a second gate: a way to take information that is partly sensitive – a client name alongside an otherwise ordinary question, say – and safely strip out the sensitive part before it goes anywhere near a cloud model, then put it back afterwards. After that, for the handful of things that should never leave our own hardware at all, a larger model running entirely locally.
None of this is being built for its own sake. Every piece exists because it lets us use AI a bit more, in a few more places, without ever loosening the basic rule we started with: sensitive information does not leave our control without a deliberate decision that it is allowed to.
You can see the live version of the classification idea, in a form built for visitors rather than for us, on this site – the Mikka widget in the corner of every page is a public demonstration of the same classify-then-route thinking that runs Mikka itself. The full platform lives at mikka.uk.
If the question this raises for you is what the equivalent of Mikka’s gate would look like for your organisation – what AI you could use confidently if the right structure were in place – that is precisely the conversation our AI Assurance services exist to have. No obligation, and we will tell you honestly whether you need us or not.
If you are not sure what AI tools are in use inside your organisation, an AI Exposure Review gives you a clear, independent picture - what is being used, what data it touches, and where the real risks are.
