Elektroniczne protokoły postępowania: tworzenie, podpisywanie, przechowywanie

0
6
Rate this post

Scenka z praktyki: „Proszę o udostępnienie protokołu… tylko którego?”

Kontroler z instytucji zarządzającej pisze: „Proszę o przesłanie elektronicznego protokołu postępowania wraz z załącznikami”. Zamawiający otwiera folder „Przetarg X” i widzi: protokol_v1.docx, protokol_popr.docx, protokol_podpisany.pdf, protokol_podpisany_poprawiony.pdf i jeszcze „protokol_ostateczny_Anna”. Do tego różne wersje generowane automatycznie na platformie e-zamówień. Który dokument jest tym właściwym, ostatecznym i ważnym dowodowo?

Zespół był przekonany, że „skoro wszystko jest w systemie”, to bałagan im nie grozi. W praktyce okazało się, że nikt nie opisał jasno, jak prowadzony jest elektroniczny protokół postępowania, kto go tworzy, kto zatwierdza, kto podpisuje i gdzie przechowuje się wersję finalną. Dopiero przy pierwszej poważniejszej kontroli zobaczyli, że protokół to nie plik, ale proces, który musi być poukładany od początku do końca.

Elektroniczny protokół postępowania w e-zamówieniach to zestaw powiązanych działań: zaprojektowanie struktury dokumentu, wypełnianie go na bieżąco, uzgadnianie treści, podpisywanie kwalifikowanymi podpisami, udostępnianie wykonawcom i instytucjom, a na końcu – bezpieczne przechowywanie w sposób gwarantujący jego integralność i autentyczność. Im lepiej zostanie to ułożone, tym mniej nerwów przy odwołaniach i kontrolach.

Ręka podpisuje papierowy protokół długopisem na drewnianym biurku
Źródło: Pexels | Autor: Pixabay

Podstawy prawne i rola protokołu w elektronicznym postępowaniu

Funkcja protokołu w zamówieniach publicznych

Elektroniczny protokół postępowania jest centralnym dokumentem opisującym cały przebieg postępowania o udzielenie zamówienia. Skupia informacje rozproszone w różnych miejscach: na platformie e-zamówień, w systemie e-Zamówienia, w poczcie elektronicznej, w wewnętrznych notatkach komisji. Dla osoby z zewnątrz – kontrolera, audytora, członka KIO – to pierwszy dokument, po który sięga, żeby zrozumieć, co się działo.

Protokół „spina” w całość inne dokumenty elektroniczne: oferty, JEDZ/ozświadczenia, wyjaśnienia, wezwania, korespondencję, raporty z sesji otwarcia, wyniki oceny. Nie musi powielać całej treści tych materiałów, ale musi je identyfikować i opisywać w sposób, który umożliwia powiązanie każdego zdarzenia z konkretnym dokumentem czy czynnością. W wersji elektronicznej istotne jest szczególnie powiązanie z logami systemu (daty, godziny, identyfikatory użytkowników).

W razie sporu lub odwołania protokół jest jednym z kluczowych dowodów. Jeśli jest wewnętrznie sprzeczny, niepełny lub zawiera rozbieżne daty i oznaczenia dokumentów, podważa to wiarygodność całego postępowania. Dlatego elektroniczny protokół nie może być traktowany jako „formalny załącznik do akt”, ale jako główne źródło wiedzy o przebiegu sprawy.

Wymogi ustawowe i rozporządzenia w praktycznym ujęciu

Ustawy i rozporządzenia (w szczególności Prawo zamówień publicznych i akty wykonawcze) określają, jakie informacje muszą znaleźć się w protokole oraz jak długo należy przechowywać dokumentację zamówień. Normy te dotyczą zarówno postępowania prowadzonego w formie papierowej, jak i w pełni elektronicznej. Elektroniczna forma nie zwalnia z obowiązków, a wręcz dodaje nowe – związane z cyberbezpieczeństwem i wiarygodnością danych.

W praktyce zamawiający ma do wyboru:

  • korzystanie z gotowych wzorów protokołów (np. załączniki do rozporządzeń lub szablony w systemie e-Zamówienia bądź komercyjnej platformie),
  • opracowanie własnego szablonu elektronicznego protokołu (np. w edytorze tekstu, systemie EZD lub innym narzędziu wewnętrznym).

