KIO 3313/25

Sygn. akt: KIO 3313/25

POSTANOWIENIE

Warszawa, dnia 23.09.25 r.

Krajowa Izba Odwoławcza - w składzie:

Przewodnicząca: Agata Mikołajczyk

Członkowie: M.M.

M.R.

po rozpoznaniu na posiedzeniu niejawnym bez udziału Stron w dniu 23 września 2025 r. w Warszawie odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 7 sierpnia 2025 r. przez wykonawcę: Comarch Polska S.A. z/s w Krakowie (Al. Jana Pawła II 39a, 31­864 Kraków) w postępowaniu prowadzonym przez zamawiającego: Urząd Komunikacji Elektronicznej z/s w Warszawie (ul. Giełdowa 7/9, 01­211 Warszawa),

postanawia:

1.Umorzyć postępowanie odwoławcze;

2.Nakazać zwrot z rachunku bankowego Urzędu Zamówień Publicznych na rzecz
‎Odwołującego: Comarch Polska S.A. z/s w Krakowie (Al. Jana Pawła II 39a, 31­864 Kraków) kwotę 13.500 zł 00 gr (słownie: trzynaście tysięcy pięćset złotych zero groszy), stanowiącą 90 % kwoty wpisu uiszczonego przez Odwołującego od odwołania.

Na orzeczenie - 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 - Sądu Zamówień Publicznych.

………………………………………

………………………………………

………………………………………

Sygn. akt: KIO 3313/25

Uzasadnienie

Odwołanie zostało wniesione do Prezesa Krajowej Izby Odwoławczej w dniu 7 sierpnia
‎2025 r. przez wykonawcę Comarch Polska S.A. z/s w Krakowie (Odwołujący) w postępowaniu prowadzonym w trybie przetargu nieograniczonego na podstawie ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z 2024 r. poz. 1320 ze zm.), [ustawa Pzp lub Pzp lub Ustawa PZP] przez Zamawiającego: Urząd Komunikacji Elektronicznej z/s w Warszawie. Przedmiotem zamówienia publicznego jest: „Zaprojektowanie, budowa wdrożenie i serwis Systemu finansowo księgowo-kadrowo-płacowego wraz z migracją danych i Pracami Analityczno-Rozwojowymi”. Ogłoszenie o zamówieniu zostało opublikowane 28/07/2025 w Dz. Urz. UE Nr: 492381-2025. Wykonawca podał: (…) Odwołujący wnosi odwołanie od czynności sformułowania treści dokumentacji zamówienia i ogłoszenia niezgodnie z PZP zarzucając Zamawiającemu naruszenie:

1. art. 112 ust. 1 PZP w zw. z art. 112 ust. 2 pkt 4 PZP w zw. z art. 16 pkt 3 PZP poprzez określenie warunków udziału w postępowaniu dotyczących zdolności technicznej i zawodowej w zakresie doświadczenia wykonawcy w sposób w sposób nieproporcjonalny do przedmiotu zamówienia;

2. art. 239 ust. 1 i 2 PZP w zw. z art. 240 ust. 1 i 2 PZP w zw. z art. 241 ust. 1 PZP w zw. z art. 16 PZP poprzez sformułowanie kryterium oceny ofert „Ocena próbki” w sposób niejednoznaczny i niezrozumiały, poprzez sformułowanie kryterium oceny ofert „Ocena próbki” w zakresie funkcjonalności niezwiązanych z przedmiotem zamówienia, poprzez zaniechanie określenia w dokumentach zamówienia kryterium oceny ofert „Ocena próbki” w sposób pozwalający na wybór najkorzystniejszej oferty z zachowaniem uczciwej konkurencji i równego traktowania wykonawców, a sformułowanie kryterium oceny ofert „Ocena próbki” w sposób pozostawiający Zamawiającemu nieograniczoną swobodę wyboru najkorzystniejszej oferty oraz uniemożliwiający weryfikację i porównanie poziomu oferowanego wykonania przedmiotu zamówienia na podstawie informacji przedstawianych w ofertach, a także poprzez sformułowanie kryterium oceny ofert „Ocena próbki” w sposób niepozwalający na wybór najkorzystniejszej oferty tj. oferty przedstawiającej najkorzystniejszy stosunek jakości do ceny, a w konsekwencji z naruszeniem zasady przejrzystości, proporcjonalności i zachowania uczciwej konkurencji i równego traktowania wykonawców;

3. art. 99 ust. 1 i 4 PZP w zw. z art. 16 pkt 3 PZP w zw. z art. 353¹ k.c. w zw. z art. 8 ust. 1 PZP poprzez wadliwe (niejednoznaczne, niewyczerpujące, bez dokładnych i zrozumiałych określeń) sformułowanie definicji Oprogramowania Standardowego i Oprogramowania Dedykowanego oraz poprzez nieproporcjonalne i niejednoznaczne żądanie przeniesienia praw autorskich i kodów źródłowych do Oprogramowania Standardowego, a w konsekwencji naruszenie zasady, proporcjonalności i zachowania uczciwej konkurencji i równego traktowania wykonawców;

4. 99 ust.1 i ust. 4 PZP w zw. z art. 16 PZP w zw. z art. 8 ust. 1 PZP w związku z art. 3531 k.c. poprzez zaniechanie opisu zobowiązań wykonawcy z uwzględnieniem wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, w szczególności na jej wycenę, a to zaniechanie jednoznacznego i wyczerpującego zwymiarowania (w roboczogodzinach) zobowiązań Wykonawcy wynikających z opisanego w § 20 Umowy tzw. Exit Plan, co oznacza, iż złożone oferty nie będą porównywalne, co godzi w zasadę zachowania uczciwej konkurencji i równego traktowania wykonawców. (…)

Odwołujący wniósł o uwzględnienie odwołania oraz podał: „Żądania odwołania zostały przedstawione pod uzasadnieniem każdego z zarzutów”.

Wykonawca także wskazał: (…) Interes Odwołującego oraz możliwość poniesienia przez Odwołującego szkody Odwołujący ma interes w uzyskaniu zamówienia, ponieważ jest podmiotem zdolnym do jego wykonania, posiadającym w tym zakresie odpowiednie kompetencje i doświadczenie. Poprzez sformułowanie przez Zamawiającego postanowień SWZ w sposób naruszający przepisy ustawy Odwołujący może być pozbawiony możliwości złożenia oferty i uzyskania zamówienia, tym samym w wyniku naruszenia przez Zamawiającego przepisów ustawy Odwołujący może ponieść szkodę polegającą na braku uzyskania przedmiotowego zamówienia. Ponadto Odwołujący wskazuje, że ma interes we wniesieniu odwołania, gdyż w wyniku uregulowania zapisów SWZ w sposób naruszający przepisy ustawy został pozbawiony uczestnictwa w postępowaniu na uczciwych i zgodnych z prawem warunkach, w tym możliwości złożenia ważnej i konkurencyjnej oferty przez wykonawców gwarantujących prawidłowe wykonanie zamówienia ze względu na posiadanie odpowiedniego doświadczenia. Odwołujący ma interes w uzyskaniu zamówienia, a w wyniku działań Zamawiającego Odwołujący został narażony na szkodę. Gdyby nie naruszające przepisy zaskarżone elementy SWZ, Odwołujący mógłby z powodzeniem ubiegać się o przedmiotowe zamówienie, co w razie jego uzyskania wiązałoby się z określonymi korzyściami finansowymi. Na tym etapie postępowania krąg podmiotów mogących skutecznie bronić swoich interesów w uzyskaniu zamówienia obejmuje każdego potencjalnego wykonawcę, mogącego samodzielnie zrealizować zamówienie. Interes Odwołującego wyraża się również w tym, aby postępowanie o udzielenie zamówienia przeprowadzone zostało zgodnie z przepisami prawa. (…)

Do postępowania odwoławczego przystąpienia nie zgłosił żaden wykonawca.

Zamawiający w odpowiedzi na odwołanie (pismo z dnia 11.09.2025 r.) wniósł w o jego oddalenie w części. W uzasadnieniu stanowiska podał: (...)

Zarzut 1 Warunek udziału w postępowaniu

Naruszenie art. 112 ust. 1 PZP w zw. z art. 112 ust. 2 pkt 4 PZP w zw. z art. 16 pkt 3 PZP poprzez określenie warunków udziału w postępowaniu dotyczących zdolności technicznej i zawodowej w zakresie doświadczenia wykonawcy w sposób w sposób nieproporcjonalny do przedmiotu zamówienia;

Zamawiający sformułował w SWZ następujący warunek udziału w postępowaniu:

„1.4. Warunki dotyczące zdolności technicznej lub zawodowej

[DOŚWIADCZENIE]

Wykonawca, dla spełnienia warunku, zobowiązany jest wykazać, że w okresie ostatnich 3 lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, należycie wykonał lub nadal wykonuje usługi dla podmiotów sektora finansów publicznych lub dla podmiotów gospodarczych o łącznej wartości co najmniej 1 000 000 zł brutto (słownie: jeden milion złotych brutto), których przedmiotem jest dostawa, wdrożenie oraz świadczenie usługi powdrożeniowej przez okres co najmniej 12 miesięcy systemu klasy ERP obejmującego co najmniej obszar finansowo-księgowy oraz kadrowo-płacowy”.

Natomiast w rozdziale 6 OPZ – Terminy realizacji, Zamawiający zawarł następującą informację: „Świadczenie Asysty Powdrożeniowej dla całości systemu musi obejmować okres 6 miesięcy od podpisania Końcowego Protokołu Odbioru Wdrożenia.” Oznacza to, że przedmiot zamówienia obejmuje 6 miesięcy świadczenia Asysty (usługi) powdrożeniowej.

Odpowiedź Zamawiającego:

Celem Zamawiającego jako jednostki sektora finansów publicznych jest zagwarantowanie efektywnego, proporcjonalnego i zgodnego z prawem wydatkowania środków publicznych. W tym przypadku dotyczy to określenia odpowiednich warunków dostępowych, weryfikujących czy dany podmiot posiada odpowiedni potencjał techniczny i zawodowy umożliwiający realizację przedmiotu zamówienia. Dlatego podmiot ubiegający się o to zamówienie publiczne powinien wykazać, że posiada odpowiednie doświadczenie w realizacji usług związanych z zakresem zamówienia tj. dostawą i wdrożeniem systemu klasy ERP oraz świadczeniem usługi powdrożeniowej. Zamawiający omyłkowo wskazał okres 12 miesięcy doświadczenia w świadczeniu usługi powdrożeniowej. Zamawiający przychyla się do stanowiska oferenta i dokonuje zmiany brzmienia w SWZ pkt 1.4 warunki dotyczące zdolności technicznej lub zawodowej w SWZ

(…)

Jest (po zmianie):

Wykonawca, dla spełnienia warunku, zobowiązany jest wykazać, że w okresie ostatnich 3 lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, należycie wykonał lub nadal wykonuje usługi dla podmiotów sektora finansów publicznych lub dla podmiotów gospodarczych o łącznej wartości co najmniej 1 000 000 zł brutto (słownie: jeden milion złotych brutto), których przedmiotem jest dostawa, wdrożenie oraz świadczenie usługi powdrożeniowej przez okres co najmniej 6 miesięcy systemu klasy ERP obejmującego co najmniej obszar finansowo-księgowy oraz kadrowo-płacowy”.

Zarzut nr 2 Kryterium oceny ofert: Ocena próbki

