Po co firmie modele językowe i kto powinien się nimi interesować
Najważniejsze zastosowania modeli językowych w biznesie
Modele językowe AI przestają być gadżetem z mediów, a stają się normalnym narzędziem pracy – trochę jak kiedyś pakiet biurowy. Dobrze wdrożone potrafią zaoszczędzić dziesiątki godzin miesięcznie w różnych działach, ale tylko wtedy, gdy korzystanie z nich jest bezpieczne i ułożone procesowo.
Najczęstsze, realne zastosowania w firmach to przede wszystkim:
Obsługa klienta – asystenci czatu, podpowiedzi odpowiedzi dla konsultantów, klasyfikacja zgłoszeń, streszczenia korespondencji. Model może np. sortować maile na reklamacje, pytania sprzedażowe, sprawy pilne, tworzyć szkice odpowiedzi i wyszukiwać informacje w bazie wiedzy.
Wsparcie programistów – podpowiedzi kodu, refaktoryzacja, generowanie testów jednostkowych, konwersja pseudokodu na kod, automatyczne opisy pull requestów. Dobrze skonfigurowane narzędzie potrafi skrócić czas żmudnych zadań i zmniejszyć liczbę błędów.
Tworzenie i edycja treści – szkice ofert, artykułów, maili, raportów, prezentacji, scenariuszy rozmów handlowych. Model nie zastąpi strategii, ale zrobi za ludzi „pierwszą wersję”, którą zespół tylko dopracuje.
Praca z dokumentami – streszczenia umów, wyciągi z regulaminów, porównanie dwóch wersji dokumentu, tworzenie listy ryzyk lub obowiązków. Przy dużej liczbie plików to często jedyny sposób, by w ogóle nad tym zapanować.
Analityka tekstowa – analiza opinii klientów, klasyfikacja zgłoszeń, ekstrakcja danych z nieustrukturyzowanych dokumentów (np. opisy szkód, notatki serwisowe), generowanie podsumowań spotkań.
Zastosowania biznesowe rosną wraz z tym, jak organizacja oswaja się z narzędziem. Zwykle zaczyna się od prostych promptów w stylu „skrót tego tekstu”, a kończy na integracji modeli językowych z CRM, systemami ticketowymi czy wewnętrzną wyszukiwarką.
Dlaczego temat dotyczy całej organizacji, nie tylko IT
Bezpieczne korzystanie z AI w firmie to nie jest projekt „wrzućmy ChatGPT na Slacka i będzie cool”. To zmiana, która dotyka:
IT i bezpieczeństwa – wybór dostawcy, architektury, integracji, kontroli dostępu, monitorowanie nadużyć i wycieków danych.
Biznesu (sprzedaż, marketing, operacje) – definiowanie przypadków użycia, mierzenie efektów, ocena wpływu na procesy i KPI.
Działu prawnego i compliance – zgodność z RODO, NDA, regulacjami branżowymi, umowami z partnerami, a także z wewnętrznymi politykami.
HR i szkoleń – edukacja pracowników, zasady użycia w procesach HR, np. rekrutacji czy ocen rocznych.
Zarządu – decyzje strategiczne: gdzie AI wykorzystać w pierwszej kolejności, jaki apetyt na ryzyko firma dopuszcza, jak zmieni się model pracy.
Jeśli modele językowe pojawiają się w firmie oddolnie i bez kontroli (pracownicy sami zakładają konta, używają darmowych wersji w przeglądarce), dział IT i bezpieczeństwa dowiaduje się o tym zazwyczaj jako ostatni. Wtedy jest już po fakcie – dane mogły dawno wylądować u zewnętrznego dostawcy, bez jakiejkolwiek umowy i nadzoru.
Znacznie rozsądniej jest założyć, że ludzie i tak będą testować AI, i z wyprzedzeniem dać im bezpieczną alternatywę: firmowy dostęp, szkolenia, jasne zasady. Inaczej „shadow AI” będzie kwitło tak samo jak kiedyś „shadow IT”.
Od „pobawimy się ChatGPT” do strategicznego wdrożenia
Modele językowe łatwo lekceważyć, bo mają przyjazny interfejs. Wpisuje się zdanie, pojawia się odpowiedź – żadnych skomplikowanych formularzy czy integracji. I właśnie w tym tkwi ryzyko. Narzędzie, które wygląda jak zabawka, może w kilka sekund przejąć fragmenty tajemnicy przedsiębiorstwa, jeśli użytkownik wklei tam zbyt wiele.
Różnica między spontanicznym „pobawimy się” a wdrożeniem strategicznym sprowadza się przede wszystkim do trzech rzeczy:
Świadomie wybrane przypadki użycia – zdefiniowane procesy, w których AI ma pomagać, z określonym zakresem danych i oczekiwanym efektem.
Bezpieczna architektura – kontrola nad tym, gdzie i jak przetwarzane są dane, kto ma dostęp, jakie logi są zbierane, jak wygląda backup i usuwanie danych.
Polityka i szkolenia – jasne zasady, przykłady dopuszczalnych i zakazanych działań, minimalny poziom świadomości u pracowników.
Lekki ton interfejsu (okienko czatu) nie zwalnia z ciężkich decyzji architektonicznych i prawnych. W dojrzałych organizacjach modele językowe traktuje się jak inne krytyczne systemy IT – z analizą ryzyka, przeglądem umów i nadzorem.
Krótki przykład: chaos kontra kontrolowany pilotaż
W jednej z firm usługowych pracownicy sprzedaży zaczęli korzystać z publicznego narzędzia AI do pisania ofert. Skopiowali kilka starszych dokumentów z wrażliwymi danymi klientów „jako przykład” i poprosili model o stworzenie nowej wersji. Nikt nie zadał sobie pytania, gdzie trafiają te dane, na jakich zasadach są przetwarzane i czy pokrywa się to z zapisami w NDA. Dział prawny dowiedział się o sprawie dopiero wtedy, gdy klient zadał proste pytanie: „Czy nasze dane były kiedykolwiek używane do trenowania zewnętrznych modeli AI?”.
W innej firmie, podobnej wielkości, IT zainicjowało pilotaż: wydzielona, firmowa przestrzeń, ograniczone przypadki użycia, warsztaty z działami biznesowymi, instrukcja „co wolno wkleić, a czego nie”. Na początku było trochę narzekania („znowu procedury”), ale kilka miesięcy później AI była już częścią kilku procesów, a zespół bezpieczeństwa miał realny wgląd, co się dzieje. Tak czy inaczej, pracownicy i tak używają modeli językowych – pytanie tylko, czy organizacja woli chaos czy sterowany eksperyment.
Źródło: Pexels | Autor: Yan Krukau
Jak działają modele językowe – skrót dla osób nietechnicznych
Czym model językowy różni się od wyszukiwarki
Na pierwszy rzut oka model językowy wygląda jak wyszukiwarka: wpisuje się tekst i dostaje tekst. Pod spodem jednak dzieje się coś innego. Wyszukiwarka przeszukuje indeks stron i zwraca linki lub fragmenty istniejących dokumentów. Model językowy nie szuka gotowej odpowiedzi – on ją generuje.
Można to porównać do różnicy między bibliotekarzem a pisarzem. Wyszukiwarka jest bibliotekarzem: pokaże książkę, w której ktoś już coś napisał. Model językowy jest pisarzem, który ma w głowie ogromny zasób wzorców językowych z przeczytanych wcześniej książek i na ich podstawie pisze nowy tekst. Problem w tym, że pisarz czasem konfabuluję – i w ogóle nie czuje się z tym głupio.
Dane treningowe, kontekst, prompt i tokeny – w ludzkim języku
Model językowy uczy się na danych treningowych – ogromnych zbiorach tekstów: stronach internetowych, książkach, kodzie, dokumentacji, artykułach. W trakcie treningu uczy się statystycznych zależności: jakie słowa występują razem, jakie zdania są typowe dla określonych sytuacji, jak wygląda kod w danym języku.
Prompt to twoje polecenie – tekst, który wpisujesz: pytanie, instrukcja, fragment dokumentu. Do promptu model dokleja jeszcze tzw. kontekst – inne informacje z rozmowy lub systemowe wytyczne, np. „odpowiadaj po polsku, bądź zwięzły”. Na tej podstawie generuje kolejne słowa.
Tokeny to małe kawałki tekstu, z których model składa wypowiedź. To nie zawsze całe słowa – czasem sylaby lub fragmenty wyrazów. Dostawcy modeli zwykle liczą zużycie w tokenach, bo to najbliższe temu, jak modele działają wewnętrznie. Dla użytkownika wystarczy świadomość, że im dłuższy prompt i odpowiedź, tym więcej zużytych tokenów, czyli większe koszty (przy modelach płatnych).
Dlaczego modele „halucynują” i mówią bzdury z wielką pewnością
Model językowy nie ma pojęcia, co jest prawdą, a co fałszem. Nie ma też wewnętrznego kompasu „nie wiem, więc nie odpowiem”. Jego zadaniem jest kontynuować tekst tak, by brzmiał spójnie na podstawie wzorców z treningu i zadanego kontekstu. Jeśli w danych treningowych widział wiele artykułów, które zaczynały się od „Badania pokazują, że…”, nauczył się po prostu jak wygląda typowy ciąg dalszy takich zdań.
„Halucynacje” to sytuacje, gdy model generuje informacje, które wyglądają bardzo wiarygodnie, ale są kompletnie zmyślone: nieistniejące przepisy prawa, nieprawdziwe cytaty z dokumentów, wymyślone referencje. Model nie ma złej woli – po prostu dopasowuje statystycznie „najbardziej pasujący” ciąg słów do kontekstu.
Dla biznesu oznacza to konkretną konsekwencję: odpowiedź AI jest wstępną propozycją, nie ostatecznym źródłem prawdy. W wielu zastosowaniach (analiza pomysłów, szkice, podsumowania) to nie problem. W obszarach regulowanych (prawo, medycyna, finanse) to już poważne ryzyko, jeśli ktoś bezrefleksyjnie przepisze wynik AI do dokumentu wysyłanego klientowi lub regulatorowi.
Model nie ma intencji ani świadomości – co to zmienia
Modele językowe nie „chcą” nikogo oszukać ani „starać się” być miłe. Nie mają też poczucia odpowiedzialności. To zaawansowana funkcja autouzupełniania tekstu, a nie cyfrowy pracownik. Decyzje, interpretacje, odpowiedzialność pozostają po stronie człowieka lub organizacji, która narzędzie wdraża.
Dla działów IT i biznesu oznacza to, że nie można cedować odpowiedzialności na AI. Jeśli system wygeneruje dyskryminującą odpowiedź dla kandydata w procesie rekrutacyjnym, regulator będzie rozmawiał z firmą, a nie z modelem. Jeżeli model przygotuje błędne podsumowanie interpretacji podatkowej, to księgowość i tak ponosi konsekwencje.
Kluczowe ryzyka biznesowe i prawne związane z modelami językowymi
Ujawnienie danych wrażliwych i tajemnicy przedsiębiorstwa
Najbardziej oczywiste, a jednocześnie najczęściej ignorowane ryzyko to wrzucanie do modelu językowego tego, co nie powinno opuścić firmowych serwerów. Przy braku jasnych zasad pracownicy zwykle chcą „tylko przyspieszyć sobie pracę”, więc wklejają:
dane klientów: imię, nazwisko, adres e-mail, numer zamówienia, opis sprawy, czasem także PESEL czy dane finansowe,
dane pracowników: informacje z rozmów HR, opisy konfliktów, wynagrodzenia,
informacje handlowe: marże, warunki rabatowe, plany cenowe,
know-how i tajemnice techniczne: fragmenty kodu, architektury systemów, plany rozwoju produktu.
Jeśli dzieje się to przez publiczny interfejs modelu językowego, bez umowy i bez gwarancji co do sposobu przetwarzania danych, może to być naruszenie RODO, NDA lub przepisów o tajemnicy przedsiębiorstwa. Nawet jeśli dostawca obiecuje, że „nie trenuje na danych użytkowników”, to i tak dochodzi do przekazania danych do zewnętrznego podmiotu – co wymaga podstawy prawnej, umowy powierzenia i często dodatkowych zabezpieczeń.
Ryzyka prawne: RODO, NDA, prawa autorskie
Z perspektywy regulacyjnej generatywna AI dotyka kilku obszarów naraz:
RODO – jeśli do modelu trafiają dane osobowe, musi być określony cel przetwarzania, podstawa prawna, okres retencji, sposób realizacji praw osoby (dostęp, usunięcie, sprzeciw). Przy korzystaniu z AI jako usługi (SaaS, API) trzeba ocenić, czy dostawca jest procesorem danych i zawrzeć umowę powierzenia.
Tajemnica przedsiębiorstwa i NDA – wysyłanie fragmentów umów, poufnych ustaleń, parametrów finansowych do zewnętrznych modeli może być naruszeniem zobowiązań wobec kontrahentów. Część umów wprost zakazuje przetwarzania danych u niezidentyfikowanych podwykonawców.
Prawa autorskie – generowane treści mogą naśladować styl konkretnego autora, zawierać fragmenty podobne do istniejących utworów, a także mieszać treści objęte różnymi licencjami. W efekcie trudno jednoznacznie orzec, jaki jest status prawny wygenerowanego tekstu czy obrazu i czy nie narusza on cudzych praw.
W tle pojawiają się też wymagania nowych regulacji dotyczących AI w UE, w tym obowiązki informacyjne wobec użytkowników i klientów, transparentność, a także ograniczenia w niektórych zastosowaniach wysokiego ryzyka.
To podejście jest zresztą spójne z trendami regulacyjnymi w UE – także w kontekście tego, jak opisywane jest Informatyka, Nowe technologie, AI w przestrzeni publicznej: narzędzie może być zaawansowane, ale odpowiedzialny zawsze jest podmiot, który je stosuje.
Ryzyko reputacyjne: treści niedozwolone, dyskryminacja, plagiat
Ryzyko reputacyjne: treści niedozwolone, dyskryminacja, plagiat (cd.)
Dla działów biznesowych problem nie kończy się na tym, że „model czasem się myli”. Znacznie bardziej bolesne są sytuacje, gdy AI generuje treści sprzeczne z wartościami firmy lub przepisami. Kilka typowych scenariuszy powtarza się w różnych organizacjach:
treści dyskryminujące – np. sugestie, że ktoś „nie nadaje się do roli menedżera” ze względu na wiek czy płeć,
język wrogi lub obraźliwy – szczególnie gdy model ma zbyt luźne ustawienia filtrów treści,
plagiat lub zbyt wierne „inspirowanie się” – marketing prosi o „tekst jak na blogu X”, a model generuje fragmenty bardzo podobne do oryginału.
Jeśli takie treści wyjdą na zewnątrz – np. w mailu do klienta, w ofercie przetargowej, na stronie WWW – problemem nie jest już tylko jakość, ale także potencjalne roszczenia, kryzys w social media i pytania od regulatora lub partnerów. Nawet jeśli wewnętrznie wszyscy wiedzą, że „to tylko AI”, świat zewnętrzny będzie patrzył na logo firmy pod wygenerowanym tekstem, nie na okienko chatu.
Dlatego w procesach zewnętrznych AI powinna działać raczej jako asystent w tle, a nie automatyczny generator komunikacji. Tam, gdzie nie da się tego uniknąć (np. chatbot samoobsługowy), konieczne są testy, monitoring i szybka ścieżka „panic button” – wyłączenia lub ograniczenia działania, gdy coś pójdzie nie tak.
Ryzyko operacyjne: nadmierne zaufanie i „shadow AI”
Gdy model zaczyna dobrze odpowiadać, ludzie szybko przestają się zastanawiać, kiedy mu ufać. Z czasem powstają dwa skrajne obozy: entuzjaści, którzy chcą „wszystko przez AI”, i sceptycy, którzy blokują każde użycie, bo „to niebezpieczne”. Oba podejścia są ryzykowne.
Nadmierne zaufanie prowadzi do włączania AI w procesy, gdzie wymagana jest wysoka przewidywalność lub zgodność z regulacjami, bez uprzedniego przeprojektowania procedur. Z kolei całkowita blokada powoduje rozwój shadow AI – pracownicy korzystają z prywatnych kont w zewnętrznych usługach, kopiują dane, robią screeny systemów i wklejają do darmowych chatbotów. Z perspektywy bezpieczeństwa to koszmar.
Techniczne blokady bez równoległego programu edukacji i legalnych alternatyw zwykle prowadzą do tego, że kreatywniejsi pracownicy i tak obejdą ograniczenia. Dlatego lepiej zaprojektować kontrolowany sposób korzystania niż udawać, że problem nas nie dotyczy.
Źródło: Pexels | Autor: Thirdman
Co można, a czego nie można wysyłać do modelu językowego
Prosty podział: dane publiczne, wewnętrzne, poufne
Zamiast zawiłych definicji prawnych przydaje się prosty model trzech szuflad:
Dane publiczne – wszystko, co już dziś jest lub może być dostępne publicznie bez szkody dla firmy: treści ze strony WWW, opisy produktów, instrukcje użytkownika, ogólne informacje branżowe.
Dane wewnętrzne (niepoufne) – informacje, których nie publikujecie, ale których wyciek nie zrujnuje firmy: procedury operacyjne, ogólne raporty, opisy procesów bez wrażliwych szczegółów.
Dane poufne/wrażliwe – dane osobowe, tajemnice przedsiębiorstwa, dane finansowe, dane o bezpieczeństwie systemów, plany strategiczne, informacje objęte NDA.
W uproszczeniu: dane publiczne są najmniejszym problemem, poufne – największym. Spór toczy się zwykle o środkową szufladę. Dlatego polityka korzystania z AI powinna jasno określać, które kategorie danych można wysyłać do jakiej klasy narzędzi (publiczny model, model zarządzany przez firmę, model on-prem).
Czego nie wklejać nigdy do publicznego modelu (bez twardych umów)
Jeśli organizacja korzysta z publicznych interfejsów (np. ogólnodostępnej strony dostawcy) bez indywidualnej umowy i konfiguracji prywatnej przestrzeni danych, sensowne jest przyjęcie zasady „zero zaskoczeń”. Do takich narzędzi nie powinny trafiać:
dane osobowe w formie identyfikowalnej – imiona, nazwiska, adresy e-mail w połączeniu z kontekstem, który pozwala zidentyfikować osobę,
szczegółowe dane finansowe – marże, warunki cenowe, raporty kosztowe, bilanse,
informacje o bezpieczeństwie – konfiguracje firewalli, szczegóły luk w systemie, plany audytów bezpieczeństwa,
krytyczne fragmenty kodu i architektury, jeśli nie ma wyraźnej zgody zespołu bezpieczeństwa i architektów.
Jeżeli trzeba omówić konkretny przypadek z AI, bezpieczniejszym podejściem jest anonimizacja i pseudonimizacja: usunięcie danych identyfikujących osoby i podmioty, zastąpienie ich neutralnymi labelami (np. „Klient A”, „Pracownik X”), uproszczenie kwot i parametrów technicznych.
Jak projektować prompty z danymi – praktyczne zasady
Nawet w bezpiecznym środowisku wewnętrznym warto wyrobić u użytkowników kilka nawyków:
Minimalizacja danych – model nie musi znać całej historii klienta, żeby pomóc w napisaniu odpowiedzi na jedno konkretne pytanie. Im mniej danych, tym mniejsze ryzyko.
Separacja opisów od identyfikatorów – zamiast „Jan Kowalski, który ma kredyt hipoteczny nr 1234…”, lepiej „Klient, który ma kredyt hipoteczny z następującymi parametrami…”.
Podział złożonego zadania – można najpierw poprosić AI o opracowanie ogólnego schematu odpowiedzi, a dopiero później samodzielnie uzupełnić go o szczegółowe dane, już bez pośrednictwa modelu.
Szablony promptów – przygotowane przez firmę wzory pytań (np. dla obsługi klienta, HR, marketingu) zmniejszają szansę, że ktoś „dla wygody” wklei cały eksport z CRM.
Dobrym krokiem jest też prosty „checklist” przed wysłaniem promptu: „Czy są tu dane osobowe? Czy są tu informacje, których nie chciałbym zobaczyć w mediach? Czy mogę to wytłumaczyć audytorowi?”. To nie jest przesada – to higiena pracy z narzędziem, które potencjalnie komunikuje się z chmurą poza firmą.
Kiedy model może zobaczyć dane osobowe
W praktyce trudno całkowicie wyeliminować dane osobowe z pracy z AI. W procesach typu HR, obsługa klienta, helpdesk czy compliance pojawiają się one naturalnie. Kluczowe jest zdefiniowanie warunków, w których ich przetwarzanie przez model jest dopuszczalne:
model działa w kontrolowanym środowisku (np. dedykowana instancja w chmurze lub on-prem),
istnieje umowa powierzenia przetwarzania z dostawcą, uwzględniająca specyfikę AI,
dane są przetwarzane zgodnie z zasadą minimalizacji – tylko to, co potrzebne do zadania,
organizacja wie, gdzie fizycznie są przechowywane dane (lokacja data center, transfery poza EOG),
można zrealizować prawa osób (dostęp, usunięcie), co w kontekście logów i historii rozmów bywa wyzwaniem technicznym.
Dla działu IT oznacza to konieczność bardzo konkretnych pytań do dostawcy, a dla działu prawnego – aktualizację rejestru czynności przetwarzania i polityk prywatności. „Wrzućmy do AI, będzie szybciej” przestaje być niewinną propozycją, gdy w grę wchodzą dane klientów i pracowników.
Wybór dostawcy i architektury: chmura, on-prem, open source
Kluczowe kryteria wyboru z perspektywy IT i biznesu
Rozmowy o dostawcach często zaczynają się od pytania „który model jest mądrzejszy?”. Tymczasem dla firmy bardziej istotne są inne parametry:
bezpieczeństwo i zgodność – lokalizacja danych, certyfikaty (ISO 27001, SOC 2), mechanizmy szyfrowania, logowanie dostępu, zgodność z RODO i regulacjami branżowymi,
kontrola nad danymi – czy dane z promptów mogą być użyte do trenowania modeli, czy można je usunąć, jak długo są przechowywane logi,
jakość i stabilność API – SLA, limity, opóźnienia, dostępność wsparcia technicznego,
koszty i skalowalność – model rozliczeń (per token, per użytkownik, subskrypcja), możliwość przewidywania kosztów przy dużej skali użycia,
możliwość dostosowania – fine-tuning, RAG (Retrieval Augmented Generation), integracja z wewnętrznymi źródłami danych,
lock-in – jak trudno będzie zmienić dostawcę za rok lub dwa; czy architektura zakłada możliwość podmiany modelu pod spodem.
Biznes będzie patrzył na efekty (jakość odpowiedzi, oszczędność czasu, wygoda użytkowania). IT – na integracje, bezpieczeństwo i przyszłą utrzymalność. Dobry wybór to zwykle kompromis między tymi dwoma perspektywami, a nie „najlepszy model w benchmarkach na Twitterze”.
Modele w chmurze zarządzanej przez dostawcę
To najpopularniejsza opcja: firma korzysta z API lub panelu webowego dostarczanego przez zewnętrzną organizację. Korzyści są oczywiste:
brak konieczności utrzymywania własnej infrastruktury GPU,
dostęp do najnowszych wersji modeli bez angażowania zespołu data science,
szybkie uruchamianie pilotaży i POC-ów.
Z drugiej strony pojawiają się pytania o lokalizację danych, powiernictwo oraz uzależnienie od jednego dostawcy. Przy tej opcji często sensowne jest zastosowanie architektury, w której:
do zewnętrznego modelu wysyłane są tylko dane niepoufne lub silnie przetworzone,
dane wrażliwe są przetwarzane przez dodatkową warstwę w firmie (np. wewnętrzny system wyszukiwania, anonimizator),
interfejs użytkownika jest firmowy, a dostawca widzi tylko to, co absolutnie konieczne.
Takie podejście wymaga więcej pracy integracyjnej, ale pozwala uniknąć sytuacji, w której każdy pracownik loguje się gdzie chce i wysyła tam, co chce.
Modele on-premise i w prywatnej chmurze
Dla organizacji z sektora finansowego, publicznego czy branż silnie regulowanych często jedyną akceptowalną opcją jest utrzymywanie modeli „u siebie”. To może oznaczać:
klastry GPU w lokalnym data center, na których uruchamiane są modele open source,
prywatną chmurę (np. w modelu IaaS), gdzie kontrola nad infrastrukturą jest po stronie firmy lub zaufanego dostawcy infrastruktury, a modele są zarządzane przez wewnętrzny zespół.
Zaletą jest pełniejsza kontrola nad danymi i środowiskiem, łatwiejsze spełnienie wymogów bezpieczeństwa oraz możliwość głębszego dostosowania rozwiązań do własnych potrzeb. Wady są również konkretne: potrzebny jest zespół z kompetencjami w zakresie MLOps, infrastruktury GPU, monitoringu modeli i ich aktualizacji. Dla wielu firm to zupełnie nowy świat.
W praktyce często sprawdza się podejście hybrydowe: na zewnątrz trafiają zadania niskiego ryzyka (np. generowanie treści marketingowych), a w newralgicznych procesach wykorzystuje się wewnętrzną instancję modelu lub nawet prostsze, klasyczne algorytmy, tam gdzie generatywna AI nie jest konieczna.
Modele open source – wolność z obowiązkami
Modele open source (LLaMA, Mistral, itp.) kuszą elastycznością i brakiem opłat licencyjnych w klasycznym rozumieniu. Dają także większą przejrzystość – można samodzielnie kontrolować, co dzieje się z danymi. Z drugiej strony:
trzeba samodzielnie zadbać o bezpieczeństwo infrastruktury,
odpowiedzialność za jakość i poprawki spada na zespół wewnętrzny (lub partnera integracyjnego),
licencje niektórych modeli open source zawierają ograniczenia komercyjne – tu konieczne jest wsparcie prawne.
Dobrym kompromisem może być skorzystanie z rozwiązań dostawców, którzy oferują zarządzane środowiska dla modeli open source (tzw. Model-as-a-Service), ale z możliwością hostowania ich w obrębie infrastruktury spełniającej wymagania firmy. Wtedy IT nie musi ręcznie kompilować bibliotek CUDA w piątek po 17:00, a biznes dostaje elastyczne narzędzie.
Multi-model i warstwa orkiestracji
Coraz częściej strategia AI w większych organizacjach nie zakłada jednego „modelu od wszystkiego”, ale portfel modeli obsługiwanych przez warstwę pośrednią (tzw. orkiestracja lub „AI gateway”). Taka architektura pozwala:
Korzyści z podejścia multi-model
Warstwa orkiestracji działa jak „router” dla zapytań do AI. Zamiast wiązać się na sztywno z jednym dostawcą, organizacja może dynamicznie dobierać model do zadania. Daje to kilka praktycznych korzyści:
optymalizacja kosztów – proste zadania (np. klasyfikacja ticketów, tagowanie treści) mogą trafić do tańszego, mniejszego modelu, a tylko krytyczne lub bardzo złożone – do najdroższych modeli premium,
dopasowanie do języka i domeny – jeden model lepiej radzi sobie z polskim prawem, inny z kodem, a jeszcze inny z marketingowym „storytellingiem”,
redukcja ryzyka vendor lock-in – zmiana dostawcy w warstwie poniżej gatewaya nie wymaga przebudowy wszystkich aplikacji,
lepsza zgodność regulacyjna – zapytania zawierające dane wrażliwe mogą być z definicji kierowane tylko do modeli hostowanych w określonej lokalizacji lub środowisku on-prem.
W dojrzałym podejściu pojawiają się też mechanizmy typu A/B testy modeli, automatyczny fallback (gdy główny dostawca ma awarię) czy dynamiczne przełączanie na podstawie bieżących opóźnień i jakości odpowiedzi. Brzmi jak science fiction, ale w dużych organizacjach to często jedyny sposób, żeby AI nie stało się „wąskim gardłem” procesów.
Elementy techniczne warstwy orkiestracji
Za samym pojęciem „AI gateway” kryje się kilka bardzo przyziemnych komponentów, które dział IT może potraktować jak zwykłą platformę integracyjną:
ujednolicony API – aplikacje w firmie „rozmawiają” z jednym endpointem, niezależnie od tego, czy pod spodem jest model chmurowy, on-prem czy open source,
centralne logowanie i audyt – możliwość odtworzenia, kto wysłał jakie zapytanie, do którego modelu i co model odpowiedział; to później ratuje skórę przy audycie lub incydencie bezpieczeństwa,
polityki routingu – reguły: „jeśli zapytanie pochodzi z działu X i zawiera typ danych Y, użyj modelu Z”,
wspólne moduły bezpieczeństwa – anonimizacja, filtrowanie treści zabronionych, maskowanie danych osobowych, zanim trafią do zewnętrznego API,
warstwa RAG – wspólny mechanizm podpinania firmowej wiedzy (bazy wiedzy, repozytoria dokumentów) do wielu modeli, zamiast implementowania tego osobno w każdym projekcie.
Część firm buduje taką warstwę samodzielnie, inne korzystają z gotowych rozwiązań komercyjnych lub open source. Niezależnie od wyboru narzędzia warto potraktować gateway nie jako „ładny dodatek”, ale jako centralny element architektury AI, który będzie rósł razem z kolejnymi zastosowaniami.
Źródło: Pexels | Autor: MART PRODUCTION
Polityka korzystania z modeli językowych w firmie – co powinna zawierać
Dlaczego formalna polityka jest konieczna
Modele językowe w organizacji bez polityki przypominają prywatne pendrive’y sprzed kilkunastu lat: wszyscy używają, każdy po swojemu, bezpieczeństwo na słowo honoru. Polityka nie jest po to, żeby utrudnić życie pracownikom, tylko żeby:
jasno określić, kiedy i do czego wolno używać AI,
ograniczyć ryzyko wycieku danych i naruszeń RODO,
wyznaczyć granice odpowiedzialności: kto zatwierdza użycie AI w danym procesie, kto nadzoruje treści,
dać pracownikom bezpieczną ścieżkę eksperymentowania, zamiast zmuszać ich do „partyzantki” na publicznych narzędziach.
Minimalny zakres polityki AI
Dobrze napisana polityka jest zrozumiała dla osób spoza IT i prawa. Nie musi mieć 60 stron, ale powinna obejmować kilka kluczowych obszarów.
1. Zakres stosowania i definicje
Na początek przydaje się jasne określenie, czego dotyczą zasady:
jakie narzędzia i typy modeli są objęte polityką (modele zewnętrzne, wewnętrzne chatboty, wtyczki AI w pakietach biurowych),
które działy i role mogą korzystać z danych rozwiązań (np. pilotaż tylko w wybranych zespołach),
ogólne definicje: co oznacza „dane wrażliwe”, „dane strategiczne”, „informacja publiczna” w kontekście firmy.
2. Dozwolone i zabronione zastosowania
Lista zakazów bez pozytywnych przykładów kończy się tym, że pracownicy i tak robią swoje, tylko po cichu. Przejrzysta polityka rozróżnia trzy kategorie:
zastosowania dozwolone – np. tworzenie zarysów prezentacji, tłumaczenia wewnętrznych materiałów, generowanie kodu pomocniczego,
zastosowania wymagające zgody (np. dyrektora jednostki + IT + prawnego) – np. automatyczne generowanie odpowiedzi do klientów, wsparcie przy analizie dokumentów prawnych,
zastosowania zabronione – np. decyzje kadrowe oparte wyłącznie na ocenie modelu, wprowadzanie do modelu danych medycznych lub informacji objętych tajemnicą zawodową (w zależności od branży).
Dobrą praktyką jest stworzenie kilku krótkich, praktycznych scenariuszy: „Jeśli chcesz, żeby AI pomogło Ci w X, możesz… / nie możesz…”. Taki „przewodnik po szarości” bywa skuteczniejszy niż rozdział o definicjach.
Ten fragment zwykle jest wspólnym dziełem działu bezpieczeństwa, IT i prawnego. Odpowiada na pytania:
jakie kategorie danych nie mogą trafić do modeli zewnętrznych w ogóle (np. tajemnica bankowa, dane szczególnej kategorii, informacje objęte NDA z kluczowymi partnerami),
jak postępować z danymi osobowymi – kiedy dopuszczalne jest ich użycie, tylko w jakim środowisku i pod jakimi warunkami,
czy i jak należy anonimizować lub pseudonimizować dane przed użyciem modelu,
czy zabronione jest korzystanie z publicznych narzędzi AI w przeglądarce poza oficjalnie zatwierdzonymi rozwiązaniami firmowymi.
4. Wymogi co do kontroli i walidacji wyników
Modele językowe mogą się mylić w przekonujący sposób. Polityka powinna jasno wskazywać, że:
materiały generowane przez AI są zawsze wstępną propozycją, wymagającą oceny człowieka,
w określonych obszarach (prawo, finanse, medycyna, komunikacja kryzysowa) wymagana jest weryfikacja przez specjalistę przed użyciem na zewnątrz,
pracownicy mają obowiązek zgłaszania „dziwnych” zachowań modeli (np. generowanie obraźliwych treści, wycieki danych, ewidentne błędy merytoryczne).
5. Zasady licencjonowania i praw autorskich
Modele potrafią pisać ładny tekst, ale niekoniecznie jest jasne, co z prawami do tak wygenerowanej treści. Polityka powinna odpowiedzieć na kilka pragmatycznych kwestii:
kto jest właścicielem materiałów wygenerowanych przez AI w pracy służbowej,
czy można wprowadzać do modeli materiały objęte licencjami (np. dokumenty vendorów, płatne raporty) i na jakich zasadach,
jak oznaczać użycie AI w materiałach zewnętrznych, jeśli wymaga tego regulacja branżowa lub standard etyczny firmy.
Jak wdrożyć politykę, żeby nie stała się „pdf-em w SharePoint”
Nawet najlepiej napisana polityka nic nie da, jeśli pracownicy o niej nie wiedzą lub nie rozumieją, jak ją stosować. Kilka rzeczy ułatwia życie:
krótkie szkolenia i mikro-moduły e-learningowe z realistycznymi przykładami (zamiast jednorazowego dwugodzinnego wykładu),
„AI champions” w działach biznesowych – osoby, które znają narzędzia, rozumieją politykę i pomagają kolegom zastosować ją w praktyce,
przyjazne materiały pomocnicze: szablony promptów, listy kontrolne, krótkie instrukcje „tak/nie” przy najczęstszych zadaniach,
kanał do zadawania pytań (np. na firmowym komunikatorze), gdzie IT/bezpieczeństwo/prawny odpowiadają na wątpliwości związane z użyciem AI.
Dobrym sygnałem dla organizacji jest też przykład z góry: jeśli menedżerowie sami korzystają z zatwierdzonych narzędzi AI i mówią o tym otwarcie, pracownicy rzadziej będą uciekać do prywatnych kont na losowych serwisach.
Governance i role: jak zorganizować odpowiedzialność za AI w organizacji
Dlaczego potrzebne jest formalne „zarządzanie AI”
Modele językowe w firmie zaczynają się zwykle niewinnie: ktoś z IT testuje API, ktoś z marketingu bawi się generowaniem treści, HR próbuje automatyzacji ogłoszeń. Po kilku miesiącach robi się z tego mozaika inicjatyw, którą trudno objąć wzrokiem. Governance nie ma zabijać innowacji, tylko:
zapewnić spójność i bezpieczeństwo wdrożeń,
unikać duplikowania prac i kosztów,
zmniejszyć ryzyko reputacyjne i prawne (np. „model dyskryminuje kandydatów z określonej grupy”),
utrzymać kontrolę nad architekturą i danymi, gdy projektów AI przybywa.
Kluczowe role w obszarze AI
Struktura organizacyjna zależy od wielkości firmy, ale pewien „zestaw ról” pojawia się prawie zawsze. Jedna osoba może pełnić kilka funkcji, zwłaszcza na początku.
1. Sponsor biznesowy / właściciel produktu
Odpowiada za to, żeby rozwiązania AI faktycznie rozwiązywały problemy biznesowe, a nie były jedynie efektowną „piaskownicą technologiczną”. Do jego zadań należy m.in.:
określenie celów biznesowych dla danego rozwiązania (KPI, oczekiwane korzyści),
priorytetyzacja funkcji i przypadków użycia,
nadzór nad wdrożeniem w procesie – szkolenia, zmiany procedur, mierzenie efektów.
2. Zespół IT / architekt AI
Po stronie IT pojawia się rola osoby (lub zespołu), która:
projektuje architekturę rozwiązań (wybór dostawców, decyzja chmura vs on-prem, integracje),
dba o bezpieczeństwo techniczne (szyfrowanie, dostęp, segmentacja sieci),
koordynuje prace rozwojowe z wewnętrznym działem dev / data science i dostawcami,
współpracuje z bezpieczeństwem i prawnym przy ocenie ryzyka nowych projektów AI.
W większych organizacjach rola ta bywa formalizowana jako AI Architect albo wchodzi w zakres obowiązków architekta korporacyjnego.
3. Dział bezpieczeństwa informacji (CISO i zespół)
Bezpieczeństwo nie sprowadza się do zablokowania dostępu do popularnych serwisów AI w firewallu. Zespół bezpieczeństwa:
określa klasyfikację danych i reguły, które dane mogą być przetwarzane przez jakie rozwiązania AI,
bierze udział w ocenie ryzyka przy nowych wdrożeniach (np. testy penetracyjne warstwy orkiestracji, analiza logów),
monitoruje incydenty związane z AI (wycieki, niewłaściwe użycie, naruszenia polityk),
współtworzy procedury reagowania na incydenty specyficzne dla AI (np. gdy model wygeneruje kontrowersyjną odpowiedź klientowi).
4. Dział prawny / compliance / ochrona danych
Ta grupa bywa postrzegana jako „hamulec ręczny”, ale bez niej pierwsze poważniejsze wdrożenie może się skończyć wizytą regulatora. Ich wkład obejmuje:
analizę podstaw prawnych przetwarzania danych w modelach, w tym w kontekście RODO i regulacji branżowych,
przygotowanie umów i klauzul z dostawcami (powierzenie przetwarzania, odpowiedzialność za incydenty, przenoszalność danych),
wsparcie przy ocenach skutków dla ochrony danych (DPIA) dla bardziej wrażliwych zastosowań,
monitorowanie zmian w prawie (np. AI Act) i aktualizowanie polityk wewnętrznych.
5. Zespół data science / ML / AI
Nawet jeśli główny ciężar „inteligencji” biorą na siebie modele dostawców, wewnętrzne kompetencje są kluczowe. Taki zespół:
Najczęściej zadawane pytania (FAQ)
Jak bezpiecznie korzystać z ChatGPT i innych modeli językowych w firmie?
Podstawą jest przyjęcie zasady: do publicznych modeli nie wklejamy danych wrażliwych, tajemnicy przedsiębiorstwa ani informacji pozwalających zidentyfikować klientów czy pracowników. Jeśli nie pokazałbyś tego slajdu na konferencji branżowej, nie wklejaj go też do „darmowego” czatu AI.
W praktyce oznacza to wdrożenie firmowego dostępu (np. poprzez konto organizacyjne), ograniczenie przypadków użycia, logowanie aktywności oraz szkolenia z przykładami „co wolno, czego nie wolno”. Dobrze jest też ustawić domyślne szablony promptów – tak, aby pracownicy nie musieli za każdym razem wymyślać, jak to zrobić „po bożemu”.
Czy mogę wklejać do AI dane klientów, umowy i maile z pracy?
Możesz tylko wtedy, gdy: masz narzędzie zatwierdzone przez IT i bezpieczeństwo, zawartą umowę z dostawcą (regulującą m.in. przetwarzanie danych) oraz jasne wytyczne prawne, co jest dozwolone. W przeciwnym razie każdy wklejony fragment umowy czy korespondencji to potencjalne naruszenie NDA lub RODO.
Bezpieczniejszym podejściem jest pseudonimizacja (usuwanie nazw, PESEL-i, adresów, numerów umów) oraz korzystanie z modeli w wydzielonym, firmowym środowisku. Dział prawny powinien jasno określić, jakie kategorie danych mogą trafić do modelu, a jakie są bezwzględnie zakazane.
Od czego zacząć wdrożenie AI w firmie – IT czy biznes?
Najrozsądniej zacząć wspólnie: biznes definiuje konkretne przypadki użycia (np. skracanie odpowiedzi na zgłoszenia klientów, generowanie szkiców ofert), a IT i bezpieczeństwo dobierają architekturę i narzędzia. Gdy któryś z tych elementów robi się „w piwnicy”, kończy się to zwykle shadow AI i nerwowymi telefonami do działu prawnego.
Dobrym startem jest mały, kontrolowany pilotaż: 1–3 procesy, ograniczony zespół, jasne zasady i szybka pętla feedbacku. Po kilku tygodniach widać, co faktycznie działa, a co było tylko prezentacją „wow” na zarządzie.
Jakie są najbezpieczniejsze zastosowania modeli językowych w biznesie na początek?
Na start lepiej wybierać zadania z mniejszym ryzykiem prawnym i reputacyjnym, np.:
tworzenie i edycja treści wewnętrznych (notatki, podsumowania spotkań, drafty prezentacji),
techniczne wsparcie programistów bez wklejania kodu objętego ścisłym NDA,
analiza i porządkowanie ogólnych zapytań klientów (bez pełnych danych osobowych),
streszczanie publicznych lub wewnętrznych, ale niewrażliwych dokumentów.
Dopiero gdy organizacja „oswoi się” z narzędziem i procedurami, można ostrożnie przechodzić do bardziej wrażliwych obszarów, np. pracy z umowami czy integracji z CRM.
Jak ograniczyć ryzyko wycieku danych przy korzystaniu z AI w firmie?
Kluczowe są trzy elementy: architektura, uprawnienia i edukacja. Po pierwsze – wybór dostawcy i modelu z jasnymi gwarancjami, gdzie są przechowywane dane, jak długo i czy nie są używane do dalszego treningu. Po drugie – kontrola dostępu (kto może korzystać, z jakich systemów, jakie logi są zbierane, jak wygląda backup i usuwanie danych).
Po trzecie – szkolenia z konkretnymi przykładami. Ludzie często nie mają złej woli, tylko nie czują skali ryzyka („co się stanie, jak wkleję tu fragment umowy, przecież to tylko czat”). Kilka realistycznych case’ów z własnej lub cudzej branży działa lepiej niż 40 slajdów z teorii.
Czym różni się użycie modeli językowych od zwykłej wyszukiwarki pod kątem bezpieczeństwa?
Wyszukiwarka głównie pokazuje istniejące treści, które sama znalazła w internecie. Model językowy generuje nową odpowiedź na podstawie danych treningowych i tego, co mu wkleisz. Z punktu widzenia bezpieczeństwa oznacza to, że wkładasz do systemu znacznie więcej „mięsa” – całe maile, fragmenty umów, specyfikacje techniczne.
Ryzyko jest więc inne: nie chodzi tylko o to, co model „wypluje”, ale co już od niego dostał. Nawet jeśli odpowiedź wydaje się niewinna, to dane wejściowe mogły zostać zapisane, zlogowane lub przesłane do dostawcy. To właśnie różni beztroskie googlowanie od korzystania z AI w organizacji.
Co to jest „shadow AI” i jak sobie z tym poradzić w firmie?
Shadow AI to sytuacja, w której pracownicy sami, bez zgody i wiedzy IT, korzystają z zewnętrznych narzędzi AI do zadań służbowych. Typowy scenariusz: ktoś zakłada prywatne konto w popularnym czacie AI, wkleja tam maile od klientów i oferty, „bo tak szybciej”. W pewnym momencie ktoś zadaje niewygodne pytanie o bezpieczeństwo danych i robi się gorąco.
Najskuteczniejsza metoda walki z shadow AI to nie zakazy, tylko danie ludziom lepszej, bezpiecznej alternatywy: firmowego dostępu, sensownych zasad, gotowych przykładów użycia i miejsca, gdzie można zadać pytanie. Gdy narzędzie organizacyjne jest wygodne i działa, chęć kombinowania z prywatnymi kontami szybko maleje.
Źródła informacji
NIST AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology (2023) – Zarządzanie ryzykiem AI w organizacjach, ramy i dobre praktyki
ISO/IEC 42001 Artificial intelligence — Management system. International Organization for Standardization (2023) – System zarządzania dla organizacji wykorzystujących AI, wymagania i kontrola ryzyka
Guidelines on the use of cloud computing services by the public sector. European Union Agency for Cybersecurity ENISA (2021) – Zasady bezpieczeństwa danych w usługach chmurowych, przydatne dla wdrożeń LLM
