Suwerenne AI w platformie: open-weight, lokalne GPU i ochrona IP

W Suwerennym IDP ustaliłem, że suwerenność to przenośność workflowów, a każdy komponent platformy podlega tej samej ocenie co infrastruktura. Jest jednak jeden, który łamie tę ocenę w nowy sposób — asystent AI. I to on spędza mi sen z powiek najbardziej. Tradycyjny Copilot nieustannie wysyła fragmenty kodu i kontekst na serwery dostawcy, do przetwarzania i potencjalnego treningu. To nie jest „przetwarzanie danych” w starym sensie — to ciągły, trudny do zauważenia wyciek własności intelektualnej poza granicę suwerenności.

Dlaczego to nowy rodzaj ryzyka

Klasyczne kontrole suwerenności pilnują, gdzie spoczywają dane. Asystent AI obchodzi je, bo dane w ruchu — prompt, otaczający kod, definicje infry, komunikaty błędów — opuszczają organizację przy każdym zapytaniu. Co gorsza, mogą zostać wchłonięte przez obce, scentralizowane pipeline’y treningowe, nad którymi nie masz żadnej kontroli ani widoczności.

Do tego dochodzi ryzyko ciągłości. Zdolność hostowana w jednej jurysdykcji może zostać odcięta z dnia na dzień decyzją administracyjną — bez uprzedzenia i bez prawa odwołania. Dla zespołu, który wpiął obcy model w krytyczną ścieżkę wytwarzania, to nie teoretyczne ryzyko, lecz nagłe zatrzymanie pracy.

Optyka: suwerenność to optionality

Suwerenne AI nie znaczy „zakaz używania zewnętrznych modeli”. Znaczy optionality — zdolność do uruchomienia całego cyklu wytwarzania na własnych warunkach, gdy zajdzie potrzeba. W praktyce sprowadza się to do trzech decyzji architektonicznych:

• Modele open-weight — o otwartych wagach, które możesz pobrać, uruchomić i audytować, zamiast czarnej skrzynki za API.
• Hosting lokalny lub suwerenny — na własnym GPU albo u dostawcy w Twojej jurysdykcji, tak by zapytania nie opuszczały granicy.
• Routing zapytań AI przez platformę — wszystkie zapytania asystentów idą przez kontrolowany punkt, nie bezpośrednio do obcego SaaS.

Dzięki temu kod, telemetria i definicje infry pozostają pod kontrolą organizacji i nie są ingerowane przez zewnętrzne modele.

Jak to wygląda na platformie

Wzorzec to brama (gateway) wystawiająca zgodne z OpenAI API, za którą stoi lokalnie hostowany model — np. uruchomiony na Kubernetes (lub lekkim k3s na brzegu z GPU). Asystenci w IDE i agenci w pipeline kierują ruch do tej bramy, nie na zewnątrz.

# wdrożenie lokalnej bramy modelu z dostępem do GPU (szkic)
apiVersion: apps/v1
kind: Deployment
metadata: { name: llm-gateway, namespace: ai }
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: gateway
          image: registry.eiac.dev/ai/openai-compatible-gateway:1.0.0
          resources:
            limits: { nvidia.com/gpu: "1" }
          env:
            - name: MODEL
              value: "open-weight-coder"

Sekrety dostępowe do bramy i providerów trzymasz w Vault/OpenBao (nie w repo), a do oceny jakości i bezpieczeństwa modeli oraz promptów używasz deklaratywnych ewaluacji i red-teamingu — np. promptfoo jako krok w CI. Provenance artefaktów generowanych z udziałem AI warto podpisywać (np. gitsign), by dało się udowodnić ich pochodzenie.

# ewaluacja i red-teaming modelu jako bramka jakości (promptfoo)
prompts: ["{{zadanie}}"]
providers: ["http://llm-gateway.ai.svc/v1"]
redteam:
  plugins: [prompt-injection, pii-leak]

Kompromisy: czego to kosztuje

Suwerenne AI nie jest darmowe. Open-weight modele bywają o krok za najlepszymi zamkniętymi frontier-models, lokalny hosting wymaga GPU i utrzymania, a brama to dodatkowy komponent do obsłużenia. To realny koszt — który zestawiasz z ryzykiem wycieku IP i utraty ciągłości. Dla wielu zespołów rozsądny jest model mieszany: wrażliwe ścieżki przez model lokalny, mniej wrażliwe — przez zewnętrzny, ale zawsze za kontrolowaną bramą, którą da się przełączyć.

Styk z regulacją

Suwerenne AI spotyka się z AI Act w dwóch punktach: transparentności (lineage modelu — co i na czym działa) oraz nadzoru i śladu (logowanie zapytań/wyników w granicy organizacji). Lokalna brama daje naturalny punkt, w którym ten ślad powstaje i pozostaje pod kontrolą. Mapowanie wymogów AI Act na cykl wytwarzania rozwijamy w AI Act a agentowy SDLC.

Podsumowanie

AI jest dziś częścią platformy — więc podlega tej samej ocenie suwerenności co reszta. Bez opcji modelu open-weight na własnej infrastrukturze data residency jest iluzją: najcenniejsze aktywa wyciekają przez asystenta. Suwerenne AI to nie ideologia, lecz zarządzanie ryzykiem IP i ciągłości — z trzeźwym uznaniem jego kosztów. To zarazem warstwa, w której rodzi się ślad wymagany przez AI Act, do którego przechodzę dalej. I tak, wiem — lokalny model kosztuje: sprzęt, ludzi, utrzymanie. Ale policz kiedyś, ile warta jest Twoja własność intelektualna, zanim uznasz, że to za drogo.