Am 2. August 2026 ist der Großteil der Verordnung (EU) 2024/1689 — des EU AI Act — in die allgemeine Anwendung übergegangen. Für die meisten Unternehmen hat sich damit wenig daran geändert, was sie bauen dürfen, und einiges daran, was sie belegen können müssen. Der Unterschied ist wichtig, denn der Markt hat mit einer Menge Compliance-Theater reagiert, das sich an Organisationen richtet, die regulatorisch betrachtet etwas ziemlich Gewöhnliches tun.
Dies ist die Checkliste, die wir durchgehen, bevor ein von uns gebautes KI-System in den Betrieb geht. Sie ist von der technischen Seite geschrieben: was in der Software, in den Protokollen und in der Dokumentation vorliegen muss. Sie ist kein Rechtsgutachten, und die Einstufungsfragen am Ende gehören zu Ihrer Rechtsabteilung.
Zuerst: In welcher Rolle sind Sie?
Die Verordnung verteilt die Pflichten im Wesentlichen zwischen Anbietern, die ein KI-System in Verkehr bringen, und Betreibern, die eines in eigener Verantwortung einsetzen. Die meisten Unternehmen, die KI kaufen oder beauftragen, sind Betreiber — und Betreiberpflichten sind spürbar leichter.
Die Falle: Man wird Anbieter, ohne es zu wollen. Wer seinen eigenen Namen oder seine Marke auf ein System setzt, dessen Zweckbestimmung ändert oder ein Hochrisiko-System wesentlich verändert, übernimmt die Anbieterpflichten. Das ist die häufigste Überraschung, die wir sehen, und sie sollte an Tag eins geklärt werden statt während der Sicherheitsprüfung eines Kunden.
Dann: Welche Risikostufe gilt?
Der AI Act skaliert mit dem Risiko, nicht mit der Technik. Dasselbe Modell kann in einem Kontext unreguliert und in einem anderen hochriskant sein, denn die Einstufung folgt dem, worüber das System entscheidet — und über wen.
- 01
Inakzeptables Risiko — verboten
Social Scoring, ungezieltes Auslesen von Gesichtsbildern, Emotionserkennung am Arbeitsplatz und in Schulen sowie einige weitere Praktiken. Diese sind seit Februar 2025 vollständig untersagt.
- 02
Hohes Risiko — die schweren Pflichten
Systeme, die Entscheidungen über Beschäftigung, Kreditwürdigkeit, Bildung, wesentliche öffentliche oder private Dienste, Migration oder Strafverfolgung wesentlich beeinflussen — dazu KI in Produkten, die bereits unter EU-Produktsicherheitsrecht fallen. Diese Stufe bringt Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht sowie Genauigkeits- und Robustheitsanforderungen mit sich.
- 03
Begrenztes Risiko — Transparenzpflichten
Chatbots, Assistenten und erzeugte Inhalte. Artikel 50 verlangt, dass Menschen erfahren, dass sie mit einem KI-System interagieren, und dass synthetische Inhalte gekennzeichnet werden. Hier sitzt die große Mehrheit gewöhnlicher Unternehmens-KI.
- 04
Minimales Risiko — keine spezifischen Pflichten
Spamfilter, Suchranking, Prognosen, die meisten internen Werkzeuge. Gute Entwicklungspraxis gilt weiterhin; die Verordnung legt nichts darauf.
Die Checkliste
Das Folgende stellen wir vor dem Start sicher. Jeder Punkt ist beim Bauen trivial und im Nachhinein teuer zu rekonstruieren — genau das ist das Argument dafür, ihn vorab zu erledigen.
1. Hinweis in der Oberfläche (Art. 50)
Interagiert eine Person mit einem KI-System, muss sie das erfahren — klar erkennbar an der Stelle der Interaktion. Eine Zeile in der Datenschutzerklärung genügt dafür nicht. Praktisch heißt das: eine dauerhaft sichtbare Kennzeichnung in der Chat-Oberfläche und — wo Sie Texte, Bilder oder Audio im Namen eines Kunden erzeugen — eine maschinenlesbare Markierung der Ausgabe.
2. Ein Mensch, der tatsächlich eingreifen kann (Art. 14)
Menschliche Aufsicht ist keine Vertragsklausel, sondern eine Maske, die jemand benutzt. In unseren Bauten bedeutet das eine Konfidenzschwelle, die unsichere Fälle in eine Prüfliste leitet, und eine benannte Person, die die Automatisierung anhalten und eine ausgeführte Aktion zurücknehmen kann. Wenn man das System nur stoppen kann, indem man einen Entwickler anruft, existiert keine Aufsicht.
3. Protokolle, die das „Warum“ beantworten (Art. 12)
Erfassen Sie die Eingabe, die Quellen oder Merkmale, auf die sich die Entscheidung gestützt hat, die Ausgabe, den Konfidenzwert und — wo einschlägig — wer geprüft hat. Geben Sie dem Protokoll eine Aufbewahrungsregel, denn ein unbegrenztes Protokoll ist ein DSGVO-Problem im AI-Act-Kostüm. Wenn eine Behörde oder ein Kunde fragt, warum eine bestimmte Entscheidung so ausgefallen ist, sollte die Antwort eine Abfrage sein und keine Ermittlung.
4. Ein Verzeichnis der Datenquellen (Art. 10)
Halten Sie fest, woher Trainings-, Tuning- oder Recherchedaten stammen, was sie enthalten, was bewusst ausgeschlossen wurde und warum. Tun Sie das während des Baus. Achtzehn Monate später ist die Rekonstruktion Raterei — und Raterei ist genau das, was die Pflicht verhindern soll.
5. Eine technische Akte (Art. 11)
Zweck, Architektur, Modellwahl und die Begründung dafür, bekannte Grenzen und Testergebnisse. Bei uns ist das ein Dokument im Repository, das sich mit dem Code ändert — kein PDF, das eine Woche vor der Prüfung entsteht.
6. Belege, dass es funktioniert (Art. 15)
Genauigkeit muss eine Zahl sein, erzeugt von einem Testset aus echten Fällen, das vor dem Start vereinbart wurde. Führen Sie es bei jeder Änderung erneut aus. Diesem Punkt widersetzen sich Teams am stärksten und profitieren am meisten von ihm — denn er ist zugleich die einzige verlässliche Methode, um zu erkennen, ob die letzten drei Wochen Feinschliff etwas gebracht haben.
Wo sich AI Act und DSGVO treffen
Sie überschneiden sich, statt zu konkurrieren. Die DSGVO regelt die personenbezogenen Daten, die durch das System fließen; der AI Act regelt das System selbst. In der Praxis bedienen dieselben Entwurfsentscheidungen beides: Datensparsamkeit bei der Erhebung, Löschfristen, die ein Job durchsetzt statt eine Richtlinie, rollenbasierter Zugriff mit Protokoll, und ein Mensch in der Schleife bei folgenreichen Entscheidungen.
Deshalb behandeln wir es als ein Architekturproblem. Ein System, das ab dem ersten Schema DSGVO-nativ entworfen wurde, erfüllt die meisten technischen Anforderungen des AI Act als Nebeneffekt — was bleibt, ist Dokumentation.
Was wir als Nächstes tun würden, in dieser Reihenfolge
- 01
Inventarisieren, was bereits läuft
Einschließlich der Werkzeuge, die eine Fachabteilung ohne die IT beschafft hat. Man kann nicht einstufen, was nicht aufgelistet ist — und die Liste ist meist länger als erwartet.
- 02
Jeden Einsatz einstufen, nicht jeden Anbieter
Ein einziges SaaS-Produkt kann eine Funktion mit minimalem und eine mit hohem Risiko enthalten. Die Einstufung hängt daran, worüber das System entscheidet und über wen.
- 03
Zuerst die Transparenzlücke schließen
Es ist der günstigste Punkt der Liste, er betrifft die meisten Systeme, und er ist für Kunden am sichtbarsten.
- 04
Dann die Nachweisebene bauen
Protokolle, Testset, technische Akte. Bei einem System üblicher Größe etwa eine Woche Entwicklungsarbeit — und der Teil, den niemand überzeugend nachrüsten kann.
Fragen, die das aufwirft
- Gilt der EU AI Act auch für Unternehmen außerhalb der EU?
- Er kann gelten. Die Verordnung erfasst Anbieter und Betreiber mit Sitz außerhalb der EU, wenn die Ausgabe des KI-Systems in der Union verwendet wird. Praktisch heißt das: Ein Unternehmen außerhalb der EU, das EU-Kunden bedient, sollte von einer Anwendbarkeit ausgehen und entsprechend einstufen.
- Ist ein Kundenservice-Chatbot ein Hochrisiko-KI-System?
- In der Regel nicht. Ein Chatbot, der Fragen beantwortet und Antworten entwirft, fällt typischerweise unter die Transparenzpflichten aus Artikel 50 und nicht unter die Hochrisiko-Anhänge. Das Risiko steigt, wenn das System eine Entscheidung über eine Person wesentlich beeinflusst — Beschäftigung, Kredit, Zugang zu wesentlichen Diensten.
- Welche Bußgelder sieht der EU AI Act vor?
- Die Verordnung sieht gestaffelte Geldbußen vor; die höchste Stufe ist verbotenen Praktiken vorbehalten, niedrigere Stufen gelten für sonstige Verstöße und für unrichtige Angaben gegenüber Behörden. Die konkrete Höhe hängt vom Verstoß und vom Umsatz ab — eine Frage für Ihre Rechtsabteilung und keine Zahl, die man aus einem Blogbeitrag zitiert.
Passende Leistungen
Nächste Notiz
Warum KI-Pilotprojekte nicht in Produktion gehen — und fünf Prüfungen, die das ändern
Der Abstand zwischen einer Demo, die im Meeting funktioniert, und einem System, das an einem Dienstagnachmittag funktioniert, ist die Stelle, an der die meisten KI-Budgets verschwinden. Fünf Prüfungen, die ihn schließen.