Jak bezpiecznie skalować AI w projektach enterprise? Podejście Sii do AI governance

AI może przyspieszyć tworzenie oprogramowania, ale bez odpowiednich zasad może równie szybko zwiększyć skalę ryzyka. Przeczytaj, dlatego organizacje, które chcą wykorzystać AI w projektach enterprise, potrzebują nie tylko narzędzi, ale przede wszystkim dojrzałego modelu governance (zarządzania AI).

W poprzednich artykułach z serii pokazaliśmy, dlaczego Sii rozwija AI-Native Delivery Framework oraz jak AI-native SDLC może pomóc przejść od lokalnej produktywności pojedynczych inżynierów do bardziej mierzalnego, przewidywalnego i skalowalnego modelu dostarczania oprogramowania.

Trzeci element tej zmiany dotyczy obszaru, bez którego AI w projektach klientów nie może być odpowiedzialnie skalowane: governance & security, czyli zarządzanie bezpieczeństwem AI.

Dostęp do narzędzi AI to dopiero początek. W środowisku enterprise prawdziwe pytania pojawiają się później: kto może używać AI, w jakim projekcie, na jakich danych, z jakimi uprawnieniami i w których momentach wymagana jest decyzja człowieka.

Dla klientów oznacza to jedno: partner technologiczny nie może ograniczyć się do deklaracji, że „korzysta z AI”. Musi pokazać, że potrafi robić to w sposób kontrolowany, audytowalny i zgodny z realiami projektów.

Właśnie dlatego obszar governance (zarządzania AI) Sii traktuje nie jako administracyjną warstwę obok dostarczania oprogramowania, ale jako jeden z fundamentów AI-native delivery.

Dlaczego governance jest problemem biznesowym, a nie tylko technicznym

AI może przyspieszyć analizę dokumentacji, development, testy, code review, utrzymanie i modernizację systemów. Może skrócić czas budowania kontekstu, wesprzeć zespoły w przejmowaniu usług, pomóc w generowaniu testów, analizie logów czy przygotowaniu dokumentacji.

Ale AI może też wprowadzić nowe ryzyka.

Niekontrolowane użycie narzędzi, przekazanie nieodpowiednich danych do modelu, użycie kodu klienta w niezatwierdzonym środowisku, zbyt szerokie uprawnienia agenta, brak śladu audytowego albo automatyczne wykonanie zmiany bez właściwego review – to nie są abstrakcyjne problemy. To źródło ryzyka dla firm, które chcą skalować AI w usługach IT.

W wielu organizacjach pierwsza fala adopcji AI zaczyna się oddolnie: pojedynczy inżynierowie, zespoły lub projekty testują narzędzia i szukają wzrostu produktywności. To naturalny etap. Problem zaczyna się wtedy, gdy lokalne eksperymenty mają stać się powtarzalnym modelem dostarczania oprogramowania dla klientów.

Bez odpowiedniej strategii zarządzania organizacja nie ma pewności, czy AI jest używane bezpiecznie, a klient nie ma jasności, jak chronione są jego dane, kod, dokumentacja i własność intelektualna. Bez governance trudno przejść od punktowych usprawnień do modelu, który można skalować między zespołami, technologiami i branżami.

Nie zaczynaj transformacji AI SDLC, jeśli nie masz przemyślanego planu na strategię AI governance. Dostęp do narzędzi AI może zwiększyć produktywność lokalnie, ale bez zasad projektowych, punktów kontroli jakości (quality gates), kontroli eksperckiej (human gates) i kontrolowanej pracy z agentami nie zbudujemy bezpiecznego modelu delivery dla klientów. Właśnie dlatego w Sii łączymy modernizację inżynierii oprogramowania ze strategią zarządzania AI od samego początku – mówi Marcin Laksander, AI Transformation Lead, Sii Polska.

Jak Sii patrzy na zarządzanie AI

Doświadczenia Sii z własnej transformacji dostarczania projektów AI pokazują, że strategia governance dla AI-native delivery musi działać na trzech poziomach.

Pierwszy poziom to ład organizacyjny. Obejmuje zatwierdzone narzędzia AI klasy enterprise, proces dostępu do licencji, role użytkowników, zasady użycia narzędzi oraz ograniczanie ryzyka niekontrolowanego użycia AI, czyli shadow AI. W Sii wdrożone są już zatwierdzone narzędzia AI, proces zatwierdzania licencji w oparciu o AI oraz rozróżnienie między dostępem do narzędzia a zgodą na jego użycie w konkretnym projekcie.

Drugi poziom to ład projektowy. Każdy projekt ma własny kontekst: klienta, umowę, model usługi, środowisko pracy, dane, repozytoria, wymagania bezpieczeństwa i ograniczenia kontraktowe. Dlatego samo przyznanie narzędzia pracownikowi nie oznacza automatycznej zgody na użycie AI w projekcie. Potrzebna jest decyzja: jakie dane mogą być użyte, jakie narzędzia są dopuszczone, czy klient wymaga dodatkowej zgody, które obszary są wyłączone z użycia AI i kiedy potrzebna jest eskalacja.

