AWS: Sztuczna inteligencja w obecnej formie nie byłaby możliwa bez chmury obliczeniowej

Ze Slavikiem Dimitrovichem, dyrektorem ds. technologii w firmie Amazon Web Services rozmawiam o dobrych praktykach wykorzystania sztucznej inteligencji, przyczynach niepowodzeń projektów związanych z AI, wyzwaniach technologicznych towarzyszących takim projektom, a także o wymaganiach technicznych i operacyjnych sztucznej inteligencji, praktycznym wykorzystaniu agentów AI i wyzwaniach cyfrowej suwerenności.

Jakie są dziś najbardziej przystępne, realne scenariusze wykorzystania AI w działalności operacyjnej?

Większość procesów biznesowych nie jest gotowa na AI, stąd wysoki odsetek porażek. Wiele projektów, mimo wdrożenia, jest wycofywanych w ciągu roku z powodu złego doboru scenariuszy. AI rzadko działa bez głębokiej przebudowy procesów. Wyjątkiem jest tworzenie oprogramowania. Dzięki 20 latom standaryzacji, powtarzalności i mechanizmom kontroli, integracja AI w IT jest najprostsza. Ewentualne błędy kodu są natychmiast wykrywane. Dla firm z działem IT automatyzacja programowania to dziś priorytet i najwyższy zwrot z inwestycji.

Czy wobec tego firmy będą częściej polegać na własnych zasobach deweloperskich?

Zdecydowanie tak. Dzięki narzędziom AI do generowania kodu, własny zespół programistyczny jest dziś w zasięgu firm, które dotąd zlecały te prace na zewnątrz. Nie namawiam do natychmiastowego przenoszenia całego IT do wewnątrz firmy. Kluczem jest selektywny insourcing – stworzenie zespołów dedykowanych tylko tym obszarom, które są najbardziej perspektywiczne.

Co z innymi scenariuszami użycia AI?

Sukces AI wymaga dojrzałych procesów z wbudowanymi mechanizmami kontroli i wycofywania błędów. Bez tego sztuczna inteligencja tylko pogłębi chaos, a brak transparentności zablokuje projekt. Klucz do wdrożenia leży w organizacji pracy, a nie w technologii. Przestańmy też wymagać od AI absolutnej perfekcji – obecne, ludzkie procesy również nie są idealne.

Jakie wyzwania techniczne najczęściej towarzyszą projektom związanym z wykorzystaniem AI?

Wśród kluczowych wyzwań technologicznych wskazałbym trzy kwestie. Po pierwsze, należy rozróżnić charakterystykę projektów pilotażowych i wdrożeń produkcyjnych. Celem pilotażu jest bowiem zdobycie wiedzy i weryfikacja założeń projektowych tak szybko, jak jest to możliwe. Specyfika pilotażowych wdrożeń AI w naturalny sposób zakłada więc pewne uproszczenia i skróty. Jest to całkowicie uzasadnione.

Problem pojawia się, gdy udany pilotaż rodzi presję na natychmiastowe wdrożenie produkcyjne. Kadra zarządzająca, nieświadoma, że to jedynie prototyp, nalega na szybkie efekty. Zespoły techniczne często ulegają tej presji, przenosząc testowe rozwiązanie w niezmienionej formie do głównego systemu. W efekcie projekt kończy się porażką, bo kod okazuje się nieskalowalny, zbyt drogi w utrzymaniu lub mało wydajny.

Kolejnym problemem często jest jakość danych. Na potrzeby eksperymentów organizacje chętnie sięgają po najlepsze dane, jakimi dysponują. Po części to właśnie dobór wykorzystanych na etapie pilotażu danych decyduje o powodzeniu takich projektów. Podczas wdrożenia produkcyjnego często okazuje się jednak, że całościowy zbiór danych, na których ma pracować rozwiązanie docelowe, nie jest jednolity i uwzględnia także dane gorszej jakości. Wykorzystanie takich danych może mieć bezpośredni wpływ na efekty działania rozwiązania produkcyjnego.

Oczywiście, chęć wdrożenia rozwiązań AI nie oznacza konieczności przebudowy wszystkich zbiorów danych. Należy jednak pamiętać o tym, że dane, którymi ma być zasilana sztuczna inteligencja powinny być odpowiednio uporządkowane i ustrukturyzowane, a także gotowe do wykorzystania w sposób zautomatyzowany.

