Fine-Tuning von Open-Source-KI — Wann werden Sie zum Anbieter?

Fine-Tuning von Open-Source-KI kann Ihr Unternehmen vom Betreiber zum Anbieter machen, wenn Sie ein Modell so weit verändern, dass regulatorisch ein neues GPAI-Modell oder ein wesentlich geändertes KI-System entsteht. Genau deshalb ist Fine-Tuning im EU AI Act kein bloß technisches Detail, sondern eine Compliance-Frage mit Folgen für Dokumentation, Konformität, Haftung und Marktbereitstellung.

Letzte Aktualisierung: 23. März 2026

Wenn Sie zuerst die Grundsystematik einordnen wollen, lesen Sie parallel unseren Beitrag zu Anbieter vs. Betreiber im AI Act, das Glossar zu KI-Anbieter vs. KI-Betreiber und die Einordnung zu General-Purpose AI. Für sensible Einsatzfelder ist außerdem relevant, ob Ihr Anwendungsfall in Richtung Hochrisiko-KI-System geht. Die operative Schulungsperspektive finden Sie auf der Seite zur EU AI Act Schulung.

Was ist Fine-Tuning — und warum ist es regulatorisch relevant?

Fine-Tuning ist die gezielte Nachschulung eines bestehenden KI-Modells mit zusätzlichen Daten oder Trainingsschritten, damit das Modell in einem bestimmten Fachgebiet, Stil oder Prozess besser funktioniert. Regulatorisch relevant wird Fine-Tuning, weil der EU AI Act nicht nur den erstmaligen Entwickler betrachtet, sondern auch Unternehmen, die ein Modell nachträglich so tief verändern, dass daraus eine neue Verantwortlichkeit entsteht.

Prompting allein ist noch kein Fine-Tuning. Wenn Sie einem bestehenden Modell nur bessere Anweisungen geben, Rollen definieren oder Ausgaberegeln per System-Prompt setzen, bleiben Sie regelmäßig beim Betrieb eines fremden Systems. Auch klassisches Retrieval-Augmented Generation, also das Einspeisen externer Dokumente zur Laufzeit, verändert das Modell selbst nicht. Das ist für die Rollenfrage entscheidend, weil RAG typischerweise Wissen ergänzt, aber keine neuen Gewichte trainiert.

Fine-Tuning beginnt dort, wo Modellgewichte angepasst werden. Das kann leichtgewichtig über Adapter, LoRA oder QLoRA geschehen oder tiefgreifend als vollständiges Retraining größerer Modellteile. Je stärker Sie in die Gewichte, Sicherheitsmechanismen, Leistungsgrenzen und den vorgesehenen Zweck eingreifen, desto eher verlassen Sie die reine Betreiberrolle. Für Hochrisiko-Systeme ist zusätzlich Art. 25 der EU-VO 2024/1689 relevant, weil eine wesentliche Änderung oder Zweckänderung dazu führen kann, dass ein Dritter wie ein Anbieter behandelt wird.

Für GPAI-Modelle ist die Lage noch sensibler. Der EU AI Act enthält in Art. 3 die Definitionen für Anbieter, Betreiber und GPAI-Modelle. Die Kommission konkretisiert in ihren GPAI-Leitlinien und Q&A-Dokumenten, wann ein nachgelagertes Unternehmen durch Modifikation oder Fine-Tuning selbst zum Anbieter eines GPAI-Modells werden kann. Die praktische Folge lautet: Open Source bedeutet nicht automatisch Ausnahme von Pflichten, sobald Sie ein Modell tiefgreifend weiterentwickeln und unter eigener Verantwortung einsetzen oder bereitstellen.

