Zwei Assistenten, dieselbe Anfrage
Eine Kreditanalystin bei einem gewerblichen Kreditgeber stellte im letzten Quartal zwei verschiedenen KI-Assistenten dieselbe Frage: „Zeige mir alle Lieferanten, die in den letzten 30 Tagen aufgenommen wurden und bei denen Steuerformulare fehlen.” Der erste Assistent — ein Chat-Widget, das auf das bestehende Portal aufgesetzt wurde — produzierte einen höflichen Absatz, der erklärte, wie man zum Lieferantenbildschirm navigiert und Filter anwendet. Der zweite, der innerhalb der DEX-Laufzeit läuft, lieferte die gefilterte Liste, respektierte ihren RBAC-Geltungsbereich und protokollierte die Abfrage im Audit-Trail. Antwortzeit: 22 Sekunden gegenüber vier Klicks, die sie nie machen musste.
Der Unterschied liegt nicht am Modell. Es liegt daran, was der Assistent sehen kann.
Was ein aufgesetzter Assistent tatsächlich weiß
Die meisten KI-Assistenten für Unternehmen leben eine Schicht über der Anwendung. Sie sehen das DOM, vielleicht einen Screenshot und das, was der Benutzer tippt. Sie sehen nicht den Deskriptor. Sie sehen nicht den Berechtigungsumfang. Sie sehen nicht die Abfrage, die das Grid gerade ausgeführt hat, oder die Validierungsregeln, die das Formular durchsetzt. Sie raten die gleiche Struktur, die die Laufzeit bereits im Speicher hat.
Diese Lücke ist der Grund, warum aufgesetzte Assistenten so viele Navigationshinweise geben. Sie sagen Benutzern, welchen Button sie klicken sollen, weil Klicken die einzige Aktion ist, die sie zuverlässig beschreiben können. Sie können nicht im Namen des Benutzers handeln, weil sie nicht wissen, was Handeln bedeuten würde.
Was ein laufzeitintegrierter Assistent leisten kann
Wenn der Assistent ein erstklassiger Teil der Laufzeit ist, liest er den Deskriptor direkt. Er weiß, dass der Bildschirm eine Lieferanten-Entität, ein tax_form_status-Feld und einen created_at-Zeitstempel hat. Er weiß, dass der RBAC-Geltungsbereich der aktuellen Benutzerin die Ergebnisse auf ihre Geschäftseinheit beschränkt. Er weiß, dass die Filterkomponente ein strukturiertes Prädikat akzeptiert, keine natürlichsprachliche Zeichenkette.
Also schreibt er keinen Absatz. Er schlägt einen Filter vor, zeigt der Benutzerin, was er tun wird, und wendet ihn nach Freigabe an. Die Interaktionsfläche schrumpft von „durch die App navigieren” zu „sagen Sie mir, was Sie möchten.” Jede Aktion, die der Assistent ausführt, durchläuft dieselben Autorisierungs- und Audit-Pfade, die die Benutzeroberfläche verwendet, weil er die Benutzeroberfläche ist.
Die Sicherheitsfrage ist einfacher, nicht schwieriger
Der häufige Einwand gegen laufzeitintegrierte Assistenten ist, dass sie die Angriffsfläche vergrößern. Wir haben das Gegenteil festgestellt. Ein aufgesetzter Assistent, der Buttons für den Benutzer klicken kann, muss Berechtigungsprüfungen neu implementieren oder, schlimmer noch, mit erhöhten Rechten arbeiten. Ein laufzeitintegrierter Assistent, der Aktionen auf Deskriptor-Ebene vorschlägt, erbt jede Prüfung, die die Laufzeit bereits durchsetzt.
Wir gewähren dem Assistenten keine Fähigkeit, die der Benutzer nicht hat. Das LLM ist eine Vorschlags-Engine. Die Laufzeit ist die Durchsetzungsschicht. Wenn die Benutzerin eine Rechnung über 50.000 USD nicht genehmigen kann, kann es auch der Assistent in ihrem Namen nicht. Das Audit-Log erfasst sowohl den Menschen als auch das Modell als Teilnehmer an der Aktion.
Warum dies schwer nachzurüsten ist
Dieses Muster in eine bestehende Unternehmensanwendung einzubauen ist teuer, weil die meisten Unternehmensanwendungen keinen Deskriptor haben, den man lesen könnte. Der Assistent hat nichts Strukturiertes, an das er sich binden kann, also fällt er auf das DOM zurück, und die Einschränkungen folgen.
Dies ist einer der Gründe, warum wir den Deskriptor und die Laufzeit vor dem Assistenten entworfen haben. Der Assistent ist eher eine Konsequenz der Architektur als ein Produkt, das ihr hinzugefügt wurde. Sobald jeder Bildschirm ein Deskriptor ist, kann ein Assistent, der Deskriptoren liest und schreibt, über die gesamte Anwendung hinweg arbeiten — ohne eine bildschirmspezifische Integration.
Was Benutzer bemerken
Die Verhaltensänderung ist in der ersten Sitzung sichtbar. Benutzer hören auf, den Assistenten zu fragen, wo sich Dinge befinden. Sie beginnen, nach Ergebnissen zu fragen. „Finde die drei Lieferanten, die wegen doppelter Bankverbindungen markiert wurden.” „Starte einen Verlängerungs-Workflow für die im Mai auslaufenden Verträge.” „Exportiere diese gefilterte Ansicht in das Format, das die Finanzabteilung verwendet.”
Unsere internen Nutzungsdaten aus frühen Pilotprojekten zeigen, dass etwa 70 % der Assistenten-Interaktionen zu einer konkreten Aktion im Namen des Benutzers führen, verglichen mit unter 20 % beim aufgesetzten Muster, gegen das wir getestet haben. Die übrigen Interaktionen sind erklärend, und selbst diese greifen auf den Deskriptor zurück statt auf ein generisches Hilfe-Korpus.
Die Erkenntnis
Ein KI-Assistent ist nur so nützlich wie die Struktur, die er lesen kann. Einen auf eine fertige App aufzusetzen ergibt ein besseres Hilfe-Widget. Einen in eine deskriptorgesteuerte Laufzeit zu integrieren ergibt einen Kollegen, der die Arbeit tatsächlich erledigen kann. Die Architekturentscheidung kommt zuerst. Das Modell kommt zweitens. Alles andere folgt aus dieser Reihenfolge.