Trzeci poziom to ład techniczny i workflow’owy. To obszar, w którym AI zaczyna działać nie tylko jako asystent, ale jako część procesu inżynierskiego: wykorzystując agentów AI, zestawy umiejętności, przepływy pracy, zestawy promptów, pakiety kontekstu, integracje z protokołem MCP oraz gotowe komponenty AI, które można wykorzystywać w kolejnych projektach. Ten poziom wymaga kontroli nad tym, kto tworzy takie zasoby, kto je akceptuje, gdzie są wersjonowane, jakie mają uprawnienia, jak są testowane i w jakim projekcie mogą być użyte.

To rozróżnienie jest kluczowe. Governance nie kończy się na polityce firmowej, lecz musi dotrzeć do zasad w projektach i codziennego przepływu pracy między inżynierami.

Od zasad do kontroli operacyjnej

W dojrzałym AI-native delivery same zasady nie wystarczą. Trzeba je egzekwować w praktyce.

Dlatego Sii buduje podejście, w którym AI governance jest powiązany z procesami dostarczania oprogramowania, monitorowaniem jakości i bezpieczeństwa, a także odpowiedzialnością projektową. Oznacza to m.in. kontrolę użycia narzędzi, klasyfikację danych, definiowanie no-prompt zones, projektowych zasad użycia AI, review przepływu pracy, ograniczanie uprawnień agentów oraz stosowanie quality gates i human gates (punktów kontroli jakości i punktów kontroli eksperckiej).

No-prompt zones są szczególnie ważnym elementem tego modelu. To zasady, które określają, jakiego typu danych lub kontekstu nie wolno przekazywać do narzędzi AI bez dodatkowej zgody lub kontroli. Mogą obejmować np. dane osobowe, poufne informacje klienta, niektóre elementy kodu źródłowego, sekrety, dane kontraktowe, dokumentację bezpieczeństwa lub informacje objęte szczególnymi ograniczeniami projektowymi. W Sii ten obszar jest obecnie rozwijany jako część szerszego modelu bezpiecznego użycia AI w dostarczaniu oprogramowania.

Podobnie wygląda obszar zarządzania AI dla agentów, skilli i przepływów pracy. To obszar, który dopiero dojrzewa w całej branży, ale już dziś widać, że nie można pozwolić, aby każdy zespół tworzył własne instrukcje, agentów i integracje bez wspólnych zasad. Każdy taki element powinien mieć właściciela, który zatwierdza wersję, zakres użycia, sprawuje nadzór nad procesem, nadaje ograniczenia uprawnień oraz wyznacza jasną ścieżkę akceptacji przed użyciem w projekcie klienta.

Quality gates i human gates

W tradycyjnym SDLC quality gates (punkty kontroli jakości) są dobrze znane: testy, review kodu, analiza statyczna, skanowanie podatności, wykrywanie sekretów czy kontrola zgodności ze standardami. W AI-native SDLC te mechanizmy nadal są potrzebne, ale trzeba je rozszerzyć o kontrole specyficzne dla AI.

Do AI-specific gates mogą należeć m.in. kontrola danych przekazywanych do modelu, walidacja źródeł kontekstu, sprawdzenie zgodności z no-prompt zones, ograniczenie dostępu agenta do wybranych narzędzi, kontrola wyników generowanych przez agenta oraz rejestrowanie decyzji podejmowanych w workflowach AI.

Równie istotne są human gates (punkty kontroli eksperckiej). AI może przygotować analizę, plan, kod, testy, dokumentację lub rekomendację, ale nie powinno przejmować odpowiedzialności za decyzje architektoniczne, bezpieczeństwo, zgodność z wymaganiami klienta ani release. W kluczowych punktach procesu musi być jasne, kto jako człowiek zatwierdza plan, zakres zmiany, użycie agenta, wynik testów, wyjątek lub decyzję wdrożeniową.

„Human-in-the-loop” nie jest więc suchym hasłem marketingowym. W modelu dostarczania oprogramowania w oparciu o AI udział człowieka powinien być konkretnym elementem przepływu pracy.

Skalowanie AI w delivery nie polega na tym, że organizacja dopuszcza kolejne narzędzia. Prawdziwe wyzwanie zaczyna się wtedy, gdy AI działa na podstawie kontekstu zapewnionego przez klienta, kodzie, dokumentacji, określonych przepływach pracy i decyzjach projektowych. Wtedy AI governance musi działać nie tylko jako polityka, ale jako technicznie egzekwowany model kontroli: z punktami kontroli jakości, strefami bez promptów, audytowalnością, jasną odpowiedzialnością człowieka i zasadami użycia agentów w konkretnym projekcie – mówi Michał Czyżowicz, AI Governance Stream Leader, Sii Polska.

