Wyrok KIO 1646/26 z 18 maja 2026

1. Oddala odwołanie w sprawie o sygn. akt KIO 1646/26.
2. Odrzuca odwołanie w sprawie o sygn. akt KIO 1648/26 w zakresie zarzutu nr 1a, ​ a w pozostałej części oddala odwołanie.
3. Kosztami postępowania w sprawie KIO 1646/26 obciąża odwołującego: Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie i:
4. 1zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (piętnaście tysięcy złotych zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania, 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika zamawiającego oraz 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika wykonawcy Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie; 3.2zasądza od odwołującego Omnilogy spółka z ograniczoną odpowiedzialnością ​ z siedzibą w Warszawie na rzecz zamawiającego kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego i na rzecz wykonawcy Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego.
5. Kosztami postępowania w sprawie o sygn. akt KIO 1648/26 obciąża odwołującego: ​ Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie i:
6. 1zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (piętnaście tysięcy złotych zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania oraz 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika zamawiającego; 4.2zasądza od odwołującego Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie na rzecz zamawiającego kwotę ​ 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego.

Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga z​ a pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie - Sądu Zamówień Publicznych.

Przewodniczący

……………………………………………..............

Sygn. akt

KIO 1646/26

KIO 1648/26

Zakład Ubezpieczeń Społecznych z siedzibą w Warszawie (dalej: Zamawiający) prowadzi n​ a podstawie przepisów ustawy z 11 września 2019 r. Prawo zamówień publicznych postępowanie w trybie przetargu nieograniczonego pn.: „Zakup oprogramowania d​ o monitorowania aplikacji i infrastruktury Portalu PUE/eZUS wraz ze wsparciem”, Numer postępowania:

1. 271.149.2025-DZP (dalej: Postępowanie).

Ogłoszenie o zamówieniu zostało opublikowane 18 sierpnia 2025 r. w Dzienniku Urzędowym Unii Europejskiej, numer publikacji ogłoszenia: 535338-2025, numer wydania ​ z.U. S: 156/2025.

D KIO 1646/26 10 kwietnia 2026 r. wykonawca Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą ​ Warszawie (dalej: Odwołujący Omnilogy), wniósł odwołanie i zarzucił Zamawiającemu: w

1. art. 226 ust. 1 pkt 5 w zw. z art. 218 ust. 2 Pzp oraz w zw. z art. 66 § 1 KC w zw. ​ z art. 8 ust. 1 Pzp i w zw. z art. 239 ust. 1 Pzp przez zaniechanie odrzucenia oferty Linux i jej wybór jako najkorzystniejszej, mimo że jest ona niezgodna z warunkami zamówienia, w tym z wymaganiami Zamawiającego określonymi w dokumentach zamówienia odnoszącymi się do obowiązku identyfikacji oferowanego oprogramowania i jego producenta, ze względu na jej niejednoznaczność, ​ co uniemożliwia ustalenie rzeczywistej treści oferty Linux w istotnym jej elemencie, jakim jest określenie przedmiotu świadczenia (tj. jaki konkretnie produkt jakiego producenta został zaoferowany), a skonkretyzowanie przedmiotu oferty musiałoby nastąpić dopiero po upływie terminu składania ofert w drodze niedozwolonych negocjacji pomiędzy Zamawiającym a Linux, które na gruncie art. 223 ust. 1 Pzp byłyby niedopuszczalne;
2. art. 239 ust. 1 w zw. z art. 242 ust. 2 pkt 1 Pzp przez przyznanie Ofercie Linux 15 punktów w kryterium „Pozycja w Gartner ®Magic Quadrant™ Observbility na rok 2025”, podczas gdy produkt wskazany przez Linux w ofercie nie znajduje się w Gartner ®Magic Quadrant™ Observbility na rok 2025;
3. art. 226 ust. 1 pkt 5 Pzp przez zaniechanie odrzucenia oferty Linux z uwagi ​ na niezgodność treści oferty z warunkami zamówienia polegającą na zaoferowaniu produktu (rozwiązania) niespełniającego wymagań określonych w dokumentach zamówienia;
4. art. 226 ust. 1 pkt 12 w zw. z art. 220 ust. 3 - 5 i w zw. z art. 16 pkt 1) - 3) Pzp przez zaniechanie odrzucenia oferty wykonawcy Kyndryl, mimo że wykonawca ten nie wyraził skutecznie pisemnej zgody na przedłużenie terminu związania ofertą na okres wskazany przez Zamawiającego, tj. do 16 maja 2026 r., lecz wyłącznie do 30 kwietnia 2026 r., a więc na okres krótszy niż objęty wezwaniem Zamawiającego, w konsekwencji czego doszło do nierównego traktowania wykonawców w Postępowaniu, braku przejrzystości Postępowania i naruszenia zasady proporcjonalności, polegających ​ na zaakceptowaniu wobec wykonawcy Kyndryl krótszego okresu związania ofertą ​ i krótszego okresu zabezpieczenia wadialnego niż wymagany od pozostałych wykonawców, którzy złożyli oferty w Postępowaniu, podczas gdy pozostali wykonawcy przedłużyli termin związania ofertą oraz wadium zgodnie z wezwaniem Zamawiającego, tj. do 16 maja 2026 r.;
5. art. 226 ust. 1 pkt 14) w zw. z art. 220 ust. 5 i w zw. z art. 97 ust. 5 i 6 i w zw. z art. 16 pkt 1) -3) Pzp przez zaniechanie odrzucenia oferty wykonawcy Kyndryl, mimo ​ że Kyndryl nie przedłużył ważności wadium ani nie wniósł nowego wadium na pełny wymagany przez Zamawiającego przedłużony okres związania ofertą do 16 maja ​ 2026 r., ograniczając ochronę wadialną wyłącznie do 30 kwietnia 2026 r., a tym samym nie wykonał ustawowego warunku skutecznego przedłużenia terminu związania ofertą ​ i nie wniósł wadium/wniósł w sposób nieprawidłowy/nie utrzymywał wadium nieprzerwanie do upływu terminu związania ofertą, w konsekwencji czego doszło ​ do nierównego traktowania wykonawców w Postępowaniu, braku przejrzystości Postępowania i naruszenia zasady proporcjonalności, polegających ​ na zaakceptowaniu wobec wykonawcy Kyndryl krótszego okresu związania ofertą ​ i krótszego okresu zabezpieczenia wadialnego niż wymagany od pozostałych wykonawców, którzy złożyli oferty w Postępowaniu, podczas gdy pozostali wykonawcy przedłużyli termin związania ofertą oraz wadium zgodnie z wezwaniem Zamawiającego, tj. do 16 maja 2026 r.

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu:

1. unieważnienia czynności wyboru najkorzystniejszej oferty;
2. ponowienia czynności badania i oceny ofert;
3. odrzucenia oferty złożonej przez Linux oraz oferty złożonej przez Kyndryl;
4. powtórzenia czynności wyboru oferty najkorzystniejszej.

W uzasadnieniu zarzutów odwołania Odwołujący Omnilogy wskazał m.in.:

Zarzuty dotyczące oferty Linux

Zarzut 1

Zgodnie ze wzorem Formularza oferty (załącznik nr 1 do SW Z) wykonawcy zobowiązani byli (w pkt 4.1 pn. Formularz cenowy) określić przedmiot oferty, wskazując nazwę oferowanego oprogramowania i producenta oferowanego oprogramowania.

Dowód: - Wzór Formularza oferty - Załącznik nr 1 do SWZ – w dokumentacji Postępowania Jak wskazano powyżej w opisie staniu faktycznego, Linux złożył ofertę, w której oferowany przez siebie przedmiot określił w sposób następujący:

Oferta Linux dotyczy zatem oprogramowania określonego jako „Enterprise”, którego producent został skonkretyzowany jako „Elasticsearch”. Mając na uwadze powyższą treść oferty wykonawcy Linux Odwołujący wskazuje, że takie oznaczanie produktu nie pozwala na jego jednoznaczną identyfikację, a więc stanowi o braku skonkretyzowania przedmiotu świadczenia objętego ofertą. W zakresie wymagania wskazania producenta, należy zauważyć, że oznaczenie producenta jako „Elasticsearch” jest nieprawidłowe i​ wieloznaczne.

Powyższe wnika z tego, że „Elasticsearch” stanowi nazwę technologii (oprogramowania), a​ nie oznaczenie producenta. Wprawdzie wyrażenie „Elasticsearch” występuje w nazwach konkretnych spółek zależnych w grupie kapitałowej Elastic, np. Elasticsearch B.V., Elasticsearch Federal Inc., jednak podmiotem powszechnie identyfikowanym na rynku jako producent i dostawca komercyjnych rozwiązań opartych na technologii „Elasticsearch” j​ est spółka Elastic N.V. Poza tym posłużenie się nazwą „Elasticsearch” jako wskazaniem producenta prowadzi do niejednoznaczności, gdyż może odnosić się zarówno d​ o oprogramowania rozwijanego przez Elastic (choć nie wiadomo jakiego konkretnie – o​ czym poniżej), jak i do jego różnych implementacji lub dystrybucji tworzonych przez inne podmioty.

Stąd wskazanie producenta jako „Elasticsearch” nie pozwala na jednoznaczne ustalenie, jaki podmiot odpowiada za oferowane rozwiązanie, ani – o czym szerzej poniżej - jakie konkretnie oprogramowanie zostało zaoferowane.

W zakresie wymagania wskazania nazwy oprogramowania, należy z kolei zauważyć, ż​ e zawarte w ofercie Linux określenie „Enterprise” także nie prowadzi do identyfikacji (konkretnego) oferowanego produktu. Określenie „Enterprise” jest to bowiem jedynie nazwa poziomu subskrypcji lub wariantu licencyjnego. Ma ono charakter ogólny i funkcjonuje wyłącznie jako element szerszego oznaczenia produktu. Należy przy tym podkreślić, ż​ e nazwa „Enterprise” stosowana przez różnych producentów (np. Windows 11 Enterprise to edycja systemu operacyjnego firmy Microsoft). Użycie tego wyrażenia bez wskazania pełnej nazwy rozwiązania uniemożliwia ustalenie, jakie oprogramowanie zostało faktycznie zaoferowane.

W konsekwencji, przy tak oznaczonym przedmiocie oferty, jaki występuje w ofercie Linux, brak jest jakichkolwiek danych pozwalających ustalić, jakie dokładnie oprogramowanie zostało zaoferowane, w tym ustalenie jego funkcjonalności, modelu licencjonowania c​ zy zakresu wsparcia, itp., a więc także to, czy zaoferowano rozwiązanie zgodne z​ warunkami zamówienia. Powyższe prowadzi do konstatacji, że oferta Linux jest niejednoznaczna w zakresie określenia jej przedmiotu, a tym samym nie jest stanowczym oświadczeniem woli zaoferowania konkretnego przedmiotu świadczenia. Odwołujący podnosi więc, że wbrew wymaganiom dokumentów zamówienia, zgodnie z którymi wykonawcy mieli obowiązek wskazania producenta oferowanego oprogramowania o​ raz nazwę oferowanego oprogramowania, Linux nie dokonał w Formularzu ofertowym jednoznacznego oznaczenia w ofercie producenta i nazwy oprogramowania, t​ zn. nie skonkretyzował przedmiotu oferowanego świadczenia. Oznaczenie w ofercie Linux producenta jako „Elasticserch” i oprogramowania jako „Enterprise” nie identyfikuje jednoznacznie oferowanego rozwiązania i uzasadnia zarzut niezgodności treści oferty

​z wymaganiami identyfikacyjnymi.

Już tylko to przesądza o niegodności treści oferty Linux z warunkami zamówienia i stanowić powinno dla Zamawiającego podstawę do odrzucenia oferty Linux (art. 226 ust 1 pkt 5 Pzp). Zaniechanie odrzucenia tej oferty w opisanych okolicznościach faktycznych stanowi naruszenie Pzp. Podnieść należy, że złożenie oferty zgodnej z warunkami zamówienia oznacza złożenie oświadczenia woli o charakterze jednoznacznym, obejmującego zobowiązanie do wykonania skonkretyzowanego i możliwego do identyfikacji świadczenia.

