AI Act dla systemów ochrony fizycznej — co musisz wiedzieć

Załącznik III AI Act wymienia osiem obszarów systemów wysokiego ryzyka. Najsilniejsza interpretacja wskazuje, że Perimetro Platform jest poza Załącznikiem III. Najbardziej dyskusyjny jest punkt 2 (infrastruktura krytyczna), ale jego literalna wykładnia dotyczy AI używanego w świadczeniu usługi krytycznej (AI sterujące rozdziałem energii, AI w SCADA, AI sterujące ruchem drogowym), nie AI w ochronie perymetru obiektu świadczącego usługę krytyczną.

Analogiczna analiza dotyczy systemów CCTV — które nie są klasyfikowane jako systemy wysokiego ryzyka, mimo że służą ochronie infrastruktury krytycznej. Pozostałe siedem punktów Załącznika III (biometria, edukacja, zatrudnienie, dostęp do usług, organy ścigania, migracja, wymiar sprawiedliwości) jednoznacznie nie obejmuje Perimetro. Klasyfikator detekcji ma trzy generyczne klasy (osoba, pojazd, naruszenie strefy, drony* w planie rozwoju modelu) bez podtypów ani identyfikacji indywidualnej.

Konserwatywna interpretacja mogłaby objąć Perimetro pod art. 6(2) jeśli klient deployer używałby systemu jako safety component swojej infrastruktury — w takim wypadku Perimetro byłoby systemem AI wysokiego ryzyka po stronie tego konkretnego deploymentu. Ostateczna decyzja należy do organu nadzorczego oraz oceny prawnej klienta deployera w jego kontekście operacyjnym. Perimetro dostarcza dokumentację dla obu ścieżek.

Częstym nieporozumieniem jest założenie, że „certyfikacja jako wysokiego ryzyka” jest mocniejszą pozycją niż „poza wysokim ryzykiem”. W praktyce z perspektywy procesu zakupowego i zgodności jest odwrotnie. Klient (podmiot wdrażający) poza kategorią wysokiego ryzyka oszczędza cztery kategorie obowiązków formalnych wynikających z art. 8-17 oraz art. 71 AI Act.

Po pierwsze, ocena zgodności przez notyfikowany organ (art. 43) — koszt 50-150 tys. EUR jednorazowo oraz odnowienia po istotnych zmianach systemu. Po drugie, oznakowanie CE i deklaracja zgodności (art. 47-48) — proces formalny 3-6 miesięcy. Po trzecie, rejestracja w unijnej bazie danych systemów AI wysokiego ryzyka (art. 71) — publiczne raportowanie oraz obowiązek aktualizacji. Po czwarte, formalne monitorowanie po wprowadzeniu na rynek (art. 72) — zgłaszanie incydentów do EU AI Office.

Jednocześnie Perimetro implementuje pełen zestaw kontroli z art. 9-15 — czyli klient otrzymuje system zaprojektowany jak wysokiego ryzyka, bez obowiązków wysokiego ryzyka po swojej stronie. Dla porównania, alternatywne rozwiązania na rynku oparte na architekturze cloud-first z transferem surowego strumienia wideo typowo wymagają od klienta (podmiotu wdrażającego) oceny zgodności dla każdej istotnej zmiany, pełnego monitorowania po wprowadzeniu na rynek i własnej infrastruktury logowania inferencji.

Stanowisko Perimetro: klient otrzymuje narzędzie audytowalne, dokumentowane, z udokumentowanym ryzykiem — niezależnie od kwalifikacji formalnej. Zakwalifikowanie poza Annex III oznacza, że klient oszczędza 6-12 miesięcy procesu zakupowego i 50-150 tys. EUR kosztu formalnej oceny zgodności, jednocześnie otrzymując architekturę przekraczającą minimum wymagań dla systemów wysokiego ryzyka.

Art. 5 AI Act wymienia osiem niedozwolonych praktyk. Perimetro spełnia ten artykuł przez ograniczenia architektoniczne, nie przez polityki organizacyjne. Identyfikacja biometryczna indywidualna (art. 5 ust. 1 lit. h): klasyfikator detekcji ma trzy klasy generyczne bez podtypów ani identyfikacji. Schemat ładunku zdarzenia nie zawiera pól pozwalających na identyfikację indywidualną.

Kategoryzacja biometryczna (lit. g): klasyfikator nie analizuje cech demograficznych — brak takich cech w architekturze modelu, brak takich kategorii w schemacie zdarzenia. Rozpoznawanie emocji (lit. f): brak funkcjonalności rozpoznawania emocji, brak takich klas w taksonomii detekcji, model ML nie ma głów detekcyjnych dla afektu, gestów ani postawy.

