Jak przygotować firmę do wdrożenia AI? Checklista gotowości przed pierwszym projektem

Firma nie jest gotowa na AI tylko dlatego, że pracownicy mają ChatGPT

Nie jest gotowa również dlatego, że:

ktoś zbudował pierwszego agenta,

firma wykupiła Copilota,

powstał chatbot,

zarząd chce „zrobić coś z AI”,

albo konkurencja zaczęła mówić o automatyzacji.

Gotowość zaczyna się wcześniej.

Firma powinna wiedzieć:

jaki problem chce rozwiązać,

w którym procesie występuje,

jak proces działa dzisiaj,

z jakich danych korzysta,

kto odpowiada za rezultat,

co system może robić samodzielnie,

gdzie potrzebny jest człowiek,

i po czym poznamy, że wdrożenie rzeczywiście coś poprawiło.

Dopiero później pojawiają się:

modele,

agenci,

RAG,

automatyzacje,

integracje,

konkretne narzędzia.

To ważne, ponieważ większość problemów z projektami AI nie zaczyna się od tego, że:

model był za słaby.

Znacznie częściej zaczynają się od:

niejasnego procesu,

rozproszonych danych,

braku standardu,

braku właściciela,

nieprzemyślanych wyjątków,

braku integracji,

braku baseline,

braku odpowiedzi na pytanie:

„Po co właściwie budujemy ten system?”

Korzystanie z AI nie oznacza jeszcze gotowości organizacji

To rozróżnienie stało się w 2026 roku jeszcze ważniejsze.

AI jest już szeroko dostępne.

Najnowsze badania McKinsey pokazują jednak, że niewielka część organizacji osiąga z AI naprawdę wysoki efekt finansowy na poziomie całej firmy.

W „The state of AI in 2026” tylko około 6% respondentów zostało zaklasyfikowanych jako AI high performers — organizacje przypisujące AI co najmniej 5% wpływu na EBIT i jednocześnie deklarujące znaczącą wartość wynikającą z jego wykorzystania.

Co wyróżnia tę grupę?

Między innymi sposób projektowania pracy.

Prawie trzy czwarte AI high performers deklaruje, że w związku z AI fundamentalnie przeprojektowuje workflow.

Wśród pozostałych organizacji robi to około jednej czwartej.

To ważna różnica.

Firma gotowa na AI nie tylko daje ludziom narzędzie.

Potrafi zmienić sposób wykonywania pracy tak, żeby technologia rzeczywiście wpływała na cały proces.

„Używamy AI” i „wdrożyliśmy AI” to dwie różne rzeczy

„Używamy AI” może oznaczać:

pracownicy piszą e-maile w ChatGPT,

marketing generuje pomysły,

handlowiec podsumowuje spotkanie,

manager analizuje dokument.

To może przynosić wartość.

Ale jest przede wszystkim indywidualnym wykorzystaniem narzędzia.

„Wdrożyliśmy AI” oznacza coś więcej.

Technologia ma:

konkretny proces,

określone dane wejściowe,

jasne zasady,

integracje,

właściciela,

kontrolę,

obsługę błędów,

KPI,

monitoring.

Przykład:

nowy lead → walidacja → analiza AI → CRM → routing → handlowiec

To już proces.

Nie pojedyncze użycie modelu.

Ten artykuł nie odpowiada na pytanie „jak wdrożyć AI?”

Odpowiada na wcześniejsze:

„Czy jesteśmy gotowi, żeby rozpocząć taki projekt?”

To ważne rozróżnienie.

Przygotowanie obejmuje:

• wybór problemu,
• uporządkowanie procesu,
• dane,
• integracje,
• ryzyko,
• odpowiedzialność,
• ludzi,
• sposób pomiaru.

Dopiero później przychodzą:

pilot,

budowa,

testy,

produkcja,

skalowanie.

Jeżeli masz już wybrany use case i chcesz przejść przez sam proces realizacji od A do Z, zobacz również:

Wdrożenie AI w firmie: jak zacząć krok po kroku i osiągnąć realny efekt

Nie potrzebujesz 50-stronicowej strategii AI

Firma nie musi od razu wiedzieć:

jak AI będzie wykorzystywane za pięć lat,

jakie modele zostaną standardem,

jak będzie wyglądał cały rynek,

ile agentów będzie działało w każdym dziale.

Technologia zmienia się zbyt szybko, żeby taki dokument sam w sobie zapewniał gotowość.

Znacznie praktyczniejszy początek to analiza codziennej pracy.

Zapytaj:

Gdzie tracimy najwięcej czasu?

Gdzie klient czeka?

Gdzie przepisujemy informacje?

Gdzie pracownik czyta setki podobnych wiadomości?

Gdzie musi przeszukiwać wiele dokumentów?

Gdzie wiedza jest rozproszona?

Gdzie proces zależy od pamięci jednej osoby?

Gdzie regularnie powstają błędy?

Gdzie wzrost firmy oznacza niemal proporcjonalny wzrost pracy administracyjnej?

To właśnie w takich miejscach najczęściej znajdują się sensowne use case'y.

OECD: problemy z AI często zaczynają się przed samym AI

OECD, BCG i INSEAD w raporcie dotyczącym adopcji AI w przedsiębiorstwach wskazują powtarzające się bariery.

Wśród nich znajdują się między innymi:

• trudność oszacowania ROI,
• niedostateczna dojrzałość danych,
• niedobory kompetencji,
• problemy z integracją,
• trudność z określeniem, jak AI ma rozwiązać realny problem biznesowy.

To bardzo ważny wniosek.

Firma nie zawsze potrzebuje:

lepszego modelu.

Może potrzebować:

lepiej zdefiniowanego problemu.

Pierwszy test gotowości: opisz projekt bez używania słowa „AI”

Załóżmy, że brief brzmi:

„Chcemy wykorzystać AI do automatyzacji sprzedaży”.

Wiemy bardzo mało.

Co dokładnie nie działa?

Który fragment sprzedaży?

Ilu ludzi dotyczy problem?

Ile razy występuje?

Ile czasu zabiera?

Co oznacza prawidłowy wynik?

Lepszy opis:

„Nowe zapytanie trafia z formularza na wspólną skrzynkę. Pracownik odczytuje wiadomość, sprawdza firmę, uzupełnia CRM, wybiera handlowca i przygotowuje pierwszą odpowiedź. Jeden przypadek zabiera średnio 8 minut, a zgłoszenia złożone po godzinach często czekają do kolejnego dnia.”

Teraz możemy pracować.

Znamy:

początek,

problem,

czynności,

systemy,

potencjalne opóźnienie,

miejsce do pomiaru.

Dopiero teraz pytamy:

czy i gdzie potrzebujemy AI?

Gotowość do AI można ocenić w siedmiu obszarach

Przed rozpoczęciem pierwszego projektu sprawdziłbym przynajmniej:

1. Problem biznesowy

2. Proces

3. Dane

4. Systemy i integracje

5. Ryzyko i bezpieczeństwo

6. Ludzi i odpowiedzialność

7. Pomiar i ekonomię

Firma nie musi być idealna w każdym obszarze.

Powinna jednak wiedzieć, gdzie znajdują się luki.

Obszar 1. Czy masz konkretny problem biznesowy?

Nie zaczynaj od:

„Gdzie możemy dodać AI?”

Zacznij od:

„Co chcemy poprawić?”

Dobry problem można opisać liczbami.

Na przykład:

500 dokumentów miesięcznie.

7 minut na ręczne przepisanie danych.

50 leadów tygodniowo.

Średnio 3 godziny do pierwszej reakcji.

20 pracowników.

Każdy traci około 30 minut dziennie na wyszukiwanie procedur.

To daje podstawę do rozmowy o wartości.

Znacznie słabsze problemy:

„chcemy być bardziej innowacyjni”,

„konkurencja wdraża AI”,

„zarząd chce agenta”.

To mogą być powody do rozpoczęcia analizy.

Nie są jeszcze business case'em.

Dobry use case powinien mieć jasno określony rezultat

System nie powinien:

„pomagać sprzedaży”.

Powinien na przykład:

przeanalizować opis zapytania i przygotować uporządkowane dane dla handlowca.

Nie:

„pomagać księgowości”.

Tylko:

wydobyć wskazane pola z faktury i przygotować je do walidacji przed zapisaniem w ERP.

Nie:

„usprawniać support”.

Tylko:

znaleźć właściwą procedurę i przygotować draft odpowiedzi na podstawie zatwierdzonej bazy wiedzy.

Im konkretniejsze zadanie, tym łatwiej je:

zaprojektować,

przetestować,

zmierzyć.

Obszar 2. Czy znasz rzeczywisty proces?

Nie procedurę.

Nie wersję managera.

Rzeczywisty sposób wykonywania pracy.

Dokumentacja mówi:

„Lead trafia do CRM”.

Praktyka:

formularz →

e-mail →

Anna czyta →

wysyła wiadomość Pawłowi →

Paweł kontaktuje klienta →

wieczorem wpisuje informacje do CRM →

czasem zapomina →

następnego dnia manager pyta o status.

To jest proces do analizy.

Nie:

„Lead trafia do CRM”.

Najprostsza mapa gotowości

Rozpisz:

wejście → decyzje → działania → wyjątki → wynik

Wejście

Co rozpoczyna proces?

Dane

Jakie informacje są potrzebne?

Decyzje

Jakie decyzje podejmuje człowiek?

Działania

Co dzieje się dalej?

Wyjątki

Co się dzieje, kiedy przypadek jest nietypowy?

Wynik

Po czym wiadomo, że proces zakończył się poprawnie?

Jeżeli firma nie potrafi jeszcze odpowiedzieć na te pytania, AI może być przedwczesnym etapem.

Wtedy warto zacząć od:

Audytu procesów w firmie – ExperciAI

Automatyzacja chaosu nadal daje chaos

Załóżmy, że trzech handlowców kwalifikuje leady.

Pierwszy patrzy głównie na:

budżet.

Drugi:

wielkość przedsiębiorstwa.

Trzeci:

treść wiadomości.

Firma mówi:

„AI będzie automatycznie kwalifikować leady”.

Według której definicji?

Model nie naprawia automatycznie braku standardu.

Najpierw trzeba ustalić:

Co oznacza dobry lead?

Które kryteria są obowiązkowe?

Które dodatkowe?

Co wpływa na priorytet?

Kiedy system może działać samodzielnie?

Kiedy potrzebny jest człowiek?

Dopiero potem AI może wspierać tę decyzję.

Najpierw standaryzuj decyzję, później ją automatyzuj

Ta zasada ma ogromne znaczenie.

Jeżeli dziesięciu pracowników wykonuje zadanie na dziesięć różnych sposobów, AI może po prostu dodać:

jedenasty sposób.

Najpierw trzeba ustalić:

jaki sposób jest pożądany.

Nie oznacza to, że każdy przypadek musi być identyczny.

Oznacza, że organizacja zna:

zasady,

granice,

wyjątki.

Wybierz jeden proces, nie „AI dla całej firmy”

Pierwszy projekt powinien mieć wyraźne granice.

Powinno być wiadomo:

gdzie się zaczyna,

gdzie kończy,

kto go posiada,

jakie dane wykorzystuje,

jaki rezultat mierzymy.

Dobre pierwsze use case'y:

• klasyfikacja zapytań,
• podsumowywanie spotkań,
• analiza określonego typu dokumentu,
• wyszukiwanie informacji w bazie wiedzy,
• przygotowywanie draftów,
• ekstrakcja danych,
• aktualizacja CRM na podstawie rozmowy.

Trudniejszy pierwszy zakres:

„agent sprzedaży dla całej firmy”.

Albo:

„zautomatyzujemy cały back office AI”.

Im mniejszy i lepiej zdefiniowany zakres, tym łatwiej nauczyć organizację pracy z AI.

Pierwszy projekt powinien łączyć wartość z ograniczonym ryzykiem

Efektowny use case nie zawsze jest dobrym pierwszym use case'em.

Idealny kandydat:

występuje często,

zabiera mierzalny czas,

ma powtarzalny szkielet,

posiada dostępne dane,

daje mierzalny rezultat,

pojedynczy błąd nie powoduje katastrofalnej konsekwencji.

Przykład:

AI przygotowujące wewnętrzne podsumowania spotkań.

W przypadku błędu pracownik może poprawić wynik.

Znacznie trudniejszy pierwszy projekt:

AI samodzielnie zmieniające:

warunki finansowe,

umowy,

decyzje rekrutacyjne,

inne elementy mające duży wpływ na ludzi lub biznes.

Na początku warto wybrać proces, na którym firma może bezpiecznie nauczyć się działania AI.

Obszar 3. Czy masz odpowiednie dane?

Nie chodzi o:

„czy mamy dużo danych?”

Tylko:

„czy mamy dane potrzebne do konkretnego zadania?”

System klasyfikujący formularze może potrzebować wyłącznie:

treści formularza,

wybranej usługi,

kilku reguł.

Asystent wiedzy może potrzebować:

aktualnych procedur,

dokumentacji,

uporządkowanych źródeł.

System przewidujący zachowanie klientów może wymagać znacznie bardziej rozbudowanej historii.

Nie wszystkie projekty AI mają takie same wymagania danych.

Nie musisz mieć idealnej hurtowni danych

To częsty mit.

Firma słyszy:

„AI potrzebuje danych”.

I dochodzi do wniosku:

„najpierw musimy przez dwa lata porządkować całą organizację”.

Niekoniecznie.

