Trend

Shadow AI detection: when staff use AI outside policy

Shadow AI describes AI use outside approved processes. Examples include private ChatGPT accounts at work, browser extensions with LLM integration and unapproved AI features in SaaS products. Customer data, source code or confidential documents can flow uncontrollably to a vendor without a contract or documentation. Swiss organisations need technical detection at network, endpoint and identity levels to make shadow AI visible and bring it back under governance. For the policy framework, see [AI Governance](/en/soc/ai-governance-security).

SOC as a ServiceAllShadow AI detection: when staff use AI outside policy

Scope: detection vs governance vs DLP

This page treats shadow AI as a detection problem: how do you see that staff use AI outside policy? What should be allowed, who approves and what evidence is required belongs to the governance layer; see AI Governance. Pure data loss prevention without AI focus addresses exfiltration in general; shadow AI detection combines DLP with network and identity signals specifically on AI endpoints. For the underlying SOC duty see SOC as a Service Switzerland.

Short version

Governance says what is allowed. Detection shows what happens. Without detection every AI policy stays a guess.

Typology: four ways shadow AI enters

Path	Example	What creates the risk
Personal web account	Staff open ChatGPT, Claude or Gemini with a private login on the work device.	Prompt content flows to a vendor without a contract or an entry in the processing register; the vendor often trains models on outputs.
Browser extension with LLM	Sidebars, summarisation tools, AI assistants in unmanaged browsers.	Extensions read page content automatically; permissions are usually too broad.
AI feature in SaaS without approval	Meeting recorders, CRM assistants, Notion AI activated without data protection review.	New sub-processors, changed data flows, without update of the processing register.
Developer tools with LLM	IDE plugins, code assistants with direct API access to external models.	Source code, secrets and configurations flow to external models; licensing and contract questions remain open.

Why this matters especially in Switzerland

revFADP (revised Federal Act on Data Protection): if an unapproved AI vendor is likely to access personal data, controllers must notify the FDPIC as soon as possible where the breach is likely to result in a high risk to the persons concerned. The controller remains accountable even if a staff member initiated the use independently. See revFADP and SOC.
ISG: operators of critical infrastructure report cyber incidents to the National Cyber Security Centre (NCSC) within 24 hours. This also applies to data exfiltration through shadow AI that affects the protected function. See SOC and ISG reporting.
FINMA: institutions report material cyber attacks under Art. 29 para. 2 FINMASA (Guidance 05/2020, refined by Guidance 03/2024): initial notification within 24 hours of discovery, full report within 72 hours. Using an unapproved cloud AI service for customer data can qualify as an outsourcing and security incident. See SOC and FINMA requirements.
Professional secrecy: transmitting data to an unapproved AI vendor may breach lawyers' professional secrecy (SCC Art. 321), bank customer secrecy (BA Art. 47) or medical professional secrecy. These obligations apply independently of data protection law.

Effective detection on three layers

Network: monitor proxy and DNS logs for known AI endpoints (openai.com, anthropic.com, mistral.ai, generativelanguage.googleapis.com, xai.com and others), alongside upload sizes. Alerts on traffic to these domains from unapproved accounts provide initial visibility. Combining this monitoring with Attack Surface Management also reveals external attack surfaces.
Endpoint: EDR telemetry detects new browser extensions, unknown desktop assistants and unusual processes with network connections to AI APIs. A managed browser policy limits extensions.
Identity: SSO and OAuth logs show which AI apps have received permissions in Google Workspace, Microsoft 365 or Slack. Personal logins on AI services surface in ITDR; see ITDR.
DLP content rules check prompts for customer data, credit cards, AHV numbers, source-code signatures and internal classifications. They trigger blocks or warnings depending on criticality.
SIEM correlation combines network signals, identity signals and DLP matches into one case. Threat hunting searches for new endpoints and changed TLS SNI patterns. See Threat hunting Switzerland.
Response playbook: the case owner notifies the staff member, and the data owner assesses the data class. The DPO decides on notification, and IT blocks the endpoint or account. Include this workflow in the Incident response plan.

Why blocking alone is not enough

Blocking AI endpoints outright shifts use to private devices and networks. The data flows become invisible, and the problem remains. An effective approach combines approved alternatives, clear communication and comprehensive detection.

Legal basis and sources

