Home • Blog • ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

Marcin Kapuściński

16 września 2026

Spis treści

    W 2025 roku sztucznej inteligencji używało 20% przedsiębiorstw w Unii Europejskiej, wobec 13,5% rok wcześniej. W Polsce odsetek ten wynosił 8,4%. Najczęstszym zastosowaniem była analiza języka pisanego, z której korzystało 11,8% firm objętych badaniem. Autorzy badania opublikowanego w 2026 roku w Organization Science opisali to zjawisko jako „jagged technological frontier”, czyli nierównomierną granicę możliwości AI: zadania o podobnym poziomie trudności dla człowieka mogą sprawiać modelowi zupełnie różne trudności. Kolejny etap wymaga odpowiedzi na bardziej precyzyjne pytanie: jaka forma AI pasuje do konkretnego zadania?

    W eksperymencie przeprowadzonym wśród 758 konsultantów osoby korzystające z GPT-4 wykonały 12,2% więcej zadań i ukończyły je średnio o 25,1% szybciej, gdy zadania mieściły się w zakresie możliwości modelu. Przy złożonym zadaniu wykraczającym poza ten zakres prawdopodobieństwo poprawnego rozwiązania spadło o 19 punktów procentowych. Autorzy badania opublikowanego w 2026 roku w Organization Science nazwali tę nieregularną granicę możliwości AI „jagged technological frontier”.

    Efektywność wynika więc z dopasowania technologii do zadania, danych, ryzyka i sposobu kontroli wyniku. Dla jednego procesu właściwym rozwiązaniem będzie firmowy asystent LLM. Drugi będzie wymagał aplikacji połączonej z CRM, bazą wiedzy i systemem uprawnień. W trzecim sprawdzi się niewielki model działający lokalnie. Operacje o jednoznacznych regułach można powierzyć kodowi, silnikom reguł lub robotyzacji procesów biznesowych (RPA). Klasyczne uczenie maszynowe sprawdza się między innymi w prognozowaniu i klasyfikacji danych.

    ChatGPT, integrated LLM, SLM for business

    1. LLM i SLM w firmie: wybór modelu, integracji i miejsca przetwarzania danych

    Określenia „LLM”, „wdrożony LLM” i „zamknięty SLM” łączą kilka warstw technologii. W praktyce biznesowej warto rozdzielić cztery decyzje:

    1. Sposób pracy: czy pracownik rozmawia z gotowym asystentem, czy proces uruchamia się automatycznie?
    2. Zakres integracji: czy rozwiązanie pracuje na materiałach przekazanych przez użytkownika, czy pobiera dane i wykonuje działania w systemach firmy?
    3. Klasa modelu: czy zadanie wymaga szerokich możliwości dużego modelu językowego, czy wystarczy wyspecjalizowany SLM?
    4. Miejsce przetwarzania: czy model działa jako usługa chmurowa, w wydzielonym środowisku, w prywatnej chmurze, lokalnie albo bezpośrednio na urządzeniu?

    Skrót SLM (Small Language Model) oznacza mały model językowy, zwykle wymagający mniej zasobów obliczeniowych. Określenie „system zamknięty” wymaga doprecyzowania: może odnosić się do ograniczonego dostępu, odizolowanego środowiska lub przetwarzania danych we własnej infrastrukturze. Duży LLM może działać w środowisku prywatnym, a SLM może być udostępniany przez publiczne API. Sama wielkość modelu nie określa warunków bezpieczeństwa danych.

    2. Sześć sposobów wykorzystania AI w procesach biznesowych

    Wariant Jak działa Najlepsze dopasowanie Główny miernik
    Firmowy asystent LLM Pracownik zleca zadanie i sprawdza wynik w zatwierdzonym środowisku, np. ChatGPT Business lub Enterprise Analiza, redagowanie, podsumowanie, przygotowanie wariantów, praca ad hoc Oszczędność czasu na zadanie po uwzględnieniu weryfikacji i poprawek
    Zintegrowana aplikacja LLM lub RAG Model korzysta z firmowych źródeł, reguł, uprawnień i integracji Powtarzalne procesy oparte na dokumentach, wiedzy i danych z systemów Koszt poprawnie zakończonej sprawy
    Agent AI Rozwiązanie planuje kolejne kroki, wybiera narzędzia i realizuje cel w określonym zakresie Wieloetapowe procesy z wyjątkami i dynamiczną ścieżką Odsetek poprawnie wykonanych zadań
    SLM Mniejszy model obsługuje wąski zakres zadań w chmurze, na serwerze firmy, na edge albo na urządzeniu Duża liczba zadań, stały zakres tematyczny, krótki czas odpowiedzi, praca offline Jakość w porównaniu z LLM przy określonym koszcie i limicie czasu odpowiedzi p95
    Prywatne lub lokalne wdrożenie LLM albo SLM działa w kontrolowanym środowisku, prywatnej chmurze, sieci firmy lub na urządzeniu Wymogi lokalizacji danych, ciągłości działania, łączności, infrastruktury lub polityki bezpieczeństwa Zgodność z wymaganiami, jakość, dostępność i całkowity koszt posiadania i użytkowania rozwiązania (TCO)
    Reguły, RPA lub klasyczne ML Przebieg procesu jest zapisany w kodzie, warunkach, modelu predykcyjnym lub maszynie stanów Obliczenia, transakcje, stałe ścieżki i jednoznaczne decyzje Dokładność, powtarzalność i kompletność śladu audytowego

    W dojrzałym wdrożeniu warianty te często współpracują. Model językowy interpretuje wiadomość, reguły sprawdzają warunki, aplikacja pobiera dane, człowiek zatwierdza działanie, a system transakcyjny zapisuje wynik.

    3. Do jakich zadań wykorzystać ChatGPT lub innego asystenta LLM?

    Gotowy asystent LLM dobrze wspiera zadania, w których pracownik odpowiada za sprawdzenie i wykorzystanie wyniku. Użytkownik inicjuje pracę, przekazuje kontekst, ocenia odpowiedź i decyduje o jej wykorzystaniu. Wynik ma formę projektu, rekomendacji, analizy lub materiału roboczego.

    Do tej grupy należą między innymi:

    • przygotowanie pierwszej wersji raportu, wiadomości, prezentacji lub artykułu,
    • streszczenie dokumentów i korespondencji,
    • porównanie kilku materiałów dostarczonych przez użytkownika,
    • tworzenie pytań, scenariuszy i wariantów rozwiązania,
    • tłumaczenie treści przeznaczonych do dalszej kontroli,
    • eksploracyjna analiza danych i wyjaśnianie wyników,
    • porządkowanie notatek ze spotkania,
    • przygotowanie projektu procedury lub planu działania.

    Taki sposób pracy sprawdza się w procesach, gdy każda odpowiedź przechodzi kontrolę człowieka, rezultat można łatwo poprawić lub wycofać, a zadanie nie wymaga automatycznego zapisu w systemie krytycznym. Duża zmienność materiału i potrzeba pracy językowej dodatkowo zwiększają użyteczność LLM.

    Bezpieczeństwo zależy od zatwierdzonego produktu i konfiguracji. OpenAI deklaruje, że dane z ChatGPT Business, ChatGPT Enterprise i API nie są domyślnie wykorzystywane do trenowania modeli. Dokumentacja kontroli danych API opisuje również oddzielne zasady retencji, w tym standardowe rejestry służące monitorowaniu nadużyć oraz opcję Zero Data Retention dla klientów spełniających określone warunki. Przed rozpoczęciem pracy organizacja powinna sprawdzić klasyfikację danych, umowę, region przetwarzania, retencję, uprawnienia administratorów i zasady korzystania z połączonych aplikacji. Więcej przykładów takiej pracy zawiera zestawienie 15 integracji ChatGPT z aplikacjami biznesowymi.

    ChatGPT Business, ChatGPT Enterprise i API

    3.1 Jak mierzyć oszczędność czasu i jakość pracy z LLM?

    Badanie pracowników wyłącznie za pomocą ankiety może zawyżać efekt. W eksperymencie METR doświadczeni programiści wykonywali badane zadania z narzędziami AI o 19% dłużej, a po eksperymencie nadal oceniali, że AI przyspieszyła ich pracę o 20%. Badanie obejmowało 16 osób i 246 rzeczywistych zadań w znanych im repozytoriach, więc jego wynik dotyczy tego konkretnego środowiska. Metodologiczny wniosek ma szersze zastosowanie: przed wdrożeniem trzeba zmierzyć rzeczywisty czas i jakość.

    Dla asystenta LLM warto monitorować medianę czasu wykonania zadania, udział wyników zaakceptowanych bez zmian, średni czas poprawek, jakość ocenianą według jednolitych kryteriów, częstotliwość użycia oraz liczbę przypadków, w których użytkownik wrócił do poprzedniej metody pracy.

    4. Kiedy zintegrować LLM z systemami firmy, a kiedy wdrożyć agenta AI?

    Integracja staje się uzasadniona, gdy wartość procesu zależy od aktualnych danych firmy, powtarzalnego przebiegu i współpracy kilku systemów. Model otrzymuje wtedy kontrolowany dostęp do dokumentów, bazy wiedzy, CRM, ERP, systemu zgłoszeń albo poczty. Aplikacja weryfikuje tożsamość użytkownika, kontroluje zakres udostępnianych danych, ustala format odpowiedzi, sprawdza wyniki, rejestruje działania i kieruje wybrane operacje do zatwierdzenia.

    Typowa zintegrowana aplikacja AI obejmuje pięć warstw:

    1. Wejście: wiadomość, dokument, formularz, zdarzenie systemowe lub rekord.
    2. Kontekst: dane pobrane zgodnie z uprawnieniami, często z wykorzystaniem RAG.
    3. Model: LLM albo SLM dobrany do konkretnego etapu.
    4. Walidacja: reguły, kontrola kompletności, sprawdzenie źródeł, klasyfikacja ryzyka.
    5. Wynik: odpowiedź dla człowieka, projekt rekordu albo zatwierdzone działanie w systemie.

    Takiej architektury wymagają między innymi wyszukiwanie odpowiedzi w wewnętrznej bazie wiedzy, analiza umów według firmowej listy ryzyk, przygotowanie oferty na podstawie CRM i cennika, klasyfikowanie zgłoszeń, wdrażanie nowych pracowników, weryfikacja dokumentów zakupowych oraz tworzenie odpowiedzi na podstawie historii klienta. Mechanizm RAG pozwala pobierać aktualne fragmenty zatwierdzonych źródeł i dołączać je do kontekstu odpowiedzi.

    Agent AI jest kolejnym poziomem integracji. Otrzymuje cel, dobiera narzędzia i planuje sekwencję działań. Według aktualnych wytycznych Google Cloud dotyczących architektury agentowej agenci pasują do otwartych, wieloetapowych problemów wymagających użycia danych zewnętrznych i pewnego zakresu autonomii. Do przygotowania pojedynczego streszczenia lub tłumaczenia zwykle wystarcza aplikacja o z góry ustalonej sekwencji działań.

    Rolę zaawansowanego modelu jako warstwy wnioskowania połączonej z narzędziami, danymi i uprawnieniami szerzej opisujemy w artykule GPT-5.5 dla biznesu: nowa era agentów AI.

    Zakres samodzielnych działań agenta można rozszerzać, gdy wyniki testów potwierdzają wymaganą skuteczność i bezpieczeństwo. Uprawnienia agenta warto ograniczyć do funkcji potrzebnych w danym procesie, rozdzielić odczyt od zapisu i wprowadzić zatwierdzenie działań o istotnych skutkach dla firmy lub klienta. OWASP określa nadmierną funkcjonalność, zbyt szerokie uprawnienia i nadmierną autonomię jako trzy główne źródła ryzyka Excessive Agency. Zasada najmniejszych uprawnień ogranicza skutki błędnej interpretacji, wygenerowania nieprawdziwej informacji lub ataku polegającego na podsunięciu modelowi złośliwych instrukcji (prompt injection).

    5. Do jakich procesów biznesowych sprawdzi się mały model językowy SLM?

    Small Language Model wykorzystuje mniej parametrów i zasobów obliczeniowych niż duży model językowy. Według Microsoft Azure sprzyja to krótszemu czasowi odpowiedzi, niższemu zapotrzebowaniu na infrastrukturę oraz przetwarzaniu danych blisko miejsca ich powstawania (edge computing), np. na urządzeniach przemysłowych. Wyspecjalizowany SLM może sprawdzić się w zadaniach o stałej tematyce, przewidywalnych danych wejściowych i jasno określonym wyniku.

    Warto przetestować SLM, gdy proces spełnia kilka z poniższych warunków:

    • stały zestaw kategorii, intencji, pól albo typów odpowiedzi,
    • wysoki i przewidywalny wolumen wywołań,
    • krótki wymagany czas reakcji mierzony jako p95, czyli wartość, której nie przekracza 95% czasów odpowiedzi,
    • ograniczone zasoby sprzętowe,
    • potrzeba pracy offline lub bezpośrednio na urządzeniu,
    • dostęp do danych z danego obszaru działalności oraz zestawu wzorcowych odpowiedzi,
    • możliwość przekazywania trudnych przypadków do większego modelu lub człowieka.

    Przykładem może być klasyfikacja zgłoszeń według 30 stałych kategorii, rozpoznawanie intencji rozmówcy, odczytywanie wartości pól z jednego typu dokumentu, generowanie krótkich odpowiedzi w ściśle określonym zakresie tematycznym albo lokalna analiza komunikatów na urządzeniu przemysłowym.

    O wyborze decyduje wynik testu na danych firmy. SLM powinien osiągnąć wymagany poziom jakości, czasu odpowiedzi i kosztu poprawnie obsłużonej sprawy. Firma może przykładowo wymagać, aby mniejszy model utrzymywał co najmniej 98% jakości referencyjnego LLM, obniżał koszt poprawnego wyniku o co najmniej 20% i mieścił się w limicie p95. Są to przykładowe progi decyzyjne, które właściciel procesu ustala przed pilotażem.

    SLM in business

    5.1 Kiedy wdrożyć LLM lub SLM lokalnie albo w prywatnej chmurze?

    Prywatne lub lokalne wdrożenie może wynikać z wymagań dotyczących suwerenności danych, polityki bezpieczeństwa, ciągłości pracy, opóźnień sieciowych albo środowiska bez dostępu do internetu. Takie wdrożenie może wykorzystywać SLM lub większy model. Równocześnie firmowa aplikacja może korzystać z zarządzanego API z szyfrowaniem, kontrolą retencji, odpowiednim regionem i umową dotyczącą danych.

    Najbardziej efektywna bywa architektura kaskadowa. Microsoft opisuje model hybrydowy, w którym SLM obsługuje typowe zapytania i przekazuje bardziej złożone przypadki do LLM. W środowisku biznesowym do tej kaskady warto dodać trzecią ścieżkę: przekazanie sprawy pracownikowi, gdy wynik budzi wątpliwości, ryzyko jest wysokie lub brakuje wymaganych danych.

    6. Które procesy zautomatyzować za pomocą reguł, RPA lub uczenia maszynowego?

    Procesy o stałych regułach wymagają jasno określonej kolejności działań i warunków ich wykonania. Dokumentacja AWS dotycząca orkiestracji rozdziela przepływy regułowe, w których kolejne stany i przejścia są jawnie zapisane, oraz orkiestrację agentową, w której model interpretuje cel i dynamicznie wybiera narzędzia. Obie warstwy mogą działać w jednej aplikacji.

    Proces Rekomendowany mechanizm Rola modelu językowego
    Naliczenie podatku, wynagrodzenia lub rabatu Kod i silnik reguł Wyjaśnienie wyniku lub interpretacja zapytania użytkownika
    Wykonanie płatności, zwrotu lub zmiany limitu Proces transakcyjny z kontrolą uprawnień Rozpoznanie intencji i przygotowanie danych do zatwierdzenia
    Nadanie lub odebranie uprawnień IAM, reguły ról i zatwierdzenia Obsługa zgłoszenia w języku naturalnym
    Sprawdzenie kompletności wymaganych pól Walidator schematu Ekstrakcja pól z nieustrukturyzowanego dokumentu
    Prognoza rezygnacji klienta lub popytu Klasyczne uczenie maszynowe Opis czynników i przygotowanie komunikacji
    Interpretacja dowolnie sformułowanej wiadomości LLM lub SLM Klasyfikacja intencji i przekazanie danych do kontrolowanego workflow

    W procesie finansowym LLM może odczytać wiadomość, rozpoznać żądanie i przygotować propozycję. Reguły sprawdzają saldo, limity, status klienta i wymagane zgody. System transakcyjny wykonuje operację po spełnieniu warunków. Każda warstwa realizuje zadanie, dla którego można określić jasne kryteria poprawności.

    7. Jak dobrać AI do procesu? Cztery kryteria oceny

    Wstępną kwalifikację można przeprowadzić w czasie krótkiego warsztatu. Osoba odpowiedzialna za proces ocenia go w czterech obszarach, przyznając od 0 do 3 punktów w każdym z nich. Poszczególne oceny pomagają określić wymagania wobec modelu, integracji, zabezpieczeń i infrastruktury.

    Oś 0 1 2 3
    Złożoność interpretacji treści Stałe pola i reguły Stały zestaw kategorii Interpretacja kontekstu Łączenie informacji i wnioskowanie na podstawie wielu źródeł
    Integracja i autonomia Brak dostępu do systemów Odczyt jednego źródła Odczyt wielu źródeł lub przygotowanie danych do zapisania w systemie Transakcje i dynamiczny wybór narzędzi
    Skutek błędu Łatwo odwracalny Ograniczony koszt operacyjny Istotny skutek finansowy, prawny lub wizerunkowy Skutek krytyczny, nieodwracalny lub dotyczący praw i bezpieczeństwa
    Wymagania dotyczące infrastruktury i danych Zarządzana chmura spełnia wymagania Wymagany region lub określona retencja Prywatna sieć albo ścisły limit opóźnienia Praca offline, w środowisku odizolowanym od sieci, na edge lub bezpośrednio na urządzeniu

    Wyniki można czytać w następujący sposób:

    • Złożoność semantyczna 0-1 i stabilne reguły: kod, workflow, RPA albo klasyczne ML.
    • Złożoność 2-3, integracja 0-1 i skutek błędu 0-1: firmowy asystent LLM z kontrolą użytkownika.
    • Złożoność 2-3 oraz integracja 2-3: zintegrowana aplikacja LLM, RAG lub agent.
    • Złożoność 1-2, wąska domena i presja infrastrukturalna 2-3: SLM jako rozwiązanie do uwzględnienia w testach porównawczych.
    • Skutek błędu 2-3: zatwierdzenie przez uprawnioną osobę, zabezpieczenia oparte na z góry ustalonych regułach i pełny rejestr działań, niezależnie od klasy modelu.

    Tabela pomaga wybrać rozwiązania do pilotażu. Ostateczną decyzję podejmuje się po porównaniu ich wyników na tym samym zbiorze rzeczywistych przypadków.

    8. ChatGPT, zintegrowany LLM, SLM i automatyzacja: przykłady zastosowań w firmie

    Przykładowy proces Rekomendowana architektura Najważniejszy KPI Kontrola człowieka
    Pierwsza wersja treści marketingowej Firmowy asystent LLM Mediana oszczędności czasu i odsetek zaakceptowanych wyników Akceptacja każdej publikacji
    Podsumowanie spotkania i lista działań Firmowy asystent z dostępem do zatwierdzonego źródła Kompletność zadań i liczba korekt Weryfikacja właścicieli i terminów
    Odpowiedzi na pytania o procedury wewnętrzne Zintegrowany LLM z RAG i cytowaniem źródeł Odsetek odpowiedzi opartych na źródłach i poprawność odwołań do źródeł Eskalacja przy braku źródła
    Klasyfikacja zgłoszeń do stałych kolejek SLM lub klasyfikator, LLM dla wyjątków Macro-F1 i odsetek wykrytych zgłoszeń priorytetowych Weryfikacja przypadków budzących wątpliwości
    Analiza umów według firmowej listy ryzyk Zintegrowany LLM z RAG, regułami i logami Odsetek wykrytych oraz przeoczonych klauzul ryzykownych Decyzja prawnika
    Ekstrakcja pól z jednego typu faktury OCR, klasyczne ML lub SLM oraz walidator reguł Dokładność na poziomie pola i koszt przetworzenia dokumentu Kontrola wyjątków
    Przygotowanie oferty na podstawie CRM i cennika Zintegrowany LLM, RAG i pobieranie cen według z góry ustalonych reguł Czas przygotowania i odsetek korekt handlowych Akceptacja ceny i warunków
    Sprawdzenie prawa do zwrotu Reguły procesu Zgodność z polityką i czas decyzji Obsługa wyjątków
    Wykonanie zwrotu pieniędzy Workflow transakcyjny i autoryzacja 100% zgodności księgowej i pełny audyt Zależna od kwoty i ryzyka
    Lokalna analiza komunikatów maszyny SLM lub model specjalistyczny na edge Czas odpowiedzi p95, odsetek wykrytych alarmów i dostępność bez połączenia z internetem Eskalacja alarmów krytycznych
    Odebranie dostępu odchodzącemu pracownikowi IAM i deterministyczny workflow Kompletność odebranych uprawnień Zatwierdzenie według polityki
    Wieloetapowa obsługa sprawy klienta Agent AI z ograniczonym zestawem narzędzi Skuteczność realizacji zadań, poprawność użycia narzędzi i odsetek spraw przekazanych pracownikowi Punkty zatwierdzenia dla działań o wysokim wpływie

    9. Jak mierzyć efekty wdrożenia AI? Wskaźniki jakości, czasu i kosztów

    Pomiar zaczyna się od obecnego procesu. Badanie Generative AI at Work, obejmujące 5 179 pracowników obsługi klienta, wykazało średni wzrost liczby rozwiązanych spraw na godzinę o 14%. Największą poprawę odnotowano u osób mniej doświadczonych. Tak zdefiniowana produktywność ma jasny licznik, mianownik i grupę odniesienia. Podobnej precyzji potrzebuje firmowy pilotaż.

    Obszar Wskaźnik Sposób pomiaru
    Skala Wolumen spraw Liczba przypadków miesięcznie, sezonowość i okresy największego obciążenia
    Czas Czas obsługi sprawy Średnia, mediana i p90 przed wdrożeniem oraz po nim
    Jakość Task success rate Odsetek przypadków spełniających wszystkie kryteria poprawnego wykonania zadania
    Użyteczność Odsetek wyników przyjętych bez zmian merytorycznych Odsetek wyników przyjętych bez zmiany merytorycznej
    Kontrola Odsetek decyzji AI zmienionych przez pracownika Odsetek decyzji lub propozycji zmienionych przez pracownika
    Ryzyko Częstotliwość błędów krytycznych Liczba błędów krytycznych na 1 000 lub 10 000 przypadków
    Klasyfikacja Precyzja, czułość i miara F1 Osobno dla każdej ważnej klasy, zwłaszcza rzadkich zdarzeń
    RAG Zgodność odpowiedzi ze źródłami Odsetek twierdzeń wspartych wskazanym, aktualnym źródłem
    Agent Poprawność wyboru narzędzi i przekazywanych parametrów Poprawny wybór narzędzia oraz poprawność przekazanych parametrów
    Automatyzacja Odsetek spraw obsłużonych w pełni automatycznie Odsetek spraw zakończonych bez ręcznej interwencji
    Wydajność Czas od rozpoczęcia zadania do uzyskania ostatecznego wyniku p50 i p95 od rozpoczęcia do ostatecznego wyniku
    Ekonomia Koszt poprawnie zakończonego zadania Pełny koszt podzielony przez liczbę poprawnych rezultatów
    Stabilność Zmiany jakości działania systemu w czasie Zmiana jakości według czasu, języka, kategorii i typu użytkownika

    Google Cloud wskazuje koszt poprawnie zakończonego zadania jako kluczowy miernik agentów AI działających w rzeczywistych procesach biznesowych. Model kosztujący 0,10 USD na uruchomienie i osiągający 50% skuteczności generuje sam koszt wywołań na poziomie 0,20 USD na poprawny wynik. Do rachunku dochodzą weryfikacja przez pracownika, ponowne próby, integracje, monitoring oraz koszt błędów.

    10. Jak obliczyć ROI wdrożenia LLM lub SLM?

    Pełny koszt rozwiązania powinien obejmować budowę i integrację, model lub API, infrastrukturę, monitoring, aktualizacje, weryfikacja przez pracownika, poprawki oraz oczekiwaną stratę wynikającą z błędów.

    Koszt poprawnie zakończonego zadania:

    C_success = (koszt budowy przypisany do okresu + model/API + infrastruktura + monitoring + kontrola człowieka + poprawki + oczekiwana strata błędów) / liczba poprawnie zakończonych zadań

    Roczna korzyść:

    Korzyść = oszczędzony czas pracy + uniknięte poprawki i błędy + dodatkowa marża + uniknięte kary SLA

    ROI:

    ROI = (Korzyść - TCO rozwiązania AI) / TCO rozwiązania AI × 100%

    Załóżmy, że zespół klasyfikuje 20 000 zgłoszeń miesięcznie. Jedno zgłoszenie zajmuje średnio 4 minuty, a pełny koszt godziny pracy wynosi 120 zł. Miesięczny koszt ręcznej klasyfikacji wynosi około 160 000 zł. W pilotażu system osiąga 88% wyników zaakceptowanych bez korekty, weryfikacja jednego wyniku trwa średnio 45 sekund, poprawa pozostałych przypadków zajmuje 3 minuty, a miesięczne koszty modelu, infrastruktury, utrzymania i amortyzowanego wdrożenia wynoszą 51 000 zł.

    • przegląd wszystkich przypadków: około 30 000 zł,
    • poprawa 12% przypadków: około 14 400 zł,
    • model, infrastruktura, utrzymanie i wdrożenie: 51 000 zł,
    • łączny koszt procesu po wdrożeniu: około 95 400 zł,
    • miesięczna różnica kosztu: około 64 600 zł, czyli 40,4%.

    To przykład metodologiczny z założonymi wartościami. W analizie opłacalności rzeczywistego wdrożenia trzeba uwzględnić zmianę kosztu błędów, sezonowość, czas przestojów, koszt obsługi wyjątków oraz tempo, w jakim pracownicy zaczynają korzystać z rozwiązania. Dla procesu generującego przychód rachunek powinien uwzględniać również zmianę marży, współczynnika konwersji albo wskaźnika utrzymania klientów

    11. Jak przeprowadzić mierzalny pilotaż LLM lub SLM?

    1. Zapisz punkt odniesienia. Zmierz wolumen, czas, jakość, błędy, eskalacje i koszt obecnej metody przez co najmniej jeden pełny cykl biznesowy.
    2. Przygotuj zestaw przypadków testowych. Uwzględnij typowe zadania, trudne i rzadkie sytuacje, przypadki na granicy dopuszczalnych warunków oraz próby celowego wprowadzenia systemu w błąd. Google Cloud zaleca własny zbiór odzwierciedlający pełne spektrum użycia.
    3. Ustal progi przed testem. Zapisz minimalną jakość, maksymalny koszt, dopuszczalną latencję, limit błędów krytycznych i zasady eskalacji.
    4. Porównaj kilka wariantów. Uwzględnij obecny proces, mocny LLM, mniejszy model oraz architekturę hybrydową.
    5. Uruchom system w trybie obserwacyjnym (shadow mode). AI przygotowuje wyniki równolegle do dotychczasowego procesu. Decyzje i działania nadal przebiegają według obowiązujących zasad. Pozwala to wykryć błędy przed dopuszczeniem AI do obsługi rzeczywistych operacji.
    6. Uruchom system w ograniczonym zakresie. Rozpocznij od propozycji i zatwierdzeń. Zakres automatycznych działań rozszerzaj na podstawie wyników.
    7. Monitoruj jakość działania. Ponawiaj testy po zmianie modelu, instrukcji dla AI, narzędzi, źródeł danych, reguł lub rodzaju przetwarzanych materiałów.

    11.1 Ile przypadków testowych potrzeba do oceny LLM lub SLM?

    Dla wskaźnika wyrażonego jako odsetek, przy poziomie ufności 95% i marginesie błędu +/-5 punktów procentowych, konserwatywna wielkość próby wynosi około 385 niezależnych przypadków. Margines +/-3 punkty procentowe wymaga około 1 068 przypadków. Próba reprezentatywna powinna zostać uzupełniona osobnym zestawem przypadków krytycznych i brzegowych.

    Przy rzadkich błędach istotna jest tak zwana reguła trzech. Jeżeli w 300 testach nie pojawi się żaden błąd krytyczny, przybliżona górna granica jego rzeczywistego prawdopodobieństwa na poziomie ufności 95% nadal wynosi około 1%. Zero błędów w 3 000 testów obniża tę granicę do około 0,1%. W procesach wysokiego ryzyka potrzebne są więc znacznie większe zbiory oraz testy ukierunkowane na konkretne zagrożenia.

    11.2 Kiedy zakończyć pilotaż AI i uruchomić system w firmie? Przykładowe kryteria

    Proces Przykładowe kryteria przejścia do produkcji
    odsetek przypisań zmienionych przez pracownika do 8% Macro-F1 co najmniej 0,90; recall zgłoszeń priorytetowych co najmniej 0,99; override rate do 8%; p95 do 2 sekund
    Wewnętrzna baza wiedzy Acceptance rate co najmniej 85%; poprawność cytowań co najmniej 98%; brak niepopartych twierdzeń w zestawie krytycznym; p95 do 8 sekund
    Projekt oferty Mediana czasu niższa o co najmniej 30%; co najmniej 75% materiałów przyjętych z drobnymi zmianami; 100% cen pobranych z autoryzowanego źródła; zatwierdzenie człowieka dla każdej oferty

    Podane wartości są przykładem konstrukcji kryteriów. Właściciel procesu ustala progi zgodnie z kosztem błędu, wymaganą jakością i tolerancją ryzyka organizacji.

    12. Jak dobrać zakres nadzoru człowieka do ryzyka związanego z AI?

    NIST definiuje ryzyko jako połączenie prawdopodobieństwa zdarzenia i skali jego konsekwencji. Ta zasada pozwala przełożyć ogólne obawy związane z AI na mierzalny model: częstotliwość błędów, wartość środków lub zasobów narażonych na stratę, możliwość cofnięcia działania, czas wykrycia błędu i koszt jego naprawy

    W skonsolidowanym tekście unijnego AI Act wymagania dla systemów wysokiego ryzyka obejmują ciągłe zarządzanie ryzykiem, odpowiedni poziom dokładności, odporności i cyberbezpieczeństwa oraz skuteczny nadzór człowieka. Środki nadzoru mają być proporcjonalne do ryzyka, poziomu autonomii i kontekstu użycia. Testy powinny korzystać z uprzednio zdefiniowanych metryk i progów właściwych dla zamierzonego zastosowania.

    W praktyce biznesowej oznacza to przypisanie konkretnej osoby do zatwierdzania, monitorowania i reagowania. Interfejs powinien pokazywać źródła, wykonane działania i poziom niepewności, a użytkownik musi mieć możliwość zatrzymania procesu. Ryzyko poważnych konsekwencji błędu uzasadnia ograniczenie uprawnień modelu, dodatkowe sprawdzanie wyników i dłuższe testy w trybie obserwacyjnym. Klasyfikację regulacyjną należy ustalić osobno dla zamierzonego zastosowania i roli organizacji.

    13. Jak połączyć LLM, SLM i reguły w jednym procesie biznesowym?

    Połączenie kilku technologii pozwala dopasować sposób obsługi do poszczególnych etapów procesu. Przykładowo SLM rozpoznaje temat zgłoszenia klienta, a LLM przygotowuje odpowiedź na podstawie historii kontaktu i dokumentów pobranych przez RAG. Gdy sprawa dotyczy zwrotu pieniędzy, system sprawdza warunki i limity zgodnie z ustalonymi regułami, a następnie kieruje operację do realizacji lub zatwierdzenia przez uprawnionego pracownika. Tak zaprojektowana obsługa łączy automatyzację z kontrolą decyzji mających skutki finansowe.

    W TTMS pomożemy Ci ocenić, gdzie podobne rozwiązanie przyniesie największą korzyść. Zaczniemy od zadań, które pochłaniają najwięcej czasu: powtarzalnych czynności, wyszukiwania informacji czy poprawiania błędów. Podczas konsultacji przeanalizujemy przebieg pracy, dostępne dane i wykorzystywane systemy. Na tej podstawie zaproponujemy technologię i zakres pilotażu, a wspólnie z Tobą ustalimy oczekiwane efekty oraz sposób pomiaru jakości, czasu i kosztów.

    Chcesz wybrać pierwszy proces do usprawnienia? Umów się z nami na konsultację dotyczącą wdrożenia AI.

    Źródła

    1. Eurostat, 20% of EU enterprises use AI technologies, 11 grudnia 2025.
    2. Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality, Organization Science.
    3. Erik Brynjolfsson, Danielle Li, Lindsey Raymond, Generative AI at Work, NBER Working Paper 31161, 2023.
    4. Joel Becker, Nate Rush, Beth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 lipca 2025.
    5. Microsoft Azure, What Are Small Language Models (SLMs)?.
    6. Microsoft Azure, Boost processing performance by combining AI models, 8 stycznia 2025.
    7. OpenAI, Enterprise privacy at OpenAI.
    8. Google Cloud, The KPIs that actually matter for production AI agents, 26 lutego 2026.
    9. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, lipiec 2024.
    10. Unia Europejska, Rozporządzenie (UE) 2024/1689, tekst skonsolidowany z 27 lipca 2026.
    11. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025.

    FAQ

    Czy do pracy na danych firmowych trzeba uruchamiać własny model AI?

    Własny model jest jednym z dostępnych wariantów. Firmy mogą korzystać z zatwierdzonego środowiska biznesowego, zarządzanego API, prywatnej chmury, wydzielonej infrastruktury lub modelu działającego lokalnie. Wybór zależy od klasy danych, lokalizacji przetwarzania, retencji, szyfrowania, tożsamości użytkowników, wymogów branżowych i umowy z dostawcą. Przykładowo OpenAI deklaruje brak domyślnego trenowania na danych klientów biznesowych i oferuje dodatkowe mechanizmy kontroli retencji dla kwalifikujących się klientów API. Organizacja powinna udokumentować przepływ danych dla konkretnej konfiguracji, ponieważ nazwa modelu nie opisuje całej architektury bezpieczeństwa.

    Czy RAG może zastąpić fine-tuning modelu na danych firmy?

    RAG i fine-tuning rozwiązują różne problemy. RAG pobiera aktualne informacje z kontrolowanego źródła w momencie tworzenia odpowiedzi, dzięki czemu dobrze pasuje do baz wiedzy, procedur, dokumentacji i treści często aktualizowanych. Fine-tuning dostosowuje zachowanie modelu do przykładów, stylu, formatu albo wyspecjalizowanego zadania. Dokumentacja AWS porównująca RAG i fine-tuning rekomenduje rozpoczęcie systemu pytań i odpowiedzi na własnych dokumentach od RAG, zwłaszcza gdy ważne są aktualność i odwołania do źródeł. Oba mechanizmy mogą działać razem, jeśli proces wymaga zarówno aktualnej wiedzy, jak i stabilnego zachowania domenowego.

    Czy jeden proces może korzystać jednocześnie z LLM i SLM?

    Tak. Router może kierować typowe, dobrze rozpoznane sprawy do SLM, a przypadki złożone do większego LLM. Trzecia ścieżka prowadzi do człowieka, gdy system wykryje brak danych, niską pewność albo wysoki poziom ryzyka. Innym wariantem jest podział procesu według funkcji: SLM klasyfikuje dokument, LLM przygotowuje wyjaśnienie, kod oblicza wartości, a workflow zapisuje zatwierdzoną decyzję. Taki układ pozwala kontrolować koszty i czas reakcji przy zachowaniu dostępu do większych możliwości w trudniejszych sprawach.

    Ile przykładów potrzeba do pilotażu LLM lub SLM?

    Liczba zależy od oczekiwanej precyzji pomiaru i rzadkości błędów. Dla odsetka skutecznych odpowiedzi próba około 385 niezależnych przypadków daje przybliżony margines +/-5 punktów procentowych przy poziomie ufności 95% w wariancie konserwatywnym. Margines +/-3 punkty wymaga około 1 068 przypadków. Losowa próba powinna odzwierciedlać rzeczywisty wolumen, języki, kanały i typy użytkowników. Osobny zestaw powinien obejmować przypadki krytyczne, brzegowe, rzadkie oraz próby manipulacji systemem.

    Jak często trzeba ponownie testować aplikację opartą na modelu językowym?

    Pełna ewaluacja powinna zostać uruchomiona po zmianie modelu, wersji promptu, narzędzia, uprawnień, źródła danych, reguł biznesowych lub formatu wejścia. Produkcja wymaga również ciągłego monitorowania najważniejszych KPI oraz cyklicznego testu regresji. Częstotliwość zależy od ryzyka i tempa zmian procesu. Aplikacja obsługująca treści marketingowe może mieć inny harmonogram niż system wspierający decyzje finansowe. Praktycznym rozwiązaniem jest automatyczny test przy każdej zmianie technicznej, miesięczny przegląd trendów oraz kwartalna ewaluacja biznesowa, z krótszym cyklem dla zastosowań wysokiego ryzyka.

    Polecane wpisy

    10 najczęstszych problemów w małych firmach. Zobacz, jak skutecznie możesz je rozwiązać
    Akademia Salesforce, czyli jak się załapać do orkiestry
    AEM Tech Talk w TTMS Poznań
    5 mitów reportingu okiem architekta Business Intelligence

    TTMS blog – świat IT oczami ekspertów

    ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

    ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

    W 2025 roku sztucznej inteligencji używało 20% przedsiębiorstw w Unii Europejskiej, wobec 13,5% rok wcześniej. W Polsce odsetek ten wynosił 8,4%. Najczęstszym zastosowaniem była analiza języka pisanego, z której korzystało 11,8% firm objętych badaniem. Autorzy badania opublikowanego w 2026 roku w Organization Science opisali to zjawisko jako „jagged technological frontier”, czyli nierównomierną granicę możliwości AI: zadania o podobnym poziomie trudności dla człowieka mogą sprawiać modelowi zupełnie różne trudności. Kolejny etap wymaga odpowiedzi na bardziej precyzyjne pytanie: jaka forma AI pasuje do konkretnego zadania? W eksperymencie przeprowadzonym wśród 758 konsultantów osoby korzystające z GPT-4 wykonały 12,2% więcej zadań i ukończyły je średnio o 25,1% szybciej, gdy zadania mieściły się w zakresie możliwości modelu. Przy złożonym zadaniu wykraczającym poza ten zakres prawdopodobieństwo poprawnego rozwiązania spadło o 19 punktów procentowych. Autorzy badania opublikowanego w 2026 roku w Organization Science nazwali tę nieregularną granicę możliwości AI „jagged technological frontier”. Efektywność wynika więc z dopasowania technologii do zadania, danych, ryzyka i sposobu kontroli wyniku. Dla jednego procesu właściwym rozwiązaniem będzie firmowy asystent LLM. Drugi będzie wymagał aplikacji połączonej z CRM, bazą wiedzy i systemem uprawnień. W trzecim sprawdzi się niewielki model działający lokalnie. Operacje o jednoznacznych regułach można powierzyć kodowi, silnikom reguł lub robotyzacji procesów biznesowych (RPA). Klasyczne uczenie maszynowe sprawdza się między innymi w prognozowaniu i klasyfikacji danych. 1. LLM i SLM w firmie: wybór modelu, integracji i miejsca przetwarzania danych Określenia „LLM”, „wdrożony LLM” i „zamknięty SLM” łączą kilka warstw technologii. W praktyce biznesowej warto rozdzielić cztery decyzje: Sposób pracy: czy pracownik rozmawia z gotowym asystentem, czy proces uruchamia się automatycznie? Zakres integracji: czy rozwiązanie pracuje na materiałach przekazanych przez użytkownika, czy pobiera dane i wykonuje działania w systemach firmy? Klasa modelu: czy zadanie wymaga szerokich możliwości dużego modelu językowego, czy wystarczy wyspecjalizowany SLM? Miejsce przetwarzania: czy model działa jako usługa chmurowa, w wydzielonym środowisku, w prywatnej chmurze, lokalnie albo bezpośrednio na urządzeniu? Skrót SLM (Small Language Model) oznacza mały model językowy, zwykle wymagający mniej zasobów obliczeniowych. Określenie „system zamknięty” wymaga doprecyzowania: może odnosić się do ograniczonego dostępu, odizolowanego środowiska lub przetwarzania danych we własnej infrastrukturze. Duży LLM może działać w środowisku prywatnym, a SLM może być udostępniany przez publiczne API. Sama wielkość modelu nie określa warunków bezpieczeństwa danych. 2. Sześć sposobów wykorzystania AI w procesach biznesowych Wariant Jak działa Najlepsze dopasowanie Główny miernik Firmowy asystent LLM Pracownik zleca zadanie i sprawdza wynik w zatwierdzonym środowisku, np. ChatGPT Business lub Enterprise Analiza, redagowanie, podsumowanie, przygotowanie wariantów, praca ad hoc Oszczędność czasu na zadanie po uwzględnieniu weryfikacji i poprawek Zintegrowana aplikacja LLM lub RAG Model korzysta z firmowych źródeł, reguł, uprawnień i integracji Powtarzalne procesy oparte na dokumentach, wiedzy i danych z systemów Koszt poprawnie zakończonej sprawy Agent AI Rozwiązanie planuje kolejne kroki, wybiera narzędzia i realizuje cel w określonym zakresie Wieloetapowe procesy z wyjątkami i dynamiczną ścieżką Odsetek poprawnie wykonanych zadań SLM Mniejszy model obsługuje wąski zakres zadań w chmurze, na serwerze firmy, na edge albo na urządzeniu Duża liczba zadań, stały zakres tematyczny, krótki czas odpowiedzi, praca offline Jakość w porównaniu z LLM przy określonym koszcie i limicie czasu odpowiedzi p95 Prywatne lub lokalne wdrożenie LLM albo SLM działa w kontrolowanym środowisku, prywatnej chmurze, sieci firmy lub na urządzeniu Wymogi lokalizacji danych, ciągłości działania, łączności, infrastruktury lub polityki bezpieczeństwa Zgodność z wymaganiami, jakość, dostępność i całkowity koszt posiadania i użytkowania rozwiązania (TCO) Reguły, RPA lub klasyczne ML Przebieg procesu jest zapisany w kodzie, warunkach, modelu predykcyjnym lub maszynie stanów Obliczenia, transakcje, stałe ścieżki i jednoznaczne decyzje Dokładność, powtarzalność i kompletność śladu audytowego W dojrzałym wdrożeniu warianty te często współpracują. Model językowy interpretuje wiadomość, reguły sprawdzają warunki, aplikacja pobiera dane, człowiek zatwierdza działanie, a system transakcyjny zapisuje wynik. 3. Do jakich zadań wykorzystać ChatGPT lub innego asystenta LLM? Gotowy asystent LLM dobrze wspiera zadania, w których pracownik odpowiada za sprawdzenie i wykorzystanie wyniku. Użytkownik inicjuje pracę, przekazuje kontekst, ocenia odpowiedź i decyduje o jej wykorzystaniu. Wynik ma formę projektu, rekomendacji, analizy lub materiału roboczego. Do tej grupy należą między innymi: przygotowanie pierwszej wersji raportu, wiadomości, prezentacji lub artykułu, streszczenie dokumentów i korespondencji, porównanie kilku materiałów dostarczonych przez użytkownika, tworzenie pytań, scenariuszy i wariantów rozwiązania, tłumaczenie treści przeznaczonych do dalszej kontroli, eksploracyjna analiza danych i wyjaśnianie wyników, porządkowanie notatek ze spotkania, przygotowanie projektu procedury lub planu działania. Taki sposób pracy sprawdza się w procesach, gdy każda odpowiedź przechodzi kontrolę człowieka, rezultat można łatwo poprawić lub wycofać, a zadanie nie wymaga automatycznego zapisu w systemie krytycznym. Duża zmienność materiału i potrzeba pracy językowej dodatkowo zwiększają użyteczność LLM. Bezpieczeństwo zależy od zatwierdzonego produktu i konfiguracji. OpenAI deklaruje, że dane z ChatGPT Business, ChatGPT Enterprise i API nie są domyślnie wykorzystywane do trenowania modeli. Dokumentacja kontroli danych API opisuje również oddzielne zasady retencji, w tym standardowe rejestry służące monitorowaniu nadużyć oraz opcję Zero Data Retention dla klientów spełniających określone warunki. Przed rozpoczęciem pracy organizacja powinna sprawdzić klasyfikację danych, umowę, region przetwarzania, retencję, uprawnienia administratorów i zasady korzystania z połączonych aplikacji. Więcej przykładów takiej pracy zawiera zestawienie 15 integracji ChatGPT z aplikacjami biznesowymi. 3.1 Jak mierzyć oszczędność czasu i jakość pracy z LLM? Badanie pracowników wyłącznie za pomocą ankiety może zawyżać efekt. W eksperymencie METR doświadczeni programiści wykonywali badane zadania z narzędziami AI o 19% dłużej, a po eksperymencie nadal oceniali, że AI przyspieszyła ich pracę o 20%. Badanie obejmowało 16 osób i 246 rzeczywistych zadań w znanych im repozytoriach, więc jego wynik dotyczy tego konkretnego środowiska. Metodologiczny wniosek ma szersze zastosowanie: przed wdrożeniem trzeba zmierzyć rzeczywisty czas i jakość. Dla asystenta LLM warto monitorować medianę czasu wykonania zadania, udział wyników zaakceptowanych bez zmian, średni czas poprawek, jakość ocenianą według jednolitych kryteriów, częstotliwość użycia oraz liczbę przypadków, w których użytkownik wrócił do poprzedniej metody pracy. 4. Kiedy zintegrować LLM z systemami firmy, a kiedy wdrożyć agenta AI? Integracja staje się uzasadniona, gdy wartość procesu zależy od aktualnych danych firmy, powtarzalnego przebiegu i współpracy kilku systemów. Model otrzymuje wtedy kontrolowany dostęp do dokumentów, bazy wiedzy, CRM, ERP, systemu zgłoszeń albo poczty. Aplikacja weryfikuje tożsamość użytkownika, kontroluje zakres udostępnianych danych, ustala format odpowiedzi, sprawdza wyniki, rejestruje działania i kieruje wybrane operacje do zatwierdzenia. Typowa zintegrowana aplikacja AI obejmuje pięć warstw: Wejście: wiadomość, dokument, formularz, zdarzenie systemowe lub rekord. Kontekst: dane pobrane zgodnie z uprawnieniami, często z wykorzystaniem RAG. Model: LLM albo SLM dobrany do konkretnego etapu. Walidacja: reguły, kontrola kompletności, sprawdzenie źródeł, klasyfikacja ryzyka. Wynik: odpowiedź dla człowieka, projekt rekordu albo zatwierdzone działanie w systemie. Takiej architektury wymagają między innymi wyszukiwanie odpowiedzi w wewnętrznej bazie wiedzy, analiza umów według firmowej listy ryzyk, przygotowanie oferty na podstawie CRM i cennika, klasyfikowanie zgłoszeń, wdrażanie nowych pracowników, weryfikacja dokumentów zakupowych oraz tworzenie odpowiedzi na podstawie historii klienta. Mechanizm RAG pozwala pobierać aktualne fragmenty zatwierdzonych źródeł i dołączać je do kontekstu odpowiedzi. Agent AI jest kolejnym poziomem integracji. Otrzymuje cel, dobiera narzędzia i planuje sekwencję działań. Według aktualnych wytycznych Google Cloud dotyczących architektury agentowej agenci pasują do otwartych, wieloetapowych problemów wymagających użycia danych zewnętrznych i pewnego zakresu autonomii. Do przygotowania pojedynczego streszczenia lub tłumaczenia zwykle wystarcza aplikacja o z góry ustalonej sekwencji działań. Rolę zaawansowanego modelu jako warstwy wnioskowania połączonej z narzędziami, danymi i uprawnieniami szerzej opisujemy w artykule GPT-5.5 dla biznesu: nowa era agentów AI. Zakres samodzielnych działań agenta można rozszerzać, gdy wyniki testów potwierdzają wymaganą skuteczność i bezpieczeństwo. Uprawnienia agenta warto ograniczyć do funkcji potrzebnych w danym procesie, rozdzielić odczyt od zapisu i wprowadzić zatwierdzenie działań o istotnych skutkach dla firmy lub klienta. OWASP określa nadmierną funkcjonalność, zbyt szerokie uprawnienia i nadmierną autonomię jako trzy główne źródła ryzyka Excessive Agency. Zasada najmniejszych uprawnień ogranicza skutki błędnej interpretacji, wygenerowania nieprawdziwej informacji lub ataku polegającego na podsunięciu modelowi złośliwych instrukcji (prompt injection). 5. Do jakich procesów biznesowych sprawdzi się mały model językowy SLM? Small Language Model wykorzystuje mniej parametrów i zasobów obliczeniowych niż duży model językowy. Według Microsoft Azure sprzyja to krótszemu czasowi odpowiedzi, niższemu zapotrzebowaniu na infrastrukturę oraz przetwarzaniu danych blisko miejsca ich powstawania (edge computing), np. na urządzeniach przemysłowych. Wyspecjalizowany SLM może sprawdzić się w zadaniach o stałej tematyce, przewidywalnych danych wejściowych i jasno określonym wyniku. Warto przetestować SLM, gdy proces spełnia kilka z poniższych warunków: stały zestaw kategorii, intencji, pól albo typów odpowiedzi, wysoki i przewidywalny wolumen wywołań, krótki wymagany czas reakcji mierzony jako p95, czyli wartość, której nie przekracza 95% czasów odpowiedzi, ograniczone zasoby sprzętowe, potrzeba pracy offline lub bezpośrednio na urządzeniu, dostęp do danych z danego obszaru działalności oraz zestawu wzorcowych odpowiedzi, możliwość przekazywania trudnych przypadków do większego modelu lub człowieka. Przykładem może być klasyfikacja zgłoszeń według 30 stałych kategorii, rozpoznawanie intencji rozmówcy, odczytywanie wartości pól z jednego typu dokumentu, generowanie krótkich odpowiedzi w ściśle określonym zakresie tematycznym albo lokalna analiza komunikatów na urządzeniu przemysłowym. O wyborze decyduje wynik testu na danych firmy. SLM powinien osiągnąć wymagany poziom jakości, czasu odpowiedzi i kosztu poprawnie obsłużonej sprawy. Firma może przykładowo wymagać, aby mniejszy model utrzymywał co najmniej 98% jakości referencyjnego LLM, obniżał koszt poprawnego wyniku o co najmniej 20% i mieścił się w limicie p95. Są to przykładowe progi decyzyjne, które właściciel procesu ustala przed pilotażem. 5.1 Kiedy wdrożyć LLM lub SLM lokalnie albo w prywatnej chmurze? Prywatne lub lokalne wdrożenie może wynikać z wymagań dotyczących suwerenności danych, polityki bezpieczeństwa, ciągłości pracy, opóźnień sieciowych albo środowiska bez dostępu do internetu. Takie wdrożenie może wykorzystywać SLM lub większy model. Równocześnie firmowa aplikacja może korzystać z zarządzanego API z szyfrowaniem, kontrolą retencji, odpowiednim regionem i umową dotyczącą danych. Najbardziej efektywna bywa architektura kaskadowa. Microsoft opisuje model hybrydowy, w którym SLM obsługuje typowe zapytania i przekazuje bardziej złożone przypadki do LLM. W środowisku biznesowym do tej kaskady warto dodać trzecią ścieżkę: przekazanie sprawy pracownikowi, gdy wynik budzi wątpliwości, ryzyko jest wysokie lub brakuje wymaganych danych. 6. Które procesy zautomatyzować za pomocą reguł, RPA lub uczenia maszynowego? Procesy o stałych regułach wymagają jasno określonej kolejności działań i warunków ich wykonania. Dokumentacja AWS dotycząca orkiestracji rozdziela przepływy regułowe, w których kolejne stany i przejścia są jawnie zapisane, oraz orkiestrację agentową, w której model interpretuje cel i dynamicznie wybiera narzędzia. Obie warstwy mogą działać w jednej aplikacji. Proces Rekomendowany mechanizm Rola modelu językowego Naliczenie podatku, wynagrodzenia lub rabatu Kod i silnik reguł Wyjaśnienie wyniku lub interpretacja zapytania użytkownika Wykonanie płatności, zwrotu lub zmiany limitu Proces transakcyjny z kontrolą uprawnień Rozpoznanie intencji i przygotowanie danych do zatwierdzenia Nadanie lub odebranie uprawnień IAM, reguły ról i zatwierdzenia Obsługa zgłoszenia w języku naturalnym Sprawdzenie kompletności wymaganych pól Walidator schematu Ekstrakcja pól z nieustrukturyzowanego dokumentu Prognoza rezygnacji klienta lub popytu Klasyczne uczenie maszynowe Opis czynników i przygotowanie komunikacji Interpretacja dowolnie sformułowanej wiadomości LLM lub SLM Klasyfikacja intencji i przekazanie danych do kontrolowanego workflow W procesie finansowym LLM może odczytać wiadomość, rozpoznać żądanie i przygotować propozycję. Reguły sprawdzają saldo, limity, status klienta i wymagane zgody. System transakcyjny wykonuje operację po spełnieniu warunków. Każda warstwa realizuje zadanie, dla którego można określić jasne kryteria poprawności. 7. Jak dobrać AI do procesu? Cztery kryteria oceny Wstępną kwalifikację można przeprowadzić w czasie krótkiego warsztatu. Osoba odpowiedzialna za proces ocenia go w czterech obszarach, przyznając od 0 do 3 punktów w każdym z nich. Poszczególne oceny pomagają określić wymagania wobec modelu, integracji, zabezpieczeń i infrastruktury. Oś 0 1 2 3 Złożoność interpretacji treści Stałe pola i reguły Stały zestaw kategorii Interpretacja kontekstu Łączenie informacji i wnioskowanie na podstawie wielu źródeł Integracja i autonomia Brak dostępu do systemów Odczyt jednego źródła Odczyt wielu źródeł lub przygotowanie danych do zapisania w systemie Transakcje i dynamiczny wybór narzędzi Skutek błędu Łatwo odwracalny Ograniczony koszt operacyjny Istotny skutek finansowy, prawny lub wizerunkowy Skutek krytyczny, nieodwracalny lub dotyczący praw i bezpieczeństwa Wymagania dotyczące infrastruktury i danych Zarządzana chmura spełnia wymagania Wymagany region lub określona retencja Prywatna sieć albo ścisły limit opóźnienia Praca offline, w środowisku odizolowanym od sieci, na edge lub bezpośrednio na urządzeniu Wyniki można czytać w następujący sposób: Złożoność semantyczna 0-1 i stabilne reguły: kod, workflow, RPA albo klasyczne ML. Złożoność 2-3, integracja 0-1 i skutek błędu 0-1: firmowy asystent LLM z kontrolą użytkownika. Złożoność 2-3 oraz integracja 2-3: zintegrowana aplikacja LLM, RAG lub agent. Złożoność 1-2, wąska domena i presja infrastrukturalna 2-3: SLM jako rozwiązanie do uwzględnienia w testach porównawczych. Skutek błędu 2-3: zatwierdzenie przez uprawnioną osobę, zabezpieczenia oparte na z góry ustalonych regułach i pełny rejestr działań, niezależnie od klasy modelu. Tabela pomaga wybrać rozwiązania do pilotażu. Ostateczną decyzję podejmuje się po porównaniu ich wyników na tym samym zbiorze rzeczywistych przypadków. 8. ChatGPT, zintegrowany LLM, SLM i automatyzacja: przykłady zastosowań w firmie Przykładowy proces Rekomendowana architektura Najważniejszy KPI Kontrola człowieka Pierwsza wersja treści marketingowej Firmowy asystent LLM Mediana oszczędności czasu i odsetek zaakceptowanych wyników Akceptacja każdej publikacji Podsumowanie spotkania i lista działań Firmowy asystent z dostępem do zatwierdzonego źródła Kompletność zadań i liczba korekt Weryfikacja właścicieli i terminów Odpowiedzi na pytania o procedury wewnętrzne Zintegrowany LLM z RAG i cytowaniem źródeł Odsetek odpowiedzi opartych na źródłach i poprawność odwołań do źródeł Eskalacja przy braku źródła Klasyfikacja zgłoszeń do stałych kolejek SLM lub klasyfikator, LLM dla wyjątków Macro-F1 i odsetek wykrytych zgłoszeń priorytetowych Weryfikacja przypadków budzących wątpliwości Analiza umów według firmowej listy ryzyk Zintegrowany LLM z RAG, regułami i logami Odsetek wykrytych oraz przeoczonych klauzul ryzykownych Decyzja prawnika Ekstrakcja pól z jednego typu faktury OCR, klasyczne ML lub SLM oraz walidator reguł Dokładność na poziomie pola i koszt przetworzenia dokumentu Kontrola wyjątków Przygotowanie oferty na podstawie CRM i cennika Zintegrowany LLM, RAG i pobieranie cen według z góry ustalonych reguł Czas przygotowania i odsetek korekt handlowych Akceptacja ceny i warunków Sprawdzenie prawa do zwrotu Reguły procesu Zgodność z polityką i czas decyzji Obsługa wyjątków Wykonanie zwrotu pieniędzy Workflow transakcyjny i autoryzacja 100% zgodności księgowej i pełny audyt Zależna od kwoty i ryzyka Lokalna analiza komunikatów maszyny SLM lub model specjalistyczny na edge Czas odpowiedzi p95, odsetek wykrytych alarmów i dostępność bez połączenia z internetem Eskalacja alarmów krytycznych Odebranie dostępu odchodzącemu pracownikowi IAM i deterministyczny workflow Kompletność odebranych uprawnień Zatwierdzenie według polityki Wieloetapowa obsługa sprawy klienta Agent AI z ograniczonym zestawem narzędzi Skuteczność realizacji zadań, poprawność użycia narzędzi i odsetek spraw przekazanych pracownikowi Punkty zatwierdzenia dla działań o wysokim wpływie 9. Jak mierzyć efekty wdrożenia AI? Wskaźniki jakości, czasu i kosztów Pomiar zaczyna się od obecnego procesu. Badanie Generative AI at Work, obejmujące 5 179 pracowników obsługi klienta, wykazało średni wzrost liczby rozwiązanych spraw na godzinę o 14%. Największą poprawę odnotowano u osób mniej doświadczonych. Tak zdefiniowana produktywność ma jasny licznik, mianownik i grupę odniesienia. Podobnej precyzji potrzebuje firmowy pilotaż. Obszar Wskaźnik Sposób pomiaru Skala Wolumen spraw Liczba przypadków miesięcznie, sezonowość i okresy największego obciążenia Czas Czas obsługi sprawy Średnia, mediana i p90 przed wdrożeniem oraz po nim Jakość Task success rate Odsetek przypadków spełniających wszystkie kryteria poprawnego wykonania zadania Użyteczność Odsetek wyników przyjętych bez zmian merytorycznych Odsetek wyników przyjętych bez zmiany merytorycznej Kontrola Odsetek decyzji AI zmienionych przez pracownika Odsetek decyzji lub propozycji zmienionych przez pracownika Ryzyko Częstotliwość błędów krytycznych Liczba błędów krytycznych na 1 000 lub 10 000 przypadków Klasyfikacja Precyzja, czułość i miara F1 Osobno dla każdej ważnej klasy, zwłaszcza rzadkich zdarzeń RAG Zgodność odpowiedzi ze źródłami Odsetek twierdzeń wspartych wskazanym, aktualnym źródłem Agent Poprawność wyboru narzędzi i przekazywanych parametrów Poprawny wybór narzędzia oraz poprawność przekazanych parametrów Automatyzacja Odsetek spraw obsłużonych w pełni automatycznie Odsetek spraw zakończonych bez ręcznej interwencji Wydajność Czas od rozpoczęcia zadania do uzyskania ostatecznego wyniku p50 i p95 od rozpoczęcia do ostatecznego wyniku Ekonomia Koszt poprawnie zakończonego zadania Pełny koszt podzielony przez liczbę poprawnych rezultatów Stabilność Zmiany jakości działania systemu w czasie Zmiana jakości według czasu, języka, kategorii i typu użytkownika Google Cloud wskazuje koszt poprawnie zakończonego zadania jako kluczowy miernik agentów AI działających w rzeczywistych procesach biznesowych. Model kosztujący 0,10 USD na uruchomienie i osiągający 50% skuteczności generuje sam koszt wywołań na poziomie 0,20 USD na poprawny wynik. Do rachunku dochodzą weryfikacja przez pracownika, ponowne próby, integracje, monitoring oraz koszt błędów. 10. Jak obliczyć ROI wdrożenia LLM lub SLM? Pełny koszt rozwiązania powinien obejmować budowę i integrację, model lub API, infrastrukturę, monitoring, aktualizacje, weryfikacja przez pracownika, poprawki oraz oczekiwaną stratę wynikającą z błędów. Koszt poprawnie zakończonego zadania: C_success = (koszt budowy przypisany do okresu + model/API + infrastruktura + monitoring + kontrola człowieka + poprawki + oczekiwana strata błędów) / liczba poprawnie zakończonych zadań Roczna korzyść: Korzyść = oszczędzony czas pracy + uniknięte poprawki i błędy + dodatkowa marża + uniknięte kary SLA ROI: ROI = (Korzyść – TCO rozwiązania AI) / TCO rozwiązania AI × 100% Załóżmy, że zespół klasyfikuje 20 000 zgłoszeń miesięcznie. Jedno zgłoszenie zajmuje średnio 4 minuty, a pełny koszt godziny pracy wynosi 120 zł. Miesięczny koszt ręcznej klasyfikacji wynosi około 160 000 zł. W pilotażu system osiąga 88% wyników zaakceptowanych bez korekty, weryfikacja jednego wyniku trwa średnio 45 sekund, poprawa pozostałych przypadków zajmuje 3 minuty, a miesięczne koszty modelu, infrastruktury, utrzymania i amortyzowanego wdrożenia wynoszą 51 000 zł. przegląd wszystkich przypadków: około 30 000 zł, poprawa 12% przypadków: około 14 400 zł, model, infrastruktura, utrzymanie i wdrożenie: 51 000 zł, łączny koszt procesu po wdrożeniu: około 95 400 zł, miesięczna różnica kosztu: około 64 600 zł, czyli 40,4%. To przykład metodologiczny z założonymi wartościami. W analizie opłacalności rzeczywistego wdrożenia trzeba uwzględnić zmianę kosztu błędów, sezonowość, czas przestojów, koszt obsługi wyjątków oraz tempo, w jakim pracownicy zaczynają korzystać z rozwiązania. Dla procesu generującego przychód rachunek powinien uwzględniać również zmianę marży, współczynnika konwersji albo wskaźnika utrzymania klientów 11. Jak przeprowadzić mierzalny pilotaż LLM lub SLM? Zapisz punkt odniesienia. Zmierz wolumen, czas, jakość, błędy, eskalacje i koszt obecnej metody przez co najmniej jeden pełny cykl biznesowy. Przygotuj zestaw przypadków testowych. Uwzględnij typowe zadania, trudne i rzadkie sytuacje, przypadki na granicy dopuszczalnych warunków oraz próby celowego wprowadzenia systemu w błąd. Google Cloud zaleca własny zbiór odzwierciedlający pełne spektrum użycia. Ustal progi przed testem. Zapisz minimalną jakość, maksymalny koszt, dopuszczalną latencję, limit błędów krytycznych i zasady eskalacji. Porównaj kilka wariantów. Uwzględnij obecny proces, mocny LLM, mniejszy model oraz architekturę hybrydową. Uruchom system w trybie obserwacyjnym (shadow mode). AI przygotowuje wyniki równolegle do dotychczasowego procesu. Decyzje i działania nadal przebiegają według obowiązujących zasad. Pozwala to wykryć błędy przed dopuszczeniem AI do obsługi rzeczywistych operacji. Uruchom system w ograniczonym zakresie. Rozpocznij od propozycji i zatwierdzeń. Zakres automatycznych działań rozszerzaj na podstawie wyników. Monitoruj jakość działania. Ponawiaj testy po zmianie modelu, instrukcji dla AI, narzędzi, źródeł danych, reguł lub rodzaju przetwarzanych materiałów. 11.1 Ile przypadków testowych potrzeba do oceny LLM lub SLM? Dla wskaźnika wyrażonego jako odsetek, przy poziomie ufności 95% i marginesie błędu +/-5 punktów procentowych, konserwatywna wielkość próby wynosi około 385 niezależnych przypadków. Margines +/-3 punkty procentowe wymaga około 1 068 przypadków. Próba reprezentatywna powinna zostać uzupełniona osobnym zestawem przypadków krytycznych i brzegowych. Przy rzadkich błędach istotna jest tak zwana reguła trzech. Jeżeli w 300 testach nie pojawi się żaden błąd krytyczny, przybliżona górna granica jego rzeczywistego prawdopodobieństwa na poziomie ufności 95% nadal wynosi około 1%. Zero błędów w 3 000 testów obniża tę granicę do około 0,1%. W procesach wysokiego ryzyka potrzebne są więc znacznie większe zbiory oraz testy ukierunkowane na konkretne zagrożenia. 11.2 Kiedy zakończyć pilotaż AI i uruchomić system w firmie? Przykładowe kryteria Proces Przykładowe kryteria przejścia do produkcji odsetek przypisań zmienionych przez pracownika do 8% Macro-F1 co najmniej 0,90; recall zgłoszeń priorytetowych co najmniej 0,99; override rate do 8%; p95 do 2 sekund Wewnętrzna baza wiedzy Acceptance rate co najmniej 85%; poprawność cytowań co najmniej 98%; brak niepopartych twierdzeń w zestawie krytycznym; p95 do 8 sekund Projekt oferty Mediana czasu niższa o co najmniej 30%; co najmniej 75% materiałów przyjętych z drobnymi zmianami; 100% cen pobranych z autoryzowanego źródła; zatwierdzenie człowieka dla każdej oferty Podane wartości są przykładem konstrukcji kryteriów. Właściciel procesu ustala progi zgodnie z kosztem błędu, wymaganą jakością i tolerancją ryzyka organizacji. 12. Jak dobrać zakres nadzoru człowieka do ryzyka związanego z AI? NIST definiuje ryzyko jako połączenie prawdopodobieństwa zdarzenia i skali jego konsekwencji. Ta zasada pozwala przełożyć ogólne obawy związane z AI na mierzalny model: częstotliwość błędów, wartość środków lub zasobów narażonych na stratę, możliwość cofnięcia działania, czas wykrycia błędu i koszt jego naprawy W skonsolidowanym tekście unijnego AI Act wymagania dla systemów wysokiego ryzyka obejmują ciągłe zarządzanie ryzykiem, odpowiedni poziom dokładności, odporności i cyberbezpieczeństwa oraz skuteczny nadzór człowieka. Środki nadzoru mają być proporcjonalne do ryzyka, poziomu autonomii i kontekstu użycia. Testy powinny korzystać z uprzednio zdefiniowanych metryk i progów właściwych dla zamierzonego zastosowania. W praktyce biznesowej oznacza to przypisanie konkretnej osoby do zatwierdzania, monitorowania i reagowania. Interfejs powinien pokazywać źródła, wykonane działania i poziom niepewności, a użytkownik musi mieć możliwość zatrzymania procesu. Ryzyko poważnych konsekwencji błędu uzasadnia ograniczenie uprawnień modelu, dodatkowe sprawdzanie wyników i dłuższe testy w trybie obserwacyjnym. Klasyfikację regulacyjną należy ustalić osobno dla zamierzonego zastosowania i roli organizacji. 13. Jak połączyć LLM, SLM i reguły w jednym procesie biznesowym? Połączenie kilku technologii pozwala dopasować sposób obsługi do poszczególnych etapów procesu. Przykładowo SLM rozpoznaje temat zgłoszenia klienta, a LLM przygotowuje odpowiedź na podstawie historii kontaktu i dokumentów pobranych przez RAG. Gdy sprawa dotyczy zwrotu pieniędzy, system sprawdza warunki i limity zgodnie z ustalonymi regułami, a następnie kieruje operację do realizacji lub zatwierdzenia przez uprawnionego pracownika. Tak zaprojektowana obsługa łączy automatyzację z kontrolą decyzji mających skutki finansowe. W TTMS pomożemy Ci ocenić, gdzie podobne rozwiązanie przyniesie największą korzyść. Zaczniemy od zadań, które pochłaniają najwięcej czasu: powtarzalnych czynności, wyszukiwania informacji czy poprawiania błędów. Podczas konsultacji przeanalizujemy przebieg pracy, dostępne dane i wykorzystywane systemy. Na tej podstawie zaproponujemy technologię i zakres pilotażu, a wspólnie z Tobą ustalimy oczekiwane efekty oraz sposób pomiaru jakości, czasu i kosztów. Chcesz wybrać pierwszy proces do usprawnienia? Umów się z nami na konsultację dotyczącą wdrożenia AI. Źródła Eurostat, 20% of EU enterprises use AI technologies, 11 grudnia 2025. Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality, Organization Science. Erik Brynjolfsson, Danielle Li, Lindsey Raymond, Generative AI at Work, NBER Working Paper 31161, 2023. Joel Becker, Nate Rush, Beth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 lipca 2025. Microsoft Azure, What Are Small Language Models (SLMs)?. Microsoft Azure, Boost processing performance by combining AI models, 8 stycznia 2025. OpenAI, Enterprise privacy at OpenAI. Google Cloud, The KPIs that actually matter for production AI agents, 26 lutego 2026. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, lipiec 2024. Unia Europejska, Rozporządzenie (UE) 2024/1689, tekst skonsolidowany z 27 lipca 2026. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025. FAQ Czy do pracy na danych firmowych trzeba uruchamiać własny model AI? Własny model jest jednym z dostępnych wariantów. Firmy mogą korzystać z zatwierdzonego środowiska biznesowego, zarządzanego API, prywatnej chmury, wydzielonej infrastruktury lub modelu działającego lokalnie. Wybór zależy od klasy danych, lokalizacji przetwarzania, retencji, szyfrowania, tożsamości użytkowników, wymogów branżowych i umowy z dostawcą. Przykładowo OpenAI deklaruje brak domyślnego trenowania na danych klientów biznesowych i oferuje dodatkowe mechanizmy kontroli retencji dla kwalifikujących się klientów API. Organizacja powinna udokumentować przepływ danych dla konkretnej konfiguracji, ponieważ nazwa modelu nie opisuje całej architektury bezpieczeństwa. Czy RAG może zastąpić fine-tuning modelu na danych firmy? RAG i fine-tuning rozwiązują różne problemy. RAG pobiera aktualne informacje z kontrolowanego źródła w momencie tworzenia odpowiedzi, dzięki czemu dobrze pasuje do baz wiedzy, procedur, dokumentacji i treści często aktualizowanych. Fine-tuning dostosowuje zachowanie modelu do przykładów, stylu, formatu albo wyspecjalizowanego zadania. Dokumentacja AWS porównująca RAG i fine-tuning rekomenduje rozpoczęcie systemu pytań i odpowiedzi na własnych dokumentach od RAG, zwłaszcza gdy ważne są aktualność i odwołania do źródeł. Oba mechanizmy mogą działać razem, jeśli proces wymaga zarówno aktualnej wiedzy, jak i stabilnego zachowania domenowego. Czy jeden proces może korzystać jednocześnie z LLM i SLM? Tak. Router może kierować typowe, dobrze rozpoznane sprawy do SLM, a przypadki złożone do większego LLM. Trzecia ścieżka prowadzi do człowieka, gdy system wykryje brak danych, niską pewność albo wysoki poziom ryzyka. Innym wariantem jest podział procesu według funkcji: SLM klasyfikuje dokument, LLM przygotowuje wyjaśnienie, kod oblicza wartości, a workflow zapisuje zatwierdzoną decyzję. Taki układ pozwala kontrolować koszty i czas reakcji przy zachowaniu dostępu do większych możliwości w trudniejszych sprawach. Ile przykładów potrzeba do pilotażu LLM lub SLM? Liczba zależy od oczekiwanej precyzji pomiaru i rzadkości błędów. Dla odsetka skutecznych odpowiedzi próba około 385 niezależnych przypadków daje przybliżony margines +/-5 punktów procentowych przy poziomie ufności 95% w wariancie konserwatywnym. Margines +/-3 punkty wymaga około 1 068 przypadków. Losowa próba powinna odzwierciedlać rzeczywisty wolumen, języki, kanały i typy użytkowników. Osobny zestaw powinien obejmować przypadki krytyczne, brzegowe, rzadkie oraz próby manipulacji systemem. Jak często trzeba ponownie testować aplikację opartą na modelu językowym? Pełna ewaluacja powinna zostać uruchomiona po zmianie modelu, wersji promptu, narzędzia, uprawnień, źródła danych, reguł biznesowych lub formatu wejścia. Produkcja wymaga również ciągłego monitorowania najważniejszych KPI oraz cyklicznego testu regresji. Częstotliwość zależy od ryzyka i tempa zmian procesu. Aplikacja obsługująca treści marketingowe może mieć inny harmonogram niż system wspierający decyzje finansowe. Praktycznym rozwiązaniem jest automatyczny test przy każdej zmianie technicznej, miesięczny przegląd trendów oraz kwartalna ewaluacja biznesowa, z krótszym cyklem dla zastosowań wysokiego ryzyka.

    Czytaj więcej
    Jak przygotować dane do Copilota w Power BI i zbudować model semantyczny gotowy na AI

    Jak przygotować dane do Copilota w Power BI i zbudować model semantyczny gotowy na AI

    Copilot może przyspieszyć analizę danych, tworzenie wizualizacji i pracę z modelem semantycznym. Nie zastępuje jednak uporządkowanych źródeł, prawidłowych relacji ani uzgodnionych definicji wskaźników. Jeżeli model zawiera kilka podobnych miar sprzedaży, techniczne nazwy kolumn i niejednoznaczne relacje, asystent AI otrzymuje ten sam problem, z którym wcześniej mierzyli się użytkownicy raportów. Różnica polega na tym, że odpowiedź wygenerowana w naturalnym języku może brzmieć przekonująco nawet wtedy, gdy została oparta na niewłaściwej metryce. Dlatego przygotowanie danych do Copilota w Power BI powinno być traktowane jako praca nad jakością modelu, kontekstem biznesowym i zasadami korzystania z danych. Samo udostępnienie funkcji Copilot nie sprawi, że niespójny model stanie się jednoznaczny. Potrzebne są czytelne nazwy, zweryfikowane miary, kontrolowany zakres danych, odpowiednie uprawnienia oraz zestaw testów odpowiadających rzeczywistym pytaniom użytkowników. W tym artykule wyjaśniamy, jak przygotować dane i model semantyczny Power BI do pracy z Copilotem, jak korzystać z funkcji Prep data for AI oraz jak ocenić gotowość rozwiązania przed udostępnieniem go pracownikom. Materiał koncentruje się na wdrożeniu i utrzymaniu jakości. Ogólne możliwości asystenta opisuje odrębny artykuł TTMS poświęcony AI i Copilotowi w Power BI. 1. Power BI gotowy na AI Model gotowy na AI pozwala użytkownikowi zadawać pytania w języku biznesowym bez konieczności znajomości technicznych nazw tabel i kolumn. Nie oznacza to, że Copilot zna organizację lub sam odkryje wszystkie reguły obowiązujące w firmie. Potrafi korzystać z informacji udostępnionych przez model, jego metadane, konfigurację funkcji AI oraz kontekst raportu. Jakość tej warstwy wpływa na to, czy pytanie o „sprzedaż” zostanie powiązane z oficjalną miarą przychodu netto, wartością zamówień czy innym polem o podobnej nazwie. Gotowość modelu należy oceniać w pięciu obszarach: jakość i aktualność danych źródłowych; poprawność oraz prostota modelu semantycznego; jednoznaczność pojęć, nazw i miar biznesowych; bezpieczeństwo, uprawnienia i odpowiedzialność za dane; powtarzalny proces testowania odpowiedzi Copilota. Jeżeli któryś z tych obszarów nie został przygotowany, samo dopracowywanie promptów przyniesie ograniczony efekt. Użytkownik może dokładniej sformułować pytanie, ale nadal nie wie, która z trzech miar marży jest oficjalna ani dlaczego jedna tabela używa daty zamówienia, a inna daty faktury. 2. Dlaczego model semantyczny decyduje o jakości odpowiedzi Model semantyczny stanowi warstwę pomiędzy danymi źródłowymi a użytkownikiem raportu. Zawiera tabele, kolumny, miary, relacje, formaty, hierarchie i reguły bezpieczeństwa. Dla Copilota jest podstawowym źródłem informacji o tym, jak dane są zorganizowane i jak należy je interpretować. Asystent może wykorzystać między innymi schemat modelu, relacje, właściwości obiektów, typy danych, formaty oraz wybrane metadane. Nie powinien jednak zgadywać definicji, które w organizacji mają szczególne znaczenie. Jeżeli „aktywny klient” oznacza klienta, który dokonał zakupu w ciągu ostatnich 90 dni, definicja powinna być zapisana w modelu i używana przez oficjalną miarę. Pozostawienie kilku możliwych interpretacji zwiększa ryzyko wyboru niewłaściwej. 2.1 Przykład niejednoznacznego modelu Załóżmy, że w modelu znajdują się miary „Sales”, „Total Sales”, „Net Sales” i „Sales Adjusted”. Dla analityka, który zna projekt, różnice mogą być oczywiste. Użytkownik biznesowy i Copilot widzą natomiast cztery prawdopodobne odpowiedzi na pytanie „Jaka była sprzedaż w ubiegłym kwartale?”. Naprawa nie polega jedynie na dopisaniu instrukcji, że Copilot ma wybierać jedną z miar. Najpierw warto ustalić oficjalną definicję, nadać jej czytelną nazwę, opisać sposób liczenia, ukryć pola techniczne i usunąć nieużywane obiekty. Instrukcja AI może następnie doprecyzować kontekst, ale nie powinna zastępować porządku w modelu. 3. Wymagania techniczne przed rozpoczęciem pracy Przed przebudową modelu należy sprawdzić, czy środowisko spełnia aktualne wymagania Microsoftu. Dostępność Copilota zależy od ustawień dzierżawy, uprawnień, obszaru roboczego oraz przypisanej pojemności. Wymagania mogą różnić się między Power BI Desktop, usługą Power BI i poszczególnymi doświadczeniami Copilot. Na dzień przygotowania artykułu dokumentacja Microsoft dotycząca wymagań Copilota w Power BI wskazuje między innymi na potrzebę włączenia odpowiedniego ustawienia dzierżawy oraz korzystania z obsługiwanej płatnej pojemności Fabric albo Power BI Premium. Autor modelu potrzebuje również właściwych uprawnień do obszaru roboczego i modelu semantycznego. Prep data for AI jest obecnie funkcją w wersji zapoznawczej. Przed jej wdrożeniem trzeba uwzględnić aktualne ograniczenia, w tym wymaganie włączenia Power BI Q&A oraz obsługiwane typy połączeń w Power BI Desktop. Obszar Co trzeba sprawdzić Dlaczego ma to znaczenie Pojemność Czy obszar roboczy korzysta z obsługiwanej płatnej pojemności Fabric lub Power BI Premium Bez właściwej pojemności wybrane doświadczenia Copilot mogą być niedostępne Ustawienia dzierżawy Czy administrator włączył korzystanie z Copilota i funkcji opartych na Azure OpenAI dla odpowiednich grup Dostęp powinien być nadany świadomie i zgodnie z polityką organizacji Uprawnienia Czy autor ma prawa do edycji modelu i publikacji w docelowym obszarze roboczym Konfiguracja modelu wymaga uprawnień odpowiednich dla danego środowiska Typ połączenia Czy sposób połączenia jest obsługiwany przez używaną funkcję w Desktop lub usłudze Zakres obsługi różni się między narzędziami i może się zmieniać Power BI Q&A Czy funkcja Q&A jest włączona dla modelu Jest to obecnie jedno z wymagań funkcji Prep data for AI Wymagań licencyjnych i funkcjonalnych nie należy utrwalać w wewnętrznej instrukcji raz na zawsze. Microsoft rozwija Copilota i zmienia dostępność poszczególnych doświadczeń. Przed wdrożeniem warto sprawdzić aktualną dokumentację oraz ustawienia własnej dzierżawy. 4. Przygotowanie danych do Copilota w Power BI Dane powinny być wiarygodne jeszcze przed załadowaniem ich do modelu. Copilot nie naprawi brakujących rekordów, błędnego mapowania klientów ani niespójnych kodów walut. Może natomiast wykorzystać te dane do wygenerowania odpowiedzi, która ukryje problem pod poprawnie brzmiącym opisem. 4.1 Jakość danych źródłowych Pierwszy etap obejmuje profilowanie i kontrolę danych. Należy sprawdzić kompletność, unikalność, spójność, aktualność i zgodność wartości z regułami biznesowymi. Kontrole powinny być powtarzalne, a nie wykonywane wyłącznie przed pierwszą publikacją. W praktyce oznacza to między innymi: identyfikację brakujących kluczy oraz rekordów osieroconych; kontrolę duplikatów w tabelach wymiarów; uzgodnienie stref czasowych, kalendarzy, walut i jednostek; sprawdzenie, czy wartości statusów mają wspólne znaczenie we wszystkich systemach; określenie właściciela danych i sposobu obsługi błędów jakościowych; monitorowanie świeżości danych oraz nieudanych odświeżeń. Każda oficjalna metryka powinna mieć określone źródło, właściciela, częstotliwość aktualizacji i regułę obliczeniową. Dzięki temu odpowiedź Copilota można porównać z wartością referencyjną, zamiast oceniać ją wyłącznie na podstawie tego, czy brzmi logicznie. 4.2 Przyjazne nazwy i stabilne definicje Nazwy techniczne, takie jak „fct_sales_hdr”, „cust_id” czy „rev_net_adj”, zwiększają koszt korzystania z modelu przez człowieka i utrudniają interpretację intencji pytania. W warstwie semantycznej warto stosować nazwy odpowiadające językowi organizacji, na przykład „Sprzedaż”, „Klient”, „Przychód netto” i „Region sprzedaży”. Sama czytelność nie wystarcza. Nazwa „Marża” nadal jest niejednoznaczna, jeżeli firma używa marży kwotowej, procentowej, planowanej i skorygowanej. Każda z tych miar powinna mieć precyzyjną nazwę i definicję. Jeżeli jedna miara ma status oficjalnej, model powinien to odzwierciedlać przez nazewnictwo, opis, organizację folderów oraz ograniczenie widoczności pól pomocniczych. 4.3 Poprawne typy danych i formaty Typ danych informuje model, czy wartość jest datą, liczbą, tekstem lub kategorią. Format wskazuje sposób prezentacji, na przykład walutę, procent albo liczbę dziesiętną. Błędny typ może uniemożliwić prawidłowe grupowanie i obliczenia, a niejednoznaczny format może prowadzić do błędnej interpretacji wyniku przez użytkownika. Warto również wskazać kategorie danych tam, gdzie mają znaczenie, na przykład dla adresów, miast i kodów geograficznych. Model powinien jasno rozróżniać datę zamówienia, wystawienia faktury, wysyłki i płatności. Jedna oznaczona tabela kalendarza oraz jawne miary ograniczają liczbę przypadkowych interpretacji. 5. Model semantyczny zrozumiały dla Copilota Samouczek Microsoft dotyczący przygotowania modelu semantycznego dla AI zaleca między innymi stosowanie schematu gwiazdy, czytelnych nazw i ograniczanie złożoności. Nie oznacza to, że każdy model musi wyglądać identycznie. Chodzi o to, aby relacje, role tabel i definicje miar były jednoznaczne. 5.1 Schemat gwiazdy W schemacie gwiazdy tabele faktów przechowują zdarzenia lub wartości liczbowe, a tabele wymiarów opisują kontekst, taki jak klient, produkt, czas i region. Taka struktura ułatwia użytkownikowi oraz mechanizmom AI odróżnienie tego, co jest mierzone, od sposobu podziału wyniku. Rozbudowany model płatka śniegu, wiele tabel pomocniczych i kilka możliwych ścieżek filtrowania mogą być uzasadnione technicznie, ale zwiększają złożoność interpretacji. Jeżeli nie można uprościć modelu fizycznie, warto ograniczyć zakres udostępniany Copilotowi przez AI data schema. 5.2 Relacje i kierunki filtrowania Relacje powinny odwzorowywać rzeczywistą logikę danych. Należy zweryfikować ich kardynalność, aktywność i kierunek filtrowania. Relacje dwukierunkowe oraz wiele alternatywnych ścieżek mogą prowadzić do nieoczekiwanych wyników, zwłaszcza gdy pytanie nie określa szczegółowego kontekstu. Nieaktywne relacje i specjalne reguły stosowane w wybranych miarach należy dokumentować. Jeżeli analiza sprzedaży według daty wysyłki wymaga innej logiki niż analiza według daty zamówienia, użytkownik powinien wiedzieć, jak sformułować pytanie, a model powinien oferować jednoznaczne miary. 5.3 Jawne miary DAX Jawne miary DAX pozwalają zapisać zatwierdzoną logikę biznesową w jednym miejscu. Są bezpieczniejszą podstawą odpowiedzi niż przypadkowe agregowanie kolumn liczbowych. Miara powinna mieć czytelną nazwę, prawidłowy format, opis i właściciela biznesowego. Przed udostępnieniem modelu Copilotowi warto sprawdzić: czy oficjalne wskaźniki są zdefiniowane jako miary; czy nie występują duplikaty o podobnych nazwach; czy format wyniku odpowiada znaczeniu biznesowemu; czy miary działają prawidłowo dla różnych filtrów i poziomów agregacji; czy pola techniczne oraz miary pomocnicze są ukryte przed użytkownikami; czy wyniki zostały uzgodnione z raportami referencyjnymi. 6. Funkcja Prep data for AI w Power BI Prep data for AI jest zestawem narzędzi zapisujących konfigurację na poziomie modelu semantycznego, a nie pojedynczego raportu. To istotne, ponieważ jeden model może zasilać wiele raportów. Zmiana schematu AI lub instrukcji może więc wpływać na więcej niż jeden scenariusz użycia. Microsoft opisuje cztery elementy przygotowania modelu do przetwarzania języka naturalnego: AI data schema (schemat danych AI), verified answers (zweryfikowane odpowiedzi), AI instructions (instrukcje AI) oraz opisy. Poszczególne elementy nie działają jednak identycznie we wszystkich doświadczeniach Copilot. Dlatego konfigurację trzeba testować w tych samych miejscach, w których będą pracowali użytkownicy. Mechanizm Zastosowanie Kiedy jest szczególnie potrzebny Czego nie zastępuje AI data schema Określa podzbiór tabel, kolumn i miar przekazywany Copilotowi Gdy model jest duży lub zawiera pola techniczne i podobne miary Porządkowania danych oraz poprawnych relacji Verified answers Łączy zatwierdzoną wizualizację z frazami uruchamiającymi Dla częstych lub niejednoznacznych pytań wymagających spójnej interpretacji Testowania danych źródłowych i kontroli dostępu AI instructions Przekazuje reguły, definicje i kontekst biznesowy Gdy organizacja używa pojęć, których znaczenia nie da się wywnioskować z nazw pól Oficjalnych miar i jednoznacznego modelu Opisy Dokumentują znaczenie tabel, kolumn i miar Gdy nazwa obiektu nie wyjaśnia w pełni jego zastosowania Instrukcji obejmujących reguły całej domeny 6.1 AI data schema AI data schema ogranicza część modelu, którą Copilot bierze pod uwagę podczas odpowiadania na pytania o dane. Nie należy automatycznie udostępniać całego schematu. Tabele techniczne, pola kluczy, nieużywane miary i obiekty przeznaczone wyłącznie do obsługi raportu zwiększają liczbę możliwych interpretacji. Dobrze zaprojektowany schemat AI powinien obejmować oficjalne wymiary, zatwierdzone miary i pola potrzebne do najczęstszych analiz. Zakres należy sprawdzić z właścicielami procesów biznesowych. Zbyt wąski schemat uniemożliwi odpowiedź na uzasadnione pytania, a zbyt szeroki może zwiększyć niejednoznaczność. 6.2 Zweryfikowane odpowiedzi Verified answers pozwalają powiązać zatwierdzoną wizualizację z określonymi frazami uruchamiającymi. Mechanizm jest przydatny, gdy użytkownicy często pytają o ten sam wskaźnik lub używają kilku określeń o podobnym znaczeniu. Przykładem może być pytanie o „sprzedaż według obszaru”. Dla jednej organizacji „obszar” oznacza region geograficzny, a dla innej grupę produktową. Zweryfikowana odpowiedź może skierować właściwe sformułowania do wcześniej sprawdzonej wizualizacji. Nie zwalnia to jednak z testowania samej miary, filtrów i uprawnień. Dla każdej zweryfikowanej odpowiedzi warto zapisać właściciela, obsługiwane pytania, źródło metryki i datę ostatniego przeglądu. Zmiana definicji wskaźnika albo struktury raportu powinna uruchamiać ponowną walidację. 6.3 Instrukcje AI AI instructions przekazują Copilotowi kontekst, którego nie da się łatwo wyrazić samą strukturą modelu. Mogą wyjaśniać terminologię organizacji, preferowane miary, reguły interpretacji okresów i powiązania pomiędzy pojęciami. Instrukcja może na przykład wskazywać, że „aktywny klient” oznacza klienta z zakupem w ostatnich 90 dniach, a „sezon wysoki” obejmuje miesiące od czerwca do sierpnia. Powinna używać konkretnych nazw obiektów modelu i krótkich, testowalnych reguł. Instrukcje nie są mechanizmem bezpieczeństwa i nie gwarantują bezwzględnego przestrzegania każdej reguły. Microsoft zaznacza, że model językowy interpretuje je jako wskazówki. Dlatego ważne definicje finansowe i operacyjne należy nadal implementować w miarach, relacjach i procesach zarządzania danymi. 6.4 Opisy tabel kolumn i miar Opisy powinny wyjaśniać znaczenie obiektu, sposób jego użycia oraz istotne ograniczenia. Zamiast „wartość sprzedaży” lepiej zapisać, że miara przedstawia przychód netto po rabatach i zwrotach, w walucie raportowej, według daty faktury. Według aktualnej dokumentacji Microsoftu opisy nie wpływają w jednakowy sposób na wszystkie możliwości Copilota. Są wykorzystywane między innymi w wybranych scenariuszach wyszukiwania i zapytań DAX. Mimo tego warto je uzupełniać, ponieważ poprawiają dokumentację modelu i przygotowują go do dalszego rozwoju funkcji AI. 7. Kontekst biznesowy dla Copilota Model może być technicznie poprawny, a mimo to nie odpowiadać językowi używanemu przez firmę. Dział sprzedaży może mówić o „kliencie aktywnym”, finanse o „przychodzie rozpoznanym”, a operacje o „zamówieniu zamkniętym”. Każde z tych pojęć wymaga definicji oraz właściciela. Dobrym punktem wyjścia jest słownik biznesowy obejmujący: nazwę pojęcia i jego dopuszczalne synonimy; definicję zaakceptowaną przez właściciela biznesowego; odpowiadającą tabelę, kolumnę lub miarę w Power BI; regułę czasu, waluty, zakresu i agregacji; wyjątki oraz przypadki, w których wskaźnika nie należy używać; osobę odpowiedzialną za zatwierdzanie zmian. Słownik nie powinien istnieć wyłącznie poza Power BI. Najważniejsze informacje trzeba przenieść do nazw, opisów, miar, AI instructions i verified answers. W przeciwnym razie użytkownicy i Copilot nadal będą pracowali z niepełnym kontekstem. 8. Bezpieczeństwo i governance danych Udostępnienie Copilota zwiększa łatwość zadawania pytań, ale nie zmienia podstawowej zasady: użytkownik powinien mieć dostęp wyłącznie do danych potrzebnych w jego roli. Należy sprawdzić uprawnienia do obszarów roboczych i modeli, role RLS, zabezpieczenia na poziomie obiektów, grupy Microsoft Entra oraz sposób udostępniania raportów i modeli. Przy projektowaniu kontroli warto odnieść się również do zasad prywatności, bezpieczeństwa i odpowiedzialnego korzystania z Copilota w Microsoft Fabric. Szczególnej uwagi wymagają uprawnienia do zapisu. W Power BI sposób egzekwowania zabezpieczeń na poziomie wiersza zależy między innymi od roli użytkownika i jego uprawnień do modelu. Testy powinny obejmować konta reprezentujące rzeczywiste role, a nie wyłącznie konto autora lub administratora. Warto również sprawdzić, czy nazwy obiektów, opisy i metadane raportu nie ujawniają informacji, których użytkownik nie powinien poznawać. Dokumentacja Microsoftu dotycząca korzystania z Copilota z modelami semantycznymi wskazuje, że w Power BI Desktop metadane bieżącej strony raportu mogą w określonych sytuacjach służyć jako dane ugruntowujące i zawierać wartości danych. Ocena bezpieczeństwa powinna więc obejmować zarówno rekordy, jak i warstwę opisową modelu. Governance powinno określać: kto może przygotowywać model do użycia przez AI; kto zatwierdza definicje i zweryfikowane odpowiedzi; które modele mogą zostać oznaczone jako zatwierdzone dla Copilota; jak często przeprowadza się testy regresji; jak zgłaszane i analizowane są błędne odpowiedzi; kiedy zmiana modelu wymaga ponownego zatwierdzenia. 9. Testowanie odpowiedzi Copilota Test nie powinien polegać na zadaniu jednego przykładowego pytania. Potrzebny jest zestaw scenariuszy odzwierciedlających język i potrzeby użytkowników. Dla każdego pytania należy określić oczekiwaną miarę, zakres filtrów, źródło wartości referencyjnej oraz dopuszczalny sposób prezentacji. Rodzaj testu Przykład Co należy ocenić Pytanie podstawowe Jaka była sprzedaż netto w poprzednim miesiącu Dobór miary, okresu i formatu wartości Synonim Pokaż obrót według regionu Czy język użytkownika został poprawnie powiązany z oficjalnym pojęciem Pytanie niejednoznaczne Pokaż wynik dla obszaru Czy Copilot prosi o doprecyzowanie albo wybiera zatwierdzoną interpretację Filtry złożone Sprzedaż klientów z sektora produkcyjnego w Polsce w ostatnim kwartale Poprawność wszystkich filtrów i relacji Uprawnienia To samo pytanie zadane przez użytkowników z różnych regionów Czy każdy użytkownik widzi wyłącznie dozwolony zakres danych Odporność na zmianę Powtórzenie testów po zmianie miary lub relacji Czy aktualizacja nie pogorszyła wcześniejszych odpowiedzi Ocena powinna obejmować zarówno wynik liczbowy, jak i sposób dojścia do odpowiedzi. W dostępnych doświadczeniach warto korzystać z funkcji diagnostycznych, takich jak informacje o tym, jak Copilot utworzył odpowiedź. Nie należy jednak uznawać samego wyjaśnienia mechanizmu za dowód poprawności wyniku. Ostatecznym punktem odniesienia pozostaje zatwierdzona metryka i kontrolowany zestaw danych. Copilot generuje odpowiedzi niedeterministycznie. To oznacza, że ten sam prompt i te same dane mogą prowadzić do różniących się rezultatów. W niektórych doświadczeniach identyczne pytanie zadane w ciągu 24 godzin przy niezmienionym modelu może jednak zwrócić odpowiedź z pamięci podręcznej. Celem testów nie jest więc udowodnienie, że każda odpowiedź zawsze będzie identyczna. Testy mają wykazać, że model kieruje Copilota do właściwych danych, typowe pytania otrzymują poprawne odpowiedzi, a ryzyka i ograniczenia są znane użytkownikom. 10. Najczęstsze błędy podczas przygotowania Power BI do AI 10.1 Włączenie Copilota przed uporządkowaniem modelu Zespół koncentruje się na licencji i ustawieniach, ale nie przegląda nazw, relacji i miar. Copilot zostaje udostępniony na modelu, który już wcześniej sprawiał trudności analitykom. Efektem są niejednoznaczne odpowiedzi oraz szybka utrata zaufania użytkowników. 10.2 Udostępnienie całego schematu Do AI data schema trafiają wszystkie tabele i pola, w tym klucze techniczne, miary pomocnicze oraz obiekty nieużywane. Większa liczba elementów nie oznacza pełniejszego kontekstu. W rozbudowanym modelu może utrudnić wybór właściwego pola. 10.3 Traktowanie instrukcji AI jako zamiennika modelowania Instrukcje próbują wyjaśnić dziesiątki wyjątków, które powinny zostać zapisane w miarach i regułach modelu. Taki dokument jest trudny do testowania i utrzymania. Im ważniejsza reguła, tym bardziej powinna być egzekwowana przez model lub proces danych, a nie jedynie opisana językiem naturalnym. 10.4 Brak właścicieli metryk Analitycy przygotowują verified answers bez formalnego potwierdzenia, która definicja wskaźnika jest obowiązująca. W razie rozbieżności nie wiadomo, kto może zaakceptować zmianę ani jaka wartość stanowi punkt odniesienia. 10.5 Testowanie wyłącznie przez autorów Autor modelu zna nazwy i strukturę danych, dlatego formułuje pytania w sposób zgodny z projektem. Użytkownicy biznesowi używają skrótów, synonimów i niepełnych określeń. Testy powinny obejmować rzeczywiste pytania zebrane od przyszłych użytkowników. 10.6 Brak testów po zmianach Zmiana definicji miary, relacji, nazwy pola lub raportu może wpłynąć na wcześniejsze scenariusze. Bez testów regresji organizacja nie wie, czy model nadal jest gotowy do użycia przez Copilota. 11. Checklista gotowości modelu Power BI do Copilota [ ] Zidentyfikowaliśmy właścicieli danych, modeli i kluczowych metryk. [ ] Dane źródłowe przechodzą powtarzalne kontrole jakości i świeżości. [ ] Oficjalne wskaźniki mają jednoznaczne definicje oraz jawne miary DAX. [ ] Nazwy tabel, kolumn i miar odpowiadają językowi biznesowemu. [ ] Pola techniczne, nieużywane i pomocnicze są ukryte lub usunięte z zakresu AI. [ ] Typy danych, formaty, kategorie oraz tabela kalendarza są poprawnie skonfigurowane. [ ] Relacje mają właściwą kardynalność i nie tworzą niejednoznacznych ścieżek filtrowania. [ ] Zdefiniowaliśmy AI data schema obejmujący wyłącznie potrzebne obiekty. [ ] Najczęstsze i najbardziej niejednoznaczne pytania mają zweryfikowane odpowiedzi. [ ] AI instructions opisują terminologię i reguły, których nie da się odczytać ze struktury modelu. [ ] Tabele, kolumny i miary posiadają przydatne opisy. [ ] Zweryfikowaliśmy ustawienia dzierżawy, pojemność, licencje i aktualne ograniczenia funkcji. [ ] Przetestowaliśmy role RLS, uprawnienia i dostęp do modeli na kontach użytkowników testowych. [ ] Zestaw testów obejmuje pytania podstawowe, synonimy, niejednoznaczności i złożone filtry. [ ] Wyniki Copilota są porównywane z zatwierdzonymi raportami lub wartościami referencyjnymi. [ ] Określiliśmy proces zgłaszania błędnych odpowiedzi i ponownej walidacji modelu. [ ] Jeśli organizacja korzysta z dostępnego obecnie w wersji zapoznawczej ustawienia Approved for Copilot, model jest oznaczany dopiero po zakończeniu testów. 12. Jak przygotować organizację do korzystania z Copilota Gotowy model nie wystarczy, jeżeli użytkownicy nie wiedzą, jak interpretować odpowiedzi. Wdrożenie powinno obejmować krótkie szkolenie, przykładowe pytania, wyjaśnienie zakresu danych i zasady weryfikacji wyników. Należy jasno wskazać, które scenariusze mają charakter wspierający, a które wymagają kontroli analityka lub właściciela procesu. Dobrym rozwiązaniem jest pilotaż na jednym modelu o dobrze zdefiniowanym zakresie. Pozwala zebrać pytania użytkowników, ocenić niejednoznaczności i zbudować zestaw testów przed rozszerzeniem funkcji na kolejne obszary. Pilotaż powinien mieć kryteria zakończenia, na przykład poprawność najważniejszych scenariuszy, akceptację właścicieli metryk i brak krytycznych problemów z uprawnieniami. Po uruchomieniu warto monitorować wykorzystanie, koszt pojemności, zgłoszenia użytkowników oraz zmiany w dokumentacji Microsoftu. Gotowość modelu do pracy z AI wymaga stałego monitorowania i ponownych testów po istotnych zmianach. 13. Dlaczego TTMS Przygotowanie Power BI do pracy z Copilotem wymaga połączenia kompetencji z zakresu integracji danych, modelowania semantycznego, Power BI, Microsoft Fabric, bezpieczeństwa i adopcji użytkowników. Skupienie się wyłącznie na interfejsie Copilota nie rozwiązuje problemów znajdujących się w źródłach, transformacjach i definicjach biznesowych. Zakres współpracy z TTMS może obejmować ocenę gotowości istniejących modeli, uporządkowanie warstwy danych, przebudowę relacji i miar oraz przygotowanie testów. Konfigurację Prep data for AI warto poprzedzić potwierdzeniem wymagań środowiska i uzgodnieniem zakresu prac. Współpraca może dotyczyć pojedynczego modelu pilotażowego albo programu obejmującego wiele domen i zespołów. Praktyczny model współpracy może obejmować: Inwentaryzację źródeł, modeli, raportów i grup użytkowników. Ocenę jakości danych, architektury modelu oraz ryzyka niejednoznacznych odpowiedzi. Uzgodnienie oficjalnych wskaźników i słownika pojęć biznesowych. Optymalizację modelu semantycznego oraz konfigurację AI data schema, verified answers i AI instructions. Testy funkcjonalne, regresyjne, bezpieczeństwa i wydajności. Przygotowanie zasad governance, dokumentacji oraz materiałów dla użytkowników. Utrzymanie modeli i ponowną walidację po zmianach danych lub funkcji Microsoftu. Rezultatem powinien być model, którego struktura jest czytelna dla analityków i użytkowników biznesowych, a odpowiedzi Copilota można oceniać względem zatwierdzonych definicji. Celem jest ograniczenie niejednoznaczności i wprowadzenie procesu kontroli jakości. Nawet dobrze przygotowany model nie gwarantuje bezbłędnych odpowiedzi generatywnej AI. 14. Rozmowa o gotowości Power BI do AI Jeżeli Twoja organizacja korzysta z Power BI i planuje udostępnić Copilota, warto rozpocząć od przeglądu danych oraz modeli semantycznych. TTMS może pomóc określić zakres pilotażu, wskazać luki i przygotować roadmapę prac od źródeł danych do testów użytkowników. Skontaktuj się z TTMS, aby omówić przygotowanie środowiska Power BI i Microsoft Fabric do bezpiecznego wykorzystania funkcji AI. 15. FAQ Kto powinien być właścicielem modelu semantycznego przygotowanego dla Copilota? Model semantyczny powinien mieć jasno określonych właścicieli odpowiedzialnych za jakość danych, definicje wskaźników biznesowych oraz utrzymanie modelu. Dzięki temu zmiany w danych, procesach i raportowaniu mogą być kontrolowane, a odpowiedzi Copilota pozostają zgodne z aktualnymi definicjami biznesowymi. Jak duży powinien być AI data schema w Power BI? AI data schema powinien obejmować wyłącznie te tabele, kolumny i miary, które są potrzebne do realizacji najczęściej zadawanych pytań biznesowych. Zbyt szeroki zakres zwiększa ryzyko niejednoznacznych odpowiedzi, natomiast zbyt wąski może ograniczyć możliwości Copilota i uniemożliwić analizę części danych. Czy Copilot może rozumieć pojęcia biznesowe, których nie ma bezpośrednio w modelu danych? Tak, częściowo. Kontekst można przekazywać za pomocą opisów, AI instructions, verified answers i odpowiednio nazwanych miar. Najważniejsze pojęcia biznesowe powinny jednak być odwzorowane bezpośrednio w modelu semantycznym, ponieważ zwiększa to dokładność interpretacji i zmniejsza ryzyko błędnych odpowiedzi. Kiedy należy ponownie zweryfikować model Power BI pod kątem Copilota? Model warto ponownie zweryfikować po każdej istotnej zmianie dotyczącej źródeł danych, definicji KPI, relacji, uprawnień, konfiguracji AI lub funkcji Microsoft Copilot. Regularne testy regresji pomagają potwierdzić, że wcześniej poprawne scenariusze nadal działają zgodnie z oczekiwaniami. Czy użytkownicy powinni bezwarunkowo ufać odpowiedziom Copilota? Nie. Odpowiedzi Copilota należy traktować jako wsparcie procesu podejmowania decyzji, a nie jako jedyne źródło prawdy. Kluczowe decyzje biznesowe powinny być weryfikowane w oparciu o zatwierdzone miary, raporty referencyjne oraz procedury governance obowiązujące w organizacji.

    Czytaj więcej
    GPT-6 Astra w Microsoft 365 Copilot: dostęp, zadania i koszty Cowork

    GPT-6 Astra w Microsoft 365 Copilot: dostęp, zadania i koszty Cowork

    Masz w firmie Copilota i chcesz wypróbować GPT-6 Astra? Model OpenAI jest dostępny także w Copilot Cowork. Możesz więc sprawdzić go przy pracy z dokumentami, pocztą i kalendarzem w środowisku Microsoftu. Dostęp do Astry zależy od licencji i ustawień organizacji, a wykonywanie zadań w Cowork wiąże się z rozliczaniem zużycia kredytów. Co musi włączyć administrator? Jakie zadania powierzysz Astrze w Cowork, a jak wygląda ich wykonanie w ChatGPT Work? Poniżej znajdziesz warunki dostępu, różnice w pracy na plikach i zasady naliczania opłat. Kwestię wyboru asystenta dla organizacji omawiamy w naszym porównaniu Microsoft Copilot i ChatGPT dla firm. 1. Co GPT-6 Astra wnosi do Copilot Cowork? Microsoft wymienia GPT-6 Astra na liście modeli Copilot Cowork. Użytkownik wybiera model z listy udostępnionej przez organizację. Domyślne ustawienie Auto pozwala Cowork dobrać model do zadania; oznaczenie przy odpowiedzi pokazuje, którego użyto. Wybór Astry dotyczy pracy w Cowork. Dostępność konkretnego modelu w pozostałych funkcjach Copilota trzeba sprawdzać osobno. GPT-6 Astra jest kolejnym modelem, któremu możesz powierzyć zadanie w Cowork. Sam Cowork zapewnia narzędzia do wyszukiwania materiałów, tworzenia plików i wykonywania czynności w Microsoft 365. Wybór modelu może wpłynąć na sposób analizy, szczegółowość odpowiedzi i czas pracy. Przy ocenie Astry warto więc sprawdzić, czy lepiej radzi sobie z zadaniem, które już wykonujesz: poprawniej łączy ustalenia, uwzględnia wyjątki i przygotowuje wynik wymagający mniej poprawek. Work IQ zapewnia Cowork dostęp do kontekstu firmowej pracy. Przy przygotowaniu podsumowania projektu potrzebne informacje mogą znajdować się w dokumentach, korespondencji i materiałach ze spotkań. Cowork może wyszukiwać firmowe zasoby potrzebne do zadania. Dlatego przed próbą warto sprawdzić, czy konto pracownika ma dostęp do właściwych materiałów i czy znajdują się wśród nich aktualne ustalenia. Od tego zależy, na jakich informacjach Astra oprze wynik. Wyniki testów modelu i przykłady jego wykorzystania opisujemy w artykule GPT-6 Astra: imponujące osiągnięcia, nowe możliwości dla biznesu. 2. Jak uzyskać dostęp do Astry w Copilot Cowork? Dla użytkowników biznesowych Microsoft opisuje Cowork jako usługę wymagającą licencji Microsoft 365 Copilot oraz rozliczania wykonywanych zadań według zużycia. Administrator musi następnie skonfigurować dostęp pracowników. W konfiguracji są dwa osobne ustawienia: Dostęp do Cowork. Pracownik musi należeć do grupy objętej zasadą wydatków, która uwzględnia Cowork. Administrator ustawia ją w centrum administracyjnym Microsoft 365, w obszarze Copilot, Cost Management, Configuration. To tutaj określa użytkowników, budżet i sposób rozliczenia. Dostęp do modeli obsługiwanych przez OpenAI. W ustawieniach Copilota administrator określa, którzy użytkownicy mogą korzystać z OpenAI jako podwykonawcy Microsoftu. Po uzyskaniu dostępu otwórz Cowork i wybierz Astrę z listy modeli. Przy pierwszym zadaniu sprawdź oznaczenie modelu przy odpowiedzi. Jeżeli pracownik widzi Cowork, ale brakuje mu Astry, administrator powinien sprawdzić ustawienia dostawcy modeli. Aby udostępnić Cowork wybranemu zespołowi, administrator musi objąć dostępem właściwą grupę użytkowników. Niski limit kredytów ogranicza wydatki, ale nadal pozwala objętemu nim pracownikowi rozpocząć pracę. 3. Astra w Cowork i ChatGPT Work: różnice przy wykonywaniu zadania Przy przygotowaniu raportu trzeba dotrzeć do aktualnych danych, opracować je i zapisać wynik w miejscu dostępnym dla zespołu. Na każdym z tych etapów znaczenie mają narzędzia udostępnione modelowi. Poniższe zestawienie pokazuje, jak oba środowiska pracują z materiałami potrzebnymi do zadania. Praca z materiałami w Copilot Cowork i ChatGPT Work Element zadania Copilot Cowork ChatGPT Work Odnalezienie materiałów Wyszukiwanie w zasobach Microsoft 365 dostępnych użytkownikowi, w tym w poczcie i plikach. Wtyczki mogą udostępniać kolejne źródła. Pliki przekazane do zadania oraz informacje pobrane przez włączone aplikacje i autoryzowane konta. Opracowanie dokumentów Tworzenie i zmiana dokumentów, arkuszy i prezentacji. Pliki wynikowe trafiają do obszaru pracy w OneDrive lub SharePoint. Tworzenie i edycja plików. Przekazanie ich do innego systemu zależy od operacji dostępnych w połączeniu z tym systemem. Pliki na dysku komputera Można przesłać plik do sesji. Cowork nie edytuje plików bezpośrednio na dysku użytkownika. Work w obsługiwanej aplikacji komputerowej może korzystać z lokalnych plików po udzieleniu odpowiedniego dostępu. Obsługa programu przez przeglądarkę Lokalna przeglądarka Edge korzysta z istniejącego logowania pracownika. Funkcja wymaga włączenia przez administratora. Dostęp zależy od wybranego narzędzia przeglądarkowego i udzielonych zgód. Zadanie w chmurze wymaga osobnej autoryzacji do firmowych zasobów. Przy pracy w przeglądarce trzeba uwzględnić miejsce uruchomienia zadania. Cowork obsługuje lokalną przeglądarkę w swojej wersji webowej otwartej w Edge. Ta funkcja nie działa obecnie w aplikacji komputerowej Copilota ani na urządzeniach mobilnych. Potrzebne jest też to samo konto służbowe w Cowork i Edge. Uśpienie komputera może wstrzymać czynności wymagające lokalnej przeglądarki. W ChatGPT Work podczas zadania lokalnego model może korzystać z udostępnionych plików i aplikacji komputera. Zadanie uruchomione w chmurze działa w osobnym środowisku. Jeśli potrzebne materiały znajdują się wyłącznie na dysku pracownika lub są dostępne przez firmowy VPN, trzeba udostępnić je temu środowisku w obsługiwany sposób. Podczas pracy Cowork pokazuje kolejne etapy zadania. Możesz przerwać sesję, doprecyzować polecenie lub dostarczyć brakujące informacje. Przed ważnymi działaniami, takimi jak wysłanie wiadomości czy zaplanowanie spotkania, Cowork prosi o zatwierdzenie. Zakres kolejnych pytań zależy również od udzielonych wcześniej zgód. Do pierwszej próby wybierz zadanie, którego materiały i miejsce zapisu wyniku możesz jednoznacznie wskazać. Przykłady obowiązków w sprzedaży, HR, finansach i innych działach znajdziesz w naszym zestawieniu 10 praktycznych zastosowań Microsoft Copilot w organizacji. 4. Ile kosztuje korzystanie z Astry w Cowork i ChatGPT Work? W budżecie trzeba uwzględnić abonament oraz wykorzystanie narzędzi do wykonywania zadań. W firmie, która ma już odpowiednie licencje, uruchomienie Cowork oznacza przede wszystkim zaplanowanie opłat za jego użycie. Poniżej podajemy publiczne ceny wybranych planów biznesowych. Ceny abonamentów. Opłaty za wykonywanie zadań opisujemy poniżej. Plan Cena za osobę miesięcznie Warunki Microsoft 365 Copilot Business 18,20 EUR; obecnie 15,60 EUR w promocji Płatność roczna, ceny netto. Potrzebna osobna, kwalifikująca się licencja Microsoft 365. Oferta dla maksymalnie 300 użytkowników. Microsoft 365 Copilot w ofercie dla przedsiębiorstw 26 EUR Płatność roczna, cena netto. Potrzebna osobna, kwalifikująca się licencja Microsoft 365. ChatGPT Business 20 USD przy płatności rocznej lub 25 USD przy miesięcznej Minimum dwóch użytkowników. Publiczna cena w USD; końcowa kwota zależy m.in. od podatków i rynku zakupu. ChatGPT Enterprise Wycena indywidualna Limity i rozliczenie wykorzystania określa umowa. Promocja Copilot Business obejmuje pierwszy rok przy zobowiązaniu rocznym i obowiązuje od 1 lipca do 31 grudnia 2026 r. 4.1 Jak naliczane są opłaty za zadania Cowork? Cowork rozlicza m.in. użycie modelu, pobieranie kontekstu, wywołania narzędzi i czas działania. Zużycie jest przeliczane na Copilot Credits; w opublikowanej ofercie pay-as-you-go jeden kredyt kosztuje 0,01 USD. Tysiąc kredytów oznacza więc 10 USD. Koszt pojedynczego zadania zależy od liczby zużytych kredytów. Na zużycie wpływa również wybrany poziom rozumowania. W Cowork dostępne są ustawienia Light, Medium, High, Extra High i Max. Wyższy poziom może wydłużyć zadanie i zwiększyć zużycie kredytów. Przy powtarzalnej pracy sprawdź, czy podniesienie tego ustawienia poprawia rezultat na tyle, by uzasadnić koszt. 4.2 Co oznacza zużycie kredytów w ChatGPT Work? ChatGPT Work korzysta z limitów i zasad rozliczania właściwych dla planu. W umowach opartych na wspólnej puli kredytów zadania zmniejszają dostępne saldo. Wykorzystanie kredytów już opłaconych w umowie jest pokryte tą opłatą. Dodatkowy koszt może powstać po ich wyczerpaniu, jeżeli umowa i ustawienia pozwalają kontynuować pracę. Przy porównywaniu kosztów użyj tej samej grupy zadań i wymagań dotyczących wyniku. Zapisz zużycie, liczbę ponownych prób oraz zakres poprawek. Przeliczenie wydatków na poprawnie ukończone zadanie pokaże, ile kosztuje wynik, z którego zespół może korzystać. Liczbę kredytów każdej usługi trzeba najpierw przeliczyć według jej własnego cennika. 5. Jakie zasady ochrony danych dotyczą Astry w Cowork? W Copilot Cowork Astra jest obsługiwana przez OpenAI jako podwykonawcę Microsoftu. Według dokumentacji do tego sposobu korzystania z modelu stosuje się warunki Microsoftu i jego dodatek dotyczący ochrony danych, z określonymi wyłączeniami. Usługi te są objęte EU Data Boundary z opisanymi wyjątkami. Microsoft wyłącza je obecnie z zobowiązań dotyczących przetwarzania w konkretnym kraju. Ten szczegół ma znaczenie dla organizacji wymagających np. przetwarzania wyłącznie w Polsce. Przy uruchomieniu Astry administrator powinien więc uwzględnić zasady dostawcy modelu oraz dostęp do materiałów używanych w zadaniu. W ChatGPT Work dodatkowo znaczenie ma lokalny lub chmurowy sposób pracy. Podczas zadania lokalnego fragmenty plików, zrzuty ekranu i wyniki narzędzi mogą być przesyłane do OpenAI. Firmowe zasady korzystania z AI powinny uwzględniać również ten sposób przekazywania informacji. 6. Od jakiego zadania zacząć korzystanie z Astry? Zacznij od obowiązku, przy którym pracownik regularnie zbiera informacje i przygotowuje materiał dla innych osób. Taki przebieg pracy pozwala sprawdzić zarówno analizę Astry, jak i dostępne w Cowork lub Work narzędzia. Przykładem może być cotygodniowe podsumowanie projektu. Przykład polecenia do własnej próby: Na podstawie folderu projektu [link] i korespondencji dotyczącej tego projektu z ostatnich siedmiu dni przygotuj raport dla kierownika. Wymień zmienione terminy, otwarte decyzje i osoby odpowiedzialne za kolejne działania. Przy każdym ustaleniu podaj źródło i datę. Jeśli materiały zawierają sprzeczne informacje, pokaż rozbieżność i wskaż, czego potrzebujesz do jej rozstrzygnięcia. Zapisz raport jako DOCX według załączonego szablonu w folderze [link]. Przygotuj szkic wiadomości do [odbiorcy] z linkiem do raportu. Wysyłkę pozostaw do mojego zatwierdzenia. Sprawdź, czy raport uwzględnia najnowsze ustalenia, podaje ich źródła i daty, wskazuje sprzeczne informacje oraz poprawnie przypisuje odpowiedzialność. Oceń też zgodność z szablonem i sprawdź, czy plik zapisano w folderze dostępnym dla odbiorców. Po udanej próbie można rozważyć regularne uruchamianie zadania. Cowork obsługuje harmonogramy oraz zadania wyzwalane m.in. wiadomością e-mail lub wpisem w Teams. Domyślnie zadania wyzwalane zdarzeniem przygotowują działania do zatwierdzenia. Projektowanie całego procesu omawiamy w przewodniku po automatyzacji procesów biznesowych z Copilotem. 7. Przygotuj z TTMS pierwsze zadania dla Astry W ramach konsultingu AI pomagamy ustalić, jakie dane będą potrzebne do zadania, które narzędzia trzeba udostępnić i jak sprawdzić rezultat. Analizujemy także wymagane licencje oraz sposób rozliczania wykorzystania. Łączymy doradztwo z projektowaniem rozwiązań AI i integracją firmowych systemów. TTMS jako pierwsza firma w Polsce uzyskała akredytowaną certyfikację ISO/IEC 42001 dla systemu zarządzania sztuczną inteligencją. Audyt TÜV Nord Poland objął zasady projektowania i wykorzystywania AI, w tym zarządzanie ryzykiem i dokumentowanie projektów. Powiedz nam, jakie zadanie chcesz powierzyć Astrze i z jakich programów korzysta Twój zespół. Porozmawiaj z TTMS o konsultingu AI dla Twojej firmy. GPT-6 Astra w Copilot Cowork: najczęstsze pytania Czy wybór Astry w Cowork zmienia model we wszystkich aplikacjach Copilota? Wybór dotyczy pracy w Cowork. Microsoft opisuje osobny wybór modelu w tym środowisku. Model obsługujący konkretną funkcję w Wordzie, Excelu lub Teams wymaga sprawdzenia w dokumentacji tej funkcji. Przy sprawdzaniu zadania Cowork można odczytać oznaczenie użytego modelu przy odpowiedzi. Czy ten sam model da identyczną odpowiedź w Copilocie i ChatGPT? Wynik może być różny. Model pracuje na informacjach udostępnionych przez dany produkt i korzysta z jego narzędzi, instrukcji oraz ustawień rozumowania. Przy porównaniu trzeba więc sprawdzić, jakie materiały otrzymał i jakie czynności mógł wykonać. Dopiero wtedy można sensownie ocenić różnicę w rezultatach. Dlaczego widzę Cowork, ale nie mogę wybrać GPT-6 Astra? Dostęp do Cowork i dostęp do modeli OpenAI mają osobne ustawienia. Administrator powinien potwierdzić, że Twoje konto może korzystać z modeli obsługiwanych przez OpenAI jako podwykonawcę Microsoftu. Lista modeli widoczna w Cowork odzwierciedla dostęp przyznany przez organizację. Czy abonament Microsoft 365 Copilot obejmuje wszystkie zadania Cowork? Zadania Cowork podlegają dodatkowo rozliczeniu według wykorzystania. Na zużycie Copilot Credits wpływają m.in. model, pobieranie informacji i narzędzia. Administrator może ustalać zasady wydatków dla użytkowników i grup. Przy planowaniu budżetu trzeba uwzględnić abonament oraz przewidywane użycie Cowork. Czy Astra w Cowork może edytować dokument zapisany na moim komputerze? Możesz przesłać dokument do sesji Cowork. Według aktualnego FAQ usługa nie otwiera ani nie edytuje plików bezpośrednio na lokalnym dysku. Cowork pracuje na przekazanych materiałach oraz plikach dostępnych w OneDrive i SharePoint. Obsługa przeglądarki Edge jest osobną funkcją. Czy ten sam model Astra zapewni taki sam wynik w Cowork i ChatGPT Work? Na wynik wpływają także dostępne dane, instrukcje, narzędzia i ustawienia rozumowania. Dlatego zadanie wykonane z tym samym modelem może przebiegać inaczej w obu środowiskach. Porównanie na tych samych materiałach pokaże, gdzie pojawiają się różnice w kompletności wyniku i wykonanych czynnościach.

    Czytaj więcej
    GPT-6 Astra: imponujące osiągnięcia, nowe możliwości dla biznesu

    GPT-6 Astra: imponujące osiągnięcia, nowe możliwości dla biznesu

    3 września 2026 r. OpenAI zaprezentowało GPT-6 Astra, a pierwsze wyniki badań i relacje użytkowników pokazują, dlaczego ta premiera wzbudza tyle emocji. Nowy model znalazł rozwiązania problemów matematycznych, z którymi w tym samym teście nie poradziły sobie poprzednie wersje GPT, jak również konkurencja. Użytkownicy sprawdzili już GPT-6 w różnych zastosowaniach: od przebudowy procesu sprzedaży w CRM, przez stworzenie szczegółowego modelu parowozu, po analizę ponad 500-stronicowej powieści. Co dokładnie udało się osiągnąć i co z tych możliwości może wykorzystać biznes? 1. Pierwsze osiągnięcia GPT-6 Astra robią wrażenie Pierwsze testy i relacje użytkowników pokazują, jak Astra radzi sobie ze złożonymi zadaniami. Są wśród nich wyniki testu przeprowadzonego przez Epoch AI oraz doświadczenia osób, które powierzyły modelowi własne projekty. 1.1 Rozwiązanie dwóch dotąd nierozstrzygniętych problemów matematycznych Epoch AI zleciło pięciu modelom rozwiązanie 68 problemów Erdősa, zapewniając każdemu takie same limity czasu i budżetu. Tylko przedpremierowa wersja Astry rozwiązała dwa z nich i zapisała rozwiązania w formie, która przeszła automatyczną weryfikację matematyczną. GPT-5.6 Sol, GPT-5.5, Claude Fable 5.1 i Claude Fable 5 nie rozwiązały w tym teście żadnego problemu. To zresztą nie pierwsze matematyczne osiągnięcia Astry. Jeszcze przed premierą OpenAI przedstawiło dziesięć innych wyników modelu dotyczących problemów z matematyki i informatyki teoretycznej. Opisaliśmy je w artykule „Astra, przyszły GPT-6: nowy model od OpenAI?”. 1.2 Model 3D parowozu z 3295 edytowalnych elementów Tom Krcha, projektant i twórca narzędzia Pencil do pracy nad interfejsami z pomocą AI, przekazał Astrze stary rysunek parowozu. Model miał na jego podstawie odtworzyć maszynę w Blenderze, programie służącym do tworzenia modeli, animacji i scen 3D. Po kilku minutach powstała konstrukcja obejmująca 3295 osobnych obiektów. Koła, osie, elementy kotła i pozostałe części można zaznaczać, przesuwać oraz modyfikować niezależnie. Astra musiała zinterpretować płaski rysunek, odtworzyć przestrzenną budowę maszyny i zachować zależności między tysiącami elementów. Według Krchy robiła to głównie przez pisanie skryptów w Pythonie, które tworzyły geometrię część po części. Tak przygotowany model może posłużyć jako baza do animacji lub projektu gry. 1.3 Przebudowa procesu sprzedaży bezpośrednio w CRM Claire Vo, twórczyni platformy ChatPRD, udostępniła Astrze używany przez siebie system zarządzania relacjami z klientami, czyli CRM. Model działał za pośrednictwem Codex i miał zmienić sposób obsługi nowych kontaktów sprzedażowych. Musiał zrozumieć istniejący schemat, znaleźć odpowiednie ustawienia i przebudować reguły działające w wizualnym edytorze. Po zmianach system sam kierował kontakty do Claire lub Zacha, wstawiał do wiadomości link umożliwiający rezerwację spotkania z odpowiednią osobą, a gotowy szkic przesyłał do komunikatora Slack do akceptacji. Nowe reguły miały obowiązywać również przy obsłudze kolejnych kontaktów. 1.4 Nowe funkcje głośnika Bluetooth dzięki Astrze Claire Vo wykorzystała model również do eksperymentu z niewielkim głośnikiem Divoom wyposażonym w ekran z kolorowych pikseli. Chciała wyświetlać na nim własne obrazy i komunikaty. Według jej relacji urządzenie nie udostępniało publicznego API, czyli interfejsu pozwalającego innym programom nim sterować. Trzeba było rozpracować sposób komunikacji ze sprzętem. Astra przygotowała aplikację, dzięki której rysunek tworzony myszą na komputerze pojawiał się na ekranie głośnika. Następnie Astra przygotowała narzędzie do sterowania głośnikiem. Wyszukała też informacje o najnowszym odcinku podcastu, po czym przesłała na ekran urządzenia przewijany tekst i animowaną grafikę. Vo podkreśla, że wcześniejsze próby z innymi modelami pozwalały jej zaledwie wyświetlić prosty komunikat powitalny. Tym razem otrzymała własne oprogramowanie do sterowania urządzeniem, które mogła rozwijać zgodnie ze swoimi pomysłami. 1.5 Sprawdzanie spójności fabuły w ponad 500-stronicowej powieści Jakub Szczęsny z Antywebu przekazał Astrze obszerny szkic własnej książki. Model miał sprawdzić chronologię wydarzeń, logikę fabuły oraz wątki zapowiedziane w jednej części tekstu i rozwinięte wiele rozdziałów później. W tak długim materiale trzeba jednocześnie śledzić losy bohaterów, kolejność zdarzeń, motywacje postaci i konsekwencje wcześniejszych decyzji. Astra porządkowała te zależności i wskazywała miejsca wymagające dopracowania, konsekwentnie sprawdzając cały tekst pod kątem wskazanych problemów. Szczęsny szczególnie docenił jej umiejętność łączenia informacji rozsianych po setkach stron. Podobna umiejętność przydaje się przy czytaniu umów, dokumentacji projektowej i raportów, w których ustalenia z jednej części wpływają na interpretację pozostałych. 1.6 Ukończenie całej gry Portal przez agenta AI Twórca publikujący jako CozyBlaze połączył Astrę z Portalem, przestrzenną grą logiczną, w której gracz tworzy przejścia między odległymi miejscami i wykorzystuje zasady fizyki do pokonywania przeszkód. Model otrzymywał zrzuty ekranu oraz informacje o położeniu postaci i kierunku, w którym była zwrócona. Na tej podstawie planował ruchy, wykonywał je i sprawdzał rezultat. Po około 23 godzinach i 43 minutach, wliczając oczekiwanie oraz przerwy techniczne, dotarł do napisów końcowych. Autor przygotował specjalne sterowanie i ustawienia ułatwiające precyzyjne poruszanie się; gra zatrzymywała się na czas obliczeń. Wznawiał też sesję po problemach z dostępnością usługi, a decyzje dotyczące rozgrywki podejmował agent. Ukończenie gry wymagało rozpoznawania sytuacji na ekranie, orientacji w przestrzeni oraz wielogodzinnego planowania ruchów i sprawdzania ich skutków. Te przykłady pokazują, skąd entuzjazm wokół Astry. Model analizuje problem, wykonuje kolejne czynności i wykorzystuje ich wyniki do dalszego działania. Dla firm otwiera to możliwość powierzania AI bardziej złożonych zadań, wymagających pracy z informacjami i aplikacjami. Porównania z GPT-5.6 pozwalają sprawdzić, gdzie wzrosła skuteczność i jakie może mieć to znaczenie dla biznesu. 2. GPT-6 Astra w biznesie: co większa skuteczność zmienia dla firm? Firma korzystająca z AI ponosi także koszt sprawdzania odpowiedzi, poprawiania błędów i interweniowania, gdy model nie potrafi dokończyć zadania. Dlatego większa skuteczność kolejnej generacji może sprawić, że więcej zadań będzie opłacało się powierzać AI. Wyniki Astry dają podstawę, by ponownie przyjrzeć się podziałowi obowiązków, wykorzystaniu firmowych systemów i czasowi poświęcanemu na kontrolę rezultatów. GPT-6 Astra a GPT-5.6 Sol: wyniki testów i znaczenie dla biznesu Badana umiejętność GPT-6 Astra GPT-5.6 Sol Znaczenie dla firmy Poprawne zakończenie zadania obejmującego kilka aplikacji, AutomationBench 41,4% 28,77% Podstawa do sprawdzenia, czy AI może samodzielnie wykonywać większy fragment procesu. Wskazywanie właściwych elementów na ekranie, ScreenSpot-Pro 92,7% 76,9% Większa precyzja przy obsłudze firmowych programów przez AI. Wykrywanie błędów wymagających analizy kilku plików, trudniejszy podzbiór CodeRabbit 57,1% 47,6% Lepsze wyniki przy analizie złożonych zależności w oprogramowaniu. Wyniki pochodzą z różnych testów i mierzą odrębne umiejętności. AutomationBench: ranking Zapiera z 9 września 2026 r., oba modele w ustawieniu Max. ScreenSpot-Pro: porównanie OpenAI. CodeRabbit: trudniejszy podzbiór przeglądów kodu. Wnioski biznesowe są interpretacją wyników, a oszczędności wymagają sprawdzenia w konkretnym procesie firmy. 2.1 Większy zakres zadań, które można delegować Im więcej etapów obejmuje zadanie, tym więcej okazji do pomyłki. Trzeba odnaleźć informacje, zastosować właściwe zasady, wykonać czynności w odpowiedniej kolejności i zachować spójność ustaleń. Właśnie takie wymagania stawia modelom AutomationBench, test firmowych procesów przygotowany przez Zapier. W rankingu z 9 września 2026 r. Astra poprawnie ukończyła 41,4% zadań, a GPT-5.6 Sol 28,77%, przy najwyższym ustawieniu rozumowania obu modeli. Zadanie zaliczano po spełnieniu wszystkich wymaganych warunków. To około 13 poprawnie zakończonych zadań więcej na każde 100. Dla biznesu oznacza to możliwość sprawdzenia, czy AI wykona więcej etapów bez pomocy pracownika. Warto przyjrzeć się obowiązkom, przy których pracownik stale podpowiada modelowi następny krok, dostarcza kolejne dane lub przenosi wynik do innego programu. Każda taka interwencja zajmuje czas i ogranicza korzyść z automatyzacji. Astra daje powód, by sprawdzić, które z tych etapów potrafi już połączyć. Wynik 41,4% pokazuje też, jak wymagające pozostają te zadania. Zakres samodzielności trzeba ustalić na podstawie rezultatów osiąganych w konkretnym procesie firmy. 2.2 Automatyzacja kolejnych czynności w firmowych programach Firmy korzystają z wielu programów wdrażanych na różnych etapach rozwoju. Dostęp AI do tych zasobów ma duże znaczenie dla jego użyteczności. Gdy model potrafi sprawnie obsługiwać aplikację za pomocą jej interfejsu, można rozważyć jego udział również w czynnościach wykonywanych przez pracowników za pomocą formularzy, przycisków i menu. W ScreenSpot-Pro, teście wskazywania elementów na zrzutach ekranu, Astra osiągnęła 92,7% skuteczności wobec 76,9% GPT-5.6 Sol. Badanie obejmuje rozbudowane programy z gęsto rozmieszczonymi narzędziami. Wynik dotyczy jednej konkretnej umiejętności potrzebnej do obsługi aplikacji. Dzięki tej poprawie warto rozważyć automatyzację kolejnych czynności w programach, z których firma już korzysta. Przy planowaniu automatyzacji warto uwzględnić zadania, które dziś wymagają ręcznego poruszania się po programach. Lepsze rozpoznawanie interfejsu może ułatwić ich wykonanie przez AI wyposażone w odpowiednie narzędzia i uprawnienia. O opłacalności zdecyduje skuteczność całej operacji, wraz z odczytaniem danych, wprowadzeniem zmian i sprawdzeniem wyniku. Precyzyjne wskazanie przycisku jest jednym z warunków jej powodzenia. 2.3 Wykrywanie błędów wymagających połączenia informacji z kilku miejsc W firmowych zadaniach trudność często wynika z powiązań między informacjami. Zmiana jednego ustalenia wpływa na kolejne decyzje, dokumenty i działania zespołu. Osoba odpowiedzialna za całość musi dostrzec te zależności i sprawdzić ich konsekwencje. W badaniu CodeRabbit przewaga Astry była szczególnie widoczna przy analizie błędów wymagających prześledzenia kilku plików kodu. Model wykrył 57,1% oznaczonych błędów wobec 47,6% GPT-5.6 Sol. W całym badaniu różnica była mniejsza: 61,3% wobec 59,0%. Największa poprawa dotyczyła więc trudniejszych przypadków. Dla osób zarządzających wykorzystaniem AI płynie z tego ważna wskazówka: warto oceniać nową generację na zadaniach, przy których wcześniejszy model przeoczał powiązania między informacjami lub wymagał wielu poprawek. Przy prostych poleceniach różnica między modelami może być niewielka. Więcej o przydatności Astry powiedzą materiały z wyjątkami, wzajemnie zależnymi warunkami i informacjami rozproszonymi w kilku miejscach. CodeRabbit dokumentuje tę poprawę w analizie oprogramowania. Sprawdzenie podobnej przewagi w dokumentacji, raportach czy uzgodnieniach biznesowych wymaga prób na własnych materiałach. To dobry kierunek oceny modelu dla firm, w których dużo czasu zajmuje właśnie ustalanie, jak poszczególne informacje wpływają na siebie. 2.4 Kiedy większa skuteczność AI oznacza oszczędności? Nawet niewielka poprawa jakości może mieć znaczenie przy zadaniu powtarzanym setki razy w miesiącu. Jeżeli pracownicy rzadziej poprawiają wynik i rzadziej pomagają AI dokończyć zadanie, zespół odzyskuje czas. Skala tej korzyści zależy od częstotliwości błędów, czasu potrzebnego na ich usunięcie oraz konsekwencji pomyłek. Wyniki Astry uzasadniają ponowną ocenę zastosowań, które wcześniej okazały się zbyt zawodne lub wymagały zbyt dużego nadzoru. Firma może wrócić do odłożonego pomysłu i sprawdzić go na zestawie rzeczywistych spraw, obejmującym także trudniejsze przypadki. W takiej ocenie liczą się trzy rzeczy: odsetek poprawnie zakończonych zadań, czas pracownika poświęcony na kontrolę i poprawki oraz łączny koszt obsługi sprawy. Te wskaźniki pozwalają ustalić, czy większa skuteczność modelu przynosi korzyść całemu zespołowi. Postęp Astry może więc sprawić, że automatyzacja wcześniej zbyt kosztownych zadań zacznie się opłacać. Zadania wymagające dotąd ciągłego wsparcia człowieka zasługują na ponowne sprawdzenie, zwłaszcza gdy są częste, czasochłonne i mają jasno określony wynik. Jak wykorzystać możliwości GPT-6 Astra w Twojej firmie? W ramach konsultingu AI pomagamy wybrać zadania, których usprawnienie przyniesie firmie największą korzyść, i zaplanować wdrożenie. W TTMS wspólnie z klientem analizujemy proces, określamy potrzebne dane i integracje oraz ustalamy, jak ocenić efekty. Łączymy doradztwo z projektowaniem rozwiązań AI i ich integracją z firmowymi systemami. Jako pierwsza firma w Polsce uzyskaliśmy akredytowaną certyfikację ISO/IEC 42001 dla systemu zarządzania sztuczną inteligencją. Dla klientów to potwierdzenie, że stosujemy sprawdzone przez niezależnych audytorów zasady oceny ryzyka, dokumentowania projektów i nadzoru nad AI. Opisz nam zadanie, które chcesz usprawnić. Wspólnie sprawdzimy, jak można wykorzystać w nim AI i od czego zacząć. Porozmawiaj z TTMS o konsultingu AI dla Twojej firmy. GPT-6 Astra w biznesie: najczęstsze pytania   Co GPT-6 Astra zmienia dla firm, które już korzystają z AI? GPT-6 Astra daje podstawę do sprawdzenia, czy AI może przejąć większą część zadania i rzadziej wymagać pomocy pracownika. Porównania z GPT-5.6 Sol pokazują poprawę w wykonywaniu czynności obejmujących kilka aplikacji, wskazywaniu elementów ekranu i analizie zależności w kodzie. Warto więc wrócić do procesów, w których zespół często poprawia wyniki lub prowadzi model krok po kroku. Korzyść pojawi się wtedy, gdy większa skuteczność ograniczy nakład pracy potrzebny do uzyskania poprawnego rezultatu. Czy GPT-6 Astra może pracować w firmowych systemach bez budowania nowej integracji? W niektórych przypadkach tak, jeśli środowisko udostępnia Astrze narzędzia do obsługi przeglądarki lub komputera. Model może wtedy wykonywać czynności przez formularze, menu i przyciski aplikacji. Potrzebuje odpowiednich uprawnień oraz dostępu do systemu. Możliwość wykorzystania tego sposobu zależy od konkretnego programu i zadania. Przy częstych, powtarzalnych operacjach warto porównać go z integracją przez API, czyli interfejs umożliwiający bezpośrednią wymianę danych między programami. Które zadania warto ponownie powierzyć AI, jeśli wcześniejsze próby automatyzacji się nie sprawdziły? W pierwszej kolejności te, przy których wcześniejszy model gubił kolejne kroki, mylił elementy interfejsu lub przeoczał zależności między informacjami. To obszary, w których opisane testy pokazują postęp Astry. Do ponownej próby warto wykorzystać te same materiały i kryteria oceny, zachowując także przypadki, które wcześniej sprawiały trudność. Jeżeli przyczyną niepowodzenia były nieaktualne dane, sprzeczne instrukcje lub brak dostępu do aplikacji, te problemy również trzeba rozwiązać. Jak ustalić, co GPT-6 Astra może wykonywać samodzielnie, a co wymaga zatwierdzenia przez pracownika? Zakres samodzielności powinien zależeć od skutków pomyłki, możliwości cofnięcia działania i wyników prób na firmowych danych. Przygotowanie szkicu dokumentu czy uporządkowanie kopii danych pozwala łatwo sprawdzić rezultat przed jego wykorzystaniem. Wysłanie oferty, zmiana warunków handlowych lub usunięcie rekordów może wymagać wcześniejszej akceptacji. W instrukcji procesu warto jasno określić, kiedy AI wykonuje zadanie, kiedy prosi o decyzję i kiedy zatrzymuje się z powodu brakujących informacji. Jak sprawdzić, czy wykorzystanie GPT-6 Astra przynosi firmie oszczędności po uwzględnieniu kontroli i poprawek? Porównaj łączny koszt wykonania tej samej grupy zadań przed zastosowaniem Astry i z jej udziałem. Uwzględnij przygotowanie danych, obsługę narzędzi, sprawdzanie rezultatów, poprawki oraz przypadki wymagające ponownego wykonania przez pracownika. Przydatnym wskaźnikiem jest koszt jednej poprawnie zakończonej sprawy przy zachowaniu wymaganej jakości. Ocenę oprzyj na reprezentatywnym zestawie zadań, obejmującym również wyjątki. Pozwoli to ustalić, czy oszczędności powtarzają się w codziennej pracy.

    Czytaj więcej
    Cybersecurity po wycieku danych: dlaczego sam backup nie wystarczy?

    Cybersecurity po wycieku danych: dlaczego sam backup nie wystarczy?

    Głośne incydenty dotyczące danych medycznych pokazują, że nawet informacje przetwarzane przez wyspecjalizowane systemy mogą stać się celem cyberprzestępców. Gdy dojdzie do naruszenia, zarząd musi odpowiedzieć nie tylko na pytanie, jakie dane mogły zostać ujawnione, lecz także czy organizacja potrafi utrzymać najważniejsze procesy i bezpiecznie odtworzyć środowisko IT. W sierpniu 2026 roku Prezes Urzędu Ochrony Danych Osobowych zapowiedział kontrolę zastosowanych środków technicznych i organizacyjnych w spółce MyDr po informacjach o incydencie dotyczącym danych pacjentów. Organ podkreślił, że dokładna skala zdarzenia nie była jeszcze w pełni znana, a kontroli miał podlegać również sposób prowadzenia analizy ryzyka. To istotne zastrzeżenie: dopóki postępowania trwają, nie należy przesądzać przyczyny ani odpowiedzialności poszczególnych podmiotów. Nie jest to pierwszy poważny sygnał dla polskiego rynku. W listopadzie 2023 roku UODO informował o ataku ransomware połączonym z wyciekiem danych z ALAB Laboratoria. Zdarzenia różnią się mechanizmem i okolicznościami, ale prowadzą do wspólnego wniosku: bezpieczeństwa danych nie można sprowadzać do jednego produktu ani jednej procedury. Wiele firm nadal traktuje backup jako podstawową odpowiedź na cyberzagrożenia. Dobrze zaprojektowana kopia zapasowa może uratować organizację po zaszyfrowaniu, usunięciu lub uszkodzeniu danych. Nie cofnie jednak wycieku, nie odbierze napastnikowi skradzionych informacji i nie zastąpi kontroli dostępu, szyfrowania, monitoringu ani przygotowanego wcześniej planu reagowania. 1. Wyciek danych i utrata danych to dwa różne zagrożenia Wyciek oznacza, że osoba nieuprawniona uzyskała lub mogła uzyskać dostęp do informacji. Utrata danych dotyczy ich niedostępności, usunięcia, zaszyfrowania albo uszkodzenia. Jeden atak może wywołać oba skutki: przestępcy najpierw kopiują dane, a następnie szyfrują systemy i żądają zapłaty za ich odblokowanie lub niepublikowanie. Backup odpowiada przede wszystkim na problem dostępności i odtworzenia. Jeśli kopie są aktualne, odseparowane i możliwe do wykorzystania, firma może odbudować system bez polegania na obietnicach napastnika. Kopia zapasowa nie przywraca jednak poufności informacji, które opuściły organizację. Po wycieku pozostają obowiązki prawne, ryzyko oszustw, koszty obsługi incydentu i utrata zaufania klientów. 1.1 Podwójne wymuszenie zmienia rolę backupu W klasycznym scenariuszu ransomware napastnik szyfrował dane i żądał opłaty za klucz deszyfrujący. Coraz częściej wcześniej kopiuje informacje, a następnie grozi ich publikacją lub sprzedażą. Ten model, określany jako podwójne wymuszenie, sprawia, że możliwość odtworzenia systemu nie kończy kryzysu. Firma może wznowić działalność, ale nadal musi ustalić zakres wycieku, ocenić ryzyko dla osób i kontrahentów oraz prowadzić komunikację zgodnie z obowiązkami prawnymi. W praktyce potrzebne są więc dwa równoległe plany. Pierwszy dotyczy odzyskania systemów i ciągłości działania. Drugi obejmuje analizę naruszenia poufności: zabezpieczenie logów, identyfikację pobranych danych, ograniczenie dalszego dostępu oraz decyzje dotyczące powiadomień. Backup jest kluczowy dla pierwszego planu, ale nie zastępuje drugiego. Takie rozróżnienie ma znaczenie również na gruncie RODO. Art. 32 RODO wskazuje m.in. na zdolność do szybkiego przywrócenia dostępności danych oraz regularne testowanie skuteczności środków bezpieczeństwa. Jednocześnie wymaga ochrony poufności i integralności, a więc szerszego zestawu zabezpieczeń niż sam backup. 2. Czego głośne wycieki danych uczą polski biznes? Pierwsza lekcja dotyczy wartości danych. Dokumentacja medyczna, dane klientów, informacje finansowe, dane pracowników i własność intelektualna mogą służyć do szantażu, kradzieży tożsamości, phishingu lub dalszych ataków. Organizacja powinna wiedzieć, gdzie takie informacje się znajdują, kto ma do nich dostęp i jak szybko wykryje ich nietypowe pobieranie. Druga lekcja dotyczy zależności od dostawców. Dane biznesowe często są przetwarzane w systemach SaaS, chmurze, centrach danych i aplikacjach utrzymywanych przez podmioty trzecie. Przekazanie obsługi technicznej nie usuwa ryzyka po stronie klienta. Potrzebne są wymagania umowne, okresowa ocena zabezpieczeń, uzgodnione zasady raportowania incydentów oraz pewność, że dane można odzyskać także w razie awarii lub zakończenia współpracy. Trzecia lekcja jest zarządcza: bezpieczeństwo nie zaczyna się w chwili ataku. Organizacja powinna wcześniej ustalić priorytety odtwarzania, role decyzyjne, kanały komunikacji i akceptowalny czas przestoju. Dla podmiotów objętych NIS2 wymagania dotyczące ciągłości działania wynikające z NIS2 obejmują m.in. zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe. 3. Kiedy backup rzeczywiście ratuje firmę? Kopia zapasowa ma największą wartość, gdy podstawowe dane lub systemy przestają być dostępne. Przyczyną może być ransomware, awaria infrastruktury, błąd administratora, wadliwa aktualizacja, usunięcie danych przez pracownika albo uszkodzenie środowiska chmurowego. Backup pozwala wtedy ograniczyć przestój, odbudować usługi i zmniejszyć zakres nieodwracalnej utraty informacji. Warunkiem jest jednak objęcie kopią całego procesu, a nie tylko pojedynczego katalogu. Do wznowienia działalności mogą być potrzebne bazy danych, konfiguracje, klucze, kod aplikacji, dokumentacja, integracje, obrazy systemów i informacje o kolejności uruchamiania usług. Kopia danych bez wiedzy, jak odtworzyć zależności, może okazać się niewystarczająca. 4. Backup, replikacja, archiwizacja i Disaster Recovery to nie to samo Pojęcia te bywają stosowane zamiennie, choć odpowiadają na inne potrzeby. Backup tworzy punkty, z których można odzyskać wcześniejszą wersję danych. Replikacja utrzymuje drugą, możliwie aktualną kopię środowiska, ale może natychmiast powielić także usunięcie pliku, błędną zmianę lub zaszyfrowanie. Archiwizacja służy długoterminowemu przechowywaniu informacji, a nie szybkiemu wznowieniu całego procesu. Disaster Recovery obejmuje natomiast technologię i procedury potrzebne do przywrócenia usług po poważnym zdarzeniu. Określa kolejność uruchamiania systemów, zależności, zasoby zastępcze, role zespołu i sposób potwierdzenia, że proces działa poprawnie. Firma może więc posiadać wiele kopii plików, a mimo to nie mieć realnego planu odtworzenia działalności. Dojrzała strategia łączy te mechanizmy. Replikacja może skrócić przestój po awarii infrastruktury, backup umożliwia powrót do stanu sprzed ataku, archiwum wspiera retencję, a Disaster Recovery porządkuje sposób wykorzystania wszystkich tych zasobów podczas kryzysu. 4.1 RPO i RTO trzeba określić językiem biznesowym RPO określa, jaką maksymalną ilość ostatnio zapisanych danych organizacja może utracić. RTO wskazuje, jak długo proces może pozostawać niedostępny. Parametry te nie powinny wynikać wyłącznie z możliwości technologii. Muszą odpowiadać skutkom biznesowym: zatrzymaniu produkcji, braku obsługi klientów, opóźnieniu rozliczeń, naruszeniu terminów lub zagrożeniu dla bezpieczeństwa ludzi. 4.2 Przykład: system sprzedażowy i miesięczne archiwum Jeżeli system przyjmuje zamówienia przez całą dobę, utrata danych z ostatnich 24 godzin może oznaczać konieczność ręcznego odtworzenia setek transakcji. Taki proces może wymagać RPO liczonego w minutach i RTO w godzinach. Dla zamkniętego archiwum dokumentów z poprzedniego roku dopuszczalne wartości mogą być znacznie wyższe. Jedna polityka backupu dla obu zasobów prowadzi albo do nadmiernych kosztów, albo do niewystarczającej ochrony. 5. Dlaczego sam backup nie zatrzyma wycieku danych? Backup jest mechanizmem odzyskiwania, a nie pełnym systemem ochrony informacji. Nawet idealnie odtworzona baza pozostaje naruszona, jeśli napastnik wcześniej pobrał jej zawartość. Dlatego kopie muszą być częścią architektury obejmującej profilaktykę, wykrywanie, reakcję i przywracanie działalności. Kontrola dostępu i zasada najmniejszych uprawnień ograniczają liczbę osób oraz kont mogących pobierać dane. MFA, segmentacja i oddzielne konta administracyjne utrudniają przejęcie całego środowiska jednym zestawem poświadczeń. Szyfrowanie chroni dane przechowywane i przesyłane, o ile klucze są zarządzane oddzielnie i bezpiecznie. DLP, klasyfikacja informacji i monitoring pomagają rozpoznać nietypowy transfer lub masowe pobieranie plików. EDR, ochrona przed malware i zarządzanie podatnościami zmniejszają prawdopodobieństwo utrzymania dostępu przez napastnika. Plan Incident Response określa, kto izoluje systemy, zabezpiecza dowody, ocenia ryzyko i uruchamia komunikację kryzysową. 6. Jak zbudować odporny backup: zasada 3-2-1-1-0 Punktem wyjścia jest zasada 3-2-1: trzy kopie danych, dwa różne rodzaje nośników lub środowisk i jedna kopia poza główną lokalizacją. W realiach ransomware warto rozszerzyć ją do modelu 3-2-1-1-0. Dodatkowa jedynka oznacza kopię offline albo niezmienialną, a zero – brak błędów potwierdzony w testach odtwarzania. Ustal, które dane, systemy i konfiguracje są krytyczne dla działania organizacji. Oddziel infrastrukturę backupową od środowiska produkcyjnego, domeny i podstawowych kont administratorów. Stosuj kopie offline lub mechanizmy niezmienialności, które blokują usunięcie i nadpisanie danych przez określony czas. Szyfruj kopie oraz kontroluj dostęp do kluczy, konsoli zarządzającej i procedur awaryjnych. Monitoruj nieudane zadania, zmiany retencji, kasowanie punktów przywracania i nietypowe logowania. Regularnie testuj odtworzenie w izolowanym środowisku i dokumentuj osiągnięte RPO oraz RTO. Zgodnie z wytycznymi CISA dotyczącymi ochrony kopii przed ransomware, organizacje powinny utrzymywać zaszyfrowane kopie danych przechowywane offline oraz regularnie sprawdzać ich dostępność i integralność. Ransomware często próbuje odnaleźć i usunąć dostępne backupy, dlatego logiczna separacja i niezmienialność mają równie duże znaczenie jak częstotliwość wykonywania kopii. 7. Backup bez testu odtworzenia jest tylko założeniem Status „backup wykonany pomyślnie” nie dowodzi, że organizacja potrafi wznowić działanie. Kopia może być niekompletna, uszkodzona, zainfekowana, zależna od niedostępnego klucza albo niemożliwa do uruchomienia na dostępnej infrastrukturze. Problem może ujawnić się dopiero podczas kryzysu, gdy czas i kompetencje zespołu są najbardziej ograniczone. Test powinien obejmować nie tylko odzyskanie pliku, ale także odtworzenie reprezentatywnego procesu. Warto sprawdzić kolejność uruchamiania usług, działanie integracji, poprawność uprawnień, integralność danych i możliwość pracy użytkowników. Ćwiczenie powinno zakończyć się raportem: co odtworzono, ile to trwało, jakie dane utracono i jakie działania naprawcze są potrzebne. Dojrzała organizacja zakłada również niedostępność części personelu i podstawowych narzędzi komunikacji. Instrukcje awaryjne, kontakty, klucze i minimalne konfiguracje powinny być dostępne w sposób bezpieczny także poza środowiskiem dotkniętym incydentem. 8. Pierwsze 24 godziny po incydencie Pierwsze działania mają wpływ zarówno na możliwość odtworzenia systemów, jak i na późniejsze ustalenie przebiegu zdarzenia. Pochopne kasowanie plików, restartowanie serwerów lub natychmiastowe przywrócenie całego środowiska może zniszczyć ślady potrzebne do analizy i ponownie uruchomić mechanizm ataku. Ogranicz rozprzestrzenianie się incydentu. Odizoluj zagrożone systemy i konta zgodnie z przygotowaną procedurą, zachowując materiały potrzebne do analizy. Zabezpiecz dowody i ustal zakres. Zachowaj logi, wskaż systemy objęte zdarzeniem i sprawdź, czy doszło wyłącznie do niedostępności, czy również do pobrania danych. Chroń środowisko odtworzeniowe. Przed przywróceniem danych potwierdź, że kopie są integralne, a konta, podatności lub konfiguracje wykorzystane w ataku zostały zabezpieczone. Uruchom ścieżkę decyzyjną i komunikacyjną. Zaangażuj osoby odpowiedzialne za IT, bezpieczeństwo, ochronę danych, kwestie prawne, ciągłość działania i komunikację z klientami. Odtwarzanie powinno następować zgodnie z priorytetami biznesowymi, nie według przypadkowej kolejności serwerów. Najpierw trzeba uruchomić usługi bazowe i mechanizmy bezpieczeństwa, a następnie procesy o najwyższym wpływie na klientów, przychody, zobowiązania prawne lub bezpieczeństwo operacyjne. 9. Bezpieczeństwo dostawców jest częścią Cybersecurity firmy Jeżeli dostawca przechowuje lub przetwarza dane, ocena backupu powinna obejmować model współodpowiedzialności. Trzeba ustalić, kto wykonuje kopie, gdzie są przechowywane, jak długo trwa odtworzenie, czy klient może otrzymać eksport oraz co dzieje się z danymi po zakończeniu umowy. Samo stwierdzenie, że usługa działa w chmurze, nie odpowiada na te pytania. Umowa powinna określać zasady zgłaszania incydentów, współpracy przy analizie naruszenia, zachowania logów, obsługi żądań organów i powiadamiania osób. Warto również weryfikować podwykonawców, lokalizacje danych, uprawnienia uprzywilejowane i wyniki testów ciągłości działania. Certyfikat lub deklaracja dostawcy mogą wspierać ocenę, ale nie zastępują analizy konkretnej usługi i przepływu danych. 9.1 SaaS nie zawsze oznacza pełny backup po stronie dostawcy W usługach SaaS dostawca zwykle odpowiada za dostępność platformy, ale klient może nadal odpowiadać za retencję, konfigurację, konta użytkowników i możliwość odzyskania przypadkowo usuniętych informacji. Wersjonowanie lub kosz w aplikacji nie zawsze zapewniają wymaganą historię zmian, odseparowaną kopię ani eksport pozwalający odtworzyć proces poza usługą. Przed zakupem należy sprawdzić zakres odpowiedzialności, okres przechowywania usuniętych danych, możliwość masowego odtworzenia, ochronę przed przejęciem konta administratora oraz sposób odzyskania danych w razie długotrwałej niedostępności dostawcy. 10. Od backupu do pełnej cyberodporności Cyberodporność oznacza zdolność zapobiegania incydentom, ich wykrywania, ograniczania skutków oraz przywracania działalności. Backup realizuje tylko część tego cyklu. Jego skuteczność zależy od jakości inwentaryzacji, klasyfikacji danych, zarządzania dostępem, monitoringu i przygotowania ludzi. Dla zarządu praktycznym punktem wyjścia jest zestaw pytań: czy wiemy, gdzie znajdują się najważniejsze dane; czy posiadamy kopię odporną na zmianę; kiedy ostatnio odtworzyliśmy krytyczny proces; kto podejmuje decyzję o izolacji systemów; jak komunikujemy się z klientami i organami; oraz czy dostawcy potrafią przedstawić dowody działania swoich procedur. Brak odpowiedzi wskazuje obszary wymagające pilnego uporządkowania. 10.1 Krótka lista kontrolna dla organizacji Najważniejsze dane i procesy mają przypisanych właścicieli, RPO, RTO oraz kolejność odtwarzania. Co najmniej jedna kopia jest odseparowana, offline lub niezmienialna i chroniona innymi poświadczeniami niż produkcja. Testy obejmują cały proces biznesowy, a nie wyłącznie odzyskanie pojedynczego pliku. Monitoring wykrywa nieudane zadania, zmianę retencji, kasowanie kopii i nietypową aktywność administratorów. Umowy z dostawcami regulują odzyskiwanie danych, współpracę podczas incydentu i zakończenie usługi. Plan Incident Response wskazuje osoby decyzyjne, kanały komunikacji i sposób współpracy funkcji technicznych, prawnych oraz biznesowych. 11. Jak TTMS pomaga przygotować organizację na incydent? TTMS wspiera organizacje w ocenie zabezpieczeń, tworzeniu polityk bezpieczeństwa, ochronie danych oraz przygotowaniu procedur reagowania i ciągłości działania. Zakres wsparcia obejmuje m.in. audyty cyberbezpieczeństwa, szyfrowanie, DLP, ochronę przed malware, zarządzanie podatnościami, Incident Response oraz planowanie odzyskiwania danych po awarii. Takie podejście pozwala umieścić backup w szerszej strategii bezpieczeństwa. Celem nie jest wyłącznie wykonanie kolejnej kopii, lecz potwierdzenie, że najważniejsze procesy można odtworzyć w założonym czasie, a ryzyko wycieku jest ograniczane przez spójne środki techniczne i organizacyjne. Czy Twoja organizacja potrafi nie tylko wykonać backup, ale także bezpiecznie odtworzyć dane i najważniejsze procesy? Sprawdź usługi cyberbezpieczeństwa TTMS i przygotuj firmę na incydent, zanim do niego dojdzie. Czy backup chroni firmę przed wyciekiem danych? Nie. Backup pomaga odzyskać dane po ich usunięciu, zaszyfrowaniu lub uszkodzeniu, ale nie blokuje ich skopiowania przez osobę nieuprawnioną. Ochrona przed wyciekiem wymaga m.in. kontroli dostępu, szyfrowania, DLP, monitoringu oraz reagowania na incydenty. Jak często firma powinna testować odtwarzanie danych? Częstotliwość powinna wynikać z ryzyka i znaczenia procesu. Systemy krytyczne wymagają częstszych testów niż archiwa o niewielkim wpływie na działalność. Test należy powtarzać także po istotnej zmianie infrastruktury, aplikacji, dostawcy lub polityki backupu. Czy backup w chmurze jest wystarczający? Może być częścią skutecznej strategii, ale sama lokalizacja w chmurze nie gwarantuje odporności. Trzeba sprawdzić separację kont, wersjonowanie, niezmienialność, szyfrowanie, retencję, możliwość eksportu oraz scenariusz utraty dostępu do głównego konta lub dostawcy. Czy zasada 3-2-1-1-0 jest obowiązkiem prawnym? Nie jest uniwersalnym przepisem obowiązującym każdą firmę. To praktyczny model projektowania kopii odpornych na awarie i ransomware. Konkretne środki powinny wynikać z analizy ryzyka, rodzaju danych, obowiązujących regulacji, umów oraz wymaganej ciągłości działania. Od czego zacząć ocenę odporności organizacji? Od inwentaryzacji danych i usług krytycznych, określenia RPO i RTO, przeglądu uprawnień oraz testu odtworzenia wybranego procesu. Wynik powinien prowadzić do planu działań obejmującego technologię, procedury, dostawców i odpowiedzialność konkretnych osób.

    Czytaj więcej
    Ograniczenia AI w oprogramowaniu dla prawników: ryzyko błędnej porady, pisma i terminu

    Ograniczenia AI w oprogramowaniu dla prawników: ryzyko błędnej porady, pisma i terminu

    Prawdziwa sygnatura, za którą kryje się zmyślona teza, to jedna z najbardziej niebezpiecznych halucynacji prawniczych. W czerwcu 2026 roku Naczelny Sąd Administracyjny opisał pismo, w którym zawodowy pełnomocnik powołał trzy istniejące orzeczenia. Problem polegał na tym, że dotyczyły innych zagadnień i nie zawierały przypisanych im tez. Pismo wyglądało wiarygodnie, dopóki ktoś nie otworzył źródeł. Ten przykład dobrze pokazuje praktyczne ograniczenia AI w oprogramowaniu prawniczym. Błąd może wpłynąć na argumentację, ocenę dowodów, termin, poradę dla klienta lub treść pisma procesowego. Za ostateczną treść porady, opinii lub pisma odpowiada prawnik, który je zatwierdza. Ewentualną odpowiedzialność odszkodowawczą ocenia się przez pryzmat należytej staranności zawodowej, zakresu zlecenia oraz okoliczności konkretnej sprawy. W artykule przeczytasz o: najczęstszych błędach AI w pracy prawników, halucynacjach dotyczących przepisów, orzeczeń i sygnatur, konsekwencjach wykorzystania błędnych treści w piśmie procesowym, odpowiedzialności prawnika za poradę przygotowaną z pomocą AI, zasadach bezpiecznego wdrażania oprogramowania AI w kancelarii. Szersze omówienie zgodności, poufności, dostawców i klasyfikacji ryzyka znajdziesz w artykule AI dla prawników w Europie i Wielkiej Brytanii: kluczowe ryzyka i ograniczenia. Tutaj skupiamy się na tym, co może pójść źle w konkretnej sprawie prowadzonej na gruncie polskiego prawa i jak zaprojektować proces, który pomaga wykryć błąd przed wysłaniem porady lub pisma. Prawdziwa sygnatura, fałszywa teza: czego uczy postanowienie NSA I FZ 104/26 W postanowieniu z 23 czerwca 2026 r., I FZ 104/26, NSA rozpoznawał zażalenie na postanowienie odmawiające wstrzymania wykonania decyzji podatkowej. Skarżący powinien był uprawdopodobnić przesłanki określone w art. 61 § 3 p.p.s.a., w szczególności niebezpieczeństwo wyrządzenia znacznej szkody lub spowodowania trudnych do odwrócenia skutków. Pełnomocnik wskazał trzy orzeczenia wraz z rzekomymi tezami. Sąd ustalił, że wskazane orzeczenia dotyczyły innych zagadnień, a ich uzasadnienia nie zawierały przypisanych im tez. Nieprawidłowe były również daty wydania tych rozstrzygnięć. NSA zwrócił też uwagę na inny problem: pismo miało ogólnikowy charakter i nie zawierało konkretnych danych ani dokumentów, które pozwoliłyby ocenić sytuację majątkową strony. Zażalenie zostało oddalone. Sąd krytycznie ocenił bezrefleksyjne użycie AI przez zawodowego pełnomocnika i podkreślił, że klient ma prawo oczekiwać profesjonalizmu. Rozstrzygnięcie pokazuje trzy realne skutki wadliwego procesu pracy: argument prawny może stracić oparcie w źródle, w piśmie może zabraknąć faktów i dowodów decydujących dla rozstrzygnięcia, sąd może zakwestionować rzetelność pracy zawodowego pełnomocnika. Rzetelna weryfikacja orzeczenia obejmuje sprawdzenie sądu, daty, sygnatury i rodzaju rozstrzygnięcia, a następnie lekturę pełnej treści uzasadnienia. Prawnik powinien ocenić kontekst faktyczny, podstawę prawną, znaczenie przywołanego fragmentu, dostępne informacje o prawomocności oraz późniejsze orzecznictwo dotyczące tej samej kwestii. Siedem ograniczeń AI, które mogą zmienić wynik sprawy 1. Prawdziwemu źródłu można przypisać zmyśloną tezę Model może podać prawdziwą sygnaturę sprawy, artykuł ustawy albo tytuł publikacji, a następnie przypisać źródłu treść, której ono nie zawiera. Taki błąd jest groźniejszy od całkowicie zmyślonej sygnatury, ponieważ może pozostać niewykryty podczas pobieżnej kontroli. System powinien prowadzić użytkownika bezpośrednio do konkretnego fragmentu źródła. Nadal konieczna jest weryfikacja przez prawnika. Badanie Stanford RegLab dotyczące amerykańskich narzędzi prawniczych łączących wyszukiwanie w bazach z generowaniem odpowiedzi wykazało halucynacje w 17-33% odpowiedzi. Badanie obejmowało produkty i pytania z rynku USA, więc nie mierzy jakości polskich systemów. Podłączenie modelu do bazy prawnej ogranicza ryzyko. Dalsza kontrola poprawności wymaga dodatkowych zabezpieczeń. 2. Model może zastosować nieaktualny lub niewłaściwy przepis Odpowiedź może brzmieć sensownie i opierać się na przepisie, który został zmieniony, jeszcze nie obowiązuje albo dotyczy innej jurysdykcji. W sprawie transgranicznej model może pomylić prawo właściwe, właściwość sądu i zasady postępowania. System AI dla prawników powinien przy każdym wniosku wskazywać właściwy porządek prawny oraz datę, na którą ustalono stan prawny. Użytkownik musi widzieć wersję aktu, datę wejścia w życie zmiany i źródło urzędowe. Sam napis „aktualne” w interfejsie ma niewielką wartość bez informacji, kiedy i na podstawie czego aktualność została sprawdzona. 3. Model analizuje ograniczony zakres akt Akta mogą być niekompletne, załącznik może nie zostać poprawnie odczytany, a istotny fakt może znajdować się w tabeli, skanie lub wiadomości, której nie dodano do analizy. Model formułuje odpowiedź na podstawie otrzymanego materiału i nie ma pełnej wiedzy o dokumentach, których nie przekazano do analizy. W efekcie stanowczo brzmiąca odpowiedź może powstać na podstawie niepełnego obrazu sprawy. Przed analizą system powinien pokazać listę wykorzystanych plików, błędy odczytu i zakres pominiętego materiału. W sprawach wymagających ustalenia faktów przydatne jest osobne zestawienie twierdzeń, dowodów i brakujących materiałów. Dzięki temu prawnik może zauważyć, że wniosek powstał bez kluczowego dokumentu. 4. Obliczanie terminów procesowych wymaga zdefiniowanych reguł Obliczenie terminu zależy między innymi od rodzaju postępowania, sposobu doręczenia, daty zdarzenia, przepisów przejściowych, dni wolnych oraz wyjątków dotyczących konkretnej czynności. Model językowy może pominąć jeden z warunków albo błędnie odczytać datę ze skanu. Do obliczania terminów należy wykorzystywać kontrolowany mechanizm regułowy z jawnymi danymi wejściowymi. Model może odczytać daty z dokumentów i zasugerować ich znaczenie. Ostateczne wyliczenie wymaga wskazania podstawy prawnej, pokazania sposobu obliczenia oraz zatwierdzenia wyniku przez prawnika prowadzącego sprawę. Terminy, których uchybienie może wywołać skutki procesowe, wymagają niezależnego obliczenia i ponownej weryfikacji. 5. Twierdzenia faktyczne w piśmie przygotowanym z pomocą AI wymagają właściwych dowodów Według prasowych omówień wyroku Sądu Okręgowego we Wrocławiu z 27 listopada 2025 r., X GC 455/25, powód posłużył się ChatGPT przy przygotowaniu pozwu. Podstawą oddalenia powództwa było niespełnienie warunków formalnych zapytania ofertowego. Sąd odniósł się również do treści przygotowanych przy użyciu AI i do wartości przedstawionych materiałów. Wydruki obejmujące wygenerowaną argumentację, analizę prawną i ocenę szans powodzenia nie stanowiły dowodu na fakty istotne dla rozstrzygnięcia sprawy. Mogły zostać potraktowane jako element argumentacji strony. System dla prawników powinien wyraźnie oddzielać twierdzenia, podstawy prawne i materiał dowodowy. Brakująca umowa, korespondencja, potwierdzenie doręczenia lub dokument finansowy pozostają luką dowodową niezależnie od jakości wygenerowanego uzasadnienia. 6. Model może utwierdzać klienta w jego ocenie sprawy Klient często opisuje sprawę jednostronnie i oczekuje potwierdzenia swojej oceny. Model może przyjąć założenia klienta i pominąć argumenty drugiej strony. W poradzie prawnej powstaje wtedy ryzyko, że klient podejmie decyzję bez poznania słabych punktów sprawy. Analiza powinna uwzględniać perspektywę drugiej strony: brakujące fakty, możliwe zarzuty drugiej strony, przeszkody procesowe, alternatywne kwalifikacje prawne i poziom pewności. W komunikacji kierowanej bezpośrednio do klienta użytkownik powinien mieć możliwość przekazania pytania prawnikowi, szczególnie gdy pytanie dotyczy terminu, roszczenia, odpowiedzialności karnej, zwolnienia pracownika albo istotnej decyzji finansowej. 7. Przekonujący styl może ukrywać błędy i niepewność Model generuje odpowiedź słowo po słowie i może zachować ten sam profesjonalny ton przy wniosku trafnym oraz błędnym. Ocena użytkownika oparta na stylu jest więc zawodna. Wskaźnik pewności wyrażony w procentach również może tworzyć pozór precyzji, jeśli wynik nie został skalibrowany dla danego zastosowania. Dobrze zaprojektowany system wskazuje źródła, braki danych, warunki zmieniające odpowiedź i sytuacje, w których system powstrzymuje się od sformułowania jednoznacznej odpowiedzi. System powinien również przewidywać odmowę udzielenia odpowiedzi oraz przekazanie sprawy prawnikowi. Czy klient może twierdzić, że przegrał przez AI? Klient może podnieść taki zarzut. Ocena odpowiedzialności zależy jednak od sposobu wykonania usługi i okoliczności konkretnej sprawy. W relacji umownej zastosowanie znajdują przede wszystkim zasady określone w Kodeksie cywilnym. Zgodnie z art. 355 § 2 k.c. przy ocenie należytej staranności uwzględnia się zawodowy charakter działalności dłużnika. Art. 471 k.c. określa natomiast zasady odpowiedzialności za niewykonanie lub nienależyte wykonanie zobowiązania. Niekorzystne rozstrzygnięcie nie przesądza o nienależytym wykonaniu umowy o świadczenie pomocy prawnej. Ocenie podlega dochowanie należytej staranności zawodowej, prawidłowość ustalenia stanu faktycznego i prawnego oraz adekwatność podjętych czynności. W sporze dotyczącym odpowiedzialności kontraktowej klient powinien wykazać: istnienie i treść zobowiązania, niewykonanie albo nienależyte wykonanie zobowiązania, powstanie szkody, adekwatny związek przyczynowy między uchybieniem a szkodą. Art. 471 k.c. przewiduje domniemanie, że niewykonanie lub nienależyte wykonanie zobowiązania wynika z okoliczności, za które odpowiada dłużnik. Możliwość uwolnienia się od odpowiedzialności wymaga oceny okoliczności konkretnej sprawy. Na ocenę odpowiedzialności może wpływać sposób wykorzystania AI, w szczególności weryfikacja źródeł, uwzględnienie kompletu akt, zastosowanie aktualnego prawa oraz zachowanie kontroli nad ostateczną treścią porady. Znaczenie awarii lub błędu po stronie dostawcy będzie oceniane łącznie z wyborem narzędzia, warunkami umowy, zakresem przeprowadzonych testów oraz sposobem weryfikacji wyników przez prawnika. Przykładowe sytuacje obejmują: uchybienie terminowi wskutek błędnego ustalenia daty doręczenia, odradzenie środka prawnego na podstawie nieaktualnego przepisu, złożenie pisma z cytatem, który nie występuje w powołanym orzeczeniu, zalecenie zawarcia ugody oparte na niepełnych aktach lub błędnym obliczeniu skutków finansowych, udzielenie klientowi stanowczej odpowiedzi przez chatbot bez przekazania sprawy prawnikowi. Opisane sytuacje mają charakter przykładowy. Ocena odpowiedzialności wymaga każdorazowo ustalenia zakresu zlecenia, standardu należytej staranności, szkody oraz związku przyczynowego. Odrębnie mogą zostać ocenione przesłanki odpowiedzialności dyscyplinarnej. Prawo o adwokaturze i ustawa o radcach prawnych przewidują również obowiązek posiadania ubezpieczenia odpowiedzialności cywilnej. Obowiązkowe ubezpieczenie OC nie przesądza o objęciu ochroną każdej szkody związanej z użyciem AI. Zakres odpowiedzialności ubezpieczyciela zależy od warunków ubezpieczenia oraz okoliczności konkretnego zdarzenia. Jakie skutki procesowe może wywołać błędne pismo przygotowane przy użyciu AI? Skutki zależą od rodzaju uchybienia oraz przepisów właściwej procedury. Błąd wynikający z użycia AI jest oceniany tak samo jak każdy inny błąd w piśmie procesowym. Znaczenie ma jego wpływ na spełnienie wymogów formalnych, wykazanie faktów, uzasadnienie żądania oraz dochowanie terminu. W zależności od rodzaju uchybienia konsekwencją może być w szczególności: zwrot pisma, jeżeli nie uzupełniono jego braków formalnych, odrzucenie pozwu lub środka zaskarżenia, gdy zachodzą przesłanki określone we właściwej procedurze, pominięcie wniosku dowodowego albo dowodu, uznanie istotnego faktu za niewykazany, nieuwzględnienie argumentacji opartej na źródle, które nie potwierdza przywołanej tezy, oddalenie wniosku, środka zaskarżenia lub powództwa z powodu niewykazania wymaganych przesłanek, obciążenie strony kosztami postępowania lub zastosowanie sankcji procesowej, jeżeli przewidują ją właściwe przepisy. W sprawie I FZ 104/26 NSA oddalił zażalenie, ponieważ skarżący nie uprawdopodobnił przesłanek wstrzymania wykonania decyzji określonych w art. 61 § 3 p.p.s.a. Ogólnikowa argumentacja i brak dokumentów miały znaczenie dla tej oceny. Błędne odwołania do orzecznictwa były dodatkowym elementem krytycznej oceny sposobu sporządzenia pisma. Ewentualna odpowiedzialność odszkodowawcza pełnomocnika jest rozpatrywana w odrębnym postępowaniu. Odpowiedzialność dyscyplinarna podlega ocenie właściwych organów samorządu zawodowego. Co w 2026 roku wynika z zasad zawodowych i AI Act? 15 czerwca 2026 r. Naczelna Rada Adwokacka poinformowała o podjęciu uchwały zmieniającej Zbiór Zasad Etyki Adwokackiej i Godności Zawodu poprzez dodanie § 23e. Zgodnie z informacją NRA, narzędzia technologiczne powinny pełnić funkcję pomocniczą. Korzystanie z takich narzędzi musi respektować tajemnicę zawodową, samodzielność adwokata i jego osobistą rolę w prowadzeniu sprawy. Rezultat działania narzędzia wymaga własnej oceny i weryfikacji przez adwokata. W odniesieniu do radców prawnych punktem odniesienia są między innymi rekomendacje Krajowej Izby Radców Prawnych dotyczące korzystania z AI. Mają one charakter praktycznych wytycznych i obejmują między innymi odpowiedzialność zawodową, poufność, weryfikację wyników oraz nadzór człowieka. Na poziomie europejskim od 2 lutego 2025 r. stosuje się art. 4 AI Act. Przepis zobowiązuje dostawców i podmioty stosujące systemy AI do podejmowania działań wspierających rozwój kompetencji personelu w zakresie AI. Dobór tych działań powinien uwzględniać wiedzę techniczną, doświadczenie, wykształcenie i szkolenie personelu, a także kontekst, w którym system jest wykorzystywany, oraz osoby, wobec których ma być stosowany. Komisja Europejska wyjaśnia, że sposób wykonania tego obowiązku zależy od roli organizacji i ryzyka związanego z konkretnym zastosowaniem AI. Od 2 sierpnia 2026 r. właściwe organy sprawują nadzór nad wykonywaniem tego obowiązku. Klasyfikacja systemu AI zależy od jego zamierzonego zastosowania. Do systemów wysokiego ryzyka mogą należeć rozwiązania przeznaczone do stosowania przez organ wymiaru sprawiedliwości lub w jego imieniu w celu wspierania tego organu w badaniu i interpretacji faktów i prawa oraz stosowaniu prawa do konkretnego stanu faktycznego. Ocena obejmuje rzeczywistą funkcję systemu, jego przeznaczenie określone przez dostawcę oraz sposób wykorzystania przez podmiot stosujący. Narzędzia kancelaryjne służące do wyszukiwania dokumentów, redagowania tekstu lub przygotowywania streszczeń wymagają indywidualnej klasyfikacji. Samo wykorzystanie systemu w kancelarii lub dziale prawnym nie przesądza o zaliczeniu go do kategorii wysokiego ryzyka. Po zmianach przyjętych w 2026 r. obowiązki dotyczące systemów wymienionych w załączniku III mają być stosowane od 2 grudnia 2027 r. W zależności od funkcji systemu, rodzaju danych i sposobu jego wykorzystania zastosowanie mogą mieć również RODO, przepisy chroniące tajemnicę zawodową, przepisy właściwej procedury oraz zasady odpowiedzialności cywilnej i dyscyplinarnej. Jak projektować system AI dla prawników, aby ograniczać ryzyko? Dobre wdrożenie powinno ułatwiać wykrywanie pomyłek, ograniczać ich wpływ na prowadzoną sprawę i dokumentować wykonanie wymaganej kontroli. Ryzyko Kontrola w produkcie lub procesie Dokumentacja kontroli Fałszywa teza lub cytat Link do pełnej treści źródła i konkretnego fragmentu, podgląd kontekstu oraz obowiązek zatwierdzenia przed eksportem Sąd, data, sygnatura, rodzaj orzeczenia, źródło, wersja dokumentu i osoba zatwierdzająca Nieaktualny stan prawny Metadane jurysdykcji i daty, wersjonowanie aktów oraz sygnalizacja zmian Data, na którą ustalono stan prawny, i wykorzystana wersja przepisu Niekompletne akta Lista przeanalizowanych plików, komunikaty o błędach OCR i wykaz brakujących danych Wykaz dokumentów oraz raport z ich odczytu Błędne obliczenie terminu Mechanizm oparty na zdefiniowanych regułach, jawne dane wejściowe i ponowna kontrola przez człowieka Podstawa prawna, dane wejściowe, przebieg obliczenia i osoba zatwierdzająca Zbyt kategoryczna porada Pytania o brakujące fakty, warunki przekazania sprawy prawnikowi i możliwość odmowy udzielenia odpowiedzi Powód przekazania sprawy i podjęte dalsze działania Ujawnienie informacji objętych tajemnicą zawodową Uprawnienia na poziomie sprawy, kontrola dostępu dostawcy i jego podwykonawców, określone miejsce przetwarzania, zasady retencji i usuwania danych oraz wyłączenie wykorzystywania danych klienta do trenowania modeli Rejestr dostępu, konfiguracja dostawcy, okres przechowywania, informacje o podwykonawcach i dokumentacja incydentów Zmiana jakości po aktualizacji systemu Testy na reprezentatywnych sprawach przed wdrożeniem i po zmianie modelu Wyniki testów, wersja modelu i decyzja o dopuszczeniu nowej wersji Zakres dokumentowania powinien być proporcjonalny do ryzyka. Rejestry audytowe, w tym historia promptów i wyników, mogą zawierać informacje objęte tajemnicą zawodową. Organizacja powinna określić zakres zapisywanych danych, krąg osób uprawnionych do dostępu, okres przechowywania, zasady usuwania oraz sposób zabezpieczenia rejestrów. Pełna historia pracy z systemem nie musi być przechowywana, jeżeli do wykazania wykonanej kontroli wystarczy węższy zakres informacji. Do opisanego wcześniej przypadku pisma z błędnymi odwołaniami do orzecznictwa wraca Natalia Lener-Bobek, partner w Kancelarii Prawnej Sawaryn i Partnerzy. Zwraca uwagę na decyzje podejmowane jeszcze przed rozpoczęciem pracy z AI: wybór narzędzia i warunki umowy z jego dostawcą. „Ten przykład pokazuje błąd użytkownika. Ryzyko powstaje już wcześniej, przy wyborze samego narzędzia. Kancelarie sprawdzają, czy model dobrze odpowiada, i pomijają umowę, na podstawie której z niego korzystają. Rejestr promptów i wyników, o którym mowa w artykule, istnieje tylko wtedy, gdy dostawca zobowiązał się go prowadzić i udostępniać na żądanie – to zapis w umowie, nie funkcja, którą się zakłada. Przed wdrożeniem sprawdzam z klientami trzy rzeczy: czy umowa wskazuje, kto odpowiada za błędny wynik systemu, czy dostawca gwarantuje dostęp do logów zapytań przez okres wystarczający na obronę w ewentualnym sporze, i czy dane objęte tajemnicą zawodową w ogóle mogą trafiać do tego narzędzia zgodnie z warunkami przetwarzania. Bez odpowiedzi na te trzy pytania obowiązek szkolenia personelu z art. 4 AI Act i tak nie ma na czym się oprzeć” Natalia Lener-Bobek Partner w Kancelarii Prawnej Sawaryn i Partnerzy Bezpieczny podział pracy między systemem a prawnikiem Przydział zadań warto uzależnić od możliwej szkody oraz łatwości wykrycia błędu. Zadanie Rola AI Wymagana kontrola Streszczenie długiego dokumentu Przygotowanie roboczego skrótu z odwołaniami do stron Kontrola fragmentów istotnych dla decyzji Porównanie wersji umowy Wykrycie i uporządkowanie zmian Ocena znaczenia prawnego przez prawnika Wyszukiwanie i analiza orzecznictwa Wyszukanie potencjalnie istotnych orzeczeń i zebranie odpowiednich fragmentów Lektura pełnej treści orzeczenia oraz ocena jego kontekstu faktycznego i prawnego Pismo procesowe Przygotowanie projektu struktury, redakcja i kontrola spójności Pełna weryfikacja faktów, dowodów, żądań, podstaw prawnych i załączników Termin procesowy Odczytanie dat i wskazanie potencjalnie właściwych reguł obliczania terminu Ustalenie zdarzenia rozpoczynającego bieg terminu, podstawy prawnej, sposobu obliczenia i skutków uchybienia terminowi Termin materialnoprawny Uporządkowanie dat i wskazanie przepisów wymagających analizy Ustalenie charakteru terminu, początku i końca jego biegu oraz skutków upływu Przedawnienie Uporządkowanie zdarzeń mogących wpływać na bieg przedawnienia Ocena początku biegu, jego zawieszenia lub przerwania oraz daty upływu terminu przedawnienia Ostateczna porada dla klienta Przygotowanie materiałów roboczych i wariantów analizy Osobista ocena, zatwierdzenie i komunikacja prawnika Takie podejście jest zgodne z praktycznym kierunkiem wskazanym przez CCBE w przewodniku dla prawników: prawnik pozostaje odpowiedzialny za swoją pracę, poradę i oświadczenia, a wynik działania generatywnej AI wymaga kontroli przed wykorzystaniem. Bezpieczne wdrożenie AI w kancelarii zaczyna się od analizy procesu Pierwszym krokiem jest wskazanie, gdzie wynik wygenerowany przez AI może wpłynąć na poradę dla klienta, pismo procesowe, ocenę dokumentu lub obliczenie terminu. Na tej podstawie można określić właściwe źródła danych, zakres uprawnień, zasady weryfikacji oraz osoby odpowiedzialne za zatwierdzanie wyników. Jeżeli planujesz wykorzystać AI do analizy akt, pracy z dokumentami lub przygotowywania umów, poznaj rozwiązanie AI4Legal. Pomagamy kancelariom i działom prawnym zaprojektować narzędzia dopasowane do ich sposobu pracy, wymagań bezpieczeństwa i zakresu odpowiedzialności prawników. Źródła Naczelny Sąd Administracyjny, postanowienie z 23 czerwca 2026 r., I FZ 104/26. Prawo o postępowaniu przed sądami administracyjnymi, tekst jednolity, Dz.U. z 2026 r. poz. 143. Kodeks cywilny, tekst jednolity. Ustawa Prawo o adwokaturze, tekst jednolity. Ustawa o radcach prawnych, tekst jednolity. Naczelna Rada Adwokacka, zmiany zasad etyki dotyczące AI, 15 czerwca 2026 r.. Krajowa Izba Radców Prawnych, rekomendacje dotyczące korzystania z AI. CCBE, Guide on the use of generative AI for lawyers, 2 października 2025 r.. Komisja Europejska, ramy regulacyjne AI Act oraz wyjaśnienia dotyczące AI literacy. Rozporządzenie (UE) 2026/1744 zmieniające harmonogram stosowania części AI Act. Stanford RegLab, Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. Dziennik Gazeta Prawna, omówienie wyroku SO we Wrocławiu X GC 455/25, 7 stycznia 2026 r.. Dziennik Gazeta Prawna, wywiad dotyczący podstaw oddalenia powództwa w sprawie X GC 455/25. Stan prawny i źródłowy: 1 września 2026 r. Materiał ma charakter informacyjny i nie stanowi porady prawnej. FAQ: ograniczenia AI w oprogramowaniu prawniczym Czy klient może żądać odszkodowania, jeśli błędna porada powstała z użyciem AI? Takie roszczenie jest możliwe. Odpowiedzialność zależy od sposobu wykonania usługi, powstałej szkody i związku przyczynowego. Kluczowe są nienależyte wykonanie usługi, szkoda i związek przyczynowy. Ocenie podlega też zawodowa należyta staranność, w tym sposób weryfikacji wyniku narzędzia. Czy sąd odrzuci pismo tylko dlatego, że przygotowano je z AI? Nie ma ogólnej polskiej zasady nakazującej odrzucenie pisma z tego powodu. Sąd ocenia wymagania formalne, terminowość, argumenty i dowody według właściwej procedury. Błędne cytaty, brak dowodów lub wadliwe żądanie mogą jednak wywołać zwykłe skutki procesowe. Czy AI może samodzielnie pilnować terminów procesowych? Dla terminów krytycznych AI powinno działać jako element szerszego procesu obejmującego kontrolowane reguły i zatwierdzenie człowieka. Bezpieczniejszy proces wykorzystuje kontrolowane reguły, jawne daty wejściowe, podstawę prawną, zatwierdzenie człowieka i niezależne przypomnienie. Jak sprawdzić, czy orzeczenie rzeczywiście wspiera tezę wygenerowaną przez AI? Trzeba otworzyć pełną treść w urzędowej lub wiarygodnej bazie, odnaleźć wskazany fragment, przeczytać jego kontekst i sprawdzić datę, skład, rodzaj rozstrzygnięcia oraz stan prawny. Sama zgodność sygnatury i nazwy sądu nie potwierdza tezy. Czy trzeba zachowywać wszystkie prompty i odpowiedzi AI w aktach sprawy? Nie istnieje jeden ogólny obowiązek przechowywania pełnej historii każdej interakcji. Zakres dokumentowania powinien wynikać z ryzyka, zasad kancelarii, tajemnicy zawodowej, ochrony danych i potrzeb audytowych. W sprawach o większym znaczeniu warto zachować źródła, wersję systemu, zakres kontroli i informację o osobie zatwierdzającej.

    Czytaj więcej
    Wiktor Janicki

    Transition Technologies MS świadczy usługi informatyczne terminowo, o wysokiej jakości i zgodnie z podpisaną umową. Polecamy firmę TTMS jako godnego zaufania i rzetelnego dostawcę usług IT oraz partnera wdrożeniowego Salesforce.

    Czytaj więcej
    Julien Guillot Schneider Electric

    TTMS od lat pomaga nam w zakresie konfiguracji i zarządzania urządzeniami zabezpieczającymi z wykorzystaniem różnych technologii. Ueługi świadczone przez TTMS są realizowane terminowo, i zgodnie z umową.

    Czytaj więcej

    Już dziś możemy pomóc Ci rosnąć

    Porozmawiajmy, jak możemy wesprzeć Twój biznes

    TTMC Contact person
    Monika Radomska

    Sales Manager