AI ARCHITECTURE

KI ist kein Feature. Sie ist ein Systemrisiko mit Wertschöpfungspotenzial, beides zugleich.

Und genau deshalb scheitern so viele Projekte.

Nicht am Modell. Nicht an der API. Sondern am (fehlenden?) Denken davor.

WARUM AI‑PROJEKTE WIRKLICH SCHEITERN

Die Zahlen sind unerfreulich:

• Bis zu 95 % aller GenAI‑Piloten erreichen keine Produktion (MIT, 2025).
• 30 % aller GenAI‑Projekte werden nach dem PoC ersatzlos eingestellt (Gartner, 2024/25).
• Bei Agentic AI prognostiziert Gartner bereits heute eine Abbruchrate von rund 40 %.

„Changing Anything Changes Everything.“ — Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS

Das ist kein Zufall, sondern ein Strukturproblem. Die Industrie produziert gerade massenhaft PoC‑Leichen, weil KI als Plug‑and‑Play missverstanden wird. Das Ergebnis ist kein Produkt, sondern Hidden Technical Debt.

LLMs haben dieses Problem nicht gelöst, sie haben es beschleunigt.

DAS EIGENTLICHE PROBLEM: ARCHITEKTUR

In KI‑Systemen besteht meist:

• 5 % aus Modellcode
• 95 % aus Glue Code (Datenaufbereitung, Prompt‑Logik, Retrieval, Evaluation, Monitoring, Logging)

Heute liegt dieser Glue Code häufig direkt in der Business‑Logik – sprich Prompt Engineering mitten in der Business‑Logik.

Konsequenzen:

• Keine Austauschbarkeit von Modellen
• Keine saubere Testbarkeit
• Keine erklärbare Entscheidungskette
• Keine Compliance‑Fähigkeit

Kurz: Ein System, das beim ersten Modell‑Update implodiert.

DIE NEUE REALITÄT: AMBIGUITÄTSTOLERANZ

Es gibt noch einen zweiten, oft übersehenen Scheitergrund: Das falsche Mindset. GenAI-Systeme sind nicht deterministisch. Sie sind probabilistisch. Der gleiche Input liefert morgen vielleicht einen anderen Output.

Wer hier mit klassischem „Requirements Engineering“ (starre Lastenhefte, binäre Abnahmen) herangeht, wird scheitern. Wir müssen lernen, im Nebel zu navigieren.

Unschärfe ist nicht das Problem, sondern das Material, das Blut in der Adern der Modelle.

Es geht nicht mehr um „Fertig“ oder „Perfekt“, sondern um „Good Enough“ und die Frage: Ist die Antwort im Kontext hilfreich? Am besten werden dazu Domänenexpert:innen herangezogen, denn ich bin ein großer Fan des domänenzentrierten Vorgehens (Stichwort: Domain Driven Design).

Anforderungen werden nicht mehr spezifiziert, sondern im Dialog mit dem System verhandelt.

Product Owner und Architekt:innen müssen zu „Uncertainty Specialists“ werden. Sie müssen entscheiden, wie viel Freiheit das Modell bekommt und wie viel Kontrolle nötig ist. Ohne diese Ambiguitätstoleranz – die Fähigkeit, Mehrdeutigkeit auszuhalten und produktiv zu nutzen – wird jedes GenAI-Projekt zur Frustrationsmaschine.

MEIN ANSATZ: ARCHITECTURE FIRST.

Ich arbeite als AI Architect an der Schnittstelle von:

• Software‑ und Cloud‑Architektur
• KI‑Engineering
• Data & AI‑Governance
• Recht (EU AI Act, DSGVO, Data Act)

Nicht theoretisch, sondern in laufenden Projekten – u. a. bei GÖRG in KI‑gestützten Systemen im juristischen Umfeld und in weiteren regulierten Kontexten.

Ich baue keine „smarten Demos“, sondern KI‑fähige Architekturen, die:

• skalieren
• messbar sind (Stichwort: Build‑Measure‑Learn‑Circle)
• erklärbar bleiben
• rechtlich standhalten

WAS EIN AI ARCHITECT HEUTE KÖNNEN MUSS

TECHNIK: DIE FABRIK, NICHT DAS MODELL

Ein AI Architect ist kein Data Scientist. Er baut nicht das Modell, sondern die Produktionsstraße.

