Cyfrowa Polska w pigułce: e-Zamówienia nie trzymają sesji, ale strategia do 2035 roku ma się znakomicie

Od 26 października rządowa platforma eZamówienia ma poważne problemy z działaniem. Użytkownicy zmagają się z niestabilnymi sesjami, błędami i przeciągającym się ładowaniem informacji. Administratorzy nie podają terminu rozwiązania problemu, a zamawiający muszą samodzielnie oceniać wpływ awarii na prowadzone postępowania. Tymczasem Ministerstwo Cyfryzacji, oficjalny partner projektu wartego ponad 34 miliony złotych, przedstawia ambitną wizję państwa cyfrowego do 2035 roku. Wygląda na to, że przyszłość jest znakomicie zaplanowana. Teraźniejszość ma natomiast problem z zalogowaniem.

Cyfrowe państwo przyszłości nie potrafi utrzymać sesji w teraźniejszości

Kiedy minister cyfryzacji Krzysztof Gawkowski przedstawia swoją, jakże ambitną wizję cyfrowej Polski, trudno nie odnieść wrażenia, że przyszłość naszego państwa zaprojektowano z niezwykłym rozmachem. Strategia Cyfryzacji Państwa do 2035 roku przewiduje między innymi, że do 2030 roku wszystkie kluczowe usługi publiczne będą dostępne w pełni online.

Obywatele nie będą musieli odwiedzać urzędów, administracja przestanie wielokrotnie pytać o te same dane, a państwo zacznie wreszcie funkcjonować jak nowoczesny, sprawnie zarządzany organizm. Brzmi świetnie, niemal jak bajka, a do kompletu brakuje tylko informacji o odchudzeniu kadry i oszczędnościach z tego procesu wynikających.

Tymczasem 29 października 2026 roku administratorzy rządowej platformy opublikowali komunikat potwierdzający, że od 26 października system ma poważne problemy z funkcjonowaniem, a dotyczą one przede wszystkim utrzymywania sesji użytkowników, logowania, wylogowywania oraz pobierania informacji.

Niektóre dane ładują się bardzo długo. Inne kończą się błędami. Co ważniejsze, administratorzy nie potrafią określić, kiedy platforma odzyska pełną funkcjonalność. Jak zauważyła Zaufana Trzecia Strona, problemy utrzymują się od kilku dni, a ich jednoznaczna przyczyna nie została publicznie przedstawiona.

To wyjątkowo interesujące zderzenie dwóch światów. W jednym mamy prezentacje o transformacji cyfrowej, sztucznej inteligencji, nowoczesnej administracji i roku 2035. W drugim przedsiębiorca próbuje przesłać ofertę w postępowaniu o zamówienie publiczne. System właśnie postanowił zakończyć z nim znajomość - bez pożegnania.

Najpierw przerwa techniczna. Potem cookies. Następnie awaria bez terminu zakończenia

Chronologia wydarzeń jest szczególnie interesująca z punktu widzenia zarządzania zmianami w systemach teleinformatycznych. 20 października przeprowadzono prace serwisowe, podczas których platforma była faktycznie niedostępna od godziny 21:09 do 21:19. Następnie od 23 do 25 października zaplanowano znacznie większe okno serwisowe. Według oficjalnego komunikatu system miał być niedostępny od 23 października, godz. 19:00, do 25 października, godz. 20:00.

Rzeczywista niedostępność trwała od 23 października, godz. 19:05, do 25 października, godz. 19:35. Czyli przez niemal cały zaplanowany okres. W komunikacie datowanym na 24 października administratorzy zalecili użytkownikom wyczyszczenie plików cookies i pamięci podręcznej przeglądarki. Zalecenie było bezpośrednio związane ze zmianami wdrożonymi podczas prac serwisowych prowadzonych od 23 do 25 października.

