EU AI Act jako przewodnik wdrożeniowy: klasyfikacja ról, ocena ryzyka i plan zgodności dla firm

Masz w firmie choć jeden proces z AI i zastanawiasz się, czy EU AI Act to „tylko papier”, czy realne obowiązki? Zrób 60‑sekundowy test: 1) Czy Twoje rozwiązanie podejmuje decyzje o ludziach (np. rekrutacja, scoring, medycyna)? 2) Czy sprzedajesz produkt z AI, czy tylko go używasz? 3) Skąd pochodzą ai models — własne, dostawcy, open source? 4) Czy ktoś nadzoruje wynik (człowiek w pętli)? 5) Czy masz ślad decyzji i dane do audytu?

Większość firm myli „używam AI” z „dostarczam system AI” — a to rozdziela role i ryzyko kar. W AI w Biznesie przekładamy AI Act na wdrożenie: checklista provider vs deployer, mapa obowiązków dla systemów AI wysokiego ryzyka oraz zasady dla general-purpose ai w punktach.

Za chwilę rozpisujemy to krok po kroku, bez prawniczego dymu i bez zgadywania.

Czym jest rozporządzenie o AI i co zmienia dla firm

Zróbmy 60‑sekundowy test. Odpowiedz „tak/nie” na 5 pytań: (1) Czy Twój produkt lub proces zawiera ai system albo kilka ai systems? (2) Czy to Ty je tworzysz/markujesz jako swoje, czy tylko je wdrażasz? (3) Czy to generative ai lub general-purpose ai, które zasila różne przypadki użycia? (4) Czy wynik wpływa na decyzje wobec ludzi (np. rekrutacja, kredyt, edukacja)? (5) Czy rozwiązanie jest used w UE i dotyka wrażliwych obszarów, w tym democratic processes?

EU AI Act (często skracany jako AI Act; formalnie bywa opisywany jako artificial intelligence act) to rozporządzenie, czyli prawo stosowane wprost — bez czekania, aż państwo „przepisze je” do krajowych ustaw jak przy dyrektywie. Klucz: to nie jest regulacja technologii „AI jako takiej”, tylko regulacja ryzyka. Liczy się, co może pójść nie tak i jaki jest wpływ na użytkownika, a nie to, jakim algorytmem to zrobisz.

Najczęstsza pomyłka w firmach brzmi: „używam AI, więc jestem bezpieczny”. Natomiast obowiązki zależą od roli w łańcuchu: czy jesteś dostawcą, wdrażającym, czy importerem. Inne wymagania mają providers of high-risk ai i organizacje, które tylko „zapuszczają roboty” na swoich danych. W kolejnych częściach pokażę, jak szybko to rozpoznać i co z tego wynika.

„EU AI Act to nie tylko obowiązki compliance — to mapa drogowa, jak projektować i wdrażać AI w sposób bezpieczny, audytowalny i zgodny z prawami użytkowników. Firmy, które już teraz uporządkują klasyfikację ryzyka, dokumentację modeli i nadzór nad danymi, zyskają przewagę: szybciej wprowadzą rozwiązania na rynek i zmniejszą ryzyko kosztownych incydentów.” — Anna Kowalska, Konsultantka ds. AI Governance, AI w Biznesie

Co realnie zmienia ten akt (act) w codziennej pracy? Po pierwsze, pojawia się podział na high-risk ai oraz high-risk ai systems (tam wchodzą twarde obowiązki: dokumentacja, system zarządzania jakością, nadzór człowieka). Po drugie, są prohibited ai practices, których nie „opłaca się ryzykować”. Po trzecie, osobno uregulowano general-purpose ai models i providers of general-purpose ai — tu w grę wchodzą m.in. informacje o trenowaniu i ograniczeniach ai models. Nad interpretacją i egzekwowaniem ma czuwać także ai office.

• Najpierw: ustal rolę (dostawca/wdrażający/importer) i listę ai systems used.
• Potem: klasyfikacja ryzyka (czy to high-risk ai).
• Na końcu: ułóż ai governance i plan artefaktów pod audyt.

Jak szybko ustalić rolę: dostawca, wdrażający, importer czy dystrybutor

W EU AI Act pierwsza rzecz do ogarnięcia to nie „czy mamy AI”, tylko jaką mamy rolę w łańcuchu. Ta rola ustawia obowiązki: inne ma dostawca, inne firma, która tylko zapuszcza roboty w procesie, a jeszcze inne podmiot, który sprowadza lub odsprzedaje rozwiązanie. Da się to rozpoznać w 10 minut, checklistą tak/nie.