Oferta jako podstawowy element postępowania o udzielenie zamówienia publicznego, musi umożliwiać zamawiającemu ustalenie jej rzeczywistej treści, w szczególności w zakresie oferowanego przedmiotu zamówienia.

Wymóg ten wynika zarówno z zasady przejrzystości i równego traktowania wykonawców (art. 16 Pzp), jak i z obowiązku jednoznacznego opisu oraz zgodności treści oferty z warunkami zamówienia. Nie można więc uznać, że doszło d​ o skutecznego złożenia jednej oferty w sytuacji, gdy z jej treści nie wynika, jakie konkretnie świadczenie wykonawca oferuje. Oferta, której elementy przedmiotowo istotne pozostają nieokreślone lub niejednoznaczne, nie pozwala bowiem na ustalenie zakresu zobowiązania wykonawcy, a tym samym nie może stanowić podstawy do jej oceny i porównania z innymi ofertami.

Zgodnie z art. 66 § 1 Kodeksu cywilnego (w zw. z art. 8 ust. 1 Pzp): „oświadczenie drugiej stronie woli zawarcia umowy stanowi ofertę, jeżeli określa istotne postanowienia tej umowy”.

Przedmiot świadczenia niewątpliwie stanowi istotne postanowienie przyszłej umowy – ​ szczególności, gdy zamawiający żąda podania w ofercie producenta i nazwy oferowanego produktu w (oprogramowania). Odwołujący podkreśla także, że okoliczności sprawy świadczą jednoznacznie, że nie można stwierdzić, jaki konkretny produkt został Zamawiającemu zaoferowany. Jednocześnie dookreślenie tego wymagałoby ustalenia przez Zamawiającego z Linux, jaka jest treść oferty w jej kluczowym elemencie, czyli co jest jej przedmiotem (jakie oprogramowanie jakiego producenta). Jednakże konkretyzacja w tym zakresie powinna nastąpić już na etapie składania ofert – w formularzu cenowym, a nie dopiero po upływie terminu składnia ofert. Jednocześnie konkretyzacja taka po upływie terminu składnia ofert prowadziłoby do niedozwolonych negocjacji pomiędzy Zamawiającym a Linux dotyczących złożonej oferty (co zostało zaoferowane – co dostarczyć Zamawiającemu) oraz musiałoby prowadzić do zmiany treści tej oferty – przez skonkretyzowanie jej treści w zakresie określenia producenta i nazwy oprogramowania.

Takie działania są zaś wprost zakazane przepisem art. 223 ust. 1 zdanie 2 Pzp, który stanowi: „W toku badania i oceny ofert zamawiający może żądać od wykonawców wyjaśnień dotyczących treści złożonych ofert oraz przedmiotowych środków dowodowych lub innych składanych dokumentów lub oświadczeń. Niedopuszczalne jest prowadzenie między zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty oraz, z uwzględnieniem ust. 2 i art. 187, dokonywanie jakiejkolwiek zmiany w jej treści”. W związku z powyższym ofertę wykonawcy Linux należy uznać za niezgodną z wymaganiami SW Z w zakresie dotyczącym obowiązku wskazania konkretnego oferowanego oprogramowania.

Jednocześnie brak jednoznacznego określenia przedmiotu świadczenia oznacza, że oferta nie spełnia wymogu stanowczości i kompletności oświadczenia woli, przez co nie może zostać uznana za skuteczną ofertę w rozumieniu Pzp i KC.

W związku z powyższym oferta Linux powinna zostać odrzucona na podstawie art. 226 ust. 1 pkt 5 w zw. z art. 218 ust. 2 Pzp oraz w zw. z art. 66 § 1 KC w zw. z art. 8 ust. 1 ustawy jako niezgodna z wymaganiami Zamawiającego określonymi w dokumentach zamówienia.

Zarzut 2

Jak wskazano wyżej, oferta Linux dotyczy oprogramowania określonego jako „Enterprise”, którego producent został wskazany jako „Elasticsearch”.

Tak oznaczony produkt, tak oznaczonego producenta, nie wstępuje w Gartner ®Magic Quadrant™ Observbility na rok 2025:

W raporcie Gartner Magic Quadrant for Observability Platforms 2025 oceniane jest rozwiązanie nazywane Elastic Observability: „Elastic został uznany za lidera w Gartner Magic Quadrant 2025 dla platform obserwacji po raz drugi z rzędu! Elastic ma zaszczyt ponownie zostać uznanym za Lidera w Gartner® Magic Quadrant™ 2025 dla platform obserwacji. The Magic Quadrant przeanalizował 20 dostawców pod kątem kryteriów oceny, aby pomóc przedsiębiorstwom w procesie selekcji. Elastic został uznany za lidera

​ze względu na zdolność realizacji i kompletność wizji zarówno w 2024, jak i 2025 roku”.

Wobec powyższego ofercie Linux nie powinno zostać przyznane żadne punkty w kryterium oceny ofert - „Pozycja w Gartner ®Magic Quadrant™ Observbility na rok 2025”.

Stąd zarzut naruszenia art. 239 ust. 1 w zw. z art. 242 ust. 2 pkt 1 Pzp jest w pełni zasadny.

Zarzut 3

Zgodnie z art. 226 ust. 1 pkt 5 Pzp zamawiający ma obwiązek odrzucić ofertę, której treść jest niezgodna z warunkami zamówienia. Warunki zamówienia należy rozumieć zgodnie z​ definicją wyrażoną w art. 7 pkt 29 Pzp, który stanowi, że przez warunki zamówienia n​ ależy rozumieć warunki, które dotyczą zamówienia lub postępowania o udzielenie zamówienia, wynikające w szczególności z opisu przedmiotu zamówienia, wymagań związanych z realizacją zamówienia, kryteriów oceny ofert, wymagań proceduralnych l​ ub projektowanych postanowień umowy w sprawie zamówienia publicznego. Linux nie skonkretyzował przedmiotu oferty, a zatem nie można na podstawie jej treści ustalić jakie konkretnie oprogramowanie oferta obejmie, jednakże zakładając, że zamiarem Linux było złożenie oferty na jakieś rozwiązanie rodziny Elastic, Odwołujący podnosi, że żadne z nich nie spełnia poniższych wymagań opisu przedmiotu zamówienia:

A.wymaganie 27.14. - prezentować drzewo wywołania kodu Java, .NET i PHP ​ w ramach ścieżki wykonania – do poziomu nazwy wywoływanej metody, zarówno ​ dla wątków wywoływanych synchronicznie jak i asynchronicznie. Zbliżona funkcjonalność realizowana jest w produktach Elastic, jednak ta aplikacja śledzi żądania http w ramach ścieżki wykonania end-to-end jako transakcje/spany ​ na poziomie framework'a programistycznego wyłącznie dla wybranych fragmentów drzewa (HTTP requests, bazy danych), ale nie daje wglądu w każde indywidualne wywołanie metody/klasy w drzewie wykonania kodu.

B.wymaganie 27.17. - umożliwiać prezentację wartości parametrów metody JAVA, .NET lub PHP, nagłówków http/s, parametrów zapytań http/s. Przechwytywanie nagłówków i parametrów zapytań http jest dostępne w produktach Elastic, jednak brak jest możliwości przechwytywania wartości parametrów metod. Aby uzyskać funkcjonalność zbliżoną do wymaganej Zamawiający (nie dostawca) musiałby wykonać zmiany w kodzie własnych aplikacji, ponosząc dodatkowy nakład finansowy przez zlecenie zewnętrznych prac programistycznych podmiotom odpowiedzialnym ​ za rozwój oprogramowania przeznaczonego do monitorowania.

C.wymaganie 27.19. - monitorować serwery webowe Apache, Nginx oraz IIS w zakresie wprowadzanych przez nie opóźnień w czasie realizacji transakcji webowej oraz błędów pojawiających się na tychże serwerach, a w szczególności monitoring musi pokazywać wpływ poszczególnych modułów działających na serwerach WWW ​ na czasy wykonania transakcji. Produkty Elastic mogą monitorować opóźnienia ​ na poziomie Apache/Nginx/IIS przez metryki oraz trace-y dla aplikacji działającej ​ za serwerem. Jednak wpływ poszczególnych modułów na czas transakcji nie jest automatycznie raportowany. Nawet zastosowanie Opentelemetry, które Zamawiający (nie dostawca) musiałby zaimplementować po stronie serwerów webowych nie udostępnia możliwości pokazywania wpływu poszczególnych modułów na czasy wykonywania transakcji.

D.wymaganie 27.23. - umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz ​ jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji, Produkty Elastic nie posiadają funkcjonalności zbierania szczegółowych informacji z pracy GC - typu dokładna alokacja pamięci, nie posiada również funkcjonalności zrzutu danych z alokacji pamięci, w szczególności nie zatrzymując procesu JVM.

E.wymaganie 27.35. - umożliwiać monitoring połączeń między poszczególnymi serwerami i udostępniać mapę połączeń w formie graficznej. W przypadku wykrycia anomalii skutkującej wygenerowaniem alertu serwer musi zostać oznaczony ​ na wizualizacji w sposób jednoznacznie wskazujący na wystąpienie problemu. ​ W produktach Elastic wizualizacja powiązań między usługami możliwa jest dzięki funkcji Service Map, jednak brak możliwości wizualizacji połączeń pomiędzy elementami infrastrukturalnymi. Implementacja wizualizacji połączeń przez dobudowane przez Dostawcę funkcjonalności wymagałaby dostarczenie przez Zamawiającego do platformy danych z ruchu sieciowego, co nie jest przedmiotem Postępowania.

F.wymaganie 27.36. - umożliwiać monitoring połączeń między poszczególnymi procesami uruchomionymi na

serwerach objętych monitoringiem i udostępniać mapę połączeń w formie graficznej. W przypadku wykrycia anomalii skutkującej wygenerowaniem alertu proces musi zostać oznaczony na wizualizacji w sposób jednoznacznie wskazujący na wystąpienie problemu, W produktach Elastic wizualizacja powiązań między usługami możliwa jest dzięki funkcji Service Map, jednak brak możliwości wizualizacji połączeń pomiędzy procesami uruchomionymi ​ na serwerach, w szczególności gdy komunikacja między procesami następuje ​ w ramach tego samego serwera.

G.wymaganie 27.44. - w przypadku wykrycia problemu system musi automatycznie wskazać najbardziej prawdopodobną przyczynę ̨ wystąpienia problemu. Produkty Elastic nie wykrywają przyczyny problemu, a bazują na mechanizmie korelacji czasowej usług i elementów, na których coś się dzieje: https://www.elastic.co/docs/solutions/observability/apm/findtransaction-latency-failure-correlations.

W przypadku zastosowania dodatkowych (nie będących częścią oferty Elastic) silników analizujących opartych jedynie o duże model językowe, zakres danych oraz oparcie ​o korelację czasową zdarzeń skutkuje zjawiskiem halucynacji przy potencjalnym wnioskowaniu o najbardziej prawdopodobnej przyczynie problemu.

H.wymaganie 27.56. - wykrywanie podatności nie może wymagać instalowania dodatkowego oprogramowania, poza tym, które wchodzi w skład platformy ​ do monitorowania. Zgodnie z dokumentacją w produktach Elastic podatności mogą być zbierane dwojako albo przez zewnętrzne integracje z programami trzecimi, ​ albo przez CloudNativeVulnerabilityManagement w skrócie CNVM. Oznacza ​ to ograniczone wsparcie wyłącznie dla jednego typu usługi chmury publicznej AW S nie spełniając wymagania Zamawiającego.

I.wymaganie 27.58. - dla wykrytych podatności klasyfikować je wg CVSS wraz ​ z uwzględnieniem informacji o ekspozycji na atak z publicznego internetu oraz dostępu do danych; W produktach Elastic CNVM wskazuje wektor ataku, ale nie wskazuje ​ czy dane są narażone na dostęp z publicznego internetu i czy zasoby są wystawione ​ na zewnątrz i są podatne na atak z publiczego internetu. Oznacza to ograniczone wsparcie wyłącznie dla jednego typu usługi chmury publicznej AWS nie spełniając wymagania Zamawiającego.

