Der Anruf, den keiner erwartet hat

Es war ein ganz normaler Dienstagmorgen bei der fiktiven MittelTech GmbH in Stuttgart. Das Unternehmen, ein IT-Beratungshaus mit rund 180 Mitarbeitern, hatte in den vergangenen zwei Jahren viel in KI investiert: ein internes Wissensmanagement-Tool, das auf einem fine-getunten LLaMA-Modell basierte, ein KI-gestützter Angebotsassistent für das Vertriebsteam und – seit Herbst 2025 – ein schlankes Chatbot-Modul, das als weißes Label in die Compliance-Management-Software zweier Kundenunternehmen eingebettet war.

Dann rief ein befreundeter Rechtsanwalt an. Er hatte den Entwurf der EU-Kommission zur Durchführungsverordnung für GPAI-Anbieter gelesen – jenen Entwurf vom 12. März 2026, der erstmals beschreibt, wie das europäische KI-Büro KI-Modellanbieter prüfen und bestrafen will. "Habt ihr euch mal angesehen, ob ihr unter den Begriff GPAI-Anbieter fallt?", fragte er. "Wegen eures Chatbot-Moduls in den Kundensystemen meine ich."

CTO Markus H. legte nach dem Gespräch den Hörer auf und starrte eine Weile an die Wand. Die ehrliche Antwort lautete: Nein, das hatte bisher niemand geprüft. Und das sollte sich als das kleinere Problem herausstellen – denn die Analyse der nächsten Wochen würde zeigen, dass MittelTech gleich in mehrfacher Hinsicht Handlungsbedarf hatte.

Diese Geschichte ist fiktiv, aber sie spiegelt eine Realität wider, mit der Beratungsunternehmen, Softwarehäuser und technisch ambitionierte Mittelständler in den nächsten Monaten konfrontiert werden. Deshalb lohnt es sich, den Fall MittelTech von Anfang bis Ende durchzuspielen – und daraus konkrete Leitlinien für die eigene Situation abzuleiten.

Was General Purpose AI technisch bedeutet – und wo die Grenze zur Anbieterrolle liegt

Bevor wir MittelTechs Compliance-Reise weiterverfolgen, müssen wir verstehen, was der EU AI Act unter einem "General Purpose AI Model" versteht – denn hier liegt die entscheidende Weiche.

Der AI Act definiert ein GPAI-Modell in Artikel 3 Absatz 63 als ein KI-Modell, das "mit einer großen Datenmenge unter Self-Supervised Learning in großem Maßstab trainiert wurde, eine allgemeine Funktionalität aufweist und in einer Vielzahl von nachgelagerten Aufgaben und Anwendungen eingesetzt werden kann". Der Trainingsaufwand spielt eine wichtige Rolle: Modelle, die mit mehr als 1023 FLOPs trainiert wurden, fallen definitiv in diese Kategorie – was praktisch alle modernen Large Language Models umfasst, von GPT-4 über Claude bis zu LLaMA 3.

Der kritische Punkt für den Mittelstand liegt in der Frage: Was macht man mit diesen Modellen? Der AI Act unterscheidet drei Rollen:

GPAI-Anbieter (Provider): Wer ein GPAI-Modell auf den Markt bringt oder in Verkehr bringt. Das umfasst nicht nur das ursprüngliche Training, sondern auch das Fine-Tuning und die Weitergabe an Dritte. Wer ein LLaMA-Modell fine-tunet und dieses angepasste Modell dann in ein Produkt einbettet, das an Kunden geliefert wird, kann als GPAI-Anbieter gelten – auch wenn das ursprüngliche Basismodell von Meta stammt.

Nachgelagerter Anbieter (Downstream Provider): Wer ein GPAI-Modell in eigene Anwendungen oder Dienste integriert, ohne das Modell selbst zu verändern. Diese Rolle bringt geringere Pflichten mit sich, aber keine Freifahrt: Transparenzanforderungen, Nutzungsbeschränkungen und die Weitergabe relevanter Informationen an Endnutzer bleiben verpflichtend.

Betreiber/Nutzer (Deployer/User): Wer ein KI-System für eigene, interne Zwecke einsetzt, ohne es weiterzugeben. Diese Rolle hat die geringsten direkten Pflichten unter dem AI Act – es sei denn, das eingesetzte System fällt in die Kategorie "Hochrisiko-KI".

Die Trennlinie zwischen diesen Rollen ist im Alltag oft weniger klar als in der rechtlichen Theorie. Ein selbst fine-getuntes Modell, das nur intern genutzt wird: eher nachgelagerter Anbieter. Dasselbe Modell in einem Produkt, das an Kunden verkauft wird: möglicherweise GPAI-Anbieter mit vollständigem Pflichtenkatalog.

