AI Act 2026: Was Unternehmen vor dem Einsatz von KI prüfen müssen

AI Act 2026 für Unternehmen beginnt nicht mit der Frage, welches Modell am meisten kann, sondern ob der geplante Einsatz überhaupt freigabefähig ist. Vor Pilot oder Rollout müssen Unternehmen den Use Case eingrenzen, die Wirkung auf Personen bewerten, Datenflüsse und Anbieterunterlagen prüfen und festlegen, wer im Betrieb eingreifen kann. Wer diese Reihenfolge überspringt, kauft oft kein Produktivitätswerkzeug, sondern ein Governance-Problem.

Für Unternehmen in der EU ist der Rahmen durch die Verordnung (EU) 2024/1689 gesetzt. Parallel bleibt die DSGVO voll anwendbar. In Polen wird das besonders dort scharf, wo internationale SaaS-Produkte, lokale Integratoren, externer Support und interne Fachbereiche zusammenkommen. Dann reichen gute Demos und allgemeine Trust-Center-Texte nicht mehr. Entscheidend sind belastbare Nachweise zu Rollen, Datenflüssen, Logs und Eingriffsmöglichkeiten.

Ein typischer Fall: Ein Unternehmen aktiviert in seinem Service-System eine KI-Funktion zur Klassifizierung eingehender Reklamationen. Der Nutzen wirkt sofort plausibel. Für eine Freigabe genügt das nicht. Vorher muss klar sein, welche Daten verarbeitet werden, ob sensible Inhalte vorkommen, ob die Priorisierung Kunden faktisch unterschiedlich behandelt und ob sich jede relevante Ausgabe später nachvollziehen lässt.

AI Act 2026 für Unternehmen: Erst den Einsatz einordnen, dann das Produkt bewerten

Viele Teams starten mit Modellqualität, Antwortgeschwindigkeit oder Lizenzpreis. Das ist zu früh. Der AI Act 2026 für Unternehmen bewertet keine Werbewörter wie Copilot, Assistent oder Smart Automation, sondern Funktion, Einsatzkontext und Wirkung im Prozess.

Praktisch relevant sind vier Ebenen: verbotene Praktiken, Hochrisiko-KI-Systeme, Transparenzpflichten und Pflichten rund um General Purpose AI, die vor allem Anbieter betreffen. Für die Freigabe zählt deshalb nicht, wie modern ein Produkt wirkt, sondern ob der konkrete Einsatz in eine dieser Kategorien fällt.

Verbotene Praktiken sind im normalen Unternehmensalltag seltener, aber nicht bloß Theorie. Heikel bleiben Konstellationen mit manipulativer Beeinflussung, Ausnutzung von Schutzbedürftigkeit oder biometrisch geprägten Grenzfällen. Emotionserkennung im Arbeitskontext ist ein Use Case, den viele Unternehmen besser gar nicht erst priorisieren sollten. Der regulatorische Aufwand steht dort meist in keinem vernünftigen Verhältnis zum Nutzen.

Deutlich häufiger relevant ist Hochrisiko. Anhang III des AI Act nennt unter anderem Beschäftigung, Bildung und den Zugang zu wesentlichen Diensten. Für die betriebliche Prüfung reicht eine einfache Übersetzung: Wenn KI über Chancen, Zugang, Reihenfolge, Eignung oder Behandlung von Personen mitentscheidet, muss Hochrisiko ernsthaft geprüft werden. Dann ist ein lockerer Pilot mit späterer Governance meist die falsche Reihenfolge.

Transparenzpflichten greifen breiter. Chatbots, generierte Inhalte oder Systeme, die Interaktionen mit Personen prägen, können Informationspflichten auslösen. Das klingt harmloser als Hochrisiko, ist aber in Self-Service-Portalen, internen HR-Abläufen oder der Kundenkommunikation schnell relevant.

Der häufigste Denkfehler liegt nicht in der Technik, sondern in der Prozessbeschreibung. Ein generatives System wird als Schreibassistenz eingekauft, obwohl es im Ablauf faktisch vorentscheidet. Ein Antwortgenerator im Reklamationsprozess bleibt keine harmlose Assistenz mehr, wenn seine Vorschläge bestimmen, welcher Fall zuerst bearbeitet wird oder welche Eskalation ausgelöst wird.

Rollen sauber trennen: Betreiber, Anbieter, Integrator

