Start z polskim AI – od pomysłu do wdrożenia #Centralny Ośrodek Informatyki
Start z polskim AI to cykl rozmów, którego celem jest przedstawienie doświadczeń związanych z polskimi modelami językowymi AI oraz praktykami firm i instytucji we wdrażaniu tych rozwiązań. Zapraszamy do rozmowy z Mikołajem Mroszczakiem, kierownikiem zespołu AI i Automatyzacji w Centralnym Ośrodku Informatyki.
Czy jako COI i jako przedstawiciel zespołu wdrażania AI tworzycie własne, autorskie modele, czy raczej bazujecie na polskich rozwiązaniach – takich jak PLLuM Jak to wygląda w praktyce u Was?
Jesteśmy zespołem wdrożeniowym AI. Przez ostatni rok byliśmy jednak członkiem konsorcjum HIVE, czyli zespołu rozwijającego polski model PLLuM. Nasza rola miała charakter praktyczny i wdrożeniowy: wnosiliśmy perspektywę realnego użytkowania modeli, opartą na doświadczeniach z budowy i testowania chatbotów.
Dostarczaliśmy wiedzę o tym, jakie pytania faktycznie zadają użytkownicy, jakie style odpowiedzi preferują oraz jakie problemy pojawiają się w codziennej pracy modeli. Dysponujemy też cennymi danymi z testów wewnętrznych, nie są to dane z publicznego asystenta w mObywatelu (które nie mogą być wykorzystywane do trenowania modeli ze względów prawnych), ale na przykład dane dotyczące bezpieczeństwa i odporności modeli na próby „łamania”.
To właśnie w tym obszarze wnosimy dużą wartość, bo podchodzimy do zabezpieczania modeli z perspektywy inżyniera i praktyka, pokazując twórcom modeli realne, często nieoczywiste scenariusze problemów. Przykładem jest sytuacja, w której chatbot, mimo instrukcji systemowych interpretuje treści kontekstowe w sposób sprzeczny z założeniami (np. „każe zainstalować aplikację”, mimo że już w niej działa). Takie „smaczki” i wnioski z testów przekazujemy konsorcjum, wspierając rozwój modeli od strony praktycznego wdrożenia i jakości działania. My z kolei sprawdzamy, jak model radzi sobie w rzeczywistym systemie, bo system AI to coś znacznie więcej niż sam model. Wykorzystujemy go na różne sposoby: do klasyfikacji, do generowania odpowiedzi, do analizy wielu dokumentów i wskazania tego najlepiej dopasowanego do zapytania. Są to obszary, które często wykraczają poza codzienny zakres pracy twórców modeli. Oczywiście duże organizacje, takie jak OpenAI, dysponują zespołami na wszystkich poziomach, natomiast w przypadku modeli takich jak PLLuM kluczowa jest specjalizacja i ścisła współpraca między twórcami modeli a zespołami wdrożeniowymi.
Wasza rola w konsorcjum polegała na pracy wdrożeniowej i testowej. Czy w przypadku PLLuM-a ta współpraca wyglądała podobnie? I czy – poza mObywatelem – możecie wskazać inne projekty lub zastosowania, w których wykorzystywaliście ten model, czy był to kluczowy obszar współpracy?
Naszą główną rolą było wdrożenie asystenta w mObywatelu. To był kluczowy i najbardziej czasochłonny obszar naszych działań. Równolegle angażowaliśmy się jednak także w inne inicjatywy. Ocenialiśmy pilotażowe wdrożenie asystenta w Ministerstwie Cyfryzacji, koncentrując się na jakości i skuteczności mechanizmów zabezpieczających. Testowaliśmy różne podejścia do bezpieczeństwa, aby sprawdzić, które z nich najlepiej sprawdzają się w praktyce.
Istotnym elementem naszej pracy było również wsparcie twórców modeli w kontekście specyfiki administracji publicznej. Administracja posługuje się bardzo precyzyjnym i często nieoczywistym językiem. Przykładem są pojęcia takie jak dowód osobisty, e-dowód, m-dowód czy „dowód osobisty w aplikacji mObywatel”, który formalnie nie jest dokumentem. To subtelne różnice semantyczne, które mają ogromne znaczenie i których poprawnego rozumienia oczekujemy od modeli wykorzystywanych w obszarze urzędowym.
Poza wdrożeniami i bezpieczeństwem wspieraliśmy również konsorcjum HIVE w badaniach użyteczności. Dysponujemy własnym zespołem badawczym, który prowadzi analizy ilościowe i jakościowe odpowiedzi chatbota – z perspektywy UX i nauk społecznych. Badamy, jakich odpowiedzi oczekują użytkownicy i w jakim kierunku powinien rozwijać się asystent. Ten obszar badań był dodatkową, istotną wartością, którą wnieśliśmy do konsorcjum.
Moje kolejne pytanie dotyczy potrzeb, które adresujecie. Wspomniałeś o wielu z nich przy poszczególnych przykładach, ale gdyby spojrzeć na to bardziej ogólnie, szczególnie w kontekście współpracy z Ministerstwem Cyfryzacji. Czy mógłbyś wymienić, jakie były kluczowe potrzeby, usprawnienia i obszary automatyzacji, którymi się zajmowaliście?
Zaczynając od wirtualnego asystenta to w praktyce odpowiada on na dwa kluczowe problemy. Pierwszy to dostępność usług. Zarówno w mObywatelu, jak i na gov.pl funkcjonuje bardzo wiele usług, które są często złożone i nie zawsze łatwe do znalezienia. Tradycyjne wyszukiwanie
w internecie wymaga pewnych kompetencji cyfrowych i często prowadzi do niepełnych lub niewiarygodnych źródeł. Wirtualny asystent pozwala natomiast zadać pytanie w języku naturalnym, np. „sprowadziłem auto z Niemiec – co muszę zrobić?”, i otrzymać uporządkowaną, kontekstową odpowiedź opartą na oficjalnych informacjach. Drugi obszar to budowanie kompetencji w administracji. Skala wdrożeń AI jest dziś na tyle duża, że nie ma możliwości, aby COI realizował wszystkie projekty samodzielnie. Większość wdrożeń będzie powstawać bezpośrednio w jednostkach administracji lub przy wsparciu partnerów zewnętrznych. Naszą rolą – jako Ministerstwa Cyfryzacji, COI czy NASK – jest dostarczanie standardów, dobrych praktyk i wiedzy: m.in. wskazywanie, jakie modele nadają się do konkretnych zastosowań oraz jakie ryzyka należy brać pod uwagę. Dzięki temu, że jesteśmy blisko zarówno technologii, jak i legislacji, możemy jako pierwsi mierzyć się z wyzwaniami prawnymi, np. na styku AI Actu i danych osobowych. Przeciętny urząd często nie ma dostępu do wyspecjalizowanego zaplecza prawnego, które w tym obszarze jest kluczowe. W efekcie, nawet jeśli nie zawsze jest to formalnie nasza rola wdrożeniowa poprzez te działania budujemy trwały zasób wiedzy i kompetencji, zarówno w ministerstwie, jak i w całej administracji.
Wracając jeszcze do Waszej współpracy polskim modelem PLLuM. Jakie kluczowe obszary i kryteria były dla Was – jako COI – najistotniejsze w trakcie tej współpracy?
Z naszej perspektywy kluczowym kryterium zawsze była i jest jakość modelu. Chcemy pracować na możliwie najlepszych rozwiązaniach. Oczywiście nie jest to jedyny wyznacznik, ale to od niego wychodzimy. Jeśli chodzi o genezę współpracy z PLLuM-em, rozpoczęła się ona jeszcze zanim dołączyłem do zespołu. Kierownictwo COI, we współpracy z Ministerstwem Cyfryzacji, zostało zaproszone do oceny modelu tworzonego przez Politechnikę Wrocławską przy wsparciu NASK i pod auspicjami Ministerstwa. Kluczowe pytanie brzmiało bardzo pragmatycznie: czy z tym modelem da się coś realnie zrobić, czy nadaje się on do zastosowań produkcyjnych? Jak już wcześniej wspominałem, modele tworzone przez zespoły badawcze często bardzo dobrze wypadają w benchmarkach, natomiast prawdziwym testem jest ich zachowanie w rzeczywistych systemach. Naturalnym polem do takiej weryfikacji był wirtualny asystent rozwijany przez COI. Oczywiście w tle pojawiały się również kwestie suwerenności technologicznej i otwartości modelu, które są istotne. Z naszego punktu widzenia też kwestia jakości była ważna. Trzeba przy tym powiedzieć, że PLLuM należy do klasy modeli o mniejszej liczbie parametrów niż GPT, Claude czy Gemini, co wiąże się z innymi kompromisami między skalą, kosztami a jakością generowanych odpowiedzi.
Decydując się na pracę z polskim modelem, świadomie utrudniliśmy sobie zadanie. Zrobiliśmy to jednak z określonym cele. Po pierwsze, sprawdzić i udowodnić, że taki model może być „wystarczająco dobry” w realnych zastosowaniach, a po drugie – zbudować kompetencje w pracy z modelami otwartymi. To są inne umiejętności niż korzystanie z gotowych usług komercyjnych.
Dla porównania, uruchomienie chatbota opartego o GPT-5 w środowisku chmurowym jest dziś relatywnie proste i szybkie – można podpiąć bazę wiedzy, wskazać model i w krótkim czasie mieć działające rozwiązanie. My natomiast sprawdzaliśmy, czy da się to zrobić z PLLuM-em, jak go utrzymywać, jak go zabezpieczać, jakie technologie są potrzebne do jego uruchomienia i jak skutecznie przekazywać twórcom informacje zwrotne. Ten cel został osiągnięty. Zweryfikowaliśmy pozytywnie pracę zespołu tworzącego PLLUM i jednocześnie nauczyliśmy się, jak w praktyce pracować z dużym, otwartym modelem językowym. To doświadczenie – nawet jeśli nie zawsze jest najprostsze czy najbardziej efektywne ekonomicznie – buduje kompetencje, które mogą okazać się kluczowe w dłuższej perspektywie.
Jakie wyzwania napotkaliście w trakcie tej współpracy wdrożeniowej przy realizacji rozwiązań opartych na AI?
Jednym z największych wyzwań miało charakter wręcz filozoficzny i dotyczyło samego podejścia do wykorzystania modeli językowych. My podchodzimy do modeli ogólnego zastosowania w ten sposób, że traktujemy je jako uniwersalne narzędzie, któremu można nadać rolę poprzez instrukcję – np. poprosić model, aby „działał jako planer wesela” i na tej podstawie zaplanował cały proces. To podejście jest typowe dla dużych, ogólnych modeli językowych. Natomiast konsorcjum – najpierw PLLUM, później HIVE – prezentowało podejście bardziej charakterystyczne dla mniejszych modeli językowych. Zamiast nadawać modelowi tożsamość i kontekst za pomocą instrukcji systemowych, preferowane było dotrenowywanie modelu pod bardzo konkretne zadania. To podejście ma swoje zalety – pozwala uzyskać model bardzo skuteczny w wąskim zakresie – ale niesie też istotne ograniczenia. Jednym z nich jest klasyczny problem znany z uczenia maszynowego, czyli zmiana dystrybucji danych. Model wyspecjalizowany w jednym obszarze może zacząć radzić sobie gorzej, gdy pojawią się nowe typy zapytań lub nowe źródła wiedzy. Przykładowo: jeśli model został dotrenowany do odpowiadania na pytania dotyczące mObywatela i gov.pl, to pojawia się pytanie, jak poradzi sobie po dodaniu nowego źródła – np. poradnika bezpieczeństwa Ministerstwa Cyfryzacji. Trudno jednoznacznie przewidzieć, czy taki model zachowa wysoką jakość odpowiedzi w nowym kontekście. Drugim istotnym wyzwaniem była aktualność wiedzy. Model wytrenowany na danych z konkretnego momentu czasowego może „przebijać” odpowiedziami opartymi na wiedzy treningowej, która jest już nieaktualna. Z naszej perspektywy kluczowe było to, aby model zawsze opierał się na dostarczonych, aktualnych źródłach wiedzy. Modele ogólnego zastosowania radzą sobie z tym zwykle lepiej, ponieważ ich wiedza bazowa jest bardzo szeroka, ale w przypadku modeli wyspecjalizowanych wymaga to dodatkowych zabezpieczeń. Te różnice w podejściu – między uniwersalnością a specjalizacją – były jednym z głównych wyzwań współpracy. Wymagały ciągłych dyskusji, testów i kompromisów, aby znaleźć rozwiązanie, które z jednej strony zapewni wysoką jakość odpowiedzi, a z drugiej będzie odporne na zmiany, aktualizacje wiedzy i nowe potrzeby użytkowników.
Jakie wnioski z tych wyzwań były dla Was najważniejsze i co dziś zrobilibyście inaczej przy podobnym wdrożeniu?
Doświadczenie otworzyło też drogę do myślenia o innych zastosowaniach AI, niekoniecznie chatbotowych. Przykładowo: streszczanie dokumentów czy odpowiadanie na bardzo wąski typ zapytań może być realizowane nawet przez znacznie mniejsze modele – rzędu kilkunastu, a nawet kilku miliardów parametrów – z bardzo dobrym efektem.
Jeśli chodzi o zastosowania AI wewnątrz COI, największe korzyści widzimy dziś w automatyzacji pracy z dokumentami. Przykładem jest narzędzie, które pilotażowo rozwijamy do poprawy jakości wymagań biznesowych oraz generowania testów manualnych. Proces ten jest dziś w dużej mierze powtarzalny i czasochłonny: wymagania są zapisywane, doprecyzowywane, a następnie na ich podstawie tworzone są testy. Dużą część tej pracy można skutecznie zautomatyzować przy użyciu LLM – nawet relatywnie małych.
Kluczowym wyzwaniem pozostają jednak dane. W wielu procesach operujemy na danych osobowych lub wrażliwych, co wymaga jasnych zasad: gdzie dane mogą być przetwarzane, jakie modele mogą być używane i czy dopuszczalne jest korzystanie z chmury lub zewnętrznych API. Bez spójnej polityki w tym zakresie trudno mówić o bezpiecznym skalowaniu AI w organizacji.
Jeśli chodzi o proces wdrożeniowy, przykład wirtualnego asystenta nie jest do końca reprezentatywny, bo początkowo był projektowany pod model komercyjny i praktycznie gotowy do uruchomienia. Zmiana na PLLUM wymagała jednak przebudowy architektury i dodatkowych prac. W praktyce kluczowe etapy takiego wdrożenia to: szybki wybór modelu i danych, zdefiniowanie wymagań, rozwiązanie kwestii prawnych i dostępności danych, przygotowanie architektury oraz iteracyjne testy jakości i bezpieczeństwa. To proces złożony, ale właśnie dzięki niemu budujemy kompetencje, które pozwalają nam wdrażać AI w sposób świadomy, bezpieczny i skalowalny.
Jak dziś podchodzicie do definiowania wymagań biznesowych dla rozwiązań AI i czym to podejście różni się od klasycznych projektów IT?
Jednym z kluczowych wyzwań we wdrażaniu rozwiązań AI jest precyzyjne zdefiniowanie wymagań biznesowych. W klasycznych systemach informatycznych jest to relatywnie proste, bo można jasno określić, że system działa poprawnie, jeśli użytkownik jest w stanie się zalogować, przejść przez konkretne podstrony i wykonać określone akcje, np. zarezerwować usługę czy sprawdzić swoje dane. W przypadku systemów opartych na AI, a szczególnie chatbotów, takie podejście nie wystarcza. Wymaganie typu „istnieje chatbot, który odpowiada na pytania” nie jest weryfikowalne biznesowo. Nawet stwierdzenie, że „chatbot odpowiada poprawnie na 80% pytań”, rodzi kolejne pytania: jakich pytań, w jakim zakresie i na jakiej podstawie zostały one dobrane?
Dlatego kluczowym etapem na poziomie MVP jest zbudowanie zestawów testowych. Dopiero wtedy możliwe jest sensowne określenie kryteriów jakości – np. gdy chatbot poprawnie odpowiada na określony procent realnych, zaakceptowanych biznesowo pytań. Ten etap wymaga ścisłej współpracy z biznesem: ktoś musi te pytania przeczytać, ocenić ich zasadność i zdecydować, czy rzeczywiście odpowiadają potrzebom użytkowników, a także wskazać ewentualne luki. W sposób iteracyjny dochodzi się do wspólnego rozumienia, czym system AI ma być i jakie cele ma realizować.
Dopiero po takim uzgodnieniu zaczyna się właściwa praca techniczna. Zespół data science pracuje nad promptami, konfiguracją modeli i eksperymentami, dążąc do osiągnięcia założonej jakości odpowiedzi. Równolegle funkcjonują dwa inne, równie istotne strumienie pracy. Pierwszy to inżynieria danych – dane, które na etapie proof of concept mogły być przetwarzane ręcznie, muszą w wersji produkcyjnej być pobierane, przetwarzane i weryfikowane automatycznie. Konieczne są mechanizmy kontroli jakości danych i odporności na błędy, tak aby cała infrastruktura była stabilna i audytowalna. Drugi strumień to MLOps, czyli warstwa infrastrukturalno-utrzymaniowa. Obejmuje ona m.in. wersjonowanie eksperymentów, wystawianie modeli, monitorowanie klasycznych metryk technicznych (zużycie zasobów, obciążenie) oraz metryk specyficznych dla AI, takich jak jakość odpowiedzi na zestawach testowych. Dzięki temu możliwe jest szybkie wykrycie degradacji jakości – np. gdy błąd w danych powoduje nagły spadek skuteczności odpowiedzi.
W idealnym modelu kolejne wersje rozwiązania są regularnie testowane z użytkownikami – choćby wewnętrznymi – i zasilane stałym feedbackiem. To pozwala wcześnie wychwycić problemy, które nie są widoczne w samych metrykach, np. zbyt długie, mało użyteczne odpowiedzi, które formalnie są „poprawne”, ale obniżają doświadczenie użytkownika.
Cały obszar data science znajduje się na styku nauki i praktyki. Nie jest to proces w pełni deterministyczny, dlatego kluczową rolę odgrywają tu product owner i analityk biznesowy – osoby, które rozumieją potrzeby użytkownika i potrafią je przełożyć na wymagania dla systemu AI. Użytkownik często nie wie, czego dokładnie chce ani jakie możliwości daje sztuczna inteligencja. Bez tej warstwy pośredniej rozmowa między czysto technicznym zespołem a biznesem zwykle nie prowadzi do realnej wartości.
To właśnie umiejętne połączenie perspektywy biznesowej, danych i technologii decyduje o sukcesie wdrożeń AI.
Co w praktyce decyduje o tym, czy użytkownik uzna, że „chatbot działa dobrze”?
W praktyce bardzo wyraźnie widać, że bez odpowiednich ról pośrednich komunikacja między technologią a użytkownikiem po prostu nie działa. Byłem na spotkaniach, na których deweloperzy tłumaczyli klientom problemy w kategoriach promptów systemowych, rerankerów czy architektury modeli. Z perspektywy klienta taka rozmowa kończy się zwykle konkluzją: „fajnie, pogadaliśmy”, ale bez realnego zrozumienia problemu.
I właśnie tu pojawia się kluczowa rola analityka biznesowego lub – szerzej – osoby odpowiedzialnej za stronę biznesową AI. Użytkownik mówi: „chatbot odpowiada głupio”. Zadaniem tej osoby nie jest polemizowanie, tylko doprecyzowanie: co to dokładnie znaczy? Jakie pytania nie działają? W jakich sytuacjach? Bardzo często okazuje się, że przyczyna jest prozaiczna – np. brak określonych informacji w bazie wiedzy.
Dlaczego technicznie poprawny chatbot nie zawsze jest chatbotem „dobrym” z perspektywy użytkownika?
Problem w tym, że komunikat „nie ma dokumentów w bazie wiedzy” nic nie mówi użytkownikowi. Trzeba to przełożyć na język zrozumiały biznesowo: korzystamy z określonych źródeł informacji – np. gov.pl, mObywatela, poradników ministerialnych, stron sejmowych – i pytanie, które zadaje użytkownik, nie znajduje się w żadnym z tych źródeł. Wtedy pojawia się realna decyzja biznesowa: czy chcemy, aby asystent odpowiadał również na tego typu pytania? Jeśli tak, to kto jest właścicielem tych danych, czy można je udostępnić i w jakiej formie.
Z perspektywy dewelopera nie zawsze widać skalę trudności takiej decyzji. Dla niego dostęp do danych to często po prostu „kolejna baza” – najlepiej z API, które da się podłączyć w dwa tygodnie. Tymczasem w realiach administracji publicznej uzyskanie dostępu do danych, np. z Ministerstwa Finansów, może być procesem długim, złożonym i obarczonym ryzykiem prawnym. I to właśnie ktoś po stronie biznesowej musi tę złożoność rozumieć i nią zarządzać.
Drugą, często niedocenianą rolą w tego typu projektach są badacze i badaczki. Deweloperzy są zwykle najbardziej widoczni, ale to badania użytkowników pozwalają zrozumieć, jak rozwiązanie jest faktycznie wykorzystywane. Wszyscy mamy naturalną tendencję do słuchania najgłośniejszych głosów – przełożonych, ekspertów, osób podobnych do nas samych. Tymczasem rzeczywisty użytkownik może korzystać z systemu w zupełnie inny sposób, niż zakładaliśmy.
Badacze potrafią przebić się przez ten szum i pokazać, do czego użytkownicy naprawdę używają narzędzia – często w sposób, którego zespoły projektowe by się nie spodziewały. To szczególnie istotne w administracji, gdzie osoby projektujące systemy znają bardzo dobrze usługi cyfrowe państwa, ale nie zawsze reprezentują perspektywę przeciętnego obywatela.
Po przejściu przez ten iteracyjny proces – z udziałem biznesu, technologii i badań – powstaje produkt, który jest akceptowalny dla wszystkich interesariuszy. Dopiero wtedy rozpoczynają się formalne testy: najpierw wewnętrzne, potem zewnętrzne, a następnie standardowy proces wydania oprogramowania. W COI oznacza to również bardzo rozbudowane testy bezpieczeństwa – zarówno klasyczne IT (porty, podatności), jak i specyficzne dla AI. Do tego dochodzą testy wydajnościowe – rozwiązania AI mają wysokie wymagania sprzętowe i trzeba upewnić się, że system nie przeciąży infrastruktury.
Jakie macie plany na przyszłość jako COI w kontekście dalszych wdrożeń AI?
Współpracujemy z kilkoma partnerami instytucjonalnymi m.in. z Ministerstwem Edukacji nad podłączaniem kolejnych publicznych baz wiedzy. Od początku zakładamy, że chatbot działa wyłącznie na danych publicznych, co pozwala nam ominąć wiele problemów związanych z przetwarzaniem danych wewnętrznych czy danych obywateli.
Równolegle rozważamy wykorzystanie chatbota w innych projektach, np. w obszarze węzła krajowego, jak profilu i podpisu zaufanego. W tym przypadku kluczowa byłaby segmentacja baz wiedzy: chatbot na stronie profilu zaufanego odpowiadałby wyłącznie na pytania związane z tym obszarem, a nie na całość zagadnień dostępnych w mObywatelu. Dzięki temu odpowiedzi byłyby bardziej precyzyjne i lepiej dopasowane do kontekstu użytkownika.
Z perspektywy długoterminowej widzimy też duży potencjał normalizacyjny. Skoro potrafimy już budować i utrzymywać chatbota, jego dalszy rozwój polega głównie na podpinaniu nowych źródeł wiedzy i nadawaniu mu kolejnych, jasno zdefiniowanych kompetencji. Jednym z często pojawiających się pomysłów jest np. automatyczne uzupełnianie formularzy. Tutaj jednak barierą nie jest technologia, lecz prawo, jak przetwarzanie danych osobowych, takich jak imię, nazwisko czy PESEL, wymagałoby zmian legislacyjnych. Na dziś są to obszary mocno ograniczone regulacyjnie. Kolejnym kierunkiem są wewnętrzne rozwiązania dokumentowe: streszczanie dokumentów, poprawa jakości treści czy wsparcie w procesach legislacyjnych. To obszary, w których AI może przynieść realną wartość, choć na razie mówimy raczej o planach niż o uruchomionych projektach.
Istotnym elementem naszych rozważań jest także wymiar standaryzacyjny. W ramach koncepcji AI Hub będącej obecnie na etapie pozyskiwania finansowania, chcielibyśmy tworzyć standardy dla modeli, w szczególności modeli agentowych. Chodzi o podejście zgodne z najlepszymi praktykami inżynierii oprogramowania: centralny model decyzyjny, który ma dostęp do zestawu zweryfikowanych narzędzi, danych i źródeł informacji.
W dłuższej perspektywie widzimy tu także rolę repozytorium sprawdzonych wdrożeń, czyli miejsca, w którym samorządy i instytucje mogłyby znaleźć gotowe architektury, opisy rozwiązań, modele i dane opatrzone „pieczątką” COI lub Ministerstwa Cyfryzacji. Dzięki temu mniejsze jednostki nie musiałyby budować wszystkiego od zera.
To ważne, bo dziś naturalną konsekwencją różnic budżetowych jest to, że największe miasta mogą sobie pozwolić na najlepsze rozwiązania, a mniejsze – niekoniecznie. W idealnym modelu duże instytucje budują rozwiązania referencyjne, a mniejsze mogą z nich korzystać i rozwijać je lokalnie. Co więcej, doświadczenie pokazuje, że w samorządach, także w mniejszych ośrodkach, pracują ludzie z bardzo dobrymi pomysłami na zastosowanie AI w konkretnych, lokalnych problemach.
Umożliwienie współdzielenia rozwiązań i wiedzy to nie tylko kwestia efektywności, ale też budowania atrakcyjności regionów. Możliwość pracy przy nowoczesnych, ogólnopolskich projektach AI może być realnym argumentem przyciągającym kompetentnych ludzi także poza największe ośrodki. To długofalowo wzmacnia zarówno administrację, jak i rozwój regionalny. Myślimy o wykorzystaniu niewielkiego modelu wizyjnego – rzędu 7 miliardów parametrów. Do jego uruchomienia wystarczyłaby stosunkowo prosta infrastruktura, np. maszyna za około 20–25 tysięcy złotych. To nie są ogromne koszty, ale jednocześnie na tyle znaczące, że w realiach administracji publicznej trudno je ponosić bez jasnego uzasadnienia i gwarancji wykorzystania. Działamy jednak w określonym kontekście organizacyjnym i politycznym – trudno oczekiwać, że np. wójt gminy zdecyduje się na zakup takiego sprzętu, jeśli nie ma pewności, że rozwiązanie będzie realnie używane i przyniesie konkretne korzyści. Dlatego kluczowe jest tworzenie rozwiązań wspólnych, sprawdzonych i możliwych do ponownego wykorzystania, które minimalizują ryzyko takich inwestycji po stronie mniejszych jednostek.
Na koniec chciałbym zapytać, co Twoim zdaniem najbardziej przyspieszyło wykorzystanie i wdrażanie polskich modeli językowych w biznesie. Czy kluczową rolę odegrała edukacja, regulacje, czy raczej rosnąca dostępność dojrzałych rozwiązań na rynku?
Z mojej perspektywy kluczowa jest przede wszystkim dostępność, choć nie jest to jedyny czynnik. Patrząc od strony biznesowej, sytuacja w Polsce nie wygląda źle. Widać dużą aktywność wokół polskich modeli, chociażby Bielika, także w relacjach z biznesem. Inicjatywy takie jak współpraca ze spółkami komercyjnymi czy obecność w międzynarodowych gremiach pokazują, że te modele zaczynają funkcjonować w realnym obiegu rynkowym i przynajmniej skłaniają firmy do refleksji: „czy w tym projekcie nie warto rozważyć polskiego modelu?”.
Jednocześnie trzeba uczciwie powiedzieć, że o wyborze modelu bardzo często decyduje jego jakość i łatwość użycia. Jeśli firma np. sieć handlowa chce wdrożyć chatbota do obsługi klienta, to w wielu przypadkach wybierze model komercyjny, bo będzie on po prostu lepszy jakościowo
i łatwiejszy do uruchomienia. Postawienie polskiego modelu wiąże się z dodatkowymi kosztami infrastruktury, kompetencjami technicznymi i większym nakładem pracy, a efekt końcowy może być słabszy. Dużą rolę odgrywa tu również niepewność regulacyjna. Zarówno w sektorze publicznym, jak i w biznesie, wiele organizacji po prostu nie wie, z jakich modeli może korzystać przy pracy z określonymi danymi. Gdyby istniały jasne zasady np. że określone typy danych muszą być przetwarzane wyłącznie przez modele europejskie lub krajowe, decyzje byłyby znacznie prostsze.
W sektorze publicznym te bariery są jeszcze silniejsze. Z jednej strony mamy regulacje, które bardzo ograniczają pole manewru, a z drugiej strony jest to brak infrastruktury i kompetencji. W COI nie stanowi problemu uruchomienie własnego modelu, ale przeciętny urząd miasta często nie ma nawet sprzętu z odpowiednią kartą graficzną, a jeśli już ma, to niekoniecznie wie, jak taki model utrzymać. Oczywiście zdarzają się wyjątki, pasjonaci, którzy potrafią to zrobić oddolnie, ale to nie jest rozwiązanie skalowalne.
Dlatego realnym przyspieszeniem dla adopcji polskich modeli byłaby centralna dostępność tych rozwiązań jako usługi. Gdyby jednostki publiczne mogły korzystać z polskich modeli, takich jak Bielik czy PLLuM przez API, po prostym procesie zgłoszeniowym, bariera wejścia drastycznie by się obniżyła. Zamiast kupować sprzęt, budować infrastrukturę i mierzyć się z listą wymagań technicznych, instytucja mogłaby skupić się na realnym zastosowaniu. Podsumowując: edukacja jest ważna, regulacje są kluczowe, ale to dostępność w praktycznym, operacyjnym sensie, łatwy dostęp do modeli, infrastruktury i standardów, najbardziej przyspieszyłaby wykorzystanie polskich modeli językowych zarówno w biznesie, jak i w administracji publicznej.
