Ograniczenia dla agentów AI w JPMorgan ujawniają lukę w autoryzacji w bankowości

Ograniczenia dla agentów AI w JPMorgan uwypuklają konflikt w bankowości: klienci chcą, aby oprogramowanie działało w ich imieniu, podczas gdy banki potrzebują dowodu jego uprawnień. BankInfoSecurity podał 30 października, że instytucje finansowe blokują nieautoryzowanych agentów lub ograniczają ich dostęp do przeglądania informacji. Agent AI, czyli oprogramowanie wybierające i realizujące działania prowadzące do celu, rodzi pytania, których nie rozstrzyga udane logowanie.

Bezpośredni spór dotyczy zgody. Klient może chcieć dopuścić asystenta do konta, ale bank może zakazywać takiej metody dostępu. Nawet gdy wszyscy rozpoznają oprogramowanie, nadal muszą uzgodnić, do których działań klient je upoważnił. Odczytywanie transakcji, zmiana ustawień konta i transfer środków wymagają odmiennych decyzji.

Microsoft i Visa opracowują podejścia do tożsamości agentów, a National Institute of Standards and Technology analizuje praktyki wdrożeniowe. Ich prace dostarczają użytecznego kontekstu, lecz nie dowodzą, że banki rozwiązały problem delegowania uprawnień przez konsumentów. Kluczowy kompromis nadal dotyczy dostępu i rozliczalności: użyteczna automatyzacja potrzebuje swobody działania, ale instytucje finansowe potrzebują egzekwowalnych granic dla jej działań.

Co faktycznie ustanawiają ograniczenia dla agentów AI w JPMorgan

Zgłaszane ograniczenia dotyczą warunków dostępu, a nie odrzucenia każdego zastosowania AI w bankowości.

Relacja BankInfoSecurity wskazuje JPMorgan, Morgan Stanley, Bank of America i Wells Fargo jako instytucje mierzące się z dostępem nieautoryzowanych agentów. Opisuje ograniczenia oraz alternatywy w trybie tylko do odczytu, czyli dostęp pozwalający przeglądać informacje bez ich zmieniania. Ograniczenia dostępu bankowego opisują zatem zakres reakcji, a nie jednolity zakaz.

To rozróżnienie zmienia sposób, w jaki czytelnicy powinni interpretować nagłówek. Ograniczenie dotyczące zewnętrznego asystenta nie dowodzi, że bank przestał rozwijać automatyzację wewnętrzną. Nie pokazuje też, że każde połączenie z udziałem oprogramowania narusza zasady instytucji.

Istotna granica przebiega między uznanym dostępem a aktywnością docierającą przez niewspieraną ścieżkę. Agent może z powodzeniem uzyskać dostęp do konta, nie mając jednak relacji akceptowanej przez bank. Możliwość techniczna i zgoda instytucjonalna pozostają odrębnymi kwestiami.

Publicznie dostępne informacje zawierają też ważne zastrzeżenie. Morgan Stanley powiedział Axios, że nie zaobserwował „nieuczciwych agentów AI uzyskujących dostęp do naszych platform”, co łagodzi interpretacje zgłaszanego nieautoryzowanego dostępu do kont.

Czytelnicy powinni zatem powstrzymać się przed przedstawianiem tej historii jako potwierdzonego przypadku autonomicznego nadużycia finansowego. Ograniczenia pokazują obawy i reakcję na ryzyko. Same w sobie nie dowodzą strat, oszukańczych transferów ani wspólnej awarii technicznej w wymienionych instytucjach.

Relacja pozostawia także nierozstrzygnięte szczegóły polityki. Nie zawiera pełnego, porównywalnego zestawienia zatwierdzonych agentów, zablokowanych funkcji, dat egzekwowania zasad ani wyjątków dla każdej instytucji. Te braki mają znaczenie dla każdego, kto próbuje ustalić, czy konkretny produkt nadal może być używany.

Dla nabywców korporacyjnych ta niepewność komplikuje obietnice dotyczące automatyzacji finansów. Demonstracja może pokazać asystenta poruszającego się po stronie internetowej. Nie może jednak potwierdzić, że operator strony zezwala na dalszy dostęp lub akceptuje interpretację instrukcji klienta przez asystenta.

Dla konsumentów to rozróżnienie jest równie praktyczne. Poproszenie asystenta o uporządkowanie informacji finansowych różni się od udzielenia mu uprawnień do zmiany ustaleń finansowych. Produkty, które zacierają granice między tymi uprawnieniami, pozostawiają klientów w niepewności co do tego, na co faktycznie wyrazili zgodę.

