Firmy wracają do architektury korporacyjnej, bo AI bez porządku się nie skaluje

Przedsiębiorstwa bez trudu wdrażają modele językowe, asystentów i agentów AI, jednak dużo trudniej idzie im przebudowa całej organizacji wokół tych narzędzi. Paradoksalnie, im szerzej próbują automatyzować procesy, tym mocniej widać, że problemem nie jest jakość samych algorytmów, ale bałagan w procesach, danych, systemach i podziale odpowiedzialności.

Z badania McKinsey wynika, że 88 proc. organizacji korzysta z AI w co najmniej jednym obszarze działalności, ale tylko około jedna trzecia z nich przeszła etap skalowania takich programów. Jedynie 39 proc. ankietowanych zauważa realny wpływ AI na wynik operacyjny całej firmy. Technologia jest więc powszechnie dostępna, ale wciąż rzadko przekłada się na ekonomię przedsiębiorstwa.

Ta rozbieżność między popularnością AI a jej rzeczywistym wpływem na biznes sprawia, że na znaczeniu ponownie zyskuje architektura korporacyjna. Nie mowa tu jednak o powrocie do rozbudowanych diagramów, wieloletnich planów i komitetów zatwierdzających każdą zmianę miesiącami. Organizacje potrzebują raczej aktualnego systemu decyzyjnego, który określa, gdzie AI może działać, z jakich danych korzystać, jakie systemy wywoływać i kto odpowiada za efekt.

Agent nie jest kolejną aplikacją

Klasyczna aplikacja działa w wyznaczonych ramach - ma określonych użytkowników, funkcje, dane wejściowe i reguły. Agent AI zachowuje się inaczej: sam wybiera narzędzia, łączy informacje z różnych źródeł, planuje następne kroki i inicjuje akcje w innych systemach.

Przykładowo agent obsługujący sprzedaż może równocześnie sięgać po dane z CRM, weryfikować dostępność produktów w systemie ERP, analizować maile, przygotowywać ofertę i wysyłać ją do klienta. Dla użytkownika wygląda to jak jedno narzędzie, ale w rzeczywistości spina kilka systemów, zestawów uprawnień, właścicieli danych i dostawców technologii.

Im więcej autonomii zyskuje AI, tym istotniejsze stają się granice, w jakich może działać. Nieaktualny rekord w CRM, źle przypisane uprawnienie czy wadliwa integracja nie są już problemem odizolowanego systemu - agent może przenieść błąd dalej w procesie i podjąć na jego podstawie realną decyzję biznesową.

To powód, dla którego firmy nie mogą skalować agentów bez wcześniejszego uporządkowania architektury danych i integracji. McKinsey podkreśla, że stabilne systemy agentowe wymagają danych dobrej jakości, jasno udokumentowanego ich pochodzenia, wspólnych reguł zarządzania oraz architektury zdolnej wspierać decyzje podejmowane w czasie rzeczywistym.

Wyzwaniem jest też sama infrastruktura. Według badania Google Cloud, obejmującego ponad 1400 liderów IT, 83 proc. z nich uważa, że ich organizacje muszą zmodernizować infrastrukturę, by móc uruchamiać autonomiczne systemy klasy produkcyjnej. Dotychczasowe środowiska nie były budowane pod oprogramowanie, które nie tylko odpowiada na zapytania, lecz samodzielnie przemieszcza się między systemami.

Dla firm oznacza to, że agentów AI nie da się prosto dołączyć do istniejącego środowiska. Bez wspólnych reguł dostępu, integracji, monitorowania i odpowiedzialności każdy nowy projekt dodaje kolejną warstwę długu technologicznego.

Architektura wraca, ale w nowej roli

Dawna architektura korporacyjna skupiała się głównie na aplikacjach, infrastrukturze i docelowym kształcie środowiska IT. W erze AI taki obraz przestaje wystarczać, bo nie ukazuje całej ścieżki - od danych aż do decyzji biznesowej.

Firma musi wiedzieć nie tylko, jakie systemy ma w portfolio, ale też jakie procesy te systemy wspierają, z jakich danych korzystają, jakie modele są w nich uruchomione i kto odpowiada za konsekwencje ich działania. Potrzebuje znać dostawców poszczególnych elementów, koszt realizacji procesu, poziom autonomii przyznanej AI oraz sposób zatrzymania systemu w razie usterki.

