Kto podejmuje decyzję, gdy agent deleguje zadania?

Delegacja może uczynić przepływ pracy AI bardziej zdolnym, ale nie bardziej odpowiedzialnym. Różnica polega na tym, czy autorytet, dowody i prawo do...

Kto podejmuje decyzję, gdy agent deleguje zadania?

Przekazanie zadania nie opróżnia fotela

Agent deleguje zadanie. Inny agent gromadzi materiały, porównuje rekordy, wywołuje narzędzie lub przygotowuje rekomendację. Trzeci agent sprawdza wynik. Praca się przemieszcza, a to przemieszczanie może być użyteczne. Może też stworzyć bardzo stary problem zarządczy w nowej formie: każdy coś zrobił, a mimo to nikt nie potrafi powiedzieć, kto był uprawniony do podjęcia decyzji.

Kusząca odpowiedź wskazuje agenta, który wykonał ostatnie wywołanie. Jest to też zwykle odpowiedź najmniej pomocna. Komponent oprogramowania może wybrać trasę, poprosić o więcej pracy i przesłać instrukcję do połączonego systemu. Żadna z tych czynności nie ustala, kto zaakceptował cel, kto wyznaczył granice, kto mógł odmówić działania ani kto musiał zostać poinformowany o zmianie warunków. Ustala jedynie, że w łańcuchu znajdował się program.

To rozróżnienie staje się wyraźne, gdy przepływ pracy ma konsekwencje. Sugerowana odpowiedź może stać się komunikacją z klientem. Klasyfikacja może stać się powodem umieszczenia sprawy w konkretnej kolejce. Porównanie może stać się rekomendacją zakupową. Przygotowana dyspozycja płatności może stać się płatnością. Każdy krok może być technicznie poprawny, a mimo to organizacyjnie niekompletny. System wykonał pracę delegowania bez wykonania pracy autorytetu.

Nie trzeba wymyślać dramatycznej awarii, aby dostrzec problem. Weźmy celowo hipotetyczny przepływ pracy. Agent segregujący otrzymuje pytanie, prosi agenta badawczego o przejrzenie istotnych materiałów, wysyła wynik do recenzenta, a następnie przygotowuje działanie w systemie zarządzania sprawami. Agent badawczy nie jest upoważniony do działania. Recenzent nie jest upoważniony do nadania sprawie skutecznego rozstrzygnięcia. Agent segregujący ma poświadczenie narzędzia. Organizacja nie określiła, czy to poświadczenie pozwala mu zatwierdzić wynik. Przepływ pracy może wyglądać na uporządkowany na pulpicie. Mimo to dotarł do najważniejszego pytania bez odpowiedzi.

Delegowanie to nie zniknięcie odpowiedzialności. To odpowiedzialność, którą trudniej dostrzec. Dobre zaprojektowanie działania sprawia, że znów jest ona łatwiejsza do dostrzeżenia. Określa, jaka jest decyzja początkowa, co można delegować, jakie warunki towarzyszą zadaniu, kto może zatwierdzić działanie nieodwracalne lub mające skutki, jaki zapis pozostaje po przekazaniu oraz jak osoba lub system może interweniować, gdy trasa przestaje być bezpieczna. Od technologii nie wymaga się posiadania sprawczości moralnej. Wymaga się, aby pozostawiła sprawczość organizacji w nienaruszonym stanie.

To jest praktyczne znaczenie rozliczalności w przepływie pracy z wieloma agentami. To nie ozdobny zapis w polityce ani pościg za najbliższym pracownikiem, gdy coś pójdzie nie tak. To właściwość trasy, zanim praca się rozpocznie. Właściwa osoba może sprawdzić, co zaproponowano, zrozumieć, dlaczego to zaproponowano, wykonać przyznane jej uprawnienia i pozostawić zapis, który można później zakwestionować.

Pojawiające się w Europie przepisy dotyczące sztucznej inteligencji są tu pomocne, ponieważ mniej interesuje je teatralny człowiek na końcu przepływu niż warunki, w których nadzór może faktycznie działać. Przepisy aktu o sztucznej inteligencji dotyczące nadzoru człowieka mają zastosowanie do systemów wysokiego ryzyka, a nie do każdego użycia agenta. To ograniczenie ma znaczenie. Jednak pytania operacyjne zawarte w akcie dobrze się przenoszą: czy wyznaczona osoba fizyczna może zrozumieć istotne możliwości i ograniczenia, monitorować anomalie i nieoczekiwane działanie, unikać nadmiernego polegania, interpretować wyniki, ignorować je lub odwracać oraz przerwać działanie systemu do stanu bezpiecznego? Przepływ pracy z wieloma agentami nie pomniejsza tych pytań. Mnoży miejsca, w których odpowiedź może zostać zagubiona.

Delegacja może przekazywać pracę dalej. Nie może wymazać drogi, którą autorytet i sprzeciw wracają z powrotem.

