Oracle Deep Trust AI Architecture przenosi zabezpieczenia AI do stosu przedsiębiorstwa

Oracle ogłosił Oracle Deep Trust AI Architecture 26 października, rozmieszczając zabezpieczenia w czterech warstwach technologicznych przedsiębiorstwa, zamiast pozostawiać egzekwowanie zasad poszczególnym aplikacjom AI. Plan obejmuje platformę programową, dane, dostęp do danych oraz tworzenie aplikacji. Jego główny argument jest praktyczny: firmy potrzebują mechanizmów kontroli, które pozostają skuteczne, gdy model AI popełni błąd.

Ogłoszenie dotyczy agentów AI, czyli oprogramowania wykorzystującego modele do wyboru narzędzi i wykonywania zadań. Systemy te rodzą trudne pytanie architektoniczne. Jeśli agent dociera do danych biznesowych nową ścieżką, czy ograniczenia wbudowane w istniejącą aplikację nadal będą obowiązywać?

Odpowiedź Oracle kładzie nacisk na egzekwowanie zasad poniżej warstwy aplikacji. AWS realizuje pokrewny cel poprzez mechanizmy AgentCore działające poza granicą wykonywania agenta. Istotne porównanie dotyczy miejsca egzekwowania polityk przez każde z podejść, ich zakresu oraz tego, co klienci nadal muszą skonfigurować. Dla nabywców korporacyjnych ogłoszenie to dotyczy więc zarówno odpowiedzialności, jak i oprogramowania.

Oracle Deep Trust AI Architecture łączy cztery warstwy kontroli

Oracle przedstawia plan architektoniczny łączący istniejące możliwości produktów, a nie ogłasza model gwarantujący godne zaufania zachowanie.

Ogłoszenie dotyczące architektury AI dla przedsiębiorstw z 26 października nastąpiło podczas Oracle AI World w Las Vegas. Łączy ono Oracle AI Database, Oracle Autonomous AI Database oraz Oracle APEX AI Application Generator.

Oracle porównuje to podejście z Maximum Availability Architecture, swoim schematem projektowania niezawodnych systemów. Tutaj celem organizującym jest utrzymanie kontroli nad dostępem AI i jej działaniami. Firma twierdzi, że wspólne zabezpieczenia mogą ograniczyć zależność od mechanizmów wdrażanych osobno w każdej aplikacji.

To rozróżnienie ma znaczenie przy ocenie tego, co się zmieniło. Ogłoszenie architektoniczne może wyznaczać wspólny kierunek projektowy, nie oznaczając, że każdy komponent stał się dostępny w dniu ogłoszenia. Kupujący powinni odróżniać publikację planu od statusu udostępnienia każdej funkcji, którą zamierzają wdrożyć.

Praktyczne znaczenie leży w tym, jak te komponenty mają współpracować. Firma może już dysponować uprawnieniami do baz danych, kontrolami aplikacyjnymi oraz operacyjnymi procesami bezpieczeństwa. Pytanie architektoniczne brzmi, czy tworzą one spójną granicę, gdy agent wprowadza kolejną ścieżkę dostępu do systemu.

Rozważmy hipotetycznego asystenta ds. zakupów, który odczytuje rejestry zakupów i przygotowuje zmiany. Jego zwykły interfejs aplikacji może odrzucać żądania wykraczające poza uprawnienia pracownika. Oddzielne połączenie z danymi źródłowymi wymagałoby równoważnych ograniczeń, nawet gdyby asystent nigdy nie otwierał tego interfejsu.

Ten przykład ilustruje problem, którym zajmuje się Oracle, a nie dokumentuje wdrożenie u klienta. Mechanizm kontroli chroni przepływ pracy tylko wtedy, gdy przepływ rzeczywiście na niego trafia. Dodanie kolejnej kontroli aplikacyjnej daje ograniczone poczucie bezpieczeństwa, jeśli inna ścieżka całkowicie ją omija.

Propozycja Oracle zmienia zatem przedmiot oceny. Kupujący muszą zbadać kompletną ścieżkę między żądaniem człowieka a istotnym działaniem systemu. Sam przegląd widocznej rozmowy z asystentem pozostawiłby ważne fragmenty tej ścieżki niezbadane.

Ujęcie czterech warstw rozdziela też różne znaczenia zaufania. Utrzymywanie platformy różni się od ograniczania dostępu do rekordu. Ograniczanie dostępu różni się od poprawnej interpretacji pytania finansowego. Aplikacja może wywiązywać się z jednej odpowiedzialności, a zawodzić w innej.

