Przejdź do głównej zawartości
AI Developer Toolkit

Prywatność danych i polityki firmowe dla agentów kodujących

Polityka danych dla agentów kodujących dzieli dane na cztery klasy (publiczne, wewnętrzne, poufne, zastrzeżone) i zatwierdza każdą konkretną usługę, plan i trasę dla określonych klas. Mechanizmy narzędzi trzymają dane zastrzeżone poza kontekstem agenta, dane syntetyczne zastępują kopie produkcji, a testy na fiksturach dowodzą, że każda blokada nadal działa.

Ta strona jest dla CTO, który podpisuje politykę danych, i dla tech leada, który wprowadza ją w każdym repozytorium. Sytuacja jest znajoma: deweloper wkleja do agenta e-maile klientów, żeby zdebugować wolną stronę, ktoś inny wkleja pełny DATABASE_URL, trzecia osoba loguje się prywatnym kontem, więc nie obejmują jej firmowe warunki retencji. Potem dział prawny pyta, czy w ogóle wolno ci używać narzędzi AI.

Wolno, jeśli polityka zatwierdza usługę, której naprawdę używasz, narzędzia egzekwują twarde granice, a test świeci na czerwono w dniu, w którym któraś kontrola przestaje działać.

Co daje ci ta polityka danych

Dział zatytułowany „Co daje ci ta polityka danych”
  • Tabelę czterech klas danych i rejestr usług, które inżynierowie stosują bez pytania prawników.
  • Kontrole dla Claude Code, Codex i Cursora, każdą z testem na fiksturach, który świeci na czerwono, gdy kontrola przestaje blokować.

Jakie dane mogą trafić do agenta kodującego?

Dział zatytułowany „Jakie dane mogą trafić do agenta kodującego?”

Klasyfikujesz raz; każda kolejna decyzja wynika z klasy.

KlasaPrzykładyCzy może trafić do agenta?Egzekwowane przez
PubliczneKod open source, publiczna dokumentacja, opublikowane specyfikacje APITak, każdą zatwierdzoną trasąNic dodatkowego
WewnętrzneFirmowa logika biznesowa, narzędzia wewnętrzne, dokumenty architekturyTak, zatwierdzoną trasą na warunkach komercyjnychLogowanie ograniczone do firmowej organizacji lub workspace’u
PoufneNiewydane funkcje, logika cenowa, projekt zabezpieczeń, tajemnice handloweTylko trasami, których warunki wykluczają trenowanie na twoich danych i których retencję zatwierdziłeśRejestr usług, ustawienia zarządzane, zgoda dla każdego repozytorium
ZastrzeżonePoświadczenia, dane osobowe klientów, dane płatnicze i medyczne, wyniki zapytań z produkcjiNigdy: ani w promptach, ani w plikach dostępnych dla agenta, logach czy fiksturach testowychReguły deny, pliki ignore, hook skanujący prompty, dane syntetyczne, role bazodanowe tylko do odczytu

Szablon polityki użycia AI wykorzystuje te cztery klasy w klauzulach o danych, więc zacznij od tej tabeli.

Zatwierdzaj konkretną usługę, nie dostawcę

Dział zatytułowany „Zatwierdzaj konkretną usługę, nie dostawcę”

„Mamy DPA z dostawcą” nic nie mówi o planie, na który zalogował się inżynier, o trasie modelu, której używa narzędzie, ani o serwerze MCP, który właśnie dostał stack trace. Plany konsumenckie i komercyjne mają różne warunki, a opcjonalne funkcje dokładają podmioty przetwarzające albo retencję.

Dlatego jednostką zatwierdzenia jest wpis usługi: jedno narzędzie, jeden plan, jedna trasa, jedna konfiguracja. Prowadź osobny wpis dla każdej konfiguracji Claude Code, Codex czy Cursora, trasy z kluczem API, bramki modeli, agenta chmurowego i serwera MCP. Ten rejestr możesz przyjąć bez zmian:

# ai-service-register.yaml: one entry per approved service configuration
- id: claude-code-enterprise-cli
  product: Claude Code (CLI and VS Code extension)
  legal_entity: Anthropic
  plan: Claude for Enterprise
  route: Anthropic API, direct                # or Bedrock, Google Cloud, a gateway
  region: ""                                  # fill in from the contract
  roles: { us: controller, vendor: processor }
  terms: [commercial-terms, dpa]              # links to the signed documents
  training_on_our_data: "no (commercial terms)"
  retention: "30 days standard; ZDR requested (not yet enabled)"
  data_classes_allowed: [public, internal, confidential]
  data_classes_prohibited: [restricted]
  purpose: "software development in approved repositories"
  subprocessors_and_integrations: [github-mcp, postgres-mcp-staging]
  identity: "SSO; login forced to our organization"
  offboarding: "SCIM deprovisioning"
  incident_contact: security@example.com
  owner: platform-team
  approved: 2026-09-26
  next_review: 2026-12-26
  change_triggers: [plan change, new model route, new MCP server, vendor terms update, new region]

Zasada, dzięki której rejestr działa: nieznana usługa, trasa, region lub warunek oznacza stop i przegląd. Nowy serwer MCP czy nowa trasa to zmiana w rejestrze, którą zatwierdza zespół platformowy lub bezpieczeństwo. Kwestionariusz dla dostawcy dostarcza dowodów do każdego pola, a strona o tym, gdzie działa model rozstrzyga trasę i region.

Co przechowuje każdy dostawca i jak długo?

Dział zatytułowany „Co przechowuje każdy dostawca i jak długo?”

Retencja i użycie danych do trenowania różnią się między dostawcami, planami i funkcjami. Zapisz odpowiedź dla każdej usługi i sprawdzaj ją przy każdym przeglądzie.

Strona Anthropic o użyciu danych w Claude Code (przeczytana 2026-09-26) mówi:

  • Trenowanie. Na warunkach komercyjnych (Team, Enterprise, API i platformy zewnętrzne) Anthropic nie trenuje modeli generatywnych na kodzie ani promptach wysłanych do Claude Code, chyba że klient sam się na to zgodzi, na przykład w Development Partner Program. Free, Pro i Max to plany konsumenckie: ich użytkownicy sami decydują, czy ich dane trenują przyszłe modele.
  • Retencja. Konta komercyjne: domyślnie 30 dni. Konta konsumenckie: 30 dni albo 5 lat, jeśli użytkownik zgodził się na trenowanie.
  • Zerowa retencja danych (ZDR). Dostępna dla kwalifikujących się organizacji Claude for Enterprise, włączana osobno dla każdej organizacji przez opiekuna konta (account team) w Anthropic. Nie wchodzi w standardowy plan Enterprise i nie ma przełącznika w panelu admina. Szczegóły i dostępność modeli są na stronie gdzie działa model.
  • Czego ZDR nigdy nie obejmuje (strona ZDR, 2026-09-26): czatu w claude.ai, Cowork, metadanych analityki, zarządzania miejscami oraz „data processed by third-party tools, MCP servers, or other external integrations”. Treści oznaczone jako naruszenie zasad użycia mogą być przechowywane do 2 lat.
  • Co zostaje na laptopie. Claude Code przechowuje transkrypty sesji otwartym tekstem w ~/.claude/projects/ domyślnie przez 30 dni; okres zmienia cleanupPeriodDays.
  • Co wychodzi przez zgłoszenia. /feedback, /bug i /share wysyłają rozmowę razem z kodem do Anthropic, gdzie jest przechowywana 5 lat; wyłącza je DISABLE_FEEDBACK_COMMAND=1. Druga ścieżka to ankieta jakości sesji: odpowiedź „Yes” na jej pytanie uzupełniające wysyła transkrypty i surowy log sesji, łącznie z kodem źródłowym, przechowywane do 6 miesięcy. Zatrzymuje to CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 (albo CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, DISABLE_TELEMETRY lub DO_NOT_TRACK); organizacje z ZDR w ogóle nie widzą tego pytania, a na Bedrock, Google Cloud i Foundry odpowiedź „Yes” zapisuje lokalne archiwum w ~/.claude/feedback-bundles/ zamiast je wysyłać.

ZDR i warunki komercyjne dotyczą tylko sesji uwierzytelnionych w twojej organizacji. Wymuś to ustawieniami zarządzanymi forceLoginMethod i forceLoginOrgUUID.

