Aleph Alpha und Cohere verhandeln Fusion

Deutsch-kanadische KI-Fusion mit Bund als Ankerkunde plus Project Spark: Was europäische KI-Souveränität für Teams jetzt konkret heißt.

8 Min. Lesezeit

Das deutsche KI-Unternehmen Aleph Alpha und die kanadische Cohere sprechen über eine Fusion. Initiiert wurde das Vorhaben von Bundesdigitalminister Karsten Wildberger (CDU), Kanzler Friedrich Merz ist eingebunden. Parallel hat das Bundesdigitalministerium mit Project Spark erstmals KI-Module für die Verwaltung unter "Public Money, Public Code" veröffentlicht. Zusammen zeigen beide Vorgänge, wie europäische KI-Souveränität 2026 konkret aussehen soll.

Die Fusionsgespräche

Die Verhandlungen zwischen Aleph Alpha (Heidelberg) und Cohere (Toronto) laufen laut Handelsblatt seit Jahresbeginn und sind weit fortgeschritten. Geplant ist ein neues Unternehmen mit Hauptsitzen in Deutschland und Kanada, das ausschließlich auf europäischer Infrastruktur betrieben werden soll, ohne Zugriff durch Drittstaaten.

Die Bundesregierung plant zwei Rollen: Ankerkunde für die Digitalisierung der Verwaltung und mögliche finanzielle Beteiligung. Dass ein Fusionsgespräch zweier privatwirtschaftlicher KI-Anbieter direkt im Kanzleramt diskutiert wird, ist neu. Für beide Unternehmen geht es um Skalierung: Aleph Alpha bringt deutsche Sprachmodelle und öffentliche Kunden, Cohere das Enterprise-Geschäft und internationales Volumen.

Project Spark: Open-Source-KI für Behörden

Das Bundesdigitalministerium (BMDS) hat am 1. April 2026 unter dem Namen Project Spark ein Bündel KI-Module veröffentlicht, das Planungs- und Genehmigungsverfahren beschleunigen soll. Laut BMDS sollen die Module Aufgaben übernehmen wie:

  • Vollständigkeitsprüfung eingereichter Dokumente
  • Datenextraktion aus Anträgen
  • Plausibilitätsprüfung bei Inkonsistenzen
  • KI-gestützte rechtliche Vorprüfung auf Basis einer an Gesetzesdatenbanken angeschlossenen "Rechtsdogmatik"

Wie tragfähig diese Selbstbeschreibung ist, klärt der Abschnitt zur kritischen Einordnung weiter unten.

Der Code liegt auf openCode unter einer freien Lizenz. Das Setup basiert auf Docker, ist kompatibel mit OpenAI-Endpunkten und funktioniert auch mit lokalen Lösungen wie LiteLLM. Damit können Kommunen, Unternehmen und Zivilgesellschaft die Bausteine übernehmen und anpassen. Project Spark wurde im Februar 2026 beim World Government Summit ausgezeichnet.

Warum beides zusammengehört

Fusion und Spark sind zwei Hebel derselben Strategie:

Kommerziell: Ein fusioniertes Aleph-Alpha-Cohere-Unternehmen soll als souveräne Alternative zu US-Hyperscalern dienen, mit staatlichem Rückhalt als Ankerkunde.

Operativ: Mit Project Spark gibt es erstmals konkrete, nachnutzbare KI-Software aus dem Bund, die Behörden und Unternehmen ohne Lizenzkosten einsetzen können.

Das beantwortet eine lange offene Frage: Was genau bedeutet "souveräne KI"? Die bisherige Antwort "irgendein europäisches Modell" reichte kaum aus. Jetzt gibt es kommerzielle Anbieter mit Beistand aus Berlin plus frei nachnutzbare Bausteine aus dem Bund. Wie weit deren Reife wirklich trägt, ist allerdings eine eigene Frage.

Kritische Einordnung: ein Blick in den Spark-Code

So weit die Darstellung des BMDS. Eine genauere Sichtung des öffentlichen Codes relativiert das Bild. Der Entwickler und Blogger Stefan Kaufmann hat das Spark-Repository durchgesehen und kommt zu einem ernüchternden Befund (stefan.bloggt.es):

  • Die beworbene "Rechtsdogmatik" und der "Anschluss an Gesetzesdatenbanken" sind im Code nicht erkennbar. Was das BMDS als juristische Vorprüfung bewirbt, beschränkt sich laut Sichtung auf Prompts und etwas RAG über Gesetzestexte. Angesichts der bekannten Schwächen von LLM beim Auslegen von Normen ist das heikel.
  • Nicht-Determinismus ist eingebaut, nicht gelöst. Die README des Plausibilitäts-Moduls warnt selbst, dass Ergebnisse zwischen Läufen schwanken können ("LLM outputs are non-deterministic"). Für Verwaltungshandeln, das berechenbar, nachvollziehbar und am Gleichheitssatz orientiert sein muss, ist das ein grundsätzliches Problem, keine Randnotiz.
  • Sicherheit: Funde waren real, wurden aber zügig adressiert. Der IT-Sicherheitsexperte Thomas Fricke fand mit dem Scanner grype mehrere Schwachstellen, darunter Hochrisiko-CVEs in Python-Abhängigkeiten und eine CVE im verdockerten LibreOffice. Diese Punkte wurden im Repo als Issues dokumentiert und am 1. Juni 2026 geschlossen: gepatchte Abhängigkeiten, ein offizielles statt selbstgebautes LiteLLM-Image und ein getrimmtes LibreOffice. Am 8. Juni kam eine automatische Security-Pipeline (devguard) hinzu. Offen sind Stand 9. Juni noch eine Pickle-Deserialisierungs-CVE in diskcache (ohne Upstream-Fix) und geteilte OS-Paket-CVEs im Basis-Image. Die "Prompt Defense" gegen Prompt Injection bleibt ihrerseits nur ein Prompt, und ob das System systematisch gegen Angriffsvektoren getestet wurde, ist weiter nicht dokumentiert.
  • Keine belegte Wirkung. Die in der Anhörung im Digitalausschuss genannte Beschleunigung "um bis zu 80 %" stützt sich laut Aussage auf die Erfahrung des Projektteams, nicht auf eine systematische Analyse. Veröffentlichte Fehlerquoten, Stresstests oder ein Sicherheitsaudit fehlen. Die Kosten beziffert Politico auf rund 96 Millionen Euro. Die Auszeichnung beim World Government Summit ersetzt diese Belege nicht, sie ersetzt sie nur in der Außenwahrnehmung.