Pozostawienie wcześniejszych danych przeglądarki mogło, według administratorów, prowadzić do problemów z wyświetlaniem stron, publikowaniem ogłoszeń i składaniem ofert. W większości przeglądarek odpowiednią operację można uruchomić skrótem Ctrl+Shift+Delete - to normalny element diagnostyki aplikacji internetowych.

Jednak konieczność zalecania użytkownikom takiej operacji po wdrożeniu zmian w systemie produkcyjnym powinna skłaniać do pytań o zarządzanie pamięcią podręczną, kompatybilność aktualizacji, obsługę sesji i testy regresyjne, ale to jeszcze nie koniec bo 26 października administratorzy zapowiedzieli krótką niedostępność platformy między godziną 11:10 a 11:20. Tego samego dnia ogłoszono kolejne prace serwisowe, tym razem w godzinach 18:00–22:00.

Równocześnie pojawiły się komunikaty o problemach technicznych dotyczących 26 i 27 października. 28 października opublikowano następny komunikat informujący o zakłóceniach dostępu do systemu. 29 października administratorzy potwierdzili utrzymującą się awarię, której terminu usunięcia nie byli w stanie określić.

Chronologia zdarzeń

Nie oznacza to, że wdrożenie z 23 - 25 października spowodowało późniejszą awarię bo takiego związku przyczynowego nie potwierdzono, ale zbieżność czasowa jest wystarczającym powodem, żeby zapytać o historię zmian, testy regresyjne, procedury wdrożeniowe i możliwość wycofania aktualizacji.

W terminologii IT mówimy o Change Management, Change Failure Rate oraz rollback. Jeżeli po rozbudowanym oknie serwisowym system zaczyna wykazywać problemy z utrzymywaniem sesji, jednym z pierwszych obszarów analizy powinno być porównanie środowiska przed wdrożeniem i po nim, a nie rozważanie, czy użytkownik przypadkiem nie ma zbyt wielu zakładek w przeglądarce.

Więcej serwerów nie pomoże. Co naprawdę dzieje się z sesjami eZamówień?

Komunikat administratorów z 29 października zawiera szczególnie istotne stwierdzenie - problemy w większości przypadków ustępują po zmniejszeniu intensywności ruchu na platformie. Jednocześnie administratorzy wyjaśniają, że nie jest to klasyczny problem wydajnościowy, który można rozwiązać zwykłym dodaniem zasobów. Zespoły techniczne pracują nad konfiguracją środowiska i codziennie wdrażają kolejne aktualizacje. To informacja, którą warto przeanalizować.

Z perspektywy infrastruktury IT samo stwierdzenie, że problemy nasilają się pod obciążeniem, nie oznacza automatycznie niedoboru mocy obliczeniowej. Podobne objawy mogą występować przy problemach z zarządzaniem sesjami, współdzielonym magazynem stanu aplikacji, mechanizmami uwierzytelniania, konfiguracją load balancera albo komunikacją między usługami.

Problem może znajdować się poza samą warstwą wydajnościową

W środowisku rozproszonym znaczenie ma spójność stanu użytkownika między instancjami aplikacji - jeżeli stan sesji przechowywany jest lokalnie, a kolejne żądania użytkownika trafiają do różnych węzłów, niewłaściwa konfiguracja może prowadzić do pozornie losowego wylogowywania. Podobne efekty mogą powodować problemy z odnawianiem tokenów uwierzytelniających, obsługą cookies, timeoutami czy zależnościami pomiędzy komponentami aplikacji.

Kolejną klasą problemów są błędy współbieżności, a występują one gdy równoczesne operacje wielu użytkowników prowadzą do nieprzewidzianych konfliktów, blokad lub niespójności stanu. Czasami problem ujawnia się wyłącznie przy odpowiednio dużym ruchu, mimo że podstawowe metryki CPU i RAM pozostają w normie. Możliwy jest również scenariusz związany z niedostateczną wydajnością jednej zależności, przez którą przechodzi duża liczba operacji.

