Die hybride KI-Architektur

Die Entscheidung zwischen lokaler KI und Cloud wird häufig wie eine Glaubensfrage geführt. Lokal steht für Kontrolle, Cloud für Leistung. In wirklichen Projekten ist beides zu grob. Eine Recherche mit öffentlichem Material, die Analyse vertraulicher Dokumente und eine automatisierte Freigabe haben unterschiedliche Anforderungen. Eine hybride Architektur ordnet deshalb nicht das ganze Unternehmen einem Ort zu. Sie zerlegt Arbeit in Schritte und entscheidet für jeden Schritt neu: Welche Daten sind nötig, welche Fähigkeit wird gebraucht, welche Wirkung entsteht – und wie lässt sich das Ergebnis prüfen?

Hybrid ist kein Kompromiss, sondern Arbeitsteilung

Eine schwache Hybridlösung entsteht, wenn Aufgaben zufällig zwischen mehreren Werkzeugen verteilt werden. Eine starke Hybridarchitektur gibt jedem Ausführungsort eine klare Rolle. Sensible Vorverarbeitung kann nah an den Daten stattfinden, ein leistungsfähiges Modell kann mit bereinigtem Material arbeiten und eine unabhängige Prüfschicht kann das Ergebnis kontrollieren.

Der Vorteil liegt nicht darin, möglichst viele Systeme zu verbinden. Er liegt in der Trennung unterschiedlicher Verantwortungen. Datenhaltung, Verarbeitung, Generierung, Prüfung und Freigabe müssen nicht am selben Ort stattfinden. Ihre Übergänge müssen jedoch sichtbar und begründet sein.

Damit wird Hybridität zu einer Gestaltungsentscheidung: Jeder Schritt erhält genau die Umgebung, die seine Daten, Fähigkeiten und Folgen rechtfertigen. Die Architektur folgt der Arbeit – nicht der Bequemlichkeit eines einzelnen Werkzeugs.

Fünf Kriterien bestimmen den Ausführungsort

Das erste Kriterium ist Sensibilität. Welche Daten braucht der Schritt wirklich, und dürfen sie den kontrollierten Bereich verlassen? Die zweite Frage ist Fähigkeit: Benötigt die Aufgabe besondere Modellqualität, ein großes Kontextfenster, Bilder, Werkzeuge oder hohe Geschwindigkeit?

Drittens zählen Kosten. Nicht nur der Preis pro Anfrage, sondern auch Betrieb, Wartung, Personal und Prüflast gehören dazu. Viertens zählt Latenz: Muss eine Antwort sofort entstehen, darf sie gebündelt werden oder kann sie als Hintergrundlauf arbeiten? Fünftens entscheidet Verifizierbarkeit. Je schwerer ein Ergebnis zu prüfen ist, desto enger sollte seine Wirkung begrenzt sein.

Diese Kriterien wirken zusammen. Ein günstiges Modell kann teuer werden, wenn seine Ergebnisse ständig nachbearbeitet werden. Ein starkes Modell ist ungeeignet, wenn die benötigten Daten nicht in seine Umgebung gelangen dürfen. Routing ist deshalb keine Rangliste von Modellen, sondern eine Zuordnung von Anforderungen.

Drei Zonen schaffen eine lesbare Architektur

Die kontrollierte Zone verarbeitet besonders sensible Informationen, Identitäten, interne Rohdaten oder Schlüssel. Sie reduziert, anonymisiert, extrahiert und prüft, bevor Material weitergegeben wird. Diese Zone kann lokal oder in einer streng kontrollierten Umgebung liegen; entscheidend sind Zugriff und Zweckbindung.

Die geschützte Arbeitszone enthält freigegebene interne Informationen. Dort können Modelle Entwürfe, Analysen und strukturierte Zwischenergebnisse erzeugen. Zugänge, Protokolle und Aufbewahrung bleiben definiert. Die offene Leistungszone arbeitet ausschließlich mit öffentlichem, synthetischem oder ausreichend bereinigtem Material und kann besondere Fähigkeiten flexibel nutzen.

