Globalny dyrektor ds. architektury rozwiązań w AWS przedstawia swój model modernizacji opartej na sztucznej inteligencji

Saurabh Shrivastava jest globalnym dyrektorem ds. architektury rozwiązań i inżynierii wdrażanej bezpośrednio w Amazon Web Services, gdzie koncentruje się na agentowej sztucznej inteligencji i modernizacji przedsiębiorstw.

Spotkaliśmy się z Saurabhem, aby dowiedzieć się więcej o nowych modelach inżynieryjnych, które wykorzystuje w swojej pracy w AWS. Oto, czym się z nami podzielił.

Odpowiedzialne uprzemysławianie sztucznej inteligencji

Jestem liderem transformacji technologicznej i transformacji opartej na sztucznej inteligencji, z ponad 20-letnim doświadczeniem w pomaganiu przedsiębiorstwom w przekształcaniu złożonych zmian technologicznych w skalowalne rezultaty biznesowe. Moja droga zawodowa obejmowała inżynierię, architekturę korporacyjną, inżynierię terenową ukierunkowaną na produkty, transformację chmurową, a obecnie także agentową sztuczną inteligencję i modele fabryk oprogramowania w AWS.

Na wcześniejszych etapach kariery tworzyłem i prowadziłem wielkoskalowe platformy korporacyjne w środowiskach telekomunikacyjnych, handlu detalicznego, łańcucha dostaw, technologii finansowych oraz badań i rozwoju. Dało mi to głębokie zrozumienie myślenia systemowego, niezawodności, złożoności integracji oraz realiów eksploatacji technologii w skali przedsiębiorstwa.

W AWS moja rola rozszerzyła się z pomagania klientom w modernizacji infrastruktury i aplikacji do kierowania globalną architekturą rozwiązań oraz inicjatywami inżynierii wdrażanej bezpośrednio ukierunkowanymi na sztuczną inteligencję, modernizację i platformy agentowe. Współpracowałem z liderami przedsiębiorstw, partnerami, zespołami produktowymi i zespołami inżynieryjnymi, aby przejść od strategii i eksperymentów do zarządzanych, gotowych do użycia produkcyjnego platform.

Sztuczna inteligencja nie jest już tylko kolejną falą technologiczną. Zmienia sposób tworzenia oprogramowania przez organizacje, sposób pracy pracowników, sposób angażowania klientów oraz sposób funkcjonowania organizacji technologicznych. Prawdziwe wyzwanie przywódcze nie polega wyłącznie na wyborze modeli czy narzędzi. Chodzi o stworzenie modelu operacyjnego, architektury, zasad zarządzania, kompetencji i dyscypliny produktowej, które umożliwią odpowiedzialne uprzemysłowienie sztucznej inteligencji.

Kierowanie architekturą rozwiązań AWS

Jako globalny dyrektor ds. architektury rozwiązań i FDE kieruję globalną organizacją AWS odpowiedzialną za architekturę rozwiązań oraz inżynierię wdrażaną bezpośrednio, koncentrującą się na platformach agentowej sztucznej inteligencji, modernizacji przedsiębiorstw i transformacji chmurowej na skalę produkcyjną.

Organizacja działa w skali przedsiębiorstwa, współpracując z dużymi globalnymi klientami, strategicznymi partnerami, zespołami produktowymi, wyspecjalizowanymi zespołami inżynieryjnymi oraz regionalnymi organizacjami terenowymi. Zakres architektury jest szeroki: platformy AI/ML, przepływy pracy agentowej, podstawy danych i analityki, modernizacja aplikacji, infrastruktura natywna dla chmury, bezpieczeństwo, zarządzanie oraz rozwiązania zintegrowane z partnerami.

Globalnie kieruję, wspieram i wywieram wpływ na ponad 200 specjalistów, inżynierów partnerskich i liderów technologii terenowych. Praca jest niezwykle złożona, ponieważ nie tworzymy odizolowanych demonstracji. Pomagamy przedsiębiorstwom przechodzić od wczesnych pomysłów związanych ze sztuczną inteligencją i uzasadnień biznesowych modernizacji do powtarzalnych, bezpiecznych i gotowych do użycia produkcyjnego platform, które można skalować w różnych jednostkach biznesowych, na różnych rynkach i w różnych środowiskach klientów.