Gotowe wzory mają tę zaletę, że są z reguły zgodne z wymaganiami minimalnymi. Często jednak w praktyce brakuje w nich pól na dane specyficzne dla danego zamawiającego, opis używanej platformy, numerów ID postępowań w systemie centralnym czy szczegółowych odniesień do załączników elektronicznych. Dlatego wielu zamawiających modyfikuje szablony lub tworzy własne, by lepiej odzwierciedlić elektroniczne środowisko pracy.

Przepisy określają również minimalne terminy przechowywania dokumentacji postępowania. W wersji elektronicznej kluczowe jest, aby przez cały wymagany okres dało się zweryfikować podpisy elektroniczne i spójność plików. Samo posiadanie pliku PDF w folderze sieciowym nie wystarczy, jeśli za kilka lat nie będzie można potwierdzić ważności e-podpisu użytego przy zatwierdzaniu protokołu.

Minimalna znajomość przepisów jako filtr decyzyjny

Osoby odpowiedzialne za przygotowanie i zatwierdzanie protokołu często nie są prawnikami. Wystarczy jednak podstawowa orientacja w wymaganiach ustawowych, by uniknąć większości problemów. Dobrze jest mieć wewnętrzną „ściągę” lub procedurę, w której wskazano:

  • jakie elementy obowiązkowo muszą znaleźć się w protokole,
  • jakie informacje mogą być przeniesione do załączników,
  • jakie terminy przechowywania dotyczą danej kategorii postępowań,
  • kto odpowiada za pilnowanie kompletności dokumentacji.

Dzięki temu komisja przetargowa nie spiera się o to, czy np. szczegóły oceny ofert mają być w treści protokołu, czy wystarczą arkusze oceny w załączniku. Odpowiedź wynika wprost z przyjętego standardu zgodnego z przepisami. Protokół staje się wówczas dokumentem uporządkowanym, a nie „zlepkiem” przypadkowych informacji.

Wniosek praktyczny: minimum znajomości przepisów oszczędza czas, bo pozwala szybko rozstrzygać, co musi znaleźć się w treści protokołu, a co wystarczy wskazać jako odrębny załącznik elektroniczny.

Bizneswoman podpisuje dokument przy biurku z laptopem i książką
Źródło: Pexels | Autor: www.kaboompics.com

Co dokładnie powinno znaleźć się w elektronicznym protokole postępowania

Zakres danych i informacji w praktyce

Elektroniczny protokół postępowania powinien odpowiadać na kilka prostych pytań: co było przedmiotem zamówienia, kto brał w nim udział, kiedy i jakie czynności wykonano, jakie decyzje podjęto i dlaczego. To brzmi prosto, ale w realnym postępowaniu wymaga konsekwentnego gromadzenia i porządkowania informacji.

W praktyce w protokole powinny znaleźć się m.in. takie elementy:

  • identyfikacja postępowania (nr postępowania, nazwa, ID w systemie e-Zamówienia lub na platformie),
  • opis przedmiotu zamówienia (skrótowy, z odwołaniem do SWZ),
  • tryb postępowania i podstawa prawna,
  • wartość szacunkowa i informacja o podziale na części,
  • skład komisji przetargowej oraz osób wykonujących czynności,
  • harmonogram czynności (daty i godziny kluczowych działań: ogłoszenie, składanie ofert, otwarcie, wezwania, wyjaśnienia, wybór oferty, zawarcie umowy),
  • wykaz wykonawców biorących udział w postępowaniu,
  • wykaz złożonych ofert wraz z podstawowymi parametrami (cena, okres realizacji, okres gwarancji – w zależności od kryteriów),
  • decyzje o odrzuceniu ofert, wykluczeniu wykonawców, unieważnieniu części lub całości postępowania wraz z uzasadnieniem,
  • opis przebiegu oceny ofert (np. wyniki oceny punktowej, informacja o negocjacjach),
  • wskazanie oferty najkorzystniejszej i uzasadnienie wyboru.

W postępowaniu elektronicznym dochodzą jeszcze elementy związane z komunikacją elektroniczną. Protokół powinien wskazywać, jakie kanały zostały użyte (platforma, system e-Zamówienia, ePUAP, e-mail), w jakich terminach dokonano poszczególnych czynności i jak je udokumentowano (logi systemowe, raporty z platformy).

Załączniki do protokołu – osobne pliki, ale jeden zestaw dowodowy

