Wer entscheidet, wenn ein Agent delegiert?

Delegation macht einen KI-Workflow leistungsfähiger, aber nicht rechenschaftspflichtiger. Der Unterschied liegt darin, ob Autorität, Belege und das Recht...

Wer entscheidet, wenn ein Agent delegiert?

Eine Übergabe entleert den Stuhl nicht

Ein Agent delegiert eine Aufgabe. Ein anderer Agent sammelt Material, vergleicht Datensätze, ruft ein Werkzeug auf oder bereitet eine Empfehlung vor. Ein dritter Agent prüft das Ergebnis. Die Arbeit bewegt sich, und diese Bewegung kann nützlich sein. Sie kann aber auch ein sehr altes Managementproblem in neuer Form erzeugen: Jeder hat etwas getan, doch niemand kann sagen, wer befugt war, die Entscheidung zu treffen.

Die verlockende Antwort ist der Agent, der den letzten Aufruf getätigt hat. Sie ist aber auch meist die am wenigsten hilfreiche Antwort. Eine Softwarekomponente kann eine Route auswählen, weitere Arbeit anfordern und eine Anweisung an ein verbundenes System übermitteln. Nichts davon legt fest, wer den Zweck akzeptiert hat, wer die Grenze gesetzt hat, wer die Aktion hätte verweigern können oder wer informiert werden musste, als sich die Bedingungen änderten. Es legt lediglich fest, dass ein Programm in der Kette war.

Diese Unterscheidung wird scharf, wenn ein Workflow Konsequenzen hat. Ein vorgeschlagener Entwurf kann zu einer Kundenkommunikation werden. Eine Klassifizierung kann zum Grund werden, warum ein Fall in eine bestimmte Warteschlange eingereiht wird. Ein Vergleich kann zu einer Kaufempfehlung werden. Eine entworfenen Zahlungsanweisung kann zu einer Zahlung werden. Jeder Schritt kann technisch kompetent sein und dennoch organisatorisch unvollständig. Das System hat die Arbeit der Delegation erledigt, ohne die Arbeit der Autorität zu erledigen.

Es ist nicht nötig, ein dramatisches Versagen zu erfinden, um das Problem zu sehen. Nehmen Sie einen bewusst hypothetischen Workflow. Ein Triage-Agent erhält eine Frage, bittet einen Recherche-Agenten, das relevante Material zu prüfen, sendet das Ergebnis an einen Prüfer und bereitet dann eine Aktion für ein Fallmanagementsystem vor. Der Recherche-Agent ist nicht befugt zu handeln. Der Prüfer ist nicht befugt, das Fallergebnis wirksam zu machen. Der Triage-Agent hat eine Werkzeugberechtigung. Die Organisation hat nicht festgelegt, ob diese Berechtigung es ihm erlaubt, das Ergebnis zu übernehmen. Der Workflow mag auf einem Dashboard ordentlich aussehen. Er hat dennoch die wichtigste Frage ohne Antwort erreicht.

Delegation ist nicht das Verschwinden von Verantwortung. Sie ist Verantwortung, die schwerer zu sehen ist. Ein gutes Betriebsdesign macht sie wieder leichter sichtbar. Es legt fest, was die ursprüngliche Entscheidung ist, was delegiert werden kann, welche Bedingungen mit der Aufgabe reisen, wer eine irreversible oder folgenreiche Aktion genehmigen kann, welche Aufzeichnung nach der Übergabe bleibt und wie eine Person oder ein System eingreifen kann, wenn die Route nicht mehr sicher ist. Von der Technologie wird nicht verlangt, moralische Handlungsfähigkeit zu besitzen. Es wird verlangt, dass sie die Handlungsfähigkeit der Organisation intakt lässt.

Das ist die praktische Bedeutung von Rechenschaftspflicht in einem Multi-Agenten-Workflow. Sie ist keine dekorative Zeile in einer Richtlinie und keine retrospektive Jagd nach dem nächsten Mitarbeiter, wenn etwas schiefgeht. Sie ist eine Eigenschaft der Route, bevor die Arbeit beginnt. Die richtige Person kann prüfen, was vorgeschlagen wurde, verstehen, warum es vorgeschlagen wurde, die ihr zugewiesene Autorität ausüben und eine Aufzeichnung hinterlassen, die im Nachhinein angefochten werden kann.

Europas aufkommende KI-Regeln sind hier hilfreich, weil sie weniger an einem theatralischen Menschen am Ende eines Flusses interessiert sind als an den Bedingungen, unter denen Aufsicht tatsächlich funktionieren kann. Die Bestimmungen zur menschlichen Aufsicht im KI-Gesetz gelten für Hochrisikosysteme, nicht für jede Nutzung eines Agenten. Diese Grenze ist wichtig. Aber die operativen Fragen im Gesetz übertragen sich gut: Kann eine zugewiesene natürliche Person die relevanten Fähigkeiten und Grenzen verstehen, auf Anomalien und unerwartete Leistung achten, übermäßiges Vertrauen vermeiden, Ausgaben interpretieren, sie ignorieren oder umkehren und das System in einen sicheren Zustand unterbrechen? Ein Workflow mit vielen Agenten macht diese Fragen nicht kleiner. Er vervielfacht die Orte, an denen die Antwort verloren gehen kann.

Delegation kann Arbeit nach vorne geben. Sie kann nicht den Weg auslöschen, über den Autorität und Einspruch zurückkehren.

Delegation ist eine Kette, kein Nebel

Menschen delegieren ständig. Eine Führungskraft bittet eine Kollegin, eine Notiz vorzubereiten. Ein Einkaufsteam bittet eine Fachkraft, eine Vertragsklausel zu prüfen. Eine Klinikerin bittet ein Labor um ein Ergebnis. Die Person, die die Aufgabe erhält, gewinnt eine definierte Rolle in der Arbeit; sie erbt nicht automatisch jede Befugnis, die die Person besitzt, die gefragt hat. Gute Organisationen treffen diese alltägliche Unterscheidung mit Stellenbeschreibungen, Genehmigungsgrenzen, Verfahren, Funktionstrennung und Aufzeichnungen. Sie tun das, weil Fähigkeit und Erlaubnis verschiedene Dinge sind.

