Wer KI-Funktionen in ein Produkt oder einen internen Prozess einbaut, entscheidet damit auch über eine neue Abhängigkeit. In vielen Fällen kommen Modelle zum Einsatz, deren Innenleben für die nutzende Organisation nicht einsehbar ist und die sich nicht an eigene Anforderungen anpassen lassen. Genau an diesem Punkt setzt die Sovereign AI Foundation (SAIF) an, eine neue Initiative unter dem Dach der Eclipse Foundation. Sie will Open-Source-Alternativen aufzeigen.

Die Meldungslage ist derzeit knapp: Bekannt ist die Zielrichtung, nicht jedes Detail der Umsetzung. Für Projektverantwortliche ist die Initiative dennoch relevant, weil sie ein Thema adressiert, das in Ausschreibungen und Architekturentscheidungen zunehmend auftaucht.

Worum es bei Souveränität in KI-Projekten geht

Souveränität meint hier nicht nur den Serverstandort. Sie umfasst mindestens drei Ebenen, die in Projekten oft vermischt werden:

  • Datenhoheit – wer kontrolliert, wohin Eingaben, Dokumente und Protokolle fließen und wie lange sie dort liegen.
  • Prüfbarkeit – ob nachvollziehbar ist, wie ein Modell gebaut wurde und auf welcher Grundlage es antwortet.
  • Anpassbarkeit – ob ein Modell an fachliche Besonderheiten, eigene Terminologie oder regulatorische Vorgaben angepasst werden kann.

Bei reinen API-Diensten, also Modellen, die ausschließlich über eine Schnittstelle eines Anbieters erreichbar sind, lässt sich vor allem die erste Ebene vertraglich regeln. Prüfbarkeit und Anpassbarkeit bleiben dagegen begrenzt, weil Trainingsdaten, Gewichte und Änderungszyklen beim Anbieter liegen.

Warum Abhängigkeit in der Praxis teuer wird

Technische Abhängigkeit wird meist erst nach der Einführung sichtbar. Typische Muster, die sich in Web- und Softwareprojekten beobachten lassen:

  • Ein Modell wird abgekündigt oder durch eine neue Version ersetzt. Prompts und nachgelagerte Logik, die auf das alte Verhalten abgestimmt waren, liefern plötzlich andere Ergebnisse.
  • Antwortqualität und Antwortzeiten verändern sich, ohne dass die eigene Anwendung angepasst wurde. Fehleranalyse ist dann nur eingeschränkt möglich.
  • Preis- und Konditionsänderungen treffen Funktionen, die inzwischen fest im Arbeitsalltag verankert sind. Ein kurzfristiger Wechsel ist dann kaum noch realistisch.
  • Compliance-Fragen kommen nachträglich auf, etwa wenn ein Fachbereich personenbezogene oder vertrauliche Inhalte verarbeitet.

Keines dieser Risiken spricht grundsätzlich gegen kommerzielle Modelle. Sie sprechen aber dafür, die Abhängigkeit bewusst zu wählen und sie architektonisch einzugrenzen.

Was offene Modelle leisten können – und was nicht

Open-Source-Alternativen verschieben das Gleichgewicht, lösen aber nicht automatisch jedes Problem. Offene Modelle lassen sich in der eigenen Infrastruktur oder bei einem Dienstleister der eigenen Wahl betreiben, was Datenflüsse überschaubar hält. Sie lassen sich versionieren und einfrieren, sodass das Verhalten einer Anwendung über längere Zeit stabil bleibt. Und sie lassen sich anpassen, wenn Fachsprache, Dokumentstrukturen oder Prüfregeln eines Unternehmens vom Allgemeinfall abweichen.

Im Gegenzug wandert Verantwortung ins Haus: Betrieb, Updates, Absicherung und Qualitätsmessung müssen organisiert werden. Auch der Begriff „Open Source“ ist im KI-Umfeld nicht einheitlich belegt – manche Modelle veröffentlichen Gewichte, aber nicht die Trainingsdaten oder die vollständigen Lizenzbedingungen für kommerzielle Nutzung. Eine Initiative, die hier Orientierung schafft, adressiert insofern einen realen Mangel.

Konsequenzen für die Architektur

Unabhängig davon, wie sich die Eclipse-Initiative weiterentwickelt, lässt sich Austauschbarkeit heute schon in Projekten verankern. Hilfreich sind vor allem vier Punkte:

  1. Abstraktionsschicht einziehen. Anwendungen sprechen nicht direkt mit einem Anbieter, sondern mit einer internen Schnittstelle. Ein Modellwechsel betrifft dann eine Komponente, nicht die halbe Codebasis.
  2. Eigene Testfälle aufbauen. Eine überschaubare Sammlung realer Aufgaben mit erwarteten Ergebnissen macht messbar, ob ein alternatives Modell für den konkreten Einsatzzweck ausreicht.
  3. Daten und Wissen getrennt halten. Inhalte, Suchindizes und Regeln gehören in die eigene Hoheit, nicht in die Feinabstimmung eines fremden Modells.
  4. Kritikalität einordnen. Ein Textvorschlag im Redaktionssystem hat andere Anforderungen als eine Auskunft mit rechtlicher Wirkung. Nicht jeder Anwendungsfall braucht die gleiche Souveränität.

Einordnung für TYPO3- und Softwareprojekte

In Content-Management-Projekten tauchen KI-Funktionen inzwischen an vielen Stellen auf: Textvorschläge in der Redaktion, Übersetzungen, Alternativtexte für Bilder, semantische Suche, Klassifizierung von Anfragen. Diese Funktionen sind einzeln klein, in Summe aber geschäftskritisch – und sie landen schnell bei einem einzigen Anbieter, weil es beim Start der schnellste Weg ist.

Für die Planung heißt das: Die Modellauswahl sollte eine Entscheidung mit Ausstiegsoption sein, keine Einbahnstraße. Ein Hybridansatz ist in vielen Fällen pragmatisch – kommerzielle Modelle dort, wo Qualität und Tempo zählen, offene Modelle dort, wo Daten sensibel sind oder Ergebnisse über Jahre reproduzierbar bleiben müssen.

Für Web- und Softwareprojekte verschiebt sich damit der Schwerpunkt von der Frage „welches Modell ist das beste“ zur Frage „wie teuer ist ein Wechsel“. Wer Abstraktion, eigene Qualitätsmessung und klare Datenflüsse von Anfang an einplant, kann neue Entwicklungen wie die Sovereign AI Foundation beobachten, ohne jedes Mal die Architektur in Frage zu stellen. Und wer Datenhoheit ohnehin nachweisen muss, hat mit prüfbaren und anpassbaren Modellen eine Option mehr auf dem Tisch.

Quellen