Private AI i agenci AI – bezpieczeństwo danych w organizacji

Pierwsza kategoria: regulacje sektorowe. DORA (instytucje finansowe), NIS2 (operatorzy usług kluczowych), MDR (wyroby medyczne), KNF/PFSA regulacje (banki, ubezpieczenia, TFI) – każda nakłada wymagania na lokalizację i kontrolę danych. Dla części scenariuszy operacyjnych Microsoft 365 z private endpoints i Azure Polska wystarcza. Dla innych wymagana jest pełna kontrola infrastruktury.

Druga kategoria: dane szczególnie chronione w rozumieniu RODO art. 9 – dane o zdrowiu, dane biometryczne, dane genetyczne, dane o orientacji seksualnej, dane o przekonaniach religijnych. Dla scenariuszy, w których agent AI dla firm ma przetwarzać te dane (np. asystent kliniczny, agent dla działu HR obsługujący L4), private AI jest często wymaganym standardem.

Trzecia kategoria: dane organizacyjne klasy najwyższej – M&A, wyniki finansowe pre-publikacja, dane wywiadowcze, dane wojskowe i bezpieczeństwa narodowego, prawo własności intelektualnej (kod, know-how). Dla tych klas żadna umowa SLA z cloud providerem nie zmienia kalkulacji ryzyka.

Czwarta kategoria: residency i sovereignty. Organizacje z polityką 'dane nie opuszczają Polski' / 'dane nie opuszczają UE'. Cloud providerzy oferują regiony UE i Polska, ale dla części klientów (zwłaszcza sektor publiczny) jest to niewystarczające – wymagana pełna kontrola fizyczna nad infrastrukturą.

Piąta kategoria: edge i offline. Agenci AI w środowiskach z ograniczoną łącznością (statki, platformy wiertnicze, fabryki, służby mundurowe). Tam private AI to nie wybór, tylko jedyna techniczna możliwość.

Przez ostatnie dwa lata zmieniła się odpowiedź na pytanie, które zarządy zadają najczęściej: „czy AI w naszej własnej serwerowni odda nam taką samą wartość biznesową jak ChatGPT czy Copilot w chmurze?”. Dziś dla większości zastosowań biznesowych odpowiedź jest twierdząca – pojawiły się rodziny modeli AI, które można uruchomić w środowisku organizacji i które dorównują głównym modelom chmurowym w typowych zadaniach analitycznych, dokumentowych i wspomagających pracę zespołów.

W praktyce decyzja o wyborze konkretnego modelu jest dziś detalem technicznym, a nie strategicznym. Architekt rozwiązania dobiera model do scenariusza – inny do asystenta obsługującego dokumentację medyczną, inny do analizy umów, inny do zapytań pracowniczych. Z perspektywy zarządu liczy się to, że ekosystem modeli „do uruchomienia u siebie” jest już dojrzały i wciąż się rozwija – uzależnienie od jednego dostawcy chmury przestało być koniecznością.

Co to oznacza biznesowo: organizacja, która jeszcze rok temu byłaby zmuszona wybierać między „użyjemy chmury i zgodzimy się na ryzyko” a „zrezygnujemy z AI”, dziś ma trzecią opcję – własna platforma AI uruchomiona w infrastrukturze firmy, z pełną kontrolą nad tym, gdzie znajdują się dane.

Praktyczna konsekwencja: dyskusję z dostawcą warto prowadzić wokół scenariuszy biznesowych („asystent dla działu zakupów”, „analiza dokumentacji projektowej”, „obsługa zapytań pracowniczych”), a nie wokół konkretnych nazw modeli. Doświadczony partner powie, jaki model dobrze pasuje do scenariusza – to nie jest decyzja, którą zarząd musi zatwierdzać samodzielnie.

Z perspektywy zarządu i biura projektowego warto rozumieć, że private AI to nie jeden produkt, tylko zestaw klocków, które muszą zagrać razem. Można go porównać do firmowej serwerowni czy własnego ERP – też nie jest jednym pudełkiem, tylko ekosystemem złożonym z infrastruktury, oprogramowania i procesów.

