Drogi Czytelniku,
Zacząłem ten newsletter w połowie 2025 roku, bo uważałem, że AI governance to ważny problem, który większość organizacji ignoruje. Miałem temat, na którym mi zależało, i nikogo wokół, kto byłby gotowy go omawiać tak szczegółowo, jak uważałem, że trzeba.
Czterdzieści wydań później zmieniły się dwie rzeczy. Pierwsza: więcej osób się tym interesuje, niż się spodziewałem. Druga: problem jest znacznie większy, niż myślałem, gdy zaczynałem pisać.
Zacząłem od governance. Okazało się, że governance to jedna z pięciu warstw problemu, którego wiele firm jeszcze nie nazwało: jak przenieść AI z eksperymentu do produkcji. Przepaść nie leży między „strategią AI" a „AI governance." Leży między demo, które zrobiło wrażenie na zarządzie, a systemem, który działa każdego dnia bez niczyjej opieki.
Czytelnicy wciąż mówili o tym samym. Nie „potrzebujemy lepszych polityk", tylko „mamy pięć pilotaży, żaden w produkcji, a zarząd pyta, co się stało z budżetem." Nie problem governance. Problem produkcyjny. Governance jest częścią tego problemu, ale tylko częścią.
To wydanie różni się od zwykłego formatu. Nie ma Briefing, nie ma analizy konkretnego obszaru. Zamiast tego: podsumowanie tego, co wyłoniło się z czterdziestu wydań — tematy, których nie planowałem poruszać — i dokąd to doprowadziło.
Trzy wzorce, których nie spodziewałem się odkryć#
1. Wiele firm zadaje niewłaściwe pierwsze pytanie#
Pytanie, które najczęściej słyszę od zespołów zarządzających, brzmi: „Gdzie możemy użyć AI?"
To złe pytanie. Właściwe pytanie brzmi: „Jaki jest nasz najdroższy nieefektywny proces?"
Pierwsze jest technology-first. Efekt: lista trzydziestu use case’ów, żadnego z priorytetem, każdy z pitchem innego dostawcy. Drugie jest pain-first. Efekt: sekwencja. Zacznij od tego, co można łatwo poprawić i uzyskać konkretne korzyści, idź dalej.
Ten wzorzec pojawił się w każdej branży, którą opisywałem. W bankowości (#36) największą luką nie jest brak modeli AI — brakuje inwentaryzacji tego, jakie AI już działa w produkcji. W telco (#37) operatorzy mają po pięćdziesiąt zidentyfikowanych use case’ów i często żadnego pomysłu na kolejność. W naukach medycznych (#38) porażki (Watson for Oncology, 62 miliony dolarów, zero wyleczonych pacjentów) miały tę samą przyczynę co sukcesy (Insilico, od identyfikacji celu do Phase 2a w pięć lat): nie jakość modelu, ale zakres problemu. W sektorze publicznym (#39) holenderski system weryfikujący dopłaty społeczne działał przez siedem lat, bo nikt nie zapytał, co się stanie z rodzinami, które model wytypował jak wyłudzające świadczenia.
Technologia zadziałała w każdym przypadku. Pytanie, które ją poprzedziło, przesądziło o wyniku.
2. Governance theatre jest domyślnym ustawieniem#
Zarządy akceptują zasady AI. Zespoły „stemplują” wyniki modeli. Pracownicy używają narzędzi, których nikt nie zatwierdził. W każdej warstwie ten sam problem: imponująca powierzchnia, za którą jest niewiele. Albo, co gorsza, firmy po prostu zamykają oczy i udają, że governance nie jest potrzebne (albo naprawdę nie wiedzą, że jest).
Wciąż sięgałem po ten sam termin — governance theatre. Wydanie po wydaniu, różne sektory, różne reżimy regulacyjne, różne poziomy dojrzałości: schemat się powtarza. Polityka governance, której system monitoringu nie egzekwuje. Wymóg „human-in-the-loop" spełniony przez kogoś, kto akceptuje wyniki bez czytania, bo ma czterdzieści innych zadań. Shadow AI, które działa w najlepsze, bo nikt nie wiedział, jak zająć się problemem.
Przepaść między deklarowanym a faktycznym nadzorem nie jest problemem komunikacji. Jest strukturalna. I często jest niewidoczna z poziomu zarządu — dlatego się utrzymuje.
3. Problem ciągle się rozrasta#
Zacząłem od governance. Z czasem pojawiła się architektura governance, controls-as-code zamiast controls-as-PowerPoint. Potem pojawiły się business case’y i ROI. Seria Production OS (#31-35) skończyła się specyfikacją pięciu warstw opisujących AI w produkcji: strategia, governance, przeprojektowanie procesów, architektura techniczna i model operacyjny, który je łączy.
Zakres się rozszerzał, bo musiał. Każda rozmowa z czytelnikiem albo potencjalnym klientem trafiała w tę samą ścianę: samo governance nie doprowadzi AI do produkcji. Firma może być w pełni zgodna z regulacjami i wciąż nie mieć ani jednego systemu AI, który generuje wartość. Brakujący element to nigdy nie jest jedna warstwa — to kombinacja komponentów z kilku. Business case zbudowany na założeniach, których architektura nie jest w stanie dostarczyć. Polityka governance, której gateway nie egzekwuje. Przeprojektowanie procesu, którego nikt nie zmapował na istniejący stack technologiczny.
Spojrzałem na te czterdzieści wydań i uświadomiłem sobie, że sam newsletter przeszedł tę samą ewolucję. Zaczął od wyjaśniania jednej warstwy. Skończył na specyfikowaniu systemu.
Punkt zwrotny#
Z czasem zaczęły pojawiać się pytania od czytelników. Okazało się, że nie dotyczyły poszczególnych regulacji EU albo frameworków zarządzania ryzykiem. To byłyby typowe pytania do newslettera. Pytania dotyczyły wdrożeń: „Możesz nam pomóc to zbudować?" albo „Mamy podobny problem — możemy porozmawiać?"
Nie planowałem pisać trylogii o Shadow AI. W #24 opisałem nieautoryzowane użycie narzędzi. W #28 problem eskalował do nieautoryzowanej produkcji kodu — pracowników budujących systemy narzędziami AI poza jakimikolwiek ramami governance. W #32 pojawiło się rozwiązanie architektoniczne: brama AI egzekwująca polityki na poziomie infrastruktury. Trzy wydania, napisane w odstępie kilku tygodni, które złożyły się w diagnozę, eskalację i leczenie.
Frameworki, które pisałem do newslettera, zaczęły pojawiać się w moich rozmowach z klientami. Shadow AI Protocol. Production Readiness Checklist. Business Case Validation Canvas. Okazywało się, że to, co pisałem jako analizę, klienci traktowali jako narzędzia.
Wtedy newsletter przestał być tylko newsletterem. Nie dlatego, że postanowiłem coś zbudować — dlatego, że czytelnicy zaczęli budować za jego pomocą.
Co dalej?#
Schemat był jasny: czytelnicy chcieli czegoś więcej niż czytania. Chcieli, żeby ktoś przeprowadził ich przez wdrożenie. Nie tylko governance. Pełną ścieżkę od eksperymentu do produkcji.
Nie planowałem budować wokół tego praktyki. Popyt pojawił się przed biznesplanem.
Pomysł na nazwę wziął się od porównania z tym, w jakiej sytuacji jest teraz rynek rozwiązań AI dla enterprise. Kwintant to urządzenie nawigacyjne skonstruowane w XVIII w. — znacznie mniej znane niż sekstant — jedna piąta okręgu, używane przez żeglarzy do ustalania pozycji na otwartych wodach, gdy morza były niezbadane, a jedynymi wiarygodnymi punktami odniesienia były gwiazdy. Nie sterował statkiem. Mówił ci, gdzie jesteś, żebyś mógł zdecydować, dokąd płyniesz dalej.
To właśnie robiłem w rozmowach z klientami. Nie sterowałem, mierzyłem. Gdzie AI już działa? Gdzie jest ekspozycja na ryzyko? Wartość nigdy nie polegała tylko na mówieniu firmom, co teoretycznie mogłyby robić AI — to robią vendorzy technologii. Polegała na tym, żeby pomóc im zobaczyć, gdzie faktycznie się znajdują i jaki kurs wybrać, gdzie są mielizny a gdzie pojawiają się sztormy.
Quintant pracuje z organizacjami, które utknęły między „mamy pilotaże AI" a „potrafimy udowodnić, że AI generuje wartość." Pięć warstw zmapowanych w newsletterze — teraz także jako projekty doradcze.
Jeśli czytasz ten newsletter i rozpoznajesz w tych wzorcach swoją organizację — złe pierwsze pytanie, governance istniejące na papierze, pilotaże, które nigdy nie wchodzą do produkcji — to jest punkt wyjścia. Na quintant.ai jest narzędzie diagnostyczne: piętnaście minut, bez zobowiązań, raport pokazujący, gdzie są luki. Najpierw ustal swoją pozycję, potem nawiguj.
Newsletter będzie trwał dalej. Research robiony co tydzień pozwala mi nauczyć się nowych rzeczy, a pisanie każdego kolejnego wydania świetnie porządkuje myśli na dany temat. Quintant ma pomagać tym, którzy chcą przejść od myślenia do budowania.
Jeśli Twoja organizacja wdraża AI i nikt nie zapytał „co się stanie, gdy to wejdzie do produkcji" — kto w Twoim zespole zarządzającym powinien zadać to pytanie?
Stay balanced,
Krzysztof Goworek