Delegacja to łańcuch, nie mgła

Ludzie delegują nieustannie. Menedżer prosi współpracownika o przygotowanie notatki. Zespół zakupowy prosi eksperta o sprawdzenie zapisu umowy. Klinicysta prosi laboratorium o wynik. Osoba przyjmująca zadanie zyskuje określoną rolę w pracy; nie przejmuje automatycznie każdego uprawnienia osoby, która je zleciła. Dobre organizacje dbają o to proste rozróżnienie poprzez opisy stanowisk, limity zatwierdzeń, procedury, podział obowiązków i rejestry. Robią to, ponieważ kompetencja i upoważnienie to różne rzeczy.

Systemy agentowe zacierają to rozróżnienie, ponieważ agent potrafi opisać, zaplanować i wykonać działanie w jednej powierzchni konwersacyjnej. Model może być w stanie wygenerować przekonujący plan skontaktowania się z dostawcą. Otoczka narzędzia może być technicznie zdolna do wysłania wiadomości. Warstwa orkiestracji może być w stanie wywołać tę otoczkę bez pauzy. Te fakty opisują możliwości. Nie przesądzają one o tym, czy wiadomość powinna zostać wysłana, czy proponowany odbiorca mieści się w zakresie, czy informacja nadaje się do ujawnienia, ani kto powinien ponieść konsekwencje, jeśli proponowane działanie jest błędne.

Pomocne jest rozdzielenie pięciu pytań, które często są ze sobą łączone. Kto nadał zadaniu jego cel? Kto może wykonywać prace przygotowawcze? Kto może delegować podzadanie? Kto może zdecydować, że proponowane działanie jest dopuszczalne? Kto może uczynić to działanie skutecznym w świecie zewnętrznym? Czasami jedna rola ludzka słusznie łączy kilka z tych odpowiedzi. Czasami muszą być rozdzielone. Nie chodzi o tworzenie rozbudowanej ceremonii dla zadania o niskim ryzyku. Chodzi o uniknięcie cichego traktowania technicznej zdolności jako przeniesienia instytucjonalnej władzy.

Delegacja powinna zatem nieść coś więcej niż polecenie. Powinna nieść mandat. Mandat określa cel, ograniczony kontekst, dozwolone dane wejściowe, oczekiwany wynik, działania, które pozostają zakazane, budżet lub limit czasu, jeśli ma to znaczenie, warunki wymagające eskalacji oraz osobę lub rolę odpowiedzialną za rezultat. Otrzymujący agent może wtedy wykonywać użyteczną pracę w widocznej kopercie. Może poprosić innego agenta o analizę. Nie może rozszerzyć koperty tylko dlatego, że przychodzi mu do głowy prawdopodobny następny krok.

To nie jest argument za zamianą każdej interakcji w spotkanie zatwierdzające. To argument za wyborem punktu, w którym organizacja chce, aby zapadła decyzja. System może przygotować wyjaśnienie bez udziału człowieka w każdej decyzji, gdy cel, odbiorca, granice źródła i zasady publikacji są już ustalone. System nie powinien zyskiwać możliwości zmiany uprawnień klienta tylko dlatego, że ten sam komponent ma dostęp do odpowiedniej bazy danych. Różnica polega na konsekwencji, a nie na inteligencji modelu.

Ta konsekwencja często rozkłada się na etapy. Zadanie może być nieszkodliwe na jednym etapie, a doniosłe na następnym. Odczytanie pliku może być rutynowe. Połączenie go z innym źródłem może zmienić wrażliwość materiału. Przygotowanie rekomendacji może być rutynowe. Naciśnięcie przycisku, który wywołuje skutek prawny, finansowy lub usługowy, już niekoniecznie. Projekt ładu, który pyta tylko o to, czy agent jest autonomiczny, nie dostrzega tej zmiany stanu. Właściwe pytanie jest węższe: autonomiczny do czego, dla kogo, wobec jakich warunków i czyim autorytetem?

Jest tu skromny holenderski instynkt, który warto zachować. Jeśli proces wymaga tuzina podpisów, pieczątek i laminowanego schematu blokowego, aby ustalić, kto może nacisnąć jeden przycisk, to może nie być triumf ładu. Ale układ odwrotny, w którym poświadczenie narzędzia traktuje się jak konstytucyjne porozumienie, też nie jest triumfem. Celem jest proporcjonalna ścieżka, która czyni doniosły autorytet jasnym, bez odgrywania małej opery wokół każdej rutynowej czynności.

Nadzór europejski jest wymogiem operacyjnym