J.wymaganie 27.69. - zapewniać monitorowanie pracy użytkownika końcowego (user experience) bez konieczności instalacji dodatkowych komponentów po stronie użytkownika i wykonywania zmian konfiguracji, serwerów W W W lub aplikacyjnych; zmiana konfiguracji czy też włączenie/wyłączenie monitorowania zachowań użytkownika musi odbywać się z konsoli narzędzia, bez potrzeby restartu serwerów monitorowanego środowiska. W produktach Elastic monitorowanie pracy użytkownika końcowego wymaga przekonfigurowania niektórych elementów wraz z restartem. Odwołujący wskazuje, że spełnienie wymagania w zakresie ww. funkcjonalności ​ w Elastic wymaga zbudowania ponownie aplikacji lub modyfikacji w kodzie HTML.

K.wymaganie 27.71. - umożliwiać dostarczanie informacji nt. charakteru każdej interakcji ​ w systemie dla każdego pojedynczego użytkownika ze wskazaniem tzw. landing pages, bounces, wpływ „third party” czy ładowania asynchroniczne AJAX. Produkty Elastic zbierają i analizują tylko część z wymaganych informacji, brak np. bounces.

Mając na uwadze powyższe nie ulega wątpliwości, że oferta Linux powinna podlegać odrzuceniu na podstawie art. 226 ust. 1 pkt 5 Pzp.

Zarzuty dotyczące oferty wykonawcy Kyndryl

Zarzut 4

Uwzględniając zmiany dokumentów zamówienia, finalny termin składania ofert został ustalony na 18 grudnia 2025 r. na g.

12:00. Mając na względzie powyższe, pierwotny termin związania ofertą upływał z dniem 17 marca 2026 r.

Dowód: -Informacja o zmianie terminu składania i otwarcia ofert praz terminu związania ofertą ​ z 02 grudnia 2025 r. (plik pn. „odpowiedzi_na_pytania zest V.pdf”. – w dokumentacji Postępowania -Ogłoszenie o zmianie ogłoszenia o zamówieniu nr 803861-2025 – w dokumentacji Postępowania Jednocześnie, zgodnie z pkt 3.1. SW Z wykonawca składający ofertę w Postępowaniu zobowiązany był wnieść wadium w wysokości 200 000,00 zł i utrzymywać je nieprzerwanie d​ o upływu terminu związania ofertą (por. pkt 3.3.1. SW Z). Niewniesienie wadium, wniesienie w sposób nieprawidłowy, nieutrzymywanie wadium nieprzerwanie do upływu terminu związania ofertą lub złożenie wniosku o zwrot wadium w przypadku, o którym mowa

​w pkt 3.4.2.3 SW Z, skutkować miało odrzuceniem oferty Wykonawcy (pkt 3.3.8. SW Z). Jednocześnie za przepisem art.

97 ust. 6 Pzp, Zamawiający wskazał w pkt 3.3.9. SWZ, ż​ e „Przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą”.

W Postępowaniu oferty złożyło trzech wykonawców: -Odwołujący Omnilogy, który wniósł wadium w formie gwarancji bankowej ważnej ​ do 17 marca 2026 r. -Wykonawca Linux, który wniósł wadium w formie pieniężnej (potwierdzenie przelewu ​ z 16 grudnia 2025 r. załączono do oferty) -Wykonawca Kyndryl, który wniósł wadium w formie gwarancji bankowej ​ nr DOK5160GWB25SS z 6 listopada 2025 r. ważnej do 30 kwietnia 2026 r.

Dowód: gwarancje wadialne Omnilogy i Kyndryl i potwierdzenie wniesienia wadium w formie pieniężnej przez Linux – w dokumentacji Postępowania Pismem z 13 marca 2026 r. Zamawiający zwrócił się do wykonawców, którzy złożyli ​ Postępowaniu oferty, z wnioskiem o przedłużenie terminu związania ofertą oraz okresu ważności wadium, wskazując w w ww. piśmie: „Zamawiający, stosownie do postanowień a​ rt. 220 ust. 3 ustawy Prawo zamówień publicznych (t.j. Dz. U. 2024 r. poz. 1320 ze zm.)., dalej „ustawa Pzp”, zwraca się z prośbą o wyrażenie zgody na przedłużenie terminu związania ofertą o 60 dni tj. do 16 maja 2026 r.

Obecny termin związania ofertą upływa 17 marca 2026 r.

Przedłużenie terminu związania ofertą, wymaga złożenia przez Wykonawcę pisemnego oświadczenia o wyrażeniu zgody na przedłużenie terminu związania ofertą. Przekazanie zgody na przedłużenie terminu związania ofertą, podpisane przez osobę uprawnioną d​ o reprezentowania Wykonawcy, winno nastąpić do upływu obecnego terminu związania ofertą, tj. do 17 marca 2026 r., z uwzględnieniem postanowień pkt. 1.5. specyfikacji warunków zamówienia w przedmiotowym postępowaniu (dalej:

„SWZ”).

Zgodnie z art. 220 ust. 5 Pzp przedłużenie terminu związania ofertą dopuszczalne jest tylko wraz z przedłużeniem okresu ważności wadium, albo jeżeli nie jest to możliwe z wniesieniem nowego wadium na przedłużony okres związania ofertą.

Przedłużenie okresu ważności wadium lub wniesienie nowego wadium, obejmującego wydłużony termin związania ofertą, w kwocie 200 000,00 zł w jednej z form wskazanych ​ pkt. 3.2. SW Z, winno nastąpić zgodnie z wymogami określonymi w pkt. 3.3. SW Z, do upływu obecnego terminu w związania ofertą, tj. do 17 marca 2026 r.”.

Dowód: wezwanie do przedłużenia terminu związania ofertą oraz okresu ważności wadium z​ 13 marca 2026 r. – w dokumentacji Postępowania W odpowiedzi na ww. wezwanie wykonawca Omnilogy złożył 16 marca 2026 r. oświadczenie o wyrażeniu zgody na przedłużenie terminu związania ofertą o 60 dni, tj. do 16 maja 2026 r., załączając jednocześnie do ww. oświadczenia aneks do gwarancji wadialnej złożonej wraz z​ ofertą, przedłużający ważność wadium do 16 maja 2026 r. (ANEKS NR 5 DO GWARANCJI BANKOW EJ NR DOK4280GWB25MV z 16 września 2025 r.)

Dowód: pismo Omnilogy z 16 marca 2026 r. w sprawie przedłużenia terminu związania ofertą i wadium – w dokumentacji Postępowania Odpowiedzi na ww. wezwanie udzielił również Wykonawca Linux, który 13 marca 206 r. z​ łożył oświadczenie o wyrażeniu zgody na przedłużenie terminu związania ofertą o 60 dni, t​ j. do 16 maja 2026 r. i jednocześnie potwierdził przedłużenie okresu ważności wadium ​ kwocie 200.000,00 zł do 16 maja 2026 r. w Dowód: pismo Linux z 13 marca 2026 r. w sprawie przedłużenia terminu związania ofertą i​ wadium – w dokumentacji Postępowania Z kolei Wykonawca Kyndryl 16 marca 2026 r. przekazał Zamawiającemu pismo o następującej treści: „W odpowiedzi na Państwa pismo z 13 marca 2026 roku, zawierające prośbę

​o wyrażenie zgody na przedłużenie terminu związania ofertą o 60 dni tj. do 16 maja 2​ 026 r. uprzejmie informuję, że wyrażamy zgodę na przedłużenie ważności naszej oferty d​ o 30 kwietnia 2026 roku tj. do końca okresu ważności aktualnego wadium. Na przedłużenie terminu wadium w formie aneksu do gwarancji bankowej potrzebne nam jest około 14 dni. ​W tym czasie zostanie do Państwa dostarczone nowe wadium z terminem ważności 16 maja 2026 roku oraz zgoda na przedłużenie ważności oferty na ten okres”.

Dowód: pismo Kyndryl z 16 marca 2026 r. w sprawie przedłużenia terminu związania ofertą d​ o 30 kwietnia 2026 r. – w dokumentacji Postępowania 31 marca 2026 r. Zamawiający dokonał wyboru jako najkorzystniejszej oferty wykonawcy Linux, wskazując w pkt III Informacji o wyborze oferty najkorzystniejszej, że: „Zamawiający informuje, że w przedmiotowym postępowaniu nie dokonał odrzucenia oferty”.

Mając na względzie powyższe, Odwołujący wskazuje, że w jego ocenie czynność badania i​ oceny ofert została dokonana wadliwie, a Zamawiający bezzasadnie zaniechał odrzucenia oferty wykonawcy Kyndryl na podstawie art. 226 ust. 1 pkt 12 Pzp, jak również art. 226 ust. 1 pkt 14 Pzp. Zgodnie z treścią Pzp w przypadku, gdy wybór najkorzystniejszej oferty nie nastąpi przed upływem terminu związania ofertą, zamawiający przed upływem terminu związania ofertą, zwraca się jednokrotnie do wykonawców o wyrażenie zgody n​ a przedłużenie tego terminu o wskazywany przez niego okres, nie dłuższy niż 60 dni. Przedłużenie terminu związania ofertą wymaga złożenia przez wykonawcę pisemnego oświadczenia o wyrażeniu zgody na przedłużenie terminu związania ofertą. Jednocześnie a​ rt. 220 ust. 5 Pzp stanowi, że „W przypadku, gdy zamawiający żąda wniesienia ​ adium, przedłużenie terminu związania ofertą, o którym mowa w ust. 2, następuje wraz w z​ przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą”, co koresponduje z art. 97 ust. 5 i 6 Pzp, wedle których:

-wadium wnosi się przed upływem terminu składania ofert i utrzymuje nieprzerwanie ​

do upływu terminu związania ofertą,

-przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą,

-Mając na względzie powyższe regulacje, do skutecznego, tj. zgodnego z przepisami Pzp, przedłużenia terminu związania ofertą konieczne jest kumulatywne spełnienie kilku wymogów: a)po pierwsze wykonawca zobowiązany jest złożyć oświadczenie woli ​ w przedmiocie zgody na przedłużeniu terminu związania ofertą o wskazany przez Zamawiającego okres (co wynika wprost z art. 220 ust. 3 Pzp), b)po drugie, oświadczenie to powinno być z zachowaniem właściwej formy, ​ a więc pisemnie (przy czym pisemność powinna być rozumiana przez pryzmat definicji legalnej z art. 7 pkt 16 Pzp) i przez osobę do tego uprawnioną, c)po trzecie, oświadczenie w przedmiocie zgody na przedłużenie terminu związania ofertą o wskazany przez Zamawiającego okres musi być złożone przed upływem pierwotnego terminu związania ofertą, -po czwarte, w przypadku, gdy zamawiający wymagał zabezpieczenia oferty wadium, przedłużenie terminu związania ofertą musi nastąpić z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą.

Brak któregokolwiek z tych elementów oznacza brak skutecznej zgody w rozumieniu Pzp, skutkujący ziszczeniem się przesłanki odrzucenia oferty wskazanej w art. 226 ust. 1 pkt 12 Pzp. Przepis ten nie może być przy tym rozumiany stricte formalistycznie jako regulacja wymagająca „jakiegokolwiek pisma z jakąkolwiek zgodą”. Taka interpretacja niweczyłaby sens art. 220 ust. 3 Pzp.

