Sobald Sie ein KI-Feature ausliefern, einen Assistenten, eine Zusammenfassungsfunktion, ein Scoring, eine Empfehlung oder einen generativen Baustein, stellt sich nicht mehr die Frage, ob der EU AI Act Sie betrifft, sondern in welcher Rolle und in welcher Tiefe. Verordnung (EU) 2024/1689 reicht über Art. 2 Abs. 1 lit. c auch zu Schweizer und britischen Anbietern, sobald der Output in der EU genutzt wird. Ein einziger Geschäftskunde in Deutschland oder Frankreich genügt, um in den Anwendungsbereich zu fallen.

Für die meisten B2B-SaaS-Anbieter ist die Nachricht beruhigend: Ihre KI-Features sind nicht hochrisikobehaftet. Sie unterliegen vor allem Transparenzpflichten nach Art. 50. Für einige wenige Use Cases greift der Hochrisiko-Pfad nach Annex III. Wer ein eigenes Modell bereitstellt, trifft zusätzlich GPAI-Pflichten. Die einzig falsche Reaktion ist, gar nicht zu klassifizieren. Dieser Beitrag zeigt, was der AI Act für SaaS mit KI-Features konkret bedeutet, wie sich die Rollen verteilen, wie alles mit Ihrem Auftragsbearbeitungsvertrag und dem Vendor Security Review verzahnt ist und wie Sie heute pragmatisch starten.

Für die grosse Mehrheit der KI-Features in B2B-SaaS ist Art. 50 die zentrale Norm. Vier Konstellationen sind relevant. Erstens: Wer ein KI-System betreibt, das direkt mit natürlichen Personen interagiert, etwa ein Chatbot oder ein Support-Assistent, muss die betroffene Person darüber informieren, dass sie mit einer KI spricht, sofern dies nicht offensichtlich ist. Zweitens: Wer synthetische Audio-, Bild-, Video- oder Textinhalte generiert, muss diese maschinenlesbar als künstlich erzeugt kennzeichnen. Drittens: Deepfakes sind gesondert offenzulegen. Viertens: KI-generierte Texte zu Angelegenheiten von öffentlichem Interesse sind als solche zu kennzeichnen.

In der Praxis heisst das für SaaS-Anbieter: ein Hinweis im UI, dass eine Funktion KI-gestützt ist, eine Kennzeichnung generierter Inhalte und eine saubere Dokumentation dieser Massnahmen. Das ist gut beherrschbar und sollte Teil Ihrer Produkt- und Release-Prozesse sein. Wichtig: Art. 50 trifft sowohl Anbieter als auch Betreiber, je nach Funktion. Wenn Sie das KI-System bereitstellen, sind Sie als Anbieter für die technische Kennzeichnung verantwortlich; Ihr Geschäftskunde als Betreiber ist für die Information seiner Endnutzer verantwortlich. Beide Pflichten greifen ineinander, und beide sollten vertraglich klar adressiert sein.

Hochrisiko ist die Ausnahme, nicht die Regel, aber sie trifft einige B2B-SaaS-Features unmittelbar. Annex III nennt acht Cluster. Für SaaS-Anbieter sind in der Praxis vor allem drei relevant. Cluster 4 (Beschäftigung und Personalmanagement) erfasst HR-Tech: KI für CV-Screening, Kandidaten-Ranking, Bewerber-Targeting, Leistungsbewertung oder Verhaltensbeobachtung. Cluster 5 (Zugang zu wesentlichen Dienstleistungen) erfasst Fintech und Insurtech: Kredit-Scoring (ausser reiner Betrugserkennung) sowie Risikobewertung und Preisgestaltung in der Lebens- und Krankenversicherung. Cluster 1 (Biometrie) trifft Anbieter von Identitäts- und Zutrittsfunktionen.

