5 powodów, dla których działy IT nie chcą AI w Twojej firmie

Właściciel wraca z konferencji albo od znajomego, który „już ma AI”, i mówi: wdrażamy. Dział IT, własny albo firma zewnętrzna od serwerów, odpowiada: „jeszcze nie”, „to niebezpieczne”, „najpierw to przeanalizujemy”. Mija kwartał. Wdrożenie AI w firmie stoi, a właściciel nie wie, czy to ostrożność, czy opór.

Znam ten moment z obu stron stołu. Przez ponad dwadzieścia lat siedziałem po stronie biznesu, w sprzedaży i marketingu, i regularnie chodziłem do IT z prośbą o dostęp albo o narzędzie. Kilka lat temu zbudowałem sobie nowy zawód, buduję automatyzacje i wdrażam AI, więc dziś to ja słyszę pytanie „a co z danymi?”.

Im dłużej to robię, tym rzadziej uważam, że IT przesadza. Powody, które wymieniam niżej, są po kolei sensowne i sam bym je podniósł na ich miejscu. Kłopot zaczyna się gdzie indziej: z sensownej ostrożności robi się blokada, bo nikt nie powiedział informatykowi, że wolno mu tę sprawę poprowadzić. Wdrożenia, które widziałem, ruszały dopiero w momencie, gdy IT dostawało mandat do pisania zasad, a nie kolejne pytanie, czy się zgadza.

Pięć pierwszych powodów słyszę od lat. Szósty dopisałem dosłownie w ostatniej chwili, bo wyszedł w rozmowie z działem IT dużej firmy produkcyjnej i okazał się najświeższy z całej listy.

1. Strach o pracę i pozycję, czyli powód, którego nie usłyszysz wprost

Zacznę od siebie sprzed lat, bo byłem wtedy tą uciążliwą stroną. Potrzebowałem dostępu do raportu sprzedażowego. Wysłałem zgłoszenie, dostałem numer sprawy i czekałem. Nie dni, tygodnie. Irytowało mnie to i uważałem, że IT celowo gra na zwłokę. Dziś wiem, że w kolejce przede mną stały inne zgłoszenia, a człowiek, który miał je obsłużyć, był jeden.

Ale w tamtym układzie informatyk był w firmie tym, który wie. Żargon, nazwy urządzeń, uprawnienia, procedury. Żeby cokolwiek załatwić, trzeba było iść z prośbą i poczekać.

Teraz pracownik z handlowego wkleja arkusz do czatu i w minutę ma to, po co kiedyś szedł do IT: wyciągnięte dane, wytłumaczony komunikat błędu. Informatyk widzi dwie rzeczy naraz. Że może przestać być potrzebny. I że za chwilę będzie tym, który spowalnia.

Część tej obawy jest po prostu prawdziwa. W badaniu ManpowerGroup z 2025 r. część specjalistów IT w Polsce wskazała rozwój AI jako zagrożenie dla własnej pozycji zawodowej. Trudno z entuzjazmem bronić zmiany, która może odebrać człowiekowi status. Ja bym nie bronił.

To, co tę obawę zdejmuje, jest banalne i dlatego rzadko wypowiadane na głos. Rola się nie kurczy, tylko przesuwa. Do tej pory liczyło się „wiem, jak to obsłużyć”. Od teraz liczy się „wiem, jak to bezpiecznie udostępnić”, a tej kompetencji nikt inny w firmie nie ma. To IT pisze zasady używania AI: kto, do czego, na jakich danych, na jakich kontach. Hamulcowym przestaje być w chwili, gdy zamiast pytania „czy wolno” dostaje pytanie „na jakich warunkach”.

Sprawdzam to w każdym projekcie i działa pod jednym warunkiem: pytam IT pierwszych, zanim pokażę cokolwiek zarządowi. Jak pokażę najpierw zarządowi, dostaję potem uwagi do zasad użycia w formie, której nikt nie lubi czytać.

2. Shadow AI

Pytanie, które słyszę od informatyków najczęściej, brzmi tak: „Dobrze, a kto to potem posprząta?”.

