Traceability EUDR jest najpierw problemem data lineage, a dopiero później raportowania
Dobry system EUDR nie zaczyna się od generatora PDF ani AI compliance assistant. Zaczyna się od canonical graphu, który potrafi odpowiedzieć: kto dostarczył materiał, jaki produkt i partia go zawierają, jakie evidence pochodzenia są przypisane, jaki rekord działki lub geolokalizacji obowiązuje tam, gdzie jest wymagany, jakie dokumenty były aktualne w chwili decyzji, jaka decyzja risk została podjęta oraz jakie due-diligence submission lub reference jest powiązane z transakcją.
Według stanu na sierpień 2026 EUDR ma być stosowane od 30 grudnia 2026 r. wobec dużych i średnich operatorów oraz mikro/małych operatorów objętych wcześniej EUTR, a od 30 czerwca 2027 r. wobec większości pozostałych mikro i małych operatorów. Komisja zaktualizowała w lipcu 2026 Information System i guidance. Architektura poniżej jest więc przeznaczona na okres realnego przygotowania danych i integracji, przy czym odpowiedzialność prawną trzeba każdorazowo zweryfikować dla konkretnego podmiotu, roli, produktu i supply chain.
1. Oddziel podmioty i role biznesowe od kont użytkowników
Dostawca, producent, importer, operator, trader czy downstream organization są podmiotami biznesowymi. Login jest tylko osobą działającą w imieniu jednego z nich. Identity firmy, rola regulacyjna, obiekty, kontakty i permissions powinny być osobnymi rekordami. Zmiana użytkownika nie może przepisywać historycznej odpowiedzialności.
2. Traktuj plot i origin evidence jako wersjonowane rekordy
Jeżeli potrzebna jest geolokalizacja lub evidence obszaru produkcji, nie zapisuj jej jako pola tekstowego u dostawcy. Utwórz wersjonowany origin record połączony z właściwym commodity, production unit i źródłem evidence. Zachowaj geometrię lub współrzędne, provenance, moment otrzymania, sposób walidacji i informację, która partia lub shipment użyła tej wersji.
Najważniejsza jest oś czasu: późniejsza korekta nie powinna po cichu zmieniać evidence, na podstawie którego podjęto wcześniejszą decyzję. Nowe dane tworzą nową wersję.
3. Modeluj product i batch lineage jako jawne relacje
| Obiekt | Na co odpowiada | Dlaczego ważny |
|---|---|---|
| Product / SKU | Jaki produkt handlowy obsługujemy? | Stabilne identity w procurement i sales |
| Batch / lot | Jaka ilość fizyczna lub logiczna się przemieszcza? | Zakres evidence i downstream allocation |
| Source allocation | Które origin records składają się na batch? | Many-to-many lineage |
| Transformation | Jakie inputy utworzyły output? | Traceability przez processing |
| Shipment / transaction | Jaka ilość przekroczyła granicę handlową? | Łączy evidence z aktywnością rynkową |
Technicznie można użyć modelu relacyjnego albo graph-like. Celem jest możliwość przejścia od produktu downstream do źródłowego evidence bez polegania na nazwach plików i pamięci człowieka.
4. Oddziel kompletność evidence od decyzji compliance
„Wszystkie pliki dodane” nie oznacza „zatwierdzone”. Workflow może wyglądać: draft → evidence incomplete → evidence complete → risk review → mitigation required → approved / rejected → superseded. Każda zmiana zapisuje aktora, timestamp, reason i kontekst reguł lub review.
AI powinno być bounded. Model może klasyfikować dokumenty, proponować ekstrakcję pól, wskazywać braki i podsumowywać sprzeczności. Nie powinien po cichu zamieniać niepewnej ekstrakcji w authoritative supplier data ani wykonywać finalnej oceny prawnej bez deterministycznych i human controls.
5. Integrację z EUDR Information System schowaj za adapterem
Nie rozlewaj pól zewnętrznego submission po całej domenie. Wewnętrzny due-diligence case powinien mieć własne identifiers, a dedykowany adapter mapuje go do aktualnego payloadu Information System. Zachowuj submission attempts, external references, response status oraz wersję lub hash payloadu.
Dzięki temu produkt odróżnia ready to submit / submitted / accepted / rejected / needs operator action i jest odporniejszy na zmianę API lub kanału.
6. Waliduj warstwami
- Schema: typy, identifiers, geometria i pola dokumentów.
- Domain: spójność product, commodity, supplier i batch.
- Evidence: wymagane dokumenty i origin records dla zakresu.
- Workflow: review i mitigation zostały zakończone.
- Submission: payload pasuje do aktualnego kontraktu integracji.
Błąd powinien wskazywać konkretną encję i brakujące lub sprzeczne evidence, a nie zwracać ogólne „compliance failed”.
7. Historia musi pozwalać odtworzyć decyzję
Do audytowalności nie jest potrzebny blockchain. Potrzebne są append-oriented events, stabilne identifiers, wersjonowane evidence, permissions i wyraźne rozróżnienie correction od deletion. Dla consequential changes warto zachować before/after lub event payload, aktora, timestamp i reason.
8. Eksporter, buyer i auditor powinni oglądać projekcje tego samego stanu
Eksporter potrzebuje supplier onboarding i missing-evidence queues. Buyer potrzebuje scoped evidence pack. Auditor — decision trail. To powinny być różne projekcje jednego canonical modelu, a nie trzy kopie danych.
Ten wzorzec wykorzystujemy w Supply Passport OS, gdzie supplier i product evidence stają się operational state, a dopiero potem workflow i shareable outputs. Zakres wdrożenia opisuje Compliance & Traceability Software Development.
Checklist architektury
- Stabilne identity party, product, batch i origin.
- Wersjonowane geolocation/origin evidence z provenance.
- Jawny batch lineage i transformations.
- Oddzielona kompletność evidence i decyzja compliance.
- Bounded AI extraction.
- Adapter do EUDR Information System.
- Repairable validation na poziomie encji.
- Append-oriented decision history.