---
title: "Poproście dostawcę agenta o rejestr decyzji, a nie o pokaz"
url: "https://predictes.com/pl/blog/poproscie-dostawce-agenta-o-rejestr-decyzji-a-nie-o-pokaz"
description: "Pokaz przedstawia agenta w jego najlepszy dzień. Pytania oddzielające dostawcę systemów produkcyjnych od dostawcy pokazów dotyczą złych dni, rejestrów i granic."
---

# Poproście dostawcę agenta o rejestr decyzji, a nie o pokaz

22 sierpnia 2026·3 min czytania·predictes

Pokazy agentów są dziś dobre. Dostawca wybiera zadanie, agent czyta maila, coś sprawdza, przygotowuje odpowiedź i aktualizuje rekord, a sala jest pod wrażeniem. Nic z tego nie dowodzi niczego poza tym, że agent potrafi wykonać zadanie raz, na sprawie, którą ktoś wybrał. Pokaz nie jest nieuczciwy. Po prostu odpowiada na inne pytanie niż to, za którego rozstrzygnięcie płacicie.

Kupujący musi wiedzieć, jak system zachowuje się w złe dni i czy ktokolwiek będzie umiał ustalić, co się stało. Na te pytania da się odpowiedzieć przed podpisaniem umowy, a sposób, w jaki dostawca na nie odpowiada, to większość oceny.

## Pytania, które warto zadać

**Czy możemy zobaczyć rejestr decyzji z prawdziwego przebiegu?** Nie pulpit — zapis tego, co agent zobaczył, co wywnioskował, co zrobił i kto to zatwierdził, dla pojedynczej sprawy. Jeśli osoba spoza projektu nie potrafi go przeczytać i odtworzyć decyzji, po incydencie też nikt nie będzie potrafił.

**Jaki jest poziom błędów i na czym go zmierzono?** Dostawca, który ma zestaw ewaluacyjny z prawdziwych spraw, łącznie z niewygodnymi, powie Wam, jak często agent się myli i w jaki sposób. Dostawca odpowiadający wskaźnikiem trafności z pokazowego zbioru danych albo zapewnieniem takiego zestawu nie zbudował.

**Co dokładnie wolno mu robić?** Granice — dane, które może widzieć, działania, które może podjąć, limity wartości, sprawy zawsze idące do człowieka — powinny istnieć na piśmie i być egzekwowane przez system, a nie przez polecenia dla modelu. Zapytajcie, gdzie są egzekwowane.

**Co się dzieje w dniu, w którym się pomyli?** Powinien istnieć zdefiniowany sposób zawężenia tego, co agent może robić bez nadzoru, runbook i wskazana osoba, którą się wzywa. Obietnica, że „przeanalizujemy sprawę”, nie jest ścieżką ograniczenia.

**Ile trwa jedno zatwierdzenie?** Bramki zatwierdzania przy działaniach nieodwracalnych nie podlegają negocjacji. To, czy działają, zależy od tego, czy człowiek sprawdzi działanie w sekundy, a nie w minuty, bo wolne sprawdzanie zamienia się w przyklepywanie. Poproście o pokazanie ekranu zatwierdzania, a jeśli jeszcze go nie ma, zapytajcie, kto i kiedy go zaprojektuje.

**Co, gdy zmieni się model?** Dostawcy modeli zmieniają się szybko. Model powinien siedzieć za interfejsem, żeby Wasz proces nie był przebudowywany według harmonogramu wydań jednego dostawcy. Zapytajcie, co musieli zmienić ostatnim razem, gdy zmieniali model.

**Co zostaje u nas?** Kod, definicje narzędzi, zestaw ewaluacyjny, rejestry i runbook — w Waszych repozytoriach i Waszej infrastrukturze, z warunkami wyjścia uzgodnionymi na starcie, póki macie siłę negocjacyjną.

-   Prawdziwy rejestr decyzjiZ prawdziwego przebiegu, czytelny dla kogoś spoza projektu.
-   Jawny poziom błędówNa prawdziwych sprawach, z niewygodnymi, a nie wygładzona średnia.
-   Spisane graniceCo może czytać, zmieniać i co musi eskalować — egzekwowane w kodzie.
-   Ścieżka ograniczeniaJak zawęża się autonomię w dniu, w którym coś pójdzie źle.
-   Projekt zatwierdzaniaGdzie potwierdza człowiek i ile trwa jedno potwierdzenie.
-   Wymienialny modelWasz proces przetrwa zmianę dostawcy modelu.
-   Warunki wyjściaKod, narzędzia, zestaw ewaluacyjny i rejestry zostają u Was.

## Jak czytać odpowiedzi

Wzorzec znaczy więcej niż którakolwiek pojedyncza odpowiedź. Dostawca budujący systemy produkcyjne na większość tych pytań odpowie artefaktem: rejestrem, liczbą, dokumentem, ekranem. Dostawca budujący pokazy odpowie opisem tego, co potrafi model.

Konkret wygrywa z efektem. Poziom błędów na nazwanym zbiorze spraw, z pokazanymi najgorszymi przykładami, jest wart więcej niż lepsza liczba bez żadnych przykładów.

Zwróćcie też uwagę, kto odpowiada. Jeśli każde pytanie trafia do osoby, która prowadziła pokaz, a żadne do osoby, która prowadziłaby system, to również jest informacja.

## Ile kosztuje zadanie tych pytań

Popołudnie i trochę niezręczności. Te pytania potrafią uczynić spotkanie handlowe niewygodnym i to jest część ich użyteczności. Dostawca, któremu nie przeszkadzają, zwykle przeszedł już przez prawdziwy incydent i zbudował system z myślą o następnym.

Kosztują też coś dostawcę — i o to chodzi. Pokazanie prawdziwego rejestru decyzji albo uczciwego poziomu błędów wymaga pracy, która istnieje tylko wtedy, gdy system zbudowano tak, żeby to wytwarzał. Dostawca, który potrzebuje kilku tygodni, żeby to przygotować, mówi Wam, jak ten system zbudowano.

## Pytania, które warto najpierw zadać sobie

Część tych pytań wraca do kupującego. Kto w Waszej organizacji będzie czytał rejestry decyzji? Kto będzie zatwierdzał działania i czy ma na to czas w tygodniu? Kto jest właścicielem procesu, w którym agent będzie pracował, i czy będzie czytał eskalacje? Dostawca może zbudować to wszystko dobrze, a agent i tak zawiedzie, jeśli po Waszej stronie nie będzie nikogo, kto to odbierze.

## Jak do tego podchodzimy

Na te właśnie pytania [inżynieria agentów AI](https://predictes.com/pl/services/ai-agents-engineering) ma odpowiadać czymś, co można obejrzeć: definicją zadania i granicy, zestawem ewaluacyjnym zbudowanym przed agentem, projektem zatwierdzania i eskalacji, rejestrami decyzji i runbookiem spisanym, zanim będzie potrzebny.

-   agenci AI
-   wybór dostawcy
-   zakupy
-   rejestr decyzji

## Czytaj dalej

-   [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem)
-   [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)