a) brak opisu kryteriów oceny ofert w sposób jednoznaczny i zrozumiały. Odwołujący zarzuca Zamawiającemu, że nie opisał kryteriów oceny ofert w sposób jednoznaczny i zrozumiały.

Odpowiedź Zamawiającego

Zamawiający dąży do wdrażania rozwiązań wpisujących się w kierunek cyfrowej transformacji, w tym wykorzystania nowoczesnych technologii już sprawdzonych w praktyce rynkowej. Przedstawione w dokumentacji wymagania odnoszą się do funkcjonalności, które mają realne zastosowanie, zostały przetestowane i są dostępne na rynku, a jednocześnie odpowiadają na potrzeby związane z rozwojem organizacji. Opis wymagań został sformułowany w sposób pozwalający wykazać, że dana funkcja jest możliwa do zrealizowania przez wykonawcę, bez narzucania nadmiernie szczegółowych rozwiązań technicznych. Zamawiający świadomie unikał zbyt szczegółowego doprecyzowania technologii czy parametrów, aby – zgodnie z zasadą uczciwej konkurencji – umożliwić udział w postępowaniu jak największej liczbie wykonawców. Zamawiający w celu doprecyzowania sposobu oceny próbki oraz zapewnienia jednoznaczności wymagań obligatoryjnych związanych z przedmiotem zamówienia wprowadza zmianę w pkt 7 Opisu Przedmiotu Zamówienia polegającą na usunięciu wymagania:

Nr 13 System będzie umożliwiał biometryczną weryfikację głosową na podstawie unikalnych cech głosu danego pracownika w komunikacji Dział Kadr – pracownik.

Nr 14 System winien umożliwiać automatyczne rozpoznawanie treści dokumentów (OCR), klasyfikowanie ich według typów i zawartości przy użyciu narzędzi sztucznej inteligencji oraz wspomagać operatorów w digitalizacji i walidacji dokumentów, umożliwiając łatwe wyszukiwanie, identyfikację metadanych i wykrywanie duplikatów. System powinien być skalowalny oraz umożliwiać obsługę dokumentacji archiwalnej zgromadzonej na przestrzeni ponad 20 lat przez Centralę UKE i 15 delegatur.

b) brak korelacji próbki

Odwołujący zarzuca także, iż zdecydowana większość wyspecyfikowanych w ww. tabeli funkcjonalności nie koresponduje z treścią przedmiotu zamówienia. Odwołujący jest świadomy tego, że wskazane wymagania są w większości funkcjonalnościami fakultatywnymi, za które Zamawiający będzie przyznawał dodatkowe punkty w ramach kryteriów oceny. Jednakże w ocenie Odwołującego nie ma wystarczającego związku pomiędzy przedmiotem zamówienia (wdrożenie Systemu finansowo-księgowo-kadrowo-płacowego), a wymaganiami wskazanymi przez Zamawiającego w kryterium oceny ofert „Ocena próbki”. Zdaniem Odwołującego próbka w ramach postępowania na dostawę systemu ERP (finansowo-księgowo-kadrowo-płacowego) powinna odnosić się do specyfiki systemu ERP. Przykładowo, biometria głosowa nie stanowi standardowej funkcjonalności systemu ERP (zdaniem Odwołującego nie sposób przyjąć, że ta funkcjonalność ma coś wspólnego z systemem ERP). Zdaniem Odwołującego, z kolei funkcjonalność OCR to domena systemów workflow (Elektronicznych Obiegów Dokumentów), a nie systemów ERP – nie ma nic wspólnego z systemem ERP.

Odpowiedź Zamawiającego:

Zarzut Odwołującego jest niezasadny. Wymagania wskazane w tabeli w ramach kryterium „Ocena próbki” zostały sformułowane celowo w taki sposób, aby umożliwić Zamawiającemu uzyskanie systemu ERP wyposażonego w nowoczesne technologie i funkcjonalności odpowiadające współczesnym trendom cyfrowym oraz wyzwaniom przyszłości. Podział na systemy ERP i EOD w nowoczesnych rozwiązaniach ulega zatarciu – współczesne systemy ERP implementują mechanizmy procesowości, obiegów dokumentów i narzędzi optymalizacji procesów. Nowoczesne systemy ERP nie tylko obsługują tradycyjne funkcje rachunkowo-kadrowe — coraz częściej integrują również zaawansowaną procesowość, która kiedyś była domeną systemów EOD (Elektronicznego Obiegu Dokumentów). Współczesne platformy ERP, realizują obieg zadań i dokumentów, zarządzanie procesami oraz automatyzację w sposób wbudowany — bez konieczności korzystania z dodatkowych, zewnętrznych systemów.

W związku z powyższym, wymagania z tabeli „Ocena próbki” — w tym automatyzacja procesów, inteligentne powiadomienia, dostęp mobilny, zarządzanie dokumentami, biometryka — znajdują pełne uzasadnienie. Stanowią naturalne elementy współczesnych, zintegrowanych systemów ERP, na których zależy Zamawiającemu jako nowoczesnej instytucji. Również wymagania związane z biometrią głosową oraz innymi mechanizmami bezpieczeństwa stanowią odpowiedź na rosnące zagrożenia cybernetyczne i odzwierciedlają nowy poziom zabezpieczeń w użytkowaniu systemów ERP. Brak ich obecności w standardowej ofercie jednego z wykonawców nie może być traktowany jako przesłanka do uznania ich za niepowiązane z przedmiotem zamówienia. Zamawiający, planując wdrożenie systemu ERP, kieruje się nie tylko bieżącymi potrzebami, lecz również przewidywanymi wymaganiami wynikającymi z rozwoju technologii, cyfryzacji administracji i bezpieczeństwa danych. Wymagania z tabeli w sposób bezpośredni wspierają realizację tych celów, a tym samym pozostają w pełnej korelacji z przedmiotem zamówienia.Ponadto w uzupełnieniu opisu kryteriów oceny próbki Zamawiający wyjaśnił cel poszczególnych rozwiązań i ich związek z przedmiotem zamówienia.

c) brak scenariuszy, zasad punktacji i regulaminu oceny próbki

Odwołujący zarzuca Zamawiającemu, że Zamawiający nie przedstawił żadnych (jednoznacznych, zrozumiałych i klarownych) zasad, w oparciu o które wykonawcy będą prezentować realizację wykazanych w tabeli funkcjonalności ani nie przedstawił, na jakich zasadach będą przyznawane (wskazane w kolumnie „Maksymalna liczba punktów cząstkowych”) punkty cząstkowe za każdą zaprezentowaną i prawidłowo zrealizowaną funkcjonalność (…).

Odwołujący zarzuca Zamawiającemu sformułowanie kryterium oceny ofert „Ocena próbki” w sposób, który przyznaje Zamawiającemu właściwie nieograniczoną swobodę wyboru najkorzystniejszej oferty, gdyż nie umożliwia weryfikacji i porównania poziomu oferowanego wykonania przedmiotu zamówienia na podstawie informacji przedstawianych w ofertach.

Odpowiedź Zamawiającego

Zamawiający nie podziela argumentów podniesionych w zarzucie przez Odwołującego. Zamawiający pragnie wskazać, że przewidział to, że ocena w ramach kryterium „Ocena próbki” odbywa się na podstawie stopnia realizacji zadań wynikających z opisanych w dokumentacji wymagań. Komisja przetargowa będzie przyznawać punkty proporcjonalnie do liczby i jakości zrealizowanych funkcjonalności, zgodnie z ich opisem w SWZ, przy czym każdy element będzie weryfikowany poprzez przedstawienie dowodu jego spełnienia. Wraz z realizacją kolejnych zapisów wymagań, popartą stosowną demonstracją lub dowodem, Komisja będzie przyznawała punkty częściowe lub pełne, odzwierciedlające stopień spełnienia danej funkcjonalności. Taki model oceny zapewnia równe traktowanie wykonawców i pozwala na obiektywne porównanie ofert. Jednocześnie, mając na względzie postulaty dotyczące transparentności, Zamawiający wprowadzi modyfikację dokumentacji postępowania polegającą na dołączeniu szczegółowych scenariuszy prezentacji dla poszczególnych funkcjonalności, które będą stanowić podstawę zarówno dla przygotowania próbek przez wykonawców, jak i dla ich oceny przez komisję. Scenariusze te będą opisane w sposób jednoznaczny i zrozumiały, aby wyeliminować ewentualne wątpliwości interpretacyjne.

d) nieproporcjonalna, nieefektywna waga kryterium

Odwołujący zarzuca, że Zamawiający dla kryterium „Ocena próbki” przypisał wagę aż 40% (40 punktów), co jest wielkością bardzo znaczącą i determinującą łączną punktację jaką mogą uzyskać wykonawcy w kryteriach oceny. Wykonawca, który nie uzyska żadnych punktów w tym kryterium nie jest w stanie złożyć konkurencyjnej oferty, nawet minimalizując cenę do 0,01 zł.

Odpowiedź Zamawiającego

Zamawiający dąży do wyboru rozwiązania najbardziej nowoczesnego, kompleksowego i przyszłościowego, dlatego przypisanie temu kryterium znaczącego udziału procentowego w ocenie ofert jest w pełni uzasadnione.Jednocześnie, mając na względzie postulaty proporcjonalności i równowagi między kryteriami, Zamawiający wprowadza w SWZ następującą modyfikację wagi kryterium „Ocena próbki” – z dotychczasowych 40% do poziomu 25%, co zachowuje jego istotność, a jednocześnie lepiej równoważy wpływ wszystkich kryteriów oceny na wynik końcowy.

(…)

JEST

Zarzut nr 2 - Podsumowanie

Podsumowując kryterium „Ocena próbki” zostało sformułowane zgodnie z przepisami PZP i stanowi istotny element oceny ofert, umożliwiający wybór rozwiązania nowoczesnego, kompleksowego i odpowiadającego bieżącym oraz przyszłym potrzebom Zamawiającego. Opis wymagań jest na tyle precyzyjny, aby umożliwić ich realizację szerokiemu gronu wykonawców, a jednocześnie pozostaje na poziomie funkcjonalnym, co zapobiega ograniczaniu konkurencji poprzez narzucanie konkretnych rozwiązań technologicznych. Wskazane w kryterium funkcjonalności, w tym związane z procesowością, obiegiem dokumentów oraz bezpieczeństwem (np. biometrią głosową), są obecnie integralną częścią nowoczesnych systemów ERP, czego przykładem są dostępne na rynku rozwiązania. Komisja przetargowa oceniać będzie stopień realizacji poszczególnych wymagań, przyznając punkty na podstawie przedstawionych dowodów ich spełnienia, a dla pełnej transparentności Zamawiający wprowadzi modyfikację dokumentacji poprzez dołączenie scenariuszy prezentacji funkcjonalności. Jednakże, by wyeliminować ewentualne wątpliwości potencjalnych Oferentów co do sposobu, kryteriów oraz zasadności poszczególnych elementów zawartych w kryterium „Ocena próbki” Zamawiający uzupełnia SWZ o doprecyzowanie opisu kryteriów oceny próbki, tj.:

1. Integracja z inteligentnym asystentem (AI Chat) w celu wyszukiwania i analizy danych z umów. Funkcjonalność umożliwia zadawanie pytań w języku naturalnym i uzyskiwanie precyzyjnych odpowiedzi bezpośrednio z treści dokumentów. (max. 4 pkt).

Cel funkcjonalny

