Co powinien zawierać opis przedmiotu zamówienia na bramkę LLM lub platformę AI?

Gdzie przetwarzane są dane, co jest przechowywane, kto może na nich trenować modele, dalsze podmioty przetwarzające i umowę powierzenia, tożsamość i dostęp (SSO, SCIM, klucze), kontrolę wydatków, dozwolone modele i dostawców, dzienniki audytu i eksport, wsparcie obowiązków podmiotu stosującego wynikających z AI Act, warunki wyjścia z umowy i SLA. Ten wzór obejmuje każdy obszar 43 wymaganiami i dowodami, których należy zażądać.

Czy zamawiający publiczni mogą użyć tego wzoru w przetargu?

Tak. Można go swobodnie kopiować i edytować. Zamawiający publiczni zwykle wykorzystują go jako załącznik z wymaganiami technicznymi do opisu przedmiotu zamówienia, a do umowy dołączają dobrowolne wzorcowe klauzule umowne UE dotyczące AI (MCC-AI). Przed publikacją sprawdźcie wymagania pod kątem przepisów o zamówieniach publicznych i oznaczcie te obowiązkowe.

Czym są wzorcowe klauzule umowne UE dotyczące AI?

To wzory postanowień do zakupu systemów AI, opublikowane przez Community of Practice on Public Procurement of AI w serwisie Public Buyers Community Komisji Europejskiej. Aktualizacja z marca 2025 r. ma pełną wersję dla AI wysokiego ryzyka i wersję uproszczoną (Light) dla pozostałych systemów AI. Są dobrowolne i mają być załącznikiem do umowy, która nadal musi regulować ochronę danych, odpowiedzialność i własność intelektualną.

Czy dostawca modeli jest dalszym podmiotem przetwarzającym bramki AI?

Zwykle tak. Gdy bramka przekazuje dostawcy modeli prompty zawierające dane osobowe, ten dostawca przetwarza dane w imieniu bramki. Dlatego wiersze 13 i 14 wymagają listy dalszych podmiotów przetwarzających obejmującej dostawców inferencji i informowania przed dodaniem nowych.

Jak długo platforma AI powinna przechowywać dzienniki żądań?

Przy zastosowaniach wysokiego ryzyka art. 26 ust. 6 AI Act wymaga od podmiotów stosujących przechowywania rejestrów zdarzeń znajdujących się pod ich kontrolą przez co najmniej sześć miesięcy, o ile inne przepisy nie stanowią inaczej. Wielu zamawiających wymaga 12 miesięcy dzienników żądań zawierających wyłącznie metadane i braku przechowywanych treści.

Wymagania do przetargu lub zapytania ofertowego na bramkę LLM albo platformę AI

Aktualizacja: 9 listopada 2026 r. Można swobodnie kopiować, edytować i wykorzystywać we własnej dokumentacji zamówienia.

Firma lub instytucja publiczna, która kupuje dostęp do dużych modeli językowych dla pracowników i aplikacji, zwykle kupuje bramkę: jedno konto i jedno API, przez które korzysta się z modeli wielu dostawców. Ten wzór zawiera 43 wymagania dla takiego zakupu, ułożone w kolejności, w jakiej przechodzi je przegląd bezpieczeństwa i zakupów. Przy każdym podano, dlaczego jest ważne i jakiego dowodu zażądać od wykonawcy.

Wzór jest neutralny wobec dostawców i sprawdza się jako załącznik z wymaganiami do zapytania ofertowego, opisu przedmiotu zamówienia w przetargu publicznym albo oceny bezpieczeństwa dostawcy. W sprawie warunków umownych dotyczących AI połączcie go z dobrowolnymi wzorcowymi klauzulami umownymi UE dotyczącymi AI (MCC-AI), opublikowanymi w marcu 2025 r. w serwisie Public Buyers Community Komisji Europejskiej.

Pobierz wzór (.md)Arkusz (.csv)

Plik CSV otwiera się w Excelu, Arkuszach Google i Numbers, z pustymi kolumnami na wagę, odpowiedź wykonawcy i otrzymany dowód.

Wymagania

Każde wymaganie jest sformułowane tak, aby wykonawca mógł odpowiedzieć na nie jednym akapitem i dołączyć dowód. Oznaczcie wymagania obowiązkowe, nadajcie wagi pozostałym i usuńcie te, które Was nie dotyczą.