Nasz model wdrażania łączy inżynierię wdrażaną bezpośrednio, globalne mechanizmy platformowe, dostarczanie prowadzone przez partnerów oraz pętle informacji zwrotnych między produktem a zespołami terenowymi. Mój zespół tworzy wielokrotnego użytku wzorce wdrożeniowe, architektury referencyjne, demonstracje dla kadry kierowniczej, podręczniki techniczne, wzorce zarządzania oraz komponowalne modele rozwiązań, które przyspieszają wdrażanie, jednocześnie zachowując jakość, bezpieczeństwo i dyscyplinę operacyjną.

Dlaczego model inżynierii wdrażanej bezpośrednio jest niezbędny w pracy ze sztuczną inteligencją

W ubiegłym roku wprowadziłem model inżynierii wdrażanej bezpośrednio na potrzeby modernizacji prowadzonej z wykorzystaniem sztucznej inteligencji.

W erze chmury mieliśmy wielokrotnego użytku architektury referencyjne, wzorce rozwiązań, schematy wdrażania i punkty kontrolne zarządzania. Były one niezbędne, ale niewystarczające w przypadku sztucznej inteligencji. Klienci nadal mieli trudności z przejściem od POC do produkcji, ponieważ najtrudniejsza praca odbywała się w ich rzeczywistym środowisku: w danych, zasobie aplikacji, złożoności kodu, ograniczeniach bezpieczeństwa i modelu operacyjnym.

Dlatego wprowadziłem mechanizm FDE, który umieszcza inżynierów znacznie bliżej rzeczywistych obciążeń klientów. Zamiast doradzać z zewnątrz, zespół FDE pracuje z danymi, kodem, architekturą i zespołami realizacyjnymi klienta, aby identyfikować kandydatów do modernizacji, tworzyć użyteczne zasoby i przenosić pierwsze obciążenie do środowiska produkcyjnego.

Wprowadziłem również prosty model 3-3-3: 3 dni na odkrywanie, 3 tygodnie na ocenę i 3 miesiące na przeniesienie pierwszego obciążenia do środowiska produkcyjnego. Dało to kadrze kierowniczej jasną ścieżkę od ambicji związanych ze sztuczną inteligencją do wymiernej wartości.

Wpływ był znaczący. Klienci mogli przyspieszyć swoją drogę modernizacji od 2x do 4x, zmniejszyć koszty nawet o połowę i wyjść poza demonstracje, osiągając rzeczywisty zwrot z inwestycji. Co ważniejsze, zmieniło to rozmowę na szczeblu kierowniczym. Sztuczna inteligencja nie była już pobocznym eksperymentem; stała się praktycznym mechanizmem modernizacji rzeczywistych obciążeń, zwiększania produktywności inżynierów i tworzenia wymiernej wartości biznesowej.

Jak modernizować szybciej bez utraty zaufania

Intensywnie korzystam z AI, aby przyspieszać rozumienie kwestii technicznych, rozpoznawanie wzorców i wydajność pracy zespołów inżynieryjnych, ale nie przekazuję AI odpowiedzialności.

W złożonych przedsiębiorstwach działalność często opiera się na kodzie rozwijanym przez dziesięciolecia, długu technicznym, nieudokumentowanych zależnościach i osadzonych regułach biznesowych. W takim środowisku potrzebujemy zarówno podejść deterministycznych, jak i probabilistycznych. Nie można polegać wyłącznie na probabilistycznym wykrywaniu za pomocą AI, próbując zrozumieć systemy o znaczeniu krytycznym dla misji.

