Nowe Decisions API od OpenAI koncentruje się na obszarze oprogramowania AI, który rzadko trafia do prezentacji premierowych: na drobnym wyborze podejmowanym między dwoma większymi krokami.

Redakcyjna fotografia technologiczna przedstawiająca abstrakcyjny proces routingu decyzji AI na monitorze.

Czy to zgłoszenie do działu wsparcia powinno trafić do rozliczeń, czy do pomocy technicznej? Czy dokument jest wystarczająco kompletny, by przejść do kolejnego etapu procesu? Czy wygenerowane polecenie powłoki wygląda na bezpieczne do automatycznego uruchomienia? Czy asystent głosowy powinien poprosić o doprecyzowanie, przekazać rozmowę dalej, czy ją kontynuować?

Takie decyzje łatwo opisać, ale ich błędne podejmowanie szybko staje się kosztowne. Jeśli aplikacja wykonuje jedną przy każdej przychodzącej wiadomości, dokumencie, transakcji czy wyniku działania narzędzia, opóźnienia się sumują. Narasta także koszt przesyłania każdego pytania do modelu ogólnego przeznaczenia. Błędna klasyfikacja może skierować pracę do niewłaściwej kolejki, ujawnić informacje nieodpowiedniemu operatorowi albo uruchomić działanie, które powinno zaczekać na weryfikację.

OpenAI udostępniło Decisions API ogólnie 22 października 2026 roku. Interfejs działa na GPT-6 Luna i zwraca odpowiedzi o określonym typie zamiast akapitu: prawdopodobieństwo, wybór ze zdefiniowanego zbioru albo wynik według uporządkowanej skali. OpenAI twierdzi, że punkt końcowy został zaprojektowany do odpowiadania na takie ograniczone pytania nawet 10 razy szybciej niż GPT-6 Luna używany za pośrednictwem Responses API. Firma podaje cenę 0,10 USD za milion tokenów wejściowych, bez opłat za tokeny wyjściowe w przypadku tego punktu końcowego.

To połączenie może zainteresować zespoły, które już tworzą produkty AI. Mniej przydatne będzie jako zamiennik ogólnego asystenta. Kluczowe pytanie nie brzmi, czy model potrafi rozumować. Chodzi o to, czy zespół potrafi wystarczająco precyzyjnie zdefiniować wąską decyzję, by ją mierzyć, ustawić wokół niej rozsądny próg i utrzymać wynikające z niej działanie w kontrolowanym przepływie pracy.

Co właściwie zwraca API

Punkt końcowy przyjmuje wspólne dane i jedno lub więcej pytań. Dane mogą mieć postać tekstu, uporządkowanej rozmowy z wywołaniami narzędzi i ich wynikami, obrazów albo struktury JSON. Każde pytanie ma typ, nazwę i instrukcje, a w razie potrzeby także zestaw dozwolonych wyborów lub uporządkowanych poziomów oceny.

predicate szacuje, czy dany warunek jest prawdziwy, i zwraca prawdopodobieństwo z przedziału od zera do jedności. Pasuje to do pytań takich jak „Czy to zgłoszenie opisuje podwójne obciążenie potwierdzone w danych zamówienia?” albo „Czy na obrazie widać uszkodzenie?”.

choice wybiera jedną wartość ze zdefiniowanego wcześniej zbioru. System routingu może oferować billing, technical_support, account_access i human_review. Aplikacja głosowa może wybierać między continue, clarify, transfer i end_call.

score ocenia dane wejściowe według uporządkowanych poziomów, takich jak niski, średni i wysoki stopień dotkliwości. Odpowiedź zawiera prawdopodobieństwa dla poszczególnych poziomów oraz średnią ważoną prawdopodobieństwem. Średnia może wypaść między dwoma poziomami, co pomaga w ustalaniu rankingu, ale staje się niebezpieczne, gdy programista potraktuje ją jak magicznie precyzyjny pomiar.

