Sektor publiczny potrzebuje zamówień, które potrafią odmówić

Odpowiedzialność organu publicznego nie zaczyna się od podpisania umowy na system AI. Zaczyna się, gdy jego wymagania, dowody, ludzka władza decyzyjna,...

Sektor publiczny potrzebuje zamówień, które potrafią odmówić

Dokument, który może zakończyć zakup

Dokumentacja zamówienia publicznego często zaczyna się od prośby, która brzmi niewinnie: znajdź system, który pomoże w wykonaniu zadania. Prośba przechodzi przez opis problemu, konsultacje rynkowe, zestaw wymagań, ocenę ofert, umowę i, jeśli proces przebiega prawidłowo, decyzję, która wciąż może zatrzymać prace. Ostatnią z tych możliwości łatwo stracić z oczu. Gdy wokół zakupu zgromadzą się pieniądze, terminy i uwaga polityków, słowo „nie” zaczyna brzmieć jak porażka w dostawie. W pracy publicznej może to być jednak najbardziej użyteczna decyzja w całej dokumentacji.

Europejskie prawo zamówień publicznych już traktuje ofertę jako coś więcej niż konkurs atrakcyjnych obietnic. Dyrektywa 2014/24/UE stanowi, że kryteria udzielenia zamówienia muszą umożliwiać skuteczną i uczciwą konkurencję oraz muszą być powiązane z rozwiązaniami pozwalającymi instytucji zamawiającej zweryfikować informacje dostarczone przez wykonawców. Dyrektywa mówi również, że kryteria nie powinny dawać instytucji nieograniczonej swobody wyboru. Zamawiający publiczny musi opisać, co ma znaczenie, wyjaśnić, jak będzie to oceniane, i sprawdzić, czy oferta faktycznie to spełnia. To nie jest administracyjny przypis. To prawny kształt decyzji, którą inni muszą móc zrozumieć i zakwestionować.

Sztuczna inteligencja utrudnia tę starą dyscyplinę, ponieważ dostawca może zaoferować system, którego działanie zależy od danych, aktualizacji modelu, promptów, progów, integracji, ludzi oraz usługi, która może się zmieniać, gdy umowa jest jeszcze świeża. Broszura może pozostać ta sama, podczas gdy rzecz za nią się zmienia. Zespół zamawiający musi zatem kupić coś więcej niż interfejs. Musi kupić ograniczoną możliwość, dowód, że ta możliwość jest odpowiednia, uprawnienie do jej nadzorowania oraz wiarygodny sposób jej zatrzymania lub wymiany.

Sektor publiczny potrzebuje zamówień, które potrafią powiedzieć „nie”, ponieważ sektor publiczny nie może zlecić na zewnątrz własnego osądu. Dostawca może dostarczyć model, proces, usługę hostowaną lub zestaw narzędzi. Nie może dostarczyć legitymizacji decyzji podjętej za ich pomocą. Instytucja wciąż musi wiedzieć, jaki problem rozwiązuje, czyje interesy mogą być naruszone, jakie dowody wspierają system, która osoba może interweniować oraz jak usługa będzie kontynuowana, jeśli dostawca zmieni kierunek. Podpis nie jest przeniesieniem odpowiedzialności. To zapis, że odpowiedzialność została zorganizowana.

Ten artykuł śledzi tę organizację od pierwszego zdania wymagania do ostatniej linii protokołu zakończenia. Wykorzystuje europejskie wytyczne publiczne i materiały dotyczące zamówień jako dowody. Praktyczne wzorce są rekomendacjami, a nie twierdzeniem, że każda instytucja musi stosować jedną formę. Każda wymyślona sytuacja jest oznaczona jako hipotetyczna. Wiarygodne biuro, schludna oferta i dramatyczna porażka nie są dowodem tylko dlatego, że pasują do znajomej historii.

Zamawiający publiczny kupuje obietnicę dwa razy

Każdy zakup publiczny niesie ze sobą dwie obietnice. Pierwszą jest obietnica dostawcy dotycząca produktu lub usługi. Drugą jest obietnica instytucji wobec ludzi, którzy zależą od tej pracy: że pieniądze zostały wydane na określony cel publiczny, że decyzja może być wyjaśniona, że uwzględniono istotne prawa oraz że ktoś pozostaje odpowiedzialny, gdy system zawiedzie. Druga obietnica to ta, która przetrwa wydarzenie inauguracyjne.

Zamówienia na sztuczną inteligencję często czynią pierwszą obietnicę wyrazistą, a drugą niejasną. Demonstracja może pokazać płynne podsumowanie, rankingową listę lub szybką odpowiedź. Rzadko pokazuje, kto może odrzucić wynik, co się dzieje, gdy brakuje źródła, jak zatwierdza się zmianę, czy rekordy można wyeksportować albo która osoba może wstrzymać usługę bez negocjowania własnych uprawnień w trakcie incydentu. Te pytania są mniej efektowne. Są to jednak pytania, które decydują o tym, czy organ publiczny może zachować kontrolę.

Komisja Europejska opisuje w ramach społeczności publicznych nabywców zaktualizowane wzorcowe klauzule umowne dotyczące sztucznej inteligencji w trzech częściach: pełnej wersji dla systemów wysokiego ryzyka zgodnej z aktem o sztucznej inteligencji, wersji uproszczonej, którą można dostosować do systemów niewysokiego ryzyka, oraz komentarzu dotyczącym sposobu stosowania i adaptacji tych klauzul. To rozróżnienie ma znaczenie. Wzorzec klauzuli nie jest magiczną pieczęcią, która czyni zamówienie właściwym. To punkt wyjścia do podziału obowiązków między instytucją publiczną a dostawcą w umowie, której zakres, cel i sposób weryfikacji wciąż musi określić zamawiający.

Zamawiający powinien zatem najpierw zapytać, co tak naprawdę obiecuje społeczeństwu, zanim zapyta, co dostawca potrafi wykazać. Czy instytucja obiecuje szybsze rozpatrywanie zaległych spraw, bardziej spójną pierwszą ocenę, bezpieczniejszą kontrolę, lepsze wykorzystanie ograniczonej ekspertyzy, czy po prostu eksperyment, którego granice są widoczne? Każdy cel rodzi inne wymagania dowodowe i inne powody, by przerwać. System sporządzający notatki wewnętrzne może wymagać innych granic uprawnień niż system rankingujący wnioski o usługę, której ludzie nie mogą uniknąć.