Nie jest to pytanie o technologię. Dział IT wie, że ludzie w firmie używają AI. Na prywatnych kontach, w darmowych wersjach, czasem wklejają rzeczy, których wklejać nie wolno. Ma to swoją nazwę: shadow AI, czyli używanie narzędzi AI poza wiedzą i zgodą firmy. Obawa nie bierze się z niewiedzy. Bierze się z tego, że kto nagłośni sprawę, ten dostanie ją do posprzątania, bez czasu i bez mandatu. Formalna niewiedza jest wygodniejsza. Rozumiem to, sam bym tak zrobił na jego miejscu.

To nie jest wrażenie z paru rozmów. W kwietniowym raporcie PARP o sztucznej inteligencji w firmach, na próbie 1 822 polskich firm, obawy o bezpieczeństwo, prywatność i cyberataki wskazało 65% badanych i była to bariera numer jeden. Wśród firm, które już używają AI, najczęściej wskazywanym zagrożeniem jest naruszenie ochrony danych firmowych (47%).

Ale najbardziej dało mi do myślenia co innego. W tegorocznym badaniu ISACA, na ponad 3 400 specjalistów, 90% widzi użycie AI przez pracowników, a tylko 38% organizacji ma pełną politykę AI. Te dwie liczby obok siebie opisują dokładnie tę sytuację: wszyscy wiedzą, prawie nikt nie ma czym tego objąć. Informatyk, który to wie i nie ma czym tego objąć, wybiera milczenie. O tym, co dzieje się z danymi wklejonymi do darmowego czatu, pisałem osobno w tekście o zagrożeniach AI w firmie.

Odpowiedź na pytanie „kto to posprząta” nie jest ambitna. Rejestr narzędzi AI: kto, czego, na jakich danych. Jedna bramka wejścia dla nowych narzędzi. Zasady użycia na jednej stronie. Krótkie szkolenie dla ludzi. To są gotowe klocki. IT nie musi tego projektować od zera. IT dostaje rolę autora reguł, a sprzątanie po każdym incydencie przestaje być jego etatem.

W firmach, z którymi pracuję, pierwsza lista „kto czego używa” powstaje w tydzień. I zwykle bardziej zaskakuje zarząd niż IT. IT wiedziało od dawna. Zarząd widzi to pierwszy raz i wtedy dopiero zaczyna się rozmowa o mandacie.

3. Nie wiemy, jak tym zarządzać, i nie chcemy być właścicielem

Ta sekcja zaczyna się od dokumentu, bo to jedyny powód, w którym argument rozstrzyga przepis, a nie doświadczenie.

Artykuł 4 unijnego rozporządzenia o AI, w brzmieniu obowiązującym od 27 lipca 2026 r., brzmi tak:

„Dostawcy i podmioty stosujące systemy AI podejmują środki, które wspierają rozwój kompetencji w zakresie AI wśród swojego personelu i innych osób zajmujących się działaniem i wykorzystaniem systemów AI w ich imieniu […]. Taki obowiązek nie oznacza, że dostawcy lub podmioty mają zapewniać osiągnięcie określonego poziomu kompetencji w zakresie AI przez poszczególne osoby.” — art. 4 ust. 1 rozporządzenia (UE) 2024/1689 w brzmieniu nadanym rozporządzeniem (UE) 2026/1744; w miejscu […] pominięto fragment o wiedzy technicznej i kontekście użycia

Czytam to zdanie działom IT na spotkaniach i zwykle zapada cisza, bo spodziewają się czegoś zupełnie innego. Prawo nie wymaga certyfikowanego eksperta ani osiągnięcia jakiegoś poziomu przez konkretne osoby. Wymaga środków wspierających rozwój kompetencji, czyli na przykład szkolenia i prostego szkieletu polityki. Podstawowe szkolenie udostępniam bezpłatnie właśnie dlatego, że to jeden z takich środków, którego IT nie musi pisać samo.

Informatyk, który mówi „nie wiem, jak tym zarządzać”, mówi prawdę i ma prawo nie wiedzieć. Przepisy są świeże, IT nie ma kompetencji prawnych i nie uważa, że powinno je mieć. W firmie nie ma prawnika od tych spraw ani osoby, która spinałaby całość. Efekt idzie łańcuchem: nie ma polityki AI, więc nie ma planu wykorzystania AI, więc nie ma procedur, więc problemy wychodzą po kolei. A kto podniesie pierwszy, ten zostaje jego właścicielem. Nikt nie chce być pierwszy.

