Falsche Antworten, sensible Daten, eigenständige Aktionen und schwer steuerbare Kosten: Je konkreter der Einsatz, desto konkreter werden die Anforderungen.
Wir untersuchen, welche Lösungen zu welchen Problemen passen, wo Gateways helfen und welche wiederkehrende Arbeit ein Produkt von zoon übernehmen könnte.
Neun Perspektiven auf konkrete Arbeitsabläufe. Öffne ein Thema, um Lösungsansätze, den möglichen Gateway-Beitrag und dessen Grenzen zu vergleichen.
Projektteams bearbeiten Kundenunterlagen, der Vertrieb Ausschreibungen, die Entwicklung Code – in Browser-Chats, Coding-Assistenten und eigenen Skripten. Die Mitarbeitenden wollen ihre Tools behalten. Die IT muss Zugänge verwalten und bei Ausfällen helfen. Die Datenschutzbeauftragte (DSB) braucht Auskunft darüber, welche Daten wohin gelangen, was gespeichert wird und wer darauf zugreifen kann.
Die erste Aufgabe: diese Wege erfassen. Geschäftsführung und IT legen Einsatz und Betrieb fest; die DSB berät und überwacht. Ein Systemhaus kann Einrichtung und Support übernehmen, wenn Aufgaben und Zugriffe geklärt sind.
Fiktiver Diskussionsfall, keine Kundenerhebung. Die Verantwortung bleibt beim Unternehmen.
Fachliche Evaluation, Prüfregeln, belastbare Quellen, Freigabe durch Menschen.
Modellversionen zuordnen, Telemetrie und Prüfbausteine einbinden.
Fachliche Wahrheit oder richtige Geschäftsentscheidung garantieren.
Datenminimierung, lokale Verarbeitung, Pseudonymisierung, DLP, Berechtigungen.
Regeln und Maskierung auf angeschlossenen Wegen durchsetzen.
Alle Geheimnisse erkennen, alle Apps erfassen oder Konformität garantieren.
Kleine Berechtigungen, Freigaben, Sandboxes, fachliche Transaktionsregeln.
Angebundene Werkzeuge und Identitäten begrenzen.
Beliebige Änderungen rückgängig machen oder lokale Shellaktionen automatisch kontrollieren.
Usage-Zuordnung, Budgets, Reservierungen, Parallelitätslimits, feste Modellwahl.
Kosten erfassen, Modellzugang und Limits zentral anwenden.
Bereits bestehende Chat-Abos verbilligen oder jede Rechnung hart deckeln.
Grenzen zwischen Daten und Anweisungen, geringe Rechte, Ausgabevalidierung, Angriffstests.
Filter einbinden und mögliche Aktionen begrenzen.
Prompt Injection zuverlässig vollständig beseitigen.
Monitoring, Konfigurationsverwaltung, Rotation, Backup/Restore, begrenzte Retries/Fallbacks.
Gemeinsamen Zugang und Fehlerroutinen bereitstellen.
Verantwortung, Wiederherstellung und Betriebsbereitschaft automatisch herstellen.
Datenpflege, Quellenbewertung, Retrieval-Evaluation, Rechte in den Quellsystemen.
Herkunft/Modellwege teilweise protokollieren.
Datenqualität und korrekte Retrieval-Auswahl herstellen.
Passende kleinere Modelle, lokale Inferenz, Optimierung, Caching.
Zwischen geeigneten Backends routen.
Rechenleistung erzeugen oder Hardware-/Energieengpässe lösen.
Verantwortliche, Freigabeabläufe, vorhandene Tickets-/GRC-Systeme.
Beschlossene technische Regeln umsetzen und Belege liefern.
Organisatorische oder rechtliche Entscheidungen treffen.
Agentenidentität und Zahlungsabwicklung sind weitere mögliche Felder. Ein API-Schlüssel und ein Budgetzähler ergeben noch keinen vollständigen Zahlungs- oder Vertretungsprozess. Dafür fehlt uns bislang ein konkreter Untersuchungsablauf.
Einordnung aus unserem Research, gestützt auf NIST AI 600-1 und die OWASP-Risikobeschreibungen. Die Zuordnung zu Lösungen ist unsere Synthese, keine Rangliste der Marktchancen.
Ein Gateway liegt zwischen angebundenen Anwendungen und Modellen oder Werkzeugen. Dort kann es Regeln anwenden. Entscheidend ist, ob das Problem an dieser Stelle kontrollierbar ist.
Identitäten, Modellzugang, Werkzeugrechte, Kostenregeln und Fehlerbehandlung konfigurieren. Anschließend die Wirkung im tatsächlichen Client testen.
Fachliche Prüfung, Datenpflege, lokale Verarbeitung, bessere Anwendungsbedienung oder klare Zuständigkeiten können geeigneter sein.
Beispiel: Ein Gateway macht eine falsche Kalkulation nicht automatisch richtig.
Modellverkehr und MCP-Werkzeugverkehr sind getrennte Wege. Ein MCP-Anschluss leitet Modellanfragen nicht automatisch um. Fremde SaaS-interne Aufrufe und lokale Shellaktionen werden dadurch nicht automatisch erfasst.
Eine zusätzliche Kontrollstelle bringt eigene Kosten und Fehlerquellen mit. Ob Nutzer sie akzeptieren, hängt davon ab, wie gut sie in den tatsächlichen Arbeitsablauf passt. Eine allgemeine Unbeliebtheit haben wir nicht untersucht.
| Nachteil / Risiko | Woran Nutzer oder Betreiber es merken | Was wir prüfen sollten |
|---|---|---|
| Aufwendige Einrichtung | Andere Serveradresse, neuer Schlüssel, SSH-Tunnel, Zertifikate oder eine zusätzliche Anmeldung. Manche Apps bieten keine passende Einstellung. | Einrichtung auf einem frischen Client beobachten. Manuelle Schritte, Fehlversuche und benötigte Unterstützung erfassen. Unser Tunnel ist ein Laborzugang, kein fertiger Rollout. |
| Umgehung des vorgesehenen Wegs | Wenn der neue Weg blockiert oder langsamer ist, kann ein direkter Providerzugang attraktiver bleiben. | Akzeptanz mit echten Nutzern prüfen und feststellen, welche anderen Zugänge bestehen. Gatewayregeln erfassen nur den angeschlossenen Verkehr. |
| Ein zusätzlicher Ausfallpunkt | Fällt der einzige Gateway oder seine Verbindung aus, erreichen Clients darüber auch einen gesunden Provider nicht mehr. | Nur den Laborgateway stoppen, Clientfehler und Wiederanlauf messen. Ein direkter Notfallzugang würde die Gatewaykontrollen umgehen. |
| Neue gemeinsame Abhängigkeiten | Mehrere Gatewayinstanzen können trotzdem dieselbe defekte Datenbank, DNS-/Netzverbindung oder falsche Policy verwenden. | Abhängigkeiten einzeln betrachten. Replikate helfen gegen einzelne Instanzausfälle, nicht gegen jeden gemeinsamen Fehler. |
| Latenz und Wartezeiten | Ein zusätzlicher Netzweg, Inhaltsprüfung oder eine Warteschlange verzögert die erste Antwort. Wiederholungen können die Gesamtdauer erhöhen. | Direkt und über Gateway mit demselben Backend vergleichen. Zeit bis zum ersten Inhalt und bis zum Abschluss getrennt messen. |
| Inkompatible oder verspätete Funktionen | Neue Clientfunktionen, Streaming, Tool-Calls oder API-Formate funktionieren durch den Proxy anders oder noch nicht. | Die tatsächlich eingesetzte Clientversion prüfen. Unser Chat-Completions-Echo beweist keine vollständige Claude-/Codex-Kompatibilität. |
| Störende Regeln | Fehlalarme entfernen nötige Informationen. Ein Budget sperrt mitten im Ablauf. Ein Ersatzmodell verändert die Antwortqualität. | Fehlermeldung, Korrekturweg und Freigabeprozess mit Nutzern testen. Technisch korrektes Blockieren kann fachlich trotzdem unbrauchbar sein. |
| Konzentration sensibler Daten | Ein Gateway kann viele Anfragen und Providerzugänge sehen. Umfangreiche Logs schaffen einen weiteren sensiblen Datenbestand. | Inhalte minimieren, Adminzugriffe und Aufbewahrung begrenzen. Kundentrennung und Betriebsmodell ausdrücklich prüfen. |
| Zusätzliche Pflegekosten | Clientänderungen, Modellpreise, Schlüssel, Updates und Störungen müssen laufend betreut werden. | Gesamten Einführungs- und Betriebsaufwand gegen den beobachteten Nutzen stellen. Ein Partnerkanal beseitigt diese Arbeit nicht automatisch. |
Bringt die gemeinsame Kontrolle in diesem Arbeitsablauf mehr Nutzen, als Einrichtung, Einschränkungen und zusätzlicher Betrieb kosten?
Single Point of Failure: Unser aktuelles Labor verwendet jeweils eine Gatewayinstanz. Der MacBook-Zugang hängt zusätzlich vom SSH-Tunnel, dem Mini und Docker ab. Ein getesteter Neustart belegt Wiederanlauf, keine durchgehende Verfügbarkeit. Der kontrollierte Instanzausfall ist inzwischen aus MacBook-Clientsicht geprüft; ein separater Tunnel- oder Netzwerkausfall bleibt offen.
Bei Ausfall: Sperren erhält die Kontrollgrenze, unterbricht aber die Arbeit. Ein kontrollierter Ersatz-Gateway kann Verfügbarkeit erhöhen. Direkt am Gateway vorbei weiterzuleiten kann dessen Rechte-, Daten- und Kostenregeln aushebeln. Diese Entscheidung gehört zum Betriebsmodell.
Das Labor macht einzelne Kontrollmechanismen sichtbar. Es prüft synthetische Aufgaben und harmlose Werkzeuge. Echte Modellqualität, Kundennachfrage und Rechnungen sind damit nicht bewertet.
Ohne Schlüssel wird die Anfrage abgewiesen. Ein gültiger A-Schlüssel darf das B-Modell trotzdem nicht nutzen. Im Mock kam der verbotene MacBook-Aufruf nicht an.
Bei agentgateway fehlt der Modellablehnung unsere Request-ID im Log. Die Sperre greift, die Korrelation ist lückenhaft.
Ein Budget von 0,02 USD erlaubte bei agentgateway und LiteLLM seriell 0,03 USD künstlichen Verbrauch, bevor die nächste Anfrage gesperrt wurde.
Im parallelen agentgateway-Viererlauf waren es 0,06 USD. Beobachtete Läufe, keine garantierte Obergrenze.
Die E-Mail-Adresse wurde vor dem Mock ersetzt. Das Echo enthielt weiterhin den Platzhalter. Die Rückführung in der tatsächlichen Klartext-App ist noch nicht angebunden.
Eine E-Mail-Regel schützt nicht automatisch einen vertraulichen Angebotspreis.
Daneben: Der Test-Runner prüft Szenarien und speichert Belege. Unser Dashboard zeigt diese Ergebnisse; die Gateway-eigene Admin-UI dient dessen Verwaltung.
Noch offen: Klartext-App im vollständigen Ablauf, Claude-/Codex-Modellverkehr und MCP im echten Client sowie Tests mit einem freigegebenen Modellprovider.
Die bisherigen Befunde reichen für eine engere Auswahl, noch nicht für eine Produktionsentscheidung.
agentgateway als ersten Kandidaten für den kombinierten Modell-/Werkzeugzugang vertiefen. LiteLLM mit denselben Aufgaben als Gegenkandidaten behalten. Envoy zunächst auf dieselben Mindestkontrollen bringen.
Die Testzahlen sind keine Rangliste: Konfiguration und Prüftiefe unterscheiden sich.
Modell- und MCP-Rechte, Maskierung und Budgetpersistenz sind im Labor belegt. Den curl-Weg vom MacBook haben wir nachvollzogen.
Policy-Anbindung erfordert Sorgfalt. Im Viererlauf wurde das künstliche Budget überschritten; unbekannte Preise und Modell-Deny-Korrelation bleiben Lücken.
Schlüsselentzug und den tatsächlich benötigten Clientpfad prüfen. Die einzelne Ausfallprobe ist unten dokumentiert.
Virtuelle Schlüssel, Modellrechte, Spend-Auswertung und Fallback innerhalb der ersten Anfrage sind im geprüften Aufbau belegt.
PostgreSQL und Schlüsselverwaltung bringen Betrieb mit. Gecachte Schlüssel antworteten bei DB-Ausfall weiter. Fehlende Preise bleiben ein Problem.
Denselben Entzugs- und Clienttest durchführen; Admin-UI und benötigte Editionsfunktionen prüfen.
Standalone auf ARM64 funktioniert ohne Kubernetes; Verbindung, Streaming, Fehlerpfade und MCP-Echo sind belegt.
Unser Testumfang ist wesentlich kleiner. Ohne konfigurierte Auth-/Kundenrechte gibt es noch keinen fairen Vergleich der Schutzwirkung.
Zunächst Auth und Modell-/Werkzeugrechte konfigurieren und negativ testen. Erst danach über Vertiefung entscheiden.
Die Dokumentation beschreibt einen verwalteten Gateway mit Analysefunktionen. Das könnte lokalen Gatewaybetrieb reduzieren; bei uns noch nicht gemessen.
Kein Live-Lauf und kein Nachweis unserer Anforderungen. Datenweg, Logging, Providerkosten und Clientunterstützung bleiben zu prüfen.
Einen kleinen Providervergleich erst nach separater Modell-, Zugangs- und Budgetfreigabe durchführen.
Normale E-Mail-Adressen und eine Adresse mit Plus-Zusatz wurden vor dem Backend maskiert. Eine ausgeschriebene Adresse mit „[at]“ und „[dot]“ sowie ein als vertraulich bezeichneter Angebotspreis blieben unverändert.
Auch die harmlose Beispieladresse in einer Tutorial-Anweisung wurde maskiert. Ein normaler Satz blieb unverändert.
Beobachtung an sechs ausgewählten Texten, keine Erkennungsquote. Ob die Tutorial-Maskierung erwünscht ist, entscheidet der konkrete Arbeitsablauf. Bereinigte Eingaben und Backend-Belege →
Ein per SSH gestarteter Python-Client auf dem MacBook Air schickte die Anfragen durch den bestehenden Tunnel zum agentgateway auf dem Mini. Alle sechs Prüfungen bestanden: kein Schlüssel → 401, falscher Schlüssel → 401, erlaubtes Modell → 200, verbotenes Modell → 403, vollständiges Streaming und E-Mail-Maskierung vor dem Backend.
Synthetischer Backend; noch kein Claude-/Codex-Anwendungstest. Clientantworten und Backend-Belege →
Vor dem kontrollierten Stop der Laborinstanz kam HTTP 200. Während des Stops erhielt der MacBook-Client einen Transportfehler und es gab keinen passenden Backend-Aufruf; der Mock blieb gesund. Nach dem Start derselben Instanz mit ursprünglicher Konfiguration und Datenvolume kam wieder HTTP 200.
Zusätzlich: Provider-429 wurde durchgereicht; eine verzögerte Anfrage endete mit HTTP 504 nach rund 1,25 Sekunden am MacBook. Bei deaktivierten Retries blieb es auch im Einmal-Fehlerfall bei genau einem Backendversuch und HTTP 429.
Einzelproben, keine Verfügbarkeits- oder Latenzgarantie. Timeout beweist keinen Abbruch der Backendarbeit. Aktivierte Retries und Schlüsselentzug bleiben offen. Der Gateway läuft wieder. Belege: Ausfall · Fehlerpfade.
agentgateway und LiteLLM dokumentieren eigene Verwaltungsoberflächen. Bei agentgateway haben wir den lokalen UI-Zugang bereits geöffnet; die LiteLLM-Admin-UI ist in unserem Labor deaktiviert. Eine Oberfläche ist noch kein getesteter Einrichtungs- oder Supportprozess. Für Envoy haben wir bisher den CLI-/YAML-Weg untersucht.
Eine eigene Verwaltungsoberfläche wäre erst begründet, wenn wiederkehrende Aufgaben damit nachweisbar einfacher werden.
Noch zu prüfen: Schlüsselentzug, aktivierte Retries, Envoy-Rechte und echte Team-Clients. Mehrere Replikate und vollständige Rücksicherung bleiben offen; echte Providerkosten brauchen eine eigene Freigabe.
Produktdokumentation, geprüft am 07.09.2026: agentgateway UI · LiteLLM UI · Envoy Standalone · Cloudflare AI Gateway. Aktuelle Dokumentation ist kein Nachweis einer im fixierten Laborimage getesteten Funktion. Messbelege: Gatewayvergleich.
DeepSeek Harness könnte einen Teil der eigenen Agentenentwicklung übernehmen. Ob daraus unser Produktkern wird, hängt vom konkreten Ablauf ab. Buzz untersucht zusätzlich die Zusammenarbeit im Team.
| Ebene | Wofür? | Was bleibt offen? |
|---|---|---|
| Arbeitsraum · Buzz | Menschen und Agenten arbeiten in gemeinsamen Räumen. Block beschreibt signierte Ereignisse und ACP-Anbindungen für bestehende Agenten. | Ein gemeinsamer Ereignislog zeigt nicht automatisch jeden internen Agentenschritt. Teile der Workflow-Freigaben sind laut README noch im Aufbau. |
| Agentenlaufzeit · DeepSeek Harness | Plugins für Modelle, Tools, Kontext und UI; eine Trajectory-Ansicht erschließt den aufgezeichneten Sitzungsverlauf. | Developer Preview mit sich entwickelnden APIs. Goose ist der nähere Vergleich als Buzz; zur internen Vorarbeit siehe unten. |
| Gateway · unser Labor | Regeln für angeschlossenen Modell- und Werkzeugverkehr, Nutzungszuordnung und Fehlerbehandlung. | Lokale Shellaktionen, nicht angeschlossene Clients und fachliche Richtigkeit sind dadurch nicht automatisch kontrolliert. |
| Fachlicher Ablauf · beispielsweise Klartext | Konkrete Nutzeraufgabe, Datenverarbeitung, Prüfung und verständliche Freigabe. | Bedarf, Qualität und wiederkehrender wirtschaftlicher Nutzen müssen wir am tatsächlichen Ablauf prüfen. |
Werkzeuge bilden einen eigenen Pfad: Manche werden lokal ausgeführt, andere über einen MCP-Gateway angebunden. Ein kontrollierter Einzelclient braucht möglicherweise keine zusätzliche Gateway-Schicht; mehrere unabhängige Clients können gemeinsame Regeln benötigen.
DeepSeek dokumentiert einen fortgeschriebenen Sitzungslog, auf dem unter anderem Wiederaufnahme, Fork und Replay beruhen. Für die Diagnose eines Agentenablaufs ist das näher am Geschehen als ein reiner HTTP-Log. Die dokumentierte Funktion ist noch kein eigener Nachweis vollständiger oder unveränderbarer Aufzeichnung.
Die Verbindung der Ebenen: Session → Agentenschritt → Request-ID → Gatewayentscheidung. Damit könnten wir erklären, welche Aktion zu welchem Modellaufruf führte. Ein Log-Replay garantiert keine identische erneute Antwort und darf externe Aktionen nicht einfach wiederholen. Trajectory kann sensible Eingaben bereits vor einer Gateway-Maskierung speichern.
DeepSeek Harness für einen kleinen, isolierten Plugin-Versuch vormerken. Den fachlichen Kern und seine Tests unabhängig vom Host halten. Buzz zuerst dann vertiefen, wenn Zusammenarbeit und Freigaben im Team das eigentliche Problem sind.
Plugins sparen möglicherweise eigene Laufzeit- und UI-Arbeit. Dafür entstehen Abhängigkeiten von Plugin-APIs, Berechtigungen und Updates. Wer sich am Markt durchsetzt, lässt sich aus der aktuellen Recherche nicht belastbar ableiten. Ein funktionierender Wechsel des Hosts ist für uns aussagekräftiger als Popularität.
Synthetischen Angebotstext prüfen, markierte Angaben schützen und eine harmlose Werkzeugaktion nach Freigabe ausführen. Eine festgehaltene Revision und genau ein Plugin verwenden.
Session, Schritt und Gateway-Request zuordnen. Abbruch, Wiederaufnahme, Export, verbotene Aktionen und sensible Log-Inhalte prüfen.
Dieselben fachlichen Tests mit einem zweiten Host ausführen. Messen, wie viel Adaptercode und Sonderlogik erforderlich werden.
Ergänzte Vorarbeit: Die interne August-Evaluation dokumentiert bereits einen UI-Start und einen echten Modell-/Werkzeuglauf mit DeepSeek Harness rc.8. Dieser historische Befund wurde hier nicht erneut ausgeführt. Der nächste Versuch sollte darauf aufbauen und gezielt Plugin, Kontrollregeln und Gateway-Korrelation prüfen.
Recherche vom 07.09.2026, keine Harness-Installation oder Modellaufrufe. Primärquellen: DeepSeek-Ankündigung, DeepSeek-Quellcode, Buzz-README mit Umsetzungsstand, Goose. Die Architektur- und Produktbewertung ist unsere Synthese.
Klartext kann eine Funktion eines größeren Produkts sein. Die App und der Pitch sind Ausgangspunkte. Die Produktgrenze ergibt sich aus dem nachgewiesenen Nutzen eines Arbeitsablaufs.
Ein Integrator kann denselben KI-Arbeitsablauf bei mehreren Kunden mit wiederverwendbaren Schutz- und Betriebsregeln einführen. zoon übernimmt die wiederkehrende Produktarbeit.
| Möglicher Produktkern | Welchen Nutzen prüfen wir? | Was spricht dagegen? |
|---|---|---|
| Eine Anwendung für einen konkreten Ablauf | Klartext-Funktion, Prüfung und Rückführung sparen manuelle Arbeit | Korrekturaufwand frisst Nutzen auf oder eine vorhandene App genügt |
| Ein Betriebsprodukt für Integratoren | Einrichtung, Rechte und Diagnose werden beim zweiten Kunden einfacher | Jeder Kunde braucht eigenen Code und dauerhafte Sonderbetreuung |
| Ein gemeinsames Angebot | Nutzerablauf und Betreiberkontrolle passen zusammen | Zu große Produktfläche, unklarer Käufer oder hoher laufender Support |
Andere Produktkerne bleiben möglich, etwa fachliche Evaluation oder Datenarbeit. Die Existenz eines KI-Risikos beweist weder eine Marktlücke noch Zahlungsbereitschaft.
Mit dem Teamfall beginnen und anschließend prüfen, ob sich die Einrichtung auf einen zweiten Kunden übertragen lässt.
Zwei häufig genutzte KI-Zugänge auswählen. Datenwege und Zuständigkeiten mit IT und DSB klären; nicht erfasste Nutzung sichtbar lassen.
Vorschlag: zehn Arbeitstage. Funktionieren die gewohnten Aufgaben? Greift ein Schlüsselentzug? Sind Datenwege und Speicherung nachvollziehbar? Einrichtungsaufwand, Nacharbeit und Supportzeit festhalten.
Eine zweite Person richtet anhand der Unterlagen ein und behebt eine Störung. Erst wenn sich das bei weiteren Teams wiederholen lässt, ist ein Produkt für Integratoren plausibel.
Verbindet Software und Arbeitsabläufe. Kann Einführung und kundenspezifische Anbindung übernehmen.
Managed Service Provider: übernimmt vertraglich vereinbarte laufende IT-Betriebsleistungen.
Model Context Protocol: technische Schnittstelle für Werkzeuge und Daten. Keine Dienstleisterrolle.
Wenn vorhandene Lösungen ausreichen, kein wiederkehrender Bedarf besteht oder jeder Kunde dauerhaft Sonderarbeit braucht, spricht das gegen den jeweiligen Produktansatz.
Ausgangspunkt war eine bereitgestellte Gemini-Ideensammlung, ergänzt um den zoon-Research vom 6. September. Pauschale Fehlerraten, Margen, kurze Verkaufszyklen und technisch garantierte Haftung sind daraus nicht belegt und werden hier nicht übernommen. Risikorahmen, eigene Messungen und Geschäftshypothesen sind unterschiedliche Belegarten.