Future{hacks}: Eigene Modelle, eigene Regeln: Wie Europa 2026 die KI-Karten neu mischt

Der erste Arbeitstag im neuen Jahr. Der Kaffee dampft, der Posteingang füllt sich, und zwischen Jahresplanungen und Budget-Mails blitzen zwei Meldungen auf, die den Ton für 2026 setzen: Europa startet mit JUPITER ins neue Jahr, und Future{hacks} ist zurück – ab sofort im Zweiwochentakt, weiterhin mit Tiefe, klaren Zahlen und umsetzbaren Entscheidungen.

JUPITER macht europäische Rechenleistung real

JUPITER, Europas erster Exascale-Supercomputer am Forschungszentrum Jülich, läuft seit Ende 2025 im Produktivbetrieb. Seit 12.01. ist eine neue Zugangsrunde für Rechenleistung offen (Zuteilung ab 01.05.), die erstmals auch Unternehmensprojekte systematisch einbezieht. Das bedeutet konkret: Teams können Training und Feintuning großer Modelle mit europäischer Recheninfrastruktur einplanen – Vorhaben, die bisher an Rechenkosten oder Compliance-Hürden scheiterten.

Wer JUPITER-Rechenzeit nutzt, kann ein 70-Milliarden-Parameter-Modell deutlich schneller feintunen – bei kontrollierbaren Kosten und ohne dass Trainingsdaten die EU verlassen müssen. Ein europäischer Standort vereinfacht die Dokumentation von Datenflüssen für Audits, verkürzt Abstimmungswege mit Datenschutzbeauftragten und erhöht die Verhandlungsposition gegenüber Cloud-Anbietern. Das reduziert nicht jedes Risiko, aber es macht Entscheidungswege direkter.

Parallel verschärft die Regulierung ihre Anforderungen. Der EU AI Act verlangt ab August 2026 von Anbietern hochriskanter KI-Systeme eine technische Dokumentation mit Modellarchitektur, Trainingsdaten-Beschreibung, Leistungsmetriken und Risikobewertung. Für jedes eingesetzte Modell muss nachweisbar sein: Welche Version, trainiert auf welchen Daten, mit welcher Genauigkeit, für welchen Zweck.

Open LLMs haben hier einen strukturellen Vorteil: Die vollständige Kontrolle über Modell-Versionierung, Trainings-Pipelines und Artefakte macht diese Dokumentation zur Routine statt zum Nacharbeits-Projekt. Wer bei geschlossenen APIs auf Anbieter-Dokumentation angewiesen ist, muss darauf vertrauen, dass diese EU-konform und aktuell bleibt. Wer heute beginnt, Modelle, Datenquellen und Artefakte konsequent zu versionieren, spart später Wochen in Compliance-Audits.

Was Open LLMs wirklich bedeuten

Open LLMs sind Sprachmodelle unter Open-Source-Lizenzen, die man als Modelldateien beziehen, auf eigener Infrastruktur betreiben und auf eigene Daten feintunen kann – im Gegensatz zu API-basierten Diensten wie GPT-4 oder Claude, bei denen die Modelle beim Anbieter bleiben. Entscheidend ist die Lizenz: Apache 2.0, MIT oder Llama Community License definieren, ob kommerzielle Nutzung, Modifikation oder Weitergabe erlaubt sind.

Die Leistungsabstände zwischen den besten geschlossenen und den besten offenen Modellen sind in vielen Kernaufgaben so klein geworden, dass die Wahl nicht mehr an einer Benchmarkzahl hängt. Auf dem MMLU-Benchmark (Massive Multitask Language Understanding) erreichte GPT-4 im Dezember 2024 86,4%¹, während Llama 3.1 405B bei 85,2% liegt². Bei Coding-Aufgaben auf HumanEval erreicht Claude 3.5 Sonnet 92,0%³, Qwen 2.5 Coder 32B kommt auf 89,5%⁴.

Liegt die Qualität von Open LLMs nah an geschlossenen Modellen, zählen Freiheitsgrade, Kostenkontrolle und Update-Tempo stärker als der Markenname. Drei Zahlen entscheiden. Qualität: Welches Modell schneidet auf zehn bis fünfzehn typischen Aufgaben besser ab? Kosten: Preis pro 1M Token – API oder eigene Infrastruktur? Update-Tempo: Wie viele Stunden vom Feintuning bis live?

Diese Zahlen zeigen in der Praxis: Bei ähnlicher Qualität liegt der Kostenvorteil von Open LLMs bei etwa 90% für kontinuierlichen Betrieb. Gleichzeitig bietet Self-Hosting volle Kontrolle über Datenstandort und Update-Zyklen – entscheidend für regulierte Branchen.