Für Unternehmen ist deshalb die wichtigste Abgrenzung einfach. Solange Sie ein Open-Source-Modell nur hosten, prompten, mit RAG anreichern oder leicht konfigurieren, bleiben Sie meist Betreiber oder Integrator. Sobald Sie aber neue Gewichte trainieren, Sicherheitsgrenzen verändern oder ein Modell mit eigenem Leistungsversprechen an Kunden oder interne Nutzer ausrollen, bewegen Sie sich in Richtung Anbieterrolle. Genau an dieser Stelle entsteht der typische Compliance-Fehler beim Fine-Tuning von Open-Source-KI.

Die 1/3-Compute-Schwelle: Der entscheidende Kipppunkt

Die bekannte 1/3-Compute-Schwelle ist kein frei erfundener Praxiswert, sondern eine regulatorische Auslegung für GPAI-Fine-Tuning. Wichtig ist die Präzision: Art. 3 Nr. 68 der EU-VO 2024/1689 definiert zunächst den "downstream provider". Die konkrete 1/3-Schwelle folgt erst aus den Leitlinien der Europäischen Kommission zum Anwendungsbereich der GPAI-Pflichten und den begleitenden GPAI-Q&A.

Der Kern der Schwelle lautet: Wenn das zusätzliche Training oder Fine-Tuning mehr als ein Drittel des Rechenaufwands des ursprünglichen Trainings benötigt, spricht viel dafür, dass Sie regulatorisch nicht mehr nur ein bestehendes Modell nutzen, sondern ein eigenständiges GPAI-Modell geschaffen haben. Die Kommission formuliert das bewusst als "indicative criterion" für den Fall, dass ein nachgelagerter Akteur als Anbieter eines modifizierten GPAI-Modells anzusehen ist. Ist der ursprüngliche Rechenaufwand unbekannt, nennen die Leitlinien Ersatzschwellen: bei einem ursprünglichen GPAI-Modell mit systemischem Risiko ein Drittel von 10^25 FLOP, sonst ein Drittel von 10^23 FLOP. Genau deshalb ist nicht nur der Code wichtig, sondern auch die Trainingsdokumentation.

Für die Unternehmenspraxis folgt daraus eine harte Governance-Anforderung. Sie sollten vor jedem Fine-Tuning festhalten:

1. Welches Basismodell Sie verwenden.
2. Ob Ihnen belastbare Angaben zum ursprünglichen Training vorliegen.
3. Wie hoch der zusätzliche Compute-Bedarf Ihres Fine-Tunings ist.
4. Ob Sicherheitsmechanismen, Modellgrenzen oder der vorgesehene Zweck verändert werden.

Ein einfaches Rechenbeispiel zeigt den Kipppunkt. Angenommen, das ursprüngliche Modell wurde mit einem Rechenaufwand von 9 Einheiten trainiert. Wenn Ihr Fine-Tuning 2 Einheiten benötigt, bleiben Sie unter einem Drittel. Wenn Ihr Fine-Tuning 3,5 Einheiten benötigt, liegen Sie darüber. Die Schwelle ist damit keine abstrakte Juristenformel, sondern eine planbare technische Kennzahl, die in Beschaffung und MLOps-Prozesse gehört.

LoRA bleibt in vielen Fällen unter dieser Schwelle, weil nur kleine zusätzliche Gewichts-Matrizen trainiert werden und der Compute-Aufwand deutlich unter dem eines vollständigen Retrainings liegt. Das ist aber nur eine Regelvermutung, keine Garantie. Wenn Sie sehr große Datenmengen, lange Trainingsläufe oder tiefgreifende Sicherheitsanpassungen kombinieren, kann auch ein formal leichtgewichtiges Verfahren regulatorisch relevant werden.

Der zweite wichtige Punkt ist die Beweisfrage. Wenn Sie den Compute nicht dokumentieren, können Sie später kaum belegen, dass Ihr Fine-Tuning unter der 1/3-Schwelle blieb. Genau deshalb ist es riskant, Fine-Tuning als reines Entwicklerprojekt zu behandeln. Für den AI Act zählt am Ende nicht Ihre Absicht, sondern ob Sie technisch und organisatorisch nachweisen können, welche Art von Modifikation tatsächlich stattgefunden hat.