W przypadku wykrywania kodu, wyodrębniania reguł biznesowych, analizy zależności, mapowania funkcji i oceny stanu obecnego preferuję bardziej deterministyczne podejście. Potrzebujemy identyfikowalności, powtarzalności, dowodów i pewności co do tego, jak działa system. AI może pomagać, podsumowując, grupując i przyspieszając analizę, ale fundamentem muszą być weryfikowalne fakty wynikające z kodu, dzienników, przepływów danych, zachowania w czasie działania oraz dowodów architektonicznych.

AI staje się coraz potężniejsza w pracy nad stanem docelowym: generuje opcje modernizacji, proponuje nowe architektury, definiuje granice usług, opracowuje wzorce migracji, pisze kod, generuje testy i przyspiesza wdrażanie. Ta część może mieć bardziej probabilistyczny charakter, ponieważ AI może analizować różne opcje i zwiększać tempo pracy zespołów inżynieryjnych.

Jednak nawet w tym przypadku ostateczna decyzja pozostaje w rękach człowieka. Inżynierowie i liderzy ponoszący odpowiedzialność muszą zweryfikować wybory architektoniczne, poziom bezpieczeństwa, gotowość produkcyjną, ryzyko związane ze zgodnością, wpływ na klientów oraz kompromisy inwestycyjne.

Mój model wygląda więc następująco: deterministyczne rozpoznanie, projektowanie i wdrażanie przyspieszane przez AI oraz walidacja nadzorowana przez człowieka. Takie połączenie pozwala nam szybciej modernizować systemy bez utraty zaufania, kontroli ani odpowiedzialności przedsiębiorstwa.

Wady AI w procesach pracy zespołów inżynieryjnych

Saurabh dzieli się spostrzeżeniami

Koszt nie jest jedyną wadą (AI). AI może również stwarzać fałszywe poczucie pewności, jeśli zespoły korzystają z niej bez nadzoru.

Największym pozytywnym rezultatem było znaczne skrócenie przez AI drogi od rozpoznania do produkcji, gdy została osadzona w zdyscyplinowanym procesie pracy zespołu inżynieryjnego.

AI przyspieszyła również rozumienie kodu, wyodrębnianie reguł biznesowych, analizę zależności, generowanie testów, tworzenie dokumentacji i planowanie modernizacji. Ograniczyła czas ręcznej analizy, pomagając zespołom inżynieryjnym w większym stopniu koncentrować się na decyzjach architektonicznych, walidacji i gotowości produkcyjnej.

AI może jednak bardzo szybko stać się niezwykle kosztowna, jeśli zespoły nie zaprojektują systemu z uwzględnieniem ekonomiki wnioskowania. W dużych przedsiębiorstwach, mających miliony użytkowników, koszty tokenów modeli czołowej generacji mogą sięgać milionów dolarów, jeśli każda interakcja zależy od zewnętrznych modeli bazowych dostarczanych przez podmioty trzecie, bez optymalizacji.

Jedna z lekcji jest taka, że architektura AI musi obejmować również architekturę kosztów. W przypadku niektórych obciążeń przedsiębiorstwa powinny rozważyć wnioskowanie hostowane samodzielnie lub w chmurze, z wykorzystaniem procesorów GPU albo akceleratorów, w tym rozwiązań takich jak vLLM w infrastrukturze chmurowej. Zapewnia to większą kontrolę nad kosztami, opóźnieniami, granicami danych i strategią udostępniania modeli. Techniki takie jak buforowanie KV, ciągłe przetwarzanie wsadowe, kwantyzacja i optymalizacja jąder obliczeniowych mogą znacząco poprawić wykorzystanie GPU i obniżyć koszt wnioskowania.

Koszt nie jest jedyną wadą. AI może również stwarzać fałszywe poczucie pewności, jeśli zespoły korzystają z niej bez nadzoru. Ryzyko obejmuje niepełne rozumienie kodu, halucynowane zależności, niewystarczające pokrycie testami, luki w zabezpieczeniach oraz zbyt szybkie przechodzenie zespołów od prototypu do produkcji.

Dlaczego AI ma trudności z kompleksową modernizacją systemów starszego typu

