Zarządzanie AI Otari: Mozilla AI łączy wybór modeli i limity agentów w jednej bramie

Mozilla AI przedstawiło 4 listopada swoje podejście do zarządzania AI Otari, łącząc wybór modeli z ograniczeniami dotyczącymi narzędzi agentów i wydatków. Firma opisuje Otari jako system operacyjny do zarządzania, choć sam produkt jest bramą open source. Brama znajduje się między aplikacjami a usługami AI, zapewniając wspólne miejsce do kierowania żądań i stosowania reguł.

Ta propozycja odpowiada na praktyczny konflikt: zespoły chcą swobodnie zmieniać modele bez przebudowywania mechanizmów kontroli wokół nich. Mozilla AI twierdzi, że Otari łączy uprawnienia przestrzeni roboczej, kontrolę budżetów i widoczność wykorzystania. Wywiera to presję na podejście, w którym każda aplikacja utrzymuje własne połączenia z dostawcami i zabezpieczenia.

Otari trafia do ugruntowanej kategorii, w której alternatywy takie jak LiteLLM już oferują scentralizowany dostęp i kontrolę wydatków. Istotne pytanie brzmi, gdzie powinna znajdować się władza decyzyjna, gdy agent może wybierać zarówno kolejne działanie, jak i kolejne płatne żądanie.

Zarządzanie AI Otari łączy wybór modeli i uprawnienia

Mozilla AI przedstawia dostęp do modeli i zakres uprawnień agentów jako elementy tej samej decyzji infrastrukturalnej.

W swoim ogłoszeniu dotyczącym zarządzania AI Mozilla AI opisuje reguły przestrzeni roboczej obejmujące dozwolone modele, wyszukiwanie w sieci, wykonywanie kodu i wymagane kontrole. Firma twierdzi, że oznaczone żądania mogą zostać zablokowane, zanim dotrą do dostawcy. Budżety są przypisywane użytkownikom i kluczom aplikacji, czyli poświadczeniom, których aplikacje używają do uzyskania dostępu do bramy.

Te możliwości wyznaczają zamierzoną granicę produktu. Deweloperzy mogą budować aplikacje wokół wspólnego punktu dostępu, podczas gdy administratorzy decydują, z których usług mogą korzystać te aplikacje. Zmiana modelu i przyznanie agentowi kolejnej możliwości stają się powiązanymi decyzjami.

Rozróżnienie ma znaczenie, ponieważ odpowiedź modelu i uprawnienia agenta rodzą odmienne obowiązki. Błędny szkic może wymagać redakcji. Błędne działanie może zmienić rekord, ujawnić informacje lub rozpocząć dodatkową pracę, zanim ktokolwiek zweryfikuje wynik.

Wspólna brama daje organizacji miejsce, w którym można wyrażać ograniczenia poza rozmową z modelem. Zmienia to, kto podejmuje ostateczną decyzję o dostępie. Aplikacja może zażądać danej możliwości, ale infrastruktura może odrzucić żądanie.

Rozważmy hipotetycznego asystenta obsługi klienta, który przygotowuje odpowiedzi na podstawie zatwierdzonej dokumentacji. Przydzielone mu zadanie nie uzasadnia automatycznie dostępu do nieograniczonej przeglądarki ani środowiska wykonawczego. Te możliwości wymagają własnego uzasadnienia, nawet jeśli poprawiają wyniki w niezwiązanych zadaniach.

Przykład ten ujawnia też częstą niejednoznaczność w dyskusjach o autonomii. Zapewnienie agentowi większej ilości użytecznych informacji różni się od umożliwienia mu podejmowania większej liczby działań. Produkt może stać się bardziej pomocny dzięki lepszej dokumentacji, nie uzyskując zarazem uprawnień do modyfikowania rekordów klientów.

Dla czytelników pytających, czym jest Otari, użyteczna odpowiedź ma więc charakter architektoniczny. Jest to miejsce koordynowania decyzji o dostępie między aplikacjami AI, przy czym Mozilla AI łączy pozycjonowanie zarządzania i wyboru dostawców.

