Budżet błędów w systemach AI

Budżet błędów to dopuszczalna część niespełnionego celu usługi w konkretnym czasie. Najczęściej wynika z SLO, czyli mierzalnego poziomu usługi. Jeśli automatyzacja ma SLO 99,5% poprawnie obsłużonych zapisów na konsultację w miesiącu, jej budżet błędów wynosi 0,5% wszystkich zapisów w tym miesiącu. To nie jest zachęta do psucia procesu ani licznik każdego błędu technicznego. To wspólna reguła, kiedy tempo zmian przestaje być ważniejsze od odzyskania zaufania użytkownika. Google SRE opisuje error budget jako narzędzie równoważące niezawodność z tempem innowacji.

W systemie AI najpierw zdefiniuj zdarzenie, które użytkownik naprawdę odczuwa. Dla agenta kwalifikującego leady może to być przekazanie kompletnego leada do CRM w ciągu pięciu minut. Dla asystenta tworzącego oferty może to być wygenerowanie pliku z wymaganymi polami, a nie samo wywołanie modelu zakończone kodem 200. Błąd modelu, timeout API i brak wymaganej informacji mogą mieć różne skutki, lecz wszystkie mogą oznaczać, że obietnica wobec klienta nie została spełniona. Mierz wynik procesu, nie tylko zdrowie pojedynczego webhooka.

Praktyczny przykład: w miesiącu wpada 400 formularzy, a SLO mówi, że 99% ma zostać poprawnie zapisanych w CRM i otrzymać potwierdzenie. Budżet wynosi cztery formularze. Gdy czwarty przypadek zostanie utracony lub obsłużony poza celem, nie dodawaj w tym samym tygodniu nowego modelu, dodatkowego agenta ani eksperymentalnego kroku personalizacji. Najpierw sprawdź przyczynę i przywróć margines bezpieczeństwa. Jeżeli błąd był wykryty i człowiek ręcznie odzyskał kontakt w czasie obiecanym klientowi, warto wcześniej zdecydować, czy taki przypadek liczy się jako naruszenie SLO. Reguła musi być zapisana przed incydentem.

Budżet błędów nie zastępuje alertów, obserwowalności ani limitu czasu. Alert informuje, że problem dzieje się teraz. Obserwowalność pomaga znaleźć jego przyczynę w śladach, metrykach i logach. Timeout chroni workflow przed czekaniem bez końca. Budżet podejmuje decyzję produktową: czy w obecnym stanie wolno zwiększać ryzyko zmian. Te elementy powinny współpracować. Bez alertu możesz odkryć problem za późno, bez obserwowalności nie wiesz, co naprawić, a bez budżetu zespół stale wybiera nowe funkcje, mimo że klienci już płacą za niestabilność.

Dla solopreneurki liczba nie musi być skomplikowana. Zacznij od jednego krytycznego przepływu i okna tygodniowego albo miesięcznego. Zapisuj liczbę wszystkich kwalifikujących się spraw, liczbę niespełnionych obietnic, przyczynę oraz to, czy klient został odzyskany. Ustal trzy stany: zielony, gdy budżet jest bezpieczny, żółty, gdy ograniczasz eksperymenty, i czerwony, gdy wstrzymujesz zmiany oraz naprawiasz proces. Stan czerwony nie powinien oznaczać zatrzymania całego biznesu. Może oznaczać przełączenie na prostszy fallback, ręczną kontrolę lub ograniczenie automatycznego działania tylko dla ryzykownego kroku.

Największy błąd to wybrać SLO wyłącznie dlatego, że brzmi ambitnie. Cel 99,99% dla automatyzacji prowadzonej przez kilka zewnętrznych narzędzi może tworzyć presję na kosztowne rozwiązania, które nie zwiększają wartości dla klienta. Z kolei brak celu ukrywa powtarzalne straty pod etykietą „pojedynczych błędów”. Google SRE podkreśla, że SLO powinno opierać się na doświadczeniu użytkownika, a polityka budżetu powinna określać konsekwencję jego wyczerpania. Wybierz poziom, który odpowiada realnej obietnicy oferty i kosztowi pomyłki, a później aktualizuj go na podstawie danych.

Nie traktuj też każdego błędu jednakowo. Jedno błędne wysłanie prywatnych danych, podwójne obciążenie karty lub nieprawidłowa publikacja może wymagać natychmiastowego zatrzymania automatyzacji niezależnie od pozostałego budżetu. Budżet jest dobry dla powtarzalnej jakości usługi, nie dla zastępowania zasad bezpieczeństwa, kontroli dostępu czy oceny ryzyka. W systemach z AI oddziel błędy jakości odpowiedzi od błędów operacyjnych. Niska jakość może potrzebować zestawu testowego i zatwierdzania przez człowieka, a awaria integracji retry, fallbacku lub kolejki błędów.

Wdrożenie zacznij od jednej tabeli lub dashboardu. Wpisz nazwę przepływu, obietnicę dla użytkownika, SLO, okres, liczbę spraw, wykorzystany budżet i decyzję na kolejny tydzień. Dodaj właściciela każdego kroku oraz link do logu incydentu. Gdy budżet jest prawie wyczerpany, przestań optymalizować prompty na ślepo. Przejdź przez ostatnie niespełnione sprawy, sprawdź timeouty, fallback i ręczny proces odzyskania klienta. Dopiero po takiej pętli możesz uczciwie powiedzieć, że automatyzacja jest gotowa na większy ruch.