Der EU AI Act in der Praxis: Ein Compliance-Leitfaden für SaaS-Teams

Ein mittelständisches Berliner SaaS-Team lieferte Anfang 2025 ein KI-Zusammenfassungs-Feature aus, einen dünnen Wrapper über GPT-4, der Support-Tickets verdichtet. Nützlich, eng umrissen, nicht kontrovers. Im Frühjahr 2026 schickte ihr größter Enterprise-Interessent einen Beschaffungsfragebogen mit einem eigenen Abschnitt zum EU AI Act. Dreiundzwanzig Fragen. Das Team beantwortete vielleicht sechs mit Überzeugung. Der Deal stockte vier Monate, während Rechtsabteilung, Engineering und Produkt eilig die Dokumentation aufbauten, die die Verordnung längst verlangte.

Das ist das Muster, dem die EU-AI-Act-Compliance 2026 folgt. Die Verordnung ist nicht mehr hypothetisch. Die Bestimmungen für KI-Modelle mit allgemeinem Verwendungszweck wurden im August 2025 anwendbar, der Großteil der Verbote und Pflichten des Acts wird über 2026 und 2027 schrittweise eingeführt, und Enterprise-Kunden nutzen AI-Act-Reife als Beschaffungsfilter. Teams, die den Act als "EU-Bürokratie für die großen KI-Labore" behandelten, stellen fest, dass das Ausliefern einer Claude- oder GPT-Integration in einem B2B-Produkt sie mitten in seinen Anwendungsbereich rückt, als Betreiber (Deployer), manchmal als Anbieter (Provider), mit echten Pflichten im Schlepptau.

Dieser Beitrag ist ein praktischer Leitfaden für mittelständische SaaS-Teams: was der Act tatsächlich von dir verlangt, wie die Risikoklassifizierung funktioniert, wenn du das Modell eines anderen integrierst, welche Dokumentations- und Transparenzmaßnahmen du brauchst und eine Compliance-Checkliste, die du gegen dein eigenes Produkt laufen lassen kannst.

Wen der Act erfasst und warum "wir rufen nur eine API auf" keine Verteidigung ist

Das häufigste Missverständnis ist, dass der EU AI Act nur für Organisationen gilt, die Foundation Models trainieren. Das tut er nicht. Die Verordnung definiert mehrere Rollen, und zwei davon treffen auf fast jedes SaaS-Team zu, das KI-Features ausliefert.

Ein Anbieter (Provider) ist, wer ein KI-System entwickelt oder unter seinem Namen oder seiner Marke entwickeln lässt und es auf dem EU-Markt in Verkehr bringt. Wenn dein Produkt als KI-Feature unter deiner Marke vermarktet wird, selbst wenn es unter der Haube Anthropic, OpenAI, Mistral oder Google aufruft, kannst du Anbieter dieses KI-Systems sein. Der zugrunde liegende Modellanbieter (Anthropic, OpenAI usw.) ist ein separater GPAI-Modellanbieter mit eigenen, anderen Pflichten.

Ein Betreiber (Deployer) ist, wer ein KI-System unter seiner Verantwortung im Rahmen einer beruflichen Tätigkeit einsetzt. Wenn du ein KI-Feature in dein SaaS einbettest und deine Kunden es nutzen, bist du Betreiber. Deine Enterprise-Kunden, die das KI-Feature in ihren Workflows nutzen, sind oft ebenfalls Betreiber, weshalb ihre Beschaffungsteams dich um Transparenzinformationen bitten, die sie brauchen, um ihre eigenen Pflichten zu erfüllen.

Der Act gilt extraterritorial. Ein SaaS mit US-Hauptsitz, das EU-Kunden bedient, fällt in den Anwendungsbereich. Ein Schweizer SaaS fällt in den Anwendungsbereich, wenn es in die EU verkauft. "Wir haben keine EU-Niederlassung" ist keine Ausnahme.

Anbieter eines schmalen, feinabgestimmten Modells zu sein, das auf einem Foundation Model aufbaut, ist ebenfalls möglich. Wenn du ein Open-Source-LLM auf den Daten deiner Kunden feinabstimmst und es als Teil deines Produkts auslieferst, bist du der Anbieter dieses abgeleiteten Systems. Die Pflichten verschieben sich entsprechend.

Die Risikopyramide: Wo die meisten SaaS-KI-Features tatsächlich landen

