Swiss Room · Leitfaden 2 von 15
RISIKO-AMPEL
Was dieser Leitfaden Ihnen gibt
Use-Case-Klassifizierung · Grenzfälle · Vertragskonsequenzen · Entscheidungsbaum
Diese Leitfadenreihe ist aus einer spezifischen Perspektive heraus geschrieben: der einer General Counsel / Senior Vice President, die über viele Jahre in leitender Inhouse-Funktion in regulierten Unternehmen gearbeitet hat – in der Schweiz und in der EU. Die Autorin verfügt über eine juristische und betriebswirtschaftliche Ausbildung in der Schweiz und in Deutschland sowie über langjährige operative Erfahrung als interne Rechts- und Compliance-Verantwortliche in internationalen Konzernen und KMU-Umfeldern.
Diese Kombination – juristische Tiefe, operatives Management-Know-how und direkte Erfahrung mit den Realitäten von Lieferketten, Vertragsverhandlungen und Aufsichtsbehörden – ist der Grund, warum die Texte so geschrieben sind, wie sie sind: nicht als formale Gesetzeskommentare, sondern als Arbeitsinstrumente. Sie richten sich gleichzeitig an Führungskräfte, die schnell einordnen müssen, was eine Regulierung für ihr Unternehmen bedeutet, und an Fachabteilungen, die wissen müssen, was operativ zu tun ist.
Der interdisziplinäre Ansatz ist bewusst: Digitale Regulierung berührt gleichzeitig IT, Recht, Procurement, Geschäftsführung, HR und Lieferkette. Eine Perspektive, die nur eine dieser Dimensionen kennt, liefert unvollständige Antworten. Die Leitfäden versuchen, alle relevanten Dimensionen gleichzeitig zu adressieren – mit dem Bewusstsein, dass in der Praxis selten ein Team allein zuständig ist und die wirklichen Herausforderungen meistens an den Schnittstellen entstehen.
Die Perspektive «Schweizer KMU im EU-Kontext» ist nicht zufällig. Sie spiegelt langjährige Arbeit an der Schnittstelle zwischen Schweizer Geschäftspraxis und europäischem Regulierungsrahmen: die Erfahrung, was es konkret bedeutet, wenn ein EU-Kundenvertrag plötzlich DORA-Klauseln enthält, wenn ein Procurement-Fragebogen AI-Act-Anforderungen stellt oder wenn ein Lieferant keine NIS2-konformen Sicherheitsnachweise liefern kann. Diese Leitfäden sind aus genau diesen Situationen heraus entstanden – nicht aus dem Lesen von Gesetzestexten, sondern aus der Erfahrung ihrer Auswirkungen.
Die Risiko-Ampel des AI Acts klingt einfach: Rot, Gelb, Orange, Grün. In der Praxis ist die Einstufung alles andere als trivial. Dieselbe Technologie kann – je nach Einsatzzweck – Minimal Risk oder High Risk sein. Und eine falsche Einstufung hat Konsequenzen: zu wenig Compliance kostet Vertrauen und Verträge, zu viel kostet Ressourcen und macht Dokumentation unglaubwürdig.
Dieser Leitfaden geht weiter als eine Tabelle. Er erklärt die Logik hinter der Ampel, zeigt Grenzfälle und wie man sie auflöst, und beschreibt die Vertragskonsequenzen jeder Einstufung.
Jede Stufe wird hier nicht nur definiert, sondern mit der Managementfrage verbunden, die sie auslöst.
Die Ampel klingt klar. In der Praxis ist sie es nicht immer. Hier sind die Konstellationen, die in Mandantengesprächen immer wieder zu Diskussionen führen.
Wann ist ein HR-Tool High Risk?
| High Risk wenn... | Nicht High Risk wenn... |
|---|---|
| Das Tool trifft oder beeinflusst Entscheidungen über Einstellung, Beförderung, Kündigung oder Lohnhöhe | Das Tool nur Daten aggregiert oder visualisiert, ohne Entscheidungsempfehlung |
| Das Tool automatisch Kandidaten filtert oder rankt | Das Tool Bewerbungsunterlagen formatiert oder zusammenfasst |
| Das Tool Leistungsbewertungen generiert, die Managemententscheidungen beeinflussen | Das Tool Kalender-Management oder Meeting-Planung übernimmt |
Kreditwürdigkeitsprüfungen sind explizit als High Risk aufgeführt. Aber nicht jede Risikobewertung ist eine Kreditwürdigkeitsprüfung.
| High Risk wenn... | Nicht High Risk wenn... |
|---|---|
| KI bewertet Kreditwürdigkeit natürlicher Personen | KI analysiert Ausfallwahrscheinlichkeit von Unternehmensanleihen |
| KI bewertet Versicherungsrisiken für Einzelpersonen | KI analysiert Marktdaten ohne Personenbezug |
| KI-Output beeinflusst Zugangsentscheidungen zu Finanzprodukten | KI unterstützt Fraud Detection ohne Personenprofilierung |
Das ist der häufigste Grenzfall: Ein Unternehmen setzt ein LLM (Large Language Model) für interne oder externe Zwecke ein. Wann ist das High Risk, wann nur Transparenz-pflichtig?
| Use Case | Risikoklasse | Begründung |
|---|---|---|
| LLM für interne Dokumentenerstellung | Minimal Risk | Keine Auswirkungen auf Dritte |
| Chatbot im Kundensupport | Begrenztes Risiko (Transparenz) | Nutzer interagieren direkt mit KI |
| LLM generiert Kreditanträge-Beurteilungen | High Risk | Beeinflusst Kreditentscheidungen |
| LLM im HR für Stellenausschreibungen | Grenzfall – wahrscheinlich Minimal Risk | Nur Content-Erstellung, kein Entscheidungseinfluss auf Personen |
| LLM filtert Bewerbungen vor | High Risk | Filtert Kandidaten, beeinflusst Einstellungsentscheidung |
| LLM für Vertragszusammenfassungen | Minimal Risk | Unterstützungsfunktion ohne Entscheidungsrelevanz |
| LLM generiert Deepfakes für Marketing | Begrenztes Risiko (Transparenz) | Kennzeichnung als synthetischer Inhalt erforderlich |
GPAI-Modelle (große Sprachmodelle wie GPT-4, Claude, Gemini) haben eigene Regelungen. Das ist relevant für Schweizer KMU, die solche Modelle nutzen oder in eigene Produkte integrieren.
| Situation | Was gilt | Was zu tun ist |
|---|---|---|
| Sie nutzen ein GPAI-Modell als Deployer | Pflichten des GPAI-Anbieters (z.B. OpenAI) gelten für ihn. Sie müssen seine Nutzungsbedingungen einhalten. | Nutzungsbedingungen prüfen. Verbotene Use Cases kennen. |
| Sie integrieren GPAI in Ihr eigenes Produkt und verkaufen es | Sie werden möglicherweise Provider für den darüber liegenden Use Case. Risikoklasse hängt vom Use Case ab. | Use Case klassifizieren. Wenn High Risk: volle Provider-Pflichten. |
| Sie fine-tunen ein GPAI-Modell und vertreiben es | Wahrscheinlich Provider-Pflichten für das angepasste Modell. | Rechtliche Einschätzung einholen. Dokumentation aufbauen. |
| # | Frage | Was die Antwort bedeutet |
|---|---|---|
| 1 | Für welchen konkreten Zweck wird das System eingesetzt – nicht wie, sondern wozu? | Die Risikoklasse hängt am Zweck, nicht an der Technologie. Dieselbe Technologie kann Minimal Risk und High Risk sein. |
| 2 | Hat der Output des Systems Auswirkungen auf Menschen – und können diese Auswirkungen negativ sein? | Wenn ja: wahrscheinlich kein Minimal Risk. Weiter mit Frage 3. |
| 3 | In welche der im AI Act explizit genannten Kategorien fällt der Use Case? | Die AI-Act-Annex-Listen sind die verbindliche Referenz. Wenn ein Use Case dort aufgeführt ist, ist er High Risk. |
Ein Use Case ist erst eingestuft, wenn das Protokoll vollständig ist. Das ist kein bürokratischer Akt – es ist Ihr Schutz, wenn ein Kunde die Einstufung bestreitet.
| Element | Was dokumentiert wird | Warum es wichtig ist |
|---|---|---|
| Use-Case-Beschreibung | Konkreter Einsatzzweck in 3–5 Sätzen | Ohne klare Beschreibung ist jede weitere Einschätzung wertlos |
| Betroffene Personengruppen | Wer ist von Output betroffen? Wie direkt? | Bestimmt, ob Grundrechte-Relevanz besteht |
| Kategorie-Check | Ist der Use Case in den AI-Act-Annexen aufgeführt? | Verbindliche Referenz; wenn ja → High Risk |
| Einstufungs-Ergebnis | Risikostufe + Begründung | Kernaussage des Protokolls |
| Datum und Verantwortlicher | Wer hat eingestuft, wann | Nachvollziehbarkeit bei Updates und Audits |
| Nächste Review | Wann wird die Einstufung überprüft? | Einstufungen sind nicht permanent; Use Cases ändern sich |
Die Risikostufe eines Use Cases bestimmt direkt, welche Vertragsklauseln EU-Kunden einbringen – und welche Sie akzeptieren können.
Minimal Risk bedeutet keine gesetzlichen Pflichten – aber nicht keine Kundenanforderungen. EU-Kunden verlangen oft auch für Minimal-Risk-Systeme:
Schriftliche Bestätigung der Einstufung mit Begründung
Erklärung, dass das System nicht in verbotenen Kategorien eingesetzt wird
Grundlegende Transparenz über eingesetzte Technologie
Für Chatbots und generative KI muss die Kennzeichnung im Produkt selbst sichtbar sein. Hier sind die Mindestanforderungen:
Beim Start einer Interaktion: Hinweis 'Sie interagieren mit einem KI-System'
Bei KI-generierten Texten, die als menschlich erscheinen könnten: Kennzeichnung
Bei Deepfakes: explizite Kennzeichnung als synthetischer Inhalt
| Anforderung | Was das bedeutet | Typischer Nachweis |
|---|---|---|
| Risikomanagement-System | Dokumentierter Prozess zur Identifikation und Kontrolle von Risiken | Risikoregister + Review-Protokoll |
| Datengouvernanz | Herkunft, Qualität, Bias-Kontrolle der Trainingsdaten | Data Sheet oder Data Card |
| Technische Dokumentation | AI System Card + Architekturübersicht | Strukturiertes Dokument, nicht Freitext |
| Transparenz für Deployer | Deployer müssen wissen, wie das System funktioniert | Instructions for Use |
| Human Oversight | Mechanismus, mit dem Menschen eingreifen und korrigieren können | Freigabeprozess-Dokumentation + Eskalationspfad |
| Logging | Protokollierung von Ein- und Ausgaben | Logging-Policy + Aufbewahrungsregeln |
| Robustheit und Cybersicherheit | System muss Angriffen und Fehlern standhalten | Testprotokolle (Adversarial Testing) |
| Post-Market-Monitoring | Laufende Überwachung nach Inbetriebnahme | Monitoring-Konzept + KPI-Reporting |
'Unser System ist nur ein Hilfsmittel – die Entscheidung trifft immer ein Mensch.' Das stimmt in der Theorie. In der Praxis trifft der Mensch nur dann eine eigenständige Entscheidung, wenn er auch tatsächlich in der Lage ist, die KI-Empfehlung zu überstimmen – mit realistischem Zeitaufwand und ausreichender Information.
'Wir setzen GPT-4 ein, das ist Minimal Risk.' Falsch. GPT-4 selbst ist ein GPAI-Modell. Was es in Ihrer Anwendung tut, bestimmt die Risikoklasse. Wenn GPT-4 Bewerbungen filtert: High Risk. Wenn GPT-4 Meeting-Notizen zusammenfasst: Minimal Risk.
Eine Einstufung ohne Datum ist wertlos. Bei einem Audit oder einem Kundengespräch wird gefragt: Wann haben Sie eingestuft? Auf welcher Basis? Was hat sich seitdem geändert? Ohne Protokoll können Sie diese Fragen nicht beantworten.
Manche KMU stufen prophylaktisch alles als High Risk ein, 'um auf der sicheren Seite zu sein'. Das erzeugt Dokumentationspflichten, die niemand erfüllen kann und will – und es macht die Einstufung unglaubwürdig, weil klar ist, dass nicht unterschieden wurde.
| Thema | Im Hauptleitfaden |
|---|---|
| Rollenbestimmung (Provider vs. Deployer) | Abschnitt 1.2 mit Rollentabelle und Kipp-Risiko |
| Provider-Pflichten im Detail | Abschnitt 2.1 mit Dokumentationsanforderungen |
| Vertragsklauseln und Verhandlungslinien | Abschnitt 3.2 mit kommentierten Klauselbeispielen |
| Branchenprofile | Abschnitt 5 mit vier konkreten CH-KMU-Szenarien |
| AI Act + NIS2 + DORA im Zusammenspiel | Abschnitt 6 mit Überschneidungstabelle |
| NBK Legal Rechts- und Compliance-Beratung EU-Digitalregulierung · Datenschutz · Cybersicherheit Schweiz · EU | Website www.nbklegal.online Alle Leitfäden der Serie www.nbklegal.online/leitfäden |
|---|