Open-Source-Modelle und DORA

Der vorherrschende Geschäftsargument für Open-Source-Modelle im Unternehmenseinsatz von KI lautet Kostensenkung — doch dieser Fokus verdeckt einen strukturellen Vorteil, der für stark regulierte Branchen von größerer Bedeutung ist. Open-Source-Modelle DORA Compliance ist der entscheidende Unterschied: Organisationen, die Open-Weight-Sprachmodelle selbst hosten, eliminieren regulatorische Risiken, die bei vendor-hosted Alternativen unter dem Digital Operational Resilience Act (DORA) entstehen [1]. Konkret beseitigt Self-Hosting die IKT-Drittanbieterbeziehung, die die Meldepflichten nach Artikel 21 auslöst, weil das Modell im eigenen Perimeter läuft statt über einen externen Dienstleister.

TL;DR: Open-Source-Modelle, die lokal betrieben werden, eliminieren die DORA-Artikel-21-Exposition gegenüber IKT-Drittanbietern, wodurch die 24-Stunden-Meldepflicht entfällt. Dieser strukturelle Vorteil macht das Eigenhosting zur compliance-orientierten Architektur für Finanzdienstleister, Gesundheitswesen und Rechtsabteilungen, die sensible regulierte Daten verarbeiten.

Wichtigste Erkenntnisse

• Kernthese: Eigengehostete Open-Weight-LLMs beseitigen die IKT-Drittanbieterbeziehungen nach DORA Artikel 21, wodurch die obligatorische 24-Stunden-Vorfallsmeldung entfällt.
• Technische Grundlage: Open-Weight-Modelle (Apache 2.0, MIT-lizenziert), die als Weights ausgeliefert werden, ermöglichen vollständige Deployment-Kontrolle ohne Vendor-hosted-API-Abhängigkeit.
• Regulatorischer Auslöser: Vendor-hosted-Modelle erzeugen IKT-Drittanbieterbeziehungen nach DORA Artikel 21, die Eigenhosting vollständig vermeidet.
• Compliance-Vereinfachung: Datensouveränität, Prompt-Vertraulichkeit und Modell-Auditerbarkeit werden zu infrastrukturellen Garantien statt zu vertraglichen Zusagen.
• Strategische Dimension: Das Open-Source-Lizenz-Ökosystem (Apache 2.0, MIT) bietet die rechtliche Planungssicherheit, die Closed-Source-Alternativen (Llama Community License) für in der EU ansässige Organisationen nicht garantieren.

Regulatorischer Kontext: DORA Artikel 21 und die IKT-Lieferkette

DORA Artikel 21 etabliert Meldepflichten für Finanzinstitute in Bezug auf größere IKT-bezogene Vorfälle [1]. Wenn ein Unternehmen ein vendor-hosted LLM über eine Cloud-API nutzt, besteht die IKT-Dienstleisterbeziehung — und jeder Ausfall, Datenleck oder Dienstunterbrechung kann die 24-Stunden-Meldepflicht für größere Vorfälle auslösen. Die Leitlinien der Europäischen Bankenaufsicht zu DORA betonen, dass das IKT-Drittanbieter-Risikomanagement sich auf alle Dienstleister erstreckt, die Daten im Auftrag des Finanzinstituts verarbeiten oder speichern [2].

Die Europäische Wertpapier- und Marktaufsichtsbehörde (ESMA) hat in ihren Leitlinien 2025 bestätigt, dass Cloud-basierte KI-Dienste in den Anwendungsbereich der IKT-Drittanbieter-Risikomanagementanforderungen fallen [3]. Dies schafft ein Compliance-Paradox: Die gleichen KI-Fähigkeiten, die die operative Effizienz steigern, führen gleichzeitig regulatorische Meldeauflagen ein, die Eigenhosting-Alternativen vermeiden.

Vendor-Hosted vs. Eigenhosting: Die Architektur-Unterscheidung