EU-AI-Act-Compliance beginnt damit, dein KI-System in eine von vier Risikostufen einzuordnen. Diese Klassifizierung richtig zu treffen ist die einzelne tragendste Entscheidung, die du triffst, weil die Pflichten je Stufe dramatisch unterschiedlich sind.

Systeme mit inakzeptablem Risiko sind schlicht verboten: Social Scoring durch Behörden, biometrische Echtzeit-Fernidentifizierung im öffentlichen Raum mit engen Ausnahmen, Emotionserkennung am Arbeitsplatz und im Bildungskontext, manipulative Beeinflussung des Verhaltens. Wenn dein Produkt so etwas tut, geht es nicht um Compliance, sondern um das Neudesign des Features.

Hochrisiko-Systeme sind erlaubt, aber stark reguliert. Anhang III des Acts listet die Kategorien: KI in kritischer Infrastruktur, Bildungszulassungen, Beschäftigungsentscheidungen (inklusive Lebenslauf-Screening und Leistungsbewertung), Zugang zu wesentlichen privaten und öffentlichen Diensten, Strafverfolgung, Migration, Justizverwaltung und demokratische Prozesse. Überraschend viele B2B-SaaS-Produkte berühren diese Bereiche: jedes HR-Tech-Produkt mit Kandidaten-Ranking, jedes EdTech-Produkt, das Zugang zu Programmen steuert, jedes FinTech-Produkt mit Kreditwürdigkeitsbewertung. Eine Hochrisiko-Einstufung löst den Großteil der Pflichten des Acts aus: Risikomanagementsysteme, Daten-Governance, technische Dokumentation, Anforderungen an die menschliche Aufsicht, Genauigkeits- und Cybersicherheitsmaßnahmen, Marktbeobachtung und Registrierung in der EU-Datenbank.

Systeme mit begrenztem Risiko sind die häufige mittlere Stufe, und hier landen die meisten KI-Features mit allgemeinem Verwendungszweck in SaaS-Produkten: Chatbots, Zusammenfasser, Content-Generatoren, Meeting-Assistenten, Sprachfeatures. Die Hauptpflicht hier ist Transparenz: Nutzer müssen wissen, dass sie mit einem KI-System interagieren, KI-generierte Inhalte müssen maschinenlesbar als solche gekennzeichnet sein, und Deepfakes müssen gekennzeichnet werden.

Systeme mit minimalem Risiko unterliegen keinen spezifischen Pflichten des Acts, nur freiwilligen Verhaltenskodizes. Spam-Filter, Bestandsoptimierung und ähnliche klassische ML-Anwendungen sitzen typischerweise hier.

Der Fehler, den die meisten Teams machen, ist, ihr Produkt reflexhaft als minimal-risiko einzustufen, weil "wir haben nur einen Chatbot hinzugefügt". Ein Chatbot ist standardmäßig begrenztes Risiko. Ein Chatbot, der den Zugang zu einem Sozialleistungsantrag steuert, ist Hochrisiko, weil er folgenreiche Entscheidungen über den Zugang zu Diensten trifft. Der Nutzungskontext, nicht die zugrunde liegende Technologie, bestimmt die Klassifizierung.

Transparenzpflichten: die Grundlinie für fast jedes SaaS

Für die Kategorie begrenztes Risiko, wo die meisten SaaS-KI-Features tatsächlich sitzen, ist die Kernanforderung Transparenz gegenüber Endnutzern. In der Praxis bedeutet das vier konkrete Dinge.

Erstens müssen Nutzer, die mit einem KI-System interagieren, darüber informiert werden, dass sie das tun, sofern dies nicht bereits aus dem Kontext offensichtlich ist. Ein Chat-Widget, klar als "KI-Assistent" gekennzeichnet, erfüllt das. Ein menschenähnlicher Sprachagent, der sich als Mensch ausgibt, nicht.

Zweitens müssen KI-generierte oder KI-manipulierte Inhalte (Text, Bild, Audio oder Video) in einem maschinenlesbaren Format als künstlich erzeugt gekennzeichnet sein. Das ist die Bestimmung, die die meisten Teams übersehen. Sie wird nicht durch einen sichtbaren Hinweis in der UI erfüllt; sie erfordert Metadaten, Wasserzeichen oder Provenienz-Signale, die nachgelagerte Systeme erkennen können. C2PA und ähnliche Content-Provenance-Standards sind die aufkommende technische Antwort.