1. Lokalizacja danych

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
1	Region przetwarzania. Wykonawca może ograniczyć inferencję do regionu wskazanego przez zamawiającego, na przykład UE/EOG lub Europy, dla całej organizacji, zespołu lub pojedynczego klucza API, łącznie z ponowieniami i trasami zapasowymi.	Dlaczego to ważneBramki przełączają ruch między dostawcami. Bez ograniczenia regionalnego obejmującego każdą próbę trasa zapasowa może niepostrzeżenie przenieść prompt do innej jurysdykcji.	Dowód, którego należy zażądaćZasady routingu dla ruchu objętego ograniczeniem, punkty końcowe dopuszczone w każdym regionie wraz z lokalizacją oraz zachowanie, gdy żaden punkt końcowy w regionie nie może obsłużyć żądania.
2	Definicja regionu. Wykonawca podaje, jakie państwa obejmuje każdy region, na przykład wyłącznie UE/EOG albo także Wielką Brytanię, Szwajcarię lub inne państwa.	Dlaczego to ważneMateriały sprzedażowe często używają słów Europa i UE zamiennie. Ocena przekazywania danych zależy od dokładnej listy.	Dowód, którego należy zażądaćPisemna definicja każdego regionu i miejsce przetwarzania przez każdy dalszy podmiot przetwarzający w jego obrębie.
3	Lokalizacja punktu wejścia i bramki. Wykonawca podaje, gdzie kończy się połączenie TLS, gdzie działa bramka i jakiej nazwy hosta używać do przetwarzania regionalnego.	Dlaczego to ważneŻądanie może obsłużyć model we właściwym regionie, a mimo to najpierw przejść przez globalną sieć brzegową.	Dowód, którego należy zażądaćNazwy hostów dla każdego regionu, dostawca hostingu i region modułu równoważenia obciążenia oraz bramki, a także diagram przepływu danych.
4	Lokalizacja metadanych i dzienników. Wykonawca podaje, gdzie są przechowywane i przetwarzane dane konta, rejestry użycia, dzienniki operacyjne, kopie zapasowe i poczta e-mail.	Dlaczego to ważneOdpowiedzi o lokalizacji danych często dotyczą tylko promptów. Metadane także zawierają dane osobowe, takie jak imiona i nazwiska, adresy e-mail i adresy IP.	Dowód, którego należy zażądaćMiejsce przechowywania dla każdej kategorii danych, łącznie z kopiami zapasowymi i wiadomościami transakcyjnymi.

2. Retencja i zerowa retencja danych (ZDR)

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
5	Brak przechowywania treści przez wykonawcę. Wykonawca przetwarza prompty i odpowiedzi wyłącznie w celu obsługi żądania albo dokładnie podaje, jakie treści przechowuje, gdzie i jak długo.	Dlaczego to ważneBramka widzi każdy prompt wysyłany przez organizację. Jej własna retencja to pierwsze ryzyko do sprawdzenia.	Dowód, którego należy zażądaćOpis przepływu danych, schemat dzienników z zapisywanymi polami i odpowiednie postanowienie umowy powierzenia.
6	ZDR u dostawców modeli. Zamawiający może wymagać, aby żądania trafiały wyłącznie do punktów końcowych modeli, które zobowiązują się nie przechowywać kopii treści, na poziomie organizacji, zespołu lub klucza, a niższe poziomy nie mogą tego wyłączyć.	Dlaczego to ważneDostawcy modeli zwykle przechowują prompty przez pewien czas w celu wykrywania nadużyć, chyba że dla danego punktu końcowego obowiązuje uzgodnienie o ZDR.	Dowód, którego należy zażądaćWarunki retencji każdego dostawcy, sposób egzekwowania ustawienia przy każdym żądaniu i funkcje wyłączane, gdy jest aktywne.
7	Funkcje, które przechowują treści. Wykonawca wymienia każdą funkcję przechowującą treści (buforowanie promptów, zapisane odpowiedzi, stan rozmowy, pliki, zadania wsadowe) wraz z okresem retencji i ustawieniem, które ją wyłącza.	Dlaczego to ważneZobowiązania dotyczące retencji zwykle mają wyjątki dla poszczególnych funkcji. Lista pokazuje, gdzie one są.	Dowód, którego należy zażądaćLista funkcji z okresem retencji dla każdej z nich i ustawieniem, które ją wyłącza.
8	Usunięcie danych po zakończeniu umowy. Wykonawca usuwa lub zwraca dane zamawiającego w określonym terminie po zakończeniu usługi i potwierdza to na piśmie.	Dlaczego to ważneArt. 28 ust. 3 lit. g) RODO wymaga, aby umowa z podmiotem przetwarzającym regulowała usunięcie lub zwrot danych po zakończeniu świadczenia usług.	Dowód, którego należy zażądaćPostanowienie umowy powierzenia z terminem, sposób postępowania z kopiami zapasowymi i wzór potwierdzenia usunięcia.

