Czas czytania: 6 min
Single-tenant w praktyce znaczy jedno: dedykowana, odizolowana instancja, która obsługuje wyłącznie Wasz workload. Nie współdzielicie z nikim mocy obliczeniowej, pamięci ani modelu, a dane nie opuszczają Waszego perymetru. Różnica wobec shared cloud nie jest deklaracją w umowie, tylko konkretną granicą, którą da się pokazać audytorowi. Poniżej rozkładamy tę granicę na części: co dokładnie jest odizolowane, jak płyną dane i gdzie się zatrzymują, kto kontroluje cykl aktualizacji i co widzi audytor. Pokazujemy też, gdzie naiwna konfiguracja single-tenant się wykłada, mimo że na papierze wygląda na dedykowaną. To, który model wybrać dla swoich danych, rozłożyliśmy osobno w tekście o single-tenant a shared cloud. Tu chodzi o to, jak dedykowana instancja wygląda, gdy już działa.
Co dokładnie jest odizolowane
„Dedykowana instancja" to nie jedna rzecz, tylko zestaw granic. Warto rozbić je osobno, bo model bywa nazywany single-tenant, gdy odizolowana jest tylko część z nich.
- Moc obliczeniowa. Wasz workload dostaje przydzielone zasoby, a nie miejsce we wspólnej puli, w której obciążenie innego klienta wpływa na Wasze wyniki.
- Model i jego wagi. Instancja modelu działa tylko dla Was. Nie dzielicie jednego endpointu z innymi organizacjami, więc Wasze zapytania i konteksty nie trafiają do wspólnej kolejki.
- Magazyn danych i indeks. Dokumenty, embeddingi i baza wektorowa żyją w Waszym środowisku, nie w współdzielonym magazynie z logicznym oddzieleniem.
- Sieć. Środowisko ma własny segment, a ruch wychodzący jest kontrolowany, nie domyślnie otwarty na publiczne API.
Dopiero gdy wszystkie cztery granice są zamknięte, „single-tenant" znaczy to, co obiecuje. Jeśli któraś jest otwarta, izolacja jest częściowa, choć nazwa sugeruje pełną.
Jak płyną dane i gdzie się zatrzymują
W dedykowanej instancji droga danych jest krótka i zamknięta. Dokumenty źródłowe, rysunki, BOM-y, zgłoszenia, trafiają do indeksu wewnątrz Waszego środowiska. Wyszukiwanie kontekstu i wnioskowanie modelu dzieją się w tej samej instancji, a odpowiedź wraca do Was. Kluczowe jest to, czego na tej drodze nie ma: nie ma wywołania publicznego API na zewnątrz, nie ma wysyłki treści dokumentów do współdzielonego modelu, nie ma logów lądujących poza perymetrem. Embeddingi liczone są na miejscu, a nie odsyłane do usługi zewnętrznej. To właśnie ta zamknięta pętla, a nie sama etykieta „prywatne", decyduje o tym, że dane produkcyjne nie wyciekają bokiem.
Cykl aktualizacji, który kontrolujecie
W shared cloud zmiana po stronie dostawcy dotyka wszystkich naraz: nowa wersja modelu czy zmiana zachowania wchodzi wtedy, gdy zdecyduje dostawca. W single-tenant to Wy decydujecie, kiedy i co się zmienia w środowisku. Nową wersję można najpierw sprawdzić na Waszych danych, porównać wyniki i dopiero potem wdrożyć, a wersję zamrozić na czas, gdy stabilność jest ważniejsza niż nowość. Dla procesu, który wpięliście w codzienną pracę, ta przewidywalność bywa ważniejsza niż dostęp do najnowszego modelu z dnia na dzień.
Jak to wygląda punkt po punkcie
Najprościej zestawić oba modele po wymiarach, które realnie definiują granicę izolacji.
| Wymiar | Shared cloud | Single-tenant |
|---|---|---|
| Moc obliczeniowa | Współdzielona pula | Dedykowana, tylko Wasza |
| Model i wagi | Wspólny endpoint | Osobna instancja |
| Dane i indeks | Logiczne oddzielenie | Własne środowisko |
| Ruch wychodzący | Często do publicznego API | Kontrolowany, w perymetrze |
| Cykl aktualizacji | Po stronie dostawcy | Po Waszej stronie |
| Odpowiedź audytorowi | Trzeba tłumaczyć separację | Jedno zdanie |
Co widzi audytor
Pod NIS2 audytor pyta o dwie rzeczy: gdzie dokładnie przetwarzane są dane i kto ma do nich dostęp. Przy współdzielonej instancji odpowiedź wymaga wytłumaczenia mechanizmu logicznej separacji i przekonania audytora, że jest szczelny. Przy dedykowanej instancji odpowiedź „osobne środowisko, tylko nasze, z udokumentowaną izolacją" broni się jednym zdaniem. To nie jest różnica kosmetyczna: łatwość obrony granicy danych przekłada się wprost na czas i ryzyko przy audycie. Szerzej piszemy o tym w tekście o publicznej AI a audycie NIS2.
Gdzie naiwna konfiguracja się wykłada
Środowisko bywa sprzedawane jako single-tenant, a mimo to przecieka. Warto o to dopytać, zanim uznacie granicę za zamkniętą.
- Odizolowana aplikacja, ale wnioskowanie w publicznym API. Sama instancja jest Wasza, lecz embeddingi albo generowanie odpowiedzi nadal wychodzą do zewnętrznej usługi. Dane opuszczają perymetr, choć panel wygląda na prywatny.
- Wspólny endpoint modelu w tle. „Dedykowane" bywa tylko na warstwie aplikacji, podczas gdy model obsługuje wielu klientów z jednej kolejki.
- Logi i telemetria poza perymetrem. Treść zapytań i fragmenty dokumentów trafiają do zewnętrznego systemu logowania dostawcy.
- Kopie zapasowe we współdzielonym magazynie. Środowisko jest dedykowane, ale backup ląduje tam, gdzie backupy innych.
- Niejasne, kto trzyma klucze. Jeśli klucze szyfrujące są po stronie dostawcy, izolacja środowiska nie kończy rozmowy o dostępie.
To pytania kontrolne, nie oskarżenia. Dobrze zaprojektowany single-tenant przechodzi je bez naciągania, a odpowiedzi da się pokazać, nie tylko zadeklarować.
Czego ten model nie załatwia
Single-tenant rozwiązuje pytanie o granicę środowiska, ale nie zastępuje kilku innych rzeczy. Nie jest tym samym co on-prem: to nadal dedykowana instancja u dostawcy infrastruktury, a nie sprzęt w Waszej serwerowni. Kiedy warto posiadać własne żelazo, a kiedy nie, rozkładamy w tekście o on-prem AI w produkcji. Izolacja środowiska nie zastępuje też kontroli dostępu wewnątrz firmy: to, że dane nie wychodzą na zewnątrz, nie znaczy, że wewnątrz widzi je każdy. Dedykowane środowisko nie jest automatycznie tańsze, a próg wejścia bywa wyższy niż w shared. I wreszcie single-tenant to gwarancja granicy, nie gwarancja jakości modelu. Dobry wynik nadal zależy od tego, na jakich dokumentach pracuje.
Kolejny krok
Jeśli Wasze dane produkcyjne nie mogą dzielić środowiska z nikim innym, warto sprawdzić, jak dedykowana instancja wyglądałaby dla jednego konkretnego zadania. Na krótkiej rozmowie przejdziemy przez granice izolacji dla Waszego przypadku, punkt po punkcie. Umówcie rozmowę z Fryderykiem, 30 minut, bez pitchu.
Autor: Fryderyk Pryjma, CortexMine. Pracujemy z producentami nad prywatnymi wdrożeniami Cyfrowych Pracowników na ich własnej infrastrukturze.
Wolicie najpierw sprawdzić to sami? Mini-audyt gotowości zajmuje 10 minut i nie wymaga zostawiania danych.