Agentensysteme neigen dazu, diese Unterscheidung zu verwischen, weil ein Agent in einer einzigen Gesprächsoberfläche beschreiben, planen und ausführen kann. Ein Modell kann in der Lage sein, einen überzeugenden Plan zur Kontaktaufnahme mit einem Lieferanten zu erstellen. Ein Tool-Wrapper kann technisch in der Lage sein, die Nachricht zu senden. Eine Orchestrierungsebene kann in der Lage sein, diesen Wrapper ohne Pause aufzurufen. Diese Tatsachen beschreiben Fähigkeit. Sie entscheiden nicht darüber, ob die Nachricht gesendet werden soll, ob der vorgeschlagene Empfänger im Rahmen liegt, ob die Informationen zur Offenlegung geeignet sind oder wer die Konsequenz tragen soll, wenn die vorgeschlagene Handlung falsch ist.

Es hilft, fünf Fragen zu trennen, die oft gebündelt werden. Wer hat der Aufgabe ihren Zweck gegeben? Wer darf vorbereitende Arbeiten ausführen? Wer darf eine Teilaufgabe delegieren? Wer darf entscheiden, dass eine vorgeschlagene Handlung akzeptabel ist? Wer darf diese Handlung in der Außenwelt wirksam machen? Manchmal hält eine menschliche Rolle zu Recht mehrere dieser Antworten. Manchmal müssen sie getrennt werden. Es geht nicht darum, eine aufwendige Zeremonie für eine Notiz mit geringem Risiko zu schaffen. Es geht darum, zu vermeiden, eine technische Fähigkeit stillschweigend als Übertragung institutioneller Autorität zu behandeln.

Eine Delegation sollte daher mehr als eine Anweisung tragen. Sie sollte ein Mandat tragen. Das Mandat identifiziert das Ziel, den begrenzten Kontext, die zulässigen Eingaben, die erwartete Ausgabe, die Handlungen, die verboten bleiben, das Budget oder die Zeitgrenze, wo relevant, die Bedingungen, die eine Eskalation erfordern, und die Person oder Rolle, die für das Ergebnis verantwortlich ist. Der empfangende Agent kann dann nützliche Arbeit innerhalb einer sichtbaren Hülle leisten. Er kann einen anderen Agenten um eine Analyse bitten. Er kann die Hülle nicht erweitern, nur weil ihm ein plausibler nächster Schritt einfällt.

Dies ist kein Argument dafür, jede Interaktion in ein Genehmigungstreffen zu verwandeln. Es ist ein Argument dafür, den Punkt zu wählen, an dem die Organisation wünscht, dass eine Entscheidung stattfindet. Ein System kann eine Erklärung entwerfen, ohne dass ein Mensch jeden Satz ansieht, wenn Zweck, Zielgruppe, Quellengrenze und Veröffentlichungsregeln bereits festgelegt sind. Ein System sollte nicht die Macht erlangen, den Anspruch eines Kunden zu ändern, nur weil dieselbe Komponente Zugriff auf die relevante Datenbank hat. Der Unterschied ist die Konsequenz, nicht die Intelligenz des Modells.

Diese Konsequenz ist oft verteilt. Eine Aufgabe kann in einer Phase harmlos sein und in der nächsten folgenreich. Das Lesen einer Datei kann Routine sein. Die Kombination mit einer anderen Quelle kann die Sensibilität des Materials verändern. Die Vorbereitung einer Empfehlung kann Routine sein. Das Drücken eines Buttons, der ein rechtliches, finanzielles oder dienstliches Ergebnis erzeugt, ist es möglicherweise nicht. Ein Governance-Design, das nur fragt, ob ein Agent autonom ist, übersieht diesen Zustandswechsel. Die nützliche Frage ist enger gefasst: autonom wofür, für wen, unter welchen Bedingungen und mit wessen Autorität?

Es gibt hier einen bescheidenen niederländischen Instinkt, den es zu bewahren lohnt. Wenn ein Prozess ein Dutzend Unterschriften, Stempel und ein laminiertes Flussdiagramm benötigt, um festzulegen, wer einen Button drücken darf, ist das vielleicht kein Triumph der Governance. Aber die gegenteilige Anordnung, bei der eine Tool-Berechtigung wie eine verfassungsrechtliche Grundsatzentscheidung behandelt wird, ist ebenfalls kein Triumph. Das Ziel ist ein verhältnismäßiger Weg, der folgenreiche Autorität klar macht, ohne um jede Routinehandlung eine kleine Oper zu inszenieren.

Europäische Aufsicht ist eine Betriebsanforderung

Der AI Act bringt diese Idee für Hochrisiko-KI-Systeme rechtlich am deutlichsten zum Ausdruck. Artikel 14 verlangt, dass sie so konzipiert und entwickelt werden, dass natürliche Personen sie während der Nutzung wirksam überwachen können. Der erklärte Zweck ist, Risiken für Gesundheit, Sicherheit und Grundrechte zu verhindern oder zu minimieren, soweit diese Risiken trotz anderer Anforderungen bestehen bleiben können. Die Maßnahmen müssen im Verhältnis zu Risiko, Autonomie und Nutzungskontext stehen. Das ist ein bewusst operativer Standard. Es wird nicht gesagt, dass irgendeine Person in der Organisation allgemein an KI interessiert ist.

Die Bestimmung geht über eine allgemeine Anweisung hinaus, einen Menschen im Loop zu halten. Je nachdem, was angemessen und verhältnismäßig ist, muss die mit der Aufsicht betraute Person in die Lage versetzt werden, relevante Fähigkeiten und Grenzen zu verstehen, den Betrieb zu überwachen und Anomalien, Funktionsstörungen oder unerwartete Leistungen zu erkennen, sich der Automatisierungsverzerrung bewusst zu bleiben, Ergebnisse zu interpretieren, zu entscheiden, ein Ergebnis nicht zu verwenden oder es zu ignorieren, zu überstimmen oder umzukehren, und in das System einzugreifen oder es in einen sicheren Zustand zu unterbrechen. Das Gesetz macht daraus keine universelle Checkliste für jedes Agentensystem. Es zeigt aber, warum ein Stempel am Ende des Prozesses ein schlechtes Modell der Aufsicht ist.

