# 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) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses), opublikowanymi w marcu 2025 r. w serwisie Public Buyers Community Komisji Europejskiej.

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

| Obowiązkowe | 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. | Bramki 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. | 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. | Materiały sprzedażowe często używają słów Europa i UE zamiennie. Ocena przekazywania danych zależy od dokładnej listy. | 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. | Żądanie może obsłużyć model we właściwym regionie, a mimo to najpierw przejść przez globalną sieć brzegową. | 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. | Odpowiedzi 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. | Miejsce przechowywania dla każdej kategorii danych, łącznie z kopiami zapasowymi i wiadomościami transakcyjnymi. |

## 2. Retencja i zerowa retencja danych (ZDR)

| Obowiązkowe | 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. | Bramka widzi każdy prompt wysyłany przez organizację. Jej własna retencja to pierwsze ryzyko do sprawdzenia. | 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ć. | Dostawcy modeli zwykle przechowują prompty przez pewien czas w celu wykrywania nadużyć, chyba że dla danego punktu końcowego obowiązuje uzgodnienie o ZDR. | 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. | Zobowiązania dotyczące retencji zwykle mają wyjątki dla poszczególnych funkcji. Lista pokazuje, gdzie one są. | 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. | Art. 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. | Postanowienie umowy powierzenia z terminem, sposób postępowania z kopiami zapasowymi i wzór potwierdzenia usunięcia. |

## 3. Trenowanie modeli i wykorzystanie danych

| Obowiązkowe | 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. | Trenowanie to wykorzystanie, które zamawiający najczęściej wyłączają, a wyłączenie wiąże tylko wtedy, gdy jest zapisane w umowie. | 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. | Zobowiązanie samej bramki nie wiąże dostawców modeli, którzy za nią stoją. | 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ć. | Wtórne wykorzystanie wykracza poza polecenia, które administrator wydaje podmiotowi przetwarzającemu, o ile nie zostało uzgodnione. | Lista form wtórnego wykorzystania, zasady przeglądu przez ludzi i ustawienie pozwalające zrezygnować. |

## 4. Dalsze podmioty przetwarzające i umowa powierzenia

| Obowiązkowe | 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. | Art. 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. | 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. | W przypadku bramki każdy dostawca modeli, który może obsłużyć Wasz ruch, jest dalszym podmiotem przetwarzającym. | 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. | Art. 28 ust. 2 wymaga, aby administrator był informowany o zmianach i miał możliwość wyrażenia sprzeciwu. | 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). | Przekazanie wymaga podstawy prawnej z rozdziału V RODO, a zamawiający dokumentuje swoją ocenę. | 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. | Administrator 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. | Postanowienie umowy powierzenia, podsumowanie procesu reagowania na incydenty i kontakt w sprawach bezpieczeństwa. |

## 5. Tożsamość i dostęp

| Obowiązkowe | 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. | Konta służbowe wiążą dostęp z zatrudnieniem i stosują MFA oraz zasady logowania zamawiającego. | 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. | SSO działające obok haseł pozostawia konta poza kontrolą dostawcy tożsamości. | 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. | Bez automatycznego usuwania kont osoby, które odeszły z firmy, zachowują dostęp, dopóki ktoś nie przypomni sobie, żeby go odebrać. | 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. | Wspólne klucze ukrywają, kto wysłał które żądanie, i nie można ich unieważnić dla jednej osoby. | 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. | To w tych narzędziach pojawiają się prywatne konta i skopiowane klucze poza procesem zakupowym. | Instrukcja konfiguracji i lista obsługiwanych narzędzi. |

## 6. Kontrola wydatków

| Obowiązkowe | 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. | Agenci i zadania wsadowe mogą wydać miesięczny budżet w kilka godzin. Limit, który tylko ostrzega, jest raportem. | 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. | Dział finansów potrzebuje jednej kwoty, której nie da się przekroczyć, niezależnie od tego, co dzieje się poniżej. | 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. | Ceny za token różnią się między modelami o rzędy wielkości, więc ocena ofert wymaga podstawy cenowej i raportowania. | Cennik, przykładowa faktura i przykładowy raport użycia. |