W środowisku elektronicznym dokumentacja zamówienia składa się z szeregu odrębnych plików: ofert, oświadczeń, wyjaśnień, raportów z sesji otwarcia, plików z logami. Gdyby wszystkie te informacje umieścić w treści protokołu, stałby się on nieczytelny. Rozwiązaniem jest jasny podział: protokół zawiera opis i odwołania, a szczegółowe treści znajdują się w załącznikach.

Załącznikami do elektronicznego protokołu postępowania są w szczególności:

  • oferty i ich pliki składowe (wraz z potwierdzeniami złożenia),
  • oświadczenia i dokumenty składane przez wykonawców (np. JEDZ, oświadczenia o grupie kapitałowej),
  • korespondencja z wykonawcami (wezwania, wyjaśnienia, odpowiedzi),
  • notatki służbowe z czynności komisji,
  • raporty i logi z platformy e-zamówień (np. raport otwarcia ofert, raport wysłanych wiadomości),
  • protokoły z dodatkowych czynności (negocjacje, dialog techniczny, wizje lokalne), jeśli wystąpiły.

Kluczową kwestią jest powiązanie tych załączników z protokołem. Dobrym zwyczajem jest stosowanie spójnego systemu oznaczania plików, np. ZP-01-2024_protokol.pdf, ZP-01-2024_zal1_oferty.zip, ZP-01-2024_zal2_korespondencja.zip, ZP-01-2024_zal3_logi_platforma.pdf. W samym protokole można zamieścić tabelę lub listę załączników z krótkim opisem zawartości.

Silne powiązanie protokołu z załącznikami jest kluczowe z punktu widzenia dowodowego. Kontroler, który otwiera protokół, powinien być w stanie w kilka minut skojarzyć każdą decyzję z konkretnym dokumentem źródłowym. Jeśli protokół odwołuje się do „pisma z dnia 10.03” bez wskazania, gdzie jest przechowywany plik i jak się nazywa, traci na przejrzystości.

Dane wrażliwe i tajemnice w treści protokołu

Protokoły postępowań często zawierają informacje objęte tajemnicą przedsiębiorstwa wykonawców oraz dane osobowe członków personelu wykonawcy czy osób wskazanych do realizacji zamówienia. W wersji elektronicznej łatwo o niekontrolowane kopiowanie i udostępnianie takich danych, dlatego sposób ich ujęcia w protokole wymaga rozwagi.

Elementy objęte tajemnicą przedsiębiorstwa powinny być opisane w taki sposób, aby umożliwić identyfikację decyzji (np. podstawy oceny oferty, przyczyny odrzucenia), ale bez ujawniania szczegółowych danych technicznych czy technologicznych. Często wystarczy wskazanie, że „w części oferty oznaczonej przez wykonawcę jako tajemnica przedsiębiorstwa stwierdzono niespełnienie wymagań określonych w pkt … SWZ”, zamiast cytowania całych fragmentów oferty.

W przypadku danych osobowych stosuje się zasadę minimalizacji: w protokole wykazuje się tylko te dane, które są niezbędne do zrozumienia przebiegu i wyniku postępowania (np. imię i nazwisko członków komisji, osób podejmujących decyzje, jeśli wynika to z przepisów wewnętrznych). Dane personelu wykonawcy zwykle wystarczająco opisane są w załącznikach (oferty, wykazy osób) i nie ma potrzeby przepisywania ich do protokołu w całości.

Jako praktyczny standard można przyjąć zasadę: protokołuj decyzje i fakty, nie kopiuj hurtowo danych. Gdy protokół trafia do udostępnienia szerokiemu kręgowi (np. wykonawcom na wniosek), łatwiej wówczas zadbać o zgodność z RODO i nie ryzykować nieuprawnionego ujawnienia informacji wrażliwych.

Przejrzysta struktura jako realne ułatwienie

Dobrze zaprojektowana struktura elektronicznego protokołu postępowania ułatwia pracę każdej zaangażowanej stronie: członkom komisji, osobom nadzorującym, wykonawcom, audytorom. Protokół, który ma jasno wyodrębnione sekcje (identyfikacja postępowania, przebieg, decyzje, załączniki), jest czytelny nawet po kilku latach.

