Wyjątki w procesie Digital Product Passport — jak zarządzać odstępstwami bez utraty audytowalności?

Status funkcji: Controlled Exceptions, approval odstępstw, automatyczne expiry i powiązanie z Compliance Gate są projektowanym workflow DPP Compliance. Nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Poniższy model jest rekomendacją organizacyjną i architektoniczną, a nie ustawową procedurą zwolnienia z wymagań DPP.

System, który pokazuje tylko „required → complete”, pomija część rzeczywistej pracy z danymi. Dostawca czeka na odnowienie deklaracji, pole dotyczy innego materiału albo firma rozważa czasową zgodę na kontynuowanie wewnętrznego zadania. Obejście kontroli poza systemem gubi powód, zakres i osobę podejmującą decyzję.

Controlled Exception powinien zachować brak danych jako fakt, a decyzję ryzyka jako osobny, wersjonowany zapis. Waiver nie jest wynikiem walidacji ani certyfikatem zgodności.

Trzy klasy egzekwowania — nie trzy rodzaje prawa

W projektowanym modelu można rozróżnić:

To taksonomia aplikacji, nie nazwy klas z rozporządzenia. Osobno trzeba określić pochodzenie wymagania: prawo, polityka firmy czy guidance. Twardą regułą może być również warunek ustanowiony przez firmę. Obowiązku regulacyjnego nie wolno przeklasyfikować na politykę wewnętrzną po to, aby go odblokować.

Zatwierdzony wyjątek nie uchyla obowiązku prawnego. Zakres DPP zależy od właściwego produktu i reżimu, a Komisja przypisuje odpowiedzialność za jego utworzenie i dokładność operatorowi gospodarczemu. Niepewne zastosowanie przepisu wymaga wyjaśnienia, nie automatycznego waivera.

Co musi zawierać rejestr odstępstw?

Scope powinien być utrwalonym zbiorem identyfikatorów. Filtr „wszystkie produkty dostawcy X” nie może później objąć nowych SKU bez kolejnego review. Zatwierdzenie dla partii nie obejmuje automatycznie innych partii ani rynków.

Dowód kompensujący powinien wskazywać konkretną rewizję. Sama obietnica odnowienia dokumentu pozostaje informacją o następnym ruchu, nie dowodem potwierdzającym właściwość produktu. Wersjonowanie dokumentów chroni historię takich decyzji.

Pending → approved → expired to nie checkbox

Praktyczny workflow obejmuje wniosek, ocenę uprawnionej osoby i skończony okres obowiązywania. Odrzucenie, cofnięcie zgody i wycofanie wniosku wymagają oddzielnych stanów. Przedłużenie tworzy nową decyzję, nie edytuje starej po cichu.

Missing evidence
→ Request exception from eligible internal policy
→ Review scope, risk and compensating controls
→ Approved until a specific deadline
→ Follow-up / obtain evidence
→ Expired or revoked
→ Re-evaluate using normal rules

Approval nie może działać wstecz. Data dzienna bez strefy czasowej jest niejednoznaczna: „do 30 listopada” trzeba zamienić na konkretny termin ze strefą i określić granicę wygaśnięcia. Przypomnienie nie zastępuje tej kontroli.

Serwer powinien sprawdzać datę ważności przy każdej chronionej operacji. Jeśli worker nie uruchomił jeszcze zadania expired, wygasła zgoda nadal nie może działać. Podobnie cache lub opóźniony webhook nie powinien przywracać pozwolenia. To kryterium projektowania, nie opis obecnego API DPP Compliance.

WARN — approved internal exception, nie PASS

Użytkownik powinien widzieć dwa niezależne wyniki:

Dane: brak deklaracji dla wymagania X
Raw readiness: bez zmiany wyniku z powodu approval
Decyzja polityki: WARN — aktywny wyjątek wewnętrzny
Zakres: produkt ABC-123, praca nad draftem
Approver: konkretna uprawniona osoba
Review i valid until: jawne terminy
Inny hard_required gap: nadal BLOCK

Approval nie dodaje wartości źródłowej, nie zwiększa liczby kompletnych danych i nie usuwa gapu z mianownika. Jeśli istnieje inny twardy brak, wynik zbiorczy pozostaje BLOCK. Zgoda na kontynuowanie jednego zadania nie jest ogólnym pozwoleniem na publikację lub wysyłkę.

Takie rozdzielenie ma znaczenie dla przyszłego DPP Compliance Gate w ERP. System zewnętrzny musi wiedzieć, dla której operacji i do kiedy obowiązuje decyzja, zamiast dostać samo „zielone”.

Not applicable pozostaje decyzją o zakresie

Nie należy mieszać wyjątku z brakiem zastosowania wymagania. Not applicable ma wynikać z warunku w profilu i potwierdzonych faktów, z uzasadnieniem. Missing oznacza, że dane są potrzebne, ale ich brakuje. Unresolved oznacza, że zastosowanie lub źródło trzeba wyjaśnić.

Przycisk „nie dotyczy” nie może zastępować supplier follow-upu. Praktyczny przewodnik o brakujących dokumentach dostawcy pokazuje, jak oddzielić te przypadki.

Audit trail bez przepisywania historii DPP

Rejestr powinien utrwalać request, approval, odrzucenie, cofnięcie, wygaśnięcie i ponowną ocenę. Każdy zapis identyfikuje aktora, kontekst, wymaganie i wersję polityki. Zmiana polityki lub zakresu produktu wymaga oceny wpływu; wcześniejsza decyzja nie powinna automatycznie objąć nowego kontekstu.

Historyczna ocena wskazuje decyzję ważną w swoim czasie. Późniejsze expiry nie przepisuje jej ani nie zmienia bajtów opublikowanego paszportu. Jeżeli publiczne informacje wymagają korekty, należy przeprowadzić osobny proces korekty DPP.

Uzasadnienia, nazwiska approverów i poufne pliki dostawców są wewnętrzne domyślnie. Akceptacja odstępstwa nie jest zgodą na publikację tych danych przez QR. Okres przechowywania historii wynika z właściwych obowiązków i polityki retencji, a nie założenia „zachowuj wszystko zawsze”.

Co sprawdzić podczas pilotażu?

Zamiast zaczynać od rozbudowanego systemu approvals, przetestuj cztery przypadki: dopuszczalny wewnętrzny wyjątek, niedopuszczalny twardy brak, faktyczne Not applicable oraz wygaśnięcie przy opóźnionym powiadomieniu. Dla każdego musi być jasne, kto ma następny ruch i co pozostaje zablokowane.

Wdrożenie DPP może obejmować uporządkowanie wymagań, źródeł i odpowiedzialności. Ten materiał nie dodaje Controlled Exceptions do aktywnego zakresu żadnego planu ani nie stanowi opinii prawnej, certyfikatu lub automatycznego potwierdzenia zgodności produktu.