Die Architektur eines KI-Projekts: drei Muster und die Disziplin, die sie nachhaltig macht

Überarbeitete Notiz vom 25. Mai 2026. Ursprünglich im März 2026 veröffentlicht — vollständige Überarbeitung.

Die Architektur eines KI-Projekts bezeichnet die Gesamtheit der strukturierenden technischen Entscheidungen: welches Modell verwendet wird, in welchem Zugangsmodus, wie die Daten verwaltet werden, wie die Komponenten orchestriert werden. Diese Entscheidungen bestimmen dauerhaft Kosten, Leistung und Skalierbarkeit des Ergebnisses. Ein schlechter technischer Start kostet Monate Verzögerung und Zehntausende von Franken; ein guter Start ist nicht sichtbar, weil er die ruhige Entwicklung des Projekts über mehrere Jahre erlaubt.

Diese Notiz legt die drei Architekturmuster dar, die die Praxis 2026 strukturieren, qualifiziert die Kriterien, die ihre geeignete Anwendung unterscheiden, und identifiziert die Disziplin, die diese Entscheidungen über den anfänglichen Start hinaus nachhaltig macht.

Drei Architekturmuster, die die Praxis strukturieren

Die scheinbare Vielfalt der KI-Projekte reduziert sich in der Praxis auf drei grundlegende Architekturmuster. Zu verstehen, was diese drei Muster unterscheidet, und zu wissen, welches einem gegebenen Anwendungsfall entspricht, stellt die strukturierendste technische Entscheidung eines Projekts dar.

Das Muster API Wrapper: direkter Zugang zu Modellen über programmatische Schnittstelle

Das einfachste Muster besteht darin, ein Sprachmodell über seine programmatische Schnittstelle aufzurufen und die Geschäftslogik der Anwendung um diesen Aufruf herum aufzubauen. Keine dedizierte Infrastruktur zu verwalten, keine spezialisierte Hardware bereitzustellen. Die Betriebskosten sind proportional zur tatsächlichen Nutzung.

Dieses Muster eignet sich für rasches Prototyping, moderate Volumen und Anwendungsfälle, die keine feine Kenntnis unternehmensspezifischer Daten verlangen: Zusammenfassung generischer Texte, einfache Klassifikation, Erzeugung standardisierter Inhalte. Ein KMU kann mit diesem Ansatz innerhalb weniger Tage einen funktionalen Prototyp erreichen.

Seine Hauptgrenze liegt in der Abhängigkeit von einem einzelnen Anbieter. Der Modellmarkt entwickelt sich schnell, und die Preis-Leistungs-Abwägungen verschieben sich regelmässig. Von Anfang an eine Abstraktionsschicht aufzubauen, die die Geschäftslogik vom Modellanbieter isoliert, bewahrt die Freiheit, den Anbieter zu wechseln, ohne die Anwendung neu zu schreiben. Diese Disziplin — oft mit dem Begriff Provider Pattern bezeichnet — ist kein Luxus; sie ist eine operative Versicherung, deren Anfangskosten marginal sind und deren Wert sich beim ersten Anbieterwechsel offenbart.

Das Muster RAG: Antworten in unternehmensspezifischen Daten verankern

Das Muster RAG — für Retrieval-Augmented Generation — ist zum Standard für Unternehmensprojekte geworden, die eine Kenntnis der organisationsspezifischen Daten verlangen. Statt alles in den an das Modell gesendeten Prompt zu injizieren, kombiniert man eine semantische Suchmaschine mit einem Sprachmodell.

Die Funktionsweise zerlegt sich in drei Schritte. Zuerst die Indexierung: Die Unternehmensdokumente — Handbücher, interne Verfahren, Wissensdatenbank, Produktkatalog, juristisches Korpus — werden in Segmente zerlegt und in vektorielle Darstellungen umgewandelt, die ihren semantischen Sinn erfassen. Dann die Suche: Wenn eine Anwenderin oder ein Anwender eine Frage stellt, identifiziert das System die relevantesten Segmente durch vektorielle Ähnlichkeit statt durch reine Stichwort-Übereinstimmung. Schliesslich die Generierung: Das Modell empfängt die Frage zusammen mit den relevanten Segmenten und produziert eine kontextualisierte Antwort, die ihre Quellen zitieren kann.