Punkt końcowy może obsłużyć do 400 pytań w jednym żądaniu — to więcej niż limit 200 pytań obowiązujący podczas publicznej bety. Ma to znaczenie, gdy wiele niezależnych cech można ocenić na podstawie tych samych danych. Nie oznacza jednak, że decyzje zależne od siebie należy łączyć. Jeśli pytanie drugie powinno zostać zadane dopiero po uzyskaniu odpowiedzi na pierwsze, osobne żądania ułatwiają analizę i testowanie przebiegu sterowania.

Najważniejszym wyróżnikiem produktu jest wynik o określonym typie. Ogólnemu modelowi można polecić zwracanie JSON-a, ale programista nadal musi sprawdzić wynik i obsłużyć wartości zniekształcone albo niejednoznaczne. Decisions ogranicza przestrzeń możliwych odpowiedzi na poziomie API. Zmniejsza to nakład pracy związany z parsowaniem, ale nie sprawia, że sama ocena staje się poprawna.

Gdzie pasuje w prawdziwej aplikacji

Najlepiej sprawdza się przy powtarzalnych decyzjach z ograniczonym zbiorem odpowiedzi i jasno określonym kolejnym krokiem. Warto traktować ten punkt końcowy jako szybką warstwę oceny wewnątrz istniejącego programu, a nie autonomicznego pracownika.

Obieg dokumentów może wykorzystywać go do sprawdzania, czy przesłany certyfikat zawiera wymagane pola, rozpoznawania kategorii dokumentu i kierowania materiału do odpowiedniej kolejki. Samo wydobywanie danych z dokumentu może nadal wymagać osobnego systemu. Decisions odpowiada na węższe pytanie: co powinno wydarzyć się dalej.

System wsparcia może klasyfikować zgłoszenie, szacować pilność i ustalać, czy wiadomość klienta zawiera wystarczająco dużo informacji, by przygotować pierwszą odpowiedź. Wynik o niskiej pewności może trafić do kolejki obsługiwanej przez człowieka zamiast posłużyć do wysłania automatycznej odpowiedzi.

System orkiestracji agentów może wykorzystać pytanie wyboru do wskazania kolejnego narzędzia z niewielkiego, wcześniej zweryfikowanego zestawu. Przychodzące żądanie można na przykład skierować do wyszukiwarki, funkcji sprawdzającej konto, funkcji planowania albo etapu doprecyzowania. Model wybiera jedną z tych opcji, ale za uprawnienia, walidację argumentów, limity zapytań i wykonanie nadal odpowiada aplikacja.

Workflow bezpieczeństwa lub operacyjny może ocenić proponowane działanie przed jego wykonaniem. OpenAI podaje, że Datadog wykorzystuje ten endpoint do oceniania poleceń powłoki generowanych przez agentów przed autonomicznym usuwaniem problemów. To potencjalnie użyteczny wzorzec, ale nie należy traktować go jako kompletnej granicy bezpieczeństwa. Wynik oceny oparty na modelu może dostarczyć sygnału do weryfikacji. Nie zastąpi jednak list dozwolonych poleceń, sandboxingu, kontroli tożsamości, ograniczeń dostępu do systemu plików ani polityki zatwierdzania.

Aplikacje głosowe również dobrze pasują do tego zastosowania, ponieważ opóźniona decyzja jest wyraźnie odczuwalna dla osoby mówiącej. Decisions ma teraz natywną integrację z GPT-Live i może być uruchamiany, gdy pojawiają się transkrypcje wejściowe lub wyjściowe. Aplikacja może zdecydować, czy asystent powinien poprosić o doprecyzowanie, przekazać rozmowę dalej albo zaktualizować stan interakcji. OpenAI informuje, że w testach Speak skrócił czas do wykonania kolejnego działania z 1,4 sekundy do 0,13 sekundy dzięki tej integracji. To wynik przedstawiony przez dostawcę, a nie gwarancja dla każdego stosu głosowego, ale pokazuje, dlaczego wyspecjalizowany endpoint może mieć większe znaczenie w interaktywnej pętli niż w procesie wsadowym.