Wyobraźmy sobie hipotetyczny zespół oceniający narzędzie do streszczania zgłoszeń dostawców. Zespół może uznać, że zadanie nadaje się do wsparcia, ale tylko pod warunkiem, że streszczenie zachowa wykluczenia, warunki i terminy oraz odsyła oceniających do odpowiednich fragmentów źródłowych. Jeśli dostawca nie potrafi wykazać, w jaki sposób te wymagania zostaną przetestowane, zespół powinien móc odrzucić narzędzie lub zawęzić zakres umowy. To nie jest oskarżenie wobec dostawcy. To wniosek o dostępnych dowodach dla zdefiniowanego celu.

To samo rozumowanie stosuje się, gdy problem jest atrakcyjny, ale słabo określony. Instytucja publiczna może chcieć przewidywać popyt, ustalać priorytety kontroli lub kierować korespondencję. Te czasowniki skrywają decyzje, które się za nimi kryją. Co liczy się jako popyt. Co zmienia priorytet. Która korespondencja może być bezpiecznie kierowana bez przeczytania jej przez człowieka. Pierwsze „nie” może dotyczyć zakresu problemu, a nie użycia oprogramowania. Odmowa zakupu o niejasnym zakresie to często sposób, w jaki instytucja chroni użyteczną część pracy przed częścią, której nie można przetestować.

Opisz problem, zanim zaproponujesz rozwiązanie

Zamówienia stają się kruche, gdy kategoria produktu pojawia się, zanim problem publiczny zostanie nazwany. Sztuczna inteligencja szczególnie sprzyja takiej kolejności, ponieważ ten sam model można przedstawić jako asystenta pisania, klasyfikator, warstwę wyszukiwania lub agenta, w zależności od slajdu. Instytucja musi opisać pracę w sposób, który pozostanie sensowny po usunięciu dostawcy, rodziny modeli i interfejsu.

Holenderski Algoritmekader, prowadzony dla instytucji publicznych, zaleca takie działania. Instytucje są proszone o opisanie zamierzonego celu i wykorzystywanych danych, określenie właściwej grupy ryzyka, ustalenie wpływu, gdyby algorytm nie działał zgodnie z przeznaczeniem, oraz podjęcie decyzji, czy rozwiązanie należy opracować, czy kupić. Kader wskazuje również na architekturę startową projektu dla opracowywania lub nabywania algorytmów. To nie ozdobniki w zamówieniach. To sposoby na uczytelnienie problemu, zanim padnie propozycja rozwiązania.

Dobre wymaganie zaczyna się od decyzji lub usługi, która ma się poprawić, osób, które ją wykonują lub z niej korzystają, informacji, które system może wykorzystywać, informacji, których nie może wykorzystywać, oraz pozostałego zakresu decyzji człowieka. Określa warunki, w których system jest użyteczny, oraz warunki, w których nie wolno go używać. Wskazuje dokumenty, które muszą powstać, gdy wynik zostanie zaakceptowany, odrzucony, poprawiony lub przekazany do wyższej instancji. Nie musi przewidywać wewnętrznego projektu dostawcy. Musi definiować publiczną zdolność, którą można poddać kontroli.

To tutaj liczą się wymagania funkcjonalne i dotyczące wydajności. Dyrektywa 2014/24/UE wymaga, aby specyfikacje techniczne były na tyle precyzyjne, by wykonawcy mogli zrozumieć przedmiot zamówienia, a zamawiający ocenić, jak oferty spełniają kryteria. Wymaganie takie jak „zapewnić inteligentne rozwiązanie” nie jest użytecznym testem. Wymaganie takie jak „zachować fragmenty źródłowe wykorzystane w projekcie, pokazać datę pobrania, umożliwić recenzentowi odrzucenie projektu i wyeksportowanie powstałego rekordu” jest bliższe możliwej do sprawdzenia potrzebie publicznej. Opisuje ono zachowanie i ścieżkę dowodową, a nie modę.

Wymagania powinny też wyznaczać granicę zadania. Instytucja publiczna może stwierdzić, że system może sugerować trasę, ale nie może podejmować ostatecznej decyzji. Może określić, że rekomendacja nie może być użyta, gdy określone źródło jest nieobecne lub sprzeczne. Może wymagać ścieżki dla człowieka dla osoby, której dotyczy decyzja i która chce ją zakwestionować. To nie są wrogie ograniczenia. To warunki, w których zakup pozostaje usługą publiczną, a nie prywatnym procesem z logo rządowym.

Wąskie sformułowanie problemu to nie brak ambicji. To sposób na to, by ambicję można było rozliczyć. Jeśli instytucja nie potrafi wyjaśnić, który krok zmienia system, kto na tym korzysta, co może pójść źle i co dana osoba może zrobić dalej, nie jest gotowa do porównywania dostawców. Właściwym działaniem może być dalsze rozpoznanie, rozwiązanie bez sztucznej inteligencji, mały kontrolowany pilotaż albo rezygnacja z zakupu. Dokumentacja postępowania powinna zostawić miejsce na każdą z tych odpowiedzi.

Zamień wymagania w dowody

Słowo „dowód” jest używane w zamówieniach na technologie dość swobodnie. Prezentacja dostawcy, pokaz produktu i stwierdzenie, że system jest godny zaufania, mogą być użytecznymi materiałami. Żadne z nich nie jest automatycznie dowodem spełnienia wymagania. Dowód musi być powiązany z twierdzeniem, testem, zakresem i osobą, która może go zbadać. Bez tego powiązania ocena staje się konkursem, w którym wygrywa najbardziej dopracowane zdanie.

Dyrektywa w sprawie zamówień jest jasna co do podstawowej zależności: kryteriom udzielenia zamówienia muszą towarzyszyć ustalenia umożliwiające skuteczną weryfikację informacji dostarczonych przez wykonawców. Zasada ta jest szczególnie ważna w przypadku sztucznej inteligencji, ponieważ wynik może wyglądać przekonująco, podczas gdy warunki, które go wygenerowały, pozostają ukryte. Zamawiający powinien zapytać, co zostanie pokazane, w jakich warunkach dotyczących danych i zadania, względem jakiej linii bazowej oraz w jaki sposób recenzent może odtworzyć lub zakwestionować wynik.

Holenderski Algoritmekader stawia ten sam wymóg w praktycznym języku. Jego środki dotyczące zamówień publicznych obejmują włączenie wymagań dotyczących algorytmów do dokumentacji zamówienia i umowy, zobowiązanie dostawców do przedstawienia dowodów spełnienia wymagań w ramach oceny, ocenę warunków odpowiedzialności dostawcy, wymóg możliwości audytu w umowie, uzgodnienie, co dzieje się z danymi i artefaktami, oraz prośbę o plan wyłączenia algorytmu. Ta lista to wytyczne, a nie uniwersalna prawna lista kontrolna. Jej wartość polega na tym, że traktuje dowód jako przedmiot zamówienia.

