Der AI Act ist auch eine Produktfrage

Auf X wird gerade wieder über den EU AI Act diskutiert. Es geht um Fristen, High-Risk-Systeme, Transparenzpflichten, KI-Agenten, menschliche Aufsicht und die Frage, was ab 2026 tatsächlich auf Unternehmen zukommt.

Ein Teil dieser Diskussion ist erwartbar zugespitzt. Manche Posts klingen, als würde an einem einzigen Datum plötzlich alles verboten oder erlaubt. Die offiziellen EU-Quellen sind nüchterner: Der AI Act gilt stufenweise. Manche Pflichten gelten bereits, andere folgen später, und einzelne Details werden durch Omnibus-Vorschläge und Leitlinien noch präzisiert.

Trotzdem wäre es ein Fehler, das Thema deshalb wegzuschieben.

Für Gründer, CTOs, Produktverantwortliche und Mittelstandsteams ist der AI Act nicht nur ein juristischer Terminplan. Er ist ein Signal, dass KI-Funktionen in Produkten und internen Systemen erwachsen werden müssen.

Die zentrale Frage lautet nicht: Welche Klausel gilt an welchem Tag?

Die bessere Produktfrage lautet:

Welche KI-Systeme betreiben wir eigentlich, welche Verantwortung übernehmen sie, und könnten wir morgen erklären, wie sie funktionieren, überwacht werden und begrenzt sind?

Compliance beginnt nicht im Rechtsordner

Viele Unternehmen behandeln Regulierung wie etwas, das nach der Entwicklung passiert. Erst wird gebaut. Dann wird geprüft. Dann schreibt jemand Dokumentation. Dann wird gehofft, dass die Lücken nicht zu groß sind.

Bei klassischer Software ist das schon anstrengend. Bei KI-Systemen wird es gefährlich.

KI-Funktionen sind oft nicht nur ein neues UI-Element. Sie verändern Entscheidungsprozesse, Datenflüsse und Verantwortlichkeiten. Ein Chatbot beantwortet Kundenfragen. Ein Agent klassifiziert Support-Tickets. Ein internes Tool priorisiert Bewerbungen, Rechnungen, Leads oder Risiken. Ein Coding-Agent erzeugt Pull Requests. Ein Produktfeature fasst Dokumente zusammen, schlägt Aktionen vor oder automatisiert einen Teil eines Workflows.

Sobald KI in solche Abläufe eingebaut wird, entstehen Fragen, die man nicht nachträglich sauber aufkleben kann:

Welche Daten fließen in das System?
Welche Entscheidung oder Empfehlung erzeugt es?
Wer ist verantwortlich, wenn die Empfehlung falsch ist?
Wann muss ein Mensch eingreifen?
Was wird protokolliert?
Welche Nutzer sehen, dass KI beteiligt ist?
Wie lässt sich ein Fehler nachvollziehen?
Welche Teile sind Modellverhalten, welche Teile sind Produktlogik?

Das sind keine reinen Legal-Fragen. Das sind Architekturfragen.

Natürlich sollten Unternehmen rechtliche Einschätzungen mit qualifizierter Beratung klären. Aber Produkt- und Engineering-Teams müssen die Grundlagen liefern. Ohne Inventar, Datenfluss, Rollenmodell, Logging, Dokumentation und klare Verantwortlichkeiten kann auch die beste Rechtsberatung nur begrenzt helfen.

Die Frist ist weniger wichtig als die Vorbereitung

Die aktuellen AI-Act-Termine sind wichtig. Verbote und AI-Literacy-Pflichten greifen bereits seit 2025. Regeln für General-Purpose-AI-Modelle sind seit 2025 relevant. Viele Regeln, darunter Transparenzpflichten und Enforcement-Strukturen, stehen im offiziellen Zeitplan für 2026. Gleichzeitig gibt es politische Einigungen und Vorschläge, bestimmte High-Risk-Pflichten oder Kennzeichnungspflichten anders zu staffeln.

Das klingt kompliziert, und das ist es auch.

Aber für die meisten Produktteams ist nicht der juristische Feinschliff der erste Engpass. Der erste Engpass ist viel praktischer:

Sie wissen nicht genau, welche KI-Funktionen sie betreiben.

Das klingt banal. Ist es aber selten.

In vielen Unternehmen gibt es inzwischen KI an mehreren Stellen:

Chatbots in Support oder Vertrieb;
LLM-Funktionen in SaaS-Produkten;
interne Assistenten auf Dokumenten, Wikis oder Tickets;
automatisierte Klassifizierungen und Zusammenfassungen;
AI-App-Builder-Prototypen in Fachbereichen;
Coding-Agenten in Entwicklungsprozessen;
Marketing- und Content-Workflows mit generativer KI;
Reporting- oder Analysefunktionen, die Empfehlungen erzeugen.

Einzelne Teams kennen ihre eigenen Tools. Aber kaum jemand hat ein vollständiges Bild.

Genau dort sollte AI-Act-Readiness beginnen: nicht mit Panik, sondern mit einem ehrlichen Inventar.

Das Inventar ist der erste Architekturakt

Ein KI-Inventar muss am Anfang nicht perfekt sein. Es muss brauchbar sein.

Für jedes relevante System sollte ein Unternehmen mindestens wissen:

Wo wird KI verwendet?
Welches Modell oder welcher Dienst ist beteiligt?
Welche Daten werden verarbeitet?
Geht es um interne Nutzung, Kundenkontakt oder öffentliche Inhalte?
Werden Entscheidungen getroffen, vorbereitet oder nur Texte erzeugt?
Gibt es personenbezogene, finanzielle, vertragliche oder sensible Daten?
Wer ist fachlich verantwortlich?
Wer ist technisch verantwortlich?
Welche Protokolle, Tests und Freigaben existieren?
Wie kann die Funktion abgeschaltet oder zurückgerollt werden?

Das ist kein Selbstzweck. Ohne dieses Bild kann ein Team nicht sinnvoll entscheiden, ob eine Funktion minimal riskant, transparenzpflichtig, operativ kritisch oder potenziell hochriskant ist.

Für deutsche Unternehmen ist dieser Punkt besonders relevant. Viele Mittelstandsteams haben gewachsene Systeme: ERP, CRM, DMS, Excel-Prozesse, Fachanwendungen, externe SaaS-Werkzeuge und interne Automationen. KI kommt oft nicht als ein großes Transformationsprogramm dazu, sondern als viele kleine Funktionen an vielen Stellen.

Ein Plugin hier. Ein Assistent dort. Ein automatischer Export. Eine neue Chat-Funktion. Ein schneller Prototyp. Eine Integration in ein Ticket-System.

Jede einzelne Entscheidung wirkt klein. Zusammen entsteht eine neue Systemlandschaft.

McDougall Digital betrachtet solche Inventare deshalb nicht als Bürokratie, sondern als Teil der Architekturarbeit. Wer nicht weiß, welche KI-Funktionen existieren, kann sie nicht sinnvoll betreiben.

Risiko ist eine Produkteigenschaft

Der AI Act arbeitet mit einem risikobasierten Ansatz. Für Produktteams ist das hilfreich, weil es eine wichtige Denkweise bestätigt:

Nicht jede KI-Funktion braucht denselben Prozess.

Ein Spamfilter, eine interne Ideenskizze oder eine Zusammenfassung nicht-sensibler Texte ist anders zu behandeln als ein Tool, das Bewerbungen sortiert, Kreditwürdigkeit beeinflusst, medizinische Informationen verarbeitet oder operative Entscheidungen in einer kritischen Infrastruktur unterstützt.

Das Problem ist, dass Teams diese Unterschiede oft erst spät benennen.

Gute Produktarbeit klassifiziert KI-Funktionen früh:

Hilfsfunktion: KI unterstützt eine Person, ohne relevante Entscheidungen zu treffen.
Transparenzrelevante Funktion: Nutzer müssen verstehen, dass KI beteiligt ist oder Inhalte generiert wurden.
Datenführende Funktion: Die KI verarbeitet personenbezogene, vertrauliche oder geschäftskritische Daten.
Entscheidungsunterstützung: Die KI beeinflusst Prioritäten, Bewertungen, Empfehlungen oder Freigaben.
Automatisierter Akteur: Ein Agent kann Aktionen in Systemen auslösen.
Potenzielle Hochrisiko-Funktion: Der Einsatz berührt Bereiche wie Arbeit, Bildung, kritische Infrastruktur, Zugang zu Leistungen oder andere sensible Kontexte.

Diese Kategorien ersetzen keine juristische Prüfung. Sie geben Produkt und Engineering aber eine Struktur.