Dlatego ograniczenia dla agentów AI w JPMorgan zasługują na uwagę wykraczającą poza zablokowane logowanie. Spór ujawnia brakujące porozumienie między klientem, operatorem agenta a instytucją prowadzącą konto. Każdy uczestnik potrzebuje spójnego rozumienia tego, co oprogramowanie może zrobić.

Skuteczne połączenie musi odpowiedzieć na to pytanie przed wykonaniem działania o istotnych konsekwencjach. W przeciwnym razie bank otrzymuje rejestr aktywności pokazujący dostęp, który niekoniecznie wyjaśnia uprawnienie stojące za nim.

Klienci chcą pomocy; banki potrzebują działań możliwych do przypisania

Presja spada na instytucje, które muszą odróżnić cel klienta od kroków wybranych przez oprogramowanie.

Rozważmy hipotetycznego klienta proszącego asystenta o przygotowanie miesięcznego podsumowania finansowego. Prośba wydaje się wąska, ale oprogramowanie nadal musi zdecydować, które konta i dokumenty sprawdzić. Musi też zdecydować, gdzie umieścić wynikowe podsumowanie.

Wyobraźmy sobie teraz, że ten sam klient prosi o poprawę swojej pozycji gotówkowej. Instrukcja wyraża cel, nie określając akceptowalnych działań. Sugestia, transfer i zmiana płatności cyklicznych stanowią istotnie różne interpretacje.

Te przykłady ilustrują problem autoryzacji; nie opisują zweryfikowanych zdarzeń w wymienionych bankach. Ich znaczenie wynika z różnicy między konwersacyjną prośbą a egzekwowalnym uprawnieniem. System finansowy potrzebuje tego drugiego.

Autoryzacja oznacza określenie, które działania zidentyfikowany podmiot może wykonywać. Uwierzytelnianie, czyli weryfikowanie, kto lub co żąda dostępu, odpowiada na inne pytanie. Bank może rozpoznać podmiot, jednocześnie odrzucając konkretne żądanie.

To rozdzielenie wywiera presję na twórców agentów. Asystent zaprojektowany wokół szerokich celów konwersacyjnych musi przełożyć je na ograniczone, możliwe do sprawdzenia operacje. Jego wyjaśnienie intencji nie może zastąpić kontroli uprawnień instytucji.

Wywiera też presję na zespoły produktowe banków. Całkowite ograniczenie zapewnia jasną granicę, ale pozostawia klientów bez zatwierdzonej ścieżki dla skądinąd akceptowalnej pomocy. Zatwierdzona ścieżka wymaga decyzji dotyczących dostępu do informacji, zmian, nadzoru i wycofania zgody.

Wyzwanie obejmuje również obsługę klienta. Jeśli asystent wykona niepożądaną operację, instytucja potrzebuje użytecznego opisu tego, co się stało. Transkrypcja wskazująca, że klient chciał pomocy, niekoniecznie rozstrzyga spór dotyczący konkretnego działania.

Odpowiedni zapis rozróżniałby prośbę klienta, przyznane uprawnienia i operację, którą oprogramowanie próbowało wykonać. Pokazywałby również, czy instytucja zatwierdziła tę operację. Są to proponowane kryteria rozliczalności, a nie możliwości potwierdzone we wszystkich bankach opisanych w tej historii.

Napięcie ekonomiczne wynika bezpośrednio z tego problemu. Asystent staje się bardziej użyteczny, gdy może wykonywać pracę między usługami. Każda usługa odpowiada za decyzję, które żądania zaakceptuje, zgodnie z własnymi kontrolami.

Taki układ osłabia założenie, że bardziej zdolny model automatycznie tworzy bardziej zdolny produkt finansowy. Dostęp zależy od gotowości instytucji do uznania połączenia. Samo lepsze rozumowanie nie może zapewnić takiego uznania.

Praca z wiedzą stanowi użyteczne porównanie. Osobista baza wiedzy dotyczy gromadzenia i odzyskiwania informacji, podczas gdy uprawnienia do transakcji wprowadzają dodatkową granicę dostępu. Opisy produktów powinny jasno wskazywać, jaki rodzaj pomocy oferują.

