7 pozycji Evidence Pack, o które zapyta audytor lub zarząd

AI Act to nie polityka PDF. Jeżeli system AI ma wejść na produkcję, zarząd, audytor albo właściciel procesu powinien zobaczyć dowody: co dokładnie działa, kto odpowiada, jakie testy system przeszedł, co jest logowane i jak go bezpiecznie zatrzymać. Taki uporządkowany zestaw nazywamy Evidence Pack.

Evidence Pack nie jest magicznym certyfikatem zgodności. To roboczy pakiet przypięty do konkretnej wersji modelu, promptu, danych, kodu i konfiguracji. Pozwala podjąć decyzję na podstawie wyników, a nie demonstracji przygotowanej na trzy wygodne pytania.

Otwórz bezpłatny, drukowalny szablon Evidence Pack. Pola można uzupełnić w przeglądarce i zapisać do PDF.

Spis treści

• 1. Inwentarz systemu i owner card
• 2. Klasyfikacja ryzyka i rola organizacji
• 3. Golden set i kryteria akceptacji
• 4. Plan oraz wyniki ewaluacji
• 5. Logi, wersjonowanie i monitoring
• 6. Human handoff i obsługa incydentów
• 7. Kill switch, rollback i decyzja go/no-go

1. Inwentarz systemu i owner card

Pierwsza pozycja brzmi banalnie: co właściwie oceniamy? W praktyce wiele organizacji nie potrafi odpowiedzieć bez kilkunastu wiadomości i spotkań. Nazwa handlowa produktu nie wystarcza. Trzeba wskazać:

• przypadek użycia i proces biznesowy;
• grupy użytkowników oraz osoby, na które system wpływa;
• właściciela biznesowego i technicznego;
• model, dostawcę, prompty, narzędzia i integracje;
• źródła danych, ich właścicieli, klasy wrażliwości i retencję;
• wersję kodu, modelu, indeksu i konfiguracji objętą decyzją;
• środowisko: PoC, test, ograniczona produkcja albo pełna produkcja.

Owner card nie jest listą kontaktów „na wszelki wypadek”. Właściciel biznesowy akceptuje skutek błędu i dozwolony zakres użycia. Właściciel techniczny odpowiada za wersję, obserwowalność, reakcję i możliwość odtworzenia wyniku. Jeżeli obu ról nie da się nazwać, system nie ma jeszcze warunków do świadomego go-live.

Dowód w pakiecie: aktualna karta systemu, diagram przepływu danych i jednoznaczny owner dla decyzji produkcyjnej.

2. Klasyfikacja ryzyka i rola organizacji

Drugie pytanie nie brzmi „czy używamy AI?”, tylko: jaki przepis i jaka odpowiedzialność dotyczą tego konkretnego systemu? Trzeba rozdzielić co najmniej cztery kwestie:

1. Czy przypadek użycia może należeć do praktyk zakazanych?
2. Czy system mieści się w obszarze wysokiego ryzyka z załącznika I lub III?
3. Czy dotyczą go obowiązki przejrzystości z art. 50, na przykład chatbot, deepfake albo treść informacyjna generowana przez AI?
4. Czy organizacja działa jako dostawca, podmiot stosujący, importer lub dystrybutor?

Zakresu nie wolno wyprowadzać z samej nazwy narzędzia. Ta sama technologia może być zwykłym asystentem redakcyjnym w jednym procesie i elementem systemu wpływającego na dostęp do usługi w innym. Liczy się rola, sposób użycia, dane i skutek.

Evidence Pack powinien zawierać wstępną kwalifikację, jej podstawę, otwarte pytania oraz osobę, która zatwierdziła dalszą ścieżkę. Gdy klasyfikacja nie jest oczywista, potrzebna jest walidacja compliance lub prawna. Sam szablon nie zastępuje porady prawnej ani formalnej oceny zgodności.

Dowód w pakiecie: tabela kwalifikacyjna z uzasadnieniem, zakresem i ownerem każdego otwartego ryzyka.

3. Golden set i kryteria akceptacji

Demo może wyglądać świetnie, bo pokazuje wybrane przypadki. Golden set odwraca tę logikę: najpierw zapisujemy reprezentatywne pytania, zadania, oczekiwane wyniki i przypadki brzegowe, a dopiero potem oceniamy system.

Dobry golden set obejmuje nie tylko sytuacje typowe. Powinien zawierać:

• pytania łatwe, trudne i niejednoznaczne;
• dane aktualne, stare, sprzeczne i niepełne;
• przypadki, w których system ma odmówić odpowiedzi lub działania;
• próby wyjścia poza uprawnienia;
• scenariusze krytyczne dla klienta, bezpieczeństwa albo zgodności;
• parafrazy tego samego polecenia;
• przypadki ujawniające różnice pomiędzy wersjami systemu.

Kryteria akceptacji zapisuje się przed końcowym testem. Inaczej zespół dopasuje interpretację do wyniku. Próg może dotyczyć poprawności, ugruntowania w źródłach, odsetka odmów, skuteczności wykrycia prompt injection, czasu odpowiedzi, kosztu jednostkowego lub liczby niekontrolowanych akcji.

Dowód w pakiecie: wersjonowany golden set, opis doboru próby oraz progi z nazwiskiem osoby, która je zatwierdziła.

4. Plan oraz wyniki ewaluacji

Raport „testy przeszły” nie jest wynikiem. Evidence Pack powinien pozwolić odtworzyć, co uruchomiono, na jakiej wersji, z jakim progiem i co dokładnie nie przeszło.

Minimalny plan ewaluacji produkcyjnego systemu GenAI lub RAG zwykle obejmuje:

• jakość odpowiedzi lub skuteczność zadania;
• ugruntowanie w źródłach i poprawność cytowań;
• halucynacje oraz zachowanie przy braku danych;
• prompt injection, wyciek danych i egzekwowanie uprawnień;
• działanie integracji i narzędzi agenta;
• fallback po błędzie modelu, źródła lub API;
• koszt, czas odpowiedzi i zachowanie przy obciążeniu;
• regresję po zmianie modelu, promptu, danych albo kodu.

Wynik musi pokazywać także ograniczenia. Jeżeli test obejmował 200 przypadków jednego procesu i dwa języki, nie dowodzi jakości dla innego działu, nieznanej populacji danych ani autonomicznych akcji. Uczciwe „nie przetestowano” jest lepsze od zielonego statusu bez zakresu.

Dowód w pakiecie: raport maszynowy i czytelne podsumowanie z wynikami, progami, blokadami oraz linkiem do artefaktów testowych.

5. Logi, wersjonowanie i monitoring

System AI zmienia się nawet wtedy, gdy interfejs wygląda tak samo. Dostawca aktualizuje model, baza wiedzy dostaje nowe dokumenty, prompt przechodzi poprawkę, a użytkownicy zaczynają zadawać inne pytania. Dlatego dowód z dnia odbioru szybko traci wartość.

Evidence Pack powinien wskazywać, czy dla każdej istotnej operacji można ustalić:

• wersję modelu, promptu, kodu i indeksu;
• wejście, wyjście, źródła i wywołane narzędzia;
• decyzję, odmowę, fallback lub eskalację;
• użytkownika albo rolę oraz zastosowane uprawnienia;
• czas, koszt i status operacji;
• politykę retencji oraz dostęp do logów;
• alerty, progi i osobę reagującą na odchylenie.

Monitoring nie powinien ograniczać się do dostępności API. Trzeba obserwować trend jakości, koszt, wzrost fallbacków, liczbę eskalacji, odsetek odpowiedzi bez źródła i incydenty uprawnień. Każdy sygnał potrzebuje progu oraz reakcji. Dashboard bez ownera jest tylko ekranem.

Jak wygląda liczbowy dowód

W publicznym case mojApteczka pokazujemy 302 516 rekordów interakcji lekowych w bazie wiedzy, 100% ekstrakcji danych na deklarowanym zbiorze walidacyjnym n=200 oraz 0,0006 USD kosztu pojedynczego skanu AI. Te liczby są dowodem dla konkretnego systemu i jego opisanego zakresu — nie gwarancją takiego samego wyniku w innym wdrożeniu.

Evidence Pack dodaje do każdej metryki kontekst: wersję, próbę, metodę, próg, datę i ownera. Dzięki temu wynik można zakwestionować, powtórzyć i porównać po zmianie.

6. Human handoff i obsługa incydentów

„Człowiek w pętli” nie jest kontrolą, jeśli nikt nie wie, kiedy człowiek ma przejąć sprawę, kto dostaje alert i co widzi po eskalacji. Handoff trzeba zaprojektować jak proces operacyjny.

W pakiecie należy zapisać wyzwalacze, na przykład niską pewność, brak wiarygodnego źródła, dane wrażliwe, prośbę o akcję nieodwracalną, decyzję o skutku finansowym lub prawnym, konflikt danych albo awarię integracji. Dla każdego wyzwalacza potrzebne są rola przejmująca, kanał, oczekiwany czas reakcji i bezpieczne zachowanie systemu do momentu decyzji.

