Kto właściwie odpowiada za AI w firmie? (oraz webinar 31.08 - poniedziałek)

CEO? CIO? CTO? Prawnik? AI Lead(er)? Właściciel procesu? Dostawca?

Najwygodniejsza odpowiedź brzmi: wszyscy.

Problem w tym, że w organizacjach „wszyscy” = nikt. Odpowiedzialność się rozmywa, nie da się niczego ustalić.

AI jest szczególnie podatne na ten problem, bo przecina kilka światów jednocześnie. Dotyka technologii, danych, procesów biznesowych, prawa, bezpieczeństwa, ludzi i pieniędzy. Dlatego trudno wskazać jedną osobę, która powinna „odpowiadać za AI”.

Więcej o webinarze przeczytasz tutaj: https://aileaders.pl/webinar-ai-leaders-poniedzialek-31-08-2026-19-00-online/

I być może właśnie nie powinniśmy jej szukać.

Znacznie ważniejsze jest rozdzielenie odpowiedzialności za kilka różnych rzeczy:

• kto decyduje, gdzie w ogóle warto użyć AI,
• kto odpowiada za wynik biznesowy tej części procesów w firmie,
• kto zatwierdza technologię i dane,
• kto ocenia ryzyko,
• kto odpowiada za wdrożenie,
• i wreszcie najtrudniejsze: kto pilnuje systemu pół roku później, kiedy projekt już dawno przestał być „projektem AI” i stał się częścią procesu, często zmienionego.

Patrzymy na ten problem z trzech perspektyw: Ingi, Pauli i Przemka.

Inga: „Dostawca rozwiązania AI może dowieźć system, doradzić, ale nie powinien być właścicielem Twojego biznesu”

Pracując przy wdrożeniach AI po stronie dostawcy, bardzo często zaczynam rozmowę z klientem od kilku prostych pytań:

Co chcecie poprawić?

Jak mierzycie to dzisiaj?

Kto po Waszej stronie odpowiada za ten wynik?

I właśnie przy trzecim pytaniu zaczynają się problemy. Jest sponsor, często z zarządu. Jest dział IT. Jest procurement. Jest security. Czasem jest już powołany AI Lead albo cały AI Committee. Jest dostawca.

Tylko nadal nie wiadomo, kto jest osobą, której naprawdę zależy na wyniku tego rozwiązania. Żeby na przykład czas obsługi klienta spadł o 30%, konwersja wzrosła o 5 czy 50% albo koszt obsługi dokumentu zmniejszył się z 12 do 3 zł.

To jest właściciel biznesowy procesu. I z mojej perspektywy to nadal jedno z najczęściej brakujących ogniw wdrożeń AI: taki jednorożec, który ponoć gdzieś jest, ale nikt go nie widział.

Dostawca nie zastąpi właściciela biznesowego

Dobry dostawca powinien umieć powiedzieć: „U innych klientów mierzymy tutaj takie parametry”. Powinien zakwestionować źle postawiony KPI. Powinien zauważyć, że automatyzujecie fragment procesu, który wcale nie jest głównym problemem. Czasem nawet powinien powiedzieć: „Nie potrzebujecie tutaj AI”.

Ale dostawca nie powinien sam ustalać, co jest sukcesem biznesowym firmy.

A kto odpowiada za co?

Najprościej rozdzieliłabym to tak:

• Kierunek i priorytety AI: zarząd lub sponsor biznesowy
• Wybór konkretnego use case'u: właściciel procesu
• Wynik biznesowy i KPI: właściciel procesu
• Koordynacja inicjatyw AI: AI Lead, AI CoE lub Head of AI
• Architektura, integracje, utrzymanie: IT, CTO lub CIO
• Dane i dostęp do danych: właściciele danych i IT
• Ryzyko prawne i compliance: Legal, Compliance lub DPO
• Budowa i jakość rozwiązania: zespół technologiczny lub dostawca
• Adopcja rozwiązania: biznes i managerowie zespołów
• Monitoring po wdrożeniu: biznes, IT i dostawca, zależnie od metryki

Najważniejsza rzecz: AI Lead nie powinien być właścicielem wszystkich wyników biznesowych związanych z AI.