Eine Aufgabe darf zwischen Zonen wandern, aber nie als unsichtbarer Kompletttransfer. Jede Übergabe benennt Felder, Entfernungsschritte, Zweck und Rückkehrweg. Datenminimierung ist damit nicht nur Datenschutz, sondern eine technische Schnittstelle.

Der Router braucht Regeln statt Bauchgefühl

Ein Router kann ein technischer Dienst, ein Workflow oder eine menschlich gepflegte Entscheidungstabelle sein. Seine Aufgabe ist stets gleich: Material klassifizieren, Anforderungen lesen und einen erlaubten Ausführungspfad wählen. Er darf nicht allein nach Modellqualität oder Verfügbarkeit entscheiden.

Gute Routingregeln sind nachvollziehbar. „Wenn personenbezogene Rohdaten benötigt werden, bleibt die Vorverarbeitung in der kontrollierten Zone.“ „Wenn nur ein öffentlicher, bereinigter Auszug gebraucht wird, darf die Generierung in die offene Zone wechseln.“ „Wenn ein Ergebnis externe Wirkung hat, folgt vor der Freigabe ein unabhängiger Review.“

Unsicherheit ist selbst eine Routingbedingung. Kann die Sensibilität nicht sicher bestimmt werden, wählt der Prozess die engere Zone oder stoppt. Automatisches Routing ist nur dort verantwortbar, wo seine Klassifikation überprüfbar bleibt.

Fallbacks machen Architektur belastbar

Eine hybride Architektur darf nicht davon ausgehen, dass jedes Modell und jeder Dienst immer verfügbar ist. Ausfälle, Kapazitätsgrenzen, Kostenänderungen oder Qualitätsprobleme müssen eingeplant werden. Ein Fallback ist dabei nicht einfach das nächste Modell in einer Liste.

Der Ersatzpfad muss dieselben Daten- und Wirkungsgrenzen einhalten. Ist ein leistungsfähiger Dienst nicht erreichbar, kann der Prozess eine kleinere lokale Fassung erzeugen, den Umfang reduzieren, eine Warteschlange bilden oder bewusst anhalten. Keine dieser Varianten sollte stillschweigend eine andere Datenzone öffnen.

Belastbarkeit bedeutet auch degradierte Betriebsarten. Ein System kann vorübergehend nur klassifizieren statt formulieren, nur Entwürfe statt Veröffentlichungen erzeugen oder nur bereits freigegebene Quellen nutzen. Weniger Funktion ist häufig sicherer als ein unkontrollierter Wechsel.

Portabilität schützt vor versteckter Abhängigkeit

Anbieterabhängigkeit entsteht nicht erst bei einem Vertrag. Sie wächst, wenn Prompts, Datenformate, Bewertungsregeln und Arbeitsabläufe nur in einer Oberfläche existieren. Selbst ein technisch austauschbares Modell ist dann praktisch schwer zu ersetzen.

Halte deshalb den Kern außerhalb einzelner Systeme: Aufgabenbeschreibung, Kontextmanifest, Datenklassifikation, Prüfkriterien, Testfälle und Outputschema. Adapter übersetzen diesen Kern in die jeweilige Umgebung. Wird ein Modell gewechselt, bleibt der Arbeitsvertrag erhalten und nur der Adapter verändert sich.

Portabilität verlangt Tests. Zwei Modelle können denselben Auftrag unterschiedlich interpretieren. Ein Wechsel gilt erst dann als gelungen, wenn definierte Referenzfälle, Sicherheitsgrenzen und Qualitätskriterien erneut erfüllt sind. Austauschbarkeit ist eine geprüfte Fähigkeit, keine Behauptung.

Beobachtbarkeit verbindet die Zonen

Wenn Arbeit über mehrere Systeme läuft, braucht sie eine gemeinsame Spur. Welche Datenklasse wurde erkannt? Welcher Pfad wurde gewählt? Welche Bereinigung fand statt? Welches Modell erzeugte welchen Zwischenschritt? Welche Prüfung führte zur Freigabe? Ohne diese Antworten bleibt Hybridität unübersichtliche Verteilung.