Die Rollenfrage entscheidet oft darüber, ob ein Vorhaben prüfbar bleibt. Das Unternehmen, das KI im eigenen Prozess nutzt, handelt praktisch als Betreiber. Es muss den Einsatz bewerten, interne Kontrollen festlegen und die Freigabe dokumentieren. Der Anbieter liefert Produktunterlagen und technische Informationen. Ein Integrator kann zusätzliche Risiken erzeugen, wenn er Datenflüsse, Routingregeln oder Rückschreibungen in Zielsysteme verändert.

Gerade in grenzüberschreitenden Setups wird diese Trennung schnell unsauber. Das Grundprodukt kommt von einem internationalen SaaS-Anbieter, die Integration baut ein lokaler Partner, Supportzugriffe laufen über weitere Parteien, und der Fachbereich geht davon aus, dass der Vertragspartner die Compliance schon abgedeckt hat. Später fehlen dann genau die Informationen, die für Freigabe und Prüfung zählen: belastbare Aussagen zu Zuständigkeiten, Datenflüssen und Exportlogs.

Die Prüfreihenfolge vor Pilot, Einkauf und Produktivstart

Unternehmen brauchen vor dem Start keine komplizierte Methodik, sondern eine feste Reihenfolge. Erst wenn diese Punkte sauber beantwortet sind, lohnt sich ein Pilot überhaupt.

Diese Matrix verschiebt die Diskussion vom Produkt auf den Prozess. Genau dort liegt 2026 der Engpass. Nicht die Frage, ob ein Modell beeindruckend wirkt, sondern ob der Einsatz im Betrieb kontrollierbar bleibt.

Daraus folgen drei harte Freigaberegeln. Kein Go ohne benannten Prozessowner. Kein Go ohne nachvollziehbare Daten- und Rollenlogik. Kein Go ohne technische Nachweisfähigkeit. Dazu gehören Logs, Fallback, Änderungsmanagement und echte Eingriffsmöglichkeiten.

Kurz gesagt: Ohne Nachweise kein Pilot.

Ein Vorhaben sollte gestoppt oder mindestens eskaliert werden, wenn Bewerbende, Beschäftigte oder Kunden systematisch priorisiert werden, wenn sensible Daten einfließen, wenn der Anbieter nur allgemeine Marketingunterlagen liefert oder wenn unklar bleibt, welche Ausgabe später welche Aktion im Zielsystem auslöst. In solchen Fällen ist ein Pilot nicht neutral. Er verlagert das Risiko nur in den Betrieb.

Beschaffungsteams unterschätzen dabei oft ein Muster: Ein eingebautes KI-Feature im bestehenden SaaS-Paket ist 2026 eher ein Warnsignal als ein Vertrauensbeweis. Nicht weil jede Zusatzfunktion problematisch wäre, sondern weil gerade dort die Prüfung häufig ausfällt. Eine bestehende Lieferbeziehung ersetzt keine neue Freigabe. Wer das anders behandelt, spart am Anfang Zeit und zahlt später mit Nacharbeit, Vertragsdiskussionen oder Prozessumbau.

DSGVO, DPIA und der operative Polen-Bezug

Der AI Act ersetzt keine Datenschutzprüfung. Sobald personenbezogene Daten verarbeitet werden, laufen AI-Act-Prüfung und DSGVO-Prüfung parallel. Relevant sind vor allem Zweckbindung, Datenminimierung, Transparenz, Rechtsgrundlage, Auftragsverarbeitung, internationale Datenübermittlungen und die Frage, ob Profiling oder eine Entscheidung mit erheblicher Wirkung vorliegt.

Für die Datenschutz-Folgenabschätzung, also die DPIA, gibt es keine Abkürzung über Produktnamen. Der Europäische Datenschutzausschuss hat in seinen Leitlinien zu automatisierten Entscheidungen und Profiling klargestellt, dass nicht nur formale Vollautomatisierung zählt, sondern die tatsächliche Wirkung auf betroffene Personen. Für die Einordnung ist außerdem die Übersicht der Europäischen Kommission zur Datenschutz-Folgenabschätzung hilfreich. Wer hier sauber prüfen will, sollte mit Primärquellen arbeiten, nicht mit Vendor-Zusammenfassungen.

Im Beschäftigungskontext wird die Lage regelmäßig strenger. Wenn ein Tool Eignungsscores erzeugt, Ausschlussgründe vorschlägt, Interviewreihenfolgen bestimmt oder Leistungsbilder verdichtet, reicht ein später Hinweis an HR nicht. Datenschutz, arbeitsrechtliche Bewertung und AI-Act-Einordnung müssen früh zusammenlaufen. Für angrenzende Architektur- und Prozessfragen kann wann fertiges SaaS nicht mehr reicht eine sinnvolle Vertiefung sein.

