Agenci AI: wzorzec „plan → wykonanie → dowody” — jak wymusić załączanie źródeł i artefaktów pracy

1. Wprowadzenie: dlaczego schemat „plan → wykonanie → dowody” podnosi jakość pracy agentów AI

Agenci AI potrafią szybko generować odpowiedzi i podejmować działania, ale w środowisku firmowym liczy się nie tylko wynik, lecz także przewidywalność, kontrola ryzyka i możliwość audytu. W praktyce największe problemy pojawiają się wtedy, gdy rezultat wygląda wiarygodnie, ale nie wiadomo, skąd się wziął, jakie założenia przyjęto, co zostało pominięte i czy agent wykonał pracę zgodnie z oczekiwaniami. Wzorzec „plan → wykonanie → dowody” porządkuje współpracę z agentem tak, aby minimalizować te ryzyka.

Ten schemat nie jest tylko formatem odpowiedzi. To sposób prowadzenia pracy, w którym agent najpierw ujawnia intencję i strategię, potem realizuje zadanie w kontrolowanych krokach, a na końcu dołącza materialne potwierdzenia (źródła, linki, logi, pliki, obliczenia, wyniki zapytań), dzięki którym można zweryfikować poprawność i odtworzyć proces.

• Plan pomaga uzgodnić kierunek, zakres i kryteria sukcesu zanim agent „pójdzie za daleko” w nieodwracalne działania lub kosztowne analizy.
• Wykonanie rozdziela pracę na obserwowalne kroki, co ułatwia kontrolę postępu, korekty w trakcie oraz powtarzalność.
• Dowody przenoszą wynik z poziomu deklaracji na poziom weryfikowalnych faktów: pokazują, co agent sprawdził, na czym się oparł i jakie artefakty wytworzył.

W porównaniu z „jednym strzałem” (agent generuje finalną odpowiedź bez ujawnienia procesu), podejście „plan → wykonanie → dowody” wprowadza trzy kluczowe usprawnienia jakości:

• Redukcja halucynacji i błędów pozornie wiarygodnych: wymóg dowodów zmusza do oparcia się na sprawdzalnych danych albo jasnego oznaczenia niepewności.
• Lepsza zgodność z oczekiwaniami biznesu: plan działa jak kontrakt na zakres i priorytety, co zmniejsza ryzyko dostarczenia „dobrego, ale nie tego” rezultatu.
• Audytowalność i odpowiedzialność: dowody tworzą ścieżkę uzasadnienia, dzięki której wynik można zatwierdzić, zaskarżyć, poprawić lub odtworzyć w przyszłości.

Wzorzec jest szczególnie użyteczny w zadaniach, gdzie stawką są decyzje, koszty lub reputacja: przygotowanie rekomendacji, analiza rynku i konkurencji, research prawny i regulacyjny, raporty dla zarządu, tworzenie treści wymagających rzetelnych źródeł, a także automatyzacje operacyjne, w których agent wykonuje działania w systemach. W takich przypadkach „dowody” nie są dodatkiem — są elementem produktu.

Warto też podkreślić różnicę między dowodem a wyjaśnieniem. Wyjaśnienie to opis rozumowania, który może brzmieć przekonująco. Dowód to coś, co da się sprawdzić niezależnie: cytowanie źródła, wynik zapytania, link do dokumentu, identyfikator ticketu, zrzut kluczowych danych, lista zmian w pliku, zapis logów. Ten nacisk na weryfikowalność jest fundamentem zaufania do agentów AI w organizacji.

Wdrożenie schematu „plan → wykonanie → dowody” przynosi również korzyści organizacyjne: ułatwia współpracę między zespołami, standaryzuje raportowanie rezultatów i skraca czas weryfikacji przez człowieka. Zamiast pytać „dlaczego tak?”, można od razu przejść do „pokaż podstawę i artefakty”, a jeśli coś się nie zgadza — szybko zlokalizować etap, na którym pojawił się błąd.

2. Architektura agenta w firmie: role, odpowiedzialności i granice działania (guardrails)

Żeby schemat „plan → wykonanie → dowody” działał w praktyce, agent AI nie może być traktowany jak „uniwersalny pracownik”, tylko jak komponent procesu z jasno zdefiniowaną rolą. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity. Architektura wdrożenia w firmie powinna odpowiadać na trzy pytania: kto deleguje zadanie, co agent może wykonać samodzielnie, oraz gdzie kończy się jego mandat i zaczyna odpowiedzialność człowieka lub innego systemu.

Role w ekosystemie agenta

W dojrzałym wdrożeniu agent funkcjonuje w otoczeniu kilku ról (czasem łączonych w jednej osobie), które porządkują odpowiedzialność i ułatwiają audyt:

• Właściciel biznesowy (process owner) – definiuje cel, kryteria sukcesu i akceptacji rezultatu oraz ryzyka, których nie wolno podejmować. Decyduje, gdzie agent realnie zwiększa przepustowość, a gdzie jest zbyt ryzykowny.
• Właściciel produktu / wdrożenia (product/solution owner) – przekłada potrzeby biznesu na zakres funkcji agenta, decyduje o tym, jakie zadania są automatyzowane, a jakie pozostają w rękach człowieka.
• Opiekun merytoryczny (SME) – dostarcza wiedzę dziedzinową, przykładowe dobre odpowiedzi oraz typowe pułapki. Jest kluczowy tam, gdzie liczą się niuanse: regulacje, język branżowy, standardy dokumentacji.
• Bezpieczeństwo / zgodność (security & compliance) – ustala zasady dostępu do danych, klasyfikację informacji, wymagania dot. logów i retencji, ograniczenia użycia zewnętrznych źródeł.
• IT / platforma – zapewnia środowisko uruchomieniowe, integracje z narzędziami, kontrolę uprawnień, monitorowanie i niezawodność.
• Użytkownik końcowy (operator) – inicjuje zadania, weryfikuje rezultat w zakresie swojej odpowiedzialności oraz zgłasza błędy i przypadki brzegowe.
• Reviewer / approver – rola kontrolna, która formalnie zatwierdza wyniki w obszarach krytycznych (np. komunikacja z klientem, treści prawne, decyzje finansowe).

Taki podział minimalizuje typowy problem wdrożeń: „agent coś zrobił” bez jasności, kto odpowiada za efekt, dane wejściowe i decyzję o publikacji.