• Modell‑Strategie
  • Proprietär vs. Open Source (Llama, Mistral) vs. Small Language Models
  • → Entscheidung nach Risiko, Kosten, Kontrollbedarf
• RAG vs. Fine‑Tuning
  • RAG: flexibel, aber teuer im Betrieb
  • Fine‑Tuning: teuer am Anfang, günstiger in der Inferenz
  • → TCO‑Berechnung vor Projektstart, nicht danach
• Evaluation & Qualität
  • LLM‑as‑a‑Judge, RAGAS, Bias‑Checks
  • Qualität wird gemessen – nicht gefühlt

GOVERNANCE: LAW AS CODE

Der EU AI Act ist kein reines Compliance‑PDF, sondern eine technische Spezifikation mit Rechtsfolgen.

• Art. 12 – Logging & Traceability
  • Architektur braucht unveränderbare Protokolle: Inputs, Outputs, Modellversion, Datenquelle, Vektor‑Referenzen.
• Art. 10 – Datenqualität
  • Repräsentativität, Bias‑Kontrolle, dokumentierte Schwellenwerte.
• Art. 14 – Human Oversight (Der Mensch im Loop)
  • Human Oversight ist kein Schalter, den man einfach umlegt (“Human in the Loop: Check”). Es ist ein Versprechen an den Betroffenen, dass eine menschliche Entscheidung wirklich stattfindet – und keine Simulation.
  • Architektur-Lösung: Statt simpler asynchroner Events (“Fire & Forget”) implementiere ich State-Machines mit “Pending”-Status.
  • Frozen State: Der Mensch sieht exakt den Daten-Snapshot, den die KI bewertet hat. Ändern sich die Daten während des Reviews, wird der Prozess invalidiert.
  • Circuit Breakers gegen Rubber-Stamping: Wenn ein Reviewer 500 Fälle pro Stunde “durchwinkt”, greift die Sicherung. Denn wer nur stempelt, übt keine Aufsicht aus (Rubber-Stamping-Verbot).
• Risk‑Tiering (ISO 42001)
  • High‑Risk‑Module technisch isoliert, anders überwacht und dokumentiert als harmlose Assistenzfunktionen.

Compliance entsteht hier nicht durch Juristen am Ende, sondern durch Architektur am Anfang – gern in Zusammenarbeit mit einem Juristen, der von Anfang an dabei ist: mich.

WAS ICH KONKRET LEISTE

• Entwurf belastbarer AI‑Systemarchitekturen
• Saubere Trennung von Modell, Retrieval, Prompt‑Layer, Business‑Logik
• Governance‑ und Logging‑Konzepte by design (inkl. Art. 14 Patterns wie Pending States & Circuit Breakers)
• Etablierung von Ambiguitätstoleranz als Prozess: Weg von binären Abnahmen, hin zu wirkungsbasierten Metriken
• Entscheidungsgrundlagen zu Kosten, Risiko, Modellwahl, Betriebsfähigkeit
• Integration von EU AI Act, Data Act, DSGVO und damit Data Governance von Beginn an. Denn glauben Sie mir, sie müssen die Kosten dafür ohnehin aufbringen, nur später werden sie exorbitant höher sein. Wie bei technischen Schulden. Je länger diese “dahinfaulen”, desto schwieriger und vor allem teurer wird nachher die Beseitigung.

Ich verhindere:

• PoC‑Friedhöfe
• Untestable Prompt‑Monster
• Compliance‑Nachrüstung unter Zeitdruck
• Juristisch unangenehme Überraschungen (z.B. wegen Rubber-Stamping oder fehlendem Human Oversight)

KURZ GESAGT

Ich mache AI Architecture für Organisationen, die KI wirklich betreiben wollen, nicht nur darüber reden. Denn Machen ist wie Wollen, nur krasser.

Für Entscheider, die verstehen, dass ein System nicht dann gut ist, wenn es beeindruckt, sondern wenn es auch in zwei Jahren noch erklärbar ist.

Und für Projekte, die lieber heute sauber gebaut werden, als morgen teuer verteidigt.

Suchen Sie jemanden, der Code liest, Gesetze versteht und Architektur ernst nimmt?
Dann passen wir wahrscheinlich gut zusammen.