Zurück zum Blog
Regulierung
Praxis

KI-Lizenzen verstehen: Open Source, proprietär und API

Llama ist Open Source, ChatGPT proprietär, Claude gibt's per API — aber was bedeutet das rechtlich? Ein Überblick über KI-Lizenzmodelle und ihre Fallstricke.

KCT
KI Comply TeamKI-Compliance Experten
25. Juli 20255 Min. Lesezeit
KI-Lizenzen verstehen: Open Source, proprietär und API

Das Wichtigste in Kürze

  • KI-Modelle werden über drei grundlegende Lizenzmodelle vertrieben: proprietär (z. B. GPT-4), Open Source / Open Weights (z. B. Llama, Mistral) und API/SaaS (z. B. Claude API, OpenAI API).
  • Jedes Lizenzmodell bringt unterschiedliche rechtliche Pflichten mit sich -- sowohl nach dem AI Act (VO (EU) 2024/1689) als auch nach deutschem Urheber- und AGB-Recht (§§69a--69g UrhG, §§305--310 BGB).
  • Viele als „Open Source" beworbene KI-Modelle erfüllen nicht die Kriterien der Open Source Initiative (OSI) -- das sogenannte „Faux Open Source"-Problem.
  • API-Nutzungsbedingungen enthalten häufig versteckte Einschränkungen zu Output-Rechten, Trainingsklauseln und Nutzungsverboten, die einer AGB-Kontrolle nach §§305 ff. BGB standhalten müssen.
  • Die AI-Act-Pflichten unterscheiden sich je nach Lizenzmodell erheblich: Open-Source-Anbieter profitieren von Erleichterungen nach Art. 53 Abs. 2, verlieren diese aber bei systemischem Risiko oder Hochrisiko-Einsatz.

Warum KI-Lizenzen Chefsache sind

Wenn ein Unternehmen heute ein KI-Modell einsetzt, trifft es damit nicht nur eine technische Entscheidung, sondern eine rechtliche und strategische Weichenstellung. Die Wahl zwischen einem proprietären Modell, einer Open-Source-Lösung oder einer API-Anbindung bestimmt, wer die Kontrolle über das Modell hat, wie abhängig das Unternehmen vom Anbieter wird, welche Compliance-Pflichten greifen und was mit den generierten Outputs geschieht.

In der Praxis erleben wir, dass viele Unternehmen die Tragweite dieser Entscheidung unterschätzen. Ein „kostenloses" Open-Source-Modell kann teurer werden als eine proprietäre Lösung, wenn die Lizenz den kommerziellen Einsatz einschränkt. Und eine API, die heute problemlos funktioniert, kann morgen per AGB-Änderung einen gesamten Geschäftsprozess gefährden.

Dieser Artikel bietet einen systematischen Überblick über die drei KI-Lizenzmodelle, ihre rechtlichen Implikationen und die konkreten Fallstricke, die Unternehmen kennen müssen.


Die drei KI-Lizenzmodelle im Überblick

1. Proprietäre Lizenzen

Bei proprietären KI-Modellen behält der Anbieter die vollständige Kontrolle über Modellgewichte, Quellcode und Architektur. Das Unternehmen erhält ein eingeschränktes Nutzungsrecht, typischerweise als Softwarelizenz im Sinne der §§69a ff. UrhG. Beispiele sind GPT-4 von OpenAI (in der Desktop-/Enterprise-Variante), Google Gemini Ultra in der Workspace-Integration oder branchenspezifische KI-Lösungen von Anbietern wie Palantir oder C3.ai.

Der Vorteil: Support, Haftungsübernahme und eine definierte Leistungsbeschreibung. Der Nachteil: vollständige Abhängigkeit vom Anbieter (Vendor Lock-in), eingeschränkte Anpassbarkeit und oft undurchsichtige Preismodelle.

2. Open Source / Open Weights

Open-Source-KI-Modelle werden mit offengelegten Modellgewichten und -- in unterschiedlichem Umfang -- mit Trainingscode, Daten und Dokumentation bereitgestellt. Bekannte Beispiele sind Metas Llama-Reihe, Mistrals Mixtral und Mistral Large, die Qwen-Modelle von Alibaba Cloud oder DeepSeek. Nutzer können das Modell lokal betreiben, feintunen und in eigene Produkte integrieren.

Allerdings ist „Open Source" bei KI-Modellen ein dehnbarer Begriff. Nicht jedes Modell mit veröffentlichten Gewichten erfüllt die Kriterien der Open Source Initiative -- ein Problem, auf das wir weiter unten im Detail eingehen.

