AI4 2026. Sztuczna inteligencja kończy etap demonstracji

Z wystąpień na AI4 2026 wyłaniał się spójny wniosek: największym wyzwaniem w skalowaniu AI nie są dziś możliwości modeli, lecz dane, procesy, uprawnienia i gotowość ludzi do zmiany sposobu pracy.

Podczas konferencji interesowały mnie przede wszystkim rozwiązania, które działają nie tylko w trakcie prezentacji, lecz także w rzeczywistych procesach, z prawdziwymi danymi, wyjątkami, ograniczeniami i odpowiedzialnością za wynik. Chciałem sprawdzić, co w praktyce odróżnia efektowne demo od rozwiązania, które można wdrożyć i utrzymać w skali dużej organizacji.

Na głównej scenie Geoffrey Hinton, Fei-Fei Li i Andrew Ng rozmawiali o kierunku rozwoju AI i odpowiedzialności związanej z jej coraz szerszym wykorzystaniem. Kilka sal dalej zespoły wdrażające AI mierzyły się ze znacznie mniej widowiskowymi problemami: jak zweryfikować odpowiedź agenta, jak ograniczyć jego dostęp do danych, jak policzyć koszt całego procesu i kiedy przekazać decyzję człowiekowi.

Różnica między tymi poziomami dyskusji była wyraźna. Pytania o przyszłe możliwości AI pozostają ważne, ale organizacje wdrażające tę technologię muszą już dzisiaj zapewnić jej przewidywalne działanie w realnych procesach i jasno określić odpowiedzialność za rezultat.

Demo to nie produkt

Jedna z ciekawszych sesji przedstawiała drogę Major League Soccer od prostego prototypu do produkcyjnego systemu tworzącego krótkie podsumowania meczów.

Samo wygenerowanie dwóch lub trzech zdań nie było szczególnie trudne. Najwięcej pracy wymagało wszystko dookoła: dostarczenie aktualnych danych, sprawdzenie nazwisk i wyniku, kontrola tonu, ponowienie operacji po błędzie oraz zatrzymanie publikacji, kiedy system nie osiągał wymaganej pewności.

Ten przykład dobrze pokazuje różnicę między demonstracją a rozwiązaniem produkcyjnym. Gotowy system nie składa się wyłącznie z modelu. Potrzebuje również danych, reguł, walidacji, limitów, monitorowania oraz jasno zaprojektowanej eskalacji do człowieka. Im większe konsekwencje błędu, tym ważniejsza staje się ta deterministyczna część rozwiązania.

Podobny wniosek wracał podczas panelu poświęconego skalowaniu pilotaży. Projekty rozpoczynane od technologii często zatrzymują się na etapie atrakcyjnego eksperymentu. Większą szansę na rozwój mają inicjatywy wychodzące od konkretnego problemu klienta lub jednostki biznesowej.

Zanim powstanie agent, trzeba wiedzieć, jaki rezultat ma poprawić: czas obsługi, jakość, koszt, przychód, doświadczenie klienta czy doświadczenie pracownika. Samo „wykorzystanie AI” nie jest wynikiem biznesowym.

Nie istnieje też jeden moment przełączenia rozwiązania z pilota na pełną skalę. Pomiędzy nimi znajduje się zwykle kilka etapów: prototyp, kontrolowany pilotaż, proces działający równolegle z dotychczasowym rozwiązaniem, ograniczone wdrożenie i dopiero później szersze upowszechnienie.

W AI zmieniają się nie tylko modele, lecz także ceny, narzędzia, standardy i oczekiwania użytkowników. Przejście od pilota do produkcji wymaga więc kolejnych etapów oceny, a nie jednorazowej decyzji o wdrożeniu.

Bez właściwego kontekstu agent nie działa wiarygodnie

W wielu sesjach wracał temat danych. Nie chodzi już wyłącznie o klasyczne „garbage in, garbage out”. Agent potrzebuje kontekstu przygotowanego do działania: aktualnego, kompletnego, właściwie podzielonego, opisanego uprawnieniami i możliwego do prześledzenia aż do źródła.