Nie ma przy tym znaczenia, że pozostałe elementy infrastruktury dysponują ogromną rezerwą zasobów. Jeżeli jeden krytyczny komponent nie odpowiada prawidłowo, doświadczenie użytkownika może być fatalne. Wszystkie powyższe przykłady opisują możliwe klasy usterek, a nie potwierdzoną przyczynę awarii eZamówień. Bez logów, telemetrii, konfiguracji i dokumentacji zmian nie można odpowiedzialnie wskazać źródła problemu.

Można jednak zadać konkretne pytania - czy administratorzy monitorują liczbę nieudanych odnowień sesji? Czy dysponują metrykami błędów uwierzytelniania? Czy analizują czas odpowiedzi poszczególnych usług? Czy porównano konfiguracje środowiska sprzed prac serwisowych i po ich zakończeniu? Czy przeprowadzono testy obciążeniowe odtwarzające zaobserwowane problemy? Czy istnieje bezpieczna możliwość przywrócenia wcześniejszej konfiguracji, jeżeli zostanie wykazane, że to ona odpowiada za stabilność usługi?

To standardowy zestaw pytań związanych z diagnostyką systemów produkcyjnych.Nie wymagają wieloletniej strategii - wymagają logów.

System działa, ale użytkownik powinien sam ocenić ryzyko

Awaria platformy zamówień publicznych ma zupełnie inny ciężar gatunkowy niż niedostępność zwykłej strony internetowej - to środowisko wykorzystywane w postępowaniach regulowanych przepisami prawa. Zamawiający publikują ogłoszenia, komunikują się z wykonawcami, zmieniają terminy i przeprowadzają określone czynności proceduralne. Wykonawcy przygotowują i przesyłają oferty. Niektóre czynności muszą zostać wykonane przed ściśle określonym terminem.

Administratorzy informują, że mimo zakłóceń część użytkowników nadal jest w stanie publikować ogłoszenia, zmieniać terminy czy komunikować się z wykonawcami. Nie można zatem twierdzić, że od 26 października każda funkcja platformy pozostaje całkowicie niedostępna. Sytuacja jest tu bardziej skomplikowana.

System działa niestabilnie, a użytkownicy napotykają problemy podczas wykonywania czynności istotnych dla prowadzonych postępowań. UZP wskazuje możliwość skorzystania z Systemu Obsługi Zgłoszeń, czyli SOZ. W określonych przypadkach zespół wsparcia może pomóc przy wykonaniu czynności technicznych, w tym związanych ze zmianą terminu lub obsługą czynności dotyczących ofert.

Jednocześnie urząd zaznacza, że to zamawiający odpowiada za ocenę wpływu awarii na przebieg konkretnego postępowania. Co więcej, zespoły wsparcia mogą pomóc wdrożyć decyzję zamawiającego, ale nie dokonują oceny zasadności jego czynności ani nie udzielają indywidualnego doradztwa w sprawie konkretnego postępowania. Z prawnego punktu widzenia ma to swoje uzasadnienie.

Administrator platformy nie może automatycznie zastąpić zamawiającego w podejmowaniu decyzji proceduralnych. Problem polega jednak na czymś innym. Państwo udostępnia centralną platformę do obsługi zamówień publicznych, ale gdy platforma ulega awarii, istotna część ryzyka operacyjnego i proceduralnego pozostaje po stronie zamawiających i wykonawców prowadzących za jej pośrednictwem postępowania.

Warto przy tym zaznaczyć, że na szczęście nie wszystkie zamówienia publiczne prowadzone są przez eZamówienia. Zamawiający mogą korzystać również z innych dopuszczonych prawem narzędzi komunikacji elektronicznej. Nie zmniejsza to jednak znaczenia centralnej platformy, między innymi w zakresie publikacji ogłoszeń w Biuletynie Zamówień Publicznych. Dla przedsiębiorcy awaria oznacza potencjalnie dodatkową pracę, niepewność oraz trudności z wykonaniem czynności w terminie. Dla zamawiającego - konieczność podejmowania decyzji pod presją harmonogramu, a czas w postępowaniu przetargowym ma nieprzyjemną właściwość - nie zatrzymuje się tylko dlatego, że aplikacja zgubiła sesję.