Pierwszy klocek to infrastruktura – serwery o odpowiedniej mocy obliczeniowej (komputery wyspecjalizowane do obsługi modeli AI), sieć i przestrzeń dyskowa. Można to mieć we własnej serwerowni, w prywatnym centrum danych albo w wydzielonym, zamkniętym fragmencie chmury. Drugi klocek to platforma, która pozwala uruchamiać i utrzymywać modele AI – odpowiednik systemu operacyjnego dla AI. Trzeci klocek to warstwa decyzyjna asystenta – to, co zamienia model AI w „kolegę z zespołu”: rozumie pytanie, wybiera właściwe źródła wiedzy, planuje sekwencję działań i wykonuje akcje w systemach firmy.

Czwarty klocek to baza wiedzy organizacji – uporządkowane dokumenty (regulaminy, procedury, polityki, dane historyczne), z których asystent korzysta podczas pracy. To jest często decydujący element jakości – dobre AI bez dobrze uporządkowanej wiedzy daje słabe odpowiedzi. Piąty klocek to integracje z systemami firmy (ERP, CRM, systemy obiegu dokumentów, Active Directory). Szósty – warstwa nadzoru: monitoring, audit, polityki dostępu i bezpieczeństwa.

Główna różnica względem rozwiązań chmurowych typu Microsoft 365 Copilot: tam większość tych klocków jest dostarczana w pakiecie i wystarczy je „włączyć”. W private AI organizacja buduje (albo zleca budowę) całość. To podnosi koszt początkowy, ale daje pełną kontrolę nad każdym elementem.

Microsoft 365 z agentami w Copilot Studio: czas wdrożenia 4–8 tygodni dla pierwszego agenta. Koszt: ~30–80 zł/użytkownik/mc (Copilot licencja) + koszt projektu. Plus: gotowy stack, governance dziedziczone, integracje z Microsoft 365 out-of-box. Minus: dane wychodzą do Azure OpenAI (nawet w private endpoints i Polska region – kontrakt z Microsoft).

Private AI z agentami: czas wdrożenia 4–6 miesięcy dla pierwszego agenta (więcej infrastruktury i custom developmentu). Koszt: 0.6–2 mln zł CAPEX + 200–400 tys. zł rocznie OPEX (zależnie od skali). Plus: pełna kontrola, dane nigdy nie opuszczają organizacji, możliwość fine-tuningu na danych organizacyjnych. Minus: dużo wyższy koszt początkowy, brak gotowych konektorów, wymaga zespołu wewnętrznego lub partnera.

Architektura hybrydowa: Microsoft 365 dla scenariuszy 'mainstream' (HR, IT, finanse w operacyjnym wymiarze), private AI dla scenariuszy z danymi wrażliwymi (M&A, dane medyczne, dane wywiadowcze). To dziś najczęstsza ścieżka dla dużych organizacji – kombinacja szybkości wdrożenia z M365 i bezpieczeństwa danych z private AI.

Praktyczna obserwacja: organizacje rzadko wybierają 'tylko private AI'. Dużo częściej wybierają hybrydowy mix, gdzie 70–80% scenariuszy idzie do M365, a 20–30% (najwrażliwsze) do private AI. To pozwala uzyskać benefity z obu architektur. Decyzję projektujemy w ramach doradztwa i strategii.

Dział compliance i zarząd potrzebują od dostawcy private AI prostej odpowiedzi na sześć pytań. Te same pytania, które dzisiaj zadaje się dostawcy hurtowni danych, systemu ERP czy zewnętrznej kancelarii prawnej. Jeśli odpowiedzi nie ma – projekt nie powinien iść dalej, niezależnie od tego, jak dobre są efekty demo.