Przy ograniczonym use case'ie wystarczy uporządkować dane potrzebne właśnie do niego.

Na przykład:

system obsługuje formularze.

Potrzebujemy:

formularza,

oferty,

zasad kwalifikacji,

CRM.

Nie potrzebujemy od razu kompletnego data lake dla całej organizacji.

Firma musi wiedzieć, gdzie znajdują się informacje

Zrób prostą mapę danych.

Czy dane są w:

CRM?

ERP?

Google Drive?

SharePoint?

Notion?

poczcie?

Excelu?

PDF-ach?

bazie danych?

głowie pracownika?

Następnie:

Które źródło jest aktualne?

Kto je aktualizuje?

Jak często?

Czy można się z nim połączyć?

Kto ma dostęp?

To prosta analiza, ale bardzo szybko pokazuje problemy.

AI potrzebuje źródła prawdy

Wyobraźmy sobie system przygotowujący ofertę.

Na stronie:

5000 zł.

W starym PDF:

4500 zł.

W CRM:

5500 zł.

Co ma odpowiedzieć AI?

Nie powinno zgadywać.

Firma powinna wcześniej określić źródło prawdy dla:

• cen,
• terminów,
• statusów,
• warunków,
• procedur,
• produktów,
• dostępności.

To jest część gotowości danych.

Baza wiedzy nie powinna być cyfrowym śmietnikiem

Technicznie można podłączyć AI do:

10 000 dokumentów.

Nie oznacza to, że warto.

Jeżeli połowa jest:

nieaktualna,

zdublowana,

sprzeczna,

bez daty,

bez ownera,

asystent otrzyma bardzo sprawne narzędzie do wyszukiwania złych informacji.

Przed budową firmowej wiedzy AI warto ustalić:

Które dokumenty są aktualne?

Które archiwalne?

Kto odpowiada za aktualizację?

Czy istnieją wersje?

Kto może mieć dostęp?

AI nie naprawia knowledge management.

Często tylko bardzo szybko pokazuje, że firma wcześniej go nie miała.

Dane podane przez człowieka i wnioski AI to nie to samo

To istotne także projektowo.

W systemie warto rozróżniać:

fakt z CRM

od:

wniosku modelu.

Przykład:

CRM:

120 pracowników.

AI:

„firma prawdopodobnie należy do segmentu mid-market”.

Pierwsze jest daną.

Drugie interpretacją.

Nie powinny być traktowane identycznie.

Obszar 4. Czy systemy można integrować?

Firma chce agenta, który:

odbiera lead,

sprawdza CRM,

pobiera ERP,

sprawdza termin,

wysyła e-mail,

tworzy zadanie.

Zanim zaprojektujemy agenta:

Czy CRM posiada API?

Czy ERP posiada API?

Jak wygląda autoryzacja?

Czy można odczytywać dane?

Czy można je aktualizować?

Jakie są limity?

Czy dostęp jest stabilny?

Czy system działa w chmurze?

Czy wymaga VPN?

Co wydarzy się podczas awarii?

Czasami największym problemem wdrożenia AI jest stary system, z którego nadal raz dziennie ręcznie eksportowany jest CSV.

Sprawdź integracje przed wyceną rozwiązania

Dwa projekty wyglądające identycznie biznesowo mogą mieć zupełnie inną złożoność.

Firma A:

HubSpot,

Google Workspace,

nowoczesne API.

Firma B:

lokalny system bez dokumentacji,

Excel,

skrzynka IMAP,

ERP dostępny tylko przez pulpit zdalny.

Use case:

ten sam.

Trudność:

zupełnie inna.

Dlatego audyt integracji powinien wydarzyć się przed ostatecznym projektem architektury.

Jeżeli AI nie jest potrzebne, nie dodawaj go

Firma chce:

formularz → CRM → przypisanie → zadanie.

Nie potrzebuje do tego modelu językowego.

Potrzebuje automatyzacji.

AI staje się wartościowe, gdy pojawia się:

tekst,

dokument,

interpretacja,

klasyfikacja,

wyszukiwanie informacji,

podsumowanie,

nieustrukturyzowane dane.

Jeżeli główny problem polega na przenoszeniu danych pomiędzy systemami, lepszym punktem startowym może być:

Automatyzacja procesów w firmie – ExperciAI

Obszar 5. Czy wiesz, jakie dane AI może przetwarzać?

To pytanie powinno pojawić się:

przed testem na prawdziwych danych.

Nie po nim.

AI może pracować na:

mailach,

CRM,

umowach,

nagraniach,

fakturach,

danych pracowników,

dokumentacji wewnętrznej.

Nie każdy system powinien dostać dostęp do wszystkiego.

Firma powinna ustalić:

Jakie dane można wykorzystać?

Jakich nie można?

Do którego dostawcy mogą trafić?

Gdzie są przetwarzane?

Czy są przechowywane?

Jak długo?

Kto ma dostęp?

Co trafia do logów?

Dane osobowe nadal podlegają RODO

Wdrożenie modelu AI nie wyłącza obowiązków ochrony danych.

Europejska Rada Ochrony Danych w opinii dotyczącej modeli AI analizuje między innymi:

• anonimowość modeli,
• podstawy prawne przetwarzania,
• uzasadniony interes,
• konsekwencje używania danych przetworzonych niezgodnie z prawem.

Zakres obowiązków zawsze zależy od konkretnego projektu.

Dlatego szczególnie w systemach pracujących na danych klientów lub pracowników warto przeprowadzić odpowiednią analizę prawną i privacy review.

Nie jest to porada prawna — konkretny system powinien być oceniany indywidualnie.

Minimalne potrzebne dane

Jeżeli AI ma klasyfikować:

opis zapytania,

nie musi automatycznie otrzymywać:

pełnej historii faktur,

wszystkich maili,

numeru PESEL,

całej historii klienta

jeśli nie są potrzebne do zadania.

Zasada:

minimum danych potrzebne do wykonania funkcji.

Daje korzyści w:

bezpieczeństwie,

koszcie,

prywatności,

debugowaniu.

Nie dawaj systemowi większych uprawnień niż potrzebuje

Agent sprawdza dostępność spotkania.

Nie musi usuwać wydarzeń.

AI analizuje CRM.

Nie musi usuwać klientów.

System przygotowuje ofertę.

Nie powinien zmieniać firmowego cennika.

Stosuj zasadę:

least privilege.

Im większa autonomia i liczba uprawnień, tym większa możliwa konsekwencja błędu.

Obszar 6. Czy wiadomo, gdzie kończy się autonomia AI?

System może:

Poziom 1

Tylko przekazać informację.

Poziom 2

Przygotować rekomendację.

Poziom 3

Przygotować gotowe działanie do zatwierdzenia.

Poziom 4

Samodzielnie wykonać działanie.

To nie są te same projekty.