3. Trenowanie modeli i wykorzystanie danych

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
9	Brak trenowania przez wykonawcę. Wykonawca nie wykorzystuje promptów, odpowiedzi ani metadanych do trenowania lub ulepszania modeli.	Dlaczego to ważneTrenowanie to wykorzystanie, które zamawiający najczęściej wyłączają, a wyłączenie wiąże tylko wtedy, gdy jest zapisane w umowie.	Dowód, którego należy zażądaćPostanowienie umowy lub umowy powierzenia i odpowiedni fragment informacji o ochronie prywatności.
10	Brak trenowania przez dostawców modeli. Wykonawca kieruje ruch zamawiającego wyłącznie do dostawców, którzy zobowiązują się nie trenować na nim modeli, i wyjaśnia, jak jest to egzekwowane przy każdym żądaniu.	Dlaczego to ważneZobowiązanie samej bramki nie wiąże dostawców modeli, którzy za nią stoją.	Dowód, którego należy zażądaćWarunki dostawcy dla każdego punktu końcowego, mechanizm egzekwowania i ruch, którego dotyczy.
11	Inne wtórne wykorzystanie. Wykonawca podaje, czy treści lub metadane są wykorzystywane do analityki, benchmarków, rozwoju produktu lub przeglądu przez ludzi, i jak z tego zrezygnować.	Dlaczego to ważneWtórne wykorzystanie wykracza poza polecenia, które administrator wydaje podmiotowi przetwarzającemu, o ile nie zostało uzgodnione.	Dowód, którego należy zażądaćLista form wtórnego wykorzystania, zasady przeglądu przez ludzi i ustawienie pozwalające zrezygnować.

4. Dalsze podmioty przetwarzające i umowa powierzenia

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
12	Umowa powierzenia przetwarzania danych. Umowa zgodna z art. 28 RODO jest dostępna przed podpisaniem i obejmuje przedmiot, czas trwania, polecenia, poufność, bezpieczeństwo, pomoc, usunięcie danych i audyty.	Dlaczego to ważneArt. 28 ust. 3 wymienia, co musi zawierać umowa z podmiotem przetwarzającym. Bramka przetwarza dane osobowe w każdym prompcie, który wspomina o jakiejś osobie.	Dowód, którego należy zażądaćTekst umowy powierzenia, prawo właściwe i sposób jej podpisania.
13	Lista dalszych podmiotów przetwarzających. Wykonawca publikuje każdy dalszy podmiot przetwarzający (w RODO: inny podmiot przetwarzający) wraz z celem, przetwarzanymi danymi i lokalizacją, łącznie z dostawcami modeli i inferencji.	Dlaczego to ważneW przypadku bramki każdy dostawca modeli, który może obsłużyć Wasz ruch, jest dalszym podmiotem przetwarzającym.	Dowód, którego należy zażądaćAdres URL listy i data jej ostatniej zmiany.
14	Informowanie o nowych podmiotach. Wykonawca z określonym wyprzedzeniem informuje o dodaniu lub zastąpieniu dalszego podmiotu przetwarzającego i daje prawo do sprzeciwu.	Dlaczego to ważneArt. 28 ust. 2 wymaga, aby administrator był informowany o zmianach i miał możliwość wyrażenia sprzeciwu.	Dowód, którego należy zażądaćPostanowienie umowy powierzenia z okresem wyprzedzenia i kanał, którym przekazywane są informacje.
15	Przekazywanie danych do państw trzecich. Dla każdego przetwarzania poza EOG wykonawca wskazuje podstawę przekazania (decyzja stwierdzająca odpowiedni stopień ochrony, standardowe klauzule umowne, UK IDTA).	Dlaczego to ważnePrzekazanie wymaga podstawy prawnej z rozdziału V RODO, a zamawiający dokumentuje swoją ocenę.	Dowód, którego należy zażądaćZałączniki do standardowych klauzul umownych i podsumowanie oceny skutków przekazania przeprowadzonej przez wykonawcę.
16	Zgłaszanie naruszeń. Wykonawca zgłasza naruszenia ochrony danych osobowych bez zbędnej zwłoki i w określonej liczbie godzin.	Dlaczego to ważneAdministrator ma zgodnie z art. 33 72 godziny na zgłoszenie organowi nadzorczemu, więc termin podmiotu przetwarzającego musi być krótszy lub równy.	Dowód, którego należy zażądaćPostanowienie umowy powierzenia, podsumowanie procesu reagowania na incydenty i kontakt w sprawach bezpieczeństwa.

