Enterprise-KI-Architektur: Was ändert sich, wenn KI in ein Unternehmen eintritt

Enterprise-KI-Architektur ist die unternehmensweite Architektur, die erforderlich ist, wenn KI Teil der realen Systeme, Daten, Entscheidungen und Abläufe eines Unternehmens wird. Das Modell ist nur eine Komponente. Sobald KI mit Unternehmensdaten, Identitäten, Berechtigungen, Geschäftsprozessen, externen Anbietern und Produktionssystemen verbunden ist, muss die Architektur auch Datenhoheit, Zugriffsgrenzen, Risikoverantwortung, Anbieterabhängigkeiten, Auditierbarkeit, Evaluierung, Lebenszyklussteuerung, Compliance und operative Verantwortung definieren. Enterprise-KI unterscheidet sich daher sowohl von einer einzelnen KI-Lösung als auch von einer gemeinsamen KI-Plattform: Sie koordiniert, wie viele KI-fähige Systeme in die breitere Organisation passen.

Was Enterprise-KI-Architektur wirklich bedeutet

Enterprise-KI-Architektur beschreibt, wie KI-Fähigkeiten in eine bestehende Organisation integriert werden, ohne die Grenzen zu durchbrechen, die Unternehmenssysteme bereits steuerbar machen: fachliche Verantwortung, Identität, Autorisierung, Datenklassifizierung, Verantwortung für Systeme of Record, Änderungsmanagement, Beschaffung, Audit, Kontinuität und Betrieb.

Der Unternehmensarchitekt ersetzt nicht den KI-Lösungsarchitekten oder den KI-Plattformarchitekten. Der Unternehmensumfang stellt eine andere Frage: Wie fügen sich mehrere KI-Lösungen und gemeinsame KI-Fähigkeiten in die Zielarchitektur, Richtlinien, Datenlandschaft, das Risikomodell und das Betriebsmodell des Unternehmens ein?

Dadurch wird Enterprise-KI-Architektur zu einer Koordinationsdisziplin über Technologie und Organisation hinweg. Eine technisch gute Modellintegration kann dennoch ein Fehler der Unternehmensarchitektur sein, wenn sie Schatten-Datenflüsse erzeugt, Identitäten dupliziert, die Beschaffung umgeht, nicht auditierbar ist, keinen Verantwortlichen hat oder nicht sicher geändert werden kann.

Das einfachste Beispiel

Ein Unternehmen beginnt mit einem internen Dokumentenassistenten. Die erste Version durchsucht freigegebene Dokumente und sendet den abgerufenen Kontext an ein Sprachmodell. Auf Lösungsebene mag dies einfach erscheinen.

Dann möchte ein zweites Team KI für den Kundensupport. Ein drittes möchte einen Agenten, der Tickets aktualisieren kann. Die Finanzabteilung möchte Dokumentenanalyse. Die Personalabteilung möchte einen internen Assistenten. Entwickler möchten Coding-Agenten. Plötzlich hat das Unternehmen mehrere Anbieter, mehrere Datenklassen, unterschiedliche Benutzergruppen, überlappende Retrieval-Indizes, unterschiedliche Protokollierungsregeln, neue Tool-Berechtigungen, duplizierte Secrets und unklare Verantwortlichkeiten.

Zu diesem Zeitpunkt lautet die Frage nicht mehr „Funktioniert der Assistent?“ Die Unternehmensfrage wird: Welche Fähigkeiten sind genehmigt, wer verantwortet sie, welche Daten dürfen welche Grenze überschreiten, wie werden Identitäten und Berechtigungen durchgesetzt, welche Anbieter sind akzeptabel, was muss auditiert werden und wie kann die Organisation Modelle oder Lieferanten ändern, ohne die Kontrolle zu verlieren?

Wo das einfache Beispiel endet

Unternehmensarchitektur bedeutet nicht, dass jede KI-Komponente zentralisiert werden muss. Einige Fähigkeiten sollten gemeinsam genutzt werden; andere müssen in der Domäne verbleiben. Finanzen, Personalwesen, Engineering und Kundensupport können legitimerweise unterschiedliche Datengrenzen, Anbieter, Bewertungskriterien und Regeln für menschliche Genehmigung erfordern.