Die Wahl hängt vom Anwendungsfall ab. Open LLMs punkten bei: Kundenservice mit sensiblen Daten (Versicherung, Banking), interne Wissensdatenbanken mit Geschäftsgeheimnissen, Übersetzung vertraulicher Dokumente, oder Branchen-Chatbots mit spezialisiertem Vokabular. Geschlossene APIs bleiben stärker bei: Schneller Prototyping-Phase (wo Investition in Infrastruktur noch nicht lohnt), komplexen Multi-Tool-Orchestrierungen (Function Calling mit 20+ Tools), oder Spezialfähigkeiten wie fortgeschrittene Code-Generierung und Reasoning. Die Faustregel: Wenn Datenhoheit, Kostenvorhersagbarkeit oder Compliance kritisch sind, prüfe Open. Wenn Geschwindigkeit und Feature-Breite zählen, starte mit APIs.

Portfolio statt Monokultur

Open LLMs machen am meisten Sinn in einer Architektur, die Wechsel erlaubt. Statt „GPT-4 für alles“ oder „Llama für alles“ nutzen kluge Teams beides: Open LLMs für Aufgaben mit strengen Daten-Anforderungen, geschlossene APIs für spezialisierte Features. Mit einer neutralen Abstraktionsschicht (OpenAI-kompatibles Protokoll), versionierten Prompts und Canary-Deployments dauert der Wechsel zwischen Modellen etwa sechs Stunden. Ohne diese Grundlagen werden aus geplanten Wechseln Notfallaktionen.

Drei konkrete Schritte für 2026

Begriffe klären, Lizenzen prüfen. Open LLMs sind selbst betreibbare Modelle unter Open-Source-Lizenzen. Nicht alle Lizenzen erlauben kommerzielle Nutzung oder Modifikation. Apache 2.0 und MIT sind permissiv und erlauben fast alles. Die Llama Community License hat eine Einschränkung: Unternehmen mit über 700 Millionen monatlichen Nutzern brauchen eine separate Meta-Lizenz. Mistral-Modelle nutzen Apache 2.0, Qwen-Modelle teilweise eigene Lizenzen mit Export-Beschränkungen für bestimmte Länder. Gemma von Google hat Nutzungsbeschränkungen für bestimmte Anwendungen. Die Praxis: Für jedes Modell im Evaluierungsprozess die Lizenz dokumentieren, mit der Rechtsabteilung klären und in einem Lizenz-Register pflegen, bevor Entwicklungsressourcen investiert werden.

Messen statt diskutieren. Für zwei laufende Use Cases jeweils zehn bis fünfzehn typische Anfragen aus der Produktion nehmen, anonymisieren und als Test-Set fixieren. GPT-4, Claude und zwei Open-Source-Kandidaten (z.B. Llama 3.1 70B, Qwen 2.5 72B) parallel testen. Qualität von zwei Personen unabhängig bewerten auf Skala 1-5, Durchschnitt bilden. Kosten pro million Tokens ausrechnen: für APIs die Pricing-Seite, für Self-Hosting die Rechenzeit auf p4d oder g5-Instanzen. Update-Zeit vom Feintuning bis Live als KPI in den Wochenreport aufnehmen – messbar in Stunden, nicht in Gefühlen.

Die europäische Karte spielen. JUPITER und andere EU-Rechenzentren für Feintuning-Projekte evaluieren. Herkunft von Modellen und Trainingsdaten konsequent versionieren: welche Modellversion, von welcher Quelle, welches Trainingsdatum, welche Lizenz. Jeden Modelleinsatz protokollieren mit Timestamp, Anwendungsfall und verantwortlicher Person. Diese Dokumentation ist ab August 2026 für hochriskante KI-Systeme Pflicht – wer jetzt beginnt, vermeidet später den Audit-Stress.

Unser Future{hacks} Fazit

Open LLMs kommen 2026 auf Augenhöhe mit geschlossenen Modellen – nicht in jeder Disziplin, aber in genug Fällen, dass die Wahl zur echten Abwägung wird. Geschlossene Angebote bleiben stark, wo umfassendes Tooling, fortgeschrittene Guardrails oder Spezialmodelle den Ausschlag geben. Dazwischen liegt der Raum, in dem Unternehmen mit Architektur gewinnen.

Wer Qualität auf eigenen Aufgaben misst, Kosten pro Million Tokens transparent rechnet und die Update-Zeit im Griff hat, entscheidet mit Zahlen statt mit Slogans. Europäische Recheninfrastruktur wie JUPITER und klare Regulierung wie der EU AI Act sind kein Ballast, sondern strategische Vorteile gegenüber US-Hyperscalern. Genau dort setzen wir an. Future{hacks} ist zurück, ab jetzt alle zwei Wochen.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.