Self Hosted Models and Staff Records: What Stays Inside the Building

When an AI assistant reads your staff records, the question people mean to ask is simple: does that information leave the building? The honest answer depends entirely on where the model runs. With a hosted service, the text of whatever the assistant reads travels to someone else's servers to be processed. With a self hosted model, it does not leave your network.

That is the whole difference, and it is worth understanding properly because it is often described in ways that make it sound more mysterious than it is.

What actually travels

An AI assistant does not "learn your HR system". It reads specific text at the moment you ask it something, and that text goes wherever the model is.

So if someone asks an assistant "who is on leave next week and what happens to their tasks", the assistant pulls the relevant records, and those records become part of the input the model processes. If the model runs on a third party service, that input goes over the network to that provider.

What travels is not your whole database. It is the slice relevant to the question. But across a year of questions, a lot of slices add up, and the slices about people are the sensitive ones.

What self hosting changes

Running a private model on your own hardware means the processing happens inside your network. The record text goes from your system to your server and back. Nothing about a person's leave, role or record crosses to an outside provider, because there is no outside provider in the path.

This is what SicherOne means when it says private models can be self hosted. Project management, HR and AI agents work from one set of records, and where data handling requires it, the model reading those records can sit on infrastructure you control. A human still approves agent output before it ships, which is a separate control and an important one.

What self hosting does not change

This is where people get over confident, so it is worth being blunt.

It does not fix access control. A self hosted model that can read every HR record can still put something from an HR record into a project summary that twenty people see. The data never left your network and it still went to the wrong audience. Who can ask the assistant what, and what the assistant is allowed to include in output, are separate decisions you still have to make.

It does not remove your obligations. Data protection rules apply to how you handle personal information, not to where the server is. Requirements vary by country and by sector, and legal advice on your own situation is worth more than a blog post. Check what applies to you.

It does not make the output correct. A model on your own hardware makes exactly the same kinds of mistakes as one on somebody else's. Approval steps still matter, and the categories worth keeping are the ones about people.

It is not free. You are taking on hardware, updates, monitoring and someone who knows how to keep it running. For some organisations that cost is obviously worth it. For others it is not, and pretending otherwise helps nobody.

How to decide

Three questions, in this order.

What would actually be read? Write down the categories. Names and leave dates are one thing. Salary, performance notes and disciplinary records are another. Many useful assistant tasks need only the first group. If you can keep the sensitive categories out of reach entirely, the hosting question gets much smaller.

What are you required to do? Some sectors and some jurisdictions have rules about where personal data may be processed. This varies, and it changes. Find out what applies before you choose, rather than after.

What would you have to explain? If an employee asked where information about their leave and performance is processed, what answer would you want to give? If the honest answer would make you uncomfortable, that is the real signal.

The middle path most teams take

You do not have to choose one setting for everything. A common and sensible arrangement is to keep the assistant on project data by default, keep HR records behind a narrower door, and self host only where the sensitive categories are genuinely involved.

Being able to separate modules helps here. SicherOne is sold per seat with modules separable, so a team can put agents next to projects without opening HR records at the same time. That is a stronger control than a written policy, because it is enforced by the system rather than by everyone remembering. The people reading what comes back still need the judgement to spot an answer that looks wrong.

The short answer

If nothing may leave your network, self host and accept the running cost. If the sensitive categories can be kept out of the assistant's reach entirely, hosting matters less than access design. And in either case, decide who can ask what, and what may appear in output a wider group will read, before you switch anything on. That decision is harder to make afterwards, and it is the one that actually protects people.