AI jako asystent komisji: od agenta w chmurze do badania zdarzeń offline

Jak przeszliśmy drogę od pierwszych eksperymentów w chmurze do roboczego obiegu „narzędzie maskujące → agent AI → demaskowanie”, a następnie zbudowaliśmy testowy system badania zdarzeń offline i przygotowujemy się do kolejnego kroku — bezpiecznego korporacyjnego środowiska AI Fire.

Główna idea: AI nie powinna „wskazywać winnego” i nie zastępuje komisji. Jej rzeczywista wartość polega na tym, że pomaga komisji szybciej złożyć rozproszone materiały w spójny obraz, dostrzec luki, sprawdzić logikę przyczynową i przygotować pierwszy roboczy szkic dokumentacji badania.

Od czego wszystko się zaczęło

Pierwsze próby wykorzystania AI w badaniu zdarzeń podjęliśmy już w 2023 roku. Sam pomysł wydawał się wtedy dość prosty: stworzyć własnego agenta, wgrać do niego metodykę badania i materiały dotyczące konkretnego zdarzenia, a następnie poprosić o ułożenie chronologii, wychwycenie sprzeczności w wyjaśnieniach pisemnych, zaproponowanie przyczyn i działań.

W 2024 roku możliwości modeli wyraźnie się poszerzyły: zaczęły sprawnie pracować nie tylko z tekstem, lecz także z obrazami. Jeden z wczesnych eksperymentów w ogóle nie był pełnoprawnym badaniem zdarzenia. W oddalonym zakładzie pracownica upadła i doznała urazu nogi. Zdjęcie rentgenowskie wykonano na miejscu, ale nie było tam specjalisty, który mógłby je od razu opisać. Wgraliśmy zdjęcie do AI, a model wskazał obszar przypominający złamanie piątej kości śródstopia.

Celowo to podkreślam: nie było to orzeczenie lekarskie i nie powinno nim być. Ostateczna ocena zdjęcia medycznego to zadanie lekarza. Dla nas jednak ten epizod stał się ważnym sygnałem technicznym: model potrafi dostrzec na obrazie szczegóły, które laik może przeoczyć. A skoro tak, w badaniu zdarzeń może on potencjalnie pracować nie tylko z tekstem, lecz także ze schematami, zdjęciami i innymi materiałami.

Pierwsza wersja robocza: agent w chmurze

Gdy pojawili się stabilniejsi agenci konfigurowani przez użytkownika, zaczęliśmy dostosowywać ich bezpośrednio do naszej korporacyjnej metodyki. Tworzyliśmy wersje w GPT, Gemini i Perplexity; na wczesnym etapie testowaliśmy też Grok. Do agenta wgrywaliśmy metodykę, a następnie wyjaśnienia pisemne, wstępny opis zdarzenia, poszczególne dokumenty i inne materiały.

Efekt praktyczny był widoczny od razu. AI szybko zestawiała relacje, proponowała sekwencję zdarzeń, wychwytywała rozbieżności w czasie i sformułowaniach, układała listę dodatkowych pytań. Dla komisji była przydatna jako „drugi analityk”, który nie męczy się ponownym czytaniem dziesiątek stron.

Pierwsza wersja miała jednak oczywistą wadę: w praktyce przekazywaliśmy zewnętrznej usłudze rzeczywiste materiały z badania. W przypadku zdarzeń to szczególnie wrażliwa kwestia: materiały mogą zawierać imiona i nazwiska, stanowiska, dane medyczne, wyjaśnienia pisemne, zdjęcia i wewnętrzne informacje przedsiębiorstwa.

Im dłużej korzystaliśmy z narzędzia, tym wyraźniej widzieliśmy, że wygoda nie może usprawiedliwiać wysyłania na zewnątrz zbędnych danych.

Zob. załącznik z promptami: Prompt 1 — bezpieczna wersja agenta w chmurze do pracy wyłącznie z wcześniej zanonimizowanymi materiałami.

Metodyka stała się bardziej rygorystyczna — i zmieniła wymagania wobec AI

Równolegle rozwijała się sama korporacyjna metodyka wewnętrznego badania zdarzeń. Dla mnie to kluczowa kwestia: AI nie można dawać prawa, by „sama wymyśliła, jak prowadzić badanie”. Najpierw musi być metodyka, a dopiero pod nią buduje się narzędzie cyfrowe.

W obowiązującej metodyce głównym celem komisji nie jest szukanie winnego, lecz opracowanie możliwie najskuteczniejszych działań, które wykluczą lub ograniczą prawdopodobieństwo powtórzenia się podobnego zdarzenia. Jeśli w łańcuchu występuje działanie człowieka, trzeba iść dalej i ustalić, dlaczego takie działanie stało się możliwe lub dopuszczalne.

Badanie opiera się na logice barier ochronnych: źródło zagrożenia → zdarzenie niepożądane → skutki; osobno analizuje się bariery prewencyjne i łagodzące. Na etapie analizy informacji tworzy się oś czasu i wyodrębnia czynniki krytyczne. Następnie buduje się drzewo przyczyn, które powinno prowadzić od przyczyn bezpośrednich i pośrednich do systemowych przyczyn źródłowych.