Nun kommt die Delegation hinzu. Wenn ein Agent eine Aufgabe an einen anderen Agenten übergibt, muss die Aufsichtsrolle mehr sehen können als den letzten Satz, den das letzte Modell produziert hat. Es braucht genug Kontext, um zu verstehen, welcher Agent die Teilaufgabe vorgeschlagen hat, welche Quellen oder Tools verwendet wurden, ob eine Richtlinienbegrenzung erreicht wurde, ob ein Ergebnis von einem Prüfer geändert wurde und ob ein späterer Agent den Umfang erweitert hat. Andernfalls kann der Mensch ein Ergebnis sehen, aber nicht den Weg, der es hervorgebracht hat. Das mag für einen Entwurf mit geringen Konsequenzen ausreichen. Es ist keine überzeugende Grundlage, um eine folgenreiche Entscheidung zu akzeptieren.

Artikel 26 macht den organisatorischen Punkt für Betreiber von Hochrisiko-Systemen noch deutlicher. Er besagt, dass Betreiber die menschliche Aufsicht natürlichen Personen übertragen müssen, die über die erforderliche Kompetenz, Schulung, Autorität und Unterstützung verfügen. Diese Wörter gehören zusammen. Kompetenz ohne Autorität schafft einen gut informierten Zuschauer. Autorität ohne Kompetenz schafft einen formalen Verantwortlichen, der das System nicht in Frage stellen kann. Beides ohne Unterstützung schafft eine Person, die in einen Prozess eingreifen soll, den sie nicht sehen kann, in einem Tempo, das sie nicht einhalten kann, mit Informationen, die sie nicht interpretieren kann.

Bei Multi-Agent-Arbeit umfasst der Support die Form der Schnittstelle und des Protokolls. Eine Bedienperson benötigt nicht jedes Token, das ein Modell erzeugt hat, oder jeden internen Wiederholungsversuch. Sie benötigt die vorgeschlagene Aktion, den benannten Zweck, die materiellen Belege, die geltende Richtlinie und das geltende Limit, die seit dem letzten Prüfpunkt vorgenommenen Änderungen, die erwartete Wirkung, den möglichen Umkehrweg und den Grund für die Eskalation des Falls. Dabei geht es weniger darum, ein Dashboard beruhigend wirken zu lassen, als vielmehr darum, die Wahrscheinlichkeit zu verringern, dass eine Person eine Antwort genehmigt, weil das System die Alternative mühsam auffindbar gemacht hat.

Das Rahmenübereinkommen des Europarats über künstliche Intelligenz und Menschenrechte, Demokratie und Rechtsstaatlichkeit stellt den breiteren institutionellen Zusammenhang her. Sein Zweck ist es, sicherzustellen, dass Aktivitäten im Lebenszyklus von KI-Systemen mit Menschenrechten, Demokratie und Rechtsstaatlichkeit vereinbar sind. Die Artikel 8 und 9 fordern Transparenz und Aufsicht, die auf spezifische Kontexte und Risiken zugeschnitten sind, sowie Rechenschaftspflicht und Verantwortung für nachteilige Auswirkungen. Das Übereinkommen schreibt kein Muster für die Orchestrierung von Agenten vor. Es bietet jedoch eine nützliche Korrektur für die Vorstellung, dass eine Kette von Softwarekomponenten die Verantwortlichkeiten der öffentlichen Stelle oder des privaten Akteurs, die sie nutzt, auflösen kann.

Diese breitere Sichtweise ist wichtig, weil eine delegierte Entscheidung mehr als nur die technische Leistung beeinflussen kann. Sie kann die Fähigkeit einer Person beeinträchtigen, eine Entscheidung zu verstehen, sie anzufechten, Abhilfe zu erlangen oder schlicht zu wissen, welche Organisation verantwortlich ist. Ein Workflow kann aus Komponenten mehrerer Anbieter, Modellen mehrerer Anbieter, von einem anderen Team betriebenen Werkzeugen und einer im Rahmen eines öffentlichen Vertrags erbrachten Dienstleistung bestehen. Die Tatsache, dass die Kette technisch verteilt ist, macht die Auswirkung auf den Einzelnen nicht weniger real. In der Praxis macht sie eine klare Rollenzuweisung umso wichtiger.

Der Datenschutz warnt aus einer anderen Richtung auf dieselbe Weise. Die Arbeit des Europäischen Datenschutzausschusses zu KI-Modellen betont, dass die Datenschutzanalyse kontextbezogen bleibt: Organisationen müssen ihre Rolle bestimmen, die betroffene Verarbeitung identifizieren und die einschlägigen Pflichten anwenden, anstatt das Etikett KI-Modell als Befreiung von der üblichen Rechenschaftspflicht zu behandeln. Wenn ein Multi-Agent-Workflow personenbezogene Daten berührt, sollte die Delegation nicht verschleiern, wer Zweck und Mittel der Verarbeitung bestimmt, welcher Agent oder welches Werkzeug welche Daten erhält und ob die nächste Übergabe für die Aufgabe erforderlich ist. Eine Teilaufgabe ist weiterhin ein Verarbeitungsschritt. Sie als Delegation zu bezeichnen, lässt sie nicht verschwinden.

Nichts davon liefert eine magische Antwort auf jeden schwierigen Fall. Die rechtlichen Pflichten hängen von der Nutzung, den Akteuren, den Daten und dem Sektor ab. Ein Artikel kann ein bestimmtes System nicht klassifizieren. Er kann jedoch ein diszipliniertes Prinzip formulieren: Wenn ein Workflow Arbeit verteilt, sollte er sie so verteilen, dass die Fähigkeit erhalten bleibt, Zuständigkeiten zu identifizieren, rechtzeitig einzugreifen, den Weg nachzuvollziehen und auf die Menschen zu reagieren, die vom Ergebnis betroffen sind.

Die Person im Prozess braucht einen echten Prozess

Menschliche Aufsicht wird leicht auf einen Bildschirm mit einem Genehmigen-Button reduziert. Dieser Bildschirm kann nützlich sein. Er kann auch ein zeremonielles Objekt sein. Die Frage ist, ob die Person, die ihn nutzt, eine echte Wahl hat. Eine Wahl ist nicht allein deshalb bedeutsam, weil die Schnittstelle zwei Buttons anzeigt. Sie hängt davon ab, ob die Person genügend Zeit, Informationen, Kompetenz und institutionelle Befugnis hat, um anders zu entscheiden.