Drittens müssen Deepfakes (KI-generierte oder manipulierte Medien, die echten Personen, Objekten oder Ereignissen ähneln) klar als solche gekennzeichnet werden. Es gibt enge Ausnahmen für künstlerische, satirische oder klar kreative Werke.

Viertens müssen Systeme zur Emotionserkennung und biometrischen Kategorisierung die ihrem Betrieb ausgesetzten natürlichen Personen informieren.

Für ein typisches B2B-SaaS, das ein GPT-gestütztes Feature ausliefert, ist das minimal tragfähige Transparenz-Set: ein sichtbarer "KI"-Hinweis in der UI nahe der generierten Ausgabe, Metadaten auf allen generierten Artefakten, die dein System verlassen (Dokumente, Bilder, E-Mails), und eine Seite in deiner Dokumentation, die erklärt, was das KI-Feature tut und welches Modell es nutzt.

Dokumentation: die Anbieterpflichten, die du wahrscheinlich erbst

Selbst wenn du dein Feature als begrenztes Risiko einstufst, werden Enterprise-Kunden, sobald du dich am Markt als Anbieter eines KI-gestützten Produkts positionierst, eine technische Dokumentation verlangen, die die Anbieterpflichten des Acts faktisch widerspiegelt. Diese Dokumentation willst du ohnehin, sie ist es, die Enterprise-Verkäufe entsperrt.

Das Dokumentations-Set, das jedes KI-fähige SaaS bis Ende 2026 bereithalten sollte:

Eine System Card für jedes KI-Feature: was das Feature tut, welches Modell es stützt, die vorgesehenen Anwendungsfälle, bekannte Grenzen und Fehlermodi, die Daten, die das Modell zur Inferenzzeit erhält, und die Daten, die es nicht erhält. Eine Seite pro Feature reicht oft. Das ist es, was Kunden ihren eigenen AI-Act-Aufzeichnungen beifügen, wenn sie dein Produkt einsetzen.

Eine Daten- und Aufbewahrungserklärung für KI-Interaktionen: ob Nutzereingaben an einen Drittanbieter-Modellanbieter gesendet werden, ob sie von diesem Anbieter aufbewahrt werden, ob sie zum Training genutzt werden (üblicherweise nicht unter Enterprise-API-Verträgen, aber prüfe es) und dein Aufbewahrungszeitraum auf deinen eigenen Servern.

Eine Beschreibung der menschlichen Aufsicht für jedes Feature, bei dem die KI-Ausgabe eine Entscheidung beeinflusst: wie Nutzer KI-Ausgaben anfechten, überstimmen oder korrigieren können und wo der menschliche Entscheidungspunkt im Workflow liegt.

Ein Risiko- und Vorfallsprotokoll, das bekannte Probleme mit dem KI-System, angewandte Gegenmaßnahmen und von Nutzern gemeldete Vorfälle dokumentiert. Für die meisten SaaS beginnt das als internes Dokument im selben Register wie Sicherheitsvorfälle und entwickelt sich mit der Reife des Produkts zu etwas Formellerem.

Ein Dokument zur Modell- und Anbieterkette: welches GPAI-Modell genutzt wird, von welchem Anbieter, unter welchen Vertragsbedingungen und worauf du dich aus der AI-Act-Compliance des Anbieters verlässt (dessen Model Card, Sicherheitsdokumentation und Urheberrechtspolitik).

Diese Dokumentation ist kein nachträglicher Einfall. Sie ist es, was die Beschaffungs- und Rechtsteams deiner Kunden tatsächlich lesen werden. Behandle sie als Produktartefakt: versioniere sie, halte sie aktuell und weise ihr eine Verantwortung zu. Ein Code-Quality-Audit einer KI-integrierten Codebasis sollte aufdecken, ob diese Dokumentation das widerspiegelt, was der Code tatsächlich tut. Dass die beiden auseinanderdriften, ist eine der häufigsten und gefährlichsten Lücken, die wir sehen.

GPAI-Regeln: Was sich ändert, wenn du feinabstimmst

Die Regeln des Acts für KI-Modelle mit allgemeinem Verwendungszweck (GPAI) gelten für Organisationen, die Foundation Models trainieren oder wesentlich modifizieren. Für die meisten SaaS-Teams liegt das außerhalb des Anwendungsbereichs, du konsumierst ein GPAI-Modell von einem Anbieter, der diese Pflichten erfüllt.

