Usługa
Bezpieczne wdrożenia lokalne AI — on-premise i air-gapped
Aktualizacja: · Sprint0
W skrócie
Uruchamiamy systemy AI w infrastrukturze klienta: model językowy open-source na własnym serwerze z GPU, aplikacja z logowaniem przez SSO i uprawnieniami rolami, monitoring i ślad audytowy — także w środowiskach air-gapped, bez połączenia z internetem. To droga dla danych, które nie mogą opuścić sieci firmy: tajemnica przedsiębiorstwa, dane regulowane, sektory objęte NIS2. Gdy takiego wymogu nie ma, mówimy to wprost i proponujemy model komercyjny na umowie powierzenia, bo jest tańszy w utrzymaniu. W obu drogach obowiązują te same cztery reguły: minimum danych do modelu, umowa powierzenia, kontrola dostępu rolami, ślad audytowy. Pierwszy krok to audyt gotowości — orientacyjnie 1–2 tygodnie.
Dla kogo
Dla firm, w których pytanie „gdzie fizycznie są nasze dane" ma odpowiedź w umowie, regulaminie albo ustawie. Typowe sytuacje: dokumentacja techniczna i konstrukcyjna, która jest przewagą firmy; dane objęte tajemnicą zawodową lub bankową (bankowość i finanse); operatorzy infrastruktury i firmy z sektorów objętych NIS2 (energetyka i OZE); środowiska odcięte od internetu z zasady. Potrzebny jest ktoś po stronie klienta, kto odpowiada za serwerownię albo za dostawcę, który ją utrzymuje.
Kiedy lokalne AI ma sens — a kiedy nie
Ma sens, gdy spełniony jest co najmniej jeden z warunków: dane nie mogą trafić do zewnętrznego dostawcy (regulacja, umowa z klientem, tajemnica), wolumen zapytań jest na tyle duży, że własny serwer wychodzi taniej niż opłaty za API, albo sieć jest odcięta od internetu i tak ma zostać. Pełne rozumowanie opisujemy w przewodniku Wdrożenie AI on-premise.
Nie ma sensu, gdy wolumen jest mały, dane nie są regulowane ani tajne, a w firmie nie ma nikogo do utrzymania serwera. Własny GPU, który przez większość dnia stoi bezczynnie, i model, którego nikt nie aktualizuje, to gorsze bezpieczeństwo niż komercyjne API na umowie powierzenia z minimum danych. W takim przypadku raport z audytu rekomenduje model komercyjny — i to jest pełnoprawny wynik, nie porażka.
Co budujemy
Serwer z GPU w Waszej serwerowni
Dobrany do zmierzonego obciążenia, nie do katalogu. Jedna karta dla działu, kilka dla firmy — z zapasem na kolejny model, bez zapasu „na wszelki wypadek”.
Model open-source uruchomiony lokalnie
Wybrany po teście na Waszych pytaniach kontrolnych. Kwantyzacja i serwowanie tak, żeby odpowiedź wracała w czasie, który ludzie zaakceptują.
Więcej →Aplikacja: RAG, ekstrakcja, agenty
Ta sama warstwa, którą budujemy na modelach komercyjnych — asystent na dokumentach, odczyt umów, automatyzacje — tyle że model stoi obok, w tej samej sieci.
Więcej →SSO, role i architektura zero-trust
Logowanie z Waszego katalogu, uprawnienia sprawdzane przy każdym zapytaniu, żaden komponent nie ufa innemu „bo jest w środku”. Segmentacja sieci razem z partnerem 0trust.
Monitoring i ślad audytowy
Obciążenie GPU, czasy odpowiedzi, błędy — oraz dziennik: kto, kiedy, o co zapytał i co system odpowiedział. Do Waszego SIEM-a, jeśli go macie.
Jak to działa
Trzy elementy stoją w sieci firmy: dane i dokumenty tam, gdzie były; aplikacja, która sprawdza uprawnienia i zapisuje ślad audytowy; model językowy na własnym serwerze z GPU. Pracownicy łączą się od wewnątrz — VPN, SSO, role z Waszego katalogu. Internet jest poza granicą. W wariancie air-gapped połączenia nie ma wcale, a aktualizacje modelu i oprogramowania wchodzą kontrolowanym kanałem: nośnik albo okno serwisowe, z podpisem i listą zmian.
Zero-trust oznacza tu coś konkretnego: żaden komponent nie ufa drugiemu dlatego, że jest „w środku”. Aplikacja uwierzytelnia się do modelu, model nie ma dostępu do dokumentów poza tym, co aplikacja mu poda, a segmenty sieci są rozdzielone. Projekt sieci i testy przygotowujemy z partnerem technologicznym 0trust.
Co dostajesz
- Działający system w Waszej infrastrukturze — serwer, model, aplikacja, SSO i monitoring uruchomione i przekazane razem z procedurą aktualizacji (także dla air-gapped).
- Architekturę na piśmie — gdzie stoi każdy komponent, kto ma do czego dostęp, jak wygląda kanał aktualizacji i ślad audytowy. Ten dokument idzie do Waszego IOD, działu bezpieczeństwa i audytora.
- Mapę zgodności — które wymagania RODO, NIS2 i AI Act dotyczą tego systemu i jak są spełnione; z listą tego, co zostaje po Waszej stronie (np. rejestr czynności, szkolenie personelu).
- Pomiar zamiast wrażeń — zestaw pytań kontrolnych ze znanymi odpowiedziami, uruchamiany po każdej zmianie modelu; wiadomo, czy nowa wersja jest lepsza, zanim trafi do ludzi.
- Kod jako własność klienta — bez licencji na naszą platformę, bez opłat za odejście; modele open-source na ich własnych licencjach.
- Utrzymanie — monitoring, aktualizacje modelu i zależności, okna serwisowe; albo przekazanie tego Waszemu zespołowi z instrukcją.
Jak pracujemy z danymi
Dwie drogi, jeden reżim. Na tej stronie mówimy o drodze lokalnej: model stoi w Waszej sieci, więc do zewnętrznego dostawcy nie trafia nic. Ale reguły są te same co na modelu komercyjnym, bo zagrożenia wewnątrz firmy nie znikają: do modelu trafia minimum danych potrzebne do jednego zadania, uprawnienia są sprawdzane rolami na etapie wyszukiwania, a każde zapytanie i odpowiedź zostawiają ślad audytowy. Jeśli część zadań (np. tłumaczenia materiałów publicznych) może iść do modelu komercyjnego, zapisujemy to w architekturze razem z umową powierzenia — i tylko dla tej klasy danych.
Regulacje traktujemy jako wymagania projektowe, nie jako załącznik. RODO: podstawa prawna i DPIA tam, gdzie przetwarzanie jest na dużą skalę lub dotyczy danych wrażliwych. NIS2: dostawca AI jest elementem łańcucha dostaw ICT, a model lokalny skraca ten łańcuch (AI zgodne z NIS2). AI Act: obowiązki podmiotu stosującego nie zależą od tego, gdzie stoi model — lokalne wdrożenie nie zwalnia z nadzoru człowieka ani z kompetencji personelu (AI Act dla firm). System i procedury projektujemy zgodnie z zasadami ISO 27001. To nie jest porada prawna. Przed startem warto przejść checklistę wdrożenia AI.
Pakiet startowy
Audyt gotowości AI
Dla firm, które chcą wiedzieć, gdzie AI zwróci się najszybciej i co stoi na przeszkodzie — zanim cokolwiek kupią.
orientacyjnie 1–2 tygodnie
- Przegląd procesów i miejsc, gdzie ludzie przepisują, szukają i odpowiadają na to samo
- Inwentaryzacja danych: co, gdzie leży, kto ma dostęp, co może opuścić sieć
- Ocena regulacyjna: RODO, NIS2, AI Act — co dotyczy Twojej firmy
- Lista 3–5 zastosowań uszeregowana według zwrotu i ryzyka
Efekt: Raport z rekomendacją: od czego zacząć, na jakim modelu (lokalny czy komercyjny) i z jakim reżimem danych.
Dlaczego audyt, a nie od razu serwer
Sprzęt kupuje się raz, a obciążenie, klasę danych i wymagania regulacyjne trzeba zmierzyć wcześniej. Audyt odpowiada na trzy pytania: które dane naprawdę nie mogą opuścić sieci, ile zapytań system obsłuży w szczycie i kto go utrzyma po oddaniu.
Wynik to raport z rekomendacją modelu (lokalny albo komercyjny) i reżimu danych. Jeśli rekomendacja brzmi „komercyjny na umowie powierzenia”, oszczędzacie serwer. Jeśli „lokalny” — wiecie, jaki i dlaczego.
Przewodniki na ten temat
Porównanie
AI on-premise vs chmura — z czego naprawdę składa się koszt
Serwer GPU i prąd, ludzie, aktualizacje modeli, tokeny, egress, zgodność, koszt incydentu. Co rośnie z wolumenem, co jest stałe i reguła kciuka bez kwot.
Przewodnik
Wdrożenie AI on-premise — przewodnik dla firm
Kiedy lokalne AI ma sens, z czego składa się infrastruktura, chmura vs on-premise, RODO/NIS2 i czynniki kosztu.
Compliance
AI zgodne z NIS2 — co dyrektywa oznacza dla firm
Kogo obejmuje NIS2, jakie nakłada obowiązki i dlaczego każdy dostawca AI to element łańcucha dostaw ICT.
Technologia
Lokalne LLM dla firm — jak działają i co potrafią
Jak duży model językowy działa we własnej serwerowni, do czego nadaje się od razu i jak zaplanować pilotaż.
Compliance
AI Act dla firm — obowiązki, terminy, kary
Kalendarz stosowania, poziomy ryzyka, rola deployer vs provider, AI w HR i obowiązek AI literacy.
Najczęstsze pytania
Czy lokalny model językowy jest gorszy od komercyjnego?
W zadaniach ogólnych czołowe modele komercyjne zwykle wypadają lepiej. W zadaniach firmowych — odpowiedzi z Waszych dokumentów, ekstrakcja pól z umów, klasyfikacja zgłoszeń — różnica jest mała, bo model dostaje gotowy materiał i ma go streścić, a nie wymyślać. Mierzymy to na Waszych pytaniach kontrolnych przed decyzją o sprzęcie, nie po.
Jaki serwer jest potrzebny do lokalnego AI?
Zależy od liczby użytkowników i rozmiaru modelu. Asystent dla jednego działu na modelu średniej wielkości mieści się na jednym serwerze z kartą GPU; kilkaset osób pytających jednocześnie to już kilka kart albo kolejka zadań. Dobór sprzętu jest częścią audytu — kupowanie GPU przed pomiarem obciążenia to najczęstszy sposób na przepłacenie.
Jak aktualizuje się system w środowisku air-gapped?
Kontrolowanym kanałem: nowa wersja modelu i oprogramowania jest przygotowana i sprawdzona poza siecią, a do środka wchodzi na nośniku albo w oknie serwisowym, z podpisem i listą zmian. Stałego łącza do internetu nie ma. To wolniejsze niż aktualizacja z chmury, ale przewidywalne — wiadomo, kiedy i co się zmieniło.
Kiedy wdrożenie lokalne nie ma sensu?
Gdy wolumen jest mały, dane nie są objęte tajemnicą ani regulacją, a w firmie nie ma nikogo, kto utrzyma serwer. Wtedy model komercyjny czołowego dostawcy na umowie powierzenia, z minimum danych i śladem audytowym, jest tańszy i równie bezpieczny dla tej klasy danych. Powiemy to wprost w raporcie z audytu, nawet jeśli oznacza to mniejszy projekt.