W praktyce częściej spotkamy się z pojęciem audit trail,  niż z polskim tłumaczeniem ścieżka audytu. Dlatego też będziemy stosować pojęcie audit trail, a tylko czasem jako zamiennik też polskie tłumaczenie.

Audit trail oznacza automatyczne gromadzenie danych umożliwiających identyfikację, kto, kiedy i jakie dane utworzył, zmodyfikował lub usunął, wraz z zachowaniem informacji o wartościach początkowych oraz nowych. Celem jest zapewnienie integralności, identyfikowalności i rozliczalności danych oraz umożliwienie odtworzenia przebiegu zdarzeń podczas audytu lub inspekcji. W dalszej części rozłożymy to na bardziej szczegółowe wymagania i pokażemy, w jaki sposób są one realizowane w PREMIS.

Opisany mechanizm chroni przed manipulacją danymi, fałszowaniem, nieautoryzowaną zmianą, a również pozwala na określenie odpowiedzialności za poszczególne dane i ich zmiany w systemie. Jest to jeden z kluczowych aspektów w systemach zarządzania jakością, ma więc szerokie zastosowanie. Jest to też jeden z warunków skutecznego zabezpieczenia systemu (cybersecurity). Audit trail nie dotyczy zabezpieczania danych przez atakami, ale daje podstawę do analizy zdarzeń oraz rozliczania działań. NIST SP 800-53 w sekcji 3.3 „Audit and accountability” definiuje ‘audit records’ (AU-3) będące odpowiednikiem audit trails. Audit trail ma fundamentalne znaczenie w wielu branżach i zastosowaniach. W związku z tym PREMIS od podstaw był projektowany tak, aby zapewnić skuteczne jego stosowanie.

Sam audit trail jest zdefiniowany w Aneksie 11 do GMP (Good Manufacturing Practice), podstawowej regulacji dla przemysłu farmaceutycznego, oraz w Dobrych praktykach dla zarządzania danymi i ich integralności w środowiskach regulowanych GMP/GDP. Na rynku amerykańskim główną regulacją jest w tym zakresie 21 CFR Part 11 (Electronic Records; Electronic Signatures). Stosowanie audit trail jest też związane z dobrymi praktykami zapewnienia integralności danych – ALCOA+, co będziemy dalej dokładniej omawiać. Samo audit trail bez zapewnienia integralności danych zgodnie z ALCOA+ jest mało skuteczne.

Cyber Resilience Act wprowadza nowe wymagania dla producentów produktów zawierających elementy cyfrowe. Obejmują one cyberbezpieczeństwo produktu, zarządzanie podatnościami, raportowanie incydentów, dokumentację techniczną, ocenę zgodności oraz utrzymanie bezpieczeństwa przez cały okres wsparcia produktu.

Regulacja jest wdrażana w dwóch etapach. Od 11 września 2026 roku obowiązkowe staje się powiadamianie o aktywnie wykorzystywanych podatnościach i poważnych incydentach. Pełne stosowanie rozporządzenia — obejmujące między innymi wymagania bezpieczeństwa produktu, bezpieczne aktualizacje, dokumentację techniczną, ocenę zgodności i współpracę z organami — będzie wymagane od 11 grudnia 2027 roku. Warto wdrażać kolejne obszary stopniowo, aby konsekwentnie budować i utrzymywać wysoki poziom cyberodporności produktów.

Obszary wymagań CRA wraz z zakresem obowiązującym w każdym z dwóch etapów wdrażania regulacji są pokazane w tabel poniżej. Układ ten jest odwzorowany w szablonie zgodności w PREMIS.