Zamawiający może podzielić dowody na trzy użyteczne kategorie. Dowody wykazane to to, co dostawca pokazuje w kontrolowanej ocenie: można zaobserwować dane wejściowe, wynik, obsługę błędów, wykorzystanie źródeł i ścieżkę dla człowieka. Dowody możliwe do zbadania to to, co instytucja może sprawdzić bez polegania na pokazie: dokumentacja, wyniki testów, logi, interfejsy, rejestry zmian, opisy danych i możliwość przeprowadzenia uzgodnionej kontroli. Dowody umowne to to, co dostawca musi nadal zapewniać: powiadomienia o istotnych zmianach, informacje o incydentach, dostęp do audytu, rejestry usług, możliwości eksportu i wsparcie kontrolowanego wyjścia. Te kategorie się nakładają, ale zapobiegają temu, by jedno imponujące spotkanie ciągnęło całą umowę.

Dowody potrzebują także zakresu. Dostawca może wykazać, że system dobrze radzi sobie na zbiorze przykładów. Zamawiający nadal musi wiedzieć, czy przykłady odzwierciedlają docelowy język, jakość dokumentów, strukturę spraw, potrzeby dostępnościowe i ograniczenia operacyjne. Twierdzenie o modelu w laboratorium nie jest automatycznie twierdzeniem o usłudze publicznej. Jest twierdzeniem o przeprowadzonym eksperymencie. Zespół zamawiający powinien zachować zadanie, warunki danych, wersję i wynik, aby późniejsza decyzja nie oderwała się od testu.

Wyobraźmy sobie hipotetyczną sytuację, w której wykonawca dostarcza przykładowy zestaw wygenerowanych streszczeń oraz ogólne oświadczenie o dokładności. Zamawiający może poprosić o dokumenty źródłowe, zasadę doboru, używaną wersję, sposób traktowania brakujących materiałów, procedurę przeglądu oraz artefakt, który pozostanie po odbiorze. Jeśli odpowiedź brzmi, że szczegóły są zastrzeżone i nie mogą być sprawdzone, zespół dowiaduje się czegoś ważnego. Nie dowiaduje się, że system jest zły. Dowiaduje się, że proponowany zakres dowodów może być zbyt słaby dla celu publicznego.

Dowody powinny być proporcjonalne. Małe wewnętrzne narzędzie wspomagające pisanie nie wymaga takiego samego pakietu kontroli jak system wpływający na dostęp do usługi publicznej. Proporcjonalność nie oznacza akceptowania sloganu przy niskim ryzyku. Oznacza dopasowanie głębokości dowodów do konsekwencji, odwracalności, liczby osób dotkniętych oraz możliwości wykrycia i naprawienia błędu. Dostawca powinien znać wymagane dowody przed złożeniem oferty. W przeciwnym razie zamawiający zmienia zasady konkursu po jego zakończeniu, co jest znanym sposobem na kosztowną niespodziankę.

Wymaganie powinno prowadzić do dowodów, a dowody powinny móc zmienić decyzję o przyznaniu zamówienia.

Zamawiający musi mieć możliwość wyrażenia sprzeciwu

Odpowiedzialność publiczna to nie to samo co przejrzystość dostawcy. Dostawca może wyjaśnić działanie swojej usługi, podczas gdy zamawiający nadal nie ma drogi, którą mieszkaniec, pracownik, przedsiębiorca lub specjalista mógłby zakwestionować sposób wykorzystania usługi. Dokumentacja zamówienia powinna zatem pytać o to, jak działa sprzeciw, a nie tylko o to, jak system generuje odpowiedź.

Algoritmekader umieszcza kontrolę człowieka, prawa podstawowe, przejrzystość i ścieżki składania skarg wśród swoich tematów dotyczących sektora publicznego. Zalecane środki obejmują znaczącą interwencję człowieka w podejmowaniu decyzji, proces, w ramach którego obywatele lub inne zainteresowane strony mogą złożyć skargę, sprzeciw lub odwołanie, publiczną decyzję o stosowaniu algorytmu oraz sposób publikowania algorytmów mających wpływ na społeczeństwo w holenderskim rejestrze algorytmów. Środki te nie zamieniają każdego algorytmu w publiczne widowisko. Sprawiają, że odpowiedzialność zamawiającego jest na tyle widoczna, że można ją zakwestionować.

Wymóg dotyczący nadzoru człowieka w zamówieniu powinien określać konkretne działanie człowieka. Czy osoba dokonująca przeglądu może zobaczyć informacje, które wpłynęły na rekomendację. Czy może poprawić zapis. Czy może odrzucić wynik bez uprzedniego uzyskania zgody systemu. Czy może poprosić o alternatywną ścieżkę, gdy brakuje źródła. Czy może zatrzymać partię, wyizolować wersję lub zgłosić problem osobie z odpowiednimi uprawnieniami. Jeśli odpowiedź sprowadza się tylko do tego, że w procesie uczestniczy jakaś osoba, to wymóg opisuje mebel, a nie nadzór.

Na niezgodę trzeba też mieć czas. Osoba, która ma sprawdzać każde wyjście, zachowując dotychczasowy zakres obowiązków, może być formalnie w pętli nadzoru, a praktycznie poza nią. Zamówienie może wymagać szkoleń, wsparcia, użytecznych dowodów i założenia dotyczącego obciążenia pracą przy przeglądzie. Może określać, które przypadki wymagają zgody przed działaniem, a które odwracalne działania o niskich konsekwencjach mogą przebiegać z rejestrowaniem i późniejszą kontrolą próbek. Może wymagać od dostawcy wsparcia tej ścieżki, a nie ukrywania jej za interfejsem programowania aplikacji.

Organ zamawiający musi też umieć sprzeciwić się własnemu entuzjazmowi. Udany pilotaż może stworzyć presję na rozszerzenie narzędzia na populację lub decyzję, które nigdy nie były częścią testu. Umowa powinna zachowywać pierwotny cel i wymagać nowej decyzji, gdy zmienia się cel, dane, osoby, których dotyczy, lub konsekwencje. Aktualizacja nie jest automatycznie nieszkodliwa tylko dlatego, że jest dostarczana jako usługa. Nowe zastosowanie nie jest automatycznie objęte umową tylko dlatego, że na górze ekranu widnieje to samo logo.

