Die meisten Organisationen beginnen ihren Weg zur KI mit einem Pilotprojekt: einem Prognosemodell für eine Abteilung, einem Konversationsassistenten für den Support, einem Klassifizierungsskript für Dokumente. Jedes davon wirkt für sich genommen wie ein Erfolg. Einige Jahre später betreibt dieselbe Organisation Dutzende von Modellen, von denen jedes Daten über eine eigene private Pipeline bezieht und in einer anderen Umgebung bereitgestellt ist, und niemand kann mit Sicherheit sagen, welche Version tatsächlich den Datenverkehr bedient. Das Problem ist nicht mehr, ein Modell zu bauen. Das Problem ist, Dutzende von Modellen und Agenten zuverlässig, sicher und prüfbar neben den Kernsystemen des Unternehmens zu betreiben.
Das ist wichtig, weil die eigentlichen Kosten von KI im Betrieb liegen, nicht im initialen Aufbau. Ein Modell ohne Überwachung der Datenqualität driftet unbemerkt von der Realität ab und liefert weiterhin mit voller Überzeugung falsche Antworten. Zugleich fragen Risikomanager und Prüfer zu Recht, auf welchen Daten, welcher Modellversion und welcher Geschäftsregel eine automatisierte Entscheidung beruhte. Ohne Plattform hängt die Antwort auf diese Fragen von manuellen Log-Recherchen und dem Gedächtnis einzelner Ingenieure ab. Genau an diesem Punkt hört KI auf, ein Vermögenswert zu sein, und wird zur technischen Schuld.
Die Architektur einer KI-Plattform lässt sich in vier Schichten beschreiben. Die Datenschicht bietet einheitlichen, kontrollierten Zugriff auf den Data Lake und die Event-Streams der Organisation. Die Modellschicht standardisiert, wie Modelle registriert, versioniert, evaluiert und bereitgestellt werden, ob klassische Machine-Learning-Modelle oder Sprachmodelle. Die Agentenschicht bündelt Entscheidungslogik und Werkzeuge zu kombinierbaren Agenten, die mit Unternehmenssystemen kommunizieren können. Die Governance-Schicht wendet Richtlinien, Berechtigungen, Tracing und Monitoring auf alles darunter an. Entscheidend ist, dass alle vier Schichten ein gemeinsames Identitätsmodell und ein gemeinsames Vokabular für Events teilen; andernfalls ist die Plattform nur vier Silos unter einem einzigen Logo.
Die erste praktische Überlegung betrifft die Trennung von Modell und Produkt. Ein Sprach- oder Prognosemodell sollte niemals direkt in Anwendungscode eingebettet werden, sondern über einen standardisierten Service mit explizitem Vertrag aufgerufen werden. Diese Trennung erlaubt es, das Modell zu aktualisieren, ohne die Anwendungen anzufassen, mehrere Modelle parallel zu evaluieren und bei sinkender Qualität auf eine frühere Version zurückzugehen. Wird etwa ein Kundensupport-Agent mit drei verschiedenen Modellen erprobt, kann das Team den besten Kompromiss zwischen Genauigkeit und Kosten wählen, ohne einen einzigen Bildschirm der Oberfläche zu ändern.
Die zweite Überlegung betrifft die Behandlung von Agenten als vollwertige Akteure der Organisation. Ein Agent, der eine Bestellung aufgeben, einen Kundendatensatz lesen oder eine Erstattung genehmigen kann, braucht eine eigene Identität, eng gefasste Berechtigungen und einen vollständigen Audit-Trail, genau wie ein Mitarbeitender. Das bedeutet, dass Agenten über denselben Identitätsdienst und dasselbe API-Gateway mit Systemen interagieren müssen, die auch Menschen und andere Anwendungen nutzen. Arbeitet ein Agent mit einem globalen Schlüssel und uneingeschränktem Zugriff, wird jeder Denkfehler zu einem Betriebsvorfall, ohne dass etwas dazwischen ihn aufhält.
Die dritte Überlegung betrifft Observability auf Entscheidungsebene. Klassisches Monitoring misst den Zustand von Services: Latenz, Fehler, Ressourcenverbrauch. Für KI muss man eine Ebene höher gehen und die Entscheidung selbst nachverfolgen: Welche Eingabe kam an, welche Datenquellen wurden herangezogen, welche Werkzeuge aufgerufen und welche Ausgabe erzeugt? Diese Spur ist sowohl für die Fehlersuche als auch für die Beantwortung von Prüferfragen unverzichtbar. Wird etwa eine automatisierte Kreditentscheidung angefochten, sollte das Team die vollständige Argumentationskette in Minuten statt in Tagen rekonstruieren können.
Die typischen Fallstricke sind vorhersehbar. Erstens: beim Modell statt bei den Daten anzusetzen; viele Projekte wählen ein Modell, bevor sie stabilen Zugang zu qualitativ guten Daten haben. Zweitens: die harte Abhängigkeit von einem einzigen Anbieter, die den Austausch oder die Ergänzung eines Modells zu einer umfangreichen Neuentwicklung macht. Drittens: die Inferenzkosten zu ignorieren, die im Unternehmensmaßstab überraschend schnell das Entwicklungsbudget übersteigen können. Viertens: Agenten Handlungsbefugnis zu geben, bevor ein Pfad zur menschlichen Prüfung und ein Not-Aus konzipiert sind. Jeder dieser Fehler lässt sich früh günstig vermeiden und später nur teuer beheben.
Bei Niadad setzt die KI-Plattform Rayon genau diese Schichtung um: Registrierung und Versionierung von Modellen, standardisierte Bereitstellung, kontinuierliche Evaluierung und kontrollierter Zugriff auf den Data Lake. Die Familie der Business-Agenten baut auf demselben Fundament auf und verbindet Agenten mit eigenen Identitäten, eng gefassten Berechtigungen und vollständigen Spuren mit Unternehmenssystemen. Beide arbeiten mit den Identitäts-, API-Gateway- und Event-Schichten von Niadad zusammen, sodass KI Teil der Infrastruktur der Organisation wird statt einer Insel daneben.
Die Zukunft der KI-Architektur ist keine Zukunft größerer Modelle, sondern eine Zukunft von Plattformen, die unterschiedliche Modelle mit ingenieurmäßiger Disziplin betreiben können. Organisationen, die diese Infrastruktur heute aufbauen, werden morgen jedes neue Modell innerhalb von Tagen einsetzen können. Wer das nicht tut, beginnt jedes Projekt immer wieder bei null. Der nachhaltige Vorteil liegt nicht in einem einzelnen Modell, sondern in der Plattform, die Modelle nutzbar macht.