AI on premise czy w chmurze: co naprawdę decyduje o wyborze dla Twojej firmy

Jeśli Wasze dane są objęte tajemnicą zawodową, kontraktami z klauzulami poufności albo sektorowymi wymogami prawnymi, własny serwer jest często jedyną bezpieczną opcją. Jeśli takich ograniczeń nie ma albo można wyraźnie oddzielić wrażliwe dane od reszty procesów, chmura publiczna jest szybsza na start, łatwiejsza w utrzymaniu i rzadko kiedy droższa w pierwszych dwóch latach. Pytanie "AI on premise czy w chmurze" ma w praktyce rzadko odpowiedź zero-jedynkową: większość firm, które przeprowadzamy przez wdrożenie, kończy na modelu mieszanym.

Gdzie leżą dane i kto ma do nich dostęp: to pytanie rozstrzyga wybór

Kiedy firma wysyła zapytanie do modelu AI w chmurze, razem z nim idą dane: treść dokumentu, fragment bazy klientów, skan faktury albo opis sprawy serwisowej. Te dane trafiają na serwery dostawcy, gdzie są przetwarzane. Ile czasu tam zostają? Kto ma do nich dostęp po stronie dostawcy? Czy trafiają do trenowania modelu? To nie są pytania teoretyczne.

U jednego klienta z branży medycznej okazało się przy okazji audytu, że narzędzie SaaS, z którego od miesięcy korzystali pracownicy, przetwarzało dane na serwerach poza UE bez podpisanej standardowej klauzuli umownej. Sam transfer nie był zakazany, ale brakowało dokumentacji wymaganej przez RODO. Ten problem można było odkryć wcześniej, czytając umowę przed podpisaniem, a nie po.

Warto zadać dostawcy konkretne pytania, zanim cokolwiek podpiszecie:

• Gdzie fizycznie są serwery, na których przetwarzane są nasze dane?
• Czy dane są przechowywane po zakończeniu sesji lub po wygaśnięciu subskrypcji, a jeśli tak, przez jak długo?
• Czy dostawca może używać naszych danych do trenowania lub poprawiania swoich modeli?
• Kto po stronie dostawcy ma dostęp do danych przesyłanych przez API i na jakich zasadach?

Jeśli dostawca nie potrafi odpowiedzieć na te pytania albo odsyła wyłącznie do "regulaminu", regulamin jest miejscem, które trzeba przeczytać.

Co jest w umowie SaaS, o czym nikt nie mówi na prezentacji sprzedażowej

Odpowiedzi na powyższe pytania są w dokumentach. Dostawcy ich nie ukrywają. Po prostu nie eksponują ich w slajdach.

W Data Processing Agreement i Terms of Service warto szukać konkretnie:

• Klauzula "service improvement" lub "model training": czy dane mogą być użyte do trenowania lub poprawy modelu? Wersje enterprise większości dużych dostawców to wykluczają, tańsze plany często nie.
• Data retention po zakończeniu umowy: ile czasu dostawca trzyma Wasze dane po tym, jak przestaniecie płacić? Typowo od 30 do 90 dni, ale bywa inaczej i warto to sprawdzić.
• Lista sub-processors: firmy, którym dostawca może przekazać Wasze dane. Lista jest często długa i zmienia się dynamicznie, zwykle z 30-dniowym wyprzedzeniem, bez konieczności uzyskania zgody.
• "For support purposes": standardowe sformułowanie, które oznacza, że pracownicy dostawcy mogą zajrzeć do Waszych danych przy rozwiązywaniu zgłoszeń.

To nie jest argument przeciwko chmurze. To argument za czytaniem umów. Różnica między planem standardowym a enterprise często sprowadza się właśnie do tych paragrafów, nie do funkcjonalności widocznych w interfejsie.

Koszt on premise w trzyletnim horyzoncie: co napędza rachunek

Porównywanie kosztów "serwer kontra chmura" na podstawie jednego miesiąca to błąd, który popełnia większość firm podejmujących tę decyzję. Miesiąc premiuje chmurę. Trzy lata pokazują inny obraz, ale niekoniecznie taki, jakiego oczekują zwolennicy własnego serwera.

W modelu chmurowym płacicie co miesiąc: licencję, koszt tokenów (zależy od liczby zapytań i ich długości), ewentualnie opłaty za API calls. Przy małej skali to niskie kwoty. Przy rosnącym wolumenie koszt rośnie proporcjonalnie do użycia. Firma procesująca kilkadziesiąt tysięcy dokumentów miesięcznie jest w zupełnie innym miejscu cenowym niż firma z kilkuset dokumentami, i warto ten wolumen oszacować przed wyborem modelu.

W modelu on premise macie duży koszt na wejściu: sprzęt (w tym karta GPU, jeśli chcecie uruchamiać większe modele lokalnie), wdrożenie, ewentualna licencja. Potem koszty stałe: prąd, administrator systemu, aktualizacje oprogramowania. I tutaj jest wątek, o którym dostawcy on premise zwykle nie mówią wprost.

Modele AI rozwijają się szybko. Model wdrożony dziś może być wyraźnie słabszy od tego, co będzie dostępne w chmurze za dwa lata. Migracja do nowszego modelu on premise to osobny projekt: testowanie, dostosowanie promptów, niekiedy nowe wymagania sprzętowe. W chmurze dostawca robi to za Was, często bez przestoju po Waszej stronie.