Akt w sprawie sztucznej inteligencji daje najjaśniejszy prawny wyraz tej idei w odniesieniu do systemów AI wysokiego ryzyka. Artykuł 14 wymaga, aby były one projektowane i rozwijane tak, by osoby fizyczne mogły je skutecznie nadzorować w trakcie ich użytkowania. Deklarowanym celem jest zapobieganie zagrożeniom dla zdrowia, bezpieczeństwa i praw podstawowych lub minimalizowanie ich, gdy zagrożenia te mogą pozostać mimo spełnienia innych wymogów. Środki muszą być współmierne do ryzyka, autonomii i kontekstu użycia. To celowo operacyjny standard. Nie mówi on, że jakaś osoba w organizacji jest ogólnie zainteresowana AI.

Przepis wykracza poza ogólne zalecenie utrzymania człowieka w pętli decyzyjnej. W zależności od tego, co jest właściwe i proporcjonalne, osoba wyznaczona do nadzoru musi mieć możliwość zrozumienia istotnych możliwości i ograniczeń, monitorowania działania oraz wykrywania anomalii, nieprawidłowości lub nieoczekiwanej wydajności, zachowania świadomości błędu automatyzacji, interpretowania wyników, decydowania o niekorzystaniu z wyniku lub o jego zignorowaniu, nadpisaniu lub odwróceniu, a także interweniowania lub przerwania działania systemu do stanu bezpiecznego. Prawo nie zamienia tego w uniwersalną listę kontrolną dla każdego systemu agentowego. Pokazuje jednak, dlaczego pieczątka na końcu procesu jest słabym modelem nadzoru.

Teraz dodajmy delegowanie. Jeśli agent przekazuje zadanie innemu agentowi, rola nadzorcza musi widzieć więcej niż tylko końcowe zdanie wygenerowane przez ostatni model. Potrzebuje wystarczającego kontekstu, aby zrozumieć, który agent zaproponował podzadanie, jakie źródła lub narzędzia zostały użyte, czy napotkano limit polityki, czy wynik został zmieniony przez recenzenta oraz czy późniejszy agent rozszerzył zakres. W przeciwnym razie człowiek widzi wynik, ale nie drogę, która go wytworzyła. To może wystarczyć w przypadku projektu o niskiej doniosłości. Nie jest to przekonująca podstawa do przyjęcia decyzji o doniosłych skutkach.

Artykuł 26 jeszcze jaśniej formułuje kwestię organizacyjną dla podmiotów wdrażających systemy wysokiego ryzyka. Mówi, że podmioty wdrażające mają powierzyć nadzór ludzki osobom fizycznym posiadającym niezbędne kompetencje, szkolenie, autorytet i wsparcie. Te słowa należą do siebie. Kompetencje bez autorytetu tworzą dobrze poinformowanego obserwatora. Autorytet bez kompetencji tworzy formalnego właściciela, który nie może zakwestionować systemu. Oba bez wsparcia tworzą osobę, od której oczekuje się interwencji w procesie, którego nie widzi, w tempie, któremu nie nadąża, na podstawie informacji, których nie potrafi zinterpretować.

W pracy z wieloma agentami wsparcie obejmuje kształt interfejsu i zapisu. Operator nie potrzebuje każdego tokenu wygenerowanego przez model ani każdej wewnętrznej ponownej próby. Potrzebuje natomiast proponowanego działania, nazwanego celu, materialnych dowodów, obowiązujących zasad i limitów, zmian wprowadzonych od ostatniego punktu przeglądu, przewidywanego efektu, możliwej ścieżki odwrócenia decyzji oraz powodu eskalacji sprawy. To mniej kwestia tego, by dashboard wyglądał uspokajająco, a bardziej zmniejszenia ryzyka, że człowiek zatwierdzi odpowiedź, ponieważ system sprawił, że znalezienie alternatywy jest wyczerpujące.

Ramowa konwencja Rady Europy o sztucznej inteligencji i prawach człowieka, demokracji i państwie prawa tworzy szersze powiązanie instytucjonalne. Jej celem jest zapewnienie, aby działania w cyklu życia systemów AI były zgodne z prawami człowieka, demokracją i państwem prawa. Artykuły 8 i 9 wzywają do przejrzystości i nadzoru dostosowanych do konkretnych kontekstów i ryzyk oraz do odpowiedzialności za niekorzystne skutki. Konwencja nie narzuca wzorca orkiestracji agentów. Stanowi jednak pożyteczną korektę poglądu, że łańcuch komponentów oprogramowania może rozmyć odpowiedzialność organu publicznego lub podmiotu prywatnego, który go używa.

Ta szersza perspektywa ma znaczenie, ponieważ decyzja podjęta w ramach delegowania może wpływać na coś więcej niż tylko wyniki techniczne. Może wpływać na zdolność osoby do zrozumienia decyzji, zakwestionowania jej, uzyskania zadośćuczynienia lub po prostu poznania organizacji odpowiedzialnej. Przepływ pracy może składać się z komponentów od kilku dostawców, modeli od kilku producentów, narzędzi obsługiwanych przez inny zespół oraz usługi świadczonej na podstawie umowy publicznej. Fakt, że łańcuch jest technicznie rozproszony, nie sprawia, że wpływ na jednostkę jest mniej realny. W praktyce czyni jasny podział ról ważniejszym.