1. Czy sprzedajesz lub udostępniasz klientom własny produkt oparty o uczenie maszynowe (np. usługa w chmurze, aplikacja)?
2. Czy Twoja marka widnieje na umowie/ofercie jako „to my dostarczamy rozwiązanie”?
3. Czy modyfikujesz model (dostrajanie, dodatkowe dane, zmiana sposobu działania), a nie tylko konfigurujesz ekran i uprawnienia?
4. Czy sprowadzasz narzędzie spoza UE i wprowadzasz je na rynek pod swoją nazwą lub w swoim pakiecie?
5. Czy odsprzedajesz gotowe narzędzie bez zmian (licencja, marketplace), działając jak pośrednik?
6. Czy Twoja organizacja odpowiada za to, jak rozwiązanie działa w procesie (zasady, dane wejściowe, akceptacja decyzji)?
7. Czy lista ai systems used obejmuje obszary wrażliwe, gdzie łatwo wpaść w high-risk ai (np. HR, kredyty, edukacja)?

Przykład 1 (HR): firma wdraża narzędzie do selekcji CV. Najczęściej jest wdrażającym: odpowiada za sposób użycia w rekrutacji, testy pod kątem dyskryminacji i kontrolę procesu.

Przykład 2 (własny produkt): software house sprzedaje klientom własną usługę generującą treści (to, co potocznie nazywa się generative ai). Tu zwykle jesteś dostawcą, a przy rozwiązaniach typu „AI ogólnego przeznaczenia” dochodzą dodatkowe obowiązki z AI Act.

Na koniec zbierz trzy artefakty (bez tego audyt z EU AI Act będzie bolał):

• Rejestr systemów (lista ai systems used + dostawca, lokalizacja, integracje).
• Opis przypadków użycia: cel, dane, decyzje, człowiek w pętli.
• Właściciele biznesowi: kto podpisuje ryzyko i kto utrzymuje proces.

Systemy AI wysokiego ryzyka: obowiązki dostawców i mapa zgodności

W praktyce „wysokie ryzyko” nie oznacza, że technologia jest zła. Oznacza, że ląduje w procesie, gdzie błąd kosztuje człowieka realnie: dostęp do pracy, kredytu, edukacji, świadczeń, zdrowia albo bezpieczeństwa. EU AI Act (to rozporządzenie, czasem skracane jako act) patrzy więc na kontekst użycia, nie na „spryt” algorytmu. Typowy scenariusz: narzędzie wspiera decyzję, która ma skutki prawne lub podobnie istotne — i wtedy organizacja może wpaść w reżim high-risk ai.

Żeby nie przepisywać załączników, trzy szybkie filtry: (1) czy system jest elementem krytycznego procesu (rekrutacja, ocena zdolności kredytowej, triage w ochronie zdrowia, infrastruktura), (2) czy wynik prowadzi do decyzji o człowieku, (3) czy skala jest masowa albo zautomatyzowana. Jeśli dwa z trzech są „tak”, to traktuj temat jak high-risk ai systems i planuj prace zgodności.

Mapa obowiązków po stronie dostawcy (providers of high-risk ai) jest do ogarnięcia, tylko trzeba ją „spiąć w jeden system”:

• Dokumentacja techniczna: opis funkcji, ograniczeń, danych, metryk, logiki działania oraz instrukcje dla klienta. Uwaga: jeśli w środku siedzą ai models dostarczane z zewnątrz, musisz opisać zależności i ryzyka łańcucha dostaw.
• QMS (zarządzanie jakością): procedury zmian, wersjonowania, obsługi incydentów, oceny dostawców, ścieżki akceptacji ryzyka.
• Dane i testy: kontrola jakości danych, testy pod kątem błędów i stronniczości, scenariusze brzegowe, testy odporności.
• Nadzór człowieka: jasno zdefiniowane „człowiek w pętli”, kiedy można przerwać działanie i jak eskalować.
• Monitoring po wdrożeniu: logi, wskaźniki dryfu, plan reagowania i raportowania incydentów.

