UE AI Act wszedł w życie w sierpniu 2024 roku, a jego przepisy są wprowadzane etapami w ciągu dwóch do trzech lat [1][2]. Do tej pory większość dyskusji na temat zgodności w przedsiębiorstwach koncentrowała się na tym, czy dany proces kwalifikuje się do kategorii „wysokiego ryzyka”. Do połowy 2026 roku rozmowa przesuwa się na bardziej praktyczne pytanie: biorąc pod uwagę, że proces jest objęty zakresem, które architektury wdrożeniowe faktycznie pozwalają spełnić obowiązki wdrożeniowca, a które z nich tego nie umożliwiają?

To drugie pytanie to moment, w którym wdrożenie on-premises przestaje być kwestią stylu, a staje się dopasowaniem strukturalnym.

Co Akt nakłada na wdrożeniowców systemów AI wysokiego ryzyka

Akt rozróżnia pomiędzy dostawcą systemu AI a wdrożeniowcem tego systemu [1]. Bank korzystający z zewnętrznego API LLM do oceny wniosków kredytowych jest wdrożeniowcem, a nie dostawcą. Wdrożeniowcy systemów wysokiego ryzyka mają obowiązki takie jak: zapewnienie nadzoru człowieka, monitorowanie działania systemu, przechowywanie logów przez odpowiedni okres, zawieszenie użycia, jeśli system zagraża podstawowym prawom, oraz wykazanie tych możliwości na żądanie.

Kilka z tych obowiązków jest prostych do spełnienia, gdy wdrożeniowiec kontroluje środowisko wykonawcze. Obowiązek „przechowywania logów przez odpowiedni okres” jest mechanicznie prosty, jeśli inferencja odbywa się na serwerze należącym do wdrożeniowca, a logi trafiają do SIEM wdrożeniowca. Obowiązek „zawieszenia użycia” jest równie trywialny, jeśli wdrożeniowiec może samodzielnie wyłączyć model na swojej infrastrukturze.

Te same obowiązki stają się trudniejsze, gdy inferencja odbywa się na chmurowym API LLM, którym wdrożeniowiec nie zarządza. Logi, które wdrożeniowiec może wygenerować, ograniczają się do tego, co udostępnia dostawca. Zawieszenie użycia wymaga współpracy dostawcy. Wykazanie na bieżąco, jakie dane przepływały przez system, wymaga zaufania do pipeline’u dostawcy.

Jak chmurowe API LLM wpisują się w regulacje

Żadne z powyższych nie sprawia, że chmurowe API LLM są niezgodne z przepisami. Artykuł po artykule, dostawcy i wdrażający AI hostowane w chmurze mogą spełnić obowiązki wynikające z Rozporządzenia. Tarcia mają charakter operacyjny, a nie prawny: wdrażający musi złożyć, przeprowadzić audyt i wykazać zgodność przekraczającą granicę dostawcy, często dla procesów wykonujących tysiące inferencji dziennie.

Indeks AI Stanford HAI śledził odpowiadającą zmianę w wydatkach przedsiębiorstw [3]: najszybszy wzrost w latach 2023–2025 nie dotyczył ogólnego generatywnego AI, lecz narzędzi wspierających — obserwowalności, zarządzania, rejestrowania promptów, klasyfikacji treści, wykrywania jailbreaków. Większość tych wydatków ma na celu zniwelowanie różnicy między tym, co natywnie udostępniają chmurowe API LLM, a tym, co wdrażający musi udokumentować w kontekście regulacyjnym.

Ta luka to strukturalna przewaga uruchamiania inferencji na sprzęcie należącym do wdrażającego. Każde pytanie „czy to się wydarzyło?” sprowadza się do pytania, na które wdrażający może odpowiedzieć na podstawie własnych logów.

Czego nie zapewnia ci on-prem za darmo

Trzy obowiązki wdrożeniowe wynikające z AI Act to nie automatycznie spełnione przez wdrożenie lokalne, warto je wymienić wprost:

  • Nadzór ludzki. Ustawa wymaga istotnego nadzoru nad systemami AI wysokiego ryzyka, z możliwością interpretacji wyników i interwencji przez człowieka. Uruchamianie modelu lokalnie nie oznacza obecności człowieka w procesie; decyduje o tym sposób zaprojektowania przepływu pracy.
  • Monitorowanie dryfu i niebezpiecznych zachowań. Wdrażający musi nieustannie monitorować system. Wdrożenie lokalne sprawia, że instalacje wodno-kanalizacyjne trywialne (dane są lokalne), ale polityka („jak wygląda dryf dla tego przepływu pracy?”) nadal musi zostać zdefiniowana.
  • Obowiązki dostawcy zostały przekazane dalej. Gdy wdrożenie on-prem opiera się na modelu zewnętrznego dostawcy (np. modelu open-weight na licencji niekomercyjnej lub modelu dostarczonym jako binarny przez dostawcę), wdrażający nadal musi ujawnić wymagane przez dostawcę informacje.

