Globalny dyrektor techniczny ds. wdrożeń apeluje do liderów o skupienie się na infrastrukturze danych przed wdrażaniem AI

Kai Waehner jest globalnym dyrektorem technicznym ds. rozwiązań terenowych w firmie Confluent i doradzał dużym przedsiębiorstwom, takim jak BMW i Siemens. Koncentruje się na infrastrukturze danych, strategii integracji oraz wdrażaniu sztucznej inteligencji.

Porozmawialiśmy z Kaiem, aby zrozumieć, dlaczego tak wiele inicjatyw związanych ze sztuczną inteligencją w przedsiębiorstwach kończy się niepowodzeniem. Oto, co miał do powiedzenia.

Przewaga wynikająca z rozpoznawania wzorców

Nazywam się Kai Waehner. Przez ostatnie dziewięć lat byłem globalnym dyrektorem technicznym ds. rozwiązań terenowych w firmie Confluent, współpracując z setkami przedsiębiorstw w Ameryce Północnej, Europie i regionie Azji i Pacyfiku. Doradzałem firmom takim jak BMW, Volkswagen, Lufthansa, Siemens, DISH Networks i Globe Telecom. Współpracuję z kadrą kierowniczą w zakresie strategii technologicznej, realizacji strategii wejścia na rynek, oceny dostawców, architektury przedsiębiorstwa i tworzenia treści.

Rola dyrektora technicznego ds. rozwiązań terenowych różni się od zarządzania pojedynczą organizacją inżynieryjną. Pracuję jednocześnie w dziesiątkach środowisk klientów, doradzając architektom i członkom najwyższej kadry kierowniczej w zakresie infrastruktury danych, strategii integracji oraz wdrażania sztucznej inteligencji. Ta szeroka perspektywa daje mi przewagę w rozpoznawaniu wzorców, którą trudno uzyskać wewnątrz jednej firmy.

Moje doświadczenie obejmuje całą historię integracji danych w przedsiębiorstwach: ETL, ESB, iPaaS i zarządzanie interfejsami API, a następnie dziewięć lat koncentracji na strumieniowaniu danych, gdzie Apache Kafka i Flink stanowią podstawę architektur sterowanych zdarzeniami, oraz coraz większe zaangażowanie w orkiestrację procesów i sztuczną inteligencję w całym spektrum — od predykcyjnego uczenia maszynowego po generatywną i autonomiczną sztuczną inteligencję. Regularnie przedstawiam analitykom z Gartnera i Forrester opinie na temat rynku oraz publikuję własne badania, obejmujące krajobraz dostawców, wzorce architektoniczne i rzeczywiste studia przypadków z różnych branż. Opublikowałem również książkę o strumieniowaniu danych.

Rozmowa o transformacji wykorzystującej sztuczną inteligencję, którą prowadzę z liderami technologicznymi, nie dotyczy przede wszystkim modeli. Chodzi o infrastrukturę, na której te modele działają. Systemy autonomicznej sztucznej inteligencji, które podejmują samodzielne działania w ramach procesów przedsiębiorstwa, potrzebują trzech elementów, aby działać niezawodnie:

• Danych w czasie rzeczywistym, aby działać na podstawie aktualnego stanu rzeczy
• Inteligencji procesowej, która określa, co wolno im robić
• Zaufania wbudowanego w architekturę, a nie tylko w model

Na tym właśnie skupiają się moje przemyślenia.

Dlaczego warstwy architektury muszą się połączyć, aby sztuczna inteligencja odniosła sukces

We wszystkich branżach konsekwentnie obserwuję, jak przedsiębiorstwa intensywnie inwestują w trzy oddzielne warstwy: szkielet integracji danych, warstwę automatyzacji procesów oraz, coraz częściej, inicjatywę związaną ze sztuczną inteligencją. Problem polega na tym, że te trzy elementy niemal nigdy nie są projektowane tak, aby współpracowały ze sobą. Integracja danych przenosi dane, ale nie łączy ich z decyzjami biznesowymi. Automatyzacja procesów egzekwuje przepływy pracy, ale działa w oparciu o nieaktualny kontekst. Agenci sztucznej inteligencji generują rekomendacje lub podejmują działania, lecz nie mają zarządzanych ograniczeń określających, co mogą robić. Każda warstwa działa w izolacji. Brakuje połączonej architektury.