Określenie „system operacyjny” pozostaje metaforą. Kupujący powinni interpretować je jako deklarację dotyczącą koordynacji, a nie dowód, że Otari zarządza każdym elementem aktywności AI organizacji. Dostęp do danych, zachowanie aplikacji i zatwierdzenia biznesowe nadal potrzebują jasno określonych właścicieli.

Listopadowe ogłoszenie najlepiej rozumieć jako deklarację kierunku rozwoju produktu. Wyjaśnia ono, co Mozilla AI chce, aby zespoły kontrolowały, oraz gdzie te mechanizmy kontroli powinny się znajdować. Nie potwierdza niezależnie zmierzonych popraw w zakresie bezpieczeństwa, niezawodności ani kosztów operacyjnych.

Praktyczna zmiana polega na bardziej jednoznacznej umowie między zespołami aplikacyjnymi a właścicielami platform. Deweloperzy żądają dostępu przez interfejs; administratorzy definiują jego dozwolony zakres. To, czy ta umowa działa, zależy od ścieżek, których aplikacja faktycznie używa.

Zespoły platformowe przejmują decyzje, których agenci nie mogą posiadać

Centralizacja dostępu czyni odpowiedzialność bardziej widoczną, ale ktoś nadal musi określić, na co zasługuje każdy przepływ pracy.

Bezpośrednia presja spada na inżynierów platformowych, zespoły bezpieczeństwa i właścicieli aplikacji. Muszą oni przełożyć szeroką instrukcję, taką jak „korzystaj z AI odpowiedzialnie”, na decyzje dotyczące poświadczeń, dozwolonych usług, wydatków i przeglądu.

Wcześniejszy argument Mozilla AI dotyczący infrastruktury agentów rozróżnia instrukcje od ograniczeń. Pisemna reguła mówi agentowi, jak powinien się zachować. Wymuszone ograniczenie określa, co faktycznie może zrobić.

To rozróżnienie staje się istotne, gdy przepływ pracy obsługuje materiały dostarczane przez osoby z zewnątrz. Prompt injection oznacza, że treść próbuje przekierować zachowanie modelu, zamiast jedynie dostarczać informacje. Zgłoszenie do wsparcia, pobrany dokument lub strona internetowa mogą zatem stać się źródłem niepożądanych instrukcji.

Ograniczenie infrastrukturalne nie wymaga od modelu rozpoznania każdego złośliwego fragmentu. Jeśli przepływ pracy nie ma uprawnienia do używania określonej możliwości, granica ta może pozostać istotna nawet wtedy, gdy osąd modelu zawiedzie.

Wskazówki OWASP dotyczące nadmiernej sprawczości wskazują nadmierną funkcjonalność, uprawnienia i autonomię jako odrębne przyczyny szkodliwych działań. Zalecenia obejmują ograniczanie narzędzi, zawężanie uprawnień w systemach zależnych oraz wymaganie zatwierdzenia dla działań o istotnych konsekwencjach.

To niezależne wytyczne bezpieczeństwa, a nie rekomendacja Otari. Wspierają one podstawowy powód umieszczania limitów poza osądem modelu. Pokazują też, dlaczego brama powinna wpisywać się w szerszy system uprawnień.

Wyobraźmy sobie asystenta badawczego, który może wyszukiwać publicznie dostępne materiały i podsumowywać ustalenia. Jego właściciel może rozsądnie zatwierdzić dostęp do sieci, jednocześnie nie przyznając mu uprawnienia do zewnętrznego publikowania wniosków. Znajdowanie informacji i reprezentowanie organizacji to różne odpowiedzialności.

Centralny punkt kontroli pomaga uwidocznić tę różnicę. Nie określa jednak polityki organizacji. Ktoś nadal musi ustalić, do jakich informacji asystent może uzyskać dostęp, które wyniki wymagają przeglądu i kto obsługuje wyjątki.