Zeit ist der am wenigsten glamouröse Teil des Designs und oft der entscheidendste. Wenn das System in einem Zeitraum, in dem ein Prüfer vernünftigerweise nur einen Bruchteil sichten könnte, Hunderte von Vorschlägen versendet, hat die Organisation eine Warteschlange geschaffen, keine Aufsicht. Wenn ein Vorschlag abläuft, bevor der Prüfer Kontext beschaffen kann, hat das System Geschwindigkeit zur faktischen Entscheidungsinstanz gemacht. Wenn ein Team nur für Durchsatz belohnt wird, hat es eine leise Anweisung darüber erhalten, welcher Knopf zu drücken ist. Software kann diese Gegebenheiten nicht heilen, indem sie einen Konfidenzwert in einem anderen Grünton hinzufügt.

Informationen müssen verhältnismäßig sein, nicht erschöpfend. Ein Prüfer, der nur eine Schlussfolgerung erhält, kann diese nicht hinterfragen. Ein Prüfer, der ein rohes Transkript jeder Agenteninteraktion erhält, kann dies in der Regel ebenfalls nicht. Die brauchbare Mitte ist ein Entscheidungspaket. Es benennt, welche Aktion vorgeschlagen wird, warum sie innerhalb des erklärten Zwecks liegt, welche wesentlichen Belege sie stützen, welche Unsicherheit verbleibt, welche Richtlinie oder Regel relevant ist, welche Wirkung vorgeschlagen wird und was geschähe, wenn die Aktion nicht genehmigt würde. Das Paket sollte auf tiefergehende Belege verlinken, aber es sollte für den Regelfall keine archäologische Expedition verlangen.

Kompetenz bedeutet mehr als ein allgemeiner Kurs über KI. Für die anstehende Aufgabe muss der Prüfer die Art der Ausgabe verstehen, die bekannten Einschränkungen, die von Bedeutung sein könnten, die Art und Weise, wie der Workflow sich verhalten soll, und die Anzeichen, die eine Eskalation erfordern. Eine Person, die eine fehlerhafte Lieferantenrechnung erkennen kann, mag gut geeignet sein, einen rechnungsbezogenen Vorschlag zu prüfen. Dieselbe Person ist möglicherweise nicht gut geeignet, die Sprachabdeckung eines Modells oder eine datenschutzrechtliche Auswirkung zu beurteilen. Die Zuweisung der Aufsicht ist daher auch eine Personalentscheidung.

Institutionelle Erlaubnis ist der Test, den viele Designs stillschweigend nicht bestehen. Der Prüfer muss in der Lage sein, den vorgeschlagenen Weg abzulehnen, zu pausieren oder zu ändern, ohne als Ursache eines Systemfehlers behandelt zu werden. Sie benötigen Zugang zu einer Person oder Rolle, die über das weitere Vorgehen entscheiden kann. Sie benötigen eine Möglichkeit zu dokumentieren, dass die Angelegenheit eskaliert wurde. Und das System benötigt einen sicheren Zustand, in dem Arbeit warten kann, ohne versehentlich durch einen erneuten Versuch, eine Zeitüberschreitung oder einen anderen Agenten, der die ursprüngliche Anweisung als unerledigte Aufgabe betrachtet, ausgeführt zu werden.

Sicherheitstechnik hat menschliche Leistung seit jeher als Teil des Systems behandelt und nicht als letzte Lackschicht. Die britische Health and Safety Executive beschreibt menschliche Faktoren als Aufgabe, Individuum und Organisation zusammen und warnt davor, sie isoliert zu betrachten. Das ist ein sinnvoller Rahmen für die Aufsicht über Agenten. Ein Prüfer ist kein abstrakter menschlicher Stecker für eine Softwarelücke. Sie verrichten eine bestimmte Aufgabe, mit bestimmten Informationen und Werkzeugen, innerhalb einer bestimmten Organisation mit bestimmten Zwängen und Grenzen. Die Qualität der Kontrolle hängt von alledem ab.

Aus diesem Grund beginnt ein gutes Human-in-the-Loop-Design, bevor der Knopf erscheint. Es legt fest, welche Entscheidungen ein menschliches Tor benötigen, wer das Tor hält, welche Belege sie erhalten, wie viel Zeit die Aufgabe zulässt, was geschieht, wenn sie abwesend sind, und ob das Tor Autorität über die Aktion selbst hat oder nur über eine Erklärung der Aktion. Wenn die Organisation diese Fragen an einem ruhigen Dienstag nicht beantworten kann, wird es nicht klarer, wenn ein Fall mit hohen Konsequenzen eintrifft. Und es sollte keiner imaginären Krise bedürfen, um dies zu bemerken.

Berechtigungen sollten die Folge einer Handlung beschreiben, nicht nur die technische Reichweite einer Anmeldedaten.

Eine Aufgabe, mehrere Arten von Befugnis

Ein kompaktes Befugnis-Modell kann den Betrieb eines Agent-Workflows erleichtern. Es muss nicht großartig sein. Beginnen Sie mit dem Unterschied zwischen Lesen, Vorschlagen, Delegieren, Ausführen und Stoppen. Eine Rolle mit Leserecht kann das für eine Aufgabe notwendige Material einsehen. Eine Rolle mit Vorschlagsrecht kann eine mögliche Handlung vorbereiten. Eine Rolle mit Delegationsrecht kann begrenzte Arbeit an einen anderen Akteur übertragen. Eine Rolle mit Ausführungsrecht kann eine folgenreiche Handlung wirksam machen. Eine Rolle mit Stopprecht kann eine Route anhalten oder stoppen, wenn ihre Bedingungen nicht mehr erfüllt sind.

Dies sind nicht einfach Rangstufen. Ein Compliance-Prüfer kann einen Workflow stoppen, aber kein Kundenergebnis ausführen. Ein spezialisierter Agent kann eine Route vorschlagen, aber außerhalb seines Bereichs keine neue Arbeit delegieren. Eine Führungskraft kann für den Zweck eines Dienstes verantwortlich sein, aber nicht die Person sein, die eine bestimmte Zahlung freigeben darf. Der nützliche Aspekt ist keine Hierarchie um ihrer selbst willen. Es ist, dass das System bewerten kann, ob ein bestimmter Akteur im aktuellen Kontext die relevante Befugnis für eine bestimmte Handlung hat.

