Wydaliśmy 8 milionów złotych na hurtownię danych. Mamy zespół data governance. Mamy słownik danych. A nasz model AI wciąż halucynuje — nawet gdy karmimy go naszymi własnymi danymi."
Jeśli brzmi znajomo, nie jesteś sam(a). Zespół techniczny niczego nie zawalił. Hurtownia działa dokładnie tak, jak została zaprojektowana. Problem w tym, że została zaprojektowana do innej pracy.
Przygotowanie danych dla AI jest równie istotne jak dla BI — ale wymagania są fundamentalnie różne.
Twoja hurtownia została zbudowana, by odpowiadać na znane pytania przy użyciu czystych, zagregowanych, dobrze ustrukturyzowanych danych. Modele AI (niezależnie od tego, czy jest to ML, czy GenAI/LLM) muszą odkrywać nieznane wzorce w surowych, granularnych danych o wysokiej wierności. Standardy czystości, które przez dekadę służyły Twoim dashboardom, aktywnie sabotują Twoje ambicje AI.
Dwa sposoby, w jakie tracisz sygnał#
Istnieją dwa mechanizmy, przez które Twoje praktyki data governance niszczą sygnał potrzebny modelom AI.
Utrata sygnału przez filtrowanie (pułapka ETL)
Twoja hurtownia danych została zbudowana w filozofii ETL (Extract-Transform-Load). Zanim dane w ogóle trafiły do tabel, inżynierowie odfiltrowali szum — znaczniki czasu uznane za nieistotne, ciągi user agent, fingerprinty urządzeń, surowe logi transakcji.
Ten „szum" to dokładnie to, czego potrzebuje Twój model wykrywania fraudów. Ten „nieistotny" wzorzec czasowy to coś, czego Twój model prognozowania popytu mógłby się nauczyć.
Filtrując dane przy wczytywaniu danych do hurtowni, podejmujesz nieodwracalną decyzję o tym, jakie informacje są ważne. ETL zakłada, że znasz pytania z góry. AI tak nie działa.
Utrata sygnału przez agregację (problem granularności)
Twoje dane klientów są zagregowane do sum dziennych. Czysto, efektywnie, idealnie do raportów miesięcznych.
Ale Twój model predykcji churnu potrzebuje granularności na poziomie zdarzeń — sekwencji kliknięć, czasu między akcjami, surowego sygnału behawioralnego. Sumy dzienne są „czyste", ale stratne. Agregacja niszczy cechy, które uczyniłyby model użytecznym.
Społeczność hurtowni danych od lat wie, że rozwiązaniem jest ELT (Extract-Load-Transform): wczytaj wszystko w surowej postaci, transformuj wewnątrz platformy. Ale wiele przedsiębiorstw wciąż używa starszych pipeline’ów ETL, a krok „transformacji" odrzuca dokładnie te dane, których potrzebuje AI.
Ekonomika przygotowania danych#
Masz 15 pilotaży AI, żadnego nie da się przenieść na produkcję. Rośnie pokusa uruchomienia ogólnofirmowego „Programu Transformacji Danych", by naprawić jakość danych dla wszystkich. To wieloletnia inicjatywa, która będzie kosztować miliony i zanim dostarczy efekty — technologia zdąży się już zmienić.
Alternatywą jest myślenie w kategoriach ekonomiki produkcji.
Dla każdego biznesowego przypadku użycia oblicz:
Koszt produkcji: Ile będzie kosztować wdrożenie tego na produkcję, włącznie z przygotowaniem pipeline’u danych?
Korzyść produkcyjna: Jaka jest mierzalna wartość biznesowa po wdrożeniu?
Uszereguj je według ROI. Przypadek użycia z najwyższym ROI dostaje Twoją uwagę — nie pilotaż z najważniejszym sponsorem na poziomie zarządu ani z najbardziej efektownym demo.
Następnie skup się na naprawie wyłącznie pipeline’u zasilającego ten przypadek użycia:
Zidentyfikuj Gold Table: Jaka jest pojedyncza, kluczowa tabela, na której trenowany jest Twój model?
Prześledź data lineage: Skąd pochodzą te dane? (Bronze → Silver → Gold)
Napraw u źródła: Rozwiąż problemy z jakością w najwcześniejszej możliwej warstwie.
Zautomatyzuj testy: Użyj testów w stylu dbt, by zrealizować testy regresji.
⠀ To jest naprawa potoku danych, nie transformacja całego obszaru. Ogólnofirmowa poprawa jakości danych zostanie zrealizowana organicznie, jedno wdrożenie produkcyjne po drugim, każde uzasadnione konkretną wartością biznesową.
Architektura medalionowa jako checkpoint governance#
Jeśli budujesz nowoczesną platformę danych, prawdopodobnie znasz już „architekturę medalionową" — warstwy Bronze, Silver, Gold. Oto jak wykorzystać ją jako punkt kontrolny governance dla AI:
| Warstwa | Cel | Akcja Governance |
|---|---|---|
| Bronze | Surowa strefa lądowania ELT, pełna wierność danych | Wykrywanie PII, kontrola dostępu (RBAC) |
| Silver | Warstwa integracji (Data Vault) | Ścieżka audytu, lineage, wymuszanie schematu |
| Gold | ML features / dane gotowe do BI | Testy jakości, sprawdzanie biasu, wersjonowanie |
| Warstwa Gold dla Twojego przypadku użycia AI nie jest tą samą warstwą Gold co dla BI. Modele ML często potrzebują zdenormalizowanych, feature-engineered tabel, które byłyby nieefektywne dla dashboardów. Planuj oddzielne warstwy na poziomie „Gold". |
Governance-as-Code dla potoków danych#
Oto test, który stosuję do każdego programu data governance:
Jeśli Twoja reguła jakości danych nie może automatycznie zablokować builda potoku, to nie jest kontrola — to życzenie.
Praktyczna implementacja:
Testy dbt: Zdefiniuj założenia (assertions) co do jakości danych (unikalność, not-null, dozwolone wartości), które uruchamiają się przy każdym wykonaniu pipeline’u.
Great Expectations: Open-source’owa biblioteka do walidacji danych z automatyczną dokumentacją.
Integracja CI/CD: Blokuj deployment, jeśli testy danych nie przechodzą.
Jeśli deweloper wypchnie kod, który narusza Twoją politykę data governance, build powinien się wysypać zanim złe dane trafią do modelu. To jest Governance-as-Code zastosowane do danych — i to jedyny governance, który naprawdę działa.
Briefing#
IBM: Jakość danych to bariera nr 1 dla AI Governance#
Nowy raport IBM Institute for Business Value, Go Further, Faster with AI, przeprowadzony wśród 1000 liderów wyższego szczebla, wykazał, że 76% z nich wskazuje słabą jakość i zarządzanie danymi jako główną barierę dla skutecznego AI governance — przed lukami kompetencyjnymi, fragmentacją regulacyjną i niespójnością polityk.
Dobry governance przyspiesza wdrożenia AI. Kadra zarządzająca przypisuje 27% swoich zysków efektywności AI silnemu governance, a firmy inwestujące więcej w etykę AI raportują 34% wyższy zysk operacyjny z przypadków użycia AI. A mimo to 58% organizacji wciąż nie ma dobrze zdefiniowanych ram danych i governance.
Jeden na cztery nieudane projekty AI upada z powodu słabego governance — nie ograniczeń technologicznych. Raport argumentuje, że statyczne modele governance załamią się pod tempem rozwoju agentowej AI. Potrzebny jest adaptacyjny, ciągły nadzór wbudowany w workflow, nie w kalendarz.
Dane pokazują, że governance to nie hamulec — to akcelerator konkurencyjności. Jeśli Twoja rozmowa o AI governance wciąż jest traktowana jako „narzut compliance’owy", wyrzucasz pieniądze w błoto. Pytanie nie brzmi czy inwestować w data governance dla AI, ale jak szybko możesz uczynić je adaptacyjnym.
AI Coding Agents: wciąż niegotowe na produkcję#
Analiza VentureBeat autorstwa inżynierów z Microsoftu i LinkedIn podsumowuje, dlaczego AI coding agents wciąż wymagają ciągłego „niańczenia" w środowiskach enterprise. Winowajcy: halucynacje powtarzające się w ramach pojedynczych wątków, brak kontekstu specyficznego dla przedsiębiorstwa, przestarzałe domyślne SDK i brak świadomości sprzętu czy ograniczeń środowiskowych.
Wzorzec jest znajomy. Tak jak Twoja hurtownia danych została zbudowana do innej pracy, tak te agenty zostały wytrenowane na publicznym kodzie — nie na Twoich wewnętrznych repozytoriach, politykach bezpieczeństwa czy architekturze systemów. Autorzy zauważają, że „czas spędzony na debugowaniu kodu generowanego przez AI może przekroczyć oczekiwane oszczędności czasu z automatyzacji".
To echo szerszego trendu. Prognoza Gartnera ostrzega, że do 2027 roku 60% organizacji nie zrealizuje oczekiwanej wartości z AI z powodu niespójnego data governance. Tymczasem badania KPMG wykazały, że 62% organizacji wskazuje brak data governance jako główną barierę hamującą inicjatywy AI.
Czy to Twój model ML, czy coding copilot, powód awarii jest ten sam: AI bez kontekstu to AI bez kontroli. Problem „niańczenia" nie zniknie wraz z lepszymi modelami — wymaga lepszego governance, lineage i projektowania human-in-the-loop od pierwszego dnia.
Pytanie tygodnia#
Przed następnym komitetem sterującym projektu AI zadaj swojemu zespołowi danych to pytanie:
„Jakie dane zostały odfiltrowane przy wczytywaniu do hurtowni — i czy możemy je odzyskać dla tego przypadku użycia AI?"
Jeśli Twój zespół nie potrafi odpowiedzieć na to w 10 minut przedstawiając odpowiedni diagram — masz odpowiedź, gdzie jest bloker. To nie model nie jest problemem tylko potok danych.
Do następnego razu, Krzysztof