Umożliwienie użytkownikowi zadawania pytań w języku naturalnym dotyczących treści umów i uzyskiwania precyzyjnych odpowiedzi bezpośrednio z tych dokumentów. Wirtualny asystent (oparty na AI) ma zrozumieć kontekst pytania i przeszukać dane umów w systemie, aby udzielić konkretnej odpowiedzi. Dzięki temu obsługa zapytań o informacje z umów jest szybsza i łatwiejsza, np. użytkownik może zapytać: „Kiedy wygasa umowa z kontrahentem X?”, a system natychmiast poda datę zakończenia.

Kroki działania w systemie

1. Z poziomu interfejsu systemu użytkownik otwiera okno systemu.

2. Użytkownik wpisuje pytanie w języku polskim dotyczące konkretnej umowy, np.: „Jaka jest data umowy o świadczenie usług IT z firmą ABC?”.

3. Asystent AI przetwarza zapytanie – rozpoznaje, że dotyczy ono danych z dokumentów typu Umowa – i przeszukuje bazę umów w systemie (ew. analizuje treść załączonego pliku umowy, jeśli jest przeszukiwalny).

4. System wyświetla w oknie czatu odpowiedź asystenta AI – np.: „Umowa z firmą ABC obowiązuje do 31 października 2025 r.”. Asystent może dodatkowo wskazać źródło informacji, np. numer umowy lub sekcję dokumentu.

Oczekiwany rezultat

System poprawnie interpretuje pytanie w języku naturalnym i zwraca precyzyjną informację z treści umowy. Odpowiedź pojawia się szybko w oknie czatu i odpowiada na zadane pytanie (bez potrzeby ręcznego przeglądania dokumentu). Użytkownik otrzymuje np. konkretną datę, kwotę lub zapis umowny, którego zażądał. Asystent powinien wykazać się rozumieniem kontekstu (np. wie, której umowy dotyczy pytanie na podstawie nazwy kontrahenta).

Skala punktowa

 0 pkt – Brak integracji z asystentem AI lub asystent nie potrafi odpowiadać na pytania o treść umów. W próbie demonstracyjnej funkcjonalność nie została pokazana lub odpowiedzi asystenta są całkowicie niepoprawne/niezwiązane z pytaniami.

 1 pkt – Asystent AI jest obecny i pozwala na zadawanie pytań, ale nie pobiera informacji z treści dokumentów. Może udzielać odpowiedzi ogólnych lub dotyczących tylko podstawowych danych (np. dostępnych w kartotekach), bez sięgania do pełnego tekstu umowy. Np. pytanie o datę końca umowy zwraca jedynie komunikat błędu albo wymaga podania numeru umowy ręcznie.

 2 pkt – Asystent potrafi udzielić częściowych odpowiedzi związanych z umowami. Np. rozpoznaje pytanie o datę końcową umowy i zwraca ją, ale tylko jeśli data jest wpisana w strukturze danych (metadanych) umowy. Nie analizuje pełnego tekstu dokumentu lub ma trudności ze zrozumieniem pytań w języku naturalnym (wymaga bardzo konkretnej frazy). Odpowiedzi mogą być niepełne lub wymagające doprecyzowania.

 3 pkt – Asystent AI poprawnie odpowiada na większość pytań dotyczących danych z umów zapisanych w systemie. Rozumie pytania kontekstowo (np. identyfikuje umowę po nazwie kontrahenta) i przytacza prawidłowe informacje znajdujące się w strukturze danych lub załączonym tekście. Mogą wystąpić drobne ograniczenia – np. asystent nie interpretuje skanowanych dokumentów nieprzetworzonych na tekst lub myli się przy bardzo złożonych pytaniach – ale zasadniczo funkcja działa.

 4 pkt – Pełna realizacja funkcjonalności. Asystent AI swobodnie komunikuje się z użytkownikiem w języku naturalnym i precyzyjnie odpowiada na pytania dotyczące treści umów, korzystając zarówno z metadanych, jak i pełnego tekstu dokumentów.

W odpowiedziach uwzględnia kontekst (wie o którą umowę chodzi bez podawania numeru, jeśli pytanie jednoznacznie identyfikuje kontrahenta/temat) i przytacza informacje takie jak daty, kwoty, klauzule umowne itp. Odpowiedzi są trafne nawet dla pytań sformułowanych potocznie lub przy drobnych literówkach. Funkcja działa płynnie, a wszystkie zaprezentowane przykładowe pytania (np. o datę, kwotę, warunki umowy) zostały poprawnie obsłużone przez asystenta.

2. Automatyczne klasyfikowanie i ekstrakcja kluczowych metadanych z umów lub dokumentów kadrowych i innych, przy użyciu AI i OCR (max. 4 pkt).

Cel funkcjonalny

Zautomatyzowanie procesu wprowadzania dokumentów (np. umów, dokumentów kadrowych, faktur) poprzez wykorzystanie sztucznej inteligencji (AI) i OCR do odczytu treści i wyciągania kluczowych metadanych. System powinien samoczynnie rozpoznać typ dokumentu (np. odróżnić umowę od innego pisma) oraz wydobyć istotne informacje – takie jak strony umowy, daty obowiązywania, kwotę wynagrodzenia, numer dokumentu, itp. – i zapisać je w odpowiednich polach systemu. Celem jest ograniczenie ręcznego przepisywania danych i przyspieszenie digitalizacji dokumentów.

Kroki działania w systemie

1. Użytkownik dodaje nowy dokument do systemu lub wybiera importuj dokument i wskazuje plik PDF skanu umowy.

2. Przetwarza dokument za pomocą OCR. Ewentualnie system automatycznie wykrywa nowy dokument w wyznaczonym katalogu do przetwarzania OCR.

3. System przesyła dokument do usługi OCR. Mechanizm AI+OCR rozpoznaje tekst na wszystkich stronach skanu (technologia rozpoznawania tekstu) oraz analizuje jego strukturę.

4. Klasyfikacja: Na podstawie zawartości tekstu AI stwierdza, że jest to umowa (np. wykrywa słowa kluczowe typu „Umowa nr…”, „Strony: …” itp.). System przypisuje dokumentowi odpowiedni typ lub znacznik (np. Umowa o pracę).

5. Ekstrakcja danych

OCR wspomagany AI wyodrębnia z tekstu dokumentu kluczowe informacje. Przykładowo:

o „Numer umowy” – znajduje ciąg znaków odpowiadający numerowi i wypełnia pole numeru.

o „Data zawarcia” i „Data obowiązywania od/do” – rozpoznaje daty i przypisuje do odpowiednich pól.

o „Strony umowy” (nazwy kontrahentów/pracownika i pracodawcy) – odnajduje nazwy podmiotów i wypełnia pola kontrahenta.

o Inne metadane jak kwota wynagrodzenia czy stanowisko (jeśli to umowa o pracę) – identyfikuje w tekście i przypisuje do odpowiednich pól.

6. Po zakończeniu przetwarzania system automatycznie tworzy w bazie nowy rekord umowy. Pola metadanych są uzupełnione wartościami odczytanymi z dokumentu. Sam oryginał skanu zostaje zapisany jako załącznik/element do tego rekordu (możliwy do podejrzenia przez użytkownika).

7. Użytkownik otwiera utworzoną kartę umowy w systemie i weryfikuje wyniki: sprawdza, czy kluczowe pola zostały poprawnie uzupełnione zgodnie z treścią dokumentu.

8. W celach demonstracyjnych użytkownik dodaje drugi dokument (np. skan świadectwa pracy lub innego rodzaju dokumentu kadrowego) i powtarza procedurę, pokazując że system potrafi odmiennie zaklasyfikować dokument (np. jako Dokument kadrowy zamiast Umowa) i wyciągnąć z niego inne zestawy metadanych.

Oczekiwany rezultat

System automatycznie rozpoznaje i rejestruje dokument. Po zaimportowaniu skanu umowy pojawia się nowy rekord w systemie, gdzie pola takie jak kontrahent/pracownik, daty, numer umowy, itp. są już wypełnione bez ręcznej ingerencji. Typ dokumentu jest poprawnie ustawiony (umowa vs inny dokument).

Skala punktowa

 0 pkt – Brak działającej funkcji OCR/AI. System nie potrafi automatycznie przetworzyć dodanego skanu – użytkownik musiałby ręcznie wprowadzić wszystkie dane, co zostaje wykazane podczas prezentacji (np. importowany dokument trafia tylko jako skan do repozytorium bez żadnej analizy).

 1 pkt – Częściowe działanie mechanizmu. System podejmuje próbę rozpoznania dokumentu, ale zakres jest bardzo ograniczony. Np. OCR odczytuje tekst, ale nie klasyfikuje rodzaju dokumentu ani nie wypełnia pól automatycznie – jedynie umożliwia użytkownikowi

skopiowanie tekstu. Ewentualnie rozpoznaje tylko nieliczne dane (np. numer dokumentu), podczas gdy resztę trzeba wprowadzić ręcznie.

 2 pkt – System poprawnie rozpoznaje tekst z dokumentu (działa OCR) i częściowo uzupełnia pola. Na przykład potrafi wypełnić podstawowe metadane (numer, datę dokumentu), ale nie identyfikuje wszystkich kluczowych informacji lub myli typ dokumentu. Użytkownik musi część danych poprawić lub uzupełnić ręcznie. Ogólnie widać automatyzację, lecz jej skuteczność jest umiarkowana (np. działa dla faktur, ale nie dla umów – w demonstracji dane z umowy nie zostały w pełni odczytane).

 3 pkt – Znaczna automatyzacja. System rozpoznaje typ dokumentu i wypełnia większość istotnych pól poprawnie. Np. po wczytaniu umowy identyfikuje strony, daty, numer i część klauzul finansowych, choć mogą zdarzyć się drobne pomyłki (np. OCR błędnie odczyta jedno nazwisko z powodu jakości skanu). Konieczne jest niewielkie korygowanie danych przez użytkownika. Funkcja klasyfikacji działa dla głównych typów dokumentów przewidzianych w systemie. Demonstracja pokazuje, że np. dla dwóch różnych dokumentów mechanizm zadziałał, choć przy jednym z nich pewne pole pozostało niewypełnione albo system poprosił o akceptację odczytanej wartości.

 4 pkt – Pełna funkcjonalność AI+OCR. W pokazie system bezbłędnie klasyfikuje przedstawiony dokument (rozpoznaje rodzaj umowy lub innego pisma) i automatycznie ekstraktuje wszystkie kluczowe metadane. Użytkownik nie musi nic dopisywać ręcznie – jedynie weryfikuje poprawność. Wszystkie ważne informacje z dokumentu (przynajmniej te wymienione w scenariuszu) są poprawnie uchwycone: kontrahent, daty, numer, kwoty itp. System radzi sobie nawet z dokumentem wielostronicowym i o mniej standardowym układzie. Wskazanie pliku skutkuje utworzeniem nowego obiektu w systemie z uzupełnionymi danymi, a oryginał jest dostępny jako załącznik. Funkcjonalność cechuje się wysoką skutecznością i niezawodnością (np. praktycznie brak błędów odczytu w zaprezentowanych przypadkach).

3. Proaktywne generowanie przez system rekomendacji dotyczących optymalizacji procesów w oparciu o analizę danych i wzorców w obiegu dokumentów. (max. 2 pkt).

Cel funkcjonalny

