Agent AI - porównanie perspektyw

Dlaczego porównałem dwa warianty?

Praca z dokumentacją naturalnie skłania do pytań o automatyzację i wsparcie AI. W praktyce pojawiają się co najmniej dwa podejścia:

• wariant chmurowy - agent w usłudze zewnętrznej, wygodny start, integracja z dokumentami, rozliczanie według modelu usługi (w tym limity i tokeny),
• wariant lokalny - model na własnym komputerze (tu: Ollama i Mistral 7B), generowanie bez limitu tokenów dostawcy, przy koszcie sprzętu, czasu i energii.

Technologię dobrałem dopiero po określeniu pytania porównawczego i celu. W moim laboratorium kluczowe są: prywatność danych, kontrola nad środowiskiem oraz możliwość pracy bez zewnętrznego dostawcy. To nie znaczy, że chmura jest zła - po prostu nie jest najlepszym wyborem dla tego konkretnego celu i warunków.

Wariant chmurowy i wariant lokalny - zestawienie

Poniższe zestawienie nie ma charakteru ogólnej prawdy technicznej. Pokazuje typowe cechy obu ścieżek z perspektywy mojego wdrożenia: tam, gdzie priorytetem są prywatność, kontrola i własne laboratorium, wariant lokalny jest bardziej atrakcyjny - choć nie bez wad.

Lokalność nie oznacza automatycznie „bezpieczniej we wszystkim”. Oznacza inną granicę zaufania: mniej zależności od zewnętrznego API i więcej odpowiedzialności za własny system. Chmura ma kluczowe znaczenie w kontekście celu wykorzystania narzędzia oraz odpowiednich kontroli, takich jak normy ISO/IEC 27001:2022 (np. A.5.23 dla usług chmurowych oraz A.8.1 dla urządzeń końcowych).

Cel biznesowy / Służbowy i spełnienie wymagań normy ISO/IEC 27001 oraz regulacji prawnych

Kluczowe wymagania i kontrole przy korzystaniu z chmury do celów służbowych:

• Tylko wersje biznesowe / Enterprise / API: zakaz używania darmowych narzędzi AI, bo dane mogą zostać użyte do trenowania modeli publicznych.
• Zapis o poufności w umowie: formalna umowa z dostawcą AI gwarantująca prywatność promptów i danych wejściowych.
• Zasady dla pracowników: wyraźna polityka, co wolno wklejać do AI, a czego nie wolno, np. dane klientów, kod źródłowy, finanse.
• Kontrola lokalizacji (RODO): wiedza, gdzie dane są przetwarzane i przechowywane oraz czy jest to obszar UE.
• Bezpieczny dostęp: obowiązkowe MFA przy logowaniu do kont AI oraz przydział odpowiedzialności administracyjnej.
• Plan awaryjny (exit plan): procedura odzyskiwania danych, przeniesienia do innego dostawcy i zabezpieczenia ciągłości pracy.

Nie jest to wszystko, a jedynie absolutne minimum, które należy zweryfikować przed wykorzystaniem narzędzi AI do pracy z danymi firmowymi.

Fine-tuning, RAG - jak się w tym połapać?

Przy dołączaniu wiedzy do modelu łatwo pomylić trzy różne podejścia:

• Dotrenowanie modelu (fine-tuning) - zmiana wag na własnych danych. Kosztowne i złożone; przy większej zmianie procedur proces trzeba powtarzać. W tym projekcie tego nie robiłem.
• RAG (Retrieval-Augmented Generation) - system wyszukuje fragmenty dokumentów pasujące do pytania i dołącza je do promptu. Działa dobrze przy dużej dokumentacji, ale wymaga indeksu i pipeline'u. Pełnego RAG tu nie ma.
• Ograniczony kontekst + generowanie lokalne. W tym projekcie z HTML buduję ograniczoną bazę wiedzy, Python przekazuje ją do Ollamy razem z promptem, wynik trafia do JSON, a strona tylko go pokazuje. To jest wariant użyty w tym projekcie.

Limit ok. 12 000 znaków kontekstu wynika z praktyki. Przy rozroście dokumentacji naturalnym kolejnym krokiem mógłby być RAG, a niekoniecznie od razu dotrenowanie modelu.

Architektura

Dokumentacja ograniczony kontekst Ollama Python JSON weryfikacja SecureHaveNET

Publiczna strona nie łączy się z modelem. Generowanie jest lokalne; demonstrator odczytuje przygotowany cache. Dzięki temu nie wystawiam Ollamy do internetu i nie buduję publicznego API generowania.

Środowisko i model

