Sep 2026 · 7-9 min read · Labs News • Field Reports • Research

How aicoo-sovereign Brings Agentic Project Management Safely Inside Your Own Walls

For critical infrastructure, the public sector and insurance: what changes when agents work on every mail, meeting and plan.

For most companies that work with aicoo, the hosted platform is the right answer and the simplest one. The project data sits in German data centres, the transfer is encrypted, the GDPR question has a documented answer, and nobody has to operate anything.

There is a group of organisations for which that answer is not available. Not because they distrust it, but because the rules they work under were written somewhere else: operators of critical infrastructure, the public sector and insurers. For them, data leaving the building is not a decision they are free to make.

aicoo-sovereign is the variant built for exactly that group. The platform runs inside their own infrastructure, on the AI models they host themselves. This article is about why that is necessary there, and how it works.

Who this is about

The obligation looks different depending on the sector, but it always comes from outside the organisation, and it is not open to negotiation:

Operators of critical infrastructure — energy, water, health, transport, telecommunications, finance — plan under KRITIS and NIS2 requirements, depending on how they are classified.
The public sector adds procurement rules and IT baseline frameworks that narrow what may be procured at all.
Insurers have to be able to explain how personal, health and claims data is processed, and what happens when part of that processing is outsourced.
And any company that has been through a cyberattack works under a self-imposed standard that is often stricter than the regulatory one.

If your organisation is not in that group, this article is not about you: the hosted platform is the easier path, and it is the one we would recommend. What follows is for the case where it is ruled out.

Where on-prem tools stop

These sectors are not short of on-prem software. Project management tools built to stay inside the building exist, some of them designed for critical infrastructure specifically, and they do what they promise: the project data stays under the organisation's own access rules, backups and operations.

What they do not do is connect to AI. They were designed when the ambition was to keep data inside, not to compute on it with models. So they stop at the point where the interesting part begins.

Meanwhile the same organisations are building AI infrastructure of their own: self-hosted models, internal inference services, an internal AI gateway — precisely so they can use AI without handing anything to a third party. That investment is standing there, and the project tool next to it cannot reach it.

The gap is therefore neither a lack of on-prem software nor a lack of models. It is the missing connection between the two.

What changes when agents do the work

A classic AI feature has a clear boundary: someone selects something, sends it, gets an answer back. The exposure is a decision a person makes, case by case, and a security policy can regulate it document by document.

An agent has no such boundary, and that is the point of it. It follows the project continuously, notices in a mail that a supplier has moved a date, connects that to the task in the plan, flags the resource conflict it creates, and writes the result into the wiki. To do that, it needs standing access to the material the organisation protects most carefully.

For a team without external obligations that is an easy trade to make. For a grid operator, an authority or an insurer it is not: running it through an external AI provider would mean the entire project reality moves outside on a daily basis, as routine rather than as an exception.

The answer is not to give the agents less access. It is to move the whole arrangement inside.

How aicoo-sovereign runs

aicoo-sovereign is the same platform, operated in a different place. It is installed inside the customer's own infrastructure, and the models it works with are the ones the customer already hosts.

aicoo runs in your own infrastructure, under your rules for access, backup and operations.
It connects to the AI your company already operates: self-hosted models or your internal AI infrastructure.
Prompts and answers move between your own systems, with no third-party AI provider in the loop.
Communication tied to the plan, the agents' proposals, resource planning and the knowledge base all run on your machines.

What stays inside is not a subset. The mails, meetings and chats, including everything the agents read out of them. The project and resource plans. The wiki and the documents behind it. The prompts, and the answers that come back.

Security and AI, in the same system

The trade-off that forces these organisations to choose is not a law of nature. It exists because the available tools were built on one side of it or the other: on-prem software without AI, or AI services that require the data to travel.

A platform that is operated on-prem and speaks to models hosted on-prem removes the choice, for the organisations that had to make it. The security requirement stays exactly as strict as it was. The AI work happens anyway.

The question is not whether a document may leave. It is whether your project reality has to leave at all.

For organisations currently building internal AI infrastructure, this is also the answer to an awkward question: what is that infrastructure actually going to be used for? Project work is a good first answer, because it touches everything and pays back every day.

And for everyone else, nothing changes: the hosted aicoo remains the shorter route to the same agents.

See it on the aicoo-sovereign page

The aicoo-sovereign page shows the setup in one picture, the sectors it is built for, and what stays inside.

Open aicoo-sovereign