Die Linie wird unscharf, wenn du ein Open-Source-LLM auf deinen eigenen Daten feinabstimmst und das resultierende Modell als Teil deines Produkts auslieferst. Du kannst dann ein Modifizierer mit nachgelagerten GPAI-Pflichten sein: Veröffentlichung einer Zusammenfassung der Trainingsdaten, Dokumentation von Fähigkeiten und Grenzen und Umsetzung einer Urheberrechts-Compliance-Politik. Wenn die Feinabstimmung die Schwellenwerte des Acts für Modelle mit systemischem Risiko erreicht (eine sehr hohe Rechenhürde, für mittelständisches SaaS unwahrscheinlich), greifen zusätzliche Pflichten.

Selbst wenn du kein GPAI-Anbieter bist, musst du die GPAI-Compliance-Haltung des Modellanbieters kennen, von dem du abhängst. Anthropic, OpenAI und Google veröffentlichen AI-Act-orientierte Transparenzdokumentation; dein Vertrag sollte darauf verweisen. Das ist es, was "wir nutzen KI" von "wir nutzen KI auf eine Weise, die einem Compliance-Audit standhält" trennt.

Eine praktische Compliance-Checkliste

Eine konkrete Checkliste, die ein mittelständisches SaaS-Team an einem Nachmittag gegen seine KI-Features laufen lassen kann:

Klassifiziere jedes KI-Feature anhand der Risikopyramide und dokumentiere die Klassifizierung und die Begründung. Wenn ein Feature hochriskant sein könnte (HR, Kredit, Bildung, Gesundheit, Zugang zu Diensten), ziehe EU-Rechtsberatung vor dem nächsten Release hinzu.

Bestätige für jedes Feature mit begrenztem Risiko, dass es einen sichtbaren KI-Hinweis, eine maschinenlesbare Kennzeichnung auf generierten Inhalten und gegebenenfalls eine Deepfake-Kennzeichnung gibt.

Stelle sicher, dass jedes KI-Feature eine einseitige System Card hat, die in der Versionskontrolle neben dem Code gehalten wird.

Prüfe deinen Datenfluss: welche Nutzerdaten deine Infrastruktur verlassen, welcher Drittanbieter-Modellanbieter sie erhält, unter welchen Vertragsbedingungen und ob sie zum Training genutzt werden. Aktualisiere deinen Auftragsverarbeitungsvertrag und deine Datenschutzerklärung entsprechend.

Dokumentiere den Mechanismus der menschlichen Aufsicht für jedes KI-Feature. "Es gibt keine menschliche Aufsicht" ist eine Antwort. Entscheide, ob das die richtige Antwort für die tatsächliche Wirkung des Features ist.

Führe ein laufendes Register über KI-Vorfälle und Hinweise von Modellanbietern. Behandle ein Sicherheitsupdate eines Modellanbieters genauso wie eine CVE in einer kritischen Abhängigkeit.

Stelle für EU-Kunden deine System Cards und Datenhandhabungserklärungen auf Anfrage bereit. Viele Enterprise-Kunden fragen einfach danach, statt einen eigenen Fragebogen zu schicken.

Richte deine Arbeit zur Legacy-Code-Optimierung und Modernisierung an diesen Dokumentationsanforderungen aus. KI-Features, die ohne diese Disziplin in ältere Codebasen nachgerüstet werden, sind genau die Stelle, an der sich Compliance-Lücken aufsummieren.

Schluss

EU-AI-Act-Compliance ist keine einmalige Checklisten-Übung. Die Verordnung wird über 2026 und 2027 schrittweise eingeführt, und die Erwartungen der Enterprise-Kunden ziehen schneller an als die gesetzlichen Fristen. Teams, die KI-Features als ausgelieferte Produkte behandeln, mit System Cards, Transparenzmaßnahmen, menschlicher Aufsicht und einem Dokumentationsrückgrat, erfüllen das Gesetz und kommen in Enterprise-Verkaufszyklen schneller voran. Der Fehlermodus ist das Gegenteil: KI-Features als vibe-codete Prototypen auszuliefern und dann hektisch Compliance nachzurüsten, wenn ein Deal stockt oder eine Regulierungsbehörde schreibt.

Wolf-Tech auditiert KI-integrierte SaaS-Produkte auf EU-AI-Act-Reife und hilft Teams in Berlin und der EU, Dokumentations-, Aufsichts- und Transparenzschichten zu gestalten, bevor der nächste Enterprise-Deal danach fragt. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.