Dla pracowników wiedzy wiąże się to bezpośrednio z różnicą między osobistą bazą wiedzy a współdzielonymi zasobami organizacyjnymi. Użyteczne wyszukiwanie nie uzasadnia automatycznie szerszego dostępu ani uprawnienia do działania.

Presja na właścicieli aplikacji jest zatem konkretna. Muszą opisać przepływ pracy wystarczająco precyzyjnie, aby uprawnienia mogły wynikać z jego celu. Etykieta taka jak „agent badawczy” daje mniej wskazówek niż jasny opis zatwierdzonych danych wejściowych i dozwolonych wyników.

Zespoły bezpieczeństwa stoją przed odpowiadającym temu obowiązkiem. Ograniczenia powinny być na tyle zrozumiałe, aby deweloperzy mogli przewidzieć zachowanie aplikacji. Niewyjaśnione odmowy utrudniają rozwiązywanie problemów i zachęcają do składania wniosków o szerszy dostęp.

Do dyskusji wchodzą również zespoły finansowe i operacyjne, ponieważ wybory agenta mogą generować powtarzalną płatną aktywność. Potrzebują przypisania, które łączy zużycie z odpowiedzialnym przepływem pracy. Wspólne poświadczenie bez znaczącego właściciela osłabia tę odpowiedzialność.

Zarządzanie AI Otari zbliża te decyzje do siebie. Konsekwencją organizacyjną jest współdzielona odpowiedzialność: zespoły aplikacyjne definiują zadanie, zespoły platformowe egzekwują granice, a właściciele biznesowi decydują, jakie rezultaty uzasadniają dalszy dostęp.

Otari vs LiteLLM przenosi uwagę na szczegóły egzekwowania zasad

Istotne porównanie dotyczy zachowania mechanizmów kontroli we wdrożeniu, a nie tego, czy produkt wymienia budżety i routing modeli.

LiteLLM stanowi użyteczny punkt odniesienia, ponieważ jego dokumentacja już opisuje scentralizowaną kontrolę wydatków. Dokumentacja dotycząca egzekwowania budżetów obejmuje budżety osobiste, zespołowe, członków zespołu i agentów. Stwierdza również, że egzekwowanie budżetów zależy od podłączonej bazy danych.

To zastrzeżenie pokazuje, dlaczego nazwy funkcji nie zapewniają pełnego porównania. Panel może wyświetlać budżet, podczas gdy wdrożeniu brakuje stanu niezbędnego do jego egzekwowania. Operatorzy muszą rozumieć warunki wspierające każdy mechanizm kontroli.

Ocena Otari vs LiteLLM powinna zatem zaczynać się od rzeczywistych ścieżek żądań aplikacji. Które poświadczenia identyfikują wywołującego? Które limity obowiązują? Co dzieje się, gdy informacje księgowe są niedostępne? Odpowiedzi mają większe znaczenie niż długa lista obsługiwanych integracji.

W tym miejscu scentralizowana infrastruktura różni się również od zabezpieczeń osadzonych osobno w aplikacjach. Oddzielne implementacje mogą odzwierciedlać lokalne wymagania, lecz każda z nich wymaga utrzymania. Wspólny punkt kontroli stwarza możliwość spójnego zachowania w tych aplikacjach.

Ta spójność ma wartość, gdy zespoły zastępują dostawcę lub wprowadzają kolejny przepływ pracy. Administratorzy powinni być w stanie zrozumieć, czy zmiana zachowuje istniejące reguły. W przeciwnym razie każda integracja staje się kolejną okazją do dryfu polityki.

Mozilla AI twierdzi, że Otari udostępnia wspólny interfejs programowania aplikacji, czyli API, przez który aplikacje docierają do modeli. Opisuje również reguły awaryjne, które przekierowują żądania, gdy dostawca staje się niedostępny.