Wyrażona przez Kyndryl zgoda na przedłużenie terminu związania ofertą nie objęła pełnego okresu wskazanego we wniosku Zamawiającego. Wykonawca Kyndryl oświadczył bowiem, ż​ e wyraża zgodę na przedłużenie terminu związania ofertą jedynie do 30 kwietnia 2026 r., nie zaś do 16 maja 2026 r., o co wnioskował Zamawiający. Jednocześnie - mimo, że Zamawiający wymagał w postępowaniu zabezpieczenia oferty wadium, przedłużenie terminu związania ofertą nie nastąpiło o wymagany przez Zamawiającego okres z jednoczesnym przedłużeniem na ten okres albo – jeżeli nie jest to możliwe, z wniesieniem na ten przedłużony okres związania ofertą nowego wadium na przedłużony okres związania ofertą, zgodnie z żądaniem Zamawiającego. Skoro więc zgoda nie została wyrażona skutecznie, ziściła się przesłanka odrzucenia oferty, o której mowa w art. 226 ust. 1 pkt 12 Pzp.

Prawidłowość i skuteczność wezwania do przedłużenia terminu związania oferta i wadium Nie ulega jednocześnie wątpliwości, że wniosek Zamawiającego o przedłużenie terminu związania ofertą i przedłużenie/wniesienie nowego wadium odpowiadał dyspozycji art. 220 u​ st. 3 i 4 Pzp. Okres wskazany w żądaniu wynosił 60 dni, a więc tyle, ile maksymalnie dopuszcza przepis. Skoro wezwanie Zamawiającego było w pełni skuteczne i zgodne z​ prawem, to zgoda wyrażona na inny okres przedłużenia terminu związania ofertą n​ iż wynikający z wniosku o wyrażenie zgody wystosowanego przez Zamawiającego, nie może być w żadnym razie poczytana jako skuteczne i zgodne z przepisami Pzp przedłużenie terminu związania ofertą.

Zamawiający zwraca się o wyrażenie zgody na przedłużenie terminu związania ofertą o​ określony w wezwaniu okres. Przepis art. 220 ust. 3 Pzp nie stanowi o zwróceniu s​ ię o wyrażenie „ogólnej zgody” na przedłużenie terminu związania ofertą. Jednocześnie prawo i obowiązek określenia tego okresu przedłużenia spoczywa tylko na zamawiającym. ​To zamawiający ustala arbitralnie długość przedłużenia i jest w tym zakresie ograniczony jedynie 60-dniowym okresem wynikającym z art. 220 ust. 3 Pzp. W sytuacji więc, g​ dy Zamawiający, wypełniając dyspozycję przepisu art. 220 ust. 3 Pzp, zażąda wyrażenia zgody na przedłużenie terminu związania oferta o okres 60 dni (tu: do 16 maja 2026 r.), t​ o wykonawca, aby nie narazić się na sankcję określoną w art. 226 ust. 1 pkt 12) Pzp, zobowiązany jest do wyrażenia ww. zgody na przedłużenie terminu związania ofertą właśnie o ten konkretny, sprecyzowany w żądaniu Zamawiającego, okres.

Wykonawca nie został uprawniony do wyrażenia „jakiejkolwiek”, czy „ogólnej” zgody n​ a przedłużenie terminu związania ofertą, ale jego oświadczenie o zgodzie na przedłużenie terminu musi być zgodne z żądaniem Zamawiającego w zakresie wymaganego terminu przedłużenia terminu związania ofertą. Co należy podkreślić, przepisy nie przyznają wykonawcom prawa do samodzielnego decydowania o okresie przedłużenia terminu związania ofertą. Wykonawca nie może dowolnie modyfikować i skracać tego okresu, ustalając sobie samowolnie zależny tylko od niego „harmonogram przedłużeń”. Powyższe chroni przejrzystość postępowania. Inaczej każdy wykonawca mógłby jednostronnie kształtować sobie własny okres związania ofertą, co niweczyłoby sens jednokrotnego wezwania i​ jednolitych warunków postępowania dla wszystkich wykonawców ubiegających się o dane zamówienie. Powyższe jest zresztą logiczne, bowiem okres związania ofertą stanowi uciążliwość dla wykonawcy. Wykonawca w okresie tym musi, nie zaś może, zawrzeć umowę z zamawiającym. Powyższe ma szczególne znaczenie w sytuacji, gdy Zamawiający, tak jak t​ o miało miejsce w niniejszym Postępowaniu, żąda zabezpieczenia oferty wadium, które ulega przepadkowi, w przypadku, gdy wykonawca uchyla się od zawarcia umowy z zamawiającym, bądź gdy wykonawca nie wnosi zabezpieczenia należytego wykonania umowy (które ​ ramach niniejszego Postępowania było wymagane – vide: pkt 8 SWZ). Upływ terminu związania ofertą i skorelowanego w z nim obowiązku utrzymywania zabezpieczenia wadialnego powoduje więc, że wykonawca nie ma obowiązku zawarcia umowy, a co za tym idzie - nie ponosi negatywnych konsekwencji odmowy jej zawarcia. Co należy podkreślić, w okresie związania ofertą zabezpieczoną wadium zamawiający ma realnie najsilniejsze instrumenty wobec wykonawcy: może przyjąć ofertę przez jej wybór, oczekiwać zawarcia umowy n​ a warunkach wskazanych w ofercie, a w razie odmowy lub uchylania się – przy spełnieniu ustawowych przesłanek – zatrzymać wadium oraz przejść do trybu z art. 263 Pzp. Celem zachowania tych uprawnień i zabezpieczenia swoich interesów, Zamawiający może jeden r​ az wystąpić o wyrażenie zgody na przedłużenie terminu związania ofertą o wskazany wprost w wezwaniu, nie dłuższy niż 60 dni, okres. Tym samym ustawodawca przyznał Zamawiającemu jednokrotne i ściśle ograniczone czasowo uprawnienie do zagwarantowania sobie możliwości skorzystania z ww. instrumentów. W przypadku braku zabezpieczenia przez wykonawcę możliwości skorzystania przez Zamawiającego z ww. instrumentów, oferta wykonawcy podlega odrzuceniu (art. 226 ust. 1 pkt 12) i 14) Pzp). Tym samym wykonawca, który nie godzi na ww. uciążliwość, musi liczyć się ze skutkiem w postaci odrzucenia oferty. Dopiero w sytuacji, gdy termin związania ofertą – w przypadku jego przedłużenia w trybie a​ rt. 220 ust. 3 i 4 Pzp – przedłużony termin związania ofertą, upłynął przed wyborem oferty najkorzystniejszej, zamawiający zobowiązany jest wezwać wykonawcę, którego oferta otrzymała najwyższą ocenę, do wyrażenia, w wyznaczonym przez zamawiającego terminie, pisemnej zgody na wybór jego oferty (art. 252 ust. 2 Pzp). W terminie związania ofertą (również przedłużonym), wykonawca jest nią więc po prostu związany, a zamawiający przez wybór przyjmuje ofertę, co obliguje wykonawcę do zawarcia umowy na warunkach w niej wskazanych i naraża go na ryzyko

utraty wadium, w przypadku uchylania się od zawarcia ww. umowy, bądź niewniesienia zabezpieczenia należytego jej wykonania. Po upływie terminu związania ofertą z kolei - instrumentarium zamawiającego prowadzące do zawarcia umowy ogranicza s​ ię jedynie do „zapytania” wykonawcy, czy zgodzi się, by wybrać jego ofertę, mimo, że nie jest on już nią związany.

Wykonawca może przy tym takiej zgody odmówić bez żadnych konsekwencji, w szczególności zaś nie jest w takiej sytuacji narażony na zatrzymanie wadium. Biorąc pod uwagę powyższe, mylne byłoby więc twierdzenie, że wyrażenie zgody n​ a przedłużenie terminu związania ofertą na okres krótszy niż wskazany we wniosku Zamawiającego nie ma realnego znaczenia dla losów postępowania, ponieważ zamawiający może wybrać ofertę takiego wykonawcy nawet w sytuacji, gdy ten nie jest już nią związany i​ wyrazi na to zgodę. Powyższe rozumowanie należy uznać za błędne, gdyż pomija o​ no kluczowy fakt, że, jeżeli wykonawca chce brać udział w postępowaniu, to – w przypadku skorzystania przez Zamawiającego z dyspozycji art. 220 ust. 3 - 5 Pzp, jest zobowiązany, p​ od rygorem odrzucenia, do wyrażenia zgody na przedłużenie terminu związania ofertą i​ wadium, o wskazany przez Zamawiającego okres, pod rygorem odrzucenia. Wykonawca uzyskuje prawo do wyrażania lub nie zgody na wybór jego oferty dopiero wówczas, gdy termin związania ofertą upłynął przed wyborem najkorzystniejszej oferty. Oczywistym jest przy tym, że nie chodzi tu o upływ terminu związania ofertą z jakiejkolwiek przyczyny, a w szczególności leżącej po stronie wykonawcy. Ustawodawca określił bowiem w ustawie Pzp skutki niewyrażenia zgody na przedłużenie terminu związania ofertą, wskazując, że konsekwencją takiej sytuacji jest odrzucenie oferty wykonawcy.

Zastosowanie tego przepisu byłoby zdaniem Odwołującego niedopuszczalne w odniesieniu d​ o wykonawcy, który wyraził zgodę na przedłużenie terminu związania ofertą, jednak na okres krótszy niż żądany przez Zamawiającego w trybie art. 220 ust. 3 Pzp, bowiem oferta takiego wykonawcy powinna w takim przypadku podlegać odrzuceniu, skutkiem czego nie mogłaby ona otrzymać najwyższej oceny w rozumieniu przepisu art. 252 ust. 2 Pzp.

Obowiązek zamawiającego odrzucenia oferty wykonawcy w sytuacji, w której na jego wezwanie do przedłużenia terminu związania ofertą, wykonawca takiej zgody skutecznie n​ ie wyrazi zachodzi więc nie tylko w przypadku całkowitego braku takiej zgody, ale również ​ przypadku złożenia oświadczenia o wyrażeniu zgody, jednak na warunkach innych niż narzucone wprost przez w zamawiającego w wezwaniu. Przepis art. 220 ust. 3 Pzp nie stanowi bowiem o wyrażeniu zgody „co do zasady”, ale zgoda ma korelować i być odpowiedzią n​ a żądanie Zamawiającego o ściśle określonej treści. Tą treścią jest wskazanie okresu, na jaki terminu związania ofertą ma być przedłużony. Jeżeli wykonawca nie akceptuje w pełni żądania Zamawiającego, to nie można mówić, że wyraził on „zgodę” na jego wniosek. Każda modyfikacja oświadczenia wykonawcy składanego w odpowiedzi na wezwanie wystosowane w trybie art. 220 ust. 3 Pzp względem żądania Zamawiającego stanowi więc o niezgodności z​ tym żądaniem, podlegając prostej kwalifikacji jako niewyrażenie zgody. Odpowiedź Kyndryl można również zakwalifikować jako odmowę wykonania wezwania w pełnym zakresie ​ zakreślonym terminie, połączoną z zapowiedzią przyszłego, niepewnego i warunkowego dopełnienia, a więc jako brak w skutecznego przystąpienia do reżimu przedłużonego związania ofertą przewidzianego przez ustawę Pzp. Złożone przez Kyndryl oświadczenie odnoszące s​ ię do przedłużenia terminu związania ofertą nie stanowi więc „zgody” przedłużającej termin związania ofertą zgodnie z żądaniem Zamawiającego i jest nieskuteczne.

W niniejszym Postępowaniu Zamawiający zwrócił się o wyrażenie zgody na wydłużenie terminu związania ofertą i wadium do 16 maja 2026 r. do wszystkich trzech wykonawców, którzy złożyli oferty. Odwołujący i wykonawca Linux wyrazili zgodę na przedłużenie terminu związania ofertą w pełni zgodną z żądaniem Zamawiającego, tj. do 16 maja 2026 r., przedłużając równocześnie do tego dnia termin wadium. Wykonawcy Ci nie tylko podtrzymali więc swoją ofertą, ale też ponieśli ekonomiczny ciężar przedłużenia wadium na wymagany przez Zamawiającego okres. Mimo, że skierowane wezwanie o wyrażenie zgody n​ a przedłużenie terminu związania ofertą i wadium do 16 maja 2026 r. jednakowo dotyczyło wszystkich wykonawców, to Kyndryl jako jedyny nie sprostał mu. Kyndryl oświadczył bowiem wprost, że przedłuża termin związania ofertą nie do 16 maja 2026 r., ale jedynie d​ o 30 kwietnia 2026 r. Literalna treść oświadczenia i okoliczności jego złożenia wskazują p​ rzy tym na świadome ograniczenie terminu do okresu aktualnego wadium. Kyndryl przed upływem terminu związania