Das Unternehmensziel ist daher nicht ein Modell, eine Vektordatenbank oder ein universeller Assistent. Das Ziel ist eine kohärente Architektur mit expliziter Variation: gemeinsame Richtlinien und wiederverwendbare Fähigkeiten, wo sie Risiko und Duplikation reduzieren, plus kontrollierte Ausnahmen, wo Geschäfts- oder regulatorische Anforderungen abweichen.

Was sich in der Architektur ändert, wenn KI ins Unternehmen Einzug hält

1. Business Ownership wird Teil der technischen Architektur

Traditionelle Anwendungen benötigen bereits Business Owner. KI macht diese Anforderung sichtbarer, weil akzeptables Verhalten nicht nur durch Verfügbarkeit und funktionale Korrektheit definiert werden kann. Jemand muss den beabsichtigten Nutzen, unzulässige Nutzung, Ausgabequalität, Eskalationspfad und Konsequenzen falscher oder unangemessener Ergebnisse verantworten.

Ein Modellteam kann nicht allein entscheiden, ob eine Antwort für HR, Finanzen, Recht oder kundenorientierte Nutzung akzeptabel ist. Enterprise-KI-Architektur verbindet daher technisches Design mit einer expliziten Geschäftsfähigkeit, einem verantwortlichen Owner, einer Nutzergruppe und einem Entscheidungskontext.

2. Datenzugriff allein reicht nicht — Datenhoheit muss definiert werden

Enterprise-KI kombiniert häufig operative Datenbanken, Dokumente, Suchindizes, Vektorspeicher, Data Warehouses, SaaS-Systeme und externes Wissen. Die Architektur muss unterscheiden, wo Informationen gespeichert sind und welche Quelle für eine bestimmte Aussage oder Aktion maßgeblich ist.

Ein Vektorindex kann das Retrieval verbessern, sollte aber nicht stillschweigend zum System of Record des Unternehmens werden. Eine Modellantwort kann einen ERP-Datensatz zusammenfassen, sollte aber das ERP nicht als maßgebliche Quelle ersetzen. Gecachter Kontext kann die Latenz verbessern, wird jedoch unsicher, wenn sich Berechtigungen oder der zugrunde liegende Geschäftszustand ändern.

Enterprise-KI benötigt daher zusätzlich zur gewöhnlichen Datenintegration Provenienz, Aktualität, Quellenklassifizierung, Autorisierungsweitergabe und Invalidierungsregeln.

3. Identität wird mehrschichtig

Enterprise-KI hat mehr Identitäten als der menschliche Nutzer. Eine Anfrage kann eine Benutzeridentität, Anwendungsidentität, Dienstidentität, Agentenidentität, Anbieter-Anmeldeinformation, Tool-Anmeldeinformation und Mandanten- oder Organisationskontext umfassen.

Diese Identitäten sollten nicht in einem einzigen gemeinsam genutzten API-Schlüssel zusammengefasst werden. Die Autorisierung muss dem richtigen Prinzipal zuordenbar bleiben, und privilegierte Tools sollten nur die für den aktuellen Vorgang erforderliche Autorität erhalten.

Für agentische Systeme wird dies besonders wichtig: Ein Modell kann eine Aktion vorschlagen, aber die Laufzeitumgebung muss entscheiden, ob die anfragende Identität berechtigt ist, sie auszuführen. Modellfähigkeit ist keine Autorisierung.

4. Berechtigungen verschieben sich vom Inhaltszugriff zur Aktionsautorität

Ein schreibgeschützter Assistent benötigt hauptsächlich kontrollierten Zugriff auf Informationen. Ein Enterprise-Agent kann Tickets erstellen, Datensätze ändern, Nachrichten senden, Workflows auslösen oder externe Systeme bedienen. Das führt eine andere Risikoklasse ein, weil das System den Zustand ändern kann, anstatt ihn nur zu beschreiben.

Die Architektur sollte Lese-, Schreib-, Genehmigungs- und administrative Fähigkeiten trennen; Human-in-the-Loop-Punkte definieren, wo die Konsequenz sie rechtfertigt; und einen Audit-Trail bewahren, der identifiziert, was angefragt, was genehmigt und was tatsächlich geändert wurde.

5. Der KI-Anbieter wird zu einer Unternehmensabhängigkeit

