KI-Architektur für Unternehmen: 12-Punkte-Checkliste

Eine gute KI-Architektur beginnt nicht mit einem Modell, Vector Store oder Agent Framework.

Sie beginnt mit einer überprüfbaren Kette von Business-Aufgabe → Daten → Entscheidungen → Systemgrenzen → Kontrollen → Betrieb.

Für Unternehmen ist deshalb nicht die Frage „Welche AI Platform brauchen wir?“ der beste Startpunkt, sondern:

Welche Evidenz muss vorliegen, damit diese Architektur sicher, wartbar und wirtschaftlich gebaut werden kann?

Gartner beschreibt Enterprise Architecture 2026 zunehmend als Koordinationsfunktion für AI-Transformation: Architektur soll AI-Initiativen, Technologieentscheidungen und skalierbare, sichere Systeme zusammenführen. Quellen: Gartner – Coordinate, Rationalize and Accelerate Enterprise AI Value, Gartner – Lead AI-Driven Business and Technology Transformation.

Die Kurzfassung: 12 Architecture Gates

| Gate | Kernfrage | | --- | --- | | 1. Business Outcome | Welche konkrete Aufgabe oder Entscheidung wird verbessert? | | 2. Workflow | Wo sitzt AI im realen Prozess? | | 3. Data | Welche Daten werden tatsächlich benötigt? | | 4. Identity & Permissions | Wer darf was sehen und auslösen? | | 5. Retrieval | Welche Information muss gesucht statt generiert werden? | | 6. Model | Welche Modellfähigkeiten werden wirklich benötigt? | | 7. Agent / Tools | Muss AI handeln oder reicht ein kontrollierter Workflow? | | 8. Integration / API | Welche Systeme sind System of Record? | | 9. Security & Privacy | Welche Grenzen und Datenflüsse sind kritisch? | | 10. Evaluation | Wie wird Qualität messbar? | | 11. Observability | Wie werden Fehler, Drift, Kosten und Latenz sichtbar? | | 12. Operations & Ownership | Wer betreibt, entscheidet und reagiert? |

Ein Gate ist erst erfüllt, wenn nicht nur eine Meinung, sondern belastbare Evidenz vorliegt.

Gate 1 – Business Outcome

Kernfrage

Welche konkrete Arbeit wird besser, schneller, günstiger oder zuverlässiger?

Schwache Anforderungen:

• „Wir wollen GenAI einsetzen.“
• „Wir brauchen einen Copilot.“
• „Wir möchten Agents.“

Stärker:

„Support-Mitarbeiter sollen aus freigegebener Dokumentation eine belastbare Antwort mit Quelle erhalten, ohne mehrere Systeme manuell durchsuchen zu müssen.“

Required Evidence

• Zielgruppe/User,
• aktueller Prozess,
• Pain oder Friction,
• erwarteter Outcome,
• messbare Baseline.

Typischer Failure Mode

Das Team optimiert Modellqualität, obwohl der Business-Prozess keinen relevanten Engpass besitzt.

Gate 2 – Workflow

Kernfrage

Wo genau sitzt AI im Prozess und wer entscheidet den nächsten Schritt?

Unterscheiden Sie:

• Assistenz,
• einzelner LLM-Schritt,
• deterministischer Workflow,
• bounded Agent,
• höher autonome Agenten.

Wenn der Ablauf stabil ist, braucht es oft keinen Agenten.

Siehe KI-Agent vs. Workflow vs. Automation.

Required Evidence

• Prozessschritte,
• Inputs/Outputs,
• Human Gates,
• Fehlerpfade,
• erlaubte Aktionen.

Typischer Failure Mode

Ein flexibler Agent ersetzt einen Prozess, der einfacher und zuverlässiger als Workflow lösbar wäre.

Gate 3 – Data

Kernfrage

Welche Daten sind erforderlich – und in welcher Qualität?

Relevant sind nicht nur Quellen, sondern:

• Ownership,
• Aktualität,
• Dokumentidentität,
• Versionen,
• strukturierte vs. unstrukturierte Daten,
• Löschungen,
• Datenqualität.

Bei RAG ist die Datenpipeline Teil der Produktlogik.

Deep Dive: RAG-Datenquellen anbinden.

Required Evidence

• Quellinventar,
• Datenklassifikation,
• Änderungsfrequenz,
• führende Quelle,
• bekannte Qualitätsprobleme.

Typischer Failure Mode

Ein Demo-Datensatz ist sauber, die späteren Produktionsdaten aber nicht.

Gate 4 – Identity & Permissions

Kernfrage

Welche Identität gilt an jeder Systemgrenze?

Die Nutzeridentität kann relevant sein für:

• Retrieval,
• API Calls,
• Tool Calls,
• Aktionen,
• Mandantentrennung,
• Audit.

Ein „Service Account für alles“ ist selten ein belastbares Enterprise-Modell.

Required Evidence

• Identity Provider,
• Rollen/Gruppen,
• ACL-Modell,
• Delegation,
• Service Identities,
• Mandantengrenzen.

Für RAG: Berechtigungen & Security Trimming.

Typischer Failure Mode

Das System liefert fachlich richtige Inhalte aus einer Quelle, die der Nutzer nicht sehen dürfte.

Gate 5 – Retrieval

Kernfrage

Welche Information muss zur Laufzeit gefunden werden?

Nicht jede Unternehmensfrage gehört in RAG.

Geeignet sind häufig:

• Dokumentwissen,
• Policies,
• Handbücher,
• Wikis,
• Wissensbestände.

Exakte aktuelle Werte wie Lagerbestand, Kontostand oder Auftragsstatus gehören häufig besser hinter eine kontrollierte API.

Required Evidence

• Query-Typen,
• Source of Truth,
• benötigte Aktualität,
• relevante Dokumenttypen,
• Retrieval-Baseline.

Der Retrieval-Layer sollte gegen reale Fragen getestet werden: RAG Evaluation.

Typischer Failure Mode

Alles wird in einen Vector Store kopiert, auch wenn strukturierte Live-Daten besser direkt abgefragt würden.

Gate 6 – Model

Kernfrage

Welche Modellfähigkeit wird wirklich benötigt?

Zu prüfen sind beispielsweise:

• Sprachqualität,
• Reasoning,
• strukturierte Ausgaben,
• Tool Calling,
• Kontextlänge,
• multimodale Fähigkeiten,
• Latenz,
• Kosten,
• Hosting.

Die Architektur sollte vermeiden, Geschäftslogik unnötig an ein einzelnes Modell zu koppeln.

Gartner empfiehlt 2026 für Enterprise Architecture unter anderem, AI nicht nur als Innovationsprojekt zu behandeln, sondern model-agnostische und multiproviderfähige Architekturen mitzudenken. Quelle: Gartner – Compute, Controls and Cost Define AI’s New Architectural Reality.

Required Evidence

• reale Testfälle,
• Qualitätsvergleich,
• Latenz-/Kostenprofil,
• Daten-/Hosting-Anforderungen.

Typischer Failure Mode

Das „beste“ Modell wird gewählt, bevor klar ist, welche Fähigkeit das System überhaupt braucht.

Gate 7 – Agent / Tools

Kernfrage

Muss das Modell tatsächlich Entscheidungen über Aktionen treffen?

Tool Calling verändert das Risikoprofil.

Ein System, das nur Text generiert, hat andere Failure Modes als eines, das:

• Datensätze ändert,
• Mails sendet,
• Tickets schließt,
• APIs aufruft,
• Zahlungen vorbereitet.

Required Evidence

• erlaubte Tools,
• Tool-Identitäten,
• Parametergrenzen,
• Read/Write-Scope,
• Human Gates,
• Stop Conditions.

Für bestehende Agenten: AI Agent Evaluation.