Pierwsze pytanie: czy dane organizacji w ogóle wychodzą poza nasze środowisko? W dobrze zaprojektowanym private AI odpowiedź brzmi „nie” – platforma działa w odizolowanej sieci wewnętrznej, bez kontaktu z internetem poza ściśle kontrolowanym kanałem aktualizacji oprogramowania.

Drugie pytanie: czy dane są zaszyfrowane na każdym etapie (na dyskach, w trakcie przesyłania między komponentami, w bazach wiedzy)? Standardem rynkowym jest pełne szyfrowanie z kluczami zarządzanymi w sposób, do którego nie ma dostępu nawet zespół utrzymujący platformę. Trzecie pytanie: czy każdy użytkownik widzi tylko te informacje, do których realnie ma uprawnienia w firmie? Asystent AI musi działać „w imieniu” konkretnego pracownika i dziedziczyć jego uprawnienia z firmowych systemów (Active Directory, polityki dostępu) – nigdy nie powinien widzieć więcej niż sam pracownik.

Czwarte pytanie: czy każda akcja asystenta zostawia ślad audytowy? Compliance officer powinien móc w każdej chwili sprawdzić, kto, kiedy i w jakim kontekście korzystał z asystenta, na jakie pytania odpowiadał i jakie akcje wykonał. Logi przechowywane minimum 7 lat (DORA, SOX), w formacie niezmienialnym.

Piąte pytanie: czy są mechanizmy chroniące przed nieumyślnym ujawnieniem danych (np. żeby asystent nigdy nie odpowiedział numerem PESEL pracownika, nawet jeśli ktoś o to zapyta wprost)? Szóste: jak platforma broni się przed próbami „oszukania” asystenta złośliwymi pytaniami (tzw. prompt injection)? Te pytania powinny być częścią każdego procesu zakupowego AI w organizacji.

Wdrożenie AI w organizacjach regulowanych styka się z kilkoma warstwami przepisów, które łatwo zlekceważyć w fazie planowania, a które potrafią zatrzymać projekt na końcu. Warto je uporządkować z perspektywy biznesowej – jaki obowiązek nakładają i jakie konsekwencje wiążą się z niespełnieniem.

Pierwsza warstwa: ogólne regulacje dotyczące AI. Unijny AI Act klasyfikuje systemy AI według poziomu ryzyka i nakłada na organizacje konkretne obowiązki – od dokumentacji, przez testowanie, po prawo użytkownika do wyjaśnienia decyzji. RODO obejmuje wszystkie procesy z danymi osobowymi. Naruszenia są dotkliwe finansowo i reputacyjnie – mówimy o karach liczonych w procentach obrotu rocznego.

Druga warstwa: regulacje branżowe. DORA dla banków i ubezpieczycieli wymaga rygorystycznej kontroli nad cyfrowym łańcuchem dostaw IT, w tym dostawcami AI. NIS2 dotyczy operatorów usług kluczowych (energetyka, transport, ochrona zdrowia, sektor publiczny). MDR dla producentów wyrobów medycznych wymaga walidacji systemów AI używanych w procesach klinicznych. Każda z tych regulacji może decydować o tym, czy chmurowe AI jest w ogóle dopuszczalne.

Trzecia warstwa: standardy i certyfikacje, których wymagają partnerzy biznesowi i klienci. ISO 27001 (bezpieczeństwo informacji), ISO 27701 (ochrona prywatności), ISO 42001 (zarządzanie AI), ISO 13485 (medtech). Brak tych certyfikacji często wyklucza dostawców z przetargów enterprise.

Czwarta warstwa: regulator krajowy. KNF dla sektora finansowego, UODO dla danych osobowych, sektorowe (lotnictwo, energetyka, obronność). Każdy ma własne wymagania interpretacyjne. Praktyczna konsekwencja dla zarządu: compliance i bezpieczeństwo to nie warstwa „po wdrożeniu” – to fundamenty, które trzeba zaprojektować w pierwszym tygodniu. Naprawianie ich później kosztuje wielokrotnie więcej i czasami w ogóle nie jest możliwe.