Po stronie wdrażającego (deployer) ważne są klocki operacyjne: lokalna ocena ryzyka, szkolenia użytkowników, konfiguracja progów i uprawnień, plus dowód, że system działa w Twoim procesie tak, jak deklaruje dostawca. To też moment na przegląd, czy gdzieś obok nie zahaczacie o prohibited ai practices. Jeśli korzystasz z komponentów typu AI ogólnego przeznaczenia, pamiętaj: dostawcy takich rozwiązań (providers of general-purpose ai) mają swoje obowiązki, natomiast Ty nadal odpowiadasz za bezpieczne osadzenie tego w procesie. I drobiazg: jeden spójny rejestr zmian oraz logów dla ai system oszczędza tygodnie w audycie.

Praktyki zakazane i ochrona procesów demokratycznych w użyciu AI

W EU AI Act najprościej myśleć o zakazach jak o „czerwonych flagach”: jeśli je widzisz w produkcie, procesie lub kampanii, nie dyskutujesz o optymalizacji — tylko zatrzymujesz temat. W dokumentach spotkasz skrót act, natomiast sens jest biznesowo prosty: są scenariusze, których nie wolno wdrażać, nawet jeśli „działają” sprzedażowo.

Poniżej szybka lista, co najczęściej wpada w kategorię prohibited ai practices i jak to rozpoznać po symptomach, nie po definicjach:

• Manipulacja i „pchnięcie” użytkownika – projektowanie komunikatów tak, by omijały świadomą decyzję (np. ukryte bodźce, presja emocjonalna na wrażliwe grupy).
• Profilowanie prowadzące do krzywdy – segmentacja, która realnie ogranicza dostęp do usług lub tworzy nieuzasadnione różnice cenowe/warunki (szukaj: brak uzasadnienia biznesowego i brak możliwości odwołania).
• Niedozwolona biometryka – identyfikacja lub kategoryzacja osób po cechach biometrycznych „hurtowo”, bez twardej podstawy prawnej i kontroli celu.

Wątek ochrony procesów demokratycznych (bez wielkich słów): jeśli tworzysz treści syntetyczne, reklamy społeczne albo polityczne, zakładaj ryzyko dezinformacji. Dobre minimum to: jasne oznaczanie treści syntetycznych, archiwum kreacji i grup docelowych, oraz kontrola źródeł danych, na których pracują modele (ai models), w tym komponenty typu general-purpose ai models. Przy kampaniach wrażliwych trzymaj checklistę zgodności z AI Act i uzgodniony tryb eskalacji.

Procedura stop-klatki: prawo wstrzymania wdrożenia ma właściciel produktu lub procesu, specjalista ds. bezpieczeństwa oraz prawnik/inspektor zgodności. Jeśli którykolwiek oznaczy scenariusz jako zakazany — wdrożenie staje, a decyzja wraca dopiero po pisemnej ocenie ryzyka i akceptacji zarządu.

AI ogólnego przeznaczenia i modele AI: zasady dla dostawców i progi

Jeśli sprzedajesz „klocek”, który inni dopiero wpinają do swojego produktu, to właśnie tu pojawia się największe pole do poprawy. EU AI Act rozdziela obowiązki dla narzędzi ogólnego zastosowania i dla samych modeli — czyli tego, co faktycznie „niesie” możliwości. W praktyce: nie wystarczy powiedzieć „to tylko silnik”; trzeba dać integratorom instrukcję bezpiecznego montażu.

Dla general-purpose ai (czyli narzędzi, które da się wykorzystać w wielu kontekstach) kluczowe są trzy rzeczy: dokumentacja, informacja dla integratorów i zarządzanie ryzykiem. Wymogi z AI Act (sam act w skrócie) nie są po to, żeby utrudniać życie, tylko żeby każdy w łańcuchu wiedział, co jest w środku i gdzie są granice odpowiedzialności.

• Dokumentacja techniczna: co model potrafi, na jakich danych był przygotowany w sensie kategorii źródeł, znane ograniczenia i typowe błędy.
• Informacje dla integratorów: jak dobrać ustawienia, jak monitorować jakość, jak wykrywać nadużycia, co logować i jak reagować na incydent.
• Polityki bezpieczeństwa i ryzyka: testy przed wydaniem, procedury poprawek, kanał do zgłaszania problemów, wersjonowanie i „co się zmieniło” między wydaniami.