Trzecia kwestia dotyczy postępującej ewolucji narzędzi do obsługi systemów AI. Są to często rozwiązania relatywnie młode, stale rozwijane, ale niekoniecznie odpowiadające na potrzeby związane ze wszystkimi scenariuszami wykorzystania sztucznej inteligencji. W efekcie, organizacje, które dysponują zasobami deweloperskimi i mają możliwość uzupełnienia standardowych narzędzi, zyskują. Alternatywnie, firmy, które polegają wyłącznie na gotowych produktach często dochodzą do wniosku, że nie są one jeszcze wystarczająco dojrzałe do wykorzystania na szeroką skalę.

Czy istnieją tu zatem wyzwania typowo biznesowe?

O tak! Głównym wyzwaniem jest umiejętność wskazania realnej wartości z wykorzystania AI. Nie jest to wyłącznie problem związany z technologią, ale wykorzystanie AI bardzo tą kwestię uwidacznia. Do niedawna decyzje o zastosowaniu sztucznej inteligencji były często podejmowane w oderwaniu od racjonalnych argumentów. Projekty były realizowane, co naturalnie generowało niemałe koszty zakupu tokenów czy innych zasobów niezbędnych do działania AI. Dopiero na koniec pojawiały się pytania o zwrot z takiej inwestycji.

Warto wówczas na chwilę zapomnieć o sztucznej inteligencji i zadać sobie pytanie: czy, gdybyśmy mogli wykonać ten proces szybciej, lepiej lub w większej skali, bylibyśmy zmierzyć wartość biznesową wynikającą z takiej zmiany? Jeśli nie, to nie warto sięgać po AI, bo wówczas problem braku określenia mierzalnych czynników sukcesu stanie się bardziej palący.

Druga kwestia dotyczy samych procesów biznesowych. Większość firm próbuje wpasować możliwości AI w ramy istniejących procesów. Tymczasem, są to procesy zaprojektowane w oparciu o historyczne ograniczenia organizacji i technologii, jaką dysponowała. Zastosowanie AI do procesów zamodelowanych lata czy nawet dekady temu nie przyniesie radykalnych usprawnień. Zdecydowanie większe sukcesy w wykorzystywaniu potencjału AI osiągają te organizacje, które cofają się o krok i przebudowują swoje procesy znając możliwości sztucznej inteligencji.

Wobec tego operacyjne wykorzystania AI powinno wiązać się z przemodelowaniem funkcjonowania organizacji…

Zdecydowanie tak. Historia zna zresztą analogie. Przed upowszechnieniem elektryczności w fabrykach istniały najczęściej pojedyncze silniki parowe i złożone systemy przekładni pasowych rozprowadzające energię mechaniczną do poszczególnych maszyn. Kiedy pojawiła się elektryczność, początkowo silnik parowy po prostu zastąpiono silnikiem elektrycznym zachowując złożony system przekładni.

Dopiero później ktoś wpadł na pomysł, że dzięki elektryczności każdą maszynę produkcyjną można wyposażyć we własny, odpowiednio dopasowany silnik elektryczny, eliminując złożony i awaryjny system pasów i kół pasowych. Dziś wiele firm stosuje sztuczną inteligencję w podobny sposób – zaprzęgają AI do działań wykonywanych wcześniej w sposób manualny zachowując ogólny projekt procesu biznesowego.

Jakie znaczenie dla powodzenia projektów AI ma zatem model chmury obliczeniowej?

Chmura ma fundamentalne znaczenie dla AI – bez niej sztuczna inteligencja w obecnej formie by nie powstała. Początkowo umożliwiła stworzenie modeli GenAI, pozwalając na tani wynajem ogromnej mocy obliczeniowej bez ryzykownej budowy własnych serwerowni. Dziś chmura jest niezbędna do operacjonalizacji AI. Ukrywa ona wielowarstwową złożoność technologiczną systemów. Dzięki tej warstwie abstrakcji programiści i użytkownicy mogą swobodnie korzystać z możliwości sztucznej inteligencji, nie musząc znać mechanizmów ukrytych pod maską.

Jakimi cechami powinien charakteryzować się stos technologii obsługujący systemy czy też środowiska AI?