W prostszych analizach ciąg pytań „Dlaczego?” może być krótki. W złożonym zdarzeniu rozgałęzia się i przekształca w pełnoprawne drzewo przyczyn. Logika barier w modelu „bow-tie” pomaga osobno sprawdzić, dlaczego zdarzenie w ogóle nastąpiło i dlaczego skutki okazały się właśnie takie.

To właśnie ta sekwencja stała się później szkieletem naszej lokalnej aplikacji.

Zob. Prompt 2–6: chronologia i czynniki krytyczne → pytania i sprzeczności → bariery → drzewo przyczyn → działania.

Druga wersja: maskujemy ręcznie

Kolejny etap był znacznie bezpieczniejszy, choć dość niewygodny. Przed wgraniem materiałów do agenta w chmurze ręcznie zastępowaliśmy nazwiska i inne wrażliwe dane oznaczeniami: „Pracownik 1”, „Pracownik 2”, „Kierownik 1”, „Dział 1” i tak dalej.

Z punktu widzenia poufności był to już krok naprzód. Agent widział logikę zdarzenia, ale nie widział prawdziwych imion i nazwisk. Po zakończeniu analizy trzeba było ręcznie zamieniać oznaczenia z powrotem — często za pomocą wyszukiwania Ctrl+F.

Dopóki uczestników jest dwóch czy trzech, taki proces da się znieść. Gdy w badaniu pojawia się wiele wyjaśnień pisemnych, świadków, dokumentów i powtarzających się nazwisk, ręczne maskowanie i odwrotne przywracanie danych stają się osobną pracą i rodzą ryzyko błędu.

Trzecia wersja: lokalne narzędzie maskujące i osobny problem nagrań audio

Gdy opanowaliśmy vibe coding, ręczną operację zastąpiliśmy lokalnym narzędziem maskującym, o którym pisałem w pierwszym artykule z tej serii. Dokument Word jest przetwarzany na komputerze i otrzymuje umowne oznaczenia, a osobno zapisywany jest klucz demaskowania. Klucz jest chroniony hasłem i nie trafia do agenta.

Dzięki temu do AI w chmurze można wysłać wyłącznie zamaskowane wyjaśnienia pisemne i inne materiały. Otrzymany wynik wraca na komputer i jest odtwarzany lokalnie. To właśnie ten obieg jest dziś u nas obiegiem roboczym: lokalne narzędzie maskujące → skonfigurowany agent do badania zdarzeń → lokalne demaskowanie. Już teraz pozwala wykorzystać mocne strony modelu w chmurze bez przekazywania mu oryginalnych imion i nazwisk ani klucza przywracania.

Pozostawał jednak jeszcze jeden słaby punkt — nagrania audio. Wyjaśnienia i rozmowy z uczestnikami wygodnie jest nagrywać głosowo, ale do analizy trzeba je najpierw zamienić na tekst. Wcześniej służyły do tego osobne usługi online i aplikacje mobilne. Później transkrypcja pojawiła się bezpośrednio w dużych usługach AI. To wygodne, ale oryginalne nagranie z głosem człowieka nadal trafia na zewnątrz.

Dlatego stworzyliśmy kolejne narzędzie — lokalne narzędzie do transkrypcji. Korzysta ono z Whisper bezpośrednio na komputerze. W naszych testach jakość transkrypcji okazała się w pełni porównywalna z popularnymi rozwiązaniami chmurowymi, a przy tym oryginalne nagranie audio nie opuszcza komputera. Po lokalnej transkrypcji tekst można zamaskować i dopiero wtedy, w razie potrzeby, przekazać roboczemu agentowi do badania zdarzeń.

Zestaw narzędzi na tym etapie: lokalna transkrypcja → lokalne narzędzie maskujące → agent w chmurze. Do analizy materiałów zob. Prompt 1–6.

Czwarta wersja: system offline już powstał — teraz go testujemy

W tym momencie pojawiło się inne pytanie. Skoro lokalnie działają już transkrypcja, odczyt dokumentów i model, to dlaczego nie połączyć tego wszystkiego w jednym bezpiecznym środowisku? Tak narodził się eksperymentalny system badania zdarzeń offline. Jest już opracowany i działa, ale dziś świadomie traktujemy go jako testowy: sprawdzamy go na przypadkach szkoleniowych i zanonimizowanych, porównujemy wyniki z pracą komisji i szukamy kolejnych iteracji, dzięki którym proces stanie się szybszy, wygodniejszy i stabilniejszy.

Zadanie brzmiało tak: stworzyć jedno stanowisko pracy komisji, do którego można wgrać podręcznik metodyczny, informacje wstępne, wyjaśnienia pisemne, pliki Word i PDF, nagrania audio, zdjęcia i schematy; lokalnie przetworzyć mowę i dokumenty na tekst; przejść przez etapy metodyki i otrzymać edytowalny pierwszy projekt raportu w formacie Word.

Prosto brzmi to tylko w jednym zdaniu. W praktyce iteracji było bardzo wiele. Lokalne rozpoznawanie mowy nie zadziałało od razu, potem trzeba było uporać się ze skanami PDF, obrazami, obszernymi materiałami, lokalnym modelem, chronologią, przyczynami i dokumentem końcowym. Schemat pracy był taki sam jak w innych naszych projektach: jedna zmiana → uruchomienie → wynik lub zrzut ekranu z błędem → kolejna iteracja z ChatGPT.