3. API / SaaS

Das drittverbreiteste Modell ist der Zugang über eine Application Programming Interface (API). Das Unternehmen sendet Anfragen an den Server des Anbieters und erhält Antworten zurück, ohne jemals Zugriff auf das Modell selbst zu haben. Beispiele sind die APIs von Anthropic (Claude), OpenAI (GPT-Modelle), Google (Gemini API) oder Cohere.

Rechtlich handelt es sich um einen Dienstleistungsvertrag (§§611 ff. BGB), der durch die Allgemeinen Geschäftsbedingungen (AGB) des Anbieters geprägt wird. Die Kontrolle liegt vollständig beim Anbieter; das Unternehmen hat weder Einsicht in die Modellarchitektur noch Einfluss auf Modell-Updates.


Vergleichstabelle: Lizenzmodelle im Überblick

KriteriumProprietärOpen Source / Open WeightsAPI / SaaS
Zugang zum ModellKein Zugang zu Gewichten/CodeModellgewichte offen, ggf. TrainingscodeKein Zugang; Blackbox-Zugriff
AnpassbarkeitGering; nur über KonfigurationHoch; Fine-Tuning, Forking möglichGering; nur Prompt-Engineering und ggf. Fine-Tuning-API
KostenLizenzgebühren, oft pro Nutzer/JahrInfrastrukturkosten (GPU, Personal)Pay-per-Token / Abo-Modell
KontrolleAnbieter behält KontrolleNutzer hat volle KontrolleAnbieter hat volle Kontrolle
DatenschutzAbhängig von Hosting; On-Premise möglichVolle Kontrolle bei Self-HostingDaten verlassen Unternehmen
AI-Act-PflichtenAnbieter- + BetreiberpflichtenErleichterungen für Anbieter (Art. 53 Abs. 2); Betreiber voll verantwortlichAnbieter- + Betreiberpflichten; Transparenzpflichten nach Art. 50

Open-Source-Lizenzen für KI-Modelle

Überblick der wichtigsten Lizenzen

Nicht jede Lizenz, die im KI-Bereich als „Open Source" vermarktet wird, ist gleich. Die folgende Tabelle zeigt die relevantesten Lizenztypen:

LizenzOSI-konformKommerziell nutzbarCopyleftEinschränkungenBeispiel
Apache 2.0JaJaNeinKeine wesentlichenWhisper, BERT
MITJaJaNeinKeine wesentlichenDiverse kleinere Modelle
GPL 3.0JaJa (mit Copyleft-Pflicht)JaAbgeleitete Werke müssen unter GPL stehenWenige KI-Modelle
Llama Community LicenseNeinEingeschränkt (>700 Mio. MAU: Sonderlizenz nötig)NeinNutzerbeschränkung, Namensnennung, NutzungsverboteLlama 2, Llama 3
Mistral License (MNPL)NeinJa, mit EinschränkungenNeinEinschränkungen bei bestimmten AnwendungsfällenÄltere Mistral-Modelle

Apache 2.0 und MIT: Echtes Open Source

Modelle unter Apache 2.0 oder MIT-Lizenz erfüllen die Kriterien der Open Source Initiative vollständig. Sie erlauben kommerzielle Nutzung, Veränderung und Weiterverbreitung ohne wesentliche Einschränkungen. Apache 2.0 enthält zusätzlich eine explizite Patentlizenz, die bei KI-Modellen relevant sein kann, wenn der Anbieter Patente auf Teile der Architektur hält.

GPL 3.0: Copyleft als Komplexitätsfaktor

Die GNU General Public License verlangt, dass abgeleitete Werke ebenfalls unter GPL veröffentlicht werden. Im KI-Kontext ist die entscheidende Frage, ob ein Fine-Tuning oder eine Integration in eine größere Software ein „abgeleitetes Werk" darstellt. Diese Frage ist rechtlich ungeklärt und birgt erhebliche Unsicherheit. Für Unternehmen, die ihre Anpassungen nicht offenlegen wollen, ist die GPL daher oft ein Ausschlusskriterium.

Llama Community License: Das „Faux Open Source"-Problem

