Do 2 grudnia 2027 roku obowiązki wdrożeniowca zgodnie z unijnym Rozporządzeniem o AI dotyczą systemów AI wysokiego ryzyka stosowanych w biometrii, infrastrukturze krytycznej, edukacji, zatrudnieniu, migracji, azylu i kontroli granicznej [1]. Zespoły ds. zgodności w 2026 roku nie czekają do grudnia 2027, aby się przygotować. Już teraz tworzą kwestionariusze due diligence dla dostawców, a zakupy AI w przedsiębiorstwach zatrzymują się na tych kwestionariuszach w tempie, które ma bardzo niewiele wspólnego z technologią będącą przedmiotem zakupu. Rozwiązaniem nie jest lepsza prezentacja. To zmiana perspektywy, o czym tak naprawdę jest rozmowa o zakupie.

Jak w rzeczywistości wygląda „zatrzymanie” w 2026 roku

Techniczny proof-of-concept przechodzi pomyślnie. Model generuje użyteczne wyniki na własnym obciążeniu klienta. Oceniacz techniczny pisze pozytywną notatkę i przekazuje plik do działu zakupów. Potem plik leży. Po trzech tygodniach zespół ds. zgodności klienta wraca z notatką: „Nie możemy udokumentować naszych obowiązków wdrożeniowca dla tego przepływu pracy, jeśli inferencja odbywa się na punkcie końcowym, którego nie kontrolujemy.”

Badanie przedsiębiorstw a16z zidentyfikowało kształt tego wzorca w trakcie jego formowania: cykle transakcyjne, które „kiedyś trwały ponad rok, teraz są realizowane w 2 lub 3 miesiące” dla 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. Silne pilotaże techniczne tego nie zmieniają.

Co tak naprawdę jest wymagane do udokumentowania w procesie zakupowym

Unijne Rozporządzenie o AI rozróżnia dostawcę systemu AI oraz wdrożeniowca tego systemu [1]. Bank korzystający z API LLM strony trzeciej do oceny wniosków kredytowych jest wdrożeniowcem. Obowiązki wdrożeniowca obejmują nadzór ludzki, monitorowanie, raportowanie incydentów oraz wykazywanie tych zdolności na żądanie. Obowiązki te dotyczą banku, a nie dostawcy LLM — a zespół zakupowy banku jest miejscem, gdzie wybór dostawcy decyduje, czy obowiązki te można praktycznie spełnić.

Ten kierunek nie jest wyłącznie unijny. NIST opublikował 7 kwietnia 2026 roku notatkę koncepcyjną dotyczącą profilu AI RMF dla Zaufanej AI w Infrastrukturze Krytycznej [2], będącą pierwszym federalnym określeniem obowiązków wdrożeniowca AI RMF dla operatorów infrastruktury krytycznej w Stanach Zjednoczonych. Obserwatorium Polityki AI OECD prowadzi aktualizowane repozytorium „z ponad 80 jurysdykcji i organizacji” [3]. Konwergencja międzyjurysdykcyjna w zakresie obowiązków po stronie wdrożeniowca to trend, a nie wyjątek.

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

Dlaczego odpowiedź „jesteśmy SOC 2” jest błędna

Odpowiedź oparta na kontrolach dostawcy, która historycznie rozwiązywała rozmowy o zakupach w przedsiębiorstwach — SOC 2 Typ II, ISO 27001, DPA zgodne z RODO — dotyczy kontroli po stronie dostawcy. Są one konieczne. Nie są jednak wystarczające dla obowiązków wdrażającego, które obecnie się pojawiają.

Obowiązki wdrażającego wymagają, aby wdrażający na żądanie wykazał, jakie dane przepłynęły przez system AI. To pytanie dotyczy własnych logów wdrażającego, a nie dostawcy. Dostawca z certyfikatem SOC-2, który przechowuje prompt i odpowiedź w zarządzanej chmurze, nie może zamknąć tej luki, ponieważ luka znajduje się po stronie wdrażającego: wdrażający nie może wygenerować logu czegoś, czego nie widzi.

To jest strukturalna niezgodność, która blokuje rozmowy zakupowe. Zespół ds. zgodności pisze notatkę przeciwko obowiązkom wdrażającego. Dostawca odpowiada certyfikatami po swojej stronie. Dwa statki mijają się bez kontaktu.

Ramka, która rozwiązuje zablokowanie

Trzy właściwości architektury wdrożenia, wymienione z góry w kwestionariuszu dostawcy, niwelują zablokowanie:

  1. Wnioskowanie lokalne u wdrażającego. Albo na urządzeniu użytkownika, albo na serwerze obsługiwanym przez wdrażającego. Prompty i odpowiedzi nigdy nie opuszczają perymetru wdrażającego.
  2. Bezpłatne logi audytowe, które należą do wdrażającego. Każda akcja administracyjna jest logowana z oznaczeniem czasu i wykonawcy, w SIEM wdrażającego. Wiersz audytu nie zawiera promptów ani odpowiedzi. Wiersz jest dowodem; treść pozostaje do przechowania według własnej polityki retencji wdrażającego.
  3. Tożsamość przez IdP wdrażającego. OIDC wobec Microsoft Entra ID lub Google Workspace. Istniejące kontrole dostępu i polityki SSO wdrażającego pozostają bez zmian.

To nie są właściwości dostawcy do certyfikacji. To właściwości architektury wdrożenia do określenia. Gdy kwestionariusz dostawcy jest sformułowany w oparciu o nie, notatka zgodności pisze się sama: każdy obowiązek wdrażającego ma odpowiadającą mu właściwość architektoniczną, na którą wdrażający może wskazać.

Jak to wygląda w kształcie, który dostarczamy

AI Suite od Software Tailor jest dostarczany jako instalatory desktopowe komunikujące się z lokalnym procesem wnioskowania. AI Admin Console to powierzchnia zarządzania, której używa zespół IT wdrażającego do egzekwowania polityk, zarządzania licencjami i udostępniania audytu. Sześciu klientów z listy Fortune Global 500 z branż farmaceutycznej, finansowej, rządowej, prawnej, obronnej i energetycznej wdrożyło ten kształt od 2007 roku (poprzedni klienci), a każde z tych wdrożeń przeszło przez wersję powyższej ramy przed podpisaniem umowy.

Najszybszym sposobem, by to zobrazować, jest przejście przez to na rzeczywistym obciążeniu. Bezpłatny, tygodniowy pilotaż umieszcza model na sprzęcie klienta, wiersz audytu w SIEM klienta oraz tożsamość przez IdP klienta — wystarczająco, by zespół ds. zgodności mógł napisać notatkę przeciwko obowiązkom, z którymi faktycznie się mierzą.

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-03.
  2. NIST. „AI Risk Management Framework.” https://www.nist.gov/itl/ai-risk-management-framework. Dostęp 2026-06-03. Notatka koncepcyjna dotycząca Infrastruktury Krytycznej została opublikowana 7 kwietnia 2026.
  3. OECD AI Policy Observatory. „Policy Navigator dashboards.” https://oecd.ai/en/dashboards. Dostęp 2026-06-03.
  4. Andreessen Horowitz. „State of Generative AI in the Enterprise.” https://a16z.com/generative-ai-enterprise-2024/. Opublikowano 21 marca 2024. Dostęp 2026-06-03.