Praktyczna architektura: model, próg, działanie

Niezawodna implementacja wymaga trzech odrębnych warstw.

Pierwszą warstwą jest pytanie. Powinno opisywać obserwowalne dowody i rozróżniać sąsiadujące ze sobą odpowiedzi. „Czy to jest dobre?” nie jest pytaniem produkcyjnym. „Czy wiadomość zawiera prośbę o anulowanie płatnej subskrypcji, a nie pytanie o informacje cenowe?” jest znacznie bliższe właściwemu pytaniu.

Druga warstwa to polityka interpretująca odpowiedź. Prawdopodobieństwo 0,82 nie oznacza, że aplikacja musi podjąć działanie. Zespół musi ustalić, czy 0,82 wystarcza do automatycznego przekierowania, czy 0,55 powinno uruchomić weryfikację oraz czy niektóre kategorie zawsze wymagają udziału człowieka, niezależnie od poziomu pewności.

Trzecią warstwą jest działanie. Modelowi nie należy przyznawać szerokich uprawnień tylko dlatego, że zwrócił prawidłowy wybór. Aplikacja powinna mapować dozwoloną wartość na znaną funkcję i odrzucać wszystko, co nie mieści się w tym mapowaniu. Operacje wrażliwe powinny wymagać niezależnej autoryzacji oraz, w odpowiednich przypadkach, potwierdzenia przez człowieka.

Taki podział umożliwia także ewaluację. Zespoły mogą zmienić próg bez przepisywania promptu. Mogą porównywać decyzje modelu z oznaczonymi przykładami. Mogą mierzyć odsetek fałszywych alarmów i przeoczeń, uwzględniając koszt każdego rodzaju błędu. Filtr antyfraudowy, router zgłoszeń do pomocy technicznej i kolejka moderacji treści nie powinny używać tego samego progu tylko dlatego, że korzystają z tego samego API.

Wskazówki dla deweloperów OpenAI wskazują na podobną zasadę: progi należy ustalać na podstawie oznaczonych przykładów z aplikacji. Łatwo przeoczyć tę poradę, ponieważ endpoint zwraca prawdopodobieństwa i wartości pewności, które wyglądają na dane ilościowe. Liczby te są przydatne do porządkowania i kierowania spraw tylko wtedy, gdy zostały skalibrowane na danych własnej organizacji.

Projektowanie promptu to teraz projektowanie polityki

Nawet wąska decyzja w dużej mierze zależy od dostarczonych dowodów i instrukcji. Prompt powinien określać, co uznaje się za dowód potwierdzający, co robić w przypadku braku dowodów oraz jak odróżniać przypadek graniczny od jednoznacznego.

Załóżmy, że zespół chce kierować faktury do odpowiednich miejsc. Słabe pytanie mogłoby prosić model o „wybranie właściwego działu”. Pytanie produkcyjne określałoby dostępne działy, pola identyfikujące każdy z nich, znaczenie niekompletnego dokumentu oraz regułę postępowania przy sprzecznych sygnałach. Mogłoby też zawierać wyraźną opcję human_review, zamiast zmuszać model do wybrania kolejki biznesowej, gdy dane wejściowe są niejednoznaczne.

Przykłady powinny obejmować zarówno typowe przypadki, jak i sytuacje prowadzące do błędów. Należy uwzględnić krótkie i długie wiadomości, mieszane języki, jeśli produkt je akceptuje, sprzeczne rekordy, brakujące pola, niepoprawny JSON oraz próby wstrzyknięcia instrukcji do dowodów. Dowody są danymi. Nie powinno się pozwalać, by zmieniały politykę podejmowania decyzji.

