AI Governance: Was der EU AI Act für selbst gebaute KI-Features bedeutet

Viele Softwarehäuser bauen inzwischen KI-Features selbst ein. Ein Chatbot im Support, eine Textzusammenfassung im Produkt, ein Scoring-Modell für Leads. Das passiert oft nebenbei, ohne dass jemand prüft, ob daraus regulatorische Pflichten entstehen. Der EU AI Act ist seit August 2024 in Kraft und wird gestaffelt scharf. Wer KI in eigene Produkte einbaut, sollte wissen, welche Rolle er damit übernimmt.

Anbieter oder Betreiber: Die Rolle entscheidet

Der AI Act unterscheidet vor allem zwischen Anbieter und Betreiber. Anbieter ist, wer ein KI-System entwickelt und unter eigenem Namen auf den Markt bringt. Betreiber ist, wer ein KI-System in eigener Verantwortung nutzt. Sobald ein Haus ein gekauftes Modell so stark anpasst oder umwidmet, dass es als eigenes System auftritt, kann es zum Anbieter werden und damit die schwereren Pflichten erben. Diese Einordnung ist kein Formaldetail. Sie bestimmt, ob nur eine Nutzungsdokumentation reicht oder ob eine technische Dokumentation, Risikobewertung und Konformitätsprüfung fällig wird.

Die Risikoklassen kurz erklärt

Der AI Act staffelt nach Risiko. Verbotene Praktiken wie Social Scoring oder manipulatives Verhalten sind seit Februar 2025 untersagt. Hochrisiko-Systeme, etwa in der Personalauswahl, Kreditvergabe oder kritischen Infrastruktur, tragen den größten Pflichtenkatalog: Risikomanagement, Datenqualität, Protokollierung, menschliche Aufsicht, technische Dokumentation. Systeme mit begrenztem Risiko, zum Beispiel ein Chatbot, müssen vor allem transparent sein. Nutzer müssen erkennen, dass sie mit einer Maschine sprechen. KI-generierte Inhalte müssen als solche gekennzeichnet werden.

Für die meisten selbst gebauten Features im Mittelstand gilt: Sie fallen in die begrenzte oder minimale Risikoklasse. Das senkt den Aufwand erheblich. Trotzdem bleibt die Pflicht, die Einordnung sauber zu begründen. Wer behauptet, ein Feature sei harmlos, muss zeigen können, warum.

GPAI-Modelle bringen eigene Pflichten mit

Seit August 2025 gelten Regeln für Modelle mit allgemeinem Verwendungszweck, die sogenannten GPAI-Modelle. Wer ein großes Sprachmodell über eine API einbindet, ist davon meist nicht direkt als Anbieter betroffen, profitiert aber von den Transparenzpflichten der Modellanbieter. Wichtig wird das, sobald ein Haus ein offenes Modell selbst weitertrainiert und verteilt. Dann kann es selbst in die GPAI-Pflichten rutschen, inklusive technischer Dokumentation und einer Zusammenfassung der Trainingsdaten.

Was Sie jetzt konkret tun sollten

Der erste Schritt ist kein juristisches Gutachten, sondern eine Bestandsaufnahme. Welche KI-Features stecken im Produkt? Welches Modell steht dahinter, eigenes oder fremdes? Was passiert mit den Daten, die hineinfließen? Wer trägt die Verantwortung für die Ausgaben? Diese vier Fragen klären in den meisten Fällen schon, ob überhaupt eine Hochrisiko-Einordnung droht.

  • Inventar aller KI-Features mit Zweck und eingesetztem Modell
  • Rolle je Feature bestimmen: Anbieter oder Betreiber
  • Risikoklasse zuordnen und die Einordnung schriftlich begründen
  • Transparenzhinweise dort einbauen, wo Nutzer mit KI interagieren
  • Datenflüsse dokumentieren, vor allem bei personenbezogenen Eingaben

Diese Inventur lässt sich gut mit dem verbinden, was ohnehin in der Lieferkette nachvollziehbar sein sollte. Wer dokumentiert, welche Modelle und Abhängigkeiten in einem Build stecken, hat die halbe AI-Governance-Grundlage bereits liegen. Eine Software-Stückliste und ein nachvollziehbarer Deployment-Trail sind hier kein Zusatzaufwand, sondern die gleiche Disziplin, nur auf KI-Komponenten erweitert.


Klarheit statt Panik

Der AI Act ist umfangreich, trifft aber die meisten Mittelständler weniger hart als die Schlagzeilen vermuten lassen. Das Problem ist selten die Regulierung selbst, sondern der fehlende Überblick darüber, was im eigenen Produkt eigentlich an KI steckt. Wer diese Inventur einmal sauber macht, weiß sofort, wo er steht.

Genau hier setzt der GitSecOps QuickCheck an. Wir schauen in Ihre Pipeline und zeigen, welche Komponenten und Modelle in Ihren Builds stecken und wo Nachweise fehlen. 1.990 Euro netto, Ergebnis in drei Werktagen. Kontakt: mm@crank.zone.

Hinterlasse einen Kommentar

MHM Digitale Lösungen

Wir machen Software-Lieferketten sicher. GitSecOps prüft und härtet deine Build- und Deployment-Pipeline, damit du gegenüber Kunden und Prüfern bestehst. Hier schreiben wir nüchtern über Supply Chain Security, DevSecOps und digitales Business.

Kontakt