Was ist ein KI-Plattform-Architekt? Modelle, Daten, Laufzeitumgebung, Sicherheit und Betrieb

Ein AI Platform Architect entwirft das wiederverwendbare KI-Fundament, über das mehrere Anwendungen, Teams oder Mandantenkontexte auf Modelle, Daten und Retrieval, Agenten- und Tool-Runtimes, Identität und Berechtigungen, Evaluierung, Observability, Quotas, Secrets und Deployment-Fähigkeiten zugreifen. Die Rolle ist breiter als Infrastruktur, aber enger als das Eigentum an jedem KI-fähigen Produkt: Ihre zentrale Verantwortung besteht darin, zu entscheiden, was geteilt werden sollte, wie geteilte Fähigkeiten gesteuert und isoliert werden und was lösungsspezifisch bleiben muss.

Was architektiert ein AI Platform Architect tatsächlich?

Der Gegenstand der Arbeit ist die Plattform: eine Reihe gemeinsamer Fähigkeiten, die wiederholte Integrationsarbeit reduziert und dabei explizite Sicherheits-, Daten- und Betriebsgrenzen wahrt. Eine Plattform kann Modellzugriff, Anbieteradapter, Retrieval-Primitive, Agentenausführung, Tool-Broker, Richtliniendurchsetzung, Evaluierung, Telemetrie und Deployment-Dienste für viele konsumierende Lösungen bereitstellen.

Die Plattform ist nicht allein deshalb wertvoll, weil Komponenten zentralisiert sind. Sie ist wertvoll, wenn Konsumenten stabile Fähigkeiten mit klaren Verträgen, Eigentum, Isolierung, Observability und Lifecycle-Regeln erhalten. Die zentrale Architekturfrage ist daher nicht „Welches Modell sollte jeder verwenden?“, sondern „Welche Verantwortlichkeiten können sicher standardisiert und wiederverwendet werden, ohne die Anforderungen jeder Lösung zu verwischen?“.

Das einfachste Beispiel

Stellen Sie sich vor, ein Unternehmen hat fünf KI-fähige Produkte: einen internen Dokumentenassistenten, einen Copiloten für den Kundensupport, einen Software-Engineering-Agenten, einen Vertragsprüfungs-Workflow und einen Produktsuchassistenten. Jedes Produkt könnte unabhängig Modell-APIs integrieren, Anmeldedaten speichern, Wiederholungsversuche implementieren, Token-Metriken sammeln, Retrieval-Code erstellen und eigene Tool-Berechtigungen aufbauen.

Diese Duplizierung ist teuer und gefährlich, wenn jedes Team ein anderes Sicherheits- und Betriebsmodell erfindet. Eine gemeinsame Plattform kann stattdessen genehmigte Anbieterverbindungen, Modellermittlung, Quotas, Anmeldedaten, mandantenfähigen Zugriff, gemeinsame Telemetrie, wiederverwendbare Retrieval-Dienste und einen Agenten-/Tool-Runtime-Vertrag anbieten.

Aber die Plattform muss an der richtigen Grenze haltmachen. Die Vertragsprüfungslösung kann rechtliche Dokumentenhoheit und Zitierregeln erfordern, die der Software-Agent nicht benötigt. Der Produktsuchassistent kann handelsspezifische Aktualitäts- und Autorisierungsregeln benötigen. Wiederverwendbare Infrastruktur macht nicht alle Domänenwahrheit wiederverwendbar.

Wo das einfache Beispiel endet

Zentralisierung ist nicht automatisch Architektur. Ein einzelner Endpunkt vor mehreren Modell-APIs ist nützlich, aber er schafft für sich genommen noch keine KI-Plattform. Eine Produktionsplattform benötigt außerdem Identitätsgrenzen, Fähigkeitsverträge, Anbieterzustand und Lifecycle-Handhabung, Quotas, Secret-Eigentum, Observability, Kompatibilitätsregeln, Sicherheitskontrollen, Release-Disziplin und klare operative Verantwortung.