Na jednej z technicznych sesji pokazano przykłady firm pracujących na tysiącach złożonych dokumentów. Pierwsze prototypy wyglądały obiecująco, ale podczas skalowania pojawiły się tabele, skany, diagramy, różne wersje schematów oraz treści zapisane w obrazach. Zwykłe przekazanie dokumentu do modelu przestało wystarczać.

Potrzebne były różne reprezentacje danych, kontrola wersji, pomiar jakości wejścia oraz możliwość odtworzenia, na jakiej podstawie system udzielił konkretnej odpowiedzi.

Osobnym problemem jest pamięć agentów. Jedna z prezentacji opisywała mechanizm przypominający „sen”: system analizuje zakończone interakcje, wyciąga z nich preferencje, fakty i skuteczne sposoby wykonywania zadań, a następnie zapisuje je jako pamięć przydatną w kolejnych rozmowach.

Agent nie musi wtedy za każdym razem zaczynać od zera. Jednocześnie pojawiają się nowe pytania: co wolno mu zapamiętać, jak długo może przechowywać informację, kto może ją odczytać i w jaki sposób można skorygować błędny wniosek? Czy pamięć jednego agenta może zasilać kolejnego?

Zarządzanie taką pamięcią staje się elementem zarządzania firmową wiedzą i dostępem do danych, a nie tylko konfiguracją dodatkowej funkcji chatbota.

Agent nie naprawi złej architektury i procesu

W dużej organizacji proces rzadko mieści się w jednej aplikacji. Dane mogą być rozproszone pomiędzy systemem transakcyjnym, CRM, narzędziem obsługi zgłoszeń, bazą wiedzy, arkuszami, komunikatorami i rozwiązaniami budowanymi wewnętrznie.

Realizacja jednego procesu z perspektywy klienta potrafi wymagać informacji z kilkunastu systemów oraz zaangażowania wielu zespołów, z których każdy odpowiada jedynie za jego fragment. Dodanie agenta do takiego środowiska nie usuwa istniejącej złożoności. Może ją ukryć albo zwiększyć konsekwencje wynikających z niej błędów.

Dlatego przed automatyzacją warto rozłożyć proces na części, usunąć zbędne przekazania pomiędzy zespołami i dopiero później zdecydować, które zadania powinien wykonywać człowiek, które klasyczna automatyzacja, a które model językowy.

Przykład JLL dobrze pokazywał skalę tej zmiany. Firma uruchomiła domenowych agentów wspierających pracowników między innymi w HR, technologii, zakupach i pracy z wiedzą prawną. Ważniejszy od samych agentów był jednak sposób przebudowy procesów przecinających wiele funkcji.

Zamiast optymalizować każdy obszar osobno, wskazano właściciela odpowiedzialnego za wynik całego procesu end-to-end i umożliwiono mu podejmowanie decyzji ponad granicami poszczególnych zespołów.

Ten przykład pokazuje, że skuteczne wdrożenie agentów wymaga zmian nie tylko w systemach, lecz także w sposobie organizacji pracy. Agent szybko ujawnia dług organizacyjny: niejasne odpowiedzialności, niespójne źródła wiedzy oraz przepływy pracy zaprojektowane wokół struktury firmy, a nie rezultatu dla użytkownika.

Technologia nie usuwa tego długu automatycznie. Czasami jedynie pozwala zobaczyć go w pełnej skali.

Nowym użytkownikiem systemów staje się nie-człowiek

Dotychczas zarządzanie tożsamością w przedsiębiorstwie koncentrowało się na pracownikach: ich rolach, dostępach i cyklu życia kont. Obecnie obok ludzi pojawiają się agenci, konta maszynowe, klucze API i połączenia agent-agent.

Tożsamość nie-człowieka staje się pełnoprawnym elementem architektury przedsiębiorstwa.

Podstawowa zasada brzmi: agent nie powinien posiadać większych uprawnień niż osoba, w imieniu której działa. Jej egzekwowanie nie jest jednak proste. Agent może korzystać z kilku narzędzi, łączyć informacje z różnych źródeł i odnajdywać zapisane w nich dane uwierzytelniające. Po zmianie modelu lub dodaniu nowej funkcji jego zachowanie może się zmienić, mimo że kod całej aplikacji pozostał podobny.