Rozdzielmy przypadki. Zwykłe ai models ogólnego przeznaczenia mają obowiązki „higieniczne” (powyżej). Natomiast general-purpose ai models o „systemowym” wpływie (czyli takie, które mogą realnie oddziaływać na rynek i bezpieczeństwo przez skalę i możliwości) wchodzą poziom wyżej: bardziej rygorystyczne testy, mocniejsza dokumentacja i twardsze zarządzanie ryzykiem. Przykład: model, który zasila setki aplikacji i potrafi generować instrukcje działań technicznych — to już nie jest mały dodatek, tylko infrastruktura.

Wątek treści generowanych przez model jest prosty do spięcia z procesami produktowymi: oznaczanie materiałów (żeby użytkownik wiedział, co powstało automatycznie), streszczenie ryzyk w karcie produktu oraz checklisty w cyklu wydawniczym. W praktyce działa to jak „kokpit wiedzy”: jeden dashboard z dokumentacją, testami, decyzjami o ryzyku i historią zmian, gotowy do pokazania przy audycie — czy to pod kątem artificial intelligence act, czy pytań od klientów. Jeśli w łańcuchu pojawia się ai office, łatwiej przejść kontrolę, gdy te klocki są poukładane od początku.

Open-source, AI governance i rola AI Office w egzekwowaniu przepisów

Open-source w kontekście EU AI Act jest jak darmowy klocek z klocków: możesz go wziąć, natomiast gdy zaczniesz z niego budować produkt, nagle dochodzą instrukcje bezpieczeństwa. W praktyce wyjątki działają głównie wtedy, gdy udostępniasz komponenty „as is”, bez monetyzacji i bez oferowania usługi wokół nich. Obowiązki wracają w momencie, gdy robisz komercjalizację, integrujesz to w platformie klienta albo sprzedajesz wsparcie jako usługę — wtedy przestajesz być tylko „publikującym kod”, a zaczynasz odpowiadać za to, co dowozisz.

To szczególnie ważne przy rozwiązaniach typu general-purpose ai oraz przy „general-purpose ai models”: nawet jeśli bazujesz na otwartym modelu, to fine-tuning, dobór danych, filtry bezpieczeństwa i sposób wdrożenia potrafią zmienić profil ryzyka. Wtedy nie wystarczy link do repozytorium — trzeba umieć pokazać, jak kontrolujesz skutki uboczne.

Minimalny model governance (bez nadęcia) to kilka klocków, które da się spiąć w jeden system:

• właściciel ryzyka (po stronie biznesu) i opiekun techniczny (po stronie zespołu wdrożeniowego),
• komitet do decyzji „wchodzimy/nie wchodzimy” w wątpliwe zastosowania,
• rejestr systemów (co działa, gdzie, na jakich danych, kto zatwierdził),
• procedura oceny: testy, kryteria akceptacji, plan monitoringu,
• audytowalność: ślady decyzji, wersjonowanie, karta zmian, żeby to obronić przy kontroli.

Jeśli w ekosystemie pojawia się high-risk ai systems albo wchodzisz w high-risk ai, te klocki przestają być „ładnym dodatkiem” — stają się warunkiem przejścia przez pytania klientów i regulatora.

AI Office to jednostka koordynująca egzekwowanie aktu (act) na poziomie UE: będzie wydawać wytyczne, wspierać spójne interpretacje i patrzeć na najbardziej wpływowe modele oraz praktyki rynkowe. Jak to śledzić, żeby nie obudzić się z ręką w nocniku? Ustal jedną osobę, która raz w miesiącu robi przegląd komunikatów AI Office, aktualizacji wytycznych oraz listy pytań i odpowiedzi do artificial intelligence act, a potem zamienia to na konkret: zmiany w rejestrze, testach i dokumentacji. To jest 85–90% roboty, która realnie chroni firmę.

Plan wdrożenia EU AI Act w firmie: artefakty, właściciele i terminy (30–60–90 dni)

Najczęstszy błąd? Zaczynanie od „czy nas to dotyczy”, zamiast od „gdzie to już działa w procesach”. Ten act da się ogarnąć bez paniki, jeśli potraktujesz go jak projekt operacyjny: inwentaryzacja → ryzyko → kontrolki → szkolenia. I tyle. Poniżej masz plan 30–60–90 dni, który domyka temat w sposób praktyczny, niezależnie od tego, czy masz własny ai system, czy korzystasz z narzędzi dostawców.