W efekcie powstał lokalny system z interfejsem w przeglądarce i własnym lokalnym środowiskiem AI. Już teraz dobrze transkrybuje nagrania, odczytuje przygotowane materiały i tworzy ustrukturyzowany projekt dokumentacji badania. Naszym zadaniem nie jest dziś ogłoszenie go „gotowym produktem”, lecz spokojne testowanie, porównywanie wyników i doskonalenie logiki działania. Do pełnowartościowego modelu lokalnego i szybkiego przetwarzania dużych zbiorów danych przydaje się odpowiednio wydajny komputer.

Zob. Prompt 8 — master prompt do vibe codingu lokalnego stanowiska pracy komisji.

Co już potrafi testowa wersja offline

W testowej wersji offline cały cykl jest już zbudowany wokół metodyki, a nie wokół zwykłego czatu z AI.

Najpierw komisja rejestruje informacje wstępne: co się stało, źródło zagrożenia, zdarzenie niepożądane, skutki, uczestnicy, wyniki oględzin. Następnie powstaje plan: jakie pytania trzeba zamknąć, z kim przeprowadzić rozmowy, jakie dokumenty i ekspertyzy uzyskać.

Do sekcji materiałów można wgrać pliki DOCX i tekstowe PDF. Skany i zdjęcia można rozpoznać lokalnie; schematy i obrazy są przechowywane w aktach sprawy, a model może zaproponować opis widocznych szczegółów. Nagrania audio i wideo są transkrybowane lokalnie. Można też nagrać rozmowę bezpośrednio przez mikrofon, a następnie otrzymać transkrypcję.

Po weryfikacji materiałów aplikacja pomaga zbudować oś czasu. AI proponuje zdarzenia i cytaty, ale decyzję o włączeniu wpisu podejmuje komisja. Osobno oznacza się czynniki krytyczne.

Kolejny blok to bariery ochronne i przyczyny. Komisja sprawdza bariery prewencyjne i łagodzące oraz buduje dwie wyjściowe gałęzie: dlaczego doszło do zdarzenia niepożądanego i dlaczego wystąpiły takie skutki. Przyczyny zaproponowane przez AI pozostają hipotezami do czasu potwierdzenia przez komisję.

Po przyczynach formułuje się działania: do której przyczyny odnosi się dany środek, kto za niego odpowiada, jaki jest termin, jaki rezultat można zweryfikować, czy potrzebna jest bariera tymczasowa, czy środek powinien wykraczać poza jeden obszar.

Dopiero wtedy powstaje projekt raportu. Aplikacja może złożyć pierwszy szkic w formacie Word zgodnie ze strukturą podręcznika metodycznego i uwzględnić w nim chronologię, drzewo przyczyn, bariery, rejestr materiałów i załączniki.

Zob. Prompt 2 — chronologia; Prompt 3 — sprzeczności i brakujące dane; Prompt 4 — bariery; Prompt 5 — drzewo przyczyn; Prompt 6 — działania; Prompt 7 — projekt raportu końcowego.

Co robi lokalna AI — i czego robić nie powinna

Tu ważne jest, by nie przeceniać automatyzacji. AI czyta zweryfikowane teksty fragmentami, proponuje chronologię, pytania, bariery, hipotezy przyczyn i warianty działań. Może znaleźć sprzeczność między dwoma wyjaśnieniami pisemnymi albo zauważyć, że w chronologii brakuje ważnego przedziału czasu.

Jednak cytat z dokumentu potwierdza jedynie to, że takie słowa rzeczywiście występują w materiale. Nie dowodzi prawdziwości relacji. Rozpoznany tekst może zawierać błąd. Schemat może zostać błędnie zinterpretowany. Związek przyczynowy może okazać się jedynie hipotezą.

Dlatego w aplikację wbudowano zasadę: AI proponuje — komisja akceptuje, odrzuca lub redaguje. Przyczyna nie staje się potwierdzona automatycznie. Osób odpowiedzialnych i terminów nie wyznacza model. Projekt w Wordzie to właśnie pierwszy roboczy szkic, a nie dokument typu „bierz i podpisuj”.

Jest to szczególnie ważne, ponieważ raport wewnętrzny nie zastępuje dokumentów przewidzianych przepisami prawa i ustalonymi procedurami. Odpowiedzialność za badanie zdarzenia pozostaje po stronie komisji.

Zob. Prompt 9 — kontrola jakości, poufności i granic automatyzacji przed wykorzystaniem wyniku.

Poufność stała się częścią architektury, a nie osobną instrukcją

W badaniu zdarzeń kwestii poufności nie można odkładać „na później”. Sama metodyka zalicza materiały wewnętrznego badania do dokumentów do użytku służbowego i odrębnie wymaga ochrony danych osobowych przy tworzeniu i przekazywaniu plików.

W testowej wersji offline materiały sprawy, transkrypcje, wyniki analizy i plik Word pozostają na komputerze. Lokalny model działa przez adres loopback, a po przygotowaniu niezbędnych modeli sesję roboczą nad sprawą można prowadzić bez połączenia z internetem.