Liczby mówią to samo, tylko chłodniej. W badaniu PARP brak lub niejasność przepisów to trzecia bariera (58%), a brak kompetencji i wiedzy czwarta (53%). W badaniu AvePoint, 750 organizacji, zgodność z regulacjami niepokoi 69,1% respondentów. Jest na to nazwa, „ai governance”, czyli zasady zarządzania użyciem AI w firmie: kto decyduje, kto odpowiada, co wolno. W polskim internecie ta nazwa prawie nie istnieje. Nie wiem, czy się u nas przyjmie, szczerze mówiąc wolałbym, żeby się nie przyjęła w tej formie. Trudno zarządzać czymś, czego nie da się nawet wygooglować po polsku.

Szkielet polityki AI, z którego korzystam, ma cztery strony. Dział IT nie pisze od zera, tylko skreśla i dopisuje. To ta jedna godzina, w której z „nie” robi się „tak, ale na naszych warunkach”. Dobrze, że tak jest. Ich warunki są zwykle ostrzejsze niż moja pierwsza wersja.

4. Bezpieczeństwo, czyli pierwszy w pełni racjonalny powód

89,5%. Tyle organizacji w ankiecie AvePoint miało w ciągu roku incydent związany z generatywną AI. Przy takiej liczbie przestaje mieć znaczenie, czy ktoś jest ostrożny z natury.

Mnie samemu w tym roku klucz dostępu do usługi AI trafił do publicznie widocznych plików wdrożenia. Znalazłem go przy przeglądzie własnych projektów, nie zgłosił mi tego żaden alarm. Naprawa polegała na wstawieniu pośrednika po stronie serwera, żeby klucz nie wychodził już do przeglądarki, i kosztowała mnie dzień. Robię to zawodowo, i mimo to. Kiedy więc informatyk mówi, że boi się wycieku, nie opowiada mi bajki o cyberprzestępcach. Opowiada o czymś, co przydarzyło się mnie.

Za cyberbezpieczeństwo odpowiada IT i nikt tego z niego nie zdejmie. Jeśli firma ma używać AI, to IT powinno przygotować narzędzia i mechanizmy: konta firmowe zamiast prywatnych, usługi z gwarancją przetwarzania danych w Unii, zasady „jakie dane wolno, a jakich nie”. Tylko że to dodatkowa praca, dodatkowa odpowiedzialność i, przede wszystkim, wiedza, której IT często nie ma. Rachunek za jej brak i tak wystawi się jemu.

Dochodzi cecha, o której informatycy mówią częściej niż menedżerowie. AI nie jest modelem deterministycznym, czyli na to samo pytanie potrafi odpowiedzieć dwa razy inaczej. Takiego systemu nie da się przetestować i odhaczyć jak zwykłego programu. W badaniu ISACA tylko 12% organizacji ma przetestowaną procedurę wyłączenia systemu AI po incydencie. Mam wrażenie, że to jest liczba, która powinna niepokoić bardziej niż wszystkie pozostałe razem wzięte, i nie wiem, dlaczego prawie nikt jej nie cytuje.

Praktyka, którą stosuję, jest prosta i zapewne zbyt prosta dla dużej firmy, ale u klientów o 20 do 500 osobach wystarcza. Dzielę dane na trzy grupy, zanim cokolwiek uruchomimy, i tak sobie to nazywam: półki. Dane publiczne idą do chmury, dowolne narzędzie firmowe. Dane klientów też do chmury, ale z umową powierzenia, czyli formalną zgodą na przetwarzanie Twoich danych przez dostawcę, z regionem w UE i z wyłączonym uczeniem modelu na naszych danych. To sprawdza się w umowie, nie w reklamie. Dane wrażliwe zostają na modelu uruchomionym lokalnie, na komputerze w firmie, bez wysyłania czegokolwiek na zewnątrz. Do tego konta firmowe i wiedza dostarczona z zewnątrz, szkoleniem, a nie wymagana od IT przy okazji.

Osobny temat to agenci AI, czyli programy, które same wykonują zadania w systemach firmy. Podnoszą ryzyko o poziom wyżej i opisałem je w tekście o agentach AI OpenClaw i Hermes. Zasada zostaje ta sama co w artykule o zagrożeniach AI: najpierw ustalam półkę, potem dobieram do niej narzędzie. Nigdy odwrotnie.

Sam dokumenty wrażliwe przetwarzam na modelu lokalnym, na własnym komputerze. Kosztuje to prąd i chwilę cierpliwości, bo lokalny model jest wolniejszy od chmury. Za to pytanie „gdzie są te dane” ma jedną odpowiedź.

