Lider technologiczny z ponad 30-letnim doświadczeniem dzieli się tym, jak przejść od odizolowanych silosów AI do zarządzanego modelu operacyjnego

Prem Kumar A S ma ponad 30 lat doświadczenia w kierowaniu projektami z zakresu IT i infrastruktury chmurowej. Obecnie pełni funkcję VCTO w The Preminent.

Porozmawialiśmy z Premem, aby zrozumieć, jak organizacje mogą przejść od rozproszonych zastosowań AI do zarządzanego modelu operacyjnego. Oto, co nam powiedział.

Ponad 30 lat doświadczenia

Mam ponad 30 lat doświadczenia w kierowaniu projektami z zakresu IT i infrastruktury chmurowej na całym świecie. Obecnie pracuję jako VCTO, doradzając zarządom i dyrektorom ds. technologii w kwestiach technologii, ryzyka cybernetycznego, odporności, zaufania i zarządzania w erze AI. Skupiam się na pomaganiu zespołom kierowniczym w podejmowaniu bardziej przejrzystych, trafniejszych i lepiej przygotowanych na przyszłość decyzji.

Równocześnie prowadzę PREMINENT KONCLAVE by Power of Knowing Forum — flagową cotygodniową serię podcastów poświęconą technologii, cyberbezpieczeństwu, rozwojowi i strategii, obejmującą ponad 370 rozmów z liderami oraz rozwijający się ekosystem ekspertów.

Jak przejść od rozproszonych zastosowań AI do zarządzanego modelu operacyjnego

Przeszliśmy od eksperymentowania z narzędziami do zarządzanego modelu operacyjnego — konkretnie poprzez wprowadzenie warstwy zarządzania AI i przeglądu wdrożeń, zanim jakiekolwiek rozwiązanie wykorzystujące AI mogło zostać uruchomione produkcyjnie.

Wcześniej AI było testowane w rozproszonych obszarach — w asystentach, pilotażowych projektach automatyzacji, zastosowaniach analitycznych i niektórych eksperymentach z zakresu bezpieczeństwa. Problemem nie był brak zaangażowania, lecz fragmentacja. Poszczególne zespoły mogły oceniać, a nawet wdrażać rozwiązania wykorzystujące AI bez wspólnych zasad dotyczących klasyfikacji danych i ryzyka ich ujawnienia, granic wykorzystania modeli, zatwierdzania zewnętrznych narzędzi AI, kontroli człowieka i odpowiedzialności ani pomiaru efektów biznesowych.

Najprościej mówiąc, AI zaczynało pojawiać się w środowisku szybciej, niż nadążało za tym zarządzanie. Stwarza to trzy rodzaje ryzyka dla każdej poważnej organizacji:

1. Narażenie bezpieczeństwa i prywatności: wrażliwe dane biznesowe lub dane klientów trafiające do niezarządzanych procesów wykorzystujących AI
2. Niespójność operacyjna: zespoły korzystające z różnych narzędzi, poleceń i procesów, bez powtarzalnych standardów
3. Ryzyko na poziomie zarządu bez odpowiedniej widoczności: wykorzystanie AI rośnie, ale kierownictwo nie wie, gdzie znajduje się rzeczywiste ryzyko ani zwrot z inwestycji

Dlatego wprowadziliśmy praktyczny model kontroli AI powiązany ze sposobem tworzenia, wdrażania i zarządzania technologią — nie jako teoretyczny dokument zawierający zasady, lecz jako dyscyplinę operacyjną. Obejmowało to pięć konkretnych zmian:

1. Przypadki użycia AI musiały zostać sklasyfikowane przed wdrożeniem. Każdy proponowany przypadek użycia AI był kategoryzowany jako niskiego ryzyka zwiększający produktywność, wspierający wewnętrzne podejmowanie decyzji, skierowany do klientów lub wrażliwy/regulowany/wysokiego ryzyka. To natychmiast zmieniło rozmowę z „Czy możemy używać AI?” na „Jakiego poziomu ładu wymaga ten przypadek użycia AI?”.
2. Wdrożenie AI otrzymało obowiązkowy punkt kontrolny w procesie przeglądu. Zanim narzędzie, automatyzacja lub przepływ pracy wykorzystujący AI mogły trafić na produkcję, musiały przejść przegląd obejmujący wrażliwość danych, mechanizmy kontroli tożsamości i dostępu, ryzyko związane z dostawcą i modelem, obsługę promptów i wyników, punkty zatwierdzania przez człowieka, mechanizmy awaryjne i wycofywania zmian oraz wymagania dotyczące rejestrowania zdarzeń na potrzeby audytu. Dzięki temu wdrażanie AI stało się częścią ładu technologicznego, a nie tylko pozorowaniem innowacji.
3. Oddzieliliśmy eksperymentowanie od środowiska produkcyjnego. Stworzono kontrolowany model piaskownicy do eksperymentowania z AI. Zespoły mogły szybko testować pomysły — ale użycie produkcyjne wymagało zatwierdzonych zbiorów danych, zatwierdzonych narzędzi/modeli, wyznaczonych właścicieli, mierzalnych wyników biznesowych oraz zatwierdzenia ryzyka tam, gdzie było to wymagane. Była to duża zmiana kulturowa, ponieważ chroniła innowacje, nie pozwalając jednocześnie, aby eksperymentowanie po cichu stało się zależnością całego przedsiębiorstwa.
4. Wprowadziliśmy zasady udziału człowieka w procesie w przypadku wrażliwych przepływów pracy. Wymagaliśmy weryfikacji przez człowieka przed wykonaniem ostatecznego działania w przypadku każdego zastosowania AI wpływającego na klientów, zgodność z przepisami, decyzje finansowe, działania związane z bezpieczeństwem lub kluczową komunikację biznesową. Zapobiegło to klasycznemu błędowi polegającemu na traktowaniu wyników generowanych przez AI jako automatycznie wiarygodnych tylko dlatego, że powstały szybko.
5. Zaczęliśmy mierzyć AI na podstawie wartości operacyjnej, a nie ekscytacji. Każda inicjatywa AI musiała odpowiedzieć na pytania: Jaki nakład pracy ręcznej jest zmniejszany? Które czasy realizacji ulegają skróceniu? Jakie ryzyka są ograniczane? W jaki sposób poprawia się jakość decyzji? Jakiej korzyści w zakresie kosztów, produktywności lub odporności oczekujemy? Dzięki temu rozmowa o AI przeszła od trendu technologicznego do rozmowy o modelu operacyjnym firmy.

Dało nam to lepszą kontrolę bez zabijania tempa. Ład przestał być postrzegany jako blokada. Dzięki stworzeniu jasnej ścieżki — tutaj eksperymentuj, tutaj zapewnij ład, tutaj wdróż — zespoły działały szybciej, z mniejszym zamieszaniem i mniejszym ukrytym ryzykiem.

Ograniczyło to również ryzyko korzystania z niezatwierdzonych narzędzi AI. Uzyskaliśmy znacznie lepszą widoczność tego, jakie narzędzia były używane, które zespoły z nich korzystały, jakie dane do nich trafiały oraz które przypadki użycia miały rzeczywistą wartość biznesową. Ma to kluczowe znaczenie, ponieważ niezarządzane wdrażanie AI szybko staje się nową formą niezatwierdzonych narzędzi IT.

Jak wdrażać AI bez wywoływania chaosu

Oto kilka wskazówek dla osób, które dopiero zaczynają — jeśli chcecie uniknąć chaosu:

1. Zacznij od często wykonywanych przepływów pracy o niskim ryzyku. Nie zaczynaj od decyzji dotyczących kluczowej architektury ani autonomicznych zmian o krytycznym znaczeniu dla produkcji. Zacznij od dokumentacji, tworzenia testów, wstępnej obsługi wewnętrznych zgłoszeń, podsumowywania logów, tworzenia projektów procedur operacyjnych lub generowania informacji o wydaniach.
2. Wprowadź zabezpieczenia przed rozpoczęciem skalowania. Każde wdrożenie AI w procesie wytwarzania oprogramowania powinno określać zatwierdzone narzędzia, zasady używania promptów i danych, reguły przeglądu kodu, wymagania dotyczące skanowania bezpieczeństwa, granice zatwierdzania przez człowieka oraz rejestrowanie zdarzeń i możliwość przeprowadzenia audytu.
3. Wykonuj pomiary przed wdrożeniem i po nim. Śledź czas realizacji, częstotliwość wdrożeń, liczbę defektów wykrywanych po wdrożeniu, MTTR, częstotliwość wycofywania zmian, czas poświęcany na powtarzalne zadania oraz informacje zwrotne inżynierów dotyczące satysfakcji i produktywności.
4. Zachowaj odpowiedzialność po stronie ludzi. AI powinno wspierać inżynierów, a nie zastępować odpowiedzialność za proces wytwarzania oprogramowania. Model może sugerować. Zespół nadal musi podejmować decyzje, weryfikować, zabezpieczać i brać odpowiedzialność za wynik.