Proaktywne wsparcie użytkownika poprzez analizę wzorców i danych gromadzonych w systemie w celu znalezienia usprawnień w procesach biznesowych. System powinien automatycznie generować rekomendacje – np. sugestie zmian organizacyjnych, podpowiedzi automatyzacji, wskazanie wąskich gardeł w obiegu dokumentów – na podstawie wykrytych trendów lub anomalii. Celem jest zwiększenie efektywności pracy z systemem i procesów urzędu dzięki AI, która uczy się z danych historycznych i na ich podstawie wskazuje optymalizacje.

Kroki działania w systemie

1. Administrator lub użytkownik przechodzi do panelu analiz procesów, gdzie zbierane są potencjalne rekomendacje.

2. Użytkownik inicjuje analizę danych – np. wybiera polecenie „przeanalizuj obieg dokumentów za ostatnie 6 miesięcy pod kątem opóźnień”.

3. System (silnik AI) przetwarza dane z logów i historii dokumentów. Wyszukuje wzorce: np. zauważa, że dokumenty typu Umowa mają średni czas akceptacji 15 dni, podczas gdy oczekiwany to 7 dni.

4. Generowanie rekomendacji

Na podstawie wykrytych odstępstw lub możliwości poprawy, system formułuje komunikaty. Przykłady rekomendacji:

o „Proces akceptacji umów trwa średnio 2 razy dłużej niż zakładano. Rekomendacja: skrócić liczbę wymaganych akceptacji z 4 do 3 dla umów o wartości < …. zł.”

o „W ostatnim kwartale 25% wniosków urlopowych przekroczyło czas akceptacji o

>24h. Rekomendacja: dodać zastępcę do akceptacji wniosku w razie nieobecności przełożonego.”

5. System wyświetla listę wygenerowanych rekomendacji na ekranie. Użytkownik je przegląda.

6. Użytkownik klika konkretną rekomendację, aby zobaczyć szczegóły.

Oczekiwany rezultat

System prezentuje czytelne, sensowne rekomendacje poparte danymi. Każda sugestia optymalizacyjna jasno odnosi się do konkretnego procesu i problemu zidentyfikowanego w analizie. Np. w scenariuszu na ekranie pojawia się komunikat wskazujący długi czas akceptacji umów i sugerujący działania naprawcze – jest to zrozumiałe dla komisji oceniającej i odpowiada rzeczywistym danym (prezentowany wykres/raport pokazuje, że faktycznie większość umów przekracza zakładany czas). Rekomendacje są mierzalne (tzn. wskazują co ulepszyć i jak to wpłynie na proces). System zachowuje się proaktywnie – informacje pojawiają się bez zapytania użytkownika bądź w odpowiedzi na proste polecenie analizy, zamiast wymagania od użytkownika samodzielnego wyciągania wniosków z surowych raportów.

Skala punktowa:

 0 pkt – Brak funkcji generowania rekomendacji. W prezentacji nie pokazano żadnej proaktywnej sugestii dotyczącej ulepszeń – system ogranicza się do standardowych raportów. Żaden element UI czy raportu nie wskazuje, by AI analizowała i proponowała usprawnienia procesów.

 0,5 pkt – Rekomendacje w formie szczątkowej. System może wyświetlać pewne statyczne podpowiedzi lub komunikaty, ale nie są one wynikiem analizy danych z kontekstu urzędu. Np. ogólne wskazówki typu „możesz skorzystać z modułu X, by zautomatyzować pracę” niezwiązane z realnymi danymi lub pojedyncze ostrzeżenia bez konkretnych sugestii (np. informacja o przekroczeniu terminu bez rekomendacji co z tym zrobić). Sugestie są niepersonalizowane, jednak sygnalizuje to próbę doradzania użytkownikowi.

 1 pkt – Pojawiają się pierwsze oznaki inteligentnych rekomendacji, ale o ograniczonym zakresie. Np. system identyfikuje 1-2 proste wzorce (tylko w jednym obszarze, np. finanse) – np. podpowie automatyzację raportu miesięcznego – ale nie obejmuje to szerszych procesów. Rekomendacje mogą być dość oczywiste lub generowane rzadko. Użytkownik w prezentacji musiał np. ręcznie wywołać analizę i otrzymał jedną sugestię optymalizacji. Funkcjonalność działa, lecz ma wąski zakres (np. tylko dla modułu księgowego) lub jej wiarygodność jest niska (sugestie mało trafne).3 pkt – Funkcjonalność działa w zadowalającym stopniu. System potrafi wygenerować kilka przydatnych rekomendacji na podstawie danych. Obejmują one więcej niż jeden obszar procesu (np. zarówno obieg dokumentów kadrowych, jak i finansowych). Sugestie są konkretne i poparte danymi – w prezentacji pokazano, że system wskazał np. konkretny krok w procesie, który wydłuża całość i zaproponował zmianę. Nadal jednak mogą istnieć pewne ograniczenia: np. rekomendacje pojawiają się tylko po ręcznym uruchomieniu analizy (nie w trybie ciągłego monitoringu) lub nie obejmują bardziej złożonych zależności. Być może system nie uwzględnia jeszcze wszystkich historycznych danych albo pomija czynniki jakościowe. Ogólnie jednak większość wygenerowanych podpowiedzi jest sensowna i komisja uznaje je za wartościowe.

 2 pkt – Zaawansowane, proaktywne rekomendacje procesowe. System stale analizuje dane z różnych modułów i automatycznie informuje użytkowników o możliwościach ulepszeń. W demonstracji pokazano, że system sam zidentyfikował kilka istotnych obszarów do poprawy i dla każdego przedstawił mierzalną propozycję usprawnienia. Rekomendacje mogą dotyczyć organizacji pracy (np. zmiana obsady akceptacji, skrócenie obiegu), wykorzystania funkcji systemu (np. włączenie automatycznych przypomnień, które są wyłączone), a nawet wskazywać potencjalne oszczędności czasu lub kosztów. Sztuczna inteligencja wychwytuje ukryte wzorce (np. zależności między obciążeniem pracą a opóźnieniami) i trafnie je

komunikuje. Funkcja jest uniwersalna – można ją zastosować do różnych procesów (kadry, finanse, zamówienia). System w punktach oceny próbki zaprezentował kilka różnych rekomendacji, z których każda była jasna, poprawna merytorycznie i weryfikowalna na podstawie danych (np. poparta wykresem lub raportem). Taki poziom realizacji pokazuje realne wykorzystanie AI do ciągłego doskonalenia procesów w organizacji.

4. Definiowanie i modelowanie procesów za pomocą jednego z ogólnie dostępnych języków programowania (max. 2 pkt).

Cel funkcjonalny