Eine Modell-API aufzurufen ist auch eine Lieferantenbeziehung. Die Architektur kann von Anbieterverfügbarkeit, Servicebedingungen, Datenverarbeitungsbedingungen, unterstützten Regionen, Modelllebenszyklus, Kontingenten, Preisgestaltung, API-Kompatibilität, Sicherheitskontrollen und Änderungsmitteilungen abhängen.

Das bedeutet, dass die Anbieterauswahl nicht nur eine Benchmark-Entscheidung ist. Beschaffung, Sicherheit, Datenschutz, rechtliche Prüfung, Kontinuitätsplanung und Exit-Strategie können alle zu Architektureingaben werden.

Anbieterabstraktion kann die Kopplung reduzieren, aber nur dort, wo die zugrunde liegenden Fähigkeiten wirklich portabel sind. Tool-Nutzung, strukturierte Ausgabe, Kontextgrenzen, Multimodalität, Sicherheitskontrollen, Fine-Tuning und gehostete Agentenfunktionen können sich zwischen Anbietern erheblich unterscheiden.

6. KI-Risiko wird zu einem Lebenszyklusprozess

KI-Risiko ist nicht mit einer einzigen Genehmigung vor dem Start abgeschlossen. Das Modell, der Prompt, das Retrieval-Korpus, das Tool-Set, der Anbieter, die Nutzerpopulation und der umgebende Geschäftsprozess können sich nach der Bereitstellung alle ändern. Das Risikoprofil ändert sich mit ihnen.

ISO/IEC 23894:2023 befasst sich ausdrücklich mit der Integration des KI-Risikomanagements in organisatorische Aktivitäten und Funktionen. NIST AI RMF rahmt das Risikomanagement ebenfalls über den gesamten Lebenszyklus. Unternehmensarchitektur sollte daher die Risikoprüfung zu einem Teil von Änderung und Betrieb machen und nicht zu einem isolierten Compliance-Dokument.

Risiko sollte auch verhältnismäßig sein. Ein Zusammenfassungsassistent und ein autonomes System, das Produktionsdatensätze ändert, sollten nicht allein deshalb identische Kontrollen erhalten, weil beide ein LLM verwenden.

7. Governance wird zu einem Betriebssystem, nicht zu einem Richtlinien-PDF

ISO/IEC 42001:2023 definiert Anforderungen für die Einrichtung, Umsetzung, Aufrechterhaltung und kontinuierliche Verbesserung eines KI-Managementsystems. Die architektonische Konsequenz ist wichtig: Governance muss Richtlinien mit realen Inventaren, Verantwortlichkeiten, Prozessen, Kontrollen, Nachweisen, Überprüfungen und Verbesserungsschleifen verbinden.

Eine Unternehmens-KI-Richtlinie, die nicht mit Anbietergenehmigung, Identität, Protokollierung, Änderungsmanagement, Evaluierung und Incident Response verbunden ist, hat begrenzte architektonische Wirkung. Die Organisation benötigt Mechanismen, die Richtlinien durchsetzbar oder zumindest beobachtbar machen.

8. Evaluierung wird zu einer Produktionskontrolle

Traditionelle Abnahmetests gehen davon aus, dass dieselbe Eingabe normalerweise dasselbe deterministische Ergebnis liefert. Generative KI kann nichtdeterministisch sein, empfindlich auf Kontext reagieren und von sich änderndem externem Wissen abhängen. Produktionsabnahme erfordert daher aufgabenspezifische Evals, Regressions-Suites und beobachtbare Schwellenwerte statt nur Unit-Tests.

Die Plattform kann wiederverwendbare Evaluierungsinfrastruktur bereitstellen, aber das Unternehmen muss weiterhin die Verantwortung für domänenspezifische Ground Truth und Release-Gates tragen. Ein zentrales KI-Team kann nicht für jede Geschäftsdomäne die richtige Antwort erfinden.

Änderungen an Modell, Prompt, Retrieval und Tools sollten auf Evaluierungsnachweise zurückführbar sein, wenn die Änderung das Ausgabeverhalten wesentlich beeinflussen kann.

9. Observability muss Verhalten, Daten und Modellkontext umfassen