1. 0–30 dni (mapowanie i właściciele)
   • Produkt/IT: spina listę narzędzi i integracji (ekosystem narzędzi, „klocki”, dane wejścia/wyjścia).
   • Dane: wskazuje źródła danych, podstawy przetwarzania, retencję.
   • Prawnik: ustala role i minimalny zestaw obowiązków, aktualizuje klauzule.
   • Zakup: robi przegląd umów i polityki dostawców.
2. 31–60 dni (ryzyko i kontrolki)
   • Bezpieczeństwo: testy podatności, kontrola dostępu, logowanie zdarzeń.
   • Produkt: plan testów i kryteria akceptacji, w tym scenariusze błędów.
   • Operacje/linie biznesowe: procedury nadzoru człowieka (kto zatwierdza, kiedy, na jakiej podstawie).
3. 61–90 dni (wdrożenie, szkolenie, audytowalność)
   • HR: szkolenia ról, krótkie instrukcje „co wolno / czego nie wolno”.
   • Prawnik + bezpieczeństwo: wewnętrzny przegląd zgodności i poprawki.
   • Właściciel biznesowy: dashboard (kokpit wiedzy) z rejestrem i statusem ryzyk.

Artefakty, które warto wytworzyć (konkret, nie prezentacja):

• Rejestr przypadków użycia (po co, gdzie, kto odpowiada, dane, dostawca).
• Ocena ryzyka i decyzje o kontrolkach.
• Polityki dostawców (wymagania, ankieta, ścieżka akceptacji).
• Plan testów (jakość, bezpieczeństwo, odporność na nadużycia).
• Procedury nadzoru człowieka (eskalacje, progi, dokumentowanie decyzji).
• Materiał szkoleniowy dla zespołów + krótkie testy wiedzy.

Mini-FAQ

• Czy akt już obowiązuje i kiedy wchodzą obowiązki? Tak, rozporządzenie obowiązuje, natomiast obowiązki wchodzą etapami. Dlatego plan 30–60–90 dni ma sens: budujesz fundamenty, które potem tylko dopasowujesz do kolejnych terminów i wytycznych do artificial intelligence act.
• Czy to „zastępuje” strategie krajowe? Nie zastępuje. Natomiast porządkuje wymagania prawne w UE i ułatwia spięcie ich w jeden system compliance, także dla modeli (ai models) i rozwiązań typu general-purpose ai.

Jeśli chcesz to zrobić bez przeciągania liny między działami: wyślij nam rejestr przypadków użycia (nawet 70% kompletny). Resztę pomożemy dopiąć w logiczną mapę obowiązków i plan wdrożenia.

EU AI Act nie jest „kolejnym papierem do odhaczenia” — to instrukcja, jak bezpiecznie zapuścić AI w firmie, wiedząc kto za co odpowiada i jakie klocki zgodności muszą się spiąć w jeden system.

W artykule pokazaliśmy praktyczny tor: szybkie ustalenie roli (dostawca vs wdrażający), mapę obowiązków dla systemów wysokiego ryzyka (dokumentacja, QMS, nadzór człowieka) oraz zasady dla general-purpose ai i tego, kiedy ai models wpadają w dodatkowe progi wymagań.

AI w Biznesie ogarnia ten temat end-to-end: od audytu użyć i content gap w dokumentach, przez „kokpit wiedzy” dla zespołu, po plan wdrożenia z właścicielami i terminami — bez udawania, że da się to zrobić w weekend.

Jeśli chcesz mieć jasną listę działań i ryzyk pod Twoje konkretne przypadki użycia, umów konsultację z AI w Biznesie — przejdziemy checklistę i ustawimy realistyczny plan zgodności.

Najczęściej zadawane pytania

Czy EU AI Act już obowiązuje i kiedy realnie wchodzą obowiązki (oś czasu 2024–2026)?

Tak — EU AI Act wszedł w życie, natomiast obowiązki są rozłożone w czasie i „doganiają” firmy etapami w latach 2024–2026. W praktyce najpierw pojawiają się zakazy i podstawowe wymagania organizacyjne, a później pełne obowiązki dla systemów AI wysokiego ryzyka oraz modele AI ogólnego przeznaczenia. W AI w Biznesie układamy klientom prostą mapę „co robić teraz, co za 6–12 miesięcy, co później”, żeby nie przepalać budżetu na rzeczy, które jeszcze nie są wymagane.

Czy to dyrektywa czy rozporządzenie — i co to oznacza dla firm?