ofertą, nie wniósł również wadium na przedłożony termin związania ofertą wymagany przez Zamawiającego, gdyż z jego oświadczenia wynika jasno, że utrzymuje on wadium jedynie do 30 kwietnia 2026 r., podczas, gdy wadium miało zabezpieczać ofertę przez cały wymagany przez Zamawiającego przedłużony termin związania ofertą, który upływać miał dla każdego wykonawcy 16 maja 2026 r. Mimo tego, ż​ e ustawa Pzp zakazuje nierównego traktowania wykonawców w takiej samej sytuacji, Zamawiający wprost naruszył ww. zasadę. Nie ulega wątpliwości, że z założenia ustawodawca dąży do sytuacji, w której to postępowanie o udzielenie zamówienia publicznego jest transparentne i równe dla wszystkich ubiegających o jego udzielenie. Stąd sytuacja, w której to jeden z ubiegających się o udzielenie zamówienia publicznego, na skutek własnych, niezgodnych z Pzp decyzji, miałby bardziej uprzywilejowaną sytuację od konkurentów startujących w tym samym postępowaniu jest zdaniem Odwołującego absolutnie niedopuszczalna. Pozostali wykonawcy ponieśli koszt pełnego wydłużenia terminu związania ofertą i wadium do 16 maja 2026 r., zaś wykonawca Kyndryl tego zaniechał. Utrzymanie jego oferty w postępowaniu mimo to, prowadzi do nierównego traktowania wykonawców. Dopuszczenie Kyndryl do dalszego udziału w postępowaniu, mimo niewyrażenia zgody n​ a przedłużenie terminu związania oferta i wadium zgodnie z żądaniem Zamawiającego, faworyzuje go ekonomicznie i organizacyjnie. Krótszy okres związania ofertą oznacza bowiem mniejsze ryzyko i niższe koszty utrzymania wadium.

Jeżeli wezwanie zamawiającego jest jednolite, to także odpowiedzi wykonawców muszą być oceniane według jednolitych kryteriów. Zaakceptowanie tego rozwiązania narusza więc wprost art. 16 pkt 1 i 3 Pzp, ponieważ Zamawiający wbrew regulacjom Pzp traktuje wykonawców nierówno i akceptuje sytuację, ​ której wykonawcy nie są obciążeni w taki sam sposób. w Niezależnie od powyższego należy wskazać, że ustawa Pzp, przeciwnie do Pzp z 2004 r., n​ ie przewiduje możliwości samodzielnego wydłużenia terminu związania ofertą przez wykonawcę. Co więcej, w orzecznictwie wskazuje się wprost, że takie przedłużenie, jako nieprzewidziane w ustawie Pzp, jest nieskuteczne. Gdyby więc wykonawca Kyndryl na etapie po złożeniu oświadczenia o wyrażeniu zgody na przedłużenie terminu składania ofert i wadium jedynie do 30 kwietnia 2026 r., próbował przekazać Zamawiającemu kolejne oświadczenie przedłużające termin i wadium do 16 maja 2026 r., to nie sposób poczytać takiego oświadczenia inaczej niż samodzielne przedłużenie terminu związania ofertą i wadium, którego regulacje Pzp nie przewidują. Uprawnienie do wyrażenia zgody na przedłużenie terminu związania ofertą o okres wskazany przez Zamawiającego może być bowiem zrealizowane jedynie przed upływem pierwotnego terminu związania ofertą. W konsekwencji powyższego, jedynie złożone przed upływem pierwotnego terminu związania ofertą oświadczenie w przedmiocie wyrażenia zgody, o której mowa w art. 220 ust. 3 Pzp, może być uznane za zgodę w rozumieniu tego przepisu. Potencjalne kolejne oświadczenia ​ przedmiocie dalszego przedłużenia terminu składania ofert (i wadium), nie byłoby więc zgodą na żądanie w Zamawiającego wystosowane na podstawie art. 220 ust. 3 i 4 Pzp, a​ le samodzielnym, nieprzewidzianym w ustawie Pzp działaniem wykonawcy Kyndryl, które cechowałaby bezskuteczność.

Podsumowując, zdaniem Odwołującego oferta Kyndryl powinna podlegać odrzuceniu n​ a podstawie w zw. z art. 220 ust. 3 -5 Pzp z uwagi na brak wyrażenia zgody na przedłużenia terminu związania ofertą o wymagany przez Zamawiającego okres.

Zarzut 5

Jednocześnie, zgodnie z art. 220 ust. 5 Pzp przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo jeżeli nie jest to możliwie, z wniesieniem nowego wadium na przedłużony okres związania ofertą. Powyższy przepis konstruuje więc ustawowy warunek skutecznego przedłużenia terminu związania ofertą w postępowaniach, w których zamawiający żądają zabezpieczenia wadialnego. Wykonawca Kyndryl w oświadczeniu w przedmiocie przedłużenia terminu związania ofertą i wadium z 16 marca 2026 r. wprost przyznał, że jego gwarancja wadialna obowiązuje jedynie do 30 kwietnia 2026 r. i dlatego tylko do tej daty „przedłuża” termin związania ofertą. Innymi słowy, wykonawca Kyndryl sam potwierdził, że na moment odpowiedzi na wezwanie nie dysponuje wadium na okres, do którego zabezpieczenia o​ ferty wadium Zamawiający żądał w wezwaniu wystosowanym w trybie art. 220 ust. 3 Pzp, t​ j. do 16 maja 2026 r. Tym samym wykonawca Kyndryl nie spełnił wymogu z art. 220 ust. 5 Pzp. Jednocześnie Kyndryl naruszył dyspozycję przepisu art. 97 ust. 6 Pzp, która wskazuje wprost, że przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą. Art. 97 ust. 5 Pzp określa z kolei cezurę czasową

dla utrzymania wadium, co w praktyce oznacza, że gwarancja wadialna powinna zachowywać ważność do końca terminu związania ofertą – w przypadku żądania jego przedłużania – do przedłużonego terminu związania ofertą.

Skuteczne przedłużenie terminu związania ofertą, tj. zgodnie z żądaniem Zamawiającego, wymagało wydłużenia terminu związania ofertą do 16 maja 2026 r. i wniesienia na ten okres nowego wadium, lub przedłużenia obecnego. Wykonawca ma przy tym obowiązek wniesienia wadium się przed upływem terminu składania ofert i utrzymywania go nieprzerwanie do upływu terminu związania ofertą. Przedłużenie terminu związania ofertą jest dopuszczalne tylko z​ jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z​ wniesieniem nowego wadium na przedłużony okres związania ofertą. W obliczu oświadczenia wykonawcy Kyndryl złożonego na wezwanie w trybie art. 220 ust. 3 Pzp, nie sposób uznać, że Kyndryl przedłużył termin związania ofertą do 16 maja 2026 r., jak również przedłużył/wniósł nowe wadium zabezpieczające ofertę do tej daty włącznie. Nie ulega wątpliwości, że wadium musi być wniesione od razu na cały okres związania ofertą/przedłużonego terminu związania ofertą. Nie jest możliwe przyjęcie, że zawarty ​ przepisie wymóg jego nieprzerwanego utrzymywania byłby zachowany także wówczas, gdyby wadium wniesiono w początkowo na część przedłużonego okresu związania ofertą, a​ przed jego upływem przedłużono aż do końca tego przedłużonego terminu, jak chciałby tego wykonawca Kyndryl, biorąc pod uwagę treść jego oświadczenia woli z 16 marca 2026 r. Taka interpretacja przepisu jest zdaniem Odwołującego błędna – ponieważ istotą wadium jest zabezpieczenie zobowiązania wynikającego z oferty. Ustawodawca przedłużanie terminu związania ofertą wiąże z obowiązkiem przedłużenia ważności wadium na cały przedłużony okres związania (art. 97 ust. 6 i art. 220 ust. 5 Pzp). Skoro więc skuteczne przedłużenie terminu związania ofertą, tj. zgodne z wnioskiem/żądaniem Zamawiającego, w tym o okres ściśle ​ nim skonkretyzowany, możliwe jest jedynie jednocześnie z przedłużeniem lub wniesieniem nowego wadium na cały w przedłużany, zgodnie z żądaniem zamawiającego okres, to konieczne jest jednorazowe, uprzednie przedłużenie wadium o wymagany przez zamawiającego okres/wniesienie nowego wadium na cały przedłużany okres. Nie sposób racjonalnie przyjąć, że przy podstawowym, jak również przedłużanym terminie związania ofertą, możliwe jest wnoszenie wadium na kolejne, krótsze okresy (nieobejmujące całego wymaganego terminu związania ofertą), aż do osiągnięcia docelowego terminu związania ofertą, gdyż stałoby ​ sprzeczności z regulacjami art. 97 ust. 6 i 220 ust. 5 Pzp. Gdyby wykonawca wraz z oferta wniósł wadium na niepełny w okres związania ofertą i zadeklarował, że dośle aneks wydłużający wadium do docelowego terminu związania ofertą „później”, oferta takiego wykonawcy podlegałaby odrzuceniu. Wniesione wraz z ofertą wadium musi bowiem zabezpieczać od razu cały okres związania ofertą. Analogicznie jest przy przedłużeniu terminu związania ofertą.

Również w tym przypadku wadium powinno zabezpieczać ofertę od razu na cały - przedłużany zgodnie z żądaniem Zamawiającego – okres.

KIO 1648/26 10 kwietnia 2026 r. wykonawca Kyndryl Poland spółka z ograniczoną odpowiedzialnością z​ siedzibą w Warszawie (dalej: Odwołujący Kyndryl), wniósł odwołanie i zarzucił Zamawiającemu:

1. art. 239 ust. 1 w zw. z art. 16 pkt 1-3 Pzp, przez nieprawidłowe przyznanie wykonawcy Linux Polska Sp. z o.o. maksymalnej liczby punktów w kryterium oceny ofert „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025”, podczas gdy prawidłowa ocena powinna skutkować brakiem przyznania jakichkolwiek punktów, ponieważ: a)przy zastosowaniu literalnej wykładni kryterium określonego przez Zamawiającego żadna z ofert – w tym oferta Linux Polska Sp. z o.o., nie spełnia kryteriów uzasadniających przyznanie jakichkolwiek punktów; b)[zarzut ewentualny względem zarzutu 1a] w raporcie Gartnera, na podstawie którego Zamawiający zobowiązał się do weryfikacji informacji zawartych ​ w formularzu ofertowym wykonawcy Linux Polska Sp. z o.o., w kategorii „Liderzy” nie znajduje się podmiot „Elasticsearch”, którego oprogramowanie zaoferował Linux Polska Sp. z o.o.
2. art. 239 ust. 1 w zw. z art. 226 ust. 1 pkt 5 Pzp przez zaniechanie odrzucenia oferty wykonawcy Linux Polska Sp. z o.o. w sytuacji, w której jej treść jest niezgodna ​ z warunkami zamówienia.

W oparciu o podniesione zarzuty Odwołujący Kyndryl wniósł o nakazanie Zamawiającemu:

1. Unieważnienia czynności wyboru oferty najkorzystniejszej,
2. Powtórzenia czynności badania i oceny ofert, a w jej ramach: a)Przyznania wykonawcy Linux Polska Sp. z o.o. 0 pkt w kryterium pn.: „Pozycja ​ w Gartner Magic Quadrant Observability na rok 2025”, b)Odrzucenia oferty Linux Polska Sp. z o.o. na podstawie art. 226 ust. 1 pkt 5 Pzp.

W uzasadnieniu swojego stanowiska Odwołujący Kyndryl wskazał m.in.:

31 marca 2026 r. Zamawiający dokonał wyboru oferty najkorzystniejszej, którą okazała s​ ię oferta wykonawcy Linux Polska Sp. z o.o. W kryterium Pozycja w Gartner®Magic Quadrant™ Observability na rok 2025 ww. wykonawca otrzymał maksymalną ilość punktów, tj. 15. Ostatecznie przełożyło się to również na punktację w wysokości 99,70 pkt. Punktacja wszystkich wykonawców przedstawia się następująco:

Zarzut nr 1a:

W pierwszej kolejności należy wskazać, że w kryterium pn.: „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025”, każdy z oferentów powinien był otrzymać 0 punktów. Wynika to z błędnej konstrukcji ww. kryterium, która uniemożliwia przyznanie jakichkolwiek punktów któremukolwiek z wykonawców. Z analizy SW Z w omawianym zakresie wynika, ż​ e punkty w ramach ww. kryterium mógł uzyskać wykonawca, którego zaoferowany produkt znajduje się w określonej pozycji rankingu Gartnera. a.0 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Gracze Niszowi, a także wykonawca, który wskazał pozycję w Gartner® Magic Quadrant™ Observability na rok 2025 dla zaoferowanego produktu niezgodnie ​ ze stanem faktycznym bądź nie wypełnił Tabeli 1 w pkt 1.6 Formularza oferty. b.2 punkty otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Wizjonerzy. c.7 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Kandydaci. d.15 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Liderzy.

Potwierdza to również treść formularza ofertowego, w którego punkcie 1.6 należało wpisać: „Informacja o pozycji zaoferowanego produktu w Gartner® Magic Quadrant™ Observability n​ a rok 2025, bądź informacja, że zaoferowany produkt nie znajduje się w Gartner® Magic Quadrant™ Observability na rok 2025, zgodnie z wymogiem 7.3.3. SW Z”. Również pod Tabelą 1 zawarto stosowną uwagę, zgodnie z którą „wypełnia Wykonawca przez wpisanie „x” tylko ​ jednej, właściwej kolumnie, w zależności od pozycji zaoferowanego produktu w Gartner® Magic Quadrant™ w Observability na rok 2025 / zaoferowany produkt nie znajduje s​ ię w Gartner® Magic Quadrant™ Observability na rok 2025, z zastrzeżeniem p​ kt 7.3.3.1.SWZ”.

Z powyższego wynika, że w ramach omawianego kryterium, zgodnie z literalną treścią S W Z oraz pozostałych dokumentów zamówienia, obowiązkiem Zamawiającego było przyznanie określonej ilości punktów wyłącznie w oparciu o pozycję zaoferowanego produktu w rankingu Gartnera. Ocenie podlega wyłącznie to, czy i w jakim segmencie rankingu Gartnera z​ najduje się produkt wskazany w ofercie danego wykonawcy. Należy jednak podkreślić, ż​ e tak ukształtowana treść przedmiotowego kryterium w praktyce uniemożliwia przyznanie jakichkolwiek punktów któremukolwiek z wykonawców, w konsekwencji czego wszyscy oferenci powinni otrzymać 0 punktów w jego ramach.

Wynika to z faktu, że w rankingu Gartnera klasyfikacji podlegają poszczególne podmioty (firmy), a nie oferowane przez n​ ie produkty. Wyjaśnienie tej materii należy rozpocząć od zdefiniowania czym jest w ogóle wspomniany ranking. Gartner Magic Quadrant™ to narzędzie wizualne oparte n​ a rygorystycznej metodologii, które przedstawia graficzne porównanie pozycji dostawców technologii i usług na określonym rynku. Ocenia ono dostawców na podstawie dwóch kluczowych kryteriów: zdolności do realizacji (Ability to Execute) oraz kompletności wizji (Completeness of Vision). Źródło: Oficjalna strona internetowa rankingu Gartnera: quadrant Na skutek ewaluacji poszczególnych firm tworzone jest ich porównanie w formie graficznej, które przyporządkowuje każdą z nich do jednej z 4 kategorii, tj. Gracze Niszowi (Niche Players), Wizjonerzy (Visionaries), Kandydaci (Challengers) oraz Liderzy (Leaders). Ranking taki tworzony jestw wielu różnych kategoriach, w tym m. in. w kategorii Observability Platforms, do której odnosił się Zamawiający w niniejszym postępowaniu w ramach kryteriów oceny ofert.

W omawianej kategorii ranking przedstawia się następująco:

Zgodnie jednak z treścią samego raportu (str. 31-36), przyporządkowanie poszczególnych firm do jednej z ww. kategorii nie zależy tylko i wyłącznie od jakości oferowanego przez nich produktu, a od szeregu innych czynników, które składają się na ich całościową ocenę. ​W śród tych czynników można wymienić m. in.: Ogólna wykonalność („Overall viability”), Realizacja sprzedaży/cennik („Sales execution/pricing”), Responsywność na rynek („Market responsiveness”), Realizacja działań marketingowych („Marketing execution”), Zadowolenie klienta („Customer experience”), Strategia sprzedaży („Sales strategy”), Model biznesowy („Business Model”) i inne.

Dowód: raport pn.: „Magic Quadrant for Observability Platforms”wraz z tłumaczeniem fragmentów (str. 31-36) na język polski.

Produkt lub usługa stanowią tylko jeden z wielu ocenianych kryteriów. Na ostateczną ocenę wpływ ma jednak szereg innych czynników. Powyższe prowadzi do wniosku, że o pozycji ​ rankingu nie przesądza jakość zaoferowanego produktu, a ogólna kondycja ocenianego wykonawcy. Co więcej, to nie w produkt zajmuje określoną pozycję w rankingu tylko dostawca. Ranking ma w ięc charakter podmiotowy, a nie przedmiotowy. Tym samym możliwa jest sytuacja, w której firma posiadająca produkt o najwyższej możliwej jakości nie znajdzie s​ ię kategorii „Liderzy”, gdyż nisko zostanie oceniona jej strategia marketingowa i biznesowa czy sprzedażowa, przez co ostatecznie wyląduje w niższej kategorii lub w ogóle nie znajdzie się w rankingu. Biorąc powyższe pod uwagę należy stwierdzić, że przyznanie przez Zamawiającego punktów w omawianym kryterium oceny ofert w jego obowiązującym brzmieniu jest niemożliwe. Kryterium to zostało bowiem skonstruowane w sposób wewnętrznie sprzeczny. Z jednej strony odnosi się wyłącznie do produktu oferowanego przez wykonawcę, z drugiej zaś odwołuje się do narzędzia oceny (Gartner Magic Quadrant™), które w istocie nie klasyfikuje produktów, lecz całościową pozycję rynkową dostawców, uwzględniając szereg czynników wykraczających poza sam produkt. W konsekwencji brak jest możliwości przypisania konkretnego produktu do określonej kategorii wskazanej w rankingu Gartnera ​ sposób zgodny z literalnym brzmieniem kryterium. Ranking ten nie przewiduje bowiem klasyfikacji na poziomie w produktu, lecz na poziomie podmiotu (dostawcy), którego ocena jest wynikiem kompleksowej analizy obejmującej m.in. strategię biznesową, zdolności operacyjne czy pozycję rynkową. Tym samym nie istnieje obiektywne i weryfikowalne kryterium pozwalające na ustalenie, w jakiej „pozycji” znajduje się konkretny produkt oferowany przez wykonawcę.

Pozycję tę zajmuje bowiem określony podmiot, a nie produkt. Powyższe prowadzi do sytuacji, w której Zamawiający chcąc zastosować przedmiotowe kryterium zmuszony byłby w istocie dokonać jego wykładni rozszerzającej, polegającej na przypisaniu określonej ilości punktów nie z uwagi na pozycję danego produktu w rankingu, a z uwagi na pozycję danego dostawcy w rankingu, co nie ma oparcia w literalnej treści ustanowionego kryterium. To z kolei nasuwa wniosek, że w ramach omawianego kryterium każdy z wykonawców powinien otrzymać 0 punktów, gdyż nie ma obiektywnej możliwości ustalenia czegoś takiego j​ ak „pozycja zaoferowanego produktu w Gartner Magic Quadrant”. Zgodnie z art. 239 ust. 1 Pzp zamawiający wybiera najkorzystniejszą ofertę na podstawie kryteriów oceny o​ fert określonych w dokumentach zamówienia. Z tego przepisu wynika zasada z​ wiązania zamawiającego zasadami oceny ofert opisanymi w dokumentach zamówienia, ​ tym ustalonymi kryteriami oraz opisem sposobu przyznawania punktów w ramach poszczególnych kryteriów. w Zamawiający do oceny ofert może zastosować wyłącznie takie kryteria i zasady, jakie wskazał w dokumentach zamówienia. Zamawiający, oceniając oferty, nie może zatem ani uszczegółowić zasad oceny przez badanie w sposób, który nie został jednoznacznie wyartykułowany w zapisach SW Z, ani też odstępować od zasad, które opisał uprzednio (…). W związku z powyższym Zamawiający, postępując zgodnie z literalną treścią ustanowionego przez siebie kryterium, powinien był w jego ramach przyznać każdemu z​ wykonawców, w tym wykonawcy Linux Polska Sp. z o.o., 0 punktów. Przyznanie wskazanemu wykonawcy maksymalnej ilości punktów w omawianym kryterium nie znajduje uzasadnienia w jego literalnym brzmieniu. To nie produkt oferowany przez firmę Elastic zajmuje bowiem określoną pozycję w rankingu, a ta firma, która oceniana jest przez pryzmat szeregu kryteriów.

Powyższe przesądza o zasadności postawionego zarzutu.

Zarzut nr 1b [ewentualny wobec zarzutu nr 1a]:

Zgodnie z treścią SWZ pkt 7.2.3.2. Zamawiający dokonuje oceny w kryterium „Pozycja ​ Gartner® Magic Quadrant™ Observability na rok 2025” na podstawie informacji podanej przez Wykonawcę w w Formularzu Oferty w zakresie zaoferowanego produktu, którą Zamawiający zweryfikuje na podstawie rankingu dostępnego pod adresem: https://www.gartner.com ​W treści formularza ofertowego wykonawca Linux Polska Sp. z o.o. wskazał, że oferowany przez niego produkt został sklasyfikowany w Gartner® Magic Quadrant™ Observability na rok 2025 w pozycji Liderzy (Leaders). Nie jest to jednak informacja prawdziwa. Zaoferowany przez ww. wykonawcę produkt został przez niego zindywidualizowany w punkcie 4 formularza ofertowego, gdzie wskazano następująco: -producent oprogramowania: Elasticsearch, -nazwa oprogramowania: Enterprise.

Tymczasem w raporcie Gartnera, na podstawie którego Zamawiający zobowiązał s​ ię do weryfikacji informacji zawartych w formularzu ofertowym, w kategorii „Liderzy” nie znajduje się podmiot „Elasticsearch”, którego oprogramowanie zaoferował Linux Polska

​S p. z o.o. W ramach ww. kategorii w raporcie znalazły się następujące podmioty: Chronosphere, IBM, Splunk. Elastic, New Relic, Dynatrace, Datadog oraz Grafana Labs. Zamawiający nie miał więc podstawy by przyznać Linux Polska Sp. z o.o. jakiekolwiek punkty w omawianym kryterium. Źródło, w którym Zamawiający zobowiązał się do weryfikacji informacji zawartych w formularzach ofertowych wykonawców, nie wymienia bowiem podmiotu Elasticsearch. To z kolei powinno skutkować przyznaniem ww. wykonawcy 0 punktów ​ omawianym kryterium. w

Zarzut nr 2

W formularzu ofertowym wykonawca Linux Polska Sp. z o.o. wskazał, że oferuje następujący produkt: -Producent oprogramowania: Elasticsearch, -nazwa oprogramowania: Enterprise.