5. Tożsamość i dostęp

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
17	Logowanie jednokrotne. Logowanie przez SAML 2.0 lub OpenID Connect z dostawcą tożsamości zamawiającego, takim jak Microsoft Entra ID, Okta lub Google Workspace, do konsoli administracyjnej i dla użytkowników.	Dlaczego to ważneKonta służbowe wiążą dostęp z zatrudnieniem i stosują MFA oraz zasady logowania zamawiającego.	Dowód, którego należy zażądaćObsługiwane protokoły i dostawcy tożsamości, instrukcja konfiguracji i połączenie testowe.
18	Wymuszenie SSO. Zamawiający może wymagać SSO od wszystkich użytkowników i wyłączyć logowanie hasłem oraz inne metody logowania.	Dlaczego to ważneSSO działające obok haseł pozostawia konta poza kontrolą dostawcy tożsamości.	Dowód, którego należy zażądaćUstawienie i jego wpływ na istniejące sesje oraz klucze API.
19	Zarządzanie kontami użytkowników. Tworzenie i usuwanie kont przez SCIM 2.0 z poziomu dostawcy tożsamości, z mapowaniem grup na role lub zespoły.	Dlaczego to ważneBez automatycznego usuwania kont osoby, które odeszły z firmy, zachowują dostęp, dopóki ktoś nie przypomni sobie, żeby go odebrać.	Dowód, którego należy zażądaćObsługiwane zasoby SCIM (użytkownicy, grupy) i to, jak szybko usunięcie konta unieważnia sesje i klucze.
20	Role i klucze API. Dostęp oparty na rolach, klucz dla każdej osoby i każdej aplikacji, klucze o ograniczonym zakresie i natychmiastowe unieważnienie.	Dlaczego to ważneWspólne klucze ukrywają, kto wysłał które żądanie, i nie można ich unieważnić dla jednej osoby.	Dowód, którego należy zażądaćMacierz ról i cykl życia kluczy: tworzenie, ograniczanie zakresu, rotacja i unieważnianie.
21	Aplikacje desktopowe i agenci programistyczni. Wykonawca podaje, jak pracownicy uwierzytelniają się w desktopowych aplikacjach AI i agentach programistycznych (na przykład Claude Desktop, Claude Code i rozszerzeniach IDE): logowaniem kontem służbowym czy rozdawanymi kluczami.	Dlaczego to ważneTo w tych narzędziach pojawiają się prywatne konta i skopiowane klucze poza procesem zakupowym.	Dowód, którego należy zażądaćInstrukcja konfiguracji i lista obsługiwanych narzędzi.

6. Kontrola wydatków

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
22	Budżety na poziomach, którymi zarządzacie. Twarde limity miesięczne dla użytkownika, aplikacji oraz zespołu lub działu, które zatrzymują wydatki po osiągnięciu limitu.	Dlaczego to ważneAgenci i zadania wsadowe mogą wydać miesięczny budżet w kilka godzin. Limit, który tylko ostrzega, jest raportem.	Dowód, którego należy zażądaćObsługiwane poziomy i to, co dzieje się po osiągnięciu limitu: blokada, ostrzeżenie czy przekroczenie.
23	Limit organizacji i alerty. Limit dla całej organizacji i alerty przed osiągnięciem dowolnego limitu.	Dlaczego to ważneDział finansów potrzebuje jednej kwoty, której nie da się przekroczyć, niezależnie od tego, co dzieje się poniżej.	Dowód, którego należy zażądaćUstawienia i kanały alertów.
24	Ceny i fakturowanie. Cena za model lub za plan, waluta rozliczeń, faktury z danymi firmy zamawiającego i numerem VAT oraz raporty kosztów według użytkowników i aplikacji do rozliczeń wewnętrznych.	Dlaczego to ważneCeny za token różnią się między modelami o rzędy wielkości, więc ocena ofert wymaga podstawy cenowej i raportowania.	Dowód, którego należy zażądaćCennik, przykładowa faktura i przykładowy raport użycia.

7. Dostęp do modeli i listy dozwolonych

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
25	Katalog modeli. Oferowane modele czołowe i modele o otwartych wagach oraz informacja, które z nich są dostępne przy każdym ograniczeniu regionalnym.	Dlaczego to ważneModel niedostępny w Waszym regionie jest dla Was niedostępny, gdy ograniczenie regionalne jest włączone.	Dowód, którego należy zażądaćLista modeli dla każdego regionu i zasady dodawania modeli.
26	Listy dozwolonych modeli. Administratorzy decydują, z jakich modeli może korzystać każdy zespół, aplikacja lub klucz. Żądania do innych modeli są odrzucane.	Dlaczego to ważneZatwierdzenie modelu zapisane tylko w dokumencie z zasadami nikogo nie powstrzyma przed wywołaniem innego modelu.	Dowód, którego należy zażądaćUstawienie i błąd zwracany dla modelu, który nie jest dozwolony.
27	Listy dozwolonych dostawców. Administratorzy decydują, którzy dostawcy inferencji mogą obsługiwać ruch. Trasy zapasowe przestrzegają listy, a nowi dostawcy nigdy nie są dodawani bez zgody.	Dlaczego to ważneDostawca dodany przez wykonawcę to nowe miejsce, w którym przetwarzane są Wasze dane.	Dowód, którego należy zażądaćUstawienie, sposób jego stosowania na trasach zapasowych i to, co się dzieje, gdy wykonawca dodaje dostawcę.
28	Zmiany modeli. Wykonawca z wyprzedzeniem informuje o wycofaniu modeli i zmianach wersji, a zamawiający może przypiąć wersję.	Dlaczego to ważneNiezauważona zmiana modelu zmienia jakość wyników i może unieważnić ocenę wykonaną dla danego zastosowania.	Dowód, którego należy zażądaćZasady wycofywania modeli i kanał powiadomień.
29	Przejrzystość routingu. Jeśli wykonawca automatycznie kieruje ruch między modelami lub dostawcami ze względu na koszt lub dostępność, dokumentuje reguły i zapisuje, który model i który dostawca obsłużył każde żądanie.	Dlaczego to ważneAutomatyczny routing ma wartość tylko wtedy, gdy widać, dokąd trafiło każde żądanie.	Dowód, którego należy zażądaćDokumentacja routingu i przykładowy wpis dla pojedynczego żądania.