Wenn Ihr KI-Feature in einen dieser Bereiche fällt, ist der Pflichtenkatalog umfangreich: Risikomanagementsystem (Art. 9), Data Governance (Art. 10), technische Dokumentation (Art. 11), Logging (Art. 12), Transparenz gegenüber Betreibern (Art. 13), menschliche Aufsicht (Art. 14), Robustheit (Art. 15), Qualitätsmanagement (Art. 17) und Konformitätsbewertung (Art. 43). Es gibt einen Ausnahmemechanismus nach Art. 6 Abs. 3 für Systeme ohne signifikantes Risiko, etwa bei eng umrissenen vorbereitenden Aufgaben. Diese Ausnahme ist aber kein Selbstläufer: Sie verlangt eine dokumentierte Begründung und eine Registrierung, und ein System, das Profiling natürlicher Personen durchführt, ist davon ausgeschlossen. Die Erstklassifikation entscheidet hier über sechsstellige Compliance-Programme.

Eine eigene Pflichtenschicht trifft Anbieter von General-Purpose-AI-Modellen (GPAI). Die meisten SaaS-Anbieter sind hier nicht betroffen: Wer ein bestehendes Foundation-Modell über eine API nutzt und darauf ein Feature aufsetzt, stellt das Modell nicht selbst bereit und ist kein GPAI-Anbieter. Wer hingegen ein eigenes Modell trainiert, ein bestehendes Modell wesentlich weitertrainiert (Fine-Tuning in einem Umfang, der eine eigene Bereitstellung begründet) oder ein Modell unter eigenem Namen verfügbar macht, kann GPAI-Pflichten auslösen.

Die Kernpflichten für GPAI-Anbieter umfassen technische Dokumentation des Modells, Informationen für nachgelagerte Anbieter, die das Modell integrieren, eine Strategie zur Einhaltung des EU-Urheberrechts und eine hinreichend detaillierte Zusammenfassung der Trainingsdaten. Für besonders leistungsfähige Modelle mit systemischem Risiko gelten verschärfte Pflichten. Die Abgrenzung zwischen blosser API-Nutzung und eigener Bereitstellung ist im Einzelfall zu prüfen. Sie ist für Ihre Rolle und Ihren Pflichtenumfang entscheidend und gehört an den Anfang jeder Klassifikation.

Die Rollenverteilung ist die wichtigste Weichenstellung, und bei SaaS ist sie oft kontraintuitiv. Anbieter ist, wer ein KI-System entwickelt und unter eigenem Namen in Verkehr bringt. Als SaaS-Anbieter, der ein KI-Feature in sein Produkt einbaut und an Geschäftskunden ausliefert, sind Sie in der Regel Anbieter dieses KI-Systems, auch wenn Sie im Hintergrund ein fremdes Foundation-Modell nutzen. Ihr Geschäftskunde, der das Feature in seinem Betrieb einsetzt, ist Betreiber.

Diese Aufteilung hat handfeste Folgen. Als Anbieter tragen Sie bei Hochrisiko-Features die volle Compliance-Last nach Art. 16, von der technischen Dokumentation bis zur Konformitätsbewertung. Ihr Kunde als Betreiber trägt Sorgfalts-, Aufsichts- und Informationspflichten nach Art. 26, und bei bestimmten Konstellationen, etwa Banken oder öffentliche Stellen, eine Grundrechte-Folgenabschätzung nach Art. 27. Achtung bei Konfigurierbarkeit: Wenn ein Kunde Ihr System wesentlich modifiziert oder unter eigenem Brand weitervertreibt, kann er nach Art. 25 selbst zum Anbieter werden. Klären Sie diese Rollen pro Feature, nicht pauschal pro Produkt, und halten Sie sie vertraglich fest.

KI-Compliance steht nie für sich allein. Verarbeitet Ihr KI-Feature Personendaten, greifen parallel das Schweizer Datenschutzgesetz (nDSG) und, bei EU-Bezug, die DSGVO. Ihr Auftragsbearbeitungsvertrag (AVV nach Art. 9 nDSG, DPA nach Art. 28 DSGVO) muss die KI-Verarbeitung präzise abbilden: welche Daten in welches Feature fliessen, ob sie zur Modellverbesserung genutzt werden (im B2B-Kontext regelmässig auszuschliessen oder strikt einzugrenzen), welche Unterauftragsverarbeiter beteiligt sind, etwa der Modellanbieter, und wo die Verarbeitung stattfindet.