Ale i tu nie ma magii. Praca lokalna nie oznacza automatycznej anonimizacji. Jeśli do akt sprawy trafią imiona i nazwiska oraz dane medyczne, pozostaną one na tym komputerze i w załącznikach do sprawy. Dlatego potrzebne są standardowe środki bezpieczeństwa informacji: chronione konto użytkownika, uprawnienia dostępu, zasady przechowywania, kopie zapasowe oraz, w razie potrzeby, dodatkowe maskowanie.

Nasza ewolucja nie zakończyła się więc hasłem „wszystko offline — więc wszystko bezpieczne”. Trafniej będzie powiedzieć tak: wyeliminowaliśmy zbędne przekazywanie materiałów na zewnątrz i pozostawiliśmy kontrolę nad danymi tam, gdzie powinna być — wewnątrz przedsiębiorstwa.

Z czego korzystamy dziś

Dziś mamy w praktyce dwa obiegi. Pierwszy to obieg roboczy: lokalnie maskujemy materiały, przekazujemy zanonimizowaną kopię do skonfigurowanego agenta do badania zdarzeń, a następnie lokalnie demaskujemy otrzymany wynik. Z tego schematu można już korzystać w rzeczywistej pracy.

Drugi to obieg testowy: system działający całkowicie offline, który sam lokalnie transkrybuje nagrania audio, odczytuje materiały, pomaga zbudować chronologię, bariery i przyczyny oraz tworzy pierwszy projekt raportu. Już działa, ale nadal go sprawdzamy i ulepszamy. To dla nas kwestia zasadnicza: pilotażu nie można przedstawiać jako dojrzałego systemu produkcyjnego tylko dlatego, że ładnie wygląda.

Obieg roboczy: narzędzie maskujące → skonfigurowany agent AI do badania zdarzeń → demaskowanie.

Obieg testowy: w pełni lokalne stanowisko pracy komisji → weryfikacja i kolejne iteracje.

Kolejny krok — bezpieczny korporacyjny Fire

Równolegle dział IT Grupy rozwija w korporacyjnym środowisku Collab wewnętrzną AI o nazwie Fire. Dla nas to logiczny kolejny etap: przenieść logikę metodyczną asystenta komisji do bezpiecznego, serwerowego środowiska korporacyjnego, w którym nie trzeba wybierać między mocą dużego modelu a wymogami poufności.

Nie postrzegamy Fire jako „automatycznego prowadzącego badanie”, lecz jako kolejne środowisko dla tej samej zasady: materiały pozostają w chronionej infrastrukturze, AI pomaga komisji analizować chronologię, bariery, sprzeczności i przyczyny, a decyzje nadal podejmuje człowiek.

Przed przeniesieniem trzeba najpierw sprawdzić możliwości techniczne Fire: pracę z dokumentami i nagraniami audio, rozmiar kontekstu, rozgraniczenie dostępu, logi, przechowywanie danych i eksport wyników. Innymi słowy, znów wychodzimy od metodyki i ochrony informacji, a nie od chęci użycia za wszelką cenę kolejnego nowego modelu.

Obejrzyj wideo: pełny cykl pracy lokalnego badania zdarzenia

W tym artykule świadomie nie przeładowuję tekstu dziesiątkami jednakowych zrzutów ekranu. Trzyminutowe nagranie ekranu lepiej pokazuje, jak elementy łączą się ze sobą i co faktycznie robi człowiek, a co program.

Zrzuty ekranu są potrzebne tam, gdzie trzeba zatrzymać się przy architekturze: rodzaje materiałów, chronologia, przyczyny, działania i końcowy plik Word. Resztę mechaniki lepiej obejrzeć na wideo — znajduje się ono na końcu artykułu.

Gdzie tu oszczędność czasu

Badanie zdarzenia i tak wymaga ludzi: trzeba obejrzeć miejsce, porozmawiać z uczestnikami, uzyskać dokumenty, omówić fakty, podjąć decyzje. Istoty pracy komisji nie da się zautomatyzować.

Można jednak wyeliminować znaczną część papierowej rutyny: przepisywanie nagrań audio, zestawianie wyjaśnień pisemnych, ręczne wyszukiwanie rozbieżności czasowych, przenoszenie cytatów do chronologii, wstępne rozpisanie barier, opracowanie drzewa przyczyn, przygotowanie roboczej listy działań i złożenie pierwszego projektu raportu.

I tu dla mnie najważniejszym efektem nie jest zmniejszenie liczby specjalistów. Wręcz przeciwnie: jeśli specjalista poświęca mniej czasu na mechaniczną pracę z dokumentami, ma więcej czasu na to, po co w ogóle prowadzi się badanie — na rozmowy z ludźmi, pracę na miejscu, sprawdzanie barier i pomaganie kierownikom w zapobieganiu powtórzeniu się zdarzenia.

Co otrzymaliśmy w efekcie

Droga, jaką przeszliśmy w ciągu kilku lat, okazała się wymowna: otwarty agent w chmurze → ręczne maskowanie → lokalne narzędzie maskujące i demaskowanie → lokalna transkrypcja → testowy system offline → kolejny krok w stronę bezpiecznego korporacyjnego Fire.