Najczęstsza obawa zarządów przed wdrożeniem AI w wersji private brzmi: „dobrze, ale czy nasz asystent będzie znał naszą firmę, nasze umowy, nasze produkty, naszą branżę – czy będzie odpowiadał ogólnymi banałami z internetu?”. To słuszne pytanie i odpowiedź zależy od dwóch elementów.

Pierwszy element to dobrze uporządkowana wiedza organizacji. Asystent AI nie „uczy się” sam – korzysta z dokumentów, polityk, procedur i danych, które organizacja mu udostępnia. Jeśli SharePoint jest uporządkowany, polityki są aktualne, procedury żyją – asystent ma na czym pracować. Jeśli wiedza jest rozproszona, przestarzała, niespójna – asystent będzie odzwierciedlał tę słabość. Praktycznie zawsze projekt wdrożenia AI ujawnia długi w obszarze zarządzania wiedzą, które trzeba spłacić przy okazji.

Drugi element to ewentualne „dotrenowanie” modelu na specyfice organizacji. Stosujemy je tylko wtedy, gdy organizacja posługuje się bardzo specyficznym językiem (medycznym, prawnym, branżowym), własnym stylem komunikacji lub specyficznymi wzorcami decyzyjnymi, których model „z półki” nie zna. Dla większości typowych zastosowań (asystent HR, asystent IT, asystent w obszarze finansów operacyjnych) takie dotrenowanie nie jest konieczne – wystarczy dobrze ustawiona warstwa wiedzy.

Praktyczna rekomendacja: w pierwszym roku skupić się na uporządkowaniu wiedzy. To zwykle daje 80% wartości za 30% kosztu. Dotrenowanie modelu rozważać dopiero po roku produkcji – gdy organizacja wie, gdzie naprawdę szwankuje jakość odpowiedzi. Zaczynanie od „zrobimy własny model AI od zera” to klasyczna pułapka, w którą wpadają organizacje, mylące AI z projektem badawczym.

Częste pytanie zarządu brzmi: „jeśli pójdziemy w private AI, czy zapłacimy więcej niż za chmurę?”. Odpowiedź zależy od skali organizacji i horyzontu, w którym liczymy zwrot. Dla średniej organizacji ze 500 użytkownikami i kilkoma asystentami AI obraz wygląda zwykle następująco.

Wariant chmurowy (Microsoft 365 z Copilot): głównie koszt subskrypcyjny – licencje per użytkownik plus jednorazowy projekt wdrożeniowy. W 3-letnim horyzoncie typowy łączny koszt to ~5 mln zł, z czego większość to powtarzalna opłata abonamentowa. Główna zaleta: szybki start (4–8 tygodni do pierwszego asystenta), niski koszt początkowy, brak konieczności utrzymania infrastruktury.

Wariant private AI: większy koszt początkowy (sprzęt, platforma, wdrożenie) i mniejszy koszt powtarzalny. W 3-letnim horyzoncie typowy łączny koszt to 2,5–4 mln zł plus koszty integracji z firmowymi systemami. Główne ryzyko finansowe: niedoszacowanie kosztów utrzymania (aktualizacje, zespół, monitoring). Dłuższy okres do uruchomienia pierwszego asystenta (4–6 miesięcy zamiast 4–8 tygodni).

Czysto matematycznie private AI zaczyna wygrywać kosztowo przy większych organizacjach i dłuższych horyzontach (4+ lata). Ale praktyka jest taka, że TCO rzadko bywa głównym powodem wyboru. Główne argumenty to: compliance, kontrola nad danymi, niezależność od dostawcy. Jeśli te argumenty są ważne dla rady nadzorczej i compliance, kalkulacja TCO jest dodatkową korzyścią, a nie głównym czynnikiem decyzji.

Wdrożenie private AI nie jest projektem IT, tylko programem transformacyjnym, który dotyka strategii, ryzyka, infrastruktury i zmiany sposobu pracy. Z perspektywy zarządu warto myśleć o nim w czterech fazach, z których pierwsza i ostatnia są najistotniejsze.