FINMA Guidance 05/2020 on reporting cyber attacks (Art. 29 para. 2 FINMASA): finma.ch
FINMA Guidance 03/2024 refining the reporting duty: finma.ch
ISG (SR 128), Art. 74a-74f: Fedlex
ISG reporting duty at the National Cyber Security Centre (NCSC) including routing: bacs.admin.ch
Reporting data security breaches to the FDPIC: edoeb.admin.ch

Frequently asked questions

How does shadow AI differ from classical shadow IT?

The mechanisms are related, but shadow AI involves more sensitive data flows. Shadow IT often uses unknown tools with limited data access. Shadow AI generates high-volume transfers to learning systems, which often reuse outputs. This significantly increases the risk of breaches of confidentiality and data protection.

Is a DLP product alone enough?

DLP alone is insufficient. It detects content but can miss the AI context, while encrypted connections and personal accounts can bypass it. Effective detection requires network and identity telemetry in the SIEM and a SOC that correlates the signals. See [SOC as a Service Switzerland](/en/soc/soc-as-a-service-switzerland).

How do you deal with AI features in existing SaaS?

Every activation of an AI feature by the vendor needs a change check: new sub-processor, changed data flow, possibly a new DPIA. A vendor alert process is part of governance; detection additionally sees whether the feature already generates traffic. See [AI Governance](/en/soc/ai-governance-security).

What should you do when you suspect unapproved AI use?

Open a case in the SOC, isolate the session and preserve prompt content and transfer volume. Involve the data owner and DPO, and assess notification duties. If the incident falls under revFADP (revised Federal Act on Data Protection), FINMA or ISG, the respective deadlines apply. Follow the workflow in the [Incident response plan](/en/soc/create-incident-response-plan).

How often do new AI endpoints emerge?

New AI endpoints emerge monthly. New vendors, models and subdomains quickly make static blocklists outdated. Detection must rely on behaviour, including large uploads to unknown APIs and TLS SNI patterns typical of LLM gateways. Teams must also continuously maintain the endpoint catalogue.

Continue reading in this cluster

AI Governance: how Swiss organisations govern AI use securely

AI Governance is the framework of policies, roles, controls and evidence with which an organisation runs AI usage safely, legally and auditably. In Switzerland, revFADP (revised Federal Act on Data Protection), sector regulation (FINMA, ISG) and the EU AI Act (for providers with EU exposure) meet. This page describes how governance decisions (which models, which data classes, which approvals) translate into technical controls and SOC detection. For the operational detection of unapproved AI use see [Shadow AI detection](/en/soc/shadow-ai-detection).

AI-driven cyber attacks: what changes, and what is marketing

Generative AI changes cyber attacks in scale, language quality and personalisation. The underlying techniques remain unchanged. Phishing in flawless Swiss German, deepfake vishing against the finance team, auto-generated malware code and LLM-driven reconnaissance are today's reality. The kill chain, detection logic and the importance of fast response remain unchanged. Attack volume, quality and the ability to bypass security controls based on linguistic or behavioural anomalies are changing.

AI in the SOC: where it helps, where it hurts, and where the marketing ends

AI in the SOC supports analysts, who remain responsible for their work. The real value lies in alert triage, correlation across data sources, summarising forensic raw data and suggesting response steps. AI causes harm through unattended auto-response without analyst sign-off and hallucinated links in reports. Assuming an AI module can replace a detection-engineering process also creates risk. ANOMAL uses AI where its output is deterministically verifiable and keeps the analyst as decision-maker.

ITDR: Identity Threat Detection and Response for Switzerland

ITDR (Identity Threat Detection and Response) detects attacks on the identity itself, not just endpoints or networks. Targets are accounts, tokens, sessions, permissions and identity providers such as Entra ID or Okta. ITDR extends EDR and SIEM with signals only visible in the identity layer. These include impossible travel, consent phishing, refresh-token abuse, role abuse and attacks on federation and directory objects. For Swiss organisations running M365, Entra ID and regulated processes, ITDR today is as important as EDR was five years ago.

Creating an incident response plan: template, roles, notification chains

An incident response plan defines who decides, who receives notifications and the order for shutting down, isolating and restoring systems before a crisis. It references the five core controls cyber insurers require: MFA, EDR, segregated backups, a patch process and the documented IR plan itself. It also assigns binding notification deadlines under revFADP (revised Federal Act on Data Protection), ISG, FINMA and DORA to specific roles and response times. Without this plan, teams improvise the 72-hour response, and insurers can contest the payout.

Look up short definitions in the glossary