Das gegenteilige Versagen ist ebenfalls häufig: jeden Prompt, jeden Vektorindex, jede Geschäftsregel, jeden Agenten und jeden Anwendungs-Workflow in ein einziges „KI-Backend“ zu packen. Das erzeugt einen Monolithen, dessen gemeinsamer Status zufällig statt architektonisch ist. Eine Plattform sollte querschnittliche Fähigkeiten standardisieren, nicht Domäneneigentum absorbieren, nur weil KI beteiligt ist.

Die wichtigste Plattformentscheidung: gemeinsam versus lösungsspezifisch

Architektur-Verantwortlichkeitskarte

1. Modell- und Anbieterzugriff

Ein Plattformarchitekt definiert, wie Konsumenten Modelle entdecken und aufrufen, ohne jede Anwendung zu zwingen, einen Anbieter fest zu codieren. Dies umfasst Anbieteradapter, Modellkennungen, Fähigkeitsmetadaten, Authentifizierung, Health-Checks, Endpunktkonfiguration, Request-Normalisierung und Kompatibilitätsverhalten.

Anbieterabstraktion muss ehrlich bleiben. Verschiedene Anbieter bieten unterschiedliche Kontextgrenzen, Tool-Semantik, strukturiertes Ausgabeverhalten, multimodale Fähigkeiten, Sicherheitskontrollen, Caching, Preisgestaltung und Fehlermodi. Eine gute Abstraktion schafft einen stabilen Plattformvertrag und bewahrt gleichzeitig den Zugriff auf Fähigkeiten, die nicht sinnvoll vereinheitlicht werden können.

2. Gateway, Routing, Quoten und Kostenkontrollen

Ein gemeinsames KI-Gateway kann Authentifizierung, Routing, Drosselung, Wiederholungen, Token-Limits, Nutzungszuordnung und Richtliniendurchsetzung zentralisieren. Microsofts aktuelle AI-Gateway-Richtlinien behandeln Token-pro-Minute-Limits, Quoten und Multi-Projekt-Eingrenzung ausdrücklich als Plattformbelange; AWS stellt ebenfalls Konto- und Modellquoten sowie zentrale Kontrollen bereit.

Das Gateway ist daher mehr als ein Reverse Proxy, wenn es KI-spezifische Richtlinien- und Betriebssemantik trägt. Es sollte jedoch nicht stillschweigend Geschäftsentscheidungen treffen. Eine Routing-Richtlinie kann ein gesundes lokales Modell, einen kostengünstigeren Anbieter oder einen regional konformen Endpunkt bevorzugen; ob diese Route für eine bestimmte Aufgabe akzeptabel ist, bleibt dennoch ein Vertrag zwischen Plattform und Lösung.

Routing benötigt auch Fehlersemantik. Wenn das bevorzugte Modell nicht verfügbar ist, muss die Plattform wissen, ob ein Fallback erlaubt ist, ob eine Cloud-Route eine ausdrückliche Zustimmung erfordert, ob ein Modell mit geringerer Fähigkeit gültig ist und wie die Entscheidung für die Observability sichtbar gemacht wird.

3. Gemeinsame Daten-, Retrieval- und Grounding-Dienste

Retrieval-Dienste sind starke Plattformkandidaten, weil Parsing, Chunking, Indexierung, lexikalische Suche, semantische Suche, Metadatenfilterung, Provenienz und Zitationsmechanik wiederverwendbar sind. Die Plattform darf jedoch eine gemeinsame Retrieval-Engine nicht mit einer gemeinsamen Quelle der Wahrheit verwechseln.

Eine Lösung besitzt weiterhin Fragen wie: Welcher Korpus ist autoritativ? Welche Version ist gültig? Darf dieser Nutzer dieses Dokument sehen? Wie aktuell müssen die Daten sein? Was zählt als ausreichende Evidenz? Kann eine Antwort generiert werden, wenn das Retrieval fehlschlägt? Das sind Domänen- und Lösungsanforderungen, selbst wenn die Plattform die Retrieval-Maschinerie bereitstellt.