Na etapie projektowania szablonu warto wręcz „przymierzyć” go do przykładowych postępowań: małego zapytania, dużego przetargu, postępowania z odwołaniem. Szybko widać, czy jakieś pola są zbędne, czy brakuje miejsca na opis istotnych czynności. Po 2–3 rundach poprawek szablon staje się narzędziem, a nie przeszkodą.

Konkluzja: porządna struktura protokołu to mniej telefonów z pytaniem „gdzie to jest?”, mniej korekt na ostatnią chwilę i znacznie większa odporność dokumentacji na stres testów w postaci kontroli i odwołań.

Dłoń podpisująca dokument długopisem na biurku
Źródło: Pexels | Autor: Cytonn Photography

Tworzenie protokołu w środowisku elektronicznym – krok po kroku

Wybór narzędzia: system e-Zamówienia, platforma komercyjna, szablon lokalny

Elektroniczny protokół postępowania można prowadzić na kilka sposobów. Każdy z nich ma swoje plusy i minusy, dlatego dobrze jest świadomie wybrać główne narzędzie i ustalić, jaką rolę pełnią pozostałe.

Najczęstsze modele to:

Model 1: protokół „wbudowany” w system e-Zamówienia lub platformę

Pracownik siada do komputera, otwiera zakładkę „Protokół” w systemie e-Zamówienia i widzi połowę pól wypełnionych automatycznie. Z jednej strony ulga, z drugiej – pytanie, czy to wystarczy na kontrolę RIO lub KIO. Pokusa, żeby „zaufać systemowi”, bywa duża, szczególnie przy dużej liczbie postępowań.

Model oparty na protokole generowanym wprost z systemu ma oczywistą zaletę: wiele danych (terminy, nazwy wykonawców, ceny, logi czynności) trafia do dokumentu automatycznie. Zmniejsza się ryzyko literówek i niespójności między protokołem a tym, co faktycznie działo się na platformie. Dla urzędów z niewielkim zespołem zamówieniowym to często jedyny realny sposób, żeby nadążyć z dokumentacją.

Ten komfort ma jednak swoją cenę. Gotowy „wydruk z systemu” zwykle nie obejmuje pełnego opisu motywów decyzji. Brakuje tam rozwiniętych uzasadnień, odniesień do konkretnych fragmentów SWZ czy ofert, a także opisów niestandardowych sytuacji (np. dwukrotne unieważnienie, powtarzające się błędy wykonawców). Samo to, że system odnotował czynność, nie oznacza jeszcze, że wiadomo, dlaczego podjęto taką a nie inną decyzję.

Bezpiecznym podejściem jest traktowanie protokołu z systemu jako szkieletu, który trzeba uzupełnić o brakujące elementy. W praktyce można przyjąć taki model pracy:

  • na bieżąco uzupełniać pola tekstowe w systemie (uzasadnienia, opisy czynności),
  • po zakończeniu postępowania wygenerować protokół z systemu w formacie edytowalnym (np. DOCX),
  • przejrzeć dokument pod kątem kompletności i dopisać brakujące fragmenty,
  • oznaczyć w nim jasno załączniki (oferty, korespondencja, logi) – z użyciem lokalnych nazw plików,
  • następnie spiąć całość w postać finalną (najczęściej PDF z podpisem elektronicznym).

Taki hybrydowy schemat daje korzyści z automatyzacji, ale nie uzależnia całej dokumentacji od jednego dostawcy systemu. Gdy za kilka lat zmieni się platforma, protokoły nadal będą zrozumiałe i kompletne.

Model 2: lokalny szablon protokołu + eksporty z systemu

W wielu jednostkach starsi pracownicy przyzwyczaili się do „swojego” formularza protokołu, który powstawał jeszcze w czasach papieru. Przejście na systemy elektroniczne nie zmieniło jednego – poczucia, że dokument sporządzony w lokalnym wzorze jest bardziej „ich” niż bezosobowy wydruk z platformy.

W modelu opartym na lokalnym szablonie to on jest dokumentem wiodącym. Platforma czy system e-Zamówienia służą jako źródło danych i repozytorium plików, ale narracja o postępowaniu powstaje w pliku przygotowywanym przez zamawiającego. Z technicznego punktu widzenia wygląda to zazwyczaj tak:

  • zespół przygotowuje wzór protokołu (DOCX/ODT) zgodny z wewnętrznym standardem i przepisami,
  • po kluczowych etapach (otwarcie, badanie, wybór) z systemu eksportowane są raporty, logi i zestawienia (CSV, XLSX, PDF),
  • dane liczbowe (np. ceny, punktacja) mogą być wklejane z raportów do tabel w protokole,
  • same raporty stanowią załączniki do protokołu, z jasno opisanym numerem i nazwą.