Dla nabywców to rozróżnienie powinno pojawić się na początku oceny. Kluczowe pytanie brzmi, które zatwierdzone operacje produkt może wykonywać w rzeczywistych warunkach konta. Przekonująca demonstracja powinna uwidaczniać te granice.

Produkty tożsamościowe rozwiązują różne części problemu

Infrastruktura tożsamości agentów dostarcza elementów składowych, lecz różne produkty regulują różne relacje.

Microsoft opisuje Entra Agent ID jako strukturę do tworzenia, zarządzania i nadzorowania tożsamości agentów. Dokumentacja opisuje szablony tożsamości, kontrole dostępu i rejestry aktywności. Microsoft twierdzi też, że platforma obsługuje agentów tworzonych poza własną rodziną produktów.

Takie podejście rozwiązuje problem zarządzania w przedsiębiorstwie: nadaje oprogramowaniu rozpoznawalną tożsamość w systemach organizacji. Zapewnia sposób traktowania agentów jako zarządzanych podmiotów. Nie przesądza jednak, że zewnętrzny bank zaakceptuje agenta przedsiębiorstwa.

Trusted Agent Protocol firmy Visa dotyczy innej relacji — między zatwierdzonymi agentami a sprzedawcami. Visa opisuje podpisane żądania, które sprzedawcy mogą weryfikować, z dodatkowymi rozwiązaniami dotyczącymi rozpoznawania konsumenta i płatności. Podpis cyfrowy zapewnia kryptograficzny dowód pochodzenia i integralności wiadomości.

To rozróżnienie jest istotne, ponieważ dostęp do zakupów i dostęp do bankowości wiążą się z odmiennymi decyzjami. Rozpoznanie zatwierdzonego agenta zakupowego nie upoważnia automatycznie do obsługi konta lub transferu środków w innym miejscu. Każda usługa odbierająca nadal potrzebuje zasad odpowiednich dla własnych operacji.

Podejść tych nie należy traktować jako wymiennych rozwiązań konkurujących według identycznej listy kontrolnej. Microsoft kładzie nacisk na zarządzanie tożsamością w przedsiębiorstwie. Visa podkreśla rozpoznawalne żądania agentów w handlu. Ich znaczenie zależy od tego, gdzie proponowany przepływ pracy przekracza granicę organizacyjną.

W kontekście ograniczeń dla agentów AI w JPMorgan praktyczne pytanie brzmi, czy zewnętrzny asystent może przedstawić uprawnienie uznawane przez instytucję. Tożsamość agenta w platformie innej firmy sama w sobie nie wystarcza. Bank musi rozumieć, co ta tożsamość oznacza.

Hipotetyczny asystent ilustruje tę lukę. Jego pracodawca może go rozpoznawać, rejestrować jego aktywność i ograniczać jego dostęp do wewnętrznych dokumentów. Kontrole te nie mówią bankowi, które konto klienta reprezentuje.

Nawet uznana relacja z klientem pozostawia kolejne pytania. Instytucja musi ustalić, które operacje są dozwolone i czy uprawnienie nadal obowiązuje. Potrzebuje też procedury na wypadek wycofania tego uprawnienia przez klienta.

Tworzy to problem koordynacji dla konkurujących dostawców technologii. Produkt może dobrze zarządzać własnymi tożsamościami, a jednocześnie pozostawać trudny do oceny dla zewnętrznych instytucji. Lokalne zapewnienie i wspólna akceptacja to różne osiągnięcia.

Nabywcy powinni w konsekwencji dokładnie analizować zakres deklaracji dotyczących tożsamości. „Agent ma tożsamość” opisuje warunek początkowy. Nie wyjaśnia, które organizacje akceptują tę tożsamość ani na jakie działania zezwalają.

To samo dotyczy deklaracji o interoperacyjności, czyli współdziałaniu systemów różnych dostawców. Udane połączenie dowodzi komunikacji. Niezawodny przepływ pracy w finansach wymaga również zgodnych zasad uprawnień i zrozumiałych rejestrów na wypadek niepowodzenia.

Prawdopodobnym źródłem zróżnicowania jest zatem precyzja operacyjna. Dostawcy muszą wyjaśnić, kim jest podmiot, którego klienta reprezentuje, jaka operacja jest dozwolona oraz czy instytucja odbierająca ją akceptuje. Ogólne stwierdzenia o zaufanych agentach pozostawiają zbyt wiele nierozstrzygniętego.

To analityczny wniosek wynikający z różnic w zakresie produktów. Dokumentacja nie wskazuje uniwersalnego zwycięzcy ani zakończonego porozumienia w branży.