W przypadku decyzji dotyczących obrazów określ, co model rzeczywiście widzi, a czego nie może ustalić. Zdjęcie może pokazywać wgniecenie, ale nie musi dowodzić przyczyny uszkodzenia. Zrzut ekranu może przedstawiać komunikat o błędzie, lecz nie potwierdza, że konto zostało przejęte. Zakres możliwych odpowiedzi powinien odzwierciedlać tę różnicę.

Gdy kilka pytań dotyczy tego samego dokumentu źródłowego lub tej samej rozmowy, umieść materiały wielokrotnego użytku we wspólnym wejściu, a instrukcje pytań zmieniaj osobno. API obsługuje buforowanie promptów dla takiego schematu. Dokumentacja wskazuje, że wielokrotnie używany prefiks musi zawierać co najmniej 1024 tokeny, a buforowane wejście jest objęte obniżoną ceną. Buforowanie może zmniejszyć koszty i opóźnienia, ale wymaga też zrozumienia granic pamięci podręcznej oraz unikania umieszczania w prefiksie danych zależnych od konkretnego wywołującego lub informacji wrażliwych, które mogłyby zostać ponownie użyte w niewłaściwym kontekście.

Koszt jest niski, ale skala zmienia rachunek

Opublikowana cena Decisions wynosi 0,10 USD za milion niebuforowanych tokenów wejściowych, a buforowane wejście kosztuje 0,01 USD za milion tokenów. Endpoint nie nalicza opłat za tokeny wyjściowe. Na pierwszy rzut oka wiele zadań związanych z routingiem wydaje się więc niemal darmowych.

Rzeczywisty rachunek zależy od ilości danych przesyłanych z każdym pytaniem. Powtarzany dokument z zasadami, historia rozmowy lub wynik narzędzia mogą być znacznie większe od samej instrukcji. Przesyłanie tego samego dużego kontekstu osobno przy każdej decyzji podważa sens małego klasyfikatora. Buforowanie pomaga, gdy prefiks pozostaje stabilny, ale zapis do pamięci podręcznej i przetwarzanie regionalne mogą zwiększać koszty.

Zespoły powinny mierzyć koszt ukończenia zadania biznesowego, a nie koszt pojedynczego wywołania API. Jeśli klasyfikator odrzuci element i skieruje go do kolejki obsługiwanej ręcznie, samo wywołanie modelu może być tanie, podczas gdy cały proces stanie się wolniejszy. Gdy automatyczny routing wywoła błędne działanie w kolejnym systemie, koszt korekty może wielokrotnie przewyższyć rachunek za tokeny.

Endpoint pozwala zadać wiele niezależnych pytań w jednym żądaniu. Może to ograniczyć narzut związany z żądaniami, ale nie powinno stać się pretekstem do zadawania każdego możliwego pytania o każdy element. Dodatkowe pytania zwiększają złożoność, utrudniają ocenę i mogą skłaniać zespoły do działania na podstawie wyników, których nikt wcześniej nie zweryfikował.

Rozsądny pilotaż rejestruje co najmniej liczbę tokenów wejściowych, współczynnik trafień do pamięci podręcznej, percentyle opóźnień, rozkład odpowiedzi, odsetek spraw kierowanych do weryfikacji, odsetek korekt oraz czas ukończenia procesu po stronie systemów zależnych. W produktach interaktywnych ważniejsze od średniej jest opóźnienie p95. W kolejkach zaplecza większe znaczenie mogą mieć przepustowość i obciążenie osób weryfikujących.

Prywatność i kontrola regionu przetwarzania

API obsługuje rezydencję wnioskowania w Stanach Zjednoczonych i Europie, a OpenAI informuje, że klienci spełniający określone warunki mogą korzystać z przechowywania zerowej ilości danych. Dokumentacja dla deweloperów wymienia również obsługę HIPAA dla uprawnionych klientów oraz opisuje dostępność Private Link. Są to przydatne mechanizmy kontroli, jednak organizacja wdrażająca system nadal musi sprawdzić warunki kwalifikacji, umowy, konfigurację endpointu i ograniczenia poszczególnych funkcji.