Takie podejście pozwala dopasować strukturę protokołu do specyfiki jednostki, uwzględnić procedury wewnętrzne (np. ścieżki akceptacji, udział radcy prawnego) oraz łatwo rozbudowywać opis tam, gdzie tego wymaga konkretna sprawa. Plusem jest też większa elastyczność archiwizacji – szablon można aktualizować, ale archiwalne protokoły pozostają niezmienne.

Słabym punktem bywa natomiast dyscyplina aktualizowania wzoru. Jeśli nikt nie czuwa nad jego dostosowywaniem do zmieniających się przepisów, po kilku latach w dokumentach zaczynają pojawiać się archaiczne podstawy prawne czy nieobowiązujące już rubryki. Rozwiązaniem jest przejęcie nadzoru nad wzorem przez jedną osobę lub mały zespół (np. koordynatora zamówień), który raz do roku robi „przegląd zdrowia” formularza.

Model 3: mieszany – minimum w systemie, rozszerzenie w załączniku opisowym

Zdarza się, że zamawiający działa na platformie, która ma bardzo prosty moduł protokołu, ograniczony do kilku pól i listy ofert. Taki „sztywny” formularz nie nadąża za rzeczywistością skomplikowanych postępowań, odwołań czy negocjacji. Wówczas rozsądną drogą jest model mieszany.

Rdzeń dokumentacji powstaje w systemie (terminy, oferty, podstawowe decyzje), a opis niestandardowych lub złożonych zagadnień tworzony jest w osobnym pliku, który staje się załącznikiem do protokołu. Może to być np.:

  • szczegółowy opis przebiegu negocjacji lub dialogu technicznego,
  • rozszerzone uzasadnienie odrzucenia ofert, gdy pojawia się wiele zastrzeżeń,
  • podsumowanie wniosków z odwołania i sposobu ich uwzględnienia.

Taki dokument opisowy ma swoje oznaczenie (np. „ZP-05-2024_uzasadnienie_rozszerzone.pdf”) i jest w protokole wyraźnie wskazany. Kontroler wie więc, że podstawowe informacje znajdzie w formularzu systemowym, a pełny obraz zdarzeń – w opisie załączonym przez komisję.

Wniosek z praktyki jest prosty: narzędzia systemowe rzadko w stu procentach pokrywają potrzeby dokumentacyjne. Zamiast walczyć z ich ograniczeniami, lepiej przyjąć model mieszany i świadomie rozdzielić, co powinno znaleźć się w „sztywnym” formularzu, a co w elastycznym załączniku.

Rejestrowanie zdarzeń na bieżąco, a nie po fakcie

Najwięcej problemów z protokołem pojawia się wtedy, gdy ktoś próbuje „odtworzyć” całe postępowanie na kilka dni przed podpisaniem umowy. Pół roku, kilka zmian personelu i jedno wezwanie do wyjaśnień, o którym nikt już nie pamięta – przepis na luki w opisie zdarzeń gotowy.

Bezpieczniejszy scenariusz zakłada, że protokół żyje wraz z postępowaniem. W wersji elektronicznej jest to szczególnie proste: dokument można otwierać i uzupełniać po każdej istotnej czynności. Sprawdza się tu podejście „krok po kroku”:

  • po ogłoszeniu postępowania: uzupełnienie sekcji identyfikacyjnej, trybu, wartości szacunkowej,
  • po otwarciu ofert: wpisanie liczby ofert, daty i godziny otwarcia, zestawienia podstawowych parametrów,
  • po pierwszym etapie badania: odnotowanie odrzuceń, wykluczeń i krótkiego uzasadnienia,
  • po negocjacjach lub wyjaśnieniach: dodanie informacji o przebiegu i wynikach czynności,
  • po wyborze oferty najkorzystniejszej: wpisanie rozstrzygnięcia i jego uzasadnienia,
  • po zawarciu umowy: wskazanie daty i głównych postanowień umowy (w zarysie) oraz oznaczenie jej jako załącznika.