Modele wdrożeniowe, które obserwuję, znacznie się różnią. Niektóre organizacje korzystają w pełni z zarządzanej infrastruktury natywnej dla chmury w AWS, Azure lub GCP, a większe globalne przedsiębiorstwa często uwzględniają również wdrożenia w Chinach kontynentalnych w Alibaba Cloud, celowo utrzymywane oddzielnie ze względów prawnych, regulacyjnych i związanych z prywatnością danych. Inne korzystają z architektur hybrydowych, w których lokalne centra danych są połączone z chmurą, ze względu na wymagania dotyczące suwerenności danych lub starsze systemy, których nie można szybko przenieść. Branże regulowane, takie jak usługi finansowe i opieka zdrowotna, niemal zawsze muszą spełniać wymagania dotyczące wielu regionów lub wielu chmur — nie z wyboru, lecz z powodu obowiązujących przepisów. Klienci z sektora produkcyjnego często korzystają z wdrożeń brzegowych, w ramach których dane są przetwarzane w pobliżu hali fabrycznej, zanim zostaną zagregowane centralnie.

We wszystkich tych środowiskach architektura sterowana zdarzeniami stała się infrastrukturą o znaczeniu krytycznym dla działalności. Apache Kafka wyłoniła się jako faktyczny standard brokera zdarzeń, umożliwiający rzeczywiste rozdzielenie systemów, przetwarzanie w czasie rzeczywistym na dowolną skalę oraz integrację środowisk hybrydowych i wielu chmur. PayPal przetwarza codziennie ponad bilion komunikatów Kafka. New Relic pozyskuje miliardy punktów danych na minutę. Nie są to wdrożenia eksperymentalne. Stanowią one operacyjny kręgosłup działalności.

Wiele przedsiębiorstw ma już trzy elementy potrzebne do zaufanej autonomicznej sztucznej inteligencji. Brakuje im architektonicznego zobowiązania, aby je połączyć.

Dlaczego gotowość danych poprzedza gotowość na sztuczną inteligencję

Myśli Kaia

Gotowość na sztuczną inteligencję to gotowość danych.

Oto, czego się dowiedziałem: sztuczna inteligencja nie jest najtrudniejszym elementem. Najtrudniejsza jest leżąca u jej podstaw infrastruktura danych.

Większość obserwowanych przeze mnie w ciągu ostatnich dziewięciu lat inicjatyw związanych ze sztuczną inteligencją w przedsiębiorstwach odnosiła sukces lub kończyła się niepowodzeniem nie tyle ze względu na wybrany model, ile na to, czy organizacja dysponowała niezawodną, zarządzaną podstawą działającą w czasie rzeczywistym, która mogła zasilać ten model aktualnymi, dokładnymi i wiarygodnymi danymi.

Dobrze dostrojony model otrzymujący nieaktualne lub niespójne dane będzie generować niewiarygodne wyniki. Agentowy system AI bez warstwy procesowej definiującej, co może robić, w końcu podejmie działanie, którego nikt nie będzie potrafił wyjaśnić ani cofnąć. To nie są problemy modelu. To problemy infrastruktury i architektury. I można je w pełni przewidzieć jeszcze przed napisaniem choćby jednej linii kodu AI.

Praktyczny wniosek jest taki, że gotowość na AI oznacza gotowość danych. Przed wyborem modelu, przed wyborem dostawcy AI i przed uruchomieniem pilotażu dyrektor ds. technologii powinien być w stanie szczerze odpowiedzieć na trzy pytania.

1. Czy organizacja ma niezawodny dostęp do danych w czasie rzeczywistym z systemów operacyjnych?
2. Czy istnieją zarządzane procesy definiujące, co system AI może, a czego nie może robić autonomicznie?
3. Czy na poziomie architektury, a nie tylko wewnątrz modelu, istnieją ramy zaufania zdolne egzekwować te granice w środowisku produkcyjnym?