AI ma największe trudności wtedy, gdy zespoły proszą ją o podejmowanie decyzji technicznych bez zapewnienia wystarczającego kontekstu systemu.

Typowym przykładem jest modernizacja starszych systemów. AI może podsumowywać kod, generować pomysły na migrację, a nawet szybko tworzyć nowy kod. Jednak w dużych przedsiębiorstwach rzeczywista złożoność wykracza poza sam kod. Obejmuje dekady reguł biznesowych, nieudokumentowane integracje, zadania wsadowe, zależności danych, wyjątki operacyjne, ograniczenia bezpieczeństwa oraz odpowiedzialność poszczególnych jednostek organizacyjnych. Jeśli poprosisz AI o modernizację takiego środowiska, dysponując jedynie częściowym obrazem, może ono generować odpowiedzi brzmiące przekonująco, ale niepełne.

Gotowość do wdrożenia produkcyjnego to kolejny obszar, w którym AI ma trudności. AI może bardzo szybko tworzyć prototypy, ale wiele prototypów nie staje się automatycznie bezpiecznymi, obserwowalnymi, odpornymi i efektywnymi kosztowo systemami produkcyjnymi. Zespoły czasami nie doceniają nakładu pracy wymaganego na testowanie, zarządzanie, reagowanie na incydenty, monitorowanie, ocenę modeli, jakość danych i zarządzanie cyklem życia.

Jak inżynierowie mogą ulepszać produkty, kontrolując koszty wnioskowania i niezawodność

Oto przykład dużej platformy do tworzenia treści medialnych i marketingowych, w której AI pomaga użytkownikom przejść od zamiaru do gotowych zasobów cyfrowych na skalę przedsiębiorstwa.

Przepływ pracy rozpoczyna się, gdy użytkownik opisuje, co chce stworzyć: kampanię wprowadzającą produkt na rynek, kreację do mediów społecznościowych, prezentację sprzedażową, fragment wideo lub zlokalizowany materiał marketingowy. AI interpretuje zamiar użytkownika, uwzględniając odbiorców, format, ton, wytyczne marki, wymagane zasoby, ograniczenia kanału i wymagania dotyczące zgodności.

Następnie platforma wykorzystuje agentowy przepływ pracy. Jeden agent pobiera zatwierdzone przez markę szablony, logotypy, czcionki, kolory i zasoby kampanii. Inny generuje teksty i warianty kreacji. Kolejny proponuje układy. Następny sprawdza zgodność z marką, dostępność, zasady i bezpieczeństwo treści. Końcowa warstwa orkiestracji składa wynik w edytowalne zasoby i kieruje go do procesów zatwierdzania lub publikacji.

Przy tej skali inżynierowie mierzyli się z wyzwaniami dotyczącymi nie tylko jakości modeli, lecz także ekonomiki wnioskowania, opóźnień, niezawodności i zarządzania. Zespół zoptymalizował środowisko wnioskowania na bardzo dużą skalę, obsługujące około 10 000 węzłów obliczeniowych i około 80 000 procesorów GPU. Architektura łączyła zasoby GPU wielu dostawców chmurowych i zatwierdzonych podmiotów zewnętrznych, integrując te środowiska za pośrednictwem hybrydowej warstwy sieciowej. Dzięki temu platforma mogła elastycznie rozmieszczać obciążenia w zależności od kosztu, opóźnień, dostępności i lokalizacji danych.

Zespół wdrożył również bardziej zdyscyplinowaną strategię obsługi modeli. Zamiast kierować każde żądanie do najdroższego zaawansowanego modelu, platforma rozdzielała żądania między modele dopasowane do konkretnych zastosowań, w tym modele otwarte, takie jak Kimi i Qwen, obsługiwane za pośrednictwem zoptymalizowanych środowisk wykonawczych, takich jak vLLM, oraz wzorców w stylu Ollama. Zespół stosował również techniki optymalizacji wnioskowania, w tym buforowanie KV, ciągłe przetwarzanie wsadowe, kwantyzację, optymalizację pamięci i dostrajanie na poziomie jąder, aby poprawić wykorzystanie GPU i obniżyć koszty.