Ocenianie społeczne (social scoring, lit. c): system nie ocenia ludzi, ocenia zdarzenia (naruszenia strefy). Rejestr zdarzeń nie zawiera zagregowanych ocen dla pojedynczych osób ani historii indywidualnych zachowań. Predykcyjne działania policji (predictive policing) dla indywidualnych przestępstw (lit. d): system nie ocenia osób, eskalacja jest oparta na zdarzeniach, nie na osobach. Nieukierunkowane pozyskiwanie wizerunków twarzy (lit. e): system nie buduje baz wizerunków, klatki kluczowe są przechowywane dla każdego zdarzenia z konfigurowalną retencją i opcjonalnym rozmyciem twarzy włączonym domyślnie.

Wszystkie powyższe zakazy są egzekwowane strukturalnie w schemacie Protocol Buffers definiującym format komunikacji edge ↔ cloud. Brak pól typu face_descriptor, emotion_score, demographic_attribute, behavioral_score jest bramką w CI/CD — automatyczne testy weryfikują, że nowy build nie wprowadził pól zakazanych. Zmiana (pull request) modyfikująca schemat zdarzenia jest obowiązkowo recenzowana przez compliance officera oraz CTO przed scaleniem.

Art. 9 AI Act wymaga ciągłego, iteracyjnego procesu zarządzania ryzykiem obejmującego identyfikację ryzyk znanych i przewidywalnych, estymację ryzyk wynikających z zamierzonego użycia, ocenę ryzyk z możliwego niewłaściwego użycia, środki zarządzania dla zidentyfikowanych ryzyk oraz eliminację lub redukcję ryzyk przez projektowanie.

Rejestr ryzyk Perimetro jest objęty kontrolą wersji i obejmuje sześć kategorii ryzyk. Operacyjne: false positive klasyfikacji powodujący niepotrzebną eskalację, false negative powodujący przeoczenie intruza, awaria łączności podczas misji — środki: próg ufności konfigurowalny dla każdej klasy, kolejka wychodząca na czas pracy bez łączności (offline), autonomiczny powrót do bazy (RTH) przy utracie łączności.

Zgodność: nieuprawniony dostęp do danych klienta, utrata śladu audytowego, naruszenie lokalizacji danych — środki: szyfrowanie odrębne dla każdego najemcy z destrukcją klucza (kryptograficzne usunięcie), łańcuch skrótów HMAC dla rejestru zdarzeń, infrastruktura wyłącznie w UE. Bezpieczeństwo modelu: przykłady kontradyktoryjne (adversarial), dryf modelu przez sezonowe zmiany oświetlenia — środki: testy kontradyktoryjne (adversarial) w CI, ewaluacja modelu przy każdym wydaniu na zbiorze testowym z przypadkami brzegowymi (edge cases), wykrywanie dryfu w produkcji.

Rejestr ryzyk jest aktualizowany przy każdym wydaniu modelu ML (przegląd ryzyka przed wdrożeniem jako bramka w CI/CD), kwartalnie (systematyczny przegląd przez compliance officera, ML leada oraz CTO), doraźnie przy incydentach produkcyjnych, oraz po istotnej zmianie regulacyjnej. Każda aktualizacja jest oznaczona timestampem, autorem i powodem zmiany. Historia jest dostępna audytorowi pod NDA jako część dokumentacji zgodnej z art. 11 AI Act (Załącznik IV).

Art. 14 AI Act wymaga, aby systemy AI wysokiego ryzyka były projektowane tak, aby umożliwić efektywny nadzór człowieka. Perimetro implementuje model HITL (Human-in-the-Loop) jako ograniczenie architektoniczne, nie jako konfigurowalną opcję. Zdarzenia HIGH (intruz w strefie zabronionej, anomalia termiczna wysokiej pewności) wymagają wyraźnego potwierdzenia operatora z jednego z czterech wyborów akcji: eskalacja, weryfikacja, błąd klasyfikacji, normalna obsługa.

System nie wykonuje żadnej autonomicznej reakcji kinetycznej. Drone Aero może zmienić trasę patrolu, ale nie może aktywnie ścigać intruza ani podejmować akcji innych niż obserwacja i raportowanie. Tower i Connect generują wyłącznie alerty — fizyczna reakcja (zablokowanie bramy, uruchomienie nagrywania, wysłanie patrolu) wymaga decyzji operatora lub jest realizowana przez integracje z systemami klienta (Genetec, Milestone, kontrola dostępu).

Interfejs panelu operatora jest projektowany zgodnie z dobrymi praktykami dostępności (WCAG AA). Alerty HIGH są blokujące (modalne) — operator nie może przejść do innego zadania bez podjęcia decyzji. Automatyczna eskalacja do przełożonego następuje po 60 sekundach (limit czasu (timeout) konfigurowalny dla każdego klienta) bez decyzji operatora — z zapisem w rejestrze zdarzeń, że przełożony został powiadomiony z powodu upłynięcia limitu czasu, nie aktywnej eskalacji operatora.

