EU AI Act und Informationssicherheit: Umsetzung für Betreiber und Anbieter von KI-Systemen

Fachbeitrag von BlackMount

Fachredaktion BlackMountFachlich verantwortet von Jannik Christ · Geschäftsführer & Senior-Berater

Praxisorientierte Einordnung zu EU AI Act und Informationssicherheit: Umsetzung für Betreiber und Anbieter von KI-Systemen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für EU AI Act aufbauen.

EU AI Act und Informationssicherheit: Umsetzung für Betreiber und Anbieter von KI-Systemen – Fachbeitrag von BlackMount

Der EU AI Act wird in vielen Unternehmen noch als juristisches Spezialthema behandelt. In der Praxis entscheidet jedoch die Verbindung zur Informationssicherheit darüber, ob KI-Systeme kontrollierbar bleiben. Modelle, Trainings- und Eingabedaten, Schnittstellen, Identitäten, Protokolle und angebundene Geschäftsprozesse bilden eine Angriffsfläche. Gleichzeitig können manipulierte Ausgaben, Datenabfluss oder ein unbemerkter Modellwechsel erhebliche fachliche und rechtliche Folgen auslösen.

Für die Umsetzung ist zuerst zu klären, in welcher Rolle ein Unternehmen handelt. Der AI Act unterscheidet unter anderem Anbieter, Betreiber, Importeur und Händler. Wer ein fremdes System unter eigenem Namen anbietet, seinen vorgesehenen Zweck wesentlich verändert oder ein System substanziell modifiziert, kann vom Betreiber zum Anbieter werden. Diese Einordnung bestimmt, welche Pflichten, Nachweise und technischen Kontrollen erforderlich sind.

Warum Informationssicherheit ein Kernbestandteil der AI-Act-Umsetzung ist

Der AI Act verlangt für Hochrisiko-KI unter anderem ein Risikomanagementsystem, technische Dokumentation, Aufzeichnung, menschliche Aufsicht sowie angemessene Genauigkeit, Robustheit und Cybersicherheit. Diese Anforderungen lassen sich nicht allein durch Richtlinien erfüllen. Sie müssen sich in Architektur, Entwicklungsprozess, Berechtigungen, Überwachung, Lieferantensteuerung und Incident Management wiederfinden. Informationssicherheit liefert dafür bestehende Verfahren, muss sie aber um KI-spezifische Szenarien erweitern.

Ein klassisches ISMS betrachtet beispielsweise unberechtigten Zugriff, Ausfall und Manipulation. Bei KI kommen Risiken wie Prompt Injection, vergiftete Trainingsdaten, Model Extraction, unsichere Erweiterungen, unerwartete Autonomie und schwer erkennbare Qualitätsverschlechterung hinzu. Die fachliche Wirkung einer fehlerhaften Ausgabe ist zudem kontextabhängig: Eine ungenaue Formulierung in einem internen Entwurf ist anders zu bewerten als eine automatisierte Vorauswahl von Bewerbern oder eine sicherheitsrelevante Steuerungsentscheidung.

Mit einem belastbaren KI-Inventar beginnen

Ohne vollständigen Überblick ist keine verlässliche Klassifizierung möglich. Das Inventar sollte nicht nur offiziell beschaffte Anwendungen enthalten, sondern auch eingebettete Funktionen in SaaS-Produkten, eigene Modelle, APIs, Entwicklungsassistenten, lokale Open-Source-Modelle und automatisierte Entscheidungen in Fachprozessen. Reine Produktnamen reichen nicht, weil dieselbe Plattform je nach Konfiguration und Verwendungszweck sehr unterschiedliche Risiken erzeugen kann.

Ein sinnvoller Mindestdatensatz umfasst Eigentümer, Anbieter, Modell oder Dienst, vorgesehenen Zweck, betroffene Personen, Ein- und Ausgabedaten, Schnittstellen, Einsatzort, Grad der Automatisierung, menschliche Kontrolle, kritische Abhängigkeiten und Änderungsmechanismus. Zusätzlich sollte dokumentiert werden, ob Inhalte erzeugt, Entscheidungen vorbereitet oder Entscheidungen automatisiert getroffen werden. So wird das Inventar zur Steuerungsgrundlage und nicht zur bloßen Softwareliste.