Mechanizm awaryjny może zachować dostępność, jednocześnie zmieniając inne właściwości zadania. Model zastępczy może inaczej stosować instrukcje, tworzyć inny format odpowiedzi lub wymagać dodatkowego przeglądu. Utrzymanie usługi różni się więc od utrzymania równoważnego zachowania.

Dlatego zmiana dostawców powinna pozostawać przetestowaną decyzją operacyjną. Interfejs może ograniczyć nakład pracy integracyjnej, nie eliminując potrzeby oceny jakości wyników. Aplikacje nadal zależą od tego, jak model interpretuje ich instrukcje i wykorzystuje dostępne narzędzia.

To samo rozumowanie dotyczy modeli o otwartych wagach, których parametry są dostępne do użycia na obowiązujących je warunkach. Dostęp do tych parametrów sam w sobie nie zapewnia otaczających usług, których oczekuje aplikacja.

Dyskusja Mozilla AI o infrastrukturze dla otwartych modeli przedstawia narzędzia takie jak wyszukiwanie i wykonywanie kodu jako element brakującej warstwy otoczenia. Jej argument polega na tym, że wybór modelu staje się bardziej praktyczny, gdy aplikacje zachowują dostęp do tych możliwości.

Dla kupujących wniosek jest taki, aby porównywać ukończoną pracę w równoważnych warunkach. Model, który szybko tworzy wiarygodną odpowiedź, może nadal wymagać rozległej weryfikacji. Inny może wykonać to samo zadanie przy mniejszej liczbie poprawek.

Różnice te wpływają na wartość przenośności między dostawcami. Łatwy routing ma największe znaczenie wtedy, gdy organizacja potrafi również ocenić, czy alternatywa spełnia jej wymagania. Bez takiej oceny możliwość zmiany pozostaje w dużej mierze teoretyczna.

Otari vs LiteLLM jest w konsekwencji porównaniem wdrożeń, a nie ogłoszeniem zwycięzcy. Zarówno dozwolony przepływ pracy, jak i warunki jego awarii powinny decydować o ocenie. Ani dokumentacja, ani lista funkcji nie ustalają, który produkt sprawdzi się lepiej w określonym środowisku.

Kontrola budżetów zależy od ścieżki, którą podąża żądanie

Limit wydatków jest tak skuteczny, jak zasady rozliczania, zakres ochrony i zachowanie przy równoczesnych żądaniach.

Notatki Otari dotyczące bezpieczeństwa budżetów zawierają zastrzeżenia, które zasługują na uwagę obok samego ogłoszenia. Opisują one rezerwacje kosztów dla równoczesnych żądań rozliczanych według tokenów oraz żądań obrazów. Tokeny są jednostkami przetwarzanymi przez modele podczas odbierania lub generowania tekstu.

Rezerwacja uwzględnia szacowany koszt przed wysłaniem pracy do wykonania. Ma to znaczenie, gdy żądania napływają jednocześnie: każde z nich nie powinno zakładać, że może wydać tę samą pozostałą pulę środków.

Notatki dotyczące bezpieczeństwa odróżniają także te rezerwacje od importów retrospektywnych, partii oraz obecnie niezarezerwowanych ścieżek o stałej cenie. Nie opisano tych ścieżek jako twardych limitów w czasie rzeczywistym. Zakres tej obietnicy ma więc znaczenie.

Nie oznacza to, że kontrola budżetu jest nieprzydatna. Oznacza, że jej granica operacyjna jest częścią decyzji zakupowej. Zespół powinien rozumieć, czy planowane obciążenie korzysta ze ścieżki z rezerwacją, czy opiera się na rozliczeniu następującym później.

Wyobraźmy sobie na przykład hipotetyczną aplikację do przetwarzania dokumentów, która przesyła pracę partiami. Jej operator nie powinien zakładać, że takie zachowanie odpowiada interaktywnemu asystentowi tylko dlatego, że oba pojawiają się na tym samym pulpicie wydatków.

