Wyrok KIO 3584/23 z 19 grudnia 2023

Zamawiający – Ministerstwo Cyfryzacji, ul. Królewska 27, 00-060 Warszawa, prowadziw trybie przetargu nieograniczonego postępowanie pn. „Zakup dostępu do platformy Cyber Threat Intelligence na poziom operacyjny”, numer referencyjny: PN-17/C/2023. Ogłoszenieo zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu 27.09.2023 r., nr 2023/S 186-581359.

W dniu 27.11.2023 r. do Prezesa Krajowej Izby Odwoławczej wpłynęło odwołanie, w którym wykonawca Alfavox Software sp. z o.o., ul. Ziębicka 35, 60-164 Poznań (dalej: „Odwołujący”) zarzucił Zamawiającemu naruszenie:

1. art. 226 ust. 1 pkt 5 w zw. z art. 16 pkt 1, 2 i 3 ustawy Prawo zamówień publicznych (t.j. Dz.U. 2023 r. poz. 1605 ze zm.), zwanej dalej „ustawą Pzp”, poprzez bezzasadne odrzucenie oferty Odwołującego, w szczególności ze względu na interpretację przez Zamawiającego warunków zamówienia w sposób skrajnie naruszający zasady uczciwej konkurencji, równego traktowania wykonawców, przejrzystości postępowania oraz proporcjonalności, podczas gdy Odwołujący zaoferował świadczenie w pełni zgodne z wyraźnie wyartykułowanymi warunkami zamówienia, 2)art. 239 ust. 1 oraz ust. 2 w zw. z art. 16 pkt 1 ustawy Pzp, poprzez bezpodstawny wybór jako najkorzystniejszej oferty Trafford IT sp. z o.o. sp. k., podczas gdy podmiot ten nie wykazał spełnienia warunków udziału w Postępowaniu (w zakresie doświadczenia), a ponadto oferta tego podmiotu nie posiada najkorzystniejszego bilansu punktowego w ramach kryteriów oceny ofert, ponieważ najkorzystniejszy bilans ceny oraz pozacenowego kryterium oceny ofert posiada bezzasadnie odrzucona oferta Odwołującego.

W szczególności Odwołujący podniósł, co następuje.

1. Rzekomy zakaz customizacji oferowanego systemu (1) Zamawiający w uzasadnieniu odrzucenia oferty wskazał wyłącznie wybrane fragmenty korespondencji mailowej prowadzonej z przedstawicielem handlowym producenta rozwiązania oferowanego przez Alfavox Software sp. z o.o. co nie oddaje jej rzeczywistego znaczenia. (…) (4) Zamawiający wskazuje więc, iż Wykonawca miał zaoferować istniejący system, który już w chwili składania ofert ma wszelkie funkcjonalności wymagane OPZ. W konsekwencji oznacza to, iż Zamawiający (rzekomo) nie dopuszczał możliwości zaoferowania wersji „customizowanej” Systemu, a więc wersji, która zostanie dostosowana do potrzeb i wymogów danego klienta przed rozpoczęciem realizacji Umowy. Stanowisko Zamawiającego w istocie oznacza, iż oferty nie mógł złożyć podmiot, który posiada określony System, który miałby jedynie zostać dostosowany do indywidualnych potrzeb danego Zamawiającego. Stanowisko takie nie wytrzymuje krytyki i jest sprzeczne z zasadą proporcjonalności oraz zasadą uczciwej konkurencji oraz równego traktowania wykonawców (o czym szerzej niżej). (5) Przede wszystkim Zamawiający, w swoim stanowisku (bez wyjaśnienia) niesłusznie założył, że takie „dostosowanie” miałoby nastąpić dopiero na etapie realizacji umowy. Natomiast w niniejszej sprawie mamy do czynienia z sytuacją, w której owe „dostosowanie” realizowane jest przed rozpoczęciem realizacji umowy. Tym samym tak jak zaoferował Odwołujący, nie przeczy to i jest zgodne z wymogiem stanowiącym pozacenowe kryterium oceny ofert, iż w chwili dostarczenia Zamawiającemu systemu (2 dni od podpisania umowy) będzie to system gotowy, spełniający wszystkie wymagania OPZ. (6) Z całą stanowczością podkreślić należy, iż w warunkach zamówienia nie wskazano, iż oferowane rozwiązanie ma mieć wszelkie funkcjonalności już w dniu składania ofert i że zakazanym jest dostosowanie posiadanego rozwiązania do potrzeb danego klienta. Przy czym Odwołujący jest świadomy, iż System wraz z wszystkimi niezbędnymi funkcjonalnościami musi być gotowy już w chwili zawarcia umowy, co gwarantował w ofercie i co nadal potwierdza. (…) (10) Zamawiający w żadnym z postanowień dokumentów zamówienia nie wskazał, iż zakazuje dokonania customizacji, modyfikacji posiadanego Systemu, oraz wzbogacenia go o wymagane funkcjonalności, celem dostosowania do potrzeb danego klienta. Nie wskazano również (i słusznie) obowiązku posiadania przez oferowany system wszystkich funkcjonalności w dniu składania ofert, czego emanacją był w szczególności brak żądania przedmiotowych środków dowodowych na potwierdzenie zgodności oferowanego rozwiązania z warunkami zamówienia. Brak takich wyraźnie wyartykułowanych zakazów/zastrzeżeń w warunkach zamówienia oznacza, iż dokonanie customizacji systemu po upływie terminu składania ofert, lecz przed zawarciem umowy jest dozwolone. (…) (16) Zamawiający nie może więc wyciągać względem wykonawców w tym Odwołującego jakichkolwiek negatywnych

konsekwencji, z tytułu niespełnienia wymagań, które nie zostały jednoznacznie ujęte w dokumentach zamówienia i które stanowią co najwyżej niewyartykułowane intencje Zamawiającego. (…)

