ROI z AI bez iluzji: nowy scorecard OpenAI

OpenAI opublikowało dziś, 17 lipca 2026 roku, materiał A scorecard for the AI age. Najważniejsza teza jest prosta: liczba kupionych licencji, aktywnych użytkowników i zużytych tokenów nie mówi, czy AI tworzy wartość. Firma proponuje patrzeć na „Useful Intelligence per Dollar”, czyli użyteczną pracę uzyskaną z każdej wydanej jednostki budżetu.

To cenna zmiana perspektywy, ale nie gotowy standard rachunkowości ani niezależna norma. Artykuł jest propozycją dostawcy modeli. Żeby podejście nadawało się do decyzji zarządczych, trzeba przełożyć je na mierzalne zadania, kryteria jakości, pełny koszt oraz ryzyko. Poniżej pokazujemy, jak zbudować scorecard, który nie nagradza samego zużycia AI i nie ukrywa kosztów poprawek, nadzoru czy błędów bezpieczeństwa.

Cztery pytania z dzisiejszego scorecardu OpenAI

OpenAI proponuje, aby liderzy biznesowi i finansowi pytali:

Czy AI wykonuje pracę, która ma znaczenie?
Ile naprawdę kosztuje każde poprawnie zakończone zadanie?
Czy użytkownik może polegać na wyniku?
Czy wraz ze wzrostem użycia każda złotówka kupuje więcej wartości?

Kluczowe jest słowo „poprawnie”. Tańszy token nie musi oznaczać tańszego rezultatu. Model może potrzebować większej liczby prób, dłuższego promptu, pracy specjalisty i ręcznej kontroli. Droższy model może zakończyć zadanie za pierwszym razem. Dlatego jednostką ekonomiczną powinien być wynik spełniający zdefiniowany próg jakości, nie wywołanie API.

Dlaczego dotychczasowe metryki wprowadzają w błąd

Dashboardy wdrożeń AI często eksponują liczbę użytkowników, rozmów, tokenów i zaoszczędzonych minut deklarowanych w ankiecie. Te dane opisują aktywność, lecz nie wartość. Milion tokenów może wytworzyć tysiąc użytecznych odpowiedzi albo tysiąc dokumentów wymagających pełnego przepisania.

Problem ma kilka źródeł:

adopcja nie równa się rezultatowi — użytkownik może otwierać narzędzie, ale nie korzystać z odpowiedzi;
koszt API jest tylko częścią kosztu — pozostają integracje, obserwowalność, ewaluacja, kontrola i poprawki;
średnia ukrywa zadania krytyczne — dobry wynik dla streszczeń nie kompensuje błędu w decyzji finansowej;
samoocena zawyża oszczędności — użytkownik porównuje rezultat z intuicją, nie z wiarygodnym baseline’em;
wolumen może nagradzać marnotrawstwo — więcej prób i tokenów wygląda jak wzrost wykorzystania.

Dlatego program AI powinien zaczynać od katalogu procesów i jednostek pracy. Pomaga w tym rejestr modeli i systemów AI, w którym zapisuje się właściciela, cel, dane, dostawcę, wersję i poziom ryzyka.

Jednostka pomiaru: zakończone zadanie, nie odpowiedź modelu

„Zadanie” musi być na tyle małe, aby dało się ocenić wynik, ale wystarczająco kompletne, aby reprezentowało wartość biznesową. Dla działu obsługi może to być odpowiedź na zgłoszenie zaakceptowana przez konsultanta i klienta. Dla programisty — pull request przechodzący testy i code review. Dla SOC — wzbogacenie alertu zawierające poprawne encje, źródła i rekomendację dalszego kroku.

Każde zadanie powinno mieć:

Element	Przykład definicji
wejście	zgłoszenie, dokument, alert albo wymaganie
oczekiwany rezultat	ustrukturyzowana odpowiedź lub wykonana akcja
próg jakości	poprawność, kompletność, format i źródła
limit ryzyka	dane, których nie wolno ujawnić; akcje wymagające zgody
limit czasu	wynik potrzebny w 5 minut lub do końca dnia
sposób oceny	automat, ekspert, odbiorca albo kombinacja

Bez tej definicji „sukces” staje się uznaniowy. Zespół wybierze przykłady, na których model wypada najlepiej, a koszt nieudanych prób wypadnie z raportu.

Pełny koszt poprawnie zakończonego zadania

Najbardziej praktyczny fragment propozycji OpenAI to odejście od ceny tokenu. Minimalny model kosztowy powinien obejmować:

koszt sukcesu = modele i infrastruktura + praca użytkownika + review + poprawki + ewaluacja + bezpieczeństwo + udział kosztów stałych

Do kosztów bezpośrednich należą wywołania modeli, embeddingi, wyszukiwanie, narzędzia, przechowywanie danych i orkiestracja. Do ludzkich — czas przygotowania danych, promptowania, weryfikacji, eskalacji i ponownej pracy. Koszty platformowe obejmują gateway, logowanie, testy regresji, zarządzanie sekretami, DLP, IAM i utrzymanie integracji.

Jeśli w miesiącu system wykonał 10 000 prób, ale tylko 6 000 wyników spełniło próg, mianownikiem nie może być 10 000. Koszt należy podzielić przez 6 000 sukcesów, a dodatkowo pokazać koszt niepowodzeń. W przeciwnym razie model o dużej liczbie tanich, błędnych odpowiedzi będzie wyglądał lepiej niż system wykonujący mniej prób, ale dostarczający stabilny rezultat.

Trzy klasy wyników zamiast jednej oceny

OpenAI sugeruje śledzić, czy rezultat jest gotowy do użycia, wymaga korekty czy eskalacji. To dobry, prosty początek:

gotowe do użycia — wynik spełnia kryteria bez merytorycznej poprawki;
wymaga korekty — człowiek może szybko poprawić rezultat bez ponownego wykonania procesu;
wymaga eskalacji — wynik jest błędny, ryzykowny albo poza zakresem automatyzacji.

Klasy trzeba doprecyzować dla procesu. Drobna zmiana stylu nie powinna być traktowana jak błąd merytoryczny. Z kolei usunięcie nieprawdziwego cytowania, błędnej kwoty lub ujawnionej danej osobowej nie jest „kosmetyczną korektą”. Warto rejestrować również powód: brak danych, halucynacja, błędne użycie narzędzia, naruszenie polityki, timeout, problem integracji albo niejednoznaczne polecenie.

Techniczny sposób budowy zbiorów testowych i bramek opisujemy w przewodniku ewaluacja LLM: metryki i testy. Scorecard zarządczy powinien korzystać z tych samych testów, a nie tworzyć osobną, łagodniejszą wersję prawdy.

ROI z AI musi obejmować ryzyko

OpenAI wskazuje, że przed skalowaniem trzeba określić dostęp do danych, systemy, z których AI może korzystać lub które może zmieniać, oraz momenty wymagające zgody człowieka. To nie jest dodatek do ekonomii. Ryzyko ma mierzalny koszt.

Błąd agenta wykonującego przelew, zmianę konfiguracji lub publikację kodu może przekroczyć wszystkie wcześniejsze oszczędności. Dlatego scorecard powinien zawierać co najmniej:

liczbę i wagę naruszeń polityki danych;
odsetek akcji wysokiego ryzyka zatrzymanych przez bramkę zgody;
nieautoryzowane wywołania narzędzi i błędy uprawnień;
wyniki testów prompt injection i odporności na zatrute dane;
czas wykrycia, zatrzymania i odtworzenia po błędnej akcji;
kompletność logów pozwalających odtworzyć decyzję agenta.

NIST w dobrowolnym AI Risk Management Framework organizuje zarządzanie ryzykiem wokół funkcji Govern, Map, Measure i Manage. Profil NIST dla generatywnej AI rozszerza to podejście o ryzyka właściwe GenAI i działania w całym cyklu życia. Propozycję ekonomiczną OpenAI warto więc osadzić w szerszym systemie zarządzania ryzykiem, zamiast traktować ją jako samodzielną kontrolę.

Przykładowy scorecard dla jednego procesu

Obszar	Metryka	Dlaczego jest potrzebna
wartość	liczba zadań spełniających próg jakości	pokazuje rzeczywistą dostawę
jakość	gotowe / korekta / eskalacja	ujawnia zależność od człowieka
koszt	pełny koszt na poprawne zadanie	umożliwia porównanie wariantów
czas	mediana i p95 czasu zakończenia	nie ukrywa długiego ogona
ryzyko	incydenty i naruszenia polityki na 1000 zadań	łączy skalę z bezpieczeństwem
niezawodność	odsetek timeoutów i błędów integracji	mierzy warstwę systemową
kontrola	pokrycie testami i logami	mówi, czy wynik da się obronić
ekonomia skali	koszt sukcesu w kolejnych miesiącach	sprawdza obietnicę poprawy