Istotne jest to, kiedy system zobowiązuje się do wykonania pracy. Jeśli rozliczenie następuje po tym zobowiązaniu, wyświetlane saldo służy innemu celowi niż ograniczenie przed wysłaniem żądania. Oba mechanizmy mogą wspierać zarządzanie finansami, lecz odpowiadają na różne pytania.

Cennik modeli jest kolejną zależnością. Polityka bezpieczeństwa Otari mówi, że cennik jest domyślnie wymagany, a żądania dotyczące modeli bez określonej ceny są odrzucane zgodnie z udokumentowanymi zasadami. To konkretne zabezpieczenie przed traktowaniem nieznanego kosztu jako kosztu zerowego.

Operatorzy mogą jednak zmieniać konfigurację, a te same notatki wskazują wyjątki. Ocena wdrożenia wymaga więc rzeczywistych ustawień i faktycznych punktów końcowych, a nie założeń opartych na wartościach domyślnych.

Szersza lekcja jest taka, że kontrola kosztów należy do przetwarzania żądań. Zależy od tożsamości, informacji o cenach, stanu rozliczeń oraz momentu, w którym praca zostaje autoryzowana. Samo raportowanie nie może zapewnić wszystkich tych warunków.

Weryfikacja przez człowieka wprowadza kolejną granicę. Agent może pozostać w ramach swojego limitu wydatków, a mimo to generować bezużyteczne wyniki. Budżet ogranicza ekspozycję; nie określa, czy wykonana praca zasługuje na poniesiony koszt.

To rozróżnienie powinno kształtować raportowanie wewnętrzne. Właściciele aplikacji muszą łączyć wykorzystanie z zaakceptowanymi wynikami, poprawkami i porzuconymi próbami. W przeciwnym razie niższe zużycie może wyglądać na sukces, nawet jeśli przepływ pracy po prostu wykonuje mniej użytecznej pracy.

Ta sama skrupulatność ma zastosowanie, gdy zespoły porównują modele. Tańsze żądanie może stać się kosztownym przepływem pracy, jeśli prowadzi do powtarzanych prób lub znacznego czyszczenia wyników. Istotną jednostką wartości jest ukończone zadanie.

Zarządzanie AI w Otari daje zespołom proponowane miejsce do koordynowania tych decyzji, ale jego dokumentacja bezpieczeństwa zawęża szerokie interpretacje słowa „kontrola”. Kupujący powinni zachować te zastrzeżenia podczas formułowania wymagań.

Odpowiedzialna ocena powinna testować zarówno zwykłe żądania, jak i warunki graniczne w autoryzowanym środowisku. Wynik powinien ustalić, co zostaje zatrzymane, kiedy zostaje zatrzymane oraz która aktywność pozostaje poza twardym limitem.

Takie dowody byłyby bardziej użyteczne niż samo stwierdzenie, że funkcja budżetowa istnieje. Łączyłyby udokumentowany mechanizm produktu z rzeczywistą ekspozycją finansową organizacji.

Śledzenie tworzy wybór między widocznością a zachowywaną treścią

Zespoły muszą odróżniać możliwość zobaczenia, co się wydarzyło, od przechowywania wszystkiego, co agent przeczytał lub wygenerował.

Śledzenie sesji łączy aktywność w osi czasu, dzięki czemu operatorzy mogą badać przebieg przepływu pracy. Ogłoszenie Mozilla AI opisuje śledzenie bez przechowywania promptów, odpowiedzi ani wyników narzędzi. To ważna część deklarowanego przez firmę podejścia do widoczności.

Historia wydań projektu dodaje jednak zastrzeżenie. Wersja 0.38.0 z datą 4 listopada wymienia obsługę zachowywania treści trasowanych żądań, które o to proszą.

Tych stwierdzeń nie należy łączyć w bezwarunkową obietnicę dotyczącą przechowywania danych. Ogłoszenie opisuje podejście minimalizujące zawartość, podczas gdy informacje o wydaniu pokazują opcjonalną możliwość zachowywania treści. Wybory wdrożeniowe zasługują więc na uwagę.