Brak autonomicznej reakcji kinetycznej jest egzekwowany strukturalnie. Maszyna stanów zdarzenia nie ma przejścia typu „auto-respond” — każde zdarzenie HIGH wymaga przejścia przez decyzję operatora lub przełożonego. Zmiana (pull request) wprowadzająca takie przejście byłaby blokowana w przeglądzie kodu przez compliance officera.

Art. 15 AI Act wymaga, aby systemy AI wysokiego ryzyka osiągały odpowiedni poziom dokładności, robustności i cyberbezpieczeństwa przez cały cykl życia. Dokładność klasyfikatora Perimetro jest mierzona na zbiorze testowym reprezentatywnym dla warunków polskich i CEE (różne pory dnia, warunki pogodowe, sezony) z metrykami precision, recall, F1 dla każdej klasy.

Odporność obejmuje testy kontradyktoryjne (adversarial — obraz spreparowany aby uniknąć detekcji lub generować false positive), ewaluację modelu przy każdym wydaniu na przypadkach brzegowych (przesłaniani intruzi, częściowa termalizacja, ekstremalna pogoda), oraz wykrywanie dryfu w produkcji (automatyczne wykrycie, gdy skuteczność dla danej klasy spada poniżej progu). Konkretne metryki są dostępne w Dataset Cards i Model Cards w VRA Pack klienta.

Cyberbezpieczeństwo: TLS 1.3 z podpisem HMAC-SHA256 per-urządzenie dla komunikacji edge ↔ cloud (z ochroną przed replay), per-tenant encryption keys z opcjonalnym Customer-Managed Keys, HMAC hash chain dla rejestru zdarzeń (tamper-evident — modyfikacja log entry jest wykrywalna kryptograficznie), regularne testy penetracyjne przez zewnętrzną firmę (coroczne + doraźne po istotnej zmianie systemu).

Wykrywanie dryfu jest automatyczne. System monitoruje skuteczność dla każdej klasy w produkcji (precision na zdarzeniach potwierdzonych przez operatora) i generuje alert do zespołu ML przy spadku poniżej progu konfigurowalnego dla każdego klienta (domyślnie 5% spadek przez 7 dni). Wyzwalacz uruchamia cykl ponownego treningu lub wycofanie (roll-back) do poprzedniej wersji modelu, decyzja w gestii ML leada z przeglądem compliance officera.

Operator infrastruktury krytycznej obejmie zazwyczaj jednocześnie NIS2, AI Act, RODO i często CER. Te reżimy mają nakładające się wymagania — rejestrowanie zdarzeń (NIS2 art. 21 oraz AI Act art. 12), zarządzanie ryzykiem (NIS2 art. 21 oraz AI Act art. 9), zgłaszanie incydentów (NIS2 art. 23 oraz AI Act art. 73 dla systemów wysokiego ryzyka), łańcuch dostaw (NIS2 art. 21(2)(d) oraz AI Act art. 25 dla dostawców).

Perimetro Platform jest zaprojektowana z myślą o wszystkich tych reżimach jednocześnie. Rejestr zdarzeń jest odporny na manipulację (łańcuch skrótów HMAC) — spełnia jednocześnie wymóg audytu NIS2 i rejestrowania z AI Act art. 12. Rejestr ryzyk obejmuje zarówno ryzyka operacyjne (ujęcie NIS2) jak i ryzyka modelu ML (ujęcie AI Act). NIS2 Reporter generuje raporty 24h/72h w formacie wymaganym przez krajowy CSIRT, niezależnie od ścieżki regulacyjnej zastosowanej do komponentu AI systemu.

Klient (podmiot wdrażający) otrzymuje jedną platformę integracyjną dla obu reżimów. Compliance officer nie musi mapować osobno na NIS2 i osobno na AI Act — Perimetro dostarcza mapowanie w VRA Pack (Vendor Risk Assessment Pack) jako wypełniony szablon z perspektywy klienta. Wypełniony szablon DPIA, analiza łańcucha dostaw, przykładowy rejestr ryzyk, specyfikacja rejestru zdarzeń — wszystko gotowe do przeglądu przez kancelarię klienta zamiast pisania od zera.

Pełna analiza i mapowanie wszystkich artykułów AI Act (art. 5 i 9-15) oraz model zagrożeń AI, FRIA, monitorowanie po wprowadzeniu na rynek, AI Regulatory Sandbox i studium przypadku oceny AI Act są dostępne w whitepaperze „Perimetro AI Act Conformity Reference Architecture v2.0” (49 stron, publicznie dostępny pod NDA dla klienta enterprise z zamiarem zakupowym).