Umożliwienie definiowania i dostosowywania logiki procesów biznesowych za pomocą powszechnie dostępnego języka programowania (np. Python, C#, VB lub innego języka skryptowego). Chodzi o to, aby system był otwarty na rozszerzenia i pozwalał programistom (lub zaawansowanym administratorom) modelować niestandardowe procesy, reguły czy integracje poprzez kod. Dzięki temu bardziej złożone wymagania można zaadresować pisząc odpowiedni skrypt lub moduł, który będzie współpracował z systemem.

Kroki działania w systemie:

1. Programista/administrator otwiera środowisko do rozszerzeń. Może to być:

o Edytor skryptów wewnątrz aplikacji (jeśli system taki posiada, np. edycja skryptu procesu).

o Zewnętrzne IDE do napisania kodu korzystającego z API ERP.

2. Tworzy nowy proces/rozszerzenie – np. definicję procedury, która będzie reagować na zdarzenie w systemie:

o Przykład

Skrypt wywoływany przy dodaniu nowej umowy. Skrypt ten pobiera dane umowy i automatycznie tworzy powiązane zadanie w zewnętrznym systemie , używając API ERP do odczytu danych i utworzenia zadania.

o Inny przykład

Skrypt generuje specjalny raport i wysyła e-mail, uruchamiany codziennie jako zadanie.

3. Użytkownik testowy wykonuje czynność inicjującą proces (np. dodaje nową umowę w systemie).

4. Skrypt/rozszerzenie uruchamia się i wykonuje zaprogramowane działania. Oczekujemy, że:

o W systemie pojawiły się dodatkowe efekty zaplanowane w kodzie (np. dodano automatycznie kolejny dokument, zmieniono status, wyliczono jakieś pole niestandardowe).

o lub zewnętrzne efekty, np. w logach widać, że system wywołał zewnętrzny webservice, utworzono plik, wysłano e-mail.

5. W ramach prezentacji, wykonawca pokazuje fragment kodu, wyjaśnia logikę oraz demonstruje, że po stronie systemu ERP proces został pomyślnie dostosowany (np. mamy „szytą na miarę” funkcję, której nie dałoby się osiągnąć bez programowania). Może to zilustrować działaniem: np. tworzy dokument, co skutkuje automatyczną akcją – komisja widzi rezultat tej akcji.

Oczekiwany rezultat

W demonstracji pojawia się rzeczywisty kod źródłowy integrujący się z systemem. Rezultat działania tego kodu jest zgodny z oczekiwaniami: np. po zdarzeniu w systemie nastąpiła oczekiwana, zaprogramowana czynność (system utworzył dokument, zmienił dane, wywołał integrację). Dla oceny ważne jest, że nie jest to tylko teoria – wykonawca praktycznie pokazał działający kod powiązany z systemem. Np. w logach systemu widać wywołanie przez API operacji utworzenia dokumentu handlowego, co potwierdza możliwość sterowania ERP poprzez zewnętrzny program.

Skala punktowa

 0 pkt – System nie umożliwia modelowania procesów poprzez kod lub nie zostało to zaprezentowane. Wszelkie procesy są sztywno zdefiniowane i nie ma API ani mechanizmu skryptowego. Wykonawca nie przedstawił żadnego sposobu na dodanie własnej logiki – tylko konfigurację przez interfejs. (Jeśli system jest zamknięty na integracje programistyczne, otrzyma 0 pkt).

 1 pkt – System posiada pewne API lub mechanizm rozszerzeń, ale jego użycie jest bardzo ograniczone albo nie pozwala na pełne modelowanie procesów. Przykład: Można co najwyżej wywołać kilka metod do pobrania danych, ale brak możliwości ingerencji w obieg dokumentów. Albo: system pozwala na skrypty, lecz tylko w bardzo podstawowym zakresie (np. proste makra, które nie mogą wpływać na głębszą logikę). Być może wykonawca pokazał fragment kodu, ale nie udało się nim wiele zdziałać (np. potrzebna funkcja API nie istnieje). Ogólnie – funkcjonalność częściowa.

 2 pkt – System jest otwarty programistycznie i umożliwia realizację niestandardowego procesu poprzez kod – co zostało skutecznie zademonstrowane. Wykonawca przedstawił działający przykład rozszerzenia: użyto popularnego języka (np. VB, C#, Java, Python lub wbudowany język skryptowy) do implementacji logiki biznesowej. Rozszerzenie integruje się z systemem (np. poprzez oficjalne API) i osiąga zamierzony efekt. Oceniający widzą, że wymagało to napisania kodu, ale dzięki temu uzyskano funkcję ponad standard systemu. Przyznane zostanie maks. 2 pkt, ponieważ pełna zdolność do modelowania w języku programowania została potwierdzona. (Uwaga: Skala do 2 pkt – 2 oznacza spełnienie wymogu. Jeśli system dodatkowo oferuje wyjątkowo łatwe i mocne narzędzia dla programistów – można to docenić w komentarzu, ale punktacja powyżej 2 nie jest tu przewidziana).

5. Zaawansowany dostęp mobilny do repozytorium umów (max. 2 pkt).

Cel funkcjonalny

Zapewnienie zaawansowanego dostępu mobilnego do dokumentów umów – to znaczy, że uprawniony użytkownik korzystający ze smartfona lub tabletu może przeglądać, wyszukiwać, jak na komputerze. Mobilny dostęp ma umożliwić pracę zdalną i ciągłość działania: np. kierownik w terenie może szybko odszukać konkretną umowę i sprawdzić jej warunki, a także wykonać na niej operacje (podpisać elektronicznie, dodać komentarz, itp.). Rozwiązanie mobilne powinno być wygodne (dostosowany interfejs) i bezpieczne.

Kroki działania w systemie

1. Na urządzeniu mobilnym użytkownik uruchamia aplikację związaną z systemem (np. system na smartfonie, lub otwiera przeglądarkę i loguje się do webowej wersji repozytorium umów).

2. Po zalogowaniu, użytkownik przechodzi do umów lub wyszukiwarki dokumentów. Interfejs jest dostosowany do ekranu mobilnego – np. lista umów wyświetla podstawowe informacje w kompaktowej formie.

3. Użytkownik korzysta z wyszukiwarki, wpisując np. nazwę kontrahenta lub numer umowy. System szybko filtruje i wyświetla wyniki. Możliwe jest też zastosowanie filtrów (typu listy rozwijane użytkownika, daty).

4. Użytkownik wybiera konkretną umowę z listy. Otwiera się podgląd dokumentu:

o Wyświetlane są metadane umowy (kontrahent, daty, status, itp.).

o Dostępna jest opcja podglądu załączonego pliku (np. skanu/pdf umowy). Użytkownik klika podgląd – dokument jest renderowany na ekranie telefonu.

5. System rejestruje te zmiany w bazie, tak jakby zostały wykonane z poziomu komputerowej aplikacji.

Oczekiwany rezultat

Możliwy dostęp do umów z urządzenia mobilnego. Użytkownik jest w stanie w kilka chwil odnaleźć potrzebny dokument i wyświetlić jego zawartość na ekranie telefonu. Wszystkie elementy interfejsu są czytelne i interaktywne na małym ekranie. Wykonane operacje (np. akceptacja) są natychmiast odzwierciedlone w systemie centralnym. System demonstruje cechy takie jak:

 Responsywność - szybkie działanie, dostosowanie UI.

 Kompletność funkcji - mobilnie dostępne są nie tylko podglądy, ale i akcje (przynajmniej podstawowe, jak akceptacja, komentarz).

 Synchronizacja w czasie rzeczywistym - np. gdy w mobilnej app dokonano zmiany statusu, komisja może zobaczyć na komputerze, że status uległ zmianie – i odwrotnie.

Skala punktowa:

 0 pkt – System nie posiada realnego dostępu mobilnego. Być może jedyną opcją jest użycie pulpitu zdalnego lub brak jest w ogóle interfejsu dla urządzeń mobilnych. W prezentacji nie pokazano działania na smartfonie/tablecie lub próba takiego działania była kompletnie nieudana (interfejs nieładowalny, bardzo nieczytelny).

 0,5 pkt – Ograniczony dostęp mobilny. Np. system można co prawda otworzyć na tablecie/telefonie (przez przeglądarkę), ale nie jest on zoptymalizowany – widać pełny interfejs desktopowy, który jest trudny w obsłudze dotykiem. Aplikacja natywna może nie istnieć lub oferuje tylko podgląd kilku prostych danych. Użytkownik w demonstracji ledwo może wyszukać dokument (np. musi przewijać duże tabele, które się niewygodnie skalują). Ogółem mobilność jest tylko hasłowa.

 1 pkt – System oferuje podstawową aplikację mobilną lub responsywny portal, który umożliwia przeglądanie dokumentów i wykonywanie tylko prostych czynności. Przykładowo: użytkownik może wyświetlić listę umów i podejrzeć szczegóły, ale nie może ich edytować ani zatwierdzać. Albo może zatwierdzać, ale nie obejrzy załącznika PDF, bo aplikacja go nie wyświetla poprawnie. Możliwości są ograniczone, choć samo logowanie i nawigacja działają. W skali ocen: system spełnia minimalny wymóg posiadania mobilnego dostępu, ale nie realizuje w pełni idei „zaawansowanego” dostępu.

 1,5 pkt – Pełny dostęp mobilny z drobnymi brakami. Aplikacja (lub strona mobilna) pozwala na prawie wszystko, co jest potrzebne: wyszukiwanie, przeglądanie załączników, akceptacje, komentarze. Prezentacja pokazuje, że kierownik na telefonie mógł znaleźć i zatwierdzić dokument, co zostało odnotowane w systemie. Ewentualne braki mogą dotyczyć wygody lub rzadziej używanych funkcji: np. brak możliwości edycji pewnych pól metadanych, albo brak powiadomień push (użytkownik musi sam sprawdzać). Jednak core funkcjonalności mobilnej jest dostępny i działa poprawnie. Interfejs jest przyjazny (np. specjalne uproszczone ekrany dla najważniejszych czynności). Komisja mogła zaobserwować, że mobilne narzędzie realnie wspiera pracę zdalną.

 2 pkt – Zaawansowany, w pełni funkcjonalny dostęp mobilny. Użytkownik na urządzeniu mobilnym może zrobić praktycznie wszystko, co w aplikacji desktopowej, przy zachowaniu wygody i ergonomii. Pokazano, że aplikacja mobilna umożliwia wszystkie kluczowe operacje na umowach: wyszukiwanie po różnych kryteriach, filtrowanie, podgląd wielostronicowych skanów, zatwierdzanie/odrzucanie, edycję atrybutów, dodawanie zdjęć/załączników np. z aparatu, podpis elektroniczny (jeśli wspierany).

6. Inteligentne alertowanie o kluczowych terminach umownych. System automatycznie monitoruje daty i wysyła powiadomienia. (max. 2 pkt).

Cel funkcjonalny

Zapewnienie, że system monitoruje terminy wynikające z umów (np. daty wygaśnięcia, odnowienia, terminy wypowiedzenia, przeglądu umowy, ważności gwarancji itp.) i wcześniej powiadamia odpowiednie osoby o zbliżających się kluczowych datach. Celem jest uniknięcie sytuacji, w której ważny termin zostanie przeoczony. Funkcjonalność alertowania powinna działać automatycznie – użytkownik nie musi samodzielnie sprawdzać kalendarza każdej umowy; zamiast tego system generuje powiadomienia/alerty gdy zbliża się określony termin (na podstawie reguł). Inteligencja może polegać np. na dostosowaniu, kogo powiadomić i kiedy (np. miesiąc przed końcem umowy z co najmniej rocznym okresem wypowiedzenia).

Kroki działania w systemie

1. Automatyczne monitorowanie

W tle system codziennie (lub w określonych odstępach) sprawdza wszystkie terminy w bazie umów. To może być zrealizowane poprzez zdefiniowane reguły: np. „jeśli data zakończenia umowy T – dzisiejsza data <= 30 dni, a umowa w statusie aktywna, to wygeneruj alert”.

2. Wygenerowanie alertu

Dla każdej umowy spełniającej kryterium zbliżającego się terminu, system tworzy powiadomienie. Powiadomienie może mieć formę:

o Wewnętrznego komunikatu/zdarzenia (np. trafia do Centrum powiadomień w aplikacji albo do modułu "Informacje"/dashboard).

o Wiadomości e-mail wysłanej do opiekuna umowy lub grupy.

3. Użytkownik prezentuje centralny widok alertów

Np. informacje bieżące, kończące się umowy z listą umów, których termin upływa w określonym okienku czasu. Na liście widoczne są np. nazwy kontrahentów i daty końca umowy.

4. Użytkownik pokazuje swój widok: otrzymał np. e-mail od systemu z przypomnieniem o wygasającej umowie.

5. Użytkownik klika link w powiadomieniu lub przechodzi w systemie do danej umowy, aby podjąć działania (np. rozpoczyna proces przedłużenia lub przygotowuje wypowiedzenie).

Oczekiwany rezultat

System aktywnie ostrzega o zbliżających się terminach związanych z umowami. Komisja widzi, że użytkownicy otrzymują wyraźne powiadomienia (na ekranie, mailowo lub mobilnie) z odpowiednim wyprzedzeniem.

Skala punktowa

 0 pkt – System nie oferuje żadnego automatycznego alertu o terminach. Użytkownik musiałby ręcznie przeglądać daty w umowach lub prowadzić je w zewnętrznym kalendarzu. W prezentacji brak wzmianki o powiadomieniach, a zapytany wykonawca stwierdza, że takiej funkcji nie ma lub nie pokazał jej działania.

 0,5 pkt – Pojawia się częściowa funkcjonalność alertów, lecz mocno ograniczona. Być może system posiada tylko statyczne raporty o terminach (np. lista wygasających umów, ale nie generuje automatycznych powiadomień – użytkownik sam musi zajrzeć do raportu). Ewentualnie powiadomienia istnieją, ale tylko w systemie (np. mały wskaźnik na dashboardzie), bez wysyłki maili czy notyfikacji. Funkcja może wymagać manualnego uruchomienia raportu z terminami. Nie jest to w pełni automatyczne czuwanie, ale podstawowe informacje o kończących się terminach są dostępne.

 1 pkt – System generuje powiadomienia, jednak nie w sposób kompleksowy. Np. potrafi wysłać e-mail, ale tylko do jednego, stałego adresu (nie do opiekuna umowy). Albo alerty wyświetlają się użytkownikom w aplikacji, lecz bez personalizacji (każdy widzi tylko własne, brak globalnego zestawienia). Możliwe, że brakuje konfigurowalności – terminy są z góry ustalone (np. zawsze 7 dni przed końcem – co nie zawsze wystarczy). Mimo to, mechanizm działa: wykonawca pokazał np. przykładowy e-mail z systemu z informacją o terminie, co oznacza, że pewna automatyka istnieje.

 1,5 pkt – Pełne działanie alertów z drobnymi ograniczeniami. System monitoruje kluczowe daty i wysyła/pokazuje przypomnienia odpowiednim osobom. W demonstracji widać, że np.

opiekunowie umów dostali e-maile zgodnie z oczekiwaniem, a w aplikacji jest miejsce, gdzie zbiorczo te alerty widać. Mechanizm może wymagać drobnej konfiguracji, ale jest elastyczny (można ustawić np. horyzont powiadamiania). Istnieje możliwość różnych kanałów (np. mail, okienko w aplikacji). Być może brak jest jedynie bardziej zaawansowanych opcji (np. kaskadowych przypomnień: 30 dni i 7 dni przed – system wysyła tylko raz). Ogólnie jednak nic ważnego nie umyka – zaprezentowano, że umowy testowe z terminami generują spodziewane alerty.

 2 pkt – Inteligentne i wszechstronne alertowanie. System nie tylko wysyła standardowe przypomnienia, ale pozwala też na dostosowanie reguł i harmonogramu powiadomień. W prezentacji wykonawca mógł np. pokazać, że dla różnych typów umów można ustawić różne wyprzedzenie (np. dla umów rocznych – 1 miesiąc przed, dla umów krótkoterminowych – 1 tydzień) i system to wspiera. Alerty są wysyłane wiele razy, jeśli termin minął a brak akcji (np. powiadomienie ponowne w dniu terminu). Ponadto, mechanizm jest zintegrowany z innymi funkcjami – np. jeśli umowa jest przedłużona, alert automatycznie znika. Możliwe są powiadomienia do wielu kanałów jednocześnie. Najwyższa punktacja zakłada, że zaprezentowane alertowanie działa niezawodnie, jest konfigurowalne i powiązane z rolami użytkowników (właściwe osoby dostają właściwe alerty) oraz że nie ogranicza się tylko do jednego rodzaju terminu, ale obejmuje całość istotnych terminów umownych.

7. Wersjonowanie dokumentów zintegrowane z pakietem Microsoft Office. (max. 1 pkt).

Cel funkcjonalny

Zapewnienie mechanizmu wersjonowania dokumentów (śledzenia zmian i przechowywania historycznych wersji) w taki sposób, by był on zintegrowany z pracą w programach Office (Word, Excel). Oznacza to, że gdy użytkownik edytuje dokument przechowywany w systemie, zmiany zostają zapisane jako nowa wersja dokumentu automatycznie lub półautomatycznie, a użytkownik może z poziomu systemu przeglądać poprzednie wersje, porównywać je i ewentualnie przywracać. Integracja z MS Office powinna ułatwiać edycję – np. otwarcie pliku z repozytorium uruchamia Worda, a zapis w Wordzie oddaje nową wersję do systemu, bez ręcznego eksportu/ponownego wgrywania pliku.

Kroki działania w systemie

1. Użytkownik znajduje określony dokument (np. poprzez listę dokumentów lub wyszukiwarkę).

2. System pobiera plik i otwiera go np. w Word na stanowisku użytkownika. (Jeśli jest plugin, może to zrobić automatycznie; jeśli nie – użytkownik może otworzyć plik ręcznie, zapisawszy go lokalnie).

3. Użytkownik dokonuje zmian w treści dokumentu w Word – np. aktualizuje paragraf z kwotą, zmienia datę lub inne postanowienia.

4. System tworzy kolejną wersję dokumentu. Poprzednia wersja jest archiwizowana.

5. Użytkownicy mają dostęp do historii wersji.

6. W systemie wersjonowanie może obejmować dynamiczne blokowanie edycji.

Oczekiwany rezultat

System zachowuje pełną historię zmian dokumentu i integruje się z typowym narzędziem biurowym, jakim jest MS Office, aby ułatwić proces edycji. Po zakończeniu scenariusza, komisja widzi:

 W obszarze dokumentów jest dokument z dwiema (lub więcej) wersjami, które można wyświetlać.

 Treść wersji poprzedniej i nowej różni się dokładnie w tych miejscach, gdzie użytkownik dokonał edycji.

 Użytkownicy mogą łatwo otworzyć starą wersję (np. Word z wersją tylko-do-odczytu) oraz przywrócić ją, jeśli to konieczne.

 Wersje są numerowane, datowane i podpisane kto dokonał zmian. Np. Wersja 2 z datą i nazwiskiem Użytkownika.

Skala punktowa:

 0 pkt – Brak funkcji wersjonowania dokumentów. System przechowuje tylko aktualną wersję pliku – nadpisanie powoduje utratę poprzedniej treści. W demonstracji nie widać opcji wersji, ani możliwości odzyskania starego pliku.

 0,5 pkt – Podstawowe wersjonowanie, brak integracji. System może zachować historię plików, ale w sposób mało wygodny. Np. użytkownik musi ręcznie tworzyć kopie lub system tworzy wersje, ale nie ma powiązania z edycją w Office – użytkownik sam musi wgrać nowy plik jako kolejną wersję. Wersje są przechowywane, lecz brak głębszej integracji (np. brak blokowania edycji, brak porównywania różnic, brak automatycznego zapisu). Funkcjonalność istnieje, lecz wymaga dużej uwagi od użytkowników.

 1 pkt – Pełne wersjonowanie z integracją Office. System automatycznie tworzy nowe wersje przy edycji dokumentów i jest to zintegrowane z procesem edycji. W demonstracji widać, że edytowanie pliku Word z repozytorium skutkuje utworzeniem kolejnej wersji przy zapisie, a poprzednia pozostaje dostępna. Można wygodnie przeglądać historię i pobierać stare wersje. Użytkownicy nie muszą myśleć o numeracji plików – system robi to za nich.

8. Mechanizm zarządzania Voiceprintami, (max. 2 pkt).

Cel funkcjonalny

Udostępnienie w systemie mechanizmów zarządzania danymi biometrycznymi głosu użytkowników (tzw. voiceprintami, czyli wzorcami głosowymi). Chodzi o to, by administratorzy mogli tworzyć, usuwać i importować profile głosowe wykorzystywane do uwierzytelniania lub identyfikacji użytkowników. Funkcja ta jest istotna w kontekście wdrożenia biometrii głosowej – system powinien pozwalać np. na zarejestrowanie głosu pracownika podczas rozmowy, zapis tego wzorca w bazie, ewentualnie usunięcie (gdy pracownik odchodzi lub odwoła zgodę) oraz import już wcześniej nagranych voiceprintów (np. z innej bazy voiceprintów). Celem jest centralna administracja voiceprintami oraz zapewnienie zgodności z przepisami (np. łatwe usunięcie danych biometrycznych na żądanie).

Kroki działania w systemie

1. Użytkownik otwiera zarządzanie voiceprintami.

2. Na liście użytkowników widzi kolumnę z informacją, kto ma zarejestrowany wzorzec głosu

3. Tworzenie voiceprintu podczas rozmowy. Użytkownik inicjuje proces rejestracji głosu. Może to wyglądać tak:

o Wywołuje funkcję dodawania voiceprint przy danym użytkowniku. System przechodzi w tryb nasłuchiwania (o ile stacja robocza ma mikrofon) lub generuje link/kod dla urządzenia mobilnego użytkownika.

o Użytkownik (w obecności administratorki lub poprzez swój telefon/aplikację) czyta na głos przedstawiony przez system tekst (np. kilka zdań lub ciąg cyfr). System nagrywa próbkę głosu i automatycznie tworzy z niej wzorzec głosowy.

o Postęp jest widoczny: np. wskaźnik nagrywania, informacja „Proszę mówić przez 10 sekund… zakończono”.

o Po zakończeniu, system wyświetla komunikat „Voiceprint utworzony pomyślnie” i nowy status przy Użytkowniku: zarejestrowano (dzisiaj, przez użytkownika).

4. Usuwanie voiceprintu: Użytkownik demonstruje usunięcie. Np. dla Użytkownika klika

„Usuń voiceprint”. System pyta o potwierdzenie (bo to działanie nieodwracalne). Użytkownik potwierdza. Status Użytkownika zmienia się na brak voiceprintu, a dane biometryczne zostają usunięte z bazy.

5. Import voiceprintu: Teraz Użytkownik chce zaimportować istniejący wzorzec (np. z zewnętrznego systemu). Wybiera opcję „Importuj voiceprint” i wskazuje plik voiceprintu

danego użytkownika oraz dane użytkownika, do którego ma zostać przypisany (Użytkownik). System zapisuje voiceprint Użytkownika (ew. nadpisując to co nagrano przed chwilą, albo scenariusz alternatywny: najpierw usunięto i teraz import). Status Użytkownika pozostaje „zarejestrowany”, a w logach odnotowano import (źródło zewnętrzne).

6. Użytkownik prezentuje w logach audytu, że wykonane zostały operacje: utworzenie voiceprintu dla Użytkownika, usunięcie dla Użytkownika, import dla Użytkownika – wraz z czasem i swoim identyfikatorem, co dowodzi pełnej kontroli i audytowalności tych działań.

Oczekiwany rezultat

System oferuje intuicyjne narzędzia do pełnego cyklu zarządzania voiceprintami:

 Dodawanie (rejestrowanie) głosu użytkownika przebiega sprawnie – wystarczy krótka próbka, po której system potwierdza pomyślną rejestrację.

 Usuwanie natychmiast usuwa powiązane dane i zmienia status użytkownika (co jest ważne np. w kontekście RODO – prawo do usunięcia danych biometrycznych).

 Import umożliwia przeniesienie danych biometrycznych z innej bazy, co przydaje się przy migracji systemu lub integracji z dedykowanym modułem biometrii.

 Voiceprinty nie umożliwiają syntezy głosu użytkownika poprzez operację odwrotną do tworzeni voiceprintu

Po tych operacjach użytkownicy mogą np. korzystać ze swoich voiceprintów do logowania, a system od strony administracyjnej ma nad tym pełną kontrolę. W efekcie, mechanizm zarządzania spełnia wymagania bezpieczeństwa (np. nie można podejrzeć samego nagrania – tylko usunąć lub zastąpić, co chroni prywatność; dostęp do funkcji mają tylko admini). W komisji buduje to zaufanie, że biometria głosowa jest dobrze zaimplementowana i daje się zarządzać.

Skala punktowa

 0 pkt – System nie obsługuje voiceprintów w ogóle. Brak jakichkolwiek funkcji związanych z biometrią głosową. W konsekwencji nic nie zostało zaprezentowane w tym obszarze.

 0,5 pkt – System posiada mechanizm weryfikacji głosowej ale voiceprinty są tworzone w sposób umożliwiający odtworzenie na ich podstawie próbki głosu z jakiego zostały utworzone przez co nie spełniają elementarnych wymagań w zakresie bezpieczeństwa danych biometrycznych

 1 pkt – System posiada pewne elementy biometrii głosowej, lecz zarządzanie nimi jest bardzo słabo rozwinięte. Np. voiceprint tworzy się ewentualnie podczas rejestracji użytkownika, ale administrator nie ma opcji samodzielnego wywołania procesu lub usunięcia wzorca (musiałby np. skasować całe konto). Import zewnętrznych voiceprintów nie jest możliwy. Demonstracja być może pokazała tylko, że ktoś ma już voiceprint, ale nie jak go tam umieszczono. Ogólnie zarządzanie nie jest udostępnione jako oddzielna funkcja – voiceprinty działają jak ukryty element systemu

 1,5 pkt – Podstawowe funkcje zarządzania voiceprintami są dostępne: rejestracja i usunięcie. Wykonawca pokazał, że może nagrać wzorzec głosu użytkownika (np. za pomocą aplikacji) i że może go usunąć z bazy. Jednak brakuje importu lub innych zaawansowanych działań. System więc pozwala na budowę bazy voiceprintów i ich kasowanie, ale nie obsługuje przenoszenia danych między systemami. Ewentualnie import jest możliwy tylko w formie nieoficjalnej (np. bezpośrednia manipulacja bazą, nie przez interfejs)

 2 pkt – Wzorcowe zarządzanie voiceprintami. System oferuje bogaty, dopracowany interfejs do administrowania biometrią głosową. W prezentacji wszystko przebiegło sprawnie: rejestracja głosu w czasie rzeczywistym (jedna próba, 10 sekund – gotowe), usunięcie jednym kliknięciem, import szybko i bez błędów. Dodatkowo mogą istnieć dodatkowe funkcje warte odnotowania: np. możliwość testowego zweryfikowania voiceprintu (sprawdzenie jakości wzorca), eksportu (kontrolowanego) w celach backupu czy podglądu listy wszystkich zarejestrowanych voiceprintów z informacją o jakości/aktualności. Mechanizmy te działają

zgodnie z oczekiwaniami i są zabezpieczone (np. potwierdzenia przy usuwaniu). System, który może być zintegrowany, prawdopodobnie dostarcza takie możliwości – zakładamy, że demonstracja je uwzględniła. Przyznane 4 pkt oznacza, że komisja nie ma wątpliwości co do możliwości zarządzania bazą voiceprintów – jest ona w pełni pod kontrolą Zamawiającego.

9. Mechanizm skuteczności biometrii głosowej (max. 2 pkt).

Cel funkcjonalny

Ocena, na ile efektywnie system potrafi weryfikować tożsamość użytkownika na podstawie głosu, czyli jaki jest poziom skuteczności zastosowanej biometrii głosowej. Innymi słowy, mechanizm ten powinien potwierdzić, że logowanie lub identyfikacja za pomocą głosu działa dokładnie i niezawodnie, odróżniając właściwych użytkowników od niepowołanych z wysoką trafnością. Celem jest wykazanie, że biometria głosowa jest praktycznie użyteczna – akceptuje prawidłowych użytkowników (ich głos) i odrzuca osoby podszywające się.

Kroki działania w systemie

1. Użytkownik próbuje zalogować się głosem. Użytkownik czyta na głos wymaganą frazę ().

o System porównuje próbkę głosu z voiceprintem Użytkownika.

o Rezultat: Pozytywna weryfikacja – system rozpoznaje, że głos należy do Użytkownika (prawowitego użytkownika). Wyświetla komunikat np. „Weryfikacja głosowa pomyślna” i pozwala na dalsze działanie.

2. Impostor (osoba nieuprawniona) – teraz testujemy sytuację ataku:

o Podszywający się użytkownik () wypowiada tę samą frazę co Użytkownik (ale może też inną).

o System dokonuje analizy i porównuje z voiceprintem Użytkownika.

o Ponieważ głos nie należy do Użytkownika, wynik powinien być negatywny. System odrzuca próbę – np. komunikat „Weryfikacja głosowa nieudana – głos niezgodny z wzorcem”. Brak dostępu.

3. Można powtórzyć różne warianty:

o Uzytkownik loguje się swoim głosem – powinna zostać poprawnie rozpoznana (sukces).

o Użytkownik próbuje użyć cudzego konta (ale i tak musi swoim głosem – co system odrzuci, bo głos nie pasuje do voiceprintu konta innej osoby).

o Test odporności: odtwarzamy nagranie Użytkownika sprzed lat lub z zakłóceniami, by zobaczyć czy system nadal go rozpozna (zakładamy, że tak, o ile jakość nie spadła drastycznie).

4. W przypadku zaawansowanych systemów, mechanizm skuteczności może pokazywać pewne metryki:

o Np. po każdej próbie wewnętrznie liczony jest score dopasowania (np. 87%).

o Administrator może mieć dostęp do statystyk: ile prób logowania głosowego się powiodło, ile nie, czy wystąpiły jakieś fałszywe akceptacje/odrzucenia.

o Dla prezentacji, można pokazać np. w logu technicznym, że dla próby Użytkownika score był 98% (powyżej progu 90% – akceptacja), dla impostora 40% (poniżej progu – odrzucenie).

5. Użytkownik (admin) może zademonstrować konfigurację progu wrażliwości: np. ustawić poziom bezpieczeństwa wyżej czy niżej i powtórzyć test. Ale to opcjonalne.

Oczekiwany rezultat

Mechanizm biometrii głosowej demonstruje wysoką skuteczność i wiarygodność. Wszystkie przeprowadzone próby autentycznego użytkownika kończą się pozytywną weryfikacją, a próby oszustwa – negatywną, co oznacza, że system nie dopuścił nieautoryzowanego dostępu. Jeśli testowano graniczne przypadki (np. nieco zniekształcony głos prawidłowego użytkownika),

system nadal sobie poradził albo pokazał, że ma pewien zapas tolerancji (np. poprosił o powtórzenie frazy, ale nie wpuścił kogoś o innym głosie). W idealnym przypadku zaprezentowano też liczbowo skuteczność: np. „system rozpoznaje głos z 99% dokładnością” – jednak nawet bez tego, sam fakt bezbłędnego rozpoznania w kilku próbach jest dowodem jakości.

Skala punktowa:

 0 pkt – Nie pokazano działania biometrii głosowej lub jest ona nieskuteczna. Np. system w ogóle nie rozpoznaje nawet poprawnego użytkownika (liczne błędy odrzucenia) albo – co gorzej – przepuszcza obce głosy. Jeżeli w demonstracji próba uwierzytelnienia głosem zawodzi dla właściwej osoby, lub uda się zalogować „cudzym” głosem, oznacza to poważny problem – skuteczność bliska zeru – i 0 punktów.

 0,5 pkt – System wykazuje niski poziom skuteczności. Pojawiają się częste błędy: np. prawidłowy użytkownik musi kilkukrotnie powtarzać próbkę, bo system go nie rozpoznaje za pierwszym/drugim razem. Albo dopuszczono pewien przypadek niepoprawny (np. inna osoba o bardzo podobnym głosie mogła przejść – może nie celowo zaprezentowane, ale wykonawca nie gwarantuje, że do takich sytuacji nie dojdzie). Widać, że technologia jest zawodna lub bardzo wrażliwa na warunki (np. minimalny hałas powoduje problemy). Ogólnie zaufanie do mechanizmu jest niskie.

 1 pkt – Umiarkowana skuteczność. System generalnie rozpoznaje właściwy głos i odrzuca obcy, ale w testach mogły się zdarzyć drobne potknięcia. Na przykład:

o Pierwsza próba logowania Użytkownika nie powiodła się (może mówił za cicho lub za szybko), dopiero druga się udała – co sugeruje, że trzeba uważać.

o System rozpoznał obcy głos poprawnie jako obcy (czyli zablokował), jednak demonstrujący ostrzegł, że w pewnych okolicznościach, np. przy bardzo podobnych głosach, może być pomyłka.

o Podsumowując, mechanizm jest funkcjonalny, ale nie bezbłędny. Komisja widzi, że działa, ale z pewną ostrożnością.

 1,5 pkt – Wysoka skuteczność w praktyce. W trakcie demonstracji system nie popełnił żadnego błędu rozpoznania w zaprezentowanych przypadkach. Zarówno Użytkownik, jak i Anna byli prawidłowo uwierzytelnieni, a obcy głos został odrzucony natychmiast. Wykonawca zapewnił, że EER ma wartość nie większą niż 6% i wykazał metodę wyznaczenia EER.

 2 pkt – Nadzwyczajna skuteczność i odporność mechanizmu. Oprócz spełnienia warunków z poziomu 3 (bezbłędne rozpoznania w testach), system wykazuje odporność na próby obejścia z użyciem zaawansowanych metod ataku. W prezentacji mogło to zostać zademonstrowane lub omówione. Przykładowo:

o Dodatkowo mechanizm może adaptować się do użytkownika (aktualizować voiceprint po udanych logowaniach, żeby uwzględnić naturalne zmiany głosu, np. starzenie, drobne choroby, różne tło).

10. Skuteczność działania mechanizmu zabezpieczającego przed atakami (max. 2 pkt).

Cel funkcjonalny

Wykazanie, że system posiada zaimplementowane solidne mechanizmy bezpieczeństwa chroniące przed atakami prezentacji. Mechanizm ma za zadanie zabezpieczyć system przed logowaniem z wykorzystaniem odtworzonego nagrania w scenariuszu, gdy po rozpoczęciu procesu logowania osoba mówiąca przestaje mówić i zaczyna odtwarzać nagranie lub syntezowany głos. Scenariusz ten ma za zadanie wykluczyć przypadki, w których proces logowania rozpoczyna się od mowy przez osobę o niskiej spójności biometrycznej z voiceprint ale 100% żywotności głosu, a po chwili następuje podmiana na odtwarzany głos o 0% żywotności, ale wysokiej spójności biometrczynej. W sytuacji takiej wiele

systemów wykaże uśredniony wynik spójności biometrycznej, który może spowodować spełnienie kryterium akceptacji użytkownika

Kroki działania w systemie

W procesie logowania głosowego na początku mówi osoba o bardzo niskiej spójności biometrycznej z voiceprintem Użytkownika (lub wszystkimi voiceprintami z bazy).

Po 2 sekundach osoba logująca się przestaje mówić i zaczyna odtwarzać nagranie z głosem Użytkownika, na którego konto chce zalogować się.

System automatycznie wykrywa zmianę źródła emisji głosu z człowieka na głos odtwarzany i blokuje możliwość logowania wraz z odpowiednim komunikatem systemowym oraz wpisem w logu zdarzeń ze wszystkimi szczegółami.

Oczekiwany rezultat

System efektywnie identyfikuje i zapobiega próbom ataku prezentacji. Przy pierwszej próbie realizacji ataku poprzez zamianę źródła emisji strumienia głosowego następuje zablokowanie możliwości zalogowania.

 Oczekiwane jest 100% skuteczne działanie przy odtwarzaniu nagrania w jakości SACD.

Skala punktowa

 0 pkt – System nie zabezpieczony przed atakami prezentacji

 0,5 pkt – Minimalne zabezpieczenia. System zabezpieczony przed atakami prezentacji, ale przy nagraniach o jakości gorszej niż SACD oraz skuteczny dla mniej niż 95% ataków

 1 pkt – Działające kluczowe mechanizmy bezpieczeństwa. System zabezpieczony przed atakami prezentacji przy nagraniach o jakości SACD oraz skuteczny dla mniej niż 95% ataków

 1,5 pkt – Zaawansowane zabezpieczenia i monitorowanie. Oprócz bazowych mechanizmów (jak blokada), system oferuje coś więcej: np. wykrywanie podejrzanej aktywności (co w demo mogło być zainscenizowane) i reagowanie na nią. Administrator dysponuje czytelnym podglądem zdarzeń bezpieczeństwa, a system być może integruje się z SIEM (jeśli to wspomniano). W każdym razie, w ocenie komisji rozwiązanie posiada solidną wielowarstwową ochronę, wykraczającą poza minimum. Wykonawca mógł wspomnieć np. że hasła są przechowywane hashowane, że każda próba logowania jest logowana wraz z IP, że po godzinach pracy dostęp jest wyłączany – choć nie wszystko da się pokazać, buduje to obraz wysokiej dbałości o bezpieczeństwo.

 2 pkt – Wzorcowe bezpieczeństwo, w pełni potwierdzone działaniem. System zabezpieczony w 100% przed atakami prezentacji z odtwarzaniem w nagrań w jakości SACD dla opisanego scenariusza

11. Mechanizm dwuetapowej autentykacji przy logowaniu. (max. 2 pkt).

Cel funkcjonalny

Zaprezentowanie procesu dwustopniowego uwierzytelniania (2FA) w oparciu o technologie głosowe. Podczas logowania musimy jedynie przeczytać krótką sekwencję znaków/tekstową znajdującą się na ekranie. Logowanie dwustopnione jest niezwykle bezpieczne poprzez podwójną autentykację. Podczas czytania tekstu weryfikowane są jednocześnie zgodność odczytanych słów (pierwszy stopień) z wzorcem jak również biometryczna zgodność głosu mówcy z jego VoicePrintem (drugi stopień).

Kroki działania w systemie

1. Użytkownik rozpoczyna logowanie do systemu (np. na laptopie z mikrofonem lub smartfonie). Na ekranie logowania pojawia się tekst do przeczytania i startuje licznik 10 sekund w którym Użytkownik musi przeczytać tekst

2. System rozpoznaje zgodność przeczytanego tekstu z wyświetlonym (1 stopień) oraz spójność biometryczną głosu z voiceprintem (2. stopień)

3. W przypadku zgodności w obydwu stopniach następuje zalogowanie a w przypadku niezgodności chociaż jednego stopnia następuje odrzucenie logowania.

4. Przy próbie kolejnego logowania wyświetlany jest nowy tekst do przeczytania

w każdym przypadku logowania (sukces/porażka) w logu systemowym następuje zarejestrowania danych logowania wraz ze wszystkimi informacjami takimi jak data i czas zdarzenia, tekst do przeczytania, tekst rozpoznany, spójności biometryczna głosu.

Oczekiwany rezultat

System pomyślnie demonstruje pełen proces VoiceToken logowania. Dla komisji ważne jest zobaczenie, że:

 Cały proces jest przyjazny użytkownikowi: interfejs wyraźnie informuje co zrobić (tekst do odczytania jest czytelny) i obywa się w pełni automatycznie.

 Bezpieczeństwo: tekst do przeczytania jest zawsze inny, składa się z losowych elementów, co utrudnia podszycie się

 Logowanie jest w pełni dwustopniowe za sprawą wykorzystania dwóch odmiennych technologii logowania

Skala punktowa

 0 pkt – Funkcjonalność nie istnieje lub nie została pokazana. Np. system wspiera tylko zwykłe logowanie hasłem; wykonawca nie ma możliwości pokazać drugiego etapu z głosem.

 0,5 pkt – Częściowe wdrożenie 2FA głosem. Być może system umożliwia co prawda potwierdzanie głosem, ale w sposób niepełny. Przykład: nie generuje dynamicznego tekstu – użytkownik zawsze powtarza tę samą frazę (co jest mniej bezpieczne, bo może być nagrana). Albo procedura jest bardzo niezgrabna technicznie (np. użytkownik musi sam uruchomić nagrywanie w oddzielnej aplikacji i załadować plik – mało przyjazne). Jeśli w demonstracji pojawiły się znaczne trudności (kilkukrotne powtarzanie frazy, bo nie rozumie, długi czas analizy) – to również wskazuje na niski poziom tej funkcji. Punkt 1 jeśli coś jest, ale raczej jako ciekawostka niż użyteczne rozwiązanie.

 1 pkt – Dwuetapowe logowanie głosem działa, ale z pewnymi problemami. Mechanizm VoiceToken jest zaimplementowany podstawowo: pseudolosowa fraza jest wybierana bazy predefinownych haseł, która nie jest silnie zabezpieczona lub liczność bazy umożliwia stworzenie listy haseł po do odczytania po wielokrotnym logowaniu. Mimo to finalnie udało się zalogować i zabezpieczenie zadziałało. Inaczej mówiąc – spełniono wymóg, ale mechanizm logowania przynajmniej w jednym stopniu jest relatywnie łatwy do złamania

 1,5 pkt – Pełna realizacja funkcji VoiceToken bez zauważalnych wad. W demonstracji logowanie dwuskładnikowe głosem przebiegło sprawnie za pierwszym razem i system poprawnie uwierzytelnił użytkownika. Nie było wątpliwości co do działania (żadnych błędów rozpoznania, komunikaty jasne). Wykonawca wykazał, że mechanizm jest dobrze zintegrowany i przemyślany. To najpewniej zadowoli Zamawiającego – stąd wysoka ocena. Aby osiągnąć jeszcze wyższą, musiałby zostać pokazany dodatkowy kontekst bezpieczeństwa. Jeśli wszystko poszło gładko i zgodnie z opisem, 3 pkt to odpowiednia ocena.

 2 pkt – Wyróżniająca się prezentacja dwuetapowej autentykacji głosem. Poza poprawnym działaniem (jak w pkt 3), wykonawca mógł zaprezentować dodatkowe scenariusze i informacje, które dowodzą, że system jest bardzo dojrzały w tym obszarze. Np.:

o Generalnie, komisja jest pod dużym wrażeniem – funkcja działa jak reklamowana: „dwustopniowa, silna autentykacja przy użyciu samego głosu”. Najwyższa ocena wskazuje, że rozwiązanie VoiceToken zostało kompletnie i przekonująco przedstawione i działa bez zarzutu, zapewniając zarówno bezpieczeństwo, jak i wygodę użytkownika na poziomie wyższym niż tradycyjne metody.

Zarzut nr 3 Definicja Oprogramowania Standardowego i Oprogramowania Dedykowanego

Odwołujący zarzuca, iż w dokumentacji przetargowej występują wadliwie, niejednoznacznie sformułowane definicje Oprogramowania Dedykowanego, które uniemożliwiają złożenie oferty.

Odpowiedź Zamawiającego:

Zamawiający, określając definicje Oprogramowania Standardowego i Oprogramowania Dedykowanego, kierował się koniecznością zabezpieczenia interesu publicznego oraz zapewnienia możliwości samodzielnego lub zleconego dalszego rozwijania systemu w zakresie modyfikacji i rozbudów stworzonych w ramach realizacji umowy. Z tego względu modyfikacje i rozbudowy Oprogramowania Standardowego, powstałe w toku realizacji zamówienia, stanowią Oprogramowanie Dedykowane i w tym zakresie Zamawiający ma prawo żądać przekazania kodów źródłowych oraz praw autorskich. Takie podejście jest uzasadnione potrzebą zapewnienia ciągłości działania i możliwości dostosowywania systemu do przyszłych wymagań prawnych, organizacyjnych i technologicznych, bez uzależnienia od jednego wykonawcy. Brak pozyskania praw i kodów źródłowych do stworzonych lub zmodyfikowanych elementów mógłby uniemożliwić dalsze utrzymanie i rozwój systemu, a tym samym narazić Zamawiającego na istotne ryzyko organizacyjne i finansowe. Jednocześnie, by wyeliminować niejasności interpretacyjne dotyczące zakresu znaczeniowego Oprogramowania Standardowego i Oprogramowania Dedykowanego Zamawiający w definicji Oprogramowania Standardowego zawartego w Opisie Przedmiotu Zamówienia (tabela z definicjami, definicja „Oprogramowanie”) wprowadza następującą modyfikację polegającą na wykreśleniu konieczności przekazania kodów źródłowych w przypadku oprogramowania standardowego. Ten element został ujęty przez Zamawiającego w definicji omyłkowo.

(…)

JEST

Oprogramowanie - całość lub dowolny element oprogramowania dostarczany lub wykonywany w ramach realizacji Umowy. W skład oprogramowania wchodzi:

1) „Oprogramowanie Standardowe” – oprogramowanie będące podstawą do budowy Systemu i/ tworzące środowisko, w którym uruchamiany jest System, istniejące i dystrybuowane przed zawarciem Umowy.

2) „Oprogramowanie Dedykowane” – oprogramowanie tworzone przez Wykonawcę lub osoby, którymi się posługuje w wykonaniu zobowiązań z Umowy, w tym rozbudowa lub modyfikacja Oprogramowania Standardowego. Oprogramowanie dedykowane jest specjalnie stworzone tylko do realizacji przedmiotu Umowy lub stworzenie jego wynika z potrzeb Zamawiającego. Na oprogramowanie dedykowane Wykonawca przekazuje kody źródłowe oraz wszelkie prawa autorskie do oprogramowania.