Gdy dostawca twierdzi, że model ma charakter wyłącznie doradczy, organ zamawiający powinien przyjrzeć się temu, co praca faktycznie robi. Jeśli pracownicy mają polecenie akceptowania rankingu, jeśli nie ma czasu na jego przegląd lub jeśli system decyduje, które przypadki trafiają do człowieka, porada może w praktyce stać się decyzją. Zespół zamawiający nie musi spierać się o idealną etykietę. Musi udokumentować ścieżkę od wyniku do konsekwencji i zachować prawo do zmiany tej ścieżki.

Granice dostawcy są częścią umowy

Zamawianie AI często opisuje się jako wybór między budowaniem a kupowaniem. Trudniejszy wybór dotyczy podziału granicy między dostawcą a organizacją publiczną. Dostawca może kontrolować model, usługę, ścieżkę aktualizacji, infrastrukturę, zespół wsparcia i część przetwarzania danych. Organ zamawiający kontroluje cel publiczny, decyzję, populację, której dotyczy, oraz obowiązek świadczenia zgodnej z prawem i użytecznej usługi. Umowa musi łączyć te obowiązki, a nie pozostawiać ich jako dwóch grzecznych schematów.

Zaktualizowane unijne wzorcowe klauzule umowne dotyczące AI są przydatne, ponieważ uznają, że publiczni nabywcy potrzebują odrębnych podejść do AI wysokiego ryzyka i AI niewysokiego ryzyka oraz wskazówek dotyczących dostosowywania klauzul w praktyce. Nie zastępują one strategii zamówień ani przeglądu prawnego. Stanowią wspólny język dla uczynienia obowiązków jednoznacznymi. Nabywca nadal musi zdecydować, które dowody, prawa do danych, dostęp audytowy, powiadomienia o zmianach, wsparcie, odpowiedzialność i warunki wyjścia są proporcjonalne do kupowanego systemu.

Dane i artefakty zasługują na szczególną uwagę. System może dotykać dokumentów źródłowych, etykiet, promptów, osadzeń, wygenerowanych szkiców, poprawek ludzkich, zestawów ewaluacyjnych, logów i końcowych zapisów. Umowa powinna rozróżniać, co dostarcza organ zamawiający, co tworzy dostawca, do czego każda strona może używać, co musi zostać zwrócone, co musi zostać usunięte i jaki dowód usunięcia lub przechowywania jest wymagany. Stwierdzenie, że organ zamawiający jest właścicielem swoich danych, nie odpowiada na pytanie, gdzie znajdują się pochodne artefakty ani w jaki sposób organ może odzyskać zapisy wyjaśniające wynik.

Audit rights need a practical shape. The buyer should know which records can be inspected, how access is requested, what notice is reasonable, which confidentiality protections apply and what happens when an audit finds a gap. An audit clause without a usable route is a sentence waiting for a dispute. The same is true of an incident clause that says the supplier will cooperate without naming the information, timing and owner needed for cooperation.

Change control should not be left to release notes. The authority can require notice of a material change to the model, data sources, processing location, subcontractors, interfaces, thresholds, evaluation method or human route. It can define what evidence is needed before a changed version is used for the public task. It can require a right to pause, reject or revert where the changed service no longer meets a material requirement. These are recommendations to make the contract operable. They are not claims that one clause can resolve every supplier relationship.

Responsibility also includes what the supplier cannot provide. A service may depend on a third-party model or infrastructure whose changes are outside the immediate supplier’s control. The buyer should be told that dependency and should know which obligations flow through to it. A public organisation cannot assess a chain by inspecting only the front door. The contract should preserve a route to the relevant evidence, or the buyer should recognise that the uncertainty is a reason to narrow or decline the purchase.

Good boundaries protect suppliers too. A public buyer that asks for every possible document, every source code detail and unlimited support without a defined purpose may reduce competition and make the contract unattractive to smaller European providers. Proportionality, clarity and a credible evidence scope let a supplier say what it can do and let a buyer say what it needs. Public procurement should be demanding without being theatrical. A wall made of impossible requirements keeps out bad systems and good ones with equal efficiency.

Change after award is still procurement

The award is not the end of the decision. It is the point at which the service enters a different kind of scrutiny. During operation, data shifts, policies change, interfaces are replaced, staff learn shortcuts, suppliers revise models and a system may be used in situations the original team did not imagine. The authority needs a way to notice these changes before they become a new public purpose by accident.

The Algoritmekader recommends regular checks that an algorithm works as intended, monitoring changes in data and evaluating performance and output when data changes, and maintaining a plan for continuous monitoring. It also includes a measure for an emergency plan to stop the algorithm. These recommendations put time inside the governance model. A procurement that captures only the initial specification has bought a photograph of a moving service.

Not every update should trigger the same ceremony. A security patch that leaves the model, data boundary and decision role unchanged may follow a different path from a new model family, a changed retrieval source or a new threshold. The contract can define materiality in operational terms: a change is material when it alters the task, affected people, evidence path, decision consequence, deployment jurisdiction, subcontractor, data use or ability to intervene. The exact definition needs legal and technical judgement. The principle is simple: change is part of the purchased capability.

Monitoring powinien zachowywać informacje potrzebne do podjęcia decyzji. Pulpit nawigacyjny może pokazywać, że usługa jest obciążona; może nie pokazywać, że źródło stało się nieaktualne albo że recenzenci odrzucają to samo zalecenie. Instytucja powinna zachowywać odpowiednią wersję, zakres zadania, warunki dotyczące dowodów, działania człowieka oraz powód zmiany. Powinna wiedzieć, które zmiany zostały zaakceptowane, które wycofano, które ograniczono, a które stworzyły nowe pytanie w postępowaniu o udzielenie zamówienia.

Dostawca może nie być w stanie z wyprzedzeniem zgłosić każdej wewnętrznej zmiany. Umowa może mimo to wymagać użytecznego powiadomienia i pakietu dowodów, zanim zmienione zachowanie zostanie uznane za wiarygodne. Instytucja może wybrać wdrożenie etapowe, kontrolowaną ocenę lub czasowe wstrzymanie. Możliwość wstrzymania nie jest karą. To ona pozwala usłudze publicznej pozostać rozliczalną, dopóki fakty nie zostaną ustalone.

Rejestr zmian chroni również przed fałszywą pewnością. Jeśli instytucja nie potrafi ustalić, czy różnica wynikała z nowego modelu, zmiany danych, promptu, obejścia zastosowanego przez człowieka czy zależności zewnętrznej, nie powinna twierdzić, że system działał spójnie. Właściwą reakcją może być ograniczenie zakresu użycia, zebranie lepszych dowodów lub zatrzymanie danego kanału. Pieniądze publiczne nie stają się bezpieczniejsze dlatego, że wyjaśnienie jest uporządkowane.