Przetwarzanie regionalne nie jest tym samym co kompletna strategia ochrony prywatności. Zespół musi nadal ustalić, czy dane wejściowe zawierają informacje osobowe, czy konieczne jest przesłanie pełnego rekordu, jak długo dzienniki aplikacji przechowują żądanie i odpowiedź oraz kto może przeglądać raporty użycia. Tam, gdzie to możliwe, redakcja i minimalizacja danych powinny nastąpić przed wywołaniem modelu.

Ustrukturyzowany JSON sam w sobie nie sprawia, że informacje wrażliwe stają się bezpieczne. Rekord klienta przekazany jako input_json nadal jest danymi klienta. Obrazy również pozostają wrażliwe, jeśli zawierają twarze, adresy, informacje medyczne lub poufne ekrany. Właściwe pytanie nie brzmi, czy API przyjmuje dany format, lecz czy przepływ pracy ma uzasadniony powód, by przesyłać te informacje.

Ta sama ostrożność dotyczy buforowania promptów. Ponowne wykorzystywanie stabilnego dokumentu referencyjnego jest wydajne. Ponowne używanie prefiksu zawierającego prywatne dane jednego klienta w niezwiązanych żądaniach to błąd projektowy. Klucze i granice pamięci podręcznej powinny być częścią przeglądu przepływu danych, a nie dodatkiem analizowanym dopiero podczas optymalizacji wydajności.

Czego Decisions nie zastępuje

Endpoint nie jest uniwersalnym systemem ekstrakcji. Jeśli aplikacja potrzebuje rozbudowanego obiektu z wieloma polami, pisemnego wyjaśnienia lub danych wyjściowych zgodnych z niestandardowym schematem, odpowiedniejszy może być Responses API ze Structured Outputs. Jeśli model musi zażądać wywołania narzędzia wraz z argumentami, czytelniejszą abstrakcją może okazać się wywoływanie funkcji.

To nie jest silnik reguł. Deterministyczna reguła jest lepsza, gdy warunek da się wyrazić dokładnie. Na przykład konta nie należy uznawać za kwalifikujące się tylko dlatego, że model z dużą pewnością ocenił, iż saldo konta znajduje się poniżej określonego progu. Aplikacja może porównać saldo bezpośrednio.

To samo w sobie nie jest zatwierdzeniem bezpieczeństwa. Wybór uznany przez model za „bezpieczny” nie upoważnia do nieodwracalnego działania. W przypadku wszystkiego, co może wydawać pieniądze, zmieniać uprawnienia, wysyłać wiadomości na zewnątrz, modyfikować dane produkcyjne lub wykonywać kod, należy stosować uprawnienia, listy dozwolonych elementów, piaskownice, limity transakcji, etapy akceptacji i dzienniki audytowe.

Nie jest też zamiennikiem ludzkiej weryfikacji w przypadkach niejednoznacznych lub mających istotne konsekwencje. Odpowiedź o określonej strukturze jest łatwiejsza do wykorzystania niż tekst swobodny, ale poprawna serializacja może sprawić, że niepewny osąd będzie wyglądał na bardziej wiarygodny, niż jest w rzeczywistości. System powinien zachowywać poziom pewności, odwołania do dowodów oraz powód eskalacji sprawy.

Mały pilotaż, który może dostarczyć użytecznych danych

Zespół rozważający ten endpoint powinien zacząć od jednej powtarzalnej decyzji, której wynik można już mierzyć. Nie należy zaczynać od procesu, którego powodzenie zależy od pięciu wywołań modeli i kilku niejasno zdefiniowanych przekazań.

Najpierw zbierz próbkę rzeczywistych danych wejściowych i poproś wykwalifikowanych recenzentów o oznaczenie prawidłowego działania. Etykiety trzymaj oddzielnie od promptów używanych podczas testów. Uwzględnij przykłady trudne i graniczne, zamiast wybierać wyłącznie oczywiste przypadki.

