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

> Bez modelu open-weight na własnej infrastrukturze data residency jest iluzją — najcenniejsze aktywa wyciekają przez asystenta. Suwerenne AI jako zarządzanie ryzykiem IP i ciągłości, z trzeźwym uznaniem kosztów.

URL: https://eiac.dev/blog/suwerenne-ai-open-weight
Filar: Security-as-Code
Data: 2026-04-17
Tagi: sovereignty, ai, llm, ip, security

---

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) 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.

<div class="callout">
<strong>Teza</strong>
<p>Jeśli Twój asystent AI przetwarza kod na cudzych serwerach, „data residency" reszty platformy nic nie znaczy. Algorytmy, logika biznesowa i definicje infrastruktury wyciekają tą samą drogą, którą miały chronić wszystkie inne kontrole.</p>
</div>

## 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](/katalog/kubernetes) (lub lekkim [k3s](/katalog/k3s) na brzegu z GPU). Asystenci w IDE i agenci w pipeline kierują ruch do tej bramy, nie na zewnątrz.

```yaml
# 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](/katalog/vault)/[OpenBao](/katalog/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](/katalog/promptfoo) jako krok w CI. Provenance artefaktów generowanych z udziałem AI warto podpisywać (np. [gitsign](/katalog/gitsign)), by dało się udowodnić ich pochodzenie.

```yaml
# 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](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)** 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](/blog/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.