Produkcyjny agent potrzebuje więc własnej tożsamości, właściciela po stronie biznesowej, rejestru dostępnych narzędzi, minimalnych uprawnień, monitorowania zachowania oraz możliwości natychmiastowego odcięcia dostępu. Podczas jednej z sesji ujęto ten problem hasłem „Know Your Agent” – przez analogię do znanego z sektora finansowego „Know Your Customer”.

Dla e-commerce ma to szczególne znaczenie. Agent nie musi już ograniczać się do rekomendowania produktów. Może porównywać oferty, składać zamówienia, uruchamiać płatności i kontaktować się z obsługą klienta. W takim świecie zaufanie przestaje być jedynie elementem wpływającym na konwersję. Staje się warunkiem działania agentowego handlu.

Zaufanie do takiego systemu nie może oznaczać założenia, że będzie on bezbłędny. Powinno wynikać z mierzalnej jakości, znanych ograniczeń, przejrzystego śladu decyzji i możliwości bezpiecznego zatrzymania działania.

Citizen development: między inicjatywą a kontrolą

Jednym z istotnych wątków AI4 było również citizen development – wyposażanie pracowników niebędących zawodowymi programistami w narzędzia pozwalające budować własne automatyzacje, agentów i przepływy pracy.

Za tą koncepcją stoi prosta obserwacja: osoby znajdujące się najbliżej problemu najlepiej rozumieją jego kontekst, wyjątki i praktyczne konsekwencje. Centralny zespół technologiczny nie jest w stanie samodzielnie odkryć i obsłużyć setek lokalnych zastosowań rozsianych po całej organizacji.

Oddanie inicjatywy pracownikom może znacząco przyspieszyć eksperymentowanie. Nie może jednak oznaczać braku kontroli. Lokalnie zbudowane rozwiązanie również potrzebuje właściciela, zasad dostępu do danych, testów, monitorowania i planu utrzymania. Trzeba także wiedzieć, kiedy eksperyment powinien zostać wyłączony, a kiedy przekształcony w rozwiązanie wspierane centralnie.

W praktyce potrzebne jest połączenie oddolnej inicjatywy z centralnie przygotowanymi zabezpieczeniami: zatwierdzonymi komponentami, wzorcami architektonicznymi, katalogiem narzędzi, kontrolą uprawnień i wsparciem ekspertów.

Jedna z panelistek ujęła proporcje prowokacyjnie: skalowanie AI to w 80 procentach ludzie, zachowania i zarządzanie zmianą, a tylko w 20 procentach narzędzia. Nie należy traktować tych liczb jako uniwersalnej reguły, ale dobrze oddają one charakter wyzwania.

Na konferencji przedstawiono program, który łączył wsparcie zarządu z oddolną siecią ambasadorów AI. Pracownicy otrzymywali narzędzia, przestrzeń na eksperymenty i krótkie szkolenia obejmujące prompting, krytyczne myślenie, zasady nadzoru i odpowiedzialne wykorzystanie AI. Po sześciu miesiącach program wymagał przebudowy, ponieważ technologia i sposób pracy zdążyły się zmienić.

Programy rozwoju kompetencji nie mogą więc mieć jednorazowego charakteru. Wymagają regularnego aktualizowania materiałów, zasad i przykładów wykorzystywanych w codziennej pracy.

Równie ważne jest doświadczenie pracownika. Jeśli AI jedynie dokłada kolejne narzędzie i wymaga porzucenia dotychczasowych przyzwyczajeń, upowszechnienie rozwiązania zatrzyma się niezależnie od jakości modelu. Łatwiej przyjmują się rozwiązania wbudowane w środowisko, w którym ludzie już pracują, redukujące uciążliwe czynności i dające użytkownikom wyraźną kontrolę nad wynikiem.

Dlatego mierniki wdrożenia powinny obejmować nie tylko oszczędzony czas i koszt, lecz również jakość rezultatu, liczbę błędów, poziom zaufania oraz wpływ rozwiązania na codzienną pracę użytkownika.

Spór o ryzyko, pracę i otwartość