System AI to w gruncie rzeczy kolejny system IT. Choć ma swoją specyfikę, to przede wszystkim musi być niezawodny. Kryteria wyboru dostawcy chmurowego są tu dokładnie takie same, jak przy każdym innym projekcie o krytycznym znaczeniu dla biznesu. Około 80% wymagań stawianych architekturze AI pokrywa się z wymaganiami klasycznych systemów – mowa tu o wysokiej dostępności (high availability) i odporności na awarie. W AWS byliśmy pionierami podejścia opartego na architekturze typu Well-Architected, a wszystkie te zasady idealnie sprawdzają się dziś w projektach AI.

Oczywiście pojawia się też około 20% nowych wyzwań. Należą do nich: precyzyjne zarządzanie potokami danych (data pipelines) oraz optymalizacja kosztów, bezpieczeństwa i stabilności samego procesu wnioskowania (inference). Kluczowe staje się też zrozumienie modelu współdzielonej odpowiedzialności za stabilność operacyjną oraz parametry techniczne, takie jak opóźnienia (latency) czy przepustowość. Wszystkie te czynniki decydują o wyborze partnera technologicznego. Na rynku jest wielu dostawców AI, ale niewielu potrafi utrzymać tak rygorystyczną dyscyplinę operacyjną jak AWS.

Jakie znaczenie na etapie wyboru dostawcy usług chmurowych ma dostępność modeli AI?

To ważna, ale często niedoceniana kwestia. Większość firm wciąż znajduje się we wczesnej fazie rozwoju w obszarze AI, a więc są bardziej skłonne do wykorzystania modelu ogólnego zastosowania. Z racji na niewielką skalę użycia niej restrykcyjnie podchodzą też do kwestii opóźnień czy kosztów. Wybierając dostawcę usług chmurowych, z którym wiążą się najczęściej na dłuższy czas. Nie analizują też kwestii wprost związanych z dostępnością konkretnych modeli AI.

Jednocześnie, organizacje bardziej dojrzałe w podejściu do sztucznej inteligencji zauważają, że duże modele, zwłaszcza te najnowocześniejsze, w obliczu dużej skali wykorzystania lub konkretnych scenariuszy użycia mogą okazać się zbyt kosztowne lub niewystarczająco wydajne. Często lepsze okazują się mniejsze lub starsze modele. Tu zaś zaczynają być widoczne różnice pomiędzy poszczególnymi dostawcami. Nie każdy dostawca usług chmurowych utrzymuje wystarczająco szeroki katalog modeli AI. W grę wchodzą też inne kwestie: podejście do bezpieczeństwa, odporność infrastruktury i usług, czy globalna skala działania. Takie właśnie kwestie są dziś wyróżnikiem dostawców, takich jak AWS – szczególnie na tle operatorów, którzy mają mniejszy zasięg geograficzny, mniejszą skalę infrastruktury lub mniejsze doświadczenie operacyjne.

Jak rosnąca rola agentów AI przekłada się na charakter pracy typowego użytkownika biznesowego?

Odpowiem na swoim przykładzie. Załóżmy więc, że jestem typowym użytkownikiem biznesowym, choć moja rola łączy obowiązki techniczne i biznesowe. Na swoim laptopie mam zainstalowanych kilka narzędzi wykorzystujących sztuczną inteligencję, ale korzystam przede wszystkim z dwóch agentów AI. Jednym z nich jest Kiro, którego używam głównie do pracy ze środowiskami AWS. Świetnie się tu sprawdza, bo doskonale rozumie stos technologiczny naszej platformy. Z Kiro korzystam również do tworzenia działających w tle agentów, których zadaniem jest obsługa mojego konta w środowisku AWS.

Drugim ze wspomnianych narzędzi jest Amazon Quick – rozwiązanie, które za sprawą AI pomaga mi wykonywać wszystkie zadania związane z zarządzaniem i obsługą klientów. Każdego dnia rano zwykle uruchamiam pogłębione analizy, które pomagają mi rozeznać się w informacjach, wydarzeniach i trendach związanych, przykładowo, z technologią, gospodarką czy przepisami. Następnie program sprawdza wszystkie moje spotkania z klientami. Tworzę również repozytoria dla wszystkich klientów, z którymi mam kontakt. System informuje mnie, że konkretna nowa informacja może być istotna dla konkretnego klienta i sugeruje dalsze działania.

