Dane w silosach — pierwszy realny bloker wdrożeń AI
Opublikowano 25 lip 2026 · 10 min czytania
Wiele firm rozpoczyna wdrożenie AI od wyboru modelu, platformy albo dostawcy technologii. Pojawiają się prezentacje, testy i efektowne demo. Agent odpowiada na pytania, analizuje dokumenty i w kilka sekund wykonuje zadanie, które wcześniej zajmowało pracownikowi godzinę.
Potem przychodzi moment podłączenia rozwiązania do prawdziwej organizacji.
Okazuje się, że dane klienta znajdują się w CRM, historia zamówień w ERP, warunki handlowe w plikach PDF, reklamacje w skrzynkach e-mail, a aktualne ustalenia w wiadomościach i notatkach pracowników. Te same pojęcia mają różne nazwy, rekordy nie mają wspólnego identyfikatora, a nikt nie jest pewien, które źródło jest aktualne.
I właśnie tutaj kończy się demo, a zaczyna prawdziwe wdrożenie AI.
Pierwszym realnym blokerem zazwyczaj nie jest model. Są nim dane zamknięte w silosach — rozproszone pomiędzy systemami, działami i właścicielami, bez wspólnego kontekstu potrzebnego do podjęcia decyzji.
AI nie potrzebuje wszystkich danych. Potrzebuje pełnego kontekstu
Model językowy potrafi dobrze analizować informacje, które otrzyma. Nie potrafi jednak samodzielnie odtworzyć faktów, do których nie ma dostępu. Jeżeli agent widzi tylko fragment procesu, jego odpowiedź może być logiczna i jednocześnie biznesowo błędna.
Wyobraźmy sobie agenta przygotowującego odpowiedź na reklamację klienta. W systemie obsługi zgłoszeń widzi opis problemu i korespondencję. Nie widzi jednak, że:
- klient posiada indywidualne warunki w umowie zapisanej w innym repozytorium,
- ostatnia faktura została już skorygowana w ERP,
- opiekun handlowy uzgodnił rekompensatę w wiadomości e-mail,
- zamówienie dotyczyło produktu z innej partii niż wskazana w zgłoszeniu.
Agent może przygotować bardzo przekonującą odpowiedź — tyle że na podstawie niepełnego obrazu sytuacji. W przypadku AI jest to szczególnie niebezpieczne, ponieważ dobra forma wypowiedzi łatwo tworzy wrażenie, że system zna również wszystkie fakty.
Dlatego podstawowym pytaniem przed wdrożeniem nie powinno być: „jaki model wybieramy?”. Najpierw trzeba ustalić: „jakie informacje są potrzebne do podjęcia tej konkretnej decyzji i skąd system ma je pobrać?”
Czym naprawdę jest silos danych
Silos danych nie zawsze oznacza starą bazę, do której nikt nie ma dostępu. Czasem wszystkie systemy są nowoczesne i działają poprawnie, ale każdy z nich opisuje tylko własny fragment rzeczywistości.
W praktyce firmy mierzą się z kilkoma rodzajami silosów jednocześnie.
Silosy systemowe
Dane są rozdzielone pomiędzy ERP, CRM, system finansowy, platformę e-commerce, helpdesk, SharePoint, dyski sieciowe i skrzynki pocztowe. Integracje istnieją częściowo albo działają tylko w jednym kierunku.
Silosy organizacyjne
Sprzedaż, finanse, operacje i obsługa klienta przechowują własne informacje i stosują własne zasady dostępu. Technicznie połączenie danych jest możliwe, ale nie wiadomo, kto może wyrazić zgodę, kto odpowiada za jakość i kto powinien rozstrzygnąć konflikt.
Silosy znaczeniowe
To jeden z najbardziej niedocenianych problemów. Dwa działy używają tego samego pojęcia, ale rozumieją je inaczej. „Aktywny klient”, „marża”, „zrealizowane zamówienie” albo „sprawa zamknięta” mogą być obliczane według różnych reguł. AI nie rozwiąże sporu definicyjnego, którego wcześniej nie rozwiązała organizacja.
Silosy tożsamości
Ten sam klient może występować w jednym systemie pod nazwą handlową, w innym pod numerem NIP, a w kolejnym pod adresem e-mail pracownika. Bez wspólnego identyfikatora agent nie wie, że trzy rekordy opisują ten sam podmiot.
Silosy dostępu
Dane istnieją i są poprawne, ale system AI nie może ich bezpiecznie odczytać. Brakuje API, katalogu uprawnień, mechanizmu dziedziczenia praw użytkownika albo sposobu oddzielenia informacji publicznych od poufnych.
Dlaczego problem ujawnia się dopiero po pilotażu
Pilotaż AI często pracuje na starannie wybranym zestawie dokumentów. Zespół usuwa duplikaty, poprawia błędy, porządkuje nazwy i ręcznie dostarcza wszystkie potrzebne materiały. W takim środowisku system prezentuje się bardzo dobrze.
Produkcja wygląda inaczej. Dane zmieniają się codziennie, część dokumentów jest nieaktualna, uprawnienia różnią się pomiędzy pracownikami, a jeden proces przechodzi przez kilka aplikacji. Pojawiają się brakujące pola, opóźnienia integracji i przypadki, których nie było w scenariuszu demonstracyjnym.
To dlatego udany proof of concept nie jest jeszcze dowodem gotowości do wdrożenia. Pokazuje, że AI potrafi wykonać zadanie w przygotowanych warunkach. Nie pokazuje, czy firma potrafi systematycznie dostarczać jej właściwy kontekst.
Badacze Google już w 2014 roku zwracali uwagę, że szybkie korzyści z machine learningu mogą prowadzić do wysokiego długu technicznego. Wśród źródeł tego długu wskazali między innymi ukryte zależności danych, niejawnych odbiorców, sprzężenia zwrotne i zmiany zachodzące poza samym modelem. Ta obserwacja jest jeszcze ważniejsza przy agentach AI, które nie tylko generują wynik, lecz również uruchamiają działania w innych systemach.
Model nie naprawi złych danych
Lepszy model może poprawić rozumienie języka, wnioskowanie albo jakość generowanej odpowiedzi. Nie rozwiąże jednak problemu dwóch różnych wartości tej samej faktury, braku aktualnego statusu zamówienia ani niejasnej definicji klienta aktywnego.
Co więcej, AI może zwielokrotnić skutki problemu. Człowiek obsługuje kilkanaście lub kilkadziesiąt spraw dziennie. Agent może przetwarzać ich tysiące. Jeżeli korzysta z błędnego źródła albo niewłaściwie łączy rekordy, automatyzuje nie tylko pracę, ale również pomyłkę.
NIST w AI Risk Management Framework podkreśla potrzebę dokumentowania pochodzenia danych: ich źródeł, przekształceń, zależności, ograniczeń i metadanych. Nie jest to administracyjny dodatek do projektu. Bez tej wiedzy trudno ocenić, dlaczego system podjął określoną decyzję i czy nadal działa na aktualnym obrazie rzeczywistości.
Czy rozwiązaniem jest przeniesienie wszystkiego do jednego miejsca?
Niekoniecznie.
Hasło „likwidujemy silosy” bywa rozumiane jako wieloletni projekt przeniesienia wszystkich danych do jednej platformy. Taki program może mieć sens, ale nie powinien być warunkiem rozpoczęcia każdego wdrożenia AI.
Firma nie musi najpierw uporządkować całej swojej historii informacyjnej. Musi przygotować minimalny, wiarygodny kontekst dla wybranego procesu.
W zależności od architektury mogą do tego służyć:
- integracje API i warstwa usługowa,
- lakehouse lub hurtownia danych,
- katalog danych i metadanych,
- wspólna warstwa semantyczna,
- master data management dla kluczowych podmiotów,
- wyszukiwarka dokumentów z kontrolą uprawnień,
- RAG dostarczający modelowi aktualne materiały,
- zdarzenia i strumienie danych dla informacji zmieniających się w czasie rzeczywistym.
Technologia jest ważna, ale sama platforma nie ustanowi źródła prawdy ani właściciela definicji. Microsoft wskazuje, że zunifikowane środowisko ułatwia wyszukiwanie, udostępnianie i spójne egzekwowanie polityk. Google podkreśla z kolei, że dane dla AI muszą być godne zaufania, możliwe do odnalezienia, poprawne i zarządzane. W obu podejściach wspólny jest jeden wniosek: wartość nie wynika z samego skopiowania informacji do nowego miejsca, lecz z nadania im spójnego znaczenia i zasad użycia.
Od czego zacząć: jeden proces, jedna decyzja, jeden właściciel
Najrozsądniejszym początkiem nie jest program pod hasłem „porządkujemy wszystkie dane w firmie”. Taki projekt szybko staje się zbyt szeroki, kosztowny i oderwany od wyniku biznesowego.
Lepiej wybrać jeden proces, w którym AI ma podjąć konkretną decyzję lub wykonać określone działanie. Następnie trzeba zbudować mapę danych potrzebnych wyłącznie dla tego przypadku.
1. Zdefiniuj wynik biznesowy
Nie „chatbot dla działu”, tylko na przykład: przygotowanie odpowiedzi na reklamację, zamknięcie niezgodności fakturowej, kwalifikacja zapytania ofertowego albo sprawdzenie kompletności dokumentacji.
2. Wypisz informacje niezbędne do decyzji
Trzeba ustalić, bez jakich danych agent nie może działać, które informacje są pomocnicze i które mają charakter wrażliwy.
3. Wskaż źródło prawdy
Dla każdej informacji należy wskazać system nadrzędny. Jeżeli dwa źródła podają różne wartości, reguła rozstrzygnięcia musi być ustalona przed uruchomieniem automatyzacji.
4. Uzgodnij definicje i identyfikatory
Agent musi wiedzieć, jak połączyć klienta, umowę, zamówienie, fakturę i zgłoszenie. Potrzebny jest wspólny klucz oraz jednoznaczne znaczenie najważniejszych statusów i miar.
5. Zaprojektuj dostęp i odpowiedzialność
AI nie powinna widzieć więcej niż użytkownik lub rola, w imieniu której działa. Jednocześnie każda kluczowa grupa danych musi mieć właściciela odpowiedzialnego za jakość, aktualność i reguły udostępniania.
6. Mierz jakość kontekstu, nie tylko odpowiedzi
Warto kontrolować kompletność danych, ich świeżość, liczbę konfliktów pomiędzy źródłami, odsetek niepołączonych rekordów oraz sytuacje, w których agent musiał przekazać sprawę człowiekowi z powodu braku informacji.
Dane gotowe na AI to zdolność organizacji, nie projekt IT
Silosy danych powstają przez lata. Są efektem kolejnych wdrożeń, przejęć, struktur działowych, indywidualnych arkuszy i decyzji podejmowanych pod presją czasu. Nie znikną po zakupie licencji na platformę ani po podłączeniu modelu językowego.
Można jednak przestać traktować je jako abstrakcyjny problem całej firmy. Dla każdego procesu AI da się wskazać minimalny zestaw danych, właścicieli, definicje, reguły dostępu i sposób kontroli jakości.
To podejście pozwala równolegle osiągać dwa cele: uruchamiać kolejne zastosowania AI oraz stopniowo porządkować architekturę informacyjną tam, gdzie przynosi to mierzalną wartość.
Dlatego pierwszym etapem wdrożenia AI nie powinno być pytanie o liczbę parametrów modelu. Powinna nim być odpowiedź na pięć prostych pytań:
- Jaką decyzję ma podjąć system?
- Jakich danych potrzebuje, aby zrobić to poprawnie?
- Gdzie znajduje się wiarygodne źródło każdej informacji?
- Kto odpowiada za jej znaczenie, jakość i dostęp?
- Co zrobi agent, gdy dane będą niepełne albo sprzeczne?
Jeżeli firma nie zna odpowiedzi, problemem nie jest jeszcze AI. Problemem jest brak wspólnego obrazu własnego biznesu.
I to właśnie jest pierwszy realny bloker, który trzeba usunąć.
Kontekst dla agentów budujemy w Data Intelligence, mapę rzeczywistego przebiegu procesu w Process Intelligence, a kolejność prac ustalamy w trakcie wdrożenia.