Ochrona danych płynie z tego samego ostrzeżenia z innej strony. Prace Europejskiej Rady Ochrony Danych dotyczące modeli AI podkreślają, że analiza ochrony danych pozostaje kontekstowa: organizacje muszą określić swoją rolę, zidentyfikować zaangażowane przetwarzanie i stosować odpowiednie obowiązki, zamiast traktować etykietę „model AI” jako zwolnienie ze zwykłej odpowiedzialności. Gdy przepływ pracy z wieloma agentami dotyka danych osobowych, delegowanie nie powinno zaciemniać tego, kto określa cele i środki przetwarzania, który agent lub narzędzie otrzymuje które dane oraz czy kolejne przekazanie jest konieczne do wykonania zadania. Podzadanie jest nadal krokiem przetwarzania. Nazwanie go delegowaniem nie sprawia, że znika.

Żadne z tych rozważań nie daje magicznej odpowiedzi na każdy trudny przypadek. Obowiązki prawne zależą od zastosowania, podmiotów, danych i sektora. Artykuł nie może sklasyfikować konkretnego systemu. Może jednak sformułować zdyscyplinowaną zasadę: jeśli przepływ pracy rozdziela zadania, powinien robić to w sposób, który zachowuje możliwość ustalenia organu odpowiedzialnego, interwencji w czasie, rozliczenia trasy i reagowania na osoby, których dotyczy wynik.

Człowiek w pętli potrzebuje prawdziwej pętli

Nadzór człowieka łatwo sprowadzić do ekranu z przyciskiem zatwierdzania. Taki ekran może być użyteczny. Może też być obiektem ceremonialnym. Pytanie brzmi, czy osoba z niego korzystająca ma rzeczywisty wybór. Wybór nie jest znaczący tylko dlatego, że interfejs wyświetla dwa przyciski. Zależy od tego, czy osoba ma wystarczająco dużo czasu, informacji, kompetencji i instytucjonalnego upoważnienia, aby zdecydować inaczej.

Time is the least glamorous part of the design and often the most decisive. If the system sends hundreds of proposals in a period in which one reviewer could reasonably inspect only a fraction, the organisation has created a queue, not oversight. If the proposal expires before the reviewer can obtain context, the system has made speed the effective decision-maker. If a team is rewarded only for throughput, it has given a quiet instruction about which button to press. Software cannot cure these arrangements by adding a confidence score in a different shade of green.

Information has to be proportionate, not exhaustive. A reviewer given nothing but a conclusion cannot challenge it. A reviewer given a raw transcript of every agent interaction cannot usually challenge it either. The usable middle is a decision packet. It identifies what action is proposed, why it is within the stated purpose, which material evidence supports it, what uncertainty remains, which policy or rule is relevant, what the proposed effect is, and what would happen if the action is not approved. The packet should link to deeper evidence, but it should not demand an archaeological expedition for the ordinary case.

Competence means more than a generic course about AI. For the task at hand, the reviewer must understand the type of output, the known limitations that could matter, the way the workflow is meant to behave, and the signs that call for escalation. A person who can recognise a flawed supplier invoice may be well placed to review an invoice-related proposal. The same person may not be well placed to assess a model's language coverage or a data-protection implication. Assigning oversight is therefore also a staffing decision.

Institutional permission is the test many designs quietly fail. The reviewer must be able to refuse, pause or change the proposed route without being treated as the source of a system fault. They need access to a person or role that can decide what happens next. They need a way to record that the matter was escalated. And the system needs a safe state in which work can wait without being accidentally committed by a retry, a timeout or a different agent taking the original instruction as unfinished business.

Safety engineering has long treated human performance as part of the system, rather than a final layer of varnish. The UK Health and Safety Executive describes human factors as the task, the individual and the organisation together, and warns against considering them in isolation. That is a sensible frame for agent oversight. A reviewer is not an abstract human shaped plug for a software gap. They are doing a particular task, with particular information and tools, inside a particular organisation with particular pressures and limits. The quality of the control depends on all of it.

For that reason, a good human-in-the-loop design begins before the button appears. It defines which decisions need a human gate, who will hold the gate, what evidence they will receive, how much time the task allows, what happens when they are absent, and whether the gate has authority over the action itself or only over an explanation of the action. If the organisation cannot answer those questions on a quiet Tuesday, it will not become clearer when a high-consequence case arrives. Nor should it need an imaginary crisis to notice.

Uprawnienia powinny opisywać skutek działania, a nie tylko techniczny zasięg poświadczenia.

Jedno zadanie, kilka rodzajów uprawnień