Dieses Muster beantwortet die zentrale Herausforderung allein genutzter Sprachmodelle: die Halluzinationen. Indem es jede Antwort in geprüften Dokumenten verankert, bleibt das System faktisch. Wenn die Wissensbasis die Antwort auf eine Frage nicht enthält, kann das System es ausdrücklich sagen, statt zu erfinden.

Seine Qualität hängt jedoch direkt von der Qualität der indexierten Daten ab. Veraltete, schlecht strukturierte, widersprüchliche oder unvollständige Dokumente produzieren mittelmässige Antworten, unabhängig vom verwendeten Modell. Die Datenvorbereitungsarbeit — im kommerziellen Diskurs um die Werkzeuge oft vernachlässigt — stellt in der in der Kanzlei beobachteten Praxis bei MCVA-Projekten einen substanziellen Anteil des Gesamtaufwands dar — typischerweise zwischen der Hälfte und zwei Dritteln bei seriösen Projekten. Diese Beobachtung verdient es, bei der Rahmenfestlegung gestellt zu werden, weil sie die Aufwandschätzung substanziell verändert.

Das Muster Agenten: die Ausführung mehrstufiger Aufgaben delegieren

Das Agenten-Muster stellt die nächste Komplexitätsstufe dar. Ein Agent ist ein modellgestütztes System, das Werkzeuge — Websuche, Berechnungen, API-Aufrufe, Datenbankabfragen — verwenden und eine Aktionsfolge planen kann, um eine komplexe Aufgabe zu bewältigen.

Dieses Muster eignet sich für Aufgaben, die mehrere koordinierte Schritte erfordern: Informationssuche, Zwischenanalyse, Entscheidung über das weitere Vorgehen, Ausführung einer Aktion in einem Geschäftssystem. Die End-to-End-Automatisierung komplexer Workflows — Überprüfung eines Bestellstatus in einem bestehenden Managementsystem gefolgt von einer Aktualisierung in einem anderen, beispielsweise — bildet den typischen Anwendungsfall.

Der operative Vorteil ist substanziell, wenn das Muster geeignet ist: End-to-End-Automatisierung von Geschäftsprozessen, die klassisch mehrere menschliche Eingriffe erforderten. Seine Grenze liegt in der Komplexität der Umsetzung — das Debugging eines mehrstufigen Agenten ist anspruchsvoll — und in den hohen Betriebskosten: Ein Agent kann mehrere Dutzend Modellaufrufe ausführen, um eine einzige komplexe Aufgabe zu bearbeiten. Dieses Muster ist Anwendungsfällen mit hohem Mehrwert vorbehalten, in denen die Komplexität die Betriebs- und Wartungskosten rechtfertigt.

Die strukturierende Disziplin: die Datenqualität geht vor der Modellwahl

Der häufigste beobachtbare Fehler bei KI-Projekten besteht darin, die Aufmerksamkeit auf die Modellwahl zu konzentrieren, während die Datenqualität die Endqualität des Ergebnisses unverhältnismässig stark bestimmt.

Drei Beobachtungen stützen diese Qualifikation.

Erstens ist bei Projekten, die auf unternehmensspezifischen Daten beruhen — der Mehrheit der seriösen Projekte —, der Qualitätsunterschied zwischen den wichtigsten verfügbaren Modellen relativ gering im Vergleich zum Unterschied, den die Qualität der indexierten Daten erzeugt. Ein mit sauberen und strukturierten Dokumenten gespeistes RAG-System auf einem Modell mittlerer Kapazität produziert regelmässig bessere Ergebnisse als ein mit unorganisierten Dokumenten gespeistes RAG-System auf einem Spitzenmodell.

Zweitens hat die Investition in die Datenqualität einen kumulativen und nachhaltigen Charakter. Einmal bereinigte und strukturierte Daten dienen allen späteren Nutzungen. Die Wahl eines Modells hingegen muss regelmässig neu überdacht werden, weil sich der Markt entwickelt. Aufwand in Daten statt in Modellauswahl zu investieren erzeugt also einen dauerhafteren Wert.