AI tworzące wewnętrzne podsumowanie:

niski poziom konsekwencji.

AI wysyłające indywidualną ofertę:

większa odpowiedzialność.

AI podejmujące istotną decyzję dotyczącą pracownika:

zupełnie inny profil ryzyka.

Dobra zasada:

im większa konsekwencja błędu, tym bliżej decyzji powinien pozostawać człowiek.

Human-in-the-loop nie musi oznaczać wiecznej ręcznej kontroli wszystkiego

Na początku:

AI przygotowuje 100 odpowiedzi.

Pracownik sprawdza każdą.

Po 500 przypadkach okazuje się:

kategoria A jest prawidłowa w 99% przypadków,

kategoria B wymaga regularnych poprawek,

kategoria C jest nietypowa.

Future state:

A → automatyczna.

B → review.

C → człowiek.

Autonomia może rosnąć wraz z dowodami.

Nie z entuzjazmem po udanym demo.

System powinien potrafić powiedzieć „nie wiem”

To ważny element gotowości.

Firma nie powinna projektować AI tak, jakby model zawsze musiał dostarczyć odpowiedź.

Dobra architektura pozwala na:

brak decyzji,

prośbę o dane,

eskalację,

przekazanie do człowieka.

W części use case'ów umiejętność:

„nie mam wystarczających informacji”

jest równie ważna jak dobra odpowiedź.

Przygotuj prawdziwe przypadki testowe

Demo prawie zawsze działa.

Prawdziwi użytkownicy:

robią literówki,

nie podają danych,

wysyłają dziwne PDF-y,

zadają dwa pytania jednocześnie,

podają sprzeczne informacje,

piszą nieprecyzyjnie.

Systemy również zawodzą.

CRM nie odpowiada.

API zwraca timeout.

Rekord istnieje dwa razy.

Dokument ma nieprawidłowy format.

Dlatego potrzebujesz zestawu:

normalnych przypadków,

trudnych przypadków,

błędnych danych,

wyjątków,

sytuacji, których AI nie powinno obsługiwać.

NIST: testuj system w kontekście rzeczywistego zastosowania

NIST AI Risk Management Framework został zaprojektowany jako dobrowolny framework wspierający organizacje w zarządzaniu ryzykiem AI.

Jego funkcje obejmują:

Govern

Map

Measure

Manage

To bardzo dobre przypomnienie:

AI nie powinno być oceniane tylko przez:

„model zwrócił poprawną odpowiedź w naszym teście”.

Liczy się:

kontekst,

ryzyko,

pomiar,

zarządzanie systemem w całym cyklu życia.

Dla generatywnej AI NIST udostępnia również Generative AI Profile.

Obszar 7. Czy istnieje właściciel biznesowy?

Wdrożenie AI nie może być wyłącznie projektem developera.

Developer potrafi zbudować:

integrację,

workflow,

backend,

agenta.

Nie powinien samodzielnie ustalać:

jak kwalifikujemy leady,

co oznacza dobra reklamacja,

jakie są kryteria prawidłowej faktury,

kiedy klient powinien otrzymać rabat.

Potrzebny jest business owner.

Osoba, która:

zna proces,

rozumie wyjątki,

określa poprawny wynik,

definiuje KPI,

akceptuje zasady.

W sprzedaży:

Head of Sales.

W support:

Customer Service Manager.

W mniejszej firmie:

founder.

Potrzebny jest również właściciel techniczny

Kto:

ma dostęp do API?

zna architekturę?

otrzymuje alert?

zarządza kluczami?

może zmienić prompt?

wie, jaki model działa produkcyjnie?

kontroluje koszty?

potrafi przeanalizować logi?

Nie musi to być osobny etat.

Ale odpowiedzialność musi istnieć.

System bez właściciela technicznego zaczyna się starzeć od pierwszego dnia.

Trzecia odpowiedzialność: dane

Przy większych projektach warto również określić:

kto odpowiada za źródła danych?

AI korzysta z cennika.

Kto aktualizuje cennik?

AI korzysta z procedury.

Kto zatwierdza jej nową wersję?

AI korzysta z katalogu produktów.

Kto odpowiada za poprawność?

Model nie powinien stać się właścicielem firmowej wiedzy.

Zespół musi rozumieć nowy proces

Pracownik dostaje komunikat:

„Od jutra mamy AI”.

Naturalne pytania:

Czy muszę sprawdzać odpowiedzi?

Co zrobić, gdy system się myli?

Czy mogę wkleić dane klienta?

Czy AI mnie zastąpi?

Kto odpowiada za błąd?

Czy muszę nadal uzupełniać CRM?

Wdrożenie zmienia sposób pracy.

Zespół powinien wiedzieć:

co się zmienia,

co pozostaje,

za co odpowiada AI,

za co odpowiada człowiek.

AI literacy jest już obowiązkiem wynikającym z AI Act

Artykuł 4 AI Act dotyczący AI literacy zaczął być stosowany 2 lutego 2025 roku.

Po zmianach wprowadzonych przez Digital Omnibus w 2026 roku temat nadal pozostaje elementem obowiązków związanych z wykorzystywaniem AI.

Komisja Europejska wskazuje, że dostawcy i podmioty stosujące systemy AI powinny podejmować działania wspierające odpowiedni poziom AI literacy osób korzystających z tych systemów w ich imieniu, uwzględniając między innymi:

• wiedzę,
• doświadczenie,
• szkolenie,
• kontekst wykorzystania.

Nie oznacza to:

„każdy musi zostać ekspertem AI”.

Pracownik powinien rozumieć system odpowiednio do swojej roli.

AI literacy to nie szkolenie „100 promptów do ChatGPT”

Przygotowanie pracownika powinno obejmować:

Do czego używamy systemu?

Czego system nie powinien robić?

Jakich informacji nie podajemy?

Jak rozpoznać niepewny wynik?

Jak zweryfikować odpowiedź?

Co zrobić przy błędzie?

Jak działa eskalacja?

To znacznie ważniejsze niż znajomość 20 technik prompt engineeringu.

AI Act w 2026 — sprawdź klasyfikację przed pilotem

AI Act jest wdrażany etapami.

Aktualny oficjalny harmonogram uwzględnia również zmiany wprowadzone przez Digital Omnibus.

Kluczowe daty obejmują:

2 lutego 2025

Zastosowanie części przepisów dotyczących:

AI literacy

i zakazanych praktyk.

2 sierpnia 2025

Zastosowanie reguł dotyczących między innymi modeli ogólnego przeznaczenia oraz części governance.

2 sierpnia 2026

Zastosowanie większości kolejnych przepisów oraz rozpoczęcie egzekwowania odpowiednich obowiązujących reguł.

Zaczęły obowiązywać również przepisy przejrzystości z art. 50.

2 grudnia 2027

Zgodnie z aktualnym harmonogramem mają być stosowane reguły dla systemów wysokiego ryzyka z Annex III.

