Krakowskie Miquido przejrzało zapytania ofertowe z drugiego kwartału i wymóg zgodności z AI Act znalazło w jednym na dziesięć. Wszystkie pochodziły z rynku polskiego, żadne z innego kraju Unii.
Kluczowe fakty:
- Krakowska firma Miquido sprawdziła zapytania ofertowe z drugiego kwartału i wymóg zgodności z AI Act znalazła tylko w jednym na dziesięć – wszystkie takie zapytania pochodziły wyłącznie z polskiego rynku.
- Od 2 sierpnia obowiązują wymogi przejrzystości z artykułu 50 AI Act, obejmujące m.in. oznaczanie treści generowanych przez AI i informowanie użytkowników o rozmowie z chatbotem – za naruszenie grozi kara do 15 mln euro lub 3% obrotu.
- Zgodnie z rozporządzeniem obowiązek spełnienia wymogów spoczywa na kliencie wprowadzającym produkt na rynek, jednak techniczna możliwość ich realizacji leży po stronie firmy budującej system – jeśli odpowiednie mechanizmy nie zostaną wbudowane w architekturę, klient może naruszać przepisy mimo braku bezpośredniego wpływu na rozwiązanie.
Od 2 sierpnia obowiązują wymogi przejrzystości z artykułu 50 unijnego rozporządzenia: oznaczanie treści generowanych przez sztuczną inteligencję, informowanie o rozmowie z chatbotem, ujawnianie deepfake’ów i systemów rozpoznających emocje. Za naruszenie grozi do 15 mln euro albo 3 procent obrotu. Tyle teorii. W praktyce między firmą, która zamawia system, a firmą, która go buduje, leży pytanie, na które przepisy odpowiadają wprost, a rynek wciąż nie.
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Odpowiada ten, kto wprowadza produkt na rynek, ale zrobić to musi ktoś inny
Piotr Polus, Head of Technology w Miquido, ujmuje to jednym zdaniem: „obowiązek jest po stronie klienta, ale techniczna możliwość jego spełnienia po naszej”.
Logika jest prosta. Firma informatyczna zwykle występuje jako wykonawca, a nie dostawca systemu AI w rozumieniu rozporządzenia. Rozwiązanie trafia na rynek pod marką klienta, więc to klient odpowiada za obowiązki z artykułu 50. Wyjątkiem w przypadku Miquido jest własny projekt otwartoźródłowy, framework Draive, przy czym on sam systemem AI nie jest, bo niczego nie wnioskuje, tylko organizuje pracę modeli.
Problem zaczyna się poziom niżej. „Jeśli ujawnienie, że «rozmawiasz z AI» nie jest wbudowane w architekturę, a system po drodze zgubi metadane o pochodzeniu treści, klient nie będzie działał zgodnie z przepisami” – mówi Polus. Klient dostaje karę, wykonawca dostaje reklamację. Kolejność jest odwrotna do tego, kto miał realny wpływ na to, czy komunikat w ogóle da się wyświetlić.
Jeden wymóg jest banalny, drugi trzeba zaplanować przy projektowaniu bazy danych
Polus sprowadza artykuł 50 do dwóch rzeczy: audytowalności i informowania o użyciu AI. Ta druga bywa zmianą na kilka godzin pracy, bo w wielu przypadkach wystarczy statyczny komunikat w interfejsie. Pierwsza jest decyzją podejmowaną na starcie projektu, przy projektowaniu schematu bazy.
Ciekawe jest uzasadnienie, dla którego Miquido logowało zdarzenia jeszcze zanim ktokolwiek mówił o karach. Rozwiązania oparte na dużych modelach językowych są nieprzewidywalne, ten sam prompt raz daje lepszą, raz gorszą odpowiedź, a testować ich nie da się jak zwykłego kodu. Jedyny sposób pracy nad jakością to zapisywać wszystko, żeby mieć do czego wrócić. Regulacja wymaga w zasadzie tego samego.
W nowych projektach zespół sprawdza to na etapie odkrywania potrzeb, przed zbudowaniem architektury. Wystarczają trzy pytania:
- czy system zapisuje zdarzenia w sposób pozwalający je później odtworzyć
- czy człowiek ma w procesie realny moment na podjęcie decyzji, a nie tylko przycisk do zatwierdzania
- czy informacja o użyciu AI jest częścią sesji, a nie elementem dorysowanym w interfejsie na końcu
W starszych, działających systemach Miquido idzie po kolei: sprawdza, co faktycznie zapisują, i dokłada brakujące elementy. Na wymogi dla systemów wysokiego ryzyka czasu jest więcej, bo grudzień 2027 albo sierpień 2028, zależnie od kategorii.
Podoba mi się w tej wypowiedzi jedna rzecz, której nie usłyszę od prawnika: że najtrudniejszą część tego przepisu wiele zespołów miało zrobioną z powodów czysto inżynierskich, na długo przed AI Act. Logowanie zdarzeń nie powstało po to, żeby zadowolić regulatora, tylko dlatego, że bez niego nie da się poprawiać jakości modelu. To najlepszy argument przeciwko tezie, że rozporządzenie jest oderwane od praktyki.
Mam jednak wątpliwość co do samego układu odpowiedzialności. Jeśli obowiązek leży po stronie klienta, a możliwość jego spełnienia po stronie wykonawcy, to w umowie musi znaleźć się zapis, który to spina. Inaczej mamy sytuację, w której karę płaci podmiot bez wpływu na architekturę, a firma, która tę architekturę zaprojektowała, wychodzi z tego bez konsekwencji. Zapytam wprost: ile polskich umów na budowę systemu z chatbotem ma dziś taki zapis? Podejrzewam, że niewiele, i to jest realne ryzyko, a nie sam artykuł 50.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Opisz krótko, czego potrzebujesz. Jesteśmy największym HUB-em AI w Polsce — w naszej bazie znajdziesz blisko 500 zweryfikowanych firm specjalizujących się w AI. W Twoim imieniu poprosimy 3-5 dopasowanych wykonawców o kontakt w ciągu 48 godzin.
Nieobecność w briefie nie znaczy, że klienta to nie obchodzi
Wynik z zapytań ofertowych brzmi alarmująco tylko przy pobieżnym czytaniu. Polus sam go studzi, zaznaczając, że to obserwacja z jednego kwartału, a nie badanie rynku. Jego interpretacja dotyczy procesu zakupowego, nie świadomości.
Zapytania ofertowe piszą działy produktu albo działy zakupów. Prawnicy praktycznie nigdy ich nie przygotowują. Wymóg zgodności pojawia się później, przy badaniu due diligence, przy negocjowaniu umowy, przy ankiecie bezpieczeństwa. „Podejrzewam, że powtórzy się schemat znany z RODO: w 2016 nikt nie pytał o zgodność z RODO, a w 2019 pytali wszyscy” – ocenia Polus. Zmiana wtedy nie wzięła się z samego rozporządzenia, tylko z przepisania szablonów umów i ankiet zakupowych.
Osobna obserwacja dotyczy tego, że w branży nie widać prób obchodzenia przepisów. „Unijne przepisy nie krępują. Są sensowne i często już dawno zaimplementowane” – mówi Polus. Za zgodność odpowiada u nich zespół produktowy, nie wydzielona rola. AI Act, w odróżnieniu od RODO z inspektorem ochrony danych, nowego stanowiska nie wymaga, bo artykuł 4 i artykuł 26 ustęp 2 stawiają wymogi kompetencyjne wobec ludzi wykonujących pracę, a nie wobec działu.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Najmniej gotowe są sklepy i rozrywka, czyli najwięksi użytkownicy generatywnego AI
Z perspektywy wykonawcy widać, gdzie jest największa dziura. Polus wskazuje część handlu internetowego i branżę rozrywkową, bo te sięgają po generatywne AI najczęściej: chatboty, generowane opisy i zdjęcia produktów, syntetyczne głosy w reklamach, wirtualni influencerzy. Każde z tych zastosowań łapie się na artykuł 50 od 2 sierpnia.
Skala problemu jest mierzalna. Z lipcowego „Szybkiego Monitoringu” NBP wynika, że w drugim kwartale narzędzia AI stosowało 42 procent polskich firm, wobec 14 procent pod koniec 2024 roku. Wśród dużych przedsiębiorstw to 59 procent. Świadomość regulacyjna nie nadąża: w badaniu Centralnego Ośrodka Informatyki na próbie 229 firm o AI Act słyszało 86 procent, ale wiedza była pobieżna i pochodziła głównie z mediów społecznościowych.
Nadzoru wciąż nie ma. Ustawa o systemach sztucznej inteligencji, podpisana przez prezydenta Karola Nawrockiego 24 lipca, weszła w życie 11 sierpnia. Przewodniczący Komisji Rozwoju i Bezpieczeństwa Sztucznej Inteligencji ma zostać powołany w październiku, cała komisja w listopadzie. Piaskownica regulacyjna, o której pisałem w poniedziałek przy okazji naboru CPPC na 35 mln zł, dostała od Brukseli dodatkowy rok, do 2 sierpnia 2027. Obowiązki z artykułu 50 żadnego przesunięcia nie dostały i obowiązują od 2 sierpnia.
Czyli firmy podlegają przepisom, kary są zapisane, a instytucji, która mogłaby je nałożyć, jeszcze nie ma. Nie wiadomo też, czy KRiBSI będzie mogła sięgnąć wstecz do okresu przejściowego. Dla dyrektora finansowego to argument, żeby poczekać. Dla zespołu produktowego, który i tak musi zaprojektować bazę danych, żaden.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz materiału prasowego Miquido z dnia 12.08.2026, przekazanego redakcji, z którego pochodzą wszystkie wypowiedzi Piotra Polusa, Head of Technology w Miquido. Harmonogram powołania KRiBSI podano za komunikatem Ministerstwa Cyfryzacji. Wykorzystano również dane „Szybkiego Monitoringu” NBP z lipca 2026, raport Centralnego Ośrodka Informatyki „Piaskownice regulacyjne w obszarze AI” z kwietnia 2026 przygotowany dla Ministerstwa Cyfryzacji, a także wcześniejsze ustalenia redakcji dotyczące rozporządzenia 2026/1744 i naboru CPPC. Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. Artykuł będzie aktualizowany w miarę powoływania KRiBSI i pojawiania się pierwszych rozstrzygnięć dotyczących artykułu 50.