Wichtig für die Einordnung: Kaufmanns Sichtung spiegelt den Repo-Stand von Mitte Mai. Ein eigener Blick ins öffentliche Repository am 9. Juni 2026 zeigt, dass gerade die Sicherheitsfunde gewirkt haben, viele wurden binnen Tagen als Issue aufgenommen und behoben. Das ist im Kern genau das Versprechen von "Public Money, Public Code": Öffentlicher Code wird öffentlich geprüft und nachgebessert. Die konzeptionellen Einwände bleiben davon unberührt. Der Nicht-Determinismus ist Stand 9. Juni weiter in der README dokumentiert, an der beworbenen, aber im Code nicht auffindbaren Rechtsdogmatik hat sich nichts geändert, und veröffentlichte Fehlerquoten oder ein externer Audit fehlen nach wie vor.

Der härteste Einwand ist ohnehin konzeptionell, nicht technisch. Spark wandelt im ersten Schritt Office-Dokumente nach Markdown, nur um sie überhaupt maschinell auswertbar zu machen. Viele dieser Prüfungen ließen sich deterministisch und mit einem Bruchteil des Aufwands erledigen, wenn Anträge von vornherein in maschinenlesbaren Strukturen vorlägen. Ein LLM-Schwarm über für Menschen formatierte Dokumente, um ein selbst geschaffenes Problem zu lösen, bleibt die teure und fehleranfällige Variante.

Unterm Strich: Die Kritik ist berechtigt und hat das Projekt auf der Sicherheitsseite messbar besser gemacht. Aber die Lücke zwischen Souveränitäts-Pressemitteilung und prüfbarer Substanz ist real. Wer Spark nachnutzen will, sollte sich den aktuellen Stand im Repository selbst ansehen, statt allein auf die Pressemitteilung vom April oder eine Code-Sichtung vom Mai zu vertrauen, denn beide bilden nur eine Momentaufnahme ab.

Was das für Teams heißt

Für die verschiedenen Rollen im DACH-Raum ergeben sich konkrete Ansatzpunkte:

  • dev: Project Spark ist Open Source und in der eigenen Docker-Umgebung lauffähig. Als Anschauungsmaterial taugen die Module durchaus, als produktiver Startpunkt nur mit Vorsicht: Im Kern ist es ein Workflow, der etablierte F/LOSS-Bausteine und LLM-Prompts zusammenklebt (siehe kritische Einordnung). Wer darauf aufbaut, sollte die Sicherheits- und Determinismus-Fragen selbst klären, nicht als gelöst voraussetzen.
  • pm/po: Wer Projekte für öffentliche Auftraggeber oder in regulierten Branchen plant, sollte die Beschaffungsoption über ein souveränes Aleph-Alpha-Cohere-Unternehmen im Blick behalten. Ausschreibungen mit Souveränitätsanforderungen werden zunehmen.
  • design/qa: Prüfprozesse und Nutzerführung für KI-gestützte Verwaltungsverfahren werden zum eigenen Arbeitsfeld. Spark liefert Workflows, die UX-seitig ausgefüllt werden müssen.

Einordnung

Noch sind weder Fusion noch finanzielle Bundesbeteiligung unterzeichnet. Kartellrechtlich ist ein deutsch-kanadischer Zusammenschluss anspruchsvoll, und die 2028 anstehenden Hochrisiko-Anforderungen des EU AI Act setzen ohnehin Rahmenbedingungen, die beide Partner erfüllen müssen.

Was sich aber abzeichnet: "Souveräne KI" wechselt vom Schlagwort zum Beschaffungskriterium. Wer 2026 neue KI-Projekte im Bund, in Ländern oder in regulierten Branchen startet, wird die Frage nach Betriebsort, Datenkontrolle und Exit-Strategie beantworten müssen. Wie man diese Kriterien systematisch prüft, behandelt der Artikel zur digitalen Souveränität für KI-Teams.

Aktualisierungen
  • 09.06.2026: Abschnitt "Kritische Einordnung" zu Project Spark ergänzt (Code-Sichtung von Stefan Kaufmann: fehlende Rechtsdogmatik im Code, Nicht-Determinismus, Sicherheitsfunde, fehlende Wirkungsbelege, ~96 Mio € Kosten). Eigener Abgleich mit dem Repo-Stand vom 9. Juni: die Security-Funde wurden Anfang Juni 2026 weitgehend behoben (Issues, Dependency-Bumps, devguard-Pipeline), die konzeptionellen Einwände bleiben. Unverifizierte BMDS-Claims im Spark-Teil als solche gekennzeichnet, "Produktionsreife" entschärft.
Quellen9