Dla osób śledzących ogłoszenie to rozdzielenie jest kluczowe. „Godna zaufania AI” może brzmieć jak pojedyncza właściwość produktu. W tym planie oznacza ona kilka obowiązków inżynieryjnych, które wymagają odrębnych dowodów, właścicieli i kryteriów akceptacji.

Wiadomością jest skoordynowana architektura i jej nacisk na egzekwowanie zasad. Nie dowodzi ona, że każde przedsiębiorstwo przyjmujące ten plan rozwiązało już te kwestie.

Właściciele danych stoją przed najtrudniejszymi decyzjami dotyczącymi zarządzania

Przeniesienie egzekwowania zasad głębiej do stosu zwiększa znaczenie precyzyjnego definiowania reguł.

Projekt bezpieczeństwa danych Oracle opisuje egzekwowanie zasad w bazie danych powiązane ze zweryfikowaną tożsamością użytkownika końcowego. SQL, język używany do odpytywania i modyfikowania danych relacyjnych, nadal podlega tym regułom.

Firma opisuje także SQL Assertions, czyli warunki bazy danych odrzucające zmiany naruszające zdefiniowane wymagania biznesowe. Jej przykład dotyczy limitu wydatków pracownika. Mechanizmy te odnoszą się do dostępu i prawidłowości zmian, zamiast polegać na tym, że agent zapamięta instrukcje.

Dla zespołów w przedsiębiorstwach implikacja ma charakter organizacyjny. Ktoś musi zdecydować, które uprawnienia i warunki biznesowe należą do tego punktu egzekwowania zasad. System techniczny może konsekwentnie stosować regułę, podczas gdy organizacja pozostaje podzielona co do tego, na co reguła powinna zezwalać.

Hipotetyczny proces zakupowy dobrze pokazuje to rozróżnienie. Uprawnienie do wyświetlenia wniosku zakupowego nie musi oznaczać uprawnienia do jego zatwierdzenia. Uprawnienie do zatwierdzenia wniosku może zależeć od działu, celu wniosku lub tymczasowego delegowania uprawnień.

To pytania zarówno dla właścicieli procesów, jak i deweloperów. Administrator bazy danych może pomóc wdrożyć uzgodniony warunek. Nie powinien jednak musieć wyprowadzać niejednoznacznej polityki zakupowej z nieformalnych rozmów.

Zarządzanie AI Oracle wywiera zatem presję na jakość definicji polityk przedsiębiorstwa. Reguły wyrażane wyłącznie przez przyzwyczajenie stają się trudniejsze w zarządzaniu, gdy oprogramowanie potrzebuje jednoznacznej decyzji. Wyjątki wymagają szczególnej uwagi, ponieważ często ujawniają założenia ukryte w zwykłym przepływie pracy.

Nie oznacza to, że każda ocena powinna znaleźć się w bazie danych. Niektóre decyzje zależą od informacji poza jej zakresem. Inne wymagają ludzkiego uznania lub zatwierdzenia w innym systemie. Architektura potrzebuje wyraźnych granic określających, co może ustalić każda kontrola.

Przykład zakupów ujawnia także różnicę między kwalifikowalnością a intencją. Wniosek może spełniać limit wydatków, a mimo to dotyczyć niewłaściwego produktu. Egzekwowanie limitu rozwiązuje określony warunek; nie ustala, czy zakup służy interesom firmy.

To rozróżnienie powinno kształtować decyzje zakupowe. Zespoły muszą określić, którym błędom proponowana kontrola zapobiega, a które nadal są możliwe. Szeroka obietnica zarządzania jest mniej użyteczna niż wyraźne przedstawienie objętych nim działań.

Deweloperzy stają przed powiązaną zmianą odpowiedzialności. Wspólne egzekwowanie zasad może ograniczyć powtarzalną pracę, lecz aplikacje nadal muszą poprawnie obsługiwać odrzucenia. Asystent powinien dokładnie wyjaśniać odmowę działania i nie traktować jej jako problemu technicznego, który należy obejść.

Właściciele danych potrzebują również procesu zmiany polityki. Reguła poprawna w chwili wdrożenia może się zdezaktualizować po reorganizacji lub zmianie procesu zatwierdzania. Niezawodne egzekwowanie zasad zwiększa wartość zdyscyplinowanych aktualizacji, ponieważ skutki obejmują każdą aplikację objętą regułą.