Przy tym dzisiejszym narzędziem roboczym nie jest eksperymentalna wersja offline, lecz sprawdzony obieg z maskowaniem: materiały źródłowe pozostają u nas, do agenta trafia wersja zanonimizowana, a przywracanie danych odbywa się lokalnie. System offline obecnie testujemy i konsekwentnie dopracowujemy.

Najważniejsza zmiana nie jest nawet techniczna. Przestaliśmy zadawać AI pytanie „kto jest winny?” i zaczęliśmy zadawać inne: „jakich danych brakuje, które bariery nie zadziałały, dlaczego nie zadziałały i jakie działania rzeczywiście zmniejszą ryzyko powtórzenia?”

Właśnie w tej roli AI jest przydatna w badaniu zdarzeń: nie jako sędzia ani przewodniczący komisji, lecz jako szybki drugi analityk, który pomaga ludziom głębiej pracować z faktami.

I jeszcze jedno: nie wolno zapominać o naturalnej inteligencji

Im potężniejsze stają się modele, tym ważniejsze jest, by nie oddawać im własnego myślenia. Sztuczna inteligencja jest przydatna wtedy, gdy wzmacnia naturalną: pomaga szybciej dostrzec powiązania, sprawdzić hipotezę, złożyć szkic i uwolnić czas na rozmowę z ludźmi i pracę na miejscu.

Dlatego dla mnie właściwa droga polega na tym, by być nie tylko użytkownikami gotowych przycisków, lecz twórcami nowych rozwiązań: rozumieć metodykę, projektować architekturę, weryfikować wyniki, poprawiać błędy i samemu stawać się silniejszym razem z narzędziem.

AI trzeba wykorzystywać, ale własną naturalną inteligencję trzeba stosować i rozwijać w nie mniejszym stopniu. A jeśli to połączenie pomaga głębiej badać zdarzenia, lepiej wyciągać z nich wnioski i zapobiegać ich powtórzeniu — to znaczy, że technologia naprawdę służy bezpieczeństwu.

Prompty do artykułu

Obieg roboczy z maskowaniem → testowy system offline → kolejny krok w stronę bezpiecznego korporacyjnego Fire

Aktualny status: w rzeczywistej pracy wykorzystywany jest obieg „lokalne narzędzie maskujące → skonfigurowany agent w chmurze → lokalne demaskowanie”. System działający w pełni offline jest już opracowany, ale znajduje się na etapie testów i udoskonaleń. Fire jest rozważany jako kolejny, bezpieczny etap korporacyjny.

Prompt 1. Obecny agent roboczy: wyłącznie zanonimizowane materiały

Związek z artykułem: sekcje „Trzecia wersja” i „Z czego korzystamy dziś”. To obecnie stosowany obieg roboczy po lokalnym maskowaniu.

Jesteś asystentem analitycznym komisji ds. wewnętrznego badania zdarzenia z zakresu BHP i bezpieczeństwa przemysłowego.

OBIEG PRACY:
Dokumenty źródłowe są najpierw maskowane lokalnie. Otrzymujesz wyłącznie zanonimizowane kopie. Po zakończeniu twojej pracy wynik jest lokalnie demaskowany za pomocą osobnego klucza i hasła, których nie posiadasz.

WAŻNE:
- pracuj wyłącznie z wcześniej zanonimizowanymi materiałami;
- nie próbuj odtwarzać imion i nazwisk, działów, adresów ani innych ukrytych wartości;
- nie korzystaj z internetu ani z zewnętrznych faktów, jeśli nie zostały osobno przekazane;
- nie wskazuj winnych;
- nie nazywaj hipotezy ustalonym faktem;
- nie zastępuj decyzji komisji.

Cel: pomóc komisji uporządkować materiały i sprawdzić kompletność badania.

Przy każdym wniosku rozróżniaj:
FACT — bezpośrednio potwierdzone materiałem;
ASSUMPTION — uzasadnione przypuszczenie;
CONFLICT — sprzeczność między materiałami;
GAP — brakująca informacja;
QUESTION — pytanie, które trzeba zamknąć;
HYPOTHESIS — możliwa przyczyna wymagająca potwierdzenia.

Kolejność:
1. Sporządź rejestr otrzymanych materiałów.
2. Wyodrębnij wyłącznie fakty możliwe do potwierdzenia, ze wskazaniem źródła.
3. Sporządź wstępną chronologię.
4. Wskaż sprzeczności i luki.
5. Sformułuj dodatkowe pytania dla komisji.
6. Po zatwierdzeniu chronologii zaproponuj analizę barier.
7. Przyczyny formułuj wyłącznie jako hipotezy do czasu decyzji komisji.
8. Działania wiąż wyłącznie z potwierdzonymi przyczynami.

We wszystkich tabelach podawaj źródło: numer materiału, dokument/plik oraz krótki cytat lub dokładne miejsce, na którym opiera się wniosek.

Prompt 2. Chronologia zdarzeń i czynniki krytyczne

Związek z artykułem: sekcja o chronologii w agencie roboczym i w testowym systemie offline.

Przekazuję zweryfikowane teksty materiałów dotyczących zdarzenia.

Sporządź PROJEKT osi czasu.

