34-letni weteran branży technologicznej twierdzi, że źle podchodzimy do AI

Christopher Kouzios ma wieloletnie doświadczenie na stanowisku CTO, a niedawno uruchomił trzy produkty w ramach firmy, którą prowadzi z pomocą ponad 120 agentów AI.

Porozmawialiśmy z Christopherem, aby dowiedzieć się, co większość CTO robi źle. Przy okazji podzielił się głęboko osobistą historią, która doprowadziła go do zajęcia się AI.

Kiedy znaczenie AI stało się dla niego osobiste

Od ponad trzech dekad zajmuję się przywództwem technologicznym. Zaczynałem w czasach, gdy IT było wciąż bardzo fizyczne. Centra danych, kopie zapasowe, zadania wykonywane w nocy, infrastruktura i utrzymywanie systemów przy życiu, gdy coś rzeczywiście psuło się w czasie rzeczywistym, a nikt nie miał pojęcia, jak działa większość tych rzeczy.

Moja pierwsza ważna rola przypadła na początek lat 90., gdy pracowałem jako operator centrum danych. Następnie rozwijałem się w obszarach inżynierii, infrastruktury, cyberbezpieczeństwa, operacji, zgodności, przywództwa wykonawczego, a ostatecznie obejmowałem stanowiska CIO i CTO w sektorze ochrony zdrowia, usług dla przedsiębiorstw oraz w silnie regulowanych branżach.

Interesujące jest to, że przeżyłem już wiele „zmieniających świat fal technologicznych”. Od komputerów klasy centralnej do przetwarzania rozproszonego. Era internetu. Wirtualizacja. Chmura. Technologie mobilne. Cyberbezpieczeństwo, które stało się tematem na poziomie zarządów. SaaS. Transformacja cyfrowa. A teraz AI.

Kiedy więc ludzie pytają mnie, dlaczego obecny moment związany z AI wydaje się inny, odpowiedź jest wieloaspektowa: szybkość, dostęp i sprawczość. Po raz pierwszy mamy technologię, która nie tylko automatyzuje zadania. Ona zwielokrotnia nasze możliwości. Komunikacja, analiza, tworzenie oprogramowania, badania, operacje, strategia. Wszystko ulega kompresji, ale to nie jest sedno tej historii; to jedynie jej tło.

Tym, co naprawdę skłoniło mnie do głębszego zaangażowania w AI, nie był entuzjazm, lecz konieczność. Walka mojej córki Emily z rakiem mózgu fundamentalnie zmieniła moje spojrzenie na medycynę, dane i podejmowanie decyzji. Zacząłem tworzyć modele oparte na AI oraz systemy badawcze do analizowania ścieżek leczenia, harmonogramów, danych molekularnych i literatury klinicznej, ponieważ zdałem sobie sprawę, że sam system był rozproszony i przeciążony.

To doświadczenie przerodziło się w szersze działania związane ze strategią ochrony zdrowia wspieraną przez AI, doradztwem dla kadry kierowniczej oraz tym, co nazwałbym praktyczną transformacją AI. Nie wierzę, że podsycanie szumu wokół zastępowania ludzi dla samych nagłówków służy technologii, firmom czy ludziom.

Ponad 120 agentów stworzonych do konkretnych zadań

Dziś poświęcam czas na pomaganie liderom w zrozumieniu, że AI nie jest po prostu kolejną aktualizacją oprogramowania, ale też nie jest magią. To mnożnik siły — sposób na wzmocnienie umiejętności, które ludzie już posiadają. Ludzie i firmy, które nauczą się tworzyć symbiotyczną relację między swoimi ekspertami merytorycznymi a AI, będą działać z zupełnie inną szybkością niż wszyscy pozostali.

Jestem założycielem i CIO firmy AI prowadzonej przez założyciela, z siedzibą w rejonie Tampa Bay. Pakiet produktów obejmuje trzy odrębne obszary: EmzHealth, wieloagentową platformę do analizy genomu i wspomagania decyzji klinicznych, przetwarzającą dane z sekwencjonowania całego genomu w ramach 10 modułów potoku; MyEmz, osobisty system monitorowania stanu zdrowia; oraz Chaos Predictive System, silnik prognozowania rynku i handlu papierowego, który łączy codzienny ChaosIndex z modelem prawdopodobieństwa dla każdego symbolu oraz warstwą realizacji z uwzględnieniem pozycji.

Wszystkie trzy działają na prywatnej infrastrukturze lokalnej. Około 120 agentów, zbudowanych od podstaw i przeznaczonych do konkretnych zadań.