Wskazać jednak należy, że zaoferowany przez Linux produkt nie spełnia części wymogów wskazanych w OPZ, tj. przede wszystkim niespełnione są wymogi wskazane w punkcie II.25, II.27.64, II.27.69 oraz II.27.55szczegółowego opisu przedmiotu zamówienia.

Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.25 Szczegółowego opisu przedmiotu zamówienia/umowy. Zgodnie z punktem II.25 SOPZ, zmodyfikowanym 2​ 6 września 2025 r. w ramach udzielonych wyjaśnień do SWZ:

„Aktualizacje Oprogramowania muszą mieć możliwość automatycznego pobierania na serwer. Aplikacja musi mieć możliwość ustawienia automatycznego lub ręcznego sposobu instalowania aktualizacji. Aktualizacja musi mieć możliwość wykonywania z poziomu centralnej konsoli serwera”.

Wskazać należy, że funkcjonalność automatycznego pobierania na serwer oraz możliwość automatycznego lub ręcznego sposobu instalowania aktualizacji nie jest jednak dostępna ​ systemie Elasticsearch. Funkcjonalność ta jest osiągalna jedynie przez integrację w z​ wykorzystaniem rozwiązań firm trzecich. Powyższe oznacza, że deklarowana przez wykonawcę funkcjonalność nie stanowi parametru gwarantowanego w każdych warunkach, lecz jest wartością możliwą do osiągnięcia jedynie w sytuacji spełnienia dodatkowych przesłanek technicznych, które nie wynikają z treści wymagań określonych przez Zamawiającego, tj. w razie zintegrowania oferowanego oprogramowania z rozwiązaniami stron trzecich. Tym samym oferowany wyrób nie zapewnia samodzielnie wymaganej funkcjonalności, lecz uzależnia jej osiągnięcie od czynników zewnętrznych, co należy ocenić jako odstępstwo od wymogu Zamawiającego określonego w sposób jednoznaczny i​ bezwarunkowy. Powyższa teza znajduje potwierdzenie w opinii wydanej przez certyfikowanego inżyniera Elastic Observability, w której wskazuje on, że:

„Rozwiązanie Elasticsearch Enterprise nie ma możliwości automatycznego pobierania aktualizacji oprogramowania na serwer. Musimy to robić ręcznie lub za pomocą narzędzi automatyzacji, takich jak Ansible czy Puppet”.

Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z​ tłumaczeniem na język polski.

Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27.64 Szczegółowego opisu przedmiotu zamówienia/umowy. Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„umożliwiać automatyczne sprawdzanie dostępności aplikacji przez wykonywanie skryptu symulującego pracę użytkownika; przygotowanie skryptu nie może wymagać od użytkownika umiejętności programistycznych, musi wykorzystywać mechanizm „rekordreplay””.

W zakresie powyższego wymogu Zamawiający udzielił następującego wyjaśnienia treści dokumentów zamówienia:

Pytanie nr 39 Czy zamawiający dopuści realizację wymagań z punktu 27.64 przez drugi produkt, bez konieczności znajomości narzędzi programistycznych? Pozwoli to dopuścić do postępowania rozwiązania i niższej cenie?

Odpowiedź:

Zamawiający podtrzymuje postanowienia SWZ.

System, którego producentem jest firma Elastic umożliwia syntetyczny monitoring dostępności aplikacji, jednak przygotowanie scenariuszy symulujących pracę użytkownika wymaga tworzenia skryptów programistycznych (JavaScript/TypeScript) i nie wykorzystuje mechanizmu record/replay. Tym samym nie spełnia wymogów Zamawiającego określonych ​ OPZ. Przede wszystkim bowiem przygotowanie skryptów wymaga od użytkownika umiejętności programistycznych, w co jest wprost niezgodne z wymaganiem punktu II.27.64.

Ponownie ww. stanowisko znajduje potwierdzenie w opinii wydanej przez certyfikowanego inżyniera Elastic Observability, w której wskazuje on, że:

„Automatyczne sprawdzanie dostępności aplikacji może być wykonane za pomocą narzędzia APM lub rozwiązania APM

Elasticsearch, czyli monitorowania wydajności aplikacji. Jednak wymagani „agenci” muszą być pobrani ze strony aplikacji, konieczne jest dostrojenie agentów po stronie aplikacji. Nie wymaga pisania dodatkowego skryptu, ale sam skrypt aplikacji musi zostać lekko zmodyfikowany, aby zintegrować APM”.

Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z​ tłumaczeniem na język polski.

Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27.6 9 Szczegółowego opisu przedmiotu zamówienia/umowy. Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„zapewniać monitorowanie pracy użytkownika końcowego (user experience) bez konieczności instalacji dodatkowych komponentów po stronie użytkownika i wykonywania zmian konfiguracji, serwerów W W W lub aplikacyjnych; zmiana konfiguracji czy też włączenie/wyłączenie monitorowania zachowań użytkownika musi odbywać się z konsoli narzędzia, bez potrzeby restartu serwerów monitorowanego środowiska”.

System Elasticsearch realizuje monitoring doświadczenia użytkownika w oparciu o RUM, którywymaga modyfikacji aplikacji lub konfiguracji serwerów W W W. Włączenie lub wyłączenie monitoringu nie odbywa się wyłącznie z poziomu konsoli narzędzia i może wymagać ponownego wdrożenia aplikacji, co jest wprost niezgodne ze wspomnianym punktem OPZ.

Ponownie powyższe stanowisko potwierdził certyfikowany inżynier Elastic Observability ​ swojej opinii, gdzie wskazano następująco: „To stwierdzenie nie jest w pełni poprawne w d​ la Elasticsearch. Elastic zapewnia monitorowanie doświadczenia użytkownika końcowego (RUM), ale wymaga agenta po stronie klienta, pewnych zmian konfiguracji i nie może być całkowicie sterowany wyłącznie z konsoli, choć wiele zmian nie wymaga restartu serwera”.

Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z​ tłumaczeniem na język polski.

Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27.5 5 Szczegółowego opisu przedmiotu zamówienia/umowy.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „wykrywać podatności bezpieczeństwa w bibliotekach wykorzystywanych przez aplikacje w trybie ciągłym (24/7). Baza podatności musi być aktualizowana automatycznie, w trybie ciągłym i nie wymagać konfiguracji po stronie Zamawiającego”. System Elasticsearch nie zapewnia natywnej funkcjonalności ciągłego (24/7) wykrywania podatności w bibliotekach wykorzystywanych przez aplikacje ani autonomicznie aktualizowanej bazy podatności w tym zakresie. Konieczna jest wykluczona przez Zamawiającego integracja z zewnętrznym rozwiązaniem. W przedłożonej jako dowód opinii certyfikowanego inżyniera Elastic Observability wskazano następująco:

„Elastic może nieustannie monitorować systemy pod kątem znanych luk, korzystając z​ zaktualizowanych informacji wywiadu zagrożeń, ale nie jest przede wszystkim zaprojektowany do automatycznego skanowania bibliotek aplikacji/zależności b​ ez dodatkowych narzędzi, takich jak snyk”.

Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z​ tłumaczeniem na język polski.

Niezależnie od powyższych okoliczności, które zostały poparte opinią certyfikowanego inżyniera Elastic Observability, Odwołujący wskazuje, że produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia innych, kategorycznych wymagań SOPZ, tj.:

3 3 . [zaoferowany produkt nie spełnia wymogu wskazanego w pkt II.14 Szczegółowego opisu przedmiotu zamówienia/umowy] Zgodnie z punktem II.14 OPZ„Dla oferowanego Oprogramowania opieka serwisowa musi być świadczona w języku polskim”. Produkt zaoferowany przez wykonawcę Linux Poland s​ p. z o.o. stwarza jedynie pozory spełniania ww. wymogu, w rzeczywistości będąc z nim niezgodny.

W pierwszej kolejności należy wskazać, że jednym z przejawów spełniania wymogu z punktu II.14 jest posiadanie polskiej wersji strony internetowej dla produktów Elastic, dostępnej p​ od adresem: https://info.elastic.co/cemea Strona ta jest jednak tylko pozorną „nakładką” na anglojęzyczną stronę producenta. Potwierdzają to następujące okoliczności: (a)Odnośniki do warunków świadczenia usług oraz oświadczenia dot. prywatności ​ są w języku angielskim; (b) link do rzekomej grupy polskich użytkowników rozwiązań elastic jest linkiem odsyłającym do nieistniejącej strony; (c)Materiały, do których linki działają są sporządzone w języku angielskim np.