Rollen nicht aus dem Einkaufsvertrag ableiten

Ein Unternehmen, das einen Standard-KI-Dienst intern nutzt, ist häufig Betreiber. Diese Aussage kann sich ändern, wenn das System unter eigener Marke in Verkehr gebracht, für einen anderen vorgesehenen Zweck eingesetzt oder wesentlich verändert wird. Auch die Integration eines General-Purpose-AI-Modells in eine eigene Lösung kann Anbieterpflichten für das daraus entstehende KI-System auslösen. Deshalb muss die Rollenprüfung den tatsächlichen Lebenszyklus berücksichtigen.

Für jedes relevante System sollte eine kurze Rollenbegründung festgehalten werden: Wer bestimmt den Zweck, wer entwickelt oder verändert das System, unter wessen Namen wird es angeboten und wo werden die Ergebnisse genutzt? Die Begründung benötigt einen fachlichen und einen juristischen Eigentümer. Änderungen an Zweck, Marke, Modell, Entscheidungslogik oder Zielgruppe müssen eine erneute Prüfung auslösen.

Risikoklassen und Pflichten sauber trennen

Der risikobasierte Ansatz unterscheidet verbotene Praktiken, Hochrisiko-Systeme, bestimmte Systeme mit Transparenzpflichten und sonstige KI. Ein Einsatz ist nicht allein deshalb Hochrisiko, weil seine Auswirkungen wirtschaftlich wichtig sind. Maßgeblich sind die Kriterien in Artikel 6 sowie die Bereiche in Anhang I und III. Bei Anhang-III-Fällen ist zusätzlich zu prüfen, ob eine gesetzliche Ausnahme greift; die Begründung muss nachvollziehbar dokumentiert werden.

Unabhängig von der gesetzlichen Klasse kann ein Unternehmen strengere interne Schutzanforderungen festlegen. Ein internes Wissenssystem fällt möglicherweise nicht in die Hochrisikokategorie, verarbeitet aber vertrauliche Mandanten- oder Konstruktionsdaten. Die regulatorische Klassifizierung und die Informationssicherheitsklassifizierung sollten deshalb getrennte Felder besitzen und anschließend in ein gemeinsames Kontrollprofil einfließen.

Verbotene Praktiken bereits am Intake stoppen

Bestimmte KI-Praktiken sind bereits seit Februar 2025 untersagt. Dazu zählen in den gesetzlich beschriebenen Grenzen unter anderem manipulative oder täuschende Techniken, die Ausnutzung bestimmter Schutzbedürftigkeiten, bestimmte Formen sozialen Bewertens sowie einzelne biometrische Praktiken. Eine Kontrolle erst vor dem Produktivstart kommt zu spät, wenn ein Fachbereich bereits Daten beschafft, Modelle trainiert und Verträge geschlossen hat.

Der Beschaffungs- und Entwicklungseingang benötigt daher wenige klare Ausschlussfragen. Werden Verhalten oder Entscheidungen von Personen beeinflusst? Geht es um biometrische Merkmale, Emotionserkennung, Strafverfolgung oder die Bewertung persönlicher Eigenschaften? Besteht ein Machtgefälle gegenüber Beschäftigten, Kindern oder anderen schutzbedürftigen Gruppen? Positive Antworten führen zu einer verpflichtenden Legal- und Governance-Prüfung, bevor weitere Kosten entstehen.

Anbieterpflichten in den Entwicklungslebenszyklus integrieren

Anbieter von Hochrisiko-KI müssen die Konformität ihres Systems über den Lebenszyklus sicherstellen. Dazu gehören Qualitäts- und Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierungsfunktionen, Gebrauchsanweisungen, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit, Konformitätsbewertung, Registrierung und Beobachtung nach dem Inverkehrbringen. Diese Anforderungen sollten keine parallele Compliance-Spur neben Entwicklung und Betrieb bilden.

In einem sicheren Entwicklungsprozess werden Anforderungen bereits im Design erfasst. Architekturfreigabe, Bedrohungsmodellierung, Datenprüfung, Testfälle, Modell- und Prompt-Versionierung sowie Freigabekriterien erzeugen die benötigten Nachweise. Änderungen an Daten, Modell, Systemprompt, Werkzeugzugriff oder Schutzmechanismen werden bewertet. So kann das Unternehmen erklären, welche Version mit welchen Grenzen geprüft und freigegeben wurde.