Następnie zapisz skończony zestaw odpowiedzi. Dodaj human_review, jeśli niepewność jest uzasadnionym wynikiem. Określ, do czego upoważnia każda odpowiedź, a do czego nie upoważnia. Jeśli działania nie da się jasno opisać, decyzja jest prawdopodobnie zbyt szeroka.

Potem przetestuj trzy tryby działania: automatyczne kierowanie powyżej wysokiego progu, weryfikację w przedziale pośrednim oraz bezpieczny mechanizm awaryjny poniżej niższego progu. Porównaj te wyniki z obecnym procesem. Pilotaż, który raportuje jedynie dokładność modelu, bez pomiaru obciążenia recenzentów lub błędów na dalszych etapach, nie odpowie na pytanie biznesowe.

Rejestruj wystarczająco dużo informacji, aby odtworzyć decyzję, ale nie przechowuj więcej wrażliwych danych, niż to konieczne. Zapisuj wersję pytania, model, próg, odpowiedź, poziom pewności, podjęte działanie i późniejszą korektę. Jeśli prompt się zmieni, potraktuj tę zmianę jak wydanie oprogramowania i ponownie uruchom zestaw ewaluacyjny.

Na koniec uruchom endpoint obok istniejącego procesu, zanim pozwolisz mu sterować działaniami. Tryb shadow może ujawnić, gdzie model nie zgadza się z doświadczonymi operatorami, gdzie dowody są niepełne oraz gdzie pozornie prosta decyzja skrywa politykę wyjątków.

Kto powinien spróbować, a kto powinien poczekać

API Decisions warto przetestować w zespołach, które mają już konkretny problem z klasyfikacją, kierowaniem, oceną lub eskalacją; potrafią zdefiniować dozwolone wyniki; oraz dysponują wystarczającą liczbą oznaczonych przykładów, by oceniać zmiany. Rozwiązanie jest szczególnie obiecujące, gdy obecnym wąskim gardłem są powtarzające się opóźnienia podczas interakcji na żywo albo koszt przepuszczania każdej drobnej decyzji przez większy generatywny proces.

Może też pasować do produktów, które muszą oceniać wiele niezależnych pytań na podstawie tego samego tekstu, obrazu lub ustrukturyzowanego rekordu. Buforowanie promptów i mechanizmy kontroli regionalnej wzmacniają argumenty za zastosowaniami ze stabilnym wspólnym kontekstem i jasno określonymi wymaganiami dotyczącymi danych.

Zespoły powinny poczekać, jeśli wciąż szukają zastosowania, nie potrafią wyjaśnić, jak wygląda prawidłowa odpowiedź, albo planują pozwolić endpointowi wybierać dowolne narzędzia i działania. Niska cena tokenów nie naprawi nieokreślonej polityki. Szybka odpowiedź nie powinna też maskować braku autoryzacji, weryfikacji lub mechanizmów audytu.

Szersze znaczenie tej premiery ma charakter architektoniczny. Aplikacje AI odchodzą od jednego dużego żądania, które próbuje jednocześnie rozumieć, decydować i działać. Łatwiejszy w utrzymaniu system rozdziela te zadania: model może interpretować dowody, ograniczony endpoint decyzyjny może wybierać spośród zweryfikowanych opcji, a zwykłe oprogramowanie może egzekwować uprawnienia i realizować wynik.

Taki podział nie wyeliminuje błędów modeli. Ułatwi jednak ich mierzenie, ograniczanie i korygowanie. Dla większości zespołów to praktyczny powód, by przetestować Decisions — nie dlatego, że każdy proces potrzebuje kolejnego endpointu AI, lecz dlatego, że niektóre procesy potrzebują mniejszej i bardziej rozliczalnej warstwy decyzyjnej.