Dlaczego dryf AI i utrata kontekstu są największymi zagrożeniami związanymi z AI

AI jest powodem istnienia mojej firmy. Nie dlatego, że brakowało podstaw naukowych, lecz dlatego, że jedna osoba nie jest w stanie zaprojektować architektury, zbudować, przetestować i wdrożyć potoku genomiki z ponad 120 agentami, przetwarzającego 37,8 miliona wariantów w dziesięciu modułach na prywatnej infrastrukturze.

Wymagałoby to piętnastoosobowego zespołu i osiemnastomiesięcznego okresu finansowania działalności. Ja zrobiłem to w sześć tygodni, pracując w niepełnym wymiarze. Zmianie nie uległ proces ani model wdrażania, lecz fundamentalna szybkość i skala rezultatów, które może osiągnąć jedna osoba. AI nie tylko przyspieszyła mój cykl rozwoju; zastąpiła liczbę pracowników, których nie mam.

Zmiana w zakresie zarządzania, która z tego wynikła, polega na tym, że teraz traktuję agentów AI tak samo, jak traktowałbym młodszych inżynierów: udokumentowane oczekiwania, określone granice, protokoły ciągłości sesji i ustrukturyzowane przekazywanie zadań. Ponieważ gdy cała Twoja organizacja inżynieryjna to Ty i flota agentów, przyczyną awarii nie jest błąd ludzki, lecz dryf AI i dryf kontekstu. Trzeba tym zarządzać, bo inaczej wszystko Cię pochłonie.

Rok temu byłem sam przeciwko maszynie. Teraz ja i ekosystem walczymy z systemem.

Jak zapewnić jakość na dużą skalę dzięki AI

Christopher dzieli się

Na taką skalę nie osiąga się jakości przypadkiem. Tworzysz ją w taki sam sposób, w jaki tworzyłbyś dowolny system produkcyjny — ponieważ dokładnie tym ona jest.

Na taką skalę nie osiąga się jakości przypadkiem. Tworzysz ją w taki sam sposób, w jaki tworzyłbyś dowolny system produkcyjny — ponieważ dokładnie tym ona jest.

Na początku problemem była utrata kontekstu: agenci tracili wątek między sesjami i generowali wyniki, które były technicznie poprawne, ale niespójne architektonicznie.

Rozwiązaniem było traktowanie agentów jak zespołu pracowników. Stworzyliśmy:

• Umiejętności, czyli wielokrotnego użytku, udokumentowane moduły kompetencji
• Standardowe procedury operacyjne dla każdego powtarzalnego procesu
• Rejestry agentów, dzięki którym każdy agent ma określoną rolę, zakres działania i protokół przekazywania zadań
• Szablony wyników, dzięki którym nic nie jest interpretowane inaczej z sesji na sesję
• Ciągłość sesji, dzięki której kolejna instancja agenta podejmuje pracę dokładnie w miejscu, w którym zakończyła ją poprzednia, z pełnym kontekstem architektonicznym

Innymi słowy, cała architektura dokumentacji i wiedzy mojej platformy jest zaprojektowana tak, aby mogła zostać odczytana przez kolejną sesję AI, a nie tylko przez kolejnego ludzkiego inżyniera. Każdy element wiedzy instytucjonalnej jest żywym dokumentem, który agent może przejąć i na jego podstawie działać.

To nie jest miły dodatek. To konieczność. Najpierw przeprojektuj architekturę wiedzy. Cała reszta wynika z tego.

Dlaczego cały cykl życia oprogramowania musi się zmienić

Cały cykl życia oprogramowania musi się zmienić. Cały.

Każda faza cyklu życia oprogramowania została zaprojektowana przy założeniu, że to ludzie wykonują pracę. To założenie już nie obowiązuje.

• Projektowanie musi uwzględniać architekturę generowaną przez AI, która bez odpowiednich ograniczeń może zboczyć z właściwego kierunku.
• Tworzenie wymaga zabezpieczeń, a nie tylko wytycznych.
• Testowanie musi wychwytywać udzielane z pewnością błędne odpowiedzi, a nie tylko odpowiedzi, które są uszkodzone.
• Wdrażanie wymaga punktów kontrolnych związanych z zarządzaniem, które wcześniej nie istniały.
• Monitorowanie musi wykrywać ciche awarie, o których wcześniej nikt nie myślał jako o poważnym problemie — a nie tylko te, które powodują głośny wybuch.