Drittens zeigt die beobachtbare Praxis, dass die scheiternden Projekte ein gemeinsames Merkmal teilen: Sie haben den Datenvorbereitungsaufwand unterschätzt und es zu spät entdeckt. Die erfolgreichen Projekte investieren ab der anfänglichen Rahmenfestlegung in diese Vorbereitung und begleiten den Einsatz mit Datenwartungsprozessen, die die Qualität über die Dauer bewahren.

Fünf wiederkehrende Fehler, die die Praxis beobachtet

Über die Musterwahl und die Datenaufmerksamkeit hinaus verdienen fünf wiederkehrende Fehler identifiziert zu werden, weil sie substanzielle Opportunitätskosten erzeugen.

Mit dem Zusatztraining eines Modells beginnen. Das Zusatztraining — oft mit dem Begriff Fine-tuning bezeichnet — ist selten in erster Linie notwendig. In der überwiegenden Mehrheit der Fälle produziert ein RAG-System mit gut konstruierten Prompts gleichwertige Ergebnisse zu einem Bruchteil der Kosten und des Aufwands. Das Zusatztraining ist in spezifischen Situationen relevant, in denen das Modell einen sehr besonderen Stil annehmen oder ein technisches Vokabular beherrschen muss, das RAG nicht korrekt abdeckt. Bevor man in diese Richtung investiert, ist es in der Regel produktiver, die RAG-Optimierung weiterzutreiben.

Die Datenqualität ignorieren. Der Punkt wurde oben entwickelt, aber er verdient es, wiederholt zu werden, weil er wahrscheinlich den strukturierendsten Fehler darstellt.

Die systematische Evaluation vernachlässigen. Ohne Qualitätsmetriken — Relevanz, Quelltreue, Vollständigkeit — ist es unmöglich, Fortschritte objektiv zu messen. Einen Evaluationsrahmen ab dem Projektstart einzurichten, mit einem Referenzset von einigen Dutzend menschlich validierten Frage-Antwort-Paaren, stellt die operative Investition mit der höchsten Rendite dar.

Die Betriebskosten in Produktion unterschätzen. Ein Prototyp, der in der Erkundungsphase ein moderates Budget verbraucht, kann in realer Produktion ein substanziell höheres Budget erreichen. Die Vorausberechnung auf Basis der erwarteten Nutzerzahl, der Nutzungshäufigkeit und der durchschnittlichen Anfragegrösse verdient es, bei der Rahmenfestlegung geführt zu werden, statt im Betrieb entdeckt zu werden.

Ein monolithisches System bauen. Ein System, das in einem einzigen, untrennbaren Block die Suchmaschine, das Sprachmodell, den Cache, die Benutzeroberfläche und die Evaluationsschicht vermischt, ist schwer weiterzuentwickeln und zu debuggen. Eine modulare Architektur, in der jede Komponente unabhängig ist, erlaubt, ein Element zu ersetzen, ohne die anderen anzutasten. Diese Modularität verlangt zu Beginn keinen substanziellen Aufwand, bewahrt aber die Skalierbarkeit des Systems über die Dauer.

Die für ein KMU empfohlene progressive Strategie

Für ein Schweizer KMU, das ein KI-Projekt startet, unterscheidet ein progressiver Ansatz die Projekte, die zum Abschluss kommen, von jenen, die im Sande verlaufen.

Die Erkundungsphase zuerst, geführt mit einem API-Wrapper-Muster auf einem präzisen und messbaren Anwendungsfall. Diese Phase, die sich typischerweise über einige Wochen erstreckt, validiert, dass das Konzept im spezifischen Unternehmenskontext trägt. Ihre Bescheidenheit ist ihre Stärke: eine begrenzte Investition, ein beschränktes Risiko, sofortige Lernerkenntnisse.