8. Dzienniki audytu i eksport

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
30	Dziennik audytu administratora. Każda zmiana dotycząca użytkowników, kluczy, budżetów i zasad, z autorem, czasem oraz wartością przed i po zmianie.	Dlaczego to ważneAudytorzy pytają, kto i kiedy zmienił zasady. Bez wartości przed i po dziennik nie odpowie, co się zmieniło.	Dowód, którego należy zażądaćPrzykładowy wpis w dzienniku i okres przechowywania.
31	Dziennik żądań. Dla każdego żądania czas, użytkownik lub klucz, model, obsługujący dostawca, ograniczenie regionalne, status, tokeny i koszt, bez treści, chyba że zamawiający to włączy, z określonym okresem przechowywania.	Dlaczego to ważnePrzy zastosowaniach wysokiego ryzyka art. 26 ust. 6 AI Act wymaga od podmiotów stosujących przechowywania rejestrów zdarzeń znajdujących się pod ich kontrolą przez co najmniej sześć miesięcy. Dziennik żądań jest też dowodem dla rejestru systemów AI.	Dowód, którego należy zażądaćLista pól, okres przechowywania i przykładowy eksport.
32	Eksport. Dzienniki można eksportować jako CSV lub przez API i przesyłać do systemu SIEM zamawiającego.	Dlaczego to ważneZapisów, których zamawiający nie może wyeksportować, nie wykorzysta we własnym audycie.	Dowód, którego należy zażądaćFormaty, limity wierszy lub okresu i dokumentacja API.

9. Obowiązki podmiotu stosującego w rozumieniu AI Act

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
33	Wsparcie rejestru i kompetencji w zakresie AI. Wykonawca dostarcza informacje potrzebne zamawiającemu do rejestru systemów AI i działań na rzecz kompetencji w zakresie AI z art. 4: modele używane w każdej aplikacji, ich dostawców i udokumentowane ograniczenia.	Dlaczego to ważneArt. 4 stosuje się od 2 lutego 2025 r., a rejestr systemów AI jest punktem wyjścia do wszystkich pozostałych obowiązków z AI Act.	Dowód, którego należy zażądaćZapisy modeli i dostawców dla każdej aplikacji i linki do dokumentacji modeli.
34	Zastosowania wysokiego ryzyka. Jeśli zamawiający użyje usługi do celu wymienionego w załączniku III, wykonawca określa swoją rolę w rozumieniu AI Act i akceptuje odpowiednie postanowienia wzorcowych klauzul umownych UE dotyczących AI.	Dlaczego to ważneObowiązki podmiotów stosujących systemy z załącznika III mają zastosowanie od 2 grudnia 2027 r. i zależą od informacji, którymi dysponują wyłącznie wykonawca i dostawca modelu.	Dowód, którego należy zażądaćOświadczenie wykonawcy o jego roli i wypełniony załącznik MCC-AI (High Risk lub Light).
35	Dokumentacja modeli AI ogólnego przeznaczenia. Dla każdego oferowanego modelu AI ogólnego przeznaczenia wykonawca podaje link do dokumentacji udostępnianej przez jego dostawcę dostawcom niższego szczebla oraz do publicznego streszczenia treści użytych do trenowania.	Dlaczego to ważneArt. 53 zobowiązuje dostawców modeli AI ogólnego przeznaczenia do jej udostępnienia, a zamawiający archiwizują ją dla każdego modelu.	Dowód, którego należy zażądaćLinki dla każdego modelu i data pobrania.
36	Przejrzystość. Wykonawca podaje, czy wyniki są oznakowane w formacie nadającym się do odczytu maszynowego i jak wspiera obowiązki informacyjne zamawiającego.	Dlaczego to ważneObowiązki przejrzystości z art. 50 mają zastosowanie od 2 sierpnia 2026 r.	Dowód, którego należy zażądaćInformacje o oznakowaniu dla każdego modelu i wskazówki dotyczące ujawniania.