Amazon Quick Desktop pomaga mi też w przygotowaniu do rozmów z klientami. Z wyprzedzeniem skanuje mój kalendarz i informuje mnie o zaplanowanych spotkaniach. Następnie zbiera publicznie dostępne informacje o kliencie, jego bieżących projektach związanych ze sztuczną inteligencją, strategii i działalności, a następnie łączy te dane z historią relacji z klientem oraz z informacjami z zespołu obsługi klienta AWS. Na tej podstawie proponuje kluczowe kwestie, które powinienem poruszyć podczas rozmowy.

W jaki sposób AWS reaguje na rosnące potrzeby europejskich klientów w kontekście cyfrowej suwerenności?

Wychodząc naprzeciw oczekiwaniom klientów w Brandenburgii uruchomiliśmy niedawno pierwszy region europejskiej chmury suwerennej AWS. Jest on odłączony od innych regionów dostępnych w ramach ogólnych usług AWS, ale zapewnia te same usługi, te same interfejsy API i tę samą logikę działania, oczywiście z pewnymi ograniczeniami dotyczącymi dostępności usług na starcie. Nasza strategia rozwoju infrastruktury zakłada systematyczny rozwój oferty usług świadczonych w poszczególnych regionach. Nie inaczej jest w przypadku oferty AWS European Sovereign Cloud. Na koniec dnia chodzi o zapewnienie klientom możliwości wyboru. Taki wybór staramy się zaoferować.

Co ważne, klienci powinni naprawdę rozumieć z jakich powodów podejmują określone decyzje i jakie ograniczenia mogą wiązać się z poszczególnymi decyzjami. Lokalny, suwerenny region usług chmurowych w naturalny sposób ma inną skalę i możliwości niż zasoby globalne. Niewątpliwie w pewnych okolicznościach jest to rozwiązanie właściwe, ale nie należy go wybierać tylko dlatego, że po prostu jest taka opcja., np. z powodu mody, strachu lub automatyzmu, zamiast z realnej, biznesowej potrzeby. Taki lokalny region ma znacznie mniej funkcji, gorszą wydajność, mniejszą skalowalność i jest droższy niż globalna chmura AWS. Krajowy, odizolowany region chmurowy nigdy nie dorówna skalą ani innowacyjnością zasobom globalnym. Bywa on niezbędny w regulowanych branżach, ale trzeba najpierw przeanalizować, co tracimy, rezygnując z globalnej chmury.

Warto pamiętać, że nie ma nic za darmo, a każda decyzja wymaga kompromisów. Przykładowo, jeśli zależy nam na ograniczeniu procesów przetwarzania danych tylko do określonej, wąskiej lokalizacji, to jednocześnie ograniczamy sobie możliwość wykorzystania zasobów technologicznych dostępnych szerzej w danym regionie. Dlatego tak ważne jest świadome i precyzyjne określenie wymaganego stopnia suwerenności danych oraz związanych z tym ograniczeń związanych z lokalizacją i dostępnością usług. W praktyce pełną prywatność danych można też osiągnąć tylko poprzez odpowiednie podejście do szyfrowania danych. Aby zagwarantować bezpieczeństwo danych nie trzeba koniecznie godzić się na ograniczenia lokalnych, w pełni suwerennych środowisk. Można nadal korzystać z rozwiązań, takich jak AWS, ale odpowiednio zaszyfrować dane i chronić klucze bezpieczeństwa.

Inną kwestią jest to, że klienci czasami przeceniają znaczenie amerykańskiej ustawy Cloud Act. Nie oznacza ona, że rząd USA może w każdej chwili uzyskać dostęp do konta dowolnej osoby lub organizacji, pobrać wszystkie zgromadzone tam dane i w dowolny sposób je wykorzystać. Cloud Act zakłada m.in. skomplikowany proces i szereg procedur zabezpieczających dane przez nieuprawnionym użyciem.

W tym kontekście warto też zauważyć, że chmurę obliczeniową AWS zbudowaliśmy w taki sposób, że nawet gdybyśmy chcieli, to jako operator nie możemy uzyskać dostępu do danych klientów. AWS Nitro gwarantuje separację danych na poziomie sprzętowym. Dopóki klienci korzystają z dostępnych narzędzi do szyfrowania danych, nie mamy do nich żadnego dostępu.