Zakres odpowiedzialności agenta: co jest „pracą”, a co „decyzją”

Agent AI najlepiej traktować jako wykonawcę pracy poznawczej o ograniczonym mandacie: porządkuje informacje, generuje warianty, przygotowuje szkice, streszcza, klasyfikuje i proponuje następne kroki. W firmowej architekturze warto rozdzielić:

• Wykonanie operacyjne – działania odwracalne i niskiego ryzyka (np. przygotowanie materiałów roboczych, uzupełnienie pól w formularzu, analiza wstępna).
• Decyzje i zobowiązania – działania nieodwracalne lub wysokiego ryzyka (np. wysyłka do klienta, publikacja, zmiany w systemach produkcyjnych, zatwierdzanie kosztów). Te punkty powinny wymagać zatwierdzenia człowieka lub dodatkowej walidacji.

Praktyczna zasada: agent może rekomendować, ale nie powinien autorytatywnie rozstrzygać w obszarach, gdzie konsekwencje błędu są istotne reputacyjnie, prawnie lub finansowo.

Granice działania (guardrails): polityki, uprawnienia i „bezpieczne domyślne”

Guardrails to zestaw ograniczeń, które mają sprawić, że nawet przy nieidealnym poleceniu użytkownika agent zachowa się przewidywalnie. W architekturze firmowej obejmują one co najmniej trzy warstwy:

• Granice zadania – definicja, jakie typy spraw agent obsługuje, a jakich nie (np. brak porad prawnych/medycznych, brak decyzji kadrowych, brak negocjacji cen). Ważne jest też wskazanie, kiedy agent ma przerwać i eskalować.
• Granice danych – do jakich repozytoriów agent ma dostęp, jakiej klasy danych nie wolno mu przetwarzać, oraz jakie fragmenty odpowiedzi muszą być redagowane lub anonimizowane.
• Granice działań – jakie operacje agent może wykonać w narzędziach (odczyt, zapis, uruchomienie akcji), z jakimi limitami (np. brak masowych zmian, brak operacji poza sandboxem, brak wysyłek bez zatwierdzenia).

Bezpieczne domyślne zachowanie oznacza m.in.: w razie niepewności agent wybiera wariant najmniej ryzykowny, prosi o doprecyzowanie, a nie „domyśla się” intencji.

Uprawnienia i separacja środowisk: mniej znaczy lepiej

W praktyce największym źródłem incydentów jest nadmiar uprawnień. Architektura powinna opierać się na zasadach:

• Najmniejszych uprawnień – agent dostaje dokładnie taki dostęp, jaki jest konieczny do wykonania zadania, i nic więcej.
• Separacji środowisk – inne reguły i dostępy dla eksperymentów, testów i produkcji; ograniczanie skutków ubocznych działań agenta.
• Jawnego zakresu kontekstu – użytkownik i organizacja powinni wiedzieć, z jakich źródeł agent może korzystać i jak szeroki jest jego kontekst, by nie powstało złudzenie „wszechwiedzy”.

To fundament nie tylko bezpieczeństwa, ale i jakości: agent z ograniczonym, dobrze dobranym kontekstem rzadziej „dopowiada” brakujące fakty.

Odpowiedzialność za wynik: agent jako współautor, nie właściciel

W firmie trzeba jasno rozstrzygnąć, kto odpowiada za rezultat końcowy. Dobre ustawienie ról zakłada, że:

• agent jest współautorem treści lub analizy,
• użytkownik jest operatorem i odpowiada za poprawność użycia narzędzia,
• reviewer/approver jest punktem kontrolnym dla ryzyka i jakości.

Takie przypisanie odpowiedzialności ogranicza zjawisko „zrzucania winy” na model i wymusza projektowanie procesu pod kontrolę jakości.

Wzorce wdrożeniowe: asystent, agent wykonawczy, agent wieloetapowy

W zależności od ryzyka i dojrzałości organizacji agent może działać w różnych konfiguracjach:

• Asystent – wspiera użytkownika, ale nie wykonuje akcji w systemach; dobry start dla zespołów, które chcą szybko zwiększyć produktywność bez automatyzacji operacji.
• Agent wykonawczy – może realizować ograniczone akcje w narzędziach (np. tworzyć zgłoszenia, aktualizować rekordy) w ramach ściśle zdefiniowanych uprawnień.
• Agent wieloetapowy – rozbija zadanie na kroki, deleguje podzadania i składa wynik; sprawdza się w procesach z wieloma zależnościami, ale wymaga najsilniejszych guardrails.

Dobór wzorca jest decyzją architektoniczną: im więcej autonomii, tym większa potrzeba ograniczeń, monitorowania i formalnych punktów zatwierdzania.

Minimalny „kontrakt” działania agenta w organizacji

Nawet bez rozbudowanej implementacji warto zdefiniować krótki kontrakt: cel agenta, dozwolone i niedozwolone zadania, zakres danych, poziom autonomii, warunki eskalacji oraz kto zatwierdza wynik. Taki kontrakt ułatwia spójne wdrożenie w różnych zespołach i zapobiega rozjechaniu się oczekiwań między biznesem, IT i bezpieczeństwem.

3. Projektowanie promptów wymuszających strukturę: plan, kroki wykonania, artefakty i źródła

Jeśli agent ma dostarczać wyniki, które da się sprawdzić, odtworzyć i zacytować, sam „dobry prompt” nie wystarczy. Potrzebujesz promptu, który wymusza format pracy: najpierw plan, potem wykonanie, a na końcu dowody (artefakty i źródła). Taka struktura ogranicza „ładnie brzmiące” odpowiedzi bez pokrycia, bo model musi pokazać co zrobił i na czym się oparł.

3.1. Trzy warstwy promptu: instrukcja, format, kryteria

Najskuteczniejsze prompty mają trzy równoległe elementy:

• Instrukcja zadaniowa — co agent ma osiągnąć (cel, kontekst, ograniczenia).
• Wymuszony format odpowiedzi — jak ma raportować (sekcje: Plan / Wykonanie / Dowody).
• Kryteria kompletności — kiedy odpowiedź jest nieakceptowalna (np. brak źródeł, brak artefaktów, brak wskazania niepewności).

Kluczowe jest rozdzielenie „co” od „jak”: nawet gdy zadania się zmieniają, format i kryteria pozostają stałe, dzięki czemu raporty agentów są porównywalne.