MittelTechs Compliance-Reise: Von der Analyse zur Umsetzung

Zurück zu Markus H. und seinem Team. Die erste Reaktion nach dem Anruf war, einen Bestandsaufnahme-Workshop mit dem eigenen Entwicklungsteam anzusetzen. Das Ergebnis der zweitägigen Analyse war ernüchternd und erhellend zugleich.

Das interne Wissensmanagement-Tool basierte zwar auf LLaMA, war aber ausschließlich intern im Einsatz und verarbeitete nur Unternehmensdokumente in einem geschlossenen Retrieval-Augmented-Generation-System. Kein Weitergabe an Externe, kein allgemeiner Einsatz jenseits definierter Abfragen. Das Team klassifizierte es als internen Betrieb eines nachgelagerten KI-Systems – Pflichten: moderat, managebar.

Der Angebotsassistent nutzte die API eines externen Anbieters (ein kommerzielles LLM) und integrierte keine eigenen Modellanpassungen. Das Modell selbst wurde nicht verändert oder weitergegeben. Ergebnis: MittelTech ist hier Nutzer, nicht Anbieter. Der externe LLM-Dienstleister trägt die GPAI-Anbieter-Pflichten.

Das Chatbot-Modul in den Kundensystemen war die kritische Konstellation. MittelTech hatte ein LLaMA-Modell mit rund 8 Milliarden Parametern für compliance-spezifische Aufgaben fine-getunet – also mit eigenen Daten weitertrainiert, um es für einen speziellen Anwendungsfall zu optimieren. Dieses angepasste Modell wurde dann als Kernkomponente in eine Software eingebettet, die an zwei Kundenunternehmen lizenziert wurde. Die Kunden nutzten es zur Analyse von Vertragsdokumenten und zur automatisierten Compliance-Prüfung ihrer Zulieferkette.

Dieser Fall war der problematischste: MittelTech hatte ein bestehendes GPAI-Basismodell modifiziert und das Resultat in einem Produkt an Dritte weitergegeben. Gleichzeitig wurde das Modell in einem hochriskanten Kontext eingesetzt: Rechtsbewertung und Compliance-Entscheidungsunterstützung. Das Entwicklerteam war sich nach der Analyse einig: Hier ist eine fundierte rechtliche Einschätzung notwendig.

Der externe Rechtsanwalt und eine auf AI-Compliance spezialisierte Beraterin kamen zu dem Schluss: MittelTech ist wahrscheinlich als "nachgelagerter Anbieter" einzustufen, da das Basismodell von Meta stammt und das Fine-Tuning nicht die Grundarchitektur verändert. Dennoch: Die Weitergabe des angepassten Modells und sein Einsatz in einem potenziell hochriskanten Kontext erzeugen erhebliche Pflichten. Das Unternehmen initiierte umgehend ein strukturiertes Compliance-Projekt.

Was konkret zu tun war: MittelTechs Maßnahmenplan

In den folgenden sechs Wochen arbeitete MittelTechs kleines KI-Governance-Team – bestehend aus dem CTO, einem Datenschutzbeauftragten und einer Rechtsanwältin – einen strukturierten Maßnahmenplan ab. Die wichtigsten Stationen:

Technische Dokumentation erstellen: Für das Chatbot-Modul wurde eine vollständige technische Dokumentation gemäß Anhang IV des AI Acts erstellt. Darin enthalten: Beschreibung des Basismodells und des Fine-Tuning-Prozesses, Angaben zu den Trainingsdaten (Herkunft, Anonymisierungsverfahren, Datenqualitätssicherung), Leistungsmetriken und Testreihen sowie eine detaillierte Beschreibung der Systemarchitektur und der Schnittstellen zu den Kundensystemen. Die Dokumentation umfasste am Ende über 40 Seiten und stellte für das Team die erste systematische Erfassung des eigenen Produkts dar – ein Nebeneffekt, den niemand erwartet hatte, der aber unbezahlbar war.

Risikobewertung durchführen: Da das Modell in einem Umfeld eingesetzt wurde, das rechtliche und compliance-relevante Entscheidungen beeinflusst, musste eine formale Risikobewertung erstellt werden. Das Team identifizierte drei Hauptrisiken: mögliche Fehlbewertungen bei komplexen Vertragssituationen (insbesondere bei internationalen Vertragsklauseln), Bias im Training durch nicht repräsentative Beispieldokumente sowie fehlende Erklärungs- und Widerspruchsmöglichkeiten für Endnutzer. Für alle drei Risiken wurden Mitigationsmaßnahmen definiert: zusätzliche Testszenarien für Kantenfälle, Erweiterung des Trainingsdatensatzes um diversere Vertragstypen und die Implementierung eines Erklärungsmoduls, das dem Nutzer die wichtigsten Faktoren einer KI-Bewertung anzeigt.