CPU-, Speicher- und HTTP-Fehlerraten sind für KI-Workloads nicht ausreichend. Produktions-Observability kann Modell-/Anbieterkennungen, Latenz, Token-Nutzung, Kosten, Retrieval-Ergebnisse, Tool-Aufrufe, Verweigerungsverhalten, Evaluierungsbewertungen, Sicherheitsereignisse und Fehlerklassifizierungen erfordern.

Gleichzeitig können KI-Telemetriedaten sensible Daten enthalten. Prompt- und Antwortprotokolle können zu einem Schatten-Datenspeicher werden. Unternehmensarchitektur muss daher definieren, was protokolliert werden darf, wie es redigiert wird, wer darauf zugreifen kann, wie lange es aufbewahrt wird und wann detailliertes Tracing deaktiviert werden muss.

10. KI-Komponenten benötigen explizite Lebenszyklus-Verantwortung

Modelle können von Anbietern umbenannt, ersetzt, außer Betrieb genommen oder geändert werden. Embedding-Modelle können eine Indexstrategie ungültig machen. Prompt-Vorlagen und Systemanweisungen können das Verhalten ändern. Agenten-Laufzeitumgebungen und Protokolle können sich weiterentwickeln. Externe Tools können ihre Schemata und Berechtigungen ändern.

Die Unternehmensarchitektur muss entscheiden, wer diese Änderungen erkennt, wer sie testet, wer sie genehmigt, wie Verbraucher benachrichtigt werden, wie ein Rollback funktioniert und welche Nachweise erforderlich sind, bevor eine neue Version zum Standard wird.

11. Incident Response muss KI-spezifische Fehlermodi berücksichtigen

Ein KI-Vorfall kann ein Anbieterausfall, ein Datenleck, ein Prompt-Injection-Pfad, ein Autorisierungsfehler, eine Retrieval-Kontamination, unerwartetes Modellverhalten, eine unsichere Tool-Ausführung, ein Kostenanstieg, veraltetes Wissen, eine Evaluierungsregression oder eine Änderung des externen Modellverhaltens sein.

Das Unternehmens-Runbook muss daher mehr als nur „den Dienst neu starten“ bieten. Es kann erforderlich sein, eine Modellroute zu deaktivieren, den Tool-Zugriff zu widerrufen, ein Korpus einzufrieren, eine Prompt-Version zu ändern, eine Agent-Fähigkeit zu deaktivieren, den Anbieter zu wechseln, an einen Domänenverantwortlichen zu eskalieren oder Traces für die Untersuchung zu sichern.

Unternehmens-KI schafft funktionsübergreifende Verantwortung

Ein praktisches Architekturmodell für Unternehmens-KI

Die Architektur ist am stärksten, wenn jede Schicht sowohl ihre Verantwortlichkeiten als auch ihre Nicht-Verantwortlichkeiten benennen kann. Beispielsweise kann die KI-Plattform Anbieterrichtlinien durchsetzen und Traces sammeln, ohne zur Quelle der Wahrheit für HR-Daten zu werden. Eine Lösung kann Domänen-Prompts definieren, ohne das Unternehmens-IAM zu besitzen. Ein Fachbereichsverantwortlicher kann einen Anwendungsfall genehmigen, ohne das Inferenz-Gateway betreiben zu müssen.

Unternehmens-KI als Daten- und Berechtigungsflüsse abbilden, nicht als Boxen

Ein Unternehmen benötigt ein KI-Inventar, bevor es KI governen kann

Organisationen können KI-Systeme nicht verwalten, die sie nicht identifizieren können. Die Unternehmensarchitektur sollte ein Inventar auf einem für Entscheidungen nützlichen Detaillierungsgrad pflegen, nicht nur eine Liste von Modellnamen.

KI-Governance und Unternehmens-KI-Architektur sind verwandt, aber nicht dasselbe

Regulierung wird zur Architekturvorgabe

Für Organisationen, die in der Europäischen Union tätig sind, kann der AI Act Anforderungen schaffen, die Systemdesign, Dokumentation, Transparenz, Governance und Betriebsprozesse beeinflussen. Die architektonischen Auswirkungen hängen von der Rolle der Organisation in der KI-Wertschöpfungskette und der konkreten Systemklassifizierung ab; nicht jedes KI-System hat dieselben Pflichten.