Je höher die Verantwortung, desto früher müssen Architektur, Datenmodell, Berechtigungen, Logging, Tests, Fallbacks und menschliche Aufsicht mitgedacht werden.

Menschliche Aufsicht ist kein Button

In vielen Diskussionen klingt “human oversight” so, als müsse man nur irgendwo eine Freigabe-Schaltfläche einbauen.

Das reicht nicht.

Menschliche Aufsicht ist ein Workflow-Design. Der Mensch muss überhaupt verstehen können, was geprüft werden soll. Er braucht Kontext, die richtige Darstellung, klare Grenzen, Zeit und eine echte Möglichkeit, einzugreifen.

Ein schlechter Oversight-Prozess sieht so aus:

Die KI erzeugt eine Empfehlung. Ein Mensch klickt unter Zeitdruck auf “OK”. Das System protokolliert, dass ein Mensch beteiligt war. Niemand kann später erklären, welche Informationen relevant waren oder ob die Prüfung ernsthaft möglich war.

Ein besserer Prozess sieht anders aus:

Die KI zeigt ihre relevante Eingabegrundlage.
Das System markiert Unsicherheiten und Grenzfälle.
Der Mensch sieht, welche Regel oder welches Kriterium angewendet wurde.
Bestimmte Aktionen bleiben immer manuell.
Widerspruch, Korrektur und Eskalation sind vorgesehen.
Die Entscheidung wird nachvollziehbar protokolliert.
Häufige Fehlmuster fließen in Produktverbesserungen zurück.

Das ist Architektur, UX und Betrieb zugleich.

Wenn ein KI-Agent Tickets schließen, Kundendaten ändern, Bewerbungen vorsortieren oder Code in eine produktive Codebasis bringen darf, muss Aufsicht im Systemdesign stecken. Sie darf nicht nur in einer Policy-Datei stehen.

Transparenzpflichten werden oft als Label-Frage verstanden: Muss irgendwo stehen, dass der Inhalt KI-generiert ist?

Manchmal ja. Aber produktseitig ist Transparenz größer.

Nutzer müssen verstehen, wann sie mit einer Maschine interagieren, wann ein Inhalt synthetisch erzeugt wurde, welche Rolle KI in einem Prozess spielt und wo menschliche Verantwortung liegt. Support-Teams müssen erklären können, was passiert ist. Sales-Teams dürfen keine Fähigkeiten versprechen, die das System nicht zuverlässig hält. Produktmanager müssen entscheiden, wann KI sichtbar gemacht wird und wann Automatisierung im Hintergrund läuft.

Das hat praktische Folgen:

UI-Texte müssen präzise sein.
Fehlerzustände müssen ehrlich sein.
KI-generierte Inhalte brauchen Herkunft und Kontext.
Support-Dokumentation muss die KI-Funktion erklären.
Interne Teams müssen wissen, welche Aussagen sie Kunden gegenüber machen dürfen.
Logs müssen die relevanten Ereignisse nachvollziehbar machen.

Transparenz ist nicht Dekoration. Sie ist ein Teil der Produktqualität.

Dokumentation muss aus dem System entstehen

Viele Teams fürchten Dokumentation, weil sie nach nachträglicher Schreibarbeit klingt.

Das ist verständlich, aber der falsche Ansatz. Bei KI-gestützter Software sollte ein großer Teil der Dokumentation aus guter Architektur und sauberer Umsetzung entstehen.

Wenn Datenflüsse modelliert sind, kann man sie dokumentieren. Wenn Rollen klar sind, kann man Berechtigungen erklären. Wenn Prompts, Modelle, Versionen, Tests und Evaluationsdaten strukturiert verwaltet werden, ist die Dokumentation keine Schatzsuche. Wenn Entscheidungen und Outputs geloggt werden, entsteht Nachvollziehbarkeit im Betrieb.

Schlechte Dokumentation ist oft ein Symptom schlechter Architektur.

Gute Readiness-Arbeit fragt deshalb:

Sind Datenquellen und Datenarten sichtbar?
Sind Modellaufrufe und Versionen nachvollziehbar?
Sind Prompts, Tools und Systemgrenzen versioniert?
Gibt es Testfälle für riskante Szenarien?
Werden Fehlverhalten und Nutzerkorrekturen ausgewertet?
Gibt es eine verantwortliche Person für Betrieb und Weiterentwicklung?
Gibt es einen Plan für Modellwechsel, Deaktivierung oder Fallback?