1. Interpretacja warunków zamówienia w sposób naruszający zasady proporcjonalności oraz uczciwej konkurencji i równego traktowania wykonawców (1) W tym miejscu wskazać należy, iż taki sposób interpretacji obrany przez Zamawiającego w postaci konieczności posiadania przez System wszystkich funkcjonalności już w dniu składania ofert i zakazu dostosowania systemu do potrzeb Zamawiającego, w powiązaniu z okolicznością, iż każdy z pozostałych wykonawców, którzy złożyli ofertę zaoferowali ten sam – jeden system, tj. Recorded Future, prowadziłby do konstatacji, iż OPZ został celowo skonstruowany w taki sposób, iż jedynie ww. system (Recorded Future) spełniał będzie wymogi Zamawiającego, ponieważ wyłącznie ten system w chwili upływu terminu składania ofert posiadał wszystkie funkcjonalności wymagane przez Zamawiającego. (2) Okoliczność ta wynika z ustaleń Shavit oraz Odwołującego, które wskazują, iż tylko platforma Recorded Future posiada w wersji standardowej (bez potrzeby żadnych modyfikacji) wszystkie ww. funkcjonalności. (…) (12) W świetle powyższego, na uwagę zasługuje również fakt, iż z dokładnej analizy protokołu z postępowania o udzielenie zamówienia publicznego (wraz z załącznikami) wynika, iż Zamawiający prowadził korespondencję odnośnie do zgodności oferowanego systemu wyłącznie z producentem rozwiązania zaoferowanego przez Alfavox Software sp. z o.o., tj. z firmą SOCRADAR. Podobnej korespondencji nie prowadzono z producentem drugiej z zaoferowanych platform tj. platformy Recorded Future, co do której Zamawiający miał zaskakującą pewność co do jej zgodności z warunkami zamówienia. Jest to o tyle zastanawiające, iż Zamawiający nie żądał w Postępowaniu jakichkolwiek przedmiotowych środków dowodowych, które miałyby potwierdzać zgodność oferowanego rozwiązania z OPZ, a z protokołu nie wynika aby Zamawiający prowadził jakiekolwiek choćby niesformalizowane badania co do zgodności platformy Recorded Future z warunkami zamówienia. (…) (14) Nie można oprzeć się wrażeniu, iż Zamawiający „szukał” tylko podstaw do odrzucenia oferty Odwołującego.
2. Brak wykazania niezgodności oferowanego rozwiązania z OPZ (2) Przede wszystkim zauważyć należy, że korespondencja prowadzona z SOCRADAR przez Zamawiającego miała charakter niesformalizowany, a Zamawiający nie wskazał producentowi z jakiego powodu kieruje do niego korespondencję i w związku z jakim projektem oraz w jakich okolicznościach, która to wiedza w tym zakresie byłaby dla przedstawiciela producenta kluczowa. (…) (3) Korespondencja pomiędzy Zamawiającym a przedstawicielem SOCRADAR dotyczy wersji podstawowej (default) Systemu SOCRADAR, a nie wersji, która jest stosownie wzbogacana o wymagane funkcjonalności wymagane przez Zamawiającego, zgodne z jego potrzebami. Okoliczność ta wynika z korespondencji prowadzonej przez Odwołującego z przedstawicielem producenta, gdzie w tłumaczeniu na język polski wskazano, iż: (…) (4) Nie bez znaczenia jest zatem fakt, iż korespondencja była prowadzona przez Zamawiającego w taki sposób, iż przedstawiciel SOCRADAR był w uzasadnionym przekonaniu, iż Zamawiający chce nabyć system w wersji standardowej bezpośrednio od SOCRADAR, który nie miał świadomości, że pytania są związane ze specjalnym projektem prowadzonym dla tego podmiotu według określonej specyfikacji (OPZ). W korespondencji przedstawiciel Zamawiającego wskazał, że rozwiązanie, o które pyta ma być „for my company”, a więc dla firmy – przedsiębiorstwa.

Taki sposób konstrukcji maila, który nie był potem przedmiotem sprostowania przez przedstawiciela Ministerstwa miał ewidentny wpływ na dalsze odpowiedzi udzielone przez SOCRADAR, na co wskazał sam przedstawiciel SOCRADAR w przedstawionej przez Odwołującego informacji (zawnioskowana powyżej wiadomość mailowa z dnia 24 listopada 2023 r. wraz z tłumaczeniem). (5) Ustosunkowując się jednak do poszczególnych wymogów zawartych w uzasadnieniu odrzucenia oferty, wskazujemy co następuje. (6) Co do zarzutu niespełnienia wymogu zawartego w rozdziale 4. Funkcjonalność Wyszukiwania Zagrożeń pkt. 5 OPZ „Dane zawarte w Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”, wskazać należy, że twierdzenie to nie polega na prawdzie. (7) Dnia 14 listopada 2023 r. Zamawiający skierował do producenta maila, który jak się wydaje miał stanowić podsumowanie dotychczasowej korespondencji prowadzonej z przedstawicielem SOCRADAR. (…) (9) Z powyższego należy więc wnioskować, iż korespondent Ministerstwa Cyfryzacji niejako wycofuje się ze swoich wcześniejszych deklaracji co do niemożliwości zaprezentowania w systemie danych sprzed 10 lat, wskazując, iż musi to jeszcze raz wewnętrznie sprawdzić, aby się upewnić. Mimo że w świetle powyższego, Zamawiający nie mógł mieć gwarancji niespełnienia komentowanego wymogu i braku tejże funkcjonalności, podjął decyzję o odrzuceniu oferty również na tej podstawie faktycznej. (10) Niezależnie od powyższego wskazać należy, iż system zaoferowany przez Odwołującego spełnia ww. wymóg Opisu Przedmiotu Zamówienia. Jak już wskazano powyżej, Odwołujący dostarczy wersję dedykowaną dla Zamawiającego, w wyniku customizacji przeprowadzonej przez Shavit oraz SOCRADAR. W konsekwencji Zamawiający w przypadku zawarcia umowy z Odwołującym będzie miał możliwość samodzielnego automatycznego (tj. bez zaangażowania w tym zakresie analityków i pracy ludzkiej) generowania danych z co najmniej 10 lat. Podkreślamy, iż Wykonawca w ramach swojej oferty dostarczy Zamawiającemu system SOC Radar umożliwiający prezentowanie danych starszych aniżeli 10 lat. (11) Ponadto należy zwrócić uwagę, że w odpowiedzi, którą Zamawiający uzyskał od producenta jest informacja, że producent „nie może prezentować starszych danych” („I got the information that we can not present older data.”).

Odpowiedź producenta oznacza jedynie, że w wersji standardowej systemu nie ma możliwości prezentowania tych danych. Co nie oznacza, że w systemie starszych danych nie ma, a jedynie oznacza, że w wersji standardowej systemu nie ma możliwości ich prezentowania (wyświetlania na monitorze operatora). (12) Wykonawca wskazuje jednocześnie, iż dostarczony system spełniał będzie drugi z budzących wątpliwości Zamawiającego wymogów, który został zawarty w rozdziale 4. Funkcjonalność Wyszukiwania Zagrożeń pkt. 26 OPZ „Mechanizm alarmowania w Systemie musi umożliwiać generowanie alarmów w zadanych interwałach np. 15 minut, 1 godzina, 8 godzin, dobowo, tygodniowo.”. (13) System SOCRadar dostarczony zostanie z możliwością kreowania alertóww interwałach rzadszych niż dzienne tj. np. 15 minut, 1 godzina, czy 8 godzin. (…) (15) Odpowiedź producenta oznacza jedynie, że w wersji standardowej (default) systemu alarmy generowane są w trybie dziennym i tygodniowym („yes currently that is done on a daily and weekly basis only.” – „Tak, obecnie odbywa się to tylko codziennie i co tydzień”.), ale nie oznacza to, że Mechanizm alarmowania w Systemie uniemożliwia generowanie alarmów w zadanych interwałach p.. 15 minut, 1 godzina, 8 godzin, dobowo, tygodniowo.

(16) Zgodnie z dotychczasowym stanowiskiem Odwołującego, złożoną ofertą oraz udzielonymi wyjaśnieniami potwierdzamy, iż system w wersji udostępnionej Zamawiającemu (w wyniku customizacji przeprowadzonej przez Shavit oraz SOCRADAR) będzie umożliwiał generowanie alarmów w interwałach czasowycp.np. 15 minut, 1 godzina, 8 godzin, dobowo, tygodniowo tj. zgodnie z OPZ.