RAG vs. LoRA vs. Full Retraining: Was macht Sie zum Provider?

RAG, LoRA und Full Retraining führen regulatorisch nicht automatisch zum gleichen Ergebnis. Die richtige Einordnung hängt davon ab, ob Sie nur Kontext zuführen, begrenzte Gewichtsänderungen vornehmen oder ein Modell substanziell neu trainieren. Für die Rollenfrage ist deshalb nicht der Marketingbegriff entscheidend, sondern die Tiefe des Eingriffs.

RAG macht Sie in aller Regel nicht zum Anbieter, weil Sie das Modell selbst nicht verändern. Sie bauen eine Anwendungsschicht um ein bestehendes Modell herum. Das kann datenschutzrechtlich, urheberrechtlich oder im Hochrisiko-Kontext trotzdem anspruchsvoll sein, ändert aber die Modellrolle meist nicht. Wenn Sie dazu mehr Kontext brauchen, ist unser Beitrag zu Anbieter vs. Betreiber im AI Act der richtige Startpunkt.

LoRA ist der häufigste Graubereich. Technisch ist LoRA deutlich leichter als ein vollständiges Retraining, regulatorisch aber nicht automatisch irrelevant. Wenn Sie damit nur ein Fachvokabular, einen Stil oder eng begrenzte Aufgaben nachschärfen und unter der 1/3-Schwelle bleiben, werden Sie häufig weiterhin als Betreiber eines angepassten Systems argumentieren können. Wenn Sie damit aber sicherheitsrelevante Grenzen verschieben, ein System für einen neuen Zweck umbauen oder die Veränderung als eigenes Produkt vermarkten, steigt das Risiko der Anbieterrolle deutlich.

Full Retraining ist der klare Provider-Fall. Wer ein Open-Source-Basismodell großflächig weitertrainiert, damit neue Fähigkeiten schafft und das Ergebnis intern oder extern unter eigener Verantwortung ausrollt, übernimmt faktisch Produktverantwortung. Für Hochrisiko-Einsatzfelder kann zusätzlich Art. 25 greifen. Für GPAI-Konstellationen rücken außerdem die spezifischen Anbieterpflichten der Verordnung in den Vordergrund.

Die praxistaugliche Faustregel lautet daher: RAG verändert Wissen im Kontext, LoRA verändert meist begrenzt die Gewichte, Full Retraining verändert das Modell selbst. Nur aus der technischen Perspektive zu argumentieren, reicht allerdings nicht. Sie müssen zusätzlich dokumentieren, welche Risiken, Sicherheitsmechanismen und Zweckbindungen sich durch das Fine-Tuning ändern. Erst daraus ergibt sich die saubere AI-Act-Einordnung.

Deployer vs. Provider: Ihre Pflichten im Vergleich

Die Pflichten eines Betreibers unterscheiden sich grundlegend von denen eines Anbieters. Betreiber müssen ein KI-System rechtskonform einsetzen, Anbieter müssen ein KI-System rechtskonform auf den Markt bringen oder in Betrieb nehmen. Genau deshalb ist die Rollenfrage beim Fine-Tuning wirtschaftlich so relevant.

Für viele Unternehmen ist schon der Dokumentationssprung entscheidend. Betreiber brauchen vor allem einen nachvollziehbaren Einsatzrahmen: Wer nutzt das System, wofür, mit welchen Freigaben, mit welcher Schulung und mit welchen Logs? Anbieter müssen deutlich tiefer gehen. Dort genügen keine internen Notizen, sondern strukturierte technische Unterlagen, Prüfungen, Governance und je nach System eine formalisierte Konformitätsbewertung.

Besonders relevant ist das für interne Produktteams. Viele Unternehmen glauben, sie würden ein Open-Source-Modell nur intern weiterentwickeln und seien deshalb kein Anbieter. Das ist zu kurz gedacht. Der AI Act kennt ausdrücklich auch die Inbetriebnahme unter eigenem Namen. Wenn Sie also ein stark modifiziertes Modell konzernweit oder unter einer eigenen Marke bereitstellen, kann die Anbieterrolle auch ohne klassischen Vertrieb ausgelöst werden.