Jednostką projektowania nie jest już zatem pojedyncza aplikacja, a cały przepływ pracy.

To fundamentalna zmiana z perspektywy CIO. Wcześniej CRM, ERP, analitykę i narzędzia komunikacyjne można było rozwijać niezależnie od siebie. Agent działający na styku tych systemów wymusza spojrzenie na cały proces, bo skuteczność automatyzacji zależy od najsłabszego ogniwa w łańcuchu.

McKinsey wyróżnia dwie ścieżki zmian: stopniowe dołączanie agentów do już istniejącej architektury albo szerszą przebudowę środowiska wokół procesów obsługiwanych przez AI. W praktyce większość organizacji będzie musiała połączyć oba podejścia - nie mogą czekać na całkowitą modernizację systemów, ale też nie powinny podłączać kolejnych agentów do każdego narzędzia bez wspólnego planu.

Najrozsądniejszym rozwiązaniem wydaje się modernizacja prowadzona domenami. Firma wybiera procesy o największym znaczeniu dla wyniku finansowego, mapuje związane z nimi dane, aplikacje, integracje i zakresy odpowiedzialności, a następnie buduje dla nich architekturę umożliwiającą bezpieczne wdrożenie AI.

Takie podejście nie zmusza do wymiany wszystkich systemów legacy. ERP i CRM mogą wciąż dobrze realizować funkcje transakcyjne, muszą jednak udostępniać dane i operacje poprzez kontrolowane interfejsy, które precyzują, kto - człowiek, aplikacja czy agent - może wykonać daną czynność.

Firma potrzebuje wspólnej platformy, nie kolejnych pilotów

Pierwsze wdrożenia AI zwykle inicjowały poszczególne działy - marketing uruchamiał narzędzie do generowania treści, obsługa klienta testowała chatbota, a IT eksperymentowało z generowaniem kodu. Przy niewielkiej skali taki model pozwala szybko zweryfikować możliwości technologii.

Kłopot zaczyna się, gdy organizacja próbuje połączyć te rozproszone narzędzia z kluczowymi procesami. Każdy odrębny projekt tworzy własne integracje, system uprawnień, mechanizmy monitorowania i umowy z dostawcami. Firma wielokrotnie płaci za te same elementy, a wciąż nie ma nad nimi pełnej kontroli.

Przejście od eksperymentów do skali wymaga wspólnej warstwy technologicznej. Powinna ona dawać dostęp do zatwierdzonych modeli, zarządzać tożsamością agentów, kontrolować połączenia z systemami firmowymi, rejestrować podejmowane działania, oceniać jakość odpowiedzi i umożliwiać szybkie wyłączenie rozwiązania.

Niezbędny jest też jeden, spójny katalog zastosowań AI. Bez niego zarząd nie ma pojęcia, ile agentów działa w firmie, z jakich danych korzystają, kto jest ich właścicielem i jakie ryzyko generują. Sam rejestr niczego jednak nie zmieni, jeśli będzie tylko kolejnym arkuszem aktualizowanym raz na kwartał - musi być połączony z architekturą aplikacji, danymi, procesami i systemem zarządzania ryzykiem.

Wspólna platforma zwiększa koszt startu programu AI, ale zmniejsza koszt każdego kolejnego wdrożenia. Umożliwia ponowne wykorzystanie tych samych integracji, mechanizmów bezpieczeństwa i narzędzi monitorowania. Przewagę daje więc nie liczba rozpoczętych pilotów, a tempo, w jakim firma uruchamia nowe zastosowania na już istniejących fundamentach.

Decyzja architektoniczna staje się decyzją finansową

Koszt AI jest znacznie trudniejszy do oszacowania niż koszt tradycyjnej aplikacji. Obejmuje nie tylko licencję czy zużycie modelu, ale też chmurę, bazy danych, wyszukiwanie, integracje, monitoring, bezpieczeństwo, przechowywanie danych oraz pracę zespołów.

Raport FinOps Foundation podaje, że 98 proc. badanych organizacji zarządza już wydatkami na AI, w porównaniu do 31 proc. dwa lata wcześniej. Inwestycje nie dotyczą wyłącznie chmury publicznej, obejmują również SaaS, centra danych i środowiska prywatne.