Jeśli odpowiedź na którekolwiek z tych trzech pytań brzmi „nie”, od tego powinien rozpocząć się proces wdrażania AI, a nie od modelu.

Dlaczego AI musi zostać osadzone w istniejących procesach biznesowych

Najważniejszą zmianą, którą przeprowadziłem, było odejście od budowania AI jako odrębnej inicjatywy na rzecz osadzania go w istniejących procesach biznesowych. To obszar, w który inwestuje się zdecydowanie za mało, mimo jego ogromnego znaczenia. W rzeczywistości powiedziałbym, że większość dyrektorów ds. technologii powinna przejść od projektowania nowych systemów AI do projektowania sposobu, w jaki AI uczestniczy w istniejących przepływach pracy, jakie granice egzekwuje warstwa procesowa oraz jak wbudowywane są zarządzanie i możliwość przeprowadzania audytów — jeszcze przed wdrożeniem choćby jednego modelu.

Zanim dokonałem tej zmiany, schemat był niemal zawsze taki sam. Projekt AI rozpoczynał się w oderwaniu od systemów operacyjnych. Model działał dobrze w laboratorium. W środowisku produkcyjnym brakowało mu niezawodnego dostępu do aktualnych danych, jasno określonych granic podejmowanych działań oraz integracji z przepływami zatwierdzania, od których zależała firma. Imponująca demonstracja. Nieudane wdrożenie.

Zmiana, do której obecnie konsekwentnie dążę, ma dwa aspekty.

• Po pierwsze, istniejącą architekturę sterowaną zdarzeniami należy traktować jako fundament wdrażania AI, a nie jako cel do zastąpienia. Systemy pozostają. Procesy biznesowe pozostają. AI uczestniczy w już działających przepływach pracy, wykorzystuje zdarzenia w czasie rzeczywistym i działa w granicach definiowanych przez warstwę procesową.
• Po drugie, zabezpieczenia AI należy przenieść z modelu do warstwy orkiestracji procesów. Dobrze dostrojony model to za mało. Godne zaufania AI w środowisku produkcyjnym oznacza, że warstwa przepływu pracy egzekwuje bramki zatwierdzania, ścieżki eskalacji i ślady audytowe dla każdego autonomicznego działania podejmowanego przez agenta.

Alpian, pierwszy w pełni licencjonowany szwajcarski cyfrowy bank prywatny, jest dobrym przykładem właściwego podejścia od samego początku. Alpian zbudował całą swoją platformę w oparciu o architekturę sterowaną zdarzeniami, z Apache Kafka jako centralnym układem nerwowym łączącym mikrousługi, domenowe produkty danych i agentów AI. Gdy firma wprowadziła agentowe AI i RAG do przepływów pracy związanych z interakcjami z klientami, architektura była już gotowa. Zdarzenia Kafka zapewniły agentom kontekst w czasie rzeczywistym. Warstwa procesowa egzekwowała mechanizmy zgodności. Od początku zastosowano szyfrowanie na poziomie pól i zarządzanie schematami.

Rezultatem była regulowana instytucja finansowa uruchamiająca autonomicznych agentów AI w ramach zarządzanych przepływów pracy, z możliwością przeprowadzania audytów — dokładnie według tego schematu tradycyjne przedsiębiorstwa próbują obecnie modernizować swoje rozwiązania.

Organizacje, które robią to właściwie, traktują wdrażanie AI jako dyscyplinę architektoniczną, a nie sprint projektowy.

Dlaczego gotowość danych decyduje o powodzeniu wdrożenia AI

Po dziewięciu latach pracy w Confluent i doświadczeniach zdobytych w setkach środowisk korporacyjnych widziałem bardzo nierówne rezultaty AI. Różnica między dobrymi a złymi wynikami niemal zawsze wynika z jednej kwestii: tego, czy infrastruktura danych była gotowa przed wprowadzeniem AI.