10. Wyjście z umowy i przenoszalność

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
37	Standardowy interfejs. API jest zgodne z powszechnie używanym interfejsem, na przykład formatem chat completions zgodnym z OpenAI, dzięki czemu aplikacje można przenieść bez przepisywania.	Dlaczego to ważneZamknięty interfejs zamienia zmianę dostawcy w projekt programistyczny.	Dowód, którego należy zażądaćDokumentacja API oraz SDK i narzędzia, o których wiadomo, że z nim działają.
38	Eksport danych przy wyjściu z umowy. Zamawiający może wyeksportować konfigurację, użytkowników, metadane kluczy, dane o użyciu i dzienniki w formacie nadającym się do odczytu maszynowego przed rozwiązaniem umowy i po nim.	Dlaczego to ważneJeśli usługa jest usługą przetwarzania danych w rozumieniu aktu w sprawie danych (Data Act), rozdział VI daje klientowi prawo do zmiany dostawcy, a od 12 stycznia 2027 r. nie wolno pobierać opłat z tytułu zmiany dostawcy.	Dowód, którego należy zażądaćFormaty eksportu, oferowane wsparcie przy przejściu i okres, przez który dane pozostają dostępne po wypowiedzeniu.
39	Okres umowy i wypowiedzenie. Okres obowiązywania umowy, okres wypowiedzenia, ewentualne opłaty przy rozwiązaniu i okres przejściowy.	Dlaczego to ważneDługie okresy umowy i opłaty za rozwiązanie decydują o tym, ile kosztuje wyjście.	Dowód, którego należy zażądaćWarunki handlowe i postanowienie o rozwiązaniu umowy.

11. Wsparcie i SLA

Nr	Wymaganie	Dlaczego to ważne	Dowód, którego należy zażądać
40	SLA dostępności. Miesięczne zobowiązanie dotyczące dostępności z rekompensatami, metodą pomiaru i wyłączeniami.	Dlaczego to ważneAI trafia do procesów produkcyjnych, w których przestoje kosztują.	Dowód, którego należy zażądaćDokument SLA, publiczna strona statusu i dostępność z ostatnich 12 miesięcy.
41	Przełączanie awaryjne między dostawcami. Gdy dostawca modelu jest niedostępny, żądania przechodzą do innego zatwierdzonego dostawcy tego samego modelu w granicach ograniczeń regionalnych i list dozwolonych.	Dlaczego to ważnePrzełączenie awaryjne, które ignoruje region lub listę dozwolonych, łamie zasady dokładnie wtedy, gdy trwa już incydent.	Dowód, którego należy zażądaćArchitektura przełączania awaryjnego i liczba dostawców dla każdego modelu przy każdym ograniczeniu regionalnym.
42	Wsparcie i komunikacja o incydentach. Kanały wsparcia, czasy reakcji według priorytetu, języki i sposób informowania o incydentach.	Dlaczego to ważneWłasny proces obsługi incydentów zamawiającego zależy od procesu wykonawcy.	Dowód, którego należy zażądaćZasady wsparcia, adres URL strony statusu i ostatnie raporty z incydentów.
43	Dokumentacja bezpieczeństwa. Opis zabezpieczeń, wypełniony kwestionariusz bezpieczeństwa oraz raporty z audytów lub certyfikaty posiadane przez wykonawcę i jego dostawców hostingu.	Dlaczego to ważneTo sprawdza zespół bezpieczeństwa zamawiającego przed zatwierdzeniem. Zażądanie tego już w przetargu oszczędza jedną rundę.	Dowód, którego należy zażądaćStrona o bezpieczeństwie, wypełniony kwestionariusz, na przykład otwarty kwestionariusz bezpieczeństwa bramki LLM (w języku angielskim), i ewentualne raporty.

Pobierz wzór (.md)Arkusz (.csv)

Jak odpowiada Standard Compute

Standard Compute to europejska bramka AI: jedno konto firmowe i jedno API dla Claude, GPT, Gemini i modeli otwartych, prowadzona przez Standard Compute AS z siedzibą w Oslo. Poniżej nasze odpowiedzi na powyższe wymagania, w brzmieniu, którego używamy na stronie o bezpieczeństwie i w umowie powierzenia. Numery odnoszą się do wierszy wzoru.