3.2. Różne zastosowania: prompt do analizy vs prompt do działania

W praktyce spotkasz dwa podstawowe zastosowania promptów strukturalnych:

• Tryb analityczny (research/opracowanie) — nacisk na cytowania, selekcję źródeł, argumentację i ślad decyzyjny.
• Tryb wykonawczy (operacje) — nacisk na kroki, komendy, parametry, wyniki narzędzi i artefakty (pliki, logi, zrzuty).

Oba tryby mogą używać schematu „plan → wykonanie → dowody”, ale różnią się tym, co uznają za dowód: w analizie będą to cytowania i notatki z lektury, a w wykonaniu — rezultaty narzędzi i namacalne artefakty pracy.

3.3. Minimalny szablon promptu wymuszający „plan → wykonanie → dowody”

Poniżej znajduje się prosty szkielet, który można wklejać do większości zadań. Najważniejsze: narzucasz sekcje i zakazujesz „gołych” stwierdzeń bez przypisanych źródeł/artefaktów.

Jesteś agentem. Wykonaj zadanie: {OPIS_ZADANIA}.

Wymagany format odpowiedzi (nie zmieniaj nagłówków):
1) PLAN
- 3–7 punktów, co zrobisz i w jakiej kolejności.

2) WYKONANIE
- Opisz wykonane kroki (numerowane), podaj wejścia/wyjścia, założenia oraz decyzje.
- Jeśli czegoś nie da się wykonać, napisz co blokuje i jak to obejść.

3) DOWODY
A) ARTEFAKTY
- Lista plików/fragmentów/raportów, które powstały (nazwa + krótki opis + gdzie się znajdują).
B) ŹRÓDŁA
- Każde istotne twierdzenie opatrz źródłem (link/tytuł/identyfikator) i wskaż, co z niego wynika.

Zasady:
- Jeśli nie masz źródła lub artefaktu dla tezy, oznacz ją jako hipotezę.
- Nie pomijaj sekcji DOWODY.

3.4. Jak wymuszać źródła: reguły cytowania w promptach

Najczęstszy błąd to ogólne „podaj źródła na końcu”. Skuteczniejsze są reguły, które wiążą źródło z tezą:

• Cytowanie przy twierdzeniu — wymagaj przypisu bezpośrednio przy zdaniu lub w podpunkcie, zamiast zbiorczej bibliografii.
• Oznaczanie statusu — „źródło”, „obserwacja z narzędzia”, „założenie”, „hipoteza”. To zmusza model do jawności.
• Zakaz autorytetu modelu — wprost: „nie używaj sformułowań typu ‘wiadomo, że…’ bez wskazania źródła”.

W promptach warto też doprecyzować, co uznajesz za źródło: dokumenty wewnętrzne, linki publiczne, identyfikatory ticketów, fragmenty specyfikacji. To redukuje „źródła” w stylu ogólnych haseł bez możliwości weryfikacji.

3.5. Jak wymuszać artefakty: definicja „dowodu pracy”

Artefakt to materialny efekt działania agenta, który można obejrzeć lub uruchomić. W promptach dobrze działa prosta zasada: „jeśli coś deklarujesz, pokaż co powstało”. Przykładowe artefakty (zależnie od zadania):

• tabela porównawcza, lista wymagań, streszczenie w ustalonym formacie,
• fragmenty konfiguracji, komendy i ich wyniki,
• pliki (np. CSV/JSON/MD), szkic specyfikacji, notatka decyzyjna.

W promptach doprecyzuj minimalny zestaw: np. „zawsze wygeneruj tabelę + checklistę” albo „zawsze dołącz dane wejściowe i wyjściowe”. Dzięki temu agent nie kończy na opisie zamiast rezultatu.

3.6. Porównanie: luźny prompt vs prompt strukturalny

3.7. Wzorce „twardych” wymagań, które warto dopisać do promptu

Żeby struktura działała konsekwentnie, dopisz do promptu krótkie, egzekwowalne reguły:

• „Brak źródeł = hipoteza” — agent nie może przedstawiać domysłów jako faktów.
• „Każdy wynik ma mieć artefakt” — nawet jeśli to tylko tabela lub lista decyzji.
• „Oddziel fakty od rekomendacji” — w wykonaniu opisujesz co zrobiono, w dowodach na czym to stoi.
• „Nie zmieniaj formatu” — stałe nagłówki i kolejność sekcji ułatwiają automatyczne sprawdzanie.

To są proste zapisy, ale robią największą różnicę: przesuwają agenta z trybu „generowania odpowiedzi” do trybu „raportowania pracy”.

4. Workflow i orkiestracja: narzędzia, pamięć, handoffy oraz standardy raportowania wyników

Sam wzorzec „plan → wykonanie → dowody” nie zadziała konsekwentnie bez procesu, który go egzekwuje. Workflow i orkiestracja to warstwa, która porządkuje kolejność kroków, kontroluje użycie narzędzi, zarządza pamięcią i wymusza jednolity format raportowania. Dzięki temu agent nie tylko „dochodzi do odpowiedzi”, ale robi to w sposób powtarzalny i możliwy do odtworzenia (z artefaktami). Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — najczęściej nie w samym planowaniu, lecz w konsekwentnym dopinaniu dowodów i utrzymaniu standardu raportu w każdym zadaniu.

Narzędzia: kiedy agent powinien wywołać systemy zewnętrzne

W praktycznych wdrożeniach agent rzadko działa wyłącznie „w głowie”. Orkiestracja definiuje jakie narzędzia są dostępne oraz w jakich momentach wolno ich użyć (np. najpierw analiza, potem pobranie danych, na końcu zapis artefaktów). Najczęstsze klasy narzędzi w workflow:

• Retrieval / wyszukiwanie (wewnętrzne repozytoria, bazy wiedzy, indeksy dokumentów) – do uzyskania cytowalnych fragmentów i uniknięcia „wiedzy z pamięci modelu”.
• Narzędzia danych (SQL, API, pliki, hurtownie) – do policzalnych wyników i zrzutów danych jako dowodów.
• Egzekucja kodu (np. sandbox, notebook) – gdy wymagane są obliczenia, transformacje, generowanie wykresów.
• Narzędzia tworzenia artefaktów (zapisy plików, generowanie raportów, eksport tabel) – aby „dowody” były materialne i możliwe do pobrania.
• Narzędzia komunikacyjne (ticketing, e-mail, chat) – do przekazywania wyników i statusów w ustandaryzowany sposób.