Najlepsze techniczne przypadki użycia AI

Właściwie wdrożone AI w technicznych przepływach pracy może znacząco poprawić szybkość, widoczność, produktywność i jakość decyzji. Wdrożone niewłaściwie może zwiększać skalę defektów, podnosić ryzyko operacyjne i tworzyć fałszywe poczucie pewności na dużą skalę.

Oto przypadki użycia i korzyści, które obserwuję:

Większa przepustowość prac inżynieryjnych, gdy AI jest używane do właściwych zadań: Największe korzyści zwykle pojawiają się w przypadku prac o niskiej lub średniej złożoności, takich jak generowanie kodu szablonowego, tworzenie przypadków testowych, przygotowywanie dokumentacji i procedur operacyjnych, podsumowywanie logów i wstępna analiza incydentów, tworzenie szablonów infrastruktury jako kodu, klasyfikowanie zgłoszeń oraz sugestie dotyczące rozwiązywania problemów na pierwszym poziomie. Obserwowane przeze mnie wyniki ilościowe obejmują:

• 20–40% skrócenie czasu cyklu w przypadku powtarzalnych zadań inżynieryjnych
• 15–30% wzrost przepustowości programistów w przypadku dobrze określonego zakresu prac
• 25–50% szybsza analiza incydentów, gdy AI podsumowuje dzienniki, alerty i prawdopodobne przyczyny źródłowe
• 30–60% mniej pracy związanej z dokumentacją procedur SOP, podręczników operacyjnych i artykułów baz wiedzy

Lepsza efektywność DevOps i platform: AI jest szczególnie skuteczna w operacjach DevOps/SRE/infrastruktury, gdy jest używana jako wsparcie analizy, a nie autonomiczny decydent. Na przykład korelowanie dzienników między narzędziami przebiega szybciej, szumne alerty są grupowane i podsumowywane, notatki dotyczące wdrożeń oraz kroki wycofania zmian są generowane automatycznie, wzorce wykorzystania zasobów są wykrywane wcześniej, a powtarzalne kontrole operacyjne są automatyzowane. Udoskonalenia ilościowe często obejmują:

• poprawę MTTR o 20–35% w środowiskach, w których często występują incydenty
• 10–25% mniej eskalacji do starszych inżynierów w przypadku znanych wzorców problemów
• 15–20% wyższy wskaźnik pomyślnych zmian, gdy AI służy do egzekwowania list kontrolnych wdrożeń, notatek wydań i walidacji zależności
• mniejsze obciążenie rutynowymi zadaniami zespołów wsparcia i operacji L1/L2, co pozwala starszym inżynierom skupić się na architekturze i odporności

Prem Kumar dzieli się spostrzeżeniami

Prawidłowo wdrożona AI w przepływach pracy technicznej może znacząco poprawić szybkość, widoczność, produktywność i jakość podejmowanych decyzji. Nieprawidłowo wdrożona może zwiększać liczbę defektów, ryzyko operacyjne i fałszywe poczucie pewności na dużą skalę.

Lepsze testowanie i zakres kontroli jakości: Jednym z najbardziej praktycznych zastosowań jest testowanie wspomagane przez AI. Obejmuje ono generowanie przypadków testowych na podstawie wymagań lub historyjek użytkownika, identyfikowanie scenariuszy brzegowych, tworzenie wzorców danych testowych oraz pomoc zespołom w szybszym zwiększaniu pokrycia testami regresji. Pozytywne rezultaty mogą obejmować:

• 20–35% szybsze tworzenie przypadków testowych
• większe pokrycie testami w tym samym czasie trwania sprintu
• krótsze cykle przygotowania testów regresji
• lepsze wykrywanie defektów na wcześniejszym etapie cyklu życia, jeśli prompty i walidacja są odpowiednio przygotowane

Sprawniejsze zarządzanie wiedzą i wdrażanie pracowników: AI jest niedoceniana w jednym kluczowym obszarze: utrwalaniu wiedzy ukrytej. W wielu zespołach inżynieryjnych duża część wiedzy operacyjnej znajduje się wyłącznie w głowach kilku osób. AI pomaga przekształcić ją w podręczniki operacyjne z możliwością wyszukiwania, instrukcje rozwiązywania problemów, podsumowania architektury, przewodniki wdrożeniowe i zestawienia RCA. Typowe korzyści obejmują:

• szybsze wdrażanie nowych inżynierów
• mniejszą zależność od kilku „bohaterów”
• lepsze przekazywanie wiedzy między zespołami
• mniej czasu spędzanego na przeszukiwaniu starych zgłoszeń i wątków w Slacku/Teams

Dla rozwijających się małych i średnich firm oraz średniej wielkości organizacji inżynieryjnych może to być jedno z zastosowań o najwyższym zwrocie z inwestycji, ponieważ poprawia skalowalność wiedzy inżynieryjnej, a nie tylko wydajność tworzenia kodu.

Wady AI

Oczywiście rezultaty nie są wyłącznie pozytywne:

• Wskaźniki defektów mogą wzrosnąć, jeśli AI zostanie zbyt szybko wdrożona do środowiska produkcyjnego. Największym błędem, który obserwujemy, jest traktowanie kodu wygenerowanego przez AI jako „produktywności programistów” bez wzmocnienia przeglądów, testów i walidacji bezpieczeństwa.
• Ryzyko związane z bezpieczeństwem i zgodnością rośnie bez odpowiednich zabezpieczeń. Jest to poważny problem w środowiskach regulowanych lub wrażliwych.

• Zespoły mogą pracować szybciej, ale z mniejszą rozwagą. Jedną z subtelnych wad jest przenoszenie obciążenia poznawczego. AI powinna ograniczać wysiłek mechaniczny, a nie ograniczać myślenie inżynieryjne.
• Czas cyklu się skraca, ale jakość dostarczania nie wzrasta. To jedna z najczęstszych pułapek dla kadry zarządzającej: zespoły świętują szybsze tworzenie kodu, ale ignorują to, czy poprawił się rezultat biznesowy. Sukcesu AI nie można mierzyć wyłącznie tym, „o ile szybciej programiści piszą kod”. Należy go mierzyć na podstawie częstotliwości wdrożeń, wskaźnika nieudanych zmian, wskaźnika defektów, które przedostały się do kolejnych etapów, MTTR, liczby ustaleń dotyczących bezpieczeństwa, kosztu wydania oraz zaoszczędzonych godzin pracy inżynieryjnej w porównaniu z nakładem pracy na poprawki.

Czego AI nigdy nie powinno dotykać

To obszary, w których AI powinno wspierać proces myślenia, ale nigdy nie zastępować człowieka odpowiedzialnego za podejmowanie decyzji.

• Akceptowanie ryzyka. Żadne AI nie powinno decydować o tym, czy zaakceptować ryzyko bezpieczeństwa, odroczyć instalację poprawki, działać pomimo znanej luki w mechanizmach kontroli ani kontynuować wydania z nierozwiązanymi problemami. Ta decyzja należy do odpowiedzialnego lidera, ponieważ wiąże się z konsekwencjami finansowymi, prawnymi i wizerunkowymi.
• Przywództwo w sytuacjach kryzysowych. Podczas poważnej awarii, incydentu cyberbezpieczeństwa, naruszenia danych lub eskalacji regulacyjnej AI może pomóc w analizie danych i wyborze opcji. Jednak ludzie muszą odpowiadać za komunikację z interesariuszami, kontakty z organami regulacyjnymi, decyzje dotyczące zaufania klientów, komunikację kierownictwa oraz kierowanie sztabem kryzysowym.
• Etyka, prywatność i kompromisy biznesowe. AI nie może być ostatecznym autorytetem w kwestii tego, czy wykorzystanie danych jest etycznie dopuszczalne, czy decyzja jest sprawiedliwa wobec klientów lub pracowników, czy mechanizm nadzoru lub monitorowania jest proporcjonalny ani czy wygoda biznesowa powinna przeważyć nad zasadami budowania zaufania. Są to decyzje przywódcze.

Dlaczego architektura nie dotyczy już wyłącznie skalowania i wydajności

AI zmusiło mnie do ponownego przemyślenia założenia, że architekturę projektuje się raz, a następnie optymalizuje w czasie. Ten model sprawdzał się, gdy systemy zmieniały się stopniowo. Przestaje działać, gdy agenci AI, asystenci programistyczni, warstwy automatyzacji i potoki danych zaczynają dynamicznie wpływać na zachowanie środowiska produkcyjnego.