Zwarty model uprawnień może ułatwić obsługę przepływu pracy agenta. Nie musi być rozbudowany. Zacznij od różnicy między czytaniem, proponowaniem, delegowaniem, zatwierdzaniem i zatrzymywaniem. Rola z uprawnieniem do czytania może przeglądać materiały niezbędne do zadania. Rola z uprawnieniem do proponowania może przygotować możliwe działanie. Rola z uprawnieniem do delegowania może przydzielić ograniczone zadanie innemu podmiotowi. Rola z uprawnieniem do zatwierdzania może nadać skuteczność działaniu o istotnych konsekwencjach. Rola z uprawnieniem do zatrzymywania może wstrzymać lub przerwać przebieg, gdy jego warunki przestają być spełnione.

To nie są po prostu szczeble hierarchii. Osoba przeprowadzająca kontrolę zgodności może mieć możliwość zatrzymania przepływu pracy, ale nie zatwierdzania skutków dla klienta. Wyspecjalizowany agent może proponować przebieg, ale nie delegować nowych zadań poza swoją dziedziną. Menedżer może odpowiadać za cel usługi, a mimo to nie być osobą upoważnioną do zwolnienia konkretnej płatności. Istotną cechą nie jest hierarchia sama w sobie. Chodzi o to, aby system mógł ocenić, czy dany podmiot ma odpowiednie uprawnienia do konkretnego działania w bieżącym kontekście.

Kontekst odgrywa dużą rolę. To samo proponowane działanie może być zwyczajne w jednej sytuacji, a brzemienne w skutkach w innej. Wysłanie już zatwierdzonego szablonu na znane wewnętrzne adresy może mieścić się w rutynowych uprawnieniach komunikacyjnych. Wysłanie nowo przygotowanej wiadomości z danymi osobowymi do nowego odbiorcy to już co innego. Zwrot w określonym progu może być delegowany do sprawdzonego procesu. Zmiana uprawnień, usunięcie danych lub zobowiązanie zewnętrzne może wymagać decyzji wskazanej osoby. Polityka powinna wyrażać tę różnicę, zanim model zostanie poproszony o planowanie wokół niej.

Istnieje też ważna różnica między potwierdzeniem a zatwierdzeniem. Potwierdzenie odnotowuje, że ktoś zobaczył wiadomość. Zatwierdzenie odnotowuje, że upoważniona osoba przyjęła określone działanie, z uwzględnieniem właściwego kontekstu, w określonym punkcie przebiegu. W systemie konwersacyjnym mogą one wyglądać podobnie. Zapisy nie powinny. Jeśli późniejszy recenzent nie może stwierdzić, jakie działanie zostało zatwierdzone i jaki skutek był oczekiwany, organizacja zarejestrowała rozmowę, a nie uchwyciła decyzję.

Samo delegowanie wymaga ograniczeń. Agent, który otrzyma zadanie porównania trzech istniejących propozycji, może mieć pozwolenie na poproszenie agenta badawczego o wyodrębnienie istotnych warunków. Nie powinien traktować tego uprawnienia jako zaproszenia do kontaktu z dostawcami, pozyskiwania nowych danych lub zmiany celu postępowania. Granicę można wyrazić w polityce, w zakresie narzędzi, w ustrukturyzowanej umowie zadaniowej lub we wszystkich trzech. Liczy się to, aby była na tyle egzekwowalna, by ograniczać przebieg, a nie tylko opisywać pożądane zachowanie po fakcie.

Głębokość delegowania to kolejne ograniczenie, które warto nazwać wprost. Człowiek może powierzyć zadanie jednemu agentowi i nadal zachować jasny obraz jego pierwszego przekazania. Po kilku zagnieżdżonych przekazaniach pierwotny cel może być technicznie obecny w metadanych, ale praktycznie niewidoczny. Organizacje mogą ustawić maksymalną głębokość delegowania dla danej klasy pracy, wymagać przeglądu na określonym poziomie lub zabronić delegatowi tworzenia kolejnych delegatów bez nowej zgody. To decyzje projektowe, a nie uniwersalne wymagania. Są najbardziej przydatne tam, gdzie dłuższy łańcuch utrudnia ustalenie, który uczestnik wprowadził nowe założenie lub zmienił faktyczny zakres.

Autorytet narzędzi musi być również oddzielony od autorytetu modelu. Model może wybrać narzędzie na podstawie planu. Integracja narzędzia powinna mimo to sprawdzić, czy żądana akcja, cel, kategoria danych, limit zasobów i stan przepływu pracy pozwalają na to wywołanie. To nie jest nieufność wobec modelu w sensie moralnym. To zwykłe projektowanie granic. Dobrze sformułowany plan może wciąż być nieodpowiedni dla bieżącego przypadku, a źle sformułowany plan nie powinien stać się rzeczywistością tylko dlatego, że dotarł do poświadczenia o szerokim dostępie.