Regulamin eZamówień. Użytkownik ma problem, UZP ma paragraf

W regulaminie platformy znajduje się zapis, który w kontekście obecnej awarii zasługuje na szczególną uwagę.

§ 2 ust. 7 regulaminu e-Zamówień stanowi:

Niedostępność Platformy e-Zamówienia nie może stanowić uzasadnienia roszczeń względem Prezesa Urzędu Zamówień Publicznych.

To autentyczne postanowienie dokumentu udostępnionego na stronie platformy. Trzeba podkreślić, że samo umieszczenie takiego zapisu w regulaminie nie przesądza jeszcze o jego skuteczności prawnej w każdej możliwej sytuacji. O ewentualnej odpowiedzialności rozstrzygają właściwe przepisy, konkretne okoliczności i - w razie sporu, odpowiednie organy lub sądy.

Jednak zestawienie tego postanowienia z aktualnymi komunikatami daje materiał do interesującej dyskusji o odpowiedzialności za e-usługi publiczne. Platforma ulega awarii. Zamawiający musi ocenić wpływ zakłóceń na własne postępowanie. Wsparcie techniczne może próbować pomóc, ale nie przejmuje odpowiedzialności za decyzje proceduralne, a regulamin zawiera postanowienie ograniczające możliwość uzasadniania roszczeń samą niedostępnością platformy.

Oczywiście administracja publiczna musi zabezpieczać się przed nieuzasadnionymi roszczeniami, jednak użytkownik ma również prawo oczekiwać odpowiednio wysokich standardów dostępności i przewidywalności systemu, od którego zależą istotne czynności prawne i gospodarcze.

Powstaje więc pytanie - jak rozkłada się odpowiedzialność za skutki awarii centralnej infrastruktury publicznej, jeśli użytkownicy wykonują w niej czynności wymagające zachowania ustawowych terminów? I uprzedzamy, że nie jest to pytanie retoryczne - to zagadnienie, które zasługuje na analizę zarówno techniczną, jak i prawną - zwłaszcza w państwie, które zamierza przenosić coraz większą część usług do internetu.

Kto odpowiada za platformę? UZP, Ministerstwo Cyfryzacji i ponad 34 miliony złotych

W tym miejscu trzeba precyzyjnie rozdzielić odpowiedzialność operacyjną od projektowej i strategicznej. Platformę eZamówienia prowadzi Urząd Zamówień Publicznych. Oficjalna dokumentacja projektu na stronie Ministerstwa Cyfryzacji wskazuje:

• Beneficjent projektu: Urząd Zamówień Publicznych.

• Partner projektu: Ministerstwo Cyfryzacji.

Projekt realizowano w latach 2019 - 2022 w ramach Programu Operacyjnego Polska Cyfrowa na lata 2014-20, a jego całkowita wartość wynosiła 34 607 304 zł brutto. Finansowanie obejmowało środki Unii Europejskiej i budżetu państwa a sam projekt zakładał między innymi stworzenie platformy do elektronicznej obsługi postępowań, rozwój interfejsów API, systemu komunikacji oraz narzędzi analitycznych. Ważne zastrzeżenie: kwota 34,6 mln zł odnosi się do historycznej wartości projektu, a nie do kosztu usunięcia obecnej awarii czy bieżącego budżetu jego utrzymania.

Ministerstwo Cyfryzacji jest oficjalnym partnerem projektu i jednocześnie instytucją odpowiedzialną za strategiczny rozwój e-administracji, a to daje wystarczający powód do zadania pytań dotyczących standardów niezawodności, zarządzania zmianą, testowania aplikacji oraz odporności cyfrowych usług publicznych.