Zarzut nr 4 Exit Plan

Odwołujący nie może zaakceptować tak ogólnych zapisów, które mogą być bardzo szeroko interpretowane i mogą zmaterializować się w bardzo kosztowny projekt doradczo-konsultingowy. Odwołujący na etapie składania oferty nie jest w stanie zidentyfikować tak blankietowo opisanych zobowiązań, a w konsekwencji ich wycenić.

Odpowiedź Zamawiającego:

Zamawiający nie podziela zarzutu sformułowanego przez Odwołującego. Zakres obowiązków wynikających z tzw. Exit Planu zależy w istotnym stopniu od rodzaju i architektury zastosowanego oprogramowania, a także od przyjętych rozwiązań technicznych i organizacyjnych po stronie Wykonawcy. W związku z tym to Wykonawca, dysponując wiedzą o proponowanym przez siebie systemie i sposobie jego wdrożenia, jest w stanie najlepiej oszacować nakład pracy niezbędny do realizacji zobowiązań wynikających z Exit Planu. Określenie w dokumentacji postępowania sztywnej liczby roboczogodzin mogłoby prowadzić do sytuacji, w której przyjęty limit byłby nieadekwatny – zbyt wysoki lub zbyt niski – względem rzeczywistych potrzeb. W pierwszym przypadku powodowałoby to niegospodarność, w drugim zaś ryzyko niewystarczającego wykonania zobowiązań. Dlatego Zamawiający pozostawił tę kwestię do oceny Wykonawcy, zobowiązując go do uwzględnienia kosztu realizacji Exit Planu w kalkulacji ceny ofertowej. Takie rozwiązanie jest racjonalne i zgodne z zasadami efektywnego wydatkowania środków publicznych. (…)