Nr	Status	Nasza odpowiedź
Nr 1	Dostępne, do włączenia	Ustawcie ograniczenie do Europy dla firmy, zespołu lub pojedynczego klucza, a każde żądanie, łącznie z ponowieniami i trasami zapasowymi, obsłużą wyłącznie zatwierdzone europejskie punkty końcowe inferencji. Jeśli żaden europejski punkt końcowy nie może go obsłużyć, żądanie zostaje odrzucone, zanim Wasz prompt zostanie wysłany.
Nr 2	Dostępne	Ograniczenie do Europy dopuszcza wyłącznie zatwierdzone europejskie punkty końcowe inferencji wymienione na naszej liście dalszych podmiotów przetwarzających, każdy z miejscem przetwarzania.
Nr 3	Dostępne	Nasza bramka UE pod adresem eu.stdcmpt.com kończy połączenia TLS i działa w Finlandii, a dane Waszego konta są przechowywane we Frankfurcie.
Nr 4	Dostępne	Dane konta i dane o użyciu są przechowywane we Frankfurcie w Niemczech. Dzienniki żądań zawierają wyłącznie metadane (model, dostawca, tokeny, koszt i status), nigdy Wasze prompty ani odpowiedzi. Każdy dalszy podmiot przetwarzający platformy jest wymieniony wraz z lokalizacją.
Nr 5	Dostępne	Przetwarzamy Wasze prompty w pamięci operacyjnej, aby obsłużyć każde żądanie, i nigdy nie zapisujemy ich w pamięci trwałej ani w logach.
Nr 6	Dostępne, do włączenia	Włączcie ZDR dla firmy, zespołu lub klucza, a każde żądanie trafi wyłącznie do punktów końcowych inferencji, które zobowiązują się nie przechowywać żadnej kopii Waszych danych. Zespoły i klucze dziedziczą to wymaganie i nigdy nie mogą go wyłączyć.
Nr 8	Dostępne	Umowa powierzenia przewiduje usunięcie lub zwrot wszystkich pozostałych danych osobowych klienta w ciągu 30 dni od zakończenia umowy (sekcja 10).
Nr 9, 10	Dostępne	Standard Compute nigdy nie trenuje modeli na Waszych promptach ani odpowiedziach. Przy włączonym ograniczeniu regionalnym lub ZDR każde żądanie trafia wyłącznie do dostawców, którzy zobowiązują się nie trenować na nim modeli.
Nr 12, 16	Dostępne	Podpiszcie naszą umowę powierzenia przetwarzania danych w panelu w kilka minut. Zobowiązuje nas ona do nietrenowania modeli na Waszych danych, nieprzechowywania Waszych treści i zgłaszania naruszeń w ciągu 72 godzin. Umowa powierzenia podlega prawu norweskiemu.
Nr 13, 14	Dostępne	Publikujemy każdy dalszy podmiot przetwarzający wraz z celem, danymi i lokalizacją i informujemy z 14-dniowym wyprzedzeniem przed dodaniem nowego podmiotu.
Nr 15	Dostępne	Przekazywanie danych poza EOG lub Wielką Brytanię do państwa bez decyzji stwierdzającej odpowiedni stopień ochrony odbywa się na podstawie standardowych klauzul umownych UE, a w przypadku danych z Wielkiej Brytanii na podstawie UK IDTA (sekcja 6 umowy powierzenia).
Nr 17	Dostępne	Podłączcie Microsoft Entra ID lub dowolnego dostawcę tożsamości SAML, aby pracownicy logowali się do Standard Compute kontami służbowymi. Każdy, kto należy do Waszej zweryfikowanej domeny, automatycznie dołącza do firmy.
Nr 18	Częściowo	Logowanie przez SAML jest dostępne dla każdej firmy z SSO. Logowanie hasłem pozostaje dostępne równolegle, więc SSO nie jest jedyną drogą dostępu.
Nr 19, 21	Dostępne	Pracownicy logują się do Claude Desktop i Claude Code kontem służbowym Microsoft przez naszą bramkę UE, więc nie trzeba rozdawać kluczy API. Dostęp jest przyznawany zgodnie z Waszymi grupami Microsoft Entra za pomocą provisioningu SCIM.
Nr 20	Dostępne	Podzielcie firmę na zespoły, zapraszajcie współpracowników e-mailem i dajcie każdej osobie i każdej aplikacji własny klucz, wszystko w ramach jednego konta firmowego. Role to administrator i członek.
Nr 22, 23	Częściowo	Każda osoba i każda aplikacja otrzymuje stały miesięczny budżet, którego nie da się przekroczyć, a limity wydatków możecie ustawić dla każdego klucza i dla całej firmy. Nie ma osobnego budżetu dla zespołu: zespoły są objęte budżetami swoich osób i aplikacji.
Nr 24	Dostępne	Stałe miesięczne plany dla osoby lub aplikacji, bez niespodzianek w kosztach tokenów, i faktury Stripe z nazwą firmy i numerem VAT. Ceny są w dolarach amerykańskich.
Nr 25	Dostępne	Korzystajcie z czołowych modeli otwartych, takich jak GLM, DeepSeek, MiniMax i Kimi, obok Claude, GPT i Gemini, przez jedno API. GLM, DeepSeek i MiniMax są też obsługiwane przez europejskich dostawców dla przestrzeni roboczych ograniczonych do Europy.
Nr 26	Dostępne	Decydujcie, z jakich modeli może korzystać każdy klucz, aby każda aplikacja i każdy członek zespołu mieli dokładnie te modele, które zatwierdzicie.
Nr 27	Dostępne	Wybierzcie dokładnie, którzy dostawcy inferencji mogą przetwarzać Wasze dane, dla całej firmy, zespołu lub pojedynczego klucza. Niższe poziomy mogą reguły tylko zawężać, nowi dostawcy nigdy nie są dodawani bez zgody administratora, a trasy zapasowe nigdy nie omijają Waszej listy.
Nr 29	Dostępne	Każdy krok trafia do najtańszego modelu, który go wykona, i do najtańszego dostawcy wystarczająco szybkiego, by go obsłużyć, a dziennik żądań pokazuje model i dostawcę, który obsłużył dane żądanie.
Nr 30, 31, 32	Dostępne	Każda zmiana administratora jest zapisywana z wartością przed i po, a zapis każdego żądania z modelem, dostawcą, który je obsłużył, i obowiązującym ograniczeniem regionalnym możecie wyeksportować. Zapisy są przechowywane przez 12 miesięcy. Eksport odbywa się w formacie CSV.
Nr 33	Dostępne	Klucz dla każdej osoby i każdej aplikacji, modele dozwolone dla każdego klucza oraz model i obsługujący dostawca każdego żądania: zapisy, których wymaga nasza lista kontrolna AI Act dla podmiotu stosującego.
Nr 37	Dostępne	Jedno API zgodne z OpenAI (format chat completions) dla każdego modelu, opisane w dokumentacji API.
Nr 40, 41	Dostępne	W razie awarii dostawcy Wasze żądanie automatycznie przechodzi do innego zatwierdzonego dostawcy tego samego modelu, bez wychodzenia poza ograniczenia regionalne i ograniczenia dostawców. Plan Enterprise obejmuje miesięczne SLA dostępności 99,9% z rekompensatami. Aktualny status jest publiczny pod adresem /status.
Nr 43	Dostępne	Nasza strona o bezpieczeństwie, wypełniony kwestionariusz bezpieczeństwa, lista dalszych podmiotów przetwarzających i umowa powierzenia są publiczne.

