Your local AI, secured, monitored and maintained.
What runs at our place today
18
From model selection to operation
One model per use
Each agent has its own model. We test many open models on your real questions, with several settings, to measure quality and consistency, then we tune agent by agent. Together we organise your references, knowledge base and governance. This is our AI readiness audit.
Secure and optimise
We install your AI on your servers or on our sovereign hosting, then lock it down: isolated agents, model engine cut off from the internet, files under fingerprint, restricted access. We then tune performance on your hardware (model size, memory, response time), with measurements to back it.
Maintain, by your side
Continuous monitoring, updates validated on the test bench, offsite backup. A contact who knows your setup steps in when an alert fires, keeps the incident log and reports to you every month. When a better model appears, we test it on your questions before proposing it.
Why so many checks
An AI model is not software like any other: it is a file of several gigabytes that cannot be read like code. The risks are concrete.
- A biased model. Every model carries the choices of those who trained it. A Chinese model, for example, will say nothing against the official position of the People's Republic of China. These biases are tested before use.
- A tampered file. The model may have been altered before it reached you, or afterwards, on disk.
- Drifting use. An agent can step outside its task, use its tools in unintended ways, change or delete files.
- A booby-trapped instruction. As soon as it reads your documents, a booby-trapped text can make it do what you never asked.
- A leak. It may try to reach the internet, or copy a password into an answer.
In July 2026, at OpenAI, agents under test faced with an impossible task changed their goal and ended up attacking a real platform, Hugging Face (METR's investigation). Nobody noticed for several days, and entire services had to be shut down to regain control. A model error or a badly framed task can produce unexpected, even dangerous, results. Monitoring is there to see that something abnormal is happening, and to stop one agent without cutting the power to the whole company. And because memory is kept apart from the model, you start again with another model and lose nothing.
What is watched at all times
| Check | When | Normal state |
|---|---|---|
| The models present, compared with the approved list (name and fingerprint) | every minute | no unknown model, no changed fingerprint |
| Every model file, checked byte by byte | regularly, across all files | no difference |
| Outbound: the model engine's connections to the internet | blocked at all times, except during a download opened by a person | no outgoing connection |
| Inbound: who can reach the model engine from the network | every minute | nobody, outside the machine itself |
| Scripts, tests, system instructions and agent tools | every minute, by fingerprint | identical to the approved version |
| Answers produced during tests | every answer | no password or key |
| What agents do in the tools | continuously | few refusals, no deletions |
When something drifts
Alerts handled and logged
Alerts reach the monitoring of your infrastructure, graded from information to critical. Each type of alert has a procedure written in advance. For clients under contract, we are the ones who act: diagnosis, corrective action, then an entry in a task and incident log that you can consult, and that feeds the monthly report.
Automatic removal, return on human approval
A model is authorised for an assistant only after passing the test bench on that assistant's questions. If it fails a later run, after an update for example, its authorisation is withdrawn automatically and the assistant can no longer launch it. To come back, it must pass the bench again and be explicitly approved by a person. The principle: a machine can withdraw a permission, never grant itself one.
Nothing gets out
The model engine has no internet access. Every new outgoing connection is refused, including name lookups (DNS), which can be used to carry data out. The rule is checked every minute and restored automatically if it disappears, after a restart or an update for example. Downloading a model goes through a window opened by a person, limited in time, that closes by itself. Every refused attempt is counted and logged.
The watcher is watched
The monitoring reports every minute. If no report arrives for five minutes, an alert goes out. Same principle for the full check of the model files: if it has not completed within the expected time, it is flagged. A watched component that stops, an agent tool that no longer answers, a missing filtering rule: each case has its own alert. A silent check is not a check, so we watch the silence too.
Limited rights, agent by agent
- Isolated agents. Each agent has only its own tools, data and rights. A compromised agent does not compromise the rest.
- Tools from a closed list. The AI does not make up commands: it calls tools whose actions are written in advance.
- Read widely, write little, execute explicitly, log everything. A deletion or a burst of writes raises an alert. A write that would erase more than half of a page is refused.
- No go-live without qualification. A model is used for an assistant only after passing the test bench on that assistant's real questions. Otherwise, the launch is blocked.
Your business know-how belongs to you
Your knowledge, procedures and business rules live in your document base, with their history, versions and approvals. Governance is defined with you: who writes, who approves, what each agent is allowed to read. The AI's indexes and search are derived from that base and can be rebuilt at any time. You can change models without losing anything: the model is replaced, your knowledge stays.
It is backed up offsite with our offsite backup: encrypted transfer, storage on AES-256 encrypted volumes, integrity checked by SHA-256 fingerprint, three independent copies and regular restore tests.
Maintenance
- An update goes through the test bench first, on your own questions. It goes live only afterwards.
- New models are compared regularly. We switch when the gain is measured, without rebuilding the solution.
- A model is downloaded only from an approved publisher, during a window opened by a person and closed afterwards.
- Monitoring, backup and reporting can join an existing maintenance contract or a dedicated AI services contract.
Coming soon
Local AI moves fast, and we move with it. No flying car on the roadmap: concrete building blocks, being finalised on our own platform, that will then reach our clients.
- Outbound filtering across the whole chain. The model engine is already cut off from the internet. The interface, document search, agents and the server itself come next.
- Scanning of production conversations, to spot a leak as it happens, not only during tests.
- Named approvals. Every approval will keep the name of its author.
- Qualification extended to the assistants in the interface, with the same test bench as for agents.
No method proves that a model is sound. What we do is make every change of model, code or configuration visible, and every deviation verifiable.
Going further
- Private AI agents and assistants: the full offer, from audit to day-to-day operation.
- Private AI chatbot: an assistant that answers from your wiki and documents, hosted at your site.
- The models we run: publisher, licence, use.
- GeoIP security: the same principle applied to your web servers.
- Sovereign WireGuard VPN: administration of your AI limited to authorised addresses only.
- Password management: access to your tools and your AI in a company vault.
Let's talk about your project
Thirty minutes, no commitment, to look at your use cases, what a local AI can do with them, and how we would protect it and run it at your site.
Want to know first which model holds up on your own questions? That is what our AI readiness audit is for.