Diese Grenze ist besonders wichtig in Multi-Tenant-Systemen. Ein technisch gemeinsamer Index oder Vektordienst rechtfertigt keine mandantenübergreifende Sichtbarkeit. Der Autorisierungskontext muss durch das Retrieval hindurch erhalten bleiben und darf nicht erst hinzugefügt werden, nachdem Suchergebnisse die Grenze bereits überschritten haben.

4. Agenten- und Tool-Runtime

Agentische Systeme fügen wiederverwendbare Runtime-Belange hinzu: Thread-/Session-Lebenszyklus, Planungsschleifen, Tool-Registrierung, Tool-Aufruf, Abbruch, Timeouts, menschliche Genehmigungen, Memory-/State-Schnittstellen, Remote-Agent-Protokolle und Trace-Korrelation. Eine Plattform kann diese Mechaniken bereitstellen, damit jedes Produkt sie nicht neu aufbauen muss.

Die Plattform muss auch die Tool-Berechtigung von der Modellfähigkeit getrennt halten. Dass ein Modell einen Shell-Befehl generieren kann, bedeutet nicht, dass die Runtime die Shell-Ausführung erlauben sollte. Die Berechtigungsgrenze gehört zur Anwendungs-/Runtime-Architektur und muss unabhängig vom Modell durchsetzbar sein.

Die aktuelle AWS-Agentic-AI-Richtlinie betont begrenzte Agenten, explizite Befugnisse, End-to-End-Tracing, versionierte Verhaltensartefakte und menschliche Aufsicht im Verhältnis zu den Konsequenzen. Das sind plattformermöglichende Belange, aber die konsumierende Lösung definiert weiterhin, welche Aktionen für ihre Domäne legitim sind.

5. Identität, Mandantentrennung und Autorisierung

KI-Plattformen stehen oft vor hochwertigen Modellen, proprietären Daten und aktionsfähigen Tools. Authentifizierung ist daher nur der Anfang. Die Architektur muss Benutzer-, Dienst-, Anwendungs- und Mandantenkontext durch jeden privilegierten Vorgang tragen, der ihn benötigt.

RBAC und Mandantentrennung lösen unterschiedliche Probleme. RBAC beantwortet, was eine Identität tun darf; Mandantentrennung beantwortet, auf welche Ressourcen welches Mandanten diese Identität einwirken darf. Eine Plattform, die Rollen prüft, aber den Mandantenkontext verliert, kann dennoch die falschen Daten offenlegen.

Die aktuelle KI-Workload-Richtlinie von Microsoft empfiehlt ausdrücklich Identitätssegmentierung und autorisierungsbewussten Zugriff auf Inhalte. Die AWS-Richtlinie für mandantenfähige generative KI-Plattformen behandelt logische Isolierung, zentralisierte Kontrollen und Auditierbarkeit ebenfalls als Plattformbelange.

6. Geheimnisse, Anmeldeinformationen und Vertrauensgrenzen

Eine Plattform sollte definieren, wem Anbieterschlüssel, entfernte Bearer-Tokens, Signiermaterial und Tool-Anmeldeinformationen gehören, wo sie gespeichert sind, welcher Prozess auf sie zugreifen kann, wie sie rotiert werden und ob sie jemals einen Browser oder einen nicht vertrauenswürdigen Renderer erreichen können.

Dies ist eine architektonische Grenze, kein Implementierungsdetail. Wenn jede konsumierende Anwendung Anbieter-Anmeldeinformationen in ihre eigene Konfiguration kopiert, hat die Organisation sowohl den operativen Aufwand als auch den Wirkungsradius dupliziert. Zentralisierung kann dieses Risiko nur reduzieren, wenn die Plattform selbst engere, auditierbare Zugriffspfade hat.

7. Evaluierung, Beobachtbarkeit und Auditierbarkeit

