We make your data and tools usable for AI
A language model knows the world, but not your company. We connect your systems: through the open MCP standard, with the permissions your people already have, and in a way that survives the next change of model.
Your systems
Gateway
Sign-in per user
Clients
What we have connected so far
Two Swiss companies where the connection runs every day, not as a trial but in production.
Coop
The group-wide GenAI platform runs on Google Cloud. We connected it to the systems that hold the group's knowledge: master data from SAP, the documentation in Confluence and in-house applications for which no ready-made interface existed.
Connected systems
Primeo Energie
The knowledge assistant searches the group's business systems and answers questions with evidence from the original sources. Connected are the documentation in Confluence, mail and calendar from Microsoft 365 and the document stores in SharePoint, each with the permissions of the person signed in.
Connected systems
One entry point for every tool and model
The middle of the diagram is not decoration. Without it every application hangs off every system separately, and every change of model turns into a rebuild.
One place for every tool
The gateway holds the MCP servers together: a registry, the connections, and filters over which tool is available to which application. New sources are registered once rather than again in every application.
Providers stay interchangeable
A single interface across OpenAI, Anthropic, Google, Mistral, Bedrock and Cohere. Plus virtual models, rule-based routing, load balancing and failover to a second provider when the first one is down.
Spend visible per team
Cost and budgets per user, team, tool and provider. Who spends how much shows up in your own report, not only in the provider's combined invoice.
Protection in one place
Masking of personal data and checking of input happen in transit, rather than being rebuilt inside every application. What applies, applies everywhere alike.
The gateway is a platform component. We set it up, connect it to your sign-in and configure it per environment. Which parts of it you need follows from your system landscape, not from a datasheet.
From the first source to running it
No big-bang project with a deadline. One source that pays off, and onwards from there.
Survey the sources
We look at where the knowledge sits, who is allowed to see it and what condition it is in. The result is a list of sources ranked by value and effort, along with an honest note on which ones are not worth it.
Connect
One MCP server per system, registered at the gateway, using the source system's own authentication. We start with a source that pays off quickly and grow from there. Not everything at once.
Operate
The connection is monitored, new models are passed through, new sources are added. We either run it or hand it over to your team, with documentation instead of knowledge in people's heads.
Nobody sees more than before
The most common concern here, and a fair one: does an AI suddenly open up document stores that used to be closed? No, provided the sign-in sits in the right place.
The difference lies in who asks the source system. A system reading through a service account of its own sees everything, and therefore passes everything on. With us the tool asks on behalf of the person signed in. SharePoint, Confluence and SAP answer the way they always answer that person. Where the permission is missing, so is the document, including in the AI's answer.
On-Behalf-Of
The AI system acts on behalf of the person signed in, not through a service account of its own. The source system sees the same user as always.
Token exchange
At the gateway the sign-in token is exchanged for a token for the target system. No permanently stored key that is allowed more than the person behind it.
OpenID Connect
Sign-in runs through the identity provider you already have, usually Microsoft Entra ID. No second user directory.
Existing directories
Where SAML is in place it gets connected rather than replaced. Groups and roles stay where they are maintained.
Rights per tool
Each MCP server only receives the permissions it needs. A tool meant to read must not be able to write.
Separate indexes
Vector indexes and caches are kept separate per tenant. A search cannot reach across the boundary, not even by accident.
What we get asked first
What happens when we switch models?
Nothing happens to the connections. MCP is an open standard: the tools address the interface, not a particular model. That is exactly what it is for. We have swapped models several times without touching the integrations.
Does the model provider see our data?
Only what is in the individual request, and only then if you choose an external provider. Running in Switzerland or in the EU is possible, as is running on your own servers. What goes where is settled beforehand and can be traced.
Can someone reach data through the AI that they cannot otherwise see?
No, and that is the point of the section above. The request runs with the identity of the person, not with a service account. Anyone who may not open a document in SharePoint will not receive it as an answer either.
How long does one connection take?
For a system with a clean interface and a settled sign-in, two to six weeks. The effort rarely lies in the technology but in the question of who may see what. That question comes up anyway; the connection merely makes it visible.
Do we have to tidy up our data first?
Not first, and not completely. It helps to begin with a source that is well kept. The result then shows what tidying up is worth. A project that starts with a data cleanup delivers nothing for six months.
Who runs it afterwards?
Either we do or your team does. We build so that both stay possible: infrastructure as code, documented procedures, no dependence on individual people.
Get in touch directly & without obligation
- ✓Non-binding initial consultation
- ✓Personal advice from our expert team
- ✓Response within 24 hours