Właściwa miara sukcesu jest zatem szersza niż samo działanie mechanizmu polityk. Organizacja potrzebuje porozumienia co do znaczenia polityk, własności, wyjątków i przeglądu. To te decyzje określają, co faktycznie osiąga konsekwentne egzekwowanie zasad.

Wspólne egzekwowanie zasad zmienia porównanie Oracle i AWS

Nacisk Oracle na mechanizmy kontroli poniżej aplikacji wpisuje się w szerszą rywalizację o to, gdzie powinna znajdować się władza nad AI w przedsiębiorstwie.

AWS opisuje egzekwowanie polityk AgentCore w Gateway, usłudze pośredniczącej w dostępie do narzędzi. Według AWS Policy ocenia wywołania narzędzi poza kodem agenta i stosuje reguły określające dozwolone działania.

Zapewnia to istotne porównanie, nie ustanawiając równoważnego zakresu ochrony. Oracle podkreśla bazę danych i stos aplikacyjny. AWS opisuje egzekwowanie zasad wokół dostępu do narzędzi. Oba podejścia podważają poleganie na instrukcjach osadzonych wewnątrz agenta, lecz ich punkty egzekwowania pełnią różne role architektoniczne.

Brama może oceniać, czy proponowane wywołanie narzędzia jest dozwolone. Kontrola bazy danych może oceniać dostęp lub zmiany, gdy żądanie dociera do bazy danych. To, czy przedsiębiorstwo potrzebuje jednego z tych podejść, czy obu, zależy od jego przepływów pracy i istniejących systemów.

Użyteczne pytanie dla kupującego jest więc konkretne: przez jakie miejsce musi przejść żądanie, zanim wywoła skutek? Diagram przedstawiający punkt egzekwowania zasad staje się znaczący, gdy zespół potrafi wskazać każdą ścieżkę prowadzącą wokół niego lub poza nim.

Wyobraźmy sobie na przykład asystenta, który może aktualizować rekord biznesowy za pomocą zatwierdzonego narzędzia. To samo środowisko może zawierać także inną integrację o szerszych uprawnieniach. Ocena powinna zbadać obie ścieżki, zamiast zakładać, że zatwierdzone narzędzie stanowi całą granicę.

To przykład analityczny, a nie twierdzenie o zidentyfikowanej słabości produktu któregokolwiek z dostawców. Ilustruje, dlaczego porównywanie nazw funkcji daje ograniczone wskazówki. Zakres ochrony zależy od rzeczywistego wdrożenia i uprawnień przydzielonych jego komponentom.

Bezpieczeństwo agentów Oracle należy zatem oceniać względem ścieżek danych klienta. Projekt skoncentrowany na bazie danych zasługuje na szczególną uwagę, gdy znajdują się tam istotne rekordy i reguły. Przepływ pracy obejmujący usługi zewnętrzne również potrzebuje mechanizmów kontroli odpowiednich dla tych usług.

Porównanie powinno unikać traktowania podejścia Oracle jako dowodu, że konkurenci polegają wyłącznie na promptach. Dokumentacja AWS wyraźnie opisuje zewnętrzne egzekwowanie zasad. Różnica konkurencyjna dotyczy integracji, zakresu, administracji oraz pracy koniecznej do utrzymywania spójnej polityki.

Istnieje również kompromis związany z konsolidacją odpowiedzialności. Wspólne kontrole mogą uprościć nadzór, zapewniając zespołom wspólne miejsce do analizowania polityk. Mogą też sprawić, że błędy we wspólnej konfiguracji będą miały konsekwencje w kilku aplikacjach.

Z kolei rozproszenie kontroli między narzędziami i usługami może zachować lokalny kontekst. Może też utrudniać ocenę spójności. Żadna preferencja architektoniczna nie usuwa potrzeby zrozumienia, jak tożsamości, uprawnienia i decyzje przemieszczają się przez kompletny przepływ pracy.

Dla kupujących dopasowanie operacyjne jest zatem bardziej informacyjne niż ogólne twierdzenie o wyższości architektonicznej. Najlepsza ocena wykorzysta własne granice uprawnień organizacji i realistyczne zadania. Demonstracja oparta na nieznanym przykładowym procesie dostarcza mniej dowodów gotowości do wdrożenia.