Der Kontext leistet einen Großteil der Arbeit. Dieselbe vorgeschlagene Handlung kann in einem Umstand gewöhnlich und in einem anderen folgenreich sein. Das Senden einer bereits genehmigten Vorlage an eine bekannte interne Adresse kann innerhalb eines routinemäßigen Kommunikationsmandats liegen. Das Senden einer neu verfassten Nachricht mit personenbezogenen Daten an einen neuen Empfänger ist etwas anderes. Eine Rückerstattung innerhalb eines definierten Schwellenwerts kann an einen gut getesteten Prozess delegiert werden. Eine Änderung eines Anspruchs, eine Datenlöschung oder eine externe Verpflichtung kann eine namentlich benannte menschliche Entscheidung erfordern. Die Richtlinie sollte diese Unterscheidung ausdrücken, bevor das Modell gebeten wird, darauf zu planen.

Es gibt auch einen wichtigen Unterschied zwischen einer Bestätigung und einer Anerkennung. Eine Anerkennung hält fest, dass jemand eine Nachricht gesehen hat. Eine Bestätigung hält fest, dass eine autorisierte Person eine definierte Handlung mit dem relevanten Kontext an einem definierten Punkt der Route akzeptiert hat. In einem Konversationssystem können diese ähnlich aussehen. Die Aufzeichnung sollte es nicht. Wenn ein späterer Prüfer nicht erkennen kann, welche Handlung genehmigt wurde und welche Wirkung erwartet wurde, hat die Organisation ein Gespräch protokolliert, statt eine Entscheidung erfasst zu haben.

Delegation selbst braucht Grenzen. Ein Agent, der die Aufgabe erhält, drei bestehende Vorschläge zu vergleichen, darf einen Forschungsagenten bitten, relevante Begriffe zu extrahieren. Er sollte diese Berechtigung nicht als Einladung betrachten, Lieferanten zu kontaktieren, neue Daten zu beschaffen oder das Beschaffungsziel neu zu formulieren. Die Grenze kann in der Richtlinie, im Werkzeugumfang, in einem strukturierten Aufgabenvertrag oder in allen dreien ausgedrückt werden. Wichtig ist, dass sie durchsetzbar genug ist, um die Route einzuschränken, statt lediglich das gewünschte Verhalten im Nachhinein zu beschreiben.

Die Delegationstiefe ist eine weitere Grenze, die es zu benennen lohnt. Ein Mensch kann einem Agenten eine Aufgabe geben und dennoch einen klaren Überblick über dessen erste Übergabe behalten. Nach mehreren verschachtelten Übergaben mag der ursprückliche Zweck technisch in den Metadaten vorhanden sein, praktisch ist er jedoch unsichtbar. Organisationen können für eine Klasse von Arbeiten eine maximale Delegationstiefe festlegen, eine Überprüfung in einer bestimmten Tiefe verlangen oder einem Beauftragten verbieten, ohne eine neue Freigabe weitere Beauftragte zu schaffen. Dies sind Gestaltungsentscheidungen, keine allgemeingültigen Anforderungen. Sie sind dort am nützlichsten, wo eine längere Kette es schwierig macht zu erkennen, welcher Akteur eine neue Annahme eingeführt oder den tatsächlichen Geltungsbereich verändert hat.

Die Werkzeugbefugnis muss ebenfalls von der Modellbefugnis getrennt sein. Ein Modell könnte ein Werkzeug auf der Grundlage eines Plans auswählen. Die Werkzeugintegration sollte dennoch prüfen, ob die angeforderte Aktion, das Ziel, die Datenkategorie, das Ressourcenlimit und der Workflow-Zustand den Aufruf zulassen. Dies ist kein Misstrauen gegenüber dem Modell im moralischen Sinne. Es ist gewöhnliches Grenzdesign. Ein gut ausgearbeiteter Plan kann für den aktuellen Fall dennoch ungeeignet sein, und ein schlecht ausgearbeiteter Plan sollte nicht allein deshalb Wirklichkeit werden, weil er eine Berechtigung mit weitreichendem Zugriff erreicht hat.

Gleiches gilt für die Wiederherstellung. Ein erneuter Versuch ist nicht immer harmlos. Einen erneuten Versuch zu unternehmen, ein öffentliches Dokument zu lesen, ist etwas anderes, als einen erneuten Versuch zu unternehmen, eine Nachricht zu senden oder eine Belastung vorzunehmen. Wenn eine delegierte Aufgabe fehlschlägt, benötigt ein Workflow eine ausdrückliche Wahl zwischen erneutem Versuch, Umleitung, Eskalation, Pause und kontrolliertem Fehlschlag. Sie als einen generischen Fehlerbehandler zu behandeln, ist die Art und Weise, wie eine operative Entscheidung stillschweigend durch Standardeinstellungen getroffen wird. Die Agentenlaufzeit kann die Optionen verfügbar machen. Die Organisation muss entscheiden, welche Option für welche Handlungsklasse gilt.

Fehler sind oft eine fehlende Entscheidung

Wenn Menschen von Fehlern hören, stellen sie sich oft einen Agenten vor, der eine falsche Aussage erzeugt, oder ein Werkzeug, das eine Zeitüberschreitung erleidet. Beides kann von Bedeutung sein. Die aufschlussreicheren Fehler bei delegierter Arbeit sind jedoch häufig leiser. Die Aufgabe wurde ohne klaren Verantwortlichen zugewiesen. Der Vorschlag überschritt eine Grenze, die niemand modelliert hatte. Der Prüfer konnte die Schlussfolgerung sehen, aber nicht die Belege. Ein erneuter Versuch wurde nach einer Pause fortgesetzt. Ein Mensch bemerkte ein Problem, hatte aber keine Befugnis, die Aktion zu stoppen. Eine Entscheidung wurde getroffen, aber der Datensatz bewahrte nur das endgültige Ergebnis und nicht die Bedingung, die es akzeptabel machte.

Dies sind keine Behauptungen über einen namentlich genannten Vorfall. Es sind Fehlermodi, die sich aus der Struktur der Delegation selbst ergeben. Sie sind auch in menschlichen Prozessen zu finden. In Software jedoch können sie sich mit der Geschwindigkeit der Automatisierung fortbewegen und sehr konsistent wiederholt werden. Diese Konsistenz ist kein Grund zur Verzweiflung. Sie ist ein Grund, die Workflow-Gestaltung als Teil der Kontrolle zu behandeln, anstatt anzunehmen, dass Genauigkeitstests einer einzelnen Modellkomponente die Frage klären.