2 sierpnia 2028

Reguły dla odpowiednich systemów wysokiego ryzyka wbudowanych w regulowane produkty z Annex I.

Harmonogram może być aktualizowany.

Dlatego w projekcie o podwyższonym ryzyku warto korzystać z aktualnych informacji Komisji Europejskiej i AI Act Service Desk, a nie ze starej prezentacji przygotowanej rok wcześniej.

Nie każda firma korzystająca z AI ma „high-risk system”

To ważne.

AI podsumowujące spotkanie:

inna sytuacja.

Chatbot odpowiadający na podstawowe pytania:

inna.

System wykorzystywany w procesie zatrudniania:

inna.

Trzeba analizować:

konkretny use case,

rolę organizacji,

sposób wykorzystania,

wpływ na ludzi.

Nie sam fakt:

„używamy AI”.

Użytkownik może potrzebować informacji, że rozmawia z AI

Od 2 sierpnia 2026 roku zastosowanie mają odpowiednie obowiązki przejrzystości z art. 50 AI Act.

Ma to znaczenie między innymi przy systemach AI przeznaczonych do bezpośredniej interakcji z ludźmi.

Dlatego już podczas projektowania:

chatbota,

voicebota,

asystenta

warto ustalić:

jak system zostanie przedstawiony użytkownikowi.

Nie doklejać tej kwestii dzień przed publikacją.

Zmierz proces przed wdrożeniem

To jeden z najważniejszych elementów readiness.

Firma buduje system.

Po trzech miesiącach zarząd pyta:

„Ile zaoszczędziliśmy?”

Zespół:

„Trudno powiedzieć, ale działa fajnie”.

To nie jest dobry rezultat.

Przed projektem mierz:

czas,

wolumen,

błędy,

koszt,

liczbę ręcznych kroków,

SLA,

rework.

W zależności od use case'u.

OECD: szacowanie ROI jest realnym problemem przedsiębiorstw

W badaniu przedsiębiorstw aktywnie wykorzystujących AI trudność oszacowania ROI była jednym z najczęściej raportowanych problemów.

Wskazywało ją:

62% badanych przedsiębiorstw produkcyjnych

oraz:

56% przedsiębiorstw ICT.

Próba nie reprezentuje wszystkich firm na świecie — badanie obejmowało przedsiębiorstwa już aktywnie korzystające z AI w krajach G7.

Ale dobrze pokazuje praktyczny problem:

firma może wiedzieć, że technologia jest interesująca

i jednocześnie nie potrafić odpowiedzieć:

„czy ten konkretny projekt ekonomicznie ma sens?”

ROI zaczyna się przed pierwszym promptem

Przykład.

300 przypadków miesięcznie.

10 minut pracy.

3000 minut.

50 godzin.

Po wdrożeniu:

3 minuty kontroli.

900 minut.

15 godzin.

Potencjalnie:

35 godzin odzyskanego czasu miesięcznie.

Teraz można zestawić:

wartość czasu,

koszt wdrożenia,

API,

utrzymanie,

review,

infrastrukturę.

Dopiero to jest początek business case'u.

Nie każda korzyść oznacza „zwolnimy pracownika”

AI może tworzyć wartość przez:

szybszą reakcję,

większą przepustowość,

mniej błędów,

pełniejsze dane,

krótszy lead time,

lepszą obsługę,

uniknięcie dodatkowego zatrudnienia.

Przykład:

firma rośnie o 30%.

Bez zmiany procesu potrzebowałaby:

dwóch kolejnych osób.

Po automatyzacji istniejący zespół jest w stanie obsłużyć wzrost.

To również jest ekonomiczny rezultat.

Przygotuj plan awaryjny

Produkcja oznacza, że:

API przestanie odpowiadać.

Model zwróci zły format.

CRM będzie niedostępny.

Token wygaśnie.

Baza wiedzy nie odpowie.

System może przekroczyć limit.

Co wtedy?

Możliwe rozwiązania:

retry,

kolejka,

alert,

ręczna ścieżka,

fallback,

zatrzymanie procesu.

„Model powinien działać”

nie jest planem awaryjnym.

Logi są częścią produktu

System zrobił coś źle.

Co otrzymał?

Jaką wersję prompta wykorzystał?

Jaki model?

Jakie źródło danych?

Jaki wynik?

Jakie działanie wykonał?

Jeżeli nie jesteś w stanie odpowiedzieć, zaczynasz debugowanie od zgadywania.

Obserwowalność należy przygotować:

przed produkcją.

Nie loguj wszystkiego bezmyślnie

Druga strona problemu:

logi mogą zawierać:

dane osobowe,

poufne dokumenty,

pełną treść rozmów.

Dlatego trzeba ustalić:

co jest logowane,

po co,

na jak długo,

kto może to zobaczyć.

Monitoring i prywatność powinny być projektowane razem.

Gotowość techniczna obejmuje monitoring kosztów

Model AI może kosztować:

0,01 zł na przypadek

albo:

kilka złotych.

Różnica przy:

100 przypadkach

może być nieistotna.

Przy:

10 milionach

już nie.

Firma powinna wiedzieć:

ile kosztuje jeden przypadek,

ile będzie kosztował przy obecnej skali,

co stanie się przy 10× większym użyciu.

Koszt API jest elementem architektury.

Nie zakładaj, że obecny model będzie używany zawsze

Dzisiaj najlepszy może być model A.

Za sześć miesięcy:

model B.

Dlatego przy większych projektach warto ograniczać niepotrzebny vendor lock-in.

Oddziel:

logikę biznesową

od:

konkretnego dostawcy modelu

tam, gdzie ma to sens.

Nie zawsze trzeba budować zaawansowaną abstraction layer.

Ale warto unikać sytuacji, w której cała organizacja procesu jest nierozerwalnie związana z jedną funkcją jednego modelu bez biznesowej potrzeby.

Firma nie musi od razu budować własnego modelu

W większości pierwszych projektów pytanie:

„Czy powinniśmy trenować własny LLM?”

jest przedwczesne.

Często wystarczy:

gotowy model,

dobre dane,

integracja,

RAG,

reguły,

monitoring.

Własny model niesie dodatkowe koszty:

infrastruktury,

danych,

ewaluacji,

utrzymania.

Technologia powinna wynikać z wymagania.

Nie z ambicji.

Przygotowanie zespołu jest równie ważne jak przygotowanie systemu

AI może działać świetnie.

Pracownicy mogą go nie używać.

Dlaczego?

Bo:

wynik jest trudny do znalezienia,

system dodaje więcej kliknięć,

nie ufają odpowiedziom,

nie wiedzą, kiedy używać narzędzia,

obawiają się konsekwencji błędu.

Gotowość organizacyjna oznacza więc również:

czy nowy sposób pracy jest lepszy dla człowieka, który ma z niego korzystać?

AI powinno trafiać do istniejącego workflow tam, gdzie to możliwe

Pracownik pracuje w:

CRM.

Firma buduje:

osobny portal AI.

Pracownik:

kopiuje dane z CRM do portalu,

kopiuje odpowiedź z portalu do CRM.

Mamy AI.

Ale dodaliśmy nowe przeklejanie.

Lepszy system może działać bezpośrednio:

w CRM,

helpdesku,

Slacku,

narzędziu operacyjnym.

AI powinno usuwać zbędne kroki.

Nie tworzyć nowe.

Jak ocenić gotowość firmy? Prosty scoring

Możesz przeprowadzić wstępną samoocenę.

Dla każdego stwierdzenia przyznaj:

0 punktów — nie

1 punkt — częściowo

2 punkty — tak

Problem i business case

1. Potrafimy wskazać konkretny proces do poprawy.
2. Potrafimy opisać problem bez używania słowa „AI”.
3. Znamy częstotliwość występowania problemu.
4. Wiemy, jaki rezultat chcemy poprawić.
5. Potrafimy wstępnie określić wartość zmiany.

Proces

1. Znamy rzeczywisty przebieg procesu.
2. Znamy początek i koniec.
3. Znamy główne decyzje.
4. Znamy wyjątki.
5. Proces ma właściciela.

Dane

1. Wiemy, jakich danych potrzebujemy.
2. Wiemy, gdzie się znajdują.
3. Znamy źródło prawdy.
4. Dane są wystarczająco aktualne.
5. Potrafimy określić, które dane AI może wykorzystywać.

Systemy

1. Znamy wszystkie potrzebne integracje.
2. Wiemy, czy systemy mają API.
3. Wiemy, jakie uprawnienia są potrzebne.
4. Potrafimy obsłużyć niedostępność integracji.
5. System posiada właściciela technicznego.

Ryzyko

1. Wiemy, co stanie się przy błędzie AI.
2. Określiliśmy poziom autonomii.
3. Wiemy, które przypadki trafiają do człowieka.
4. Sprawdziliśmy wymogi bezpieczeństwa i prywatności.
5. Przeanalizowaliśmy podstawowe wymagania regulacyjne.

Testy i monitoring

1. Mamy prawdziwe przypadki testowe.
2. Mamy przykłady trudnych przypadków.
3. System będzie posiadał logi.
4. Zdefiniowaliśmy monitoring.
5. Istnieje plan awaryjny.

Ludzie i adopcja

1. Pracownicy wiedzą, dlaczego wdrażamy system.
2. Wiedzą, czego AI nie powinno robić.
3. Wiedzą, co robić przy błędzie.
4. Określiliśmy potrzebny poziom AI literacy.
5. Wiadomo, kto odpowiada za wynik biznesowy.

Pomiar

1. Posiadamy baseline.
2. Zdefiniowaliśmy KPI biznesowe.
3. Zdefiniowaliśmy KPI techniczne.
4. Potrafimy oszacować koszt rozwiązania.
5. Wiemy, kiedy projekt uznamy za sukces lub porażkę.

Maksymalnie:

80 punktów.

To nie jest naukowy model dojrzałości.

Jest praktycznym narzędziem do wstępnej rozmowy.

0–30 punktów

Najpierw uporządkuj podstawy.

Budowa systemu może być jeszcze przedwczesna.

31–55 punktów

Firma posiada część fundamentów.

Warto zamknąć najważniejsze luki przed pilotem.

56–70 punktów

Dobry poziom przygotowania do ograniczonego projektu pilotażowego.

71–80 punktów

Proces jest dobrze opisany i organizacja prawdopodobnie może rozpocząć pilot przy zachowaniu właściwej analizy konkretnego use case'u.

Wysoki wynik nie oznacza oczywiście automatycznej zgodności prawnej ani gwarancji sukcesu projektu.

Co przygotować przed pierwszą rozmową o AI?

Nie potrzebujesz prezentacji na 70 slajdów.

Znacznie bardziej użyteczne będą:

5–10 realnych przykładów

E-maile.

Dokumenty.

Formularze.

Raporty.

Opis procesu

Krok po kroku.

Lista systemów

CRM.

ERP.

Poczta.

Dysk.

Najczęstsze wyjątki

Co zawsze komplikuje pracę?

Wolumen

Ile przypadków tygodniowo lub miesięcznie?

Czas

Ile zajmuje praca?

Właściciel

Kto zna proces najlepiej?

Oczekiwany efekt

Co chcemy poprawić?

Ograniczenia

Jakich danych nie wolno używać?

Jakich działań system nie powinien wykonywać?

Taki zestaw jest znacznie bardziej wartościowy niż brief:

„Chcemy agenta AI. Ile kosztuje?”

Gotowość nie oznacza perfekcji

Firma nie potrzebuje:

idealnych danych,

100% opisanych procesów,

zespołu machine learning,

własnych modeli,

pięcioletniej strategii.

Musi wiedzieć wystarczająco dużo o jednym konkretnym use case'ie.

Jaki problem?

Jaki proces?

Jakie dane?

Kto odpowiada?

Jakie ryzyko?

Co mierzymy?

To wystarczy do rozpoczęcia sensownego pilota.

Gotowość do AI to nie to samo co dojrzałość całej firmy

Organizacja może posiadać:

chaotyczny marketing,

słaby HR,

stary ERP,

a jednocześnie być dobrze przygotowana do jednego konkretnego projektu AI w dziale obsługi dokumentów.

Nie trzeba więc pytać:

„Czy cała firma jest gotowa na AI?”

Lepsze pytanie:

„Czy ten proces jest wystarczająco gotowy na to konkretne zastosowanie?”

To dużo bardziej praktyczne.

Zacznij od jednego kontrolowanego pilota

Pierwszy projekt powinien pozwolić firmie nauczyć się:

jak testować AI,

jak mierzyć jakość,

jak reagować na błędy,

jak pracownicy współpracują z systemem,

ile naprawdę kosztuje utrzymanie,

jak działa governance.

To wiedza, którą później można wykorzystać przy kolejnych projektach.

Pierwszy pilot nie powinien być:

„AI transformuje całą organizację”.

Powinien być:

„rozwiązujemy jeden ważny problem i uczymy się robić to dobrze”.

Po pilocie gotowość organizacji wzrasta

Pierwsze wdrożenie tworzy coś więcej niż sam system.

Firma zdobywa:

wiedzę o danych,

procedury testowania,

standardy bezpieczeństwa,

wzorce integracji,

sposób monitorowania,

doświadczenie użytkowników,

wiedzę o dostawcach,

metody liczenia ROI.

Dlatego nawet niewielki pierwszy projekt może mieć strategiczną wartość.

Buduje zdolność organizacji do kolejnych wdrożeń.

