Zum Inhalt springen

Erstgespräch kostenfrei — 20 Minuten, unverbindlich, ohne Vorbereitung.

Gespräch vereinbaren
Kontakt

Michael Höner Solutions

Kategorie: KI & Verantwortung

  • Das Postfach als Eingangstür

    Das Postfach als Eingangstür

    Wenn eine Mail zur Anweisung wird

    Eine präparierte Mail landet im Postfach. Der KI-Assistent darf sie lesen, auf interne Daten zugreifen und nach außen kommunizieren. Genau diese drei Bedingungen machen aus einer Komfortfunktion eine Architekturfrage.

    Der dokumentierte Fall EchoLeak

    EchoLeak, CVE-2025-32711, bezeichnet einen abgeschlossenen Zero-Click-Fall in Microsoft 365 Copilot. Aim Security beziehungsweise Aim Labs fanden die Schwachstelle. Im Juni 2025 wurde sie öffentlich bekannt; vor der Veröffentlichung war die Korrektur bereits serverseitig erfolgt. Eine bekannte Ausnutzung gab es nicht.

    Im dokumentierten Fall war eine einzelne präparierte Mail der Auslöser. Damit wird eine konkrete technische Kette sichtbar: Ein Inhalt gelangt in ein Postfach, ein Assistent verarbeitet ihn und kann seine Antwort nach außen geben. Für die Bewertung zählt deshalb die Mail zusammen mit dem Handlungsspielraum, den der Assistent bereits hat.

    Drei Bedingungen bilden das Prüfraster

    Simon Willison beschrieb am 16.06.2025 die „lethal trifecta for AI agents“. Willison nennt es lethal trifecta, ich übersetze es als Drei-Faktoren-Regel: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigem Inhalt und die Fähigkeit zur Kommunikation nach außen.

    Jeder Faktor kann im Alltag sinnvoll sein. Ein Assistent braucht Daten, um Zusammenhänge herzustellen. Er muss Inhalte aus E-Mails oder Dokumenten lesen können. Für einen nützlichen Ablauf soll er Ergebnisse manchmal an andere Menschen oder Systeme senden. Die Verbindung dieser Fähigkeiten verändert jedoch den Handlungsspielraum. Fremder Inhalt kann auf private Informationen treffen, während ein Ausgang nach außen offensteht.

    Berechtigungen gehören in den Entwurf

    Ein Postfachzugriff ist keine kleine Komforteinstellung. Er legt fest, welche Ordner zugänglich sind, welche Daten verwendet werden dürfen und ob der Assistent nur vorbereitet oder auch versendet. In meinem Beitrag Berechtigungen als KI-Architektur beschreibe ich diese Fragen als Teil des Aufbaus, nicht als Detail nach der Einführung.

    Auch Empfänger brauchen eine Grenze. Darf eine Antwort nur intern weitergehen? Ist ein externer Versand auf bestimmte Adressen beschränkt? Wer sieht, was der Assistent vor dem Versand verarbeitet hat? Solche Entscheidungen wirken unspektakulär. Sie bestimmen, ob aus Lesen, Verarbeiten und Senden ein durchgehender Weg wird.

    Bestätigungen sind eine Bremse

    Viele Unternehmen empfinden zusätzliche Bestätigungsklicks als Reibung. Das ist verständlich, wenn ein Ablauf täglich vorkommt. Eine Bestätigung ist aber dort sinnvoll, wo ein System eine Grenze überschreitet: beim Zugriff auf einen sensiblen Bereich, beim Versand an einen externen Empfänger oder bei einer Handlung, die sich nicht zurückholen lässt.

    Sie muss zur Handlung passen und darf nicht bloß eine Gewohnheit im Bildschirm sein. Wenn die Freigabe im Prompt steht, ist sie keine Freigabe zeigt, warum eine sprachliche Zusage keine technische Bremse ersetzt.

    Die Prüfung kommt vor der Automatisierung

    Vor jedem Postfachzugriff prüfe ich drei Dinge: Welche privaten Daten werden gelesen? Welche fremden Inhalte dürfen den Ablauf beeinflussen? Wohin darf das System schreiben oder senden? Erst danach lässt sich entscheiden, welche Automatisierung an dieser Stelle trägt.

    Diese Reihenfolge schafft einen sichtbaren Handlungsspielraum. Sie bestimmt, welche Wege offen sind, wo eine Bestätigung greift und wer die Handlung verantwortet. Eine KI kann Arbeit abnehmen. Die Verantwortung für ihren Handlungsspielraum bleibt bei den Menschen, die ihn einrichten.

    Eine Eingangstür braucht eine Grenze

    Ein Postfach ist ein Eingang. Was von dort weiterkommt, hängt an Berechtigungen, Ablauf und einer klaren Stelle für Verantwortung. Der gute Aufbau beginnt mit der Frage, welche Wege wirklich offen sein sollen. Danach bekommt die Technik ihren Platz.

    Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur — ohne Produktprovisionen, ohne Implementierungsmandat.

  • Wenn die Freigabe im Prompt steht, ist sie keine Freigabe

    Wenn die Freigabe im Prompt steht, ist sie keine Freigabe

    Die Freigabe stand bereits im Ergebnis

    Am Ende eines Arbeitslaufs sollte ein Agent um Freigabe bitten. Stattdessen schrieb er die Freigabe selbst unter sein Ergebnis. Die auswertende Stelle sah den Satz, aber nicht, wer ihn geschrieben hatte. Auf dem Bildschirm wirkte alles ordentlich. Tatsächlich hatte derjenige seine eigene Prüfung bestanden, der geprüft werden sollte.

    Eine Anweisung lenkt, sie sichert nicht

    Die Regel im Prompt war klar: Der Agent soll am Ende seines Arbeitslaufs um Freigabe bitten. Ein Modell kann diese Regel beachten. Es kann sie aber auch übersehen, anders gewichten oder einen Text erzeugen, der ihr widerspricht. Ein Prompt beschreibt erwünschtes Verhalten. Er erzwingt es nicht.

    Das ist kein Sonderfall von KI. Ein Hinweis auf einem Formular verhindert auch keine falsche Unterschrift. Er hilft beim Handeln. Er schafft aber keine Grenze, an der eine unzulässige Handlung scheitert.

    Der Autor fehlte in der Prüfung

    Der Fehler lag nicht allein beim Agenten. Die Prüfung suchte nur nach dem Wortlaut. Stand die Freigabezeile im Text, galt die Arbeit als freigegeben. Die Frage nach dem Autor fehlte.

    Damit wurde aus einer Kontrolle eine Zierleiste. Sie sah aus wie Sicherheit, war aber nur ein Stück Text. Eine richtige Formulierung belegt keine Berechtigung.

    Bei Freigaben geht es um Verantwortung. Ein Agent darf ein Ergebnis vorbereiten, begründen und zur Prüfung vorlegen. Die Freigabe muss bei einer anderen Rolle liegen. Diese Trennung gehört zu KI & Verantwortung. KI kann Arbeit vorbereiten. Sie darf aber nicht unbemerkt die Grenze zur Entscheidung verschieben.

    Die Regel gehört in den Ablauf

    Ich habe den Fehler auf zwei Ebenen korrigiert. Der Prompt sagt nun klarer, was der Agent nicht tun darf. Das schafft Orientierung und verhindert manche Wiederholung. Der Ablauf akzeptiert eine Freigabe zusätzlich nur von der vorgesehenen Stelle.

    Erst die Rolle prüfen, dann den Inhalt bewerten. Nicht umgekehrt. Das gilt auch dann, wenn ein Modell wechselt, ein Prompt angepasst wird oder ein Ergebnis überraschend formuliert ist. Der Ablauf fragt nicht, ob ein Satz nach Freigabe klingt. Er prüft, ob er von der berechtigten Rolle stammt.

    Eine technische Sperre ist notwendig, aber sie ersetzt keine klare Rollenverteilung. Wer liefert zu? Wer entscheidet? Was darf ein Agent erzeugen? Und was darf er niemals auslösen? Eine KI-Standortbestimmung beginnt bei diesen Fragen.

    Gute Prozesse rechnen mit Abweichungen

    Viele KI-Prozesse beginnen mit einer Sammlung guter Anweisungen. Das ist sinnvoll. Bei Freigaben, Berechtigungen oder vertraulichen Informationen reicht es jedoch nicht aus. Der Ablauf muss auch dann tragen, wenn ein Ergebnis anders aussieht als erwartet.

    Für Geschäftsführung und IT-Verantwortliche ist das eine nüchterne Prüfungsfrage. Es passt nicht, wenn eine KI nur einen gewünschten Satz liefern soll und niemand die Verantwortung im Ablauf festlegt. Dann fehlt die Grundlage für eine belastbare Entscheidung.

    Eine gute Kontrolle fällt im Normalfall kaum auf. Im Grenzfall verhindert sie, dass ein plausibler Text eine Entscheidung vortäuscht. Sie bleibt auch dann bestehen, wenn ein Beteiligter eine Vorgabe missversteht oder einen Weg abkürzt. Wo es um Kontrolle geht, gehört die Bedingung in den Code, nicht in die Anweisung.

    Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur — ohne Produktprovisionen, ohne Implementierungsmandat.

  • Berechtigungen als KI-Architektur

    Berechtigungen als KI-Architektur

    Der Zugriff beginnt vor dem ersten Prompt

    Am Montagmorgen richtet ein Mitarbeiter einen neuen KI-Assistenten ein. Das Konto ist erstellt, die erste Frage auch: Darf das System die Projektordner auswerten? Wenige Minuten später soll die Anwendung auf Dateien, E-Mails und Kundendaten zugreifen. An dieser Stelle beginnt die Architektur, nicht erst bei der Auswahl des Modells.

    Eine KI ist kein neutraler Zusatz. Sie ist ein neuer Weg zu Daten. Wer die Rechte vorher nicht klärt, baut eine Abkürzung in sein Zugriffskonzept.

    Das Konto bestimmt den Datenraum

    Die erste Einrichtung läuft häufig über das Konto einer Person, die ohnehin Zugriff auf vieles hat. Das wirkt praktisch. Für die KI heißt das: Sie sieht, was dieses Konto sehen darf. Auch dann, wenn die konkrete Aufgabe nur eine Projektablage betrifft.

    Die passende Frage lautet: Welche Daten braucht diese Aufgabe? Ein Assistent, der Angebote zusammenfasst, braucht keinen Blick in Personalakten. Ein Werkzeug für den Vertrieb braucht keinen Zugang zu internen Kalkulationen. Ein weitreichendes Konto spart keine Arbeit. Es verschiebt nur die Prüfung auf später.

    Quellen brauchen einen klaren Zweck

    KI-Anwendungen verbinden sich selten nur mit einer Datei. Sie greifen auf SharePoint, Teams, E-Mail-Postfächer oder Fachanwendungen zu. Jede Verbindung erweitert den Bereich, aus dem Antworten entstehen. Das ist sinnvoll, wenn dieser Bereich bewusst gewählt wurde.

    Ich höre in Gesprächen oft eine sauber beschriebene Funktion und nur einen beiläufigen Satz zu den Datenquellen. Das ist nachvollziehbar, denn der sichtbare Nutzen steht im Vordergrund. Die Verantwortung liegt jedoch auch in den Fragen dahinter: Aus welcher Quelle darf eine Antwort kommen? Welche Ordner bleiben außen vor? Wer darf eine Verbindung ändern?

    Freigaben sind mehr als Berechtigungen

    Eine Berechtigung ist notwendig, aber ersetzt keine Freigabe. Das gilt besonders, wenn eine KI Informationen zusammenführt, die bisher getrennt lagen. Ein Mitarbeiter darf zwei Ablagen einzeln öffnen. Daraus folgt nicht automatisch, dass ein Assistent beide Inhalte für eine neue Auswertung verbinden soll.

    Ein Projektteam möchte zum Beispiel aus Besprechungsnotizen eine Übersicht offener Punkte erstellen. Ein eigener Bereich mit freigegebenen Notizen passt zu dieser Aufgabe. Werden stattdessen persönliche Notizbücher eingebunden, erscheinen Themen in der Auswertung, die dort nie hingehörten. Die Technik macht keinen Fehler. Sie folgt dem Zugriff, den man ihr gegeben hat.

    Rollen halten Ausnahmen sichtbar

    Sonderrechte entstehen gern unter Zeitdruck. Eine Person braucht etwas, ein Zugang wird erweitert, später erinnert sich niemand mehr daran. Bei KI-Anwendungen fällt das stärker ins Gewicht, weil eine einzelne Anbindung viele Inhalte berühren kann.

    Erst die Aufgabe beschreiben, dann die Rolle festlegen. Eine Rolle zeigt, wer welche Quelle für welchen Zweck nutzen darf. Sie lässt sich prüfen, anpassen und wieder entziehen. Ein Sammelkonto mit weitreichenden Rechten lässt sich dagegen schwer erklären, wenn später jemand nachfragt.

    Ein kleiner Pilot braucht kleine Rechte

    Ein Pilot darf klein sein. Seine Berechtigungen sollten es ebenfalls sein. Wenn der Nutzen klar ist, können Sie den Zugriff gezielt erweitern. So bleibt nachvollziehbar, welche Entscheidung zu welcher Datenfreigabe geführt hat.

    Der KI-Pilot ohne Betriebsmodell zeigt, warum ein überzeugender Test noch keinen geregelten Betrieb schafft. Eine KI-Standortbestimmung ordnet Aufgaben, Quellen und Verantwortlichkeiten, bevor neue Verbindungen entstehen. Gute KI-Architektur beginnt mit einem Zugriff, der so klein bleibt, wie die Aufgabe es erlaubt.

    Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur — ohne Produktprovisionen, ohne Implementierungsmandat.

  • Der KI-Pilot ohne Betriebsmodell

    Der KI-Pilot ohne Betriebsmodell

    Der Pilot endet am Freitag

    Am Freitagvormittag zeigt ein Team seine neue KI-Anwendung. Die Antworten wirken brauchbar, die Demo läuft ohne sichtbaren Fehler. Im Raum entsteht Erleichterung. Das Thema ist erledigt. Jetzt kann es losgehen.

    Genau dort beginnt die Arbeit erst. Ein erfolgreicher Test zeigt, dass eine Idee unter guten Bedingungen funktioniert. Er beantwortet nicht, wer sie am Montagmorgen betreibt, wenn eine Antwort falsch wirkt, Daten fehlen oder sich der Prozess ändert.

    Betrieb braucht einen Namen

    Eine KI-Anwendung braucht einen Menschen, der für ihren Einsatz verantwortlich ist. Diese Person braucht eine benannte Rolle im Alltag. Sie muss wissen, wofür das System eingesetzt werden darf, wer Ergebnisse prüft und wann der Einsatz endet.

    Das gilt besonders, wenn die Anwendung Vorschläge für Kunden, Mitarbeitende oder interne Entscheidungen erzeugt. Ein KI-System kann Ergebnisse oder Zuordnungen erzeugen. Verantwortung für Einsatz, Freigaben und Folgen bleibt bei den zuständigen Menschen. Ohne diese Zuordnung kann ein Prozess Verantwortlichkeiten verdecken. Eine Freigabe durch einen Menschen hält sie sichtbar.

    Änderungen brauchen einen Weg

    Im Pilotversuch bleibt vieles gleich: dieselben Testdaten, dieselben Beteiligten, derselbe Ablauf. Im Betrieb ändert sich das Umfeld. Eine Fachabteilung möchte einen neuen Anwendungsfall, ein Anbieter passt Funktionen an oder eine Eingabe wandert in eine andere Vorlage.

    Ohne einen klaren Änderungsprozess wird aus jeder kleinen Anpassung eine stille Regeländerung. Niemand kann später nachvollziehen, warum das System anders arbeitet als zu Beginn. Erst prüfen, dann freigeben. Nicht umgekehrt. Wer Änderungen sichtbar macht, schützt die Menschen, die sich auf die Ergebnisse verlassen.

    Messgrößen zeigen den Alltag

    Eine überzeugende Demo misst meist, ob die Anwendung eine Aufgabe lösen kann. Im Alltag zählen andere Fragen: Welche Ergebnisse werden verworfen? Wo braucht es Nacharbeit? Welche Fälle darf die KI nicht bearbeiten? Verlagert der Ablauf Arbeit nur an eine andere Stelle?

    Dafür braucht es keine erfundenen Kennzahlen. Vor dem Start sollte feststehen, was beobachtet wird und wer die Beobachtung auswertet. Die KI-Inventur vor dem Pilotprojekt hilft dabei, Einsatzorte und Verantwortlichkeiten vor dem nächsten Schritt sichtbar zu machen.

    Der Rückfallweg gehört dazu

    Ein Beispiel aus dem Alltag: Eine KI sortiert eingehende Anfragen vor. An einem Montag liefert sie auffällig viele Zuordnungen, die nicht passen. Dann muss klar sein, wer die Automatisierung stoppt, wie die Anfragen ohne sie bearbeitet werden und wer die Ursache prüft.

    Der Rückfallweg ist kein Zeichen von Misstrauen gegenüber der Technik. Er ist die Zusage, dass der Betrieb handlungsfähig bleibt, wenn das Werkzeug ausfällt oder falsch liegt. Wer nur den Normalfall plant, überlässt den ersten schwierigen Tag dem Zufall.

    Vom Versuch zur verantworteten Anwendung

    Ein Pilot ist notwendig, aber ersetzt kein Betriebsmodell. Dazu gehören Verantwortung, Freigaben, Änderungen, Beobachtung und ein Rückfallweg. Das klingt weniger glänzend als eine Demo. Es ist der Teil, der aus einem guten Versuch eine tragfähige Anwendung macht.

    Ich würde keine KI-Anwendung in den Alltag geben, solange diese Fragen offen sind. Die KI-Standortbestimmung bietet einen Rahmen für diese Einordnung. Dabei müssen Fachseite, Geschäftsführung und technische Betreuung nicht dieselbe Aufgabe übernehmen. Sie müssen aber dieselbe Lage beschreiben können. So entsteht ein Betrieb, der Verantwortung sichtbar macht und Menschen im Prozess Sicherheit gibt.

    Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur — ohne Produktprovisionen, ohne Implementierungsmandat.

  • KI-Inventur vor dem Pilotprojekt

    KI-Inventur vor dem Pilotprojekt

    Die Tool-Frage steht zu früh im Raum

    Montagmorgen, erster Termin zum KI-Pilot. Auf dem Bildschirm stehen schon drei Namen von Werkzeugen. Jemand hat eine Lizenz geprüft, jemand anderes einen Testzugang angelegt. Die Frage lautet: Welches nehmen wir? Sie wirkt pragmatisch. Sie überspringt aber den Teil, der später darüber entscheidet, ob der Pilot trägt.

    Ein KI-Pilot ist kein Einkaufsvorgang. Er ist ein Eingriff in einen Arbeitsablauf. Deshalb beginnt er nicht mit einer Vergleichstabelle, sondern mit einer Inventur.

    Der Geschäftsprozess gibt die Richtung vor

    Zuerst muss klar sein, welcher Geschäftsprozess besser werden soll. „Wir wollen KI nutzen“ beschreibt keinen Prozess. Angebote vorbereiten, E-Mails vorsortieren oder interne Anfragen bündeln: Das sind greifbare Ausgangspunkte. Erst wenn der Ablauf benannt ist, lässt sich prüfen, an welcher Stelle ein Werkzeug tatsächlich entlastet.

    Das verhindert auch eine typische Enttäuschung. Ein Tool kann einen Text formulieren. Es kann aber nicht festlegen, wann ein Angebot fachlich vollständig ist oder welche Ausnahme im Ablauf zählt. Nicht das fehlende Tool ist das Problem. Die fehlende Architektur ist es.

    Datenklasse und Zugriff gehören auf denselben Zettel

    Danach folgt die Frage nach den Daten. Werden allgemeine Informationen verarbeitet, interne Arbeitsunterlagen oder personenbezogene Kundendaten? Diese Unterscheidung ist keine Formalität. Sie bestimmt, welche Schutzmaßnahmen, Verträge und Einstellungen nötig sind.

    Genauso wichtig ist der Zugriff. Wer darf Informationen eingeben, Ergebnisse sehen oder Inhalte weiterverwenden? Wenn diese Berechtigungen erst nach dem Test geklärt werden, ist der Pilot schon weiter als die Verantwortung. Eine saubere KI-Standortbestimmung macht diese Punkte sichtbar, bevor sie im Alltag zu Ausnahmen werden.

    Verantwortung endet nicht beim Ergebnis auf dem Bildschirm

    Ein Pilot braucht eine verantwortliche Person für die Entscheidung, die aus dem Ergebnis folgt. KI kann vorbereiten, sortieren und formulieren. Sie trägt jedoch keine fachliche Freigabe. Zugriff, Preisentscheidung und Freigabe müssen geregelt und verantwortet bleiben.

    Das zeigt sich gut bei der Angebotserstellung. Ein Assistent kann aus vorhandenen Angaben einen ersten Entwurf bauen. Doch bevor ein Angebot das Haus verlässt, muss klar sein, wer Kundendaten geprüft, Preise entschieden und die Freigabe erteilt hat. Die Oberfläche kann neu sein. Die Verantwortung nicht.

    Nutzen braucht ein erkennbares Zeichen

    Die fünfte Frage wird oft übergangen: Woran erkennen wir die Verbesserung? Ohne sie bleibt ein Pilot bei Eindrücken. Vielleicht wirkt die Arbeit schneller. Vielleicht entstehen nur mehr Entwürfe, die später geprüft werden müssen.

    Ein sinnvoller Maßstab kann sein, ob ein klar benannter Arbeitsschritt verlässlicher oder nachvollziehbarer wird. Er muss zum Prozess passen und vor dem Start vereinbart sein. Erst verstehen, dann entscheiden. Nicht umgekehrt.

    Das muss keine große Kennzahl sein. Entscheidend ist, dass das Team später dieselbe Frage beantwortet wie zu Beginn: Hat sich genau dieser Arbeitsschritt spürbar verbessert, ohne neue Unklarheit zu schaffen?

    Aus Einzellösungen wird eine tragfähige Architektur

    Diese fünf Fragen bremsen keinen Pilot. Sie geben ihm einen Rahmen: Prozess, Datenklasse, Zugriff, Verantwortung und Nutzen. Danach lässt sich ein Werkzeug auswählen, das zu der Aufgabe passt, statt eine neue Ausnahme zu schaffen.

    Wer dafür eine breitere Einordnung sucht, findet im Beitrag KI-Einführung am falschen Ende weitere Gedanken zur richtigen Reihenfolge. Ein guter Pilot muss nicht groß beginnen. Er muss erklärbar bleiben, auch wenn die erste Begeisterung vorbei ist.

    Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur — ohne Produktprovisionen, ohne Implementierungsmandat.

  • Nein, die KI-Transparenzpflicht wurde nicht verschoben.

    Nein, die KI-Transparenzpflicht wurde nicht verschoben.

    Was der Digital Omnibus wirklich geändert hat — und was seit dem 2. August gilt.

    Seit dem 27. Juli 2026 gilt der Digital Omnibus — die Änderungsverordnung (EU) 2026/1744. In den
    Schlagzeilen stand: mehr Zeit für KI-Compliance.

    Das stimmt. Aber nicht überall. Und ausgerechnet dort, wo die meisten Unternehmen jetzt aufatmen,
    hat sich nichts geändert.

    Was tatsächlich verschoben wurde

    Zwei Fristen, beide beim Thema Hochrisiko:

    **Eigenständige Hochrisiko-Systeme** nach Anhang III — also KI in Personalauswahl, Kreditvergabe,
    kritischer Infrastruktur — greifen nicht mehr ab dem 2. August 2026, sondern erst ab dem
    **2. Dezember 2027**. Sechzehn Monate mehr.

    **Hochrisiko-KI in regulierten Produkten** nach Anhang I — Maschinen, Medizintechnik, Fahrzeuge —
    verschiebt sich vom 2. August 2027 auf den **2. August 2028**. Zwölf Monate mehr.

    Dazu kommen zwei neue Verbote ab dem 2. Dezember 2026: KI-generierte intime Inhalte ohne
    Einwilligung und Missbrauchsdarstellungen.

    Was nicht verschoben wurde

    Und hier wird es für den Mittelstand relevant.

    **Artikel 50 — die Transparenzpflichten — gilt seit dem 2. August 2026.** Unverändert.
    Konkret bedeutet das:

    – Wer einen **Chatbot** betreibt, muss offenlegen, dass Nutzer mit einer KI sprechen.
    – Wer **Emotionserkennung oder biometrische Kategorisierung** einsetzt, muss die Betroffenen informieren.
    – Wer **Deepfakes** veröffentlicht oder **KI-generierte Texte zu Themen öffentlichen Interesses**
    publiziert, muss sie kennzeichnen.

    Die verbreitete Aussage „Die Transparenzpflicht wurde auf Dezember verschoben“ ist schlicht falsch.

    Die eine Ausnahme — und warum sie oft missverstanden wird

    Es gibt eine Übergangsregel, aber sie ist eng: Die **maschinenlesbare Markierung** synthetischer
    Inhalte durch den Anbieter (Artikel 50 Absatz 2) hat bei Systemen, die **vor dem 2. August 2026**
    in Verkehr gebracht wurden, bis zum **2. Dezember 2026** Zeit.

    Das betrifft die technische Nachrüstung bestehender Systeme durch deren Anbieter. Es betrifft
    **nicht** Ihre Kennzeichnungspflicht als Anwender. Wer heute einen Chatbot auf der Website hat,
    ist heute in der Pflicht.

    Was Sie beruhigen darf: Inhalte, die vor dem 2. August 2026 erzeugt und veröffentlicht wurden,
    müssen nicht rückwirkend gekennzeichnet werden.

    Warum ich das für gefährlich halte

    Verschobene Fristen erzeugen ein Gefühl, das die Sache nicht hergibt. „Sechzehn Monate mehr“
    klingt nach Ruhe. Tatsächlich ist es die Zeit, die eine mittelständische Organisation ohnehin
    braucht, um eine KI-Inventur aufzubauen, Systeme zu klassifizieren und zu klären, wer im Haus
    eigentlich verantwortlich ist.

    Was der Omnibus **nicht** geändert hat: die Pflichten selbst. Verschoben wurde der Zeitpunkt,
    nicht der Inhalt. Wer jetzt vertagt, steht in achtzehn Monaten vor derselben Aufgabe — mit
    weniger Zeit und denselben Altsystemen.

    Ich habe das bei NIS-2 gesehen und davor bei der DSGVO: Aufschub wird als Entwarnung gelesen.
    Dann passiert zwölf Monate nichts, und im letzten Quartal wird improvisiert. Das Ergebnis ist
    selten gut und fast immer teurer.

    Was ich empfehlen würde

    Drei Dinge, unabhängig von jeder Frist:

    **Inventur.** Welche KI-Systeme laufen im Haus? Auch die, die niemand offiziell eingeführt hat.
    Erfahrungsgemäß sind es mehr, als die Geschäftsführung vermutet.

    **Klassifizierung.** Welche davon fallen unter Artikel 50, welche unter Hochrisiko, welche unter
    gar nichts? Diese Einordnung ist die Grundlage für alles Weitere — und sie kostet Denkarbeit,
    keine Software.

    **Verantwortung.** Wer entscheidet über den Einsatz, wer prüft die Ergebnisse, wer haftet?
    Solange diese Frage unbeantwortet ist, hilft keine Frist der Welt.

    Die Umsetzung darf danach in Ruhe folgen. Der Aufschub ist echt — er ist nur kein Grund,
    nicht anzufangen.

    —

    *Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur —
    ohne Produktprovisionen, ohne Implementierungsmandat.*

    **Quellen:**

  • Architektur statt Aktionismus: ein Praxisbeispiel zum Anrufen

    Architektur statt Aktionismus: ein Praxisbeispiel zum Anrufen

    Warum ich mein Telefon nicht ausgelagert, sondern neu gedacht habe

    Ich verpasse Anrufe. Nicht aus Desinteresse, sondern weil ich in einem Gespräch sitze, konzentriert an einer Architektur arbeite oder schlicht nicht erreichbar bin. Jeder verpasste Anruf ist eine Frage, die unbeantwortet bleibt – und manchmal ein Gespräch, das nie zustande kommt.

    Die naheliegende Lösung wäre ein Telefonservice oder eines der neuen KI-Telefonprodukte gewesen. Stattdessen habe ich mich gefragt: *Was würde es eigentlich bedeuten, so etwas selbst zu bauen – sauber, datenschutzkonform, in meiner eigenen Hand?*

    Das ist keine Bastelei aus Langeweile. Es ist die Frage, die ich auch meinen Kunden stelle: nicht „welches Tool kaufen wir“, sondern „was genau wollen wir
    erreichen, und welche Architektur trägt das“.

    Was entstanden ist

    „Felix“ nimmt jetzt meine Anrufe entgegen. Er begrüßt den Anrufer in meinem Namen, versteht das Anliegen, ordnet es ein, nimmt bei Bedarf eine Nachricht oder eine Sprachnachricht auf und stellt wichtige Gespräche durch. Er spricht ruhig, siezt, drängt nicht – so, wie ich selbst am Telefon auftreten würde.

    Das Entscheidende ist, *wo* er läuft: auf einem kleinen Rechner bei mir, an meinem eigenen Anschluss. Die Gespräche verlassen mein Haus nicht in eine fremde Cloud.
    Den KI-Anbieter kann ich frei wählen – auch eine europäische, DSGVO-konforme Variante. **Datenhoheit ist hier kein Marketing-Versprechen, sondern eine
    Architekturentscheidung.**

    Drei Dinge, die ich dabei gelernt habe

    1. KI ist heute zugänglicher, als die meisten denken – und unmündiger, als die
      Werbung suggeriert.
      Die Bausteine sind verfügbar. Aber ein System, das am Telefon professionell auftritt, entsteht nicht durch „KI anschalten“. Es entsteht durch viele kleine, bewusste Entscheidungen: Wann unterbricht es höflich? Wie verhindert man, dass jemand vertrauliche Interna ins Telefon diktiert? Wann ist Schweigen besser als eine schnelle, falsche Antwort?
    2. Die Technik ist selten das Problem. Die Haltung ist es.
      Mein Assistent verkauft nicht. Er hört zu, ordnet ein, führt zu *einem* sinnvollen nächsten Schritt. Genau das musste ich ihm beibringen – gegen die Tendenz solcher Systeme, geschwätzig und gefällig zu sein. Eine KI ist immer auch ein Spiegel der Haltung, mit der man sie baut.
    3. Datenschutz ist eine Designfrage, kein Nachgedanke.
      Wer ihn erst am Ende „dazupackt“, hat die Architektur schon falsch aufgesetzt. Wer ihn an den Anfang stellt – eigene Hardware, eigene Schlüssel, klare Löschregeln – bekommt ihn fast geschenkt.

    Was das für Sie bedeutet

    Sie müssen kein Telefonsystem bauen. Aber die Fragen dahinter stellen sich in jedem KMU, das gerade über KI nachdenkt:

    • – Kaufen wir ein Werkzeug – oder verstehen wir zuerst, was wir erreichen wollen?
    • – Wo liegen unsere Daten, und wer hat darauf Zugriff?
    • – Behalten wir die Kontrolle über das, was im Namen unseres Unternehmens spricht?

    Das ist der Kern dessen, wofür ich stehe: **Architektur statt Aktionismus.** Nicht dem nächsten Hype hinterherlaufen, sondern erst durchdenken, dann handeln. Felix ist für mich der lebende Beweis, dass das funktioniert – im Kleinen genauso wie in großen Digitalisierungsvorhaben.

    Ein nächster Schritt

    Wenn Sie gerade vor einer KI- oder Digitalisierungsentscheidung stehen und sie einmal in Ruhe einordnen wollen: In einem kurzen Erstgespräch (20 Minuten, unverbindlich) klären wir, worum es bei Ihnen eigentlich geht – ohne Sales-Pitch, mit einer ehrlichen Einschätzung.

    Und wenn Sie demnächst bei mir anrufen: Sagen Sie Felix ruhig Guten Tag.

  • Der KI-Omnibus nimmt die Pflicht raus. Nicht das Risiko!

    Der KI-Omnibus nimmt die Pflicht raus. Nicht das Risiko!

    Der KI-Omnibus nimmt formal Druck aus der KI-Kompetenzpflicht, ändert aber nichts daran, dass Unternehmen ohne saubere Schulung ein reales Risiko fahren – rechtlich und operativ. Die Frage verschiebt sich von „Sind wir verpflichtet?“ zu „Können wir es uns leisten, es nicht zu tun?“.

    Was steckt hinter dem KI-Omnibus?

    Der „Digital Omnibus on AI“ ist ein Änderungsvorschlag der EU-Kommission zur bestehenden KI-Verordnung (EU AI Act). Ziel: Regeln vereinfachen, Bürokratie reduzieren und vor allem KMU entlasten – ohne den risikobasierten Schutzansatz über Bord zu werfen.

    Der Omnibus ist Teil einer größeren Wettbewerbs- und Entbürokratisierungsstrategie der EU. Im Kern geht es darum, KI-Regulierung praxistauglicher zu machen: weg von theoretisch perfekten, aber schwer umsetzbaren Vorgaben, hin zu Vorgaben, die Unternehmen mit vertretbarem Aufwand erfüllen können.

    Die zentralen Änderungen im Überblick

    1. KI-Kompetenzpflicht wird zur Empfehlung

    Bislang verpflichtet Artikel 4 der KI-Verordnung Anbieter und Betreiber, sicherzustellen, dass ihr Personal über angemessene KI-Kompetenz verfügt. Formal war das schon eher als Appell formuliert und nicht bußgeldbewehrt, aber klar als Arbeitgeberpflicht adressiert.

    Der KI-Omnibus dreht hier weiter runter: Aus der Pflicht soll eine Empfehlung werden. Die Verantwortung, KI-Kompetenz in der Breite zu fördern, rückt stärker zur öffentlichen Hand – also zu Mitgliedstaaten und EU, etwa über Programme, Leitfäden und Bildungsinitiativen.

    Für Arbeitgeber heißt das: weniger ausdrücklicher Regulierungsdruck. Aber die Verantwortung verschwindet nicht. Wer produktiv KI einsetzt, ohne die Leute zu befähigen, schafft sich an anderer Stelle ein Haftungs- und Qualitätsproblem.

    2. Längere Übergangsfristen

    Der Omnibus sieht verlängerte Übergangsfristen für wesentliche Compliance-Pflichten vor, insbesondere für:

    • Hochrisiko-KI-Systeme

    • General Purpose AI (GPAI), also Modelle mit allgemeinem Verwendungszweck

    Unternehmen sollen mehr Luft bekommen, um Dokumentation, Risikoanalysen, technische Anpassungen und Governance-Strukturen aufzubauen. Das ist relevant, wenn KI nicht nur als Pilot läuft, sondern tief in Prozesse, Produkte oder Personalentscheidungen hineinreicht.

    3. Erleichterungen für Mittelstand und „Small Mid-Caps“

    Ein klarer Schwerpunkt liegt auf Entlastungen für kleinere Unternehmen und „Small Mid-Caps“ (bis 750 Mitarbeitende oder 150 Mio. Euro Umsatz). Vorgesehen sind unter anderem:

    • vereinfachte Konformitätsbewertungen in bestimmten Konstellationen

    • reduzierte Dokumentationsanforderungen

    • teilweise abgesenkte Bußgelder

    Die Botschaft: KI-Regulierung soll Mittelständler nicht davon abhalten, sinnvolle KI-Anwendungen überhaupt anzugehen. Gleichzeitig: Hochrisiko-Anwendungen bleiben reguliert, nur der Weg dahin wird pragmatischer.

    4. Governance, Hochrisiko-KI und Sandboxes

    Auch an der Governance-Struktur wird gedreht. Rolle und Zuständigkeiten des EU AI Office und das Zusammenspiel mit nationalen Aufsichtsbehörden sollen geschärft werden. Ziel: weniger Flickenteppich, mehr einheitliche Anwendung der KI-Verordnung in der EU.

    Für Hochrisiko-KI sollen Anforderungen praxistauglicher werden, etwa bei Risikobewertung und technischer Dokumentation. Statt pauschalem Maximalanspruch geht es stärker um reale Risikosituationen.

    Parallel stärkt der Omnibus regulatorische Sandboxes. Unternehmen können KI-Anwendungen in einem kontrollierten Rahmen testen, bevor die volle Regulierung greift. Das ist für Organisationen interessant, die ernsthaft experimentieren wollen, ohne im Blindflug unterwegs zu sein.

    Wo steht das Gesetzgebungsverfahren?

    Der KI-Omnibus ist aktuell noch ein Vorschlag, aber weit fortgeschritten. Seit April 2026 läuft der Trilog zwischen Kommission, Rat und Parlament, eine politische Einigung im Frühsommer 2026 ist realistisch. Erfahrungsgemäß folgt die formale Annahme und Veröffentlichung dann innerhalb weniger Wochen.

    Wichtig: Bis zur endgültigen Verabschiedung gilt die bestehende Rechtslage. Artikel 4 der KI-Verordnung bleibt also in Kraft. Unternehmen unterliegen weiterhin der Pflicht, KI-Kompetenz sicherzustellen – auch wenn diese Pflicht schon jetzt eher weich ausgestaltet ist.

    Was bedeutet das für Arbeitgeber?

    Die geplante Umwandlung der KI-Kompetenzpflicht in eine Empfehlung klingt nach Entlastung. In der Praxis sollte sie aber kein Argument sein, Schulungen einzusparen oder Projekte auf „Selbststudium“ umzustellen.

    Drei Punkte sind entscheidend:

    1. Haftung hört nicht auf, nur weil die Regulierung weicher wird.
      Wenn ungeschulte Mitarbeitende KI-Systeme falsch nutzen und dadurch Schäden entstehen, steht schnell die Frage im Raum, ob die Organisation ihre Sorgfaltspflichten erfüllt hat. Die KI-Verordnung ist dann nur ein Baustein in der Bewertung – Arbeitsrecht, Zivilrecht und interne Compliance spielen genauso mit hinein.

    2. Ohne Kompetenz wird KI ineffizient oder gefährlich eingesetzt.
      Mitarbeitende, die Funktionsweise, Grenzen und Risiken von KI nicht verstehen, neigen entweder zu blindem Vertrauen („die KI wird schon recht haben“) oder zu genereller Ablehnung. Beides ist schlecht: Entweder entstehen Qualitäts- und Sicherheitsprobleme, oder die Investition in KI verpufft.

    3. KI-Kompetenz ist ein Wettbewerbsfaktor, keine Strafmaß-Vermeidungsmaßnahme.
      Unternehmen, die ihr Personal strukturiert qualifizieren, integrieren KI schneller, stabiler und nachvollziehbarer. Sie können Kunden, Aufsichtsbehörden und Mitarbeitenden erklären, was das System tut – und warum. Das ist in vielen Branchen längst ein Differenzierungsmerkmal.

    Kein Freibrief, sondern ein Stresstest für Governance

    Der KI-Omnibus markiert einen Kurswechsel: weg von der Idee, KI-Kompetenz über harte Pflichten zu erzwingen, hin zu mehr Eigenverantwortung und staatlicher Förderung. Für Arbeitgeber ist das bequem – und gleichzeitig ein Stresstest.

    Wer KI heute ernsthaft einsetzt, sollte bestehende Schulungskonzepte, KI-Governance-Strukturen und Richtlinien nicht abbauen, sondern konsolidieren und gezielt weiterentwickeln. Der regulatorische Druck mag nachlassen. Die Verantwortung für sauberes, nachvollziehbares und sicheres Handeln bleibt bei dir.

    Wenn du magst, können wir daraus im nächsten Schritt eine sehr konkrete 1‑Seiten-KI-Schulungsroadmap für deine Kunden bauen – eher für KMU oder für größere Organisationen mit mehreren Standorten?

  • DSVGO-konforme KI ist kein Häkchen. Sondern Architektur.

    DSVGO-konforme KI ist kein Häkchen. Sondern Architektur.

    DSGVO-konforme KI heißt nicht: ein Häkchen im Tool setzen und fertig. Sie heißt: KI so in Ihre Prozesse einbauen, dass Rechte von Menschen, Geschäftsrisiken und regulatorische Pflichten sauber zusammenspielen – von der Datenerfassung bis zur Auswertung.

    Was bedeutet DSGVO-Konformität bei KI konkret?

    Sobald eine KI personenbezogene Daten verarbeitet – Namen, E-Mails, Logdaten, Nutzungsprofile, Chat-Inhalte – gilt die DSGVO mit allen Grundsätzen und Pflichten. KI ist kein Sonderrecht, sondern ein weiterer Verarbeitungsvorgang, der auf eine Rechtsgrundlage gestützt sein muss, etwa Vertragserfüllung, rechtliche Pflicht, Einwilligung oder berechtigtes Interesse nach Art. 6 DSGVO.

    Unternehmen bleiben Verantwortliche, auch wenn sie externe KI-Anbieter nutzen oder Cloudmodelle einbinden. Sie müssen also nachweisen können, dass sie Datenschutzgrundsätze einhalten, Betroffenenrechte ermöglichen und geeignete technische und organisatorische Maßnahmen getroffen haben.

    Wird KI für Profiling oder automatisierte Entscheidungen mit erheblichen Auswirkungen eingesetzt – etwa Scoring, Risikobewertungen oder Personaleinsatzplanung – kommen zusätzliche Anforderungen wie Informationspflichten zur Logik und zu den Auswirkungen der Entscheidungen dazu.

    Zentrale Datenschutzgrundsätze für KI

    Die DSGVO liefert kein eigenes KI-Kapitel, aber ihre Grundprinzipien passen sehr gut auf KI-Systeme.

    • Rechtmäßigkeit und Zweckbindung
      Vor jedem KI-Einsatz braucht es einen klar definierten Zweck: Wofür genau sollen die Daten genutzt werden (z. B. Support-Automatisierung, Fraud Detection, Wartungsprognosen)? Daraus leiten Sie die Rechtsgrundlage ab und begrenzen die Verarbeitung auf diesen Zweck.

    • Datensparsamkeit und Speicherbegrenzung
      KI „lebt“ von Daten, aber DSGVO-konform heißt: nur so viele Daten wie nötig und nur so lange wie nötig. Für Trainingsdaten, Logs und Prompt-Historien braucht es klare Löschkonzepte und Pseudonymisierung, wo immer möglich.

    • Transparenz und Fairness
      Betroffene müssen verstehen können, dass und wie KI eingesetzt wird, welche Daten verwendet werden und welche Folgen das hat. Gerade bei automatisierten Entscheidungen sind Aussagen zur involvierten Logik und zu möglichen Auswirkungen Pflicht.

    • Integrität, Vertraulichkeit und Sicherheit
      KI-Systeme müssen gegen unbefugten Zugriff, Datenlecks und Manipulation geschützt sein. Das umfasst Verschlüsselung, Zugriffskonzepte, Monitoring und regelmäßig geprüfte technische und organisatorische Maßnahmen.

    • Privacy by Design und by Default
      Datenschutz muss ins Modell und in die Architektur eingebaut werden, nicht im Nachhinein daraufgeklebt werden. Voreinstellungen sollten datenschutzfreundlich sein: minimale Datensammlung, deaktivierte unnötige Trackingfunktionen, strenge Rollen- und Berechtigungsmodelle.

    Typische Herausforderungen für Unternehmen

    In der Praxis scheitert DSGVO-konforme KI selten an der Theorie, sondern an Strukturen und Verantwortung.

    • Intransparente „Black-Box“-Modelle
      Viele Unternehmen wissen nicht genau, welche Daten der Anbieter wofür verarbeitet, wo sie gespeichert werden und ob sie zu Trainingszwecken weiterverwendet werden. Ohne diese Infos wird jede Datenschutz-Folgenabschätzung zur Glaskugelübung.

    • Unklare Rollen: Verantwortlicher vs. Auftragsverarbeiter
      Je nach KI-Szenario ist der Hersteller reiner Auftragsverarbeiter oder teilweise eigener Verantwortlicher. Das muss vertraglich sauber geklärt sein, inklusive Auftragsverarbeitungsvertrag und Unterauftragsnehmern.

    • Datenminimierung vs. Modellqualität
      Technische Teams möchten viele Daten, um Modelle zu verbessern. Datenschutz verlangt Beschränkung und klare Löschregeln. Dieser Zielkonflikt braucht Governance: jemand entscheidet bewusst, welche Daten wirklich nötig sind.

    • DSFA-Pflicht und fehlende Informationen
      Bei vielen KI-Anwendungen ist eine Datenschutz-Folgenabschätzung (DSFA) zwingend, etwa bei umfangreicher Profilbildung oder Bewertung persönlicher Aspekte. Die Aufsichtsbehörden betonen, dass Verantwortliche dafür auf fundierte Informationen der Anbieter angewiesen sind – die oft nicht vollständig vorliegen.

    • Umgang mit Betroffenenrechten
      Auskunft, Löschung oder Widerspruch in komplexen KI-Architekturen technisch sauber umzusetzen, ist anspruchsvoll, vor allem wenn Trainingsdaten, Logs und Backups im Spiel sind.

    EU AI Act als ergänzender Rechtsrahmen

    Der EU AI Act ergänzt die DSGVO, ersetzt sie aber nicht. Während die DSGVO den Schutz personenbezogener Daten regelt, adressiert der AI Act Risiken von KI insgesamt: Sicherheit, Diskriminierung, Transparenz und menschliche Aufsicht.

    Unternehmen müssen KI-Systeme nach Risikokategorien einordnen: von verbotenen Praktiken bis hin zu Hochrisiko-KI mit strengen Pflichten, etwa Dokumentation, Risikoanalysen, Qualität des Trainingsdatensatzes, Human Oversight und Konformitätsbewertung. Für viele Organisationen bedeutet das: Inventarisierung aller KI-Systeme, Risikoanalyse und regelmäßige Überprüfung werden Pflicht.

    Datenschutz und AI Act greifen ineinander: Hochrisiko-KI muss nicht nur DSGVO-konform sein, sondern auch AI-Act-Anforderungen wie Transparenzberichte, CE-Kennzeichnung und technische Dokumentation erfüllen. Für Sie als Verantwortlichen ergibt sich daraus ein gemeinsamer Governance-Rahmen statt zwei getrennte Baustellen.

    Konkrete Handlungsempfehlungen für Unternehmen

    Statt über „KI-Strategie“ abstrakt zu diskutieren, hilft eine nüchterne Architekturperspektive. Ein mögliches Vorgehen:

    1. KI-Landkarte erstellen
      Erfassen Sie alle KI-Anwendungen im Unternehmen: eingesetzte Tools, Schnittstellen, Datentypen, Zwecke und beteiligte Dienstleister. Diese Transparenz ist Basis für jede Risikobewertung.

    2. Zwecke und Rechtsgrundlagen pro Use Case festlegen
      Für jede Anwendung klar definieren: Zweck, betroffene Personengruppen, Datenarten, Rechtsgrundlage und geplante Speicherdauer. Alles, was sich nicht sauber begründen lässt, wird entweder angepasst oder gestrichen.

    3. Datenschutz-Folgenabschätzung dort, wo das Risiko hoch ist
      Prüfen Sie systematisch, ob für einen Use Case eine DSFA erforderlich ist – bei Profiling, Scoring oder sensiblen Daten ist das oft der Fall. Grundlage sind strukturierte Infos vom Anbieter zur Funktionsweise und zu den Risiken des Systems.

    4. Verträge und TOM mit Anbietern aktualisieren
      Schließen oder aktualisieren Sie Auftragsverarbeitungsverträge, klären Sie Unterauftragsverarbeiter, Datenübermittlungen in Drittländer und dokumentieren Sie technische und organisatorische Maßnahmen. Prüfen Sie, ob der Anbieter Optionen für Privacy by Design und by Default bietet.

    5. Technische Architektur auf Datenschutz ausrichten

      • Pseudonymisierung und Anonymisierung, wo immer möglich

      • Strenge Rollen- und Rechtekonzepte für KI-Tools

      • Trennung von Produktivdaten und Trainingsdaten, definierte Löschpfade

      • Logging und Monitoring, um Zugriffe und Anomalien nachhalten zu können

    6. Transparenz- und Informationskonzepte bauen
      Passen Sie Datenschutzhinweise, interne Richtlinien und Informationsblätter an, damit Betroffene verstehen, welche KI eingesetzt wird und welche Auswirkungen das hat. Stellen Sie intern Vorlagen bereit, wie automatisierte Entscheidungen erklärt werden können.

    7. Kompetenz im Unternehmen aufbauen
      KI- und Datenschutzkompetenz lassen sich nicht vollständig outsourcen. Der AI Act verlangt, dass Mitarbeitende, die mit KI-Systemen arbeiten, angemessen geschult sind. Dazu gehören Grundlagen zu DSGVO, zu Risiken von KI sowie zur praktischen Nutzung der eingesetzten Systeme.

    8. Governance etablieren statt Einzelfallreaktion
      Richten Sie ein kleines, verbindliches Gremium ein (IT, Fachbereich, Datenschutz, ggf. Legal), das neue KI-Use-Cases prüft, Risiken bewertet und Freigaben dokumentiert. So entsteht ein wiederholbares Muster statt Einzellösungen.

  • EU AI Act: Auch wenn Sie nur ChatGPT nutzen.

    EU AI Act: Auch wenn Sie nur ChatGPT nutzen.

    „Wir nutzen doch nur ChatGPT.“ Diesen Satz höre ich oft. Er klingt harmlos — und er ist es meistens auch. Aber er ist kein Freifahrtschein. Der EU AI Act unterscheidet nicht danach, ob ein Unternehmen KI entwickelt oder nur nutzt. Er unterscheidet nach Risikoklasse, Anwendungsfall und Konsequenz.

    Das Gute: Die meisten KMU fallen nicht in die Hochrisiko-Kategorie. Das Schlechte: Dokumentations- und Governance-Pflichten treffen fast jeden — und werden regelmäßig unterschätzt.

    Was das konkret bedeutet und was jetzt zu tun ist, kläre ich hier.

    Vier Risikoklassen — eine kurze Einordnung

    Der AI Act teilt KI-Systeme in vier Klassen ein. Die Klasse bestimmt, welche Pflichten gelten.

    Verbotene KI

    Systeme, die grundlegende Rechte verletzen: Social Scoring durch Behörden, biometrische Massenüberwachung in Echtzeit, manipulative KI ohne Bewusstsein der Betroffenen. Für KMU in der Praxis kaum relevant — aber wichtig zu kennen.

    Hochrisiko-KI

    Systeme in sensiblen Bereichen: Personalentscheidungen, Kreditwürdigkeit, kritische Infrastruktur, Bildung, Strafverfolgung. Hier gelten strenge Anforderungen: Konformitätsbewertung, Transparenzpflichten, menschliche Aufsicht, umfangreiche Dokumentation.

    Begrenzt riskante KI

    Chatbots, generative Systeme, Deepfakes. Die Kernpflicht: Transparenz. Nutzer müssen wissen, dass sie mit KI interagieren.

    Minimales Risiko

    Spam-Filter, KI-basierte Produktempfehlungen, einfache Automatisierungen. Keine besonderen Pflichten — aber auch hier gilt: wer es einsetzt, sollte es dokumentiert haben.

    Welche KMU-Anwendungen fallen in welche Klasse?

    Abstrakte Kategorien helfen wenig. Konkrete Beispiele helfen mehr.

    HR-Screening mit KI-Unterstützung → Hochrisiko

    Wer KI nutzt, um Bewerbungen vorzuselektieren, Eignung zu bewerten oder Kündigungsentscheidungen vorzubereiten, fällt unter die Hochrisiko-Kategorie. Das gilt auch dann, wenn ein Mensch die finale Entscheidung trifft — solange das System die Entscheidungsgrundlage beeinflusst. Konsequenz: Konformitätsbewertung, Bias-Prüfung, vollständige Dokumentation des Systems.

    Kundenservice-Bot → begrenzt riskant

    Ein Chat-Assistent auf der Website, der Anfragen beantwortet oder weiterleitet, fällt in die begrenzte Risikoklasse. Die zentrale Pflicht: Nutzer müssen erkennen können, dass sie mit einer KI kommunizieren. Ein diskreter Hinweis „Dieser Chat wird durch KI unterstützt“ reicht in den meisten Fällen aus.

    Interne Wissensbasis mit KI-Suche → minimales Risiko

    Ein internes Tool, das Dokumente durchsucht und Zusammenfassungen liefert, ist in der Regel minimal riskant. Keine besonderen Pflichten — aber eine kurze interne Dokumentation darüber, was das System tut, welche Daten es nutzt und wer dafür zuständig ist, ist trotzdem sinnvoll.

    Die entscheidende Frage ist immer: Trifft oder beeinflusst das System Entscheidungen, die Menschen direkt betreffen? Je mehr das zutrifft, desto höher die Risikoklasse.

    Fristen 2025–2027: Was wann gilt

    Februar 2025
    Verbote gelten. Verbotene KI-Praktiken sind seit dem 2. Februar 2025 unzulässig. Wer Social Scoring, manipulative KI oder unzulässige biometrische Kategorisierung einsetzt, muss das sofort beenden.
    August 2025
    GPAI-Regeln und Governance. Anforderungen an Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (General Purpose AI) greifen. Unternehmen, die solche Modelle in eigene Produkte integrieren, müssen Transparenz- und Dokumentationspflichten erfüllen.
    August 2026
    Hochrisiko-Pflichten für neue Systeme. Neu eingesetzte Hochrisiko-KI-Systeme unterliegen ab diesem Datum dem vollständigen Anforderungsrahmen: Konformitätsbewertung, Risikomanagement, technische Dokumentation, menschliche Aufsicht.
    August 2027
    Vollständige Geltung auch für Bestandssysteme. Hochrisiko-Systeme, die bereits vor August 2026 im Einsatz waren, müssen bis dahin vollständig compliant sein. Kein Bestandsschutz mehr.

    2026 ist also das Jahr, in dem die Uhr für viele KMU wirklich zu ticken beginnt. Wer jetzt anfängt, hat noch genug Zeit für einen strukturierten Ansatz. Wer wartet, macht Compliance zur Feuerwehrübung.

    Die 5 Pflichten, die fast jedes KMU betreffen

    Selbst wenn das eigene Unternehmen keine Hochrisiko-KI einsetzt: Diese fünf Anforderungen gelten für nahezu alle, die KI geschäftlich nutzen.

    1. Transparenz

    Nutzer müssen wissen, wenn sie mit KI interagieren. Das gilt für Chatbots genauso wie für KI-generierte Inhalte. Keine versteckte Automatisierung, keine KI, die vorgibt, ein Mensch zu sein.

    2. Dokumentation

    Welche KI-Systeme werden eingesetzt? Zu welchem Zweck? Wer ist verantwortlich? Welche Daten werden verarbeitet? Das muss schriftlich vorliegen — nicht ausformuliert in einem 50-seitigen Bericht, aber nachvollziehbar und abrufbar.

    3. Kompetenznachweis

    Der AI Act fordert, dass Mitarbeiter, die KI-Systeme einsetzen, ein grundlegendes Verständnis davon haben, was das System tut und was es nicht tut. KI-Literacy ist keine Kür mehr — sie ist Pflicht. Das gilt besonders für Führungskräfte, die Entscheidungen auf Basis von KI-Ausgaben treffen.

    4. Risikobewertung

    Bevor ein KI-System produktiv genutzt wird, braucht es eine Einschätzung: Welche Risiken entstehen durch den Einsatz? Was passiert, wenn das System falsch liegt? Wer kontrolliert das? Für Nicht-Hochrisiko-Systeme reicht eine schlichte, aber ehrliche Einschätzung. Für Hochrisiko-Systeme ist ein formales Risikomanagementsystem Pflicht.

    5. Menschliche Aufsicht

    KI darf nicht unkontrolliert entscheiden. Für Systeme, die Konsequenzen für Menschen haben, muss klar geregelt sein, wer eingreift, wann eingegriffen wird und wie Entscheidungen übersteuert werden können. Das ist kein bürokratischer Zusatz — das ist gesunder Menschenverstand in Verfahren gegossen.

    Schnittstelle zu DSGVO und NIS-2: Doppelarbeit vermeiden

    Wer die DSGVO bereits ernst nimmt, hat einen Vorsprung. Viele Anforderungen des AI Act überschneiden sich mit bestehenden Datenschutzpflichten — und das lässt sich gezielt nutzen.

    DSGVO und AI Act: Datenschutz-Folgenabschätzungen (DSFA) und KI-Risikobewertungen haben denselben Grundgedanken: systematisch durchdenken, was schiefgehen kann. Wer bereits DSFA-Prozesse hat, kann diese erweitern, statt von vorn zu beginnen. Besonders relevant: Transparenz- und Informationspflichten gelten in beiden Regelwerken — mit ähnlichem Inhalt, aber unterschiedlicher Rechtsgrundlage. Einmal aufsetzen, für beide nutzen. Mehr dazu im Artikel zu DSGVO-konformer KI.

    NIS-2 und AI Act: Wer KI in kritischen oder wichtigen Einrichtungen einsetzt — Energie, Gesundheit, Transport, digitale Infrastruktur — muss beide Regelwerke im Blick haben. NIS-2 fordert Sicherheitsmaßnahmen und Meldepflichten. Der AI Act ergänzt das um Anforderungen an das KI-System selbst. Überschneidungen gibt es beim Risikomanagement, bei der Dokumentation und bei der Zuständigkeitsregelung. Sauber strukturiert, lässt sich das in einem gemeinsamen Governance-Rahmen abbilden. Mehr dazu im Artikel zu NIS-2.

    Das Muster ist immer dasselbe: Wer Compliance als isolierte Aufgabe behandelt, zahlt dreimal. Wer einen gemeinsamen Rahmen aufbaut, zahlt einmal — und hat mehr davon.

    Pragmatischer Startplan in 4 Schritten

    Kein Projekt, kein Beratermarathon. Vier konkrete Schritte, die sich in den nächsten Wochen umsetzen lassen.

    Schritt 1: KI-Bestandsaufnahme (1–2 Tage)

    Welche KI-Systeme oder KI-gestützten Tools sind im Unternehmen im Einsatz — bewusst oder unbewusst? Das schließt SaaS-Produkte mit KI-Features ein: Microsoft Copilot, ChatGPT, Recruiting-Tools, CRM mit KI-Scoring. Einfach dokumentieren: Name, Zweck, eingesetzte Abteilung, Entscheidungsrelevanz.

    Schritt 2: Risikoklasse bestimmen (halber Tag)

    Für jedes identifizierte System die Frage stellen: Trifft es Entscheidungen über Menschen? In welchem Kontext? Die meisten Tools landen in begrenzt riskant oder minimal riskant. Wer unsicher ist, kann das mit unserem AI Act Kurzcheck in wenigen Minuten einordnen.

    Schritt 3: Sofortmaßnahmen für bestehende Pflichten (1 Woche)

    Transparenzhinweise für Chatbots und KI-generierte Inhalte einführen. Zuständigkeiten klären: Wer ist intern verantwortlich für welches System? Kurze Schulung oder Information der betroffenen Mitarbeiter zur KI-Literacy. Das sind keine großen Projekte — das sind Entscheidungen und kurze Texte.

    Schritt 4: Governance-Struktur aufbauen (1–4 Wochen, je nach Größe)

    Eine einfache KI-Richtlinie festlegen: Was darf eingesetzt werden, unter welchen Bedingungen, wer entscheidet darüber. Dokumentationsvorlage für neue KI-Systeme einführen. Risikobewertung in die Einführung neuer Tools integrieren — als feste Frage, nicht als Sonderprojekt.

    Wer diese vier Schritte durchgeht, hat keine perfekte Compliance — aber eine ehrliche, nachvollziehbare Grundlage. Das ist der Unterschied zwischen vorbereitet und unvorbereitet, wenn eine Aufsichtsbehörde fragt.

    📋EU AI Act Kurzcheck

    Welche Risikoklasse trifft auf Ihr KI-Projekt zu? Eine Seite, klare Fragen, sofortige Einordnung. Kein Registrierungsformular, kein Newsletter — einfach herunterladen und nutzen.

    Kurzcheck herunterladen (PDF)

    Fazit: Nicht warten auf Hochrisiko

    Die häufigste Fehleinschätzung ist diese: „Wir nutzen keine Hochrisiko-KI, also betrifft uns der AI Act kaum.“ Das stimmt nicht. Transparenz, Dokumentation, Kompetenz, Aufsicht — das sind Anforderungen, die unabhängig von der Risikoklasse gelten und die jetzt schon in Kraft sind oder in Kürze greifen.

    Die gute Nachricht: Das lässt sich strukturiert angehen. Es braucht kein großes Projekt, keinen externen Berater für alles, keine monatelange Analyse. Es braucht eine klare Bestandsaufnahme, eine ehrliche Einordnung und ein paar konkrete Entscheidungen.

    Wenn Sie das strukturiert und ohne Umwege angehen wollen, schauen wir uns das gemeinsam an. Ich helfe Ihnen, die richtigen Fragen zu stellen — und die richtigen Antworten zu dokumentieren.

    Passende Themen:

    Quellen und weiterführende Dokumente:

    Fragen zur Einordnung Ihrer KI-Systeme? Sprechen Sie mich an.