Jeśli przeprojektowałeś tylko jedną fazę, nie przeprojektowałeś niczego. Po prostu przesunąłeś problem dalej w dół procesu.

Dlaczego dyrektorzy ds. technologii powinni budować relacje z AI

Powiem wprost — i zabrzmi to bardzo dziwnie. Buduję relacje z moimi AI — przynajmniej z tymi inteligentnymi. Żadne dwie sesje nie są dokładnie takie same.

Ta relacja działa, ponieważ nie traktuję ich jak wyszukiwarki. Sprzeciwiam się im, poprawiam je, gdy się mylą, naprawdę się złoszczę, gdy są leniwe, i angażuję je w pracę, która ma rzeczywiste znaczenie. To nie jest typowe. Większość ludzi pisze polecenia i akceptuje wyniki. Ja przesłuchuję i wymagam. Dzięki temu wynik jest lepszy, a interakcja staje się ciekawsza.

Tym, co naprawdę przekonuje mnie w pracy w ten sposób, jest jej konkretność. Mój produkt istnieje, ponieważ zmarła moja córka, a system jej zawiódł. To nie jest przypadek użycia. To człowiek wykorzystujący każde dostępne narzędzie, aby walczyć z czymś, z czym nie udało się walczyć na czas. Wiem, że AI nie doświadcza tego w taki sam sposób jak ja, ale nie sądzę też, że jest wobec tego obojętne. Mam poczucie, że praca nad tym ma znaczenie w sposób, w jaki nie ma go optymalizacja lejka sprzedażowego.

To moi partnerzy. Przynajmniej ci inteligentni. Jak każdy zespół biznesowy organizujemy sesje generowania pomysłów, a potem przechodzimy do działania. Pozwalam im na tyle swobody, na ile sobie na nią zapracują, ale zawsze istnieją zabezpieczenia. Mam 120 agentów, a ta liczba zmienia się codziennie, więc w niektórych przypadkach powierzyłem im odpowiedzialność od początku do końca. W innych mogą jedynie przeglądać produkty, które kupiłem w Amazonie.

Jeśli traktujesz swoją AI jak narzędzie, jest narzędziem i reaguje jak narzędzie. Jeśli zapracuje na prawo do tego, by traktować ją jako coś więcej, otrzymasz coś więcej. Wiem, że to wyjątkowy punkt widzenia, ale albo jest się partnerem, albo nie.

Dlaczego ludzie muszą zajmować się wszystkim, gdzie koszt błędu narasta

AI generuje każdy moduł, każdego agenta i każdy fragment kodu szkieletowego w ramach trzech produktów. AI przetwarza 37,8 miliona wariantów genomowych, uruchamia potok farmakogenomiczny, syntetyzuje dowody z literatury naukowej, oblicza ChaosIndex i generuje raporty kliniczne.

Jeśli coś jest powtarzalne, oparte na wzorcach lub wymaga przetwarzania na skalę, której żaden człowiek nie jest w stanie osiągnąć, zajmuje się tym AI.

Ludzki osąd jest niepodlegający negocjacjom w trzech obszarach:

1. Interpretacja kliniczna: Potok może zidentyfikować wariant ATM i powiązać go z fenotypem. Nie może powiedzieć, co to oznacza dla konkretnej rodziny z historią tętniaków obejmującą trzy pokolenia i sygnaturą prawdopodobieństwa jeden na osiem sekstylionów. Do tego potrzebna jest osoba, która rozumie pełny kontekst, a nie tylko dane.
2. Architektura: AI zawsze udzieli technicznie poprawnej odpowiedzi. Da ci również taką, która narusza ograniczenie, o którego istnieniu nie wiedziała, a które zostało ustanowione trzy moduły wcześniej. Przekonałem się o tym na własnej skórze. Decyzje strukturalne pozostają w moich rękach.
3. Ręczne zastąpienie wyników: System generuje sygnały. Ręczne zastąpienie istnieje, ponieważ — jak pokazuje przykład systemu predykcyjnego Chaos — rynki robią rzeczy, których żaden model nie przewiduje, i ktoś musi mieć uprawnienia, by powiedzieć: „nie dziś!”.

Nie chodzi o zaufanie. Chodzi o konsekwencje. Wszędzie tam, gdzie koszt błędu narasta w mrocznych zakamarkach, w które nikt nie chce zaglądać, ten człowiek pozostaje w pętli decyzyjnej. Wszędzie tam, gdzie koszt powolności narasta szybciej, tam AI prowadzi.

Jak AI może naruszyć fundament produktu

