Wdrażanie AI w firmie: trzy rzeczy, o które rozbija się każdy projekt
Pytanie brzmiało: “czy ten agent może wysyłać maile w imieniu Pana Dyrektora?”. Padło w czwartek po południu, na korytarzu, między spotkaniami. Człowiek od bezpieczeństwa odpowiedział, że musi to sprawdzić. Pół godziny później okazało się, że poc trwał już od czterech miesięcy. Nikt nie pytał wcześniej, bo działało.
Tak wygląda dziś wdrażanie AI w firmie w polskim mid-marketcie. Najpierw uruchomienie, potem chęć zabezpieczenia, na końcu telefon do bezpiecznika z prośbą, żeby “to jakoś ogarnął”. W tym poście rozkładam trzy problemy, o które rozbija się prawie każdy taki projekt, oraz pięć rzeczy, które warto u siebie poukładać, zanim AI zaleje stack na dobre.
Wdrażanie AI w firmie po polsku: kolejność odwrotna
W większości projektów, które ostatnio widziałem w polskich firmach, kolejność jest dokładnie odwrotna od tej, którą sugeruje zdrowy rozsądek. Najpierw zarząd przywozi z konferencji hasło, że “trzeba mieć AI”. Potem dyrektor IT dostaje zadanie kwartalne, żeby wdrożyć AI dla X osób. Następnie ktoś deployuje Copilota albo agenta w n8n, podpina go pod firmowe konta i puszcza do użytkowników. Bezpiecznik pojawia się dopiero wtedy, gdy ktoś z compliance zadaje pierwsze pytanie albo audytor zewnętrzny zauważa, że nie ma logu.
W rezultacie powstaje sytuacja, w której decyzje architektoniczne są już podjęte, dane już płyną, a bezpieczeństwo trzeba dorobić na działającym systemie. Z mojego doświadczenia ten model kończy się jednym z dwóch scenariuszy. Albo bezpiecznik wprowadza ograniczenia, które niszczą doświadczenie użytkownika i poc umiera śmiercią naturalną. Albo nie wprowadza, ponieważ nie chce być “tym od mówienia nie”, a wtedy ryzyko siedzi w systemie do pierwszego incydentu.
Problem jest realny. Za każdą decyzję, którą bezpiecznik podejmuje dziś bez kontekstu, będzie odpowiadał w audycie za rok. Decyzje podjęte w pośpiechu rzadko bronią się przed kontrolą. Dlatego wdrażanie AI w firmie wymaga porządku, który zaczyna się od pytań, nie od wdrożenia.
Trzy problemy, o które rozbija się wdrażanie AI w firmie
Trzy rzeczy wracają w prawie każdej rozmowie z CISO i IT managerem ostatnich miesięcy. Tożsamość agentów. AI wdrażane na siłę przez zarząd. Pracownicy zostawieni samym sobie. Każda z nich osobno jest do ogarnięcia, razem tworzą sytuację, w której bezpiecznik nadrabia organizacyjny chaos technicznymi środkami, co rzadko kończy się dobrze.
Tożsamość agentów AI: nieopisany insider
To dziś ten sam temat, którym dziesięć lat temu była tożsamość service accountów, tylko w gorszej wersji. Agent działa w imieniu pracownika, ale logi pokazują “agent zrobił X”. Wysłał maila? Skopiował dane do drugiego systemu? Zmodyfikował rekord w CRM? Kto autoryzował tę akcję, kiedy, w jakim kontekście, z jakim zakresem uprawnień?
Pytania są techniczne, jednak skutki są organizacyjne. Service account z OAuth tokenem ważnym przez 90 dni i scope offline_access to nie jest “konto agenta”. To stała delegacja uprawnień bez okna kontroli. Tymczasem klasyczny IAM zakłada, że dostęp ma człowiek albo nazwany proces, a nie byt pośredni, który dziedziczy uprawnienia po jednym pracowniku i wykonuje akcje w imieniu drugiego.
Robiłem ostatnio przegląd jednego stacku no-code w firmie produkcyjnej. Trzynaście agentów w n8n, jedno wspólne konto serwisowe Google Workspace, scope rozszerzany “tymczasowo” przy każdym nowym przepływie. Audyt sześć miesięcy temu nie zgłosił problemu, ponieważ wtedy był tylko jeden flow. Klasyczny soft-lock w drugą stronę: nikt nie chciał zatrzymać projektu, więc nikt nie zadał pytania o tożsamość.
Każdy nieopisany agent to potencjalny insider o nieznanym promieniu rażenia. Bez wyjątków.
AI wdrażane na siłę przez zarząd
Drugi problem nie jest techniczny, jest kulturowy. Zarząd usłyszał na konferencji, że trzeba mieć AI, i wraca z hasłem “do końca kwartału mamy mieć Copilota dla 200 osób”. Bez strategii. Bez governance. Bez polityki klasyfikacji danych. Pracownik dostaje narzędzie i pytanie od menedżera: “dlaczego z tego nie korzystasz?”. Pytanie, które naprawdę powinien zadać sobie zarząd, brzmi inaczej: “co konkretnie ma się zmienić w pracy tych 200 osób?”. Zostaje bez odpowiedzi.
Antywzorzec rozpoznaję po jednym sygnale. Jeśli na pierwszym slajdzie prezentacji wdrożeniowej widnieje liczba użytkowników, a nie konkretny proces biznesowy do zmiany, projekt służy KPI, nie firmie. AI staje się celem samym w sobie. Ważny jest sam fakt wdrożenia, nie wynik. Po trzech miesiącach okazuje się, że adopcja jest niska, ROI niemierzalny, a dane firmowe regularnie wpadają do publicznego LLM, ponieważ nikt nie powiedział pracownikom, czego nie wolno wklejać.
To nie jest problem AI. To problem strategii biznesowej, który AI tylko uwidacznia. Ponieważ jednak skutki tej strategii trafiają na biurko bezpiecznika, on musi reagować, mimo że źródło problemu jest dwa piętra wyżej.
Pracownicy zostawieni samym sobie
Trzeci problem jest prosty: pracownicy nie znają zasad, których nikt im nie powiedział. Nie wiedzą, co wolno wkleić do ChatGPT, a czego nie. Nie wiedzą, czy agent w n8n powinien mieć dostęp do firmowego CRM. Nie wiedzą, kto jest właścicielem tego, co agent zrobi w ich imieniu. To nie ich wina, ponieważ firma im tego nie powiedziała.
W rozmowach z zespołami operacyjnymi słyszę te same trzy pytania w kółko. “Czy mogę wkleić do ChatGPT mail od klienta, żeby zrobił mi streszczenie?”. “Czy agent automatyzujący raporty może czytać dane z mojego folderu na dysku firmowym?”. “Jeśli ten agent wyśle bzdurę do klienta, kto to dostanie po głowie?”. Odpowiedź “to zależy” nie pomaga. Pomaga jednostronicowy dokument z trzema kolumnami: zielone, żółte, czerwone. Konkretne przykłady, nie zasady ogólne.
Pracownik nie potrzebuje wykładu o klasyfikacji danych. Potrzebuje listy: tego wkleić można, tego nie, w razie wątpliwości pytaj X. Bez listy zgaduje. A zgaduje często źle.
Wdrażanie AI w firmie pod presją NIS2, DORA i EU AI Act
W środku tego zamieszania ląduje bezpiecznik z czterema rzeczami jednocześnie. W jednej ręce NIS2 (w PL transponowana przez nowelizację ustawy o Krajowym Systemie Cyberbezpieczeństwa), w drugiej DORA dla podmiotów finansowych, w trzeciej EU AI Act dla systemów wysokiego ryzyka, a w czwartej pytanie z biznesu: “czy ten agent może wysyłać maile w imieniu Pana Dyrektora”.
Co konkretnie wymagają trzy regulacje
NIS2 wymaga w art. 21 środków technicznych i organizacyjnych proporcjonalnych do ryzyka, w tym polityk bezpieczeństwa informacji, zarządzania incydentami i kontroli dostępu. Agent AI używający firmowych danych jest w zakresie tej dyrektywy z definicji. DORA dla banków, ubezpieczycieli i firm inwestycyjnych dorzuca operacyjną odporność, zarządzanie ryzykiem ICT i wymóg klasyfikacji incydentów. EU AI Act z kolei w artykułach 9-15 nakłada wymagania na systemy wysokiego ryzyka: zarządzanie ryzykiem, jakość danych, dokumentację techniczną, nadzór ludzki, dokładność i robustness. Wiele rozwiązań klasy “agent AI” w korporacji mieści się w którejś z tych kategorii, nawet jeśli wdrażający tak na nie nie patrzy.
Dlaczego nie ma sensu czekać na interpretację
Tu pojawia się pułapka, w którą wpada wielu CISO. Czekają, aż regulator albo polski organ powie dokładnie, czego oczekuje. Regulator napisał te przepisy szeroko z premedytacją. Organ powie “stosujcie się do art. 21”, a interpretacja zostaje na firmie. W konsekwencji wdrażanie AI w firmie bez własnej, świadomej interpretacji oznacza, że w audycie ktoś inny zinterpretuje to za was. Ta interpretacja prawie zawsze będzie surowsza niż wasza. Praktyka jest jedna: piszemy własną interpretację, dokumentujemy decyzje, łączymy je z konkretnymi kontrolami w systemie. Deklaratywna polityka, której nikt nie egzekwuje, nie obroni się przed kontrolą. Egzekwowany standard, nawet niedoskonały, obroni się.
Co poukładać, zanim AI zaleje stack na dobre
Pięć rzeczy, które warto zrobić, zanim wdrażanie AI w firmie wymknie się spod kontroli. Każda z nich jest wykonalna w skali tygodni, nie miesięcy. Każda zwraca się przy pierwszym audycie albo pierwszym incydencie, w zależności od tego, co przyjdzie szybciej.
1. Inwentaryzacja agentów AI i ich tożsamości
Zacznij od listy. Brzmi banalnie, dopóki nie spróbujesz jej zrobić. Inwentarz agentów to dokument odpowiadający na pytania: co to za agent, kto jest właścicielem biznesowym, kto technicznym, jakie konto (service account, OAuth, API key, delegated credentials), jakie scope, do jakich danych, kiedy został uruchomiony, kiedy ostatnio przeglądany. Format mniej ważny niż dyscyplina aktualizacji.
Pierwszy przebieg inwentaryzacji w średniej firmie wyciąga zwykle dwa razy więcej agentów, niż zakłada IT. Część działa w n8n na koncie jednego pracownika. Część w Power Automate na koncie wspólnym. Część to integracje typu Zapier z OAuth tokenami sprzed dwóch lat. Każdy nieopisany w inwentarzu to insider o nieznanym promieniu rażenia. Powtarzam, ponieważ to istota tematu.
Przegląd raz na kwartał. Każdy nowy agent przed uruchomieniem przechodzi przez ten sam check, co nowy service account dziesięć lat temu. Bez wyjątków dla testów/poców.
2. Polityka klasyfikacji danych dla AI
Polityka klasyfikacji danych dla AI to nie jest kolejny ciężki dokument bezpieczeństwa. To jednostronicowy cheat sheet, który pracownik ma pod ręką, gdy zastanawia się, czy wkleić mail klienta do ChatGPT. Trzy kolumny: zielone, żółte, czerwone. Konkretne kategorie danych, nie zasady ogólne.
Zielone: dane publiczne firmy, ogólne teksty marketingowe, nieidentyfikujące fragmenty bez tajemnicy handlowej.
Żółte: dane wewnętrzne, których wyciek byłby uciążliwy, ale nie katastrofalny. Tu używa się wyłącznie prywatnej instancji (Copilot w tenancie firmy, Azure OpenAI w VNet, Bedrock, dedykowany endpoint).
Czerwone: dane osobowe wrażliwe, dane klientów objęte tajemnicą, materiały IP, sekrety i dane logowania, dokumenty prawne w toku. Tych nie wkleja się nigdzie, niezależnie od kuszącej obietnicy productivity boost.
Polityka bez cheat sheetu to dokument na półce. Cheat sheet bez polityki to chaos.
3. Log audytowy agentów osobno od logów użytkowników
Standardowy zapis: “akcja X wykonana przez agenta Y w imieniu użytkownika Z, w czasie T, ze scope S, na danych D, z wynikiem R”. Bez tych pól log audytowy nie spełnia podstawowej funkcji, którą jest możliwość zrekonstruowania, kto faktycznie zrobił co i na jakiej podstawie.
W praktyce oznacza to dwa strumienie logów. Pierwszy to logi tożsamości człowieka (logowanie, sesja, autoryzacja). Drugi to logi tożsamości agenta (token użyty, scope, endpoint API, payload jeśli polityka pozwala). Korelacja przez identyfikator sesji albo correlation ID jest obowiązkowa, w przeciwnym razie SIEM nie powie wam nic użytecznego po incydencie. Retencja zgodna z polityką dla logów bezpieczeństwa, czyli zwykle minimum 12 miesięcy, dla finansowych więcej.
Brak osobnego logu agentów to klasyczny soft-lock dla zespołu SOC. Widzą efekty, nie widzą sprawcy.
4. Właściciel dla każdego agenta: imię i nazwisko
Imię i nazwisko, nie “dział IT”. Nie “zespół automatyzacji”. Konkretna osoba, która odpowiada za to, że ten agent robi, co ma robić, i nie robi tego, czego nie powinien.
Właściciel odpowiada za trzy rzeczy. Po pierwsze, za scope: każde rozszerzenie uprawnień przechodzi przez jego decyzję. Po drugie, za przegląd: raz na kwartał potwierdza, że agent jest wciąż potrzebny i działa zgodnie z założeniem. Po trzecie, za reakcję: gdy agent zrobi coś dziwnego, telefon dzwoni do niego, nie do helpdesku.
Bez nazwanego właściciela każdy agent prędzej czy później staje się problemem trzech zespołów, które wzajemnie wskazują na siebie. “To nasz, ale konfigurował zespół X”. “Skonfigurowaliśmy, ale uprawnienia daje zespół Y”. Tymczasem agent dalej działa i dalej robi swoje. Bez wyjątków: agent bez właściciela to agent do wyłączenia.
5. Procedura wyłączania agenta: kill switch z prawdziwego zdarzenia
Procedura wyłączania ma trzy elementy. Pierwszy to techniczny mechanizm, który faktycznie działa: revoke OAuth tokenu, wyłączenie konta serwisowego, blokada na poziomie API gateway, w skrajnych przypadkach blokada wszystkich integracji w n8n albo Power Automate. Drugi to lista osób uprawnionych do pociągnięcia switcha, krótka, z numerami telefonów. Trzeci to SLA wewnętrzny: ile minut od decyzji do efektu.
Test tego mechanizmu przeprowadza się raz na kwartał, na nieprodukcyjnym agencie. W przeciwnym razie nikt nie wie, czy procedura działa, dopóki nie trzeba jej użyć w prawdziwym incydencie. W praktyce widziałem trzy razy, że firma miała procedurę na papierze, a w trakcie testu okazywało się, że OAuth token był poza zarządzaniem IT, ponieważ agent działał na koncie osobistym kogoś, kto już nie pracował.
Kill switch bez testu to przekonanie. Kill switch z testem to kontrola.
Podsumowanie: AI Security jako równoległy IAM, DLP i SIEM
AI Security przestaje być działem od jednej technologii. Staje się równoległym IAM dla bytów, które nie są ani człowiekiem, ani klasycznym serwisem. Staje się równoległym DLP, ponieważ przepływy danych przy AI wyglądają inaczej niż przy zwykłych aplikacjach. Staje się równoległym SIEM, ponieważ log agentów to osobny strumień zdarzeń, który koreluje się z resztą dopiero przy świadomym projekcie.
Wdrażanie AI w firmie zrobione dobrze nie polega na wyborze platformy. Polega na tym, czy zadaliście trzy pytania przed pierwszym pilotem: kto autoryzuje, kto odpowiada, kto wyłącza. Reszta jest implementacją.
Pytanie do was nie brzmi, czy w waszej firmie ktoś wdraża AI. Brzmi: czy wiecie, ilu agentów już macie, kto za nich odpowiada i kto może ich wyłączyć. Jeśli odpowiedź to “nie wiem, sprawdzę”, właśnie zaczęliście drogę, którą warto przejść świadomie. Wcześniej, niż wymusi to audyt.