Metas Llama-Modelle werden häufig als Open Source bezeichnet. Tatsächlich unterliegen sie der Llama Community License, die wesentliche Einschränkungen enthält:

  • Nutzerbeschränkung: Unternehmen mit mehr als 700 Millionen monatlich aktiven Nutzern benötigen eine gesonderte Lizenz von Meta.
  • Nutzungsverbote: Bestimmte Anwendungsfälle (z. B. Verwendung zur Verbesserung anderer großer Sprachmodelle) sind untersagt.
  • Namensnennung und Branding: Die Nutzung des Namens „Llama" unterliegt Einschränkungen.

Diese Bedingungen verstoßen gegen mehrere Grundprinzipien der Open Source Definition der OSI, insbesondere gegen das Diskriminierungsverbot gegenüber Personen/Gruppen (Kriterium 5) und das Verbot von Nutzungseinschränkungen (Kriterium 6).

Die Open Source Initiative hat 2024 eine eigene Definition für Open-Source-KI veröffentlicht, die explizit fordert, dass ein Modell ohne Nutzungseinschränkungen verwendet, studiert, verändert und geteilt werden kann. Llama erfüllt diese Kriterien nicht.

Warum das für Unternehmen relevant ist: Wer sich auf die „Open-Source-Ausnahme" des AI Act (Art. 2 Abs. 12 VO (EU) 2024/1689) berufen will, muss prüfen, ob die Lizenz tatsächlich den Anforderungen einer „freien und quelloffenen Lizenz" im Sinne der Verordnung entspricht. Ob die Llama-Lizenz diese Schwelle erreicht, ist rechtlich umstritten. Die sicherere Annahme ist, dass Modelle wie Llama nicht unter die Open-Source-Ausnahme fallen.


API- und SaaS-Nutzungsbedingungen: Die versteckten Fallstricke

Nutzungseinschränkungen (Acceptable Use Policies)

Nahezu alle API-Anbieter definieren in ihren Nutzungsbedingungen umfangreiche Acceptable Use Policies (AUP). Diese verbieten typischerweise:

  • Erzeugung illegaler Inhalte
  • Desinformation und manipulative Inhalte
  • Militärische und überwachungsbezogene Anwendungen
  • Automatisierte Entscheidungen ohne menschliche Aufsicht

Die Grenzen sind oft vage formuliert. Was genau unter „Desinformation" oder „manipulativ" fällt, liegt im Ermessen des Anbieters. Ein Verstoß kann zur sofortigen Sperrung des Zugangs führen -- ohne Vorwarnung und ohne Möglichkeit der Datenrettung.

Aus Sicht des deutschen AGB-Rechts (§§305--310 BGB) sind solche Klauseln nicht automatisch wirksam. Insbesondere überraschende Klauseln (§305c Abs. 1 BGB) und unangemessene Benachteiligungen (§307 Abs. 1 BGB) können unwirksam sein. Allerdings: Die Unwirksamkeit einer Klausel hilft wenig, wenn der Anbieter den Zugang bereits technisch gesperrt hat und der Sitz in den USA liegt.

Output-Rechte: Wem gehört das Ergebnis?

Die meisten API-Anbieter übertragen in ihren Terms of Service die Rechte am Output auf den Nutzer -- jedoch mit erheblichen Einschränkungen:

  • OpenAI überträgt die Rechte am Output, behält sich aber das Recht vor, Input und Output für die Verbesserung der Modelle zu nutzen (sofern nicht deaktiviert).
  • Anthropic überträgt die Rechte am Output und nutzt API-Inputs standardmäßig nicht für das Training.
  • Google überträgt bei Gemini API die Output-Rechte, schließt aber bestimmte Nutzungen (z. B. Training konkurrierender Modelle) aus.

Entscheidend ist: Output-Rechte sind nicht gleichbedeutend mit Urheberrechten. Wie in unserem Artikel zu KI und Urheberrecht erläutert, genießen rein KI-generierte Inhalte nach deutschem Recht (§§2, 7 UrhG) keinen urheberrechtlichen Schutz. Die vertragliche Rechteübertragung schafft also nur ein relatives Recht zwischen den Vertragsparteien, keinen absoluten Schutz gegenüber Dritten.

Trainingsklauseln: Werden Ihre Daten verwendet?

Eine der kritischsten Fragen bei API-Nutzung ist, ob der Anbieter Ihre Inputs und Outputs zum Training zukünftiger Modelle verwendet. Die Regelungen unterscheiden sich erheblich:

  • Verbraucher-Produkte (ChatGPT Free, Gemini Free): Inputs werden standardmäßig für das Training verwendet.
  • API-Zugang: Die meisten Anbieter nutzen API-Daten nicht für das Training -- aber die Formulierungen variieren, und es gibt Ausnahmen (z. B. für Abuse-Monitoring).
  • Enterprise-Verträge: Hier wird Training mit Kundendaten typischerweise vertraglich ausgeschlossen.