Faza 1 (6–8 tygodni) to discovery i decyzje strategiczne. Identyfikacja procesów, dla których private AI rzeczywiście ma sens (zwykle 2–4 procesy w organizacji). Decyzja, czy idziemy w model „w pełni u nas” czy „częściowo u nas, częściowo w chmurze”. Uzgodnienie z compliance, z radą nadzorczą, z IT. Wynik: business case z konkretnym ROI i mapą ryzyk – nie technologia, tylko decyzja zarządcza.

Faza 2 (3–4 miesiące) to przygotowanie infrastruktury i platformy. Tu pracuje głównie dział IT z partnerem wdrożeniowym – serwery, sieci, oprogramowanie, podstawowe zabezpieczenia. Z perspektywy biznesowej to faza „cierpliwości” – widoczne efekty pojawią się dopiero w fazie 3.

Faza 3 (3–4 miesiące) to uruchomienie pierwszego asystenta AI dla konkretnego procesu biznesowego. Zwykle wybiera się ten najbardziej krytyczny pod kątem ryzyka (asystent dla działu compliance, asystent w obszarze danych medycznych, asystent dla działu fuzji i przejęć). Mierzymy realny efekt biznesowy w pierwszym kwartale produkcji.

Faza 4 (4–6 miesięcy) to rozszerzanie na kolejne procesy. Każdy następny asystent wdraża się szybciej, bo platforma już istnieje. Cały program – od decyzji zarządu do dojrzałej platformy z 3–5 asystentami – trwa typowo 16–22 miesiące. Inwestycja w średniej organizacji: 2–5 mln zł, zwrot zwykle widoczny w 24–36 miesiącu, długoterminowy ROI 200–500% rocznie.

Pierwszy błąd, najczęstszy: wybór private AI bardziej z powodów emocjonalnych niż biznesowych. Zarząd decyduje „chcemy mieć własne AI, bo nikt nie powinien nas widzieć”, a w analizie okazuje się, że scenariusz w 80% nie wymaga tego z perspektywy compliance. Efekt: kilkukrotnie wyższy koszt bez proporcjonalnej wartości. Lepiej: rzetelne policzenie, ile procesów organizacji rzeczywiście wymaga private AI – zwykle to jest mniej, niż się początkowo wydaje.

Drugi błąd: niedoszacowanie kosztu utrzymania. Organizacje skupiają się na kosztach zakupu sprzętu i wdrożenia, a zapominają o stałych kosztach operacyjnych – aktualizacje modeli co kilka miesięcy, monitoring, łatanie bezpieczeństwa, rotacja zespołu. Realny koszt całkowity w 3-letnim horyzoncie jest zwykle o 30–50% wyższy niż pierwotne kalkulacje. Zarząd powinien wymagać od dostawcy konkretnej tabeli z rocznymi OPEX-ami.

Trzeci błąd: chęć budowy „wszystkiego od zera” we własnym zespole. Organizacje, które słyszały, że to „tylko oprogramowanie open-source”, decydują o samodzielnym zespole AI. Efekt po roku: brak gotowego rozwiązania, wysokie koszty zespołu, brak dojrzałości operacyjnej. Lepiej: skorzystać z dojrzałych komponentów rynkowych i partnera wdrożeniowego, a wewnątrz organizacji budować kompetencję zarządczą, nie techniczną.

Czwarty błąd: traktowanie jakości polskiego języka jako oczywistej. Modele AI „z półki” są optymalizowane głównie pod angielski; bez świadomej pracy nad warstwą językową asystent może odpowiadać nieprecyzyjnie na polskie terminy branżowe. To pułapka szczególnie kosztowna w branżach z gęstym żargonem (medycyna, prawo, ubezpieczenia).