EU AI Act to rozporządzenie, czyli prawo stosowane bezpośrednio w całej UE — nie czekasz na „polską wersję” w postaci osobnej ustawy, żeby zacząć przygotowania. Natomiast państwa członkowskie będą doprecyzowywać elementy egzekwowania (np. organy, procedury), więc warto śledzić lokalne wdrożenie. My zwykle tłumaczymy to prosto: rdzeń wymagań jest wspólny dla wszystkich, a „operacyjne detale” trzeba doszlifować pod kraj i branżę.

Jak szybko sprawdzić, czy jesteś „dostawcą” (providerem) czy „wdrażającym/użytkownikiem” (deployerem) systemu AI?

Najszybszy test jest w trzech pytaniach: kto decyduje o przeznaczeniu systemu, kto wprowadza go na rynek lub oddaje do użycia pod własną marką oraz kto kontroluje kluczowe zmiany (model, dane, progi, reguły działania). Jeśli sprzedajesz/udostępniasz rozwiązanie klientom albo „brandujesz” cudzy komponent jako swój — często wpadasz w rolę dostawcy; jeśli używasz go w procesach firmy — częściej jesteś wdrażającym. W AI w Biznesie robimy tę kwalifikację warsztatowo na konkretnych przypadkach (np. chatbot HR, scoring, rekomendacje), bo w hybrydach najłatwiej o kosztowną pomyłkę.

Jak to wygląda w praktyce dla dostawców systemów AI wysokiego ryzyka — krok po kroku?

W skrócie: klasyfikacja systemu → zaprojektowanie zgodności → dokumentacja i dowody → testy/ocena zgodności → wdrożenie z nadzorem człowieka → monitoring po wdrożeniu. Najczęściej „klocki” do spięcia w jeden system to: system zarządzania jakością (QMS), zarządzanie ryzykiem, jakość danych, logowanie zdarzeń, przejrzysta instrukcja użycia oraz mechanizmy nadzoru człowieka. W AI w Biznesie przekładamy to na checklistę dla zespołów (produkt, prawny, IT, bezpieczeństwo), żeby każdy wiedział, co ma do ogarnięcia i w jakiej kolejności.

Jakie są zasady dla modeli AI ogólnego przeznaczenia (GPAI) i modeli AI — w punktach?

EU AI Act wprowadza obowiązki dla dostawców modeli AI ogólnego przeznaczenia, niezależnie od tego, w jakich produktach finalnie wylądują. W praktyce chodzi m.in. o przygotowanie dokumentacji/README dla integratorów, polityki zgodności z prawem autorskim oraz podsumowania danych użytych do trenowania (na poziomie wymaganym przez przepisy), a przy modelach o wysokim wpływie — mocniejsze wymagania dotyczące bezpieczeństwa, testów i raportowania incydentów. W AI w Biznesie robimy mapę: „model” vs „system”, bo wiele firm myli te pojęcia i przez to albo panikuje, albo ignoruje realne obowiązki.

Jak EU AI Act traktuje modele open-source — kiedy są wyjątki, a kiedy ich nie ma?

Open-source nie jest magiczną tarczą: część obowiązków może być ograniczona, jeśli model jest udostępniany na otwartej licencji i spełnia warunki z rozporządzenia, natomiast wyjątki nie obejmują wszystkiego. Jeśli na bazie takiego modelu budujesz komercyjny system (zwłaszcza wysokiego ryzyka) albo istotnie go modyfikujesz i „wypuszczasz” jako produkt, obowiązki mogą wrócić jak bumerang — tylko w innym miejscu łańcucha. My w AI w Biznesie pomagamy rozdzielić: co wynika z samego faktu open-source, a co z tego, jak go używasz w procesie i jakie ryzyka generujesz.

Czym jest AI Office i jak to działa w praktyce dla firm?

AI Office to jednostka na poziomie UE, która ma wspierać spójne wdrażanie EU AI Act, koordynować podejście do modeli AI ogólnego przeznaczenia oraz pracować z nadzorem i wytycznymi. Dla firm oznacza to głównie jedno: pojawią się interpretacje, praktyki nadzorcze i „standard” oczekiwań, do którego warto się dopasować, zamiast zgadywać. W AI w Biznesie śledzimy te materiały i przekładamy je na konkret: jakie dokumenty warto mieć, jak opisać przypadek użycia i gdzie najczęściej jest pole do poprawy.