System spełniał będzie również wymóg zawarty w rozdziale 9 Dostęp do interfejsu API systemu pkt. 19 OPZ, tj.: „19.

Producent musi zapewnić dedykowaną specyfikację typu OpenAPI do swojego API, która zawiera graficzny kreator zapytań 1) Graficzny kreator zapytań musi automatycznie generować kod dla wymaganego zapytania minimum za pomocą cURL i Python (v2 i v3).” (18) Jak wynika więc z powyższego, ww. funkcjonalność w chwili zadania pytania była w trakcie opracowywania. W tym zakresie wskazać należy, iż Graficzny Kreator Zapytań został przygotowany i dostarczony Zamawiającemu system posiadał będzie również tę funkcjonalność.

System spełniał też będzie wymóg wynikający z rozdział 4 - Funkcjonalność Wyszukiwania Zagrożeń pkt 37 – PZ - „37.

System Sandbox musi umożliwiać transfer i analizę plików o rozmiarze maximum 3GB”)”. (20) Korespondencja Zamawiającego z przedstawicielem producenta nie uwzględnia więc funkcji niestandardowych dostępnych dzięki customizacjom (licencja premium). Odpowiedź producenta w kontekście plików nie większych aniżeli 3GB oznacza jedynie, że wersja standardowa (dla klientów masowych) nie posiada mechanizmów automatycznych w tym zakresie. Przy czym już sam producent potwierdza, że w wersji standardowej wykonanie analiz plików większych aniżeli 3GB jest możliwe, przy czym wymaga operacji manualnych. Odwołujący zaoferował jednak system w wersji umożlwiający transfer i analizę plików o rozmiarze 3 GB, bez konieczności udziału analityków – pracy ludzkiej, co oznacza, iż spełnia wymogi warunków zamówienia. (…) (22) Przedstawiciel odnośnie do ww. funkcjonalności wskazał „However, this can ben customizable”, co oznacza, iż komentowaną funkcjonalność można dostosować – może to zostać skonfigurowane wg potrzeb klienta, tak jak to jest w przypadku wersji oferowanej przez Odwołującego. (23) W konsekwencji wskazać należy, iż Wykonawca gwarantuje Zamawiającemu dostarczenie dostępu do wersji customizowanej (rozbudowanej) platformy Producenta – dedykowanej dla klientów klasy Government, w której dostępne będzie automatyczne analizowanie plików o rozmiarze większym niż 3GB. Mechanizmy te są efektem rozbudów platformy standardowej przez partnerów takich jak Shavit. (24) Dostarczony Zamawiającemu System posiadał również będzie funkcjonalność z Opis Przedmiotu Zamówienia, wskazaną w pkt. 2 Funkcjonalność Rozpoznawania Zagrożeń w Cyberprzestrzeni, ppkt. 8 w brzmieniu: „System musi wspierać algorytmy Natural Language Processing oraz deep data analysis dostępne minimum dla języków: angielskiego, rosyjskiego, arabskiego, niemieckiego, chińskiego, japońskiego, francuskiego, polskiego oraz hiszpańskiego”. (25) Powyższe stanowi kolejną funkcjonalność dedykowaną dla klientów typu Agencje Rządowe - Government Agencies.

W dostarczaniu tego typu customizacji (rozbudów), które umieszczane są w platformie, a do których dostęp uzyskują tylko ściśle określeni klienci, a nie klienci standardowi, specjalizuje się firma Shavit. W konsekwencji Odwołujący gwarantuje, że w przypadku udzielenia mu zamówienia, Zamawiający otrzyma system spełniający wymagania OPZ także w tym zakresie (m.in. deep analysis) tj. dostęp do kompletnej, ponadstandardowej platformy Producenta. (26) Podsumowując ww. wywód, w wyniku błędnej i nieprawidłowej interpretacji postanowień dokumentów zamówienia, cała korespondencja z przedstawicielem producenta rozwiązania oferowanego przez Alfavox Software sp. z o.o., prowadzona była przez Zamawiającego w sposób, który nie mógł przesądzić ponad wszelką wątpliwość, że system w wersji oferowanej przez Odwołującego nie spełnia wymagań OPZ, ponieważ korespondencja odnosiła się do wersji standardowej, a nie tej którą oferuje Odwołujący. Zamawiający nie zapytał czy prowadzone są jakiekolwiek prace celem dokonania customizacji i na kiedy taka customizacja byłaby gotowa. Wskutek tego, producent – przedstawiciel SOCRADAR nie uwzględnił w swoich odpowiedziach do Zamawiającego kwestii, które są wynikiem customizacji, m.in. dzięki partnerom SOCRADAR, którym w tym wypadku jest podwykonawca Odwołującego, tj. Shavit Group. Podkreślić należy, iż producent wielokrotnie w swoich dotychczasowych odpowiedziach odwoływał się do słów typu „by default” lub „standard” – czyli w wersji standardowej (domyślnej). Stąd odpowiedzi producenta na niedoprecyzowane pytania Zamawiającego są tu nieadekwatne i nie mogły stanowić podstawy prawnej do odrzucenia oferty Alfavox Software sp. z o.o. Producent w swojej odpowiedzi odniósł się do funkcjonalności standardowych, dostępnych dla klientów masowych, nie uwzględniając dedykowanych funkcji platformy dostępnych dzięki customizacjom (rozbudowom) platformy przez partnerów takich jak podwykonawca Odwołującego – Shavit Group. (27) W konsekwencji wskazać należy, iż Zamawiający nieprawidłowo odrzucił ofertę Odwołującego na podstawie art. 226 ust. 1 pkt 5 PZP (…)

1. Bezzasadny wybór jako najkorzystniejszej oferty złożonej przez Trafford IT sp. z o.o. sp. k. (…) (4) Wykonawca musi wykazać się więc doświadczeniem w realizacji co najmniej dwóch umów których przedmiotem było zapewnienie licencji na dostęp do platformy internetowej (aplikacji webowej) w modelu Subskrypcji typu Software as a Service (SaaS) służącej do dostarczania informacji z zakresu Cyber Threat Intelligence, przy czym każda z tych umów powinna trwać co najmniej 12 miesięcy, oraz opiewać na wartość 1 miliona złotych brutto. (…) (7) Jak wynika z wnikliwej analizy podmiotowych środków dowodowych złożonych przez Trafford IT sp. z o.o. sp.k., podmiot ten celem wykazania spełnienia warunków udziału w postępowaniu w zakresie doświadczenia powołał się na doświadczenie potencjalne, które co najwyżej może uzyskać, a nie doświadczenie, które rzeczywiście posiada.