• Sprzęt - AMD Ryzen 7 7435HS, 16 GB RAM, NVIDIA GeForce RTX 4060 - GPU (8 GB)
• Model: mistral:latest w Ollamie (typowo model Mistral 7B; dokładna wersja zależy od tagu pobranego w danym momencie)
• Temperatura: 0,2 - niższa losowość, bardziej przewidywalne odpowiedzi; to nie jest miara ryzyka ani zgodności
• Kontekst w skrypcie: num_ctx = 8192, timeout 300 s, atomowy zapis JSON po każdej odpowiedzi

Jak działa demonstrator?

Wybierz pytanie, aby zobaczyć odpowiedź wygenerowaną lokalnie. Interfejs strony jedynie wczytuje gotowy plik JSON - bez połączenia z Ollamą w przeglądarce.

Co wynika z odpowiedzi demonstratora?

Czas generowania pochodzi z pomiaru w skrypcie.

Uwaga: im krótszy czas odpowiedzi na pytanie, tym lepiej - o ile zachowana jest poprawność, spójność i zgodność z rzeczywistością.

Średni czas dla tego zestawu: ok. 12,56 s na pytanie (od ok. 4,92 s do ok. 22,38 s). To daje realistyczny obraz wydajności lokalnego modelu w tym konkretnym pipeline (pipeline - zautomatyzowany ciąg kroków, które przekształcają surowe dane w działający model AI, a następnie pozwalają na korzystanie z niego w gotowej aplikacji) i na tym sprzęcie.

Wniosek jakościowy (Check): Pomiary pokazują, że czas generowania (od ok. 4,9 s do ponad 22 s) zależy od złożoności zapytania oraz struktury promptu. Szybka odpowiedź nie oznacza jednak automatycznie pełnej poprawności merytorycznej - przykładowo, pytania o parametry techniczne (jak rola temperatury 0,2) wymagały krytycznego spojrzenia, ponieważ model bywa zbyt ostrożny lub nieprecyzyjny. Faza sprawdzenia (Check) musi więc obejmować nie tylko parametry sprzętowe, ale przede wszystkim weryfikację treści pod kątem biznesowym i audytowym.

Ryzyka, których lokalność nie kasuje

• dostęp do komputera i konta, na którym działa Ollama,
• jakość i aktualność bazy wiedzy,
• błędne lub zbyt pewne odpowiedzi modelu,
• pokusa traktowania odpowiedzi jak zatwierdzonej procedury,
• logi, cache i pliki JSON z treścią,
• ewentualne późniejsze podpięcie internetu lub systemów wewnętrznych bez nowej analizy ryzyka.

Human-in-the-Loop

LLM propozycja weryfikacja decyzja człowieka

Model może przyspieszyć uporządkowanie wiedzy i wskazać ryzyka. Nie ponosi odpowiedzialności za zgodność procedury, decyzję jakościową ani bezpieczeństwo. Odpowiedź dotycząca temperatury w demonstratorze pokazuje, że nawet przy prostej konfiguracji model bywa nieprecyzyjny - stąd weryfikacja nie jest ozdobą procesu, lecz jego niezbędną częścią.

Jak budowałem rozwiązanie

Zdefinowanie problemu ryzyko wybór architektury zgodny z celem implementacja test korekta moja decyzja

• Plan - porównać wariant lokalny z wariantem chmurowym pod kątem limitu generowania, prywatności i kosztów.
• Wykonanie - Ollama, Mistral 7B, Python, ograniczony kontekst HTML, JSON, statyczna strona.
• Sprawdzenie - działanie rozwiązania, czasy generowania, treść odpowiedzi demonstratora oraz ich jakościowa weryfikacja.
• Korekta (Act) - m.in. timeout 300 s, limit kontekstu, atomowy zapis cache po każdej odpowiedzi, a także wdrożenie procedury cyklicznego przeglądu wygenerowanych treści (Human-in-the-Loop) przed ich zatwierdzeniem jako obowiązujących wytycznych w organizacji.

Porównanie: Ollama (Mistral 7B), Gemini i Grok

Te same siedem pytań, zbliżony profil systemowy (SecureHaveNET, GRC, lokalna inferencja). Pomiary lokalne pochodzą ze skryptu oraz Ollamy na sprzęcie projektu. Wyniki chmurowe (Gemini, Grok) to osobne przebiegi - służą jako porównanie.

* Czas chmurowy nie jest pomiarem perf_counter na stacji z Ollamą - co oznacza, że nie zestawiamy tu wyników w identycznych warunkach laboratoryjnych. Pomiar lokalny to twardy, techniczny odczyt z użyciem funkcji perf_counter() w skrypcie na własnym sprzęcie, podczas gdy czasy chmurowe bazują na zewnętrznych odpowiedziach infrastruktury dostawców. To celowe zestawienie skrajnych środowisk, a nie test procesorów na tych samych zasadach.

