Wdrożenie asystenta AI dla działu obsługi klienta kosztowało 680 tysięcy złotych i zostało odebrane w terminie. Model odpowiadał na siedemdziesiąt procent zapytań bez eskalacji, zespół dostał nagrodę wewnętrzną, prezentacja poszła na zarząd. Czternaście miesięcy później skuteczność spadła do czterdziestu jeden procent, a dział obsługi po cichu wrócił do pracy ręcznej, bo szybciej było odpowiedzieć samemu niż poprawiać po asystencie.
Nikt nie zmienił modelu. Nikt nie zmienił promptu. Zmieniło się to, na czym asystent stał: cennik przeszedł dwie rewizje, dwa produkty zostały wycofane, regulamin dostał nowy rozdział o zwrotach, a system CRM zmienił słownik statusów zgłoszeń, bo zespół sprzedaży poprosił o nowe kategorie. Każda z tych zmian była poprawną decyzją biznesową. Żadna nie miała przypisanego kroku „zaktualizuj dane, na których stoi asystent”, bo taki krok nie istniał w żadnym procesie — projekt się skończył, a wraz z nim skończył się budżet, który miał kogokolwiek do tego zobowiązywać.
Ten artykuł broni tezy, która stoi w poprzek sposobu, w jaki ten rynek wycenia AI: największą pozycją kosztową wdrożenia sztucznej inteligencji nie jest model ani infrastruktura, tylko utrzymanie jakości danych w czasie — i to ona, a nie trafność modelu w dniu odbioru, decyduje o tym, czy wdrożenie przeżyje drugi rok.
Dlaczego rachunek za AI wygląda inaczej po dwóch latach niż w budżecie?
Standardowy sposób budżetowania AI dzieli koszt na fazy: proof of concept, wersja minimalna, wdrożenie produkcyjne. Robimy to również my — nasze własne zestawienie kosztów wdrożenia AI od PoC do produkcji jest zbudowane dokładnie w ten sposób i jest użyteczne dla tego, co ma opisać: dla nakładu do momentu uruchomienia.
Problem polega na tym, że ten kształt budżetu niesie ze sobą milczące założenie, które w przypadku AI jest fałszywe. Model fazowy zakłada, że po ostatniej fazie koszt spada do poziomu utrzymania infrastruktury — tak jak w projekcie wdrożenia systemu, gdzie po odbiorze zostaje licencja, hosting i wsparcie. W AI po ostatniej fazie nie spada nic, bo główny czynnik kosztotwórczy nie znajduje się w systemie, tylko na zewnątrz niego: w tempie, w jakim zmienia się świat, który dane opisują.
Model uczy się rozkładu. Rozkład jest zdjęciem rzeczywistości z konkretnego momentu. Rzeczywistość biznesowa zmienia się niezależnie od tego, czy ktoś o tym poinformuje zespół AI: wchodzą nowe produkty, zmieniają się ceny, przepisy, kanały kontaktu, nazewnictwo, struktura organizacyjna. Każda taka zmiana odsuwa dane od rzeczywistości o mały krok, a suma tych kroków ma jedną własność, którą trzeba zobaczyć wprost: degradacja jest cicha. System nie przestaje działać, nie rzuca błędem, nie zapala się na czerwono. Odpowiada dalej, tylko coraz częściej źle — i to w sposób, który wygląda na pewny siebie.
Tu leży asymetria, przez którą ten koszt jest tak systematycznie pomijany. Awaria infrastruktury jest widoczna w minutę i ma właściciela. Degradacja danych jest widoczna po kwartałach i nie ma właściciela, bo nie ma zdarzenia, które by ją zgłosiło. Budżet reaguje na zdarzenia.
Co dokładnie kryje się pod „jakością danych” i dlaczego to nie jest jednorazowe czyszczenie?
„Poprawa jakości danych” brzmi jak zadanie z początku projektu: wyczyścić duplikaty, uzupełnić braki, ujednolicić formaty. To jest jednorazowa część i zwykle najtańsza. Pozycja, o której mówi ten artykuł, składa się z sześciu wymiarów, z których pięć wymaga pracy ciągłej.
Kompletność. Udział rekordów z wypełnionymi polami, na których stoi rozwiązanie. Degraduje się sama, gdy zmienia się proces — nowy formularz, nowe pole nieobowiązkowe, zmiana w kolejności kroków sprzedaży.
Aktualność. Odległość między stanem danych a stanem świata. Jedyny wymiar, który degraduje się nawet wtedy, gdy nikt niczego nie dotyka — samym upływem czasu.
Spójność definicji. To, czy „klient aktywny” znaczy to samo w hurtowni, w CRM i w głowie osoby, która opisała wymaganie. Najbardziej podstępny wymiar, bo rozjazd definicji nie zostawia śladu w danych — zostawia go dopiero w wynikach.
Poprawność etykiet. Przy rozwiązaniach uczonych nadzorowanie: czy przypisane kategorie nadal odpowiadają temu, co kategoria oznacza dzisiaj. Zmiana taksonomii produktów unieważnia część zbioru etykiet natychmiast i po cichu.
Reprezentatywność. Czy dane obejmują przypadki, które faktycznie występują. Wchodzi na nowy rynek albo nowy segment klientów — i zbiór przestaje reprezentować to, o co system jest pytany.
Ciągłość dostawy. Czy źródło nadal dostarcza dane w tym samym kształcie, o tej samej porze, z tą samą semantyką. Najczęstsza przyczyna nagłej awarii i jedyny wymiar, który zwykle ma monitoring.
Pierwszy wymiar da się załatwić projektem. Pozostałe pięć są funkcją tempa zmian w biznesie, a nie funkcją jakości pierwszego wdrożenia. To jest różnica między czyszczeniem a utrzymaniem i jednocześnie różnica między pozycją jednorazową a abonamentem.
Dlaczego w polskich realiach ta pozycja rośnie szybciej, niż wynikałoby z samego biznesu?
Do naturalnego tempa zmian dochodzą u nas czynniki, których w rachunku opartym na zagranicznych benchmarkach po prostu nie ma.
Źródła publiczne zmieniają się bez uzgodnienia z wami. Rozwiązania korzystające z rejestrów — KRS, CEIDG, REGON, dane statystyczne z BDL — dziedziczą ich harmonogram zmian i ich definicje. Zmiana struktury odpowiedzi albo słownika w rejestrze publicznym nie jest z wami negocjowana i nie przychodzi z okresem przejściowym uzgodnionym z waszym zespołem. Każde takie źródło to osobna pozycja w koszcie utrzymania, a nie „darmowe dane”.
KSeF i e-fakturowanie zmieniają najgęstsze źródło danych transakcyjnych w firmie. Ustrukturyzowana faktura to jednocześnie duża szansa i duży koszt przejściowy: dane stają się porównywalne i maszynowo czytelne, ale każdy model albo raport zbudowany na dotychczasowym kształcie danych fakturowych wymaga ponownego zestrojenia. Kto planuje wdrożenie AI na danych sprzedażowych i nie ma tej pozycji w harmonogramie, planuje wdrożenie, które zderzy się ze zmianą schematu u podstawy.
RODO nakłada obowiązek prawidłowości danych. Art. 5 ust. 1 lit. d RODO wymaga, by dane osobowe były prawidłowe i w razie potrzeby uaktualniane, a dane nieprawidłowe niezwłocznie usuwane lub sprostowane. W praktyce oznacza to, że utrzymanie aktualności części zbioru nie jest decyzją biznesową o zwrocie z inwestycji, tylko obowiązkiem — a więc pozycją, której nie da się wyciąć przy rewizji budżetu, choć w wielu organizacjach właśnie tam ląduje nóż.
Rynek kompetencji jest wąski w innym miejscu, niż wszyscy patrzą. Uwaga rekrutacyjna idzie na specjalistów uczenia maszynowego, a wąskim gardłem utrzymania jest inżynieria danych. Kto planuje budżet, powinien patrzeć na stawki inżynierów danych, a nie wyłącznie na stawki zespołu modelowego, bo to ta pierwsza pozycja powtarza się co roku.
Dlaczego koszt modelu spada, a koszt danych rośnie?
Te dwie krzywe rozchodzą się i to rozejście jest głównym powodem, dla którego proporcje z 2023 roku wprowadzają dziś w błąd.
Koszt strony modelowej spada z kilku niezależnych przyczyn naraz: wnioskowanie tanieje z każdą generacją sprzętu i każdą rundą konkurencji między dostawcami, gotowe modele wypierają trenowanie własnych w większości zastosowań firmowych, a narzędzia do budowy rozwiązania dojrzały na tyle, że praca, która zajmowała kwartał, zajmuje tydzień. To jest krzywa, która pracuje na waszą korzyść i będzie pracować dalej.
Koszt strony danych rośnie, bo jest iloczynem dwóch rosnących wielkości. Pierwsza to liczba źródeł — udane wdrożenie natychmiast generuje popyt na kolejne przypadki użycia, a każdy kolejny przypadek podłącza nowe systemy. Druga to tempo zmian w tych źródłach, które rośnie razem z tempem zmian w biznesie. Iloczyn dwóch rosnących liczb rośnie szybciej niż każda z nich.
Praktyczna konsekwencja jest taka: przy planowaniu na trzy lata proporcja z pierwszego roku jest myląca w obie strony. W pierwszym roku model i wdrożenie dominują rachunek, bo to jest rok budowy. W trzecim roku dominuje utrzymanie danych, przy czym w międzyczasie nikt tej proporcji nie przeliczył, bo nikt nie miał do tego powodu — projekt formalnie się zakończył.
Z tego, co widzimy w rozmowach o utrzymaniu, roczny koszt utrzymania jakości danych dla rozwiązania w produkcji plasuje się zwykle w przedziale kilkunastu do kilkudziesięciu procent pierwotnego kosztu wdrożenia, przy czym górna część przedziału dotyczy rozwiązań opartych na wielu źródłach i na danych opisujących szybko zmieniającą się ofertę. To jest rząd wielkości, nie stawka — ale nawet jako rząd wielkości wystarcza, żeby zmienić decyzję o zakresie pierwszego wdrożenia.
Skąd bierze się drugi rok jako moment śmierci wdrożenia?
Drugi rok nie jest przypadkowy i nie jest przesądem branżowym. Zbiegają się w nim cztery zegary, z których każdy tyka od dnia odbioru.
Zegar pierwszy: dryf danych wchodzi w zakres istotności. Pojedyncze zmiany w ofercie, procesie i słownikach nie ruszają wyniku zauważalnie. Ich suma po kilkunastu miesiącach — owszem. Degradacja jest stopniowa aż do momentu, w którym przekracza próg, poniżej którego użytkownicy jeszcze tolerowali błędy.
Zegar drugi: budżet projektowy się zamknął. Rezerwa, z której finansowano poprawki w pierwszych miesiącach, zniknęła wraz z rozliczeniem projektu. Utrzymanie zostało w budżecie operacyjnym w wysokości pokrywającej infrastrukturę, bo tak wyglądał wniosek.
Zegar trzeci: odeszła osoba, która rozumiała dane. Wiedza o tym, dlaczego jedno pole jest wiarygodne, a drugie należy ignorować, rzadko trafia do dokumentacji. Rotacja w zespołach danych sprawia, że po roku albo dwóch nikt nie potrafi odtworzyć intencji stojącej za transformacją.
Zegar czwarty: zaufanie użytkowników wyczerpuje się nieliniowo. Ludzie tolerują błędy narzędzia do pewnego progu, a po jego przekroczeniu przestają go używać skokowo, nie stopniowo. Odzyskanie zaufania kosztuje wielokrotnie więcej niż jego utrzymanie, bo wymaga nie tylko naprawy, ale i udowodnienia naprawy.
Wniosek jest niewygodny dla wszystkich stron rozmowy handlowej: wdrożenie AI zaplanowane bez pozycji utrzymaniowej nie jest wdrożeniem tańszym. Jest wdrożeniem z krótszym horyzontem, w którym różnicę pokrywa się później i po wyższym koszcie jednostkowym — bo restart zawsze kosztuje więcej niż ciągłość.
Jak policzyć roczny koszt utrzymania jakości danych przed podpisaniem projektu?
Rachunek nie wymaga narzędzi ani konsultanta i mieści się w tygodniu pracy. Trzy wielkości, wszystkie mierzalne historycznie.
Liczba niezależnych źródeł. Policz systemy, z których rozwiązanie faktycznie czerpie dane — nie warstwy pośrednie, tylko miejsca, w których dane powstają. Każde źródło ma osobnego właściciela, osobny harmonogram zmian i osobny tryb awarii. Koszt utrzymania skaluje się z tą liczbą prawie liniowo, a złożoność uzgodnień szybciej niż liniowo.
Historyczne tempo zmian schematu. Dla każdego źródła sprawdź w historii zmian ostatnich dwóch lat, ile razy zmieniła się struktura albo definicja pola, na którym rozwiązanie ma stać. To jedyna prognoza tempa zmian, która nie jest zgadywaniem — bo poprzednie dwa lata są najlepszym dostępnym przybliżeniem kolejnych dwóch.
Udział danych wymagających ludzkiej oceny. Tylko ta część generuje koszt ponownego etykietowania, i tylko ona wymaga budżetu na pracę ludzi, a nie na maszyny. Jej wielkość rozstrzyga, czy pozycja utrzymaniowa jest umiarkowana, czy dominująca.
Do tych trzech dochodzą dwie pozycje stałe, mniejsze i łatwiejsze do oszacowania: monitoring jakości danych (testy świeżości, kompletności i rozkładu uruchamiane automatycznie) oraz czas na reagowanie na alarmy, który jest realnym ułamkiem etatu, a nie zerem. Wielkości te warto zebrać w tym samym arkuszu, w którym liczycie koszt wdrożenia od PoC do produkcji — jako osobny wiersz powtarzalny rocznie, nie jako procent narzutu.
Ile kosztuje ponowne etykietowanie i dlaczego nikt tego nie budżetuje?
Etykietowanie jest jedyną pozycją kosztową w AI, która jest widoczna na starcie i niewidoczna później — i to zestawienie tłumaczy, dlaczego wypada z rachunku.
Na starcie widać ją doskonale: ktoś musi opisać zbiór, jest to praca ludzka, ma cenę i termin, więc trafia do budżetu bez dyskusji. Nasze opracowanie o adnotacji danych jako procesie strategicznym opisuje tę fazę szczegółowo.
Niewidoczna staje się w momencie, w którym zbiór jest gotowy — bo intuicja podpowiada, że etykieta jest trwała. Nie jest. Etykieta jest twierdzeniem o świecie i traci ważność razem z nim. Zmiana taksonomii produktów unieważnia część etykiet natychmiast. Nowa kategoria zgłoszeń w obsłudze klienta oznacza, że dotychczasowy zbiór nie zawiera ani jednego przykładu klasy, która od jutra będzie występować. Zmiana regulaminu przesuwa granicę między dwiema klasami, przez co część historycznych etykiet staje się po prostu błędna.
Praktyczna reguła, którą warto przyjąć w planowaniu: w domenach, w których oferta lub proces zmieniają się kilka razy w roku, roczne odświeżenie obejmuje istotny ułamek pierwotnego zbioru — nie kilka procent. Organizacje, które tego nie budżetują, i tak ponoszą ten koszt, tylko w gorszej formie: jako spadek skuteczności, który jest widoczny dopiero z opóźnieniem i kosztuje dodatkowo utratą zaufania użytkowników.
Jest tu też prosty ruch obniżający tę pozycję, który warto rozważyć przed pierwszym etykietowaniem: projektowanie taksonomii tak, żeby była odporna na przewidywalne zmiany oferty. Etykiety opisujące intencję klienta starzeją się wolniej niż etykiety opisujące nazwę produktu, a różnica w koszcie utrzymania między tymi dwoma podejściami jest wielokrotna.
Czy gotowy model albo warstwa RAG zdejmuje ten koszt?
To jest najmocniejszy zarzut wobec tezy tego artykułu i zasługuje na uczciwą odpowiedź, bo w pewnym zakresie jest trafny.
Trafny jest w tym: rezygnacja z trenowania własnego modelu na rzecz gotowego rzeczywiście usuwa z rachunku duże pozycje — koszt zbioru treningowego, koszt obliczeń, koszt zespołu badawczego. Wybór między budową a zakupem rozwiązania AI faktycznie przesuwa znaczną część kosztu na dostawcę, i dla większości zastosowań firmowych jest to dziś wybór właściwy.
Nietrafny jest w tym, że nie usuwa pozycji, o której mówi ten artykuł — przenosi ją i zmienia jej nazwę. W układzie z wyszukiwaniem w waszych dokumentach jakość odpowiedzi jest funkcją jakości pobierania, a jakość pobierania jest funkcją jakości i świeżości tego, co zindeksowano. Baza wektorowa zbudowana na procedurach z ubiegłego roku zwraca procedury z ubiegłego roku, i robi to z pełną płynnością językową, która jest tu dodatkowym problemem: odpowiedź brzmi wiarygodnie niezależnie od tego, czy źródło jest aktualne.
Zmieniają się natomiast konkretne pozycje w rachunku i warto je nazwać, bo to zmienia plan działania:
- znika koszt trenowania i etykietowania zbioru uczącego;
- zostaje i rośnie koszt świeżości — kto i jak często sprawdza, czy zaindeksowane dokumenty są aktualne, i kto wycofuje nieaktualne;
- pojawia się koszt rozstrzygania sprzeczności — gdy dwa dokumenty mówią co innego, ktoś musi zdecydować, który obowiązuje, bo system tego nie zrobi;
- zostaje koszt spójności definicji, dokładnie ten sam co przy modelach uczonych, bo to problem organizacji, a nie techniki.
Wniosek dla praktyka: architektura zmienia strukturę kosztu utrzymania danych i potrafi go obniżyć, ale nie sprowadza go do zera w żadnym scenariuszu, w którym dane opisują coś, co się zmienia.
Kiedy ta teza się nie stosuje?
Są przypadki, w których koszt utrzymania jakości danych jest naprawdę bliski zeru i uczciwość wymaga ich wskazania — bo teza sformułowana bez wyjątków jest hasłem, a nie analizą.
Dane zamknięte i statyczne. Rozpoznawanie treści dokumentów o ustabilizowanym, wieloletnim formacie, przetwarzanie skanów według stałego wzorca, klasyfikacja obiektów, których definicja nie zależy od decyzji biznesowych. Świat opisany przez te dane po prostu się nie zmienia, więc nie ma czego utrzymywać.
Dane, które są samym systemem. Asystent pracujący na repozytorium kodu ma dane aktualizowane przez zwykłą pracę zespołu — świeżość jest produktem ubocznym procesu, a nie osobnym zadaniem. To najzdrowszy możliwy układ i warto go szukać przy wyborze pierwszego przypadku użycia.
Zastosowania jednorazowe i analityczne. Jednorazowa analiza historycznego zbioru w celu podjęcia jednej decyzji nie potrzebuje utrzymania, bo nie ma horyzontu, w którym mogłaby się zestarzeć.
Warto z tego wyciągnąć wniosek praktyczny, który jest zaskakująco użyteczny przy wyborze pierwszego wdrożenia: przypadki użycia różnią się kosztem utrzymania o rząd wielkości, a ta różnica jest widoczna przed rozpoczęciem projektu. Wybierając między dwoma kandydatami o podobnym zwrocie, wybierz ten, którego dane zmieniają się wolniej — kupujesz w ten sposób nie tylko niższy koszt, ale i dłuższy czas życia wdrożenia.
Kto powinien być właścicielem tej pozycji budżetowej?
Umiejscowienie kosztu jest tu ważniejsze niż jego wysokość, bo rozstrzyga o tym, czy ktokolwiek ma jednocześnie wiedzę i wpływ.
Nie zespół AI. Zespół widzi skutek — spadek skuteczności — ale nie ma wpływu na przyczynę. Nie on decyduje, że handlowcy przestaną wypełniać pole ani że system źródłowy zmieni słownik. Trzymanie tej pozycji w budżecie zespołu AI oznacza, że przy pierwszej rewizji kosztów zostanie ona obcięta jako „utrzymanie narzędzia”.
Nie dział IT. IT odpowiada za to, że dane płyną, i robi to dobrze. Nie odpowiada za to, czy znaczą to, co powinny znaczyć — bo to jest pytanie o proces biznesowy.
Właściciel procesu, w którym dane powstają. To jedyna rola, która ma jednocześnie wiedzę o tym, co dane znaczą, i wpływ na to, jak są wytwarzane. Kierownik sprzedaży odpowiadający za jakość danych o klientach ma narzędzia, żeby coś z nią zrobić; kierownik zespołu AI ma wyłącznie alarm.
Praktyczny sposób osadzenia tej odpowiedzialności bez tworzenia nowej struktury to kontrakt danych między właścicielem źródła a odbiorcą. Kontrakt zawiera cztery elementy i mieści się na dwóch stronach: opis struktury i znaczenia udostępnianych pól; zobowiązanie do świeżości, czyli maksymalne opóźnienie, z jakim dane odzwierciedlają rzeczywistość; zobowiązanie do uprzedzenia o zmianie łamiącej zgodność, z konkretnym wyprzedzeniem; oraz imiennie wskazanego właściciela po obu stronach. Kontrakty danych są zwykłą praktyką w architekturach zdecentralizowanych — podejście data mesh opisuje je jako element modelu — ale ich wartość nie zależy od architektury i nie wymaga żadnej transformacji, żeby zacząć.
Jak wygląda mapa dojrzałości utrzymania jakości danych?
Poniższa mapa pozwala umiejscowić własną organizację w kilka minut. Kolumna z typowym objawem jest ważniejsza od nazwy poziomu, bo to po objawie rozpoznaje się miejsce, w którym się jest.
| Poziom | Kto odpowiada za jakość danych | Jak wykrywana jest degradacja | Pozycja w budżecie | Typowy objaw |
|---|---|---|---|---|
| 0 — brak | nikt | przez skargę użytkownika | brak | wdrożenie cicho przestaje być używane, nikt nie zgłasza awarii |
| 1 — reaktywny | zespół AI, po fakcie | przez spadek skuteczności zauważony przy przeglądzie | doraźnie, z rezerwy | cykl gaszenia pożarów co kilka miesięcy, zawsze po fakcie |
| 2 — monitorowany | zespół danych | automatyczne testy świeżości i kompletności | stała pozycja utrzymaniowa | alarmy istnieją, ale nikt nie ma mandatu, żeby wymusić naprawę u źródła |
| 3 — kontraktowy | właściciel źródła, na podstawie kontraktu danych | testy plus zobowiązanie do uprzedzenia o zmianie | pozycja u właściciela procesu | zmiany schematu przychodzą z wyprzedzeniem, nie jako awaria |
| 4 — wbudowany | proces biznesowy | jakość mierzona w miejscu powstania danych | koszt procesu, nie koszt AI | nowe przypadki użycia startują tygodniami zamiast kwartałami |
Przeskok, który zmienia ekonomikę, następuje między poziomem 2 a 3 i nie jest przeskokiem technicznym — na poziomie 2 organizacja już wszystko wie, tylko nikt nie ma mandatu. Poziom 3 wymaga jednej decyzji zarządczej: przeniesienia pozycji budżetowej i odpowiedzialności do właściciela źródła. Nie wymaga nowego narzędzia.
Jakie są kluczowe wnioski?
Wdrożenia AI rzadko umierają dlatego, że model był zły. Umierają, bo dane, na których stały, rozjechały się z rzeczywistością, a w organizacji nie było pozycji budżetowej ani osoby, której zadaniem byłoby temu zapobiec. Model fazowy — PoC, MVP, produkcja — opisuje tylko koszt budowy i milcząco sugeruje, że po odbiorze zostaje utrzymanie infrastruktury. W AI po odbiorze zaczyna się właśnie ta pozycja, która rozstrzyga o powodzeniu.
Trzy rzeczy warto zrobić przed podpisaniem kolejnego wdrożenia. Po pierwsze, policz źródła i sprawdź w historii zmian, ile razy w ostatnich dwóch latach zmieniła się struktura każdego z nich — to najlepsza dostępna prognoza kolejnych dwóch lat. Po drugie, dopisz do budżetu osobny, powtarzalny co roku wiersz na utrzymanie jakości danych, zamiast chować go w narzucie na utrzymanie. Po trzecie, wskaż imiennie właściciela tego wiersza po stronie biznesu, nie po stronie zespołu AI — a jeśli nie da się nikogo wskazać, potraktuj to jako informację o gotowości organizacji, a nie jako drobiazg do dopięcia później.
Przy wyborze pierwszego przypadku użycia warto też świadomie uwzględnić tempo zmian danych jako kryterium na równi ze zwrotem, korzystając z tej samej dyscypliny, co przy ocenie dostawcy AI. Wdrożenie o niższym zwrocie i wolniej starzejących się danych bywa lepszą pierwszą decyzją niż spektakularne, które zestarzeje się w rok.
W ARDURA Consulting budujemy rozwiązania z obszaru AI i inżynierii danych i rozmowę o wdrożeniu zaczynamy od pytania, które w tej branży pada zbyt rzadko: kto po odbiorze będzie odpowiadał za to, żeby dane nadal opisywały rzeczywistość. Porozmawiajmy o waszym przypadku użycia, zanim jego koszt policzy za was drugi rok.