Liderzy opinii

Zarządzanie AI nie jest problemem dla szczebla kierowniczego. To problem bazy danych.

mm
Dodaj Unite.AI do preferowanych źródeł w Google

Tempo eksperymentów z AI wewnątrz przedsiębiorstw nigdy nie było szybsze, a jednak droga do produkcji pozostaje uporczywie wolna. Zespoły uruchamiają pilotażowe wersje, testują modele i demonstrują obiecujące wyniki w ciągu tygodni, a nawet dni. Ale gdy przychodzi czas wdrożenia tych systemów na dużą skalę, postęp często zwalnia. Pojawiają się obawy dotyczące bezpieczeństwa, wymagania zgodności się zaostrzają, a pytania dotyczące zarządzania się mnożą.

Raport MIT The GenAI Divide: State of AI in Business 2025 ujawnił, że 95% pilotażowych projektów AI w przedsiębiorstwach nie przynosi mierzalnego wpływu biznesowego. Tylko 5% osiąga produkcję i generuje rzeczywiste finansowe zwroty. Badanie objęło ponad 300 wdrożeń AI i 150 wywiadów z executiveami, a jego wniosek brzmiał, że główną barierą nie jest zdolność modelu. To błędna integracja przedsiębiorstwa. Większość organizacji traktuje to jako problem polityczny do rozwiązania na poziomie kierowniczym. Uważam, że zarządzanie AI to wyzwanie systemowe, które zaczyna się na poziomie danych.

Dlaczego projekty AI zatrzymują się na etapie pilotażu

Wiele inicjatyw AI nie powodzi się, ponieważ środowiska wykorzystywane do ich prototypowania są fundamentalnie niezgodne z rzeczywistością wdrożenia przedsiębiorstwa. Deweloperzy są zachęcani do pracy szybko, wykorzystując elastyczne narzędzia, luźno zarządzane zestawy danych i infrastrukturę samousługową, aby jak najszybciej udowodnić wartość. To idealne dla eksperymentów — ale nie przekłada się na środowiska produkcyjne, które wymagają audytowalności, surowych kontroli dostępu, zgodności z przepisami i odporności operacyjnej.

W rezultacie zarządzanie jest często wprowadzane dopiero po udanym prototypie. W tym momencie to, co powinno być warstwą umożliwiającą, staje się ograniczeniem — zmuszając zespoły do dostosowania modeli bezpieczeństwa, ponownego projektowania przepływów danych i ponownej oceny założeń zgodności, które powinny być podstawą od samego początku.

To tworzy coraz większą lukę między tym, co systemy AI mogą udowodnić w kontrolowanych środowiskach, a tym, co przedsiębiorstwa mogą bezpiecznie i niezawodnie wdrożyć w produkcji.

W tym samym czasie nowoczesny stos AI ewoluował, aby priorytetem było szybkość i dostępność, często kosztem kontroli. Platformy przyjazne dla deweloperów ułatwiają pilotaż, ale mogą ukryć, gdzie dane mieszczą się, jak są wykorzystywane i kto ma do nich dostęp.

To wprowadza prawdziwe operacyjne i regulacyjne ryzyka, w tym niezamierzoną ekspozycję danych, niejasne granice danych między środowiskami i niewystarczającą audytowalność zachowania systemu. Te problemy pojawiają się bezpośrednio w przeglądach gotowości produkcyjnej i ocenach zgodności. Ankiety przedsiębiorstw stale pokazują, że kwestie jakości danych i zarządzania są wśród głównych przyczyn nieudanych projektów AI, wymienianych w 60-70% przypadków. Ten problem jest pogarszany przez rosnącą zależność od infrastruktury i usług zarządzanych przez strony trzecie, co może dalej fragmentować własność danych i skomplikować zgodność z przepisami. W wielu przypadkach organizacje zakładają, że zarządzanie jest niejawnie obsługiwane przez platformy, kiedy w rzeczywistości odpowiedzialność jest rozproszona na wiele warstw stosu.

Rezultatem jest paradoks. Narzędzia, które przyspieszają eksperymenty AI, są często tymi samymi, które wprowadzają tarcie w punkcie produkcji.

Baza danych jako prawdziwa warstwa zarządzania

