What actually leaks when your team uses AI assistants at work

Every organisation we assess has AI usage. The ones that believe they do not have unmanaged AI usage, which is the same thing with less visibility. Enterprise AI adoption across the Nordics runs well above the EU average, and individual usage runs ahead of organisational policy nearly everywhere.

The five paths, ranked by how much they actually matter

1. Personal accounts on personal devices

An employee opens a consumer AI assistant on their phone and pastes in a customer contract to summarise. No logging, no data processing agreement, no retention control, and consumer terms that may permit training on the content. You cannot see it, you cannot prove it did not happen, and no technical control on your network touches it.

This is the largest exposure by volume and it is a policy and enablement problem, not a technical one. Blocking corporate access makes it worse, because it removes the sanctioned alternative.

2. AI features already inside your existing SaaS

Meeting transcription and summarisation, mailbox assistants, document copilots, support-desk suggestion engines, code assistants. These frequently arrive enabled by default in a licence tier you already bought, processing data you already store, under terms nobody re-read at the time of the change.

This is the most underestimated path, because it does not look like AI adoption — it looks like a product update. A meeting transcription feature turned on across an organisation captures a great deal of material that was never intended to be written down at all.

3. Applications your own developers built

An internal tool calls a model API. The prompt is assembled from a template plus retrieved context, and the retrieved context is frequently broader than the developer assumed — an entire record rather than the two fields the feature needs, or a document chunk containing information the requesting user should not see.

Two distinct problems live here: what goes out to the provider, and whether the retrieval respects your own access control. The second is an authorisation flaw in a new location and it is common.

4. Code assistants

Code sent for completion routinely includes configuration files, connection strings, and comments containing internal architecture detail. Enterprise tiers generally offer stronger contractual protections than consumer ones, but the question of what context is transmitted from the open editor is separate from the question of what the vendor promises to do with it.

5. Browser extensions and unvetted wrappers

The smallest volume and the highest per-incident risk. An extension with permission to read page content on all sites, from a developer nobody assessed, is an exfiltration channel with a legitimate installation path. These deserve an outright allowlist approach rather than policy language.

What is actually in the prompts

Finding out what is actually happening

1. Query egress logs and DNS for the major model provider domains and the well-known wrapper services. You will get a usage picture within an hour, and it will be larger than expected.
2. Audit installed browser extensions across managed devices, filtering for AI-related permissions.
3. Review AI features in every SaaS product you licence, specifically checking which are enabled by default and which have been enabled since procurement.
4. Search your codebase for model API endpoints and SDK imports to find internally built integrations.
5. Ask people. An anonymous survey asking which AI tools staff find useful produces more accurate results than any technical control, because there is no incentive to hide when nothing is being blocked.

Controls that work, in order of effectiveness

• Provide a sanctioned tool with a data processing agreement, and make it genuinely good. Almost all shadow usage is a workaround for an unmet need. This single measure does more than every technical control combined.
• Publish a short, specific policy. Not 'use AI responsibly' but a page listing approved tools, the three categories of data that must never be entered, and what to do if something is entered by mistake — with an explicit no-blame reporting route.
• Turn off SaaS AI features you have not assessed, then re-enable deliberately. Default-on is not a decision.
• Put a gateway between your applications and model providers, so that what internal systems send can be inspected, pseudonymised where appropriate, policy-checked and logged.
• Allowlist browser extensions. This is the one path where blocking is straightforwardly correct.
• Include AI data flows in your record of processing activities. If personal data reaches a model provider, that is processing, and it needs a documented basis and a processor agreement.

The ordering is deliberate. Organisations reliably reach for the technical controls first because they feel actionable, and reliably discover that usage simply relocates. Provision before prohibition.