(d)Próba otworzenia rzekomo polskojęzycznych materiałów (np. Elasticsearch: pierwsze kroki skutkuje przeniesieniem do anglojęzycznej wersji strony bez wyświetlenia polskojęzycznego materiału.

Zgodnie z punktem II.27.6 SOPZ wzakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać własną definicję warstwy/usługi, która zostanie włączona w reprezentację graficzną przez wskazanie punktu startowego - metody wykonywanego kodu. Taka warstwa/usługa powinna być raportowana w ramach pełnego przebiegu transakcji (end-2-end) oraz niezależnie od przebiegu”.

Wskazać należy, że ww. funkcjonalność możliwa jest do osiągnięcia przez system Elastic przez ingerencję w kod aplikacji i dopisanie linii kodu umożliwiających wysyłanie odpowiednich informacji do systemu. Oznacza to, że ww. system nie spełnia wymogu OPZ w sposób bezwarunkowy, a dopiero po uwzględnieniu dodatkowego nakładu pracy programisty i​ związanego z tym wynagrodzenia. Zamawiający oczekiwał spełnienia ww. funkcjonalności przez oferowany produkt bezwarunkowo i samodzielnie co oznacza, że oferta Linux Polska Sp. z o.o. jest niezgodna warunkami zamówienia.

Zgodnie z punktem II.27.6 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„umożliwiać własną definicję warstwy/usługi, która zostanie włączona w reprezentację graficzną przez wskazanie punktu startowego - metody wykonywanego kodu. Taka warstwa/usługa powinna być raportowana w ramach pełnego przebiegu transakcji (end-2-end) oraz niezależnie od przebiegu”. Wskazane wymaganie spełnione jest przez system Elastic tylko częściowo co oznacza, że w pozostałej części jest niezgodne z OPZ bowiem wymaga modyfikacji kodu aplikacji, a nie wyłącznie konfiguracji systemu monitorującego. Oznacza t​ o, że nie jest to tożsame z wymogiem zapisanym przez Zamawiającego w SOPZ.

Zgodnie z punktem II.27.16 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„prezentować zapytania SQL wykonane w ramach transakcji z możliwością uzyskania informacji o liczbie zwróconych wierszy”. Dla spełnienia ww. wymogu przez system Elastic wymagana jest modyfikacja kodu. Żeby spełnić wymaganie „SQL + liczba zwróconych wierszy”, trzeba dostarczyć tę informację spoza standardowego APM, np.: Instrumentacja ​ aplikacji wymaga dopisania funkcjonalności w kodzie. w Zgodnie z punktem II.27.23 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji”.

Wymóg ten wzbudzał liczne wątpliwości, które zostały przez Zamawiającego sprecyzowane ​ toku postępowania: w Pytanie nr 11 Wykonawca zwraca się z wnioskiem o wykreślenie z treści SW Z pkt. 27.23 z Załącznika 7, rozdz. II. Zapis w obecnym kształcie może wskazywać na preferowanie jednego producenta (Dynatrace) oraz ryzyko ograniczenia konkurencji w Postępowaniu. Alternatywnie czy Zamawiający dopuszcza możliwość spełnienia tego wymagania przez integrację zaoferowanego przez Wykonawcę rozwiązania z istniejącymi na złożenia oferty narzędziami zewnętrznymi.

Odpowiedź:

Zamawiający oczekuje funkcjonalności określonej w pkt 27.23 – oferowane oprogramowanie ma „umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji”. Zamawiający dopuszcza możliwość spełnienia tego wymagania przez integrację zaoferowanego przez Wykonawcę rozwiązania z istniejącymi na złożenia oferty narzędziami zewnętrznymi objętymi ofertą Wykonawcy.

Pytanie nr 51 Ad Załącznik nr 7 do SWZ „Szczegółowy opis przedmiotu zamówienia/Umowy”. Pkt II, ppkt 27.23 „Czy Zamawiający dopuści rozwiązanie, które nie posiada funkcjonalności wykonywania automatycznego zrzutu pamięci ze sterty Java, przy czym umożliwia automatyczne wykrywanie wycieków pamięci celem wczesnego ostrzegania o możliwych problemach z​ wydajnością aplikacji Java oraz łatwiejszą analizy przyczyn źródłowych tych problemów?" Zastosowany zapis jest właściwy dla firmy Dynatrace i uniemożliwia zaoferowanie innych rozwiązań niż Dynatrace Managed Odpowiedź:

Zamawiający podtrzymuje postanowienia SWZ, jednocześnie patrz odpowiedź na Pytanie nr 11.

Oferowany przez wykonawcę Linux Polska system nie posiada natywnej funkcjonalności wykonywania zrzutów pamięci sterty Java (heap dump) dla monitorowanych aplikacji Zamawiającego ani ich analizy pod kątem wycieków pamięci i optymalizacji. Realizacja tego wymagania wymaga zastosowania zewnętrznych narzędzi lub profilerów JVM (np. narzędzi JDK lub dedykowanych rozwiązań APM), a Elastic pełni jedynie rolę platformy zbierania i​ korelacji danych. Z oferty Linux nie wynika, aby takie zewnętrzne narzędzia zostały zaoferowane.

Dodatkowo, mechanizmy wykonywania heap dumpów w środowiskach zarządzanych przez Elastic (np. ECE) powodują pauzę JVM w trakcie tworzenia zrzutu, co oznacza czasowe wstrzymanie przetwarzania aplikacji. W konsekwencji nie jest spełniony wymóg OPZ, zgodnie z którym zrzut pamięci nie może zatrzymywać działającej aplikacji. Powyższe okoliczności powinny skłonić Zamawiającego do uznania, że w rzeczywistości produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia warunku wskazanego w pkt II.27.23 SOPZ.

Zgodnie z ww. wymogiem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„posiadać własny interfejs do tworzenia lub konfigurowania własnych wtyczek monitorujących rozszerzających standardowe funkcjonalności narzędzia”.

Dla spełnienia ww. wymogu przez system Elastic wymagana jest jego integracja z​ rozwiązaniami firm trzecich. Elastic nie spełnia wymagania posiadania własnego interfejsu do tworzenia lub konfigurowania wtyczek monitorujących; realizacja rozszerzeń funkcjonalnych wymaga prac programistycznych oraz użycia narzędzi zewnętrznych.

Zgodnie z punktem II.27.26 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„umożliwiać maskowanie adresów IP użytkowników. Maskowanie musi być wykonane przed zapisem adresu IP do bazy danych narzędzia”. System Elastic by spełnić ww. wymaganie wymaga integracji z rozwiązaniami trzecimi (brak natywnej funkcjonalności). Elastic zapewnia automatyczny monitoring wszystkich procesów na poziomie metryk systemowych. Rozszerzony monitoring procesów Java, .NET i PHP (wątki, sterta, GC) realizowany jest warunkowo i wymaga instalacji oraz konfiguracji dedykowanych agentów APM - nie jest aktywowany automatycznie dla każdego nowo wykrytego procesu. To oznacza, że wskazane wymaganie nie jest spełnione bezwarunkowo. Dla poprawnego działania systemu, w zgodzie z zapisami OPZ, niezbędnym jest spełnienie dodatkowych wymogów, co potwierdza, że oferta jest niezgodna z warunkami zamówienia i powinna zostać odrzucona.

Zgodnie z punktem II.27.37 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać monitoring wszystkich procesów działających na serwerach objętych monitoringiem na poziomie co najmniej metryk systemowych: wykorzystanie CPU, pamięci, operacji IO, wykorzystanie sieci. Dla procesów JAVA, .NET i PHP dodatkowo monitoring musi obejmować statystyki wykorzystania wątków, sterty JVM i CLR oraz wpływ działania Garbage Collector’a na proces. Nowe procesy muszą być wykrywane i monitorowane automatycznie bez potrzeby ręcznej konfiguracji”.

Wymóg ten został dodatkowo doprecyzowany przez Zamawiającego:

Pytanie nr 95 Dotyczy punktu 27.37: Jakie konkretne dane lub metryki dotyczące działania Garbage Collector'a są wymagane dla aplikacji PHP? Czy wymagane jest monitorowanie GC n​ a poziomie szczegółowym (czas, częstotliwość), czy wystarczą dane ogólne, np. wzrost zużycia pamięci lub opóźnień?

Odpowiedź: Zamawiający wymaga monitorowania Garbage Colletora na poziomie szczegółowym.System oferowany przez wykonawcę Linux Polska Sp. z o.o., nie ma takiej natywnej funkcjonalności i wymaga integracji z rozwiązaniami trzecimi. Ponownie świadczy t​ o o tym, że wymaganie Zamawiającego nie jest spełnione w sposób bezwarunkowy przez oferowane rozwiązanie.

Elastic zapewnia automatyczny monitoring wszystkich procesów n​ a poziomie metryk systemowych. Rozszerzony (szczegółowy) monitoring procesów Java, .NET i PHP (wątki, sterta, GC) realizowany jest warunkowo i wymaga instalacji oraz konfiguracji dedykowanych agentów APM. nie jest aktywowany automatycznie dla każdego nowo wykrytego procesu. Tym samym nie jest spełniony wymóg, na którym szczególnie zależy Zamawiającemu, tj. monitorowanie Garbage Collectora na poziomie szczegółowym.

Tym samym spełnienie przedmiotowego wymogu uzależnione jest od dalszych działań implementacyjnych, wykraczających poza zakres standardowej funkcjonalności oferowanego oprogramowania, co pozostaje w sprzeczności z jednoznacznie określonymi wymaganiami SOPZ.

Powyższe okoliczności powinny skłonić Zamawiającego do uznania, że w rzeczywistości produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia warunku wskazanego w pkt II.27.37 SOPZ.

Odnośnie do wyżej wskazanych postanowień OPZ należy zwrócić uwagę na odpowiedź Zamawiającego na pytanie nr

1. W odpowiedzi tej Zamawiający podkreślił, że interesuje g​ o rozwiązanie, w ramach którego nie jest konieczne użycie drugiego produktu.

Pytanie nr 38 Czy zamawiający dopuści realizacje wymagań z punktów 27.55-27.61 SW Z przed drugi produkt, bez wpływu na jakość danych, co pozwoli dopuścić do postępowania rozwiązania i niższej cenie?

Odpowiedź:

Zamawiający podtrzymuje postanowienia SWZ.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„wykrywanie podatności nie może wymagać instalowania dodatkowego oprogramowania poza tym, które wchodzi w skład platformy do monitorowania”.

By spełnić ww. wymaganie system Elastic wymaga integracji z rozwiązaniem firm trzecich. Elastic nie realizuje wykrywania podatności w bibliotekach aplikacyjnych w ramach własnej platformy monitorującej. Spełnienie wymagania wymaga zastosowania i instalacji zewnętrznego oprogramowania.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„dla wykrytych podatności prezentować listę wszystkich procesów, które posiadają wykrytą podatność oraz serwerów, na których te procesy działają”.

System Elastic nie zapewnia natywnej funkcjonalności prezentowania listy procesów oraz serwerów dotkniętych wykrytymi podatnościami w bibliotekach aplikacyjnych. Konieczna jest wykluczona przez Zamawiającego integracja z zewnętrznym rozwiązaniem.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:

„dla wykrytych podatności klasyfikować je wg CVSS wraz z uwzględnieniem informacji o​ ekspozycji na atak z publicznego internetu oraz dostępu do danych”.

Ponownie dla spełnienia wskazanego punktu SOPZ system Elastic musi zostać zintegrowany z rozwiązaniem firm trzecich. System ten nie zapewnia natywnej klasyfikacji podatności aplikacyjnych wg CVSS ani ich oceny w kontekście ekspozycji na atak z publicznego Internetu oraz dostępu do danych. Realizacja wymagania wymaga zastosowania zewnętrznego rozwiązania.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „dla wykrytych podatnościach prezentować informacje o​ istnieniu exploitów, które mogą być wykorzystane do ataku”.

System Elastic nie zapewnia natywnej prezentacji informacji o istnieniu exploitów d​ la wykrytych podatności aplikacyjnych. Konieczna jest zakazana przez Zamawiającego integracja z zewnętrznym rozwiązaniem.

Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „dla wykrytych podatności prezentować ich opis oraz sposób remediacji, o ile taki istnieje”.

System Elastic nie zapewnia natywnej prezentacji opisów podatności aplikacyjnych a​ ni zaleceń remediacyjnych. Konieczna jest zakazana przez Zamawiającego integracja z​ zewnętrznym rozwiązaniem.

Mając na uwadze powyższe, należy stwierdzić, że oferowane rozwiązanie ponownie n​ ie spełnia wymagań OPZ w sposób bezwarunkowy. Kluczowe funkcjonalności SOPZ nie są dostępnenatywnie w ramach systemu Elastic i wymagają zastosowania dodatkowych, zewnętrznych narzędzi, co pozostaje w sprzeczności z jednoznacznym stanowiskiem Zamawiającego wyrażonym w odpowiedzi na pytanie nr 38. W konsekwencji oznacza t​ o, że treść oferty jest niezgodna z warunkami zamówienia, co powinno skutkować jej odrzuceniem na podstawie art. 226 ust. 1 pkt 5 Pzp.

Dla wykazania okoliczności, o których mowa w punktach 33-41 Odwołujący załącza dodatkowo opinię ekspercką wykonaną przez p. J.S., który również jest Certyfikowanym Inżynierem Elastic.

Potwierdza ona fakt, że oferta wykonawcy Linux Polska Sp. z o.o. jest niezgodna z warunkami zamówienia, co powinno prowadzić do jej odrzucenia na podstawie art. 226 ust. 1 pkt 5 Pzp.

Zamawiający 24 kwietnia 2026 r. złożył odpowiedzi na oba odwołania i:

1. Uwzględnił zarzuty nr 4 i 5 odwołania KIO 1646/26, a w pozostałym zakresie wniósł ​ o oddalenie odwołania,
2. wniósł o oddalenie odwołania KIO 1648/26.

Przystępujący Kyndryl wniósł sprzeciw wobec częściowego uwzględnienia przez Zamawiającego odwołanie KIO 1646/26.

Po przeprowadzeniu rozprawy Izba, uwzględniając dokumentację przedmiotowego postępowania o udzielenie

zamówienia publicznego, w tym w szczególności treść SWZ, jak również biorąc pod uwagę oświadczenia i stanowiska Stron i Przystępujących zawarte w odwołaniach, odpowiedziach na odwołania i pismach procesowych, a także wyrażone ustnie na rozprawie i odnotowane w protokole, ustaliła i zważyła, co następuje.

Izba odrzuciła odwołanie KIO 1648/26 w zakresie zarzutu nr 1a uznając, że został o​ n wniesiony po upływie ustawowego terminu. Zarzut ten dotyczył przede wszystkim konstrukcji pozacenowego kryterium oceny ofert – większość argumentów podniesionych przez Odwołującego sprowadzało się do faktycznego kwestionowania kryterium „Pozycja ​ Gartner® Magic Quadrant™ Observability na rok 2025”. Odwołujący kwestionował fakt przyznania punktów ofercie w Linux, ale konsekwentnie wskazywał, że kryterium jest wadliwe, więc żadna oferta nie powinna uzyskać punktów w ramach tego kryterium. Uzasadnienie zarzutu zostało przytoczone wyżej w całości – jednoznacznie wynika z niego, że Odwołujący w zarzucie nr 1a w sposób faktyczny zmierza do zmiany zasad punktacji ofert określonych ​ SWZ, mimo, że postępowanie jest na etapie wyboru najkorzystniejszej oferty. w Izba stwierdziła, że w zakresie pozostałych zarzutów odwołań nie została wypełniona żadna z​ przesłanek ustawowych skutkujących ich odrzuceniem, wynikających z art. 528 Pzp.