Betrachten Sie ein weiteres ausdrücklich hypothetisches Design. Ein Agent wird gebeten, eine Fallzusammenfassung vorzubereiten. Er delegiert die Dokumentextraktion an eine Komponente und die Sprachnormalisierung an eine andere. Eine dritte Komponente sieht ein unvollständiges Feld und nutzt eine verbundene Wissensquelle, um die Lücke zu füllen. Die endgültige Zusammenfassung liest sich flüssig. Wenn der Workflow das fehlende Feld, die Quelle, die zur Füllung verwendet wurde, die damit verbundene Konfidenz oder Unsicherheit und die Tatsache, dass die ursprüngliche Aufgabe nur die Zusammenfassung erlaubte, nicht aufgezeichnet hat, kann ein Prüfer nicht erkennen, ob er eine Zusammenfassung oder eine neu erstellte faktische Behauptung genehmigt. Das Problem ist nicht, dass der letzte Satz seltsam klingt. Das Problem ist, dass sich die Bedeutung der Aufgabe innerhalb der Route geändert hat.

Eine vernünftige Antwort ist nicht, Delegation zu verbieten. Es geht darum, Änderungspunkte im Protokoll festzuhalten. Eine neue Quelle, ein neues Werkzeug, eine neue Datenkategorie, eine neue Aktionsklasse, eine wesentliche Änderung der Konfidenz, eine fehlgeschlagene Kontrolle, eine länger als zulässige Delegationskette oder der Vorschlag, eine externe Grenze zu überschreiten, können jeweils ein Grund sein, die Arbeit zur Überprüfung vorzulegen. Die genauen Auslöser werden je nach Kontext unterschiedlich sein. Das Prinzip ist stabil: Eine Änderung, die für die verantwortliche Eigentümerin oder den verantwortlichen Eigentümer von Bedeutung wäre, sollte nicht unsichtbar bleiben, nur weil sie zwischen Komponenten aufgetreten ist.

Hier ist das Denken in Sicherheitsnachweisen nützlich. Ein Sicherheitsnachweis ist kein Versprechen, dass nichts schiefgehen kann. Es ist ein strukturiertes Argument dafür, warum ein System für einen definierten Zweck unter definierten Bedingungen akzeptabel ist, wobei Belege, Annahmen, Kontrollen und Restrisiken sichtbar sind. Sorgfältig auf einen Agenten-Workflow angewendet, bedeutet das, dass die Behauptung nicht ist, dass Agenten allgemein sicher sind. Die Behauptung ist enger gefasst: Diese Route darf für diesen Zweck genutzt werden, mit diesen Grenzen, weil diese Kontrollen und Aufsichtsvereinbarungen existieren, und sie muss überdacht werden, wenn die genannten Annahmen nicht mehr gelten.

Der Workflow lässt sich dann leichter hinterfragen. Eine Bedienerin oder ein Bediener kann fragen, ob die Aktionsklasse korrekt zugewiesen wurde. Eine Risikoeigentümerin oder ein Risikoeigentümer kann fragen, ob die prüfende Person noch genügend Zeit hat. Eine Ingenieurin oder ein Ingenieur kann fragen, ob ein erneuter Versuch eine doppelte Wirkung erzeugen könnte. Eine Datenschutzspezialistin oder ein Datenschutzspezialist kann fragen, ob die Teilaufgabe weiterhin notwendig und verhältnismäßig ist. Eine von einem Ergebnis betroffene Person kann, wo es der anwendbare Rahmen verlangt, einen Weg erhalten, die Entscheidung anzufechten. Diese Fragen sind keine Bürokratie, die nach der interessanten technischen Arbeit hinzugefügt wird. Sie sind die Arbeit, das technische System in einer Organisation rechenschaftspflichtig zu machen.

Metriken sollten derselben Disziplin folgen. Die Anzahl delegierter Aufgaben zu zählen, sagt uns etwas über das Volumen, nicht über rechenschaftspflichtigen Betrieb. Nützlichere Messgrößen können die Rate umfassen, mit der ein Workflow eskaliert, weil sich eine Grenze geändert hat, die Zeit, die eine Entscheidung an einem Tor wartet, der Anteil folgenreicher Aktionen mit einem vollständigen Entscheidungspaket, die Anzahl erfolgreicher Umkehrungen oder die Anzahl der Fälle, in denen eine Richtlinienprüfung einen Werkzeugaufruf verweigerte. Solche Messungen benötigen weiterhin eine Definition und einen Kontext. Sie sollten niemals für eine Broschüre erfunden werden. Aber die Protokolle so zu gestalten, dass sie messbar wären, ist ein Zeichen dafür, dass Rechenschaftspflicht als Betriebseigenschaft behandelt wird.

Das Protokoll ist der Ort, an dem Verantwortung überlebt

Ein Multi-Agenten-System erzeugt eine eigenartige Art von Geschichte. Es gibt Nachrichten, Werkzeugaufrufe, Zwischenausgaben, Richtlinienprüfungen, Modellversionen, Zeitinformationen, erneute Versuche, geänderte Zuweisungen und vielleicht menschliche Genehmigungen. Jedes Byte für immer aufzubewahren, ist weder notwendig noch oft angemessen. Nur die endgültige Antwort aufzubewahren, ist meist zu wenig. Das Protokoll muss die Entscheidungen und Belege bewahren, die erklären, wie der Workflow von einer Anfrage zu einem Ergebnis gelangte.

Für eine folgenreiche Aktion sollte dieses Protokoll einer prüfenden Person normalerweise erlauben, ein paar grundlegende Fakten zu rekonstruieren. Was war das Ziel? Welche Richtlinie oder welches Mandat machte die Arbeit zulässig? Wer oder was erhielt jede Zuweisung? Was wurde an jedem folgenreichen Tor vorgeschlagen? Welche Informationen wurden verwendet, um den Vorschlag zu stützen? Welche Grenzen, Warnungen oder Fehler traten auf? Wer hatte die Befugnis, die Aktion zu genehmigen, zu stoppen oder umzukehren? Welche Aktion wurde wirksam, und was geschah danach? Das sind keine exotischen Fragen. Es sind die Fragen, die eine Organisation stellt, wenn sie wissen möchte, ob eine Entscheidung ihre Entscheidung war.