5. Koszty, czyli drugi w pełni racjonalny powód

Ta rozmowa wygląda zwykle tak:

— Ile to będzie kosztowało miesięcznie? — Zależy, ile razy tego użyjecie. — To znaczy, że nie wiesz. — Nie wiem. Ale wiem, jak zrobić, żeby nie przekroczyło kwoty, którą ustalicie.

Informatyk, który słyszy pierwszą część tej odpowiedzi, ma pełne prawo się zjeżyć. Licencja to stała kwota, raz w roku, wiadomo ile. AI to opłata za zużycie: za pytanie, za dokument, za każdą operację automatu. Jedna pętla w źle napisanym automacie potrafi spalić miesięczny budżet w jedną noc. IT widziało już faktury-niespodzianki z chmury i nie chce podpisywać się pod następną. Dochodzi koszt, którego na fakturze nie widać: czas i pieniądze na wiedzę, o którą nikt nie prosił.

Mnie też się to przytrafiło, a nie zamierzam przepłacać, jeśli nie muszę. W kwietniu tego roku Google Cloud pobrał z mojej karty 200 zł, których się nie spodziewałem, za usługę, którą uważałem za darmową w używanym zakresie. Kwota niewielka. Lekcja: liczyć, zanim się uruchomi, nie po fakcie. W badaniu PARP wysokie koszty wdrożenia to druga bariera (63%), tuż za bezpieczeństwem.

Druga część mojej odpowiedzi z tej rozmowy wygląda tak. Operacja ma cenę w jednostkach, użytkownik ma limit dzienny i miesięczny, system sprawdza saldo, zanim cokolwiek wykona, a alarm odzywa się przy 80% budżetu. Modele lokalne tam, gdzie dane są wrażliwe, i wtedy koszt to prąd. I pilotaż z kwotą ustaloną z góry: testujemy za 300 zł, potem decydujemy. IT nie musi nikomu wierzyć na słowo, bo widzi licznik.

Taki licznik działa w mojej własnej aplikacji, w której AI ocenia dokumenty. Ładny nie jest, natomiast działa. A automat, który codziennie ocenia dla mnie kilkadziesiąt źródeł branżowych, kosztuje po przeliczeniu około 1 zł miesięcznie, bo ktoś policzył, zanim go uruchomił.

6. IT nie nadąża za tempem, w jakim rozwija się AI

Ten powód dopisuję na końcu, bo wyszedł w rozmowie, którą miałem tuż przed napisaniem tego tekstu, w dziale IT dużej firmy produkcyjnej. Nie było w niej mowy o wycieku ani o koszcie. Było zdanie, które chodzi za mną od tamtego dnia: nie nadążamy za tempem zmian w AI i za tym, co te narzędzia dają.

To nie jest ten sam strach co w punkcie pierwszym. Tam chodziło o pozycję. Tutaj o rytm pracy.

Ja pracuję czasami nad dziesięcioma rzeczami naraz. Jedna rzecz się liczy w tle, druga czeka na moją decyzję, trzecia jest w połowie, a w międzyczasie wychodzi narzędzie, które robi to, nad czym siedziałem wczoraj, i muszę je sprawdzić. Dział IT przywykł do jednego projektu naraz: analiza, wdrożenie, odbiór, utrzymanie, następny. To nie jest wada, to inny model pracy, wypracowany po to, żeby firma miała działającą sieć i działające systemy przez cały czas. Tylko że przy takim rytmie każde nowe narzędzie, które ktoś taki jak ja przynosi, wchodzi do kolejki, a kolejka rośnie szybciej, niż da się ją obsłużyć.

I nikt tu nikogo nie oszukuje. IT nie ma jak poznać, ocenić i wpiąć rzeczy, które pojawiają się co tydzień, a jednocześnie ma utrzymać wszystko, co już działa. Sam nie nadążam, a to jest moja praca na pełny etat i nie odpowiadam przy tym za czyjeś serwery.

Rzecz, którą proponuję najpierw, jest jedna i wygląda banalnie: okno wydawnicze. Zamiast puszczać narzędzia do IT wtedy, kiedy są gotowe, zbieram je i oddaję w paczkach co dwa tygodnie. Moje dziesięć równoległych rzeczy zamienia się wtedy w jedną kolejkę, którą IT obsługuje swoim zwykłym procesem, bez uczenia się nowego. Przy okazji ja przestaję przynosić rzeczy, które za tydzień i tak bym wycofał, bo dwa tygodnie wystarczą, żeby połowa pomysłów odpadła sama.

