Dlaczego wdrożenia AI on-prem grzęzną na etapie zakupów (i ujęcie, które to rozwiązuje)

Do 2 grudnia 2027 r. obowiązki podmiotów stosujących wynikające z EU AI Act mają zastosowanie do systemów AI wysokiego ryzyka wykorzystywanych w biometrii, infrastrukturze krytycznej, edukacji, zatrudnieniu, migracji, azylu i kontroli granicznej ^[1]. Zespoły ds. zgodności w 2026 r. nie czekają z zajęciem pozycji do grudnia 2027 r. Już teraz tworzą kwestionariusze due diligence dla dostawców, a zakupy AI w przedsiębiorstwach grzęzną na tych kwestionariuszach w tempie, które ma niewiele wspólnego z samą zamawianą technologią. Rozwiązaniem nie jest lepsze demo. Rozwiązaniem jest zmiana ujęcia tego, czego w istocie dotyczy rozmowa zakupowa.

Jak naprawdę wygląda „impas” w 2026 r.

Techniczny proof-of-concept wypada pomyślnie. Model produkuje użyteczne wyniki na rzeczywistym obciążeniu klienta. Ewaluator techniczny pisze przychylną notatkę i przekazuje sprawę do zakupów. Następnie sprawa leży. Trzy tygodnie później zespół ds. zgodności klienta wraca z memorandum: „Nie jesteśmy w stanie wykazać naszych obowiązków podmiotu stosującego w tym procesie, jeśli wnioskowanie odbywa się na końcówce, której nie kontrolujemy”.

Badanie a16z dotyczące przedsiębiorstw zidentyfikowało kształt tego wzorca w chwili jego formowania się: cykle transakcyjne, które „kiedyś zajmowały ponad rok, są domykane w 2 lub 3 miesiące” w przypadku produktów spełniających nowe wymagania ^[4]. Implikacja działa też w drugą stronę. Zakupy produktów, które nie spełniają nowych wymagań, nadal trwają rok. Mocne piloty techniczne tego nie zmieniają.

Co zakupy w istocie muszą udowodnić

EU AI Act rozróżnia dostawcę systemu AI oraz podmiot stosujący ten system ^[1]. Bank korzystający z zewnętrznego API LLM do oceny wniosków kredytowych jest podmiotem stosującym. Do obowiązków podmiotu stosującego należą nadzór ludzki, monitorowanie, zgłaszanie incydentów oraz wykazywanie tych zdolności na żądanie. Obowiązki te dotyczą banku, a nie dostawcy LLM — i to zespół zakupowy banku stanowi powierzchnię, na której wybór dostawcy przesądza, czy obowiązki te będzie można praktycznie spełnić.

Kierunek ten nie jest wyłącznie unijny. NIST opublikował notę koncepcyjną dotyczącą profilu AI RMF dla godnej zaufania AI w infrastrukturze krytycznej w dniu 7 kwietnia 2026 r. ^[2], co stanowi pierwsze federalne ujęcie zakresu obowiązków podmiotów stosujących w ramach AI RMF dla operatorów infrastruktury krytycznej w Stanach Zjednoczonych. OECD AI Policy Observatory prowadzi żywe repozytorium „z ponad 80 jurysdykcji i organizacji” ^[3]. Konwergencja obowiązków po stronie podmiotu stosującego między jurysdykcjami to trend, a nie odstępstwo.

Zespoły zakupowe w regulowanych branżach odczytują te sygnały i pozycjonują się z wyprzedzeniem. Nie mogą czekać do 2 grudnia 2027 r., aby dowiedzieć się, czy architektura dostawcy pozwoli im spełnić ich obowiązki.

Dlaczego „mamy SOC 2” to niewłaściwa odpowiedź

Odpowiedź odwołująca się do kontroli po stronie dostawcy, która historycznie zamykała korporacyjne rozmowy zakupowe — SOC 2 Type II, ISO 27001, DPA zgodna z RODO — dotyczy kontroli po stronie dostawcy. Są one konieczne. Nie są jednak wystarczające w odniesieniu do nadchodzących obowiązków podmiotu stosującego.

Obowiązki podmiotu stosującego wymagają, aby podmiot ten wykazał, na żądanie, jakie dane przepłynęły przez system AI. Jest to pytanie o własne logi podmiotu stosującego, a nie dostawcy. Dostawca o czystym SOC 2, który przechowuje prompt i odpowiedź w zarządzanej chmurze, nie zlikwiduje tej luki, ponieważ leży ona po stronie podmiotu stosującego: nie może on okazać logu czegoś, czego nie widzi.

