DECISION TOOLKIT · OPERATIVES GOVERNANCE-MODELL
Kontrollintensität an der Konsequenz ausrichten
Risiko ist keine Eigenschaft eines Modellnamens. Es ergibt sich aus der Wirkung des Workflows, der erteilten Autorität und der Fähigkeit, Fehler zu erkennen und umzukehren.
Entwürfe, Suche, risikoarme interne Arbeit
freigegebenes Tool · Nutzerverantwortung · leichte Logsprofessionelles Urteil oder externe Inhalte
Evaluationsset · Reviewer · nachvollziehbarer Outputschreibt in Systeme oder betrifft Kunden
Least Privilege · validierte Calls · BestätigungRechte, Sicherheit, Finanzen oder regulierte Entscheide
formale Freigabe · unabhängige Assurance · Incident-ÜbungRisikoarme Nutzungen über einen Fast Track führen; die stärkste Governance für Workflows mit materiellem Schadenspotenzial reservieren.
KI-Governance funktioniert nicht, wenn sie nur aus Grundsätzen, einer Richtlinie und einem Freigabegremium besteht. Sie muss im Alltag beantworten: Welche Systeme existieren, welches Risiko tragen sie, wer darf was entscheiden und welcher Nachweis zeigt, dass die Kontrollen wirken?
Für Schweizer Unternehmen beginnt der Rahmen beim Bundesgesetz über den Datenschutz und den konkreten Pflichten der Organisation. Je nach Markt, Kundschaft und Einsatz kann zusätzlich der EU AI Act relevant sein. Governance muss daher juristische Beurteilung ermöglichen, darf aber nicht mit ihr verwechselt werden.
1. Ein lebendes KI-Inventar führen
Ein Inventar sollte nicht nur offiziell beschaffte Plattformen enthalten. Dazu gehören Enterprise Workspaces, APIs, eingebettete Funktionen in SaaS-Produkten, Coding Agents, lokale Modelle, Experimente und kritische persönliche Accounts.
Für jedes System braucht es mindestens:
- verantwortete Geschäftsprozesse und Nutzergruppen;
- verwendete Datenklassen und Datenflüsse;
- Modelle, Anbieter, Deployment- und Integrationsmuster;
- mögliche Aktionen und menschliche Freigaben;
- Business-, Technical- und Risk Owner;
- aktuellen Lifecycle-Status und nächsten Review.
Ein jährliches Spreadsheet reicht nicht. Das Inventar muss mit Beschaffung, Architektur, Security und Delivery verbunden sein.
2. Nach Wirkung und Autorität klassifizieren
Die Risikoklasse darf nicht allein am Modellnamen hängen. Entscheidend ist das System: sein Zweck, seine Nutzer, seine Daten und seine Fähigkeit zu handeln.
| Dimension | Leitfrage |
|---|---|
| Wirkung | Beeinflusst das System Menschen, Geld, Rechte oder kritische Abläufe? |
| Daten | Verarbeitet es vertrauliche, personenbezogene oder regulierte Informationen? |
| Autorität | Kann es schreiben, ausführen, kommunizieren oder Transaktionen auslösen? |
| Exposition | Ist es intern, kundenbezogen oder öffentlich zugänglich? |
| Abhängigkeit | Können Menschen das Ergebnis realistisch prüfen und korrigieren? |
Ein interner Entwurfsassistent kann einen leichten Pfad erhalten. Ein Agent mit Schreibrechten in Kernsystemen braucht strengere Architektur, Evaluation, Freigabe und Incident Readiness.
3. Richtlinien in Kontrollen übersetzen
Eine Regel wie «keine vertraulichen Daten in nicht genehmigte Systeme» ist nur dann operativ, wenn das genehmigte System leicht zugänglich ist, Identitäten verwaltet werden, Datenklassen verständlich sind und technische Grenzen den sicheren Weg unterstützen.
Ein vollständiger Kontrollsatz deckt vier Ebenen ab:
- Organisation — Ownership, Acceptable Use, Training, Beschaffung und Eskalation.
- Architektur — Identität, Datengrenzen, Netzwerk, Isolation, Secrets und Integrationen.
- Modell und Anwendung — Evaluation, Grounding, Prompt Injection, Output-Kontrollen und Human Gates.
- Betrieb — Logging, Monitoring, Änderungen, Incidents, Reviews und Abschaltung.
Jede Kontrolle braucht einen Owner, eine Frequenz, einen Nachweis und eine begründete Verbindung zum Risiko.
4. Evaluation vor der Freigabe definieren
«Das Modell wirkt gut» ist kein Abnahmekriterium. Ein Evaluation Set muss repräsentative Aufgaben, erwartete Qualitätsmerkmale und relevante Fehlermodi enthalten. Dazu gehören falsche Aussagen, unsichere Tool-Nutzung, Datenlecks, Rechteüberschreitungen, Prompt Injection und unklare Unsicherheit.
Die Schwelle ist risikobasiert. Für eine kreative Ideengenerierung ist ein anderer Standard angemessen als für Vertragsanalyse, Kundenkommunikation oder Codeänderungen.
5. Risikoakzeptanz sichtbar machen
Nicht jedes Restrisiko kann technisch beseitigt werden. Dann muss eine benannte Person es mit Kontext, Dauer und Auflagen akzeptieren. Ein gutes Decision Record hält fest:
- welchen Einsatz und welches Risiko der Entscheid betrifft;
- welche Evidenz geprüft wurde;
- welche Kontrollen gelten und welche Lücken verbleiben;
- wer akzeptiert, bis wann und unter welchen Bedingungen;
- welches Ereignis eine erneute Prüfung auslöst.
6. Governance als Service betreiben
Governance skaliert, wenn der sichere Weg klarer und schneller ist als der inoffizielle. Bieten Sie Vorlagen, freigegebene Plattformen, Standardarchitekturen, Evaluation Harnesses und definierte Fast Tracks für risikoarme Anwendungen.
Ein monatliches Governance-Forum sollte nicht jede technische Entscheidung treffen. Es steuert das Portfolio, prüft Ausnahmen, beobachtet Incidents und entscheidet über neue Risikogrenzen. Delivery-Teams bleiben für die Kontrollen in ihren Systemen verantwortlich.
Die Kernfrage lautet nicht, ob ein Unternehmen «eine KI-Policy» besitzt. Sie lautet, ob die Organisation jederzeit zeigen kann, welche KI mit welcher Autorität arbeitet, welche Kontrollen greifen und wer auf neue Evidenz reagiert.