Aby rozwiązać ten problem, konieczne jest przemyślenie, gdzie tak naprawdę dochodzi do zarządzania.

Zarządzanie jest często pozycjonowane jako funkcja polityczna, zdefiniowana przez zespoły prawne, zgodności lub kierownicze i egzekwowana przez procesy dokumentacji i przeglądu. Chociaż są one niezbędne, te mechanizmy same w sobie są niewystarczające. Zarządzanie staje się istotne tylko wtedy, gdy jest egzekwowane na poziomie systemowym.

W praktyce to egzekwowanie następuje tam, gdzie dane są przechowywane, dostępne i przekształcane. To sprawia, że baza danych i otaczająca infrastruktura danych stają się najważniejszą warstwą zarządzania w stosie AI.

Nowoczesne bazy danych nie są biernymi repozytoriami. Definiują one uprawnienia dostępu, egzekwują wymagania dotyczące rezydencji danych, zarządzają szyfrowaniem i kontrolami kluczy oraz generują dzienniki audytowe wymagane do zgodności i nadzoru bezpieczeństwa. Coraz częściej służą również jako punkt kontrolny, przez który systemy AI współdziałają z danymi przedsiębiorstwa.

To ma znaczenie, ponieważ systemy AI dziedziczą postawę zarządzania poziomu danych, na którym się opierają. Jeśli podstawowa warstwa bazy danych brakuje struktury, kontroli lub widoczności, te słabości przenoszą się bezpośrednio do systemów AI zbudowanych na ich podstawie. Żadna reguła na poziomie aplikacji nie może w pełni skompensować niewłaściwie zarządzanego fundamentu danych.

To prowadzi do szerszej zmiany architektonicznej: zarządzanie musi być wbudowane w infrastrukturę od samego początku, a nie warstwą nakładaną po wdrożeniu. Infrastrukturalne podejście do AI oznacza projektowanie systemów, w których zarządzanie jest wbudowaną właściwością, a nie zewnętrznym ograniczeniem. Dostęp do danych jest pośredniczony przez kontrolowane interfejsy. Zapytania i interakcje systemowe są rejestrowane domyślnie. Reguły zgodności, takie jak ograniczenia dostępu, zasady przechowywania i wymagania dotyczące rezydencji, są egzekwowane na poziomie systemowym, a nie przez ręczny nadzór lub walidację post factum.

To wymaga wzorców architektonicznych, takich jak bezpieczne warstwy pośredniczące zapytań, sterowane polityką kontrolami dostępu oraz scentralizowana obserwowalność w rozproszonych środowiskach danych. Te mechanizmy zapewniają, że zarządzanie jest stale egzekwowane, a nie okresowo sprawdzane.

Różnica między proaktywnym a reaktywnym zarządzaniem jest fundamentalna. Podejścia reaktywne próbują poprawić problemy po tym, jak systemy są zbudowane i wdrożone. Podejścia proaktywne zapobiegają tym problemom, wbudowując kontrolę bezpośrednio w architekturę systemu.

W środowiskach AI ta różnica decyduje o tym, czy systemy mogą rosnąć czy zatrzymać się.

Gdy agenci wkraczają do obrazu

Autonomiczne agenci zmieniają równanie zarządzania w sposób, na który większość organizacji nie jest przygotowana. Agent nie tylko czyta dane. Zapisuje je, wyzwala akcje w systemach i robi to wszystko bez udziału człowieka.

To zmienia tryb awaryjny całkowicie. Źle zarządzane zapytanie zwraca błędną odpowiedź. Źle zarządzany agent działa na tej błędnej odpowiedzi, aktualizuje rekordy, wyzwala przepływy pracy w dół, propaguje decyzje w systemach, zanim ktokolwiek zorientuje się, że coś poszło nie tak.

Dlatego barierki nie mogą istnieć na poziomie aplikacji. Agent działający w wielu systemach zawsze znajdzie najkrótszą drogę. Kontrolę trzeba egzekwować na poziomie danych, gdzie każde odczyt i zapis są pośredniczone i rejestrowane, niezależnie od tego, co je spowodowało.