Kundenkommunikation anpassen: Die Serviceverträge mit den beiden Kundenunternehmen wurden grundlegend überarbeitet. Neu aufgenommen: explizite Hinweise auf den KI-Einsatz und dessen rechtliche Implikationen, Erläuterungen zur Funktionsweise und zu den nachgewiesenen Grenzen des Systems, klare Beschreibung der menschlichen Überwachungspflicht auf Kundenseite sowie dedizierte Kontaktinformationen für Meldungen von Fehlfunktionen oder unerwarteten Ausgaben. Beide Kundenunternehmen reagierten positiv – eines bat sogar um eine gemeinsame Schulung für die eigenen Compliance-Teams.

Interne Schulungen etablieren: Die Mitarbeitenden, die das System bei Kunden einführten und betreuten, erhielten eine strukturierte KI-Governance-Schulung. Themen: Was ist eine KI-Fehlfunktion im Sinne des Gesetzes? Wie wird ein Vorfall intern gemeldet und dokumentiert? Welche Informationspflichten bestehen gegenüber dem Kunden? Die Schulungsunterlagen wurden direkt in das interne Wissensmanagementsystem integriert – und da es sich dabei um ein KI-gestütztes System handelte, entstand beim Entwicklerteam ein kleines, unvermeidliches Schmunzeln.

Der größere Kontext: Wo der EU AI Act gerade steht

Die Geschichte von MittelTech ist kein Sonderfall – sie ist ein Vorgeschmack auf Diskussionen, die in vielen Unternehmen in den nächsten Monaten stattfinden werden. Denn der EU AI Act ist keine abstrakte Zukunftsregulierung mehr. Er ist in Kraft, wesentliche Teile sind bereits anwendbar, und die Durchsetzungsmaschinerie wird gerade hochgefahren.

Der aktuelle Zeitplan: Die Verbote für KI-Praktiken mit inakzeptablem Risiko (Artikel 5, darunter Social Scoring durch staatliche Stellen und manipulative Subliminal-Techniken) sind seit Februar 2026 in Kraft. Die Pflichten für GPAI-Anbieter (Artikel 53) sind seit August 2025 anwendbar. Die vollständige Durchsetzung der Anforderungen für Hochrisiko-KI-Systeme in Bereichen wie Bildung, Beschäftigung und Justiz beginnt im August 2026. Die neue Durchführungsverordnung, deren öffentliche Konsultation am 9. April 2026 endete, präzisiert, wie das KI-Büro die Compliance von GPAI-Anbietern tatsächlich überprüfen wird.

Was viele Mittelständler noch unterschätzen: Der AI Act ist kein isoliertes Regulierungsinstrument. Er verknüpft sich systematisch mit anderen Regelwerken. Die DSGVO ist relevant bei personenbezogenen Daten im KI-Training und bei der Verarbeitung personenbezogener Daten durch KI-Systeme. NIS2 schreibt Cybersicherheitsmaßnahmen vor, die auch KI-Systeme als kritische IT-Komponenten umfassen. Der Cyber Resilience Act (CRA) reguliert die Software-Sicherheit von Produkten, in die KI-Komponenten eingebettet sind. Wer Compliance ganzheitlich denkt, muss diese Verflechtungen von Anfang an mitdenken – andernfalls entstehen teure Parallelstrukturen.

Und dann ist da noch das Digital-Omnibus-Paket der EU, das seit März 2026 im Trilog verhandelt wird. Es enthält unter anderem Anpassungen der KI-Haftungsrichtlinie und Änderungen am Produkthaftungsgesetz, die KI-Schäden erstmals in einem breiten Rahmen adressieren. Die politische Richtung ist klar: Wer KI-gestützte Dienstleistungen anbietet, muss damit rechnen, dass er für Fehlfunktionen in Zukunft leichter haftbar gemacht werden kann als bisher.

Die Compliance-Checkliste für den Mittelstand

Auf Basis von Projekten wie dem von MittelTech lässt sich ein strukturierter Einstiegspfad für die GPAI-Compliance ableiten. Die folgende Checkliste ersetzt keine individuelle Rechtsberatung, gibt aber einen belastbaren Orientierungsrahmen:

Phase 1 – Bestandsaufnahme (1–2 Wochen): Erstellen Sie eine vollständige Inventarliste aller eingesetzten KI-Systeme. Für jedes System: Wer ist der ursprüngliche Modellanbieter? Wird das Modell modifiziert (Fine-Tuning, Prompt-Engineering, RAG, Modell-Kombination)? Wird das System intern genutzt oder an Kunden weitergegeben? In welchem Kontext entscheidet das System mit – insbesondere: Personalwesen, Kreditvergabe, Rechtsberatung, Gesundheit, Bildung, kritische Infrastruktur?

Phase 2 – Rollenklärung (1–3 Wochen mit externer Unterstützung): Klären Sie für jedes System Ihre Rolle: GPAI-Anbieter, nachgelagerter Anbieter oder Betreiber? Diese Frage hat direkte Auswirkungen auf Ihren Pflichtenkatalog und sollte mit einem auf Technologierecht spezialisierten Anwalt beantwortet werden. Besonders komplex ist die Situation bei Fine-Tuning kombiniert mit Weitergabe an Dritte.

Phase 3 – Dokumentation aufbauen (4–8 Wochen): Für alle Systeme, bei denen Sie als Anbieter oder nachgelagerter Anbieter auftreten, muss eine technische Dokumentation erstellt werden. Modellbeschreibung und Herkunft, Trainingsdaten und deren Provenienz, Leistungsmetriken und Testverfahren, bekannte Einschränkungen und Risiken, Sicherheitsmechanismen und Monitoring-Konzept. Beginnen Sie jetzt – diese Dokumentation ist gleichzeitig Compliance-Grundlage und technisches Qualitätssicherungsdokument.

Phase 4 – Governance-Strukturen etablieren (fortlaufend): Benennen Sie eine verantwortliche Person für KI-Governance. Implementieren Sie einen internen Prozess für KI-Vorfälle: Wer entscheidet über Meldepflichten? Wie werden Fehlfunktionen eskaliert? Überprüfen Sie Ihre KI-Strategie regelmäßig auf regulatorische Relevanz. Der AI Act entwickelt sich weiter, und Ihre Governance muss mithalten.

Phase 5 – Kundenkommunikation und Verträge (2–4 Wochen): Passen Sie alle Serviceverträge und AGB an, in denen Sie KI-gestützte Leistungen erbringen. Kunden müssen über den KI-Einsatz informiert werden, seine Grenzen kennen und einen klaren Ansprechpartner für KI-bezogene Probleme haben. Für Hochrisiko-Anwendungen ist sicherzustellen, dass der kundenseitige Betreiber seine eigenen Pflichten kennt – insbesondere die Anforderung menschlicher Aufsicht bei kritischen Entscheidungen.

Ausblick: KI-Compliance als strategischer Vorteil

Es mag seltsam klingen, aber: Unternehmen, die den AI Act früh und strukturiert angehen, schaffen sich einen echten Wettbewerbsvorteil. Zum einen, weil regulatorische Verstöße teuer werden – Bußgelder bis zu 15 Millionen Euro sind für den Mittelstand existenzbedrohend. Zum anderen, weil B2B-Kunden zunehmend fragen, wie ihre Dienstleister mit KI-Risiken umgehen. Wer hier eine klare, dokumentierte Antwort hat, gewinnt Vertrauen und Aufträge.

Und es gibt noch einen dritten Grund: Die Dokumentations- und Governance-Prozesse, die für den AI Act nötig sind, erzwingen eine Auseinandersetzung mit den eigenen KI-Systemen, die viele Unternehmen bisher vermieden haben. Das Ergebnis ist nicht nur Compliance – es ist ein tieferes Verständnis der eigenen KI-Landschaft, das für strategische Entscheidungen unersetzlich ist. MittelTech hatte am Ende des Compliance-Projekts nicht nur eine sauberere rechtliche Situation. Das Unternehmen hatte drei technische Schwachstellen im Chatbot-Modul entdeckt, die unabhängig von regulatorischen Anforderungen behoben werden mussten, und hatte eine interne Diskussion über die strategische Richtung der eigenen KI-Entwicklung angestoßen.

Manchmal beginnt die beste KI-Strategie mit einer Compliance-Prüfung. Wenn Sie wissen möchten, wie Ihre Situation im Vergleich aussieht, unterstützt Sie das pleXtec-Team bei der KI-Inventarisierung, der Rollenklärung und dem Aufbau nachhaltiger Governance-Strukturen. Sprechen Sie uns gerne über unser Kontaktformular an oder besuchen Sie unsere Leistungsübersicht.