Bez architektury łączącej zasoby techniczne z procesami biznesowymi firma nie jest w stanie określić, ile faktycznie kosztuje dane zastosowanie AI, ani czy jego wartość rośnie w tym samym tempie co zużycie infrastruktury. Nie wie też, które komponenty są współdzielone, a które finansuje wielokrotnie w różnych projektach.

Architektura korporacyjna, FinOps i zarządzanie portfelem inwestycji zaczynają więc funkcjonować jako jeden system. Wybór modelu, sposobu integracji czy miejsca przetwarzania danych nie jest już wyłącznie decyzją techniczną - wpływa na koszt jednostkowy procesu, marżę, bezpieczeństwo i możliwość zmiany dostawcy.

Governance powinno przyspieszać, nie blokować

Rosnące wymogi regulacyjne dodatkowo wzmacniają potrzebę aktualnego obrazu środowiska AI. AI Act, NIST AI Risk Management Framework oraz ISO/IEC 42001 opierają zarządzanie ryzykiem na stałym identyfikowaniu systemów, ich zastosowań, odpowiedzialności i skutków działania. NIST porządkuje ten proces wokół czterech funkcji: zarządzania, mapowania, mierzenia i reagowania na ryzyko, a ISO/IEC 42001 wymaga wdrożenia i nieustannego doskonalenia systemu zarządzania AI.

To nie oznacza jednak, że każdy projekt musi przechodzić przez długi proces ręcznych akceptacji - taki model szybko staje się wąskim gardłem. Z badania SAP LeanIX wynika, że decyzje architektoniczne trwały miesiąc lub dłużej w 51 proc. organizacji.

Skuteczna architektura nie powinna mnożyć komitetów, a tworzyć zatwierdzone wzorce, komponenty i automatycznie wymuszane zasady. Zespół może działać szybko, jeśli korzysta z dopuszczonego modelu, właściwego źródła danych, standardowej integracji i wymaganego mechanizmu monitorowania.

Governance wbudowane w architekturę przyspiesza wdrożenia, bo większość decyzji zostaje podjęta z wyprzedzeniem. Kontrola pojawiająca się tuż przed uruchomieniem produkcyjnym prowadzi natomiast do opóźnień, kosztownych poprawek i konfliktów między biznesem, IT, bezpieczeństwem i prawnikami.

CIO staje się projektantem sposobu działania firmy

AI sprawia, że decyzji technologicznych nie da się już oddzielić od decyzji organizacyjnych. Określenie, do jakich systemów agent ma dostęp, jest jednocześnie decyzją o podziale obowiązków. Ustalenie poziomu nadzoru człowieka zmienia sam przebieg procesu. Wybór danych wpływa na jakość podejmowanej decyzji i na odpowiedzialność za jej skutki.

CIO nie powinien więc zaczynać od budowy architektury dla całego przedsiębiorstwa. Lepiej wybrać kilka procesów o największym znaczeniu dla przychodów, kosztów lub ryzyka i zmapować dla nich cały łańcuch działania: dane, aplikacje, modele, dostawców, integracje, uprawnienia, koszty i właścicieli.

Zarząd z kolei nie musi dopytywać, który model ma najwięcej parametrów. Powinien natomiast wiedzieć, w jakich procesach AI jedynie doradza, a w jakich samodzielnie wykonuje działania, kto odpowiada za rezultat, ile kosztuje cały proces i czy dostawcę można wymienić bez przebudowy środowiska.

Najważniejszym miernikiem dojrzałości nie jest liczba wdrożonych narzędzi, a zdolność do szybkiego uruchamiania kolejnych zastosowań bez proporcjonalnego wzrostu kosztów, ryzyka i złożoności.

Architektura korporacyjna wraca więc do łask, ale nie jako techniczna dokumentacja - staje się systemem łączącym strategię, procesy, dane, technologię, finanse i odpowiedzialność. Bez niej firmy będą miały coraz więcej agentów AI i coraz mniej kontroli nad tym, jak naprawdę funkcjonuje ich przedsiębiorstwo.

AI nie skaluje się dzięki kolejnym pilotom, lecz dzięki architekturze, która pozwala bezpiecznie i ekonomicznie powielać ich rezultaty w całej organizacji.