Interoperacyjność to grzeczne słowo na odejście

O interoperacyjności mówi się często tak, jakby była techniczną uprzejmością między systemami. W zamówieniach publicznych jest ona również mechanizmem ciągłości. Jeśli usługa publiczna nie może przenieść swoich rejestrów, konfiguracji, dowodów, interfejsów i wiedzy operacyjnej na inną drogę, instytucja może być prawnie wolna do odejścia, ale praktycznie niezdolna do tego. Umowa stworzyła zależność, której nie nazwano w dokumentacji postępowania.

Raport JRC Komisji na temat przyspieszenia wdrażania sztucznej inteligencji w administracjach publicznych UE określa zamówienia jako kluczową rolę umożliwiającą i stwierdza, że interoperacyjność powinna być wbudowana od samego początku. Przedstawia również zamówienia strategiczne jako sposób na zmniejszenie zależności od dostawców spoza UE oraz wsparcie europejskich startupów AI, rozwiązań open-source i GovTech. Nie jest to argument za kupowaniem po europejsku z hasła ani za traktowaniem open source jako automatycznej gwarancji. To argument za tym, aby techniczna i instytucjonalna zdolność do zmiany kursu stała się częścią kupowanej wartości.

Odejście zaczyna się od listy tego, co musi przetrwać. Może ona obejmować rekordy źródłowe, identyfikatory, etykiety, prompty, wersje modeli i konfiguracji, zestawy ewaluacyjne, rejestry audytu, mapowania użytkowników i ról, kontrakty integracyjne, status retencji, materiały związane z bezpieczeństwem oraz znaczenie pól. Lista zależy od usługi. Przenośny plik bez kontekstu może być mniej użyteczny niż mniejszy rekord z zachowaną semantyką i uprawnieniami. Eksport to możliwość, którą należy przetestować, a nie pole do odhaczenia.

Interoperacyjność oznacza również, że instytucja może przeprowadzić sensowne porównanie. Czy miejsce docelowe może przetwarzać rekordy bez cichej zmiany ich znaczenia. Czy recenzenci mogą porównać stary i nowy wynik w tych samych warunkach zadania. Czy usługa publiczna może działać w trybie ograniczonym, jeśli jedna z zależności jest niedostępna. Czy dowody pozostaną czytelne po zniknięciu interfejsu. Te pytania należą do wymagań, ewaluacji i umowy, ponieważ odejście odkryte w trakcie sytuacji awaryjnej to zwykle wykopaliska archeologiczne.

Przenośność nie musi oznaczać, że dostawca przekazuje każdy szczegół wewnętrznej implementacji. Oznacza natomiast, że instytucja może zachować funkcję publiczną oraz dokumentację, za którą odpowiada, z zastrzeżeniem prawem przewidzianych uprawnień i ograniczeń bezpieczeństwa. Granica tych obowiązków powinna być określona przed podpisaniem umowy. Jeśli model dostawcy jest niedostępny, instytucja może nadal wymagać przenośnych danych wejściowych, wyników, rejestrów decyzji, ocen, konfiguracji oraz ścieżki umożliwiającej odtworzenie publicznych zobowiązań usługi. Jeśli nie może uzyskać takiej ścieżki, powinna uczciwie wycenić to uzależnienie albo z niego zrezygnować.

Próba wyjścia z systemu jest cenna, bo zamienia obietnicę umowną w zaobserwowaną zdolność. Publiczny nabywca może przetestować eksport, sprawdzić pola, uruchomić reprezentatywne obciążenie w kontrolowanym środowisku docelowym i porównać powstałe rejestry. Może odnotować, co się nie przeniosło, i ocenić, czy ta luka jest do zaakceptowania. Ćwiczenie nie musi być spektakularne. Niewielka próba przeprowadzona przed odnowieniem umowy jest lepsza niż heroiczna migracja wykonana po tym, jak dostawca stał się jedyną osobą, która pamięta, jak działa system.

Wyjście to sekwencja: uprawnienie, eksport, znaczenie, weryfikacja, ciągłość i zamknięcie. Przycisk z napisem eksport nie jest tą sekwencją.

Koszt to coś więcej niż pozycja w ofercie

Cenę łatwo porównać, gdy przedmiot zakupu jest stabilny. Zakupy rozwiązań AI mają dłuższy horyzont kosztowy. Mogą obejmować prace integracyjne, przygotowanie danych, czas na przegląd, kontrolę bezpieczeństwa, przechowywanie, ocenę, aktualizacje modeli, prace nad dostępnością, reagowanie na incydenty, wsparcie, eksport i wymianę. Część kosztów ponosi instytucja. Inne są przenoszone na pracowników lub na społeczeństwo, gdy usługa staje się trudniejsza do zakwestionowania. Zakup, który porównuje wyłącznie opłatę początkową, niekoniecznie jest ekonomiczny. Po prostu liczy jeden widoczny element.

Dyrektywa 2014/24/UE przewiduje kalkulację kosztów w cyklu życia, gdy instytucja wybierze takie podejście. Dyrektywa opisuje koszty takie jak nabycie, użytkowanie, utrzymanie, wycofanie z eksploatacji oraz, w stosownych i weryfikowalnych przypadkach, koszty zewnętrzne dla środowiska. Wymaga też, aby dokumenty zamówienia określały dane, które mają przekazać oferenci, oraz metodę oceny kosztu cyklu życia. To użyteczna dyscyplina w przypadku AI, ponieważ wymaga od nabywcy określenia, co będzie liczone, zamiast pozwalać każdemu dostawcy na własną definicję taniości.

Ta sama zasada dotyczy ludzkiej uwagi. Jeśli system generuje rekomendacje wymagające przeglądu, praca nad ich przeglądem należy do modelu operacyjnego. Jeśli usługa publiczna potrzebuje ścieżki korekty, ścieżka ta musi mieć właściciela i czas. Jeśli aktualizacja dostawcy wymaga nowej oceny, organ musi mieć zdolność do jej przeprowadzenia. To nie są argumenty przeciwko automatyzacji. To przypomnienia, że automatyzacja zmienia miejsce, w którym wykonywana jest praca. Oszczędność na fakturze może być kosztem w kolejce, jeśli zamówienie nie określa nowej pracy.

Koszt powinien również obejmować koszt niemożności odejścia. Zależność może wydawać się niedroga, gdy jest nowa, a stać się kosztowna, gdy wokół niej zgromadzą się dokumentacja, wiedza specjalistyczna, integracje i oczekiwania społeczne. Kupujący może poprosić o szacunkowy koszt migracji, inwentaryzację danych i artefaktów, zobowiązanie do wsparcia oraz harmonogram prób. Może porównać te warunki jako część wartości oferty. Wybór nie polega na optymizmie lub pesymizmie. Polega na zależności, która jest widoczna, i takiej, która jest ukryta w czasie przyszłym.

