AI bardzo szybko weszło do obszarów, w których przez lata dominowały arkusze Excela, checklisty i dokumenty kopiowane z projektu na projekt. Ocena ryzyka maszyn również stała się podatna na tę pokusę. Wystarczy wpisać nazwę maszyny, dodać kilka ogólnych informacji i po chwili można otrzymać tabelę, która wygląda profesjonalnie: zagrożenia, następstwa, środki ochronne, poziomy ryzyka, ryzyko resztkowe.
Na pierwszy rzut oka wszystko się zgadza.
Tylko że ładnie wyglądająca tabela nie jest jeszcze oceną ryzyka zgodną z ISO 12100.
Ocena ryzyka nie polega na wygenerowaniu listy zagrożeń. Nie polega też na wypełnieniu komórek technicznie brzmiącymi zdaniami. Jej wartość nie wynika z tego, że dokument ma dużo wierszy, kolorowe oznaczenia i profesjonalny język. Wartość oceny ryzyka wynika z tego, czy można odtworzyć sposób myślenia, który doprowadził do konkretnych decyzji projektowych.
A to jest zupełnie inny poziom odpowiedzialności.
AI w ocenie ryzyka maszyn: nowa technologia, stary problem
Przez lata wiele ocen ryzyka maszyn wyglądało tak samo: Excel, lista zagrożeń, kilka ogólnych skutków, standardowe środki ochronne i na końcu obowiązkowa redukcja ryzyka. Dokument był. Rubryki były wypełnione. Kolory się zgadzały. Tylko że bardzo często brakowało najważniejszego elementu ISO 12100 — realnego powiązania zagrożenia z zadaniem człowieka, fazą życia maszyny, sytuacją zagrożenia i zdarzeniem niebezpiecznym.
Czy zagrożenie zostało wpisane? Zostało.
Czy ryzyko początkowe zostało ocenione? Zostało.
Czy po zastosowaniu środka ochronnego ryzyko spadło? Oczywiście, że spadło. W końcu po coś ta tabela była wypełniana.
Tylko czy ktoś naprawdę sprawdził, co operator robi przy przezbrojeniu? Czy ktoś rozumiał, jak wygląda usuwanie zacięcia? Czy ktoś przeanalizował czyszczenie, regulację, konserwację, nastawianie, tryb ręczny, dostęp serwisowy i przewidywalne obchodzenie zabezpieczeń? Czy środek redukcji ryzyka wynikał z analizy, czy po prostu z potrzeby domknięcia wiersza w arkuszu?
To jest niewygodne pytanie, bo w wielu przypadkach odpowiedź brzmi: nie.
Problemem nigdy nie był sam Excel. Excel jest tylko narzędziem. Problem polegał na tym, że z Excela bardzo łatwo było zrobić atrapę procesu. Wystarczyło wpisać „ruchome elementy”, „zmiażdżenie”, „osłona stała”, „instrukcja stanowiskowa”, „szkolenie operatora” i dokument zaczynał wyglądać znajomo. Technicznie. Bezpiecznie. Poważnie.
Ale znajomy układ kolumn nie oznacza jeszcze, że ktoś wykonał ocenę ryzyka.
Dziś pojawia się AI i ten sam błąd można zrobić szybciej, ładniej i bardziej przekonująco. To jest właśnie moment, w którym trzeba się zatrzymać. Bo AI nie tworzy problemu od zera. AI tylko wzmacnia problem, który w ocenie ryzyka maszyn istniał od dawna: mylenie dokumentu z procesem.
Kiedyś człowiek kopiował stare wiersze z poprzedniego projektu. Dziś model językowy może wygenerować nowe wiersze w kilka sekund. Kiedyś tabela wyglądała topornie. Dziś może wyglądać dojrzale, spójnie i profesjonalnie. Kiedyś widać było, że ktoś coś przepisał. Dziś tekst może brzmieć tak, jakby napisał go ekspert.
I właśnie dlatego ryzyko jest większe.
Bo słaby Excel często zdradzał sam siebie. Był powtarzalny, ubogi, posklejany z gotowych formułek. Tabelka wygenerowana przez AI może już nie wyglądać słabo. Może wyglądać bardzo dobrze. Może mieć logiczne zdania, płynny język, branżową terminologię i pozornie kompletną strukturę. Może sprawiać wrażenie, że ktoś naprawdę przeanalizował maszynę.
Tylko że wrażenie analizy to jeszcze nie analiza.
ISO 12100 nie opisuje sztuki produkowania dobrze brzmiących dokumentów. ISO 12100 opisuje metodykę osiągania bezpieczeństwa przy projektowaniu maszyn, obejmującą ocenę ryzyka i redukcję ryzyka. To jest proces oparty na wiedzy o projektowaniu, użytkowaniu, incydentach, wypadkach i ryzykach związanych z maszynami. Nie chodzi więc o to, żeby wygenerować listę technicznych zagrożeń. Chodzi o to, żeby zrozumieć, gdzie człowiek spotyka się z maszyną, co wtedy robi, co może pójść źle i jak projekt powinien na to odpowiedzieć.
To jest zasadnicza różnica.
Lista zagrożeń może powstać bez głębokiego zrozumienia maszyny. Wystarczy znać typ urządzenia. Przenośnik? Będą wciągnięcia, pochwycenia, zmiażdżenia. Prasa? Będzie strefa narzędzia, ruch roboczy, energia resztkowa. Robot? Będzie kolizja, wejście w strefę, tryb programowania, nieoczekiwany ruch. Linia pakująca? Będą napędy, taśmy, siłowniki, noże, elementy grzejne, dostęp do stref serwisowych.
To wszystko można wygenerować.
Pytanie brzmi: co z tego?
Bo sama obecność zagrożenia w tabeli niczego jeszcze nie wyjaśnia. Nie mówi, kto jest narażony. Nie mówi, podczas jakiego zadania. Nie mówi, czy dostęp występuje codziennie, raz w tygodniu czy tylko przy awarii. Nie mówi, czy człowiek wykonuje czynność przy zatrzymanej maszynie, w trybie ręcznym, z podtrzymaniem energii, z otwartą osłoną, pod presją czasu albo z ograniczoną widocznością. Nie mówi też, czy zastosowany środek ochronny naprawdę rozwiązuje problem, czy tylko wygląda dobrze w komórce tabeli.
A ocena ryzyka zaczyna się właśnie tam.
Nie przy haśle „zagrożenie mechaniczne”.
Nie przy automatycznym doborze ciężkości urazu.
Nie przy magicznym spadku ryzyka po wpisaniu „szkolenie operatora”.
Ocena ryzyka zaczyna się od pytania: jaka konkretna osoba, w jakiej fazie życia maszyny, podczas jakiego zadania, w jakich warunkach może znaleźć się w sytuacji zagrożenia?
Dopiero potem można pytać dalej.
Co może zainicjować zdarzenie niebezpieczne? Czy będzie to nieoczekiwany rozruch? Utrata stabilności? Dostęp do ruchomych części? Błąd w logice sterowania? Energia resztkowa? Zacięcie materiału? Błędna regulacja? Brak widoczności? Praca jednoosobowa? Źle zaprojektowany dostęp? A może normalna, codziennie wykonywana czynność, którą projektant potraktował jako „serwisową”, chociaż operator robi ją piętnaście razy na zmianę?
To są pytania, których nie zastąpi ładna tabela.
Rozporządzenie maszynowe 2023/1230 również nie mówi: „przygotuj dokument wyglądający jak ocena ryzyka”. Mówi o obowiązku przeprowadzenia oceny ryzyka w celu określenia mających zastosowanie zasadniczych wymagań w zakresie ochrony zdrowia i bezpieczeństwa oraz środków potrzebnych do ograniczenia ryzyka. W praktyce oznacza to konieczność przejścia przez ograniczenia maszyny, użytkowanie zgodne z przeznaczeniem, racjonalnie przewidywalne niewłaściwe użycie, identyfikację zagrożeń, szacowanie ryzyka, ocenę ryzyka i redukcję ryzyka.
I tu AI może być bardzo pomocne — ale tylko pod jednym warunkiem.
Musi pracować na procesie, a nie zamiast procesu.
Jeżeli użytkownik wpisze do modelu: „przygotuj ocenę ryzyka dla maszyny pakującej”, to dostanie coś, co będzie przypominało ocenę ryzyka. Prawdopodobnie nawet całkiem niezłą na pierwszy rzut oka. Będą tam zagrożenia mechaniczne, elektryczne, ergonomiczne, może hałas, może elementy pneumatyki, może ryzyko poparzenia, może kilka ogólnych środków ochronnych.
Tylko że taka odpowiedź nie będzie oceną konkretnej maszyny.
Będzie statystycznie prawdopodobnym opisem typowej maszyny pakującej.
A między jednym a drugim jest przepaść.
Konkretna maszyna ma konkretne ograniczenia. Konkretny układ dostępu. Konkretne tryby pracy. Konkretne sekwencje ruchu. Konkretne miejsca zacięć. Konkretne czynności utrzymania ruchu. Konkretną przestrzeń wokół siebie. Konkretnego operatora, który pracuje w konkretnym zakładzie, z konkretną presją produkcyjną, na konkretnej zmianie, często z konkretnymi obejściami, które pojawiły się dlatego, że projekt nie przewidział rzeczywistości.
AI tego nie wie.
Nie wie, że operator musi włożyć rękę głębiej, niż zakładał projektant.
Nie wie, że panel jest po złej stronie i dlatego człowiek obserwuje ruch maszyny z miejsca, którego nikt nie przewidział.
Nie wie, że osłona jest ciężka, więc po dwóch tygodniach zaczęto ją zostawiać otwartą.
Nie wie, że procedura czyszczenia wymaga narzędzia, którego nikt nie używa, bo zabiera za dużo czasu.
Nie wie, że w instrukcji wpisano dwie osoby, a w realnym procesie pracuje jedna.
Nie wie, że przezbrojenie „raz na jakiś czas” w praktyce odbywa się kilka razy dziennie.
Nie wie, że awaria, którą projektant uznał za mało prawdopodobną, dla utrzymania ruchu jest normalnym poniedziałkiem.
I właśnie dlatego AI bez kontekstu jest niebezpiecznie przekonujące.
Nie dlatego, że zawsze się myli. Często się nie myli w sprawach ogólnych. Problem polega na tym, że ocena ryzyka nie rozstrzyga się na poziomie ogólnym. Rozstrzyga się w szczególe. W tym jednym dostępie, tej jednej czynności, tym jednym trybie pracy, tej jednej sytuacji, w której człowiek robi coś trochę inaczej niż zakładała dokumentacja.
Tu nie wystarczy „zagrożenie: zmiażdżenie”.
Trzeba wiedzieć: przez co, kiedy, kogo, podczas jakiego zadania, po jakiej sekwencji zdarzeń, z jakim możliwym skutkiem i dlaczego wybrany środek redukcji ryzyka jest adekwatny.
Dlatego dobre wykorzystanie AI w ocenie ryzyka nie powinno zaczynać się od polecenia: „wygeneruj tabelę”. Powinno zaczynać się od zebrania kontekstu. Od ograniczeń maszyny. Od faz życia. Od zadań. Od rzeczywistych interakcji człowieka z maszyną. Od sytuacji zagrożenia. Od zdarzeń niebezpiecznych. Od pytań, które zmuszają inżyniera do opisania rzeczywistości, a nie tylko do zatwierdzenia ładnie brzmiącej odpowiedzi.
Bo AI może pomóc zapytać: czy uwzględniłeś czyszczenie?
Może pomóc zapytać: czy operator ma dostęp do strefy ruchu podczas usuwania zacięcia?
Może pomóc zapytać: czy ta czynność występuje tylko przy konserwacji, czy również podczas normalnej pracy?
Może pomóc zapytać: czy ryzyko redukujesz przez projektowanie bezpieczne samo w sobie, przez środek ochronny, czy tylko przez informację dla użytkownika?
Ale AI nie powinno samo odpowiadać na te pytania bez danych z maszyny.
Bo wtedy nie analizuje. Zgaduje.
A zgadywanie
w bezpieczeństwie maszyn bywa eleganckie tylko do pierwszego wypadku.
ISO 12100 nie zaczyna się od zagrożeń
To jest jeden z najczęstszych błędów w ocenie ryzyka maszyn: zaczynamy od pytania „jakie zagrożenia ma maszyna?”.
Na pierwszy rzut oka brzmi rozsądnie. Maszyna ma napędy, więc są zagrożenia mechaniczne. Ma zasilanie, więc są zagrożenia elektryczne. Ma pneumatykę, więc mamy energię sprężonego powietrza. Ma gorące elementy, więc pojawia się ryzyko oparzenia. Ma ruchome części, więc wpisujemy pochwycenie, zmiażdżenie, przecięcie, uderzenie.
I tabela zaczyna rosnąć.
Tylko że to nadal nie jest jeszcze ocena ryzyka.
To jest katalog potencjalnych zagrożeń. Przydatny, ale niewystarczający. ISO 12100 nie każe patrzeć na maszynę jak na statyczny zbiór niebezpiecznych elementów. Każe patrzeć na maszynę w relacji do człowieka, który będzie ją transportował, instalował, uruchamiał, obsługiwał, regulował, czyścił, konserwował, naprawiał, przezbrajał, diagnozował i wycofywał z eksploatacji.
Zagrożenie samo w sobie jeszcze nie opisuje ryzyka.
Ostry element jest zagrożeniem. Ale ryzyko pojawia się dopiero wtedy, gdy ktoś może mieć z nim kontakt. Napęd jest źródłem energii. Ale ryzyko zależy od tego, kto, kiedy i po co znajduje się w jego pobliżu. Ruchomy mechanizm może być całkowicie odseparowany w normalnej pracy, ale stawać się krytyczny podczas czyszczenia, usuwania zacięcia albo testów w trybie ręcznym.
Dlatego pytanie „jakie zagrożenia ma maszyna?” jest za płytkie.
Lepsze pytanie brzmi: kto, podczas jakiego zadania, w jakiej fazie życia maszyny, w jaki sposób może znaleźć się w sytuacji zagrożenia?
To zmienia wszystko.
Bo wtedy nie analizujemy już abstrakcyjnej maszyny. Analizujemy realny proces pracy. Nie pytamy tylko, czy istnieje ruchoma część. Pytamy, czy człowiek ma powód, żeby się do niej zbliżyć. Nie pytamy tylko, czy istnieje strefa niebezpieczna. Pytamy, kiedy i dlaczego ktoś może do niej wejść. Nie pytamy tylko, czy zastosowano osłonę. Pytamy, czy ta osłona pozwala wykonać zadanie bez obchodzenia zabezpieczeń.
To jest różnica między dokumentem, który wygląda jak ocena ryzyka, a oceną ryzyka, która naprawdę wynika z ISO 12100.
W słabych ocenach ryzyka zagrożenie żyje osobno, zadania człowieka osobno, zdarzenia niebezpieczne osobno, środki ochronne osobno, a ryzyko resztkowe spada trochę jak z obowiązku. W dobrych ocenach ryzyka widać nie tyle jeden sztywny łańcuch, ile tok rozumowania: jakie są ograniczenia maszyny, w jakich fazach życia występują zagrożenia, jakie zadania wykonuje człowiek, jakie warunki pracy i otoczenia trzeba uwzględnić, gdzie powstają sytuacje zagrożenia, jakie zdarzenia niebezpieczne mogą wystąpić i do jakiej szkody mogą doprowadzić.
To ważne rozróżnienie.
Nie każda sytuacja zagrożenia musi być opisana przez osobne zdarzenie niebezpieczne. I nie każde zdarzenie niebezpieczne wynika bezpośrednio z zadania operatora. Ocena ryzyka maszyny nie może więc działać jak prosty formularz: „zadanie → sytuacja → zdarzenie → środek ochronny”. Taki układ bywa przydatny w wielu scenariuszach, ale nie wyczerpuje logiki ISO 12100.
Czasem punktem wyjścia jest zadanie człowieka: czyszczenie, przezbrojenie, regulacja, usuwanie zacięcia, nastawianie, konserwacja. Wtedy pytamy, czy człowiek może znaleźć się w sytuacji zagrożenia i co może uruchomić scenariusz prowadzący do szkody.
Ale czasem punktem wyjścia jest zdarzenie: pęknięcie przewodu, utrata stateczności, nieoczekiwany rozruch, awaria układu sterowania, spadek ładunku, trzęsienie ziemi, pożar, utrata zasilania albo uwolnienie energii. Takie zdarzenie może dopiero stworzyć sytuację zagrożenia dla człowieka albo zmienić warunki pracy maszyny w sposób, którego nie widać, jeśli analiza zaczyna się wyłącznie od listy zadań operatora.
Dlatego dobra ocena ryzyka nie powinna wciskać każdego scenariusza w jeden sztywny schemat. Powinna umieć obsłużyć oba kierunki myślenia: zadaniowy i zdarzeniowy.
W podejściu zadaniowym pytamy: kto, kiedy, gdzie i podczas jakiej czynności może zostać narażony na zagrożenie?
W podejściu zdarzeniowym pytamy: jakie zdarzenie może wystąpić w maszynie, układzie sterowania, instalacji, środowisku lub otoczeniu i jak może doprowadzić do szkody?
Dopiero po połączeniu tych dwóch perspektyw ocena ryzyka zaczyna mieć sens. Inaczej łatwo przeoczyć scenariusze, które nie pasują do wygodnej tabelki.
I tu znowu wraca problem AI.
Model językowy bardzo chętnie ułoży wszystko w elegancki, liniowy schemat. Będzie wyglądało logicznie. Będzie miało strzałki. Będzie miało kolumny. Tylko że maszyna, człowiek, awaria i otoczenie nie zawsze układają się w jedną prostą sekwencję. Czasem sytuacja zagrożenia wynika z zadania. Czasem zdarzenie niebezpieczne tworzy sytuację zagrożenia. Czasem oba elementy występują równolegle. A czasem najważniejsze jest właśnie to, czego nie da się łatwo upchnąć w jednym wierszu Excela.
Dlatego proces oceny ryzyka musi być bardziej inteligentny niż sama tabela. Musi pozwalać na identyfikację sytuacji zagrożenia i/lub zdarzeń niebezpiecznych, a nie wymuszać sztucznej relacji tam, gdzie jej nie ma.
Bo tabela bez łańcucha decyzji jest tylko formatką. Można ją wypełnić ręcznie. Można ją skopiować z poprzedniego projektu. Można ją wygenerować przez AI. Efekt wizualny może być podobny. Różnica pojawia się dopiero wtedy, gdy ktoś zapyta: „dlaczego tak?”.
Dlaczego uznano, że dostęp występuje tylko sporadycznie?
Dlaczego przyjęto taką ciężkość urazu?
Dlaczego zignorowano tryb czyszczenia?
Dlaczego nie uwzględniono usuwania zacięcia?
Dlaczego zastosowano tylko szkolenie, skoro dostęp do strefy niebezpiecznej wynika z normalnej organizacji pracy?
Dlaczego ryzyko spadło po wpisaniu instrukcji, jeśli projekt nadal wymusza kontakt człowieka z ruchem maszyny?
To są pytania, które bardzo szybko oddzielają rzeczywistą analizę od dokumentacyjnej dekoracji.
I tu właśnie AI może zarówno pomóc, jak i zaszkodzić.
Może pomóc, jeżeli pracuje na uporządkowanym procesie. Jeżeli dostaje konkretne zadania, fazy życia maszyny, opis dostępów, tryby pracy, ograniczenia przestrzenne, rodzaje energii, sekwencje ruchu, wymagania serwisowe i realne dane od projektanta lub użytkownika. Wtedy może wspierać identyfikację luk, podpowiadać pytania kontrolne, porównywać scenariusze, porządkować dokumentację i pomagać redagować uzasadnienia.
Ale może też zaszkodzić, jeśli zaczyna od końca.
Jeżeli AI od razu generuje tabelę, to bardzo często produkuje odpowiedzi bez procesu, który powinien je poprzedzać. Wpisuje zagrożenia, bo statystycznie pasują do danej maszyny. Dobiera skutki, bo brzmią technicznie. Wskazuje środki ochronne, bo często występują w podobnych opisach. Obniża ryzyko, bo tabela ma pokazać redukcję.
Tylko że ISO 12100 nie polega na tym, żeby ryzyko „ładnie spadło” w ostatniej kolumnie.
Redukcja ryzyka ma wynikać z konkretnej decyzji projektowej. Najpierw trzeba pytać o możliwość eliminacji zagrożenia lub ograniczenia ryzyka przez projektowanie bezpieczne samo w sobie. Dopiero później o techniczne środki ochronne. A dopiero na końcu o informacje dla użytkownika, ostrzeżenia, instrukcje, szkolenia czy środki ochrony indywidualnej.
W wielu tabelach ten porządek jest tylko teorią.
Najpierw wpisuje się zagrożenie. Potem wpisuje się „osłona”, „instrukcja”, „szkolenie”, „procedura LOTO”, „oznakowanie”. Ryzyko spada. Wiersz zamknięty. Można przejść dalej.
Tylko czy ktoś naprawdę sprawdził, czy osłona nie utrudnia pracy tak bardzo, że będzie obchodzona?
Czy procedura LOTO jest realna przy czynności wykonywanej kilka razy na godzinę?
Czy szkolenie jest środkiem redukcji ryzyka, czy wygodnym sposobem przerzucenia odpowiedzialności na operatora?
Czy instrukcja rozwiązuje problem projektowy, czy tylko opisuje ryzyko, którego nie chciało się usunąć?
To nie są drobiazgi redakcyjne. To jest sedno oceny ryzyka.
Dlatego najgorsze wykorzystanie AI w tym obszarze polega na tym, że model wygeneruje wiarygodnie brzmiące odpowiedzi na pytania, których nikt naprawdę nie zadał. Powstanie dokument bez bólu. Bez rozmowy z konstruktorem. Bez przejścia po maszynie. Bez obserwacji operatora. Bez analizy trybów pracy. Bez sporu o to, czy ryzyko trzeba redukować konstrukcyjnie, czy można zostawić je w instrukcji.
A dobra ocena ryzyka często właśnie na tym sporze polega.
Na niewygodnym pytaniu: dlaczego człowiek w ogóle musi tam wkładać rękę?
Na konflikcie między produkcją a bezpieczeństwem: czy ta osłona naprawdę pozwoli utrzymać takt?
Na rozmowie z utrzymaniem ruchu: czy ta awaria jest wyjątkowa, czy wszyscy wiedzą, że zdarza się co tydzień?
Na decyzji projektowej: czy zmieniamy konstrukcję, dodajemy blokadę, zmieniamy dostęp, zmieniamy procedurę, ograniczamy energię, czy tylko dopisujemy ostrzeżenie?
AI może wesprzeć taką rozmowę. Może nawet pomóc ją lepiej uporządkować.
Ale nie może jej zastąpić piękną tabelą.
Bo w ocenie ryzyka najważniejsze nie jest to, czy dokument ma wszystkie kolumny. Najważniejsze jest to, czy za każdą istotną decyzją stoi możliwy do odtworzenia tok rozumowania. Jeżeli tego toku nie ma, to nie mamy audytowalnej oceny ryzyka. Mamy dokument, który wygląda jak wynik pracy inżynierskiej.
A to duża różnica.
AI jako asystent inżyniera, nie autor odpowiedzialności
To nie znaczy, że AI nie ma miejsca w ocenie ryzyka maszyn.
Ma.
Tylko trzeba bardzo precyzyjnie ustawić jego rolę. AI może być dobrym asystentem inżyniera. Może pomóc zauważyć luki, uporządkować informacje, zaproponować pytania kontrolne, wskazać typowe scenariusze zagrożeń, poprawić język dokumentacji i przyspieszyć pracę nad raportem. Może być użyteczne tam, gdzie człowiek ma już dane, zna maszynę i potrzebuje wsparcia w przejściu przez proces.
Ale AI nie powinno być traktowane jak autor odpowiedzialności.
Bo odpowiedzialność nie powstaje w modelu językowym. Odpowiedzialność zostaje po stronie producenta, projektanta, integratora, zespołu inżynierskiego, osoby podpisującej dokumentację i podmiotu, który wprowadza maszynę do obrotu albo oddaje ją do użytku. To oni muszą wykazać, że ocena ryzyka nie jest tylko tekstem, ale wynikiem konkretnego procesu.
AI może wygenerować zdanie: „zastosować osłonę blokującą z ryglowaniem”.
Ale ktoś musi odpowiedzieć na pytania: dlaczego właśnie taką? Dla jakiego dostępu? Przy jakim czasie zatrzymania? Dla jakiej funkcji bezpieczeństwa? Przy jakiej częstotliwości wejść? Czy osłona nie stworzy nowego ryzyka? Czy nie utrudni czyszczenia? Czy nie wymusi obchodzenia zabezpieczeń? Czy nie trzeba przewidzieć trybu pracy z otwartą osłoną? Czy funkcja bezpieczeństwa osiąga wymagany poziom niezawodności?
AI może napisać: „przeszkolić operatora”.
Ale ktoś musi uczciwie sprawdzić, czy szkolenie w ogóle może być środkiem redukcji w danym przypadku. Jeżeli człowiek codziennie musi sięgać w pobliże ruchomego elementu, to problemem nie jest brak szkolenia. Problemem jest projekt, który wymusza kontakt człowieka z zagrożeniem. Dopisanie szkolenia może wtedy wyglądać dobrze w tabeli, ale nie rozwiązuje problemu.
AI może napisać: „stosować procedurę LOTO”.
Ale ktoś musi zapytać, czy mówimy o czynności konserwacyjnej wykonywanej raz na miesiąc, czy o usuwaniu zacięcia wykonywanym kilka razy na zmianę. Bo jeżeli procedura odłączenia energii jest wpisana przy czynności, której realnie nikt nie będzie wykonywał w takim trybie, to nie mamy redukcji ryzyka. Mamy życzenie wpisane w komórkę.
I takich przykładów są setki.
Właśnie dlatego dobre wykorzystanie AI wymaga czegoś, czego AI samo z siebie nie ma: kontekstu.
Nie ogólnego kontekstu typu „maszyna pakująca”.
Konkretnego kontekstu.
Jakie są ograniczenia maszyny? Jakie ma tryby pracy? Jakie są fazy jej życia? Kto ma do niej dostęp? Jakie zadania wykonuje operator? Jakie zadania wykonuje utrzymanie ruchu? Co dzieje się podczas przezbrojenia? Jak wygląda czyszczenie? Gdzie występują zacięcia? Jakie są źródła energii? Czy są ruchy niebezpieczne po zaniku zasilania? Czy są elementy gorące? Czy występują substancje, pyły, hałas, ergonomia, ręczne manipulacje, ostre krawędzie, upadki, wejścia na podesty, dostęp do strefy roboczej?
Dopiero na takim materiale AI może sensownie pomagać.
Bez tego działa jak człowiek, który pisze ocenę ryzyka po obejrzeniu nazwy maszyny w nagłówku.
Może trafić w wiele ogólnych punktów. Może nawet napisać coś rozsądnego. Ale rozsądne ogólniki nie są jeszcze analizą konkretnego ryzyka.
To jest ten moment, w którym warto odróżnić dwa podejścia.
Pierwsze podejście brzmi: „AI, wygeneruj mi ocenę ryzyka”.
Drugie podejście brzmi: „Przeprowadźmy ocenę ryzyka według procesu, a AI wykorzystajmy tam, gdzie może pomóc wykryć braki, uporządkować dane i przygotować czytelne uzasadnienia”.
Różnica jest fundamentalna.
W pierwszym podejściu AI staje się maszynką do produkowania dokumentu. W drugim — narzędziem wspierającym proces inżynierski. W pierwszym najważniejszy jest efekt końcowy: tabela. W drugim najważniejszy jest ślad decyzji: dlaczego tak oceniono ryzyko i dlaczego taki środek redukcji uznano za właściwy.
A ocena ryzyka bez śladu decyzji jest słaba nawet wtedy, gdy wygląda profesjonalnie.
Prompt nie jest metodyką ISO 12100
W tym miejscu pojawia się kolejna pokusa: skoro AI potrafi wygenerować dobrą odpowiedź, to wystarczy napisać lepszy prompt.
„Uwzględnij ISO 12100”.
„Uwzględnij cały cykl życia maszyny”.
„Zidentyfikuj zagrożenia mechaniczne, elektryczne, termiczne, ergonomiczne i sterownicze”.
„Dodaj ryzyko początkowe, środki redukcji i ryzyko resztkowe”.
Brzmi lepiej. I faktycznie wynik może być lepszy.
Tylko że prompt nadal nie jest metodyką.
Można napisać bardzo ambitne polecenie. Można zażądać tabeli z piętnastoma kolumnami. Można kazać AI uwzględnić fazy życia maszyny, przewidywalne niewłaściwe użycie i hierarchię redukcji ryzyka. Można nawet dostać odpowiedź, która wygląda znacznie lepiej niż większość ręcznie robionych arkuszy.
Ale jeżeli dane wejściowe są puste, ogólne albo oderwane od rzeczywistości maszyny, to wynik nadal będzie tylko eleganckim rozwinięciem założeń.
AI nie doda faktów, których nie zna.
Może je dopowiedzieć. Może je uśrednić. Może założyć, że dana maszyna działa podobnie do innych maszyn. Może wygenerować typowy scenariusz dla typowego przypadku. Ale w ocenie ryzyka najważniejsze są często właśnie nietypowe szczegóły.
To, że dostęp do strefy niebezpiecznej znajduje się od strony, której nie widać z pulpitu.
To, że operator musi jednocześnie obserwować materiał i naciskać przycisk.
To, że po zatrzymaniu maszyny element jeszcze przez chwilę się porusza.
To, że przy awarii materiał trzeba wyciągać ręcznie.
To, że konserwacja wymaga wejścia na konstrukcję, której projektant nie potraktował jak stanowiska dostępu.
To, że przy czyszczeniu trzeba usunąć osłonę, bo inaczej nie da się dotrzeć do zabrudzonego miejsca.
To, że maszyna pracuje w wilgoci, zapyleniu, niskiej temperaturze albo w otoczeniu innych maszyn, które zmieniają rzeczywiste warunki dostępu.
To, że instrukcja mówi jedno, a praktyka na hali robi drugie.
I teraz pytanie: skąd AI ma to wiedzieć?
Nie z nazwy maszyny.
Nie z ogólnego opisu.
Nie z promptu, który brzmi profesjonalnie.
Dlatego problemem nie jest to, że AI „nie zna ISO 12100”. Problem jest głębszy. AI może znać strukturę, język i typowe wymagania. Może dobrze imitować formę. Ale ocena ryzyka nie jest konkursem na znajomość słownictwa normowego. To proces wiązania zagrożeń z rzeczywistymi zadaniami człowieka i realnymi decyzjami projektowymi.
Prompt może pomóc uruchomić rozmowę.
Nie może zastąpić rozpoznania maszyny.
Nie może zastąpić obserwacji.
Nie może zastąpić decyzji konstruktora.
Nie może zastąpić odpowiedzialności producenta.
Może natomiast zrobić coś bardzo podstępnego: dać poczucie, że skoro odpowiedź jest długa, techniczna i uporządkowana, to proces został wykonany.
A to jest dokładnie ten sam błąd, który wcześniej robiono w Excelu. Tylko w lepszej oprawie.
Największa wartość jest w pytaniach, nie w automatycznych odpowiedziach
Dobre narzędzie do oceny ryzyka nie powinno zaczynać od tego, że obiecuje gotowy wynik.
Powinno zaczynać od tego, że zmusza do zadania niewygodnych pytań.
Jakie są granice maszyny?
Kto będzie jej używał?
Kto będzie ją czyścił?
Kto będzie ją konserwował?
Kto będzie usuwał zacięcia?
Kto będzie pracował w trybie ręcznym?
Kto będzie miał dostęp do stref niebezpiecznych podczas regulacji?
Jakie czynności wykonuje się codziennie, a jakie tylko przy awarii?
Które zadania wymagają obejścia normalnych środków ochronnych?
Które czynności są opisane w instrukcji jako serwisowe, ale w praktyce wykonuje je operator?
Które środki ochronne mogą zostać obchodzone, bo utrudniają produkcję?
Które ryzyka zostały tylko „opisane”, ale nie zostały realnie zredukowane?
To są pytania, które bolą. Ale bez nich ocena ryzyka jest słaba.
AI może pomóc te pytania wygenerować. Może nawet stworzyć bardzo dobrą listę kontrolną. Może zapytać o fazy życia maszyny, przewidywalne niewłaściwe użycie, dostęp do energii, ergonomię, hałas, substancje, utratę stabilności, błędy sterowania, tryby awaryjne i prace serwisowe.
To jest wartościowe.
Ale dopiero odpowiedzi inżyniera, projektanta, użytkownika lub zespołu oceniającego nadają temu sens.
I właśnie dlatego najciekawszy kierunek dla AI w ocenie ryzyka nie polega na tym, żeby model sam „wymyślał” ocenę. Znacznie sensowniejsze jest wykorzystanie AI jako warstwy wspomagającej proces: do sprawdzania kompletności, podpowiadania brakujących scenariuszy, porównywania z typowymi zagrożeniami, wskazywania niespójności i wspierania redakcji uzasadnień.
Czyli nie: „AI, zrób za mnie ocenę ryzyka”.
Raczej: „AI, pomóż mi sprawdzić, czy jako inżynier nie pominąłem czegoś ważnego”.
To jest zupełnie inna filozofia.
Pierwsza filozofia produkuje dokument.
Druga wzmacnia proces.
A w bezpieczeństwie maszyn dokument jest tylko śladem procesu. Nie jego zamiennikiem.
Ślad decyzyjny jest ważniejszy niż ładna tabela
Każda poważna ocena ryzyka powinna dać się odtworzyć.
Nie tylko przeczytać.
Odtworzyć.
To oznacza, że po czasie powinno być jasne, dlaczego dane ryzyko zostało ocenione w określony sposób. Dlaczego uznano, że dana sytuacja zagrożenia jest istotna. Dlaczego przyjęto taką ciężkość możliwej szkody. Dlaczego uznano daną częstotliwość narażenia. Dlaczego wybrano taki środek redukcji ryzyka. Dlaczego nie zastosowano innego rozwiązania. Dlaczego ryzyko resztkowe uznano za akceptowalne.
Bez tego dokument jest trudny do obrony.
Bo sama tabela pokazuje wynik, ale nie pokazuje myślenia.
A przy maszynach to właśnie myślenie jest kluczowe. Zwłaszcza wtedy, gdy ktoś po miesiącach albo latach wraca do oceny i pyta: „dlaczego podjęliśmy taką decyzję?”. Może to być audyt. Może to być modernizacja. Może to być analiza incydentu. Może to być kontrola. Może to być spór z klientem. Może to być pytanie po wypadku.
Wtedy zdanie „AI tak wygenerowało” nie jest argumentem.
Tak samo jak nie było argumentem zdanie „tak wyszło w Excelu”.
Trzeba pokazać tok rozumowania.
Jeżeli ryzyko zredukowano przez osłonę, trzeba wiedzieć, jaką funkcję pełni ta osłona, przed jakim dostępem chroni i jakie zadanie człowieka uwzględnia. Jeżeli zastosowano funkcję bezpieczeństwa, trzeba wiedzieć, jaki scenariusz zagrożenia ma przerwać i jakie wymagania techniczne musi spełnić. Jeżeli zostawiono ryzyko resztkowe, trzeba wiedzieć, dlaczego nie dało się go dalej racjonalnie zmniejszyć przez projekt lub środki ochronne.
Jeżeli jedynym śladem jest wiersz w tabeli, to jesteśmy w dokumentacyjnej mgle.
I właśnie tutaj AI może być zarówno wzmacniaczem jakości, jak i wzmacniaczem bałaganu.
Jeżeli proces jest dobrze ułożony, AI może pomóc opisywać decyzje bardziej konsekwentnie, wykrywać braki w uzasadnieniach, pytać o powiązania między zadaniem a zagrożeniem, wskazywać niekonsekwencje między środkiem ochronnym a ryzykiem resztkowym.
Ale jeżeli procesu nie ma, AI tylko wygeneruje bardziej elegancką mgłę.
Będzie więcej tekstu.
Będzie lepszy styl.
Będą bardziej techniczne sformułowania.
Ale nadal nie będzie wiadomo, dlaczego podjęto taką decyzję.
A dobra ocena ryzyka nie polega na tym, że nikt nie zadaje pytań. Dobra ocena ryzyka polega na tym, że kiedy pytania padają, dokumentacja potrafi na nie odpowiedzieć.
Powtarzalny proces zamiast widzimisię
W ocenie ryzyka maszyn bardzo łatwo popaść w uznaniowość.
Jeden inżynier oceni ryzyko jako wysokie. Drugi jako średnie. Jeden uzna, że szkolenie wystarczy. Drugi zapyta, dlaczego nie zmieniono konstrukcji. Jeden wpisze zagrożenie ogólne. Drugi rozbije je na kilka sytuacji zagrożenia zależnych od fazy życia maszyny i zadania człowieka.
Część tej różnicy wynika z doświadczenia. Ale część wynika z braku procesu.
Jeżeli nie ma stałej struktury oceny, decyzje zaczynają zależeć od stylu osoby, która wypełnia dokument. Od jej ostrożności, przyzwyczajeń, znajomości danej branży, presji czasu i tego, jak wyglądał ostatni użyty szablon.
AI może tę uznaniowość zmniejszyć albo zwiększyć.
Zmniejszyć — jeżeli działa w ramach stałej metodyki, która wymusza te same kroki: ograniczenia maszyny, fazy życia, zadania, sytuacje zagrożenia, zdarzenia niebezpieczne, zagrożenia, szkody, szacowanie, ewaluację, redukcję, ryzyko resztkowe i uzasadnienie.
Zwiększyć — jeżeli każdy użytkownik wpisuje dowolny prompt, a model za każdym razem generuje trochę inną tabelę, trochę innym językiem, z trochę innymi założeniami.
To jest bardzo ważne.
Bo bezpieczeństwo maszyn nie lubi „trochę”.
Nie powinno zależeć od tego, czy dzisiaj prompt był lepszy, czy gorszy. Czy model miał lepszy dzień. Czy użytkownik dopisał „uwzględnij cały cykl życia maszyny”, czy zapomniał. Czy AI skupiło się na normalnej pracy, a pominęło czyszczenie. Czy wygenerowało „osłonę”, ale nie zapytało o dostęp do strefy niebezpiecznej podczas przezbrojenia.
Powtarzalność procesu jest tutaj kluczowa.
Nie po to, żeby każda ocena ryzyka była identyczna. Ma być przeciwnie — każda powinna wynikać z konkretnej maszyny. Ale sposób dochodzenia do decyzji powinien być spójny. Inaczej nie wiadomo, czy różnice między ocenami wynikają z różnic między maszynami, czy z przypadkowości sposobu wypełniania dokumentu.
To jest jeden z powodów, dla których samo AI nie wystarczy.
AI może generować.
Ale proces musi prowadzić.
Jeżeli proces jest słaby, AI wygeneruje słabą ocenę w dobrym stylu.
Jeżeli proces jest mocny, AI może stać się narzędziem przyspieszającym pracę, a nie zasłoną dymną dla braku analizy.
Przykład: czujnik widełkowy na slitterze i „genialna” odpowiedź AI
Weźmy prosty przykład z życia.
Na slitterze czujnik widełkowy wykrywa położenie taśmy. Przy zmianie szerokości materiału operator musi przestawić czujnik. Problem polega na tym, że regulacja znajduje się w strefie niebezpiecznej. Żeby przesunąć czujnik, człowiek musi wejść w obszar, w którym występują ruchome elementy, wały, rolki, punkty wciągania, naprężona taśma albo elementy układu rozcinania.
Co zrobi AI, jeśli dostanie ogólny prompt?
Prawdopodobnie napisze coś takiego:
„Zagrożenie: dostęp operatora do strefy niebezpiecznej podczas przezbrojenia. Możliwy skutek: pochwycenie, zmiażdżenie, przecięcie. Środki redukcji ryzyka: zastosować procedurę LOTO, przeszkolić operatora, oznakować strefę niebezpieczną, stosować środki ochrony indywidualnej, zapewnić instrukcję przezbrojenia, zastosować osłony i wyłącznik awaryjny.”
Brzmi dobrze?
Brzmi.
Tylko że to może być klasyczna dokumentacyjna ucieczka od problemu.
Bo właściwe pytanie nie brzmi: „jak opisać ryzyko wejścia do strefy?”. Właściwe pytanie brzmi: dlaczego operator w ogóle musi wchodzić do strefy niebezpiecznej, żeby wykonać normalne przezbrojenie maszyny?
To jest różnica między wypełnieniem tabeli a oceną ryzyka.
Jeżeli zmiana szerokości taśmy jest normalną, powtarzalną czynnością produkcyjną, to nie można traktować jej jak wyjątkowej interwencji serwisowej. Nie wystarczy wpisać „procedura LOTO” i uznać, że problem został rozwiązany. Trzeba sprawdzić, czy ta procedura ma sens w realnym cyklu pracy. Czy operator będzie ją wykonywał przy każdym przezbrojeniu? Czy maszyna musi być wtedy całkowicie zatrzymana? Czy czujnik da się ustawić bez materiału? Czy regulacja wymaga obserwacji położenia taśmy? Czy po przestawieniu czujnika trzeba wykonać test z ruchem? Czy osłona blokująca umożliwia wykonanie tej czynności, czy wymusza obchodzenie zabezpieczeń?
AI może tego nie wiedzieć.
AI zobaczy „wejście do strefy niebezpiecznej” i zaproponuje typowy pakiet: osłona, instrukcja, szkolenie, LOTO, oznakowanie. Taki zestaw wygląda bezpiecznie w tabeli. Problem w tym, że może nie odpowiadać na przyczynę ryzyka.
A przyczyną ryzyka może być źle zaprojektowana regulacja.
Może czujnik powinien być przesuwany z zewnątrz strefy niebezpiecznej — na prowadnicy dostępnej spoza osłony. Może powinien mieć mechaniczną skalę, pozycjonowanie według receptury albo szybkozłącze umożliwiające ustawienie bez wejścia w strefę. Może zamiast jednego przesuwanego czujnika trzeba zastosować inny układ detekcji, który nie wymaga ręcznej regulacji w niebezpiecznym miejscu. Może trzeba zmienić konstrukcję wspornika, lokalizację czujnika, dostęp operatora albo sekwencję przezbrojenia.
Dopiero gdy nie da się usunąć potrzeby dostępu przez zmianę projektu, można rozważać dalsze środki: osłonę blokującą, tryb nastawczy, ograniczoną prędkość, sterowanie podtrzymywane, urządzenie zezwalające, bezpieczne zatrzymanie, procedurę odcięcia energii, instrukcję i szkolenie.
Ale kolejność ma znaczenie.
ISO 12100 nie zaczyna od „przeszkolić operatora”. Najpierw pyta, czy można wyeliminować zagrożenie albo ograniczyć ryzyko przez projektowanie bezpieczne samo w sobie. W tym przykładzie oznacza to bardzo konkretne pytanie: czy regulację czujnika można zaprojektować tak, żeby człowiek nie musiał wchodzić do strefy niebezpiecznej?
I to jest moment, w którym AI bez procesu zaczyna być niebezpieczne.
Bo może dać odpowiedź poprawną językowo, ale złą inżyniersko. Może opisać ryzyko, zamiast pomóc je usunąć. Może przykleić do problemu procedurę, zamiast zapytać o zmianę konstrukcji. Może obniżyć ryzyko w tabeli po dodaniu szkolenia, mimo że operator dalej musi wykonywać tę samą czynność w tym samym niebezpiecznym miejscu.
W dokumencie będzie wyglądało to elegancko.
W rzeczywistości człowiek dalej będzie wchodził tam, gdzie nie powinien.
Dlatego dobry proces oceny ryzyka powinien wymusić inne pytania:
Czy przestawienie czujnika jest normalną czynnością operatora, czy czynnością serwisową?
Jak często występuje przezbrojenie szerokości taśmy?
Czy regulacja odbywa się przy zatrzymanej maszynie, przy podtrzymanej energii, w trybie ręcznym czy podczas próbnego ruchu?
Jakie elementy niebezpieczne znajdują się w tej strefie?
Czy operator musi obserwować taśmę podczas regulacji?
Czy istnieje możliwość nieoczekiwanego uruchomienia?
Czy dostęp do czujnika wymaga zdjęcia osłony?
Czy obecne rozwiązanie zachęca do obchodzenia zabezpieczeń?
Czy czujnik można przestawiać spoza strefy niebezpiecznej?
Czy można zastosować mechaniczne pozycjonowanie, skalę, nastawy recepturowe albo inny układ detekcji?
Czy po zmianie konstrukcyjnej nadal pozostaje ryzyko resztkowe?
Dopiero po takich pytaniach zaczyna się prawdziwa ocena ryzyka.
Nie dlatego, że tabela będzie dłuższa. Dlatego, że decyzja będzie miała sens.
I to jest dokładnie granica między AI jako generatorem dokumentacji a AI jako asystentem procesu. Generator napisze: „zastosować procedurę LOTO i przeszkolić operatora”. Asystent procesu powinien zapytać: czy ta czynność w ogóle powinna wymagać wejścia do strefy niebezpiecznej?
To jedno pytanie może być warte więcej niż dwadzieścia ładnie wypełnionych wierszy w Excelu.
AI jako wsparcie oceny ryzyka to jedno. AI w funkcji bezpieczeństwa to zupełnie inna liga.
W całej tej dyskusji trzeba bardzo wyraźnie oddzielić dwie rzeczy.
Pierwsza rzecz to wykorzystanie AI jako narzędzia wspierającego pracę inżyniera: do porządkowania informacji, zadawania pytań kontrolnych, szukania luk, redagowania uzasadnień i sprawdzania spójności dokumentacji. To jest obszar, w którym AI może realnie pomóc. Oczywiście pod warunkiem, że pracuje na dobrym kontekście i nie udaje, że samo „zna” konkretną maszynę.
Druga rzecz to wykorzystanie AI albo uczenia maszynowego w samej maszynie — zwłaszcza wtedy, gdy taki system miałby zapewniać funkcję bezpieczeństwa.
I tu kończy się zabawa w modne hasła.
Rozporządzenie maszynowe 2023/1230 mówi wprost, że producent maszyny lub produktu powiązanego ma obowiązek przeprowadzić ocenę ryzyka, aby określić zasadnicze wymagania w zakresie ochrony zdrowia i bezpieczeństwa, a następnie zaprojektować i wytworzyć maszynę tak, aby eliminować zagrożenia albo minimalizować ryzyko z uwzględnieniem wyników tej oceny. To nie jest obowiązek modelu językowego. To jest obowiązek producenta.
Rozporządzenie idzie jednak dalej. Wprost wskazuje systemy o samozmieniającym się zachowaniu zapewniającym funkcje bezpieczeństwa jako kategorię szczególną. Powód jest prosty: zależność od danych, nieprzejrzystość, autonomia i łączność mogą zwiększać prawdopodobieństwo oraz dotkliwość szkody. Dlatego ocena zgodności takich elementów bezpieczeństwa lub systemów powinna być przeprowadzana przez stronę trzecią. Nie dlatego, że ustawodawca nie lubi innowacji. Dlatego, że funkcja bezpieczeństwa nie może opierać się na wierze, że algorytm „zazwyczaj dobrze działa”.
W załączniku I część A rozporządzenie wymienia między innymi elementy bezpieczeństwa o całkowicie lub częściowo samozmieniającym się zachowaniu z wykorzystaniem uczenia maszynowego, które zapewniają funkcje bezpieczeństwa, oraz maszyny z takimi wbudowanymi systemami — w odniesieniu do tych systemów. To oznacza wejście w obszar oceny zgodności z udziałem jednostki notyfikowanej, a nie prostą deklarację: „mamy AI, więc jest nowocześnie”.
To jest bardzo ważna granica.
AI, które pomaga przygotować pytania do oceny ryzyka, to jedno.
AI, które decyduje o zachowaniu maszyny w sytuacji związanej z bezpieczeństwem, to drugie.
W pierwszym przypadku mówimy o narzędziu wspierającym człowieka. W drugim — o elemencie, którego błąd może doprowadzić do szkody. A wtedy nie wystarczy piękny opis w dokumentacji, wykres skuteczności modelu i slajd o „inteligentnej predykcji”. Trzeba wykazać zgodność, przewidywalność, odporność, właściwe ograniczenia, nadzór, dokumentację, testowanie i możliwość obrony całego rozwiązania technicznego.
AI Act wzmacnia tę logikę. System AI jest traktowany jako wysokiego ryzyka między innymi wtedy, gdy ma być używany jako element bezpieczeństwa produktu objętego unijnym prawodawstwem harmonizacyjnym z załącznika I albo sam jest takim produktem, a produkt lub system wymaga oceny zgodności przez stronę trzecią. W praktyce oznacza to, że AI powiązane z bezpieczeństwem maszyny nie jest zwykłym „feature’em” software’owym. To może być regulacyjnie system wysokiego ryzyka.
AI Act nie mówi też: „wystarczy, że model ma dobrą skuteczność”. Dla systemów wysokiego ryzyka wymaga systemu zarządzania ryzykiem jako ciągłego, iteracyjnego procesu przez cały cykl życia. Ten proces obejmuje identyfikację znanych i racjonalnie przewidywalnych ryzyk, szacowanie i ocenę ryzyk przy użyciu zgodnym z przeznaczeniem oraz w warunkach racjonalnie przewidywalnego niewłaściwego użycia, a także dobór odpowiednich środków zarządzania ryzykiem. To brzmi znajomo, bo logika jest bliska temu, czego inżynier bezpieczeństwa powinien oczekiwać również przy maszynach: nie deklaracja, tylko proces.
Do tego dochodzi nadzór człowieka. AI Act wymaga, aby systemy wysokiego ryzyka były projektowane tak, by mogły być skutecznie nadzorowane przez osoby fizyczne. Osoba nadzorująca ma rozumieć możliwości i ograniczenia systemu, monitorować jego działanie, wykrywać anomalie, prawidłowo interpretować wynik oraz w konkretnej sytuacji zdecydować, że wyniku nie użyje, zignoruje go, odwróci albo przerwie działanie systemu w bezpiecznym stanie. To jest dokładne przeciwieństwo ślepego zaufania do automatu.
I tu wracamy do sedna.
W bezpieczeństwie maszyn problemem nie jest to, że algorytm może mieć 90%, 95% albo 99% trafności. Problemem jest to, co dzieje się w tym pozostałym procencie. Co się dzieje, gdy model nie rozpozna człowieka? Co się dzieje, gdy dane wejściowe są inne niż w fazie testów? Co się dzieje, gdy środowisko pracy zmieni się przez zabrudzenie, oświetlenie, temperaturę, wibracje, nietypowy materiał, awarię czujnika albo zachowanie operatora, którego nikt nie przewidział? Co się dzieje, gdy system uczy się dalej albo zmienia swoje zachowanie po wdrożeniu?
To nie są pytania filozoficzne.
To są pytania inżynierskie.
AI Act wymaga dla systemów wysokiego ryzyka odpowiedniego poziomu dokładności, solidności i cyberbezpieczeństwa przez cały cykl życia, deklarowania poziomów dokładności i metryk w instrukcjach oraz możliwie wysokiej odporności na błędy, usterki, niespójności i interakcje z ludźmi lub innymi systemami. Wprost pojawia się też logika rozwiązań redundantnych, backupowych lub fail-safe. To pokazuje, że „statystycznie dobrze” nie wystarcza, jeśli mówimy o bezpieczeństwie.
Dlatego w ocenie ryzyka maszyn trzeba uważać na dwa rodzaje złudzeń.
Pierwsze złudzenie: AI wygenerowało dokument, więc mamy ocenę ryzyka.
Drugie złudzenie: AI dobrze działa w testach, więc może przejąć funkcję bezpieczeństwa.
Oba są niebezpieczne.
W pierwszym przypadku można stworzyć elegancką dokumentację bez realnego procesu decyzyjnego. W drugim można wejść w obszar funkcji bezpieczeństwa bez zrozumienia, że prawo i inżynieria wymagają tu zupełnie innej dyscypliny: oceny zgodności, dokumentacji technicznej, zarządzania ryzykiem, nadzoru człowieka, odporności, cyberbezpieczeństwa i możliwości wykazania, dlaczego system ma działać bezpiecznie nie tylko w prezentacji handlowej, ale także na hali produkcyjnej.
AI może być świetnym asystentem.
Ale im bliżej funkcji bezpieczeństwa, tym mniej miejsca zostaje na marketingowe „zaufajmy algorytmowi”.
W maszynach bezpieczeństwo nie polega na tym, że system brzmi inteligentnie. Polega na tym, że potrafimy wykazać, co zrobi w sytuacji przewidywalnej, co zrobi w sytuacji błędnej i jak ograniczymy skutki wtedy, gdy coś pójdzie nie tak.