Sygn. akt: KIO 3584/23
WYROK
z dnia 19 grudnia 2023 r.
Krajowa Izba Odwoławcza – w składzie:
Przewodnicząca:Emilia Garbala
Protokolant:Rafał Komoń
po rozpoznaniu na rozprawie w dniu 18 grudnia 2023 r. w Warszawie odwołania wniesionego do Prezesa Krajowej Izby
Odwoławczej w dniu 27 listopada 2023 r. przez wykonawcę Alfavox Software sp. z o.o., ul. Ziębicka 35, 60-164
Poznań,
w postępowaniu prowadzonym przez zamawiającego: Ministerstwo Cyfryzacji, ul. Królewska 27, 00-060 Warszawa,
przy udziale wykonawcy Trafford IT sp. z o.o. sp.k., ul. Taneczna 18, 02-829 Warszawa zgłaszającego przystąpienie
do postępowania odwoławczego po stronie zamawiającego,
orzeka:
1.umarza postępowanie odwoławcze w zakresie zarzutu nr 2,
2.w pozostałym zakresie oddala odwołanie,
3.kosztami postępowania obciąża odwołującego: Alfavox Software sp. z o.o., ul. Ziębicka 35, 60-164 Poznań, i:
3.1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych
zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania,
3.2.zasądza od odwołującego: Alfavox Software sp. z o.o., ul. Ziębicka 35, 60-164 Poznań, na rzecz zamawiającego:
Ministerstwa Cyfryzacji, ul. Królewska 27, 00-060 Warszawa, kwotę 3 600 zł 00 gr (słownie: trzy tysiące sześćset
złotych zero groszy) tytułem zwrotu kosztów wynagrodzenia pełnomocnika
Stosownie do art. 579 ust. 1 i art. 580 ust. 1 i 2 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (t.j.
Dz.U. z 2023 r. poz. 1605 ze zm.) na niniejszy wyrok - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za
pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie.
Przewodnicząca:…………………………
Sygn. akt KIO 3584/23
UZASADNIENIE
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.
2. 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. (…)
3. 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.
4. 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 (…)
5. 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ń.
1) Graficzny kreator zapytań musi automatycznie generować kod dla wymaganego zapytania minimum za pomocą
cURL i Python (v2 i v3).”
4)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: ...…………………..