EnaGuard
Die Architektur-Entscheidungsmatrix
Entscheidungen zur Unternehmens-KI-Architektur werden meist als Wahl zwischen zwei Optionen dargestellt: ein großes Modell oder ein kleines, ein einzelner Anbieter oder mehrere, Cloud- oder im eigenen Rechenzentrums-Infrastruktur. Doch die eigentliche Frage ist nicht, welche Option generell stärker ist, sondern welche zu einem bestimmten Anwendungsfall, einer Datenklasse, einem Risikoniveau und einem Betriebsmodell passt. Jede Wahl verschiebt Geschwindigkeit, Kontrolle, Kosten, Flexibilität, Resilienz und operativen Aufwand unterschiedlich.
Diese Matrix soll die technische Entscheidung nicht für die Führung treffen, sondern helfen, die Annahmen zu verstehen, auf denen die Entscheidung beruht. Jede Entscheidung wird entlang vier Dimensionen betrachtet: Chance, zentrales Risiko, die Bedingungen, unter denen sie passt, und der Nachweis, der eingefordert werden sollte. Das macht aus „warum haben wir diese Technologie gewählt?" die Frage „für welchen Geschäftsbedarf haben wir sie gewählt, welches Risiko haben wir akzeptiert, unter welchen Bedingungen würden wir es überdenken, und wie belegen wir, dass die Wahl funktioniert?"
Die Matrix sollte niemals genutzt werden, um eine einzige Präferenz für das gesamte Unternehmen abzuleiten. Dasselbe Unternehmen könnte für einen internen Wissensassistenten ein allgemeines Cloud-Modell nutzen und für sensible Kundentransaktionen ein domänenspezifisches im eigenen Rechenzentrums-Modell wählen. Ein Hersteller könnte für latenzkritische Abläufe in der Fertigung ein kleines Edge-KI-Modell betreiben und für Forschung und Dokumentenanalyse ein größeres zentrales Modell. Die Qualität einer Entscheidung hängt von Geschäftsauswirkung, Datensensibilität, Ausfalltoleranz, operativer Kapazität und überprüfbaren Ergebnissen ab, nicht von der Popularität einer Option.
| Architekturentscheidung | Chance | Zentrales Risiko | Eignungsbedingungen | Einzufordernder Nachweis |
|---|---|---|---|---|
| Großes vs. kleines Modell | Große Modelle bieten breite Aufgabenvielfalt und starke Schlussfolgerungsfähigkeit. Kleine Modelle bieten geringere Kosten, schnellere Antwortzeiten und lokale Ausführbarkeit. | Ein großes Modell kann Kosten und Anbieterabhängigkeit erhöhen. Ein kleines Modell kann bei komplexen oder domänenfremden Aufgaben an Qualität verlieren. | Aufgabenkomplexität, Latenzziel, Datensensibilität, Transaktionsvolumen und Betriebsumgebung müssen klar definiert sein. | Anwendungsfallbezogene Qualitätstests, Latenz- und Kostenvergleich, Lasttests, Fehleranalyse. |
| Einzelner Anbieter vs. Multi-Modell | Ein einzelner Anbieter vereinfacht Integration und Betrieb. Ein Multi-Modell-Ansatz bietet Flexibilität, Preisoptimierung und Leistungkontinuität. | Ein einzelner Anbieter kann eine starke Abhängigkeit schaffen. Ein Multi-Modell-Ansatz kann Qualitäts-, Richtlinien-, Datenportabilitäts- und operative Komplexität erhöhen. | Modell-Routing-Regeln, gemeinsame Sicherheitsrichtlinien, portable Datenstrukturen und ein Anbieterwechselprozess müssen vorhanden sein. | Anbieterinventar, Modell-Routing-Richtlinie, Ausweichverfahren-Tests, Verträge, Aufzeichnungen zum Datenstandort. |
| Cloud vs. im eigenen Rechenzentrums | Cloud bietet schnelles Kapazitätswachstum und breiten Leistungzugang. im eigenen Rechenzentrums bietet stärkere Datenkontrolle, lokalen Betrieb, dedizierte Hardwareverwaltung. | Cloud kann Probleme bei Datenstandort, Kosten und Anbieterabhängigkeit schaffen. im eigenen Rechenzentrums verlagert Investition, Expertise, Updates und Kapazitätsaufwand auf das Unternehmen. | Datenklasse, Regulierung, Latenz, Konnektivität, Skalierungsbedarf und Betriebskapazität müssen gemeinsam bewertet werden. | Datenflussdiagramme, Kapazitätsplan, Gesamtbetriebskosten, Ausfalltests, Update-/Patch-Aufzeichnungen. |
| Allgemeines RAG vs. domänenspezifisches RAG | Ein allgemeiner Aufbau bietet gemeinsamen Wissenszugang und schnelle Einführung. Ein domänenspezifischer Aufbau kann höhere kontextuelle Genauigkeit und engere Zugriffskontrolle bieten. | Allgemeine Pools können Rechteausweitung und Risiko falscher Quellen erhöhen. Domänenspezifische Aufbauten können doppelte Infrastruktur und fragmentierte Governance schaffen. | Dateneigentum, Nutzerrollen, Aktualität der Quellen, Zugriffsmodell und Antwortqualität müssen messbar sein. | Retrieval-Tests, Quellengenauigkeitsmessungen, Zugriffsszenarien, Aufzeichnungen zu Indexaktualisierung und -löschung. |
| Zentrale Plattform vs. verteiltes Teammodell | Eine zentrale Plattform liefert gemeinsame Standards, Kostentransparenz und wiederverwendbare Fähigkeiten. Ein verteiltes Modell gibt Geschäftsbereichen Geschwindigkeit und lokale Flexibilität. | Übermäßige Zentralisierung kann einen Engpass schaffen. Unkontrollierte Verteilung kann Technologiewucherung, Schatten-KI und uneinheitliche Standards schaffen. | Zentrale Mindeststandards müssen klar von lokalen Entscheidungsbereichen getrennt sein; Ausnahme- und Genehmigungsprozesse müssen definiert sein. | Plattformnutzungsrate, Ausnahmeinventar, Projektmigrationszeit, Abdeckung gemeinsamer Kontrollen, Verantwortlichkeitsmatrix der Teams. |
| Volle Autonomie vs. menschliche Freigabe | Autonomie liefert Geschwindigkeit und Skalierung. Menschliche Freigabe fügt für Aktionen mit hoher Wirkung eine Ebene von Urteilsvermögen und Verantwortlichkeit hinzu. | Breite Autonomie kann unkontrollierte Handlungen erzeugen. Übermäßige Freigabelast kann Prozesse verlangsamen und Freigabemüdigkeit erzeugen. | Transaktionen müssen nach Wirkung, Umkehrbarkeit, finanzieller Grenze, Kundenauswirkung und physischer Konsequenz klassifiziert werden. | Transaktionsklassifizierungsmatrix, Freigabeaufzeichnungen, Agentenberechtigungen, Ablehnungs-/Korrekturraten, Kill-Switch-Tests. |
| Feinabstimmung vs. Retrieval | Feinabstimmung kann Verhalten und Domänensprache in das Modell einbetten. Retrieval erleichtert die Nutzung aktuellen Unternehmenswissens zusammen mit seinen Quellen. | Feinabstimmung kann Probleme bei Datenherkunft, Aktualisierung und Vergessen schaffen. Retrieval kann ungenaue, veraltete oder manipulierte Quellen ins System bringen. | Es muss klar sein, ob der Bedarf Aktualität des Wissens oder Verhaltensanpassung ist; der Datenlebenszyklus muss beherrschbar sein. | Vergleichende Bewertung, Trainingsdatenaufzeichnungen, Datenberechtigungen, Aktualitätstests der Quellen, Modelländerungsberichte. |
| Echtzeit- vs. Batch-Inferenz | Echtzeitverarbeitung erfüllt unmittelbare Kunden- und Betriebsbedürfnisse. Batchverarbeitung kann hohes Volumen wirtschaftlicher und kontrollierter bewältigen. | Echtzeitsysteme sind latenz- und verfügbarkeitsempfindlich. Batchprozesse können veraltete Ergebnisse, Warteschlangenwachstum und verzögerte Fehlererkennung erzeugen. | Wartetoleranz des Prozesses, Bedarf an Datenaktualität, Transaktionsvolumen und Umgang mit Fehlerfortsetzung müssen definiert sein. | SLO- und Latenzmessungen, Warteschlangenkennzahlen, Kapazitätstests, Kontrollen zur Neuverarbeitung, Fehleraufzeichnungen. |
| Open-Source vs. geschlossenes Modell | Open-Source-Modelle bieten Anpassbarkeit, lokalen Betrieb und mehr technische Kontrolle. Geschlossene Modelle können schnellen Zugang, einen verwalteten Dienst und starke allgemeine Leistung bieten. | Open-Source verlagert Lizenz-, Sicherheits-, Patch- und Betriebsverantwortung auf das Unternehmen. Geschlossene Modelle können Transparenz und Portabilität einschränken. | Technische Fähigkeit des Unternehmens, Lizenzbedingungen, Datensensibilität, Update-Kapazität und Anbieterrisiko müssen bewertet werden. | Modellquelle, Lizenzprüfung, eine KI-Stückliste, Sicherheitsscans, Anbietervertrag, Versionsverwaltungsaufzeichnungen. |
| Zentrale Agentenplattform vs. anwendungsfallspezifische Agentenarchitektur | Eine zentrale Plattform liefert gemeinsame Identität, einen Werkzeugkatalog, Observability und Richtliniendurchsetzung. Lokale Aufbauten bieten anwendungsfallspezifische Geschwindigkeit und Designflexibilität. | Eine zentrale Plattform kann einen gemeinsamen Ausfallpunkt und Engpass schaffen. Verteilte Agenten können uneinheitliche Berechtigungen, Protokollierung und Sicherheitskontrollen schaffen. | Eine gemeinsame Kontrollebene, ein Agenten-Identitätsstandard, ein Werkzeugfreigabeprozess und lokale Entwicklungsgrenzen müssen definiert sein. | Agenten- und Werkzeuginventar, Identitätstrennung, Berechtigungsaufzeichnungen, durchgängige Nachverfolgung, Kill-Switch- und Missbrauchstests. |
Die Matrix ist keine Einkaufsliste und kein automatisches Auswahlwerkzeug. Jede Zeile sollte für einen bestimmten Anwendungsfall separat bewertet werden. Ein Entscheidungsprotokoll sollte den Geschäftsbedarf, die betrachteten Alternativen, die akzeptierten Risiken, die verantwortliche Person, die Bedingungen für eine Überprüfung und die erwarteten Erfolgskennzahlen erfassen, und Architekturentscheidungen so zu institutionellem Gedächtnis machen statt zu persönlicher Vorliebe oder einem vorübergehenden Technologietrend.
Eine vertretbare Architekturentscheidung entsteht nicht auf einer Folie. Sie zeigt sich in der Produktivbetrieb.
Qualitätsvergleiche, Kostendaten, Live-Konfigurationen, Testaufzeichnungen, Ausfallszenarien und Produktionskennzahlen, nicht allein die Logik auf Papier. Das ist der Nachweis, nach dem eine EnaGuard-Bewertung sucht.