Przy takim sposobie pracy każda czynność ma swój „świeży” opis, sporządzony, gdy szczegóły są jeszcze w głowie członków komisji. Docelowo mniej czasu zużywa się na nerwowe poszukiwania informacji i odtwarzanie sekwencji zdarzeń.

Dodatkowym atutem bieżącego uzupełniania jest możliwość wczesnego wychwycenia braków. Jeśli protokół po etapie badania ofert „woła” o wpisanie uzasadnienia odrzucenia, sygnał ten widać od razu. Łatwiej wtedy wrócić do wzoru pisma, korespondencji z wykonawcą czy notatki służbowej i spiąć je w spójną całość.

Podpisywanie protokołu w wersji elektronicznej

Scenka z życia: przewodniczący komisji loguje się do systemu, klika „podpisz protokół”, po czym dzwoni do informatyka z pytaniem, czy właśnie podpisał cały dokument, czy tylko jedno pole. Sposób podpisywania protokołu elektronicznego wciąż budzi wiele nieporozumień, zwłaszcza gdy w grę wchodzi kilku członków komisji i kierownik zamawiającego.

Punktem wyjścia jest decyzja, jaki rodzaj podpisu elektronicznego będzie stosowany w jednostce:

  • podpis kwalifikowany – zapewnia wysoki poziom bezpieczeństwa i jednoznaczną identyfikację, jest też najczęściej akceptowany przez organy kontrolne,
  • podpis zaufany (profil zaufany ePUAP) – wygodny, szczególnie dla mniejszych jednostek i osób, które nie posiadają podpisu kwalifikowanego,
  • podpis wewnętrzny/zaawansowany w systemie – uzależniony od funkcjonalności platformy, zwykle wykorzystywany w połączeniu z logami systemowymi.

Po wyborze narzędzia trzeba uporządkować kwestię kolejności i zakresu podpisów. Dobrze działa klarowny schemat, opisany w regulaminie udzielania zamówień, np.:

  • członkowie komisji podpisują roboczą wersję protokołu (lub jego części, jeśli system na to pozwala),
  • na końcu kierownik zamawiającego lub osoba upoważniona składa podpis zatwierdzający,
  • ewentualne korekty po podpisaniu wymagają ponownego podpisu lub przygotowania aneksu do protokołu.

W praktyce istotne jest, co dokładnie jest podpisywane. Jeżeli system umożliwia dodanie podpisu bezpośrednio pod treścią protokołu (np. w formacie PDF), sytuacja jest prosta: podpis obejmuje cały dokument. Jeśli jednak podpis składany jest „na poziomie systemu” (kliknięcie „zaakceptuj” bez wglądu w ostateczny PDF), należy zadbać, aby logi systemowe jednoznacznie wskazywały wersję dokumentu, której akceptacja dotyczy.

Bezpiecznym rozwiązaniem jest wygenerowanie finalnego pliku protokołu (najczęściej PDF), a następnie jego podpisanie kwalifikowanym podpisem elektronicznym lub podpisem zaufanym. Wówczas nie ma wątpliwości, że podpis dotyczy konkretnej treści i konkretnego zestawu załączników wymienionych w dokumencie.

Wielu podpisujących – jak zorganizować obieg elektroniczny

Gdy protokół ma podpisać pięcioosobowa komisja i kierownik jednostki, a każdy korzysta z innego rodzaju podpisu, łatwo o chaos. Jeden wydrukuje, inny podpisze PDF, trzeci kliknie w systemie – a potem trudno ustalić, która wersja jest tą „prawdziwą”.

Porządek można wprowadzić, stosując ustaloną ścieżkę obiegu protokołu. Przykładowo:

  1. Sekretarz komisji przygotowuje finalny plik protokołu (PDF) na podstawie danych z systemu i szablonu lokalnego.
  2. Plik trafia do podpisu członków komisji – np. kolejno, w uzgodnionej kolejności, lub równolegle, przy użyciu narzędzia do wielokrotnego podpisywania (jeśli jest dostępne).
  3. Po zebraniu wszystkich podpisów komisji dokument przesyłany jest do kierownika zamawiającego, który składa swój podpis jako ostatni.
  4. Podpisany plik jest umieszczany w elektronicznym repozytorium (system EZD, elektroniczne archiwum zamówień), a w systemie e-Zamówienia lub na platformie zamieszczana jest ta właśnie wersja jako obowiązujący protokół.