Mianowicie ze złożonych dokumentów przez bezpodstawnie wybranego jako najkorzystniejszego wykonawcę wynika, iż powołuje się on na doświadczenie w postaci zapewnienia licencji na dostęp do platformy internetowej (aplikacji webowej) w modelu Subskrypcji typu Software as a Service (SaaS) służącej do dostarczania informacji z zakresu Cyber Threat Intelligence, lecz umowy te w chwili upływu terminu składania ofert nie były realizowane przez okres 12 miesięcy. (…) (9) Skoro każda z ww. umów jest realizowana od (końcówki) listopada 2022 r., to przy uwzględnieniu terminu składania ofert przypadającego na 11 października 2023 r., wskazać należy, iż podmiot ten nie spełnia warunku udziału w postępowaniu i nie posiada doświadczenia w postaci zapewnienia licencji na dostęp do platformy internetowej (aplikacji webowej) w modelu Subskrypcji typu Software as a Service (SaaS) służącej do dostarczania informacji z zakresu Cyber Threat Intelligence przez 12 miesięcy. (10) Jest to równoznaczne z tym, iż bezzasadnie wybrany wykonawca nie przedstawił referencji potwierdzających należytą realizację usług przez wymagany okres 12 miesięcy, ponieważ w dniu składania ofert okres ten nie został osiągnięty. (11) Ponadto należy mieć na uwadze, iż w referencjach z dnia 24 października 2023 r. (W KIRU-44-50/2022) wystawionych przez Sąd Apelacyjny w Krakowie wskazano, iż „W dniu 09.12.2022r. Protokołem Odbioru Licencji dokonano odbioru dostarczonych licencji wymaganych do prawidłowego funkcjonowania Systemu. System został

wdrożony i odebrany Protokołem Odbioru Wdrożenia Systemu w dniu 27.02.2023r.”. Co oznacza, iż może umowę podpisano dnia 29 listopada 2022 r., jednak faktyczne udostępnienie licencji nastąpiło jeszcze później, bo w grudniu 2022 r. albo nawet na koniec lutego tego roku, gdyż dopiero wtedy został „wdrożony” system. (12) Co godne uwagi, mimo tego, iż umowy, które ujęte zostały w wykazie usług zostały zawarte w listopadzie 2022 r., to Trafford IT sp. z o.o. sp. k. w swoim wykazie wskazało, iż: a) w przypadku Sadu Apelacyjnego w Krakowie „umowa obejmowała zapewnienie licencji na okres 36 miesięcy***”; b) w przypadku Narodowego Banku Polskiego „umowa obejmowała zapewnienie licencji na okres 36 miesięcy***”. (13) Wybrany wykonawca powołuje się więc w Postępowaniu na doświadczenie potencjalne, które może nabyć, a nie doświadczenie, które faktycznie nabył przed upływem terminu składania ofert. Sam fakt, iż umowa została zawarta na okres 36 miesięcy nie dowodzi, iż doświadczenie takie zostanie, a tym bardziej że zostało nabyte. (…)” W związku z powyższym Odwołujący wniósł o nakazanie Zamawiającemu:

1. unieważnienia czynności odrzucenia oferty Odwołującego na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp, 2)unieważnienia czynności wyboru jako najkorzystniejszej oferty Trafford IT sp. z o.o. sp.k., 3)powtórzenia czynności badania i oceny ofert z uwzględnieniem oferty Odwołującego.

Pismem z dnia 04.12.2023 r. wykonawca Trafford IT sp. z o.o. sp.k., ul. Taneczna 18, 02-829 Warszawa (dalej:

„Przystępujący”) zgłosił przystąpienie do postępowania odwoławczego po stronie Odwołującego. Izba stwierdziła, że przystąpienie zostało dokonane skutecznie.

Pismem z dnia 15.12.2023 r. Zamawiający złożył odpowiedź na odwołanie, w której wniósł o jego oddalenie w zakresie zarzutu nr 1, jak też poinformował o tym, że „unieważnił wybór oferty najkorzystniejszej, przystąpił do ponownego badania oferty Przystępującego, a w dniu 8 grudnia 2023 r. dokonał ponownego wyboru oferty Przystępującego jako najkorzystniejszej w Postępowaniu” i w związku z tym wniósł o umorzenie postępowania odwoławczego w zakresie zarzutu nr 2.

Pismem z dnia 15.12.2023 r. również Przystępujący przedstawił swoją argumentację i złożył tożsame wnioski procesowe, jak Zamawiający.

Unieważnienie przez Zamawiającego czynności wyboru najkorzystniejszej oferty oznacza, że przestała istnieć czynność, wobec której odwołanie zostało wniesione w zakresie zarzutu nr 2. Tym samym w tymże zakresie nie istnieje tzw. substrat zaskarżenia, niezbędny do tego, aby Izba mogła rozpoznać odwołanie merytorycznie i stwierdzić, czy Zamawiający dokonując wyboru oferty Przystępującego dopuścił się naruszenia przepisów ustawy Pzp, czy nie.

Powyższe powoduje, że postępowanie odwoławcze w zakresie zarzutu nr 2 staje się zbędne, gdyż przedmiot zaskarżenia (w tym wypadku: czynność wyboru najkorzystniejszej oferty) nie istnieje, co stanowi podstawę umorzenia postępowania odwoławczego w tym zakresie w oparciu o art. 568 pkt 2 ustawy Pzp.

Należy jednocześnie zaznaczyć, że w piśmie z dnia 05.12.2023 r. informującym o unieważnieniu czynności wyboru najkorzystniejszej oferty Zamawiający wyraźnie zastrzegł, że „podtrzymuje w mocy czynność odrzucenia oferty Wykonawcy Alfavox Software Sp. z o.o. dokonaną 17.11.2023 r. i nie unieważnia jej”. Tym samym postępowanie odwoławcze nie podlega umorzeniu na podstawie art. 568 pkt 2 ustawy Pzp w zakresie zarzutu nr 1 dotyczącego odrzucenia oferty Odwołującego, dlatego też zarzut nr 1 został przez Izbę rozpoznany.

Krajowa Izba Odwoławcza ustaliła, co następuje:

Przedmiotem zamówienia jest zakup dostępu do platformy Cyber Threat Intelligence na poziom operacyjny.

Zamawiający wymienił w OPZ m.in. następujące wymagane funkcjonalności systemu:

1. Rozdział 4 Funkcjonalność Wyszukiwania Zagrożeń pkt 5 OPZ: „Dane zawartew Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”.
2. Rozdział 4 Funkcjonalność Wyszukiwania Zagrożeń pkt 26 OPZ: „Mechanizm alarmowania w Systemie musi umożliwiać generowanie alarmów w zadanych interwałach np. 15 minut, 1 godzina, 8 godzin, dobowo, tygodniowo.”
3. Rozdział 9 Dostęp do interfejsu API systemu pkt 19 OPZ: „Producent musi zapewnić dedykowaną specyfikację typu OpenAPI do swojego API, która zawiera graficzny kreator zapytań.
4. Graficzny kreator zapytań musi automatycznie generować kod dla wymaganego zapytania minimum za pomocą cURL i Python (v2 i v3).”
5. Rozdział 4 Funkcjonalność Wyszukiwania Zagrożeń pkt 37 ppkt 3 OPZ: „System Sandbox musi umożliwiać transfer i analizę plików o rozmiarze maximum 3GB”, 5)Rozdział 2 Funkcjonalność rozpoznawania zagrożeń w cyberprzestrzeni pkt 8 OPZ:„System musi wspierać algorytmy Natural Language Processing oraz deep data analysis dostępne minimum dla: 1) Angielski; 2) Rosyjski; 3) Arabski; 4) Niemiecki; 5) Chiński; 6) Japoński; 7) Francuski; 8) Polski; 9) Hiszpański.”

