AI
Shadow AI is a supply problem, not a discipline problem
Blocking consumer AI tools does not reduce AI use inside your organisation, rather it reduces your visibility into it. The only control that has ever worked against shadow IT is a sanctioned path that is faster than the unsanctioned one.
Nearly half your workforce, two thirds of them invisible
Verizon's 2026 Data Breach Investigations Report analysed 858,440 DLP events involving generative AI tools. Three findings from that dataset are worth putting in front of your board.
45 percent of employees are now regular AI users on corporate devices, up from 15 percent the year before. That is a tripling in twelve months.
67 percent of them sign in with non-corporate accounts. Personal Gmail, personal subscriptions, free tiers. This is the number that matters operationally, because it means the majority of AI usage in a typical enterprise is invisible to your identity provider, your SSO logs, your licence inventory and your procurement records. You cannot see it in billing because there is no billing.
Shadow AI is now the third most common non-malicious insider action in enterprise DLP datasets, a fourfold year-over-year increase.
And the data type most frequently submitted to external models, by a wide margin, is source code. Structured data and internal research documentation follow. In 3.2 percent of DLP violations, employees uploaded research and technical documentation directly into an unauthorised model.
One more finding deserves attention because it bypasses controls most teams believe they have: more than 15 percent of users had unauthorised AI browser extensions installed. Those extensions collect and retain context from internal sites. They operate independently of traditional DLP, on pages your DLP never sees as an upload event.
This is not a rogue minority problem. It is a majority behaviour, running through accounts you do not govern, moving your most valuable data.
Why the ban fails, predictably
The organisations that responded to the 2023 to 2025 AI wave with a blanket prohibition instead of a governed alternative reproduced exactly the shadow IT dynamic they had spent a decade eliminating, with higher stakes data flowing through it.
The mechanism is not mysterious. An employee has a task, a deadline, and a tool that halves the work. The sanctioned path is either nonexistent, slow, materially worse than the consumer tool, or requires a ticket. The unsanctioned path is one browser tab. Policy loses to friction every time, and the loss is silent, because the employee who routes around the ban does not file a report about it.
Microsoft's 2026 Work Trend Index adds the incentive dimension: only 13 percent of AI users say they are rewarded for reinventing how they work with AI when results are not guaranteed. That pushes experimentation underground rather than into sanctioned pilots. When the formal channel is slow and the informal one is punished if it fails, people choose the one nobody is watching.
The honest reframe: shadow AI is the clearest available signal of unmet demand in your organisation. Treat the volume as a requirements document, not as a disciplinary matter.
The compliance shape of the problem
For regulated enterprises in Austria, Germany and Switzerland, the exposure is not abstract.
GDPR. The violation is not the tool, it is the disclosure. When an employee pastes personal data into a free-tier consumer LLM, the provider is not your processor. Under consumer terms it is an independent controller of what it receives, often with training rights. That makes the paste a disclosure of personal data without a legal basis under Article 6, potentially a reportable breach in its own right. If you would argue the tool was acting as your processor instead, Article 28 requires a contract and sufficient guarantees you do not have. Either way, Article 30 requires a record of the processing and Article 32 requires demonstrable technical and organisational measures, and neither exists for data flows you have not documented. There is no reading of the situation in which you are compliant.
EU AI Act. The Digital Omnibus on AI entered into force on 27 July 2026 and shifted the heaviest part of the regime. High-risk obligations for standalone Annex III systems now apply from 2 December 2027, and for AI embedded in regulated Annex I products from 2 August 2028. Two things did not move in substance. The Article 4 AI literacy duty has applied since February 2025 and continues in amended form under the Omnibus. The Article 50 transparency obligations apply from 2 August 2026, with a narrow transitional window for systems already on the market, running until 2 December 2026. Neither obligation is dischargeable for AI systems you have not inventoried.
DORA. For financial entities, an external AI API is an ICT third-party dependency. It belongs in the register of information, it needs contractual terms on data handling and subcontracting, and it needs an exit strategy. Prompts containing customer financial data that leave via an employee's personal account create a dependency that is by definition unregistered.
Undisclosed subprocessors. The chain does not stop at the tool. An AI feature inside a SaaS product you already approved might route to a model provider that never appeared in the subprocessor list you reviewed at onboarding. Shadow AI is not only what employees add. It is also what vendors quietly enable.
The auditor's question is becoming standardised: which AI tools process regulated data, where are the corresponding DPAs, and show us the DNS, proxy or CASB logs that prove active discovery rather than self-attestation.
The sanctioned alternative has to actually win
Most internal AI platforms fail for one of three reasons, all of them recoverable.
It is slower. Latency is a governance property. If the internal endpoint takes noticeably longer than the consumer tool, usage decays back to the shadow path within weeks, and you have spent budget on a control that produces no coverage.
It is worse. A visibly weaker model does not get adopted out of loyalty. If the sanctioned option produces output the employee has to rewrite, they will paste the task into the tool that does not.
It requires migration work. Any platform that demands a new client library, a new SDK or a rebuilt integration will lose to the one that does not. This is the strongest argument for OpenAI-compatible interfaces: the migration is a base URL and a key, and every tool your team has already built keeps working.
On the performance question, our own benchmarking on a DGX Spark node with Qwen 3.6-35B-A3B-FP8 measured 352 tokens per second through the Xinity gateway against 325 tokens per second direct to the engine. The more relevant figure is behaviour under pressure. At 512 concurrent requests with 65,000-token prompts, the gateway completed 85 percent of requests against 4.6 percent for the unmanaged path. The comparison people expect is throughput. The comparison that determines adoption is what happens on a Monday morning when the whole team hits the endpoint at once, because that is when a sanctioned system either holds or teaches users to go back around it.
A sequence that works
Measure before you legislate. DNS, egress and proxy logs plus a browser extension inventory will tell you which tools are in use and roughly what for. Run this as discovery, not enforcement, and say so. An amnesty produces a real inventory. An investigation produces a quieter one.
Publish one good default rather than a long allowlist. Coverage comes from a single obvious answer to "what do I use for this", not from a policy document with fourteen conditional branches.
Make switching a one-line change. OpenAI-compatible endpoint, same request format, same tooling. Anything more than that is an adoption tax you will pay in shadow usage.
Log at the gateway. Per-user attribution, prompt and response metadata, retention periods you set. This is what converts an ungovernable behaviour into an auditable system, and it is the artefact you hand an auditor.
Block last. Once the sanctioned path is genuinely better, enforcement stops fighting your own employees and starts catching the residual.
The trade
With a consumer tool, you get the productivity and you lose the record. With inference running on infrastructure you control, you get the same productivity and you keep the record. That is the entire decision, and it is not really about AI policy. It is about whether the logs exist.
Xinity Runtime is open source under Apache 2.0, exposes an OpenAI-compatible API, and runs on your own hardware in your own data centre. Prompts stay inside your perimeter. Every request is attributable. Your model choice is yours.
If you want to know what your organisation's actual AI usage looks like before you write another policy about it, that is the conversation to start with.
This article was drafted with AI assistance and reviewed, fact-checked and edited by the Xinity team. All statistics link to their original sources. We are not lawyers, and nothing here is legal advice. For questions about your specific obligations under GDPR, the EU AI Act or DORA, talk to your legal counsel.