What Shadow AI is, and why Norwegian SMBs struggle to see it

Your employees are already using AI on your company data. You just cannot see what they are sending, or what comes back.

In the Falcon console during recent onboardings, AI traffic shows up before any AI policy does. A finance lead pasting a draft contract into ChatGPT on a managed laptop. A developer running a Claude desktop app against an internal repo. A support agent quietly feeding customer messages into a free-tier translator that retains prompts. None of this is in anyone’s risk register. It is just on the endpoint, every weekday, in volumes that surprise the IT manager when I show them the first week of telemetry.

That is Shadow AI. It is the AI-era version of Shadow IT, and the same dynamic applies: people reach for tools that help them get work done, faster than security can catalogue or approve them. The difference is the data path. With Shadow IT, an unsanctioned SaaS app at least keeps your data in one place you can later audit. With Shadow AI, prompts leave the perimeter the moment they are sent, and you have no copy of what went out.

What counts as Shadow AI

Shadow AI is the unsanctioned use of generative AI tools by employees on company data, where security has no visibility into what is sent or what comes back. In practice that covers a wider set of tools than most SMB leaders expect:

• Public chatbots used through the browser or as desktop apps, including ChatGPT, Claude, Gemini, Copilot variants, and DeepSeek.
• Embedded AI features inside SaaS the company already pays for, where the AI tier was switched on by default at the vendor’s next release.
• Browser extensions and side-panel assistants that read open tabs and send selections to a model.
• AI agents that act on a user’s behalf, calling APIs, reading files, or writing to systems, often without an audit trail a human can read after the fact.

CrowdStrike’s product team frames the same surface in their AIDR announcement on 23 March 2026, where they call out desktop AI apps, MCP servers, and IDE extensions as the new endpoint AI footprint. That maps to what I see on the sensor.

The risk surface is concrete. Regulated data (personal, health, financial) leaving the perimeter without a processing record. Intellectual property pasted into a free tier that retains prompts for training. Prompt-injection abuse, where a poisoned document or web page convinces an agent to do something the user did not intend. Agentic AI making decisions that touch internal systems with no log a compliance lead can pull six months later. The Norwegian Data Protection Authority and your own customers will eventually ask which model touched which record, and you need an answer.

The common Norwegian SMB response

When I raise this with a 40 to 80 person Norwegian firm, the answer is usually the same: “We have a policy that says no ChatGPT.” Sometimes it is on a wiki page. Sometimes it sat in an all-hands slide six months ago. Once it was in the employee handbook from 2024, back when the company had thirty people.

The intent is right. The execution is incomplete.

A written policy without detection is faith. You are trusting that every employee read it, agreed with it, and stuck with it on the Friday afternoon when the proposal deadline is at 16:00 and Claude can summarise the RFQ in a minute. Some will. Many will not. The ones who do not will not tell you, because they read the policy.

The harder problem: a flat block at the network layer pushes usage to personal devices and home networks, where you have no visibility at all. In one composite onboarding with a Norwegian professional services firm this spring, the IT lead was confident their proxy blocked all the public AI domains. The first week of Falcon telemetry showed AI traffic from managed laptops that was using mobile tethering and personal accounts to route around the corporate egress. The work was still happening. The proxy logs just stopped seeing it.

See first, govern second

Our recommendation is straight: detect before you decide. Build the visibility layer first, look at what is happening on your endpoints, then write a policy that matches the reality you can defend.

This is the order that holds up in audit. A policy you can show telemetry against is a control. A policy you cannot verify is a wish.

In FM CyberSecurity’s AI security practice we run the detection step on the endpoint, because that is where the AI traffic originates regardless of which network the laptop is on at the time. CrowdStrike Falcon AIDR sits in that detection layer. Per CrowdStrike’s documentation, AIDR detects AI use at runtime on managed endpoints, including desktop AI applications like ChatGPT, Claude, Gemini, and Microsoft Copilot, surfaces prompt-layer threats (prompt injection, data leaks, policy violations), and feeds a sanctioned-versus-unsanctioned view of AI usage across the fleet. Desktop application coverage moved out of pre-beta after CrowdStrike’s Q2 2026 GA. AI Discovery in Falcon Exposure Management complements it by listing the AI apps, agents, LLM runtimes, MCP servers, and IDE extensions running on each endpoint in real time.

Charlotte AI, CrowdStrike’s agentic triage layer (covered in our piece on the agentic SOC), reduces the noise that comes with that telemetry, so the team reading the alerts is reading what matters.

The honest distribution of work on Shadow AI: Falcon AIDR detects and alerts on AI traffic from managed endpoints. CrowdStrike Falcon Complete Next-Gen MDR runs the 24/7 bridge that responds. FM CyberSecurity handles the onboarding, the tuning, the local escalation in Norwegian, and the conversation with your business about what the data justifies as policy. We do not staff the overnight bridge ourselves.

What you usually find in the first two weeks

Two concrete patterns from recent first-week telemetry reviews, both composite-tagged across multiple onboardings:

• The number of distinct AI services touched by a single small-fleet endpoint is higher than the IT manager expected. In one composite case with around 50 endpoints, the first pass surfaced AI traffic to roughly a dozen different services, the long tail being browser-embedded AI features in SaaS the company already paid for, not headline tools the policy had named.
• The volume of AI activity outside work hours is non-trivial. People use these tools at 21:30 on a Tuesday from a managed laptop on a home network. A perimeter-only control does not see it, but the sensor does.

Those two patterns are the argument. You cannot write a policy that fits the real usage if you have not yet seen the real usage.

What you gain by inverting the order

Detect first, govern second, and you keep the productivity wins that drove people to these tools in the first place. The work people do with AI is often legitimately better and faster. A blanket block stops that, and your competitors who built the visibility layer instead will outpace you on proposals, on code review, on translation, on the dozen small tasks AI compresses by an order of magnitude.

The reverse: you ship a policy that names which tools are sanctioned, which require approval, and which are off limits, against telemetry that shows whether the policy is holding. The control is verifiable. The data protection officer has an answer when a customer audit asks how you govern model use. The board owns AI risk on the basis of a number, not a slogan.

If this resonates:

• Read how we handle Shadow AI with Falcon AIDR for the operational view of detection, triage, and policy build.
• Forward this to your data protection officer, the person who will have to answer the model-use question first.
• Talk to me for a 30-minute view on what AI traffic leaves your endpoints today.