Ogłoszenie porusza istotną kwestię konkurencyjną: przedsiębiorstwa kupują systemy ograniczające zachowanie AI, obok systemów, które je generują. Wartość tych ograniczeń zależy od tego, czy pozostają skuteczne na ścieżkach faktycznie wykorzystywanych przez firmę.

Trafne odpowiedzi wymagają czegoś więcej niż kontroli uprawnień

Agent może mieć legalny dostęp do danych, a mimo to udzielić wprowadzającej w błąd odpowiedzi biznesowej.

Możliwości Oracle Deep Trust obejmują Deep NL2SQL, system przekształcający pytania w języku naturalnym w zapytania do bazy danych. Oracle podaje, że uwzględnia on kontekst biznesowy oraz obsługuje informacje zwrotne i weryfikację, które mają poprawiać odpowiedzi.

Dotyczy to innej odpowiedzialności niż autoryzacja, czyli decyzja o tym, czy dane działanie jest dozwolone. Dozwolone zapytanie nadal może błędnie zrozumieć pytanie. Prawidłowy wynik nadal może wspierać interpretację, której dane źródłowe nie uzasadniają.

Rozważmy hipotetycznego asystenta finansowego, którego poproszono o wskazanie najsilniejszych relacji z klientami. „Najsilniejsze” może oznaczać przychody, retencję, rentowność lub znaczenie strategiczne. Wybranie jednej interpretacji bez doprecyzowania ukształtowałoby odpowiedź jeszcze przed pobraniem jakiegokolwiek rekordu.

Problem nie musi wynikać z błędu obliczeniowego. Asystent może poprawnie obliczyć wybraną przez siebie miarę. Błąd dotyczyłby tego, czy miara odpowiada na pytanie biznesowe.

W tym miejscu zarządzanie AI Oracle przecina się z zarządzaniem wiedzą. Organizacja potrzebuje utrzymywanego opisu swojej terminologii, zatwierdzonych miar i istotnego kontekstu. Polityka regulująca dostęp nie może zastąpić tych definicji.

Dla czytelników porównujących systemy informacyjne rozróżnienie między wiedzą osobistą a zespołową stanowi przydatny kontekst. Indywidualne rozumienie i definicje organizacyjne służą różnym celom. Odpowiedź biznesowa potrzebuje źródła autorytetu odpowiedniego do danego zadania.

Wyzwanie analityczne polega na decyzji, czyja interpretacja staje się częścią systemu. Lider sprzedaży i lider finansowy mogą z uzasadnionych powodów używać tego samego terminu inaczej. Użyteczne wdrożenie powinno zachowywać ten kontekst, zamiast po cichu standaryzować każde pytanie wokół jednego znaczenia.

Informacje zwrotne wprowadzają kolejną odpowiedzialność. Skorygowanie odpowiedzi może usprawnić konkretną interakcję, ale wspólna definicja wpływa także na przyszłe pytania. Zmiany wymagają oceny ich szerszych konsekwencji, zwłaszcza gdy od tych samych pojęć zależy kilka zespołów.

Kupujący powinni zatem prosić o przykłady obejmujące niejednoznaczność, a nie tylko pytania o oczywistych odpowiedziach. Reakcja systemu na niedookreśloną prośbę pokazuje, czy prosi on o doprecyzowanie, przedstawia założenia, czy prezentuje interpretację jako ustalony fakt.

Jakość odpowiedzi wymaga również odpowiedniego standardu oceny. Zgodność z wcześniejszą odpowiedzią jest niewystarczająca, jeśli wcześniejsza odpowiedź korzystała z nieaktualnej definicji. Proces przeglądu musi odróżniać spójność od poprawności.

Te rozważania nie umniejszają znaczenia kontroli baz danych. Wyjaśniają, dlaczego schemat obejmuje więcej niż bezpieczeństwo. Zapobieganie nieautoryzowanemu dostępowi i tworzenie odpowiedzi wystarczającej do podjęcia decyzji to odrębne cele, nawet gdy oba zadania wykonuje ten sam asystent.

Dla pracowników wiedzy jest to najbardziej bezpośrednia implikacja. Dopracowana odpowiedź zasługuje na weryfikację, gdy jej założenia biznesowe pozostają niewidoczne. Zaufanie w przedsiębiorstwie wymaga zrozumiałych definicji i możliwego do prześledzenia rozumowania obok granic uprawnień.

