The Logicalis CIO Report 2026 surfaces a number that sits uncomfortably in most IT leadership meetings: only 37 percent of CIOs have full visibility into the AI tools used inside their organisation. Bitkom reports that 40 percent of companies with 20 or more employees suspect private AI tool usage in-house. In mid-market companies the picture sharpens: smaller governance teams, higher tool density per head, faster onboarding paths for new SaaS services. Anyone taking the problem seriously will get sales calls for AI posture management tooling from multiple directions. We see in projects that 80 percent of those purchases solve nothing that DNS plus SSO plus endpoint discovery would not have solved. Three telemetry sources the house already owns are enough for a defensible inventory in under two weeks: DNS logs, SSO telemetry, endpoint discovery.
Why banning AI never works
Bans move the problem from the company laptop to the private device. Anyone who wants to polish a draft email in ChatGPT will do so on their phone. What you ban away is control and audit. The productive strategy is not “ban AI” but “see what is running” and “define acceptable use”. Visibility is the precondition for any governance discussion. Without visibility you talk hypotheses; with visibility you talk facts.
Pattern 1: DNS logs as a 60-minute inventory
Every API call to an external LLM provider leaves the network through DNS. Whoever sees DNS resolutions sees the tools. In mid-market companies the visibility sources are typically three: firewall logs on pfSense or OPNsense, Cisco Umbrella or similar DNS-layer solutions, or local Pi-hole instances on managed networks.
The relevant domain list for 2026 includes the obvious candidates and some less obvious ones. In practice we see:
| Provider | Main domain | Common API subdomain |
|---|---|---|
| OpenAI | openai.com | api.openai.com |
| Anthropic | anthropic.com | api.anthropic.com |
| Google AI | googleapis.com | generativelanguage.googleapis.com |
| Mistral | mistral.ai | api.mistral.ai |
| Perplexity | perplexity.ai | api.perplexity.ai |
| Cohere | cohere.com | api.cohere.com |
| xAI | x.ai | api.x.ai |
| DeepSeek | deepseek.com | api.deepseek.com |
| Together AI | together.xyz | api.together.xyz |
| Replicate | replicate.com | api.replicate.com |
We regularly observe that the first five do not paint the full picture. A property management client with fewer than 80 employees had eight unknown AI API calls in their seven-day DNS data, three of them to smaller providers that were not on the standard top-five list. That was not a security incident but uncoordinated tool selection by individual business units. Without a DNS inventory it would never have surfaced.
Effort: 60 minutes to write an analysis query against existing DNS logs, half a day for cross-checking and documentation. Tools we like include GoAccess or a simple Python script that matches logs against the domain list above.
Pattern 2: SSO telemetry for tool discovery
DNS sees direct API calls. SSO sees SaaS tools with built-in LLM features. That is the genuinely underestimated gap. Notion AI, Slack AI, Atlassian Intelligence (Jira, Confluence), Linear, GitHub Copilot, Salesforce Einstein, HubSpot Breeze: they all run via OAuth or SAML and therefore show up in the SSO provider. Anyone running Azure AD, Okta, Google Workspace or Keycloak already owns the inventory without realising it.
The analysis runs against the application table of the SSO provider. We filter for SaaS apps that added an LLM feature since 1 January 2025 and cross them against the list of active OAuth apps. An insurance back-office client with 240 end users had 12 OAuth apps in their Azure AD tenant, seven of which run an LLM feature in the background without being perceived as “AI tools”. The discovery was both relieving and revealing: relieving because no shadow software was running on the side, revealing because the tools in active use were already feeding data into LLM pipelines without anyone actively approving it.
Effort: three to five hours for the analysis, one day to assess the apps against the company’s data protection concept. In Azure AD the application overview suffices, in Okta the system logs API, in Google Workspace the reports API.
Pattern 3: Endpoint discovery for local models
Locally installed LLMs are the third inventory hole. Browser extensions for Claude or ChatGPT, local model runners like Ollama, LM Studio or GPT4All bypass DNS (Ollama makes no external calls) and bypass SSO entirely. They only become visible at the endpoint itself.
Three tools deliver results here:
Microsoft Intune with compliance policies that report installed applications. Wherever Intune is in use, write a custom compliance check that searches for Ollama, LM Studio, GPT4All, Jan and a few others. The result lands in standard reporting.
Jamf for the Mac fleet with the same logic, plus browser extension inventory through configuration profiles.
osquery as the open-source alternative, runs on Linux, Mac and Windows, has a simple SQL-like query language and turns endpoint inventory into a database query. The pragmatic path for houses without Intune or Jamf.
A logistics mid-market client with 180 endpoints had Ollama or LM Studio on 17 percent of devices. That was not a compliance scandal but a signal that in-house developers were actively trying out local models. The right follow-up conversation was not “you installed unauthorised software” but “let us build a clean setup standard for local models so you are supported”. Visibility made the conversation possible in the first place.
Effort: one day for the custom query or compliance policy, two to three days for fleet-wide evaluation. With a clean endpoint management tool in place, this becomes hours rather than days.
What the three sources show together
After a two-week inventory sprint the house holds three lists: external AI APIs from DNS, SaaS tools with AI features from SSO, local model installations from endpoint discovery. The union of the three is the inventory picture the Logicalis number means when it talks about “full visibility”. In 80 percent of mid-market projects this gets us to robust coverage. The remaining 20 percent involve edge cases like mobile devices with private browser profiles or webhook-based integrations that run without a browser session. Those warrant additional measures but are not the starting point.
NIS-2 Art. 21 requires risk management that captures the IT systems in use. A documented AI inventory based on the procedure above satisfies this requirement directly. Audit conversations become short and factual. We covered the NIS-2 context separately in our NIS-2 compliance piece.
Three anti-patterns
“We buy an AI discovery vendor.” A posture management tool typically runs at 30,000 to 80,000 euros per year for mid-market companies and delivers nothing for the first 80 percent that DNS plus SSO plus osquery would not deliver. The right moment for a vendor is when those three sources are exhausted and concrete posture questions remain open. That is rarely the first sprint.
“We run an employee survey.” Employees systematically misanswer the question “which AI tools do you use?”. Anyone using a tool in a grey zone does not admit to it. Anyone using a technically inconspicuous tool (a browser extension, a small plugin integration) does not remember. The answers are not dishonest but a mix of memory gaps and taboo effects. Telemetry is structurally superior to surveys on this question.
“We block AI domains.” Pushes the problem to private devices and destroys compliance-grade telemetry at the same time. Anyone who blocks no longer sees what is running. Anyone who accepts and observes can govern.
Bridge to watermarking
No inventory, no watermarking. Anyone who does not know which in-house systems produce AI output cannot decide which of them need machine-readable marking under Art. 50(2). The inventory sprint described here is the precondition for any watermarking plan. We worked out the regulatory and implementation side separately in our watermarking duty piece, which applies from 2 August 2026 onward for providers of generative AI systems.
Conclusion and inventory checklist
Shadow AI in mid-market companies is not a vendor problem but a telemetry problem. Anyone evaluating the existing sources cleanly has a defensible inventory in two weeks, NIS-2-compatible and ready as the foundation for any further governance discussion. The following checklist sums up the sprint and is intended as a printable template.
| # | Item | Source | Effort | Owner |
|---|---|---|---|---|
| 1 | Extract DNS logs of the last 7 days | Firewall / Umbrella / Pi-hole | 30 min | Network |
| 2 | Domain match against AI provider list | Script / GoAccess | 60 min | Network |
| 3 | Document and cross-check with business units | – | 2 h | IT lead |
| 4 | Export SSO application list | Azure AD / Okta / Workspace | 30 min | IAM |
| 5 | Identify OAuth apps with AI features | Manual + vendor docs | 2 h | IAM |
| 6 | Data protection assessment of found apps | – | 4 h | DPO |
| 7 | Write endpoint discovery query | Intune / Jamf / osquery | 2 h | Endpoint |
| 8 | Run query across the fleet | – | 1 h | Endpoint |
| 9 | Capture local model installations | – | 1 h | Endpoint |
| 10 | Build browser extension inventory | Intune / Jamf / osquery | 2 h | Endpoint |
| 11 | Consolidate inventory in a central document | Confluence / Notion / Markdown | 3 h | IT lead |
| 12 | Assign owner per system | – | 2 h | IT lead |
| 13 | Roughly classify protection need per system | – | 4 h | DPO + IT |
| 14 | Refresh inventory quarterly | Calendar reminder | – | IT lead |
| 15 | Hand over to watermarking planning | – | 1 h | IT lead |
Total effort: one focused weekend or two weeks spread out, depending on team size. No new vendor, no new tool, no posture management subscription.
EverBright IT supports mid-market companies on Shadow AI inventory from telemetry analysis to handover to watermarking planning. Learn more about our AI advisory or get in touch directly.
Frequently Asked Questions
Do I need a new tool for shadow AI inventory?
In 80 percent of mid-market setups, no. DNS logs, SSO telemetry and endpoint management reports provide the necessary data. A dedicated AI posture management tool becomes useful only after those three sources are exhausted and concrete posture questions remain.
How often should the inventory be refreshed?
Quarterly is the pragmatic rhythm. The tool landscape changes monthly, and a quarterly sprint catches new providers, new SaaS features and new local installations early enough. Regulated industries should shorten the cadence to monthly or event-driven.
What happens to employees whose shadow AI tools show up?
Nothing disciplinary, just a conversation. Shadow AI is a symptom, not blame. Employees reach for unapproved tools when the approved one is missing or unfit. The follow-up conversation is “what problem were you trying to solve” and ends in a tool approval or an official alternative.
Is DNS logging alone enough?
No. DNS only sees direct API calls. SaaS tools with embedded LLM features (Notion AI, Slack AI, Atlassian Intelligence) do not surface as “AI domains” in DNS because the call happens server-side at the provider. SSO is what makes that layer visible.
How does this map to NIS-2?
NIS-2 Art. 21 requires risk management with a documented system inventory. An AI inventory built with this procedure meets the requirement directly and is presentable as evidence during audits. For essential and important entities under NIS-2 the inventory is mandatory, not optional.