Z pozytywnej strony dane liczbowe z dobrze zaprojektowanych wdrożeń są przekonujące. Firma BMW zapobiega ponad 500 minutom nieplanowanych przestojów produkcji rocznie w jednym zakładzie. Alpian prowadzi w pełni regulowany bank cyfrowy z osadzoną agentową AI w zarządzanych i podlegających audytowi procesach obsługi klienta. Wzorzec jakościowy w udanych wdrożeniach jest spójny: szybsze wprowadzanie produktów na rynek, niższe koszty operacyjne w wielkoskalowych, powtarzalnych procesach oraz znacząco lepsza obsługa klienta, gdy AI korzysta z kontekstu w czasie rzeczywistym, a nie z nieaktualnych danych przetwarzanych wsadowo.

Z negatywnej strony schemat niepowodzeń jest równie spójny. Projekty AI pozbawione zarządzanego fundamentu danych niemal zawsze przynoszą ten sam rezultat: imponujące demonstracje i nieudane wdrożenia produkcyjne. Model działa w laboratorium. W środowisku produkcyjnym otrzymuje nieaktualne lub niespójne dane, halucynuje w przypadkach brzegowych, podejmuje działania bez ścieżki audytowej i zamiast budować zaufanie biznesu do AI, podważa je. Badania MIT wskazują, że około 95% pilotażowych projektów AI w przedsiębiorstwach nie przekłada się na mierzalny wpływ biznesowy. Liczba ta odpowiada moim obserwacjom z praktyki.

Najnowszym schematem niepowodzeń, który obserwuję, jest zbyt późne dodawanie mechanizmów zarządzania. Organizacje wdrażają agentową AI, a następnie odkrywają — zwykle dopiero po incydencie — że żadna warstwa procesowa nie określiła, co agent może robić, nie zdefiniowano ścieżki eskalacji dla niepewnych wyników modelu ani ścieżki audytowej umożliwiającej odtworzenie zdarzeń. To nie jest problem AI. To problem architektury. I można mu całkowicie zapobiec.

Dlaczego AI dostarcza informacji do podejmowania decyzji, ale ludzie zapewniają odpowiedzialność

Nieustannie obserwuję pewien schemat: AI dostarcza informacji i przyspiesza działania. Podejmuje autonomiczne decyzje w określonych granicach. Jednak ludzie ponoszą odpowiedzialność za decyzje, które mają największe znaczenie.

Po stronie decyzji opartych na informacjach dostarczanych przez AI wyraźną wartość zapewniają synteza wyników badań, tworzenie treści, generowanie kodu dla dobrze zdefiniowanych problemów, automatyczne testowanie i skanowanie bezpieczeństwa. W mojej pracy narzędzia AI skracają wielodniową syntezę informacji z raportów analityków, rozmów z klientami i dokumentacji technicznej. Wynik nadal wymaga weryfikacji przez eksperta, ale punkt wyjścia jest znacznie bardziej zaawansowany.

Po stronie autonomicznego podejmowania decyzji agenci AI powinni decydować niezależnie, gdy ryzyko jest ograniczone, a proces podlega odpowiedniemu zarządzaniu. Najbardziej oczywistym przykładem jest wykrywanie oszustw w usługach finansowych. Poniżej określonego progu ryzyka agent AI automatycznie blokuje transakcję bez udziału człowieka. Wraz ze wzrostem wartości transakcji i ryzyka regulacyjnego warstwa orkiestracji procesu kieruje sprawę do analityka, zanim zostanie podjęte jakiekolwiek działanie. Granica nie jest stała. Określa ją firma, koduje ją przepływ pracy, a egzekwuje ją warstwa procesowa — nie sam model.

Po stronie decyzji wyraźnie pozostawionych ludziom stawiam granicę przy decyzjach o poważnych konsekwencjach architektonicznych, strategicznym ryzyku biznesowym lub istotnej odpowiedzialności regulacyjnej. Wybór podstawowego wzorca architektury, wybór strategicznego dostawcy technologii, zaprojektowanie modelu zarządzania systemem agentowej AI — to nadal decyzje podejmowane przez ludzi. Szybsze działanie nie niweluje konsekwencji błędnych decyzji.

Dlaczego AI nie spełnia oczekiwań w trzech głównych obszarach

AI nie przyniosła oczekiwanego przez klientów wpływu technicznego ani inżynieryjnego w trzech obszarach.