Der Datensatz sollte eine operative Tatsache von einer später erstellten Erklärung unterscheiden. Wenn ein System angibt, dass eine prüfende Person eine Aktion genehmigt hat, sollte das Ereignis die Identität oder Rolle der prüfenden Person, die ihr gezeigte Aktion, den relevanten Kontext und den Zeitpunkt festhalten, zu dem die Genehmigung an diese Aktion gebunden war. Wenn das System angibt, dass ein Modell eine Stellvertretung ausgewählt hat, sollte der Datensatz die Auswahlregel, die Kandidaten oder die Kriterien in einem für die Verwendung angemessenen Umfang sowie die resultierende Zuordnung bewahren. Eine spätere Erzählung kann einer lesenden Person helfen, sie sollte jedoch nicht das Ereignis ersetzen, das stattgefunden hat.

Die Versionierung ist hier von Bedeutung. Die Ausgabe eines Agenten kann neu generiert werden. Eine Richtlinie kann aktualisiert werden. Ein Tool-Schema kann sich ändern. Ein Modell-Endpunkt kann ausgetauscht werden. Wenn eine Entscheidung von einer bestimmten Version eines Prompts, einer Richtlinie, eines Modells, einer Wissensquelle oder einer Integration abhängt, benötigt der Datensatz eine stabile Referenz auf diese Version. Andernfalls wird die Wiederholung zu einer Aufführung: Sie reproduziert, was die Organisation gerade jetzt hat, und nennt das Ergebnis eine Erklärung dessen, was damals geschah.

Der Umkehrbarkeit gebührt gleichermaßen Aufmerksamkeit. Der AI Act bezieht sich im Zusammenhang mit der Hochrisiko-Aufsicht ausdrücklich auf die Fähigkeit, eine Ausgabe zu ignorieren, zu überstimmen oder umzukehren und ein System zu unterbrechen, sodass es in einem sicheren Zustand zum Stillstand kommt. In einer Multi-Agenten-Route ist der sichere Zustand nicht unbedingt ein gestoppter Modellprozess. Es kann bedeuten, dass keine externe Kommunikation gesendet wird, eine in der Warteschlange befindliche Aktion zurückgehalten wird, ein nachgelagertes System nicht aktualisiert wird, temporäre Anmeldeinformationen für die Aufgabe nicht mehr verwendbar sind und die Beweise, die für die Entscheidung über das weitere Vorgehen erforderlich sind, aufbewahrt werden. Das ist eine operative Schlussfolgerung aus der Aufsichtsanforderung, kein Zitat des Gesetzes. Es ist auch ein nützlicher Designtest.

Sicher bedeutet nicht für immer eingefroren. Ein angehaltener Workflow benötigt einen kontrollierten Wiederaufnahmepfad. Jemand muss entscheiden, ob die Aufgabe geändert, der Vorschlag verworfen, ein begrenzter Teil der Arbeit erneut ausgeführt, ein anderes Tool verwendet, weitere Beweise eingeholt oder die Route aufgegeben werden soll. Ein sauberer Datensatz erleichtert diese Wahl, weil er der nächsten Person mitteilt, was bekannt ist, was versucht wurde, warum die Arbeit gestoppt wurde und welche Auswirkungen eingetreten sind und welche nicht. Ohne diesen Datensatz wird die Wiederherstellung zu einer weiteren unstrukturierten Delegation, die in der Regel unter größerem Druck erfolgt als die erste.

Aus diesem Grund benötigen Aufbewahrung und Zugriff ihre eigenen Entscheidungen. Nicht jede handelnde Person sollte jede Spur lesen können. Ein Datensatz kann personenbezogene Daten, kommerziell sensible Materialien oder sicherheitsrelevante Details enthalten. Aber kontrollierter Zugriff ist nicht dasselbe wie kein Datensatz. Die Betonung der Konvention des Europarats auf Transparenz, Aufsicht, Rechenschaftspflicht und Verantwortung ist eine nützliche Erinnerung daran, dass die Grenze gestaltet und nicht angenommen werden sollte. Eine Organisation kann eine rechenschaftspflichtige Route bewahren, während sie den Zugriff auf die Details beschränkt, die eine bestimmte prüfende Person tatsächlich benötigt.

Was ein Delegationsvertrag sichtbar machen sollte

Ein Delegationsvertrag kann eine Datenstruktur, ein Workflow-Schema, ein signiertes Genehmigungspaket oder eine Kombination daraus sein. Seine Form ist weniger wichtig als sein Inhalt. Er sollte der empfangenden handelnden Person mitteilen, was sie tun darf, was sie nicht tun darf und wie die Arbeit beurteilt wird. Wenn diese Einschränkungen fehlen, neigen Agenten dazu, mit zunehmend aufwendigeren Anweisungen zu kompensieren. Das kann einen bestimmten Durchlauf verbessern. Es schafft jedoch keine organisatorische Grenze, die ein Tool, eine prüfende Person oder eine Wirtschaftsprüferin durchsetzen kann.

Beginnen Sie mit dem beabsichtigten Zweck. Ein Zweck sollte konkret genug sein, um naheliegende Aufgaben auszuschließen. Vergleichen Sie die Bedingungen in den eingereichten Vorschlägen ist etwas anderes als den besten Anbieter finden. Fassen Sie die eingegangenen Dokumente zusammen ist etwas anderes als die fehlenden Tatsachen feststellen. Entwerfen Sie eine Antwort zur Überprüfung ist etwas anderes als eine Entscheidung mitteilen. Der Kontrast kann pingelig klingen, bis ein Agent eine breite Anweisung nutzt, um einen vernünftigen, aber nicht autorisierten nächsten Schritt zu unternehmen. Dann ist es der Unterschied zwischen nützlicher Initiative und einem unbegrenzten Mandat.

Legen Sie die zulässigen und unzulässigen Handlungsklassen fest. Ein Agent darf möglicherweise eine Akte lesen, benannte Felder extrahieren, mit einer Richtlinie abgleichen und einen Entwurf vorbereiten. Es kann ihm untersagt sein, einen Quelldatensatz zu ändern, eine externe Partei zu kontaktieren, eine neue Quelle auszuwählen oder eine Transaktion auszuführen. Dabei handelt es sich nicht nur um Anweisungen im Prompt. Die Werkzeug- und Workflow-Ebene sollte sie dort durchsetzen, wo dies praktikabel ist. Eine Richtlinie, die im Moment der Handlung nicht überprüft werden kann, ist als Leitlinie weiterhin nützlich, aber als Kontrolle schwächer.