Prem Kumar dzieli się spostrzeżeniami

Architektura nie dotyczy już wyłącznie skalowania i wydajności. Obecnie chodzi w niej o zdolność adaptacji, identyfikowalność, odporność i zarządzanie.

Dziś architekturę należy traktować jako żywy system kontroli, a nie stały schemat. Oznacza to, że:

• Systemy muszą być projektowane z myślą o ciągłej adaptacji.
• Obserwowalność musi wykraczać poza infrastrukturę i obejmować zachowanie AI oraz jakość podejmowanych decyzji.
• Bezpieczeństwo musi przejść od obrony perymetrycznej do wbudowanego zaufania, kontroli i odporności.

Innymi słowy, architektura nie dotyczy już wyłącznie skalowania i wydajności. Obecnie chodzi w niej o zdolność adaptacji, identyfikowalność, odporność i zarządzanie.

Rady dla CTO

Moja rada dla CTO jest prosta: nie traktujcie AI wyłącznie jako wyścigu technologicznego — potraktujcie je jako moment przywództwa biznesowego. Obecnie zbyt wiele organizacji ściga się, wdrażając projekty pilotażowe, narzędzia i przypadki użycia AI, bez zadania sobie najważniejszych pytań: Jaki problem biznesowy rozwiązujemy? Jakie ryzyko wprowadzamy? Jaką zdolność budujemy z myślą o długim okresie?

CTO muszą kierować zmianą związaną z AI na pięciu frontach:

1. Zacznij od wartości biznesowej, a nie od szumu wokół AI. Jeśli AI nie jest powiązana ze wzrostem przychodów, produktywnością, doświadczeniem klienta, ograniczaniem ryzyka lub szybkością realizacji, staje się eksperymentowaniem bez wpływu na wyniki.
2. Buduj AI na solidnych fundamentach. AI nie zrekompensuje słabej infrastruktury, rozproszonych danych, niewłaściwego zarządzania ani niejasnego zakresu odpowiedzialności. CTO muszą najpierw zadbać o właściwą dyscyplinę danych, gotowość chmurową organizacji, zabezpieczenia cyberbezpieczeństwa i architekturę integracji. Bez tego AI będzie szybciej skalować chaos niż wartość.
3. Traktuj cyberbezpieczeństwo, prywatność i zarządzanie jako zasady projektowe. To nie jest moment na dodawanie zabezpieczeń na późniejszym etapie. AI wprowadza nowe zagrożenia — wycieki danych, niewłaściwe wykorzystanie modeli, uprzedzenia, halucynacje, luki w zgodności z przepisami oraz korzystanie z niezatwierdzonych narzędzi AI przez zespoły. Najlepsi CTO będą od pierwszego dnia uwzględniać zarządzanie AI, kontrolę dostępu, ochronę danych, odpowiedzialność za modele i nadzór człowieka w modelu operacyjnym.
4. Zdefiniuj na nowo rolę lidera technologicznego. W tej erze CTO nie jest już tylko opiekunem systemów. CTO musi stać się tłumaczem między ambicjami biznesowymi a rzeczywistością techniczną — pomagając zarządowi i zespołowi kierowniczemu zrozumieć, co AI naprawdę potrafi, gdzie może zawieść i jak wdrażać ją w odpowiedzialny sposób. Chodzi tu w równym stopniu o edukację, ustalanie priorytetów i budowanie zaufania, co o architekturę.
5. Najpierw skup się na wspomaganiu, a dopiero potem na automatyzacji. Najlepsza strategia AI nie brzmi: „Jak zastąpić ludzi?”. Powinna brzmieć: „Jak sprawić, by nasi ludzie pracowali szybciej, trafniej i skuteczniej?”. AI powinna w pierwszej kolejności wspomagać zespoły — usprawniać podejmowanie decyzji, ograniczać powtarzalną pracę, przyspieszać analizę i uwalniać talenty, aby mogły zajmować się zadaniami o większej wartości. To właśnie buduje zaufanie, poprawia adopcję i sprawia, że transformacja staje się trwała.

Bądź na bieżąco

Możesz śledzić działalność Prem na LinkedInie. Zajrzyj także do jego podcastu PREMINENT KONCLAVE.

Wkrótce na The CTO Club pojawią się kolejne wywiady z ekspertami!