Ludzie zachowali kontrolę w kluczowych punktach podejmowania decyzji. AI generowało opcje, rekomendowało układy, pisało teksty i przyspieszało produkcję, ale użytkownik lub właściciel marki zatwierdzał ostateczny zasób. Zespoły inżynierskie odpowiadały za mechanizmy ochronne: bezpieczeństwo, dostęp do danych, wybór modelu, obserwowalność, opóźnienia, kontrolę kosztów, kontrole bezpieczeństwa i pętle informacji zwrotnej.

Rezultatem był przepływ pracy oparty na AI, który stał się częścią doświadczenia produktowego, a nie tylko wewnętrznym narzędziem zwiększającym produktywność. Skrócił czas od pomysłu do gotowego zasobu, poprawił personalizację, zwiększył ponowne wykorzystanie zatwierdzonych elementów marki i stworzył pętlę informacji zwrotnej, w której zmiany użytkowników oraz dane o zaangażowaniu ulepszały przyszłe rekomendacje. Jednocześnie architektura zapewniła firmie znacznie większą kontrolę nad kosztami wnioskowania, niezawodnością i zarządzaniem.

Dlaczego wdrażanie AI wymaga myślenia produktowego

Wdrażanie narzędzi AI to w mniejszym stopniu kwestia przyjęcia narzędzia, a w większym — zmiana operacyjnego modelu pracy inżynierskiej.

Początkowo wiele organizacji uważa, że wyzwaniem jest zapewnienie inżynierom dostępu do asystentów programowania, narzędzi wspomagających kodowanie, interfejsów API modeli lub wewnętrznych platform AI. To pomaga, ale nie wystarcza. Bez jasnych wzorców zespoły korzystają z AI w niespójny sposób. Niektóre używają go wyłącznie do generowania kodu. Inne wykorzystują je do tworzenia dokumentacji. Część nadmiernie mu ufa. Jeszcze inne go unikają, ponieważ nie mają pewności co do zagrożeń związanych z bezpieczeństwem, własnością intelektualną lub jakością.

Gdybym miał zacząć od nowa, zdefiniowałbym przepływ pracy inżynierów z AI jeszcze wcześniej: gdzie AI powinno i nie powinno być używane, jakie dowody są wymagane, co ludzie muszą sprawdzać oraz jak wyniki są testowane, zabezpieczane i wdrażane na produkcję.

Pozwoliłoby to uniknąć kilku problemów. Po pierwsze, moglibyśmy ograniczyć niespójne wykorzystanie AI w poszczególnych zespołach. Po drugie, moglibyśmy uniknąć fałszywego poczucia pewności co do kodu lub analiz wygenerowanych przez AI, które wyglądały poprawnie, ale nie uwzględniały wystarczającego kontekstu. Po trzecie, moglibyśmy wcześniej kontrolować koszty, wdrażając od początku routing modeli, budżetowanie tokenów, buforowanie i zarządzanie procesem wnioskowania. Po czwarte, moglibyśmy tworzyć lepsze wzorce wielokrotnego użytku, zamiast pozwalać każdemu zespołowi opracowywać własne podejście.

Najważniejsza lekcja jest taka, że wdrażanie AI wymaga myślenia produktowego i platformowego. Potrzebne są działania umożliwiające skuteczne wykorzystanie AI, mechanizmy ochronne, obserwowalność, kontrola kosztów, przegląd bezpieczeństwa, wielokrotnego użytku prompty i agenci, wzorce ewaluacji oraz jasno określona odpowiedzialność człowieka. W przeciwnym razie AI zwiększa aktywność, ale nie zawsze podnosi jakość inżynierii ani wartość biznesową.

Dlaczego SDLC musi stać się AI-DLC

Saurabh dzieli się

CTO powinni aktywnie przeprojektowywać sam cykl dostarczania oprogramowania.