Betreiberpflichten in den Fachprozess übersetzen

Betreiber von Hochrisiko-Systemen müssen die Gebrauchsanweisung beachten, geeignete technische und organisatorische Maßnahmen treffen, menschliche Aufsicht zuweisen und den Betrieb überwachen. Wenn sie Eingabedaten kontrollieren, müssen diese für den vorgesehenen Zweck relevant und hinreichend repräsentativ sein. Protokolle sind innerhalb der gesetzlichen Vorgaben aufzubewahren, und bei erkannten Risiken oder schwerwiegenden Vorfällen bestehen Informations- und Reaktionspflichten.

Diese Anforderungen gehören in die Arbeitsanweisung des betroffenen Prozesses. Dort wird festgelegt, wer eine Ausgabe prüft, wann sie verworfen werden muss, welche Fälle eskalieren und welches Ersatzverfahren bei Ausfall gilt. Eine Person ist nur dann wirksame menschliche Aufsicht, wenn sie Systemgrenzen versteht, ausreichend Zeit besitzt und eine Entscheidung tatsächlich stoppen oder übersteuern darf.

Bedrohungsmodellierung für KI konkretisieren

Die Analyse beginnt bei schützenswerten Zielen: Modell, Trainings- und Retrieval-Daten, Systemprompts, Zugangsdaten, Ausgaben, Protokolle und verbundene Werkzeuge. Danach werden Vertrauensgrenzen und mögliche Angreifer betrachtet. Externe Nutzer, kompromittierte Datenquellen, bösartige Dokumente, Insider, Dienstleister und automatisierte Agenten besitzen unterschiedliche Fähigkeiten und Zugriffswege.

Ein konkretes Szenario lautet beispielsweise: Ein präpariertes Dokument im Wissensspeicher enthält versteckte Anweisungen, die ein Sprachmodell dazu bringen, interne Informationen über ein angebundenes Werkzeug abzurufen und in der Antwort offenzulegen. Kontrollen umfassen getrennte Berechtigungen, Inhaltsbehandlung, sichere Tool-Freigaben, Ausgabefilter, Protokollierung und Tests mit Angriffsmustern. Die Kombination ist entscheidend, weil ein einzelner Prompt-Filter keine belastbare Sicherheitsgrenze darstellt.

Daten-Governance mit Sicherheitskontrollen verbinden

Für Hochrisiko-KI stellt der AI Act Anforderungen an Trainings-, Validierungs- und Testdaten. Aus Sicherheitssicht muss zusätzlich bekannt sein, woher Daten stammen, wer sie verändern darf und wie Manipulation erkannt wird. Herkunftsnachweis, Prüfsummen, Versionsverwaltung, Vier-Augen-Freigaben und getrennte Umgebungen helfen, unbemerkte Änderungen zu verhindern.

Bei Retrieval-Systemen liegt das Risiko häufig nicht im Basismodell, sondern im Dokumentbestand. Veraltete, falsch berechtigte oder gezielt präparierte Inhalte beeinflussen die Ausgabe. Deshalb benötigen Datenquellen Eigentümer, Klassifizierung, Lösch- und Aktualisierungsregeln sowie eine Zugriffsprüfung, die bis in die Antwortkette wirksam bleibt. Das Modell darf nicht über seinen technischen Dienstaccount Berechtigungen umgehen, die für den fragenden Nutzer gelten.

Technische Dokumentation als Systemakte aufbauen

Eine belastbare Systemakte erklärt Zweck, Architektur, Modell- und Datenherkunft, Leistungsgrenzen, Prüfmethoden, Risikokontrollen, Schnittstellen, menschliche Aufsicht und Betriebsbedingungen. Sie sollte auf konkrete Artefakte verweisen, statt dieselben Informationen in mehreren Dokumenten zu duplizieren. Architekturdiagramm, Modellkarte, Datenblatt, Testbericht, Risikoregister und Freigabeprotokoll können gemeinsam die technische Dokumentation bilden.