Znajomość agenta nie dowodzi, że transakcja została autoryzowana

Możliwy do zidentyfikowania agent nadal może zażądać działania wykraczającego poza zamierzone uprawnienia klienta.

Omówienie NIST z 27 sierpnia dotyczące podstaw tożsamości agentów ostrzega przed współdzieleniem poświadczeń, nadmiernymi uprawnieniami i poleganiem na powtarzanych zatwierdzeniach przez człowieka. Argumentuje, że obecne praktyki tożsamościowe stanowią fundament, podczas gdy agenci konsumenccy tworzą dodatkowe trudności. NIST rozróżnia również zarządzane wdrożenia korporacyjne od zewnętrznych agentów, których instytucje nie kontrolują.

Analiza ta wspiera ostrożną interpretację produktów związanych z tożsamością. Nadanie oprogramowaniu odrębnej tożsamości poprawia zdolność rozpoznania podmiotu. Nie rozstrzyga jednak każdego pytania dotyczącego tego, co ten podmiot powinien robić.

Nierozstrzygnięta kwestia staje się jasna, gdy zadanie zmienia się w trakcie wykonywania. Asystent przygotowujący raport może odkryć brakujące informacje i poszukać kolejnego połączenia. Pierwotny cel pozostaje ten sam, ale żądany dostęp się rozszerzył.

Rozsądna granica kontroli powinna wyraźnie oceniać takie rozszerzenie. Nie powinna zakładać, że uprawnienie do ukończenia celu obejmuje każdą drogę prowadzącą do jego realizacji. Jest to szczególnie ważne, gdy działanie wywołuje konsekwencje wykraczające poza pobieranie informacji.

Również weryfikacja przez człowieka wymaga starannej interpretacji. Ekran potwierdzenia może zarejestrować zgodę, lecz jego użyteczność zależy od tego, co klient zrozumiał. Niejasna prośba o „kontynuowanie” zapewnia mniej klarowności niż wyjaśnienie proponowanej operacji.

Nie oznacza to, że zgoda klienta jest bezcelowa. Oznacza to, że zgoda wymaga określonego przedmiotu: konta, działania i istotnych konsekwencji. W przeciwnym razie interfejs może zbierać akceptację bez usuwania niepewności.

To samo rozumowanie dotyczy uprawnień, które pozostają aktywne. Klient może zatwierdzić dostęp do natychmiastowego zadania, nie zamierzając nawiązywać relacji na czas nieokreślony. Projekt produktu musi odróżniać czas trwania przepływu pracy od czasu trwania jego uprawnień.

Cofnięcie uprawnień, czyli wycofanie istniejącej zgody, wyznacza kolejną granicę. Zatrzymanie przyszłego dostępu nie może automatycznie cofnąć już ukończonej operacji. Nie może też zagwarantować, że wcześniej przekazane informacje zniknęły z każdego miejsca docelowego.

Dostęp tylko do odczytu ogranicza zatem pewną kategorię ryzyka, nie eliminując całej ekspozycji. Przeglądanie informacji finansowych nadal rodzi pytania o obsługę, przechowywanie i dalsze udostępnianie. Decyzji instytucji o zezwoleniu na przeglądanie nie należy interpretować jako ogólnego poparcia dla każdego dalszego wykorzystania.

Te rozróżnienia wyjaśniają, dlaczego główny konflikt jest szerszy niż wykrywanie botów. Bank może zidentyfikować zautomatyzowany ruch, a mimo to nie mieć wystarczających podstaw do przyjęcia jego instrukcji. Wykrywanie identyfikuje warunek; autoryzacja wymaga decyzji.

Wyjaśniają też, dlaczego twierdzenia o kompletnych rozwiązaniach zasługują na analizę. Dostawca może zademonstrować rozpoznawanie, ograniczony dostęp lub interfejs zatwierdzania. Żadna z tych demonstracji sama w sobie nie dowodzi, że cały przepływ pracy zachowuje intencję klienta.

Właściwym standardem są dowody powiązane z proponowaną operacją. Standard ten pozostaje wymagający nawet wtedy, gdy agent działa poprawnie. Banki potrzebują procesu, który potrafi wyjaśnić awarie i spory równie jasno jak udane demonstracje.

Dowody nie ustanawiają uniwersalnej polityki bankowej

Zgłaszane ograniczenia są istotne, lecz dostępne dowody nie uzasadniają traktowania każdego banku ani każdego agenta jako równoważnych.

