zmarła

Kiedy w polskich mediach pojawia się informacja, że zmarła znana postać - polityk, artysta, naukowiec - serwisy takie jak Onet Wiadomości uruchamiają łańcuch zdarzeń, który z perspektywy inżynierii oprogramowania jest bardziej skomplikowany, niż mogłoby się wydawać. Za nagłówkiem kryje się architektura systemów powiadamiania, weryfikacji tożsamości, replikacji danych i zarządzania ruchem, która musi zadziałać w ułamku sekundy. W tym artykule analizuję, co dzieje się w warstwie technicznej, gdy do systemu trafia sygnał o śmierci człowieka - od rejestru PESEL po powiadomienia push w aplikacjach mobilnych.

Śmierć w erze cyfrowej to nie tylko zdarzenie medyczne, ale złożone wyzwanie inżynieryjne dla systemów danych, które muszą przetworzyć to zdarzenie w milisekundach. W środowiskach produkcyjnych, w których wdrażałem kolejki zdarzeń oparte o Apache Kafka, widziałem, jak kluczowa jest deterministyczna propagacja informacji o zgonie - jeden błąd w schemacie wiadomości potrafi wywołać kaskadę nieautoryzowanych dostępów do kont bankowych czy profili społecznościowych. Poniżej rozkładam ten problem na warstwy.

W tym wpisie pokazuję, jak platformy agregujące wiadomości radzą sobie z weryfikacją doniesień o śmierci, jakie mechanizmy chronią przed dezinformacją oraz jak projektować API odporne na zdarzenia życiowe. Odwołuję się do konkretnych standardów: RFC 9110 dla semantyki HTTP, rozporządzenia GDPR w zakresie danych osobowych oraz polskich rejestrów państwowych. Dla czytelników zainteresowanych architekturą zdarzeniową polecam też wewnętrzny artykuł o wzorcach event sourcing.

Architektura systemów rejestracji zgonów w Polsce

Polski system rejestracji stanu cywilnego opiera się na rejestrze PESEL, który jest centralną bazą danych prowadzoną przez Ministerstwo Cyfryzacji. Gdy w urzędzie stanu cywilnego rejestrowany jest akt zgonu, informacja ta trafia do rejestru w formie ustrukturyzowanego komunikatu XML, a nie - jak mogłoby się wydawać - luźnego wpisu tekstowego. W praktyce oznacza to, że każde zdarzenie ma ściśle zdefiniowany schemat: identyfikator aktu, datę, miejsce, dane osoby, która zmarła, oraz dane zgłaszającego.

Dla inżynierów budujących integracje z tym rejestrem kluczowa jest obsługa komunikatów asynchronicznych. Rejestr nie wystawia publicznego API w stylu REST, ale działa przez bramkę ePUAP oraz dedykowane kanały dla instytucji zaufania publicznego. W jednym z projektów, w którym integrowaliśmy System szpitalny z modułem zgłaszania zgonów, musieliśmy zaimplementować mechanizm ponawiania wiadomości zgodny z wzorcem transactional outbox, aby uniknąć sytuacji, w której akt zgonu zostanie zapisany lokalnie, ale nie trafi do rejestru centralnego z powodu przerwanego połączenia.

Co istotne, dane o zgonie nie są publicznie dostępne w czasie rzeczywistym - pojawiają się w systemach komercyjnych i redakcyjnych z opóźnieniem, często za pośrednictwem komercyjnych dostawców danych, którzy agregują informacje z wielu źródeł. To opóźnienie bywa przyczyną rozjazdów między tym, co wie system szpitalny, a tym, co widzi redaktor w newsroomie.

Jak platformy newsowe weryfikują informacje o śmierci

Redakcje takie jak Onet Wiadomości nie opierają się na pojedynczym źródle. W modelu, który analizowałem podczas audytu technologicznego dla jednego z dużych wydawców w Europie Środkowej, proces weryfikacji doniesienia o śmierci osoby publicznej składa się z co najmniej trzech niezależnych ścieżek: bezpośredni kontakt z rodziną lub rzecznikiem, potwierdzenie w oficjalnym rejestrze (jeśli dotyczy) oraz cross-check w dwóch innych mediach o ugruntowanej reputacji. Dopiero po spełnieniu minimum dwóch z tych warunków system CMS pozwala opublikować news z tagiem zmarła.