Na tym polega strukturalna rozbieżność, która zatrzymuje rozmowę zakupową. Zespół ds. zgodności pisze memorandum opisujące obowiązki podmiotu stosującego. Dostawca odpowiada certyfikatami po swojej stronie. Obie strony mijają się jak statki w nocy.

Ujęcie, które przełamuje impas

Trzy właściwości architektury wdrożeniowej, nazwane wprost na samym początku kwestionariusza dostawcy, znoszą impas:

1. Wnioskowanie lokalne wobec podmiotu stosującego. Albo na urządzeniu użytkownika, albo na serwerze, którym operuje podmiot stosujący. Prompty i odpowiedzi nigdy nie opuszczają perymetru podmiotu stosującego.
2. Logi audytowe bez treści, których właścicielem jest podmiot stosujący. Każde działanie administracyjne jest rejestrowane wraz ze znacznikiem czasu i aktorem, w SIEM podmiotu stosującego. W wierszu audytu nie pojawiają się żadne prompty ani odpowiedzi. Wiersz audytu stanowi dowód; treść pozostaje w gestii podmiotu stosującego i jest zachowywana zgodnie z jego własną polityką retencji.
3. Tożsamość przez IdP podmiotu stosującego. OIDC wobec Microsoft Entra ID lub Google Workspace. Istniejące kontrole dostępu i polityki SSO podmiotu stosującego obowiązują bez zmian.

Nie są to właściwości dostawcy do certyfikowania. Są to właściwości architektury wdrożeniowej do wyspecyfikowania. Z chwilą ujęcia kwestionariusza dostawcy w ich kategoriach memorandum zespołu ds. zgodności pisze się samo: każdemu obowiązkowi podmiotu stosującego odpowiada konkretna właściwość architektoniczna, na którą podmiot ten może wskazać.

Jak to wygląda w postaci, w której dostarczamy nasze produkty

AI Suite firmy Software Tailor jest dostarczany jako instalatory desktopowe komunikujące się z lokalnym procesem wnioskowania. AI Admin Console jest powierzchnią zarządczą, z której korzysta dział IT podmiotu stosującego, aby egzekwować politykę, zarządzać licencjami i prezentować audyt. Sześciu klientów z listy Fortune Global 500 z branż farmaceutycznej, finansowej, rządowej, prawniczej, obronnej i energetycznej wdrożyło rozwiązania o tym kształcie od 2007 r. (dotychczasowi klienci), a każdy z tych projektów przeszedł przez wersję powyższego ujęcia, zanim podpisano kontrakt.

Najszybszym sposobem, aby to skonkretyzować, jest przeprowadzenie ćwiczenia na rzeczywistym obciążeniu. Bezpłatny tygodniowy pilotaż umieszcza model na sprzęcie klienta, wiersz audytu w SIEM klienta i tożsamość w IdP klienta — w zakresie wystarczającym, aby zespół ds. zgodności mógł sporządzić memorandum w odniesieniu do obowiązków, które realnie go dotyczą.

Źródła

1. European Commission. „AI Act — Regulatory framework on AI.” digital-strategy.ec.europa.eu. Dostęp: 2026-06-03.
2. NIST. „AI Risk Management Framework.” nist.gov/itl/ai-risk-management-framework. Dostęp: 2026-06-03. Notę koncepcyjną dla infrastruktury krytycznej opublikowano 7 kwietnia 2026 r.
3. OECD AI Policy Observatory. „Policy Navigator dashboards.” oecd.ai/en/dashboards. Dostęp: 2026-06-03.
4. Andreessen Horowitz. „State of Generative AI in the Enterprise.” a16z.com/generative-ai-enterprise-2024. Opublikowano 21 marca 2024 r. Dostęp: 2026-06-03.

Powiązane artykuły

• Przesunięcie od cloud-first do residency-first w korporacyjnych zakupach AI
• OECD AI Policy Observatory: co zmieniło się w ciągu ostatnich 12 miesięcy
• Logi audytowe bez treści: jak dowodzimy, co zrobił model, nie przechowując promptów
• EU AI Act w 2026 r.: co wdrożenie on-prem zmienia w zakresie zgodności
• Dlaczego dostarczamy AI w postaci instalowalnych plików binarnych, a nie chmurowego SaaS
• Wszystkie artykuły →