## 7. Dostęp do modeli i listy dozwolonych

| Obowiązkowe | 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. | Model niedostępny w Waszym regionie jest dla Was niedostępny, gdy ograniczenie regionalne jest włączone. | 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. | Zatwierdzenie modelu zapisane tylko w dokumencie z zasadami nikogo nie powstrzyma przed wywołaniem innego modelu. | 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. | Dostawca dodany przez wykonawcę to nowe miejsce, w którym przetwarzane są Wasze dane. | 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ę. | Niezauważona zmiana modelu zmienia jakość wyników i może unieważnić ocenę wykonaną dla danego zastosowania. | 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. | Automatyczny routing ma wartość tylko wtedy, gdy widać, dokąd trafiło każde żądanie. | Dokumentacja routingu i przykładowy wpis dla pojedynczego żądania. |

## 8. Dzienniki audytu i eksport

| Obowiązkowe | 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. | Audytorzy pytają, kto i kiedy zmienił zasady. Bez wartości przed i po dziennik nie odpowie, co się zmieniło. | 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. | 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. Dziennik żądań jest też dowodem dla rejestru systemów AI. | 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. | Zapisów, których zamawiający nie może wyeksportować, nie wykorzysta we własnym audycie. | Formaty, limity wierszy lub okresu i dokumentacja API. |

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

| Obowiązkowe | 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. | Art. 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. | 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. | Obowią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. | 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. | Art. 53 zobowiązuje dostawców modeli AI ogólnego przeznaczenia do jej udostępnienia, a zamawiający archiwizują ją dla każdego modelu. | 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. | Obowiązki przejrzystości z art. 50 mają zastosowanie od 2 sierpnia 2026 r. | Informacje o oznakowaniu dla każdego modelu i wskazówki dotyczące ujawniania. |

## 10. Wyjście z umowy i przenoszalność

| Obowiązkowe | 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. | Zamknięty interfejs zamienia zmianę dostawcy w projekt programistyczny. | 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. | Jeś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. | 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. | Długie okresy umowy i opłaty za rozwiązanie decydują o tym, ile kosztuje wyjście. | Warunki handlowe i postanowienie o rozwiązaniu umowy. |

## 11. Wsparcie i SLA

| Obowiązkowe | 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. | AI trafia do procesów produkcyjnych, w których przestoje kosztują. | 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. | Przełączenie awaryjne, które ignoruje region lub listę dozwolonych, łamie zasady dokładnie wtedy, gdy trwa już incydent. | 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. | Własny proces obsługi incydentów zamawiającego zależy od procesu wykonawcy. | 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. | To sprawdza zespół bezpieczeństwa zamawiającego przed zatwierdzeniem. Zażądanie tego już w przetargu oszczędza jedną rundę. | Strona o bezpieczeństwie, wypełniony kwestionariusz, na przykład otwarty kwestionariusz bezpieczeństwa bramki LLM (w języku angielskim) (https://standardcompute.com/security/questionnaire), i ewentualne raporty. |

---

## Źródła

- [Zaktualizowane wzorcowe klauzule umowne UE dotyczące AI (MCC-AI High Risk i Light), Public Buyers Community, 5 marca 2025 r.](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Rozporządzenie (UE) 2016/679, ogólne rozporządzenie o ochronie danych (RODO), art. 28 i 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679)
- [Rozporządzenie (UE) 2024/1689, akt w sprawie sztucznej inteligencji, art. 4, 26, 50 i 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689)
- [Rozporządzenie (UE) 2023/2854, akt w sprawie danych, rozdział VI o zmianie usług przetwarzania danych, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, protokół SCIM 2.0](https://www.rfc-editor.org/rfc/rfc7644) i [SAML 2.0 Core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Bezpłatny wzór wymagań przetargowych dla bramki LLM i platformy AI z https://standardcompute.com/opis-przedmiotu-zamowienia-bramka-llm (wersja z 9 listopada 2026 r.). Można swobodnie kopiować i edytować. Nie stanowi porady prawnej._