Zanim przejdziemy do tematu argumentacji dla systemów kosmicznych należy powiedzieć, że procesy związane z takimi systemami są bardzo mocno uporządkowane na wszystkich etapach rozwoju aż do akceptacji do lotu, następnie podczas eksploatacji systemu, która może trwać wiele lat, aż do wycofania z użycia. Stosowane są rygorystyczne zasady zarządzania wymaganiami, testowania, weryfikacji i walidacji, przeglądów. Przeglądy generują zgłoszenia RID (Review Item Discrepancy), których rozwiązanie jest śledzone. Określone są bramki kolejnych faz i określone są precyzyjnie warunki przejścia przez taką bramkę fazy. Mówimy przede wszystkim o standardach ECSS stosowanych w Europie, ale poziom rygorów standardów NASA nie jest niższy. Czy w takich sformalizowanych procesach stosowanie assurance case jest dodatkowym formalizmem, czy przynosi korzyści?

Nie będziemy raczej zalecali stosowania assurance case dla małych projektów typu CubeSat, gdzie poziom złożoności nie jest duży. Ale w większych projektach argumentacja dobrze uzupełnia sam proces rozwoju systemu. Standardy ECSS raczej mówią, co należy zrobić i jakie artefakty wytworzyć. Natomiast assurance case pokazuje, dlaczego można ufać, że system rzeczywiście spełnia wymagane cele. Nie chodzi o to, aby argumentacja była checklistą wymagań standardu, bo wtedy utracimy korzyści jej stosowania. Ma prezentować ciąg logiczny od celów poprzez argumentację i uzasadnienia, aż do dowodów, ale z zachowaniem podejścia określonego przez ECSS.

• Assurance case pomaga identyfikować luki, na przykład brakujące dowody.
• Usprawnia prowadzenie przeglądów. Dla osoby prowadzącej przegląd daje to dobre możliwości przejścia od celów do dokumentów dowodowych.
• Ułatwia określanie zakresu zmian i zarządzanie zmianami.
• Wspiera komunikację między różnymi grupami zaangażowanymi w projekt.
• Dokumentuje decyzje i ich uzasadnienie, co może być użyteczne szczególnie w wieloletnich projektach.

Strukturalne argumentacje wymuszają powiązanie w logiczny łańcuch zależności celów zgodności ze wszystkimi dowodami ich osiągnięcia. To ułatwia prowadzenie audytów. Jest to użyteczne dla utrzymania gotowości do kontroli. Narzędzia assurance case na bieżąco pokazują status gotowości dla każdego obszaru. Gdy assurance case jest zintegrowane z systemem zarządzania dokumentacją, możliwa jest sprawna weryfikacja gotowości do kontroli. Umożliwia to szybkie wykrywanie luk, a przecież chodzi właśnie o to, aby je samodzielnie wykrywać i naprawiać, aby nie były wykrywane podczas audytów zewnętrznych.

Większość czasu podczas kontroli i inspekcji pochłania szukanie, selekcja i przygotowanie danych, a nie ich analiza. Czasem analiza to tylko 20% czasu kontroli. Stosowanie assurance case to zmienia, bo dane są od początku porządkowane i jest to utrzymywane przez cały czas. Więcej czasu można przeznaczyć na analizę. Audyty są bardziej efektywne. Nawet jeżeli początkowa struktura argumentacji nie jest optymalna, to kolejne audyty dają też informacje zwrotne pomagające ją poprawić. Dobre assurance case zapewniają wysoką efektywność audytów. Strukturalne argumentacje ułatwiają prowadzenie kontroli i weryfikacji, co czasem można interpretować, że bardziej pomagają audytorom, a nie jednostkom audytowanym. Ale tu kontrolujemy naszą własną gotowość do audytów i ta cecha assurance case staje się korzyścią dla nas.

Assurance cases są uniwersalnym rozwiązaniem skutecznym na poziomie całej organizacji, mogą obejmować różne działy, systemy i technologie. W ten sposób assurance case staje się też platformą komunikacji.