Eine wiederverwendbare Plattform kann Evaluierungs-Harnesses, Trace-IDs, Modell-/Anbieter-Metadaten, Token- und Kostenmetriken, Latenz, Fehlerraten, Verknüpfung von Prompt-/Modellversionen, Agenten-/Tool-Traces und kontrolliertes Logging bereitstellen. AWS und Microsoft behandeln sowohl Beobachtbarkeit als auch Evaluierung als zentrale Produktionsbelange für KI-Workloads.

Plattform-Evaluierung und Lösungs-Evaluierung müssen getrennt bleiben. Eine Plattform kann verifizieren, dass ein Endpunkt gesund ist, eine Modellversion eine allgemeine Regressionssuite besteht und Traces vollständig sind. Sie kann nicht entscheiden, dass eine rechtliche Antwort, ein medizinischer Workflow oder eine Produktempfehlung akzeptabel ist, ohne domänenspezifische Ground Truth und Akzeptanzkriterien.

Logging schafft auch eine Datenschutzgrenze. Prompt- und Antwortprotokolle können sensible oder proprietäre Daten enthalten. Der Plattformarchitekt muss daher entscheiden, was protokolliert, redigiert, gesampelt, aufbewahrt und zugänglich gemacht wird, anstatt anzunehmen, dass mehr Telemetrie immer sicherer ist.

8. Laufzeit, Bereitstellung und Lokalität

Ein Plattformarchitekt entscheidet, wie gemeinsame KI-Fähigkeiten bereitgestellt und erreicht werden: verwaltete Cloud-Dienste, selbst gehostete Endpunkte, lokale Inferenz, hybrides Routing, containerisierte Dienste, Desktop-Laufzeiten, private Netzwerke oder air-gapped Umgebungen. Die wichtige Unterscheidung ist zwischen wo der Steuerungs-/Laufzeitprozess läuft und wo Inferenz und Datenverarbeitung tatsächlich stattfinden.

Ein lokaler Client kann dennoch ein Cloud-Modell aufrufen. Eine Cloud-Steuerungsebene kann zu einem On-Premises-Modell routen. Ein Remote-Agent kann Tools innerhalb eines Kundennetzwerks ausführen. Architekturdiagramme müssen daher Vertrauens- und Datenflussgrenzen zeigen, anstatt „lokal“ und „Cloud“ als vage Bezeichnungen zu verwenden.

9. Plattform-Lebenszyklus, Kompatibilität und Onboarding

Wiederverwendbare Fähigkeit wird erst dann zu einer Plattform, wenn Konsumenten sich im Laufe der Zeit darauf verlassen können. Das erfordert versionierte Verträge, Migrationsregeln, Kompatibilitätsrichtlinien, Deprecation, Release-Tests, Rollback, Incident-Verantwortung, Kapazitätsplanung, Dokumentation und einen Weg zum Onboarding neuer Teams oder Anwendungen.

Sich schnell entwickelnde KI-Ökosysteme machen dies besonders wichtig. Modellnamen, SDKs, Protokollversionen, Anbieter-APIs und Sicherheitsfähigkeiten ändern sich unabhängig voneinander. Eine Plattform muss einen Teil dieser Volatilität absorbieren, ohne Änderungen zu verbergen, die das Verhalten einer Lösung wesentlich beeinflussen.

Ein praktisches Modell für Control-Plane / Execution-Plane / Solution-Plane

Diese Trennung hilft, Plattform-Drift zu diagnostizieren. Wenn eine Anwendung jeden providerspezifischen Credential und Endpunkt kennen muss, ist der Plattformvertrag zu dünn. Wenn die Plattform entscheidet, welcher Kundendatensatz rechtlich autoritativ ist oder ob eine Domänenantwort akzeptabel ist, hat die Plattform die Grenze zur Solution-Ownership überschritten.

Was sollte ein AI Platform Architect produzieren?

Die Arbeit besteht hauptsächlich aus Trade-offs, nicht aus maximaler Zentralisierung

Wie unterscheidet sich das von angrenzenden Rollen?