Unternehmen, die personenbezogene Daten oder Geschäftsgeheimnisse über APIs verarbeiten, müssen die Trainingsklauseln sorgfältig prüfen. Eine pauschale Einwilligung in die Datennutzung zu Trainingszwecken kann gegen die DSGVO (insbesondere Art. 5 Abs. 1 lit. b -- Zweckbindung) verstoßen.

Änderungsvorbehalte: Die AGB können sich jederzeit ändern

Ein besonders tückischer Aspekt von API-Nutzungsbedingungen sind einseitige Änderungsvorbehalte. Die meisten Anbieter behalten sich das Recht vor, Nutzungsbedingungen, Preise und sogar die verfügbaren Modelle jederzeit zu ändern. Nach deutschem AGB-Recht (§308 Nr. 4 BGB) sind solche Vorbehalte nur wirksam, wenn die Änderung für den Nutzer zumutbar ist -- ein unbestimmter Rechtsbegriff, der im Streitfall ausgelegt werden muss.

In der Praxis bedeutet das: Ein Unternehmen, das einen geschäftskritischen Prozess auf eine API aufbaut, geht das Risiko ein, dass sich die Bedingungen ändern, ohne dass es darauf Einfluss nehmen kann.


Proprietäre Lizenzen: Kontrollierte Umgebung mit eigenen Risiken

Audit-Rechte und Compliance-Nachweise

Proprietäre Lizenzverträge enthalten häufig Audit-Klauseln, die dem Anbieter das Recht einräumen, die lizenzgerechte Nutzung zu überprüfen. Im KI-Kontext betrifft das insbesondere die Frage, ob das Modell nur für die vertraglich vereinbarten Zwecke eingesetzt wird und ob die vereinbarte Nutzerzahl eingehalten wird.

Gleichzeitig können Unternehmen als KI-Betreiber nach dem AI Act (Art. 26 VO (EU) 2024/1689) verpflichtet sein, die Funktionsweise des eingesetzten KI-Systems zu dokumentieren und zu überwachen. Bei proprietären Modellen, deren Architektur und Trainingsmethodik nicht offengelegt werden, kann diese Pflicht faktisch nicht oder nur eingeschränkt erfüllt werden -- ein Spannungsfeld, das der Gesetzgeber bislang nicht aufgelöst hat.

Vendor Lock-in

Die Abhängigkeit von einem proprietären KI-Anbieter geht über die reine Softwarenutzung hinaus. Im KI-Bereich umfasst der Lock-in-Effekt:

  • Modellspezifische Anpassungen: Prompts, Fine-Tuning-Daten und Integrationen sind häufig nicht auf andere Modelle übertragbar.
  • Datenformate und APIs: Proprietäre Schnittstellen folgen keinem einheitlichen Standard.
  • Vertragliche Bindung: Mindestlaufzeiten, Kündigungsfristen und Datenmigrations-Klauseln erschweren den Wechsel.

Aus Compliance-Sicht ist Lock-in problematisch, weil das Unternehmen im Fall einer regulatorischen Änderung -- etwa einer Neubewertung des Risikos nach dem AI Act -- möglicherweise nicht schnell genug auf eine alternative Lösung umsteigen kann.


AI Act: Pflichten je nach Lizenzmodell

Die VO (EU) 2024/1689 differenziert bei den Anbieterpflichten nach der Art der Bereitstellung. Für Unternehmen, die KI-Modelle auswählen, ergibt sich folgendes Bild:

Open Source (echtes Open Source nach OSI-Definition)

  • Art. 2 Abs. 12: Ausnahme von den meisten Pflichten, sofern das Modell nicht in einem Hochrisiko-Kontext (Anhang III) oder für verbotene Praktiken (Art. 5) eingesetzt wird.
  • Art. 53 Abs. 2: GPAI-Modelle mit offenen Gewichten unter einer echten Open-Source-Lizenz müssen nur eine reduzierte Dokumentation bereitstellen (im Wesentlichen: die Modellkarte und eine Zusammenfassung der Trainingsdaten).
  • Wichtig: Die Erleichterung entfällt vollständig, wenn das Modell ein systemisches Risiko darstellt (Art. 51 Abs. 2). In diesem Fall gelten dieselben Pflichten wie für geschlossene Modelle.