Benennen Sie den Verantwortlichen und den Eskalationsweg. Der Verantwortliche ist nicht unbedingt die Person, die jede Handlung genehmigt. Es ist die Rolle, die für das Ergebnis verantwortlich ist und dafür, was geschieht, wenn der Weg zu einer ungeklärten Frage führt. Der Eskalationsweg benennt die nächste Instanz, wenn der Agent eine Grenzverletzung, unzureichende Belege, einen Konflikt zwischen Quellen, eine Richtlinienabweichung oder eine Bedingung erkennt, die das System nicht auflösen darf. Eine Warteschlange ohne benannten Entscheidungsverantwortlichen ist schlicht eine Verzögerung mit einem optimistischen Etikett.

Fügen Sie eine Belegregel hinzu. Die Regel kann festlegen, welche Quellen maßgeblich sind, ob der Agent über diese hinaus suchen darf, wie Unsicherheit dargestellt wird, was im Vorschlag zitiert werden muss und wann eine widersprüchliche Quelle eine Überprüfung erfordert. Dies ist besonders wichtig für Systeme, die flüssige Prosa erzeugen. Flüssigkeit kann eine Grenzverletzung wie eine nützliche Vervollständigung aussehen lassen. Eine Belegregel macht die richtige Frage verfügbar: Ist der Workflow innerhalb des Materials geblieben, das zu verwenden ihm gestattet war?

Setzen Sie dort Grenzen für Zeit, Ressourcen und Delegation, wo sie von Bedeutung sind. Eine Aufgabe, die unbegrenzt weiterlaufen darf, kann Kosten, betriebliche Überlastung oder Druck erzeugen, ein veraltetes Ergebnis zu übernehmen. Eine Aufgabe, die wiederholt delegieren darf, kann eine Kette erzeugen, die kein Verantwortlicher ohne Weiteres überblicken kann. Ein begrenztes Design legt fest, wie lange die Aufgabe gültig bleibt, wie viele Ressourcen sie verbrauchen darf, ob sie eine Unteraufgabe erstellen darf, welche maximale Tiefe zulässig ist und was geschieht, wenn ein Limit erreicht wird. Die Antwort kann automatische Pause, Eskalation oder kontrollierter Fehlschlag sein. Wichtig ist, dass sie entschieden wird, bevor das Limit überschritten wird.

Definieren Sie schließlich die Abschlussbedingung. Abgeschlossen bedeutet nicht immer, dass der Agent Text erzeugt hat. Es kann bedeuten, dass ein Prüfer ein vollständiges Paket erhalten hat, dass ein Richtliniengate eine bestimmte Handlung akzeptiert hat, dass ein nachgelagertes System ein reversibles Update bestätigt hat oder dass ein verantwortlicher Eigentümer beschlossen hat, nicht fortzufahren. Abschlussbedingungen halten den Workflow ehrlich. Sie verhindern, dass ein Agent den Vorschlag einer Entscheidung so behandelt, als hätte die Organisation sie bereits getroffen.

Diese Muster sind nützlich, ob der Workflow einen einzelnen modellbasierten Agenten oder ein größeres Team spezialisierter Komponenten enthält. Mehr Agenten erfordern nicht automatisch mehr Prozess. Sie erfordern jedoch, dass die Grenzen zwischen den Rollen ausgedrückt statt impliziert werden. Die Kosten dieses Ausdrucks sind in der Regel viel geringer als die Kosten des Versuchs, Autorität zu rekonstruieren, nachdem mehrere Systeme Teilanweisungen ausgetauscht haben und eines davon die Außenwelt berührt hat.

Delegation sollte die Organisation leistungsfähiger machen, nicht weniger rechenschaftspflichtig

Agentensysteme werden oft so beschrieben, als läge ihr Wert darin, Organisation aus der Arbeit zu entfernen. Die interessantere Aussicht ist das Gegenteil. Ein sorgfältig gestaltetes System kann organisatorische Zusagen klarer machen: Eine Aufgabe hat einen Verantwortlichen, eine Delegation hat eine Grenze, eine folgenreiche Handlung hat eine Autorität, eine Überprüfung hat Belege, ein Halt hat einen sicheren Zustand und ein Datensatz kann erneut abgespielt werden. Das ist kein Hindernis für nützliche Automatisierung. Es ist das, was Automatisierung ermöglicht, bedeutungsvolle Arbeit zu übernehmen, ohne von Menschen zu verlangen, einer unsichtbaren Kette zu vertrauen.

Wir haben Dweve Nexus um diese Unterscheidung herum gebaut. Die lokale Produktdokumentation beschreibt dauerhafte Aufgaben, Befugnisse, die vor einer Aktion anhand des Laufzeitkontexts bewertet werden, ausdrückliche Kooperationsstrukturen einschließlich Delegation sowie eine Aufzeichnung, die während der Arbeit entsteht. Die entsprechende Behauptung ist bewusst bescheiden. Es handelt sich um Designeigenschaften, die einen delegierten Weg nachvollziehbar machen sollen. Sie sind kein Beweis dafür, dass eine bestimmte Bereitstellung rechtmäßig, sicher oder geeignet ist, und sie heben nicht die Notwendigkeit auf, dass eine Organisation ihren eigenen Zweck, ihre eigenen Befugnisse und ihre menschliche Aufsicht festlegt.

Die weiterreichende Lehre hängt nicht von einem einzelnen Produkt ab. Ein Modell kann entscheiden, wie es eine Aufgabe aufteilt. Ein Agent kann einen anderen Agenten um Arbeit bitten. Ein Werkzeug kann eine Aktion ausführen. Die Organisation muss dennoch entscheiden, wo die Befugnis liegt. Sie muss dies vor Beginn der Delegation tun, nicht erst, nachdem ein endgültiges Ergebnis zu etwas poliert wurde, das schwer in Frage zu stellen ist.

Das ist die Antwort auf den Titel. Der Eigentümer einer Entscheidung ist nicht der Agent, der zufällig zuletzt gesprochen hat. Es ist die Person oder Rolle, der die Organisation die Befugnis zugewiesen hat, die Konsequenz der Entscheidung zu akzeptieren, mit ausreichenden Informationen und der Macht, sie abzulehnen. Delegation ist nützlich, wenn sie diese Person leistungsfähiger macht. Sie wird gefährlich, wenn sie sie unmöglich auffindbar macht.