Dla operatora te tryby wspierają różne dochodzenia. Oś czasu może pomóc zlokalizować nieudane żądanie lub zmianę trasowania. Odtworzenie, dlaczego odpowiedź zawierała konkretny błąd, może wymagać informacji o wykorzystanym materiale.

Tworzy to praktyczne napięcie. Zachowywanie mniejszej ilości treści może zmniejszyć ilość wrażliwego materiału gromadzonego na potrzeby debugowania. Zachowywanie większej ilości może ułatwić zrozumienie określonych incydentów. Żadna z tych preferencji nie odpowiada na każdą potrzebę operacyjną.

Hipotetyczny asystent obsługujący badania wewnętrzne dobrze obrazuje ten kompromis. Jego zapis aktywności może wskazywać, która usługa obsłużyła żądanie i czy zakończyło się ono niepowodzeniem. Zrozumienie wprowadzającego w błąd podsumowania może także wymagać zbadania fragmentu źródłowego.

Organizacja powinna zdecydować, gdzie należy przechowywać taki materiał dochodzeniowy. Może on już istnieć we własnych rejestrach aplikacji i podlegać odrębnym ograniczeniom dostępu. Powielanie go w innym systemie tworzy kolejne miejsce wymagające zarządzania.

Dlatego twierdzenie dotyczące śledzenia nie może zastąpić ogólnoorganizacyjnej polityki retencji danych. Aplikacje, usługi modeli, usługi wyszukiwania i narzędzia wykonawcze mogą zajmować różne pozycje w przepływie pracy.

Konfiguracja bramy jest istotna dla tego obrazu, lecz nie opisuje wszystkich pozostałych komponentów. Zespoły powinny zmapować zaangażowane usługi, zanim zaczną zapewniać, gdzie informacje przemieszczają się lub pozostają.

Istnieje także różnica między widocznością operacyjną a odpowiedzialnością za wyniki. Ślad może potwierdzać, że działanie nastąpiło. Ustalenie, czy było ono właściwe, nadal wymaga celu przepływu pracy i zasad nim rządzących.

Recenzent badający incydent powinien móc połączyć aktywność z odpowiednią aplikacją i odpowiedzialnym właścicielem. W przeciwnym razie szczegółowa oś czasu może pozostać trudna do zinterpretowania.

Ta sama zasada dotyczy zablokowanych działań. Odmowa jest bardziej użyteczna, gdy upoważniony operator może zrozumieć, która reguła ją spowodowała. Wspiera to korektę bez automatycznego rozszerzania uprawnień agenta.

Dostępność open source daje możliwość zbadania wyborów implementacyjnych. Nie oznacza jednak, że każda wdrożona instancja używa tej samej konfiguracji lub zachowuje te same informacje.

Dla kupujących wniosek jest konkretny: należy zapytać, który tryb śledzenia jest włączony, kto może go zmienić i kto może przeglądać powstałe zapisy. Odpowiedzi na te pytania przekształcają ogólne twierdzenie o prywatności w zobowiązanie operacyjne.

Wybór powinien wynikać z wrażliwości przepływu pracy i potrzeb dochodzeniowych. Publiczny asystent badawczy oraz asystent przetwarzający poufne dokumenty nie muszą zachowywać takich samych dowodów, aby wspierać odpowiedzialne działanie.

Na co zwrócić uwagę dalej: dowody egzekwowania, przenośność i wdrażanie

Postępy Otari będą najbardziej widoczne, gdy użytkownicy będą mogli połączyć jego mechanizmy kontroli z obserwowalnym zachowaniem w rzeczywistych przepływach pracy.

Pierwszym sygnałem, na który warto zwracać uwagę w nadchodzących miesiącach, są powtarzalne dowody egzekwowania zasad. Użyteczne raporty pokazywałyby, jak wskazane wdrożenie obsługuje niedozwolone narzędzia, wyczerpane budżety i równoczesne żądania. Powinny wskazywać wersję oraz istotną konfigurację.

