Process AI where your data belongs.
OdyControl governs local and external language models through a single endpoint. You define which workloads take which route: sensitive ones stay local or go only to approved providers, non-critical ones use whichever suitable model is available.
Local AI first. External models only on your terms.
OdyControl runs in production at Cybervize and is installed in your environment. Which models, applications and data classes you connect is what the conversation is for.
Not every AI request carries the same protection need
An internal contract, a personnel record, confidential source code and a draft for a trade fair text must not be treated under the same rules. Yet in many organisations they are: either every request goes through the same external service, or cloud AI is blocked outright.
Everything goes out
A single external service receives every question, regardless of what is in it. In the end nobody knows exactly what left the building.
Everything is blocked
Cloud AI is forbidden, and the ban rarely holds. Anyone facing a deadline pastes the paragraph into a browser. The ban turns into shadow AI.
The route in between
Whether data may leave the organisation becomes a routing decision you set once and that then applies to every request.
OdyControl turns data sovereignty into an executable policy. Local models are the preferred route; external models are not a default route but a deliberately approved addition.
Your people already use AI. Just not yours.
The question behind it sounds much the same everywhere: data leaves my organisation every day because people use shadow AI. If I block it, I slow the business down. What am I supposed to do?
- 78%
of the knowledge workers surveyed who use AI at work bring their own tools for it.
Microsoft Work Trend Index 2024, survey of knowledge workers
- 27.4%
of the volume of corporate data entered into AI tools was detected as sensitive, up from 10.7% a year earlier.
Cyberhaven, March 2024, usage data from around three million employees
- 20%
of the organisations studied had a breach connected to shadow AI.
IBM Cost of a Data Breach 2025, around 600 organisations that had already suffered a breach
- $670k
was the average difference in breach cost between organisations with high and with low or no shadow AI use.
IBM Cost of a Data Breach 2025, difference between groups, not a demonstrated cause
Allowing it is not enough on its own
The best-known case is Samsung in 2023. According to media reports, engineers entered confidential source code into ChatGPT shortly after the company had permitted its use; it then banned it again. The order of events is what matters: use was already permitted, and something still left that should not have. Permitting without a rule on which data may take which route produces the same outcome as no guidance at all. A ban, in turn, tends to move the usage rather than end it: anyone facing a deadline uses the tool that answers.
What your people could do instead
First, who does what, so the list below is not misread: the interface, the knowledge bases and the assistants belong to a platform that sits alongside. OdyControl is its control layer and decides which request may reach which model. What such a workplace can cover typically looks like this, in each case on a model you operate yourself.
Write proposals
The assistant knows your customers' requirements from curated knowledge bases and inserts standards, specifications and boilerplate from earlier bids, with a reference back to the source document.
Translate
Correspondence, documentation and contracts between languages. As long as the data class stays local, the text touches no external translation service.
Draft emails
Drafts, rewrites and tone adjustments, from a quick reply to sensitive customer communication.
Summarise
Condense long documents, reports, meeting notes and mail threads into a briefing.
Work on documents
Upload and analyse PDF and Office files, analyse data, dictate, and set up your own templates and team assistants.
Research the web
Find and compile sources. Here the search query leaves the environment; the content of your documents stays inside as long as the workflow does not put it into the query.
Where OdyControl sits in this
An answer to shadow AI has two halves. One is a workplace your people use willingly; whether it is good enough for them is decided by your tasks, not by a promise from us. The other is a control layer that enforces which request may reach which model, and that can prove what actually happened. OdyControl is the second half. The first you bring, or we build it with you.
A policy nobody can enforce is a document
Most organisations now have an AI policy. It sits in a folder while reality runs alongside it: anyone facing a deadline uses whichever tool answers. OdyControl is where the policy becomes a rule that applies to every single request.
Anyone building an AI management system to ISO/IEC 42001 or implementing the requirements of the EU AI Act describes which data may be processed by which systems. OdyControl does not replace that work. It enforces its outcome on the model path and records what actually happened. Both frameworks are in our catalogue, and OdySecure carries the evidence for them.
Three routes, and you decide which one applies
Your organisation defines the classification. OdyControl enforces the resulting routing rules on the model path.
Local Only
Stays inside your environmentTrade secrets, confidential research data, proprietary source code, personal data needing special protection, unreleased product information, confidential contracts.
Only models running on your own infrastructure are permitted: the local primary model, a second model server, a second cluster, local specialist models.
If no permitted local backend is available, OdyControl ends the request in a controlled way. It is not quietly handed outside. Availability does not override the confidentiality boundary.
Trusted External
Vetted providers onlySensitive data whose external processing is permissible for the specific case, for instance under a data processing agreement, a checked processing region and clarified training use.
Your local models are permitted, plus a restricted pool of specially vetted providers, in an order you define.
If local AI is unavailable, a new request may go to an approved provider, provided the policy explicitly allows it for this class.
Flexible Processing
Free choice of modelPublicly available information, general ideation, generic drafts without internal detail, synthetic test data, sufficiently abstracted content.
Any connected model you have approved for this class is permitted. Selection follows your routing strategy, for example required capability, availability or local capacity.
If the local model fails, new requests move straight to an external model. They stay answerable without sensitive data taking the same route.
Where the class comes from
OdyControl does not infer it from the content. The classification comes from the calling application, from the workflow, from a fixed policy for the use case, or from an upstream classification service. OdyControl enforces it.
An outage does not move a data boundary
Ordinary failover asks whether the next system is reachable. For enterprise AI that is not enough. A model can be running and still be impermissible for this request. OdyControl therefore checks two conditions: is the target technically available, and is it permitted for this data class. Only when both hold does the request go there.
A backend fails
OdyControl detects the state, removes the backend from active rotation and stops sending new requests to it.
Recovery
An automated restart of the model serving process is triggered, the state is checked again, and after a successful check the backend returns to rotation.
Second cluster
Where the local infrastructure has at least two independent clusters, new requests keep running on the healthy cluster during an outage, including Local Only ones.
Return
Once the local backend passes its health check it becomes the preferred target again, depending on the routing strategy. Local first in normal operation, controlled fallback in the exception.
What failover does not do
It catches new requests. A response already streaming can break off during an outage and has to be requested again. Redundant model clusters alone also do not add up to high availability: gateway, network, identity, storage and monitoring have to be sized and designed accordingly.
One entry point, behind which the model landscape may change
Chat interfaces, agents, development environments, scripts and line-of-business applications address one central, OpenAI-compatible endpoint. Behind it you can run several local model servers, additional clusters, specialist models and approved external providers.
Your application's integration stays unchanged, even when
- a local model is replaced
- a new model cluster is added
- an external provider is approved or withdrawn
- a model is temporarily unavailable
- departments use different models
- a routing policy changes
How much adjustment a connection needs in a given case depends on which functions the client uses, for instance streaming or tool calls.
OdyControl runs in your environment: fully local, hybrid with approved external providers, or isolated with no outbound connection. Which topology suits your organisation is what the architecture call is for.
What OdyControl does
Local first
Process confidential AI workloads on self-operated models inside your own infrastructure.
Policy-based routing
Define which data stays local, which may use approved providers and which models are available for non-critical work.
Safe failover
During a local outage, move only to targets permitted for that data class.
One central endpoint
Connect chat interfaces, agents and applications through a single OpenAI-compatible interface.
Provider freedom
Use local models and different external providers without tying your applications to any one of them.
Traceable use
Document model targets, routing decisions, operational events and, where needed, complete requests and responses.
Document without recording everything
Every model call that runs through OdyControl can be documented centrally, local ones as well as forwarded external ones. At three depths.
- 1
Operational data
Timestamp, calling application, user or group reference, data class, routing policy, chosen model, local or external target, provider, status, latency, errors, failover and recovery events. No content.
- 2
Selective or redacted
Specific fields are deliberately captured, omitted or pseudonymised.
- 3
Complete
The full request and response, for explicitly approved use cases. Including external calls routed through OdyControl.
The third level is not a default setting
A complete log can itself contain what the data class is meant to protect, which makes it a particularly sensitive store. Purpose, legal basis, data scope, access, retention, deletion, pseudonymisation, affected groups and co-determination requirements must be settled before it is switched on.
What OdyControl does not do
Four points that should be settled before a pilot, not after.
It does not detect sensitive data by itself
The routing decision needs a reliable data class or another unambiguous attribute. Where that attribute comes from is set by your implementation.
It controls the model path, not every data flow
Web search, file transfer, retrieval outside the controlled path, external tools, code execution, speech services and identity services need controls of their own.
It does not replace legal review
A technically connected provider is not automatically permissible for every processing operation. Legal basis, contract, provider assessment and data minimisation are your organisation's call. OdyControl replaces neither a data protection review nor DLP or AI governance; it enforces their outcome technically.
It only works if it is the only route
Model requests should run exclusively through OdyControl. If applications keep reaching external providers directly, OdyControl is an offer rather than a control point.
Frequently asked questions
Does OdyControl keep all data local?
Fully local operation is possible. In mixed operation the configured data class decides whether a request must stay local or may use an external provider. Stated precisely: your organisation determines which AI workloads may leave it.
Can Local Only data be processed externally during an outage?
No. A Local Only policy remains binding during an outage. With no local backend available the request is refused in a controlled way or can be submitted again later.
Does OdyControl detect sensitive data automatically?
OdyControl enforces the configured data class and routing policy. Whether the class is set manually, by the application, by the use case or by a connected classification service depends on your implementation.
Does OdyControl make us data-protection compliant?
No. OdyControl provides technical control mechanisms. Legal basis, contract design, provider assessment, data minimisation and the permissibility of the specific use case are assessed by your organisation.
Do existing applications have to be changed?
OpenAI-compatible applications can use the central endpoint. The effort depends on which API functions the client uses, for instance streaming or tool calls.
OdyControl and OdySecure
OdySecure, the security platform by Cybervize, brings ISMS, compliance and risk onto one data foundation. OdyControl governs the model traffic in front of it: which request may reach which language model. Two products, the same stance: control stays with the organisation.
Let's talk about your data routes
In an architecture call we work out which workloads have to stay local at your organisation, which providers are candidates for which cases, and which topology fits.