Pierwszym z nich jest integracja danych przedsiębiorstwa. AI miała znacznie uprościć łączenie heterogenicznych systemów: mapowanie schematów, egzekwowanie jakości danych, logikę transformacji i zarządzanie w złożonych środowiskach hybrydowych. W praktyce AI pomaga w tych zadaniach, ale ich nie rozwiązuje. Model nie jest w stanie rozumowaniem przezwyciężyć istniejącego długu architektonicznego, systemów starszego typu z nieudokumentowanymi modelami danych, niespójnej semantyki w poszczególnych jednostkach biznesowych, brakujących metadanych i rozproszonej odpowiedzialności. Inżynierowie nadal muszą wykonać trudną pracę.

Drugim obszarem jest agentowa AI w złożonych, wieloetapowych procesach przedsiębiorstwa. Demonstracje są przekonujące. W środowisku produkcyjnym agenci zawodzą w nieprzewidywalny sposób, gdy napotykają przypadki brzegowe, których nie obejmowały dane treningowe, gdy okno kontekstowe nie zawiera wystarczającej ilości aktualnego stanu lub gdy warstwa procesowa nie przechwytuje i nie obsługuje prawidłowo błędów agentów. Różnica między tym, co agent potrafi zrobić w kontrolowanym środowisku, a tym, co możemy mu zaufać i powierzyć autonomicznie w regulowanym procesie produkcyjnym, nadal jest znacząca.

Trzecim obszarem jest podejmowanie decyzji architektonicznych. Narzędzia AI znacząco przyspieszyły rutynowe kodowanie, pisanie testów i tworzenie dokumentacji. Nie poprawiają jednak niezawodnie decyzji dotyczących podstawowej architektury. Modele odzwierciedlają wcześniejsze wzorce. Architektura przedsiębiorstwa wymaga oceny przyszłych ograniczeń, kierunków zmian regulacyjnych i strategicznych zakładów technologicznych, których modele nie potrafią dobrze określić. Zespoły nadmiernie polegające na AI przy podejmowaniu decyzji architektonicznych mają tendencję do tworzenia systemów lokalnie spójnych, ale globalnie podatnych na awarie.

Wspólny mianownik wszystkich trzech obszarów jest następujący: AI przynosi rezultaty, gdy problem ma jasno określony zakres, dane są czyste i aktualne, a w proces zaangażowany jest człowiek dysponujący wiedzą dziedzinową. AI nie spełnia oczekiwań wszędzie tam, gdzie problem wymaga oceny kontekstowej, zmiany organizacyjnej lub myślenia architektonicznego wykraczającego poza dopasowywanie wzorców na podstawie danych historycznych.

Jak AI zmaga się z bezpieczeństwem i skalowalnością kodu

Najbardziej konsekwentne wyzwanie, jakie obserwuję, pojawia się na styku kodu generowanego przez AI i inżynierskiej oceny wymaganej w środowisku produkcyjnym.

Narzędzia do generowania kodu przez AI są naprawdę przydatne w przypadku dobrze zdefiniowanych, powtarzalnych zadań: kodu szablonowego, przypadków testowych, dokumentacji i prostych transformacji. Problemy pojawiają się wtedy, gdy zespoły przenoszą to zaufanie na decyzje architektoniczne, kod wrażliwy pod względem bezpieczeństwa lub komponenty krytyczne dla skalowalności, bez rygorystycznego przeglądu dokonywanego przez człowieka.

Po stronie bezpieczeństwa kod generowany przez AI często wprowadza subtelne podatności, które przechodzą automatyczne skanowanie, ale ujawniają się w warunkach ataku. Wstrzykiwanie promptów jest obecnie najbardziej wyraźnym przykładem w agentowych systemach AI. Agent, który generuje lub wykonuje kod na podstawie danych wejściowych użytkownika bez odpowiedniej walidacji danych wejściowych i izolowanego środowiska, tworzy wektory ataku, które łatwo przeoczyć i trudno wykryć po fakcie. Widziałem ten schemat we wczesnych wdrożeniach agentowych systemów AI, w których zespoły koncentrowały się na możliwościach i szybkości, a przegląd bezpieczeństwa traktowały jako późniejszy etap.