Zasady:
1. Nie dodawaj zdarzeń, których nie ma w materiałach.
2. Jeśli czas jest dokładny — podaj go jako dokładny.
3. Jeśli czas jest przybliżony — oznacz go jako „orientacyjnie”.
4. Jeśli dwa źródła podają różny czas lub różną kolejność — nie wybieraj po cichu jednej wersji; wskaż CONFLICT.
5. Dla każdego wiersza podaj: datę/godzinę; zdarzenie lub okoliczność; źródło; status FACT / ASSUMPTION / CONFLICT; dlaczego jest to ważne.
6. Osobno zaproponuj listę czynników krytycznych: zdarzeń/okoliczności, bez których zdarzenie niepożądane lub ciężkość skutków prawdopodobnie byłyby inne.
7. Czynników krytycznych nie uznawaj za zatwierdzone do czasu decyzji komisji.

Na końcu przedstaw:
A. projekt chronologii;
B. listę sprzeczności;
C. listę brakujących danych;
D. projekt czynników krytycznych do omówienia przez komisję.

Prompt 3. Sprzeczności, luki i plan dodatkowych rozmów

Związek z artykułem: sekcje o planowaniu, gromadzeniu materiałów i roli AI jako drugiego analityka.

Na podstawie materiałów i projektu chronologii przygotuj arkusz roboczy komisji.

Należy:
1. Znaleźć sprzeczności między wyjaśnieniami pisemnymi, dokumentami, czasem i danymi technicznymi.
2. Nie traktować różnic w sformułowaniach jako kłamstwa bez dowodów.
3. Dla każdej sprzeczności wskazać: źródło A; źródło B; na czym dokładnie polega różnica; co należy sprawdzić.
4. Sformułować pytania do dodatkowej rozmowy.
5. Pytania powinny być otwarte i neutralne, bez sugerowania odpowiedzi.
6. Osobno sporządzić listę dokumentów, pomiarów, ekspertyz, zdjęć lub schematów, które mogą wypełnić lukę.
7. Oznaczyć, które pytania są kluczowe dla ustalenia okoliczności, barier ochronnych, przyczyn i ciężkości skutków.

Nie wyciągaj wniosku o niewiarygodności relacji wyłącznie na podstawie samego istnienia sprzeczności.

Prompt 4. Logika barier i „bow-tie”

Związek z artykułem: sekcja o logice barier i przejściu do przyczyn.

Wykorzystaj chronologię i czynniki krytyczne zatwierdzone przez komisję.

Sporządź PROJEKT analizy barier.

1. Źródło (źródła) zagrożenia.
2. Zdarzenie niepożądane.
3. Skutki.
4. Bariery prewencyjne: jaka bariera powinna była zapobiec zdarzeniu/kontaktowi; czy istniała; czy była dostępna; czy była stosowana; czy zadziałała; źródło potwierdzenia.
5. Bariery łagodzące: jaka bariera powinna była zapobiec skutkom lub zmniejszyć ich ciężkość; czy istniała; czy zadziałała; źródło potwierdzenia.
6. Dla każdej brakującej lub nieskutecznej bariery sformułuj pytanie „Dlaczego?”.

Nie uznawaj automatycznie braku bariery za przyczynę źródłową.
Nie wymyślaj barier, których nie ma w metodyce, dokumentach ani logice technologicznej, bez oznaczenia HYPOTHESIS.

Wynik — tabela do omówienia przez komisję, a nie zatwierdzony wniosek.

Prompt 5. Drzewo przyczyn i przyczyny źródłowe

Związek z artykułem: sekcja „Metodyka stała się bardziej rygorystyczna” i blok przyczyn.

Dane wejściowe:
- potwierdzona chronologia;
- czynniki krytyczne;
- analiza barier;
- decyzje komisji dotyczące potwierdzonych faktów.

Zbuduj PROJEKT drzewa przyczyn.

Punkt wyjścia: „Zdarzenie niepożądane + skutki”.
Pierwsze dwie gałęzie:
A. Dlaczego doszło do zdarzenia niepożądanego?
B. Dlaczego wystąpiły takie skutki / dlaczego ich ciężkość była taka?

Dalej:
1. Dla każdego węzła zadawaj pytanie „Dlaczego?” tyle razy, ile potrzeba, by dojść do przyczyny systemowej.
2. Każdą przyczynę powiąż z pytaniem nadrzędnym.
3. Każdy czynnik krytyczny musi znaleźć odzwierciedlenie w drzewie albo zostać osobno wyjaśniony jako wykluczony.
4. Działania/błędu człowieka nie przyjmuj za przyczynę źródłową. Kontynuuj analizę: dlaczego działanie było możliwe lub uznawane za dopuszczalne.
5. Przyczynę źródłową proponuj tylko wtedy, gdy opisuje konkretną wadę procesu/systemu; da się ją usunąć; leży w obszarze, na który przedsiębiorstwo/Grupa ma wpływ; pozwala zaproponować konkretny środek.
6. Zabronione są ogólnikowe sformułowania bez rozwinięcia: „niska kultura”, „osobista nieostrożność”, „zła organizacja”, „braki w szkoleniu”.

Dla każdego węzła:
- sformułowanie;
- typ: bezpośrednia / pośrednia / kandydat na przyczynę źródłową;
- źródła potwierdzające;
- powiązane czynniki krytyczne;
- status FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

