Open-Source-KI im Hochrisiko-Einsatz — Was Unternehmen wissen müssen

Die kurze Antwort lautet: Die Open-Source-Ausnahme aus Art. 2 Abs. 12 der EU-VO 2024/1689 gilt nicht, wenn ein System als Hochrisiko-KI nach Art. 6 und Anhang III eingesetzt wird. Wer ein offenes Modell in einem solchen Zweck in Betrieb nimmt oder den Zweck entsprechend festlegt, kann rechtlich wie ein Anbieter behandelt werden und muss die Pflichten aus Art. 16 vollständig abdecken.

Letzte Aktualisierung: 23. März 2026

Für Unternehmen ist damit nicht die Lizenzfrage der Endpunkt, sondern der Einsatzkontext. Wenn Sie die Grundlagen vertiefen wollen, lesen Sie parallel Open-Source-KI und der EU AI Act, die Einordnung zu Hochrisiko-KI nach Annex III und die Rollenlogik aus Anbieter vs. Betreiber.

Art. 2(12) gilt NICHT bei Hochrisiko

Die Kernregel ist eindeutig: Freie und offene Lizenzen befreien nicht von der Verordnung, sobald das System als Hochrisiko-KI auf den Markt gebracht oder in Betrieb genommen wird. Genau diese Ausnahme enthält Art. 2 Abs. 12 selbst.

Für die Praxis zählen drei Fragen zuerst:

1. Liegt überhaupt eine freie und offene Lizenz im Sinne von Art. 2 Abs. 12 vor?
2. Fällt der konkrete Einsatz unter Art. 6 und Anhang III?
3. Wird das System nur intern getestet oder bereits produktiv in einem Hochrisiko-Prozess eingesetzt?

Die Lizenz ist deshalb nur die erste Prüfebene. Wer ein Modell unter Apache- oder MIT-Lizenz in ein Recruiting-, Bildungs-, Kredit- oder biometrisches System integriert, verliert die Schutzwirkung der Open-Source-Ausnahme für diesen Use Case.

| Frage | Relevante Norm | Praktische Folge | | --- | --- | --- | | Modell ist frei und offen lizenziert | Art. 2 Abs. 12 | Ausnahme kann grundsätzlich beginnen | | Einsatz liegt in Anhang III | Art. 6 Abs. 2 + Anhang III | Ausnahme endet | | System wird als Hochrisiko in Betrieb genommen | Art. 2 Abs. 12 | Voller AI-Act-Pflichtenrahmen | | System bleibt außerhalb Hochrisiko, Art. 5 und Art. 50 | Art. 2 Abs. 12 | Teilweise Ausnahme möglich |

Viele Teams verwechseln „Open Source“ mit „regulatorisch privilegiert“. Richtig ist nur: Open Source kann bei allgemeinen, nicht hochriskanten Anwendungen relevant sein, aber nicht bei Annex-III-Konstellationen.

Wer wird zum Provider?

Die kurze Antwort lautet: Provider ist nicht nur der ursprüngliche Modellentwickler. Auch ein Unternehmen, das ein offenes Basismodell in ein eigenes Hochrisiko-System überführt, unter eigener Verantwortung bereitstellt oder den vorgesehenen Zweck in einen Hochrisiko-Kontext verschiebt, kann in die Anbieterrolle geraten.

Maßgeblich sind die Definitionen in Art. 3 Nr. 3 und die Zurechnungsregeln aus Art. 25. Für offene Modelle ist das besonders relevant, weil Unternehmen technische Freiheit oft mit regulatorischer Distanz verwechseln.

Typische Provider-Auslöser sind:

1. Sie bauen aus einem offenen Grundmodell ein eigenes HR-, Scoring- oder Prüfungsprodukt.
2. Sie bringen das System unter eigenem Namen oder eigener Marke in Verkehr.
3. Sie ändern den vorgesehenen Zweck so, dass aus allgemeiner KI ein Hochrisiko-Einsatz wird.
4. Sie nehmen eine wesentliche Änderung vor, die Verhalten, Risiko oder Leistungsgrenzen substanziell verschiebt.

| Konstellation | Rolle des Unternehmens | Warum das kritisch ist | | --- | --- | --- | | Reine Nutzung eines externen Tools im Unternehmen | Meist Betreiber | Kein eigenes Inverkehrbringen | | Eigenes Produkt auf Basis eines offenen Modells | Häufig Anbieter | Eigene Produktverantwortung | | White-Label eines Hochrisiko-Systems | Anbieter nach Art. 25 | Eigenes Branding genügt | | Zweckänderung zu Recruiting, Bildung oder Kredit | Anbieter-Risiko hoch | Aus allgemeiner KI wird Hochrisiko-KI |

Entscheidend ist damit nicht, ob das Basismodell von Meta, Mistral oder einer Open-Source-Community stammt. Entscheidend ist, wer das konkrete Hochrisiko-System verantwortet, dokumentiert und in Betrieb setzt.