Pismem z dnia 16.10.2023 r. Zamawiający, na podstawie art. 223 ust. 1 ustawy Pzp, wezwał Odwołującego do złożenia wyjaśnień w zakresie spełnienia m.in. następujących wymogów:

1. „Dane zawarte w Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”, 2)„System musi wspierać algorytmy Natural Language Processing oraz deep data analysis dostępne minimum dla: a.

Angielski; b. Rosyjski; c. Arabski; d. Niemiecki; e. Chiński; f. Japoński; g. Francuski; h. Polski; i. Hiszpański.”

W piśmie z dnia 23.10.2023 r. Odwołujący udzielił twierdzącej odpowiedzi, że oferowany system spełnia ww. wymogi.

Pismem z dnia 27.10.2023 r. Zamawiający przedstawił swoje wątpliwości i na podstawie art. 223 ust. 1 ustawy Pzp, wezwał Odwołującego do złożenia wyjaśnień w zakresie spełnienia m.in. następujących wymogów:

1. „System Sandbox musi umożliwiać transfer i analizę plików o rozmiarze maximum 3GB”, 2)„Mechanizm alarmowania w Systemie musi umożliwiać generowanie alarmów w zadanych interwałach np. 15 minut, 1 godzina, 8 godzin, dobowo, tygodniowo”, 3)„Dane zawarte w Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”, 4)„Producent musi zapewnić dedykowaną specyfikację typu OpenAPI do swojego API, która zawiera graficzny kreator zapytań. Graficzny kreator zapytań musi automatycznie generować kod dla wymaganego zapytania minimum za pomocą cURL i Python (v2 i v3).”

W piśmie z dnia 03.11.2023 r. Odwołujący udzielił wyjaśnień, a dodatkowo wskazał: „Na wstępie podkreślamy, iż przy takim rodzaju przedmiotu zamówienia wysoce istotnym jest kwestia tzw. customizacji, a więc spersonalizowania danej usługi, w tym przypadku platformy SOC Radar pod potrzeby danego klienta. Ani Wykonawca, ani podmiot udostępniający zasoby, nie mają wiedzy z jakiej wersji platformy korzystał w tym przypadku Zamawiający. W każdym razie Wykonawca w porozumieniu z Podmiotem udostępniającym zasoby ponownie zweryfikował zgodność oferowanego rozwiązania z wymogami Zamawiającego i analiza ta przyniosła wynik pozytywny. Wersja oferowanego w Postępowaniu rozwiązania SOC Radar jest w pełni zgodna z wymogami Zamawiającego wynikającymi z Opisu Przedmiotu Zamówienia (…). Istotnym jest, iż podmiot udostępniający zasoby Shavit Group – Security Defense and

Cyber- Tech Ltd (dalej jako: „Shavit Group”), ma możliwość używania customizowanych funkcji systemu SOC Radar, co oznacza, iż Zamawiający w toku badania oferty korzystał z wersji, która nie posiada wszystkich funkcjonalności wymaganych w Postępowaniu w przeciwieństwie do wersji Systemu oferowanej w tym Postępowaniu przez Alfavox So^ware sp. z o.o. Istnieje więc możliwość spersonalizowania oferowanej usługi pod danego klienta, zgodnie z jego wymogami (co ma odzwierciedlenie m.in. w cenie) także stąd wynikają różnice stwierdzone przez Zamawiającego”.

Pismem z dnia 17.11.2023 r. Zamawiający poinformował o wyborze jako najkorzystniejszej oferty Przystępującego oraz o odrzuceniu oferty Odwołującego na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp. W uzasadnieniu Zamawiający wskazał m.in.:

„W toku badania oferty złożonej przez Wykonawcę Alfavox Software Sp. z o.o., Zamawiający zażądał dwukrotnie wyjaśnień dotyczących treści złożonej oferty w zakresie zaoferowanego przez Wykonawcę dostępu do platformy internetowej (aplikacji webowej): SOC Radar (…) –Odpowiedzi Wykonawcy Alfavox Software Sp. z o.o. budziły jednak dalsze wątpliwości Zamawiającego, dlatego też zwróciliśmy się do producenta oferowanej platformy internetowej firmy SOCRADAR CYBER INTELLIGENCE INC. (…) Pisząc do producenta, zaznaczono, że prosimy o odpowiedź w kontekście najbogatszej wersji platformy, posiadającej wszystkie funkcjonalności, w wersji której nie trzeba w późniejszym terminie uzupełniać. (…) Z otrzymanej przez producenta odpowiedzi wprost wynika, że oferowany System SOCRadar nie jest w stanie prezentować starszych danych niż te z lipca 2021 r., co oznacza, że ww. System nie spełnia jednego z warunków zamówienia, wymogu opisanego w OPZ w Rozdziale 4. Funkcjonalność Wyszukiwania Zagrożeń pkt. 5, tj. „Dane zawarte w Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”. (…) Z otrzymanej przez producenta odpowiedzi, że alerty mogą być obecnie tworzone tylko w ujęciu dziennym oraz tygodniowym, wprost wynika, że system SOCRadar nie posiada możliwości kreowania alertów w interwałach rzadszych niż dzienne tj. 15 minut, 1 godzina, 8 godzin, co oznacza, że ww. System nie spełnia jednego z warunków zamówienia, wymogu opisanego w OPZ w Rozdziale 4 Funkcjonalność Wyszukiwania Zagrożeń pkt. 26 (…) Z otrzymanej przez producenta odpowiedzi wprost wynika, że oferowany System SOCRadar nie posiada wymaganej przez Zamawiającego w OPZ funkcjonalności tj. graficznego kreatora zapytań, który automatycznie generuje kod dla wymaganego zapytania minimum za pomocą cURL i Python (v2 i v3), co za tym idzie nie spełnia jednego z warunków zamówienia wynikającego z OPZ. Dodatkowo producent przyznał, że dopiero pracują nad wdrożeniem tego rozwiązania. (…) Z otrzymanej przez producenta odpowiedzi wprost wynika, że oferowany System SOC Radar nie posiada wymaganej przez Zamawiającego w OPZ funkcjonalności tj. możliwości transferu i analizy plików o rozmiarze maximum 3GB w Systemie Sandbox, co za tym idzie nie spełnia on jednego z warunków zamówienia wynikającego z OPZ. (…) Z otrzymanej przez producenta odpowiedzi wprost wynika, że oferowany System nie posiada wymaganej przez Zamawiającego w OPZ funkcjonalności tj. nie wykonuje głębokiej analizy danych dla wszystkich z wymienionych języków, co za tym idzie nie spełnia on jednego z warunków zamówienia wynikającego z OPZ. System producenta SOCRadar nie posiada w pełnym zakresie ww. wymaganej funkcjonalności, co jest niezgodne z OPZ. (…) Ponadto Zamawiający podkreśla, że zgodnie z postanowieniem OPZ Przedmiot Zamówienia pkt. 5 „System musi posiadać wyłącznie scentralizowane bazy danych gwarantujące jednakowy dostęp dla wszystkich użytkowników. Nie dopuszcza się rozwiązania kreującego indywidualną bazę dla indywidualnych klientów lub użytkowników.” oraz pkt 6.