W tym miejscu kluczowe są różnice zastosowań: retrieval odpowiada za źródła tekstowe, dane/kod za wyniki obliczeń, a generowanie artefaktów za „opakowanie” dowodów w pliki i linki. Szczegóły typów artefaktów i ścieżki audytu są domeną kolejnych tematów; tu ważne jest, że workflow powinien jasno rozdzielać te obowiązki.

Pamięć: co zachowywać, gdzie i jak długo

Orkiestracja określa, jak agent korzysta z pamięci, aby nie mieszać kontekstu między zadaniami i jednocześnie nie tracić istotnych ustaleń. W uproszczeniu można wyróżnić:

• Pamięć krótkotrwałą (kontekst sesji) – bieżące kroki, aktualny plan, stan wykonania.
• Pamięć długotrwałą – stabilne fakty organizacyjne (np. definicje KPI, słowniki pojęć, polityki), które powinny być wersjonowane i weryfikowalne.
• Pamięć zadaniową – powiązaną z konkretnym zleceniem: decyzje, parametry, linki do artefaktów, ID zgłoszeń.

Różnica praktyczna: pamięć sesji służy sterowaniu krokami, pamięć długotrwała – spójności organizacyjnej, a pamięć zadaniowa – odtwarzalności (kto, co, kiedy, na podstawie czego). Dobrze zaprojektowany workflow nie pozwala, by agent „zapamiętywał” niezweryfikowane ustalenia jako trwałe fakty; zamiast tego kieruje je do warstwy źródeł lub artefaktów.

Handoffy: przekazywanie pracy między agentami i człowiekiem

Wzorzec „plan → wykonanie → dowody” szczególnie zyskuje, gdy praca jest dzielona na role (np. agent zbierający dane, agent analizujący, agent redagujący). Orkiestracja definiuje handoff, czyli minimalny pakiet informacji przekazywany dalej, aby kolejny wykonawca nie musiał „domyślać się” kontekstu.

Handoff powinien zawierać przede wszystkim:

• Stan: co już zrobiono, co jest w toku, co zostało pominięte i dlaczego.
• Plan następnych kroków: co ma zostać wykonane jako kolejne i jakie są warunki zakończenia.
• Dowody: linki/ID do artefaktów, cytowania źródeł, wyniki zapytań, logi narzędzi (w zakresie niezbędnym do kontynuacji).
• Ryzyka i niepewności: elementy wymagające walidacji lub decyzji człowieka.

Najczęstsze zastosowania handoffów:

• Agent → agent: gdy rozdzielasz zbieranie danych od analizy lub generowanie treści od kontroli jakości.
• Agent → człowiek: gdy potrzebna jest decyzja biznesowa, akceptacja ryzyka, dostęp do systemu lub interpretacja wymagań.
• Człowiek → agent: gdy doprecyzowujesz kryteria lub dostarczasz brakujące wejścia; workflow powinien wymusić, by te wejścia zostały zapisane jako część „dowodów” zadania.

Standardy raportowania: ujednolicony wynik zamiast „ściany tekstu”

Orkiestracja jest także „kontraktem” na format odpowiedzi. Standard raportowania powinien być na tyle sztywny, by dało się automatycznie ocenić kompletność, ale na tyle prosty, by nie obciążał operacyjnie. W praktyce sprawdza się raport, który rozdziela: rezultat, plan/wykonanie oraz dowody (linki, cytaty, artefakty).

Minimalny szablon raportu (niezależny od narzędzi) może wyglądać tak:

WYNIK
- 1–3 zdania podsumowania

STATUS
- Done / Blocked / Needs review

WYKONANE KROKI (SKRÓT)
- krok 1: ...
- krok 2: ...

DOWODY
- Źródła: [link/cytat/ID dokumentu]
- Artefakty: [link/ścieżka/ID pliku]
- Logi narzędzi (jeśli dotyczy): [ID uruchomienia / zapytania]

OTWARTE KWESTIE
- co wymaga decyzji lub doprecyzowania

Istotna różnica względem zwykłej odpowiedzi: raport ma część operacyjną (status, kroki, otwarte kwestie) oraz część audytowalną (dowody). Nawet jeśli użytkownik końcowy czyta tylko „WYNIK”, organizacja nadal zyskuje powtarzalność i możliwość kontroli.

Workflow jako „stan maszyny”: etapy, bramki i reguły przejść

Najprostszy, a jednocześnie skuteczny sposób orkiestracji to potraktowanie pracy agenta jako sekwencji etapów z bramkami (gates). Na poziomie wysokim często wystarcza:

• Wejście: walidacja wymagań, kompletność danych wejściowych.
• Plan: rozpisanie kroków i przypisanie narzędzi do kroków.
• Wykonanie: praca narzędziowa, zbieranie wyników cząstkowych.
• Zebranie dowodów: konsolidacja linków, cytowań, plików, identyfikatorów uruchomień.
• Raport: rezultat w standardzie organizacji + status + otwarte kwestie.

Orkiestracja nie musi oznaczać skomplikowanej platformy. Może to być reguła w aplikacji, skrypt, pipeline lub prosta automatyzacja, o ile konsekwentnie egzekwuje: brak przejścia dalej bez dowodów oraz jednolity format raportu.

Porównanie podejść orkiestracyjnych (w skrócie)

5. Artefakty i dowody: typy, formaty, wersjonowanie oraz ścieżka audytu

Wzorzec „plan → wykonanie → dowody” działa tylko wtedy, gdy agent potrafi zostawić po sobie sprawdzalny ślad. W praktyce oznacza to konsekwentne rozróżnienie dwóch kategorii: artefaktów (to, co agent wytworzył) oraz dowodów (to, co uzasadnia, że wynik jest prawidłowy i skąd pochodzi). Bez tej warstwy łatwo o „ładny raport”, którego nie da się zweryfikować, odtworzyć ani audytować.

Artefakty vs dowody: szybkie rozróżnienie

• Artefakt = rezultat pracy, który ma być użyty dalej (np. plik, dokument, fragment kodu, zestaw danych, diagram, ticket, konfiguracja).
• Dowód = materiał umożliwiający weryfikację, że artefakt jest oparty na faktach i wykonany zgodnie z wymaganiami (np. cytowania do źródeł, logi wywołań narzędzi, wyniki testów, linki do commitów, zrzuty/eksporty, hash plików).