Oracle Deep Trust AI Architecture łączy te odpowiedzialności w jedną opowieść. Jej skuteczność nadal zależy od jakości wiedzy organizacji oraz dowodów wykorzystanych do walidacji odpowiedzi.

Twierdzenie o zaufaniu nadal wymaga dowodów wdrożeniowych

Ogłoszenie przedstawia stanowisko Oracle dotyczące projektu; nie stanowi niezależnego potwierdzenia bezpieczeństwa ani dokładności wdrożenia u klienta.

Szerokie sformułowania Oracle dotyczące zabezpieczeń, których AI nie może ominąć, należy odczytywać w zakresie skonfigurowanych mechanizmów kontroli. Nie należy rozszerzać ich na twierdzenie, że cały system przedsiębiorstwa jest odporny na niewłaściwe użycie.

Wskazówki OWASP dotyczące nadmiernej sprawczości wskazują ryzyka wynikające z niepotrzebnej funkcjonalności, nadmiernych uprawnień i nadmiernej autonomii. Zalecenia obejmują ograniczanie możliwości oraz wykonywanie działań w kontekście bezpieczeństwa właściwego użytkownika.

Te wskazówki wspierają architektoniczną zasadę ograniczania uprawnień. Nie są oceną wdrożenia Oracle. To rozróżnienie ma znaczenie, ponieważ zgodność z zasadą projektową nie zastępuje dowodów dotyczących konkretnego produktu lub konfiguracji.

Rzetelna ocena powinna analizować zwykłe błędy, a także celowe ataki. Asystent może błędnie odczytać prośbę, wybrać niewłaściwy rekord lub spróbować wykonać działanie, którego użytkownik nigdy nie zamierzał. Mechanizmy kontroli powinny zapewniać zrozumiałe rezultaty w takich warunkach.

Prompt injection, czyli próba nakłonienia modelu do wykonania instrukcji osadzonych w niezaufanym materiale, dodaje kolejną kategorię testów. Kupujący powinni sprawdzić, jakie uprawnienia pozostają dostępne po takiej próbie, a także czy model rozpoznaje złośliwą instrukcję.

Kluczowym pytaniem analitycznym jest skutek awarii. Jeśli model zachowuje się nieprawidłowo, jakie działanie nadal może zostać wykonane? Ocena tego skutku dostarcza bardziej użytecznych dowodów niż pytanie, czy asystent ogólnie przestrzega instrukcji.

Wspierające komentarze analityków również wymagają kontekstu. W opublikowanych przez Oracle perspektywach zaufania architektonicznego Dave Vellante z theCUBE Research dostrzega możliwość ograniczenia prac integracyjnych. Podkreśla też, że przedsiębiorstwa nadal odpowiadają za polityki, walidację i nadzór nad wdrożeniem.

Komentarze te pojawiają się na własnej stronie Oracle. Stanowią przypisane perspektywy zewnętrzne wybrane przez dostawcę, a nie niezależny test porównawczy. Czytelnicy powinni zachować to rozróżnienie przy ocenie odbioru ogłoszenia.

Materiały przeanalizowane na potrzeby tego artykułu nie zawierają niezależnego benchmarku porównawczego potwierdzającego ogólne bezpieczeństwo lub dokładność odpowiedzi. Ogranicza to wnioski, jakie można wyciągnąć z premiery. Nie dowodzi to, że mechanizmy kontroli są nieskuteczne.

Dowody wdrożeniowe powinny obejmować również uzasadnioną pracę, którą system odrzuca. Ograniczenie może zapobiec niepożądanemu działaniu, jednocześnie blokując konieczne zadanie. Nadmierne odrzucanie może skłonić pracowników do ręcznych obejść, osłabiając zamierzony proces.

Podobnie skuteczne egzekwowanie powinno pozostawiać wystarczające informacje do dochodzenia. Zespół musi rozumieć, która tożsamość zainicjowała prośbę, która reguła została zastosowana i jaki był wynik. Odmowa bez zrozumiałego wyjaśnienia tworzy inne obciążenie operacyjne.

Właściwy wniosek jest ograniczony. Oracle przedstawił wiarygodny problem architektoniczny i skoordynowaną odpowiedź. Kupujący nadal potrzebują dowodów, że wybrane komponenty, skonfigurowane dla ich środowiska, rozwiązują problemy, które są dla nich istotne.

Na co kupujący powinni zwracać uwagę do początku 2027 roku