Diese Grenzen sind organisatorisch, nicht universell. In einem kleinen Team kann eine Person mehrere Verantwortlichkeiten tragen. In einem regulierten Unternehmen können sie auf Architektur-, Sicherheits-, Plattform-, Daten- und Betriebsgruppen aufgeteilt sein. Die nützliche Unterscheidung ist der Umfang der Architekturverantwortung, nicht der auf einem Organigramm gedruckte Jobtitel.

Implementierungsnachweise: Wie diese Plattformgrenzen in meiner eigenen Arbeit erscheinen

Aaasaasa AI Client: Trennung von Provider, Laufzeit und Berechtigungen

Aaasaasa AI Client ist ein lokal-first Desktop-KI-Arbeitsbereich, der mit Nuxt 4, Electron und TypeScript erstellt wurde. Sein AI Hub trennt bewusst Agent/Client, Provider, Modell, Verbindungs-/Laufzeitort, Berechtigungen und Web-Client, anstatt sie als einen Konfigurationswert zu behandeln.

Die Implementierung umfasst direkte Provider-Adapter, Codex-Agent-Laufzeitintegration, lokale Ollama/LM Studio-Pfade, OpenAI-kompatible Dienste, zentralisierte Arbeitsbereichsberechtigungen, Credential-Speicherung im Hauptprozess, DuckDB, Qdrant/Vektor-Unterstützung, PDF-/Readability-Extraktion und authentifizierten MCP-basierten Verzeichniszugriff.

Zwei Plattformlektionen sind besonders relevant. Erstens ist eine lokale Laufzeit nicht dasselbe wie lokale Inferenz: Ein lokaler Codex-Prozess kann immer noch ein Cloud-Modell verwenden. Zweitens fällt automatisches Routing nicht stillschweigend von lokaler auf kostenpflichtige Cloud-Inferenz zurück. Das macht Routing-Richtlinie und Laufzeitlokalität explizit statt aus UI-Labels abgeleitet.

Aaasaasa AI CMS: mandantenbezogene Autorisierung als Plattformgrenze

Die Codebasis des Aaasaasa AI CMS bietet ein separates Implementierungsbeispiel: mandantenbezogenes RBAC wird durch Rollen, Berechtigungen und Benutzer-Rollen-Zuweisungen dargestellt, die an eine Mandantenkennung gebunden sind. Systemberechtigungen sind nach Fähigkeiten gruppiert, und Rollensuche und -aktualisierungen bleiben mandantenbezogen.

Dies ist für sich genommen kein Beweis für eine vollständige KI-Plattform, aber es ist direkt relevant für eine der schwierigsten Grenzen gemeinsamer Plattformen: Ein wiederverwendbarer Dienst muss bewahren, wer was tun darf und für welchen Mandanten. Das Hinzufügen von KI-Inferenz oder Retrieval auf einer Anwendungsplattform beseitigt diese Anforderung nicht.

Die architektonische Implikation ist, dass Modell-Gateways, Retrieval-Dienste und Agenten etablierten Identitäts-/Mandantenkontext nutzen sollten, anstatt ein paralleles, nur auf KI ausgerichtetes Autorisierungsuniversum zu erfinden.

Source of Truth Research Engine: gemeinsame Retrieval-Mechanik ohne gemeinsame Wahrheit

Die Source of Truth Research Engine bietet ein drittes Implementierungsbeispiel. Verschiedene Recherchemodelle teilen einen gemeinsamen Evidenzkern: Quellen, Artefakte, Provenienz, Claims, Relationen, Widersprüche, ein Referenzmodell und Audit-Trail. Das System bietet außerdem lokales lexikalisches Retrieval, optionales semantisches Retrieval, Extraktion, Snapshots und SHA-256-basierte Provenienz.

Das Projekt behandelt Suche und semantische Ähnlichkeit ausdrücklich als Entdeckungssignale und nicht als Evidenz. Ein Ergebnis muss auf eine konkrete Quelle und einen Locator zurückgeführt werden können, bevor es einen Claim stützen kann. Genau das ist die Unterscheidung, die eine KI-Plattform braucht: wiederverwendbare Retrieval-Maschinerie kann geteilt werden, während die Evidenzautorität weiterhin durch die konsumierende Methodik und Domäne geregelt wird.