W wielu zadaniach artefakt i dowód powinny współistnieć w jednym pakiecie: np. „raport.pdf” (artefakt) + „sources.md, logs.json, test-results.xml” (dowody).

Typy artefaktów i typy dowodów (oraz kiedy je stosować)

Formaty: dlaczego „czytelne” to nie zawsze „audytowalne”

Format powinien odpowiadać temu, czy artefakt ma być czytany, przetwarzany automatycznie, czy archiwizowany. Dla audytu liczy się też stabilność i jednoznaczność.

• Do przeglądu przez człowieka: HTML/PDF/Markdown (łatwe w lekturze; PDF bywa wygodny jako „zamrożony” snapshot).
• Do automatycznej weryfikacji: JSON/YAML/CSV (łatwe do parsowania; umożliwiają checklisty i walidacje).
• Do danych i powtarzalności: Parquet/JSONL (lepsze dla większych wolumenów i logów).
• Do śladu dowodowego: pliki tekstowe z hashami, manifesty, exporty logów (łatwiej wykazać integralność).

Praktyczna zasada: co najmniej jeden format „dla ludzi” i jeden „dla maszyn”, jeśli wynik ma przejść przez proces kontroli lub dalszej automatyzacji.

Wersjonowanie: artefakt bez wersji jest artefaktem bez kontekstu

Wersjonowanie dotyczy nie tylko kodu, ale także dokumentów, danych i raportów. Minimalny zestaw informacji, który pozwala odtworzyć wynik, to: wersja artefaktu, czas, autor/agent, źródła wejściowe oraz środowisko/parametry (w skrócie: „co”, „kiedy”, „kto”, „z czego”, „jak”).

• SemVer dla komponentów (gdy ma sens): ułatwia ocenę ryzyka zmiany.
• Identyfikatory niezmienne: commit hash, tag wydania, snapshot danych.
• Snapshoty danych: osobna wersja dla wejść i wyjść (nawet jeśli tylko jako manifest i ścieżki).
• Changelog/nota zmian: krótko „co się zmieniło i dlaczego”, zamiast rozproszonych komentarzy.

Ścieżka audytu: jak spiąć cytowania, logi, linki i pliki w jedną całość

Ścieżka audytu to mapa zależności między twierdzeniami w wyniku, użytymi źródłami i operacjami wykonanymi przez agenta. Powinna umożliwiać odpowiedź na pytania: „skąd to wiadomo?”, „jak to policzono?”, „kto i czym to wygenerował?”, „czy da się to odtworzyć?”.

• Cytowania: każde istotne twierdzenie faktograficzne ma odnośnik do źródła (link/ID) i najlepiej wskazanie fragmentu (sekcja, strona, akapit).
• Linki do artefaktów: jawne odwołania do plików/obiektów (ścieżka, URL, identyfikator w repozytorium lub magazynie plików).
• Logi działań: rejestr kroków, parametrów i wyników operacji narzędziowych (np. zapytania, komendy, odpowiedzi skrócone do metadanych).
• Spójne identyfikatory: jeden identyfikator zadania/uruchomienia (run id), który pojawia się w nazwach plików, logach i raporcie.
• Integralność: hash/eTag artefaktów lub manifest z sumami kontrolnymi (wystarczy dla podstawowych potrzeb audytu).

Minimalny „pakiet dowodowy” (propozycja)

Niezależnie od domeny, warto ustandaryzować minimalny zestaw plików dołączanych do wyniku. Poniżej prosty szkielet, który dobrze skaluje się od analiz po zadania inżynierskie:

./deliverable/
  result.md (lub result.pdf)         # artefakt główny
  sources.md                         # lista źródeł + wskazania fragmentów
  manifest.json                      # metadane: wersje, run_id, wejścia/wyjścia
  logs.jsonl                         # logi działań (narzędzia, parametry, status)
  attachments/                       # pliki pomocnicze: wykresy, eksporty, zrzuty
  checks/                            # wyniki walidacji: testy, raporty jakości

Kluczowe jest nie tyle „jakie pliki”, co konsekwencja: ten sam układ ułatwia automatyczne sprawdzanie kompletności i szybkie review.

Pułapki i dobre praktyki (w skrócie)

• Pułapka: źródła bez kontekstu — sam link to za mało; potrzebne jest wskazanie fragmentu i relacji „twierdzenie → źródło”.
• Pułapka: logi bez możliwości korelacji — jeśli logi nie mają run_id albo nie wskazują, który artefakt powstał z którego kroku, są mało użyteczne.
• Pułapka: brak wersji wejść — bez wersjonowania danych/konfiguracji nie da się powtórzyć wyniku.
• Dobra praktyka: manifest — jedno miejsce, które spina metadane, ścieżki, wersje i sumy kontrolne.
• Dobra praktyka: „dowód na każde ważne twierdzenie” — ogranicza halucynacje i wymusza dyscyplinę wnioskowania.

6. Kryteria akceptacji: definicja „done”, metryki jakości i checklista dla rezultatów agenta

Bez jednoznacznych kryteriów akceptacji agent AI może „dowieźć” rezultat pozornie poprawny, ale nieużyteczny: bez pokrycia wymagań, bez weryfikowalnych dowodów, bez spójnego formatu lub z ryzykiem halucynacji. Definicja „done” przenosi ocenę z poziomu wrażenia na poziom sprawdzalnych warunków: co musi zostać dostarczone, w jakiej jakości, z jakimi dowodami i w jakiej formie.

6.1. Definicja „done”: co oznacza „ukończone” dla pracy agenta

„Done” to zestaw warunków, które muszą być spełnione jednocześnie. Dobrze zdefiniowane „done” obejmuje trzy warstwy:

• Kompletność – wszystkie wymagane elementy odpowiedzi/artefaktów są dostarczone (np. raport + tabela + linki do źródeł).
• Weryfikowalność – każda istotna teza ma przypisane źródło lub artefakt pracy; dane liczbowe są możliwe do odtworzenia.
• Użyteczność operacyjna – rezultat jest w formacie gotowym do użycia (np. zgodny ze szablonem firmy, w ustalonej strukturze, z jasnymi rekomendacjami i ograniczeniami).

W praktyce „done” powinno być zapisane jako konkretne kryteria akceptacji (testowalne), a nie jako ogólne oczekiwania typu „ma być dobrze”.