To samo dotyczy odzyskiwania po błędzie. Ponowienie nie zawsze jest nieszkodliwe. Ponowienie żądania odczytu publicznego dokumentu różni się od ponowienia żądania wysyłającego wiadomość lub dokonującego opłaty. Gdy zadanie delegowane kończy się niepowodzeniem, przepływ pracy potrzebuje jednoznacznego wyboru między ponowieniem, przekierowaniem, eskalacją, wstrzymaniem i kontrolowanym zakończeniem niepowodzeniem. Traktowanie ich jako jednego generycznego modułu obsługi błędów to sposób, w jaki decyzja operacyjna jest po cichu podejmowana przez ustawienia domyślne. Środowisko uruchomieniowe agenta może udostępnić te opcje. Organizacja musi zdecydować, która opcja dotyczy której klasy działań.

Niepowodzenie to często brak decyzji

Gdy ludzie słyszą o niepowodzeniu, często wyobrażają sobie agenta generującego fałszywe stwierdzenie lub narzędzie przekraczające limit czasu. Oba przypadki mogą mieć znaczenie. Bardziej odkrywcze niepowodzenia w pracy delegowanej są często cichsze. Zadanie zostało przydzielone bez jasnego właściciela. Propozycja przekroczyła granicę, której nikt nie zamodelował. Recenzent widział wniosek, ale nie dowody. Ponowienie było kontynuowane po wstrzymaniu. Człowiek zauważył problem, ale nie miał uprawnień, aby zatrzymać działanie. Podjęto decyzję, ale zapis zachował tylko końcowy wynik, a nie warunek, który uczynił go akceptowalnym.

To nie są twierdzenia o konkretnym incydencie. To tryby niepowodzenia wynikające z samej struktury delegowania. Można je znaleźć także w procesach ludzkich. W oprogramowaniu mogą jednak działać z szybkością automatyzacji i być powtarzane bardzo konsekwentnie. Ta konsekwencja nie jest powodem do rozpaczy. Jest powodem, aby traktować projektowanie przepływów pracy jako część kontroli, zamiast zakładać, że testowanie dokładności jednego komponentu modelu rozstrzyga sprawę.

Rozważmy kolejny wyraźnie hipotetyczny projekt. Agent ma przygotować streszczenie sprawy. Deleguje ekstrakcję dokumentów do jednego komponentu, a normalizację języka do drugiego. Trzeci komponent widzi niekompletne pole i korzysta z podłączonego źródła wiedzy, aby uzupełnić lukę. Końcowe streszczenie czyta się płynnie. Jeśli przepływ pracy nie odnotował brakującego pola, źródła użytego do jego uzupełnienia, związanej z nim pewności lub niepewności oraz faktu, że pierwotne zadanie pozwalało tylko na streszczenie, recenzent nie może stwierdzić, czy zatwierdza streszczenie, czy nowo utworzone twierdzenie faktyczne. Problem nie polega na tym, że ostatnie zdanie brzmi dziwnie. Problem polega na tym, że znaczenie zadania zmieniło się w trakcie trasy.

A sound response is not to ban delegation. It is to put change points in the record. A new source, a new tool, a new data category, a new action class, a material change in confidence, a failed control, a longer-than-permitted delegation chain, or a proposal to cross an external boundary can each become a reason to surface the work for review. The exact triggers will differ by context. The principle is stable: a change that would matter to the accountable owner should not remain invisible because it occurred between components.

This is one place where safety-case thinking is useful. A safety case is not a promise that nothing can go wrong. It is a structured argument about why a system is acceptable for a defined purpose under defined conditions, with evidence, assumptions, controls and residual risks visible. Applied carefully to an agent workflow, that means the claim is not that agents are generally safe. The claim is narrower: this route may be used for this purpose, with these limits, because these controls and oversight arrangements exist, and it must be reconsidered when the stated assumptions no longer hold.

The workflow is then easier to challenge. An operator can ask whether the action class was properly assigned. A risk owner can ask whether the reviewer still has enough time. An engineer can ask whether a retry could create a duplicate effect. A data-protection specialist can ask whether the subtask remains necessary and proportionate. A person affected by an outcome can, where the applicable framework requires it, be given a route to question the decision. Those questions are not bureaucracy added after the interesting technical work. They are the work of making the technical system answerable in an organisation.

Metrics should follow the same discipline. Counting the number of delegated tasks tells us something about volume, not about accountable operation. More useful measures may include the rate at which a workflow escalates because a boundary changed, the time a decision waits at a gate, the proportion of consequential actions with a complete decision packet, the number of successful reversals, or the number of cases in which a policy check refused a tool call. Such measurements still need a definition and a context. They should never be invented for a brochure. But designing the records so they could be measured is a sign that accountability is being treated as an operating property.

The record is where responsibility survives

A multi-agent system produces an awkward kind of history. It has messages, tool calls, intermediate outputs, policy checks, model versions, timing information, retries, changed assignments and perhaps human approvals. Keeping every byte forever is neither necessary nor often appropriate. Keeping only the final answer is usually too little. The record needs to preserve the decisions and evidence that explain how the workflow crossed from a request to an outcome.