Jak ExperciAI podchodzi do przygotowania firmy do AI?

W ExperciAI nie zaczynamy od:

„Jaki model wdrażamy?”

Najpierw chcemy zobaczyć:

jak wygląda praca dzisiaj,

gdzie powstaje strata,

które działania są ręczne,

jakie dane przepływają,

jakie systemy uczestniczą,

gdzie proces czeka,

jakie występują wyjątki,

kto odpowiada za rezultat.

Następnie rozdzielamy proces na trzy obszary:

co powinien wykonywać człowiek,

co powinna wykonywać klasyczna automatyzacja,

gdzie AI rzeczywiście daje dodatkową wartość.

Jeżeli firma jeszcze nie wie, który proces wybrać:

Audyt procesów w firmie – ExperciAI

Jeżeli use case jest już określony:

Wdrożenia AI dla firm – ExperciAI

Jeżeli głównym problemem są ręczne działania i brak połączenia systemów:

Automatyzacja procesów – ExperciAI

Nie przygotowujemy firmy do:

„posiadania AI”.

Przygotowujemy konkretny proces do tego, żeby dzięki technologii działał lepiej.

Checklista gotowości przed pierwszym pilotem AI

Przed rozpoczęciem projektu sprawdź:

1. Czy potrafimy wskazać jeden konkretny proces?
2. Czy problem można opisać bez słowa AI?
3. Czy znamy jego skalę?
4. Czy znamy częstotliwość?
5. Czy wiemy, ile czasu zabiera?
6. Czy znamy koszt błędów?
7. Czy proces ma jasno określony początek?
8. Czy posiada wynik?
9. Czy mamy mapę rzeczywistego current state?
10. Czy znamy główne wyjątki?
11. Czy istnieją spójne zasady biznesowe?
12. Czy wiemy, które elementy można usunąć lub uprościć?
13. Czy wiadomo, gdzie naprawdę potrzebujemy AI?
14. Czy zwykła automatyzacja wystarczy dla części procesu?
15. Czy znamy potrzebne dane?
16. Czy wiadomo, gdzie się znajdują?
17. Czy mamy źródło prawdy?
18. Czy dokumenty są aktualne?
19. Czy wiemy, kto odpowiada za aktualizację danych?
20. Czy znamy potrzebne integracje?
21. Czy systemy posiadają API?
22. Czy znamy ograniczenia techniczne?
23. Czy wiadomo, jakie dane AI może przetwarzać?
24. Czy stosujemy zasadę minimalnych danych?
25. Czy system otrzyma minimalne potrzebne uprawnienia?
26. Czy przeanalizowaliśmy dane osobowe?
27. Czy sprawdziliśmy właściwe wymagania AI Act?
28. Czy określiliśmy poziom autonomii?
29. Czy wiadomo, kiedy potrzebny jest człowiek?
30. Czy AI może odmówić podjęcia decyzji?
31. Czy mamy ownera biznesowego?
32. Czy mamy ownera technicznego?
33. Czy zespół zna swoją rolę?
34. Czy zapewniliśmy odpowiedni poziom AI literacy?
35. Czy posiadamy rzeczywiste przykłady testowe?
36. Czy testujemy również wyjątki?
37. Czy mamy baseline?
38. Czy istnieją KPI biznesowe?
39. Czy istnieją KPI techniczne?
40. Czy znamy koszt jednego przypadku?
41. Czy koszt pozostanie akceptowalny przy większej skali?
42. Czy system będzie monitorowany?
43. Czy mamy logi?
44. Czy mamy alerty?
45. Czy istnieje fallback?
46. Czy można ręcznie przejąć proces?
47. Czy wiemy, jak wycofać błędną zmianę?
48. Czy pilot ma warunki sukcesu?
49. Czy pilot ma warunki zatrzymania?
50. Czy po pilocie będziemy potrafili jednoznacznie odpowiedzieć: „czy warto to skalować?”

Jeżeli na dużą część pytań odpowiedź brzmi:

„nie wiemy”

nie oznacza to:

„firma nie nadaje się do AI”.

Oznacza:

właśnie znaleźliśmy rzeczy, które trzeba przygotować przed inwestycją w development.

FAQ: jak przygotować firmę do wdrożenia AI?

Jak przygotować firmę do wdrożenia AI?

Najpierw należy wybrać konkretny proces, poznać jego rzeczywisty przebieg, zmierzyć stan obecny, ustalić wymagane dane, integracje, ownera oraz oczekiwany rezultat. Dopiero później warto projektować rozwiązanie AI.

Skąd wiedzieć, czy firma jest gotowa na AI?

Dobrym sygnałem jest możliwość odpowiedzi na pytania: jaki problem rozwiązujemy, jak działa obecny proces, jakie dane są potrzebne, kto odpowiada za rezultat, co może wykonywać AI i jak zmierzymy efekt.

Czy przed AI trzeba przeprowadzić audyt procesów?

Nie zawsze. Audyt jest szczególnie przydatny, kiedy organizacja nie wie jeszcze, który proces wybrać albo problemy występują w wielu miejscach jednocześnie.

Czy wszystkie dane muszą być uporządkowane?

Nie. Trzeba przede wszystkim uporządkować dane potrzebne do konkretnego zastosowania.

Czy firma potrzebuje własnego data lake?

Nie w każdym projekcie. Prosty use case może wymagać zaledwie kilku wiarygodnych źródeł.

Co oznacza source of truth?

To wskazane przez organizację nadrzędne źródło konkretnej informacji. Przykładowo aktualny cennik może znajdować się w ERP, a nie w starym PDF-ie wykorzystywanym przez jednego pracownika.

Czy firma potrzebuje własnego zespołu AI?

Nie. Projekt może być realizowany z partnerem zewnętrznym. W organizacji nadal powinien istnieć właściciel biznesowy procesu.

Kto powinien być właścicielem projektu AI?

Osoba odpowiedzialna biznesowo za proces oraz osoba odpowiedzialna technicznie za działanie systemu. Przy bardziej złożonych projektach warto również jasno określić ownership danych.

Czy AI literacy jest obowiązkowe?

AI Act zawiera obowiązki dotyczące wspierania odpowiedniego poziomu AI literacy osób korzystających z systemów AI w imieniu dostawcy lub podmiotu stosującego. Artykuł 4 zaczął być stosowany 2 lutego 2025 roku.

Czy każdy pracownik musi przejść szkolenie AI?

Zakres przygotowania powinien odpowiadać jego roli oraz systemowi, z którego korzysta. Nie każdy potrzebuje takiego samego poziomu wiedzy.

Czy trzeba sprawdzić AI Act przed pilotem?

Tak, szczególnie jeśli system wchodzi w interakcję z ludźmi, pracuje w regulowanym obszarze albo może wpływać na ważne decyzje dotyczące osób.

Czy każde AI jest systemem wysokiego ryzyka?