Po stronie skalowalności narzędzia AI mają tendencję do generowania rozwiązań, które działają poprawnie na małą skalę, ale opierają się na ukrytych założeniach dotyczących ilości danych, współbieżności lub opóźnień, ujawniających się dopiero pod obciążeniem produkcyjnym. Wygenerowany konsument Kafka, który działa bez problemów podczas testów, może nieprzewidywalnie zawieść przy dziesięciu tysiącach zdarzeń na sekundę, jeśli wygenerowany kod nie uwzględnia ponownego równoważenia partycji, zarządzania przesunięciami ani obsługi przeciążenia. Model nie zna Twojego środowiska produkcyjnego. Zna wzorce z danych treningowych.

Praktyczną reakcją nie jest zaprzestanie korzystania z AI do generowania kodu. Należy traktować kod wygenerowany przez AI tak samo, jak kod pochodzący od zdolnego, ale początkującego inżyniera, który nigdy nie widział Twojego systemu produkcyjnego. Przeglądaj go. Testuj go w realistycznych warunkach. I nigdy nie dopuszczaj go do ścieżek krytycznych dla bezpieczeństwa lub skalowalności, chyba że zatwierdzi go starszy rangą inżynier.

Co liderzy technologii muszą zrobić dalej

Przemyślenia Kaia

Zainwestuj w podstawy danych, zanim rozwiniesz ambicje związane z AI…traktuj zarządzanie AI jako problem architektoniczny, a nie problem dotyczący polityki…myśl jednocześnie w obu kierunkach.

Oto trzy rady, uporządkowane według ich znaczenia:

Po pierwsze, zainwestuj w podstawy danych, zanim rozwiniesz ambicje związane z AI. Organizacje osiągające mierzalne rezultaty dzięki AI to nie te, które najszybciej przeszły na nowy model. Miały uporządkowane, aktualizowane w czasie rzeczywistym i zarządzane dane przepływające przez ich systemy, zanim rozpoczęła się rozmowa o AI. Jeśli Twoje dane są rozproszone w silosach, nieaktualne lub nieobjęte zarządzaniem, najpierw napraw ten problem. Żaden model nie zrekompensuje złych danych na dużą skalę.

Po drugie, traktuj zarządzanie AI jako problem architektoniczny, a nie problem dotyczący polityki. Tworzenie wytycznych dotyczących odpowiedzialnego korzystania z AI jest konieczne, ale niewystarczające. To warstwa procesowa faktycznie zarządza zachowaniem agentów w środowisku produkcyjnym: punkty kontrolne przepływu pracy, progi zatwierdzania, ścieżki eskalacji i ślady audytowe, które egzekwują granice niezależnie od tego, co rekomenduje model. Wbuduj je w architekturę od samego początku. Dodawanie mechanizmów zarządzania po wdrożeniu jest kosztowne, zawodne i zwykle następuje dopiero wtedy, gdy coś pójdzie nie tak.

Po trzecie, myśl jednocześnie w obu kierunkach. Oddolna presja, by szybko wdrażać przypadki użycia AI, jest realna i uzasadniona. Uzasadniona jest również odgórna potrzeba strategicznej architektury, która pozwoli uniknąć tworzenia rozproszonych rozwiązań punktowych, których porządkowanie zajmie lata. CTO, których obserwuję i którzy dobrze radzą sobie z tym wyzwaniem, potrafią utrzymać oba podejścia jednocześnie: szybko działać w odniesieniu do konkretnych przypadków użycia, zachowując przy tym jasny architektoniczny kierunek, dzięki któremu te przypadki użycia pozostają kompozycyjne i możliwe do objęcia zarządzaniem w dłuższej perspektywie.

Organizacje, które będą wspominać ten okres jako przewagę konkurencyjną, to nie te, które najwcześniej wdrożyły AI. Zbudowały infrastrukturę, dzięki której AI stało się godne zaufania, a następnie szybko działały na tym fundamencie.

Śledź dalsze informacje

Możesz śledzić pracę Kaia Waehnera na jego stronie internetowej, blogu i LinkedInie.

Na The CTO Club już wkrótce kolejne wywiady z ekspertami!