Die Engine zeigt auch, warum eine gemeinsame Plattform keine gemeinsame Interpretation erfordert. Historische, wissenschaftlich-technische, Marktintelligenz- und Monitoring-Modi können die Kern-Evidenzinfrastruktur wiederverwenden und dennoch modusspezifische Methodik beibehalten.

Wie aktuelle Architekturleitlinien diesen Plattformumfang stützen

ISO/IEC/IEEE 42010:2022 bietet eine allgemeine Disziplin für Architekturbeschreibungen über Software, Systeme, Unternehmen und verwandte Entitäten hinweg. Es definiert keinen AI Platform Architect, aber es stärkt die Notwendigkeit, architektonische Belange, Beziehungen und Sichtweisen auszudrücken, anstatt Architektur auf eine Technologieliste zu reduzieren.

NIST AI RMF 1.0 und das Generative AI Profile rahmen KI-Risikomanagement über den Lebenszyklus ein und nicht nur zum Zeitpunkt der Modellauswahl. Governance, Mapping, Messung und Management sind daher mit einer Plattformarchitektur vereinbar, die gemeinsame Kontrollen und Evidenz über viele konsumierende Workloads hinweg trägt.

Die aktuelle AI-Workload-Leitlinie von Microsoft behandelt Anwendungsdesign, Daten, Sicherheit, Betrieb, Test/Evaluierung und GenAIOps als verbundene Architekturbereiche. Die aktuelle AI-Gateway-Leitlinie zeigt zudem praktische Plattformbelange wie zentralisierten Modellzugriff, projektspezifische Token-Limits, Quoten und Multi-Team-Eingrenzung.

Der aktuelle Generative AI Lens und das Multi-Tenant-Plattformszenario von AWS trennen ebenfalls grundlegende Plattformkontrollen von der Verantwortung konsumierender Anwendungen. AWS weist ausdrücklich darauf hin, dass eine zentrale Plattform gemeinsame Guardrails und Auditierbarkeit durchsetzen kann, während Datenqualität und workloadspezifische Observability weiterhin Verantwortlichkeiten konsumierender Anwendungen oder Datenproduzenten bleiben.

Die Anbieterprodukte unterscheiden sich, aber das quellenübergreifende Muster ist stabil: Produktions-KI-Plattformen müssen Identität, Datenzugriff, Modelle, Richtlinien, Evaluierung, Observability, Kapazität, Kosten und Lebenszyklus koordinieren. Ein GPU-Cluster oder Modell-Endpunkt deckt nur einen Teil dieser Verantwortung ab.

Häufige Missverständnisse

Fehlermodi, die ein AI Platform Architect verhindern sollte

Eine praktische Entscheidungssequenz für die Plattformarchitektur

Randfälle und Grenzen der Rolle

Eine kleine Organisation mit einer einzigen KI-Anwendung benötigt möglicherweise keine eigenständige KI-Plattform oder keinen Plattformarchitekten. Verfrühte Plattformbildung kann mehr Abstraktion als Wert schaffen. Die richtige Architektur kann eine gut entworfene Lösung mit einigen wiederverwendbaren Modulen sein.

Eine luftgespaltene oder souveräne Bereitstellung ändert das Provider-, Update- und Observability-Modell erheblich. Modell-Hosting, Artefaktverteilung, Identitätsintegration und Telemetrie-Export benötigen möglicherweise alle lokale Äquivalente.

Hochregulierte oder folgenschwere Workloads können eine stärkere physische oder organisatorische Isolation erfordern, anstatt einer logisch gemeinsamen Plattform. Wiederverwendung ist niemals ein ausreichender Grund, eine erforderliche Sicherheitsgrenze zu schwächen.

Verwaltete Cloud-KI-Dienste können die Implementierungslast entfernen, aber nicht die architektonische Verantwortung. Die Organisation entscheidet weiterhin über Identität, Datenzugriff, Protokollierung, Aufbewahrung, Quoten, Modellberechtigung, Fallback, Evaluierung und Lösungsabnahme.