Ministerstwo nie musi administrować każdym serwerem - powinno natomiast umieć wyjaśnić, jakie standardy jakości promuje, jak są one egzekwowane w projektach państwowych i w jaki sposób oceniana jest faktyczna niezawodność usług. Szczególnie że projekt eZamówienia realizowano w ramach działania o wyjątkowo wymownej nazwie - "Wysoka dostępność i jakość e-usług publicznych".

W tym momencie można już niemal usłyszeć odległy dźwięk orkiestry grającej podczas uroczystego otwierania kolejnego systemu, który po pierwszym większym wdrożeniu sugeruje użytkownikom usunięcie cookies.

Strategia Cyfryzacji do 2035 roku kontra rzeczywistość października 2026

15 lipca 2026 roku Ministerstwo Cyfryzacji opublikowało materiał dotyczący przyjętej przez rząd Strategii Cyfryzacji Państwa. Dokument wyznacza dość ambitne cele. Do 2030 roku wszystkie kluczowe usługi publiczne mają być dostępne w pełni online. Administracja ma ograniczyć wielokrotne zbieranie tych samych danych, a obywatele powinni móc załatwiać sprawy bez wizyty w urzędzie. Do 2035 roku sztuczna inteligencja ma wspierać pracę 80% urzędów, a kompetencje cyfrowe społeczeństwa i infrastruktura państwa mają osiągnąć znacznie wyższy poziom.

Trudno kwestionować potrzebę takich zmian. Problem polega na tym, że dostępność usługi w internecie nie jest tym samym co jej niezawodność. System może formalnie realizować usługę online, a jednocześnie być bezużyteczny w chwili dużego obciążenia albo awarii jednego z kluczowych komponentów. W informatyce rozróżnia się między innymi:

• Availability -> dostępność usługi.

• Reliability -> niezawodność.

• Resilience -> odporność i zdolność do działania mimo zakłóceń.

• Recovery Time Objective (RTO) -> docelowy czas przywrócenia usługi.

• Recovery Point Objective (RPO) -> dopuszczalną utratę danych wyrażoną w czasie.

• Service Level Objective (SLO) -> mierzalny cel jakości usługi.

To właśnie takie parametry powinny mieć znaczenie przy ocenie dojrzałości cyfrowych usług państwowych. Nie wystarczy bowiem, że dana usługa ma adres internetowy i guzik "Zaloguj". Trzeba jeszcze zadbać, żeby użytkownik mógł skutecznie przeprowadzić operację biznesową, szczególnie w godzinach największego obciążenia.

Istnieje zasadnicza różnica między systemem, który pozwala otworzyć stronę główną, a systemem, który niezawodnie obsługuje proces wymagający uwierzytelnienia, przesłania dokumentów i zachowania określonego terminu. Dlatego warto postawić pytanie o sens ambitnych wskaźników liczbowych bez równie wyraźnego nacisku na jakość świadczenia usług. Sto procent kluczowych usług publicznych dostępnych online nie będzie wielkim osiągnięciem, jeżeli użytkownicy nie otrzymają gwarancji, że rzeczywiście mogą z tych usług korzystać. Cyfrowe państwo musi być czymś więcej niż katalogiem adresów URL.

Co powinien zawierać raport techniczny z awarii?

Po przywróceniu stabilnego działania platformy Urząd Zamówień Publicznych powinien opublikować szczegółowy raport poawaryjny (Post-Incident Review), obejmujący analizę przyczyn źródłowych (Root Cause Analysis), wpływ incydentu na użytkowników oraz działania zapobiegające jego ponownemu wystąpieniu.

Nie chodzi o publikowanie wrażliwej konfiguracji infrastruktury ani danych, które mogłyby ułatwić atak na platformę. Chodzi o przejrzyste przedstawienie tego, co zawiodło i jakie wnioski wyciągnięto. Taki dokument powinien odpowiedzieć przynajmniej na następujące pytania.