„System musi być udostępniony w formie dostępu do chmurowej platformy Producenta. (…)”. Dlatego nie jest dopuszczalne, aby Wykonawca/Podwykonawca oferował rozwiązanie będące autorską "nakładką" na platformę producenta lub uwzględniające funkcjonalności dopełniane w sposób manualny przez zatrudniane przez nich osoby. (…)”.

Krajowa Izba Odwoławcza rozpoznając na rozprawie złożone odwołanie i uwzględniając dokumentację z niniejszego postępowania o udzielenie zamówienia publicznego oraz stanowiska Stron i Przystępującego złożone na piśmie i podane do protokołu rozprawy, zważyła, co następuje.

W pierwszej kolejności Izba ustaliła wystąpienie przesłanek z art. 505 ust. 1 ustawy Pzp, tj. istnienie po stronie Odwołującego interesu w uzyskaniu zamówienia oraz możliwość poniesienia przez niego szkody z uwagi na kwestionowane czynności Zamawiającego.

Ponadto Izba stwierdziła, że nie została wypełniona żadna z przesłanek ustawowych skutkujących odrzuceniem odwołania, wynikających z art. 528 ustawy Pzp.

Zgodnie z art. 226 ust. 1 pkt 5 ustawy Pzp, zamawiający odrzuca ofertę, jeżeli jej treść jest niezgodna z warunkami zamówienia.

Zgodnie z art. 223 ust. 1 ustawy Pzp, 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 pierwszej kolejności należy stwierdzić, że w niniejszej sprawie nie jest sporne, że wskazany przez Odwołującego w ofercie system SOC Radar nie jest zgodny z wymogami zawartymi w OPZ i wyszczególnionymi przez Zamawiającego w piśmie informującym o odrzuceniu tej oferty. Jednocześnie jednak w odpowiedzi na wezwanie Zamawiającego do złożenia wyjaśnień Odwołujący wskazał, że oferowany przez niego system zostanie scustomizowany, czyli dostosowany do tych wymogów. Sporne zatem w tej sprawie jest to, czy customizacja była w ogóle dopuszczalna w przedmiotowym postępowaniu, a jeśli tak – to czy jej dokonanie pozwala uznać ofertę Odwołującego za zgodną z warunkami zamówienia.

Odnosząc się zatem do kwestii dopuszczalności customizacji systemu należy się zgodzić z Odwołującym, że niezgodność z warunkami zamówienia, o której mowa w art. 226 ust. 1 pkt 5 ustawy Pzp, zachodzi wówczas, gdy oferta wykonawcy jest niezgodna z jasno wyrażonym postanowieniem zawartym w dokumentach wskazanych w art. 7 pkt 29 ustawy Pzp, tj. w szczególności w opisie przedmiotu zamówienia, w wymaganiach związanych z realizacją zamówienia, w kryteriach oceny ofert, w wymaganiach proceduralnych lub w projektowanych postanowieniach umowy w sprawie zamówienia publicznego. Przy czym niezgodność ta również musi mieć charakter niewątpliwy. Zamawiający nie może zatem odrzucić oferty w oparciu o art. 226 ust. 1 pkt 5 ustawy Pzp, jeżeli nie można jednoznacznie stwierdzić, jaki wymóg wynika z warunków zamówienia lub czy oferta wykonawcy rzeczywiście jest niezgodna z warunkami zamówienia, gdyż stanowiłoby to naruszenie nie tylko ww. przepisu, ale także zasad udzielania zamówień, o których mowa w art. 16 ustawy Pzp.

Jednocześnie jednak wyżej wskazane reguły stosowania art. 226 ust. 1 pkt 5 ustawy Pzp nie oznaczają, że w niniejszym postępowaniu jasno wyrażone postanowienie SW Z musiałoby brzmieć np.: „zakaz customizacji systemu”.

Zakaz taki może być bowiem równie jasno wyrażony w inny sposób, np. poprzez opisanie takich wymagań, które wykluczają możliwość oferowania systemu wymagającego customizacji. W ocenie Izby Zamawiający, pomijając już nawet, że w żadnym postanowieniu OPZ nie przewidział customizacji i żadnych prac dostosowawczych w ramach systemu, wskazał w szczególności następujące wymagania świadczące o niedopuszczalności zaoferowania systemu scustomizowanego:

1. wykonawca ma udostępnić oprogramowanie w terminie 2, 3 lub 5 dni od dnia zgłoszenia wykonawcy przez Zamawiającego osób kontaktowych po stronie Podmiotów KSC wrazz listą Użytkowników, dla których wymagane jest założenie konta (rozdział XV pkt 1.2. SW Z), co z kolei ma nastąpić nie później, niż w ciągu 3 dni roboczych od dnia zawarcia umowy (§ 4 ust. 3 projektu umowy), 2)wykonawca ma przekazać dokumentację użytkową w terminie 5 dni od dnia zawarcia umowy (§ 4 ust. 7 projektu umowy) i ma ona być napisana w taki sposób, by osoba posiadająca do niej dostęp była w stanie korzystać ze wszystkich dostępnych w systemie funkcjonalności w przypadku, gdyby nie posiadała wiedzy co do określonych funkcjonalności, w tym obejmować musi dokładny opis wszystkich funkcjonalności (rozdział 11 pkt 3 ppkt 1 OPZ), 3)Zamawiający nie przewiduje dostępu wykonawcy do infrastruktury teleinformatycznej Zamawiającego (§ 3 ust. 2 projektu umowy), 4)Skuteczność Systemu musi być opisana i sklasyfikowana w publicznie dostępnych raportach i analizach, przynajmniej Frost Radar: Cyber Threat Intelligence Market lub pokrewnych (pkt 4, str. 2 OPZ).

Ww. postanowienia SW Z, w tym OPZ i projektu umowy wskazują, że Zamawiający nie dopuszczał customizacji systemu. Świadczą o tym choćby bardzo krótkie terminy na udostępnienie samego oprogramowania, jak też na dostarczenie dokumentacji użytkowej zawierającej dokładny opis wszystkich funkcjonalności, które wykluczają realną możliwość wykonania prac dostosowawczych systemu. Nie jest przy tym wiarygodna argumentacja Odwołującego, zgodnie z którą może on dokonać customizacji jeszcze przed zawarciem umowy, gdyż pomijając już nawet ryzyko ekonomiczne takich działań w sytuacji gdy wykonawca nie wie przecież, czy jego oferta zostanie wybrana, przede wszystkim należy stwierdzić, że w dalszym ciągu czas na dostosowanie czy wręcz wytworzenie szeregu funkcjonalności wymaganych w OPZ byłby za krótki, co potwierdziło się choćby podczas prezentacji scustomizowanego systemu na rozprawie (o czym w dalszej części uzasadnienia).