Jeżeli organizacja ma rozwiązania AI w sprzedaży, customer service, HR, finansach i operacjach, jedna osoba nie może odpowiadać za wynik każdego z tych obszarów.

AI Lead powinien spinać system: portfolio, standardy, wiedzę, wspólne komponenty, governance i drogę od pomysłu do produkcji.

Nie zastępować właścicieli biznesowych.

Governance powinien rosnąć razem z problemem

Nie jestem też zwolenniczką kopiowania modelu dużej korporacji do każdej organizacji.

Nie każda firma potrzebuje AI Council, AI CoE, Chief AI Officera i rozbudowanego RACI.

Jeżeli prowadzicie trzy inicjatywy AI, możecie potrzebować tylko:

• sponsora, który potrafi ustawić priorytety,
• właściciela biznesowego dla każdego rozwiązania,
• osoby odpowiedzialnej za technologię, bezpieczeństwo i dostęp do danych,
• jasnej ścieżki oceny ryzyka.

Sytuacja zmienia się, kiedy inicjatyw jest kilkanaście. Marketing kupuje jedno narzędzie. Sprzedaż testuje drugie. HR ma Copilota. IT buduje asystenta. Customer Service rozmawia z dostawcą voicebota.

Wtedy problemem przestaje być samo uruchamianie kolejnych eksperymentów. Pojawia się pytanie, czy firma przypadkiem nie buduje pięciu osobnych światów AI. I tutaj AI Lead albo niewielkie AI CoE zaczyna mieć znacznie większy sens. Nie po to, żeby zatwierdzać każdy eksperyment. Po to, żeby pilnować wspólnych zasad, dostawców, architektury, ryzyka, portfolio i tego, czego organizacja nauczyła się z poprzednich wdrożeń.

W dużej skali naturalnie prowadzi to do modelu federacyjnego. Centralnie ustalamy boisko gry: architekturę, bezpieczeństwo, polityki, preferowane platformy, proces oceny ryzyka i sposób zarządzania portfolio.

Natomiast odpowiedzialność za wynik pozostaje tam, gdzie znajduje się proces.

Customer Service odpowiada za Customer Service. Sprzedaż za sprzedaż. HR za HR. Finanse za finanse.

Centralny zespół AI pomaga organizacji korzystać z AI dobrze. Nie przejmuje odpowiedzialności za prowadzenie każdego biznesowego procesu.

Paula: a kto odpowiada, kiedy AI zrobi coś źle?

W tym miejscu do organizacyjnego „kto odpowiada?” dochodzi jeszcze jedno, znacznie mniej wygodne pytanie: kto odpowiada prawnie, kiedy coś pójdzie źle?

I tutaj pierwsza rzecz, którą warto sobie wybić z głowy, brzmi: „mamy dostawcę, więc to on odpowiada za AI”. Nie. A przynajmniej nie zawsze.

Jeżeli firma kupuje system AI od zewnętrznego dostawcy, odpowiedzialność nie przesuwa się automatycznie razem z fakturą. Dostawca może odpowiadać za to, co zbudował i dostarczył. Organizacja korzystająca z systemu może odpowiadać za to, po co go użyła, na jakich danych, wobec jakich osób, z jakim nadzorem i co zrobiła z jego wynikiem. A czasem obie strony mogą odpowiadać jednocześnie, tylko za coś innego.

Umową można przesunąć pieniądze, odpowiedzialność niekoniecznie

Załóżmy, że firma wdraża system wspierający rekrutację. Dostawca zapewnia, że rozwiązanie zostało przetestowane, spełnia określone parametry jakościowe i może być używane do wskazanego celu.

Firma natomiast decyduje, że system będzie oceniał kandydatów, zasila go własnymi danymi, ustala sposób wykorzystywania wyniku i określa, czy człowiek może rekomendację AI zmienić albo zignorować.