Reszta to już drobiazgi, które wynikają z tego okna. Rejestr narzędzi z właścicielem i stanem: prototyp, pilot, produkcja, przy czym prototyp nie wymaga niczyjej zgody, bo nie dotyka firmowych danych. Panel testowy poza produkcją, żeby obejrzenie nowego narzędzia nie oznaczało wpuszczenia go do systemu. Dokumentacja pisana razem z narzędziem, a nie tydzień po nim, bo to od niej zależy, czy IT w ogóle jest w stanie to utrzymać. I spisane raz kryterium, co IT musi przejrzeć, a co jest poza jego odpowiedzialnością, obowiązujące w obie strony.

Jest jeszcze rzecz, której nie umiem załatwić procedurą. Wspólna nauka. Ten sam materiał o narzędziach, który ma osoba wdrażająca, powinien dostać dział IT. Bez tego rozjazd tylko rośnie: jedna strona zna możliwości i nie zna ograniczeń infrastruktury, druga zna infrastrukturę i ogląda narzędzia dopiero w zgłoszeniu.

I jeszcze jedno, czego nie ma w badaniach: rozproszone kompetencje

Tego nie znajdziesz w żadnym raporcie, bo trudno to zmierzyć. Widzę to jednak w małych i średnich firmach częściej niż połowę rzeczy wymienionych wyżej.

Nikt nie ma całego obrazu. Kierowanie IT bywa zlecone firmie zewnętrznej, ta zna sieć i serwery. Osoby od wewnętrznych systemów znają swoje systemy i niewiele poza nimi. Ktoś inny widzi ryzyka bezpieczeństwa, ale nie ma mandatu, żeby o nich decydować. A zewnętrzny wykonawca zbudował kiedyś rozwiązanie, które częściowo już działa i o którym połowa firmy nie wie.

I w taki układ wpada polecenie: „zbudujcie narzędzie z AI”. Trafia do kilku osób, z których żadna nie zna całej infrastruktury, dostępów i zasobów. Każda z obaw wyżej robi się w takim układzie silniejsza, bo nikt nie może powiedzieć „biorę to na siebie”. Nie ma z czego. Ten wzorzec ma nazwę: silosy wiedzy. Informacje o systemach żyją w głowach kilku osób. W firmie, rozumianej jako dokumenty i procedury, ich nie ma. Kiedy któraś z nich odchodzi, wiedza odchodzi razem z nią.

Zanim ktokolwiek zacznie budować, potrzebna jest jedna mapa: kto co wie, kto ma jakie dostępy, gdzie leżą dane, co już działa. To tydzień pracy koordynatora z mandatem, nie kwartał, i ta praca procentuje przy każdym kolejnym projekcie. W firmie produkcyjnej, z którą pracowałem, sama ta mapa wyjaśniła, dlaczego wcześniejsze podejścia do automatyzacji utknęły. Każde zaczynało od innego fragmentu układanki i żadne nie widziało całości.

Co z tego wynika dla właściciela

Prawie wszystkie te powody mają jeden rdzeń. AI jest dla działu IT dodatkową pracą, dodatkową odpowiedzialnością i, przede wszystkim, wiedzą, której IT często nie ma. Tej wiedzy nikt nie nabędzie za darmo i z własnej inicjatywy, dopóki nie dostanie polecenia, czasu i mandatu z góry. Stąd opór, najczęściej bierny, czasem czynny. Nie ma w tym złej woli. Jest reakcja na zadanie, które ktoś dorzucił na biurko bez budżetu.

Czyli „nie” z IT nie ocenia technologii. Mówi o brakującym mandacie.

Można próbować samemu i da się przejść tę drogę, tylko trzeba się liczyć z oporem i z kilkoma błędami po drodze. Każda obawa wyżej to jeden z nich: dane klientów w darmowym czacie, faktura-niespodzianka, polityka AI pisana po incydencie, narzędzie bez właściciela, projekt rozbity między kilka osób bez mapy. Płaci się za nie czasem, pieniędzmi i, najdrożej, zaufaniem IT do kolejnych prób. Druga droga to ktoś, kto te procesy już przeszedł, wie, czego się spodziewać, i wie, jak rozbroić problem, zanim urośnie. Ktoś, kto ustali zasady razem z IT, wskaże półkę danych, ograniczy koszt, przeszkoli ludzi i zdejmie z IT samotną odpowiedzialność.