Piąty błąd: założenie, że „private AI samo się broni”. Sama lokalizacja w naszej serwerowni nie eliminuje ryzyk – bez audytu, polityk dostępu, monitoringu i procedur zarządczych private AI jest tak samo ryzykowne jak chmura. Governance i compliance muszą być uwzględnione od dnia pierwszego, nie dorabiane po wdrożeniu.

Decyzja o private AI rzadko bywa czarno-biała. Doświadczeni doradcy strategiczni proponują pięcioetapowy proces, który pozwala dojść do uzasadnionej decyzji – takiej, którą można obronić przed radą nadzorczą i compliance.

Pytanie 1: czy nasze dane rzeczywiście wymagają private AI? Trzeba zinwentaryzować procesy i kategorie danych. Zwykle okazuje się, że private AI jest konieczne tylko dla 2–4 procesów (np. fuzje i przejęcia, dane medyczne, dokumentacja patentowa), a dla pozostałych chmura Microsoft 365 wystarcza w pełni.

Pytanie 2: czy istnieje ryzyko, którego rada nadzorcza nie zaakceptuje, nawet jeśli formalnie compliance pozwala na chmurę? Czasem odpowiedź jest „tak” – psychologiczne i reputacyjne ryzyko jest dla zarządu większe niż formalne zabezpieczenia umowne z dostawcą.

Pytanie 3: czy organizacja ma kompetencje (własne lub w postaci sprawdzonego partnera), żeby utrzymać private AI w produkcji przez 5–7 lat? Bez tej zdolności wdrożenie kończy się jako kosztowna nieużywana infrastruktura.

Pytanie 4: czy private AI jest potrzebne dla całej organizacji, czy tylko dla wycinka procesów? Praktycznie zawsze odpowiedź brzmi „dla wycinka” – co oznacza, że właściwa odpowiedź to architektura hybrydowa, a nie czysty private AI.

Pytanie 5: czy całkowity koszt w horyzoncie 3–5 lat mieści się w apetycie inwestycyjnym zarządu? Tu warto wymagać od dostawcy konkretnej kalkulacji, nie ogólnej oferty. Wynik tego procesu to nie „tak/nie”, tylko jasny obraz: które procesy → który model. To decyzja, którą można obronić przed każdą instancją kontrolną.

Rynek private AI jest dziś dojrzały na tyle, że organizacje z najbardziej wrażliwymi danymi – banki, ubezpieczyciele, ochrona zdrowia, sektor publiczny, firmy z dużą bazą własności intelektualnej – mają realną alternatywę dla chmury. Nie jest to już decyzja typu „chmura albo nic”, tylko świadomy wybór: które procesy mogą korzystać z chmury, a które muszą zostać w naszej infrastrukturze.

Najważniejszy wniosek dla zarządu: decyzja private AI vs chmura nie jest decyzją techniczną. To decyzja zarządcza, ryzyko, compliance i kontroli. Większość organizacji wybiera model hybrydowy – większość procesów (HR, IT, finanse operacyjne) w chmurze Microsoft 365, a najwrażliwsze procesy (fuzje i przejęcia, dane medyczne, dane finansowe przed publikacją) w private AI. Tylko organizacje z dominującym udziałem danych wrażliwych decydują się na pełen private AI.

Inwestycja jest znacząca: 2–5 mln zł w średniej organizacji i 16–22 miesiące do dojrzałej platformy. Ale zwrot, jeśli decyzja była dobrze uzasadniona, jest dwojaki – wymierna oszczędność operacyjna (zwykle 200–500% rocznie po trzecim roku) plus radykalne obniżenie ryzyka regulacyjnego i reputacyjnego. W Algorcomp wspieramy klientów w pełnym cyklu: od decyzji zarządczej, przez projekt architektury, po wdrożenie i utrzymanie.

Pozostałe artykuły z serii pokazują temat z czterech komplementarnych perspektyw: agenci AI w firmach – jak organizacje automatyzują procesy, jak wdrożyć agentów AI w organizacji, agenci AI w finansach oraz agenci AI w Microsoft Teams.