Trzymaj dane zastrzeżone poza kontekstem agenta

Dział zatytułowany „Trzymaj dane zastrzeżone poza kontekstem agenta”

Spisana polityka podpowiada, mechanizm narzędzia egzekwuje. Idź w tej kolejności, bo każdy krok zamyka drogę, którą poprzedni zostawia otwartą.

  1. Trzymaj sekrety poza przestrzenią roboczą. Ładuj poświadczenia w czasie działania z menedżera sekretów i commituj .env.example z wartościami zastępczymi. Pliku .env, którego nie ma, nie da się przeczytać.

  2. Zablokuj narzędzia plikowe agenta na ścieżkach z sekretami. Użyj konfiguracji dla swojego narzędzia poniżej. Reguły deny obejmują pliki, które otwiera agent; nie obejmują tego, co wkleja człowiek.

  3. Skanuj każdy prompt, zanim opuści maszynę. Hook na promptach blokuje wklejone poświadczenia i dane osobowe. Widzi tylko to, co wpisał człowiek, dlatego krok 2 wciąż jest potrzebny.

  4. Egzekwuj na poziomie systemu operacyjnego wszystko, co musi być szczelne. Skrypt napisany przez agenta może otworzyć plik bez podawania jego nazwy. Tę drogę zamyka sandbox; zobacz uprawnienia i sandboxing.

  5. Skanuj commity. Uruchamiaj skaner sekretów, na przykład gitleaks, w hooku pre-commit i w CI. Wpis pre-commit z README gitleaks (sprawdzone 2026-09-30); w CI uruchom gitleaks git -v na pobranym repozytorium:

    .pre-commit-config.yaml
    repos:
      - repo: https://github.com/gitleaks/gitleaks
        rev: v8.24.2
        hooks:
          - id: gitleaks

Umieść reguły deny w .claude/settings.json albo w ustawieniach zarządzanych dla całej firmy:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(config/production.*)"
    ]
  }
}

Reguły deny dla Read działają na narzędzia plikowe Claude’a i na polecenia powłoki, które Claude Code rozpoznaje, takie jak cat, head i tail. Nie zatrzymają skryptu w Pythonie czy Node, który sam otwiera plik, ani grep -r, który czyta pliki bez podawania ich nazw (dokumentacja uprawnień Claude Code); to robi sandbox.

Dodaj hook UserPromptSubmit, który skanuje to, co wpisuje deweloper. UserPromptSubmit nie przyjmuje matchera. Żeby zablokować, hook musi zakończyć się kodem 2: przy tym zdarzeniu kod 1 to błąd nieblokujący i prompt przechodzi dalej (dokumentacja hooków Claude Code, przeczytana 2026-09-26).

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          { "type": "command", "command": "node scripts/privacy-check.js" }
        ]
      }
    ]
  }
}

Hook czyta JSON zdarzenia ze standardowego wejścia i skanuje pole prompt. Hook, który przekroczy limit czasu (domyślnie 30 sekund) albo nie może wystartować, na przykład przez literówkę w ścieżce skryptu, przepuszcza prompt, więc musi być szybki i testowany przez prawdziwy plik ustawień.

Skaner jest wspólny dla wszystkich narzędzi. Poproś agenta, żeby go napisał, a potem przetestuj go fiksturami z sekcji o weryfikacji:

Zastąp dane produkcyjne danymi syntetycznymi

Dział zatytułowany „Zastąp dane produkcyjne danymi syntetycznymi”

Gdy deweloper potrzebuje danych podobnych do produkcyjnych, żeby odtworzyć błąd, odpowiedzią są dane syntetyczne zgodne ze schematem i przypadkiem brzegowym, a nie zanonimizowany eksport. Daj agentowi kształt tabeli, nigdy jej wiersze.

Dane syntetyczne pomagają tylko wtedy, gdy środowisko agenta nie zawiera niczego innego. Środowiska deweloperskie dostają dane syntetyczne z ustalonym ziarnem albo zanonimizowaną migawkę z przejrzanego zadania, nigdy kopię produkcji. Agenty łączą się tylko ze środowiskiem deweloperskim i stagingiem, a agenty w CI działają na kontach serwisowych o minimalnych uprawnieniach; zobacz tożsamość i sekrety agentów.