Gartner przewiduje, że ponad 40% projektów AI z agentami zostanie opóźnionych lub anulowanych z powodu problemów z zarządzaniem i niezawodnością. Ta liczba wydaje się niska, ponieważ zakłada, że organizacje prawidłowo identyfikują zarządzanie jako przyczynę, a nie przypisują niepowodzeń do modelu lub narzędzi. Przyczyna pierwotna jest zwykle niewidoczna, aż staje się droga.

Od eksperymentów do gotowych do produkcji systemów AI

Organizacje, które z powodzeniem przenoszą AI z eksperymentów do produkcji, mają wspólną cechę — wczesne wyrównanie środowisk rozwojowych i produkcyjnych.

Zamiast pozwolić, aby systemy eksperymentalne odeszły od ograniczeń produkcyjnych, projektują one oba środowiska zgodnie z zasadami zarządzania, bezpieczeństwa i dostępu do danych. To redukuje tarcie później w cyklu życia, gdy modele przechodzą z prototypów do obciążeń produkcyjnych.

To wyrównanie jest coraz bardziej istotne, ponieważ większość przedsiębiorstw nadal nie posiada dojrzałej, gotowej do produkcji infrastruktury AI. Trwałe luki pozostają w bezpiecznym dostępie do danych, monitorowaniu, obserwowalności i egzekwowaniu zgodności. Te luki nie są izolowane — są to wyzwania strukturalne, które pojawiają się, gdy AI jest skalowana poza środowiska pilotażowe do krytycznych dla misji przepływów pracy.

Inna duża rozbieżność między prototypowaniem a produkcją występuje, gdy aplikacje produkcyjne i bazy danych muszą być hostowane lokalnie lub na ściśle zarządzanych kontach w chmurze, podczas gdy prototypy zostały opracowane na platformach baz danych w chmurze.

W dojrzałych organizacjach obciążenia AI są traktowane z taką samą surowością, jak inne regulowane systemy. To oznacza spójne logowanie, surowe kontrolowanie dostępu, ciągłe monitorowanie i wyraźnie zdefiniowane struktury odpowiedzialności w zespołach. Wymaga to również bliższego wyrównania między inżynierią danych, inżynierią platformy, bezpieczeństwem i funkcjami zgodności od samego początku, a nie jako późniejszy dodatek.

Korzyści z tego podejścia sięgają poza redukcję ryzyka. Organizacje doświadczają również szybszych cykli wdrożeniowych, mniej awarii produkcyjnych i większej wewnętrznej pewności co do systemów AI. W tym kontekście skalowanie AI jest mniej związane z innowacjami modelu, a bardziej z dojrzałością infrastruktury.

Zarządzanie jest imperatywem architektonicznym

Ostatecznie rozmowa o zarządzaniu AI musi się przenieść poza politykę i do architektury.

Zarządzanie jest często traktowane jako funkcja nadzoru, ale w praktyce jest egzekwowane przez systemy, które definiują, jak dane są dostępne i wykorzystywane. Baza danych nie jest po prostu warstwą przechowywania, jest punktem kontrolnym dla bezpieczeństwa, zgodności i integralności operacyjnej w całym stosie AI.

Gdy AI staje się coraz głębiej osadzone w przepływach pracy przedsiębiorstwa, znaczenie tego punktu kontrolnego znacznie wzrasta. Każda interakcja między modelem a danymi przedsiębiorstwa staje się zarządzanym zdarzeniem, niezależnie od tego, czy organizacje jawnie je projektują.

Poprzez priorytetowe traktowanie infrastrukturalnego zarządzania, rozpoczynającego się od warstwy bazy danych, przedsiębiorstwa mogą zamknąć lukę między pilotażem a produkcją. W ten sposób przenoszą AI z izolowanych eksperymentów w trwałą, skalowalną zdolność wbudowaną w całą organizację.

Phillip Merrick jest współzałożycielem i CPO w pgEdge. Przedsiębiorca, technolog i doświadczony menedżer z głębokimi korzeniami w infrastrukturze danych i platformach chmurowych napędzających dzisiejsze systemy AI. Współzałożyciel i/lub CEO webMethods, EDB, SparkPost, Fugue i pgEdge; prowadził firmy od startupu przez IPO i trzy wyjścia w zakresie 9-10 cyfr.