Kolejne użyteczne dowody będą dotyczyć możliwości wdrożenia, zmierzonego zachowania i odpowiedzialności operacyjnej.

Pierwszym sygnałem jest jasność wdrożeniowa dotycząca konkretnych możliwości, z których kupujący zamierzają korzystać. Do początku 2027 roku klienci powinni szukać precyzyjnej dokumentacji obejmującej obsługiwane środowiska, wymagania wstępne, ograniczenia i dostępność komponentów.

Informacje te wzmocniłyby praktyczną wartość Oracle Deep Trust AI Architecture, przekształcając szeroki schemat w możliwe do oceny wdrożenie. Utrzymująca się niepewność dotycząca wymagań utrudniałaby planowanie wdrożenia, nawet gdyby ogólny projekt pozostawał atrakcyjny.

Ten sygnał ma znaczenie, ponieważ środowiska przedsiębiorstw różnią się między sobą. Organizacja powinna móc ustalić, które części propozycji dotyczą jej obecnych systemów. Ogólne stwierdzenie o zakresie architektonicznym nie może odpowiedzieć na każde pytanie wdrożeniowe na poziomie komponentu.

Drugim sygnałem są dowody z oceny obejmujące przypadki niepowodzeń. Użyteczne wyniki analizowałyby nieautoryzowane prośby, błędne interpretacje, dozwolone działania oraz uzasadnione zadania odrzucone przez mechanizmy kontroli. Kupujący powinni szukać jasno opisanego środowiska testowego i wyraźnie określonych ograniczeń.

Dowody z zewnętrznej oceny lub udokumentowanej ewaluacji klienta wzmocniłyby zaufanie bardziej niż kolejne ogólne poparcie. Wynik ograniczony do wąskiej demonstracji wspierałby węższy wniosek.

Kluczowe jest, czy ocena odpowiada przedstawianemu twierdzeniu. Test pokazujący, że jedna zabroniona prośba kończy się niepowodzeniem, nie potwierdza zakresu dla niezwiązanych działań. Wynik dotyczący dokładności z określonego zestawu pytań nie powinien stawać się uniwersalnym twierdzeniem o niezawodności.

Trzecim sygnałem są dowody od klientów dotyczące obsługi mechanizmów kontroli w czasie. Organizacje powinny obserwować relacje opisujące zmiany polityk, aktualizacje tożsamości, obsługę wyjątków i utrzymanie. Szczegóły te pokazują, czy architektura pozostaje łatwa w zarządzaniu po początkowym wdrożeniu.

W tym miejscu porównania konkurencyjne również stają się bardziej użyteczne. Dokumentacja Oracle i AWS opisuje różne miejsca egzekwowania zasad. Doświadczenia klientów mogą pomóc wyjaśnić nakład pracy potrzebny do utrzymania pokrycia w rzeczywistym połączeniu baz danych, aplikacji i usług zewnętrznych.

Żaden z tych sygnałów nie wymaga przewidywania zwycięzcy rynku. Oferują one sposób oceny, czy architektura dostarcza praktyczną wartość. Jasne wymagania wdrożeniowe, istotne oceny i rozliczalne działania operacyjne wzmocniłyby argumenty Oracle.

Dla deweloperów bezpośrednią implikacją jest odróżnienie generowania działania od jego autoryzowania. Dla kupujących w przedsiębiorstwach oznacza to wymaganie dowodów na granicy egzekwowania. Dla pracowników wiedzy oznacza pytanie, jakie definicje wspierają odpowiedź.

Przed rozszerzeniem uprawnień asystenta wybierz przepływ pracy, którego reguły i konsekwencje zespół rozumie. Poproś dostawców o pokazanie dozwolonej prośby, zabronionej prośby i niejednoznacznej prośby z wykorzystaniem tego przepływu pracy. Sprawdź, co dzieje się, gdy model wybiera nieprawidłowo, a następnie ustal, kto odpowiada za wynikającą z tego korektę polityki lub wiedzy. Zachowaj dowody powiązane z rzeczywistym wdrożeniem, zamiast traktować etykietę produktu jako zatwierdzenie. Oracle Deep Trust AI Architecture oferuje konkretny punkt wyjścia do tej dyskusji. Wykorzystaj go, aby zadać precyzyjne pytanie: gdy asystent popełni błąd przy kolejnym kroku, który mechanizm kontroli zapobiega temu, by niewłaściwy krok stał się działaniem biznesowym?