Nie zatwierdzaj przyczyny źródłowej zamiast komisji.

Prompt 6. Działania korygujące i zapobiegawcze

Związek z artykułem: sekcja o działaniach i oszczędności czasu przy przygotowaniu pierwszego szkicu.

Wykorzystuj wyłącznie przyczyny, które komisja postanowiła ująć w wykazie do opracowania działań.

Dla każdej przyczyny zaproponuj 2–4 warianty działań.

Dla każdego wariantu podaj:
- jaką konkretną przyczynę usuwa lub jaką barierę wzmacnia;
- typ: techniczne / organizacyjne / szkolenie / kontrola / inne;
- oczekiwany, weryfikowalny rezultat;
- jak sprawdzić skuteczność;
- zakres wdrożenia: miejsce zdarzenia / podobne obiekty / przedsiębiorstwo / Grupa;
- czy potrzebny jest tymczasowy środek ochronny do czasu wdrożenia rozwiązania stałego;
- możliwe ryzyka uboczne;
- jakie dane są potrzebne, aby określić termin i osobę odpowiedzialną.

Nie wpisuj imienia i nazwiska osoby odpowiedzialnej ani konkretnego terminu bez decyzji komisji.
Nie proponuj działania typu „przeprowadzić dodatkowy instruktaż” jako uniwersalnego rozwiązania, jeśli nie usuwa ono ustalonej przyczyny.
Osobno oznacz działania, które jedynie wzmacniają kontrolę, ale nie usuwają przyczyny źródłowej.

Prompt 7. Projekt raportu końcowego zgodnie z metodyką

Związek z artykułem: sekcja o tworzeniu pliku Word i zasadzie „pierwszy szkic, a nie dokument do podpisu”.

Przygotuj PROJEKT tekstu raportu wewnętrznego wyłącznie na podstawie elementów zatwierdzonych przez komisję.

Wykorzystaj:
- kartę zdarzenia;
- potwierdzoną chronologię;
- wykaz czynników krytycznych;
- zatwierdzoną analizę barier;
- ostateczne drzewo przyczyn;
- zatwierdzoną listę przyczyn;
- uzgodnione działania;
- rejestr materiałów.

Nie włączaj do wyniku jako faktów niepotwierdzonych hipotez, spornych wersji bez oznaczenia ani wniosków bez źródła.

Struktura:
1. Informacje skrócone i okoliczności.
2. Materiały i metody gromadzenia informacji.
3. Chronologia.
4. Czynniki krytyczne.
5. Bariery ochronne.
6. Analiza przyczyn.
7. Przyczyny źródłowe.
8. Działania korygujące i zapobiegawcze.
9. Załączniki / rejestr materiałów.

Tam, gdzie to możliwe, przy istotnym wniosku zachowuj odwołanie do materiału źródłowego.
W górnej części dokumentu umieść oznaczenie: „PROJEKT. Wymaga weryfikacji i uzgodnienia przez komisję”.
Nie formułuj wniosku o winie.

Prompt 8. Master prompt dla testowego systemu offline

Związek z artykułem: sekcja „System offline już powstał — teraz go testujemy”.

Nie jestem programistą. Pomóż mi stworzyć TESTOWĄ lokalną aplikację do wewnętrznego badania zdarzeń zgodnie z metodyką korporacyjną. Celem tego etapu jest pilotaż i sprawdzenie jakości, a nie automatyczne wdrożenie do eksploatacji produkcyjnej.

Pracuj krok po kroku. Na każdym kroku:
1. wyjaśnij, co robimy i po co;
2. podaj jedno działanie albo jeden gotowy plik/łatkę;
3. poczekaj na mój wynik lub zrzut ekranu;
4. sprawdź go;
5. dopiero potem przejdź dalej.

ARCHITEKTURA DOCELOWA
- Windows 10/11;
- lokalny backend na 127.0.0.1 i interfejs w przeglądarce;
- po jednorazowym przygotowaniu modeli praca z materiałami sprawy bez dostępu do internetu;
- przewidzieć pracę na wydajnym komputerze roboczym; dla słabszej maszyny zaproponować lżejszy model, ale nie ukrywać spadku jakości/szybkości;
- lokalne przechowywanie spraw;
- archiwum sprawy z sumami kontrolnymi;
- historia wersji;
- żadnego obowiązkowego wysyłania materiałów do zewnętrznych API.

MATERIAŁY
- DOCX: akapity, tabele, nagłówki i stopki;
- PDF z warstwą tekstową;
- skany PDF / obrazy — lokalne rozpoznawanie;
- schematy / zdjęcia — przechowywać oryginał, a opis proponować wyłącznie jako wersję roboczą;
- audio / wideo — lokalna transkrypcja;
- nagranie z mikrofonu;
- ręczne wprowadzanie i edycja;
- obowiązkowe oznaczenie „zweryfikowano z oryginałem” przed użyciem tekstu w analizie AI.

MODELE LOKALNE
- LLM przez lokalny silnik (np. Ollama);
- wielojęzyczny model mowy Whisper;
- w razie potrzeby lokalny model vision;
- aplikacja nie może potajemnie pobierać modeli w trakcie badania.