Evidence package: zaufanie wymaga audytowalności

Kolejnym elementem dojrzewającego modelu governance jest evidence package. To uporządkowany pakiet dowodowy pokazujący, jak AI zostało użyte w konkretnym procesie dostarczania oprogramowania i jakie kontrole zostały wykonane.

Evidence package może obejmować informacje o użytym narzędziu lub modelu, context packu, danych wejściowych, promptach, przepływach pracy, testach, skanach bezpieczeństwa, wynikach walidacji, wyjątkach oraz osobie, która zaakceptowała rezultat.

Dla klienta taki mechanizm ma praktyczne znaczenie. Pozwala lepiej zrozumieć, co zostało wykonane z użyciem AI, jakie ryzyka zostały sprawdzone i kto odpowiadał za finalną decyzję. Nie zastępuje procesów zapewniania zgodności ani nie jest gwarancją braku ryzyka, ale zwiększa przejrzystość, audytowalność i kontrolę nad sposobem użycia AI w projekcie.

W Sii evidence package jest obecnie rozwijany jako element docelowego modelu AI-native delivery. To ważne szczególnie tam, gdzie klient działa w środowisku regulowanym, posiada wysokie wymagania bezpieczeństwa lub oczekuje większej przewidywalności w sposobie realizacji usług.

Co to oznacza dla klientów Sii

Dla klientów najważniejsze nie jest to, czy partner technologiczny używa AI. Coraz ważniejsze jest to, jak go używa.

Podejście Sii ma ograniczać ryzyko niekontrolowanego użycia AI, zwiększać bezpieczeństwo danych i kodu, wzmacniać audytowalność oraz zapewniać, że AI wspiera dostarczanie projektu w sposób zgodny z kontekstem. To szczególnie istotne dla klientów enterprise, gdzie decyzje technologiczne muszą uwzględniać kontrakty, compliance, bezpieczeństwo, IP, środowiska klienta i odpowiedzialność za rezultat.

Sii wykorzystuje własne doświadczenia z przebudowy modelu delivery, aby wspierać klientów w bezpiecznym wdrażaniu AI w usługach IT. To podejście jest ważne zarówno w modelu Power People powered by AI, gdzie klient otrzymuje zespoły i specjalistów przygotowanych do pracy w AI-native delivery, jak i w modelu Assess-Transform-Deliver, gdzie Sii może pomagać klientowi ocenić potencjał AI, przekształcić wybrane elementy delivery i prowadzić usługę w bardziej nowoczesnym modelu.

Nie chodzi przy tym o sprzedaż governance jako osobnego produktu. Governance jest warunkiem odpowiedzialnego AI-native delivery. Jest częścią tego, co sprawia, że AI może być stosowane w projektach klientów bez chaosu, nadmiernego ryzyka i niekontrolowanych eksperymentów.

Dlaczego Sii

Wyróżnikiem Sii jest to, że nie podchodzi do AI-native delivery wyłącznie jako do koncepcji konsultingowej. Sii buduje ten model od środka: na własnych procesach dostarczania oprogramowania, w wielu Centrach Kompetencyjnych, w różnych typach usług i technologii.

AI-native delivery dotyczy nie tylko developmentu. Obejmuje obszar testów, DevOps, IT operations, cyberbezpieczeństwa, SAP, Salesforce, analizy danych, rozwiązań chmurowych, a także utrzymania, przejmowania systemów i modernizacji istniejących rozwiązań. Taka szerokość kompetencji ma znaczenie, ponieważ zarządzanie AI w usługach IT nie może być określone wyłącznie z perspektywy jednego narzędzia lub jednego typu projektu.

W Sii ten model rozwijają zespoły delivery, eksperci techniczni, AI CoE, security, governance, testing, digital, ITO oraz przedstawiciele wielu obszarów usługowych. Dzięki temu model governance nie jest odseparowanym dokumentem. Jest częścią szerszej zmiany sposobu dostarczania usług klientom.

Podsumowanie

AI-native delivery nie rozwija się wyłącznie dzięki narzędziom, lecz przynosi skalowalne efekty wtedy, gdy bezpieczeństwo, odpowiedzialność i jakość są wbudowane w projekty, przepływ pracy, zasady pracy agentów oraz punkty kontroli jakości – quality gates i human gates.

Dla klientów oznacza to większą kontrolę nad tym, jak AI jest używane w ich projektach, a dla zespołów delivery oznacza to jasne zasady pracy. Dla organizacji oznacza to możliwość przejścia od lokalnych eksperymentów do przewidywalnego, audytowalnego i skalowalnego modelu użycia sztucznej inteligencji.

W Sii właśnie taki kierunek przyjmujemy: AI ma przyspieszać dostarczanie projektów, ale strategia AI governance (zarządzania AI) ma zapewnić, że dzieje się to bezpiecznie, świadomie i z pełną odpowiedzialnością człowieka za finalny rezultat.