Ab dem 8. Oktober 2026 gilt nach dem aktuellen konsolidierten Text, dass die Verordnung im Allgemeinen ab dem 2. August 2026 Anwendung findet. Governance-Regeln und Pflichten für Allzweck-KI-Modelle galten bereits früher, während bestimmte Vorschriften für Hochrisikosysteme spätere Termine haben. Die Kommission begann außerdem ab dem 2. August 2026 mit der Durchsetzung neuer Transparenzanforderungen für relevante interaktive und synthetische Inhalte erzeugende Systeme.

Die Lehre für die Unternehmensarchitektur lautet nicht „Compliance ins Modell packen“. Sie besteht darin, Klassifizierung, Anbieter-/Betreiberrolle, Dokumentation, Transparenz, Aufsicht, Protokollierung und Änderungsnachweise auf das System zurückführbar zu machen, das den Anwendungsfall tatsächlich umsetzt.

Beschaffung und Architektur werden miteinander verbunden

Ein externes Modell oder eine verwaltete KI-Plattform kann zu einer tiefen Abhängigkeit werden, selbst wenn die Integration nur wenige API-Aufrufe erfordert. Unternehmensarchitektur sollte daher Beschaffungsfragen technisch konkret machen.

Unternehmensarchitektur entscheidet, wie viel KI-Kontrolle die Anforderung tatsächlich benötigt

Die am stärksten kontrollierte Architektur ist nicht automatisch die beste Unternehmensarchitektur. Mehr Eigenverantwortung erhöht die Verantwortung für Patches, Kapazität, Sicherheit, Tests, Modellbetrieb und Incident Response. Unternehmensarchitektur sollte die Kontrolle nur dort erhöhen, wo die Anforderung die zusätzliche betriebliche Belastung rechtfertigt.

KI macht Change Management zu einem Verhaltensproblem

Ein normales Abhängigkeitsupdate kann Leistung oder Kompatibilität verändern. Eine KI-Änderung kann auch das Verhalten verändern. Der Austausch eines Modells, die Änderung eines System-Prompts, die Änderung des Retrievals, das Hinzufügen eines Tools oder die Änderung der Kontextrichtlinie kann die Art und Weise verändern, wie das System interpretiert und antwortet, selbst wenn sich der umgebende Anwendungscode kaum ändert.

Unternehmens-KI braucht weiterhin NFRs und ADRs

KI ersetzt nicht die gewöhnliche Architekturdisziplin. Nicht-funktionale Anforderungen bleiben die Zielbedingungen: Verfügbarkeit, Latenz, Datenschutz, Isolation, Auditierbarkeit, Wiederherstellbarkeit, Kostengrenzen, Erklärbarkeit oder andere Qualitätsanforderungen. Architecture Decision Records bewahren die gewählte Antwort und ihre Abwägungen.

Der KI-spezifische Unterschied besteht darin, dass einige Qualitätsattribute probabilistisch oder empirisch bewertet werden müssen. „Antworten müssen nützlich sein“ ist zu vage. Eine Produktionsanforderung sollte die Aufgabe, die Daten, die Benutzerpopulation, akzeptable Fehlerbedingungen, die Messmethode und den Schwellenwert identifizieren, wo praktikabel.

Unternehmens-KI-Architektur muss mit der Lieferung verbunden sein

Architektur, die niemals Backlog, Implementierung, Abnahme und Betrieb erreicht, bleibt konzeptionell. Unternehmens-KI benötigt daher Rückverfolgbarkeit von Architekturentscheidungen in die Lieferarbeit und zurück von Implementierungsnachweisen in die Architektur.

Jira und Confluence sind Beispiele für Tools, die diese Trennung unterstützen können, wenn sie bewusst eingesetzt werden: Confluence kann Anforderungen, Architektur, Entscheidungen, Risiken und Begründungen bewahren; Jira kann umsetzbare Lieferarbeit und Status verwalten. Das wichtige Prinzip ist die Rückverfolgbarkeit, nicht die Marke des Tools.

Ursprüngliche Projektnachweise: Enterprise Aaasaasa 0.1

Enterprise Aaasaasa 0.1 kombiniert Plattformarchitektur, SaaS-/API-Konzepte, Internationalisierung, KI-Integration und strukturierte Projektgovernance. Das Projekt wurde bewusst so organisiert, dass Anforderungen, Architektur, Prototypenlieferung, Validierung und Abschluss separate Meilensteine waren und nicht eine undifferenzierte Implementierungsphase.