Relacja źródłowa łączy odpowiedzi instytucji, obawy ekspertów i oczekiwania dotyczące popytu klientów. Kategorie te mają różną wagę dowodową. Zgłoszona decyzja polityczna różni się od prognozy eksperta dotyczącej kierunku adopcji.

W relacji BankInfoSecurity dyrektor ds. bezpieczeństwa Domino Data Lab, Chris Talevi, podkreśla odpowiedzialność, podczas gdy założyciel Uptiq AI, Snehal Fulzele, ostrzega przed frustracją klientów. Fulzele wzywa również do nadzoru człowieka. Ich stanowiska opisują rzeczywisty kompromis, lecz żadne z nich nie ustanawia jednolitego zachowania klientów ani sprawdzonej implementacji.

To rozróżnienie ma znaczenie przy ocenie prognoz handlowych. To, że klienci chcą pomocy, nie mówi nam, jaki model dostępu zaakceptują. Nie dowodzi też, że nieograniczeni asystenci przewyższają węższe przepływy pracy zatwierdzone przez instytucje.

Podobnie ostrożność instytucjonalna nie dowodzi, że cała zewnętrzna automatyzacja jest niebezpieczna. Ograniczenie może odzwierciedlać niepewność dotyczącą tożsamości, uprawnień, umów lub obowiązków wsparcia. Publiczne dowody nie wyodrębniają jednego wyjaśnienia dla każdej instytucji.

Ograniczenia dotyczące agentów AI w JPMorgan nie powinny więc stać się skrótem myślowym dla ustalonego werdyktu branży. Bardziej uzasadniony wniosek dotyczy relacji dostępu. Instytucje finansowe mierzą się z asystentami, których uprawnień nie można po prostu wywnioskować ze zdolności klienta do zalogowania się.

Pozostaje także kwestia konkurencyjna, którą dowody pozostawiają otwartą. Asystenci zatwierdzeni przez instytucje mogą zapewniać jaśniejsze granice, wymagając jednocześnie od klientów korzystania z odrębnych doświadczeń. Zewnętrzni asystenci obiecują ciągłość między usługami, lecz muszą zdobywać akceptację na każdej granicy.

Żadna z tych dróg automatycznie nie rozwiązuje problemu klienta. Zbiór odrębnych asystentów może fragmentować zadanie. Szeroko połączony asystent może stać się trudny do nadzorowania, jeśli jego uprawnienia pozostają niejasne.

Znaczące porównanie dotyczy ukończonego przepływu pracy. Czy klient może zrozumieć jego zakres, naprawić błędy i zatrzymać dalsze działania? Czy instytucja może odróżnić dozwoloną pomoc od nieobsługiwanego zachowania?

Pytania te pozwalają uniknąć założenia, że sama autonomia mierzy jakość produktu. System, który wykonuje mniej operacji przy jasno określonych uprawnieniach, może być bardziej niezawodny dla konkretnego zadania finansowego. To ocena projektowa, a nie ustalenie dotyczące wskazanych produktów.

Dowody nie uzasadniają również przypisywania odpowiedzialności finansowej z góry. Odpowiedzialność zależy od okoliczności i obowiązujących ustaleń. Nagłówki o dostępie agentów nie mogą rozstrzygać wyniku hipotetycznych sporów.

Dla czytelników użyteczna sceptyczna postawa powinna być precyzyjna, a nie lekceważąca. Należy pytać, które twierdzenia opisują zaobserwowane zachowanie, które opisują politykę instytucjonalną, a które zamierzoną zdolność dostawcy. Rozdzielenie tych kategorii czyni historię bardziej informacyjną.

Pozwala też zachować możliwość postępu. Ograniczenia mogą współistnieć z węższym, zatwierdzonym dostępem. Ważne pytanie brzmi, czy instytucje i dostawcy czynią te ścieżki wystarczająco jasnymi, by można było z nich korzystać i je oceniać.

Obserwuj zatwierdzony dostęp, testy między dostawcami i praktyczne standardy

Kolejne znaczące sygnały pokażą, czy instytucje potrafią zezwolić na użyteczne działania w granicach, które wytrzymują rzeczywiste przepływy pracy.

Pierwszym sygnałem jest jaśniejszy zatwierdzony dostęp ze strony instytucji finansowych. W nadchodzących miesiącach warto obserwować publiczne wyjaśnienia wskazujące obsługiwane połączenia i dozwolone operacje. Ogólne oświadczenie witające AI dostarcza mniej dowodów niż szczegółowy opis możliwego do użycia dostępu.

