Governance
“Just paste it into Claude” is not a tool choice. It is a decision about data.
For regulated companies and anyone who signed an NDA, not everything can go to public AI. That is why we have layers: the rule about what may leave is configuration with an audit trail, not a policy in a drawer.
Regulatory framework
Four reasons not everything can go to the cloud
DORA
Resilience and ICT risk management, including suppliers. An AI tool is part of the supply chain.
NIS2
Cybersecurity: control over where and how data is processed.
GDPR
Personal data must not leave a defined environment.
NDA
A contractual commitment: a client’s content, code and data do not belong in public tools.
Compliance is demonstrated by the regulated entity as a whole, and its legal team assesses scope. We provide the setup, documentation and cooperation.
How we handle it
The rule is configuration, not policy
Sensitive data on local models only
Client data, internal code and personal data are processed by models on our GPUs. Neither prompt nor answer leaves our network.
Public tools only with data that may leave
We use cloud models where the data allows: no internal code, no personal data, no NDA content.
Routing in the gateway, scope in MCP
LiteLLM decides where a request may go. An MCP service account with a defined scope decides what AI may reach. Both with an audit log.
One audit trail
Who, which model, over which sources and when. Traceable without stitching logs from five tools.
Data classification is part of the brief
Which class the data belongs to is decided at the start of a task, not in a check after it.
Where we are today
What code enforces and what configuration does, for now
We are honest about how far we are. For an agent working on mail or GitLab, the difference between “we have a rule” and “the rule cannot be bypassed” matters.
| Where | How | Status |
|---|---|---|
| Agents on client data (GitLab triage, Delegator) | Before the first request, code asks the gateway where the model runs. Nothing is sent off our hardware. | enforced in code |
| Mail triage (IMAP triage) | The model is set by the configuration of each mailbox and category. Operational mailboxes run locally only; the cloud is allowed only for drafts in selected mailboxes. | enforced by configuration |
| LiteLLM gateway | We are introducing keys restricted to local models, so the rule holds on the gateway side too, not just in the client. | rolling out |
With every client we want to set this up together and in writing: which classes of data you have, which may go to the cloud and who can change that.
FAQ
What compliance asks
Does our data leave your network?
Data that the agreed rules keep inside is processed only by models on our hardware. Cloud models are used only for data that may leave, and always through one gateway with an audit trail. We set the rules with you in writing at the start.
Will you make us DORA or NIS2 compliant?
Compliance is demonstrated by the regulated entity as a whole, not by its supplier. We provide the AI layer setup, the audit trail and documentation for your supplier assessment, and cooperation during an audit.
Where do the models physically run?
On our servers in two data centres in the Czech Republic, on the same infrastructure where we run clients’ production applications.
Who can see what the AI was asked?
The gateway’s audit log records who, with which model and when. Nux operations have access to it, and we can make it available for your audit within a scope we agree on.
No-obligation consultation
Let’s find the first job for AI in your company.
An hour’s conversation about where your data lives, which processes slow you down and what of it may leave your network. You leave with a proposal for a first pilot, not a tool demo.
Built and is accountable for the AI layer at Nux
Radek Růžička
Managing Director and CTO, Nux s.r.o.