Co dokładnie zawiodło?

Czy problem dotyczył usług uwierzytelniania, zarządzania sesjami, integracji między komponentami, warstwy aplikacyjnej, bazy danych czy infrastruktury sieciowej?

Czy awaria miała związek z pracami serwisowymi?

Czy zmiany wdrożone między 23 a 25 października wpłynęły na późniejszą stabilność? Jeżeli tak, jaka konkretna zmiana spowodowała problem? Jeżeli nie, jakie ustalenia pozwalają wykluczyć taki związek?

Dlaczego problemy nasilały się przy większym ruchu?

Czy zidentyfikowano ograniczenia związane ze współbieżnością, zarządzaniem stanem sesji, zależnościami aplikacyjnymi albo zasobami współdzielonymi?

Jak działały monitoring i alertowanie?

Czy administratorzy wykryli problem automatycznie? Czy system monitorowania pozwolił zidentyfikować krytyczny komponent? Czy alerty występowały jeszcze przed zgłoszeniami użytkowników?

Czy możliwy był rollback?

Jeżeli określone wdrożenie spowodowało niestabilność, czy istniała możliwość bezpiecznego przywrócenia poprzedniego stanu? Jeżeli nie to z jakich powodów?

Jaki był rzeczywisty wpływ awarii?

Ilu użytkowników napotkało błędy? Ile operacji zakończyło się niepowodzeniem? Czy i w jakim zakresie problemy wpłynęły na terminy składania ofert oraz przebieg postępowań?

Co zostanie zmienione?

Czy opracowano działania korygujące? Czy ustalono ich właścicieli, terminy oraz sposób weryfikowania skuteczności? To standardowe zagadnienia związane z zarządzaniem poważnymi incydentami IT. W wielu organizacjach wykorzystuje się do tego również mierniki, takie jak Mean Time to Detect (MTTD) czy Mean Time to Restore (MTTR).

Nie chodzi o szukanie kozła ofiarnego - chodzi o ustalenie przyczyn, ograniczenie skutków i usunięcie słabości systemowych. W świecie profesjonalnych operacji IT samo stwierdzenie, że "prowadzono intensywne prace", nie jest jeszcze raportem poawaryjnym. Jest informacją, że ktoś pracował. To niekoniecznie to samo.

Ministerstwo Cyfryzacji przedstawia: Departament Wielkich Strategii i Zaginionej Sesji

W całej tej historii najbardziej fascynująca nie jest nawet sama awaria bo systemy informatyczne mają to siebie, że czasem się psują. Czasami w sposób spektakularny, czasami kompromitujący, a czasami tak osobliwy, że administrator przez trzy godziny patrzy w logi i zaczyna rozważać hodowlę alpak. Fascynujące jest coś innego. Ministerstwo Cyfryzacji, oficjalny partner projektu przedstawia obywatelom wizję państwa cyfrowego do 2035 roku, podczas gdy jedna z istotnych usług publicznych nie potrafi niezawodnie utrzymać zalogowanego użytkownika.

Trudno nie zauważyć groteskowego rozdźwięku między ambitnymi deklaracjami a doświadczeniami użytkowników, którzy próbują wykonać podstawowe czynności w systemie. Wyobraźmy sobie więc posiedzenie fikcyjnego Departamentu Cyfrowej Doskonałości.

"Obywatele mają problem z utrzymaniem sesji, panie ministrze".

"Doskonała wiadomość. A jak wygląda Strategia Cyfryzacji do 2035 roku?"

"Prezentuje się znakomicie".

"A platforma?"

"Nie działa prawidłowo".

"Zatem strategia wyraźnie wyprzedza rzeczywistość. Proszę wpisać to do raportu jako sukces transformacji".

W tym samym czasie przedsiębiorca próbuje złożyć ofertę. System odmawia współpracy, termin nieubłaganie się zbliża, a oficjalny komunikat przypomina, że zamawiający powinien samodzielnie ocenić ryzyko związane z awarią.