Zamawiający wprost też wskazał, że nie zamierza udostępnić wykonawcy własnej infrastruktury teleinformatycznej, co oznacza, że zakłada dostarczenie oprogramowania standardowego, które nie będzie wymagało weryfikacji w zakresie współpracy z posiadaną przez niego infrastrukturą teleinformatyczną.

Wreszcie wymóg opisania i sklasyfikowania skuteczności systemu w publicznie dostępnych raportach i analizach jasno pokazuje, że Zamawiający oczekiwał zaoferowania systemu już istniejącego i w związku z tym możliwego do oceny/klasyfikacji w ww. publicznie dostępnych raportach i analizach, nie zaś systemu, który po customizacji jest w istocie produktem nowym i co za tym idzie – nieistniejącym w takich opracowaniach.

Reasumując, brak zawarcia w dokumentach zamówienia postanowienia o „zakazie customizacji” nie oznacza, że Zamawiający ją dopuścił. Treść wyżej wskazanych bowiem postanowień SW Z, w tym OPZ i projektu umowy, świadczy o tym, że Zamawiający oczekiwał zaoferowania gotowego, standardowego produktu, który nie będzie wymagał dostosowywania do jego wymagań. Powyższe prowadzi do wniosku, że customizacja oferowanego systemu nie była dozwolona w przedmiotowym postępowaniu. Skoro zatem customizacja nie była dozwolona, a wskazany w ofercie Odwołującego system SOC Radar bez dokonania customizacji nie posiada wszystkich wymaganych funkcjonalności (fakt bezsporny), to znaczy, że oferta Odwołującego nie jest zgodna z warunkami zamówienia i podlega odrzuceniu na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp.

Jednocześnie, abstrahując już nawet od niedopuszczalności dokonania customizacji systemu w niniejszym postępowaniu, Izba uznała także za słuszne uwagi Zamawiającego i Przystępującego, dotyczące braku w ofercie Odwołującego jakiejkolwiek wzmianki o tym, że oferuje on system scustomizowany. Informacja na ten temat nie pojawiła się: - ani w pkt 2 formularza oferty („Oferujemy dostęp do platformy internetowej (aplikacji webowej): SOC Radar”), - ani w pkt 11 formularza oferty dotyczącym podwykonawcy Shavit Group Ltd i zakresu prac, jakie mają mu zostać powierzone („Udzielenie licencji na rozwiązanie chmurowe w tym Udostępnienie oraz dokumentacja użytkownika, włącznie z raportami i niezbędnymi dostępami do platformy systemowej, internetowej, w tym dostęp do serwera umieszczonego w chmurze, wsparcie producenta zgodnie z OPZ, zapewnienie certyfikatów wymaganych zamówieniem”), mimo że obecnie Odwołujący twierdzi, że to właśnie z pomocą Shavit Group Ltd customizacja ma być ma dokonana, - ani w zobowiązaniu Shavit Group Ltd jako podmiotu udostępniającego zasoby (m.in. „Podmiot udostępniający zapewni w toku realizacji zamówienia dostęp do platformy internetowej (aplikacji webowej) w modelu Subskrypcji typu Software as a Service (SaaS) służącej do dostarczania informacji z zakresu Cyber Threat Intelligence (rozpoznawanie zagrożeń w cyberprzestrzeni) o poziomie operacyjnym, w tym dostęp do serwera zamieszczonego w chmurze, wraz z jednoczesnym zagwarantowaniem wsparcia przy wdrożeniu rzeczonego rozwiązania”).

Należy przy tym podkreślić, że nie może być tak, że wykonawca oferuje jakiś konkretny produkt i dopiero po otrzymaniu wezwania do złożenia określonych wyjaśnień czy dokumentów w związku z powzięciem przez zamawiającego wątpliwości co do zgodności tego produktu z warunkami zamówienia, stwierdza, że w istocie jego oferta dotyczy produktu zmienionego w sposób dostosowujący go do wymagań opisanych w dokumentach zamówienia. Takie sytuacje noszą znamiona zmiany oferty, a zatem wymagają zbadania pod kątem wystąpienia działań niedozwolonych w myśl art. 223 ust. 1 ustawy Pzp. W przedmiotowej sprawie oznacza to, że niezależnie od niedopuszczalności customizacji systemu, ujawnienie przez Odwołującego dopiero po złożeniu oferty, że w istocie nie oferuje on oryginalnego systemu SOC Radar, ale system scustomizowany, również nie mogłoby być przez Zamawiającego, w świetle art. 223 ust. 1 ustawy Pzp, zaakceptowane, co ponownie prowadzi do wniosku, że oferta Odwołującego podlegała odrzuceniu na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp.

Niezależnie od powyższych ustaleń, w tym przede wszystkim zakazu customizacji systemu w przedmiotowym postępowaniu, należy odnieść się do okazanych na rozprawie funkcjonalności systemu SOC Radar po dokonanej customizacji. Na wniosek Odwołującego Izba przeprowadziła bowiem dowód z prezentacji scustomizowanego w międzyczasie systemu i w ocenie Izby dowód ten wykazał niezgodność systemu (nawet po customizacji) z warunkami zamówienia.

W ramach prezentacji Odwołujący okazywał działanie 5 funkcjonalności wymienionych przez Zamawiającego w piśmie informującym o odrzuceniu oferty, tj.:

1. „Dane zawarte w Systemie muszą pochodzić z przynajmniej ostatnich 10 lat”, 2.„Mechanizm alarmowania w Systemie musi umożliwiać generowanie alarmów w zadanych interwałach np. 15 minut, 1

godzina, 8 godzin, dobowo, tygodniowo”, 3.„Producent musi zapewnić dedykowaną specyfikację typu OpenAPI do swojego API, która zawiera graficzny kreator zapytań 1) Graficzny kreator zapytań musi automatycznie generować kod dla wymaganego zapytania minimum za pomocą cURL i Python (v2 i v3)”, 4.„System Sandbox musi umożliwiać transfer i analizę plików o rozmiarze maximum 3GB”)”, 5.„System musi wspierać algorytmy Natural Language Processing oraz deep data analysis dostępne minimum dla języków: angielskiego, rosyjskiego, arabskiego, niemieckiego, chińskiego, japońskiego, francuskiego, polskiego oraz hiszpańskiego”.

Przede wszystkim należy zauważyć, że w ramach prezentacji funkcjonalności z pkt 1 (dane z 10 lat), mimo że sama możliwość wybrania danego okresu czasu została okazana, Odwołujący nie był w stanie pokazać z żadnego okresu danych dotyczących któregokolwiek z incydentów wymienionych np. w dowodach złożonych przez Przystępującego (dane o wyciekach ze stron policji, MON i KPRM) ani nawet danych o znanym powszechnie incydencie z Alab Laboratoria, czy też po prostu danych o wyciekach z określonych jednostek. Odwołujący powoływał się przy tym na podstawę odrzucenia swojej oferty, na potrzebę skontaktowania się z właściwą osobą znającą działanie systemu po customizacji, ewentualnie proponował ogólne okazywanie danych w języku polskim.