Na ile problem jest poważny i czy taka weryfikacja jest potrzebna? W kwietniu FDA wydało Warning Letter odrzucając zgłoszenie rejestracji leku i wskazując na poważne błędy procesowe, w tym związane z niewłaściwym zastosowaniem AI (zajrzyj do sekcji „Inappropriate Use of Artificial Intelligence”). Podejście FDA jest bardzo restrykcyjne. Konsekwencje przedstawienia nieprawdziwych informacji w zgłaszanej dokumentacji mogą być bardzo poważne. Gdzie są przyczyny tych problemów? Czy dokumenty tworzone przez AI tylko przykrywają błędy ludzi? Niestety AI nie tylko halucynuje, ale też generuje błędy. Publikacja Microsoft Research „LLMs Corrupt Your Documents When You Delegate” wskazuje, że AI może skutecznie uszkodzić nawet 25% dokumentacji po wykonaniu 20 iteracji pracy nad nią. Z jednej strony AI przyspiesza prace, ale jednocześnie tworzy nowe zagrożenie.

Strukturalne argumentacje powstały w  celu uporządkowania informacji pod kątem ich weryfikacji oraz ułatwienia przeglądów dokumentacji złożonych systemów. Powiązane informacje, które powinny być sprawdzone razem, bo prowadzą do określonego konkretnego wniosku, są w argumentacji obok siebie. Osoba weryfikująca ma je razem podane na tacy, nie musi ich szukać. Assurance case ułatwia życie weryfikującym, nie twórcom systemu. Jeżeli AI tworzy jakąś dokumentację systemu, to możemy też delegować do AI zadanie uporządkowania informacji z tej dokumentacji w formie argumentacji. Zwykle nie będzie potrzebna żadna modyfikacja samej dokumentacji systemu, bo argumentacja jest dodaną strukturą informacji, która może po prostu odwoływać się do poszczególnych dokumentów i ich fragmentów. Tworzona argumentacja pozwala trochę spojrzeć na dokumentację okiem audytora. Samo zadanie tworzenia argumentacji może pomóc AI w lepszym zrozumieniu celów i poprawy dokumentacji. Niech AI tworzy takie argumentacje, a człowiek niech je sprawdza. Maksimum efektu przy minimum wysiłku.

Aby porozmawiać o zastosowaniu assurance case dla takiego systemu musimy zacząć od określenia zakresu wymagań formalnych.

• Taki system spełnia kryteria systemu wysokiego ryzyka w rozumieniu AI Act, który określa też wymagania na certyfikację zgodności przed dopuszczeniem do użytkowania.
• ISO 13485 to podstawowy wymóg po stronie kwalifikacji systemów medycznych. Standard określa wymagania na system zarządzania jakością, co jest też wymagane przez AI Act.
• Kolejny wymagany standard branżowy to ISO 14971 dotyczący zarządzania ryzykiem dla wyrobów medycznych. Zarządzanie ryzykiem jest też wymagane w AI Act dla systemów wysokiego ryzyka.
• Nie możemy też zapominać o rozporządzeniu MDR (EU Medical Device Regulation 2017/745) dla wyrobów medycznych.

Przeglądając AI Act znajdziemy też wymagania cyberbezpieczeństwa, gdzie nie ma wprost wymagania stosowania ISO 27001, ale w tym standardzie znajdziemy wymagane zabezpieczenia.

Bardziej szczegółowa analiza może zidentyfikować więcej standardów, ale przedstawiona grupa zapewnia dobrą bazę do prac nad systemem AI i przygotowaniem do jego certyfikacji. Mamy więc dosyć szeroki zakres procesu i dokumentacji, które podlegają ocenie dla akceptacji systemu. Punktów niezależnej oceny jest kilka, w tym ocena wiarygodności klinicznej, audyty systemu zarządzania jakością (QMS), a na koniec ocena zgodności systemu dla AI Act i MDR. 

Certyfikacja systemu nie jest końcem, a punktem przejściowym do fazy użytkowania systemu. Mamy wtedy audyty post-market, w szczególności po wystąpieniu incydentów. A co bardziej istotne dla systemów AI, dla każdej nowej wersji, jeżeli model AI jest modyfikowany, wymagana jest ponowna certyfikacja, o ile certyfikacja nie obejmuje ciągłego uczenia się. To wszystko razem tworzy potrzebę silnego zarządzania spójnością całości dokumentacji oraz kontroli zmian i wersjonowania. Assurance case może być centralnym punktem tych prac.