To już niemal gotowy skecz o administracji, która stworzyła elektroniczną procedurę po to, żeby ograniczyć niepewność, a następnie poinformowała użytkownika, że niepewność stanowi obecnie jego indywidualną odpowiedzialność. Nic tylko zatrudniać Pana Walaszka.

Najlepsze pozostawiono jednak na koniec. Oficjalna dokumentacja projektu eZamówienia wskazuje, że był on współfinansowany w ramach działania o szumnej nazwie: "Wysoka dostępność i jakość e-usług publicznych". Nie "Dostępność okazjonalna". Nie "Jakość zależna od liczby otwartych kart w przeglądarce". Nawet nie "Usługi publiczne, które zasadniczo działają, chyba że akurat są potrzebne". Wysoka dostępność i jakość e-usług publicznych. Cóż za piękna nazwa. Można ją wydrukować, oprawić w elegancką ramkę i zawiesić obok monitora z komunikatem o awarii. Byłaby to prawdopodobnie najbardziej niezawodna część całego przedsięwzięcia.

A jeśli komuś przeszkadzałby nadmiar ironii, zawsze można utworzyć Departament Wyjaśniania, Dlaczego Nazwa Projektu Nie Musi Odpowiadać Aktualnemu Stanowi Projektu. Naturalnie z osobnym podzespołem do spraw podzespołów. I formularzem elektronicznym. Pod warunkiem że uda się zalogować.

Cyfryzacja nie polega na zamienianiu problemów papierowych w elektroniczne

Ministerstwo Cyfryzacji nie musi osobiście naprawiać mechanizmu sesji platformy eZamówień. Powinno jednak, jako partner projektu i autor strategicznej wizji cyfrowego państwa, interesować się tym, czy deklarowane standardy dostępności, testowania i odporności usług publicznych rzeczywiście przekładają się na praktykę.

Bo cyfryzacja nie polega na tym, że urzędowy formularz zastępujemy formularzem internetowym, a potem każemy obywatelowi samodzielnie rozważyć konsekwencje tego, że formularz internetowy przestał odpowiadać. Nie polega również na organizowaniu coraz bardziej imponujących konferencji o roku 2035, kiedy użytkownik próbuje wykonać czynność z terminem przypadającym na dzisiaj.

Można oczywiście przyjąć, że plan na najbliższe dziewięć lat jest ważniejszy niż aktualny stan platformy. Tylko że przedsiębiorcy i zamawiający mają pewną niewygodną cechę - żyją w roku 2026. W informatyce istnieją pojęcia availability, reliability, incident management, root cause analysis i rollback. Żadne z nich nie oznacza "prosimy o wyrozumiałość przez czas nieokreślony".

Od instytucji odpowiedzialnych za cyfrowe usługi publiczne należy oczekiwać nie tylko komunikatów o trwających pracach, ale również przejrzystego raportu dotyczącego przyczyn awarii, jej wpływu na użytkowników, chronologii działań oraz zabezpieczeń przed podobnymi zdarzeniami. I jeszcze jednej rzeczy. W państwie, które chce przenieść 100% kluczowych usług publicznych do internetu, niezawodność nie może być funkcją opcjonalną, aktywowaną dopiero po zakończeniu prac serwisowych.

Na razie Polska Cyfrowa roku 2035 wygląda wspaniale - Polska Cyfrowa roku 2026 uprzejmie prosi o wyczyszczenie plików cookies i pamięci podręcznej. Następnie zaleca ponowne uruchomienie przeglądarki. A później, najwyraźniej, odrobinę cierpliwości.

Jeżeli to jest podróż ku cyfrowej przyszłości, wypada tylko mieć nadzieję, że do 2035 roku uda się przynajmniej utrzymać sesję przez całą konferencję prasową poświęconą jej osiągnięciom.