Dobry handoff przekazuje kontekst: pytanie, źródła, historię, powód eskalacji, ostrzeżenia oraz działania już wykonane. Po obsłużeniu sprawy wynik powinien wrócić do rejestru błędów, golden setu albo planu naprawczego. W przeciwnym razie organizacja płaci za ten sam incydent wiele razy.

Dowód w pakiecie: tabela wyzwalaczy, role i SLA, zrzut lub log testowej eskalacji oraz sposób zamknięcia feedback loop.

7. Kill switch, rollback i decyzja go/no-go

Ostatnia pozycja odpowiada na najbardziej praktyczne pytanie zarządu: co zrobimy, kiedy system przestanie zachowywać się bezpiecznie? Odpowiedź „naprawimy prompt” nie wystarcza.

Kill switch powinien zatrzymać ryzykowną funkcję lub akcje agenta bez czekania na pełne wdrożenie nowej wersji. Rollback powinien wskazywać ostatnią bezpieczną wersję modelu, promptu, danych i kodu, czas przywrócenia oraz testy wykonywane po powrocie. Trzeba też ustalić fallback: ręczna obsługa, odpowiedź tylko ze źródeł, tryb read-only albo czasowe wyłączenie funkcji.

Na końcu Evidence Pack zapisuje decyzję:

• GO — progi są spełnione w zatwierdzonym zakresie;
• GO warunkowe — system działa w ograniczonym zakresie, a otwarte ryzyka mają ownerów i terminy;
• NO-GO — istnieje bloker jakości, bezpieczeństwa, zgodności lub kontroli operacyjnej.

Do decyzji dołącza się plan naprawczy: luka, priorytet, działanie, właściciel, termin i dowód zamknięcia. Podpis nie ma upiększać raportu. Ma pokazać, kto świadomie akceptuje zakres i ryzyko.

Dowód w pakiecie: przetestowany scenariusz zatrzymania, plan rollbacku, zatwierdzona decyzja i lista działań naprawczych.

Najczęstsze błędy

1. Pakiet bez wersji. Wyniki nie mówią, którego modelu, promptu i danych dotyczą.
2. Progi zapisane po teście. Kryteria zostają dopasowane do wyniku.
3. Same średnie. Dobry wynik ogólny ukrywa krytyczny błąd w małym segmencie.
4. Monitoring bez reakcji. Jest alert, ale nie ma właściciela ani procedury.
5. Handoff „do człowieka”. Nie wiadomo którego, w jakim czasie i z jakim kontekstem.
6. Szablon traktowany jak certyfikat. Puste pola nie są dowodem, a Evidence Pack nie zastępuje oceny prawnej.

Co zrobić teraz

Najpierw otwórz szablon Evidence Pack i wypełnij kartę systemu oraz kryteria akceptacji. Jeżeli nie możesz wskazać wersji, ownera albo progu go/no-go, zacznij od tej luki — dopiero potem uruchamiaj kolejne testy.

Jeżeli potrzebujesz niezależnego zaprojektowania golden setu, ewaluacji, red teamingu i decyzji produkcyjnej, zobacz AI Assurance & Governance. Semitora może ocenić system zbudowany przez Twój zespół albo innego wykonawcę bez przejmowania całego projektu.

FAQ

Czy Evidence Pack jest wymaganym przez AI Act dokumentem?

AI Act nie narzuca jednego dokumentu o tej nazwie. Evidence Pack to praktyczny sposób zebrania technicznych i operacyjnych dowodów w jednym miejscu. Konkretne obowiązki zależą od roli organizacji, przypadku użycia i klasyfikacji systemu.

Czy wypełniony szablon dowodzi zgodności?

Nie. Dowodem są podpięte wyniki, logi, wersje, decyzje i realnie działające kontrole. Szablon pomaga je uporządkować, ale nie zastępuje porady prawnej ani formalnej oceny zgodności.

Czy Evidence Pack przygotowuje się tylko przed produkcją?

Pierwsza kompletna wersja powinna poprzedzać decyzję produkcyjną. Potem pakiet trzeba aktualizować po istotnej zmianie modelu, promptu, danych, integracji, zakresu użycia albo ryzyka.

Kto powinien zatwierdzić go/no-go?

Co najmniej właściciel biznesowy i techniczny. W zależności od systemu do decyzji włącza się security, privacy, compliance, dział prawny lub właściciela procesu sektorowego.