Tę drugą rolę pełnię ja. Ponad dwadzieścia lat na stanowiskach menedżerskich w zarządzaniu, sprzedaży i marketingu, w małych firmach i w dużych korporacjach. Nawyki mam korporacyjne i nie ukrywam tego, bo w takim projekcie akurat się przydają. Od ponad siedmiu lat buduję automatyzacje biznesowe, od ponad trzech wdrażam rozwiązania oparte na AI. Nie obiecuję cudów i nie wchodzę do firmy obok IT, wchodzę razem z nim. Najchętniej od małej próby, żeby obie strony zobaczyły, czy ta współpraca idzie.

Zanim jednak zadzwonisz do kogokolwiek, w tym do mnie, zadaj u siebie sześć pytań. Odpowiedzi na nie są ważniejsze niż wybór narzędzia:

1. Kto pisze zasady używania AI w firmie i czy IT wie, że to jego rola, a nie kolejny obowiązek bez mandatu?
2. Czego ludzie używają dziś, czy mamy listę narzędzi AI, kont i danych, które do nich trafiają?
3. Kto jest właścicielem polityki AI: jedno nazwisko, wewnątrz albo z zewnątrz, z czasem na to zadanie?
4. Na której półce leżą nasze dane, publiczne, klientów czy wrażliwe, i co z tego wynika dla wyboru narzędzia?
5. Jaki jest limit kosztu: kwota pilotażu, limit dzienny, kto dostaje alarm?
6. Kto ma mapę, czyli kto zna infrastrukturę, dostępy i to, co już działa, i czy ta wiedza jest spisana, czy siedzi w głowach?

Jeśli na trzy z sześciu odpowiedź brzmi „nie wiem”, to jest typowy punkt startu i nie ma w tym nic wstydliwego. To nie wina IT, tylko stan organizacji. Rozmowa, która to zmienia, zaczyna się od jednego zdania właściciela do informatyka: „ty piszesz zasady, ja daję czas i budżet, a ktoś spina całość”. Jeśli chcesz, żebym usiadł do niej razem z Tobą i Twoim IT, napisz przez formularz kontaktowy, na kontakt@aiwbiznesie.online albo zadzwoń: 602 486 311. Nie namawiam do wdrożenia. Zaczynamy od przeglądu praktyk AI, czyli od jednego pytania: co w firmie już używa AI, na jakich danych i kto za to odpowiada.

Najczęstsze pytania o wdrożenie AI w firmie i opór działu IT

Czy dział IT może zablokować wdrożenie AI w firmie?

Formalnie decyduje zarząd. W praktyce IT blokuje skutecznie: brakiem czasu, brakiem odpowiedzi, analizą bez końca. To bierny opór i jest racjonalny, bo bez mandatu, budżetu i wiedzy IT nie ma jak wziąć na siebie odpowiedzialności.

Co powinna zawierać polityka AI w firmie 20–500 osób?

Jedna strona, nie regulamin: lista dozwolonych narzędzi i kont, trzy półki danych (co wolno wkleić i gdzie), właściciel polityki z nazwiska, ścieżka zgłaszania nowego narzędzia i zasada „liczba, nazwa i paragraf od AI to hipoteza do sprawdzenia, nie fakt”.

Czy firma musi mieć certyfikowanego specjalistę od AI?

Nie. Art. 4 rozporządzenia o AI w brzmieniu od 27 lipca 2026 r. wymaga „środków wspierających rozwój kompetencji”, a nie osiągnięcia określonego poziomu przez konkretne osoby. Szkolenie, wewnętrzna instrukcja i rejestr działań to takie środki. Przepisy się zmieniają, więc przed decyzją sprawdź aktualne brzmienie. Jeśli firma używa AI do decyzji o ludziach albo działa w branży regulowanej, to inny przypadek niż chatbot do pisania ofert i tam potrzebna jest konsultacja prawna.

Od czego zacząć, jeśli IT mówi „nie”?

Od rozmowy, w której IT dostaje rolę autora zasad, a nie kolejne zadanie. Potem sześć pytań z listy wyżej, krok po kroku, bez narzędzia na stole.