Odwołujący w piśmie procesowym z dnia 22 września 2025 r. wskazując na art. 520 ust. 1 i 2 ustawy z dnia 19 września 2019 r. – Prawo zamówień publicznych oświadczył: (...) po zapoznaniu się z odpowiedzią Zamawiającego na odwołanie z dnia 7 sierpnia 2025 i zapowiedzianymi zmianami w SWZ, które realizują co do zasady żądania odwołania, niniejszym cofam odwołanie (sygn. akt KIO 3313/25) w całości.”.

Izba ustaliła i zważyła, co następuje:

Postępowanie odwoławcze w niniejszej sprawie podlega umorzeniu na podstawie art. 520 ust.1 ustawy Pzp w związku z oświadczeniem złożonym przez wnoszącego odwołanie wykonawcę o cofnięciu odwołania. Zgodnie z art. 520 ust. 1 ustawy Pzp: „Odwołujący może cofnąć odwołanie do czasu zamknięcia rozprawy”.

W niniejszej sprawie ma zastosowanie wskazany przepis, albowiem Odwołujący w piśmie z dnia 22 września 2025 r. - przed wyznaczeniem terminu posiedzenia i rozprawy jednoznacznie oświadczył, że cofa odwołanie wniesione w przedmiotowym postępowaniu o udzielenie zamówienia publicznego.