6.2. Kryteria akceptacji: minimalny zestaw dla zadań agentowych

Poniżej znajduje się zestaw kryteriów, który można traktować jako bazowy i dostosowywać do typu zadania:

• Zgodność z celem: rezultat odpowiada na zadane pytanie i mieści się w zakresie (bez „odpływania” w dygresje).
• Pokrycie wymagań: każdy punkt wymagań wejściowych ma przypisany fragment wyniku (mapowanie „wymaganie → dowód w wyniku”).
• Źródła i dowody: dla kluczowych twierdzeń dołączono cytowania/odnośniki; dla obliczeń lub analiz dołączono artefakty (np. arkusz, zapytania, logi).
• Jasność i format: wynik zgodny ze standardem raportowania (nagłówki, sekcje, tabele), jednoznaczny język, brak sprzeczności.
• Ograniczenia i założenia: agent jawnie wskazuje, czego nie wie, jakie przyjął założenia i jaki to ma wpływ na wnioski.
• Bezpieczeństwo i zgodność: brak ujawnienia danych wrażliwych; przestrzeganie polityk (np. licencje, prawa autorskie, compliance).

6.3. Metryki jakości: jak mierzyć rezultat, a nie „wrażenie”

Metryki powinny być dopasowane do typu zadania, ale warto rozdzielić je na trzy grupy: jakość merytoryczna, jakość dowodowa i jakość operacyjna. Dzięki temu „plan → wykonanie → dowody” ma odzwierciedlenie w pomiarze.

Ważne: metryki nie muszą być skomplikowane. Kluczowe jest, by były konsekwentnie stosowane i umożliwiały porównywanie wyników w czasie (trend jakości, regresje po zmianie promptów lub narzędzi).

6.4. Checklista akceptacyjna: szybki audyt wyniku agenta

Poniższa checklista pozwala ocenić rezultat w kilka minut i ogranicza ryzyko dopuszczenia pracy bez „dowodów”. Może być używana przez osobę odbierającą lub automatycznie (część punktów da się walidować regułami).

• Zakres: odpowiedź mieści się w zadanym zakresie, bez niezamówionych rozszerzeń.
• Kompletność: wszystkie wymagane sekcje/elementy są obecne (np. streszczenie, rekomendacje, ryzyka, załączniki).
• Mapowanie wymagań: każdy wymóg ma wskazane miejsce w wyniku (np. w tabeli „wymóg → fragment → dowód”).
• Źródła: kluczowe tezy mają cytowania/odnośniki; źródła są adekwatne (nie przypadkowe) i możliwe do sprawdzenia.
• Artefakty: dołączono pliki/wyjścia narzędzi/obliczenia wymagane do odtworzenia wyniku; opisano, co zawierają.
• Rozróżnienie faktów i opinii: fakty są oddzielone od rekomendacji; brak „pewnych” twierdzeń bez podstawy.
• Założenia i luki: jawnie wskazane założenia, braki danych i wpływ na wnioski.
• Spójność: brak sprzeczności wewnętrznych; liczby i definicje są konsekwentne w całym dokumencie.
• Format i czytelność: wynik spełnia standard struktury i jest zrozumiały dla odbiorcy (nie tylko dla autora/agenta).
• Ryzyka i ograniczenia: wskazane potencjalne ryzyka (np. niepewność danych) oraz ograniczenia zastosowania wyniku.
• Zgodność: brak danych wrażliwych; przestrzeganie licencji i polityk publikacji/udostępniania.

6.5. Szablon „kryteria akceptacji” do wklejenia do zlecenia (minimalny)

Ten krótki blok można dodawać do zadań dla agenta, aby jednoznacznie ustalić, co zostanie uznane za „done”:

KRYTERIA AKCEPTACJI (DONE)
1) Wynik pokrywa wszystkie wymagania wejściowe (wymaganie → miejsce w wyniku).
2) Każda kluczowa teza/dane liczbowe mają przypisane źródło lub artefakt.
3) Dołączone są artefakty umożliwiające odtworzenie pracy (jeśli dotyczy).
4) Jawnie opisane są założenia, ograniczenia i obszary niepewne.
5) Format zgodny z ustalonym szablonem; brak sprzeczności i niejednoznaczności.
6) Wynik nie zawiera danych wrażliwych i spełnia wymagania zgodności.

Tak zdefiniowane kryteria akceptacji nie opisują jak agent ma pracować, tylko jak ma wyglądać rezultat i co musi być do niego dołączone, aby był sprawdzalny i gotowy do użycia.

7. Walidacja i zabezpieczenia: automatyczne testy, cross-check, wykrywanie halucynacji i review człowieka

Nawet przy rygorystycznym schemacie „plan → wykonanie → dowody” agent AI może popełniać błędy: od nieprecyzyjnych wniosków, przez pominięte ograniczenia, po nieuzasadnione twierdzenia. Dlatego skuteczne wdrożenie wymaga warstwy walidacji i zabezpieczeń, która oddziela wytworzenie odpowiedzi od jej dopuszczenia do użycia. W praktyce oznacza to łączenie automatycznych testów, niezależnych cross-checków, mechanizmów wykrywania halucynacji oraz przeglądu człowieka tam, gdzie ryzyko jest najwyższe.

Automatyczne testy: szybkie filtry jakości i zgodności

Automatyczne testy powinny wychwytywać typowe problemy zanim wynik trafi do użytkownika lub systemu downstream. Ich rola jest pragmatyczna: nie udowadniają prawdy, ale skutecznie eliminują część błędów formalnych, logicznych i proceduralnych.

• Testy struktury: czy agent dostarczył wszystkie wymagane elementy (np. dowody, linki, załączniki, jawne założenia), w oczekiwanym formacie.
• Testy spójności: czy wnioski wynikają z przedstawionych danych, czy nie ma sprzeczności między sekcjami oraz czy liczby, daty i nazwy są konsekwentne.
• Testy ograniczeń: czy agent nie przekroczył dozwolonego zakresu (np. brak ujawniania danych wrażliwych, brak rekomendacji wykraczających poza polityki).
• Testy kompletności: czy wskazano braki danych i ryzyka, zamiast maskować je pewnymi stwierdzeniami.

Kluczowa różnica w porównaniu do dalszych metod: automatyczne testy są tanie i szybkie, ale działają głównie na poziomie formy, spójności i reguł, a nie głębokiej weryfikacji merytorycznej.