For a consequential action, that record should normally let a reviewer reconstruct a few basic facts. What was the objective? Which policy or mandate made the work permissible? Who or what received each assignment? What was proposed at each consequential gate? Which information was used to support the proposal? What limits, warnings or failures were encountered? Who held authority to approve, stop or reverse the action? What action became effective, and what happened afterwards? These are not exotic questions. They are the questions an organisation asks when it wants to know whether a decision was its decision.

The record should distinguish an operational fact from an explanation produced later. If a system says a reviewer approved an action, the event should record the identity or role of the reviewer, the action they were shown, the relevant context and the time at which the approval bound to that action. If the system says a model selected a delegate, the record should preserve the selection rule, candidates or criteria at the level appropriate for the use, and the resulting assignment. A later narrative can help a reader, but it should not replace the event that occurred.

Versioning matters here. An agent's output may be regenerated. A policy may be updated. A tool schema may change. A model endpoint may be swapped. If a decision depends on a particular version of a prompt, policy, model, knowledge source or integration, the record needs a stable reference to that version. Otherwise replay becomes a performance: it reproduces whatever the organisation happens to have now and calls the result an explanation of what happened then.

Reversibility deserves equal attention. The AI Act expressly refers, in the high-risk oversight context, to the ability to disregard, override or reverse an output and to interrupt a system so it comes to a halt in a safe state. In a multi-agent route, the safe state is not necessarily a stopped model process. It may mean no external communication is sent, a queued action is held, a downstream system is not updated, temporary credentials are no longer usable for the task, and the evidence needed to decide what happens next is retained. That is an operational inference from the oversight requirement, not a quotation of the law. It is also a useful design test.

Safe does not mean frozen forever. A halted workflow needs a controlled resumption path. Someone must decide whether to amend the task, discard the proposal, rerun a bounded part of the work, use a different tool, seek further evidence or abandon the route. A clean record makes that choice easier because it tells the next person what is known, what was attempted, why the work stopped and which effects have and have not occurred. Without that record, recovery becomes another unstructured delegation, usually undertaken under more pressure than the first one.

This is why retention and access need their own decisions. Not every actor should be able to read every trace. A record may contain personal data, commercially sensitive material or security-relevant details. But controlled access is not the same as no record. The Council of Europe Convention's emphasis on transparency, oversight, accountability and responsibility is a useful reminder that the boundary should be designed rather than assumed. An organisation can preserve an accountable route while limiting access to the detail that a particular reviewer genuinely needs.

What a delegation contract should make visible

A delegation contract can be a data structure, a workflow schema, a signed approval packet or a combination of these. Its form matters less than its content. It should tell the receiving actor what it is allowed to do, what it is not allowed to do and how the work will be judged. When these constraints are absent, agents tend to compensate with increasingly elaborate instructions. That may improve a particular run. It does not create an organisational boundary that a tool, reviewer or auditor can enforce.

Begin with the intended purpose. A purpose should be concrete enough to exclude nearby tasks. Compare the terms in the supplied proposals is different from find the best supplier. Summarise the received documents is different from establish the missing facts. Draft a reply for review is different from communicate a decision. The contrast can sound fussy until an agent uses a broad instruction to take a reasonable but unauthorised next step. Then it is the difference between useful initiative and an unbounded mandate.

Określ dozwolone i zabronione klasy działań. Agent może mieć uprawnienie do odczytu akt sprawy, wyodrębniania nazwanych pól, porównywania z polityką oraz przygotowania projektu. Może mieć zakaz zmiany rekordu źródłowego, kontaktowania się z podmiotem zewnętrznym, wybierania nowego źródła lub zatwierdzania transakcji. To nie są jedynie instrukcje w promptcie. Warstwa narzędzi i przepływu pracy powinna egzekwować te zasady tam, gdzie jest to praktyczne. Polityka, której nie można sprawdzić w momencie działania, wciąż jest przydatna jako wskazówka, ale jako mechanizm kontroli jest słabsza.

Wskaż właściciela i ścieżkę eskalacji. Właściciel niekoniecznie jest osobą, która kliknie „zatwierdź” przy każdej czynności. To rola odpowiedzialna za wynik oraz za decyzję o tym, co się dzieje, gdy ścieżka napotka pytanie bez rozstrzygnięcia. Ścieżka eskalacji wskazuje kolejny organ decyzyjny, gdy agent wykryje naruszenie granic, niewystarczające dowody, konflikt między źródłami, niezgodność z polityką lub warunek, którego system nie ma uprawnień rozstrzygnąć. Kolejka bez wskazanego właściciela decyzji to po prostu opóźnienie z optymistyczną etykietą.