Die Spur muss nicht jeden internen Gedankenschritt speichern. Sie sollte Entscheidungen und Wirkungen erklären können. Besonders wichtig sind Übergaben, Fallbacks, Ausnahmen und menschliche Freigaben. Sie zeigen, wo die Architektur tatsächlich Verantwortung getragen hat.

Eine regelmäßige Auswertung verbessert das Routing. Welche Aufgaben landen unnötig in teuren Umgebungen? Wo wird zu viel Kontext übertragen? Welche lokale Verarbeitung erzeugt zu viel Nacharbeit? So wird die Architektur nicht durch Vermutungen, sondern durch beobachtete Arbeit weiterentwickelt.

Der Mensch gestaltet die Grenze, nicht jede Ausführung

Menschen sollen nicht jede Modellwahl einzeln bestätigen. Sie definieren die Regeln, prüfen Grenzfälle und entscheiden über Pfade mit großer Wirkung. Gute Architektur verschiebt menschliche Aufmerksamkeit von Routineentscheidungen zu Ausnahmen, Änderungen und Freigaben.

Dafür braucht es klare Zuständigkeiten: Wer klassifiziert Daten? Wer darf Routingregeln ändern? Wer genehmigt eine neue Abhängigkeit? Wer entscheidet bei Qualitätsabfall? Ohne diese Rollen wird ein technischer Router schnell zu einer unsichtbaren Governanceinstanz.

Eine souveräne hybride Architektur ist deshalb weder lokal um jeden Preis noch grenzenlos vernetzt. Sie ist die Fähigkeit, Arbeit bewusst zu verteilen, Übergaben klein zu halten, Ergebnisse zu prüfen und jederzeit einen sicheren Rückweg zu besitzen.

Die Routingkarte

Eine kompakte Karte hält für jeden Arbeitsschritt Datenklasse, Zone, Übergabe, Prüfung und Fallback an einer Stelle zusammen:

# ROUTINGKARTE

**Arbeitsschritt und Wirkung**
Was soll entstehen, welche Folge darf es haben?

**Datenklasse**
Öffentlich, intern, sensibel oder besonders kontrolliert?

**Fähigkeitsbedarf**
Welche Qualität, Modalität, Werkzeuge, Geschwindigkeit und Kontextmenge sind nötig?

**Zone und Modellrolle**
Wo wird vorverarbeitet, generiert, geprüft und freigegeben?

**Übergabe**
Welche Felder verlassen eine Zone, was wird entfernt oder ersetzt?

**Verifikation**
Wie wird das Ergebnis vor der nächsten Wirkung geprüft?

**Fallback**
Welche sichere Ersatz- oder Reduktionsstufe gilt bei Ausfall?

**Portabilität**
Welche Standards, Tests und Adapter ermöglichen einen Wechsel?

Die beste hybride Architektur ist nicht die technisch eindrucksvollste. Es ist diejenige, bei der jede Übergabe einen Zweck hat, jedes Modell eine begrenzte Rolle erfüllt und ein Wechsel möglich bleibt, ohne Wissen, Sicherheit oder Arbeitsfähigkeit zu verlieren.

Übungsblatt: Entwirf einen hybriden Modellpfad

Wähle einen realen Prozess mit mindestens drei Arbeitsschritten. Ordne nicht das ganze Projekt einem Modell zu, sondern gestalte einen prüfbaren Pfad.

1. Schritte und Wirkung trennen. Zerlege den Prozess in Vorverarbeitung, Generierung, Prüfung und Freigabe. Benenne je Schritt die mögliche Wirkung.

2. Daten und Fähigkeiten klassifizieren. Ordne Datenklasse, benötigte Modellfähigkeit, Latenz, Kosten und Verifizierbarkeit zu.

3. Zonen und Übergaben entwerfen. Bestimme für jeden Schritt die Zone. Notiere exakt, welche Informationen eine Grenze passieren und wie sie reduziert werden.

4. Fallback und Degradation planen. Definiere für zwei Ausfälle einen sicheren Ersatz, eine reduzierte Betriebsart oder einen bewussten Stopp.

5. Portabilität testen. Formuliere drei Referenzfälle und die Kriterien, die ein alternatives Modell oder ein neuer Adapter erfüllen muss.