Wzmocniłoby to propozycję Mozilla AI poprzez połączenie udokumentowanych mechanizmów kontroli z zaobserwowanymi wynikami. Raporty pomijające ścieżki żądań lub ustawienia dawałyby mniejszą pewność, nawet jeśli końcowy wynik brzmiałby zachęcająco.

Najbardziej pouczające przykłady obejmowałyby próby przekroczenia granic, a także normalne działanie. Udana odpowiedź pokazuje użyteczność. Właściwie odrzucone żądanie pokazuje, że określone ograniczenie utrzymało się w testowanych warunkach.

Drugim sygnałem jest przenośność między dostawcami przy równoważnych ograniczeniach. Zespoły powinny szukać porównań, w których aplikacja zachowuje swoje zadanie, dozwolone narzędzia i standard weryfikacji, zmieniając jednocześnie model działający w tle.

Pokazałoby to, czy łatwiejsze trasowanie przekłada się na praktyczny wybór. Jeśli zmiana nadal wymaga znacznej naprawy przepływu pracy, korzyść integracyjna pozostaje realna, lecz jest węższa, niż sugeruje metafora systemu operacyjnego.

Jakość wyników powinna pozostać częścią tej oceny. Zmiana dostawcy, która zachowuje interfejs, ale zwiększa liczbę poprawek, tworzy pracę gdzie indziej. Przenośność staje się cenna, gdy organizacja może zaakceptować wynikające z niej zachowanie.

Trzecim sygnałem jest trwałe wdrażanie z jasno określoną odpowiedzialnością operacyjną. Istotne relacje powinny wyjaśniać, kto utrzymuje bramę, przegląda zmiany zasad, bada awarie i decyduje, czy agent zasługuje na szerszy dostęp.

Te szczegóły pokazałyby, czy scentralizowane zarządzanie ogranicza powtarzaną pracę, czy tylko ją przenosi. Przekonująca relacja z wdrożenia powinna uwzględniać utrzymanie i wyjątki obok korzyści.

W tym miejscu podejście open source staje się również testowalne. Organizacje mogą badać oprogramowanie i zdecydować się na samodzielne jego prowadzenie, ale ktoś musi odpowiadać za aktualizacje, konfigurację i reagowanie na incydenty.

Dowody stabilnej odpowiedzialności wzmocniłyby argument za traktowaniem bramy jako współdzielonej infrastruktury organizacyjnej. Wdrożenie działające wyłącznie dzięki nieudokumentowanej interwencji osłabiłoby ten argument, niezależnie od zakresu jego funkcji.

Te sygnały utrzymują dyskusję w ramach wydarzenia opisanego przez Mozilla AI. Otari przedstawia spójną propozycję koordynowania dostępu do modeli, uprawnień agentów i wydatków. Jego długoterminowa wartość zależy od tego, jak te elementy działają razem.

Ujęcie zarządzania przedstawione przez firmę jest najbardziej użyteczne, gdy skłania do precyzyjnych pytań. O jakie działania może poprosić asystent? Których może odmówić infrastruktura? Które koszty system może ograniczyć, zanim rozpocznie się praca?

Zespoły oceniające zarządzanie AI w Otari powinny zacząć od przepływu pracy, którego cel i akceptowalny wynik już rozumieją. Dzięki temu łatwiej rozpoznać awarie i ocenić ulepszenia. Zachowaj stabilność zadania podczas badania uprawnień, zachowania wydatków oraz dowodów dostępnych po wystąpieniu problemu.

Przed rozszerzeniem dostępu poproś właściciela aplikacji o wyjaśnienie, co umożliwia dodatkowa funkcja i kto przyjmuje odpowiedzialność za jej użycie. Poproś właściciela platformy o wskazanie, gdzie to uprawnienie jest egzekwowane. Następnie porównaj, czy inny model może wykonać tę samą pracę w tych granicach. Które decyzje pozostają możliwe do wyegzekwowania, gdy agent popełni błąd?