Agentowa AI w bankowości to dziś problem inżynierski przebrany za problem AI. Model jest wymienny; płaszczyzna kontroli — nie. Wyzwaniem 2026 roku nie jest adopcja — Cambridge CCAF szacuje ją już na 52% — lecz to, czy autonomiczne systemy, które wasz bank uruchamia dziś, przejdą badanie SR 11-7 w przyszłym kwartale. Większość — nie przejdzie.
Streszczenie wykonawcze / Najważniejsze wnioski
- Przestańcie nazywać ich chatbotami. Jednostką produkcyjną jest ograniczony przepływ pracy ze ścisłymi uprawnieniami do wywołań narzędzi. Praca odbywa się wewnątrz przepływu, nie wewnątrz LLM.
- OSWorld na poziomie 66,3% to sufit niezawodności. Najbliższy korporacyjnemu użyciu narzędzi benchmark Stanford HAI wciąż zawodzi w jednym na trzy zadania strukturalne. To liczba uzasadniająca agresywne wdrożenie z człowiekiem w pętli; nie uzasadnia nienadzorowanego wykonania na czymkolwiek, co dotyka pieniędzy klienta.
- Klasyfikuj według uprawnień, nie według inteligencji. Drabina Autonomii biegnie od Poziomu 0 (ekstrakcja klauzul ISDA tylko do odczytu) do Poziomu 4 (wielonarzędziowa naprawa płatności z obowiązkowymi punktami kontrolnymi). Poziom 5 — wykonanie samoorkiestrujące bez punktów kontrolnych — nie powinien istnieć w produkcyjnej bankowości w 2026 roku.
- Płaszczyzna Kontroli Agenta to pięć zaprojektowanych komponentów, a nie dokument polityki. Konta serwisowe z OAuth o ograniczonym zakresie, deterministyczny routing semantyczny, bramkowanie Open Policy Agent, logowanie audytu WORM oraz przetestowany wyłącznik awaryjny. Brak czegokolwiek to ustalenie audytu.
- SR 11-7 i PRA SS1/23 już obowiązują. Fed wielokrotnie wyjaśniał, że każdy system decyzyjny przekształcający dane wejściowe w wyjściowe podlega zakresowi. Banki argumentujące, że LLM nie jest modelem, przegrały spór regulacyjny zanim go rozpoczęły.
Dlaczego rok 2026 jest rokiem, w którym ten indeks ma znaczenie #
Przejście od czatu do ograniczonych przepływów pracy to jedyna rzecz, która liczy się w agentowej AI dla banków w tym roku. Chatbot redagujący e-mail do klienta jest możliwy do przejrzenia. Agent wywołujący POST /accounts/{id}/freeze w produkcyjnej platformie kart to audytowalny dowód. Produkcja dogoniła ramę: badanie Cambridge CCAF z 2026 roku donosi o 52% aktywnej adopcji agentowej i 23% na poziomie skalowania lub transformacji (Cambridge CCAF ⧉). Próg „izolowanego pilotażu" został przekroczony gdzieś pod koniec 2025 roku.
Wraz z adopcją zmieniły się dwie rzeczy.
Po pierwsze, regulatorzy przestali traktować LLM jako nowinkę. Rezerwa Federalna wyjaśniła, że SR 11-7 ⧉ stosuje się do podejmowania decyzji w oparciu o LLM, niezależnie od tego, czy LLM jest wewnętrznie sklasyfikowany jako model. PRA SS1/23 ⧉ zawsze było wystarczająco szerokie, aby je objąć. Wysokoryzykowna klasyfikacja unijnego AI Actu obejmuje większość zastosowań LLM w usługach finansowych. Argument „nie jesteśmy pewni, czy to się liczy" już nie istnieje.
Po drugie, rzeczywistość benchmarków dogoniła. Stanford HAI's AI Index 2026 raportuje OSWorld — najbliższy dostępny benchmark do prawdziwego korporacyjnego użycia narzędzi — z dokładnością 66,3% (Stanford HAI ⧉). Jedno na trzy zadania strukturalne wciąż zawodzi. Ta liczba wyznacza techniczny sufit autonomii w 2026 roku. Wysoki na tyle, by uzasadnić ograniczone wdrożenia Poziomu 3 pod nadzorem HITL; niewystarczająco wysoki, by uzasadnić nienadzorowane wykonanie wobec jakiegokolwiek API dotykającego funduszy klientów.
Indeks Agentowej AI dla banków musi zrobić z podejmowaniem decyzji opartym na LLM to, co framework Bazylei zrobił z kapitałem: przekształcić twierdzenia „mamy kontrole" w mierzalne, audytowalne dowody na każdy przepływ pracy.
Architektura Indeksu 2026 #
| Warstwa indeksu | Jak wygląda „gotowość" | Metryka gotowości | Tryb awarii |
|---|---|---|---|
| Poziom autonomii | Każdy produkcyjny przepływ pracy oznaczony Poziomem 0–4; żadnego Poziomu 5 w produkcji | % przepływów według poziomu; udział na Poziomie 3+ | Agent produkcyjny emituje pacs.008 do halucynowanego BIC beneficjenta, ponieważ żadna statyczna lista dozwolona nie bramkuje ładunku przed SWIFTNet |
| Uprawnienia API | Każdy agent mapowany na jedno konto serwisowe z zakresami OAuth najmniejszych uprawnień (np. card-freeze:write:lt-5000usd); MTLS do legacy core |
% agentów na najmniejszych uprawnieniach; liczba osieroconych uprawnień | Agent ponownie używa konta serwisowego o nadmiernym zakresie; iteruje konta, których nie miał prawa czytać; incydent z art. 33 RODO złożony w ciągu 72 godzin |
| Deterministyczne mechanizmy zabezpieczające | Każde wywołanie narzędzia kierowane przez router semantyczny (NeMo Guardrails / LangChain Guardrails) plus walidator JSON-schema przed API | % przechwyconych wywołań narzędzi; wskaźnik odrzuceń według kategorii | LLM emituje wywołanie transfer z amount: 0; downstream API nie waliduje; alert uzgodnienia ksiąg ląduje 18 godzin później w innej strefie czasowej |
| Zasięg człowiek w pętli | Każde wykonanie Poziomu 3 wyświetla interfejs zatwierdzenia z twardym limitem czasu; automatyczne zatwierdzanie wyłączone polityką | Przepustowość zatwierdzeń; wskaźnik bezrefleksyjnego zatwierdzania (zaakceptowane w mniej niż 2 sekundy) | Operator klika „zatwierdź" w 200 alertach w 4 minuty; SAR zgłoszony przeciw legalnemu klientowi; skarga regulatora w tym samym tygodniu |
| Kompletność audytu | Niezmienny dziennik WORM przechwytuje system prompt + pobrany kontekst + wyjście LLM + wywołanie narzędzia + wynik narzędzia + UID zatwierdzającego; kryptograficznie podpisany w momencie zapisu | % wywołań z kompletnym śladem | Inspektor SR 11-7 pyta, dlaczego agent #4421 zatwierdził przelew $4,8M; bank ma potwierdzenie przelewu i kartę modelu; brak dowodu na poziomie promptu; wydane ustalenie |
| Ekonomia jednostkowa | Koszt na ukończoną decyzję śledzony wraz z kosztem cofnięcia i naprawy; dodatni względem ręcznej linii bazowej | Koszt netto na decyzję; wskaźnik cofnięć | Wydatek na tokeny dla agentów obsługujących skrajne przypadki przekracza koszt ręcznego inspektora, którego zastąpili; CFO zamyka program w Q3 |
Bieżące sygnały do śledzenia #
| Sygnał | Co oznacza dla banków | Źródło |
|---|---|---|
| 52% aktywnej adopcji | Agentowa AI minęła fazę pilotażu; ład korporacyjny w skali instytucji jest spóźniony | Cambridge CCAF ⧉ |
| 23% skalujących lub transformujących | Znacząca mniejszość wyszła poza teatr proof-of-concept | Cambridge CCAF ⧉ |
| OSWorld na 66,3% | Stopa awarii jeden-na-trzy przy strukturalnym użyciu narzędzi. Nienadzorowane wykonanie wobec API funduszy klientów jest nie do obrony na tym poziomie niezawodności | Stanford HAI ⧉ |
| 55% wskazuje utratę nadzoru ludzkiego jako kluczowe ryzyko | Projektowanie kontroli to główne zagadnienie inżynierskie, nie zaś późniejsza kwestia zgodności | Cambridge CCAF ⧉ |
| 76% dużych instytucji finansowych ma problem ze zmierzeniem wartości | Ogólne twierdzenia o produktywności nie przetrwają rozmowy z CFO. Mierzcie na przepływ pracy, a nie na program | Cambridge CCAF ⧉ |
Drabina Autonomii #
Klasyfikuj agentów według tego, co wolno im robić, a nie według tego, jak inteligentny jest model bazowy. Ta sama instancja GPT-5 / Claude 4 / Gemini 3 może siedzieć na każdym poziomie; różni się opakowanie.
- Poziom 0 — Obserwuj. Dostęp tylko do odczytu do logów, śladów lub transakcji. Agent uwydatnia wzorce lub anomalie; nigdzie nie zapisuje. Przykład: wykrywanie dryfu wskaźników odrzuceń
pacs.008według korytarza i alertowanie zespołu operacyjnego. - Poziom 1 — Pobieranie tylko do odczytu. Czyta z systemów operacyjnych; emituje strukturalne wyjście do konsumpcji przez człowieka. Przykład: ekstrakcja wariantów klauzul CSA z umowy ramowej ISDA kontrahenta i flagowanie odchyleń od standardowego szablonu banku. Agent nigdy nie zapisuje z powrotem do magazynu kontraktów.
- Poziom 2 — Redaguj do złożenia przez człowieka. Generuje treść, którą człowiek przegląda i składa. Przykład: redagowanie raportu o podejrzanej aktywności (SAR) na podstawie alertu z systemu antyfraudowego, rekordu KYC i śladu transakcji; oficer BSA czyta, edytuje w razie potrzeby i składa. System ewidencyjny widzi tylko wersję zatwierdzoną przez człowieka.
- Poziom 3 — Ograniczone wykonanie. Wywołuje produkcyjne API z twardymi, deterministycznymi limitami egzekwowanymi przez opakowanie. Przykład: wywołanie API zamrożenia karty z
max-amount-at-risk: 5000 USDegzekwowanym przez politykę listy dozwolonej; agent nie może zamrozić karty powiązanej z saldami powyżej tego progu bez eskalacji Poziomu 2. Limit żyje w polityce jako kod, a nie w prompcie — prompty nie są granicą bezpieczeństwa. - Poziom 4 — Wielonarzędziowa orkiestracja z obowiązkowymi punktami kontrolnymi. Wykonuje sekwencję między systemami; każda zmiana stanu jest logowana; punkty kontrolne wymagają zatwierdzenia przez człowieka przed następnym wywołaniem narzędzia. Przykład: przepływ pracy naprawy płatności — wyciągnij nieudany
pacs.008z kolejki listów martwych → sprawdź poprawnego beneficjenta przez SWIFT KYC Registry → wygeneruj skorygowany komunikat → zapisz do kolejki wychodzącej → człowiek zatwierdza ponowną wysyłkę. Jeśli którykolwiek krok nie przejdzie walidatora schematu, przepływ zatrzymuje się i tworzy przypadek wyjątku. - Poziom 5 — Samoorkiestracja. Agent planuje i wykonuje bez zatwierdzania w punktach kontrolnych. Żaden produkcyjny przepływ bankowy nie powinien być na Poziomie 5 w 2026 roku. To nie jest stwierdzenie o dojrzałości; to stwierdzenie o niezawodności. OSWorld na 66,3% kumuluje się w łańcuchu wywołań API. Trzy wywołania narzędzi po 66% każde dają 29% sukcesu end-to-end. Pięć — 13%. Nie róbcie tego.
Płaszczyzna Kontroli Agenta #
Płaszczyzna kontroli to warstwa inżynierska między LLM a waszymi systemami produkcyjnymi. Pięć komponentów, wszystkie runtime, żadnego z nich nie zapisuje się w dokumencie polityki.
1. Tożsamość i uprawnienia #
Każdy agent mapowany jest na dokładnie jedno konto serwisowe. To konto trzyma tokeny OAuth client_credentials ograniczone do minimalnej powierzchni API. Token agenta zamrażającego kartę może wywoływać POST /accounts/{id}/freeze z amount-at-risk: 0..5000 usd. Nie może wywoływać GET /accounts/{id}/balance dla innych klientów. Nie może wywoływać niczego w custody, treasury ani trading. Sekrety kont serwisowych rotują tygodniowo; długoterminowe poświadczenia to najczęstsza awaria płaszczyzny kontroli w produkcyjnych wdrożeniach.
2. Deterministyczne mechanizmy zabezpieczające wywołań narzędzi #
Każde wywołanie narzędzia przez LLM przechodzi przez deterministyczny router semantyczny (NeMo Guardrails, LangChain Guardrails lub odpowiednik) zanim trafi do produkcyjnego API. Router klasyfikuje intencję względem skończonej listy dozwolonej; wywołania spoza listy są odrzucane i logowane. Następnie walidator JSON-schema sprawdza ładunek — wymagane pola obecne, kwoty dolarowe w granicach, kody krajów ISO prawidłowe, BIC beneficjenta na zatwierdzonej liście kontrahentów banku. Walidator powinien być paranoiczny: pacs.008 z amount: 0 to awaria modelu, a nie legalna transakcja. Tak samo przelew do kraju, którego wasz filtr sankcyjny nie zatwierdził wcześniej dla danego segmentu klientów inicjujących.
3. Polityka jako kod #
Open Policy Agent (lub odpowiednik) siedzi między walidatorem a API. Polityki są wersjonowane w Git; decyzje odrzucające są logowane; ten sam silnik polityki, który bramkuje wywołania mikrousługa-mikrousługa w waszej istniejącej platformie, bramkuje wywołania narzędzi agentów. Traktowanie agentów jako specjalnej klasy z dedykowanym bramkowaniem to sposób, w jaki banki kończą z cieniowymi płaszczyznami kontroli, których nikt w zespole platformowym nie rozumie sześć miesięcy później.
4. Logowanie audytu #
Niezmienne magazyny WORM — S3 Object Lock, niezmienność Azure Blob lub baza danych z księgą. Każde wywołanie przechwytuje: znacznik czasu, ID agenta, ID konta serwisowego, hash system promptu, pobrany kontekst, dostawca LLM plus model plus wersja, surowe wyjście LLM, sparsowane wywołanie narzędzia, decyzja OPA, odpowiedź API, efekt downstream oraz UID zatwierdzającego, jeśli dotyczy. Rekordy są kryptograficznie podpisane w momencie zapisu. Tego dziennika audytu będą żądać inspektorzy SR 11-7 i SS1/23. Jeśli nie potraficie wyprodukować kompletnego śladu dla dowolnej decyzji, nie macie agenta z zarządzaniem ryzykiem modelu.
5. Wyłącznik awaryjny #
API typu „czerwony przycisk", które anuluje wszystkie trwające wywołania agentów w obrębie klasy uprawnień w mniej niż 60 sekund. Testowane kwartalnie ćwiczeniem stolikowym. Wyłącznik awaryjny to jedyna rzecz, która uratuje was z wydania modelu dostawcy, które cicho regresuje, z wektora wstrzyknięcia promptu, którego nie przewidzieliście, lub ze zdarzenia dryfu, które przesuwa wskaźniki fałszywie dodatnich poza wasz próg operacyjny. Nietestowane wyłączniki awaryjne nie działają; zaplanujcie czas na ćwiczenie.
Zarządzanie ryzykiem modeli #
Banki argumentujące „LLM nie jest modelem w rozumieniu SR 11-7" już przegrały. Rezerwa Federalna wielokrotnie wyjaśniała, że każdy system przekształcający dane wejściowe w wyjściowe używany w przepływie decyzyjnym podlega zakresowi. PRA SS1/23 jest jeszcze szersze. Właściwa postawa: traktuj każdego agenta produkcyjnego jako model SR 11-7 / SS1/23 od pierwszego dnia. Koszt retrospektywnego zaklasyfikowania wdrożonego agenta jako modelu to wielokrotność kosztu zaprojektowania go takim z góry.
Trzy linie obrony zastosowane do agentów:
- Pierwsza linia (właściciel modelu). Dokumentuje przeznaczenie agenta, pochodzenie danych treningowych i ewaluacyjnych, schemat system promptu, listę dozwoloną wywołań narzędzi, wyniki testów wyłącznika awaryjnego. Posiada monitorowanie dryfu na produkcji.
- Druga linia (zespół MRM). Waliduje agenta przed produkcją. Raport walidacji obejmuje wyniki ewaluacji wydane przez dostawcę (MMLU, HumanEval, HellaSwag są użyteczne, ale niewystarczające), wyniki ewaluacji specyficzne dla banku (wasz własny zbiór ewaluacyjny zbudowany na przykładach operacyjnych — to praca, w którą większość banków inwestuje za mało), wyniki red-teamu wstrzykiwania promptu, analizę stronniczości i sprawiedliwości tam, gdzie przepływ pracy ma wpływ na klienta, oraz skwantyfikowane oświadczenie o ryzyku rezydualnym.
- Trzecia linia (audyt wewnętrzny). Testuje bramki płaszczyzny kontroli i kompletność dziennika audytu na próbie decyzji produkcyjnych. Cykl audytu 2027 będzie wyglądał zupełnie inaczej niż cykl 2025; zaplanujcie go już teraz.
Ciągłe monitorowanie ma większe znaczenie niż walidacja w punkcie czasowym. Cotygodniowe uruchamianie zbiorów ewaluacyjnych specyficznych dla banku wychwytuje regresje aktualizacji modelu, których benchmarki dostawców nie ujawnią. Tempo wydań OpenAI, Anthropic i Google jest szybsze niż wasze tempo walidacji; albo lukę zamykacie wy, prowadząc ciągłe ewaluacje, albo zamknie ją dla was ustalenie inspektora.
Pomiar wpływu biznesowego #
Ogólne twierdzenia o produktywności nie przetrwają rozmowy z CFO. Mierzcie agentów tak, jak mierzycie inne zmiany operacyjne:
- Koszt na ukończoną decyzję, wraz z kosztem cofnięcia i naprawy nieudanych decyzji. Agent redagujący SAR, który skraca czas oficera BSA o 40%, ale generuje 12% fałszywie dodatnich zgłoszeń, zniszczył wartość, a nie ją stworzył.
- Uniknięte dotknięcia ręczne, liczone netto względem nowych dotknięć stworzonych przez nadzór płaszczyzny kontroli i obsługę wyjątków. Chodzi nie o minimalizowanie ludzkiej uwagi; chodzi o przekierowanie jej na decyzje o większej dźwigni.
- Wskaźnik cofnięć — procent działań wykonanych przez agenta cofniętych w ciągu 24 godzin. Wskaźnik cofnięć powyżej 2% na przepływie Poziomu 3 to problem niezawodności. Powyżej 5% — to problem płaszczyzny kontroli.
- Kompletność śladu audytowego — procent decyzji z pełnym pochodzeniem możliwym do zrekonstruowania z dziennika WORM. Powinien wynosić 100% na przepływach Poziomu 3 i Poziomu 4. Cokolwiek mniej to porażka polityki, która wyjdzie w audycie.
Jeśli przepływ pracy staje się szybszy, ale mniej wyjaśnialny, indeks musi go karać. Najtańszym sposobem oblania egzaminu regulacyjnego jest optymalizacja pod przepustowość i utrata śladu.
Co to oznacza według typu banku #
Globalnie istotne banki systemowe #
Trudny problem to ład korporacyjny w skali: setki agentów w liniach biznesowych, każdy z własnym właścicielem modelu, każdy potencjalnym ustaleniem audytu. Inwestycja to nie kolejny pilotaż. To centralna płaszczyzna kontroli, zunifikowana infrastruktura dziennika audytu i ławka MRM zdolna do walidacji ponad 50 agentów kwartalnie. Bez tej zdolności agenci lądują szybciej niż mogą być zarządzeni, a instytucja po cichu kumuluje ekspozycję SR 11-7.
Banki transakcyjne i korporacyjne #
Najwyższy zwrot z inwestycji dają przepływy pracy naprawy płatności, ekstrakcji dokumentów KYC, odsiewu FAQ usług skarbowych i przełamań uzgodnień. Wszystkie Poziom 2 lub ograniczony Poziom 3. Klienta korporacyjnego nie obchodzi, że agent wykonał pracę; obchodzi go, że SLA się poprawił, a wskaźnik sporów pozostał płaski. Prowadźcie metrykami, nie technologią.
Banki regionalne #
Kupujcie, nie budujcie. Wybierzcie dostawcę, którego platforma agentowa ma już prymitywy płaszczyzny kontroli — zakresowanie OAuth, integrację OPA, logowanie audytu WORM, przetestowany wyłącznik awaryjny — i walidujcie tę platformę względem waszego frameworku MRM. Budowa dedykowanej płaszczyzny kontroli to wieloletnia inwestycja, która nie różnicuje na skali regionalnej. Zainwestujcie zdolność inżynierską w projektowanie przepływów pracy i UX operatora.
Fintechy, dostawcy usług płatniczych i dostawcy infrastruktury #
Pytanie produktowe dla dostawców nie brzmi „czy wasz agent AI działa lepiej niż ludzie." Brzmi „czy wasza platforma produkuje ślad audytowy zgodny z SR 11-7 od ręki." Dostawcy, którzy odpowiedzą tak, zamkną kontrakty korporacyjne. Dostawcy, którzy nie, utkną w pętlach proof-of-concept, podczas gdy zespół MRM banku znajdzie powody, by oblać walidację.
Wnioski #
Agentowa AI w bankach w 2026 roku to problem inżynierski. Ciekawa praca odbywa się w płaszczyźnie kontroli, nie w modelu. Model jest wymienny; zakresowanie OAuth, deterministyczny router semantyczny, bramki polityki OPA, niezmienny dziennik audytu i wyłącznik awaryjny — nie są.
Instytucje, które za 18 miesięcy będą wyglądały wiarygodnie dla regulatorów, to te, które traktują każdego agenta produkcyjnego jako model SR 11-7 / SS1/23 od pierwszego dnia, z ciągle uruchamianymi zbiorami ewaluacyjnymi specyficznymi dla banku i płaszczyzną kontroli zaprojektowaną do bezpiecznej awarii. Instytucje, które tego nie robią, dowiedzą się, czy ich ławka MRM jest w stanie skalować się do obsługi ponad 50 ustaleń naprawczych kwartalnie.
Mierzcie agentów tak, jak mierzycie każdą zmianę operacyjną: koszt, niezawodność, odwracalność, dowody. OSWorld na 66,3% to wasz sufit niezawodności. Planujcie odpowiednio.
Najczęściej zadawane pytania #
Czym jest agentowa AI w bankowości?
Ograniczony przepływ pracy, który łączy LLM z wywołaniami narzędzi do systemów produkcyjnych, mechanizmami zabezpieczającymi runtime i punktami kontrolnymi z człowiekiem w pętli. Praca odbywa się wewnątrz przepływu, nie wewnątrz modelu. Jeśli usłyszeliście słowo „chatbot", jesteście w niewłaściwej kategorii.
Od czego banki powinny zacząć?
Od przepływów pracy Poziomu 1 i Poziomu 2, gdzie wartość jest mierzalna, a strona ujemna do okiełznania: ekstrakcja klauzul ISDA, redagowanie SAR, triaż naprawy płatności, wewnętrzne pobieranie wiedzy, wspomaganie przeglądu kodu, klasyfikacja dokumentów KYC. Pomińcie Poziom 3, dopóki wasza płaszczyzna kontroli nie obsługuje zakresowania OAuth, routingu semantycznego, bramkowania OPA, logowania WORM i przetestowanego wyłącznika awaryjnego.
Co jest największym ryzykiem?
Pozwolenie agentom na wykonywanie wobec produkcyjnych API bez deterministycznych mechanizmów zabezpieczających między wyjściem LLM a API. Liczba OSWorld 66,3% to ostrzeżenie. Niezapakowane wywołania narzędzi przy takim wskaźniku awarii wobec SWIFT MT103 lub API funduszy klientów piszą najczarniejszy nagłówek następnego cyklu regulacyjnego.
Czy SR 11-7 stosuje się do agentów opartych na LLM?
Tak. Rezerwa Federalna wyjaśniła, że każdy system przekształcający dane wejściowe w wyjściowe używany w przepływach decyzyjnych podlega SR 11-7. PRA SS1/23 pokrywa ten sam grunt w Wielkiej Brytanii. Wysokoryzykowna klasyfikacja unijnego AI Actu obejmuje większość przypadków użycia w usługach finansowych. Debata „czy to model" jest zakończona; działajcie odpowiednio.
Jak należy raportować agentową AI do zarządów?
Cztery liczby na przepływ pracy: poziom autonomii, kompletność śladu audytowego, wskaźnik cofnięć, koszt netto na decyzję. Plus lista pięciu najważniejszych ryzyk rezydualnych. Pomińcie slajdy z kartami modeli.
Bibliografia #
- Stanford HAI, (2026). Raport AI Index 2026 ⧉.
- Stanford HAI, (2026). Rozdział: Wydajność techniczna ⧉.
- Cambridge Centre for Alternative Finance, (2026). Globalny raport AI w usługach finansowych 2026 ⧉.
- Federal Reserve, (2011). SR 11-7: Wytyczne dotyczące zarządzania ryzykiem modeli ⧉.
- Prudential Regulation Authority, (2023). Oświadczenie nadzorcze SS1/23: Zasady zarządzania ryzykiem modeli dla banków ⧉.
- Komisja Europejska, (2024). Rozporządzenie (UE) 2024/1689 — AI Act ⧉.
- NVIDIA, (2024). Framework NeMo Guardrails ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
Ostatnia weryfikacja .
Ostatnia weryfikacja .