Typischer Failure Mode

„Tool Calling funktioniert“ wird mit „Tool Calling ist kontrolliert“ verwechselt.

Gate 8 – Integration / API

Kernfrage

Welches System bleibt für welche Information oder Aktion führend?

AI sollte bestehende Systems of Record nicht unkontrolliert duplizieren.

Eine API-first Architektur trennt:

• AI Orchestration,
• Retrieval,
• Business Logic,
• System APIs,
• UI.

Required Evidence

• System-of-Record-Matrix,
• API-Verträge,
• Schreib-/Lesegrenzen,
• Idempotenz,
• Fehlerhandling.

Typischer Failure Mode

Business Logic wandert in Prompts, obwohl sie deterministisch in Services oder Workflows gehört.

Gate 9 – Security & Privacy

Kernfrage

Welche Daten und Aktionen dürfen welche Systemgrenzen überschreiten?

Prüfen Sie technisch:

• Datenklassen,
• Processing Locations,
• Logs,
• Modellprovider,
• Retention,
• Secrets,
• Tool Permissions,
• Prompt-Injection-Pfade,
• Exfiltration.

Self-Hosting oder EU-Hosting ist dabei nicht automatisch DSGVO-konform. Der konkrete Einsatz entscheidet.

Siehe DSGVO-konforme KI für Unternehmen und Private AI vs. Public Cloud.

Die technische Einordnung ersetzt keine Rechtsberatung.

Required Evidence

• Datenflussdiagramm,
• Datenklassen,
• Provider-/Hosting-Modell,
• Logging-Konzept,
• Security Boundaries.

Typischer Failure Mode

Die Architektur bewertet nur, wo das Modell läuft, aber nicht, welche Daten über Connectoren, Logs oder Tools fließen.

Gate 10 – Evaluation

Kernfrage

Was bedeutet „funktioniert“?

Evaluation muss vor dem Build beginnen.

Je nach System:

• Correctness,
• Groundedness,
• Retrieval Quality,
• Citation Accuracy,
• Task Success,
• Tool Accuracy,
• Policy Compliance,
• Human Escalation.

Required Evidence

• Golden Dataset,
• Baseline,
• kritische Failure Classes,
• Go-/No-Go-Kriterien.

Siehe RAG Evaluation und AI Agent Evaluation.

Typischer Failure Mode

Die Demo wird von Projektmitgliedern „gut gefunden“, aber niemand kann Regressionen messen.

Gate 11 – Observability

Kernfrage

Wie erkennen wir, dass das System schlechter wird?

Ein AI-System braucht mehr als Infrastruktur-Monitoring.

Je nach Anwendung relevant:

• End-to-End-Latenz,
• Modell-/Tool-Fehler,
• Retrieval-Failures,
• Datenfreshness,
• Kosten pro Task,
• No-Answer-Rate,
• Eskalationen,
• Regressionen.

Required Evidence

• Events/Traces,
• Metriken,
• Alerting,
• Sampling-/Review-Prozess,
• Incident-Diagnose.

Typischer Failure Mode

Server und APIs sind „grün“, während Antwortqualität oder Retrieval unbemerkt degradiert.

Gate 12 – Operations & Ownership

Kernfrage

Wer trägt nach dem Pilot Verantwortung?

Benötigt werden klare Owner für:

• Produkt/Use Case,
• Daten,
• Modelle,
• Infrastruktur,
• Security,
• Evaluation,
• Incident Response.

Required Evidence

• Owner je Systemschicht,
• Runbook,
• Change-Prozess,
• Rollback,
• Review-Zyklus,
• Kostenverantwortung.

Typischer Failure Mode

Das Pilotteam löst sich auf und niemand besitzt das produktive AI-System.

Minimalarchitektur vs. Zielarchitektur

Ein Pilot muss nicht die komplette Zielplattform enthalten.

Er muss aber die kritischen Architekturtreiber realistisch testen.