Strukturalną przewagą rozwiązań on-prem jest obsługa danych i możliwość ich wykazania, a nie polityka. Polityka musi być napisana i egzekwowana niezależnie od tego, gdzie znajduje się GPU.

Jak to się ma do USA, Wielkiej Brytanii i innych jurysdykcji

Rozporządzenie UE dotyczące sztucznej inteligencji jest najbardziej szczegółowe spośród głównych ram regulacyjnych. Amerykański NIST AI RMF [4] przyjmuje dobrowolne, oparte na ramach podejście, a Obserwatorium Polityki AI OECD [5] śledzi, jak rządy narodowe spoza UE zbliżają się do zasad ogólnie podobnych (nadzór oparty na ryzyku, obowiązki przejrzystości, zasady przetwarzania danych).

Dla międzynarodowego wdrożeniowca praktycznym skutkiem jest to, że to najsurowsza jurysdykcja determinuje architekturę. Jeśli przepływ pracy musi spełniać wymogi unijnej ustawy o AI dla użytkowników europejskich, ten sam przepływ nie naruszy wymagań USA, Wielkiej Brytanii, Japonii ani Singapuru, jeśli jest zaprojektowany zgodnie z unijnymi standardami. Projektowanie wdrożenia zgodnie z najsurowszymi wymogami — w tym zdolnością wdrożeniowca do udokumentowania obsługi danych na żądanie — sprawia, że rozwiązanie on-premises jest strukturalnie prostszym domyślnym wyborem w przedsiębiorczej AI w 2026 roku.

Jak wygląda wdrożenie AI on-premises gotowe na zgodność z przepisami 2026 roku

Kształt, który dostarczamy — i którego oczekują recenzenci zgodności, z którymi współpracujemy — to:

  • Wnioskowanie lokalne u klienta. Albo na urządzeniu użytkownika, albo na serwerze obsługiwanym przez klienta. Żadne zapytania nie opuszczają obszaru sieciowego.
  • Dzienniki audytu bez treści. Każde działanie administracyjne jest rejestrowane z oznaczeniem czasu i wykonawcy; w wierszu audytu nie pojawiają się zapytania ani odpowiedzi. Wiersz audytu stanowi dowód; treść pozostaje do przechowania przez wdrażającego zgodnie z jego własną polityką retencji.
  • Tożsamość przez IdP klienta. OIDC wobec Microsoft Entra ID lub Google Workspace, z zachowaniem istniejących kontroli dostępu wdrażającego bez zmian.
  • Brak dzierżawy wnioskowania obsługiwanej przez dostawcę. Software Tailor nie obsługuje środowiska uruchomieniowego modelu ani nie otrzymuje zapytań, odpowiedzi czy dokumentów klienta tą ścieżką. Tożsamość organizacji, licencjonowanie, polityka, stan serwera, agregowane użycie, zapisy audytu i wsparcie mogą nadal korzystać z płaszczyzny kontrolnej dostawcy i muszą być oceniane jako odrębne zależności.

Ostatnia cecha wnioskowania to coś, czego strukturalnie nie mogą odtworzyć chmurowe API dużych modeli językowych. Nie czyni to produktu on-premises automatycznie zgodnym ani nie eliminuje potrzeby oceny jego płaszczyzny kontrolnej, kanałów wsparcia, łańcucha dostaw modelu i obowiązków operacyjnych klienta.

Tło dotyczące tego, jak od początku budowaliśmy rozwiązanie wokół tego, znajduje się w Dlaczego dostarczamy AI jako instalowalne binaria, a nie chmurowe SaaS. Funkcje realizujące audyt, tożsamość i powierzchnię polityki znajdują się w AI Admin Console.

Bibliografia

  1. Komisja Europejska. „AI Act — Ramy regulacyjne dotyczące AI.” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Dostęp 2026-06-15.
  2. Komisja Europejska. „AI Act wchodzi w życie.” https://digital-strategy.ec.europa.eu/. Dostęp 2026-06-15.
  3. Stanford HAI. „Raport AI Index.” https://aiindex.stanford.edu/. Dostęp 2026-06-15.
  4. NIST. „AI Risk Management Framework (AI RMF 1.0).” https://www.nist.gov/itl/ai-risk-management-framework. Dostęp 2026-06-15.
  5. OECD AI Policy Observatory. „Krajowe polityki AI.” https://oecd.ai/. Dostęp 2026-06-15.