Myślenie o cyklu życia pomaga zespołowi ds. zamówień powiedzieć „nie” bez udawania, że najtańsza widoczna oferta jest opcją neutralną. Zespół może odrzucić propozycję, ponieważ jej dowody, obciążenie przeglądem, ścieżka zmian lub koszt wyjścia nie są zgodne z celem publicznym. Może wyjaśnić decyzję na podstawie opublikowanych kryteriów. To nie jest gest przeciwko rynkowi. To właśnie to, co rynek z weryfikowalnymi wymaganiami powinien umożliwiać.

Publiczni nabywcy potrzebują uprawnień do odmowy

Zespół ds. zamówień nie może korzystać z uprawnień, których organizacja mu nie przyznała. Wiele organów ma osoby, które potrafią oceniać kwestie prawne, techniczne, finansowe i usługowe, ale uprawnienia do połączenia tych ocen w wstrzymanie lub odmowę są niejasne. Skutek jest znany: obawy są odnotowywane w jednym dokumencie, entuzjazm w innym, a przyznanie zamówienia następuje, ponieważ nikt nie wie, która rola może zamknąć bramę.

Organ powinien określić role, które mogą zaakceptować, odrzucić, zawęzić lub wstrzymać zakup na każdym etapie. Role te potrzebują dostępu do odpowiednich dowodów i możliwości odnotowania powodu. Urzędnik ds. zamówień może zarządzać procesem, właściciel usługi celem publicznym, inspektor ochrony danych warunkiem prywatności, lider ds. bezpieczeństwa kontrolą, recenzent techniczny testem, a osoba na stanowisku kierowniczym odpowiedzialnym za całość podejmuje ostateczną decyzję. Dokładne ustalenia mogą się różnić. Brak ustaleń jest niebezpieczną częścią.

Przydatny warunek zatrzymania to nie czerwona odznaka z napisem „wysokie ryzyko”. To fakt, który blokuje kolejną decyzję. Zamierzony cel nie jest wystarczająco zdefiniowany. Dostawca nie może przedstawić dowodów na istotne wymaganie. Osoba, której dotyczy sprawa, nie ma użytecznej ścieżki odwoławczej. Organ nie może sprawdzić istotnej zmiany. Prawa do danych lub artefaktów są niejasne. System nie może zostać wyeksportowany ani zastąpiony w ramach planu ciągłości działania. Osoba dokonująca przeglądu ma odpowiedzialność, ale nie ma uprawnień. Każdy warunek może mieć inne rozwiązanie. Niektóre wymagają wyjaśnienia, niektóre zmiany umowy, niektóre zawężenia zakresu, a niektóre odmowy.

Warunki zatrzymania powinny być znane przed oceną ofert. Powinny być powiązane z kryteriami przyznania zamówienia i z umową, aby kupujący nie wymyślał nowego standardu po zobaczeniu odpowiedzi dostawcy. Należy je również ponownie rozważyć po przyznaniu zamówienia. Wymóg spełniony na starcie może przestać być spełniony po istotnej zmianie lub nowym zastosowaniu. Zdolność do odmowy to nie pojedyncza brama na końcu. To utrzymywane uprawnienie przez cały okres świadczenia usługi.

Rozważmy hipotetyczny zespół publiczny zamawiający usługę routingu dokumentów. Jego opublikowane wymagania obejmują identyfikowalność źródła, ścieżkę przeglądu przez człowieka, powiadomienie o istotnych zmianach modelu, eksport rejestrów oraz zdefiniowaną procedurę zatrzymania. Jeden oferent przedstawia mocną demonstrację, ale nie pozwala instytucji na wgląd w wybór źródła ani na zachowanie wersjonowanych dowodów routingu. Inny oferent oferuje mniej funkcji, ale spełnia wymagania dotyczące dowodów i wyjścia. Zespół nie ma obowiązku preferowania głośniejszej demonstracji. Może zastosować określone kryteria, zadać proporcjonalne pytania i odrzucić pierwszą ofertę, jeśli istotne wymaganie pozostanie nieudowodnione.

Ta decyzja nie powinna być formułowana jako ocena moralna dostawcy lub technologii. Powinna określać cel publiczny, wymaganie, otrzymane dowody, nierozwiązany warunek oraz decyzję dopuszczoną przez dokumenty zamówienia. Jasne „nie” jest bardziej szanujące niż niejasne „może”, które później przeradza się w obowiązkowe przedłużenie. Daje też rynkowi użyteczny sygnał: publiczni nabywcy zapłacą za dowody i kontrolę, a nie tylko za teatr możliwości.

Ludzka władza zatrzymania musi być użyteczna w incydencie. Operator powinien wiedzieć, kogo wezwać, jaki stan systemu zachować, która trasa usługi może działać dalej i jaka komunikacja jest wymagana. Rejestr decyzji powinien odróżniać natychmiastowe powstrzymanie szkody od dłuższej decyzji zakupowej. Organ publiczny nie musi czekać na doskonałe dochodzenie, zanim zapobiegnie dalszej szkodzie, ale powinien unikać twierdzenia o większej pewności, niż posiada. Zatrzymanie jest kontrolą. Wyjaśnienie może się rozwijać.

Zamówienia publiczne kształtują rynek

Zamówienia publiczne to jeden ze sposobów, w jaki Europa decyduje, które możliwości warto budować. Raport JRC na temat przyspieszania adopcji AI w administracjach publicznych UE opisuje sektor publiczny jako główną siłę kształtującą rynek. Łączy on udaną adopcję z zarządzaniem, gotowością kadr, odpowiedzialnymi zamówieniami, interoperacyjnością i zaufaniem publicznym. Stwierdza również, że strategiczne zamówienia mogą zmniejszyć zależność od dostawców spoza UE oraz wspierać europejskie startupy, rozwiązania open-source i GovTech. Nie chodzi o to, by organ publiczny stał się funduszem venture capital. Chodzi o to, że jego wymagania mogą albo nagradzać odpowiedzialne możliwości, albo nagradzać przekonujące opakowanie wokół zależności.