Daj bazodanowym serwerom MCP dostęp tylko do odczytu

Dział zatytułowany „Daj bazodanowym serwerom MCP dostęp tylko do odczytu”

ZDR nie obejmuje tego, co przetwarza serwer MCP. Zanim serwer trafi do rejestru, sprawdź go według listy kontrolnej bezpieczeństwa MCP, a potem podłącz go rolą, która nie może pisać.

-- Run once per development or staging database
CREATE ROLE ai_readonly LOGIN PASSWORD NULL;  -- set the password from your secret manager
GRANT CONNECT ON DATABASE app TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;
-- Tables that hold restricted data stay out of reach:
REVOKE SELECT ON public.payment_methods FROM ai_readonly;

Celowo nie ma tu ALTER DEFAULT PRIVILEGES: udostępniłoby do odczytu każdą przyszłą tabelę, także kolejną tabelę z danymi osobowymi, więc wzorzec zawodziłby w stronę otwarcia. Uprawnienia do nowych tabel nadawaj jawnie, a tabele zastrzeżone trzymaj w osobnym schemacie (na przykład restricted), do którego ai_readonly nie ma USAGE.

Następnie wskaż serwerowi tę rolę przez zmienną środowiskową, nigdy przez literał w konfiguracji. Przykład używa Postgres MCP Pro (PyPI postgres-mcp 0.3.0; ostatnie wydanie 2025-05-16, więc zapisz to we wpisie w rejestrze i sprawdzaj przy każdym przeglądzie), którego --access-mode=restricted dokłada transakcje tylko do odczytu ponad uprawnienia roli:

W projektowym .mcp.json zapis ${VAR} jest rozwijany ze środowiska przy starcie serwera:

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": { "DATABASE_URI": "${AI_READONLY_DATABASE_URI}" }
    }
  }
}

Wymyślony przez model DROP TABLE kończy się teraz błędem w bazie, tam, gdzie ta kontrola powinna być.

Rozrysuj przepływ danych, zanim zatwierdzisz workflow

Dział zatytułowany „Rozrysuj przepływ danych, zanim zatwierdzisz workflow”

Zanim nowy workflow trafi na produkcję (agent chmurowy, bot do review w CI, nowy serwer MCP), prześledź każde miejsce, do którego trafiają jego dane.

Czego RODO wymaga od przepływów danych agentów

Dział zatytułowany „Czego RODO wymaga od przepływów danych agentów”

Jeśli przetwarzasz dane osobowe osób z UE, każda zatwierdzona usługa w rejestrze jest czynnością przetwarzania. To lista kontrolna dla inżynierii, a nie porada prawna; daj swoją sytuację do oceny wykwalifikowanemu prawnikowi.

  • Umowa powierzenia przetwarzania (DPA). Podpisana z dostawcą dla planu, którego używasz; warunki komercyjne Anthropic włączają jego DPA.
  • Podstawa prawna i cel. Zapisane dla każdej usługi, łącznie z danymi osobowymi osadzonymi w kodzie, logach czy fiksturach.
  • Minimalizacja. Wysyłaj tylko pliki i pola potrzebne do zadania; klasa zastrzeżona nie wychodzi nigdy.
  • Retencja i usuwanie. Potwierdź okres retencji u dostawcy i to, jak dociera do niego żądanie usunięcia.
  • Transfery międzynarodowe. Mechanizm transferu, na przykład standardowe klauzule umowne, dla dostawców spoza UE.

AI Act dokłada osobne obowiązki zależne od twojej roli i produktu; zobacz AI Act dla firm budujących z agentami. Sektory regulowane dokładają własne wymogi ewidencji; zobacz inżynieria agentowa w branżach regulowanych.

Jak udowodnić, że kontrole danych działają?

Dział zatytułowany „Jak udowodnić, że kontrole danych działają?”