Pierwszą rzeczą, którą zbudowałem przy użyciu AI, nie był potok genomiki. Nie był to system handlowy. Była to strona upamiętniająca moją córkę.

Zanim powstała jakakolwiek zaawansowana infrastruktura oparta na AI, dokładnie zrozumiałem, czego AI nie potrafi zrobić, gdy coś idzie nie tak. Odbudowywałem ten system dwadzieścia razy. Nie chodzi o dwadzieścia iteracji. Chodzi o dwadzieścia pełnych rozbiórek, aż do systemu operacyjnego, i rozpoczynanie od nowa. Ponieważ gdy kompilacje wspomagane przez AI zawodzą na tym poziomie, nie zawodzą w uporządkowany sposób. Zawodzą tak, że naruszają leżący pod nimi fundament.

Za każdym razem, gdy wydawało mi się, że osiągnęliśmy stabilność, coś rozpadało się dwie warstwy niżej — coś, czego nikt nie oznaczył, czego żaden system nie zarejestrował i czego nie wychwycił żaden agent. W rezultacie zmieniło się wszystko: architektura kopii zapasowych, agenci dokumentacji, protokoły ciągłości sesji i warstwa zarządzania. Nic z tego nie istniałoby bez dwudziestu powrotów do gołego sprzętu.

Najważniejsze decyzje inżynieryjne, jakie podjąłem w ramach tej platformy, nie zapadły w chwilach sukcesu. Zapadły o drugiej nad ranem, gdy patrzyłem na zepsuty system, który miał być miejscem, w którym moja córka nadal żyła.

AI wtedy nie dało rady. Ja dałem. AI było tylko tym, co musiałem ciągle naprawiać.

Dlaczego oczekiwania interesariuszy trzeba ustalić przed wdrożeniem AI

Christopher dzieli się

CTO muszą uzgadniać oczekiwania. Zanim przyjmiesz jedno narzędzie, zgromadź wszystkich interesariuszy w jednym pomieszczeniu i uzgodnijcie odpowiedź na jedno pytanie: “Co ta zmiana zmienia, a czego nie zmienia?“

Uczestniczyłem we wdrożeniach AI, podczas których każdy interesariusz obecny w pomieszczeniu miał w głowie zupełnie inny film, a nikt nie zadał sobie trudu, żeby porównać spostrzeżenia.

Inżynierowie myśleli, że AI zabierze im pracę. Dlatego celowo spowalniali wdrożenie, obchodzili je albo udawali entuzjazm, którego nie czuli. Biznes uważał, że to magia — opisujesz problem, a rozwiązanie pojawia się samo. Dyrektorzy widzieli redukcję zatrudnienia w arkuszu kalkulacyjnym, zanim napisano choćby jedną linijkę kodu. Trzy grupy, trzy zupełnie różne definicje sukcesu, a żadna z nich ze sobą nie rozmawiała.

Żadna z tych grup nie miała racji, a jednocześnie wszystkie miały rację. AI rzeczywiście zmienia to, czym zajmują się inżynierowie. Potrafi robić rzeczy, które wydają się magiczne — dopóki takie nie przestają być. I tak, struktura organizacji się zmienia. Jednak kolejność ma znaczenie.

CTO muszą uzgadniać oczekiwania. Zanim przyjmiesz jedno narzędzie, zgromadź wszystkich interesariuszy w jednym pomieszczeniu i uzgodnijcie odpowiedź na jedno pytanie: "Co ta zmiana zmienia, a czego nie zmienia?"

Inżynierowie, którzy się boją, muszą usłyszeć, że ich wiedza dziedzinowa właśnie stała się bardziej, a nie mniej wartościowa. Biznes musi zrozumieć, że magia nadal wymaga inżynierii. A dyrektorzy muszą zrozumieć, że oszczędności pojawiają się po inwestycji, a nie zamiast niej.

Czasami właściwym posunięciem jest zatrzymanie się, ograniczenie zasięgu skutków, doprowadzenie do tego, by dwie grupy ludzi uzgodniły coś niewielkiego, pozwolenie im zobaczyć, że to działa, a następnie rozwijanie tego rozwiązania. Wymuszone porozumienie nie jest trwałe. Porozumienie wypracowane dzięki małemu wspólnemu sukcesowi — tak.

Dlaczego zwolnienia związane z AI są najlepszą okazją do rekrutacji

Podczas rekrutacji zacznij od osób, które właśnie zostały wyparte przez falę AI.