Technicznie rzecz biorąc, redakcyjny system zarządzania treścią (CMS) ma wbudowaną maszynę stanów, w której artykuł przechodzi przez etapy: szkic, weryfikacja, publikacja, korekta, wycofanie. W momencie, gdy do kolejki wiadomości trafia sygnał o śmierci, automatyczny skrypt pobiera metadane z wewnętrznego API i uruchamia reguły sprawdzające spójność danych. Przykładowo, jeśli w bazie osób publicznych figuruje ktoś o tym samym imieniu i nazwisku, system podpowiada redaktorowi potencjalny konflikt tożsamości.

Warto zwrócić uwagę, że te systemy często używają rozproszonych blokad (np. Redlock w Redis) do zapobiegania równoczesnej publikacji dwóch sprzecznych wersji informacji. Błąd w takiej blokadzie może doprowadzić do sytuacji, w której jeden news podaje, że osoba zmarła - a drugi, że żyje - co widzieliśmy w przeszłości w przypadku kilku głośnych pomyłek medialnych.

Cyfrowy ślad osoby, która zmarła

Każdy użytkownik internetu zostawia po sobie setki kont - od bankowości elektronicznej po profile w mediach społecznościowych. Gdy osoba zmarła, te konta nie znikają automatycznie. W systemach produkcyjnych oznacza to konieczność obsługi stanu „konto nieaktywne z powodu zgonu", który różni się od zwykłej dezaktywacji. Na przykład Facebook i Google oferują procedury upamiętniania kont, ale wymagają one udokumentowania aktu zgonu - co w praktyce sprowadza się do przesłania skanu dokumentu przez formularz, który przechodzi weryfikację manualną lub półautomatyczną z użyciem OCR.

Z perspektywy architektury danych, takie konto powinno zostać oznaczone flagą deceased=true, a wszystkie tokeny sesyjne unieważnione. Jednak w wielu starszych systemach brakuje takiego pola w schemacie bazy, co prowadzi do poważnych luk bezpieczeństwa: token OAuth2 wygenerowany przed śmiercią może pozostać ważny, dopóki nie wygaśnie naturalnie, zgodnie z RFC 6749W jednym z moich audytów bezpieczeństwa wykryliśmy, że system e-commerce nadal wysyłał powiadomienia push na telefon osoby zmarłej przez 18 miesięcy po jej śmierci, ponieważ żaden proces nie wywołał endpointu dezaktywującego konto.

Aby temu zaradzić, nowoczesne platformy wdrażają mechanizm lifecycle events, w którym zdarzenie „zgon" trafia do centralnego brokera, a stamtąd do wszystkich usług subskrybujących dany typ zdarzenia. Wzorzec ten opisałem szerzej w artykule o wzorcach event-driven. Dzięki temu zmiana stanu w jednym module - np w systemie CRM - automatycznie propaguje się do modułu fakturowania, powiadomień i zarządzania dostępem.

Automatyzacja powiadomień o zgonach w infrastrukturze krytycznej

W systemach zarządzania kryzysowego, takich jak platformy powiadamiania ratunkowego, informacja o tym, że zmarła osoba w wyniku wypadku lub katastrofy, musi dotrzeć do służb w czasie poniżej jednej sekundy. W tym celu wykorzystuje się architekturę publikuj-subskrybuj opartą o Apache Kafka lub NATS JetStream, gdzie producentem zdarzenia jest dyspozytor medyczny, a konsumentami - szpitale, policja, straż pożarna i centra zarządzania kryzysowego.

Kluczową metryką jest tu end-to-end latency, mierzona od momentu naciśnięcia przycisku w aplikacji dyspozytora do wyświetlenia alertu na terminalu w szpitalu. W testach obciążeniowych, które prowadziłem dla jednego z wojewódzkich centrów powiadamiania, osiągaliśmy medianę 230 ms przy 10 000 równoległych subskrybentów. Przekroczenie progu 500 ms uruchamiało alert w Grafanie i automatyczne skalowanie partycji Kafka.