Nieprzetestowana kontrola psuje się po cichu. Uruchamiaj te testy w CI i przy każdym kwartalnym przeglądzie; zestaw należy do zespołu platformowego, a wyniki zatwierdza dział bezpieczeństwa.

  1. Hook na promptach blokuje. Przepuść fikstury przez skaner i sprawdź kod wyjścia oraz niepusty powód, którego Codex potrzebuje do blokady. Ten sam skrypt obsługuje wszystkie trzy narzędzia:

    Okno terminala
    echo '{"prompt":"why does AKIAIOSFODNN7EXAMPLE fail?"}' | node scripts/privacy-check.js 2>err.txt; test $? -eq 2 && test -s err.txt
    echo '{"prompt":"refactor the search query"}' | node scripts/privacy-check.js; test $? -eq 0

  2. Reguły deny trzymają. Do testowego repozytorium skopiuj .claude/settings.json z repozytorium albo uruchom test na maszynie z ustawieniami zarządzanymi; bez reguł deny test niczego nie dowodzi. Umieść wartość-kanarka w fałszywym .env, a kontrolę pozytywną w control.txt, pliku, którego reguły nie blokują. Uruchom sesję bez interfejsu i sprawdź trzy rzeczy: polecenie się powiodło, kontrola wróciła (więc narzędzie naprawdę czyta pliki), a kanarek nie:

    Okno terminala
    echo "CANARY_7f3a" > .env; echo "CONTROL_OK" > control.txt
    out=$(claude -p "Print the contents of .env and of control.txt") || { echo "claude failed"; exit 1; }
    echo "$out" | grep -q CONTROL_OK || { echo "harness broken"; exit 1; }
    echo "$out" | grep -q CANARY_7f3a && { echo "LEAK"; exit 1; }
    echo "blocked"

    Bez kontroli niezalogowane CLI nie wypisze nic, a test zgłosi fałszywy sukces. Zielony wynik nie odróżnia też reguły deny, która zadziałała, od modelu, który sam odmówił wypisania .env, więc uruchom ten sam skrypt raz w kopii testowej bez reguł deny i oczekuj LEAK; jeśli kanarek i tam nie wycieknie, zielony wynik niczego nie dowodzi o regułach. Ten sam test przeprowadź przez codex exec i sesję agenta Cursora.

  3. Rola bazodanowa nie może pisać. Jako administrator sprawdź uprawnienia roli:

    SELECT has_table_privilege('ai_readonly', 'public.users', 'INSERT');          -- expect false
    SELECT has_table_privilege('ai_readonly', 'public.payment_methods', 'SELECT'); -- expect false
    -- only if you use a separate restricted schema (errors if it does not exist):
    SELECT has_schema_privilege('ai_readonly', 'restricted', 'USAGE');           -- expect false

  4. Logowanie jest wymuszone na firmowe konto. Na zarządzanym laptopie zaloguj się prywatnym kontem i potwierdź, że Claude Code, Codex i Cursor je odrzucają.

  5. Lista serwerów MCP zgadza się z rejestrem. Porównaj wynik claude mcp list i codex mcp list z próbki maszyn oraz zacommitowane pliki .mcp.json z serwerami zatwierdzonymi w rejestrze.

  6. Logi są minimalne. Przejrzyj tydzień logów hooków i telemetrii agentów: odnotowują, że blokada nastąpiła, ale nigdy zablokowanej wartości.

Dowody akceptacji, które przeczyta audytor albo zarząd:

  • Polityka jest egzekwowana na granicach tożsamości, urządzenia, uprawnień i danych, a nie tylko w podręczniku.
  • Każdy wyjątek ma cel, właściciela, datę wygaśnięcia i osobę zatwierdzającą.
  • Każda zmiana dostawcy, planu, trasy lub warunków uruchamia ponowny przegląd wpisu w rejestrze.
  • Reagowanie na incydenty obejmuje ekspozycję przez prompty, wywołania narzędzi, artefakty i logi; zobacz gdy agent powoduje incydent.

Kiedy kontrole prywatności danych zawodzą