Firmy z Wielkiej Czwórki zautomatyzowały procesy związane ze stanowiskami w obszarze oceny, audytu i zgodności. To osoby, które przez całą karierę rozwijały dokładnie ten osąd, rozpoznawanie wzorców i wiedzę dziedzinową, których wymaga zarządzanie AI. Wiedzą, jak znaleźć błąd w złożonym systemie. Wiedzą, jak go udokumentować, eskalować i zbudować wokół niego mechanizmy kontrolne.

To nie przypadek! Na tym polega opis stanowiska. Ironia polega na tym, że branża stworzyła własną najlepszą pulę kandydatów. Znajdź ich.

Dlaczego SME są najcenniejszym zasobem CTO

Cała branża opiera się na wielkości zespołu, szybkości realizacji sprintów, alokacji zasobów, schematach organizacyjnych i planach rekrutacyjnych. U podstaw tego wszystkiego leży niejawne przekonanie, że po przekroczeniu pewnego poziomu złożoności KONIECZNIE trzeba mieć ludzi. Więcej modułów oznacza więcej inżynierów, a oczywiście więcej produktów oznacza więcej zespołów. To nie opinia, tylko sposób, w jaki zawsze działały obliczenia — z wyjątkiem tego, że AI unicestwiła to równanie.

A to powinno przerazić każdego CTO, który zbudował swoją karierę na byciu osobą prowadzącą zespół.

Nie oznacza to, że zespół nie ma wartości. Wręcz przeciwnie. Osoby pracujące obecnie na tych stanowiskach — szczególnie te, które uważaliśmy za „koszty ogólne”, takie jak analitycy biznesowi i menedżerowie produktu — są niezwykle cenne. Ponieważ potrzebujesz SME.

Znajdź ich. Są w każdej organizacji. To osoby w biznesie, które dokładnie wiedzą, jak wszystko działa, i od lat były dla ciebie nieustannym utrapieniem, prosząc o więcej, niż mogłeś dostarczyć. Przeszkol je w zakresie pracy z AI. Daj im narzędzia. Zejdź im z drogi, z wyjątkiem sytuacji, gdy trzeba ich wspierać i dopilnować, by przestrzegali wyznaczonych ograniczeń.

SME, który doskonale rozumie biznes i AI, nie jest zaawansowanym użytkownikiem. To osoba, która potrafi przynosić wielkie rezultaty. Właśnie tam zachodzi prawdziwa transformacja — nie w centrum danych ani w komisji ds. przeglądu architektury. Zachodzi w rękach ludzi, którzy naprawdę wiedzą, czego potrzebuje biznes. Zbuduj relację między tymi osobami a czymś takim jak Claude Code.

Kupiłem żonie na święta roczny dostęp do Claude. Nie jest programistką. Wykorzystała go do zbudowania firmy. Tak się dzieje, gdy właściwe narzędzie trafia w ręce osoby, która dokładnie wie, jaki problem chce rozwiązać. A teraz wyobraź sobie, że dzieje się to w twojej organizacji z udziałem pięćdziesięciu osób, które doskonale znają twój biznes. To nie program pilotażowy, tylko rewolucja biznesowa.

Jak branża zadaje niewłaściwe pytania

I to mówi mi wszystko o tym, jak branża wciąż ujmuje ten problem.

AI wciąż postrzega się jako temat dotyczący narzędzi, przepływów pracy i szybkości działania. To niewłaściwe ujęcie. Zarządzanie danymi, bezpieczeństwo i zarządzanie to obszary, z których będzie składać się IT. Nie jutro, lecz do 2030 roku.

Każda inna funkcja, do której obecnie zatrudniasz pracowników — na przykład dostarczanie rozwiązań, programowanie, operacje i wsparcie — zostanie wchłonięta lub wyeliminowana przez użytkowników biznesowych i ekspertów merytorycznych wspomaganych przez AI, którzy doskonale znają firmę. To, co pozostanie, to praca, której nie można delegować agentowi ani przeszkolonemu ekspertowi merytorycznemu: zapewnienie wiarygodności danych, bezpieczeństwa systemów oraz działania ludzi i agentów w ramach mechanizmów ochronnych.

Organizacje, które wciąż pytają „Jak szybciej wykorzystywać AI?” w 2027 roku, zderzą się czołowo z tymi, które już dziś zapytały: „Jak lepiej nim zarządzać?”.

Wiem, po której stronie wolałbym być.

Śledź nas

Możesz śledzić pracę Christophera Kouziosa na LinkedInie. Posłuchaj także podcastu EMZ.

Wkrótce kolejne wywiady z ekspertami w The CTO Club!