Najbardziej informacyjne ujawnienia rozróżniałyby przeglądanie informacji od zmieniania stanu konta. Wyjaśniałyby także, w jaki sposób klienci udzielają i wycofują zgodę. Taki szczegół wzmocniłby argument, że ograniczenia ustępują miejsca kontrolowanemu uczestnictwu.

Utrzymująca się niejednoznaczność osłabiłaby tę ocenę. Klienci i deweloperzy nie mogą niezawodnie tworzyć rozwiązań wokół uprawnień, które pozostają nieudokumentowane lub zależą od jednorazowego działania demonstracji. Dostępność musi oznaczać więcej niż sporadyczny sukces techniczny.

Drugim sygnałem są testy między dostawcami, pokazujące, jak uprawnienia utrzymują się w całym przepływie pracy. Należy szukać demonstracji obejmujących zewnętrznego agenta i instytucję przyjmującą z niezależnie egzekwowanymi ograniczeniami. Istotnym wynikiem jest to, czy zakazane operacje pozostają zablokowane.

Użyteczny test powinien także ujawniać zachowanie w przypadku awarii. Co dzieje się, gdy zgoda wygasa, żądana operacja się zmienia albo połączenie przestaje działać? Dowody przewidywalnej awarii powiedziałyby nabywcom więcej niż dopracowana sekwencja udanych kroków.

W przypadku Microsoft, Visa i innych uczestników pytanie dotyczy tego, jak ich poszczególne podejścia łączą się z akceptowanymi operacjami. Sama ekspansja produktu nie dowodzi tego połączenia. Jasne oświadczenia dotyczące akceptacji przez stronę przyjmującą dostarczyłyby silniejszych dowodów.

Trzecim sygnałem są praktyczne prace wdrożeniowe prowadzone przez organy normalizacyjne. Aktualizacja NIST z 29 września dotycząca projektu tożsamości wskazuje, że jego projekt bezpiecznego rozwoju oprogramowania zapewni pierwszy przypadek użycia implementacji. Wyznacza to konkretny kierunek testowania identyfikacji, uwierzytelniania i autoryzacji agentów.

Wybrane środowisko ma znaczenie. Dowody z rozwoju oprogramowania mogą naświetlić kwestie wdrożeniowe, lecz nie powinny być przedstawiane jako zakończona walidacja bankowości konsumenckiej. Przeniesienie do innego środowiska wymaga zbadania jego operacji i obowiązków.

W ciągu najbliższych kilku miesięcy użyteczne wyniki wyraźnie określałyby założenia i granice egzekwowania. Praktyczne przykłady wzmocniłyby zaufanie, że istniejące podstawy tożsamości mogą wspierać przepływy pracy agentów. Szerokie zobowiązania bez możliwych do sprawdzenia implementacji pozostawiłyby obecną niepewność w dużej mierze nienaruszoną.

Żaden z tych sygnałów nie wymaga dramatycznego ogłoszenia nieograniczonej autonomii. Postęp może przejawiać się jako węższe połączenie, które klienci rozumieją, a instytucje konsekwentnie wspierają. Taki rezultat rozwiązywałby centralny problem dostępu bardziej bezpośrednio niż kolejne ogólne twierdzenie o zdolnych agentach.

Przed przyjęciem asystenta finansowego poproś jego dostawcę o wskazanie zatwierdzonej ścieżki dostępu i opisanie uprawnień stojących za każdą obsługiwaną operacją. Zapytaj, co dzieje się, gdy instrukcja staje się niejednoznaczna, uprawnienie wygasa lub instytucja odrzuca żądanie. Traktuj ograniczenia dotyczące agentów AI w JPMorgan jako powód, by domagać się tych odpowiedzi przed poleganiem na przepływie pracy. W przypadku powiązanej pracy z wiedzą zachowaj oddzielność między organizacją informacji a uprawnieniem do wprowadzania istotnych zmian. Oceniaj pomoc, z której faktycznie możesz korzystać w udokumentowanych warunkach, w tym jej zachowanie w przypadku awarii. Następnie obserwuj dostęp zatwierdzony przez instytucje i niezależne dowody wdrożeniowe. Czy dostawca potrafi wykazać, że uprawnienia asystenta pozostają zrozumiałe od żądania klienta aż po końcowe działanie?