Nie łącz wszystkich pól w jeden „AI score” bez pokazania składowych. Waga ryzyka jest zależna od procesu, a jedna liczba pozwala ukryć krytyczny regres za dobrym wynikiem kosztowym.

Jak porównywać modele i architektury

Test powinien obejmować cały system: prompt, retrieval, narzędzia, zabezpieczenia, model i review. Porównywanie samych modeli na publicznym benchmarku nie odpowiada na pytanie o firmowy proces. Użyj zamrożonego zbioru zadań, tej samej definicji sukcesu i pełnego kosztu.

W praktyce warto porównać co najmniej:

proces bez AI jako baseline;
mały, tani model bez routingu;
model mocniejszy dla wszystkich zadań;
router modeli AI, który eskaluje trudne przypadki;
wariant z obowiązkowym review dla działań wysokiego ryzyka.

Raportuj przedział niepewności i liczebność próby. Różnica kilku punktów procentowych na kilkunastu przykładach nie uzasadnia migracji. Test obejmujący tylko łatwe zadania nie przewidzi zachowania na przypadkach rzadkich i kosztownych.

Plan wdrożenia na 30, 60 i 90 dni

Pierwsze 30 dni: definicja i baseline

Wybierz jeden proces o wystarczającym wolumenie. Zdefiniuj zadanie, właściciela, próg jakości i niedozwolone skutki. Zmierz wariant bez AI: czas, koszt, błędy i eskalacje. Uzupełnij zasady bezpiecznego wdrażania AI w firmie oraz zinwentaryzuj Shadow AI, korzystając z praktycznego przewodnika wykrywania.

Dni 31–60: instrumentacja i test kontrolowany

Dodaj identyfikator zadania, wersję promptu, model, koszty, opóźnienie, użyte narzędzia, decyzję review i przyczynę niepowodzenia. Uruchom ograniczony pilotaż na ruchu, który można bezpiecznie zweryfikować. Nie pozwalaj systemowi samodzielnie wykonywać nieodwracalnych akcji. Obserwowalność agentów można oprzeć na wzorcach opisanych w tekście OpenTelemetry dla agentów AI.

Dni 61–90: decyzja o skali

Porównaj pełny koszt sukcesu z baseline’em, zbadaj rozkład jakości oraz incydenty. Zwiększaj ruch dopiero po spełnieniu bramek. Ustal automatyczny rollback po regresie kosztu, jakości albo bezpieczeństwa. Jeśli wartość rośnie wyłącznie dlatego, że pracownicy wykonują niewidoczny review po godzinach, pilotaż nie udowodnił ROI.

Najczęstsze pułapki scorecardu AI

Pierwsza to wybieranie wygodnego mianownika. Koszt na użytkownika wygląda dobrze przy dużej liczbie kont, nawet gdy niewiele zadań kończy się sukcesem. Druga to pomijanie pracy po wdrożeniu: ręczna korekta i obsługa eskalacji znikają w budżecie innego działu. Trzecia to zmiana testu razem z modelem, przez co każda wersja zdaje własny, łatwiejszy egzamin.

Czwarta pułapka to optymalizacja metryki kosztem celu. Jeśli premiujesz liczbę zamkniętych zgłoszeń, system może generować krótkie odpowiedzi i szybciej oznaczać sprawy jako rozwiązane. Potrzebna jest metryka jakości z perspektywy odbiorcy oraz kontrola ponownych otwarć. Piąta to nieuwzględnianie incydentów o małej częstotliwości, ale wielkim skutku.

Co dzisiejsza publikacja zmienia dla firm

Najcenniejsza część propozycji OpenAI nie polega na nowym haśle. Polega na przesunięciu uwagi z zakupu i użycia narzędzia na dostarczoną pracę. CFO, CISO i właściciel procesu mogą wreszcie patrzeć na ten sam mianownik: poprawnie wykonane zadanie o znanym koszcie i ryzyku.

„Useful Intelligence per Dollar” warto traktować jako hipotezę pomiarową. Organizacja musi zdefiniować, co znaczy „useful”, jakie błędy są niedopuszczalne i kto ponosi pełny koszt. Dopiero wtedy wykres pokazuje ekonomię systemu, a nie skuteczność marketingu adopcyjnego.

Chcesz sprawdzić, czy firmowy agent AI daje powtarzalny rezultat bez ukrytego ryzyka? Umów audyt bezpieczeństwa AI z BreachRoad — zbudujemy scenariusze ewaluacyjne, przetestujemy granice uprawnień, logowanie i odporność na nadużycia, a wyniki połączymy z mierzalnym scorecardem procesu.