Diese Fragen helfen nicht nur bei Regulierung. Sie machen das Produkt robuster.

Warum jetzt anfangen?

Weil die teuren Lücken nicht erst am Stichtag entstehen.

Sie entstehen, wenn ein Team KI-Funktionen über Monate in ein Produkt einbaut, ohne Datenflüsse, Verantwortlichkeiten, Logging und Grenzen sauber zu definieren. Sie entstehen, wenn ein Prototyp zum Kundenfeature wird. Sie entstehen, wenn ein Agent erst intern assistiert und später Aktionen ausführen darf. Sie entstehen, wenn niemand mehr weiß, welche Modellversion welche Entscheidung beeinflusst hat.

Wer erst kurz vor einer Frist aufräumt, muss oft umbauen.

Wer jetzt beginnt, kann AI-Act-Readiness als Qualitätsarbeit behandeln:

bessere Produktentscheidungen;
klarere Systemgrenzen;
weniger Schattenprozesse;
bessere Dokumentation;
belastbarere Support- und Betriebsprozesse;
realistischere Versprechen gegenüber Kunden;
weniger Risiko beim Ausbau von KI-Funktionen.

Das ist der produktive Blick auf Regulierung. Nicht: Wie vermeiden wir Ärger? Sondern: Wie bauen wir KI-gestützte Software so, dass sie erklärbar, wartbar, sicher und verantwortbar ist?

Ein pragmatischer 30-Tage-Start

Unternehmen müssen nicht sofort ein riesiges AI-Governance-Programm starten. Ein sinnvoller Anfang kann sehr konkret sein.

In den ersten 30 Tagen:

KI-Inventar erstellen: Alle KI-Funktionen, internen Assistenten, Agenten, App-Builder-Prototypen und generativen Workflows sammeln.
Daten klassifizieren: Welche Funktionen berühren personenbezogene, vertrauliche, finanzielle, vertragliche oder kundenspezifische Daten?
Risiko grob einordnen: Welche Funktionen sind nur Hilfsmittel, welche beeinflussen Entscheidungen, welche handeln automatisch?
Owner festlegen: Jede relevante Funktion braucht fachliche und technische Verantwortung.
Transparenz prüfen: Wo müssen Nutzer, Kunden oder interne Teams klarer informiert werden?
Oversight definieren: Welche Aktionen brauchen menschliche Prüfung, Eskalation oder manuelle Freigabe?
Logging und Dokumentation prüfen: Was wäre nachvollziehbar, wenn morgen ein Fehler untersucht werden müsste?
Prioritäten setzen: Nicht alles muss gleichzeitig gelöst werden. Kritisch sind externe, datenführende und entscheidungsnahe Systeme.

Dieser Start ersetzt keine rechtliche Bewertung. Aber er macht das Unternehmen gesprächsfähig und handlungsfähig.

Wie McDougall Digital helfen kann

Für McDougall Digital ist AI-Act-Readiness kein isoliertes Compliance-Projekt. Es ist ein Teil davon, KI-gestützte Software seriös in Produktion zu bringen.

Wir helfen Unternehmen dabei, aus vagen KI-Ideen belastbare Systeme zu machen:

KI-Funktionen und Agenten inventarisieren;
Datenflüsse, Modellaufrufe und Systemgrenzen sichtbar machen;
Risiken aus Produkt-, Architektur- und Betriebssicht bewerten;
menschliche Aufsicht und Freigabeprozesse sinnvoll in Workflows einbauen;
Logging, Dokumentation, Rollen und Verantwortlichkeiten strukturieren;
Prototypen produktionsreif machen oder bewusst begrenzen;
AI-gestützte interne Tools so bauen, dass sie wartbar und betreibbar bleiben.

Das Ziel ist nicht, Innovation mit Papier zu ersticken. Das Ziel ist, gute KI-Ideen so zu bauen, dass ein ernsthaftes Unternehmen sie verantworten kann.

Der AI Act wird weiter diskutiert werden. Fristen können präzisiert, verschoben oder durch Leitlinien ergänzt werden. Aber die technische Grundarbeit bleibt.

Wer heute weiß, welche KI-Systeme er betreibt, welche Daten sie berühren, welche Entscheidungen sie beeinflussen und wie Menschen eingreifen können, ist nicht nur besser auf Regulierung vorbereitet.

Er baut auch bessere Software.