Wniosek: wariant chmurowy wygrywa latencją i często krótszą, bardziej skondensowaną odpowiedzią. Wariant lokalny - kontrolą oraz prywatnością przetwarzania zapytań i dokumentacji. „Szybciej” nie oznacza automatycznie „więcej treści”, a dłuższa odpowiedź lokalna nie oznacza automatycznie wyższej precyzji.

Wnioski

1. Da się zbudować lokalnego asystenta opartego o własną treść bez publicznego API modelu.
2. Wariant lokalny i wariant chmurowy odpowiadają na podobną potrzebę, ale w moim przypadku to lokalne rozwiązanie ma przewagę z uwagi na prywatność, pełną kontrolę, przewidywalność kosztów i niezależność od subskrypcji.
3. Brak limitu tokenów u dostawcy nie oznacza generowania za darmo: pozostają sprzęt, czas obliczeń, energia i odpowiedzialność za środowisko wykonawcze.
4. W tym projekcie nie dotrenowywałem modelu i nie zbudowałem pełnego RAG - użyłem ograniczonego kontekstu. To świadomy kompromis prostoty i kontroli.
5. Odpowiedzi modelu bywają pomocne, bywają też nieprecyzyjne. Dlatego pozostaje Human-in-the-Loop, niezależnie od tego, czy mówimy o modelu chmurowym czy lokalnym.
6. To projekt demonstracyjny, a nie gotowy system pod całą dokumentację organizacyjną. W moim laboratorium jednak lokalny wariant jest praktycznym i sensownym wyborem.
7. Wdrożenie lokalnego agenta to nie tylko wybór techniczny (GPU, Ollama), ale decyzja z zakresu Governance, Risk and Compliance (GRC) - przeniesienie odpowiedzialności za bezpieczeństwo logów, ciągłość działania i weryfikację wyników całkowicie na własny zespół.

Podsumowanie

Każde z podejść ma swoje zalety i ograniczenia. W warunkach chmurowych agent zwykle wygrywa wygodą, skalowalnością integracji i mniejszym progiem wejścia. Jednak w moim modelu użytkowania - laboratorium, prywatność, pełna kontrola nad środowiskiem, brak uzależnienia od subskrypcji i możliwość wpływania na każdy element procesu - lokalna ścieżka jest praktyczniejsza i bardziej zgodna z potrzebami.

• kontrola nad danymi i zapytaniami - generowanie pozostaje na własnym sprzęcie,
• przewidywalność limitów generowania - zamiast tokenów dostawcy obowiązują zasoby maszyny i czas,
• możliwość przejścia mechanizmu end-to-end - od promptu i kontekstu, przez pomiar czasu, po świadome oddzielenie generowania od warstwy publicznej,
• prostsza granica ekspozycji - publiczna strona może jedynie odczytywać JSON, bez wystawiania modelu do sieci,
• elastyczność eksperymentu - kontrola nad modelem, temperaturą, kontekstem i momentem uruchomienia generowania.

Ograniczenia wariantu lokalnego też są jasne: czas odpowiedzi, utrzymanie środowiska, brak gotowych integracji chmurowych oraz konieczność samodzielnego dbania o aktualność wiedzy i bezpieczeństwo informacji.

Najważniejsza lekcja pozostaje wspólna dla obu ścieżek i zgodna z podejściem do GRC:

Źródła i dokumenty odniesienia

• Ollama - lokalne środowisko uruchamiania modeli językowych.
• mistral:latest - model Mistral 7B w bibliotece Ollama.
• Microsoft Copilot Studio - dokumentacja - oficjalna dokumentacja platformy agentów w ekosystemie Microsoft.
• Rozporządzenie (UE) 2024/1689 (AI Act) - unijne ramy prawne dotyczące systemów AI, w tym m.in. transparentności i zarządzania ryzykiem.
• Large language model - hasło encyklopedyczne (Wikipedia) wprowadzające w pojęcie modeli językowych.
• NIST AI Risk Management Framework (AI RMF 1.0) - framework zarządzania ryzykiem systemów AI (National Institute of Standards and Technology).
• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements
• ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls.

Odpowiedzi w demonstratorze zostały wygenerowane automatycznie przez lokalny model językowy. Zgodnie z zasadą przejrzystości treści AI wymagają weryfikacji człowieka i nie stanowią samodzielnej rekomendacji prawnej, jakościowej ani decyzyjnej. Odniesienie do AI Act dotyczy ram regulacyjnych UE; ten projekt demonstracyjny nie jest oceną zgodności konkretnego systemu z rozporządzeniem.