Art. 16 Pflichten komplett

Wenn Ihr Unternehmen Anbieter eines Hochrisiko-Systems wird, greifen die Pflichten aus Art. 16 vollständig. Das ist kein Teilpaket und keine abgespeckte Open-Source-Version.

Die Pflichtblöcke aus Art. 16 bauen auf den Produktanforderungen aus Art. 8 bis 15 auf. Sie müssen also nicht nur eine Rollenentscheidung treffen, sondern ein belastbares Governance-, Dokumentations- und Freigabesystem aufsetzen.

Die wichtigsten Pflichten im Überblick:

1. Konformität des Systems mit Art. 8 bis 15 sicherstellen.
2. Ein Qualitätsmanagementsystem nach Art. 17 betreiben.
3. Technische Dokumentation nach Art. 11 und Anhang IV erstellen.
4. Logging und automatische Aufzeichnungen nach Art. 12 ermöglichen.
5. Transparenz- und Gebrauchsinformationen nach Art. 13 bereitstellen.
6. Menschliche Aufsicht nach Art. 14 wirksam auslegen.
7. Genauigkeit, Robustheit und Cybersicherheit nach Art. 15 absichern.
8. Vor Inverkehrbringen eine Konformitätsbewertung nach Art. 43 durchführen.
9. EU-Konformitätserklärung ausstellen und CE-Kennzeichnung anbringen.
10. Korrekturmaßnahmen, Rücknahmen und Behördenkommunikation organisieren.

| Pflichtbereich | Zentrale Norm | Was Unternehmen konkret vorbereiten müssen | | --- | --- | --- | | Risikomanagement | Art. 9 | Risikoanalyse über den gesamten Lebenszyklus | | Daten und Daten-Governance | Art. 10 | Qualitätskriterien, Herkunft und Eignung der Datensätze | | Technische Dokumentation | Art. 11 + Anhang IV | Nachweisstruktur vor Go-live | | Human Oversight | Art. 14 | Rollen, Eingriffsrechte, Eskalationspfade | | Konformitätsbewertung | Art. 43 | Prüffähige Unterlagen vor dem Einsatz | | CE und Erklärung | Art. 47 bis 49 | Formale Marktzulassung für Hochrisiko-KI |

Für Mittelständler ist das der entscheidende Denkfehler: Ein offenes Modell reduziert Lizenzkosten, aber nicht die Anbieterpflichten. Wer Hochrisiko-KI mit Open-Source-Komponenten baut, spart vielleicht beim Modellzugang, nicht aber bei Governance, Testing, Dokumentation und Freigabe.

Praxisbeispiel: HR-Recruiting mit Llama

Die kurze Antwort lautet: Ein Recruiting-System auf Basis von Llama bleibt rechtlich kein harmloses Open-Source-Projekt. Wenn das System Bewerbungen vorsortiert, Eignungsscores erzeugt oder Empfehlungen für Einstellung, Ablehnung oder Einladung liefert, liegt der Fall nahe an Anhang III für Beschäftigung und Personalmanagement.

Llama ist dafür ein gutes Beispiel, weil das Modell oft als „offen“ bezeichnet wird, Unternehmen daraus aber schnell ein eigenes Produkt bauen. Selbst wenn man die Lizenzfrage ausblendet, kippt die Einordnung spätestens dann, wenn aus dem Basismodell ein HR-System mit konkretem Entscheidungsbezug wird.

Ein typischer Projektablauf sieht so aus:

1. Das Unternehmen hostet ein Llama-Modell in eigener Infrastruktur.
2. Es ergänzt Bewerberdaten, Stellenprofile und ein Ranking-Modul.
3. Recruiter erhalten eine Priorisierung oder einen Fit-Score.
4. Diese Ausgabe beeinflusst, wer eingeladen oder aussortiert wird.

| Projektstufe | Technische Änderung | Regulatorische Wirkung | | --- | --- | --- | | Basismodell lokal deployen | Offenes Modell wird selbst betrieben | Noch kein Hochrisiko-Fall allein | | HR-Daten und Bewertungslogik ergänzen | System bekommt Personalzweck | Annex-III-Risiko entsteht | | Score oder Ranking ausgeben | Entscheidung wird strukturiert beeinflusst | Hochrisiko-Einsatz sehr wahrscheinlich | | Produktiv im Recruiting nutzen | Inbetriebnahme im Personalprozess | Anbieter- oder Betreiberpflichten greifen voll |

Der zentrale Punkt ist die Zweckfestlegung. Wenn Ihr Unternehmen das Modell nicht nur als allgemeinen Textassistenten nutzt, sondern als Bewertungslogik für Personalentscheidungen auslegt, entsteht ein Hochrisiko-System unabhängig davon, dass die Modellgewichte öffentlich verfügbar waren.