Jeżeli potem okaże się, że system systematycznie dyskryminuje określoną grupę kandydatów, to musimy rozłożyć problem na atomy. Czy problem tkwił w samym systemie? Czy dostawca nie poinformował o jego ograniczeniach? Czy firma używała go do celu, do którego nie był przeznaczony? Czy wprowadzała niewłaściwe dane? Czy człowiek miał sprawować nadzór, ale w praktyce tylko bezrefleksyjnie klikał „zaakceptuj”? Czy organizacja wiedziała, że jakość spada, ale dalej korzystała z rozwiązania?

Dopiero jak się tego dowiemy, możemy realnie zacząć odpowiadać na pytanie o odpowiedzialność. Dlatego postanowienie w umowie w stylu „dostawca ponosi pełną odpowiedzialność za działanie AI” wnosi tyle, ile ja do sympozjum fizyków kwantowych. Nic.

Aby jednak nie być aż tak brutalną: może to być za to całkiem ważne dla wzajemnych rozliczeń stron, regresu, kar umownych czy obowiązku pokrycia określonych szkód. Ale nie sprawi, że regulator, pracownik, kandydat czy klient przestanie interesować się zachowaniem firmy korzystającej z rozwiązania.

Można więc delegować zadania. Można kontraktowo rozdzielić ryzyka. Ale nie zawsze można delegować obowiązek wynikający bezpośrednio z prawa.

Prawo nie czyta Waszego RACI

AI Act bardzo dobrze pokazuje tę logikę. Nie tworzy jednej kategorii pod tytułem „ten, kto odpowiada za AI”, tylko rozdziela role w łańcuchu: mamy m.in. dostawcę systemu i podmiot wdrażający, czyli organizację, która korzysta z niego w swojej działalności. Każdy odpowiada za inny kawałek układanki.

W przypadku systemów wysokiego ryzyka dostawca odpowiada m.in. za zgodność samego systemu z wymaganiami, dokumentację, ocenę zgodności czy system zarządzania jakością. Ale podmiot korzystający z systemu też nie jest tylko biernym odbiorcą pudełka z technologią. Po jego stronie pojawiają się obowiązki dotyczące m.in. korzystania zgodnie z instrukcją, zapewnienia rzeczywistego nadzoru człowieka, odpowiednich danych wejściowych, monitorowania działania systemu czy reagowania na ryzyko i incydenty.

Co więcej, role potrafią się zmieniać. Firma, która kupiła cudzy system, może w określonych przypadkach sama zostać potraktowana jak jego dostawca, przykładowo wtedy, gdy dokona istotnej modyfikacji systemu wysokiego ryzyka albo zmieni jego przeznaczenie w sposób przewidziany przez AI Act. Możecie więc wpisać w RACI, że za AI odpowiada AI Lead. Tylko że z punktu widzenia prawa samo wpisanie nazwiska w komórkę Excela nie zmienia dostawcy w deployera ani deployera w dostawcę.

Zresztą AI Act przecież nie zna stanowiska „AI Lead”. To rola organizacyjna, nie kategoria odpowiedzialności prawnej. AI Lead może prowadzić governance, tworzyć standardy, pilnować portfolio, koordynować klasyfikację systemów, budować proces akceptacji, organizować monitoring. Może być człowiekiem, dzięki któremu cała organizacja działa rozsądniej. Ale powołanie AI Leada nie powoduje, że od tego momentu wszystko, co dotyczy AI, staje się jego osobistą odpowiedzialnością… i bardzo dobrze. Bo AI Lead nie powinien podejmować za HR decyzji, czy ryzyko związane z konkretnym procesem rekrutacyjnym jest akceptowalne. Nie powinien za CFO decydować, czy można zaakceptować błąd modelu na określonym poziomie w procesie finansowym. I nie powinien za zarząd ustalać apetytu organizacji na ryzyko.

W efekcie zarząd powinien mieć pewność, że istnieje system, który pozwala wiedzieć, jakiego AI używamy, do czego, z jakim ryzykiem i kto podejmuje decyzje. Powinien zapewnić zasoby i ustalić granice akceptowalnego ryzyka. AI Lead może ten system zaprojektować i prowadzić.

Kto zatem powinien podpisać się pod „GO LIVE”?

Też nie jedna osoba. Przed uruchomieniem potrzebujemy raczej kilku różnych odpowiedzi:

• Biznes: czy system robi wystarczająco dobrze to, co miał robić, i czy ryzyko błędu jest akceptowalne w tym konkretnym procesie?
• Technologia i security: czy rozwiązanie jest bezpieczne, stabilne, właściwie zintegrowane i czy wiemy, co dzieje się z danymi?
• Legal / Compliance / Privacy: czy sposób użycia mieści się w ramach prawnych i jakie warunki muszą zostać spełnione przed uruchomieniem?
• Właściciel procesu: czy biorąc pod uwagę wszystkie powyższe informacje, uruchamiamy rozwiązanie?

I właśnie tego ostatniego elementu często brakuje, bo mamy pięć pozytywnych opinii ekspertów, ale nie mamy człowieka, który rzeczywiście podejmuje decyzję: tak, przy tych parametrach i tych zabezpieczeniach akceptuję użycie AI w moim procesie.

PS. Jest jeszcze jeden powód, dla którego prawnik powinien pojawić się wcześniej niż na etapie negocjowania limitu odpowiedzialności. W projektach „ejajowych” wiele decyzji prawnych jest w rzeczywistości decyzjami projektowymi. Do czego system będzie używany? Kto zobaczy jego wynik? Czy rekomendacja jest tylko informacją, czy realnie wpływa na decyzję? Jak działa human oversight? Jakie logi przechowujemy? Jak użytkownik dowie się, że ma do czynienia z AI? Co zrobimy, jeżeli dostawca zmieni model bazowy? Jak sprawdzimy po sześciu miesiącach, czy jakość nie spadła? Jak szybko dostaniemy informacje potrzebne do obsługi incydentu?

Jeżeli prawnik dowiaduje się o projekcie dzień przed podpisaniem umowy, bardzo często może już tylko próbować kontraktowo naprawić decyzje technologiczne podjęte trzy miesiące wcześniej.

Znacznie sensowniejszy model to taki, w którym Legal pomaga na początku określić kilka „guardrailsów”: które przypadki wymagają głębszej analizy, jakie mamy hard stops, jakie dowody musimy zebrać i jakie wymagania trzeba przekazać dostawcy.

A kiedy AI naprawdę wyrządzi szkodę?

Wtedy oprócz umowy z dostawcą i wewnętrznych polowań na czarownice musimy dodać jeszcze kilka elementów, bo do gry mogą wejść równolegle odpowiedzialność kontraktowa, deliktowa, RODO, prawo konsumenckie, prawo pracy, regulacje sektorowe, a za chwilę także nowe europejskie przepisy o odpowiedzialności za produkt wadliwy.

Od grudnia 2026 r. nowy unijny reżim product liability (odpowiedzialności za produkt na gruncie dyrektywy PLD) obejmie wprost także software, w tym systemy AI. To kolejny powód, dla którego odpowiedź na pytanie „kto odpowiada za AI?” coraz częściej będzie wymagała spojrzenia na cały łańcuch dostarczania i używania technologii, a nie znalezienia jednego człowieka z tytułem „Head of AI”. W efekcie szukamy odpowiedzi na kilka pytań. Kto miał obowiązek zrobić konkretną rzecz, której nie zrobiono? Kto podjął decyzję o użyciu systemu w taki sposób? Kto wiedział o ryzyku? Kto mógł zatrzymać proces? I kto miał zareagować, kiedy system zaczął zachowywać się inaczej niż na początku? Dopiero z odpowiedzi na te pytania wyłania się rzeczywista odpowiedzialność.

Przemek: kto jest właścicielem AI jako produktu?

Albo inaczej zadane pytanie: czy AI jest produktem samo w sobie? Możemy dyskutować o tym, kto płaci i odpowiada za wdrożenie, na kim spoczywa odpowiedzialność oraz zgodność z prawem, zasadami czy wymaganiami. Jednak to, czy ktokolwiek w organizacji będzie naturalnie (ba, i nawet natywnie) wykorzystywać implementowaną technologię, jest zależne od osób, które potrafią zrozumieć wszystkie aspekty: biznesowe, techniczne, governance, prawne czy choćby UX-owe.

Jeszcze inaczej wygląda ten problem, kiedy AI przestaje być narzędziem, po które sięga pojedynczy pracownik, a staje się elementem produktu albo fundamentem całego procesu.