Der Polen-Bezug ist vor allem dort relevant, wo er die Umsetzung verändert. Unternehmen mit Sitz oder operativer Verarbeitung in Polen sollten die Praxis der polnischen Datenschutzbehörde UODO im Blick behalten, besonders bei Beschäftigtendaten, Profiling und grenzüberschreitenden Dienstleisterketten. Der Verordnungstext ist in der EU derselbe. Die operative Nachweiserwartung kann sich trotzdem in Sprachfassungen, internen Freigaben und Supportverantwortlichkeiten bemerkbar machen.

Ein oft unterschätzter Punkt ist die Dokumentationssprache. Wenn Anbieterunterlagen nur auf Englisch vorliegen, operative Teams aber auf Polnisch arbeiten, entstehen Missverständnisse genau dort, wo Nutzerhinweise, Eskalationsregeln und Freigaben präzise sein müssen. Das ist kein Komfortthema. In HR, Kundenservice und Compliance wird daraus schnell ein Anwendungsrisiko.

Grenzüberschreitende Datenflüsse sollten ebenfalls konkreter geprüft werden, als viele Einkaufsunterlagen nahelegen. Ein EU-Hosting-Standort allein reicht nicht als Entwarnung. Relevant sind auch Supportzugriffe, Unterauftragsverarbeiter, Telemetrie, Modellaufrufe und die Frage, ob Inhalte außerhalb des primären Speicherorts verarbeitet werden. Bei US-geprägten Plattformen sollte diese Prüfung nicht über Marketingseiten laufen, sondern über Vertragsunterlagen, technische Dokumentation und belastbare Antworten des Anbieters.

Die Rechtsgrundlage selbst findet sich im EUR-Lex-Text der Verordnung (EU) 2024/1689. Für Datenschutzfragen rund um Profiling und automatisierte Entscheidungen sind die Leitlinien des EDPB relevanter als viele verkürzte Marktkommentare. Das ändert nicht jede Einzelfrage, verbessert aber die Qualität der Freigabeentscheidung deutlich.

Welche Use Cases 2026 zuerst gestoppt oder verschoben werden sollten

Nicht jeder KI-Einsatz verdient denselben Aufwand. Einige Kategorien sind als erste produktive Rollouts schlicht schlecht gewählt, weil sie regulatorisch und organisatorisch zu früh zu viel verlangen.

Ganz oben auf der Stop- oder Verschiebungsliste stehen Bewerberranking, Mitarbeitendenbewertung, automatisierte Ablehnung oder Priorisierung bei Leistungen, Reklamationen oder Anträgen sowie biometrische oder emotionsbezogene Auswertung im Arbeits- oder Kundensetting. Diese Fälle berühren AI Act, DSGVO und oft arbeitsrechtliche Fragen gleichzeitig. Als erste KI-Projekte sind sie selten vernünftig.

Im Kundenservice liegt das Risiko oft verdeckter. Ein Textassistent wirkt harmlos. Sobald er aber Dringlichkeit, Kulanz, Eskalation oder Reihenfolge beeinflusst, entscheidet er wirtschaftlich mit. Dann muss das Unternehmen nicht nur die Qualität der Antworten prüfen, sondern auch die Logik der Behandlung. Wer schneller antwortet, aber systematisch falsch priorisiert, hat kein Effizienzprojekt gestartet, sondern ein Steuerungsproblem in den Kernprozess eingebaut.

Weniger heikel und deshalb als Startpunkt oft sinnvoller sind interne Wissenssuche, Zusammenfassungen, Entwurfsfunktionen oder Support-Antwortvorschläge ohne automatische Ausspielung. Solche Einsätze testen Governance, Schulung und Betrieb, ohne sofort in entscheidungsnahe Zonen zu geraten.

Ein konkretes Muster aus dem Service-Betrieb sieht so aus: Ein mittelgroßer Kundenservice mit mehreren Dutzend Agenten aktiviert in seinem Ticketsystem eine automatische Fallklassifizierung. Der Rollout wirkt klein, die Reibung sitzt aber an anderer Stelle: sensible Kategorien sind nicht sauber abgegrenzt, exportierbare Logs fehlen und nach Produktupdates greifen Routingregeln anders als erwartet. Der Aufwand entsteht dann nicht im Modelltest, sondern in Nachdokumentation, Prozesskorrektur und zusätzlicher Freigabe.

