Trend

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).

All

Scope: governance vs detection vs AI attacks

This page treats AI Governance as an organisational and regulatory framework: policies, roles, approvals, evidence. Shadow AI detection explains how to detect and stop unapproved AI use on the network. AI-driven cyber attacks explains how attackers use AI to scale attacks. AI in the SOC explains how the SOC uses AI defensively. For the underlying question why a SOC is needed at all, see SOC as a Service Switzerland.

Short version

Governance defines what is allowed and who approves it. Detection checks whether the rules are followed. Without detection every policy stays a statement of intent.

Regulatory frame

  • revFADP (revised Federal Act on Data Protection): AI use that processes personal data must follow the core principles of purpose limitation, proportionality and transparency. Automated individual decisions require informing the data subject and, where applicable, human review. See revFADP and SOC.
  • FINMA: supervised institutions must integrate AI-supported processes into their operational risk and outsourcing management; model governance, bias control and traceability are expected practice. See SOC and FINMA requirements.
  • ISG: operators of critical infrastructures remain fully accountable for AI-supported processes; cyber incidents with AI relevance fall under the 24-hour notification duty to the National Cyber Security Centre (NCSC). See SOC and ISG reporting.
  • EU AI Act: providers of AI systems in the EU and users of their output in the EU face obligations based on risk class. These classes cover prohibited, high-risk, transparency-related and minimal-risk uses. The Act applies to Swiss organisations with EU customers or an EU subsidiary. High-risk systems require risk management, data quality, logging, human oversight and conformity assessment.
  • Contract law: use of cloud AI (OpenAI, Anthropic, Google, Mistral, Azure OpenAI) creates processor relationships. Contracts must define data classification, geographic processing location and retention.

Building blocks of a reliable governance framework

Building blockWhat it governsEvidence for the auditor
AI policyApproved models, data classes, forbidden use cases, approval process.Signed policy with version and reviewer, training records of staff.
Roles and responsibilitiesAI owner, data owner, security owner, accountable legal representative per system.RACI matrix per AI system in production.
Model and use case registerWhich models in which version run where, with risk class.Current register, linked to contracts and data protection impact assessment.
Data protection impact assessmentRequired for high-risk processing (revFADP Art. 22); documents purpose, data categories, measures.Signed DPIA, consultation of FDPIC if residual risk remains high.
Technical controlsDLP on prompts, sanctioned AI gateways, prompt and output logging, rate limits.Log extracts, configuration baseline, detection rules in the SIEM.
Monitoring and detectionSOC detects unapproved AI endpoints, unusual data volumes and sensitive content in prompts.Use cases, alerts, playbooks; see Shadow AI detection.

From governance decision to SOC detection

  1. Policy defines allowed AI endpoints and data classes. Each approval has an owner and a classification from the outset.
  2. The identity provider restricts access to sanctioned AI gateways to managed accounts and devices. It blocks personal accounts.
  3. DLP rules filter prompts for sensitive patterns (customer data, credit cards, source-code signatures, confidentiality classifications).
  4. Network telemetry and proxy logs flow to the SIEM; SOC has use cases for non-sanctioned domains and data exfiltration over HTTPS. See ITDR for the identity side.
  5. The Incident response plan includes a playbook for AI incidents. It defines who isolates the session, who decides on reporting obligations and who communicates with the FDPIC.
  6. Review the model register, audit logs and detection rules quarterly. Keep version records of changes.
The expensive mistake

A policy without detection is not governance; it is a wish. Without prompt logging, network visibility on AI endpoints and SIEM use cases, organisations cannot verify or demonstrate whether staff follow the rules.

Legal basis and sources

Frequently asked questions

Does the EU AI Act apply to purely Swiss organisations?

The Act does not apply directly, but market access often brings Swiss organisations into scope. Anyone who offers AI systems in the EU, uses them for EU customers or exploits their output in the EU falls into scope. For Swiss groups with EU subsidiaries conformity is regularly relevant; for purely domestic Swiss use, revFADP (revised Federal Act on Data Protection) and sector rules apply first.

Where does AI Governance end and shadow AI detection begin?

Governance defines rules, roles and evidence. Detection identifies and stops policy breaches in practice. Both belong together; without detection governance stays unprovable, without governance detection has no target. See [Shadow AI detection](/en/soc/shadow-ai-detection).

Are ChatGPT Enterprise or Copilot for M365 legally unproblematic?

They are better protected than consumer variants but not automatically compliant. Organisations must individually assess processing location, retention, training opt-out, roles under revFADP (revised Federal Act on Data Protection) and the contract with the vendor. FINMA-supervised institutions additionally have to meet outsourcing rules.

What role does the SOC play in AI governance?

The SOC provides operational evidence that staff follow the rules. It detects unapproved AI use and provides audit logs for prompts and outputs, alongside playbooks for AI incidents. For the link to notification duties, see [Incident response plan](/en/soc/create-incident-response-plan). For the underlying duty, see [SOC as a Service Switzerland](/en/soc/soc-as-a-service-switzerland).

How often must the governance framework be reviewed?

Review the framework at least annually and after every material change: a new model, data category, vendor or regulation. Review the model register and detection rules quarterly because the vendor landscape and attack surface change quickly.

Continue reading in this cluster
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).
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.
revFADP (revised Federal Act on Data Protection) and SOC: what the revised Swiss data-protection act requires from security operations
The revFADP (revised Federal Act on Data Protection, in force since 1 Sep 2023) requires appropriate technical and organisational measures. Controllers must document these measures and notify the FDPIC as soon as possible of data security breaches likely to result in a high risk to the persons concerned. A SOC delivers the detection, documented response and evidence trail needed for a credible FDPIC notification and for informing data subjects.
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

Related terms