Cross-check: niezależna weryfikacja tego samego wyniku

Cross-check polega na tym, by wynik agenta został zweryfikowany niezależnym torem — innym modelem, inną konfiguracją, alternatywnym narzędziem lub inną metodą dojścia do odpowiedzi. Celem nie jest „druga opinia” dla samej opinii, tylko wykrywanie sytuacji, w których agent dopasował narrację do hipotezy.

• Weryfikacja krzyżowa faktów: porównanie kluczowych twierdzeń z niezależnym źródłem lub innym sposobem pozyskania danych.
• Replikacja rozumowania: sprawdzenie, czy da się dojść do podobnych wniosków inną ścieżką, przy tych samych ograniczeniach.
• Porównanie wariantów: ocena różnic między odpowiedziami; rozbieżności są sygnałem do zatrzymania lub eskalacji.

Cross-check jest szczególnie użyteczny w zadaniach analitycznych, researchu i podsumowaniach, gdzie ryzyko „pewnego tonu bez podstaw” jest wysokie, a jednocześnie istnieje możliwość niezależnego sprawdzenia.

Wykrywanie halucynacji: sygnały ostrzegawcze i progi zaufania

Halucynacje najczęściej nie wyglądają jak oczywiste błędy — bywają językowo poprawne i przekonujące. Dlatego warto traktować ich wykrywanie jako zarządzanie ryzykiem: identyfikowanie sygnałów ostrzegawczych, mierzenie niepewności i wymaganie dowodów proporcjonalnych do wagi decyzji.

• Twierdzenia bez pokrycia: jeśli w odpowiedzi pojawiają się nowe fakty, liczby lub cytaty, które nie mają przypisanych źródeł lub artefaktów, powinno to obniżać zaufanie do całości.
• Nadmierna stanowczość: kategoryczne wnioski przy słabych danych wejściowych; brak rozróżnienia między faktami, interpretacją i spekulacją.
• „Źródła-widma”: odwołania do dokumentów lub linków, których nie da się otworzyć, zweryfikować lub które nie zawierają przywoływanych informacji.
• Konflikty wewnętrzne: różne wartości tej samej metryki w jednej odpowiedzi, sprzeczne daty, niespójne definicje.

Praktycznym podejściem jest ustawianie progów zaufania: im wyższe ryzyko (np. finansowe, prawne, bezpieczeństwa, reputacyjne), tym więcej niezależnych dowodów i walidacji jest wymagane, a tym mniej miejsca na domysły.

Review człowieka: ostatnia instancja odpowiedzialności

Review człowieka nie powinien być domyślnie „czytaniem wszystkiego”, tylko celowaną kontrolą tam, gdzie automaty i cross-check nie wystarczają albo koszt błędu jest zbyt wysoki. Człowiek ma przewagę w ocenie kontekstu biznesowego, intencji, etyki, ryzyk oraz w wyłapywaniu subtelnych manipulacji językowych.

• Ocena merytoryczna i kontekstowa: czy rekomendacje są sensowne w realiach organizacji, czy nie pomijają krytycznych ograniczeń.
• Weryfikacja kluczowych twierdzeń: manualne sprawdzenie kilku najważniejszych punktów zamiast pełnej kontroli wszystkiego.
• Decyzja o eskalacji: jeśli wynik nie spełnia progów zaufania, recenzent decyduje o ponownym uruchomieniu pracy, doprecyzowaniu wejścia lub zmianie narzędzi.

Ważna zasada: człowiek powinien oceniać wynik wraz z dowodami, a nie „ładnie napisaną odpowiedź”. Jeśli dowody są nieadekwatne, review ma prawo uznać rezultat za nieprzyjęty nawet wtedy, gdy brzmi przekonująco.

Polityki bezpieczeństwa: minimalizacja szkód i kontrola ekspozycji

Walidacja jakości to jedno, ale agent musi też działać bezpiecznie. Podstawowe zabezpieczenia obejmują ograniczanie dostępu, minimalizację danych oraz kontrolę tego, co agent może publikować lub wykonywać.

• Minimalny niezbędny dostęp: agent dostaje tylko takie uprawnienia i dane, które są konieczne do zadania.
• Ochrona danych wrażliwych: wymuszanie redakcji, anonimizacji i zasad udostępniania; blokowanie nieautoryzowanych ujawnień.
• Bezpieczne wykonywanie akcji: jeśli agent może wywoływać działania (np. wysyłkę, aktualizację, publikację), powinien mieć mechanizmy zatwierdzania i możliwość zatrzymania.
• Śledzenie i odpowiedzialność: logowanie działań oraz decyzji walidacyjnych tak, by dało się odtworzyć, dlaczego wynik został dopuszczony.

Jak łączyć metody w praktyce

Najlepsze efekty daje podejście warstwowe: automatyczne testy filtrują błędy formalne i zgodności, cross-check redukuje ryzyko błędów merytorycznych i stronniczości, wykrywanie halucynacji pilnuje relacji „twierdzenie ↔ dowód”, a review człowieka domyka odpowiedzialność w zadaniach o wysokiej stawce. Dzięki temu schemat „plan → wykonanie → dowody” staje się nie tylko formatem raportowania, ale podstawą egzekwowalnej kontroli jakości i bezpieczeństwa.

8. Przykładowe szablony promptów i gotowe wzorce wdrożeniowe dla typowych zadań biznesowych

Poniższe szablony są zaprojektowane tak, aby agent konsekwentnie pracował w schemacie „plan → wykonanie → dowody”. Różnią się przede wszystkim: poziomem rygoru dowodowego (jak mocno wymagane są cytowania, logi i artefakty), rodzajem artefaktów (np. brief, lista zmian, raport, backlog), oraz mechanizmem akceptacji (kto i w jaki sposób zatwierdza wynik). Każdy wzorzec można zastosować zarówno w trybie jednorazowego zadania, jak i cyklicznego procesu.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

8.1. Uniwersalny szablon „plan → wykonanie → dowody” (do większości zadań)

