Ein Logistik-Konzern verlangt von seinem SaaS-Lieferanten einen schriftlichen Nachweis zur Konformität mit dem EU AI Act, bevor er einen Pilotvertrag unterschreibt. Im Fragebogen dazu taucht ein Wort auf, das viele SaaS-Teams unterschätzen: Anbieter, nicht Betreiber. Die meisten kleinen und mittleren SaaS-Häuser gehen wie selbstverständlich davon aus, im Sinne der KI-Verordnung höchstens Betreiber zu sein – schließlich bauen sie ihr Produkt auf einem zugekauften Sprachmodell auf, das ein anderes Unternehmen trainiert hat. Dieser Irrglaube sitzt tief in der Compliance-Strategie vieler SaaS-Teams – und genau er verdient eine Richtigstellung.
Der Irrtum vom reinen Betreiber
Regelmäßig bouldert ein Bekannter von mir im Kletterzentrum Frankfurt-West. Kürzlich hat er mir sein kleines SaaS-Team beschrieben: ein zugekauftes GPAI-Modell als Motor, die Regulierungsfrage für erledigt gehalten, weil man ja nur Kunde des Modell-Anbieters sei. Genau hier liegt der Denkfehler: Sobald ein SaaS-Anbieter ein zugekauftes Modell anpasst, feintunt oder unter eigenem Produktnamen vermarktet, kann er vom Betreiber zum vollwertigen Anbieter im Sinne der Verordnung werden, mit allen Pflichten, die das nach sich zieht. Wo genau die Grenze zwischen einer bloßen Kundenanpassung und einer eigenständigen Anbieterrolle verläuft, kann selbst ich nicht immer sofort sagen, und dieser Punkt sorgt in fast jedem SaaS-Mandat für Rückfragen.
Welche Use Cases konkret unter die Hochrisiko-Kategorien von Anhang III fallen, ist ein eigenes, sehr technisches Thema, das an anderer Stelle ausführlicher behandelt gehört. Genau an der Schnittstelle zwischen zugekauftem Modell und eigenem Produkt entscheidet sich am Ende, in welche Rolle ein SaaS-Anbieter rutscht – ob als reiner Vermittler fremder Funktionalität oder als jemand, der das Modell so verändert, dass er die Verantwortung dafür übernimmt.
Wann wird aus dem Betreiber ein Anbieter?
Die Frage nach der eigenen Rolle stellt sich nicht einmalig beim Onboarding, sondern bei jedem relevanten Produkt-Update neu. SaaS-Teams sollten die Rollenprüfung fest in den Freigabeprozess für neue Features einbauen, als festen Punkt neben Security-Review und Datenschutz-Check, nicht als separates Rechtsprojekt, das einmal im Jahr stattfindet. Der Gedanke kam mir zuletzt bei einem Spaziergang durch den Grüneburgpark im Frankfurter Westend wieder in den Sinn, während ich über genau dieses Mandat nachdachte: wie leicht ein Feature-Release durchrutscht, ohne dass jemand im Team die Frage laut ausspricht.
Ein Mandant hatte vorher Webinare einer großen, überregional tätigen Unternehmensberatung gebucht, deren Inhalte klar auf DAX-Konzerne zugeschnitten waren, mit Fallbeispielen aus Konzernstrukturen, die mit einem kleinen SaaS-Team wenig gemeinsam hatten. Für die eigene Unternehmensrealität brachte das wenig, weil die Beispiele nie zur Größenordnung des Unternehmens passten und die Rollenfrage im gesamten Kursmaterial überhaupt nicht vorkam.
KI-Kompetenz schützt nicht vor der Rollenfalle
Art. 4 KI-VO verpflichtet Anbieter dazu, ausreichende KI-Kompetenz im eigenen Team sicherzustellen, doch das beantwortet die Rollenfrage kein Stück. Ein Entwicklerteam kann bestens geschult sein und trotzdem übersehen, dass ein Feature-Update es gerade erst zum Anbieter gemacht hat. Für die Auswahl der passenden Lerninhalte lohnt sich deshalb ein Blick auf die Checkliste für den Einkauf von KI Compliance Schulungen, weil dort auch die Frage mitgedacht wird, ob ein Kurs überhaupt zur eigenen Unternehmensgröße passt.
Ähnlich verhält es sich mit der Dokumentation der Schulungsmaßnahmen: Sie gehört zur Nachweispflicht dazu, verdient aber ein eigenes Kapitel, das getrennt behandelt werden sollte. Wer nur die deutsche Übersetzung der Verordnung liest, verpasst mitunter genau die Nuance, die bei der Anbieter-Frage den Unterschied macht, und ein Grund, warum ich bei Zweifelsfällen immer auch einen Blick in den englischen Originaltext werfe.
Wenn externe Hilfe ins Leere läuft
Der Fall mit der Unternehmensberatung liefert die kürzeste Antwort auf die Frage, wann externe Hilfe nichts bringt: sobald das Kursmaterial für eine andere Unternehmensgröße geschrieben wurde. Auch wenn es bei der Rollenfrage primär um Entwicklung und Produkt geht, lohnt sich ein Blick in den KI-Führerschein für Mitarbeiter im Mittelstand, sobald Sie auch Vertrieb und Marketing im Umgang mit den entsprechenden Begriffen schulen wollen.
Wenn ich zum wiederholten Mal eine Artikelnummer der Verordnung in ein Anmerkungsfeld tippe, merke ich, wie routiniert sich das mittlerweile anfühlt, und wie leicht genau diese Routine dazu verleitet, die eigentliche Rollenfrage aus den Augen zu verlieren. Der Geschäftsführer eines Maschinenbau-Zulieferers aus Hanau erzählte mir neulich, seine Risikoklassifizierung stehe inzwischen so sicher im Unternehmen, dass er für die nächste Prüfung keinen externen Berater mehr brauche. Genau das ist das Ziel, das ich mit jedem SaaS-Mandanten verfolge: internes Wissen aufbauen, statt dauerhaft auf externe Rechnungen angewiesen zu sein.
Die Rollenprüfung im Entwicklungsprozess verankern
Der praktische Rat bleibt einfach, auch wenn die Verordnung selbst es nicht ist: Prüfen Sie bei jeder Anpassung, jedem Fine-Tuning und jeder Umbenennung eines zugekauften Modells aktiv, ob Sie damit die Anbieterrolle übernehmen und dokumentieren Sie diese Prüfung als festen Schritt im Release-Prozess, nicht als nachträgliche Rechtfertigung gegenüber einem Großkunden. Sobald ein SaaS-Anbieter in die Anbieterrolle rutscht, verändern sich Fristen, Haftungsfragen für die Geschäftsführung und Transparenzpflichten gegenüber Endnutzern gleichermaßen. Jedes dieser Themen verdient für sich genommen eine eigene, ausführliche Betrachtung.
Wer die Rollenfrage früh und regelmäßig klärt, verhandelt mit Großkunden aus einer stärkeren Position heraus, statt bei jeder neuen Ausschreibung nachträglich zu rechtfertigen, warum die eigene Einstufung stimmt. Bei einer möglichen Anbieter-Einstufung sollten Sie zusätzlich Ihren Justiziar oder einen Fachanwalt für IT-Recht einbeziehen, weil die Konsequenzen über die reine Produktentwicklung hinausgehen.