Unternehmen stehen vor einer binären architektonischen Wahl für LLM-Deployments. Vendor-hosted-Modelle begründen per Definition eine IKT-Drittanbieterbeziehung, da das Modell auf Infrastruktur läuft, die das Unternehmen weder besitzt noch kontrolliert. Eigengehostete Open-Weight-Modelle kehren diese Beziehung um: Wenn ein Unternehmen Modellgewichte herunterlädt und Inference auf eigener Infrastruktur betreibt, existiert keine IKT-Drittanbieterbeziehung im DORA-Sinne. Das LLM wird nicht "durch Drittanbieter ermöglicht", wie die EMA-Richtlinien für extern gehostete Modelle beschreiben — es wird durch interne Infrastruktur ermöglicht. Die EMA-Klassifikation unterscheidet explizit "third-party, externally hosted" von "(re)trained internally", wobei Letzteres "extensive customisation, including bespoke interfaces, integration with internal data sources for retrieval augmented generation, and fine-tuning performance" bietet [4].

Anschauliches Szenario:

Eine Vermögensverwaltungsgesellschaft nutzt ein vendor-hosted LLM für die Überprüfung von Compliance-Dokumenten. Während eines globalen Cloud-Ausfalls beim Anbieter kann die Firma Client-Onboarding-Dokumentation nicht verarbeiten. Nach DORA Artikel 21 könnte dieser Dienstausfall als größerer Vorfall gelten, der eine 24-Stunden-Meldung an die zuständige nationale Behörde erfordert — regulatorischer Meldeaufwand während einer operativen Krise. Dieselbe Firma, die ein vergleichbares Open-Weight-Modell lokal betreibt, erfährt keine API-Abhängigkeit, keine IKT-Drittanbieterbeziehung nach DORA und keine Vorfallsmeldepflicht.

Open-Source-Lizenzen und der EU-Rechtsrahmen

Open-Source-Modelle unter Apache 2.0 oder MIT-Lizenzen bieten die Rechtssicherheit, die DORA für IKT-Drittanbieter-Risikomanagement verlangt. Echte Open-Source-Modelle — wie sie von der Open Source Initiative definiert werden — bieten klare Nutzungsrechte ohne Zweckbeschränkungen oder rückwirkende Verbote. Für in der EU ansässige Unternehmen stellt die Llama 4 Community License eine spezifische Einschränkung dar, die Open-Weight-Alternativen wie Mistral Small 3 (Apache 2.0) nicht auferlegen [5] [6].

Content-Filtering bleibt eine bewusste architektonische Anforderung für Eigenhosting-Deployments. Open-Weight-Modelle werden ohne die Guardrails ausgeliefert, die in Hosted-APIs eingebaut sind. Ein produktionsreifer Eigenhosting-Stack umschließt das Modell daher mit Klassifikatoren oder Open-Source-Sicherheitsfiltern, die Eingaben und Ausgaben auf schädlichen, nicht konformen oder datenleckenden Inhalt prüfen, bevor eine Antwort den Nutzer erreicht.

Betriebliche Realitäten: Wann Eigenhosting nicht passt

Eigenhosting von LLM-Infrastruktur erfordert DevOps- oder MLOps-Kapazitäten. Jemand muss GPU-Provisionierung, Inference-Optimierung und Modell-Updates verwalten. Kleine Organisationen mit geringem oder unvorhersehbarem Abfrageaufkommen werden feststellen, dass API-Kosten die Infrastrukturkosten unterschreiten. Teams, die absolute Frontline-Fähigkeiten von OpenAI oder Anthropic benötigen, könnten bei Open-Source-Alternativen bei multimodaler Verarbeitung oder komplexer Tool-Nutzung zurückfallen.