CTO powinni aktywnie przeprojektowywać sam cykl dostarczania oprogramowania. Postrzegam to jako przejście od tradycyjnego SDLC do AI-DLC — cyklu dostarczania rozszerzonego przez AI na potrzeby ery agentowej AI.

W tradycyjnym SDLC często stosujemy liniowe fazy: wymagania, projektowanie, programowanie, wdrażanie i wsparcie. Sprawdzało się to całkiem dobrze, gdy głównym celem było tworzenie deterministycznego oprogramowania za pomocą uporządkowanych przekazań między zespołami. Jednak w przypadku AI, a zwłaszcza agentowej AI, cykl staje się bardziej iteracyjny i skompresowany.

Upraszczam AI-DLC do trzech głównych faz: rozpoczęcia, budowy i działania.

• W fazie rozpoczęcia AI pomaga w rozpoznaniu, zrozumieniu kodu, wyodrębnianiu reguł biznesowych, analizie zależności, doprecyzowaniu wymagań, identyfikacji ryzyka i planowaniu stanu docelowego.
• W fazie budowy AI wspiera wybór wariantów architektury, dekompozycję usług, generowanie kodu i testów, dokumentację, przeglądy bezpieczeństwa, wzorce infrastruktury oraz realizację modernizacji.
• W fazie działania AI wspiera obserwowalność, wstępną analizę incydentów, pętle informacji zwrotnej, ewaluację modeli, optymalizację kosztów, zarządzanie i ciągłe doskonalenie.

Ważne jest to, że AI-DLC nie jest po prostu SDLC z dodanym asystentem programowania. To przeprojektowany model operacyjny inżynierii. Łączy agentów AI, deterministyczne rozpoznanie, walidację przez człowieka, bramki bezpieczeństwa, gotowość produkcyjną i zarządzanie kosztami w jeden przepływ pracy.

Jak zespoły inżynieryjne zmieniają się pod wpływem AI

AI przesunęła zespoły inżynieryjne od sekwencyjnej realizacji opartej na rolach w stronę bardziej zintegrowanych zespołów skoncentrowanych na rezultatach.

W przeszłości organizowaliśmy pracę wokół odrębnych ról: architektów, inżynierów aplikacji, inżynierów danych, zespołów DevOps, bezpieczeństwa, kontroli jakości i operacji. Te role nadal mają znaczenie, ale AI skraca cykl i zmniejsza wartość długich przekazań między zespołami. Najlepiej działające zespoły są bardziej interdyscyplinarne i bliższe problemowi biznesowemu.

W przypadku modernizacji prowadzonej przez AI i inżynierii produktów szukam obecnie zespołów łączących kilka kompetencji: solidne podstawy inżynierii oprogramowania, inżynierię chmurową i platformową, biegłość w zakresie danych i AI, świadomość bezpieczeństwa, myślenie produktowe oraz trafną ocenę sytuacji operacyjnej. Cenię również inżynierów, którzy potrafią pracować w niejednoznacznych środowiskach, rozumują od podstaw i weryfikują wyniki AI, zamiast bezkrytycznie je akceptować.

Dobrym przykładem jest model inżynierii wdrażanej bezpośrednio w środowisku klienta. Zamiast utrzymywać architekturę, inżynierię AI, DevOps i bezpieczeństwo w oddzielnych, następujących po sobie ścieżkach, przybliżamy te kompetencje do środowiska klienta lub biznesu. Zespół pracuje z rzeczywistym kodem, danymi, ograniczeniami i miernikami sukcesu.

Zmieniło się również zatrudnianie. Nadal bardzo cenię głęboką wiedzę techniczną, ale szukam także osób myślących systemowo: ludzi, którzy rozumieją architekturę, odpowiedzialnie korzystają z AI, komunikują się z interesariuszami biznesowymi i biorą odpowiedzialność za rezultaty produkcyjne. W erze AI najlepsi inżynierowie nie są tylko twórcami kodu. Potrafią definiować problemy, weryfikować rozwiązania i budować powtarzalne systemy.

Jak mierzyć skuteczność AI