Różnica jest zasadnicza. Narzędzie można wymienić w piątek po południu i w poniedziałek nikt tego nie zauważy. Jeżeli model stoi w środku procesu obsługi klienta albo w środku Waszej oferty, jego wymiana nie jest zmianą licencji, tylko zmianą produktu. I wtedy pytanie „kto odpowiada za AI” rozpada się na zestaw znacznie mniej wygodnych pytań.

Build czy buy

Rzadko jest to pytanie o koszt. To pytanie o to, czy dany fragment AI jest źródłem Waszej przewagi, czy infrastrukturą. Za infrastrukturę się płaci, przewagi nie kupuje się w abonamencie, bo konkurencja może kupić to samo nazajutrz. Praktyczna odpowiedź zwykle leży pośrodku: kupujemy warstwę, która jest towarem (modele, hosting, bazy wektorowe, standardowe integracje), budujemy cienką warstwę, która jest nasza (dane domenowe, logika procesu, sposób oceny jakości). Jedno zastrzeżenie: „buy” nie oznacza „bez pracy”. Dane, integracja, zmiana sposobu pracy ludzi i utrzymanie zostają po Waszej stronie niezależnie od tego, czyje logo widnieje na fakturze.

Własny zespół czy dostawca

Pytanie brzmi: kto po dwóch latach będzie wiedział, jak to działa? Dostawca daje tempo i kompetencje od pierwszego dnia. Własny zespół daje kumulację wiedzy. Najgorszy wariant to ten, w którym po dwóch latach macie działający system i zero zrozumienia, dlaczego działa akurat tak. Minimalny bezpiecznik: przynajmniej jedna osoba wewnątrz organizacji, która rozumie rozwiązanie na tyle dobrze, żeby zakwestionować dostawcę, oszacować koszt wyjścia, zarządzić tworzeniem dokumentacji i poprowadzić migrację, gdyby trzeba było.

Jeden centralny stack czy dziesiątki lokalnych rozwiązań

To fałszywa alternatywa. Właściwe pytanie brzmi: która warstwa musi być wspólna? Wspólne powinno być to, czego nie da się sensownie powielić dziesięć razy: dostęp do danych, tożsamość i uprawnienia, logowanie, monitoring kosztów, sposób oceny jakości, lista dopuszczonych modeli i dostawców. Lokalne może zostać to, co jest blisko procesu: konkretne przypadki użycia, przepływy pracy, sposób działania zespołu. Pięć niezależnych światów AI kosztuje pięć razy: pięć umów, pięć analiz ryzyka, pięć integracji, pięć zestawów logów. I jeden moment, w którym nikt w firmie nie potrafi odpowiedzieć, ile AI właściwie kosztuje.

Kto odpowiada za roadmapę

Roadmapa istnieje tylko wtedy, gdy ktoś ma prawo powiedzieć „nie”. Jeżeli plan rozwoju rozwiązania jest sumą życzeń pięciu działów, to nie jest roadmapa, tylko kolejka. Należy do osoby odpowiedzialnej za wynik procesu, nie do IT i nie do dostawcy. Warto przy tym pamiętać o czymś, o czym łatwo zapomnieć: jeżeli budujecie na cudzym modelu, cudza roadmapa staje się częścią Waszej. Wycofanie wersji modelu, zmiana cennika czy zmiana zachowania API to zdarzenia produktowe u Was, nie tylko u dostawcy.

Kiedy eksperyment powinien zostać produktem

POC kończy się zwykle zdaniem „działa”. To za mało. Potrzebny jest warunek promocji ustalony, zanim eksperyment ruszy: jaka jakość, na jakiej próbce (realnej, nie demonstracyjnej), przy jakim koszcie jednostkowym, z jakim planem integracji i z czyim podpisem pod wynikiem. Równie ważny jest warunek zamknięcia. Najbardziej kosztowny stan to eksperyment, który po cichu wszedł do procesu, bo nikt nie podjął decyzji ani o jego promocji, ani o wygaszeniu. Ma wtedy pełne ryzyko rozwiązania produkcyjnego i zerową opiekę.

