Wo UES.IO passt
Gebaut für Systeme, die nicht ausfallen dürfen
PRAXISBEISPIEL:
Globales Logistikunternehmen ersetzt die Tabelle, mit der es sein Geschäft führte
Das Problem:
Ein globales Frachtunternehmen verhandelte Frachtraten mit Carriern über eine einzige gemeinsame Tabelle – über 40 Registerkarten, Dutzende eingebettete Makros und darüber ein Geflecht aus E-Mail-Freigaben. Mehr als 200 Personen arbeiteten jeden Monat damit. Als der Analyst, der sie gebaut hatte, das Unternehmen verliess, verstand niemand mehr die ganze Logik. Raten gingen falsch hinaus, Margen gingen verloren, und ein Audit zum Quartalsende stufte den Prozess als wesentliches Kontrollrisiko ein. Ein Neubau als «richtige Software» war mit 9 Monaten und einem siebenstelligen Budget offeriert worden – also wurde die Tabelle weiter geflickt.
Die Lösung:
Mit UES.IO baute das interne Team den gesamten Prozess für das Ratenmanagement in weniger als sechs Wochen als beständige interne Anwendung neu. KI-gestützte Orchestrierung erzeugte Datenmodell, Workflows und Benutzeroberfläche aus der bestehenden Logik. Der Zugriff wurde datensatzgenau gesichert – regionale Manager sahen nur ihre eigenen Routen, die Finanzabteilung sah die Margen, und Carrier sahen nichts, was sie nicht sehen sollten. Freigabeschritte, die bisher in E-Mails stattfanden, wurden zu kontrollierten Checkpoints in der App: Jede Ratenänderung wurde von einer Person freigegeben, bevor sie live ging. Als sich Vertragsbedingungen änderten, erweiterte das Team die App, statt neue Makros anzuhängen – und verteilte Updates über Managed Packages sofort an jedes regionale Team.
Die Einsparungen:
Der neu gebaute Prozess sparte dem Team rund 2’400 Stunden manuelle Arbeit pro Quartal und schloss den Audit-Befund vollständig. Margenverluste durch Preisfehler – zuvor rund USD 1,8 Mio. pro Jahr – sanken praktisch auf null. Der messbare Gesamtnutzen im ersten Jahr lag über USD 3,5 Mio., bei Baukosten, die nur einen Bruchteil der ursprünglichen Software-Offerte ausmachten. Der ROI war bereits im ersten Quartal erreicht.
Dieses Muster sehen wir immer wieder: Die Tabelle, die «einfach funktioniert», ist meist die, die das Geschäft still und leise gefährdet. Wir bauen eine Ihrer Tabellen in einer halbtägigen Prototyp-Session neu.
Funktionen
- Verbindung zu jeder proprietären Datenbank für die Restrukturierung
- Neue Benutzererlebnisse auf bestehenden Daten bauen, ohne sie zu migrieren
- KI-gestützte Workflows einführen, ohne grundlegende Systeme zu ersetzen
- Sauberer Kontext für KI-Agenten – strukturierte Legacy-Daten verbessern die Genauigkeit der Agenten
- Legacy-Systeme so anbinden, wie sie sind. Im eigenen Tempo modernisieren.
Praxisbeispiele
Demo-Video verfügbarEine beliebige REST API über MCP mit einem Chatbot verbindenDemo ansehen (2:20)
FALLBEISPIEL:
Versicherer modernisiert ein 30 Jahre altes Kernsystem, ohne es anzutasten
Das Problem:
Eine regionale Versicherung betrieb ihre Policenverwaltung auf einem System aus der Mainframe-Ära, das über drei Jahrzehnte gewachsen war. Es funktionierte – es verwaltete Millionen von Policen und enthielt die gesamte Geschäftslogik des Unternehmens –, aber es liess sich nur langsam ändern, war mühsam zu integrieren, und es war unmöglich, Fachleute dafür zu finden. Underwriter wechselten für einfache Aufgaben zwischen Terminal-Masken und Nebentabellen hin und her. Jeder Anbieter schlug dasselbe vor: einen mehrjährigen, achtstelligen Komplettaustausch, der das Geschäft gefährdet und 30 Jahre gewachsenes Wissen verworfen hätte. Die Geschäftsleitung lehnte immer wieder ab, und der Modernisierungsrückstand wuchs weiter.
Die Lösung:
Mit UES.IO liess die Versicherung das Kernsystem bestehen und baute darauf auf. UES.IO verband sich über OData und REST direkt mit der Legacy-Datenbank und den bestehenden Services – keine Migration, keine Daten verschoben. Das Team baute auf den bestehenden Daten moderne Oberflächen für die Underwriter und schlankere Workflows und ergänzte dann KI-gestützte Automatisierung für Triage und Dokumentenprüfung. Weil die Legacy-Daten nun als strukturierter, verlässlicher Kontext bereitstanden, trafen die KI-Agenten deutlich genauere Entscheidungen als frühere Versuche, die mit fragmentierten Tabellendaten gearbeitet hatten. Das Kernsystem lief als führendes System weiter; die Modernisierung erfolgte schrittweise, im eigenen Zeitplan des Teams und ohne eine einzige riskante Umstellung.
Passende Demo
Im Beispiel der Versicherung entsteht alles über die bestehenden Schnittstellen auf einem Legacy-Kernsystem. Diese Demo zeigt einen Teil davon: eine REST API, die über MCP mit einem Chatbot verbunden wird.
- Eine REST API, über MCP mit einem Chatbot verbunden
- Claude beantwortet eine Frage aus der API
- Die Antwort stimmt mit der Anzeige in der App überein
Direkt zu: Claude fragen (1:24) · Die Antwort stimmt mit der App überein (1:47)
Demo: eine REST API, über MCP mit einem Chatbot verbunden. Beispieldaten. Die Antwort von Claude stimmt mit der Anzeige in der App überein.
Die Einsparungen:
Die Versicherung lieferte ein modernes Underwriting-Erlebnis in Monaten statt Jahren und vermied ein geschätztes Austauschprogramm von über USD 12 Mio. vollständig. Die Bearbeitungszeit der Underwriter sank um rund 35 %, und die genauere KI-Triage reduzierte kostspielige Fehlklassifizierungen. Der messbare Nettonutzen im ersten Jahr lag über USD 4 Mio. Die Investition in das Legacy-System blieb erhalten, statt abgeschrieben zu werden – und der laufende Betrieb wurde in keiner Weise gestört.
Die Erkenntnis, die wir immer wieder sehen: Sie müssen sich nicht zwischen riskantem Austausch und Stillstand entscheiden. Sie können eines Ihrer Legacy-Systeme anbinden und in kürzester Zeit eine funktionierende moderne Oberfläche darauf bauen.
Funktionen
- MCP-native Orchestrierung von Agenten mit Human-in-the-Loop (HITL)
- Kontrolle über Agenten: Profile und Berechtigungssets sind in die Laufzeit integriert und werden auf Ebene der Person ausgewertet
- Verbindung zu externen MCP-Servern, LLMs und SLMs – oder private Modelle auf Ihrer eigenen Infrastruktur betreiben
- Modelle frei wechseln – kein Umbau der Architektur, kein Lock-in, keine Folgen für nachgelagerte Systeme
- Richtlinien und Guardrails auf Plattformebene und pro Agent durchgesetzt
- Nachvollziehbarkeit der Agenten und eine zentrale Kostenkontrolle halten Sie im Budget
Praxisbeispiele
Demo-Video verfügbarErsetzen Sie Ihren Rechnungs-Bot durch kontrollierte KI-AgentenDemo ansehen (3:11)
FALLBEISPIEL:
Globale Bank setzt KI-Agenten ein, die ihr Sicherheitsteam tatsächlich freigegeben hat
Das Problem:
Eine multinationale Bank wollte KI-Agenten im gesamten Betrieb einsetzen – um Anfragen zu bearbeiten, Ausnahmen weiterzuleiten und Antworten zu entwerfen. Doch jede allgemeine Agentenplattform, die sie prüfte, scheiterte an derselben Hürde: proprietäre Laufzeitumgebungen, die das Sicherheitsteam nicht einsehen konnte, undurchsichtige Abhängigkeiten von einem einzigen Modellanbieter und keine Möglichkeit festzulegen, für wen ein Agent handeln oder was er sehen darf. Die Risiko- und Compliance-Teams lehnten jede einzelne ab. Gleichzeitig hatten Geschäftsbereiche, frustriert über die Verzögerung, begonnen, Agenten auf eigene Faust mit externen KI-Tools zu verbinden – und damit genau die unkontrollierte Schatten-KI geschaffen, die die Bank am meisten fürchtete.
Die Lösung:
Mit UES.IO setzte die Bank agentische Anwendungen vollständig innerhalb ihres eigenen Sicherheitsperimeters ein. Die Agenten wurden MCP-nativ orchestriert, mit Human-in-the-Loop-Checkpoints bei jeder folgenreichen Aktion. Entscheidend war: Die Agenten übernahmen dieselben Profile und Berechtigungssets wie die Personen – zur Laufzeit auf Plattformebene ausgewertet –, sodass ein Agent nie mehr sehen oder tun konnte als die Person, für die er handelte. Die Bank band freigegebene externe MCP-Server an, betrieb sensible Modelle privat auf ihrer eigenen Infrastruktur und wechselte frei zwischen LLMs und kleineren spezialisierten Modellen, ohne die Architektur umzubauen. Jede Aktion eines Agenten wurde protokolliert und war nachvollziehbar, und eine zentrale Kostenkontrolle hielt die Ausgaben im Budget. Das Sicherheitsteam gab grünes Licht, weil Governance nicht nachträglich aufgesetzt war – sie war das Fundament.
Passende Demo
Im Beispiel der Bank wird Arbeit zwischen Agenten und Freigabeberechtigten verteilt. Diese Demo zeigt dieselbe Mechanik bei Lieferantenrechnungen.
- Eine Rechnung wird automatisch freigegeben
- Eine wird von der zuständigen Person freigegeben
- Eine wird auf dem Server blockiert und abgelehnt
- Jeder Schritt wird in Agent Traces protokolliert
Direkt zu: Auf dem Server blockiert (2:15) · Agent Traces (2:51)
Demo-App: Rechnungsstelle. Beispieldaten. Drei Rechnungen: eine automatisch freigegeben, eine von der zuständigen Person, eine blockiert und abgelehnt.
Die Einsparungen:
Die Bank kam innerhalb eines einzigen Quartals von festgefahrenen Pilotprojekten zu Agenten in Produktion – eine Arbeit, die frühere Plattformen über ein Jahr lang blockiert hatten. Mit dem Ende der Schatten-KI schloss die Bank ein Compliance-Risiko, das sie an möglichen regulatorischen Folgen und Datenpannen auf zweistellige Millionenbeträge schätzte. Die Automatisierung im Betrieb sparte schätzungsweise USD 5–7 Mio. pro Jahr an manueller Bearbeitung, und die freie Modellwahl senkte die Inferenzkosten gegenüber der Bindung an einen einzigen Anbieter um rund 30 % – alles innerhalb eines Governance-Modells, das vollständig in der Hand des Sicherheitsteams lag.
Das Muster ist immer dasselbe: Was KI im Unternehmen bremst, sind nicht die Fähigkeiten, sondern die Governance. Wir setzen in einer halbtägigen Prototyp-Session einen kontrollierten Agenten für einen Ihrer echten Workflows auf.
Funktionen
- Compliance auf Bankenniveau: FINMA, DSGVO, DORA, EU AI Act – integriert in die Infrastruktur Ihrer Wahl
- Deployment in der Private Cloud, On-Premises oder air-gapped
- Proprietäre Daten bleiben innerhalb Ihres Perimeters – kein Risiko durch Datenhaltung bei Dritten
- Freigabe-Checkpoints durch Menschen für jede agentische Aktion, die sensible Daten betrifft
Praxisbeispiele
Demo-Video verfügbarEine Mobile App und KI-Erklärungen auf einem Legacy-Quant-SystemDemo ansehen (1:53)
FALLBEISPIEL:
Vermögensverwalter modernisiert seine Legacy-Quant-Engine – und macht daraus ein Produkt
Das Problem:
Ein Vermögensverwalter hatte über Jahre ein ausgeklügeltes Quant-System aufgebaut – die analytische Engine hinter seinen Portfoliomodellen und Risikoberechnungen und ein echter Wettbewerbsvorteil. Doch es steckte in einem Legacy-Stack fest: schwer erweiterbar, nicht auf Mobilgeräten nutzbar und nicht mit modernen KI-Tools verbindbar. Das Unternehmen sah eine Chance über den Eigengebrauch hinaus – die Engine als Paket an Banken zu verkaufen –, konnte aber Jahrzehnte proprietärer Quant-Logik nicht ohne mehrjährigen Neubau zugänglich machen. Und es durfte nicht riskieren, dass dieses geistige Eigentum oder die Daten seiner Kundschaft seine Kontrolle verlassen. Unter FINMA, DSGVO, DORA und dem EU AI Act musste jede Lösung zudem innerhalb des eigenen Perimeters betrieben werden können – ohne Ausnahme.
Die Lösung:
Mit UES.IO modernisierte das Unternehmen, ohne die Quant-Engine neu zu schreiben. UES.IO verband sich über OData und REST mit dem Legacy-System, so wie es war – die bewährte Berechnungslogik blieb genau dort, wo sie war, und war nun sauber über MCP zugänglich. Auf diesem Fundament baute das Team moderne mobile Apps für Beratende und Kundschaft und orchestrierte KI-Agenten, die strukturierte Quant-Ergebnisse als verlässlichen Kontext nutzten statt fragmentierter Eingaben. Entscheidend war: Das Ganze wurde als Multi-Tenant-Anwendung paketiert, die sich über Managed Packages sofort bei jeder Bank bereitstellen liess – mit datensatzgenauen Zugriffskontrollen, unveränderlichen Audit-Logs und Freigabe-Checkpoints durch Menschen bei jeder agentischen Aktion. Jede Bank betrieb die Anwendung auf ihrer eigenen Infrastruktur, sodass weder das geistige Eigentum des Unternehmens noch Kundendaten je einen kontrollierten Perimeter verliessen. Compliance war in die Infrastruktur integriert, statt nachträglich versprochen zu werden.
Passende Demo
Im Beispiel des Vermögensverwalters bleibt die Legacy-Quant-Engine bestehen, und alles Neue entsteht darauf. Diese Demo zeigt denselben Ansatz: eine Mobile App und KI-Erklärungen auf einem Legacy-Quant-System.
- Eine Kundin prüft auf dem Smartphone ihre Rentenlücke
- UES.IO ruft das Legacy-Quant-System über REST auf
- Das Quant-System übernimmt weiterhin die Berechnung
- Die KI erklärt das Ergebnis persönlich anhand der eigenen Zahlen der Kundin
Direkt zu: Das Legacy-Quant-System (0:41) · Erklär es mir (1:04)
Demo-App: Pension Gap. Beispieldaten. Eine Kundin prüft auf dem Smartphone ihre Rentenlücke, und die KI erklärt das Ergebnis anhand ihrer eigenen Zahlen.
Die Einsparungen:
Das Unternehmen machte aus einem statischen internen Asset eine neue Einnahmequelle: Es brachte seine Quant-Engine als Produkt zu Banken, ohne den mehrjährigen, achtstelligen Neubau, den eine konventionelle Öffnung erfordert hätte – und vermied so geschätzte Entwicklungs- und Zertifizierungskosten von über USD 10 Mio. Mobile und KI-gestützte Anwendungen erreichten die Beratenden in Monaten statt Jahren, und dank Managed Packages liess sich jede neue Bank in Tagen statt über individuelle Integrationen anbinden. Am wertvollsten war, dass die proprietäre Quant-Logik als beständiges geistiges Eigentum erhalten blieb – modernisiert, monetarisierbar und vollständig kontrolliert –, statt neu gebaut und gefährdet zu werden.
Das Muster gilt für alle regulierten Kunden, mit denen wir arbeiten: Ihre am härtesten erarbeiteten Systeme sind Werte, auf denen Sie aufbauen können, keine Altlasten, die ersetzt werden müssen. Wir binden eines Ihrer Legacy-Systeme an und setzen in einer halbtägigen Prototyp-Session eine moderne, kontrollierte App darauf auf.
Funktionen
- Claude, ChatGPT und andere Assistenten mit Unterstützung für eigene MCP-Connectoren anbinden
- Jede Person meldet sich mit ihrem eigenen Konto an, Anfragen laufen also mit ihren Berechtigungen
- Lesen und Schreiben über MCP pro Site separat aktivieren
- Berechtigungen auf Feldebene gelten für jede Antwort eines Assistenten
- Jeder Aufruf eines Assistenten protokolliert: Person, Agent, Modell, Prompt, Antwort, Tokens und Kosten
- Kein separates Integrationsprojekt und keine Kopie der Daten
Praxisbeispiele
Demo-Video verfügbarEin Agent, zwei Personen, zwei AntwortenDemo ansehen (2:59)
FALLBEISPIEL:
Spitalgruppe lässt Betriebspersonal Planungsdaten über den eigenen Assistenten abfragen
Das Problem:
Die Betriebsteams einer Spitalgruppe arbeiteten mit Systemen für OP-Planung, Bettenmanagement und Material. Eine einfache Frage zu beantworten – etwa, welche OP-Programme nächste Woche zu überziehen drohten –, hiess, einen Analysten zu fragen, der die Daten in eine Tabelle exportierte. Mitarbeitende hatten begonnen, Exporte in öffentliche KI-Tools einzufügen, um Zeit zu sparen, und das Team für Informationssicherheit konnte nicht sehen, was das Haus verlassen hatte. Ein Verbot der Tools verdrängte die Gewohnheit nur aus dem Blickfeld, und eine eigene Integration für jeden Assistenten war auf mehrere Monate Arbeit geschätzt worden.
Die Lösung:
Die Gruppe stellte ihre Planungs- und Betriebsanwendungen auf UES.IO als MCP-Connector bereit. Die Mitarbeitenden fügten den Connector dem Assistenten hinzu, den sie bereits nutzten, und meldeten sich mit ihrem eigenen Konto an. Weil jede Anfrage unter dem Profil und den Berechtigungssets der jeweiligen Person lief, sah eine Stationskoordinatorin nur ihre eigenen Standorte und Felder, und Details, die andere Rollen nicht benötigten, blieben verborgen. Der Connector war schreibgeschützt; der Schreibzugriff blieb ausgeschaltet. Die Informationssicherheit prüfte den Audit Trail, der zeigte, wer was über welchen Assistenten gefragt hatte und was zurückkam.
Passende Demo
Im Beispiel der Spitalgruppe erhält jede Person nur Antworten, die sie sehen darf. Diese Demo zeigt, wie derselbe Agent zwei Personen zwei unterschiedliche Antworten gibt.
- Ein Agent, zwei Personen
- Jede Antwort entspricht den Berechtigungen der jeweiligen Person
- Der Agent läuft als bestimmte Person (Vic Viewer)
- Ein Lesezugriff, den die Person nicht sehen darf, wird verweigert
Direkt zu: Als Vic Viewer ausführen (1:22) · Der verweigerte Lesezugriff (2:21)
Demo-App: HR People. Beispieldaten. Ein Agent läuft als zwei verschiedene Personen und gibt jeder eine andere Antwort, einschliesslich eines verweigerten Lesezugriffs.
Das Ergebnis:
Die Betriebsteams erhielten Antworten in Minuten, statt auf Exporte der Analysten zu warten, und das Einfügen von Exporten in öffentliche Tools ging zurück. Die Sicherheit hatte vorher keinen Einblick in die Nutzung von Assistenten und nun eine vollständige Aufzeichnung. Das Analystenteam erstellte keine Ad-hoc-Exporte mehr, sondern verbesserte die zugrunde liegenden Anwendungen. Als die Gruppe später für einen Workflow Schreibzugriff wollte, aktivierte sie ihn für diese eine Site, statt die Integration neu zu bauen.
Funktionen
- Die Agenten App Builder, Schema Builder und View Builder erstellen Apps aus einem Dialog
- Agenten schreiben dieselbe deklarative YAML-Ebene wie Entwicklerinnen und Entwickler
- Änderungen sind lesbar, versioniert und nach Ihren üblichen Regeln validiert
- Aktionen der Agenten werden wie jede andere Änderung protokolliert
- Läuft innerhalb Ihrer Vertrauensgrenze, auch selbst gehostet und air-gapped
- Entwicklerinnen und Entwickler prüfen, verfeinern und erweitern, was die Agenten erstellen
Praxisbeispiele
Demo-Video verfügbarEine funktionierende App mit drei KI-Agenten bauenDemo ansehen (2:37)
FALLBEISPIEL:
Versicherer baut ein Tool für die Schadenerfassung in Tagen statt in einem Release-Zyklus
Das Problem:
Das Schadenteam eines mittelgrossen Versicherers bearbeitete neue Schadenfälle über ein gemeinsames Postfach, eine Tabelle und ein altes Fallsystem. Sachbearbeitende erfassten dieselben Angaben dreimal, und die Teamleitung hatte keinen aktuellen Überblick darüber, was anstand. Das Team hatte zweimal eine Anwendung für die Schadenerfassung beantragt, und beide Male landete sie im IT-Backlog hinter regulatorischen Arbeiten. Inzwischen wuchs die Tabelle, und die dadurch verursachten Probleme mit der Datenqualität zeigten sich im Monatsabschluss.
Die Lösung:
Die Leiterin der Schadenabwicklung arbeitete auf UES.IO mit den Builder-Agenten. Der Schema Builder Agent definierte die Collections für Schäden, Policenreferenzen und Dokumente, der View Builder Agent erstellte das Erfassungsformular und die Warteschlange für die Teamleitung, und der App Builder Agent fügte alles zu einer Anwendung zusammen – mit den bestehenden Profilen und Berechtigungssets des Versicherers. Die Agenten schrieben deklaratives YAML in einen Entwicklungs-Workspace. Ein Entwickler prüfte die Definitionen, verschärfte zwei Validierungsregeln und veröffentlichte eine Bundle-Version über den üblichen Release-Prozess.
Passende Demo
Im Beispiel des Versicherers entsteht ein Tool für die Schadenerfassung mit Builder-Agenten. Diese Demo zeigt drei KI-Agenten von UES.IO, die eine funktionierende App bauen.
- Drei KI-Agenten bauen eine funktionierende App
- Die fertige App im Betrieb
- View Builder erstellt die Ansichten und die Navigation
Direkt zu: Die fertige App (0:56) · View Builder: Ansichten und Navigation (1:35)
Demo: Drei KI-Agenten bauen eine funktionierende App. Beispieldaten. Zeigt die fertige App und wie View Builder Ansichten und Navigation erstellt.
Das Ergebnis:
Die erste funktionierende Version stand den Sachbearbeitenden innerhalb weniger Tage zur Verfügung, statt auf den nächsten Release-Zyklus zu warten. Die Mehrfacherfassung entfiel, weil das Formular direkt in eine einzige Collection schrieb, und die Teamleitung erhielt eine aktuelle Warteschlange. Weil die Definitionen als einfaches YAML in der Versionskontrolle lagen, konnte das IT-Team jede Änderung der Agenten prüfen und behielt die Verantwortung für die Anwendung.
Funktionen
- Claude Code, Codex und andere Coding-Agenten verbinden sich über den UESIO Connector for Agents
- Der uesio-dev Skill führt Agenten so, dass sie so entwickeln, wie es die Plattform vorsieht
- Agenten arbeiten in einem Entwicklungs-Workspace; die Veröffentlichung auf einer Site ist ein separater Schritt
- Definitionen, Workflows und Berechtigungssets lassen sich in Ihr eigenes Git exportieren
- Bundle-Versionen geben Ihnen Kontrolle über Releases und Rollbacks
- Von Agenten und von Hand gebaute Apps folgen denselben Schemaregeln und demselben Deployment-Weg
Praxisbeispiele
Demo-Video verfügbarUrlaubsanträge aus einem einzigen PromptDemo ansehen (3:10)
FALLBEISPIEL:
Retailbank führt Coding-Agenten ein, ohne eine Hintertür zu öffnen
Das Problem:
Die Entwicklungsteams einer Retailbank wollten Coding-Agenten nutzen, um interne Tools schneller zu liefern. Das Risikoteam wollte jedoch weder Agenten zulassen, die direkt in Produktivsysteme schreiben, noch Code, den niemand auf dem üblichen Weg prüfen konnte. Entwicklerinnen und Entwickler testeten Agenten bereits auf eigene Faust auf ihren Laptops mit Beispielprojekten – ein Schattenprozess, den die Bank weder sehen noch kontrollieren konnte. Zudem baute jedes Team denselben Grundcode für Formulare, Validierungen und Zugriffsregeln neu.
Die Lösung:
Die Bank legte UES.IO als Standardziel für von Agenten gebaute interne Tools fest. Die Entwicklungsteams verbanden Claude Code über den UESIO Connector for Agents mit dem uesio-dev Skill, und die Agenten erstellten Collections, Ansichten und Workflows in einem Entwicklungs-Workspace. Nichts gelangte auf eine Live-Site, ohne dass eine Entwicklerin oder ein Entwickler eine Bundle-Version über die üblichen Pull-Request- und Release-Kontrollen der Bank freigab. Weil die Definitionen deklarativ waren und in die eigenen Git-Repositories der Bank exportiert wurden, lasen die Prüfenden dasselbe YAML, das sie bereits kannten, und die Berechtigungssets wanderten mit der Anwendung mit.
Passende Demo
Im Beispiel der Retailbank arbeiten Coding-Agenten an internen Tools. Diese Demo zeigt, wie Claude Code aus einem einzigen Prompt eine Funktion für eine UES.IO-App baut.
- Claude Code baut eine Funktion für Urlaubsanträge
- Ein einziger Prompt startet den Build
- Das Ergebnis wird in der Entwicklungsumgebung getestet
Direkt zu: Ein Prompt (1:20) · Test in der Entwicklungsumgebung (1:57)
Demo: Urlaubsanträge, mit Claude Code aus einem einzigen Prompt gebaut. Beispieldaten. Zeigt den Prompt und den Test des Ergebnisses in der Entwicklungsumgebung.
Das Ergebnis:
Die Teams lieferten interne Tools schneller, und das Risikoteam hatte einen einzigen prüfbaren Weg statt eines Schattenprozesses. Von Agenten und von Hand gebaute Anwendungen durchliefen dieselben Schemaregeln und Release-Schritte, sodass es auf Audit-Fragen nur eine Antwort gab. Die Bank behielt ihre Repositories, ihren Review-Prozess und die freie Wahl des Coding-Agenten.
FALLBEISPIEL:
Versicherer senkt die Kosten der Schadentriage, indem er jedem Schritt das passende Modell zuordnet
Das Problem:
Im Pilotprojekt eines Versicherers las ein einziges Premium-Modell jedes eingehende Schadendokument, klassifizierte es und entwarf eine erste Beurteilung. Der Pilot funktionierte, doch bei einem normalen Wochenvolumen lag die Kostenprognose deutlich über dem Business Case, und niemand konnte sagen, welche Schritte die Kosten verursachten. Das Sicherheitsteam wollte ausserdem, dass sensible Schadenfälle nach strengeren Regeln behandelt werden als Routinefälle – das liess sich mit nur einem Modell nicht abbilden.
Die Lösung:
Das Team baute den Workflow auf UES.IO als orchestrierten Ablauf neu. Ein günstigeres Modell klassifizierte jedes Dokument und leitete Routinefälle weiter, während komplexe oder unklare Fälle an ein stärkeres Modell für Schlussfolgerungen gingen. Sensible Schadenarten lösten strengere Guardrails und einen Freigabe-Checkpoint durch einen Menschen aus, bevor eine Empfehlung verschickt wurde. Die Kosten jedes Durchlaufs wurden pro Modell erfasst, sodass das Team genau sah, welcher Schritt wie viel kostete, und ein Budget pro Person hielt Experimente im Rahmen.
Die Einsparungen:
Mit den Kosten pro Schritt vor Augen optimierte das Team die Weiterleitung, bis die Kostenprognose innerhalb des Business Case lag. Sensible Schadenfälle folgten strengeren Regeln als Routinefälle, und jede Entscheidung war im Audit Trail nachvollziehbar. Als für den Schritt mit den Schlussfolgerungen ein besseres Modell verfügbar wurde, wechselte das Team es aus, ohne den Workflow neu zu bauen.