W zakresie funkcjonalności z pkt 2 (mechanizm alarmowania), mimo wygenerowania jakichś losowych alarmów z tytułem, treścią i częstotliwością, Odwołujący nie był w stanie pokazać ich treści merytorycznej mającej wartość użytkową. Przykładowo, po zawężeniu typu wydarzeń do „wyborów” nie pokazały się żadne odpowiadające temu typowi incydenty, za to pokazały się informacje dotyczące np. Samsung Galaxy, którego związku z wyborami Odwołujący nie wyjaśnił i ponownie powoływał się na potrzebę uzyskania pomocy ze strony przeszkolonej osoby oraz na podstawy odrzucenia swojej oferty.

W zakresie funkcjonalności z pkt 3 (graficzny kreator zapytań) problemem okazała się wersja Python nr 3, której Odwołujący nie był w stanie wykazać i poprzestał na ustnym zapewnieniu, że kod jest kompatybilny z każdą wersją, tj. nr 2 i nr 3.

W trakcie prezentowania funkcjonalności z pkt 4 (transfer i analiza plików o rozmiarze max. 3GB) Odwołujący pokazał, że wyświetla się wielkość pliku, jego nazwa i status analizy (czy jest zainfekowany, czy nie). Nie był jednak w stanie pokazać działania funkcjonalności na testowym pliku Eicar („ze względu na ograniczenia techniczne”), ani zaprezentować analizy, dlaczego system pokazał dany obiekt jako złośliwy (Odwołujący pokazał jedynie na pliku o rozmiarze mniejszym niż wymagany – „file is clean”).

W zakresie funkcjonalności z pkt 5 (Natural Language Processing) Odwołujący pokazał, że dane wyświetlają się w różnych wymaganych przez Zamawiającego językach, ale jednocześnie przy zawężeniu wyszukiwania do „Polski” nie potrafił wyjaśnić, jaki związek z Polską mają wyświetlone ciągi cyfr (wyraził przypuszczenie, że mogą to być numery kont Polaków). Z kolei po zawężeniu wyszukiwania do słów: „przeciek”, „wyciek”, „leak”, „kprm” nie ukazały się żadne dane, a po wpisaniu „kprm.gov.pl” pokazały się m.in. linki z wynikami naborów do pracy w KPRM. Odwołujący stwierdził też, że potrzebuje pomocy analityka, aby utworzyć zapytanie pokazujące nie tylko suche dane, ale także ich kontekst z danego języka.

Opisana wyżej prezentacja 5 funkcjonalności pokazała, że system nawet po customizacji nie spełnia wymogów OPZ w tym zakresie. Należy przy tym zgodzić sięz Odwołującym, że podstawy odrzucenia oferty nie mogą być w postępowaniu odwoławczym rozszerzane. Nie oznacza to jednak, że oceniając prezentowane funkcjonalności można stracić z pola widzenia cel, dla którego system jest w ogóle zamawiany. Celem tym jest natomiast uzyskiwanie informacji istotnych dla bezpieczeństwa informatycznego państwa. Nie można zatem, powołując się na podstawy odrzucenia oferty, przykładowo pokazać, że system daje możliwość wybrania jakiegoś okresu czasu aż do 10 lat, ale trzeba także pokazać, że finalnie z tego okresu pokażą się użyteczne dla Zamawiającego dane. Podobnie nie wystarczy pokazać, że do systemu dodano możliwość ustawienia wymaganych interwałów czasowych dla wygenerowania alarmów, ale trzeba pokazać, że po takim ustawieniu rzeczywiście wygenerują się merytoryczne informacje o tych alarmach. Jako kolejny przykład można wskazać, że nie wystarczy pokazać, że system operuje różnymi językami, ale trzeba pokazać, że to co się w tych językach ukazuje ma sens z punktu widzenia potrzeb Zamawiającego. Nie chodzi zatem o to, by formalnie stworzyć w systemie informatycznym jakąś funkcjonalność, ale o to, by funkcjonalność ta rzeczywiście działała i pozwalała na uzyskanie użytecznych informacji. Innymi słowy: dodane w wyniku customizacji funkcjonalności muszą zapewniać możliwość rzeczywistego korzystania z systemu zgodnie z potrzebami Zamawiającego. W związku z tym zasada niedopuszczalności rozszerzania w postępowaniu odwoławczym podstaw odrzucenia oferty nie może być sprowadzana do absurdu, tj. do takiego jej rozumienia, zgodnie z którym dla wykazania niezasadności odrzucenia oferty wystarczy formalne, pozorne spełnienie określonych wymogów, ale konieczne jest wykazanie rzeczywistego spełnienia tych wymogów. W tym wypadku oznacza to, że nie wystarczy stworzenie w systemie „na pierwszy rzut oka” jakichś funkcjonalności, ale funkcjonalności te muszą działać zgodnie z celem, dla którego miały zostać stworzone.

Z przyczyn opisanych powyżej zaprezentowany przez Odwołującego na rozprawie scustomizowany system SOC Radar nie spełnia wymogów wymienionych w piśmie o odrzuceniu oferty, co oznacza, że nawet gdyby w przedmiotowym postępowaniu customizacja była dopuszczalna i nawet gdyby nie doszło w tym zakresie do zmiany oferty, to i tak z powodu pokazanego na rozprawie niedziałania ww. 5 funkcjonalności oferta podlegałaby odrzuceniu jako niezgodna z warunkami zamówienia (art. 226 ust. 1 pkt 5 ustawy Pzp).

Jedynie na marginesie należy dodać, że wyniki prezentacji tak szybko scustomizowanego przez Odwołującego systemu pokazały, w ocenie Izby, że wprowadzenie brakujących funkcjonalności w sposób zapewniający ich rzeczywiste działanie i rzeczywiste zaspokojenie potrzeb Zamawiającego, wymaga znacznie więcej czasu niż przeznaczył na to Odwołujący. Powyższe potwierdza z kolei, że m.in. krótki termin przewidziany przez Zamawiającego na udostępnienie oprogramowania i przekazanie dokumentacji użytkowej z góry wykluczał możliwość zaoferowania systemu, który będzie dopiero customizowany w celu spełnienia wymogów OPZ.

W tym stanie rzeczy Izba nie odnosi się już do korespondencji Zamawiającego i Odwołującego z producentem SOC Radar, gdyż bez względu na treść tej korespondencji, w szczególności ustalony przez Izbę zakaz customizacji systemu obowiązujący w niniejszym postępowaniu i wyniki prezentacji 5 funkcjonalności systemu po customizacji, przesądzają o zasadności odrzucenia oferty Odwołującego na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp.

Wobec powyższego, Izba postanowiła jak w sentencji wyroku, orzekając na podstawie art. 552 ust. 1, art. 553 i art. 554 ust. 1 ustawy Pzp.

Orzeczenie Izby zostało wydane w oparciu o dokumentację postępowania o udzielenie zamówienia oraz stanowiska Stron i Przystępującego przedstawione na rozprawie i w pismach procesowych.

O kosztach postępowania orzeczono stosownie do wyniku, na podstawie art. 574 i art. 575 ustawy Pzp oraz w oparciu o

§ 8 ust. 2 pkt 1 w zw. z § 5 pkt 1 i pkt 2 lit. b), rozporządzenia w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu d odwołania (Dz.U. z 2020 r. poz. 2437).

Przewodnicząca

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