Entscheidend ist die Aktualität. Ein einmal erstelltes Dokument verliert seinen Wert, wenn der Cloudanbieter das Modell austauscht oder der Fachbereich einen neuen Datenbestand anschließt. Änderungsereignisse aus Entwicklung, Einkauf und Betrieb müssen deshalb die Systemakte aktualisieren. Ein automatisierter Vergleich von Modellversionen, Konfiguration und Schnittstellen kann Hinweise liefern, ersetzt aber nicht die fachliche Bewertung wesentlicher Änderungen.

Protokollierung mit einem klaren Untersuchungszweck planen

Logs müssen eine spätere Untersuchung ermöglichen, ohne unnötig personenbezogene oder vertrauliche Inhalte zu vervielfältigen. Relevante Metadaten sind System- und Modellversion, Zeitpunkt, Nutzer- oder Prozesskennung, aktivierte Werkzeuge, Sicherheitsentscheidungen, Freigaben, Fehler und Ergebnisstatus. Ob Prompts und vollständige Ausgaben gespeichert werden dürfen oder müssen, ist anhand von Zweck, Datenschutz und Schutzbedarf gesondert zu entscheiden.

Aufbewahrung, Zugriff und Manipulationsschutz gehören zum Konzept. Sicherheitsbetrieb, Fachverantwortliche und Datenschutz benötigen unterschiedliche Sichten. Alarmregeln sollten ungewöhnliche Datenmengen, wiederholte Schutzverletzungen, neue Werkzeugaufrufe, starke Qualitätsabweichungen und Nutzung außerhalb des vorgesehenen Zwecks erkennen. Ohne vorher definierte Schwellen entsteht zwar viel Telemetrie, aber keine belastbare Überwachung.

Robustheit nicht mit durchschnittlicher Modellqualität verwechseln

Ein hoher Mittelwert im Testdatensatz sagt wenig über seltene, aber folgenschwere Fehler aus. Tests müssen die vorgesehenen Betriebsbedingungen, Grenzfälle, missbräuchliche Eingaben und Störungen abdecken. Für ein System zur Dokumentenklassifizierung sind etwa ungewöhnliche Dateiformate, beschädigte Dateien, Sprachwechsel, adversariale Inhalte und der Ausfall externer Dienste relevant.

Akzeptanzkriterien sollten nach Risikoklasse des Ergebnisses unterscheiden. Bei sicherheitsrelevanten Entscheidungen kann eine niedrige Fehlerrate dennoch inakzeptabel sein, wenn bestimmte Fallgruppen systematisch betroffen sind. Neben Genauigkeit werden Stabilität über Versionen, Ablehnungsverhalten, Wiederherstellbarkeit und Wirksamkeit der menschlichen Kontrolle geprüft. Ergebnisse fließen in Freigabe und Monitoring ein.

Lieferanten und General-Purpose-AI-Modelle beherrschen

Viele Unternehmen entwickeln kein Basismodell, sondern beziehen Modelle, Plattformen oder fertige Funktionen. Sie bleiben dennoch für ihre eigene Rolle und Integration verantwortlich. Benötigt werden Informationen zu Modellversionen, Nutzungsbedingungen, Datenverarbeitung, Sicherheitsmaßnahmen, bekannten Grenzen, Unterauftragnehmern, Vorfällen und Änderungen. Bei kritischen Einsätzen müssen Verträge rechtzeitige Information und angemessene Unterstützung ermöglichen.

Besonders wichtig ist die Frage, ob Eingaben für Training oder Produktverbesserung genutzt werden, in welchen Regionen Daten verarbeitet werden und welche Administrationszugriffe bestehen. Technische Einstellungen müssen mit den vertraglichen Zusagen übereinstimmen. Ein sicherer Enterprise-Tarif hilft wenig, wenn Teams private Konten oder unkontrollierte API-Schlüssel verwenden. Beschaffung, Identitätsmanagement und Cloud-Governance müssen deshalb zusammenspielen.

Incident Management um KI-Szenarien erweitern

Ein KI-Vorfall kann ein klassischer Sicherheitsvorfall, eine erhebliche Fehlfunktion, eine Verletzung von Grundrechten oder eine Kombination daraus sein. Beispiele sind Datenabfluss über Eingaben, kompromittierte Modellartefakte, systematisch diskriminierende Ausgaben, unautorisierte autonome Aktionen oder der Einsatz einer falschen Modellversion. Der Meldeweg darf nicht davon abhängen, ob eine Störung zuerst im SOC oder im Fachbereich auffällt.