Proprietär und API/SaaS

  • Keine Ausnahmen: Proprietäre Anbieter und API-Dienstleister unterliegen den vollständigen Anbieter-Pflichten nach dem AI Act.
  • GPAI-Pflichten (Art. 53 Abs. 1): Umfassende Dokumentation, Transparenz gegenüber nachgelagerten Anbietern, Einhaltung des Urheberrechts.
  • Transparenzpflichten (Art. 50): Kennzeichnung von KI-generierten Inhalten, Hinweis auf die KI-Nutzung.

Betreiberpflichten -- unabhängig vom Lizenzmodell

Unabhängig davon, ob ein Unternehmen ein proprietäres, ein Open-Source- oder ein API-basiertes Modell einsetzt: Als Betreiber (Deployer) im Sinne des AI Act gelten die Betreiberpflichten nach Art. 26 immer. Dazu gehören insbesondere:

  • Sicherstellung der bestimmungsgemäßen Nutzung
  • Menschliche Aufsicht bei Hochrisiko-Systemen
  • Information der betroffenen Personen
  • Überwachung auf Risiken

Das bedeutet: Die Open-Source-Ausnahme entlastet den Anbieter, nicht den Betreiber. Ein Unternehmen, das Llama in einem Bewerbungsprozess einsetzt, trägt dieselben Betreiberpflichten wie bei der Nutzung von GPT-4.


Entscheidungshilfe: Wann welches Modell?

Die Wahl des richtigen Lizenzmodells hängt von mehreren Faktoren ab. Hier eine Orientierung:

Open Source / Open Weights eignet sich, wenn:

  • Das Unternehmen über eigene ML-Kompetenz verfügt
  • Datenschutz höchste Priorität hat (Self-Hosting)
  • Maximale Anpassbarkeit gefragt ist (Fine-Tuning, domänenspezifische Modelle)
  • Langfristige Unabhängigkeit von einzelnen Anbietern gewünscht ist
  • Die Lizenz tatsächlich die geplante Nutzung erlaubt (Vorsicht bei Llama und ähnlichen Lizenzen)

API / SaaS eignet sich, wenn:

  • Schnelle Integration ohne eigene Infrastruktur gewünscht ist
  • Die Nutzung variabel ist und ein Pay-per-Use-Modell wirtschaftlich sinnvoller ist
  • Kein hochsensibles Datenumfeld vorliegt
  • Die AGB des Anbieters sorgfältig geprüft und für akzeptabel befunden wurden
  • Das Unternehmen einen Plan für den Fall hat, dass der Anbieter den Dienst einstellt oder die Bedingungen ändert

Proprietäre Lizenzen eignen sich, wenn:

  • Ein klar definierter Anwendungsfall vorliegt, der eine spezialisierte Lösung erfordert
  • Vertraglich garantierter Support und SLAs (Service Level Agreements) notwendig sind
  • Regulatorische Anforderungen eine definierte Verantwortungskette verlangen
  • Das Unternehmen keine eigene KI-Infrastruktur aufbauen kann oder will

In der Praxis setzen viele Unternehmen auf einen hybriden Ansatz: API-Zugang für explorative Anwendungen, Open-Source-Modelle für datenintensive und datenschutzkritische Aufgaben, proprietäre Lösungen für spezifische, regulierte Anwendungsfälle.


FAQ: Häufige Fragen zu KI-Lizenzen

Ist Llama wirklich Open Source?

Nein, nicht im Sinne der OSI-Definition. Metas Llama-Modelle werden unter der Llama Community License veröffentlicht, die kommerzielle Nutzungseinschränkungen enthält (insbesondere die Schwelle von 700 Millionen monatlich aktiven Nutzern). Die Open Source Initiative hat 2024 eine eigene Definition für Open-Source-KI veröffentlicht, die Llama nicht erfüllt. Ob Llama unter die Open-Source-Ausnahme des AI Act (Art. 2 Abs. 12 VO (EU) 2024/1689) fällt, ist rechtlich umstritten.

Darf der API-Anbieter meine Inputs für das Training verwenden?

Das hängt von den konkreten Nutzungsbedingungen ab. Bei Verbraucher-Produkten (z. B. ChatGPT Free) werden Inputs standardmäßig für das Training genutzt. Bei API-Zugängen schließen die meisten Anbieter dies aus, jedoch gibt es Ausnahmen. Unternehmen sollten die Trainingsklauseln vor Vertragsschluss prüfen und bei Bedarf eine Data Processing Addendum (DPA) vereinbaren. Werden personenbezogene Daten verarbeitet, gelten zusätzlich die Anforderungen der DSGVO (Art. 5 Abs. 1 lit. b -- Zweckbindung, Art. 28 -- Auftragsverarbeitung).

