GovernanceKI-Sicherheit im ISMS steuern.
KI-Sicherheit braucht klare Verantwortung, kein Parallelprogramm. Diese Seite zeigt Rollen und Gremien mit RACI-Vorlage, Policy-Hierarchie, Programmphasen, Freigabe-Gates für neue Use Cases und den Einbau in die bestehende ISMS-Prozesslandkarte.
Rechtsstand: 10. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar.
Ein ISMS,
keine Nebenwelt.
KI-Systeme sind Assets mit eigenen Risiken: Modellverhalten, Trainings- und Wissensdaten, Prompt Injection, Abhängigkeit von wenigen Anbietern. Die Steuerung dieser Risiken gehört in das bestehende ISMS. Ein separates KI-Programm mit eigener Risikomethode, eigenem Inventar und eigenen Ausnahmen erzeugt Doppelarbeit und Lücken an den Schnittstellen.
Das NIST AI RMF ordnet Governance als Querschnittsfunktion GOVERN ein: Richtlinien, Verantwortlichkeiten, Inventar, Schulung und Umgang mit Dritten. GOVERN 2.3 sieht vor, dass die oberste Leitung Verantwortung für KI-Risikoentscheide übernimmt. Die OECD-Prinzipien ergänzen Rechenschaft, Transparenz und Robustheit. Beide sind frei zugänglich.
Wer entscheidet,
wer verantwortet.
| Rolle | Aufgabe | Typische Besetzung |
|---|---|---|
| Verwaltungsrat / Aufsichtsrat (Board) | Legt KI-Strategie und Risikobereitschaft fest, nimmt das KI-Lagebild ab, überwacht die Umsetzung. | Gesamtgremium oder Risiko- bzw. Prüfungsausschuss |
| Geschäftsleitung | Setzt Strategie um, stellt Ressourcen bereit, trägt Risikoakzeptanz für hohe Restrisiken. | CEO, CIO, COO |
| KI-Ausschuss | Entscheidet über Gates bei hoher Kritikalität, priorisiert, schlichtet Zielkonflikte. | CIO (Vorsitz), CISO, Datenschutz, Compliance/Recht, Fachbereich |
| AI-Owner (Use-Case-Owner) | Verantwortet ein KI-System über den ganzen Lebenszyklus: Zweck, Inventareintrag, Risikobeurteilung, Betrieb, Stilllegung. | Leitung des nutzenden Fachbereichs |
| CISO | Gibt Sicherheitsanforderungen vor, prüft Architektur, Tests und Lieferanten, berichtet Sicherheitslage. | Informationssicherheit |
| Datenschutz | Prüft Rechtsgrundlage, Datenschutz-Folgenabschätzung, Betroffenenrechte. | Datenschutzberater/in (CH) oder Datenschutzbeauftragte/r (DE) |
| Fachbereich | Nutzt das System bestimmungsgemäss, prüft Ergebnisse, meldet Auffälligkeiten. | Anwenderinnen und Anwender |
| Einkauf | Stellt sicher, dass KI-Bezug bei jeder Beschaffung erkannt und vertraglich geregelt wird. | Einkauf, Vendor Management |
| Interne Revision | Prüft unabhängig Wirksamkeit von Governance und Kontrollen. | Revision oder externer Prüfer |
In kleineren Organisationen übernimmt die Geschäftsleitung die Rolle des KI-Ausschusses. Wichtig ist nicht die Zahl der Gremien, sondern dass jedes KI-System genau einen AI-Owner hat.
Zuständigkeit
pro Aktivität.
R = durchführend, A = rechenschaftspflichtig (genau eine Rolle), C = konsultiert, I = informiert. Die Vorlage ist ein Startpunkt und an die eigene Organisation anzupassen.
| Aktivität | Board | KI-Ausschuss | AI-Owner | CISO | Datenschutz | Fachbereich | Einkauf |
|---|---|---|---|---|---|---|---|
| KI-Strategie und Risikobereitschaft | A | R | C | C | C | I | I |
| KI-Policy-Set erlassen und pflegen | I | A | C | R | C | I | C |
| Inventareintrag erstellen und aktuell halten | – | I | A/R | C | C | C | C |
| AI-Act-Einstufung und Rolle festlegen | – | A | R | C | C | I | C |
| Risikobeurteilung (Sicherheit, Modell, Recht) | – | C | A | R | R | C | I |
| Lieferantenprüfung und Vertrag | – | I | A | C | C | I | R |
| Betriebsfreigabe hohe Kritikalität | I | A | R | C | C | C | I |
| Betriebsfreigabe niedrige Kritikalität | – | I | A | C | C | R | – |
| Überwachung im Betrieb | – | I | A | R | I | R | – |
| KI-Vorfall behandeln | I | I | R | A | R | C | C |
| Ausnahme genehmigen | I | A | R | C | C | I | – |
| Schulung und KI-Kompetenz | I | A | C | R | C | R | – |
Vier Ebenen,
ein Regelwerk.
KI-Regeln ergänzen das bestehende Regelwerk. Die Informationssicherheitsrichtlinie DCH regelt die Freigabe von KI-Services bereits in einem Abschnitt. Darauf bauen die folgenden Ebenen auf.
- Ebene 1 · Leitlinie: Informationssicherheitsleitlinie mit Grundsatz zu KI, Risikobereitschaft und Verweis auf die Governance.
- Ebene 2 · Richtlinien: KI-Nutzungsrichtlinie für alle Mitarbeitenden, Abschnitt KI in den Richtlinien zu Beschaffung, Entwicklung und Datenklassifizierung.
- Ebene 3 · Standards: Sicherheitsanforderungen an KI-Architekturen, Prüfkatalog für Tests, Mindestinhalte für Verträge mit KI-Anbietern.
- Ebene 4 · Verfahren: Freigabeprozess mit Gates, Inventarpflege, Ausnahmeverfahren, Vorfallbehandlung.
Drei Phasen
statt Grossprojekt.
| Phase | Ziel | Ergebnisse | Abschlusskriterium |
|---|---|---|---|
| 1 · Sichtbar machen | Wissen, welche KI im Einsatz ist und wer sie verantwortet. | AI-Owner benannt, Erstinventar, Nutzungsrichtlinie, freigegebene Werkzeuge für generative KI, Regel für Schatten-KI. | Jedes bekannte KI-System hat einen Owner und eine vorläufige Einstufung. |
| 2 · Steuern | Neue Use Cases laufen durch einen einheitlichen Prozess. | Freigabe-Gates, Risikomethode mit KI-Szenarien, Lieferantenanforderungen, Schulungsprogramm, Ausnahmeverfahren. | Kein neues KI-System geht ohne Gate-Entscheid in Betrieb. |
| 3 · Nachweisen | Wirksamkeit belegen und verbessern. | Kennzahlen, Tests und Überwachung im Betrieb, Prüfung durch Revision, optional Zertifizierung. | Board erhält regelmässig ein KI-Lagebild mit Kennzahlen. |
Welche Prozesse
KI ergänzen.
Die ISMS-Prozesslandkarte bleibt der Rahmen. KI erweitert bestehende Prozesse um konkrete Prüfpunkte.
| ISMS-Prozess | KI-Ergänzung |
|---|---|
| 01 Steuerung | KI-Grundsatz in der Leitlinie, KI-Ausschuss, Berichtslinie ans Board. |
| 02 Risiko | KI-spezifische Risikoszenarien in der bestehenden Methode, nicht in einer zweiten. |
| 03 Compliance | AI-Act-Einstufung und Rolle je System, Datenschutz, Aufsichtsrecht. |
| 04 Architektur | Referenzarchitektur für KI-Anwendungen, Agenten und Schnittstellen. |
| 05 Inventar | KI-Systeme, Modelle und Datensätze als Asset-Klassen, siehe KI-Inventar. |
| 07 Lieferanten | KI-Bezug in jeder Beschaffung abfragen, Vertragsklauseln zu Daten und Modellnutzung. |
| 11 Awareness | KI-Kompetenz nach Zielgruppen, Nachweis der Teilnahme. |
| 14 Entwicklung | Sicherheitsanforderungen für eigene Modelle, Prompts und Agenten. |
| 17 Änderungen | Modellwechsel, neues Training oder neuer Zweck lösen eine neue Prüfung aus. |
| 20 Incident | KI-Vorfälle als eigene Kategorie mit Meldewegen. |
| 24 Wirksamkeit | Kennzahlen und Prüfungen für KI-Kontrollen. |
Fünf Gates
pro Use Case.
Die Prüftiefe richtet sich nach der Kritikalität aus dem Inventar. Bei niedriger Kritikalität können Gates zusammengelegt werden. Bei hoher Kritikalität entscheidet der KI-Ausschuss.
| Gate | Leitfrage | Nachweise | Entscheid |
|---|---|---|---|
| G0 · Antrag | Welcher Zweck, welcher Nutzen, wer ist Owner? | Inventareintrag mit Zweck, Owner, Datenarten | AI-Owner |
| G1 · Vorprüfung | Verbotene Praktik nach Art. 5 AI Act? Hochrisiko? Welche Rolle haben wir? Welcher Schutzbedarf? | AI-Act-Einstufung, Rolle, Kritikalität | KI-Ausschuss bei hoch, sonst CISO |
| G2 · Design und Beschaffung | Sind Risiken beurteilt und Anforderungen festgelegt? | Risikobeurteilung, Datenschutz-Folgenabschätzung falls nötig, Lieferantenprüfung, Architekturentscheid | AI-Owner mit CISO und Datenschutz |
| G3 · Betriebsfreigabe | Funktioniert das System sicher und wie vorgesehen? | Testergebnisse, menschliche Aufsicht geregelt, Protokollierung, Notfallabschaltung, Schulung der Nutzenden | gemäss RACI nach Kritikalität |
| G4 · Rezertifizierung und Stilllegung | Ist der Einsatz noch zweckmässig und beherrscht? | Bestätigung Owner, Kennzahlen, Vorfälle; bei Stilllegung Daten- und Zugriffsrückbau | AI-Owner |
G4 entspricht GOVERN 1.7 des NIST AI RMF (geordnete Stilllegung). Die Gates lassen sich an bestehende Projekt- und Change-Freigaben koppeln.
Befristet,
begründet, sichtbar.
- Ausnahmen laufen über das bestehende Ausnahmeverfahren des ISMS, nicht über ein eigenes KI-Verfahren.
- Jede Ausnahme ist befristet, hat kompensierende Massnahmen und einen Owner.
- Die Risikoakzeptanz trägt die Linie, die den Nutzen hat, nicht die Informationssicherheit.
- Keine Ausnahme von verbindlichem Recht, etwa von verbotenen Praktiken nach Art. 5 AI Act.
Art. 4 AI Act
nach Omnibus.
Seit der Änderung durch die Verordnung (EU) 2026/1744 lautet Art. 4 Abs. 1: Anbieter und Betreiber ergreifen Massnahmen, um die Entwicklung der KI-Kompetenz ihres Personals und weiterer Personen, die in ihrem Auftrag mit KI-Systemen arbeiten, zu unterstützen. Die Pflicht verlangt ausdrücklich nicht, ein bestimmtes Kompetenzniveau zu garantieren. Für Hochrisiko-Systeme gilt zusätzlich Art. 26 Abs. 2: Betreiber übertragen die menschliche Aufsicht Personen mit Kompetenz, Ausbildung und Befugnis.
Praxis: Schulung nach Zielgruppen (alle Mitarbeitenden, AI-Owner, Entwicklung, Geschäftsleitung), Teilnahme dokumentieren. In Deutschland verlangt § 38 Abs. 3 BSIG von Geschäftsleitungen NIS-2-regulierter Einrichtungen regelmässige Schulungen zum Risikomanagement der Cybersicherheit.
Schweiz und
Deutschland.
Schweiz: Es gibt kein KI-spezifisches Gesetz. Die Oberleitung, die Festlegung der Organisation und die Oberaufsicht sind unübertragbare Aufgaben des Verwaltungsrats nach Art. 716a OR. KI-Risiken fallen darunter, sobald sie wesentlich sind. Das Datenschutzgesetz gilt direkt für KI-Anwendungen mit Personendaten.
Deutschland: § 91 Abs. 2 AktG verlangt vom Vorstand ein Überwachungssystem zur Früherkennung bestandsgefährdender Entwicklungen. Für NIS-2-regulierte Einrichtungen verlangt § 38 Abs. 1 BSIG, dass die Geschäftsleitung Risikomanagementmassnahmen umsetzt und überwacht. Der AI Act gilt als EU-Verordnung unmittelbar.
Einordnung der Pflichten: Regulierung DCH. Fristen: Fristenkalender DCH.
Wenige Zahlen,
regelmässig.
- Anteil KI-Systeme mit Owner und aktueller Einstufung
- Anteil produktiver Use Cases mit Gate-Entscheid G3
- Offene Ausnahmen und überfällige Rezertifizierungen
- Erkannte Schatten-KI und deren Überführung
- KI-Vorfälle nach Schweregrad
- Schulungsabdeckung je Zielgruppe
Kennzahlenset mit Schwellen und Berichtsmuster für das Board: Seite Kennzahlen und Reporting.
ISO/IEC 42001
oder NIST AI RMF.
Einzige zertifizierbare Norm für ein KI-Managementsystem. Sie folgt der gemeinsamen Struktur der ISO-Managementsystemnormen und lässt sich daher mit einem ISMS nach ISO/IEC 27001 kombinieren. Anforderungen an Zertifizierungsstellen regelt ISO/IEC 42006:2025 (kostenpflichtig). Sinnvoll, wenn Kunden oder Partner einen Nachweis verlangen oder KI Kern des Angebots ist.
Frei zugänglicher Rahmen mit den Funktionen GOVERN, MAP, MEASURE und MANAGE und einem Playbook mit Umsetzungsvorschlägen. Nicht zertifizierbar, aber als Aufbauhilfe geeignet. Wer zuerst nach NIST AI RMF aufbaut, kann später auf ISO/IEC 42001 umsteigen, ohne die Grundlagen neu zu erstellen.
Vergleich weiterer Grundlagen: KI-Frameworks im Vergleich.
Schweiz: Die FINMA beurteilt nach Aufsichtsmitteilung 08/2024, Kap. 2.1 (Governance), ob Beaufsichtigte mit vielen oder wesentlichen KI-Anwendungen eine KI-Governance haben. Dazu zählt sie ein zentral geführtes Inventar mit Risikoklassifizierung, festgelegte Zuständigkeiten für Entwicklung, Implementierung, Überwachung und Nutzung, Vorgaben zu Modell-Tests, Dokumentationsstandards und breite Schulungsmassnahmen. Bei Outsourcing prüft sie zusätzliche Tests, Kontrollen und Vertragsklauseln zu Verantwortung und Haftung.
EU: Nach DORA Art. 5 Abs. 2 legt das Leitungsorgan alle Vorkehrungen des IKT-Risikomanagements fest, genehmigt und überwacht sie und trägt die letzte Verantwortung (Bst. a). KI-Systeme sind IKT-Systeme und fallen darunter. Art. 5 Abs. 4 verlangt ausreichende Kenntnisse der Mitglieder des Leitungsorgans und regelmässige Schulung. Für Betreiber von Hochrisiko-KI, die Finanzinstitute sind, gilt die Überwachungspflicht nach Art. 26 Abs. 5 AI Act durch Einhaltung der Governance-Regeln des Finanzmarktrechts als erfüllt.
Vertiefung: AI Act Framework für Finanzinstitute (Lifecycle-Gates, Kontrolltiefe nach Risiko).
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt beim Aufbau der KI-Governance und bei der Einbettung in das bestehende ISMS. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 4, 5, 26 (EU, 13.06.2024)
- Verordnung (EU) 2026/1744, Digital-Omnibus zur KI, Neufassung Art. 4 (EU, 08.07.2026)
- AI Act, konsolidierte Fassung vom 27.07.2026 (EUR-Lex, ohne Rechtswirkung)
- NIST AI 100-1, AI Risk Management Framework 1.0, GOVERN 1.6, 1.7, 2.3 (NIST, 01/2023)
- NIST AI RMF Playbook (NIST, laufend)
- OECD AI Principles (OECD, rev. 2024)
- Guidelines for secure AI system development (NCSC/CISA u. a., 11/2023)
- ISO/IEC 42001:2023 AI management system (ISO) (kostenpflichtig)
- ISO/IEC 42006:2025 Anforderungen an Zertifizierungsstellen (ISO) (kostenpflichtig)
- Obligationenrecht, Art. 716a (Fedlex, SR 220)
- Aktiengesetz, § 91 Abs. 2 (gesetze-im-internet.de)
- BSI-Gesetz, § 38 Abs. 1 und 3 (gesetze-im-internet.de)
- FINMA-Aufsichtsmitteilung 08/2024, Kap. 2.1 Governance (FINMA, 18.12.2024)
- Verordnung (EU) 2022/2554 (DORA), Art. 5 Abs. 2 und 4 (EU, 14.12.2022)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.