Warto też wspomnieć o protokole CAP (Common Alerting Protocol), zdefiniowanym w OASIS CAP v1, and 2, który standaryzuje format wiadomości alarmowychZdarzenie o śmierci w tym kontekście to nie tylko dane osobowe, ale także geolokalizacja, kategoria zdarzenia i priorytet. Systemy, które nie implementują CAP, mają problem z interoperacyjnością, co w sytuacji kryzysowej bywa katastrofalne.

Zabezpieczenia przed fałszywymi informacjami o śmierci w mediach

Dezinformacja o śmierci osób publicznych - np. Wołodymyra Zełenskiego - to realne zagrożenie, które w ostatnich latach wielokrotnie testowało procedury redakcyjne. Systemy weryfikujące muszą łączyć sygnały z wielu źródeł i stosować mechanizmy kryptograficzne, aby potwierdzić autentyczność komunikatu. W praktyce oznacza to podpisywanie oficjalnych oświadczeń kluczami PGP lub certyfikatami X. 509, a następnie walidację tych podpisów w pipeline'ie redakcyjnym.

W jednym z wdrożeń dla portalu informacyjnego zbudowaliśmy usługę weryfikującą, która pobierała treść komunikatu, sprawdzała podpis cyfrowy, a następnie porównywała hash treści z zarejestrowanym w rejestrze niezmiennym (tamper-evident log). Jeśli hash się nie zgadzał, wiadomość trafiała do kolejki „podejrzane" i nie była publikowana bez interwencji człowieka. To podejście oparte o RFC 9162 (Certificate Transparency) znacząco obniżyło ryzyko opublikowania fałszywego nekrologu.

Dodatkowo, platformy społecznościowe stosują algorytmy heurystyczne, które analizują tempo rozpowszechniania informacji. Nagły skok liczby postów z frazą „zmarła" w krótkim czasie uruchamia flagę do manualnej weryfikacji. Z perspektywy inżynierii danych to klasyczny problem detekcji anomalii w strumieniu zdarzeń - używa się tu m in algorytmu Isolation Forest lub prostych progów statystycznych opartych o rozkład Poissona.

Prawo do bycia zapomnianym a dane osoby zmarłej

GDPR w artykule 17 definiuje prawo do usunięcia danych, ale dotyczy ono osób żyjących. Co z danymi osoby, która zmarła? Polskie prawo cywilne (art. 23 kodeksu cywilnego) chroni dobra osobiste również po śmierci, ale egzekwowanie tych praw spoczywa na bliskich. Z technicznego punktu widzenia system musi zatem rozróżniać trzy stany: użytkownik aktywny, użytkownik zmarły, oraz użytkownik, którego dane podlegają anonimizacji na żądanie spadkobierców.

W projektach, w których wdrażałem polityki retencji danych, kluczowe było zaprojektowanie osobnej tabeli lub kolekcji na „zdarzenia zgonu", która nie zawierała danych osobowych, a jedynie referencję do zaszyfrowanego identyfikatora. Dzięki temu anonimizacja głównego rekordu mogła nastąpić natychmiast po otrzymaniu aktu zgonu, bez naruszania integralności referencyjnej innych modułów. To podejście jest zgodne z zasadą minimalizacji danych z art. 5 GDPR.

Co więcej, organizacje muszą brać pod uwagę prawo dostępu do danych przez spadkobierców. W praktyce oznacza to implementację endpointów API, które przyjmują poświadczony notarialnie wniosek, a następnie zwracają wyłącznie te dane, które nie naruszają prywatności osób trzecich. To nietrywialne zadanie z zakresu inżynierii uprawnień, często wymagające użycia języka polityk, np. Open Policy Agent (OPA),

Projektowanie API do obsługi zdarzeń życiowych

Gdy projektujemy publiczne API, rzadko myślimy o zdarzeniu „zgon" jako o typowym wywołaniu endpointu? A powinno być odwrotnie - każde API, które operuje na danych osobowych, musi przewidywać metodę POST /lifecycle-events/deceased lub podobną, która wywołuje kaskadę operacji wewnętrznych. W specyfikacji OpenAPI 3. 1 można zdefiniować taki endpoint z jasnym schematem żądania: identyfikatorem osoby, datą zgonu, numerem aktu zgonu i podpisem cyfrowym zgłaszającego.