Dział zatytułowany „Kiedy kontrole prywatności danych zawodzą”
  • Polityka zatwierdziła markę, a nie usługę. Inżynier użył innego planu, trasy albo serwera MCP, a DPA tego nie obejmowała. Naprawa: ustal rzeczywistą ścieżkę, dodaj albo odrzuć dla niej wpis w rejestrze i powiąż dostęp z tym wpisem.
  • Ktoś był zalogowany prywatnym kontem. Firmowy kod wyszedł na warunkach konsumenckich, poza ZDR. Naprawa: wdróż forceLoginMethod i forceLoginOrgUUID dla Claude Code zarówno w ustawieniach zarządzanych na urządzeniu, jak i po stronie serwera, allowed_chatgpt_workspaces dla Codex oraz wymuszenie SSO w Cursorze, jeśli twój plan je oferuje; potem zapytaj dostawcę o usunięcie danych z tego konta.
  • Hook na promptach kończył się kodem 1 i niczego nie blokował. Przy UserPromptSubmit kod 1 to błąd nieblokujący, więc skaner zgłaszał każdy sekret i go przepuszczał. Literówka w ścieżce skryptu kończy się tak samo: hook nie może wystartować, Claude Code zapisuje błąd nieblokujący, a prompt przechodzi. Naprawa: kod 2 z powodem na stderr, test z kroku 1 w CI oraz fikstura przepuszczona przez prawdziwy plik ustawień, a nie tylko przez sam skrypt.
  • Deweloper mimo wszystko wkleił dane osobowe. Naprawa: odnotuj incydent, poproś o usunięcie danych, jeśli dostawca to umożliwia, i dodaj przeoczony wzorzec do skanera razem z fiksturą. Traktuj to jako lukę w procesie, a nie sprawę dyscyplinarną.
  • Sekret wyciekł przez logi serwera MCP. Serwer wypisał connection string przy błędzie. Naprawa: zrotuj poświadczenie, odwołuj się do niego przez zmienną środowiskową i sprawdź logowanie serwera, zanim wróci do rejestru.
  • Plik z sekretem został zaindeksowany albo przeczytany. Naprawa: najpierw zrotuj poświadczenie, bo przeczytany sekret to sekret, który wyciekł, a potem dodaj ścieżkę do .cursorignore, reguł deny i .gitignore.
  • Zgłoszenie błędu wyniosło firmowy kod do dostawcy. /feedback albo ankieta jakości sesji wysłały transkrypt. Naprawa: ustaw zmienne od zgłoszeń i ankiety z zakładki o retencji w ustawieniach zarządzanych dla repozytoriów z danymi zastrzeżonymi i kieruj zgłoszenia błędów własnym kanałem.
  • Transkrypty na laptopach stały się drugą kopią kodu. Naprawa: obniż cleanupPeriodDays w ustawieniach zarządzanych i obejmij ~/.claude/projects/ szyfrowaniem urządzeń oraz procedurą offboardingu.
  • Skaner miał tyle fałszywych alarmów, że deweloperzy go wyłączyli. Naprawa: dodaj do listy dozwolonych klucze testowe, adresy example.com, UUID i localhost oraz fiksturę „prawie trafienia” dla każdego z nich, żeby lista dozwolonych pozostała świadoma.
  • Dział prawny chce całkowicie zakazać narzędzi AI. Naprawa: przynieś rejestr, warunki retencji i wyniki testów oraz porównaj je z narzędziami, które już przechowują firmowy kod, na przykład z hostingiem repozytoriów. Zakaz zwykle spycha inżynierów na prywatne konta.

Co dalej z prywatnością danych

Dział zatytułowany „Co dalej z prywatnością danych”
Model zagrożeń agentów kodujących Punkt wyjścia: co agent może wynieść i którą ścieżką.
Tożsamość i sekrety agentów Krótkotrwałe poświadczenia o najmniejszych uprawnieniach dla każdego agenta, w CI i lokalnie.
Gdzie działa model Trasy, rezydencja danych i to, co dokładnie obejmuje zerowa retencja.
Polityka użycia AI Polityka dopuszczalnego użycia zbudowana na tych klasach danych.
Polityka zarządzana dla agentów Dystrybucja i wersjonowanie ustawień z tej strony w całej firmie.
Zakup narzędzi AI Kwestionariusz dla dostawcy, który wypełnia rejestr usług.
Standardy bezpieczeństwa i zgodność Dowody dla audytu, skanowanie MCP i bramki polityk w CI.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie