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.
| Prüfschritt | Was konkret zu prüfen ist | Freigabefähig | Stopp oder Eskalation |
|---|---|---|---|
| 1. Use Case abgrenzen | Prozessschritt, Eingaben, Ausgaben, Zielsysteme, Prozessowner, betroffene Abteilung | Ein klarer, begrenzter Ablauf mit benanntem Owner | Unklare Prozessgrenzen, mehrere Teams ohne Verantwortung, offener Scope |
| 2. Betroffene Personen bestimmen | Mitarbeitende, Bewerbende, Kunden, Lieferanten oder andere Personen | Interne Assistenz ohne Außenwirkung | Bewertung, Priorisierung, Ausschluss oder Überwachung von Personen |
| 3. Daten und Rechtsgrundlage prüfen | Personenbezogene Daten, besondere Kategorien, Datenquellen, Speicherorte, Transfers | Datenminimierung, Zweckbindung, Löschpfad und Rechtsgrundlage sind dokumentiert | Unklare Datenherkunft, sensible Daten ohne Schutzkonzept, Drittlandzugriffe ungeklärt |
| 4. Entscheidungswirkung bewerten | Beeinflusst die KI Zugang, Reihenfolge, Preis, Leistung, Beschäftigung oder Eskalation? | Nur Entwurf, Recherche oder Empfehlung mit echter menschlicher Prüfung | Automatische oder faktisch automatische Vorentscheidung |
| 5. AI-Act-Kategorie prüfen | Verbot, Hochrisiko, Transparenzpflicht, GPAI-Bezug auf Anbieterseite | Keine Verbote, Pflichten beherrschbar, Kategorie dokumentiert | Hochrisiko-Kontext ohne Nachweise oder unzulässige Praxis |
| 6. Anbieterunterlagen prüfen | Funktionsbeschreibung, Logs, Update-Prozess, Datennutzung, Unterauftragsverarbeiter, Sicherheitskonzept | Nachvollziehbare Unterlagen und vertraglich belastbare Aussagen | Marketingaussagen ohne prüfbare Dokumentation |
| 7. Kontrollen definieren | Logging, Freigabe, Fallback, Rollen, Testfälle, Monitoring, Abschaltbarkeit | Kontrollen vor Produktivstart eingerichtet | Direkter Rollout ohne Überwachung oder Rückfalloption |
| 8. Freigabe dokumentieren | Risikoannahmen, Auflagen, Verantwortliche, Review-Termin, Stop-Kriterien | Schriftliche Freigabe mit Scope und Auflagen | Pilot oder Rollout ohne dokumentierte Entscheidung |
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.