Welche AI-Act-Pflichten habe ich als Betreiber eines Open-Source-Modells?

Als Betreiber gelten dieselben Pflichten wie bei proprietären Modellen. Die Open-Source-Ausnahme (Art. 2 Abs. 12 und Art. 53 Abs. 2 VO (EU) 2024/1689) entlastet nur den Anbieter des Modells, nicht das Unternehmen, das es einsetzt. Betreiberpflichten nach Art. 26 -- insbesondere menschliche Aufsicht, bestimmungsgemäße Nutzung und Information der Betroffenen -- gelten uneingeschränkt.

Kann ich von einem proprietären KI-Anbieter zu einem anderen wechseln?

Grundsätzlich ja, aber in der Praxis ist der Wechsel oft mit erheblichem Aufwand verbunden. Prompts, Fine-Tuning-Daten und Integrationen sind häufig modellspezifisch und nicht direkt übertragbar. Unternehmen sollten bei Vertragsschluss auf Datenexport-Klauseln und Migrationshilfen achten. Aus AI-Act-Perspektive empfiehlt es sich, die KI-Dokumentation so anzulegen, dass sie modellagnostisch ist -- also nicht von einem bestimmten Anbieter abhängt.

Sind die AGB von US-amerikanischen KI-Anbietern in Deutschland wirksam?

AGB unterliegen in Deutschland der Inhaltskontrolle nach §§305--310 BGB. Überraschende Klauseln (§305c Abs. 1 BGB) und unangemessene Benachteiligungen (§307 Abs. 1 BGB) sind unwirksam -- auch wenn die AGB eine Rechtswahl zugunsten US-amerikanischen Rechts enthalten, sofern der Nutzer Verbraucher ist (Art. 6 Abs. 2 Rom-I-VO). Bei B2B-Verhältnissen ist die Rechtslage komplexer; hier kann eine Rechtswahlklausel grundsätzlich wirksam sein, unterliegt aber den Grenzen des ordre public (Art. 21 Rom-I-VO).


Fazit: Lizenzen sind kein Nebenthema

Die Wahl des KI-Lizenzmodells hat Auswirkungen auf Datenschutz, Haftung, Compliance, Kosten und strategische Flexibilität. Ein sorgfältiger Lizenzvergleich gehört daher in jede KI-Strategie -- nicht als Fußnote, sondern als zentraler Bestandteil der Entscheidungsfindung.

Unternehmen sollten insbesondere drei Dinge beachten:

  1. „Open Source" kritisch prüfen: Nicht jedes Modell mit offenen Gewichten ist OSI-konformes Open Source. Die konkreten Lizenzbedingungen bestimmen, was erlaubt ist -- und ob die AI-Act-Ausnahme greift.
  2. AGB lesen -- wirklich: API-Nutzungsbedingungen enthalten Klauseln zu Output-Rechten, Trainingsverwendung und Änderungsvorbehalten, die geschäftskritische Auswirkungen haben können.
  3. Betreiberpflichten sind lizenzunabhängig: Egal ob Open Source, proprietär oder API -- als Betreiber eines KI-Systems gelten die AI-Act-Pflichten nach Art. 26 VO (EU) 2024/1689 immer.

Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für die Bewertung konkreter KI-Lizenzen im Unternehmenskontext empfehlen wir die Hinzuziehung spezialisierter Rechtsberatung.


Sie möchten Ihr Team für den rechtskonformen Umgang mit KI-Lizenzen schulen? KI Comply bietet praxisnahe Schulungen, die Lizenzrecht, AI Act und Datenschutz verbinden -- zugeschnitten auf Ihre Branche und Ihre eingesetzten KI-Systeme. Jetzt informieren →

Rechtsquellen

  • Software-Urheberrecht§§69a-69g UrhG
  • AI Act Open SourceArt. 2 Abs. 12, Art. 53 Abs. 2 VO (EU) 2024/1689 (Quelle)
  • AGB-Recht§§305-310 BGB

Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für eine rechtliche Bewertung Ihres konkreten Falls wenden Sie sich bitte an einen spezialisierten Rechtsanwalt.

Artikel teilen:

Machen Sie Ihr Team KI-fit

Mit unserer Online-Schulung erfüllen Sie die Anforderungen der KI-Verordnung - einfach und effizient.

Preise ansehen