Kto finansuje dalszy rozwój i utrzymanie

Pilotaż zwykle ma sponsora i budżet innowacyjny. Drugi rok zwykle nie ma ani jednego, ani drugiego. AI różni się przy tym od klasycznego oprogramowania: koszt bieżący nie jest stały, tylko rośnie razem z użyciem, a do rachunku dochodzą pozycje, których w klasycznym projekcie IT nie było. Inference. Ocena jakości. Nadzór człowieka. Aktualizacje promptów i modeli. Obsługa incydentów. Dobry test intencji jest prosty: zapytajcie, z czyjego budżetu operacyjnego pójdzie rachunek za dwanaście miesięcy. Jeżeli żaden właściciel procesu nie chce tego wziąć na siebie, to najmocniejszy sygnał, że wartość jest wątpliwa.

Kiedy projekt ma jeszcze sens ekonomiczny przy rosnącej skali

To pytanie, które zadaję najczęściej i najrzadziej dostaję na nie odpowiedź. W klasycznym oprogramowaniu koszt krańcowy kolejnego użycia zbliża się do zera. W rozwiązaniach opartych na modelach bywa bliski liniowemu. Jednocześnie wartość krańcowa zwykle spada, bo pilotaż robi się na przypadkach najprostszych i najbardziej wartościowych, a skala dokłada ogon spraw trudnych i tanich. Business case policzony na tysiącu dokumentów miesięcznie potrafi się rozjechać przy pięćdziesięciu tysiącach. Dlatego próg opłacalności warto liczyć na wolumenie docelowym, nie pilotażowym, i osobno sprawdzić, przy jakim wolumenie rozwiązanie przestaje mieć sens.

POC może mieć project managera. Rozwiązanie produkcyjne potrzebuje właściciela

To nie jest różnica w tytule na wizytówce, tylko w funkcji celu.

Project manager optymalizuje zakres, czas i budżet. Jego sukcesem jest dowiezienie. Jego praca kończy się w momencie wdrożenia. Właściciel produktu albo procesu optymalizuje wynik utrzymany w czasie. Jego praca w momencie wdrożenia dopiero się zaczyna.

Widać to na kilku wymiarach naraz:

• Pytanie. POC: czy to w ogóle działa? Produkcja: czy nadal działa i czy się opłaca?
• Sukces. POC: wynik na próbce. Produkcja: wynik procesu utrzymany w czasie.
• Rola. POC: project manager. Produkcja: właściciel produktu lub procesu.
• Horyzont. POC: tygodnie. Produkcja: lata, aż do decyzji o wyłączeniu.
• Budżet. POC: jednorazowy, innowacyjny. Produkcja: operacyjny, powtarzalny.
• Metryka. POC: jakość na próbce. Produkcja: KPI procesu, koszt jednostkowy, jakość w czasie.
• Zakończenie. POC: raport i decyzja. Produkcja: świadoma decyzja o wygaszeniu.

Pięć pytań, które w praktyce sprawdzają, czy właściciel istnieje:

• Kto ma wynik tego rozwiązania w swoich celach rocznych?
• Z czyjego budżetu operacyjnego pójdzie rachunek w przyszłym roku?
• Kto akceptuje kolejną zmianę zakresu i kto może ją odrzucić?
• Kogo trzeba obudzić, jeżeli jakość spadnie o dziesięć punktów procentowych?
• Kto ma prawo to wyłączyć?

Ostatnie pytanie jest najważniejsze. Jeżeli nikt nie ma prawa wyłączyć rozwiązania, to nikt nie jest jego właścicielem. Jest tylko zbiór osób, które je tolerują.

I stąd wracamy do pytania z początku. Nie, AI nie jest produktem samo w sobie. Produktem jest konkretna usługa, proces albo funkcja, którą AI ma robić lepiej, taniej albo szybciej. Dopiero kiedy nazwiecie ten produkt po imieniu, pytanie o właściciela przestaje być filozoficzne. „Kto odpowiada za AI” nie ma dobrej odpowiedzi. „Kto odpowiada za koszt obsługi jednego dokumentu i za jakość tej obsługi” ma ją zawsze.