Jedno z pytań, które chciałbym, aby zadawało więcej osób, brzmi: Jak CTO powinni mierzyć, czy AI tworzy trwałą wartość dla przedsiębiorstwa?

CTO nie powinni mierzyć AI wyłącznie liczbą wdrożonych projektów pilotażowych lub copilotów ani samą dokładnością modelu. Są to przydatne sygnały, ale nie potwierdzają transformacji.

CTO powinni mierzyć AI w czterech wymiarach:

1. Produktywność inżynieryjna: Czy AI skraca czas realizacji, poprawia jakość kodu, zwiększa pokrycie testami, przyspiesza modernizację i ogranicza dług techniczny?
2. Wpływ na biznes: Czy AI poprawia doświadczenia klientów, produktywność pracowników, konwersję sprzedaży, efektywność kosztową lub szybkość wprowadzania produktów na rynek?
3. Dojrzałość produkcyjna: Czy systemy AI są bezpieczne, obserwowalne, niezawodne, zarządzane i objęte kontrolą kosztów? Czy mają jasno określoną odpowiedzialność człowieka oraz kryteria gotowości produkcyjnej?
4. Możliwość ponownego wykorzystania i skalowalność: Czy zespoły tworzą wielokrotnego użytku usługi AI, agentów, prompty, wzorce, produkty danych i możliwości platformowe, czy też tworzą odizolowane demonstracje?

Ma to znaczenie, ponieważ AI może generować dużą ilość widocznej aktywności bez tworzenia trwałej wartości. CTO muszą przekształcić aktywność związaną z AI w powtarzalne możliwości. Oznacza to połączenie strategii, architektury, modelu operacyjnego, zarządzania i ekonomiki.

Dlaczego CTO muszą oddzielić eksperymentowanie od uprzemysłowienia

Oto moja rada.

Po pierwsze, nie traktujcie AI jako pobocznego eksperymentu. Traktujcie je jako nową warstwę operacyjną firmy. AI wpłynie na sposób tworzenia oprogramowania, pracy pracowników, interakcji z klientami i podejmowania decyzji. Zadaniem CTO jest przeprowadzenie organizacji od rozproszonych projektów pilotażowych do zarządzanej, skalowalnej strategii platformy AI.

Po drugie, oddzielcie eksperymentowanie od uprzemysłowienia. Szybkie eksperymentowanie jest w porządku, ale produkcyjne AI wymaga architektury, bezpieczeństwa, zarządzania danymi, ewaluacji, obserwowalności, kontroli kosztów i jasno określonej odpowiedzialności człowieka. Wiele firm utknęło w miejscu, ponieważ ma wiele demonstracji, ale nie ma powtarzalnej ścieżki do produkcji. CTO muszą zbudować tę ścieżkę.

Po trzecie, skupcie się na wartości biznesowej, a nie na nowości modelu. Zwycięskimi organizacjami nie będą te, które po prostu korzystają z najnowszego modelu. Będą nimi te, które wbudują AI w rzeczywiste przepływy pracy, zmodernizują podstawy technologiczne, poprawią produktywność inżynieryjną i będą mierzyć wyniki, takie jak czas realizacji, efektywność kosztowa, doświadczenia klientów, wpływ na przychody i ograniczenie ryzyka.

I po czwarte, moja praktyczna rada brzmi: stwórzcie jednocześnie platformę AI i model inżynierii wdrażanej bezpośrednio. Platforma zapewnia możliwość ponownego wykorzystania, zarządzanie i skalę. Model FDE wprowadza AI do rzeczywistych obciążeń klientów i przedsiębiorstwa, wykorzystując rzeczywiste dane, rzeczywisty kod i rzeczywiste ograniczenia. W ten sposób CTO mogą przejść od ambicji związanych z AI do faktycznie zrealizowanego zwrotu z inwestycji.

Śledź dalsze informacje

Śledź pracę Saurabha Shrivastavy na LinkedIn oraz na jego stronie autora w serwisie Amazon.

Na łamach The CTO Club pojawi się więcej wywiadów z ekspertami!