Zwei Punkte verdienen besondere Aufmerksamkeit. Erstens die Sub-Prozessoren-Liste: Wenn Ihr KI-Feature einen externen Modellanbieter aufruft, ist dieser ein Unterauftragsverarbeiter und gehört transparent in Ihre Liste, inklusive Datenresidenz und Datenübermittlung in Drittländer. Zweitens automatisierte Einzelentscheidungen: Trifft Ihr Feature Entscheidungen mit erheblicher Wirkung auf Personen, sind Art. 22 nDSG und Art. 22 DSGVO einschlägig, mit Informations-, Interventions- und Begründungspflichten. Eine Datenschutz-Folgenabschätzung kann erforderlich sein. AI-Act-Klassifikation, DPA und DSFA gehören in dasselbe Dossier, sonst widersprechen sich Ihre Antworten gegenüber Kunden und Aufsichtsbehörden.

Der Praxisdruck kommt selten zuerst von der Aufsichtsbehörde, sondern vom Geschäftskunden. Enterprise-Einkauf und Third-Party-Risk-Management fragen heute systematisch nach Ihren KI-Features. Typische Fragen im Security-Fragebogen lauten: Welche KI-Funktionen verarbeiten unsere Daten? Werden unsere Daten zum Training oder zur Modellverbesserung genutzt? Welcher Modellanbieter steht dahinter, und wo werden die Daten verarbeitet? Wie ist Ihre KI-Governance organisiert? Gibt es eine AI-Act-Klassifikation Ihrer Features? Wie stellen Sie menschliche Aufsicht und Transparenz sicher?

Wer diese Fragen schnell, präzise und konsistent beantwortet, hält den Deal in Bewegung. Wer zögert oder widersprüchlich antwortet, riskiert wochenlange Verzögerungen im Procurement oder den Verlust des Mandats. Genau hier zahlt sich Vorarbeit aus: ein KI-Inventar, eine dokumentierte Klassifikation, klare DPA-Klauseln zur KI-Nutzung, eine aktuelle Sub-Prozessoren-Liste und ein Trust-Center-Eintrag zu Ihrer KI-Governance. Sicherheit und Compliance werden so vom Kostenpunkt zum Verkaufsargument: Sie verkürzen den Review und gewinnen Vertrauen.

Die Fristen des AI Act sind in Bewegung. Die Transparenzpflichten nach Art. 50 sind angelegt, die Hochrisiko-Fristen liegen ab 2026/2027 und stehen im Rahmen des Digital Omnibus in Revision, im Einzelfall ist das Datum zu prüfen. Diese Unsicherheit ist kein Grund zu warten, sondern ein Grund, die Grundlagen jetzt zu schaffen. Beginnen Sie mit dem, was unabhängig von Fristen Bestand hat: einem vollständigen Inventar Ihrer KI-Features und ihrer Datenflüsse, einer dokumentierten Erstklassifikation (Transparenz, Hochrisiko, GPAI) und einer klaren Rollenzuordnung Anbieter vs Betreiber pro Feature.

SIDD setzt hier mit zwei Leistungen an. Der AI Governance Check (ab CHF 3'900) liefert Ihnen ein dokumentiertes KI-Inventar, die Erstklassifikation Ihrer Features und eine priorisierte Massnahmenliste, die marktüberwachungs- und reviewfest ist. Der AI Officer (ab CHF 500/Monat) hält Ihre KI-Governance laufend aktuell, pflegt Inventar und Klassifikation und beantwortet die KI-Fragen im Security Review verlässlich. Ergänzend verzahnen wir die Datenschutzseite über Datenschutzberatung (nDSG) und, bei EU-Bezug, DSGVO-DPO und EU-Vertreter. Eine erste Einordnung Ihrer KI-Features besprechen wir über das Kontaktformular; ein vollständiges Programm beantragen Sie über unser Offerte-Formular.