Der angereicherte Prototyp danach, in der Regel mit einem RAG-Muster auf den unternehmensspezifischen Daten, begleitet von einer systematischen Qualitätsbewertung und ersten Anwendertests. Diese Phase, die sich über einige Monate erstreckt, passt das System an die realen Nutzungsbedingungen an und identifiziert die vor der Produktivsetzung notwendigen Anpassungen.

Die Produktivsetzung mit Monitoring vervollständigt die Sequenz. Diese Phase setzt das System in seinem Zielnutzungskontext ein, mit den Anwender-Feedback-Prozessen, der kontinuierlichen Verbesserung der Prompts und der Datenwartung, die die Qualität über die Dauer bewahren.

Die Bewertung eines eventuellen Zusatztrainings des Modells oder der Hinzufügung von Agenten zur Automatisierung komplexer Workflows erfolgt erst nach dieser Produktivsetzung, auf der Grundlage realer Beobachtungen statt Hypothesen. Diese Wartedisziplin unterscheidet Projekte, die einen operativen Wert konsolidieren, von jenen, die Komplexitätsschichten anhäufen, ohne greifbaren Nutzen.

Die Souveränität der bearbeiteten Daten

Für Projekte, die Daten betreffen, die dem Bundesgesetz über den Datenschutz^[1] oder spezifischen sektoralen Pflichten unterliegen, strukturieren drei Ansätze die Praxis nach zunehmender Strenge.

Die vertraglichen Nicht-Aufbewahrungs-Zusagen zuerst, mit den wichtigsten Modellanbietern für ihre Unternehmensangebote verhandelbar. Dieser Ansatz eignet sich für die Mehrheit der Fälle, in denen die Daten sensibel, aber nicht strategisch kritisch sind.

Das Hosting auf europäischer oder schweizerischer Infrastruktur danach, das garantiert, dass die Daten die betroffene Jurisdiktion nicht verlassen. Dieser Ansatz eignet sich für Kontexte, in denen die Lokalisierung eine ausdrückliche Anforderung ist, sei sie regulatorisch oder vertraglich.

Der Einsatz auf kontrollierter Infrastruktur vervollständigt die Liste, in der Regel mit offenen Modellen. Dieser Ansatz garantiert, dass die Daten vollständig auf der Unternehmensinfrastruktur bleiben, zum Preis einer internen technischen Kompetenz und materieller Investitionen, die substanziell sein können.

Für Unternehmen, die strengen sektoralen Regulierungen unterliegen — Finanzsektor, Gesundheit, öffentliche Verwaltung —, vermeidet eine bei der anfänglichen Rahmenfestlegung geführte formale Risikoanalyse kostspielige Abwägungen auf halbem Weg.

Die Disziplin, die Ernsthaftigkeit auszeichnet

Die Wahl einer Architektur für ein KI-Projekt ist keine Frage spitzer Expertise, die nicht-technischen Entscheidern unzugänglich wäre. Es ist eine Frage methodischer Disziplin: das geeignete Muster für den Anwendungsfall stellen, in die Datenqualität vor der Modellwahl investieren, von Anfang an die Skalierbarkeitsbedingungen des Systems aufbauen, die Souveränitätsfrage ausdrücklich behandeln statt sie zu umgehen.

Diese Disziplin unterscheidet auch hier Projekte, die einen dauerhaften Wert produzieren, von solchen, die Budget verbrauchen, ohne die Funktionsweise der Organisation tatsächlich zu transformieren. Sie verlangt kein besonderes technisches Genie. Sie verlangt anhaltende Aufmerksamkeit gegenüber der beruflichen Strenge der anfänglichen Abwägungen.

Zum RAG-Muster im Besonderen und zu den konversationellen Architekturen, die es als Sockel verwenden, siehe auch die Notiz Durch generative Modelle gespeiste Chatbots: vom skriptbasierten FAQ zu agierenden Agenten.

Quellen

[1] Bundesgesetz über den Datenschutz (DSG), Revision vom 25. September 2020, in Kraft seit 1. September 2023. www.fedlex.admin.ch/eli/cc/2022/491/de [↩]

Jérôme Deshaie ist CEO der MCVA Consulting SA, Schweizer Kanzlei für strategische Beratung in künstlicher Intelligenz mit Sitz im Wallis.