AI dla CTO – 8 decyzji architektonicznych, które przesądzą o kosztach i bezpieczeństwie wdrożenia AI

W większości średnich firm rozsądnym punktem wyjścia jest chmura. Usługi takie jak Microsoft Foundry (dawniej Azure AI Foundry), Amazon Bedrock czy Google Vertex AI dają dostęp do aktualnych modeli bez kupowania sprzętu. Płacisz za zużycie, a za dostępność i aktualizacje odpowiada dostawca.

Model hybrydowy oznacza, że część danych przetwarzasz u siebie, a część w chmurze. Ma sens, gdy masz dane, które z powodów prawnych lub umownych nie mogą opuścić firmy, np. dokumentację medyczną. Kosztuje więcej, bo utrzymujesz dwa środowiska i zasady przepływu danych między nimi.

Wyłącznie własne serwery wybiera się rzadko. Uzasadnieniem bywa zakaz przetwarzania danych w chmurze wynikający z umowy z klientem, bardzo duża liczba zapytań albo strategia ochrony know-how. Przed taką decyzją sprawdź, czy wymóg rzeczywiście wyklucza chmurę, czy tylko określa region przetwarzania danych.

Model AI nie jest wyborem na lata. Dostawcy co kilka miesięcy wydają nowe wersje i wyłączają stare, a ceny i jakość zmieniają się szybciej niż w większości obszarów IT. Architektura musi to przewidywać.

Najprostsza zasada: aplikacja nie powinna wywoływać modelu konkretnego dostawcy bezpośrednio w wielu miejscach kodu. Lepiej zbudować jedną warstwę pośrednią, która przyjmuje zapytanie i przekazuje je do wybranego modelu. Wymiana modelu oznacza wtedy zmianę konfiguracji i testy, a nie przebudowę aplikacji.

Opłaca się też dobierać model do zadania. Proste zadania, takie jak klasyfikacja maili czy krótkie odpowiedzi, obsłużą mniejsze i tańsze modele. Duże modele zostaw do analizy długich dokumentów i trudnych pytań. Przy każdej zmianie modelu uruchom ten sam zestaw testowych pytań i porównaj odpowiedzi.

Większość firmowych rozwiązań AI działa w modelu RAG: przed odpowiedzią system wyszukuje pasujące fragmenty firmowych dokumentów i przekazuje je modelowi. Przypomina to pracownika, który przed odpowiedzią klientowi zagląda do właściwej instrukcji. Jakość odpowiedzi zależy więc w dużej mierze od jakości wyszukiwania.

Do takiego wyszukiwania potrzebna jest baza, która znajduje fragmenty podobne znaczeniowo, a nie tylko po słowach kluczowych. Opcje opisuje tabela poniżej. W firmie, która pracuje na Microsoft 365 i Azure, naturalnym wyborem jest Azure AI Search. Jeśli już masz bazę PostgreSQL, rozszerzenie pgvector pozwala zacząć bez nowego systemu.

Typowy błąd to traktowanie wyboru bazy jako najważniejszej decyzji. Ważniejsze są dobrze podzielone dokumenty, aktualne wersje i uprawnienia przeniesione z systemu źródłowego. Bez nich każda baza zwróci nieaktualny albo niedozwolony fragment.

Rozwiązanie AI bez monitorowania jest czarną skrzynką. Nie wiesz, ile kosztuje pojedyncze zapytanie, które pytania kończą się złą odpowiedzią ani dlaczego koszt w tym miesiącu wzrósł dwukrotnie. Dopisanie monitorowania po roku zwykle oznacza przebudowę dużej części systemu.

Minimum to zapis każdego wywołania modelu z kilkoma informacjami wymienionymi poniżej. Do tego dochodzi zestaw testowych pytań z poprawnymi odpowiedziami, uruchamiany po każdej zmianie. Do zbierania danych możesz użyć narzędzi, które już masz, np. Azure Monitor, albo wyspecjalizowanych narzędzi do monitorowania AI.

Pamiętaj, że zapisy zapytań zawierają często dane osobowe i tajemnice firmy. Ustal okres ich przechowywania i dostęp tylko dla wąskiej grupy osób.