Na wiersze, których tu nie ma, odpowiemy w ofercie razem z Waszym opiekunem. Powyższy wzór pozostaje neutralny wobec dostawców: używajcie go z każdym wykonawcą.

Załóż konto firmowe

Pytania

Co powinien zawierać opis przedmiotu zamówienia na bramkę LLM lub platformę AI?: Gdzie przetwarzane są dane, co jest przechowywane, kto może na nich trenować modele, dalsze podmioty przetwarzające i umowę powierzenia, tożsamość i dostęp (SSO, SCIM, klucze), kontrolę wydatków, dozwolone modele i dostawców, dzienniki audytu i eksport, wsparcie obowiązków podmiotu stosującego wynikających z AI Act, warunki wyjścia z umowy i SLA. Ten wzór obejmuje każdy obszar 43 wymaganiami i dowodami, których należy zażądać.
Czy zamawiający publiczni mogą użyć tego wzoru w przetargu?: Tak. Można go swobodnie kopiować i edytować. Zamawiający publiczni zwykle wykorzystują go jako załącznik z wymaganiami technicznymi do opisu przedmiotu zamówienia, a do umowy dołączają dobrowolne wzorcowe klauzule umowne UE dotyczące AI (MCC-AI). Przed publikacją sprawdźcie wymagania pod kątem przepisów o zamówieniach publicznych i oznaczcie te obowiązkowe.
Czym są wzorcowe klauzule umowne UE dotyczące AI?: To wzory postanowień do zakupu systemów AI, opublikowane przez Community of Practice on Public Procurement of AI w serwisie Public Buyers Community Komisji Europejskiej. Aktualizacja z marca 2025 r. ma pełną wersję dla AI wysokiego ryzyka i wersję uproszczoną (Light) dla pozostałych systemów AI. Są dobrowolne i mają być załącznikiem do umowy, która nadal musi regulować ochronę danych, odpowiedzialność i własność intelektualną.
Czy dostawca modeli jest dalszym podmiotem przetwarzającym bramki AI?: Zwykle tak. Gdy bramka przekazuje dostawcy modeli prompty zawierające dane osobowe, ten dostawca przetwarza dane w imieniu bramki. Dlatego wiersze 13 i 14 wymagają listy dalszych podmiotów przetwarzających obejmującej dostawców inferencji i informowania przed dodaniem nowych.
Jak długo platforma AI powinna przechowywać dzienniki żądań?: Przy zastosowaniach wysokiego ryzyka art. 26 ust. 6 AI Act wymaga od podmiotów stosujących przechowywania rejestrów zdarzeń znajdujących się pod ich kontrolą przez co najmniej sześć miesięcy, o ile inne przepisy nie stanowią inaczej. Wielu zamawiających wymaga 12 miesięcy dzienników żądań zawierających wyłącznie metadane i braku przechowywanych treści.

Źródła

Odpowiedzcie na cały wzór z jednym wykonawcą: europejska bramka do modeli czołowych i otwartych, ze wszystkimi mechanizmami kontroli na jednym koncie firmowym.