Dołącz regułę dowodową. Reguła może określać, które źródła są wiążące, czy agent może szukać poza nimi, jak reprezentowana jest niepewność, co musi być zacytowane we wniosku oraz kiedy sprzeczne źródło wymaga przeglądu. Jest to szczególnie istotne w systemach generujących płynną prozę. Płynność może sprawić, że naruszenie granic będzie wyglądać jak użyteczne ukończenie zadania. Reguła dowodowa udostępnia właściwe pytanie: czy przepływ pracy pozostał w obrębie materiału, do którego korzystania był upoważniony?

Ustal limit czasu, zasobów i delegowania tam, gdzie ma to znaczenie. Zadanie, które może trwać w nieskończoność, może generować koszty, zator operacyjny lub presję na zatwierdzenie nieaktualnego wyniku. Zadanie, które może wielokrotnie delegować, może stworzyć łańcuch, którego żaden właściciel nie jest w stanie łatwo prześledzić. Projekt z limitami określa, jak długo zadanie pozostaje ważne, ile zasobów może zużyć, czy może tworzyć podzadania, jaka jest maksymalna dozwolona głębokość oraz co się dzieje po osiągnięciu limitu. Odpowiedzią może być automatyczne wstrzymanie, eskalacja lub kontrolowana awaria. Istotne jest to, że decyzja zapada przed przekroczeniem limitu.

Na koniec zdefiniuj warunek ukończenia. „Ukończone” nie zawsze oznacza, że agent wygenerował tekst. Może oznaczać, że recenzent otrzymał kompletny pakiet, bramka polityki zaakceptowała konkretne działanie, system niższego szczebla potwierdził odwracalną aktualizację lub odpowiedzialny właściciel zdecydował nie kontynuować. Warunki ukończenia utrzymują przepływ pracy w uczciwości. Zapobiegają traktowaniu przez agenta samego zaproponowania decyzji tak, jakby organizacja już ją podjęła.

Te wzorce są przydatne zarówno wtedy, gdy przepływ pracy zawiera pojedynczego agenta opartego na modelu, jak i większy zespół wyspecjalizowanych komponentów. Więcej agentów nie wymaga automatycznie więcej procesów. Wymaga natomiast, aby granice między rolami były wyrażone, a nie tylko domniemane. Koszt tego wyrażenia jest zwykle znacznie niższy niż koszt próby odtworzenia uprawnień po tym, jak kilka systemów wymieniło między sobą częściowe instrukcje i jeden z nich wszedł w kontakt ze światem zewnętrznym.

Delegowanie powinno zwiększać możliwości organizacji, a nie zmniejszać jej odpowiedzialność

Systemy agentowe są często opisywane tak, jakby ich wartość polegała na usuwaniu organizacji z pracy. Bardziej interesująca perspektywa jest odwrotna. Starannie zaprojektowany system może uczynić zobowiązania organizacyjne jaśniejszymi: zadanie ma właściciela, delegowanie ma granicę, działanie o istotnych skutkach ma organ decyzyjny, przegląd ma dowody, wstrzymanie ma bezpieczny stan, a zapis można odtworzyć. To nie jest przeszkoda dla użytecznej automatyzacji. To właśnie pozwala automatyzacji podejmować się wartościowej pracy bez wymagania od ludzi zaufania do niewidzialnego łańcucha.

Zbudowaliśmy Dweve Nexus wokół tego rozróżnienia. Jego lokalna dokumentacja produktu opisuje trwałe zadania, autorytet oceniany względem kontekstu wykonania przed działaniem, jawne struktury współpracy, w tym delegowanie, oraz zapis tworzony w miarę wykonywania pracy. To twierdzenie jest celowo skromne. Są to właściwości projektowe, które mają sprawić, że delegowana ścieżka będzie możliwa do zbadania. Nie są dowodem na to, że jakiekolwiek konkretne wdrożenie jest zgodne z prawem, bezpieczne lub odpowiednie, i nie usuwają potrzeby, aby organizacja sama zdecydowała o swoim celu, autorytecie i ludzkim nadzorze.

Szersza lekcja nie zależy od jednego produktu. Model może zdecydować, jak podzielić zadanie. Agent może poprosić innego agenta o pracę. Narzędzie może wykonać działanie. Organizacja nadal musi zdecydować, gdzie mieszka autorytet. Musi to zrobić przed rozpoczęciem delegowania, a nie po tym, jak końcowy wynik został dopracowany do czegoś, co trudno zakwestionować.

To jest odpowiedź na tytuł. Właściciel decyzji to nie agent, który akurat przemówił ostatni. To osoba lub rola, której organizacja przypisała autorytet do przyjęcia konsekwencji decyzji, z wystarczającą ilością informacji i władzy, aby ją odrzucić. Delegowanie jest użyteczne, gdy czyni tę osobę bardziej zdolną. Staje się niebezpieczne, gdy czyni ją niemożliwą do znalezienia.

Kto podejmuje decyzję, gdy agent deleguje zadania?