Conformity Assessment: Ablauf und Kosten

Die kurze Antwort lautet: Die Konformitätsbewertung ist der teuerste und zeitkritischste Teil des Open-Source-Hochrisiko-Einsatzes. Ohne belastbare Unterlagen nach Art. 43 dürfen Hochrisiko-Systeme nicht sauber in Verkehr gebracht oder in Betrieb genommen werden.

Für die meisten Annex-III-Systeme ist zunächst ein internes Konformitätsverfahren mit vollständiger Nachweiskette relevant. In Sonderfällen kann zusätzlich eine notifizierte Stelle eingebunden werden, insbesondere wenn harmonisierte Normen fehlen oder spezielle Verfahren das verlangen.

Der Ablauf lässt sich in fünf Schritte gliedern:

1. Systemzweck und Risikoklasse dokumentieren.
2. Anforderungen aus Art. 8 bis 15 nachweisbar umsetzen.
3. Technische Dokumentation und Testprotokolle vervollständigen.
4. Konformitätsbewertung durchführen und Abweichungen schließen.
5. EU-Konformitätserklärung, CE-Kennzeichnung und Registrierung vorbereiten.

| Kostenblock | Typischer Umfang | Wovon die Höhe abhängt | | --- | --- | --- | | Juristische Einordnung | ca. 5.000 bis 20.000 EUR | Komplexität des Use Cases und Vertragsstruktur | | Technische Dokumentation und Testing | ca. 15.000 bis 80.000 EUR | Reifegrad, Datenlage, Audit-Tiefe | | Qualitätsmanagement und Prozesse | ca. 10.000 bis 50.000 EUR | Vorhandene Governance und Teamgröße | | Externe Prüfung oder Spezialgutachten | ca. 10.000 bis 60.000 EUR | Normenlage und Prüfverfahren | | Interner Personalaufwand | mehrere Personenmonate | Produkt, Recht, IT, Security, Fachbereich |

Diese Zahlen sind keine gesetzlich festgelegten Gebühren, sondern realistische Projektgrößen für Unternehmen, die bei null starten. Für viele Teams ist deshalb nicht das Modell selbst der Kostentreiber, sondern die Nachweisfähigkeit vor dem Stichtag 2. August 2026.

Checkliste: Hochrisiko mit Open-Source-KI

Die wichtigste Handlungsempfehlung lautet: Behandeln Sie Open-Source-KI in Hochrisiko-Fällen wie ein reguliertes Produkt, nicht wie ein IT-Experiment. Genau damit vermeiden Sie die Fehleinschätzung, dass ein offenes Modell automatisch weniger Pflichten auslöst.

Prüfen Sie vor jedem produktiven Einsatz mindestens diese Punkte:

1. Klassifizieren Sie den Use Case gegen Art. 6 und Anhang III.
2. Prüfen Sie, ob Ihr Unternehmen Anbieter oder nur Betreiber ist.
3. Dokumentieren Sie Zweck, Datenquellen, Modellversion und Entscheidungslogik.
4. Planen Sie Human Oversight, Logging und Freigaben vor dem Pilotbetrieb.
5. Erstellen Sie die technische Dokumentation vor dem Rollout, nicht danach.
6. Kalkulieren Sie Budget und Personal für die Konformitätsbewertung ein.
7. Schulen Sie Fachbereiche und Produktverantwortliche nach Art. 4 vor dem Go-live.

| Prüffrage | Ja bedeutet | Nächster Schritt | | --- | --- | --- | | Ist der Use Case in Anhang III genannt? | Hochrisiko wahrscheinlich | Spezialprüfung sofort starten | | Beeinflusst das System Rechte oder Chancen natürlicher Personen? | Grundrechtsrelevanz hoch | Dokumentation und Governance vertiefen | | Bringen Sie das System unter eigenem Namen in Verkehr? | Anbieterrolle möglich | Art. 16 vollständig prüfen | | Fehlen technische Nachweise, Logs oder Tests? | Konformitätslücke | Go-live stoppen | | Ist nur die Lizenz geprüft, aber nicht der Zweck? | Fehlklassifizierung | Gesamtbewertung neu aufsetzen |

Unabhängig davon, ob Sie Open-Source- oder proprietäre Modelle einsetzen: Die EU AI Act Schulung vermittelt die Grundlagen zu Artikel 4, Hochrisiko-Pflichten und Dokumentation — kompakt in 90 Minuten mit Schulungszertifikat.

Wenn Sie den Grundrahmen für Ihr Team sauber aufsetzen wollen, verbinden Sie diese Checkliste mit einer dokumentierten Schulung und einer festen Rollenentscheidung. Genau dafür sind unsere Beiträge zu Open-Source-KI und dem EU AI Act, Hochrisiko-KI nach Annex III und Anbieter vs. Betreiber die sinnvollste Vertiefung.