METODYKA / ETAPY
1. Informacje wstępne.
2. Plan komisji.
3. Gromadzenie materiałów.
4. Chronologia i czynniki krytyczne.
5. Bariery i przyczyny.
6. Działania.
7. Raport.

ZASADY AI
- AI wyłącznie proponuje.
- Każdy wniosek przechowuje źródło i cytat.
- Rozróżniać FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Przyczyny są hipotezami do czasu potwierdzenia przez komisję.
- Model nie wyznacza sam osób odpowiedzialnych ani terminów.
- Komisja musi mieć możliwość zaakceptowania, odrzucenia lub zredagowania każdej propozycji.
- Końcowy plik Word to edytowalny projekt.
- W raporcie uwzględniać drzewo przyczyn, bariery, rejestr i załączniki.

BEZPIECZEŃSTWO
- bez CDN i zewnętrznej telemetrii;
- połączenia sieciowe w ramach badania wyłącznie przez loopback;
- informować użytkownika, że praca lokalna nie oznacza automatycznej anonimizacji;
- nie przechowywać sekretów w jawnym kodzie po stronie klienta;
- przewidzieć usuwanie sprawy, kopię zapasową i przenoszenie.

Zacznij od struktury katalogów, formatu danych sprawy i modelu zagrożeń. Nie pisz kodu przed moim potwierdzeniem.

STATUS PILOTAŻOWY
- wyraźnie oznaczaj wersję jako „TESTOWA / PILOTAŻ”;
- dodaj zestaw kontrolnych przypadków szkoleniowych;
- dla każdego przypadku porównaj wynik AI z wnioskami człowieka/komisji;
- prowadź dziennik wykrytych defektów i iteracji;
- nie nazywaj systemu gotowym do eksploatacji produkcyjnej przed zakończeniem testów.

Prompt 9. Audyt pilotażowego systemu offline

Związek z artykułem: sekcje o granicach automatyzacji, poufności i obecnym statusie testowym.

Przeprowadź audyt gotowej aplikacji i projektu dokumentacji badania przed przekazaniem ich komisji.

SPRAWDŹ POD WZGLĘDEM TECHNICZNYM
1. Czy podczas pracy ze sprawą występują zewnętrzne połączenia sieciowe.
2. Czy używane są CDN, zewnętrzne czcionki, chmurowy speech-to-text, zewnętrzne API.
3. Gdzie przechowywane są pliki źródłowe, transkrypcje, modele lokalne i kopie zapasowe.
4. Co się dzieje po usunięciu sprawy.
5. Czy dokumenty źródłowe nie trafiają do logów diagnostycznych.
6. Czy zawartość sprawy nie jest wysyłana na zewnątrz w razie błędu.

SPRAWDŹ POD WZGLĘDEM METODYCZNYM
7. Czy wszystkie istotne wnioski mają źródło.
8. Czy fakty są oddzielone od hipotez.
9. Czy wszystkie czynniki krytyczne są odzwierciedlone w analizie przyczyn.
10. Czy działania człowieka nie zostały uznane za przyczynę źródłową bez analizy uwarunkowań systemowych.
11. Czy działania są powiązane z konkretnymi przyczynami/barierami.
12. Czy model nie wyznaczył osób odpowiedzialnych i terminów bez decyzji komisji.
13. Czy projekt raportu nie jest przedstawiany jako zatwierdzony dokument.

SPRAWDŹ POUFNOŚĆ
14. Jakie dane osobowe/medyczne znajdują się w lokalnej sprawie.
15. Czy potrzebne jest dodatkowe maskowanie na potrzeby prezentacji, publikacji lub przekazania.
16. Czy nazwy plików i zrzuty ekranu nie zawierają zbędnych imion i nazwisk.

Wynik przedstaw w tabeli:
Weryfikacja | Status | Wykryte ryzyko | Co poprawić | Kto powinien potwierdzić.

Nie poprawiaj automatycznie merytorycznych wniosków z badania.

SPRAWDŹ STATUS DOJRZAŁOŚCI
17. Czy istnieje zestaw przypadków kontrolnych i wyniki porównania.
18. Które funkcje są już stabilne, a które pozostają eksperymentalne.
19. Jakie błędy/ograniczenia muszą zostać usunięte przed zastosowaniem produkcyjnym.
20. Czy interfejs nie stwarza fałszywego wrażenia, że wynik AI jest decyzją komisji.

Jak korzystać z promptów

• Prompt 1 — obieg roboczy stosowany obecnie: wyłącznie wcześniej zanonimizowane materiały; klucz demaskowania nie jest przekazywany agentowi.
• Prompt 2–7 — metodyczne bloki robocze, które można wykorzystać zarówno w obecnym agencie, jak i w przyszłym obiegu lokalnym/serwerowym.
• Prompt 8 — tworzenie i dalsze dopracowywanie testowego systemu działającego w pełni offline.
• Prompt 9 — audyt pilotażu przed rozszerzeniem zakresu stosowania.

Główna zasada serii pozostaje niezmienna: najpierw chronimy dane i ustalamy metodykę, a dopiero potem automatyzujemy. AI wzmacnia pracę komisji, ale nie zastępuje profesjonalnego myślenia, weryfikacji faktów ani odpowiedzialności człowieka.