Runbooks benötigen Kriterien für Abschaltung, Rückkehr auf eine freigegebene Version, Sperrung von Werkzeugen, Sicherung von Beweisen, Bewertung betroffener Personen und Information von Anbieter oder Behörden. Protokolle müssen früh gesichert werden, weil Cloudanbieter Aufbewahrungszeiten begrenzen können. Übungen zeigen, ob Fachbereich, Informationssicherheit, Datenschutz, Legal und Kommunikation dieselbe Lage schnell bewerten können.

Die Anwendungstermine im Jahr 2026 richtig einordnen

Verbote und die ursprünglichen Vorgaben zur KI-Kompetenz gelten bereits seit dem 2. Februar 2025; Governance-Regeln und Pflichten für General-Purpose-AI-Modelle folgten am 2. August 2025. Seit dem 2. August 2026 werden weitere Teile einschließlich bestimmter Transparenzpflichten durchsetzbar. Nach der 2026 in Kraft getretenen Anpassung gelten die Regeln für Hochrisiko-Fälle nach Anhang III ab 2. Dezember 2027 und für in regulierte Produkte eingebettete Hochrisiko-KI ab 2. August 2028.

Diese Staffelung ist kein Grund zu warten. Inventar, Rollenklärung, Vertragszugang, Datenherkunft und technische Dokumentation lassen sich nicht kurz vor einem Stichtag nachträglich rekonstruieren. Außerdem greifen Datenschutz, Informationssicherheit, Arbeitsrecht und branchenspezifische Anforderungen bereits unabhängig vom AI Act. Priorität haben aktuell verbotene Praktiken, Transparenz, GPAI-Abhängigkeiten und Systeme mit hohem fachlichem Schadenpotenzial.

Ein gemeinsames Kontrollmodell statt paralleler Programme

Bestehende Kontrollen aus ISO 27001, Datenschutz, sicherer Entwicklung, Lieferantenmanagement und Enterprise Risk Management können wiederverwendet werden. Dafür wird jede AI-Act-Anforderung auf Prozess, Kontrollziel, konkrete Kontrolle, Eigentümer, Frequenz und Nachweis gemappt. Eine allgemeine Zuordnung „durch ISMS abgedeckt“ ist zu grob, weil KI-spezifische Daten-, Qualitäts- und Aufsichtspflichten fehlen können.

Beispielsweise unterstützt das normale Schwachstellenmanagement die Cybersicherheit, prüft aber nicht automatisch Prompt Injection oder unsichere Modellwerkzeuge. Das Lieferantenmanagement bewertet möglicherweise Bonität und Zertifikate, erfasst jedoch keinen unangekündigten Modellwechsel. Das gemeinsame Kontrollmodell zeigt sowohl Wiederverwendung als auch Erweiterungsbedarf und verhindert widersprüchliche Maßnahmenlisten.

Praktischer Umsetzungsplan in sechs Arbeitspaketen

Erstens wird das KI-Inventar mit einem verbindlichen Intake-Prozess aufgebaut. Zweitens folgen Rollen- und Risikoklassifizierung einschließlich Ausschlussprüfung. Drittens werden kritische Systeme technisch und fachlich analysiert. Viertens entsteht je Klasse ein Mindestkontrollprofil. Fünftens werden Nachweise und Monitoring in Entwicklungs-, Beschaffungs- und Betriebsprozesse integriert. Sechstens prüft eine unabhängige Funktion die Wirksamkeit.

Die Roadmap priorisiert nicht nach Dokumentenmenge, sondern nach Exposition und Umsetzungszeit. Schnell realisierbare Schutzmaßnahmen wie zentrale Zugänge, Sperrung öffentlicher Konten, Protokollierung und Freigaberegeln laufen parallel zu langfristigen Aufgaben wie Vertragsänderung oder Architekturumbau. Jede Maßnahme erhält Verantwortlichen, Termin, Zielrisiko, Abnahmekriterium und benötigten Nachweis.

Beispiel: Bewerbervorauswahl mit externer KI