Panel Geoffreya Hintona, Fei-Fei Li i Andrew Ng nie przyniósł wspólnej oceny kierunku rozwoju AI. Różnice dotyczyły przede wszystkim wpływu technologii na zatrudnienie, potrzeby regulacji oraz roli otwartych modeli.

Hinton ostrzegał, że możliwości AI rozwijają się szybciej niż zdolność instytucji do reagowania. Jego zdaniem wzrost produktywności w części zawodów może przełożyć się na spadek zapotrzebowania na pracowników, szczególnie w przypadku powtarzalnej pracy intelektualnej. Opowiadał się przy tym za regulacją rozumianą nie jako hamulec dla rozwoju AI, lecz jako sposób nadawania mu właściwego kierunku.

Ng podważał założenie, że automatyzacja poszczególnych zadań musi oznaczać likwidację całych zawodów. Jako przykład wskazywał programistów, których zakres pracy rozszerza się dzięki narzędziom AI. Podkreślał również przewagę pracowników wynikającą ze znajomości kontekstu organizacji, klientów i praktycznych ograniczeń. Bronił przy tym otwartych modeli, argumentując, że ograniczają one ryzyko skupienia kontroli nad AI w rękach kilku największych firm.

Li unikała zarówno katastroficznych prognoz, jak i bezwarunkowego optymizmu. Zwracała uwagę, że większość zawodów składa się z wielu różnych zadań, z których tylko część może zostać zautomatyzowana. Podkreślała też, że wzrost produktywności nie musi oznaczać równomiernego podziału korzyści. Dlatego rozwój AI powinien chronić sprawczość ludzi oraz obejmować inwestycje publiczne w naukę, uczelnie i otwarte badania.

Z perspektywy organizacji każda z tych ocen wskazuje na inny aspekt tego samego problemu. Trzeba jednocześnie analizować wpływ AI na strukturę pracy, kontrolę nad technologią, pozycję pracownika oraz sposób podziału korzyści wynikających z automatyzacji.

Na poziomie konkretnego wdrożenia pytania stają się bardziej bezpośrednie: do jakich systemów agent ma dostęp, jak mierzony jest jego wynik, co zrobi po błędzie i kto może go zatrzymać. Dyskusja o długoterminowej przyszłości AI nie zastępuje odpowiedzi na te pytania.

Pięć pytań przed wdrożeniem produkcyjnym

Na AI4 2026 pojechałem dzięki Allegro. Spośród wielu prezentowanych metod i przykładów najbardziej przydatne okazały się pytania, które warto zadać przed skalowaniem rozwiązania opartego na AI:

1. Czy usprawniamy pojedynczą czynność, czy cały proces z perspektywy klienta?
2. Czy agent otrzymuje kontekst i uprawnienia potrzebne do wykonania zadania i nic ponadto?
3. Czy obsługa wyjątków i przekazanie sprawy człowiekowi są częścią projektu, czy rozwiązaniem dodanym dopiero po wystąpieniu problemu?
4. Czy poza czasem i kosztami mierzymy również jakość, liczbę błędów oraz wpływ rozwiązania na doświadczenie klienta i pracownika?
5. Co musi się wydarzyć, aby lokalny eksperyment stał się bezpiecznym i możliwym do utrzymania standardem?

Nie są to pytania wyłącznie techniczne. Odpowiedzi zależą od jakości danych, konstrukcji procesu, podziału odpowiedzialności i sposobu mierzenia efektów. To właśnie te elementy, znacznie częściej niż wybór modelu, decydują, czy obiecujący pilotaż da się przenieść na produkcję.

Najważniejszy wniosek, który wynoszę z AI4, dotyczy ograniczeń. Możliwości modeli coraz rzadziej są głównym problemem. Trudniejsze jest zbudowanie wokół nich systemu, który działa przewidywalnie, ma jasno określonego właściciela i potrafi w odpowiednim momencie bezpiecznie przekazać decyzję człowiekowi.

Coraz rzadziej chodzi więc o to, czy AI potrafi wykonać dane zadanie. Znacznie ważniejsze staje się pytanie, czy potrafimy zaprojektować warunki, w których będzie wykonywać je bezpiecznie i powtarzalnie.