Welche Unterlagen und Kontrollen vor der Freigabe nicht verhandelbar sind

Ein Satz wie „AI-Act-konform“ ist als Beschaffungsgrundlage wertlos. Vor einer Freigabe brauchen Unternehmen Unterlagen, die den konkreten Einsatz prüfbar machen.

• Funktionsbeschreibung des konkreten KI-Features: Was macht das System genau, was nicht, und an welcher Stelle greift es in den Prozess ein?
• Rollenklärung: Wer ist Anbieter, wer Integrator, wer Betreiber, wer Auftragsverarbeiter, wer supportberechtigt?
• Datenfluss- und Speicherortbeschreibung: inklusive Unterauftragsverarbeiter, Supportzugriffe, Telemetrie und möglicher Drittlandbezüge.
• Update- und Änderungsmanagement: Wie werden Modellwechsel, Prompt-Änderungen oder Funktionsänderungen angekündigt, getestet und dokumentiert?
• Logging- und Exportmöglichkeiten: Lassen sich Eingaben, Ausgaben, Nutzeraktionen, Konfigurationsstände und Freigaben nachvollziehen?
• Sicherheits- und Zugriffskonzept: Rollen, Berechtigungen, Mandantentrennung, Verschlüsselung, Incident-Prozess.
• Regeln zur Datennutzung: Werden Eingaben für Training, Feinabstimmung oder Produktverbesserung genutzt, und wenn ja, unter welchen Bedingungen?

Wenn zwei oder drei Kernpunkte offen bleiben, sollte Beschaffung nicht auf Hoffnung umstellen. Verschiebung ist dann oft billiger als spätere Korrektur. Gerade in entscheidungsnahen Prozessen ist fehlende Auditierbarkeit kein Schönheitsfehler, sondern ein Ausschlusskriterium.

Vor dem Produktivstart sind vier Kontrollen besonders wichtig. Erstens Protokollierung: Für jeden relevanten Vorgang sollte feststehen, welche Eingabe verarbeitet wurde, welche Modell- oder Prompt-Version aktiv war, welche Ausgabe erzeugt wurde, wer freigegeben oder verworfen hat und welche Aktion danach im Zielsystem ausgelöst wurde. Zweitens echte menschliche Kontrolle: Ein Freigabeschritt genügt nur dann, wenn die prüfende Person Kontext, Zeit und Eingriffsmöglichkeiten hat. Drittens Fallback und Abschaltbarkeit: Wenn ein Modell ausfällt oder sich nach einem Update anders verhält, muss der Prozess weiterlaufen. Viertens Änderungsmanagement: Neue Datenquellen, geänderte Prompts oder andere Schwellenwerte verändern das Verhalten im Prozess und brauchen Testfälle, Freigabe und Dokumentation.

Architekturfragen sind nur dann wichtig, wenn sie Kontrollierbarkeit und Auditierbarkeit verändern. Eine eigene Integrationsschicht ist nicht immer nötig. Sobald KI-Ausgaben aber in ERP, CRM, HR-Systeme oder Kundenvorgänge zurückgeschrieben werden, ist eine kontrollierte Zwischenschicht oft sinnvoller als direkte Tool-zu-Tool-Automatisierung. Sie schafft Logging, Rollentrennung, selektive Abschaltung und klarere Verantwortlichkeit.

Eine belastbare interne Freigabe muss nicht lang sein, aber konkret. Sie benennt den Use Case, die betroffenen Personen, die Datenarten, die AI-Act-Einordnung, die Datenschutzprüfung, die technischen Kontrollen, die Verantwortlichen und die Bedingungen, unter denen der Einsatz gestoppt oder neu bewertet wird. Formulierungen wie „nur unterstützend“ oder „mit menschlicher Kontrolle“ reichen nicht, wenn nicht beschrieben ist, wer kontrolliert, wann kontrolliert wird und welche Folgen eine falsche Ausgabe im Prozess auslösen kann.

Am Ende bleibt eine einfache Frage: Kann das Unternehmen diesen KI-Einsatz mit seinen Prozessen, Rollen und Nachweisen tatsächlich verantworten? Wenn die Antwort nur mit Annahmen, späteren Klärungen oder Vendor-Versprechen funktioniert, ist 2026 nicht der richtige Zeitpunkt für den Rollout.