Die Architekturrichtung umfasst Multi-Instanz-/Multi-Datenbank-Konzepte zusammen mit API-, CRUD-, i18n- und KI-Fähigkeiten. Das ist für Unternehmens-KI wichtig, weil Mandanten- oder Instanzgrenzen, Datenbankeigentum und Anwendungsdienste explizit bleiben müssen, wenn KI-Funktionen hinzugefügt werden.

Die Projektstruktur behandelte auch Architekturverzögerungen, Scope Creep und KI-/Datenschutzbedenken als Projektrisiken, anstatt sie erst während der Implementierung zu entdecken. Zu den Stakeholdern gehörten technische, Sicherheits-, Sponsor-/Lenkungs- und externe Service-Perspektiven, was der realen funktionsübergreifenden Natur von Unternehmens-KI näher kommt als ein reiner Modellprototyp.

Der nützliche Nachweis ist daher die Integration von Architektur und Lieferung: Geschäfts- und Projektstruktur, Meilensteine, Risiken, Architektur, Backend/API, Frontend-/KI-Arbeit, Validierung und Abschluss werden als verbundene Verantwortlichkeiten behandelt. Dieses Muster ist wiederverwendbar, auch wenn das Projekt selbst nicht als Beweis für externe Unternehmensakzeptanz präsentiert werden sollte.

Unterstützende Implementierungsmuster aus der breiteren Plattformarbeit

Separate Implementierungsarbeit in der breiteren Aaasaasa-Plattform liefert konkrete Beispiele für Grenzen, die Unternehmens-KI-Architektur bewahren muss: mandantenbezogenes RBAC im CMS, explizite Trennung von Anbieter/Modell/Laufzeitumgebung/Berechtigung im Aaasaasa AI Client und Provenienz-first-Retrieval in der Source of Truth Research Engine.

Diese Projekte sollten nicht zu einer einzigen beanspruchten Produktionsplattform zusammengefasst werden. Ihr Wert ist hier enger: Sie demonstrieren implementierte Muster für Identitätsumfang, Anbietergrenzen, kontrollierte Laufzeitberechtigungen, Retrieval-Provenienz und Nachweis-Rückverfolgbarkeit, die direkt für Unternehmens-KI relevant sind.

Wie die wichtigsten Standards zusammenpassen

Diese Quellen lösen unterschiedliche Probleme. ISO/IEC 42001 ist kein Ersatz für technische Architektur. ISO/IEC 23894 und NIST AI RMF definieren keinen einzigen verbindlichen Software-Stack. Der EU AI Act ist Gesetz, kein Plattform-Designmuster. Architektur muss die anwendbaren organisatorischen, Risiko- und rechtlichen Anforderungen in implementierbare Systemgrenzen und Nachweise übersetzen.

Häufige Fehlermuster bei Unternehmens-KI

Häufige Missverständnisse

Eine praktische Entscheidungssequenz für Enterprise-KI-Architektur

Checkliste für Enterprise-KI-Architektur

Grenzfälle und Grenzen

Ein kleines Unternehmen mit einem risikoarmen KI-Anwendungsfall benötigt möglicherweise keine formale Enterprise-KI-Architekturfunktion. Dieselben Prinzipien können leicht angewendet werden: klarer Eigentümer, genehmigte Daten, expliziter Anbieter, grundlegende Bewertung, Zugriffskontrolle und betriebliche Verantwortung.

Eine stark regulierte Organisation kann eine stärkere Trennung, unabhängige Validierung, formale Konformitätsprozesse, lokales Hosting oder Air-Gapped-Betrieb erfordern. Diese Kontrollen werden durch den Anwendungsfall und das regulatorische Umfeld bestimmt, nicht durch das Wort „Enterprise“.

Eine Organisation kann auch überwiegend SaaS-KI-Produkte nutzen, anstatt KI-Systeme zu bauen. Enterprise-Architektur bleibt dennoch wichtig, weil Identität, Datenzugriff, Vertragsbedingungen, Shadow-KI, Aufbewahrung, Audit und Lieferantenkonzentration organisatorische Anliegen bleiben.