Minimalarchitektur

Beispiel:

User → Identity → Application → Retrieval/API → Model → Response + Logging

Zielarchitektur

Später können hinzukommen:

• mehrere Modelle,
• Agenten/Tools,
• zusätzliche Datenquellen,
• Policy Layer,
• Observability,
• Admin-/Evaluation-UI,
• Kostensteuerung,
• Multi-Tenant-Funktionen.

Der Pilot darf Infrastruktur vereinfachen. Er darf aber zentrale Risiken nicht künstlich entfernen.

Mehr dazu: KI-Pilot planen.

Ein nützliches Referenzmodell

Eine technologieoffene Enterprise-AI-Architektur lässt sich grob so denken:

User / System
↓
Identity & Policy
↓
Application / Workflow
↓
AI Orchestration
↙︎ ↓ ↘︎
RAG / Search · Tools / APIs · Models
↓
Evaluation / Observability / Audit
↓
Operations & Ownership

Die konkrete Produktwahl kann sich ändern. Die Grenzen sollten verständlich bleiben.

Architecture Decision Records für AI

Relevante Entscheidungen sollten nicht nur in Slides leben.

Für wichtige Architecture Decisions dokumentieren Sie:

• Entscheidung,
• Kontext,
• Optionen,
• Treiber,
• Risiken,
• Konsequenzen,
• Exit-/Revisit-Trigger.

Beispiele:

• Warum Hybrid Search?
• Warum Public Cloud statt On-Premise?
• Warum Workflow statt Agent?
• Warum Modellabstraktion?
• Warum bestimmte Permission-Strategie?

Das reduziert später „Architecture by Memory“.

12-Gate-Scorecard

Ein einfacher Review kann jeden Gate so markieren:

• Green: Evidenz vorhanden, Entscheidung belastbar.
• Yellow: Annahme plausibel, muss im Pilot geprüft werden.
• Red: kritische Frage offen oder Architektur widersprüchlich.

Ein Go-Live sollte nicht daran hängen, dass alles perfekt ist. Aber kritische rote Gates bei Identity, Security, Evaluation oder Operations sind keine kosmetischen Restarbeiten.

Anti-Patterns

Tool-first Architecture

„Wir haben Azure/OpenAI/LangChain gekauft – jetzt suchen wir den Use Case.“

Prompt as Business Logic

Deterministische Regeln werden in unversionierte Prompts verschoben.

One Model Everywhere

Ein Modell wird ohne Aufgabenvergleich für alle Funktionen verwendet.

RAG Everything

Strukturierte Live-Daten werden unnötig in Dokument-Retrieval gepresst.

Agent Everything

Autonomie wird eingesetzt, obwohl ein Workflow besser kontrollierbar wäre.

Pilot ohne Production Path

Die Demo funktioniert nur mit Testdaten, Admin-Rechten und manueller Nacharbeit.

Wann eine Architekturreview sinnvoll ist

Eine Review ist besonders sinnvoll, wenn:

• mehrere AI-Piloten parallel entstehen,
• Plattform- oder Cloud-Entscheidungen bevorstehen,
• RAG und Agenten in produktive Systeme integriert werden,
• Security/Identity nachträglich kompliziert werden,
• Vendor Lock-in wächst,
• niemand eine klare Zielarchitektur besitzt.

Nächster Schritt

Wenn Sie eine AI-Initiative planen und noch zwischen Plattformen, RAG, Agents, Private AI oder Integrationswegen entscheiden, sollte die Architektur vor einem größeren Build belastbar werden.

Ich unterstütze Unternehmen dabei, Business-Ziel, Systemgrenzen, Daten, Identity, Integration, Evaluation und Betriebsmodell in eine pragmatische Zielarchitektur zu überführen: KI-Beratung & AI Solution Architecture.

Wenn ein PoC bereits existiert und die Frage eher lautet „Ist dieses System produktionsreif?“, passt KI Production Readiness.