Izba dodatkowo zauważa, że w myśl art. 520 ust. 2 Pzp: „2.Cofnięte odwołanie nie wywołuje skutków prawnych, jakie ustawa wiąże z wniesieniem odwołania do Prezesa Izby”. Odwołujący – jak podkreśla się w orzecznictwie i doktrynie Prawa zamówień publicznych - jest dysponentem wniesionego przez siebie odwołania, co przejawia się również w uprawnieniu do jego wycofania. Krajowa Izba Odwoławcza nie bada i nie ocenia przyczyn cofnięcia odwołania. Bada wyłącznie formalną skuteczność złożenia oświadczenia o jego cofnięciu. Skuteczne cofnięcie odwołania jest wiążące dla Krajowej Izby Odwoławczej. Ponadto cofnięcie odwołania nie wymaga zgody pozostałych stron i uczestników postępowania.

Tym samym Izba na podstawie art. 568 pkt 1 ustawy Pzp w związku z art. 520 ust.1 powołanej ustawy postanowiła o umorzeniu postępowania odwoławczego.

Orzekając o kosztach postępowania odwoławczego Izba miała na uwadze art. 557 ustawy Pzp oraz § 9 ust. 1 pkt 3 lit. a) rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz.U. z 2020 r., poz. 2437) i uwzględniając wskazane przepisy, nakazała zwrócić na rzecz Odwołującego 90% kwoty wpisu uiszczonego od odwołania w wysokości 15.000 zł.

Mając powyższe na uwadze postanowiono jak w sentencji.

………………………………………

………………………………………

………………………………………