Sprawozdanie specjalne Europejskiego Trybunału Obrachunkowego nr 28/2023 nosi tytuł „Public procurement in the EU: less competition for contracts awarded for works, goods and services in the ten years up to 2021”. Jego publiczne streszczenie opisuje konkurencję w europejskich przetargach publicznych jako malejącą. Rynek z mniejszą liczbą skutecznych konkurentów to złe miejsce do ukrywania niejasnych wymagań. Jeśli instytucja nie może porównać dowodów, może wybierać między stylami marketingowymi, a nie między usługami. Odrzucenie niemożliwej do przetestowania oferty może zachować warunki do lepszej konkurencji w przyszłości.

Jednocześnie nabywca może przypadkowo wykluczyć użytecznych dostawców, żądając dowodów w formie, którą może przedstawić tylko największy dostawca. Proporcjonalne wymagania, jasne interfejsy, otwarte formaty i etapowe oceny mogą pozwolić mniejszym organizacjom na wykazanie ograniczonej możliwości bez udawania, że mają zasoby międzynarodowej korporacji. Nabywca powinien być rygorystyczny co do celu publicznego i elastyczny co do wdrożenia, jeśli wdrożenie nie wpływa na ten cel. W ten sposób „nie” staje się lepszym pytaniem, a nie zamkniętymi drzwiami.

Kształtowanie rynku oznacza również odmowę uczynienia prywatnej architektury jednego dostawcy definicją potrzeby publicznej. Jeśli wymaganie wskazuje konkretny model, chmurę lub zastrzeżony przepływ pracy bez uzasadnionego związku z zadaniem, konkurencja może zostać zawężona, zanim zobaczy się dowody. Wymagania funkcjonalne i weryfikowalne wyniki dają publicznym nabywcom więcej miejsca na porównanie podejść. Sprawiają też, że umowa jest mniej krucha, gdy wybrany komponent się zmienia.

Organ publiczny może być wymagającym klientem, nie stając się klientem trudnym. Może publikować dowody, których oczekuje, wyjaśniać powód warunku zatrzymania, oferować drogę do wyjaśnień i płacić za pracę, która tworzy trwałą zdolność publiczną. Rynek ma wtedy na co odpowiedzieć. Nie musi zgadywać, czy czynnikiem decydującym była ukryta preferencja, piękna prezentacja czy cena przyszłego problemu.

Wzorzec działania dla zamówienia, które może odmówić

Poniższy wzorzec to praktyczne zalecenie, a nie nowa procedura prawna. To sposób na utrzymanie widoczności decyzji publicznej, gdy system przechodzi od pomysłu do działania. Organ powinien dostosować go do swojego prawa, sektora, ryzyka i metody zamówień. Najważniejsze jest to, aby każda brama miała właściciela, dowody i dozwolony wynik obejmujący wstrzymanie lub odmowę.

Po pierwsze, opisz cel publiczny. Nazwij usługę, osoby ją wykonujące, osoby ją otrzymujące, decyzję lub działanie, które może się zmienić, oraz powód, dla którego rozważa się system. Określ, co pozostaje poza zakresem. Jeśli celu nie da się opisać bez słownictwa produktowego dostawcy, organ wciąż prowadzi rozpoznanie rynku. Wynikiem tej bramy jest opis problemu i decyzja, czy zamówienie jest właściwym kolejnym krokiem.

Po drugie, opisz granicę dowodów. Dla każdego istotnego twierdzenia określ, co świadczyłoby o jego prawdziwości w zamierzonym zadaniu. Nazwij warunki dotyczące danych, język, potrzeby dostępności, źródłowe rejestry, wersję, punkt odniesienia i ścieżkę przeglądu, które czynią test miarodajnym. Określ, co musi być możliwe do sprawdzenia, co może pozostać poufne, a co musi zostać dostarczone jako zapis umowny. Wynikiem tej bramy jest zestaw wymagań zrozumiałych dla oferentów oraz plan oceny, który może zmienić przyznanie zamówienia.

Po trzecie, opisz granicę uprawnień organu. Nazwij działania, które system może sugerować, działania, które może podejmować, działania wymagające zatwierdzenia oraz działania zabronione. Nazwij, kto może poprawić źródło, odrzucić wynik, zmienić regułę, wstrzymać usługę i porozmawiać z osobą, której sprawa dotyczy. Zdefiniuj, co się dzieje, gdy system jest niepewny lub dowody są sprzeczne. Wynikiem tej bramy jest ścieżka ludzka bardziej konkretna niż pole wyboru.

Po czwarte, opisz granicę zmian. Zidentyfikuj zmiany wymagające powiadomienia, oceny, zatwierdzenia lub nowej decyzji o zamówieniu. Uwzględnij model, dane, dostawcę, podwykonawcę, infrastrukturę, lokalizację przetwarzania, interfejs, próg, populację, cel i ścieżkę ludzką. Zdecyduj, które dowody pozostają w rejestrze zmian, a które mogą zostać zanonimizowane z uzasadnionych powodów. Wynikiem tej bramy jest prowadzony rejestr, a nie obietnica, że system pozostanie niezmienny.

Po piąte, opisz granicę wyjścia. Wymień rejestry, dane, konfigurację, dowody, uprawnienia, integracje i wiedzę operacyjną, które muszą przetrwać. Określ formaty, terminy, wsparcie, weryfikację, ograniczoną usługę, przełączenie, zamknięcie dostępu i usunięcie. Przećwicz mały eksport przed odnowieniem lub istotnym rozszerzeniem. Wynikiem tej bramy jest ścieżka, którą można przetestować, gdy dostawca jest jeszcze partnerem, a nie dopiero wtedy, gdy relacja stała się sporem.

Po szóste, opisz rejestr publiczny. Zdecyduj, co można opublikować na temat celu, roli systemu, dowodów, ścieżki ludzkiej, zmian, incydentów i kontaktu do zakwestionowania decyzji. Chroń informacje poufne i osobowe, nie zamieniając całej decyzji w prywatną rozmowę. Rejestr publiczny może mówić, co jest znane, co nie jest znane i kiedy odbędzie się kolejny przegląd. Jego zadaniem nie jest sprawianie, by system wyglądał na doskonały. Ma uczynić ocenę organu możliwą do sprawdzenia.

Na koniec należy sformułować odmowę. Odmowa nie jest dramatycznym komunikatem prasowym. To normalny wynik w rejestrze decyzji: wymóg był istotny, dowody go nie spełniły, rozważono środek zaradczy, a organ zdecydował się odmówić, zawęzić, wstrzymać lub poszukać innej drogi. Postępowanie, które nie może przedstawić takiego rejestru, sprawia, że zakup wygląda na nieunikniony, zanim na to zasłuży.