• Rola i cel: „Działasz jako [rola]. Twoim celem jest [cel biznesowy].”
• Ograniczenia: „Nie zgaduj. Jeśli brakuje danych, zadaj pytania lub oznacz lukę jako ryzyko.”
• Format odpowiedzi: „Zwróć: Plan, Wykonanie, Dowody, Ryzyka i założenia, Rekomendacje.”
• Dowody: „Do każdego kluczowego twierdzenia dołącz źródło (link/cytat/ID dokumentu) albo artefakt (plik, notatka, log, lista zmian).”
• Definicja gotowości: „Wynik jest ukończony, jeśli spełnia: [kryteria]. Jeśli nie, zwróć listę braków.”

Zastosowanie: szybkie wdrożenie standardu raportowania w zespołach, gdy nie chcesz utrzymywać wielu wariantów promptów.

8.2. Research i synteza wiedzy (rygor cytowań)

• Cel: przegląd źródeł + wnioski + rekomendacje oparte na dowodach.
• Plan: wyszukania/zakres, kryteria doboru źródeł, sposób porównania.
• Wykonanie: streszczenia per źródło, porównanie tez, wskazanie niezgodności.
• Dowody: cytowania fragmentów, linki, daty publikacji, rozróżnienie „fakt” vs „interpretacja”.
• Artefakty: bibliografia, notatki z lektury, lista pytań otwartych.

Różnica: nacisk na transparentność pochodzenia informacji i oddzielenie opinii od cytowanych faktów.

8.3. Analiza dokumentów wewnętrznych (compliance i audyt)

• Cel: ocena zgodności, identyfikacja luk, propozycje zmian.
• Plan: mapowanie wymagań do fragmentów dokumentów, kryteria zgodności.
• Wykonanie: wylistowanie punktów zgodnych/niezgodnych, priorytetyzacja ryzyk.
• Dowody: precyzyjne odwołania do sekcji/akapitów (ID, numer rozdziału), ślad decyzji.
• Artefakty: rejestr niezgodności, lista zmian do dokumentu, notatka dla interesariuszy.

Różnica: dowody mają formę odwołań do konkretnych miejsc w materiałach, a nie ogólnych źródeł.

8.4. Tworzenie treści biznesowych (brief → wersje → uzasadnienia)

• Cel: przygotowanie materiału (np. opis produktu, komunikat, prezentacja) z uzasadnieniem decyzji.
• Plan: odbiorcy, cel, ton, kluczowe tezy, ograniczenia prawne/marki.
• Wykonanie: wersja robocza + warianty (np. krótszy/dłuższy, formalny/luźniejszy).
• Dowody: źródła danych liczbowych i claimów, lista przyjętych założeń.
• Artefakty: brief, wersje tekstu, lista zmian i uzasadnień (dlaczego tak, a nie inaczej).

Różnica: ważne są artefakty iteracji (wersje i uzasadnienia), nie tylko finalny tekst.

8.5. Wsparcie analityczne (dane → wnioski → załączniki)

• Cel: interpretacja danych i rekomendacje operacyjne.
• Plan: pytania analityczne, metryki, segmenty, ryzyka błędnej interpretacji.
• Wykonanie: obliczenia, porównania, wykryte anomalie, alternatywne wyjaśnienia.
• Dowody: wskazanie źródeł danych, zakresów, filtrów, definicji metryk.
• Artefakty: zestawienie wyników, opis transformacji, lista założeń i ograniczeń.

Różnica: „dowody” to przede wszystkim parametry analizy (co, skąd, jak liczono), aby dało się ją odtworzyć.

8.6. Zadania operacyjne i koordynacyjne (checklista dowodów wykonania)

• Cel: doprowadzenie zadania do zamknięcia w wielu krokach (np. przygotowanie wysyłki, aktualizacja materiałów, koordynacja zgłoszeń).
• Plan: lista kroków, zależności, właściciele, punkty kontrolne.
• Wykonanie: statusy kroków, blokery, decyzje i eskalacje.
• Dowody: potwierdzenia wykonania (link do zadania, numer zgłoszenia, notatka z ustaleń, zrzut z systemu – jeśli dostępny).
• Artefakty: lista kontrolna, dziennik działań, podsumowanie zmian.

Różnica: kluczowe jest „udowodnienie, że zrobione”, a nie głęboka analiza merytoryczna.

8.7. Przygotowanie wymagań i backlogu (specyfikacja + ślad decyzji)

• Cel: przełożenie potrzeb na wymagania i elementy backlogu.
• Plan: zakres, interesariusze, definicje pojęć, kryteria priorytetu.
• Wykonanie: opis problemu, propozycje rozwiązań, kryteria akceptacji, ryzyka.
• Dowody: odwołania do rozmów/ustaleń, dokumentów, ograniczeń technicznych.
• Artefakty: backlog, szkic user stories, lista pytań i decyzji do podjęcia.

Różnica: nacisk na ślady ustaleń (co było wymaganiem, skąd wynika i kto zatwierdził).

8.8. Wzorzec wdrożeniowy „twarde dowody” vs „lekkie dowody”

W praktyce warto utrzymywać dwa poziomy rygoru:

• Twarde dowody: zadania o wysokim ryzyku (prawo, finanse, bezpieczeństwo, reputacja). Wymagaj cytowań, identyfikatorów dokumentów, wersjonowania artefaktów i jasnego rozdzielenia faktów od interpretacji.
• Lekkie dowody: zadania niskiego ryzyka (robocze streszczenia, wstępne szkice). Wymagaj minimum: lista założeń, źródła dla liczb/claimów i artefakt końcowy.

Kluczowa zasada: poziom dowodów dobieraj do konsekwencji błędu, a nie do „ważności” zadania w odczuciu zespołu.

8.9. Minimalny zestaw „artefaktów obowiązkowych” (do wklejenia w prompt)

• Artefakt końcowy: wynik w formie docelowej (tekst, lista decyzji, rekomendacja, backlog).
• Lista źródeł: linki/odnośniki/ID dokumentów użytych do wniosków.
• Założenia i luki: co przyjęto bez potwierdzenia i czego brakuje.
• Ślad pracy: krótki log kroków lub lista wykonanych działań, umożliwiająca odtworzenie.

Ten zestaw działa jako prosty „bezpiecznik jakości”: nawet gdy agent nie wykona wszystkiego idealnie, pozostawi materiał do weryfikacji i poprawy.

Excel + Power Automate: automatyczne wersjonowanie plików i blokada nadpisywania (wzorzec zespołowy) 30 kwietnia 2026

Testy odporności agentów na dane brudne: 9 klas błędów wejścia (daty, waluty, OCR) i jak je symulować 28 kwietnia 2026