Für die Praxis sollten Sie deshalb vor dem Go-live vier Fragen beantworten:

1. Haben Sie nur die Anwendungsschicht verändert oder das Modell selbst?
2. Bleibt der vorgesehene Zweck identisch oder entsteht ein neuer Zweck?
3. Können Sie Compute, Trainingsdaten und Sicherheitsanpassungen belegen?
4. Wird das Ergebnis unter Ihrer Marke oder Ihrer betrieblichen Verantwortung bereitgestellt?

Wenn Sie eine dieser Fragen nicht sauber beantworten können, fehlt meist schon die notwendige Dokumentationsbasis. Dann ist nicht nur die Compliance unsicher, sondern auch die spätere Verteidigung gegenüber Kunden, Aufsichtsbehörden oder Gerichten.

Haftungsrisiken bei unkontrolliertem Fine-Tuning

Unkontrolliertes Fine-Tuning erhöht nicht nur regulatorische Pflichten, sondern auch Haftungsrisiken. Wenn ein angepasstes Modell fehlerhafte, diskriminierende oder sicherheitskritische Ergebnisse liefert, stellt sich sehr schnell die Frage, ob Ihr Unternehmen nur Anwender war oder durch das Fine-Tuning selbst Produktverantwortung übernommen hat.

Das erste Risiko liegt in der Produkthaftung. Mit der neuen Produkthaftungsrichtlinie Richtlinie (EU) 2024/2853 werden Software und bestimmte digitale Änderungen ausdrücklich stärker in die Haftungslogik einbezogen. Wer durch Fine-Tuning ein Modell erheblich verändert, sollte deshalb nicht davon ausgehen, dass jede Verantwortung beim ursprünglichen Open-Source-Herausgeber bleibt. Wenn Ihr Eingriff das Fehlerprofil verändert, wird diese Veränderung im Streitfall genau untersucht werden.

Das zweite Risiko liegt in nationalem Delikts- und Vertragsrecht. Wenn ein feinjustiertes Modell etwa Bewerber systematisch benachteiligt, falsche Risikobewertungen erzeugt oder in einer Qualitätsprüfung gefährliche Fehlklassifikationen liefert, geht es nicht nur um AI-Act-Compliance. Es geht auch um Organisationsverschulden, unzureichende Tests, fehlende Aufsicht und mangelhafte Dokumentation. Gerade im B2B-Kontext sind Haftungsketten dann oft vertraglich verschärft.

Das dritte Risiko ist die Beweislage. Je schlechter Ihr Training, Ihre Datengrundlage und Ihre Freigabeprozesse dokumentiert sind, desto schwerer können Sie nachweisen, dass ein Schaden nicht durch Ihr Fine-Tuning verursacht wurde. Die oft genannte AI Liability Directive ist dafür kein geltendes Auffangnetz: Der Richtlinienvorschlag wurde von der Kommission im Arbeitsprogramm 2025 zur Rücknahme gestellt und ist Stand 23. März 2026 kein anwendbares Haftungsregime. Für Unternehmen ist die praktische Konsequenz dennoch eindeutig: Dokumentationslücken helfen im Streitfall fast nie dem Betreiber.

Drei typische Szenarien zeigen das Problem:

1. Ein HR-Team fine-tuned ein Open-Source-Modell mit historischen Bewerbungsdaten und setzt es danach zur Vorauswahl ein. Wenn das Modell Frauen oder ältere Bewerber systematisch schlechter bewertet, drohen nicht nur Diskriminierungs- und Arbeitsrechtsrisiken, sondern bei Hochrisiko-Kontexten auch AI-Act-Folgen.
2. Ein Industrieunternehmen trainiert ein Modell auf interne Qualitätsdaten nach und nutzt es für sicherheitsrelevante Freigaben. Liefert das Modell falsche Freigaben, rückt sofort die Frage nach Testtiefe, menschlicher Aufsicht und technischer Dokumentation in den Vordergrund.
3. Ein SaaS-Anbieter baut ein Open-Source-Modell per Fine-Tuning zu einem branchenspezifischen Assistenten um und verkauft ihn unter eigener Marke. Kommt es zu Fehlentscheidungen beim Kunden, wird es sehr schwer, sich noch als bloßer Nutzer des Basismodells darzustellen.

Haftungsprävention beginnt deshalb nicht beim Gerichtsverfahren, sondern vor dem ersten Trainingslauf. Sie brauchen Freigabekriterien, Testprotokolle, Datenquellen-Nachweise, Versionsstände, Rollback-Möglichkeiten und eine klare Rollenentscheidung. Wenn Ihr Team diese Basics nicht sauber beherrscht, ist Fine-Tuning kein Innovationsprojekt, sondern ein ungesteuertes Haftungsexperiment.

Checkliste: So bleiben Sie beim Fine-Tuning compliant

Fine-Tuning bleibt beherrschbar, wenn Sie Technik, Recht und Governance von Anfang an gemeinsam steuern. Die folgende 7-Punkte-Checkliste deckt die Mindestfragen ab, die vor jedem produktiven Fine-Tuning beantwortet sein sollten.

1. Basismodell klassifizieren: Dokumentieren Sie Modellname, Version, Lizenz, Herkunft und den vorgesehenen Zweck. Für die Rollenabgrenzung helfen unser Beitrag zu Anbieter vs. Betreiber im AI Act und das Glossar zu General-Purpose AI.
2. Modifikation abgrenzen: Halten Sie fest, ob Sie nur prompten, RAG einsetzen, LoRA verwenden oder ein tiefes Retraining planen. Ohne diese Abgrenzung ist keine belastbare Rollenbestimmung möglich.
3. Compute messen: Erfassen Sie vorab und nachträglich den Rechenaufwand des Fine-Tunings, damit Sie die 1/3-Schwelle begründet einordnen können.
4. Zweckänderung prüfen: Klären Sie, ob aus einem allgemeinen Modell durch Ihren Einsatz ein sensibler oder sogar hochriskanter Einsatz wird.
5. Sicherheits- und Testprotokolle führen: Dokumentieren Sie Datensätze, Evaluationskriterien, Guardrails, Fehlerraten und bekannte Rest­risiken.
6. Rollenentscheidung freigeben: Lassen Sie Compliance, Produkt, IT und Fachbereich gemeinsam festhalten, ob Sie Betreiber bleiben oder Anbieter werden könnten.
7. Mitarbeitende schulen: Stellen Sie sicher, dass technische Teams, Einkauf, Legal und Fachbereiche die Folgen von Fine-Tuning verstehen. Für diesen Schritt ist eine strukturierte EU AI Act Schulung oft der schnellste Weg.

Eine kompakte Dokumentationsvorlage kann aus sieben Feldern bestehen: Basismodell, Lizenz, Modifikationsart, zusätzlicher Compute, Zweckänderung, Risikoklasse, Freigabeverantwortliche. Wenn Sie diese Felder pro Modellversion pflegen, haben Sie bereits den Kern dessen, was im Audit, bei Kundenfragen oder in einer internen Freigaberunde benötigt wird.

Die wichtigste Schlussfolgerung ist damit klar. Fine-Tuning von Open-Source-KI ist kein bloßer Performance-Hebel, sondern ein Rollenwechsel-Risiko. Wer die 1/3-Schwelle, Art. 25, die Anbieterpflichten und die Dokumentation ignoriert, kann unbeabsichtigt vom Betreiber zum Anbieter werden. Wenn Ihr Team diese Grenze sicher verstehen und in der Praxis belastbar dokumentieren soll, ist die EU AI Act Schulung der passende nächste Schritt.