Swiss Room · Leitfaden · KI-Governance · 1 von 15
EU AI ACT
Praxisleitfaden für Schweizer KMU
Adressaten · Vorabklärung · Tiefe
Primär für
Geschäftsleitung · Produktverantwortliche · KI-Entwickler:innen · Compliance
Auch hilfreich: Recht · Procurement
Was vorab klar sein sollte
KI-Systeme im Unternehmen vorhanden oder geplant. Keine juristischen Vorkenntnisse nötig.
Tiefenstufe
Vertiefung — der Vollleitfaden zum AI Act.
Nicht der richtige Leitfaden? Wenn Sie zuerst verstehen möchten, ob ein KI-System überhaupt unter den AI Act fällt: starten Sie mit der AI Act Risiko-Ampel.
Was dieser Leitfaden Ihnen gibt
- Schnelltest: Bin ich vom AI Act betroffen?
- Risikoklassen-Zuordnung für Ihre KI-Anwendungen
- Konkrete Compliance-Schritte mit Priorisierung
- Verbindung zu NIS2 und DORA
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.
Vorwort: Wie man diesen Leitfaden benutzt
Dieser Leitfaden ist kein Kommentar zum EU AI Act. Er ist ein Arbeitsinstrument.
Er enthält Entscheidungsbäume, Vertragskommentare, Branchenprofile und eine Liste typischer Fehler aus der Praxis – Punkte, die in vielen Leitfäden unterbelichtet bleiben, weil sie konkrete Festlegungen erfordern. Aus der Praxis heraus treffen wir diese Festlegungen.
1. Bin ich betroffen? – Entscheidungslogik
Stopp. Bevor Sie weiterlesen: Beantworten Sie die folgenden Fragen der Reihe nach. Sie ersparen sich damit den Rest des Leitfadens – oder wissen genau, welche Teile relevant sind.
1.1 Der Schnelltest in vier Schritten
1.2 Rollen im Überblick
| Rolle | Kurzdefinition | Typisches CH-KMU-Beispiel | Hauptrisiko |
|---|---|---|---|
| Provider | Entwickelt KI-System oder bringt es unter eigenem Namen auf den Markt | SaaS-Anbieter mit KI-Funktion, White-Label-Lösung | Umfassendste Pflichten; Rollenübernahme oft unbewusst |
| Deployer | Setzt fremdes KI-System im eigenen Betrieb ein | HR-Tool mit KI-Scoring, KI-Chatbot im Kundensupport | Einsatzprozesse, Human Oversight, Monitoring |
| Importer / Distributor | Bringt Nicht-EU-KI in den EU-Markt oder vertreibt sie | CH-Unternehmen resellt US-KI-Tool in die EU | Verantwortungszuordnung, Dokumentationspflichten |
| Lieferkettenakteur | Liefert Daten, Modelle oder Komponenten für EU-KI | Datenannotation, Modell-API, Cloud-Hosting | Vertragliche Flow-Downs, Incident-Informationspflichten |
1.3 Risikoklassen – was sie für Sie bedeuten
Als didaktisches Modell werden oft „vier Risikoklassen" genannt. Das ist eine Vereinfachung – die gesetzliche Systematik umfasst zusätzlich GPAI-Regeln und rollenspezifische Pflichten, und „Minimal Risk" ist keine definierte gesetzliche Klasse. Wichtig ausserdem: Hochrisiko-KI entsteht auf zwei Wegen – als produktbezogene Sicherheitskomponente über Art. 6 Abs. 1 + Anhang I (z. B. Medizinprodukte, Maschinen), oder über die eigenständigen Anwendungsfälle des Anhang III. Entscheidend ist nicht, welche Technologie Sie einsetzen, sondern wofür – und in welcher Rolle.
| Klasse | Was ist verboten / geregelt | Typische Use Cases | Konsequenz für CH-KMU |
|---|---|---|---|
| Unacceptable | Social Scoring, manipulative Verhaltenssteuerung, biometrische Echtzeitüberwachung öffentlicher Räume | Selten direkt relevant, aber: prüfen Sie Recruiting-Tools und Scoring-Systeme kritisch | Use Case sofort stoppen. Keine Übergangsregelung. Seit Februar 2025 in Kraft. |
| High Risk | Auswirkungsstarke KI in Bereichen wie HR, Kreditvergabe, Bildung, kritische Infrastruktur | Recruiting-Systeme, Kreditwürdigkeitsprüfung, Medizinprodukte mit KI-Komponente | Vollständige Compliance-Pflichten (Doku, Risikomanagement, Human Oversight, Logging, CE) |
| Transparenz | Für die einzelnen Tatbestände des Art. 50: Offenlegung der KI-Interaktion und Kennzeichnung bestimmter synthetischer Inhalte – nicht jede KI-Nutzung pauschal | Chatbots, generative KI, Deepfakes, KI-Inhalte zu Angelegenheiten von öffentlichem Interesse | Kennzeichnungspflichten in UI und Kommunikation je nach Tatbestand; verhältnismässig einfach umzusetzen |
| Minimal Risk | Keine spezifischen Hochrisiko-Pflichten allein aufgrund dieser Einstufung | Spamfilter, interne Analysetools, Assistenzsysteme ohne Entscheidungsrelevanz | Andere AI-Act-Pflichten (z. B. Art. 50, AI-Literacy) und allgemeines Recht können dennoch gelten; Einstufung dokumentieren |
2. Was wird von mir verlangt?
Dieser Abschnitt ist nach Rolle strukturiert. Lesen Sie nur den für Sie relevanten Teil.
2.1 Provider-Pflichten (Sie entwickeln oder vermarkten KI)
Technische Dokumentation
Was Sie haben müssen – nicht als Selbstzweck, sondern weil EU-Kunden es verlangen:
AI System Card: Zweck, Funktionsweise, Trainingsdaten, Grenzen, bekannte Risiken, Einsatzbedingungen
Model Card: Architektur, Performance-Metriken, Bias-Tests, Evaluationsverfahren
Architekturübersicht: Schnittstellen, Datenflüsse, Abhängigkeiten von Drittkomponenten (Cloud, APIs)
Risikomanagement-Dokumentation: Identifizierte Risiken, Massnahmen, Testprotokolle
Logging und Monitoring
Für High-Risk-KI gesetzlich vorgeschrieben; für alle anderen von EU-Kunden faktisch verlangt:
Eine dem Zweck und Risiko angemessene automatische Ereignisprotokollierung; welche Eingaben, Ausgaben, Statusinformationen und Entscheidungen gespeichert werden, ist rechts- und risikobasiert festzulegen (auch mit Blick auf Datenschutz und Datenminimierung)
Performance-Monitoring muss nachweisbar sein
Anomalien müssen erkennbar und eskalierbar sein
Aufbewahrungspflicht: Provider und Deployer von Hochrisiko-KI müssen die automatisch erzeugten Logs, soweit diese ihrer Kontrolle unterliegen, grundsätzlich mindestens sechs Monate aufbewahren, sofern kein anderes anwendbares Recht eine abweichende Frist vorsieht (Art. 19 für Provider, Art. 26 Abs. 6 für Deployer)
Human Oversight
Das ist der Punkt, bei dem viele KMU zu wenig konkret sind. 'Human Oversight' bedeutet nicht, dass ein Mensch dabei sitzt – es bedeutet, dass ein Mensch die KI-Entscheidung korrigieren oder stoppen kann, bevor sie Wirkung entfaltet.
Freigabeprozesse für KI-Entscheidungen mit hoher Auswirkung dokumentieren
Eskalationspfade definieren und testen
Zuständigkeiten namentlich zuordnen, nicht nur rollenbasiert
2.2 Deployer-Pflichten (Sie setzen fremde KI ein)
Als Deployer tragen Sie weniger Pflichten als ein Provider – aber mehr als die meisten KMU annehmen.
Einsatz gemäss Anweisungen: Sie müssen die Nutzungsbedingungen des Providers einhalten. Abweichungen können Sie zum Provider machen.
Zweckbindung: KI-Systeme dürfen nicht für andere als die vorgesehenen Zwecke eingesetzt werden.
Mitarbeiterinformation: Betroffene Mitarbeitende müssen informiert werden, wenn KI Entscheidungen über sie trifft.
Kundentransparenz: Kunden müssen wissen, wenn sie mit einem KI-System interagieren.
Incident-Meldung: Schwerwiegende Vorfälle müssen an den Provider und – je nach Setup – an zuständige Stellen kommuniziert werden.
2.3 Lieferkettenakteur-Pflichten
Wenn Sie Daten, Modelle oder Infrastruktur für EU-Kunden bereitstellen, die selbst KI-Systeme betreiben:
Data Governance: Herkunft, Qualität und Nutzungsrechte Ihrer Daten müssen nachvollziehbar sein
Bias-Prüfung: Wenn Ihre Daten in KI-Entscheidungen einfliessen, erwarten EU-Kunden Nachweise zur Verzerrungskontrolle
Incident-Kommunikation: Wenn ein Datenproblem einen Vorfall beim Kunden auslöst, müssen Sie schnell und strukturiert informieren können
Subdienstleister-Transparenz: Wenn Sie selbst auf Cloud-Provider oder Drittmodelle angewiesen sind, müssen Sie das offenlegen und in Ihre Governance einbinden
3. Was können Sie von Ihren EU-Kunden verlangen?
Dieser Abschnitt ist andernorts oft unterbelichtet. Viele Compliance-Dokumente behandeln Schweizer KMU vor allem als passive Empfänger von Anforderungen. Das ist falsch. Sie haben eigene Rechte – und die müssen Sie aktiv einfordern.
3.1 Informationen, die Sie brauchen – und verlangen können
Um Ihren Teil der AI-Act-Compliance zu erfüllen, brauchen Sie von Ihren EU-Kunden folgende Informationen. Wenn diese nicht geliefert werden, können Sie Ihre eigenen Pflichten nicht erfüllen – und das ist ein Vertragsrisiko für den Kunden, nicht für Sie.
| Was Sie brauchen | Warum Sie es verlangen dürfen | Was Sie tun, wenn es verweigert wird |
|---|---|---|
| Risikoklassifizierung des Use Cases durch den EU-Kunden | Ohne Klassifizierung können Sie Ihre eigene Rolle nicht bestimmen | Schriftlich nachfragen; fehlende Auskunft als Vertragsrisiko dokumentieren |
| Klare Rollenzuordnung (wer ist Provider, wer Deployer) | Rollenunklarheit kann Sie unbeabsichtigt zum Provider machen | Rollenzuordnung ausdrücklich im Vertrag festlegen lassen |
| Instructions for Use des eingesetzten KI-Systems | Deployer müssen gemäss Anweisungen handeln – ohne diese ist das unmöglich | Deployment bis zur Lieferung zurückstellen |
| Incident-Meldewege und Fristen auf Kundenseite | Ihre eigene Incident-Response hängt von den Fristen des Kunden ab | Eigene Standardfristen vorschlagen (24h/72h/1 Monat) |
| Scope und Umfang von Audit-Rechten | Unbegrenzte Audit-Rechte sind unzumutbar; Umfang muss definiert sein | Gegenvorschlag mit zeitlicher und inhaltlicher Begrenzung einreichen |
3.2 Vertragsklauseln: Was ist akzeptabel, was nicht
Hier folgen typische Klauseltypen aus der Praxis – mit einer klaren Einschätzung, wo die Verhandlungslinie liegt.
Audit-Klauseln
Flow-Down-Klauseln (Weitergabe an Ihre Subdienstleister)
Incident-Meldepflichten
4. Die fünf häufigsten Fehler in der Praxis
Diese Fehler wiederholen sich in Mandantengesprächen regelmässig. Sie kosten Zeit, Geld und Verhandlungsposition.
Fehler 1: Rolle pauschal statt use-case-spezifisch bestimmen
Viele KMU entscheiden einmalig: «Wir sind Deployer.» Das ist falsch. Die Rolle hängt vom konkreten Use Case ab. Dasselbe Unternehmen kann für Produkt A Deployer sein und für Produkt B – weil es dort unter eigenem Namen vermarktet – Provider.
Fehler 2: Compliance-Dokumentation als einmalige Aufgabe behandeln
Die AI System Card, die Rollenmatrix und das Risikomanagement-Dokument werden erstellt – und dann vergessen. EU-Kunden merken das bei der ersten Nachfrage: veraltete Dokumente sind schlechter als gar keine, weil sie Vertrauen zerstören.
Fehler 3: Audit-Rechten pauschal zustimmen
Unter Zeitdruck werden Vertragsanhänge mit unbeschränkten Audit-Rechten unterschrieben. Das erzeugt operative Dauerbelastung und ist rechtlich riskant, weil Betriebsgeheimnisse kaum mehr schützbar sind.
Fehler 4: Over-Compliance aus Unsicherheit
Das Gegenteil von Fehler 3: Manche KMU implementieren High-Risk-Compliance-Prozesse für Use Cases, die klar in die Kategorie «Minimal Risk» fallen – weil sie nicht sicher sind und lieber zu viel tun. Das kostet Ressourcen und macht die eigene Dokumentation unglaubwürdig, weil alles gleich behandelt wird.
Fehler 5: Lieferkette nicht einbinden
Das eigene KI-Governance-Konzept ist erstellt – aber der Cloud-Provider, der das Modell hostet, der Annotationsdienstleister und die API, die das Modell antreibt, sind nicht eingebunden. EU-Kunden wollen End-to-End-Nachweise. Wenn Ihre Subdienstleister nicht auskunftsfähig sind, sind Sie es auch nicht.
5. Branchenprofile: Was bedeutet das konkret für Sie?
Abstrakte Regulierung wird erst nützlich, wenn sie auf konkrete Situationen angewendet wird. Hier sind vier Profile, die typische Schweizer KMU-Konstellationen abbilden.
Profil A: Schweizer SaaS-Anbieter mit KI-Funktion, EU-Kunden im Mittelstand
| Ihre Rolle | Provider – Sie bringen ein KI-System unter eigenem Namen auf den Markt |
|---|---|
| Risikoklasse | Abhängig vom Use Case: Qualitätsprüfung → wahrscheinlich Minimal Risk. HR-Screening → wahrscheinlich High Risk |
| Was EU-Kunden verlangen | AI System Card, Rollenbestätigung Provider, Transparenzhinweise in Ihrer UI, Incident-Eskalationsweg |
| Priorität jetzt | Use-Case-Liste erstellen, pro Use Case Risikoklasse bestimmen, AI System Card für jeden High-Risk-Use-Case erstellen |
| Typisches Problem | Kunde klassifiziert Ihren Use Case als High Risk, obwohl Sie ihn als Minimal Risk eingestuft haben. Lösung: Risikoklassifizierung gemeinsam in der Vertragsvorbereitung klären, nicht erst bei der Implementierung. |
Profil B: Schweizer IT-Dienstleister, der KI-Tools für EU-Finanzinstitute integriert
| Ihre Rolle | Integrator / potenzieller Deployer – Sie konfigurieren und betreiben fremde KI-Systeme |
|---|---|
| Risikoklasse | Oft High Risk, da Finanzentscheidungen betroffen sind. Zusätzlich DORA-Relevanz (→ separater Leitfaden) |
| Was EU-Kunden verlangen | Dokumentierter Betriebsprozess, Human Oversight Nachweis, Logging-Architektur, Subdienstleister-Transparenz (Cloud, APIs) |
| Priorität jetzt | Betriebshandbuch für KI-Systeme erstellen, Human-Oversight-Prozesse schriftlich fixieren, Eskalationspfade testen |
| Typisches Problem | Sie werden faktisch zum Provider, weil Sie das System so stark anpassen, dass es als Ihre Lösung gilt. Prüfen Sie: Vermarkten Sie es unter eigenem Namen? Wenn ja → Provider-Pflichten. |
Profil C: Schweizer Datenspezialist, der Trainingsdaten für EU-KI-Systeme liefert
| Ihre Rolle | Lieferkettenakteur – kein direkter AI-Act-Adressat, aber vertraglich stark exponiert |
|---|---|
| Risikoklasse | Die Risikoklasse des Systems Ihres Kunden ist entscheidend – Sie müssen sie kennen |
| Was EU-Kunden verlangen | Datenherkunftsnachweise, Bias-Analyse, Nutzungsrechtsdokumentation, Qualitätsprotokolle |
| Priorität jetzt | Data Sheet für Ihre wichtigsten Datensätze erstellen (Herkunft, Aufbereitung, bekannte Limitierungen, Lizenz) |
| Typisches Problem | Kunde verlangt Garantien zu Bias-Freiheit, die Sie nicht geben können. Lösung: Dokumentieren Sie, was Sie getan haben (Tests, Aufbereitungsverfahren), nicht was das Ergebnis garantiert ist. |
Profil D: Schweizer Unternehmen, das intern KI-Tools (z.B. LLMs) einsetzt und EU-Kunden hat
| Ihre Rolle | Deployer – auch interne KI kann relevant sein (etwa bei Personal-, Kredit- oder Versicherungsentscheidungen, kritischer Infrastruktur, biometrischen Verfahren oder AI-Literacy). Massgeblich sind Zweck und Rolle, nicht die Kundenwahrnehmbarkeit. |
|---|---|
| Risikoklasse | Meist Transparenz oder Minimal Risk – aber prüfen Sie, ob KI-Output Entscheidungen über Personen beeinflusst |
| Was EU-Kunden verlangen | Transparenzhinweise wenn KI-generierte Inhalte geliefert werden, Einhaltung der Provider-Nutzungsbedingungen |
| Priorität jetzt | Interne KI-Nutzungsrichtlinie erstellen, klären wo KI-Output in Kundenleistungen einfliessen, Kennzeichnungsregeln definieren |
| Typisches Problem | Mitarbeitende nutzen KI-Tools ad hoc ohne Policy. Das macht Nachweise unmöglich. Eine interne Policy, die in zwei Stunden erstellt werden kann, löst dieses Problem. |
6. Wenn AI Act, NIS2 und DORA gleichzeitig gelten
Für Schweizer KMU, die EU-Kunden im Finanzsektor oder in kritischen Infrastrukturen bedienen, sind häufig alle drei Regime gleichzeitig relevant. Das ist kein Zufall: Sie adressieren verschiedene Aspekte derselben digitalen Wertschöpfungskette.
| Thema | AI Act | NIS2 | DORA |
|---|---|---|---|
| Kernfrage | Ist die KI sicher und transparent? | Ist die digitale Infrastruktur resilient? | Ist der Finanzbetrieb bei Störungen aufrechtzuerhalten? |
| Dokumentation | AI System Card, Risikoklassifizierung | Security Architecture, Risikomanagement | ICT Resilience Konzept, BCM/DR |
| Incident-Pflichten | Meldung schwerwiegender Vorfälle durch Provider | 24h Early Warning, 72h Notification | Mehrstufiges Reporting (initial/intermediate/final) |
| Lieferkette | Flow-Downs zu Subdienstleistern | End-to-End Sicherheitsanforderungen | Drittanbieter-Management und Exit-Strategien |
| Überschneidung | Logging-Anforderungen überlappen | Monitoring-Anforderungen überlappen | Alle drei verlangen strukturierte Incident-Response |
7. Was Sie jetzt tun – priorisiert
Nicht alles ist gleich dringend. Hier ist die Priorisierung nach Aufwand und Wirkung:
| Prio | Massnahme | Warum jetzt |
|---|---|---|
| 1 | Use-Case-Liste mit Rollenzuordnung erstellen | Grundlage für alles andere. Aufwand: 2–4 Stunden. Ohne diese Liste ist jede weitere Compliance-Arbeit ineffizient. |
| 2 | Laufende Verträge mit EU-Kunden auf AI-Act-Klauseln prüfen | Viele laufen bereits jetzt in Verträge, die AI-Act-Pflichten enthalten – oft unbemerkt. |
| 3 | AI System Card für jeden High-Risk-Use-Case erstellen | Das ist das Dokument, das EU-Kunden am häufigsten als Erstes verlangen. |
| 4 | Interne KI-Nutzungsrichtlinie verabschieden | Gilt für alle Mitarbeitenden. Verhindert unkontrollierten KI-Einsatz, der Ihre Compliance untergräbt. |
| 5 | Lieferantenmatrix für KI-relevante Subdienstleister erstellen | EU-Kunden fragen zunehmend nach Ihrer Sublieferantenkontrolle. |
| 6 | Proaktives Governance-Dokument an Top-3-EU-Kunden kommunizieren | Verlagert die Verhandlungsposition zu Ihren Gunsten. |
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 |
|---|
Lerngeschichte zum Thema
Ein konstruierter Compliance-Krimi macht greifbar, was sich aus Paragraphen allein nicht lesen lässt — wie Strukturen sich nicht abgesprochen haben, wie ein Befund nicht gemeldet wurde, wie das Nicht-Ereignis zum Ereignis wird.
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.