Te bramy można ująć w odpowiedzi na zapytanie ofertowe, architekturze startowej projektu, harmonogramie umowy, spotkaniu przeglądowym i scenariuszu incydentu. Nie powinny stać się większym formularzem dla samego siebie. Jeśli brama nie zmienia tego, co zespół może zdecydować, to prawdopodobnie teatr dokumentacyjny. Jeśli daje człowiekowi dowody i uprawnienia do działania, jest częścią usługi.

Pytania, które warto umieścić w zapytaniu ofertowym

Najlepsze pytania to nie te, które skłaniają dostawcę do powtarzania języka marketingowego. To te, które uwidaczniają cel publiczny i granicę dowodów. Zamawiający może dostosować poniższe pytania do systemu i procedury:

  • Jakie dokładnie zadanie publiczne wspiera proponowana funkcjonalność, a które zadania są poza jej zamierzonym zastosowaniem?
  • Które osoby, rejestry i źródła danych są objęte zakresem, a które muszą być wyłączone?
  • Jaki wynik generuje system i jaka decyzja lub działanie może z niego wynikać?
  • Który wymóg można wykazać, który można sprawdzić, a który będzie utrzymywany umownie?
  • W jaki sposób organ odtworzy wynik przy odpowiedniej wersji, źródłach, konfiguracji i warunkach zadania?
  • Co może zobaczyć, zmienić, odrzucić, eskalować lub zatrzymać człowiek dokonujący przeglądu, zanim nastąpi działanie o istotnych skutkach?
  • Które zmiany modelu, danych, infrastruktury, podwykonawcy lub polityki wymagają powiadomienia i ponownej oceny?
  • Które rejestry i artefakty może wyeksportować organ, w jakich formatach, z jakim znaczeniem, prawami i statusem przechowywania?
  • Co się dzieje, gdy usługa jest niedostępna, dowody są niekompletne lub ktoś kwestionuje wynik?
  • Które obowiązki wsparcia, audytu, incydentu, szkolenia i wyjścia obowiązują po pierwszym wydaniu?

Te pytania nie zastępują dyrektywy o zamówieniach publicznych, aktu o sztucznej inteligencji, przepisów o ochronie danych ani przepisów sektorowych. To podpowiedzi, które mają pomóc organowi wdrożyć własne obowiązki. Dostawca, który potrafi jasno na nie odpowiedzieć, wciąż może nie być właściwym dostawcą. Dostawca, który nie potrafi na nie odpowiedzieć, może nadal mieć użyteczny komponent, ale organ nie powinien mylić użytecznego komponentu z kompletną zdolnością publiczną.

Nasza krótka uwaga

W Dweve nasz AI Compas obejmuje neutralny wobec dostawców szlak zamówień i zarządzania dla regulowanych organizacji europejskich. Materiały RFI i RFP proszą zespoły o sklasyfikowanie przypadku użycia, zastosowanie kryteriów eliminacyjnych, porównanie dostawców, przeprowadzenie proof-of-concept i gromadzenie dowodów przez cały okres monitorowania. To nasz kontekst wdrożeniowy, a nie niezależny dowód dotyczący zamówień publicznych ani twierdzenie, że jedna struktura pasuje do każdego organu. Wspominamy o tym, ponieważ dyscyplina opisana tutaj to także dyscyplina, którą staramy się stosować we własnej pracy: określ granicę, wymagaj dowodów, pozostaw decyzję człowiekowi i uczynij wyjście widocznym.

Nasze Trust Centre stosuje to samo rozróżnienie w innym rejestrze. Rejestr publiczny może opisywać, co jest udokumentowane, co jest przygotowane, a co pozostaje przyszłym wydarzeniem, bez zamieniania deklaracji intencji w dowód. Zespół zamówień publicznych zasługuje na taką samą uczciwość ze strony swoich dostawców. Zamawiający powinien widzieć status twierdzenia, dowody za nim stojące i drogę do jego zakwestionowania.

Lekcja

Organ publiczny nie staje się odpowiedzialny, gdy podpisze umowę na system AI. Staje się odpowiedzialny, gdy postępowanie zakupowe potrafi wyjaśnić, dlaczego system należy do tej pracy, jakie dowody wspierają to stanowisko, kto może interweniować, co się dzieje, gdy system się zmienia, oraz jak funkcja publiczna może działać dalej, jeśli dostawca nie jest w stanie jej świadczyć.

Europejskie przepisy o zamówieniach publicznych już zapewniają ważne nawyki: kryteria powinny być powiązane z przedmiotem zamówienia, informacje powinny być weryfikowalne, wagi powinny być określone, a warunki umowy jasne. Klauzule dotyczące zamówień na systemy AI opracowane przez Komisję Europejską dają instytucjom publicznym sposób na omówienie systemów wysokiego i niewysokiego ryzyka oraz na podział obowiązków. Holenderski Algoritmekader zamienia odpowiedzialne zakupy w praktyczne środki dotyczące celu, danych, dowodów, audytu, kontroli ludzkiej, zatrzymania i wyjścia. Raport JRC umieszcza zamówienia w kontekście europejskiej dyskusji o zdolnościach i suwerenności. Ostrzeżenie ECA o kurczącej się konkurencji przypomina, że słabej rywalizacji nie naprawia pewne przyznanie zamówienia.

Najtrudniejsze słowo to wciąż „nie”. Nie, cel nie jest zdefiniowany. Nie, dowody nie mogą być zbadane. Nie, ścieżka ludzkiej kontroli jest dekoracyjna. Nie, ścieżka zmian jest niewidoczna. Nie, rejestr publiczny nie może być prowadzony. Nie, usługa nie może zostać zakończona bez utraty pracy, którą miała chronić. Każde „nie” może być odmową, zawężeniem, pauzą lub prośbą o lepszą odpowiedź. Organ powinien zdecydować, które z nich ma na myśli, udokumentować powód i pozostawić decyzję otwartą na zakwestionowanie.

Zamówienia, które potrafią powiedzieć „nie”, to nie zamówienia bojące się technologii. To zamówienia, które znają różnicę między zdolnością a obietnicą. Płacą za system, który można przetestować, nadzorować, zmieniać i zakończyć. Dają dostawcom uczciwszą rywalizację, ponieważ pytanie jest widoczne. Dają pracownikom publicznym drogę do interwencji, zanim problem stanie się polityką. Dają osobom, których dotyczy usługa, coś bardziej użytecznego niż oświadczenie, że dostawca został zatwierdzony.

Zakup publiczny powinien kończyć się usługą, którą organ może nadal zarządzać. Jeśli dowody są mocne, powiedzenie „tak” ma znaczenie. Jeśli dowody są słabe, powiedzenie „nie” jest pracą publiczną. Akta postępowania zakupowego powinny być w stanie pomieścić oba te zdania.

Źródła