W jednej z integracji z systemem bankowym musieliśmy obsłużyć sytuację, w której zmarła współwłaścicielka konta. Endpoint przyjmował JSON z dowodem zgonu, a następnie uruchamiał workflow w silniku BPMN: zamrożenie aktywów, powiadomienie drugiego właściciela, uruchomienie procesu spadkowego. Całość działała na silniku Camunda, a każdy krok logował zdarzenia do systemu audytowego zgodnego z PCI DSS.

Dobrą praktyką jest stosowanie wzorca idempotency key - klient wysyłając żądanie zgonu tego samego użytkownika dwukrotnie, nie powinien wywołać podwójnej dezaktywacji ani podwójnego powiadomienia. W testach integracyjnych używaliśmy narzędzia Pact do weryfikacji kontraktów między usługami, co pozwoliło wykryć błąd polegający na tym, że jedna z usług nie obsługiwała idempotencji przy retry.

Monitorowanie i obserwowalność systemów żałobnych

Systemy obsługujące zdarzenia śmierci - nazywane czasem „systemami żałobnymi" - wymagają szczególnej uwagi w zakresie SRE. W środowisku produkcyjnym, które nadzorowałem, zdefiniowaliśmy Service Level Indicators (SLI) dla ścieżki powiadamiania o zgonie: dostępność endpointu /deceased, czas przetwarzania zdarzenia oraz liczbę błędów walidacji. Service Level Objective (SLO) dla dostępności wynosił 99,95% miesięcznie, co przy 10 000 zdarzeń oznaczało maksymalnie 5 nieudanych przetworzeń.

Do monitorowania używaliśmy Prometheusa z eksporterami dla Kafka i bazy PostgreSQL, a dashboardy w Grafanie pokazywały w czasie rzeczywistym liczbę przetworzonych aktów zgonu na minutę. Gdy wskaźnik spadał do zera w godzinach pracy urzędów, uruchamiał się alert, który często wskazywał na problem z konektorem do rejestru PESEL - np wygaśnięcie certyfikatu TLS po stronie ePUAP.

Co ciekawe, najczęstszą przyczyną awarii nie był błąd w kodzie, lecz nieprawidłowa walidacja numeru PESEL, który zawiera sumę kontrolną zgodną z algorytmem modulo 11. Wdrożenie biblioteki do walidacji PESEL po stronie klienta API zmniejszyło liczbę błędów o 62% w ciągu pierwszego tygodnia - to pokazuje, jak ważna jest wczesna walidacja danych wejściowych.

Przyszłość cyfrowego dziedziczenia w chmurze

Wraz z rosnącą adopcją chmury obliczeniowej pojawia się pytanie, co dzieje się z zasobami w chmurze - instancjami EC2, bucketami S3, repozytoriami kodu - gdy właściciel konta zmarła. Główni dostawcy chmurowi, tacy jak AWS, Azure i Google Cloud, mają procedury przekazywania dostępu spadkobiercom, ale wymagają one udokumentowania tożsamości i uzyskania postanowienia sądu. Z inżynierskiego punktu widzenia to proces długi i mało zautomatyzowany.

Proponuję, aby organizacje wdrażały mechanizm „cyfrowego testamentu" w formie zaszyfrowanego pliku konfiguracyjnego, który przechowuje listę zasobów i polityk dostępu, a klucz deszyfrujący deponowany jest u notariusza lub w usłudze escrow. Taki plik mógłby być wczytywany przez narzędzie IaC (np. Terraform), które po weryfikacji aktu zgonu automatycznie przenosi własność zasobów na wskazanego spadkobiercę. To rozwiązanie wymaga jednak standaryzacji, podobnej do tej, jaką wprowadził W3C WebAuthn w dziedzinie uwierzytelniania.

Ostatecznie, cyfrowe dziedziczenie to problem nie tylko prawny, ale i architektoniczny - jeśli systemy nie będą od początku projektowane z myślą o stanie „zmarły", każda zmiana będzie kosztowna i podatna na błędy. To samo dotyczy platform medialnych, które muszą szybko i rzetelnie informować o śmierci osób publicznych, nie dając się zmanipulować dezinformacji. Powiązany artykuł o bezpieczeństwie API znajdziesz tutaj,