Eine zentrale Plattform ist nicht zwingend erforderlich. Föderierte Plattformverantwortung kann gültig sein, wenn Domänen wesentlich unterschiedliche Anforderungen haben, sofern unternehmensweite Identitäts-, Risiko-, Inventar- und Interoperabilitätsverantwortlichkeiten kohärent bleiben.

Was würde diese Antwort ändern?

Die Architektur ändert sich, wenn sich Risikotoleranz, regulatorische Klassifizierung, Datensensibilität, geografischer Umfang, Anbieterstrategie, interne Fähigkeiten oder Geschäftskritikalität der Organisation ändern. Ein öffentlicher Marketing-Assistent und ein System, das an Entscheidungen zu Beschäftigung, Finanzen, Gesundheitswesen oder kritischer Infrastruktur beteiligt ist, sollten nicht identische Kontrollmodelle erben.

Die Umsetzung ändert sich auch, wenn sich Standards, Regulierung und KI-Plattformen weiterentwickeln. NIST AI RMF 1.0 wird derzeit überarbeitet, der EU AI Act hat gestaffelte Anwendungsdaten, und Modell-/Anbieterfähigkeiten ändern sich weiterhin schnell. Enterprise-Architektur sollte daher stabile Verantwortungsgrenzen bewahren, während Anbietermechanismen und regulatorische Details als versionierte Eingaben behandelt werden.

Verwandtes kanonisches Wissen

Enterprise-KI-Architektur baut auf Lösungs- und Plattformarchitektur auf. Die Lösungsebene erklärt eine Arbeitslast. Die Plattformebene erklärt wiederverwendbare KI-Fähigkeiten. Die Enterprise-Ebene verbindet beides mit unternehmensweiten Daten, Identität, Governance, Risiko, Beschaffung und Betrieb.

Retrieval-Augmented Generation ist nur ein Mechanismus innerhalb dieser Architektur. RAG kann den Zugriff auf Unternehmenswissen verbessern, löst aber nicht von sich aus Datenhoheit, Berechtigungen, Governance oder Antwortgültigkeit.

Für evidenzintensive Unternehmensanwendungsfälle benötigt die Gültigkeit von Antworten ebenfalls eine explizite Grenze: Eine Ausgabe wird nur unter den Evidenzen, der Version, dem Umfang und den Annahmen gestützt, die sie hervorgebracht haben.

Nachgelagerte Unternehmensthemen umfassen KI-Governance, Private KI, Souveräne KI, Air-Gapped KI, Multi-Tenant-KI-Architektur, RBAC versus Mandantenisolierung, Anbieterabstraktion, Modell-Routing und Produktions-KI-Architektur.

Häufig gestellte Fragen

Glossar

Fazit

Wenn KI in ein Unternehmen Einzug hält, gewinnt das Unternehmen nicht nur eine neue Softwarekomponente. Es gewinnt eine neue Klasse von Verhalten und Abhängigkeit, die Daten, Identität, Lieferanten, Geschäftsentscheidungen, Sicherheit, Betrieb, Governance und Change Management durchdringt.

Die architektonische Antwort besteht nicht darin, alles zu zentralisieren. Sie besteht darin, Verantwortlichkeiten explizit zu machen: welche Daten autoritativ sind, welche Identitäten handeln dürfen, welche Anbieter zugelassen sind, welche Kontrollen geteilt werden, welche Entscheidungen in der Domäne verbleiben, wie Verhalten evaluiert wird, wie Vorfälle behandelt werden und wie sich das System im Laufe der Zeit ändert.

Das ist die Kernunterscheidung der Unternehmens-KI-Architektur: Sie verwandelt isolierte KI-Fähigkeiten in ein organisatorisch steuerbares System, ohne vorzugeben, dass Modelle, Plattformen, Geschäftsdomänen und Unternehmenskontrollen dasselbe sind.

Primärquellen und aktuelle Leitlinien

Externe Standards, Regulierung und aktuelle Anbieterarchitektur-Leitlinien unten wurden am 8. Oktober 2026 überprüft. Projektspezifische Abschnitte sind ausdrücklich als ursprüngliche Projektnachweise gekennzeichnet und sollten nicht als Behauptungen allgemeiner Branchenfakten gelesen werden.