Kto jest odpowiedzialny za agenta AI w twojej firmie: sześć obowiązków i osoby, które je pełnią
Kto w twojej firmie posiada agenta AI? O tym, jak SR 26-2 traktuje agenty, sześć ról odpowiedzialnych, jak obsadzić je z istniejących zespołów oraz codzienne zarządzanie.
Źródła: Who Owns What When Your Company Deploys an AI Agent: Six Responsibilities, and Which Teams Hold Them
Sztuczna inteligencja agentowa to oprogramowanie, które samodzielnie wybiera sekwencję działań i korzysta z narzędzi, zamiast postępować według ustalonego skryptu. Gdy takie oprogramowanie działa wewnątrz firmy, pojawia się proste pytanie: kto za nie odpowiada?
Organy regulacyjne nie doszły do porozumienia w tej kwestii. W wspólnym piśmie o numerze SR 26-2 z dnia 17 kwietnia 2026 roku Federalna Rezerwa oraz Biuro Kontroli Waluty, które zastąpiło dokument SR 11-7 – który stanowił wytyczne dotyczące zarządzania ryzykiem modeli, według których działały banki od 2011 roku – wycofały własne komunikaty na ten temat pochodzące z 1997 roku. W przypisie do tego piśma stwierdzono, że sztuczna inteligencja generatywna i agentowa nie podlega tym wytycznym. Ponadto rola „właściciela modelu”, która była szczegółowo opisana w starym tekście, w nowym w ogóle nie występuje.
Pięć miesięcy wcześniej Singapur poszedł w przeciwnym kierunku. Proponowane przez Urząd Monetarny Singapuru wytyczne dotyczące zarządzania ryzykiem związanym z sztuczną inteligencją, których konsultacje zakończyły się w styczniu 2026 roku, a w momencie pisania tego tekstu nie istniała jeszcze ich ostateczna wersja, objęły agenty sztucznej inteligencji bezpośrednią aplikacją tych przepisów. W wytycznych ostrzega się, że agent posiadający dostęp do systemu może podejmować działania sprzeczne z celami biznesowymi lub interesami klientów, i proponuje się niezależną weryfikację, czyli przegląd dokonany przez osoby, które nie tworzyły systemu, zanim cokolwiek o wysokim stopniu ryzyka zostanie uruchomione. Ten tekst nie jest jeszcze prawem i obowiązywałby jedynie licencjonowane instytucje w jednej jurysdykcji.
Żaden z dokumentów nie określa, kto w firmie jest odpowiedzialny za agenta po jego uruchomieniu, a ta luka nie może czekać, aż regulator ją wypełni. Oprogramowanie, które podejmuje działania, wymaga wyraźnych granic, czyli linii oddzielającej to, co może robić samo, od tego, co wymaga interwencji człowieka. Egzekwowanie tych granic to kwestia techniczna. Decyzja o tym, kto za nimi stoi, ma charakter organizacyjny, a żaden tekst tego nie omawia. Poniższy tekst obejmuje wszystko, co agent może zrobić lub źle zrobić, i dla każdego przypadku wskazuje osobę, która musi za to odpowiedzieć. Omawia, kto daje zgodę, jak obsadzić role z istniejących zespołów, co wiąże się z obsługą agenta po jego uruchomieniu oraz co muszą się nauczyć twórcy. Źródłami informacji są teksty regulacyjne, badania opublikowane od 2024 roku oraz firmy, które powiązały swoje nazwy z konkretnymi twierdzeniami.
Sześć obowiązków, sześciu odpowiedzialnych
W procesie tworzenia produktu powstaje sześć zadań, a każde z nich wymaga jednego osoby odpowiedzialnej. Wyobraźmy sobie diagram zadań: osoba odpowiedzialna odpowiada za wynik, osoba wykonująca zadanie je realizuje, a osoba konsultowana dostarcza opinie, ale nie ma ostatecznego głosu.
- Biznes i dziedzina. Właściciel biznesu oraz eksperci w danej dziedzinie. Właściciel odpowiada za konkretny przypadek użycia, a jeden z ekspertów pełni jednocześnie rolę głównego odpowiedzialnego – osoby, która doskonale zna ten obszar i potrafi orzec, co jest poprawne.
- Produkt i architektura. Architekt, menedżer produktu oraz projektant interakcji.
Audyt wewnętrzny nie znajduje się na tej liście, ponieważ SR 26-2 stanowi, że zazwyczaj nie powtarza działań związanych z ryzykiem modeli. Kilka wymienionych poniżej firm (Kaiser Permanente, Thomson Reuters, Morgan Stanley) korzysta z narzędzi do tworzenia i wyszukiwania danych zamiast w pełni autonomicznych agentów, co czyni je najbliższymi dostępnymi publicznymi odpowiednikami.
Właściciel biznesu: zatwierdzanie tego, co agent może robić
To zatwierdzenie obejmuje zakres działania, progi finansowe oraz klientów, których agent nie może dotykać, z podziałem według poziomu ryzyka, zgodnie z propozycją Singapuru. Obejmuje ono również finansowanie systemu oraz jego ostateczne wycofanie. Banki mają częściowy precedens w powierzaniu tej roli podmiotom biznesowym. Zgodnie z SR 11-7, właściciel modelu znajdował się zazwyczaj w jednostce biznesowej, jak podano w podręczniku dla inspektorów OCC z 2021 roku, chociaż nie było to regułą powszechną, a rewizja z 2026 roku usunęła tę rolę bez podania niczego, co mogłoby ją zastąpić.
Argument praktyczny jest silniejszy od precedensu. Każda decyzja podejmowana w ramach tej aprobaty – czy to ustalenie progu, wykluczenie określonego segmentu klientów czy określenie daty wycofania – polega na kompromisie pomiędzy przychodami lub usługami a ryzykiem. Jedyną osobą, która może dokonać takiego kompromisu i być za niego odpowiedzialna, jest ta, która odpowiada za wynik końcowy. Osoba zajmująca to stanowisko potrzebuje zarówno budżetu, jak i możliwości zatrzymania procesu, a tylko właściciel firmy posiada obie te rzeczy: ryzyko może powstrzymać to, na co nie ma środków, natomiast inżynieria może stworzyć to, czego nie może zatrzymać. Przekazanie tego stanowiska osobie odpowiedzialnej za realizację projektu pozwoliłoby jej zatwierdzać własny zakres prac, natomiast przekazanie go osobie odpowiedzialnej za zarządzanie ryzykiem pozostawiłoby nikogo bez odpowiedzialności za aspekt korzyści. Sformułowanie w Singapurze wskazuje w tym samym kierunku, ponieważ definiuje szkodę w odniesieniu do celów biznesowych i interesów klientów, a tylko firma może określić, czym one są. Wytyczne z Hongkongu przekładają odpowiedzialność na zarząd.
Architekt: odpowiedzialny za projekt
Projekt powstaje w momencie, gdy agent przestaje działać, a interweniuje człowiek. Składa się on z procesu, którym kieruje się agent, punktów przekazania obowiązków osobie fizycznej oraz uprawnień, które zapobiegają dalszemu postępowaniu. Te dwa ostatnie elementy razem stanowią konkretnie określone granice działań. Dwie firmy umieściły punkty przekazania w tym samym miejscu. Lekarze Kaiser Permanente edytują wstępny projekt przygotowany przez Ambient-Scribe, zanim trafi on do dokumentacji medycznej, natomiast według oficjalnego oświadczenia firmy, narzędzie Debrief firmy Morgan Stanley umożliwia doradcy edycję podsumowania spotkania, zanim cokolwiek zostanie zapisane w bazie danych klientów. Inżynierowie lub dostawcy mogą stworzyć model uprawnień oraz interfejs. Mimo to architekt pozostaje decydentem, ponieważ ustalenie granic jest elementem projektu, który musi obowiązywać niezależnie od tego, kto pisze kod.
Odpowiedzialny za standardy: tworzenie kryteriów
Kryteria to lista kontrolna określająca, co powinno zawierać poprawna odpowiedź. W Thomson Reuters starsi prawnicy na poziomie partnerów poświęcili miesiące na opracowanie kryteriów dla aplikacji do wyszukiwania informacji. Podsumowując wyniki, stwierdzili, że dobra odpowiedź składa się z piętnastu niezbędnych elementów, natomiast ta wyglądająca wiarygodnie – z dziewięciu. Tylko prawnik potrafi odróżnić piętnaście od dziewięciu, co oznacza, że opracowanie kryteriów wymaga czasu eksperta w danej dziedzinie oraz jednego właściciela, ponieważ kryteria zmieniają się, gdy ocenia kilka osób. Badanie na temat weryfikacji narzędzi do weryfikacji modeli językowych AI wykazało, że kryteria ulegają zmianie po rozpoczęciu oceny, a badanie przeprowadzone przez Shreya Shankar i Aditya Parameswarana na grupie osób używających narzędzi do zapytań o dane doszło do tego samego wniosku, wskazując, że obowiązek weryfikacji spada na użytkownika.
Ustalanie standardu i jego mierzenie to dwa różne zadania. Mierzenie, czyli codzienny cykl ocen i analizy błędów, należy do inżynierów i naukowców danych. To oni tworzą narzędzie oceny, konstruują kod służący do wykonywania przypadków testowych przez agenta oraz oceny wyników, a także analizują występujące błędy. Następnie osoba odpowiedzialna za weryfikację sprawdza stopień pokrycia oraz kalibrację narzędzia oceny, bez konieczności ponownego uruchamiania testów zespołu deweloperskiego.
Operacje: utrzymanie funkcjonowania
Po uruchomieniu praca polega na monitorowaniu pokrycia, triażu alertów, wyłączaniu i przywracaniu systemu do pracy, ponownym wykonywaniu zestawu testów regresji (przypadków testowych uruchamianych po każdej zmianie) oraz obserwowaniu poziomu wykorzystania zasobów i kosztów. Ktoś z działu biznesowego uczestniczy w rotacji osób pełniących dyżury, ponieważ niektóre alerty dotyczą decyzji biznesowych. Planowanie, klasyfikacja powagi problemów oraz procedury eskalacji należą do osoby odpowiedzialnej za operacje, która jest inżynierem.
Walidator: sprawdzanie przed uruchomieniem
Przegląd przeprowadzany przez walidator składa się z trzech części. Sprawdza on możliwość wstrzyknięcia kodu (złowrogich instrukcji umieszczonych w materiałach, które czyta agent) oraz nieuprawnione wywołania narzędzi. Analizuje również dane osobowe, które trafiają do zapisu działań agenta, czyli logu jego krok po kroku. Ponadto monitoruje osoby, które zatwierdzają działania agenta.
Menedżer dostawcy: zarządzanie umową
Miejsce to pojawia się tylko wtedy, gdy firma dokonuje zakupu. Wtedy dostawca buduje część systemu, uruchamia jej funkcjonowanie i tworzy dowody, które musi przeanalizować weryfikator, przy czym odpowiedzialność pozostaje tam, gdzie była. Tymczasem wszyscy pozostali właściciele polegają na czymś, co może zapewnić jedynie kontrakt. Weryfikator potrzebuje uprawnień do audytu. Operacje wymagają wcześniejszego powiadomienia o zmianach w modelu, ponieważ to one uruchamiają testy regresji. Właściciel standardu potrzebuje sposobu na eksport śladów i danych, w przeciwnym razie ocena firmy nie ma na czym się oprzeć. Właściciel biznesu potrzebuje warunków wyjścia, w przeciwnym razie wyłączenie systemu staje się negocjacją zamiast decyzją. Menedżer dostawcy zapewnia te cztery elementy, nie wykonywając żadnej z czterech zadań. Dział zakupów jest konsultowany w kwestiach zakresu i akceptacji, ale nie ponosi odpowiedzialności za żadną z nich.
Trzy z sześciu zadań – określenie przypadku użycia, decydowanie o tym, co stanowi poprawną odpowiedź, oraz niezależna weryfikacja wyników – to rzeczy, których zespół implementacyjny dostawcy sam nie może wykonać. Przypisanie odpowiedzialnego za każde z tych zadań to element, którego brakuje w tekstach regulacyjnych.
Obsadzanie stanowisk z obecnych zespołów
Osoby pełniące te role są wybierane spośród obecnych pracowników, a kolejność ma znaczenie, ponieważ każde stanowisko opiera się na poprzednim.
Należy zacząć od właściciela biznesu; dopóki taki nie istnieje, projekt musi czekać. Ta osoba kontroluje budżet, procesy oraz ma uprawnienia do wyłączania systemu, a pierwszym krokiem jest przypisanie poziomu ryzyka oraz zatwierdzenie uprawnień agenta. Talenty inżynieryjne nie mogą zastąpić tej osoby, ponieważ nikt inny nie może ponosić odpowiedzialności za jej decyzje.
Następnie architekt. W idealnym wariancie jest to osoba, która doskonale zna proces biznesowy oraz system, dzięki czemu może określić, gdzie kończy się rola agenta, a zaczyna rola człowieka. Tam, gdzie taka osoba istnieje, to ona zajmuje to stanowisko. Gdy nikt nie nadaje się na tę rolę, praca może zostać rozpoczęta przez osobę z zewnątrz, chociaż firma musi nadal wskazać wewnętrznego odbiorcę, ponieważ stanowisko nie może pozostać nieobsadzone, nawet jeśli praca odbywa się gdzie indziej.
Na trzecim miejscu znajduje się standardowy właściciel, a decydującym czynnikiem jest to, czy ekspert od danej dziedziny ma rzeczywiście wolny czas do poświęcenia. Jeśli czas jest zabezpieczony, ekspert opracowuje kryteria oceny, tak jak zrobili to prawnicy Thomson Reuters. W przeciwnym razie specjaliści od produktu i projektowania przygotowują je do podpisu eksperta, w wyniku czego standardy ulegają dewiacjom, ponieważ to nie ci, którzy wiedzą, jak powinna wyglądać dobra odpowiedź, są tymi, którzy ją spisują. W swoim liście do akcjonariuszy Jamie Dimon formułuje ogólną zasadę: praca stanowiąca niewielką część obowiązków wielu osób nigdy nie zostaje ukończona, a realizacja misji wymaga zespołu poświęcającego jej się w pełnym wymiarze czasu.
Kalibracja sędziego oraz monitorowanie odchyleń w tym aspekcie pomiarowym powinny trafić do zespołu ds. danych lub analityki, jeśli firma taki zespół posiada. W przeciwnym razie wyznaczony członek zespołu rozwoju musi przeznaczyć na to specjalne godziny pracy. Przykłady pokazują, jak to zmienia rolę zespołu ds. nauki o danych, gdy model agenta jest dostarczany przez dostawcę. Modelowanie i dopracowywanie przypada na dostawcę, więc nie można już zakładać, że to zespół ds. sztucznej inteligencji zajmuje się tymi zadaniami. Pozostają kalibracja i monitorowanie odchyleń jako stałe funkcje, a także nowe obowiązki związane z modelami kredytowymi, przeciwdziałania oszustwom, ustalania cen i prognozowania, które zespół nadal tworzy: konieczność określenia docelowej grupy użytkowników dla każdego modelu przed tym, jak agent będzie mógł go wykorzystywać jako narzędzie. Ubezpieczyciele i szpitale prawdopodobnie borykają się z tym samym pytaniem dotyczącym własnych modeli, ale żaden z przeanalizowanych tutaj źródeł nie porusza tego tematu.
Czwartym elementem jest walidator, a decydującym czynnikiem jest moment, w którym wchodzi w grę zgodność z regulacjami. Zgodność z regulacjami może dostarczyć definicje ryzyka od samego początku, co, jak podaje się, robi zespół ds. zgodności w Chime, albo może być sprawdzana jedynie przy wdrożeniu – w takim przypadku scenariusz o wysokim ryzyku nadal wymaga niezależnej weryfikacji przed uruchomieniem, zgodnie z wymogami projektu przepisów singapurskich. Dla banku najprostszą drogą wydaje się funkcja zarządzania ryzykiem modeli, ponieważ SR 26-2 nie obejmuje agentów i pozostawia decyzję każdej instytucji. Jednak żadne źródło z 2024 roku i późniejszych nie donosi o banku, który podjąłby takie kroki.
Piątym elementem są operacje, a decydującym czynnikiem jest to, kto monitoruje system po jego uruchomieniu. W następnej sekcji omówiono to zagadnienie.
Dwa elementy są wspólne dla wszystkich przypadków użycia. Po pierwsze, brama – jedyna ścieżka, której używa każdy agent, aby dotrzeć do modelu, gdzie weryfikowana jest tożsamość i rejestrowane są połączenia; jest ona kontrolowana przez osobę odpowiedzialną za operacje. Wealthsimple podaje, że około 80 procent ruchu związanych z LLM przechodzi przez tę bramę, co pozostawia otwarte pytanie, czy reszta jest również regulowana. Po drugie, pomiary – czyli narzędzia do ich przeprowadzania i osoba oceniająca, które są wspólnie zarządzane przez dział nauk danych lub analityki, ponieważ dwa zespoły oceniające się za pomocą dwóch różnych narzędzi uzyskują wartości, których nie da się porównać. Pozostałe elementy, mianowicie przypadek użycia, jego kryteria oceny, osoba odpowiedzialna za standardy oraz jego miejsce w kolejności realizacji, pozostają w gestii jednostki biznesowej, która go obsługuje.
Przeważnie te role polegają na rozszerzaniu istniejących zadań, a nie na tworzeniu nowych. Właściciel biznesu, który już odpowiada za wyniki finansowe, dodaje zatwierdzenie zakresu prac. Ekspert w danej dziedzinie dodaje elementy do wiedzy, którą już posiada. Inżynier przejmuje funkcje sędziego i konstruktora. Nauka o danych, która już monitoruje swoje modele pod kątem degradacji, rozszerza ten nadzór na agenta. Procedury zgodności łączą definicje ryzyka z już istniejącymi procesami sprawdzania. Nie zakłada się zatrudniania nowych osób. Tylko rola weryfikatora nie może być rozszerzana, ponieważ to zadanie kończy się w momencie rozpoczęcia budowy.
Kierowanie agentem na co dzień
Po uruchomieniu przez cały okres życia systemu realizowane są sześć zadań. Odpowiedzialny za operacje przejmuje cztery z nich, osoba odpowiedzialna za standardy – jedno, a weryfikator – jedno; każda z tych ról wymaga wyznaczonej osoby oraz określonego czasu reakcji.
Sortowanie alertów trafia do działu operacyjnego, przy czym w rotacji bierze udział osoba odpowiedzialna za zarządzanie biznesem. Alerty nie są jednolite: błąd uprawnień, przerwa w działaniu oraz błędnie odrzucona zgłoszenie wymagają różnego podejścia, a w przypadku ostatniego chodzi o decyzję biznesową. Zarówno projekt Singapuru, jak i akt AI UE wymagają takiego procesu eskalacji.
Zamknięcie systemu jest zatwierdzane przez właściciela firmy i realizowane przez dział operacyjny w czterech etapach: natychmiastowe zatrzymanie, przywrócenie techniczne, korekta działania firmy oraz udzielenie zgody na ponowne uruchomienie. Ustawa UE w sprawie sztucznej inteligencji stanowi, że osoba odpowiedzialna za nadzór nad systemem o wysokim ryzyku musi mieć możliwość jego zatrzymania za pomocą przycisku lub podobnej procedury, która zapewni bezpieczny stan systemu. Osoba, która tworzy przycisk, to nie ta, która decyduje o jego naciśnięciu. Zamknięcie okna czatu nie anuluje płatności ani powiadomienia, które już są w kolejce, a korekta działania firmy nie ma odpowiednika w postaci cofnięcia kodu. Dlatego decyzja o zatrzymaniu jest sprawą biznesową, natomiast jej realizacja to zadanie działu operacyjnego.
Testy regresji po zmianie modelu to wspólny wysiłek dziedzin nauki o danych, inżynierii oraz działu biznesu, przy czym wypuszczenie produktu wymaga zatwierdzenia przez osobę odpowiedzialną za weryfikację. Dokumentowanym przykładem jest Morgan Stanley’s Assistant: funkcjonuje on na modelach OpenAI, jednak bank stworzył własną ramę oceny. Doradcy oraz specjaliści od promptów codziennie razem oceniają zestaw testów regresji, a dostawca nie udostępnia ani kryteriów oceny, ani podstawowych zasad, na których się one opierają. Źródłem tego rozwiązania jest OpenAI, które czerpie korzyści z prezentacji takiego klienta, a chodzi tu o aplikację do wyszukiwania informacji. Proces rozpoczyna się od powiadomienia o zmianie od dostawcy, które musi uzyskać menedżer ds. dostawców.
Użycie i koszt należą do działu operacyjnego, a właściwą jednostką jest zakończona zadanie. Próby ponowne, ocena oraz praca korygująca należą wszystkie do danego zadania, a jedna wywołanie modelu to zaledwie jego część, dlatego podawanie cen za pojedyncze wywołanie pokazuje tylko fragment całej historii kosztów.
Zwracanie niepowodzeń produkcji do procesu oceny to ciągłe obowiązki osoby odpowiedzialnej za standardy. W wykładzie opublikowanym ponownie przez Arize, firmę, która ma wśród swoich klientów Ubera, projektant rozmów Ubera stwierdził, że narzędzie oceny oraz związany z nim zbiór danych są aktualizowane co tydzień, ponieważ dane pochodzące z przestarzałego zbioru są gorsze niż żadne. To projektant wykonywa pracę, która według powyższych rol powinna być przypisana inżynierom i naukowcom danych. Podobno sygnały dotyczące zgodności od Chime trafiają do narzędzia oceny w ciągu godzin, poprzez offline analizę przeprowadzaną później.
Obserwowanie osób dokonujących zatwierdzeń to ciągła praca walidatora. Anthropic donosi, że około 93 procent prośb o uprawnienia dla jego agenta programistycznego jest akceptowanych, co stanowi wysoki wskaźnik wskazujący na jedynie formalne zatwierdzenie bez rzeczywistej weryfikacji. Ponieważ chodzi o agenta programistycznego, a nie zajmującego się procesami biznesowymi, ilustruje to ryzyko, choć nie podaje jego kwantyfikacji. Profil sztucznej inteligencji generatywnej opracowany przez NIST, który jest dobrowolny, zaleca rejestrowanie każdego przypadku, gdy osoba przejmuje kontrolę nad wynikiem systemu – to ta sama weryfikacja widziana z drugiej strony.
Te obowiązki nigdy się nie kończą, a żaden publiczny raport nie podaje liczby godzin, jakie pochłania każdy z nich. Rotację, testy regresji oraz śledzenie kosztów można zlecić z zewnątrz, co jest tematem do dalszej dyskusji.
Co zespół musi się nauczyć i jak wysokie są wymagania
Szkolenie rodzi trzy pytania: co każdy w zespole musi umieć robić, gdzie specjalista jest nadal konieczny oraz jaki poziom jakości jest wystarczający.
Cztery umiejętności są potrzebne wszystkim, niezależnie od tytułu stanowiska:
- obserwowanie śladów i wyników oceny na własne oczy, bez polegania na podsumowaniu kogoś innego
- rozumowanie na podstawie rozkładów wyników, a nie pojedynczych przykładów
- ocenianie pracy na podstawie końcowego stanu, jaki pozostawiła, a nie na podstawie tego, co agent twierdzi, że zrobił
- formułowanie zadania w sposób wystarczająco jasny, aby je delegować, a następnie nadzorowanie wyniku
Marco Argenti, dyrektor ds. informacji w Goldman Sachs, wskazuje właśnie tę ostatnią sekwencję. Jego zdaniem liderzy muszą opanować trzy umiejętności menedżerskie: opisywanie zadania, delegowanie go agentowi AI oraz nadzorowanie wyników.
Połowa pracy związanej z oceną nadal wymaga specjalisty. Cykl ocen i analizy błędów, codzienna praca polegająca na ocenianiu wyników i wyśledzaniu przyczyn awarii, dzieli się na część rutynową i część sporadyczną. Część rutynowa obejmuje pisanie kodu służącego do oceny, konfigurację niezbędnych narzędzi oraz analizę błędów z każdego dnia. Wymaga ona umiejętności inżynierskich oraz znajomości statystyki, a pracodawcy coraz częściej łączą je pod jednym tytułem – inżynier AI. Mapa umiejętności DeepLearning.AI opisuje tę rolę na podstawie ogłoszeń i wywiadów, chociaż jej wydawca sprzedaje właśnie te kursy, których wymagają te ogłoszenia. Część sporadyczna polega na kalibracji narzędzi oceny w porównaniu z ludzkimi ocenami oraz ocenie tendencji zmian, co lepiej pasuje do specjalisty od danych i jest potrzebne głównie podczas przeglądów. Przedsiębiorstwo niezwiązane z technologią rozsądnie szkoliłoby inżynierów oprogramowania do pracy jako inżynierowie AI, zachowując jednocześnie dziedzinę nauki o danych do kalibracji oraz do wspierania procesu oceny przez weryfikatorów. Żadne badanie nie porównuje tych dwóch podejść, a raport Skills Map przedstawia jedynie to, czego wymagają pracodawcy.
Bariera ma na celu wykrycie tego rodzaju awarii, których narzędzia stale nie potrafią dostrzec, a ta odpowiedzialność spoczywa na właścicielu standardu oraz walidatorze. W badaniu z 2026 roku Antaripa Saha i Hamel Husain, którzy prowadzą płatny kurs oceniania, przetestowali sześć zautomatyzowanych systemów przeglądania na 100 śladach z produkcji zawierających 39 ręcznie oznaczonych awarii. Najlepszy system odnalazł 87 procent oznaczonych awarii, a te, których nie wykryto, były systematyczne – jedna kategoria awarii umykała wszystkim systemom. Wszystkie one wskazywały również na awarie, których nie zauważył człowiek dokonujący oceny, więc wyniki nie stanowią rankingu, a dane to pojedynczy zbiór danych z oznaczeniami jednego eksperta. Badanie pokazuje jednak, gdzie nadal są potrzebni ludzie: właściciel standardu, którego kryteria określają, co stanowi awarię, oraz walidator, którego sprawdzanie zakresu szuka dokładnie tego, czego nie potrafią narzędzia.
Ta umiejętność rozwija się poprzez pokazywanie ludziom błędów oraz jest utrzymywana dzięki regularnym przeglądom. Husain i Shankar, którzy deklarują takie samo zainteresowanie płatnymi kursami, dzielą ocenianie pomiędzy inżynierami a menedżerami produktów. Inżynierowie wykrywają problemy techniczne, takie jak błędy przy pobieraniu danych czy usterki narzędzi, natomiast menedżerowie produktów identyfikują błędy produktu, na przykład oczekiwania użytkowników, które nie zostały spełnione. Jedna osoba podejmująca decyzje zajmuje się codziennym ocenianiem, co stanowi różną rolę w porównaniu z niezależnym przeglądem przez osoby sprawdzające. Aby uzyskać zgodę, zalecają unikanie prezentowania ocen i sugerują pokazywanie kolegom tego, co wychodzi podczas analizy danych. Projekt z Singapuru dodaje drugi element: sama ta umiejętność musi być okresowo ponownie oceniana.
Co te dowody mogą, a czego nie mogą potwierdzić
Każdy fragment tekstu regulacyjnego oraz każdy opisany przypadek ma swoje własne źródło, ale istotne są również ograniczenia. Regulacje określają wymagania, a SR 26-2 wyklucza sztuczną inteligencję działającą jako agent spoza zakresu obowiązywania tych regulacji. Badania opierają się na użytkownikach wyszukujących dane, na 39 niepowodzeniach w jednym zestawie danych oraz na małej próbie jakościowej. Assistant firmy Kaiser, Thomson Reuters oraz Morgan Stanley to narzędzia do wyszukiwania lub tworzenia tekstu, a nie wieloetapowi agenci działający samodzielnie. Żadna firma spoza sektora technologicznego nie opublikowała listy swoich zespołów agentów, a wymienione firmy to te, które zdecydowały się to zrobić, więc ciche niepowodzenia projektów nie znajdują się w próbie badawczej. Większość takich firm nie będzie się zastanawiać nad zakupem platformy dla agentów; wybiorą jednego z głównych dostawców chmury i przejdą dalej. Trudniejszym wyborem jest pomoc z zewnątrz – czy to konsulting, wzmocnienie zespołu, czy inżynier działający na miejscu – oraz to, co pozostanie po zakończeniu współpracy. Wszystkie sześć stanowisk pozostaje wewnętrznych, a to, co można kupić, to jedynie realizacja zadań.
Rezerwa Federalna usunęła nazwisko właściciela modelu ze swoich wytycznych w kwietniu, a Singapur pięć miesięcy wcześniej zaproponował, aby agenta mającego dostęp do systemu sprawdzali osoby spoza zespołu twórczego. Żaden z tych dokumentów nie wskazuje, kto w firmie jest odpowiedzialny za tego agenta. Firma potrzebuje sześciu określonych właścicieli, począwszy od właściciela biznesu, który zatwierdza, co agent może robić, pokrywa koszty i może to zatrzymać. Organizacje regulacyjne już nie opisują tej roli, ale nie można jej pozostawić pustą, ponieważ to zatwierdzenie określa zakres pracy wszystkich innych. Ostrzeżenie Marco Argentiego jest aktualne: delegowanie zadań agentowi bez możliwości nadzoru prowadzi do katastrofy, dlatego ludzie potrzebują nowego podejścia do kontroli jakości i odpowiedzialności.
Literatura pokrewna
- Twoja gra faktorów należy do YAML: Kompilowanie 17-agentowego LangGraph podczas uruchamiania — Jak mały silnik w czasie rzeczywistym kompiluje jeden plik YAML do struktury LangGraph StateGraph: generowanie stanu, pluginy importlib, routery etykiet, adaptacyjne wywołania oraz zmiany węzłów w zależności od sesji.
- Gemini Spark wyjaśnione: zadania, umiejętności, harmonogramy, bezpieczeństwo i ceny — Co robi agent Gemini Spark dostępny cały czas od Google w Gmail, Kalendarzu i Docs, jak działają jego warstwy bezpieczeństwa, ile kosztuje, gdzie jest zablokowany i kto powinien go przyjąć.