Kilka dni temu byłem na szkoleniu z unijnych wymagań CRA 2024/2847 (ang. Cyber Resilience Act), tj. rozporządzenia w sprawie horyzontalnych wymagań w zakresie cyberbezpieczeństwa w odniesieniu do produktów z elementami cyfrowymi. Samo wydarzenie było zorganizowane w ramach gościnności Uniwersytetu Gdańskiego Wydziału Informatyki, chociaż było prowadzone przez zewnętrzną fundację CODE:ME. Szkolenie świetnie zorganizowane, miła atmosfera, ponad 60 słuchaczy – oby więcej takich wydarzeń.
Pojawiłem się na tym szkoleniu z myślą o skalibrowaniu swojej wiedzy na temat kolejnego wymagającego unijnego aktu, który zacznie obowiązywać w na jesień 2027 r. Podczas szkolenia dało się zauważyć, że prelegent jako informatyk ma bardzo dużą praktykę w branży automotive. Jednak jego wiedza na temat unijnych aktów prawnych, New Legal Framework (NLF) oraz produktowych wymagań nowego i globalnego podejścia jest niewielka. Powodowało to kłopoty z przedstawienie aktu prawnego jako zestawu wymagań. Kłopoty z określeniem, które produkty i w jakich sytuacjach wymagają wdrożenia wymagań CRA. Oraz trudności z wytłumaczeniem modułów oceny zgodności i całej dokumentacyjnej kwestii. Natomiast prelegent wykazał się doskonałą wiedzą na temat praktyki jak zabezpieczyć software przed podatnościami i świetnie o tym opowiadał.
Z sali płynęły liczne pytania i dało się zauważyć, że wśród słuchaczy są nie tylko producenci maszyn, a głównie automatycy i inżynierowie związani z osprzętem oraz wyposażeniem elektronicznym. Dlatego pytania najczęściej dotyczyły wyrobów, które jednocześnie znajdował się w zakresie LVD 2014/35/UE, EMC 2014/30/UE, RoHS 2011/65/UE oraz dyrektywie MD 2006/42/EC, którą w styczniu 2027 r. zastąpi rozporządzenie MR 2023/1230. Co prawda szkolenie było dedykowane wyłącznie przepisom CRA. Jednak podczas dyskusji okazało się, że brak zrozumienia unijnych aktów prawnych oraz przede wszystkim odniesienia do różnych grup produktów na które CRA jest nałożone, powoduje trudności w zrozumieniu samego ducha tych przepisów oraz tego, jak je implementować, jak wykazać zgodność przez odpowiednią dokumentację techniczną.
I jak to bywa w przypadku wdrożeń nowych unijnych wymagań, przewodnik jest już przygotowany, ale za to norm zharmonizowanych jeszcze nie ma. Przetartych ścieżek działania jeszcze nie ma, w rozporządzeniu przywołane są jednostki notyfikowane, natomiast te jeszcze nie zostały powołane itd. …ot zwykła codzienność w Product Compliance, którą już wielokrotnie widziałem w swojej karierze.
To szkolenie i dyskusja, która się wywiązała, szybko dały mi do zrozumienia, że wymaganie CRA bardzo łatwo trafią „w ręce informatyków”, którzy traktują rozporządzenie 2024/2847 jako wyizolowane wymaganie, nie zastanawiając się nad konsekwencjami połączeń z pozostałymi aktami dotyczącymi produktów. Pakiet NLF określił nam zakres obowiązku dla poszczególnych grup podmiotów, opisał moduły oceny zgodności i narzucił definicja. A to wyznaczyło kierunek traktowania wszystkich produktów podlegających unijnym wymaganiom nowego podejścia, a w tym tych które są w zakresie CRA.
We współczesnym Świecie, mamy bardzo złożone i skomplikowane produkty, które podlegają coraz większej liczbie aktów prawnych i norm technicznych, a razem tworzy to bardzo złożoną, oraz trudną do zrozumienia i interpretacji warstwę wymagań. Dlatego nie da się, aby ocena zgodności była prowadzona przez jednego specjalistę, jedną branżę, z jednej strony interpretowana. Współczesne skomplikowane produkty i stawiane przed nimi wymagania powodują konieczność wykazania zgodności przez grupę specjalistów, na którą coraz częściej trzeba nie tylko nie tylko inżyniera od oceny zgodności, nie tylko inżyniera mechanika i elektryka, ale także automatyka, informatyka i oczywiście chemika.
Niestety coraz częściej obserwuję, że małe, średnie, ale także duże firmy nie rozumiejąc złożoności nadchodzących przepisów zrzucają zadania implementacji kolejnych wymagań na jednego człowieka i oczekują wykonania całej oceny zgodności bez uwzględnienia wymaganych na to środków i czasu na wykonanie zadań. W swojej karierze wielokrotnie widziałem sytuację, gdzie oczekiwano wykonania oceny z godności dla drona w ciągu jednego miesiąca za kilka tysięcy złotych. Czy dla maszyny, która już dawno stoi na linii produkcyjnej i jest zespolona z innymi maszynami. …albo dla produktów płynących na statku w kontenerze.
Ocena zgodności powoduje wyzwania nie tylko na najniższym poziomie, gdzie jest wykonana praca, ale bardzo często wyzwania polegające na wytłumaczeniu i dotarciu do zarządów firm, które powinny zrozumieć przed jakim wyzwaniem stają ich pracownicy. Dlatego od początku rola Product Compliance Engineera czy Product Compliance Specialist wiązała się z pokazywaniem i tłumaczeniem wymagań oraz koordynowaniem prac. A teraz widzę, że Compliance Engineer zbliża się swoją rolą do Scrum Mastera.
Autor: Piotr R. Gajos
Product Compliance Engineer