Die Plattformgrenze kann sich auch je nach Modalität unterscheiden. Textinferenz, multimodale Generierung, Sprache, Computernutzung und autonome Agenten können unterschiedliche Latenz-, Daten-, Berechtigungs- und Observability-Anforderungen haben, selbst wenn sie Provider- und Identitätsinfrastruktur teilen.

Was würde diese Antwort ändern?

Die Kerndefinition würde sich ändern, wenn sich der organisatorische Umfang ändert. Wenn der Architekt einen Workload besitzt, nähert sich die Rolle einem KI-Lösungsarchitekten. Wenn sich die Verantwortung auf organisationsweite Fähigkeitsstrategie, Investitionen, Standards und Zielzustandsportfolios ausdehnt, bewegt sie sich in Richtung Enterprise-KI-Architektur.

Die Implementierungsanleitung ändert sich, wann immer sich Provider, Gateway-Produkte, Agent-Protokolle, regulatorische Verpflichtungen, Modellfähigkeiten oder Bereitstellungsbeschränkungen ändern. Deshalb sollte die Plattformarchitektur stabile Verantwortlichkeiten und Verträge getrennt von aktuellen Anbietermechanismen ausdrücken.

Checkliste für KI-Plattformarchitekten

Fazit

Ein KI-Plattformarchitekt ist verantwortlich für die wiederverwendbare Architektur zwischen KI-Fähigkeiten und den Lösungen, die sie nutzen. Die Rolle definiert, wie Modelle, Provider, Retrieval, Agenten, Tools, Identität, Mandanten, Geheimnisse, Evaluierung, Observability, Quoten und Laufzeitoperationen zu verlässlichen Plattformdiensten werden, anstatt wiederholte Einmalintegrationen zu sein.

Der schwierige Teil ist nicht die Maximierung der Wiederverwendung. Es ist die Wahl der richtigen Grenze. Eine starke Plattform standardisiert Mechanismen, Richtlinien und Betrieb dort, wo mehrere Konsumenten wirklich profitieren, während sie lösungsspezifische Datenautorität, Geschäftslogik, Sicherheitsanforderungen und Abnahmekriterien bewahrt.

Diese Unterscheidung erklärt auch die Beziehung zur KI-Lösungsarchitektur: Der Lösungsarchitekt macht ein KI-fähiges System zweckmäßig; der Plattformarchitekt macht gemeinsame KI-Fähigkeiten sicher, wiederverwendbar, betreibbar und über viele solcher Systeme hinweg entwickelbar.

Verwandtes kanonisches Wissen

Dieser Artikel baut auf den kanonischen Grundlagen zu generativen KI-Komponenten, ADR versus NFR und KI-Lösungsarchitektur auf. Diese Konzepte sind Voraussetzungen, weil eine Plattform existiert, um wiederverwendbare Systemfähigkeiten bereitzustellen und architektonische Entscheidungen gegen explizite Qualitäts- und Betriebsanforderungen zu kodifizieren.

Retrieval-Augmented Generation ist ein Beispiel für eine Fähigkeit, die über eine Plattform angeboten werden kann, aber die Plattform sollte Retrieval-Infrastruktur, Domänenwissen und Antwortvalidität nicht zu einem einzigen Konzept verschmelzen.

Agentenprotokolle, Mandantentrennung, KI-Governance, Modell-Routing, Context Engineering und MLOps/LLMOps sind nachgelagerte oder angrenzende Wissensknoten. Sie lassen sich leichter durchdenken, sobald die Plattformgrenze explizit ist.

Häufig gestellte Fragen

Glossar

Primärquellen und aktuelle Architekturempfehlungen

Die folgenden Quellen stützen die allgemeinen Architektur- und Produktionsplattform-Aussagen. Die Abschnitte Aaasaasa AI Client, Aaasaasa AI CMS und Source of Truth Research Engine sind ausdrücklich originäre Implementierungsnachweise. Aktuelle externe Referenzen wurden am 8. Oktober 2026 geprüft.