Der ArXiv 2601.09527 berichtet von Inference-Kosten von 0,001–0,04 $ pro Million Tokens (Strom nur) — 40–200× günstiger als Cloud-APIs auf Budget-Niveau — wobei sich die Hardware-Investition bei moderatem Abfrageaufkommen innerhalb von vier Monaten amortisiert. Die tatsächlichen Hardware-Kosten hängen von Modellgröße und Inferenz-Framework ab; Deployments reichen von Consumer-GPUs bis zu Server-grade-Setups.

Infrastrukturelle Souveränität als Compliance-Strategie

Der Übergang von vendor-hosted zu selbstgehosteten Open-Source-Modell-Deployments stellt mehr als eine operative Veränderung dar — er begründet eine grundlegende Neuordnung der ICT-Risikosteuerung unter DORA Artikel 21. Wenn das Modell im eigenen Perimeter läuft, wird der regulatorische Auslöser nicht aktiviert — die Compliance-Position verschiebt sich von reaktiver Meldung zu präventiver architektonischer Gestaltung.

Datensouveränität und Modell-Auditerbarkeit transformieren sich von vertraglichen Zusagen in infrastrukturelle Garantien, wenn Organisationen Open-Source-Modelle intern betreiben. Content-Filtering wird zur expliziten operativen Anforderung statt zum impliziten Service-Feature — produktionsreife Eigenhosting-Stacks umschließen Modelle mit Klassifikatoren oder Open-Source-Sicherheitsfiltern, die Eingaben und Ausgaben auf schädlichen, nicht konformen oder datenleckenden Inhalt prüfen, bevor Antworten Nutzer erreichen. Diese architektonische Transparenz ermöglicht Compliance-Teams unabhängige Überprüfungen von Modellverhalten, Sicherheitsposturen und Datenhandhabungspraktiken ohne Abhängigkeit von Vendor-Zusicherungen oder vertraglichen Garantien.

Die betrieblichen Realitäten des Eigenhostings erfordern spezifische technische Fähigkeiten. Organisationen müssen GPU-Infrastruktur provisionieren, Inference-Optimierung durchführen und Modell-Update-Pipelines warten — Fähigkeiten, die sich mit lokalen Deployment-Pipelines verbinden. Die Hardware-Investitionen hängen von Modellgröße und Deployment-Scale ab, mit verbessernden Kostenstrukturen bei steigendem Abfrageaufkommen.

Die Infrastruktur-Anforderungen für selbstgehostete Modelle verbinden sich mit Compliance-Engine-Frameworks, die speziell für DORA Artikel 21 Anforderungen konzipiert sind.

Organisationen, die ihre regulatorische Positionierung evaluieren, sollten prüfen, wie Compliance-Engine-Frameworks in Unternehmens-AI-Strategien integriert werden, die speziell für DORA Artikel 21 Anforderungen konzipiert sind.

Fazit: Infrastrukturelle Souveränität als Compliance-Strategie

Der Fokus auf Eigenhosting von Open-Source-LLMs hat sich von Kosteneffizienz auf regulatorische Architektur verschoben. Finanzdienstleister, Versicherer, Gesundheitsdienstleister und Rechtsabteilungen, die sensible regulierte Daten verarbeiten, stehen vor einer eindeutigen strukturellen Präferenz für Eigenhosting von Open-Weight-Deployments: Die Beseitigung der DORA-Artikel-21-Exposition gegenüber IKT-Drittanbieter-Lieferketten entbindet von einer ganzen Kategorie obligatorischer 24-Stunden-Vorfallsmeldungen. Wenn das Modell im eigenen Perimeter läuft, wird der regulatorische Auslöser nicht aktiviert. Die Compliance-Position verschiebt sich von vertraglichem Risikomanagement zu infrastruktureller Kontrolle. Unternehmen, die LLM-Strategien bewerten, sollten diese regulatorische Vereinfachung als primäres architektonisches Kriterium gewichten — zusammen mit Datensouveränität und langfristiger Kostenvorhersehbarkeit.