Nie. Klasyfikacja zależy od konkretnego zastosowania oraz innych warunków określonych w AI Act.

Czy RODO ma zastosowanie do projektów AI?

Jeżeli w procesie przetwarzane są dane osobowe, wymagania RODO nadal mają znaczenie. Konkretny zakres obowiązków zależy od projektu.

Jaki pierwszy projekt AI wybrać?

Najlepiej proces częsty, mierzalny, względnie uporządkowany i o kontrolowanych konsekwencjach błędu.

Czy agent AI jest dobrym pierwszym projektem?

Nie zawsze. Prosty workflow wykorzystujący AI tylko w jednym miejscu może być łatwiejszy do przetestowania i bezpieczniejszy.

Jakie przypadki testowe przygotować?

Zarówno typowe, jak i trudne: niepełne dane, literówki, sprzeczne informacje, nietypowe dokumenty, awarie integracji i przypadki wymagające człowieka.

Po co mierzyć proces przed wdrożeniem?

Bez baseline nie można wiarygodnie stwierdzić, czy system skrócił czas, zmniejszył koszt, ograniczył błędy albo poprawił wynik.

Czy trzeba policzyć ROI przed pierwszym pilotem?

Warto przynajmniej przygotować wstępny business case i znać ekonomię obecnego procesu. Pilot może później dostarczyć lepszych danych do pełnej kalkulacji.

Co zrobić, jeśli firma nie spełnia całej checklisty?

Nie trzeba spełniać wszystkiego idealnie. Checklista ma wskazać najważniejsze luki do zamknięcia przed rozpoczęciem inwestycji.

Podsumowanie

Firma nie jest gotowa na AI dlatego, że:

ma ChatGPT,

widziała efektowne demo,

konkurencja wdraża agentów.

Jest gotowa wtedy, kiedy potrafi odpowiedzieć:

Jaki problem rozwiązujemy?

W jakim procesie?

Jak proces działa dzisiaj?

Jak ma wyglądać po zmianie?

Jakich danych potrzebujemy?

Które źródła są wiarygodne?

Jakie systemy trzeba połączyć?

Co może robić AI?

Co nadal kontroluje człowiek?

Co wydarzy się przy błędzie?

Kto odpowiada za wynik?

Jak zmierzymy efekt?

Nie potrzeba idealnej organizacji.

Nie trzeba od razu transformować całego przedsiębiorstwa.

Wystarczy jeden dobrze wybrany proces.

Jasny problem.

Realne dane.

Kontrolowany pilot.

I sposób pomiaru.

Pierwsze wdrożenie nie ma udowodnić:

„AI jest niesamowite”.

Powinno udowodnić:

„ten proces po zmianie działa mierzalnie lepiej”.

Dopiero wtedy warto iść dalej.

Kolejny proces.

Kolejny use case.

Większy zakres.

Większa autonomia.

Gotowość do AI nie polega więc na posiadaniu największej liczby narzędzi.

Polega na zbudowaniu zdolności organizacji do wybierania właściwych problemów, bezpiecznego wdrażania technologii i odróżniania efektownego demo od realnej wartości biznesowej.

Źródła i badania

1. McKinsey & Company — The state of AI in 2026: On the road to ROI

Globalne badanie z sierpnia 2026 roku dotyczące skalowania AI, agentów i mierzalnego wpływu technologii na przedsiębiorstwa. Raport pokazuje między innymi, że organizacje osiągające największą wartość z AI częściej fundamentalnie przeprojektowują workflow oraz posiadają bardziej dojrzałe praktyki związane z pomiarem, leadershipem i zarządzaniem ryzykiem.

The state of AI in 2026 – McKinsey & Company

2. McKinsey & Company — The key to AI value is hiding in plain sight: Your operating model

Analiza z września 2026 roku dotycząca sposobu organizowania przedsiębiorstwa wokół AI. McKinsey wskazuje między innymi, że prawie trzy czwarte AI high performers fundamentalnie przeprojektowuje workflow w związku z AI, podczas gdy robi to około jednej czwartej pozostałych organizacji.

The key to AI value is hiding in plain sight – McKinsey & Company

3. McKinsey & Company — From adoption to impact: Three horizons of AI transformation

Materiał z 2026 roku pokazujący przejście od indywidualnego używania AI przez zmianę workflow do bardziej kompleksowej transformacji organizacji.

From adoption to impact – McKinsey & Company

4. OECD / BCG / INSEAD — The Adoption of Artificial Intelligence in Firms

Raport dotyczący praktycznej adopcji AI w przedsiębiorstwach. Omawia między innymi problemy związane z dojrzałością danych, kompetencjami, integracją, wyborem zastosowania oraz trudnością oszacowania zwrotu z inwestycji.

The Adoption of Artificial Intelligence in Firms – OECD

5. OECD / BCG / INSEAD — Survey of AI-Adopting Enterprises

Badanie przedsiębiorstw aktywnie korzystających z AI w krajach G7. Pokazuje między innymi trudność oszacowania ROI oraz znaczenie dostępu do odpowiednich danych i infrastruktury.

Key findings from the OECD/BCG/INSEAD Survey of AI-Adopting Enterprises – OECD

6. NIST — Artificial Intelligence Risk Management Framework 1.0

Dobrowolny framework National Institute of Standards and Technology dotyczący zarządzania ryzykiem systemów AI. Obejmuje cztery główne funkcje: Govern, Map, Measure i Manage.

NIST AI Risk Management Framework

7. NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

Rozszerzenie AI RMF dotyczące ryzyk charakterystycznych dla generatywnej sztucznej inteligencji oraz działań wspierających zarządzanie nimi w cyklu życia rozwiązania.

NIST Generative AI Profile

8. European Commission — AI talent, skills and literacy

Oficjalne informacje Komisji Europejskiej dotyczące AI literacy oraz art. 4 AI Act. Przepis zaczął być stosowany 2 lutego 2025 roku i dotyczy działań wspierających odpowiedni poziom kompetencji osób wykorzystujących systemy AI.

AI talent, skills and literacy – European Commission

9. European Commission AI Act Service Desk — Implementation timeline

Aktualny harmonogram wdrażania AI Act uwzględniający zmiany wynikające z Digital Omnibus. Obejmuje między innymi zastosowanie większości kolejnych przepisów od 2 sierpnia 2026 roku oraz późniejsze terminy dotyczące określonych systemów wysokiego ryzyka.

AI Act implementation timeline – European Commission

10. European Data Protection Board — Opinion on AI models and GDPR

Opinia Europejskiej Rady Ochrony Danych dotycząca wykorzystywania danych osobowych przy opracowywaniu i wdrażaniu modeli AI, w tym kwestii anonimowości, podstaw prawnych i przetwarzania danych.

Opinia EROD w sprawie modeli AI – European Data Protection Board