AI zmienia trzy obszary bezpieczeństwa. Pierwszy to dane wysyłane do modelu: dane osobowe i tajemnice firmy trzeba wykrywać i w razie potrzeby usuwać lub maskować przed wysłaniem. Drugi to uprawnienia: asystent AI znajdzie w kilka sekund dokument, który wcześniej był ukryty tylko dlatego, że nikt o nim nie wiedział.

Trzeci obszar to tzw. wstrzykiwanie poleceń (ang. prompt injection), czyli ukrycie w mailu lub dokumencie instrukcji, którą AI może potraktować jak polecenie. Ryzyko rośnie, gdy agent AI ma dostęp do systemów i może sam coś zmienić lub wysłać. Podstawowe zabezpieczenia to oddzielenie instrukcji od treści z zewnątrz, kontrola wyników i akceptacja człowieka przed działaniami, których nie da się cofnąć.

Jeśli Twoja firma jest podmiotem kluczowym lub ważnym w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, rozwiązania AI wchodzą w zakres zarządzania ryzykiem. Uwzględnij je w systemie zarządzania bezpieczeństwem informacji, który trzeba wdrożyć do 3 kwietnia 2027 r.

Każdy wybór – dostawcy modelu, bazy wiedzy, chmury – tworzy pewne uzależnienie. Całkowicie go nie unikniesz, ale możesz świadomie decydować o jego poziomie. Prosty test: ile czasu zajęłoby przeniesienie rozwiązania do innego dostawcy modelu? Jeśli odpowiedź brzmi „kilka miesięcy”, uzależnienie jest wysokie.

Wysokie uzależnienie nie zawsze jest błędem. Firma, która pracuje w Microsoft 365, często świadomie wybiera Copilota i Copilot Studio, bo dostaje gotową integrację z uprawnieniami, Teams i SharePoint. Ważne, żeby to była decyzja, a nie przypadek.

Niezależnie od wyboru zadbaj o to, żeby instrukcje dla modelu, zestawy testowe i konfiguracja należały do firmy i były zapisane poza narzędziem dostawcy. To one są najcenniejszym wynikiem projektu.

Rozwiązanie AI trzeba utrzymywać: aktualizować model, poprawiać instrukcje, reagować na błędne odpowiedzi i pilnować kosztów. Wdrożenie bez osób, które potrafią to robić, kończy się narzędziem, z którego po kilku miesiącach nikt nie korzysta.

W średniej firmie rzadko potrzebny jest osobny zespół AI. Zwykle wystarczy jedna lub dwie osoby z działu IT, które rozumieją działanie modeli, integracje z systemami i monitorowanie. Do tego zewnętrzny partner na etapie budowy i przy większych zmianach.

Masz trzy drogi, które najczęściej się łączy: rekrutację, przeszkolenie własnych ludzi i współpracę z partnerem. Przy współpracy z partnerem zapisz w umowie przekazanie wiedzy i dokumentacji. Bez tego zamienisz jedno uzależnienie na drugie.

API to łącze, przez które Twoja aplikacja korzysta z modelu działającego u dostawcy. Płacisz za zużycie, liczone w tokenach, czyli kawałkach tekstu. Alternatywą jest uruchomienie modelu o otwartych wagach, który można pobrać i zainstalować na własnym sprzęcie.

Porównując koszty, zestaw dwie kwoty. Koszt API to miesięczna liczba tokenów pomnożona przez cenę z cennika dostawcy. Koszt własnego modelu to serwery z kartami graficznymi, prąd, czas administratorów, monitorowanie i aktualizacje. Ten drugi koszt ponosisz także wtedy, gdy nikt nie wysyła zapytań.

Przy liczbie zapytań typowej dla średniej firmy API jest zwykle tańsze i prostsze. Własny model ma sens, gdy dane nie mogą opuścić firmy albo gdy wolumen jest bardzo duży i stały. Pamiętaj też, że modele otwarte również się starzeją, a ich wymianę przeprowadzasz sam.