Drugi koszt, o którym rzadko mówią handlowcy sprzedający serwery: dyżur. Ktoś musi zareagować, gdy serwer przestaje odpowiadać poza godzinami pracy. Jeśli macie własny dział IT z dyżurem, ten koszt jest już "wbudowany" w strukturę firmy. Jeśli nie macie, musicie go kupić zewnętrznie albo zaakceptować, że AI będzie niedostępna po 17:00.

Kiedy własny serwer jest jedyną opcją

Są sytuacje, w których chmura publiczna nie wchodzi w grę, niezależnie od tego, jak dobra jest oferta dostawcy.

• Dane objęte tajemnicą zawodową: dokumentacja medyczna w podmiotach leczniczych, akta klientów w kancelariach prawnych, dane objęte tajemnicą bankową. Regulacje sektorowe lub umowy z pacjentami i klientami narzucają tu miejsce przetwarzania.
• Kontrakty z zakazem przekazywania danych podmiotom trzecim. To zdarza się częściej, niż się wydaje, szczególnie w firmach obsługujących duże korporacje. Wystarczy jeden taki kontrakt w portfelu, żeby cały proces musiał zostać on premise.
• Firmy z sektora obronności lub infrastruktury krytycznej. Wymagania są narzucone przez zamawiającego lub regulatora i nie podlegają negocjacji.
• Certyfikaty branżowe z konkretnymi wymogami co do lokalizacji przetwarzania. Część certyfikatów ISO 27001 wdrożonych w określonym zakresie systemu wymaga pełnej kontroli i dokumentacji nad miejscem, gdzie dane są przetwarzane.

Warto też przy okazji sprawdzić polisy ubezpieczeniowe od cyberzdarzeń. Część warunków ochrony zawiera zapisy co do miejsca przetwarzania danych firmowych. Rzadko to decydujący czynnik, ale bywa niespodzianką podczas likwidacji szkody.

Kiedy własny serwer to przepłacenie

Większość firm MŚP nie ma danych, które uzasadniają pełne on premise. Mają dane wrażliwe, owszem, ale często można je wyraźnie oddzielić od procesów, które trafiają do AI.

Własny serwer to przepłacenie, gdy:

• Procesujecie głównie dane, których ewentualny wyciek byłby kłopotliwy, ale nie pociągałby za sobą odpowiedzialności prawnej ani utraty kontraktu
• Nie macie działu IT zdolnego do administrowania serwerem z modelem LLM, aktualizowania go i reagowania na awarie
• Skala użycia jest na tyle mała, że koszty stałe serwera nie amortyzują się w rozsądnym czasie
• Chcecie przetestować, czy AI w ogóle pomaga w danym procesie, zanim zdecydujecie się na większy projekt

Ten ostatni punkt jest ważny praktycznie. Wdrożenie w chmurze można uruchomić w dni lub kilka tygodni. On premise, łącznie z zakupem sprzętu, konfiguracją i testami, to kwestia tygodni lub miesięcy. Jeśli nie wiecie jeszcze, czy dany proces warto automatyzować, on premise to zły punkt wejścia. Lepiej zacząć w chmurze, wyciągnąć wnioski, a decyzję o własnej infrastrukturze podjąć, gdy wiadomo już, co ma realnie działać i w jakiej skali.

Hybryda: jak wygląda to w praktyce dla firmy z mieszanym portfelem danych

Większość wdrożeń, które realizujemy, nie jest ani czysto on premise, ani czysto w chmurze. To nie jest kompromis. To podejście wynikające wprost z analizy danych konkretnej firmy.

Typowy podział wygląda tak: dane wrażliwe, czyli dokumentacja kadrowa, dane pacjentów, treści objęte NDA, dane z kontraktów z klauzulą poufności, zostają na własnej infrastrukturze lub w prywatnej instancji środowiska (np. izolowana maszyna wirtualna z kontrolą dostępu). Procesy, gdzie dane są mniej wrażliwe, takie jak generowanie treści marketingowych, obsługa FAQ, analiza danych publicznych czy redakcja standardowych maili do klientów, idą do chmury publicznej przez API.

Taka architektura wymaga jednej decyzji na wejściu: klasyfikacji danych. Które dane mogą opuścić firmę? Które muszą zostać? Ta decyzja powinna być zapisana. Najlepiej jako część polityki bezpieczeństwa lub rejestru czynności przetwarzania, który i tak macie obowiązek prowadzić na mocy RODO. I powinna być zaktualizowana zanim uruchomicie jakikolwiek AI, nie po pierwszym incydencie.

Od czego zaczynamy

Nie od wyboru technologii. Od mapowania procesów i danych.

Konkretnie robimy to tak: spisujemy procesy, które firma chce objąć AI. Do każdego procesu przypisujemy kategorie danych, które w nim przepływają: czy to dane osobowe klientów, czy dane wewnętrzne operacyjne, czy dokumenty objęte umowami z klientami. Sprawdzamy, czy te dane mogą trafić do zewnętrznego dostawcy zgodnie z umowami, RODO i regulacjami sektorowymi dla danej branży. Dopiero po tej analizie ma sens rozmowa o chmurze, on premise albo hybrydzie, i o tym, który dostawca spełnia warunki dla danej kategorii danych.

Jeśli chcecie to zrobić systematycznie, zaczynamy od bezpłatnego audytu. Sprawdzamy, które procesy nadają się do AI, gdzie leżą realne ograniczenia danych i jaką architekturę wdrożenia to implikuje. Jak wyglądają takie projekty u innych firm, możecie zobaczyć w realnych wdrożeniach.