[ 01 ]
Everything on-prem, or nothing
Treating all data alike leads either to expensive hardware for trivial tasks or to a public tool for sensitive ones. Data has to be classified first.
[ SOVEREIGN & LOCAL AI ]
Use AI on the data that cannot leave.
Some data can never go to a public model. We set up AI on infrastructure you control: your cloud region, your servers or your managed devices. Local models for the cases that cannot leave, provider APIs where they can.
Inference location chosen per use caseOpen-weight and provider modelsGoverned and logged
[ 01 — WHERE IT GOES WRONG ]
Why sovereign AI projects go wrong.
The idea is simple. The trade-offs are where projects lose months.
- [ 02 ]
Benchmarks instead of your tasks
A model that tops a leaderboard may fail on your contracts. Only your own sample tells you the quality gap. - [ 03 ]
Hardware bought before the need is clear
GPUs are sized for a guess and idle within months. Volume and latency decide the setup, not enthusiasm. - [ 04 ]
Nobody to run it
A local model needs updates, monitoring and an owner. Without a runbook it becomes a science project.
[ 02 — WHAT YOU GET ]
Control you can point to.
Sovereign does not mean everything on-prem. It means each workflow has a documented answer to where data goes.
- [ 01 ]
Data and hosting map
For each workflow: what data goes in, where inference runs, which provider or model sees it and what is stored. - [ 02 ]
Deployment options
Your cloud tenant and region, a private endpoint, servers you operate or a local model on managed devices. - [ 03 ]
Model selection
Open-weight models such as Llama, Mistral or Qwen families next to provider models. We test them on your tasks and report the quality gap. - [ 04 ]
Governed access
Your identities, roles and logging in front of every model, so use is attributable and reviewable. - [ 05 ]
Honest trade-offs
Local models cost hardware and upkeep, and are weaker on some tasks. You get the numbers before you commit.
[ 03 — HOW WE DE-RISK IT ]
How niivo takes the risk out.
We decide with evidence before anything is bought.
- [ 01 ]
Classify before you build
Data is sorted into what may go to a provider, what stays in your cloud region and what stays inside. The architecture follows that map. - [ 02 ]
Test on your tasks
A sample of your own work runs through local and hosted candidates. You get quality, speed and cost side by side. - [ 03 ]
Vendor-neutral choice
Open-weight and provider models are compared without a favourite. Switching later is possible because the workflow is separate from the model. - [ 04 ]
A runbook and an owner
Monitoring, updates and a named owner are part of the handover. You run it, or we do under a separate agreement backed by worxspace's ops team.
[ 04 — PROCESS ]
Decide with evidence.
We compare options on your own tasks, not on benchmarks.
- 01
Classify the data
Which data may go to a provider, which only to your cloud region, which must stay inside.1 to 2 weeks - 02
Test the models
We run a sample of your tasks through local and hosted candidates and compare quality, speed and cost.2 weeks - 03
Pilot the setup
One workflow on the chosen architecture, with logging and access control in place.4 weeks - 04
Hand over
Runbook, monitoring and a named owner. You can operate it, or we can, under a separate agreement.1 to 2 weeks
[ 05 — USE CASES ]
Cases where it matters.
Typical scenarios. None of these describe a specific client.
Internal knowledge assistant
- Today
- Staff cannot use public chatbots on internal documents.
- With the workflow
- A private assistant answers from approved documents and cites sources. It respects existing file permissions.
Sensitive document processing
- Today
- Contracts or case files are read by hand because they cannot go to an external API.
- With the workflow
- A local model extracts fields and summaries on your own servers. A person confirms each result.
Regional hosting requirement
- Today
- A customer contract requires processing in a defined region.
- With the workflow
- The workflow runs on a model deployed in that region, with a log that shows where each request ran.
[ 06 — SCOPE & PRICE ]
Architecture first, build second.
The alternative to a decision made on evidence is hardware bought on a guess, or sensitive work that stays manual because no tool is allowed. The model tests give you the quality gap in numbers before you spend on either.
Sovereign AI architecture & setup · 6 to 8 weeks
from CHF 14,000fixed scope · excl. VAT
Hardware and inference costs are separate. Extensions: CHF 2,200 per day.
- Data and hosting map
- Model tests on your tasks
- One workflow on the chosen setup
- Runbook and named owner
[ 07 — QUESTIONS ]
What people ask about sovereign AI.
Is local AI as good as the big models?
Not on every task. For narrow, well-defined work such as extraction or classification, compact local models often do well. For open-ended reasoning, provider models are usually stronger. We measure this on your tasks.
Does a provider API mean our data is used for training?
Business API terms of the main providers generally exclude training on your data, but terms differ and change. We read them with you per use case and document the outcome.
Do we need our own GPUs?
Not always. Options range from a private cloud endpoint to a single server or workstation. The audit sizes it against your volume.
Who maintains it?
You can, with a runbook we hand over, or we can under a separate support agreement. Updates to models are planned, not automatic.
What if a better open model appears next month?
It will. The workflow is separate from the model, and we keep the test sample, so a new model is checked against the same yardstick before you switch.
Can this run in our Microsoft tenant?
Yes, for example with Azure AI Foundry in your region. Tenant operations remain with worxspace or your IT team.
Tell us what cannot leave the building.
We show you what is possible on your own infrastructure, and what it costs.