W regulaminie warto doprecyzować m.in.:

  • terminy na podpisanie protokołu przez poszczególne osoby,
  • sposób postępowania w razie nieobecności członka komisji (zastępca, adnotacja),
  • zasady wersjonowania – co zrobić, gdy po podpisaniu trzeba wprowadzić drobną korektę (np. oczywista omyłka pisarska).

Dzięki temu każdy członek komisji wie, kiedy i jak ma złożyć podpis, a sekretarz nie musi codziennie wysyłać maili z pytaniem, czy ktoś już „kliknął”. Elektroniczny obieg staje się powtarzalny i przewidywalny, co ma ogromne znaczenie przy większej liczbie postępowań.

Łączenie treści protokołu z podpisem – unikanie „gołych” plików

Błędem, który ciągle się zdarza, jest podpisywanie samej wersji roboczej protokołu, bez wskazania kompletu załączników lub bez aktualizacji po istotnej zmianie (np. po unieważnieniu postępowania). Po kilku miesiącach trudno potem ustalić, czy podpis odnosi się do tego, co faktycznie jest przechowywane w repozytorium.

Aby tego uniknąć, w końcowej części protokołu warto umieścić krótką sekcję techniczną, np.:

  • wskazanie wersji dokumentu (np. „Wersja 1.2 z dnia 15.04.2024 r.”),
  • listę zasadniczych załączników z ich nazwami plików i formatami,
  • informację, gdzie przechowywane są pliki źródłowe (np. ścieżka w systemie EZD lub nazwa folderu w repozytorium).

Taka adnotacja sprawia, że podpis elektroniczny obejmuje nie tylko treść „opisową”, lecz także ramy zestawu dowodowego. Osoba kontrolująca ma jasność, że podpisany dokument odwołuje się do konkretnych plików i konkretnej struktury archiwum, a nie do bliżej nieokreślonej „dokumentacji postępowania” rozproszonej po wielu katalogach.

Przechowywanie elektronicznego protokołu i załączników

Kluczowe Wnioski

  • Elektroniczny protokół to nie pojedynczy plik, lecz uporządkowany proces: od tworzenia i uzupełniania na bieżąco, przez uzgadnianie treści i podpisywanie, aż po bezpieczne przechowywanie jednej wersji finalnej.
  • Protokół pełni rolę centralnego „kręgosłupa” postępowania – spina oferty, korespondencję, wyjaśnienia, raporty z systemu i logi, tak aby zewnętrzny kontroler mógł z niego odtworzyć cały przebieg sprawy.
  • Bałagan w wersjach (kolejne pliki „v1”, „poprawiony”, „ostateczny”) to realne ryzyko dowodowe; organizacja musi jasno określić, kto tworzy, kto zatwierdza, kto podpisuje i gdzie przechowywana jest wersja uznawana za wiążącą.
  • Gotowe wzory protokołów zapewniają zgodność z minimum ustawowym, ale często nie uwzględniają specyfiki e-zamówień (ID postępowań, opisy platform, odwołania do logów i załączników), dlatego wymagają świadomej modyfikacji lub stworzenia własnego szablonu.
  • Forma elektroniczna nie zmniejsza obowiązków, lecz dodaje nowe: przez cały okres archiwizacji trzeba być w stanie potwierdzić ważność podpisów elektronicznych oraz integralność plików, a nie tylko „mieć PDF na dysku”.
  • Prosta, wewnętrzna instrukcja (co musi być w protokole, co może być w załączniku, kto pilnuje kompletności, jakie są terminy przechowywania) ogranicza spory w zespole i przyspiesza pracę komisji przetargowej.
Poprzedni artykułTerminy w postępowaniach poniżej progów unijnych: elastyczność a bezpieczeństwo
Daniel Wojciechowski
Praktyk rynku przetargowego, od lat wspierający wykonawców w przygotowaniu ofert i komunikacji z zamawiającymi. Specjalizuje się w analizie SWZ, wyjaśnianiu wymagań technicznych oraz kompletowaniu dokumentów podmiotowych i przedmiotowych. Na EuroZamówienia.pl opisuje typowe błędy wykonawców i pokazuje, jak ich unikać, korzystając z przykładów z realnych postępowań. Każdy poradnik opiera na aktualnych interpretacjach UZP i orzeczeniach KIO, a rozwiązania testuje w praktyce, przygotowując oferty dla firm z różnych branż.