Ein Unternehmen nutzt eine SaaS-Lösung, die Bewerbungen bewertet und eine Rangfolge empfiehlt. Der Einsatz liegt in einem sensiblen Beschäftigungskontext und verlangt eine sorgfältige Hochrisikoprüfung. Das Unternehmen dokumentiert seine Betreiberrolle, prüft Anweisungen und Konformitätsinformationen des Anbieters, informiert die erforderlichen Beteiligten und weist eine qualifizierte menschliche Aufsicht zu.

Sicherheitstechnisch werden Single Sign-on, minimale Rollen, geschützte Datenübertragung, Protokolle und ein geregelter Export eingerichtet. Die Personalabteilung darf Rankings nicht ungeprüft übernehmen. Stichproben untersuchen Qualitätsabweichungen und systematische Benachteiligung; Beschwerden und Vorfälle besitzen einen klaren Eskalationsweg. Ein manueller Prozess bleibt verfügbar, falls das System gesperrt oder unzuverlässig ist.

Beispiel: Interner Assistent für vertrauliche Technikdokumente

Ein Entwicklungsunternehmen verbindet ein Sprachmodell mit internen Spezifikationen. Der Anwendungsfall ist möglicherweise keine Hochrisiko-KI im Sinne des AI Act, besitzt aber hohen Schutzbedarf. Das Unternehmen klassifiziert ihn daher intern als kritisch. Dokumente bleiben in getrennten Wissensräumen, Nutzerberechtigungen werden bei jeder Abfrage durchgesetzt und das Modell erhält keinen pauschalen Zugriff auf sämtliche Projekte.

Vor dem Start werden Prompt-Injection, Datenabfluss, fehlerhafte Quellenangaben und unzulässige Werkzeugaufrufe getestet. Antworten zeigen ihre Quellen und tragen einen Hinweis auf die notwendige fachliche Prüfung. Modell- oder Konfigurationswechsel lösen Regressionstests aus. Das Beispiel zeigt, warum gesetzliche Risikoklasse und unternehmerisches Sicherheitsrisiko gemeinsam, aber nicht identisch gesteuert werden müssen.

Woran eine wirksame Umsetzung erkennbar ist

Gute Kennzahlen beschreiben Steuerungsfähigkeit: Anteil klassifizierter Systeme, Zeit bis zur Rollenentscheidung, Abdeckung kritischer Systeme durch Bedrohungsmodelle, offene Hochrisiko-Feststellungen, ungeprüfte Modelländerungen, Wirksamkeit menschlicher Aufsicht und Zeit bis zur Vorfallbewertung. Reine Zahlen zu Schulungen oder ausgefüllten Formularen zeigen dagegen kaum, ob Risiken sinken.

Managementberichte sollten die wichtigsten Systeme, Abhängigkeiten, Restrisiken und Entscheidungen zusammenführen. Wenn ein Anbieter notwendige Nachweise nicht liefert oder ein Fachbereich die geforderte Aufsicht nicht leisten kann, ist das eine Geschäftsentscheidung und kein offener Punkt im Sicherheitsregister. Akzeptanz, Einschränkung oder Beendigung des Einsatzes muss auf der richtigen Ebene beschlossen werden.

Fazit: AI Act und Informationssicherheit als ein Betriebsmodell denken

Eine belastbare Umsetzung beginnt mit Inventar, Rolle und Zweck. Darauf folgen gesetzliche sowie interne Klassifizierung, ein konkretes Risikomodell und Kontrollen, die im normalen Lebenszyklus wirken. Anbieter benötigen besonders tiefe Entwicklungs- und Konformitätsnachweise; Betreiber müssen Gebrauch, Aufsicht, Daten und Monitoring im Fachprozess beherrschen. Beide Seiten brauchen sichere Architektur, nachvollziehbare Änderungen und geübte Reaktion auf Vorfälle.

BlackMount unterstützt Unternehmen bei AI-Act-Readiness und sicherer KI-Governance: von Inventar und Rollenmodell über Bedrohungsanalyse und Kontrollrahmen bis zur prüfbaren Umsetzung. Das Ziel ist kein separates Papierprogramm, sondern ein Betriebsmodell, das Innovation ermöglicht und zugleich sensible Daten, Geschäftsprozesse und betroffene Personen schützt.