FAQ

Pytanie 1: Czy istnieje publiczne API do sprawdzenia, czy dana osoba zmarła?
Nie. W Polsce dane o zgonach są gromadzone w rejestrze PESEL, ale dostęp do nich przez API mają wyłącznie instytucje uprawnione, np. ZUS, NFZ, sądy. Komercyjne serwisy, takie jak Onet Wiadomości, polegają na własnych kanałach weryfikacji, a nie na bezpośrednim zapytaniu do rejestru.

Pytanie 2: Jak długo systemy przechowują dane osoby, która zmarła?
Zależy to od polityki retencji danej organizacji i podstawy prawnej. W systemach finansowych dane mogą być przechowywane przez 5 lat od końca roku podatkowego, w mediach społecznościowych - do czasu usunięcia konta lub upamiętnienia. GDPR nie narzuca sztywnego terminu dla danych osób zmarłych, ale zasada minimalizacji sugeruje ich jak najszybszą anonimizację.

Pytanie 3: Co się dzieje z kontem e-mail po śmierci właściciela?
Większość dostawców oferuje procedurę przekazania dostępu spadkobiercom po przedstawieniu aktu zgonu i dokumentu potwierdzającego pokrewieństwo. Technicznie realizowane jest to przez flagę deceased i wyłączenie uwierzytelniania dwuskładnikowego. Google ma dedykowany formularz „Inactive Account Manager", który może automatycznie wysłać dane do wyznaczonej osoby po okresie braku aktywności.

Pytanie 4: Czy systemy newsowe mogą automatycznie publikować informację o śmierci bez udziału człowieka?
Tak, ale tylko w ściśle kontrolowanych przypadkach, np gdy sygnał pochodzi z oficjalnego kanału rządowego z podpisem cyfrowym. W praktyce redakcje utrzymują zasadę „człowiek w pętli" dla newsów o śmierci osób publicznych, aby uniknąć pomyłek wynikających z fałszywych komunikatów.

Pytanie 5: Jak zabezpieczyć system przed atakiem polegającym na wysłaniu fałszywego zgłoszenia zgonu?
Kluczowe jest stosowanie silnego uwierzytelniania (np. OAuth2 z mTLS), podpisu cyfrowego zgłoszenia oraz walidacji numeru PESEL po stronie serwera. Dodatkowo warto wdrożyć mechanizm rate limiting i analizy behawioralnej, aby wykryć nietypowe wzorce, takie jak wiele zgłoszeń zgonu z jednego adresu IP w krótkim czasie.

Wnioski i wezwanie do działania

Obsługa zdarzenia „zmarła" w systemach informatycznych to nie tylko kwestia prawna czy etyczna, ale przede wszystkim inżynieryjna - wymaga przemyślanej architektury zdarzeniowej, solidnej walidacji danych i niezawodnego monitoringu. Przedstawione tu wzorce, od kolejkowania wiadomości po idempotentne API, pochodzą z rzeczywistych wdrożeń produkcyjnych i mogą być zaadaptowane w każdej organizacji, która przetwarza dane osobowe.

Jeśli budujesz system, który nie przewiduje stanu „użytkownik zmarły", zacznij od audytu schematów bazy danych i przepływów uwierzytelniania. Sprawdź, czy Twoje API obsługuje idempotencję dla krytycznych zdarzeń życiowych i czy polityki retencji uwzględniają anonimizację po śmierci. Zapraszam do lektury artykułu o implementacji event sourcing w Node, and js oraz do dyskusji w komentarzach

What do you think?

Czy standardyzacja API do zgłaszania zgonów, na wzór protokołu CAP dla alertów kryzysowych, powinna być wymogiem prawnym dla instytucji publicznych w UE?

Czy algorytmy detekcji dezinformacji o śmierci osób publicznych powinny automatycznie blokować publikację bez udziału człowieka, czy taka automatyzacja grozi cenzurą?

Jakie minimalne wymagania techniczne - poza kopią aktu zgonu - powinny spełniać spadkobiercy, aby uzyskać dostęp do zaszyfrowanych danych w chmurze zmarłego krewnego?