Swiss Room · Leitfaden · KI-Governance · 2 von 15
AI Act Risiko-Ampel
Praxisleitfaden für Schweizer KMU
Adressaten · Vorabklärung · Tiefe
Primär für
Geschäftsleitung · Produktverantwortliche
Auch hilfreich: IT · Recht
Was vorab klar sein sollte
Keine. Die Ampel ist eine erste Vorsortierung und braucht weder AI-Act- noch juristische Vorkenntnisse.
Tiefenstufe
Einstieg — visuelle Entscheidungshilfe.
Nicht der richtige Leitfaden? Für die operative Umsetzung benötigen Sie zusätzlich den AI Act Vollleitfaden.
Was dieser Leitfaden Ihnen gibt
- Schnelle Einordnung Ihrer KI-Anwendungen nach Risikoklasse
- Visuelle Ampel-Logik: Grün, Gelb, Rot
- Konkrete Handlungsempfehlungen pro Risikoklasse
- Verbindung zum ausführlichen AI-Act-Leitfaden
Use-Case-Klassifizierung · Grenzfälle · Vertragskonsequenzen · Entscheidungsbaum
Vorbemerkung
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.
Warum dieser Leitfaden existiert
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.
1. Die vier Risikostufen im Klartext
Jede Stufe wird hier nicht nur definiert, sondern mit der Managementfrage verbunden, die sie auslöst.
2. Grenzfälle – die schwierigen Einstufungen
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.
Grenzfall 1: HR-Tools
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 |
Grenzfall 2: Kreditvergabe und Scoring
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 Risiken oder Preise in der Leben- oder Krankenversicherung natürlicher Personen (Anhang III Nr. 5 lit. c) | KI analysiert Marktdaten ohne Personenbezug — oder bewertet Kfz-/Sach-/Haftpflicht-Risiken (nicht von Anhang III Nr. 5 erfasst) |
| KI-Output beeinflusst Zugangsentscheidungen zu Finanzprodukten | KI unterstützt Fraud Detection ohne Personenprofilierung |
Grenzfall 3: Generative KI im Unternehmenseinsatz
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 |
Grenzfall 4: GPAI – General Purpose AI
GPAI-Modelle (grosse 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. |
3. Den Einstufungsprozess in der Praxis umsetzen
3.1 Die drei Fragen, die immer zuerst kommen
| # | 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? | Anhang III ist die verbindliche Referenz. Steht ein Use Case dort, ist zunächst die Hochrisiko-Einstufung eröffnet; anschliessend ist die Ausnahmeprüfung nach Art. 6 Abs. 3 vorzunehmen und zu dokumentieren. |
3.2 Das Einstufungsprotokoll
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 |
4. Was jede Risikostufe vertraglich bedeutet
Die Risikostufe eines Use Cases bestimmt direkt, welche Vertragsklauseln EU-Kunden einbringen – und welche Sie akzeptieren können.
4.1 Minimal Risk – was trotzdem verlangt wird
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
4.2 Transparenzpflichtige Systeme – konkrete Umsetzung
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
4.3 High Risk – die vollständige Anforderungsliste
| 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 |
5. Die häufigsten Einstufungsfehler
Fehler 1: Use Case zu eng definieren
'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.
Fehler 2: Technologie mit Use Case verwechseln
'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.
Fehler 3: Einstufung ohne Datum und Begründung
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.
Fehler 4: Hochstufen ohne Konsequenzen
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.
6. Verbindung zum Hauptleitfaden AI Act
| 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 |
Kontakt & weitere Informationen
| NBK Legal Rechts- und Compliance-Beratung EU-Digitalregulierung · Datenschutz · Cybersicherheit Schweiz · EU | Website www.nbklegal.online Alle Leitfäden der Serie www.nbklegal.online/S_leitfaeden |
|---|
Wissen prüfen
Möchten Sie Ihr Wissen zu diesem Thema testen? Die folgenden Quiz- bzw. Lernkarten-Sets decken den Stoff dieses Stücks ab — jeweils mit Erklärung nach jeder Antwort bzw. Aufdeck-Logik.