Polityka narzędzi — zatwierdzone workflow i mierzone wyjątki

Polityka narzędzi AI wskazuje zatwierdzoną usługę i konfigurację dla każdego workflow inżynierskiego, granicę danych i uprawnień każdego z nich oraz właściciela, który ją zatwierdza. Maksymalny wynik w pytaniu Q2 CTO Scorecard wymaga macierzy zatwierdzonych workflow, kontrolowanych usług domyślnych i ograniczonych w czasie wyjątków, które kończą się dowodami i sprzątaniem. Lista zatwierdzonych logotypów go nie daje.

Ta strona jest dla CTO lub VP Engineering, który podejmuje decyzje o narzędziach AI, oraz dla lidera platformy lub DevEx, który utrzymuje politykę. Typowy punkt wyjścia: wiki mówi „używamy Cursora”, zespół platformowy pracuje w Claude Code na firmowych licencjach, dwóch inżynierów używa Codexa przez prywatne plany ChatGPT, a serwerów MCP czytających system zgłoszeń nikt nie przejrzał. Każda prośba o nowe narzędzie kończy się dyskusją, a niczego, co raz wypróbowano, nikt potem nie wyłącza. Zanim zaczniesz, przeczytaj klucz odpowiedzi do scorecardu CTO, żeby zobaczyć miejsce Q2 wśród pozostałych pytań, oraz politykę korzystania z AI, która definiuje klasy danych używane na tej stronie.

Co daje polityka narzędzi

Macierz zatwierdzonych workflow, która dla każdego typowego zadania odpowiada: jakie narzędzie, z jakimi danymi i co wolno mu zmienić.
Datowaną kartę usługi dla każdego narzędzia i planu, który bezpieczeństwo i finanse mogą porównać z rzeczywistą konfiguracją.
Narzędzia domyślne wymuszone ustawieniami zarządzanymi, a nie stroną na wiki.
Kartę wyjątku i test w CI, który wygasza każdy wyjątek, jeśli jego dowody nie przejdą bramki decyzyjnej.
Tabelę dowodów, którą recenzenci zatwierdzą bez audytu każdego laptopa.

Która odpowiedź w Q2 opisuje twoją organizację?

Scorecard CTO pyta „Jak wygląda polityka narzędzi (Claude Code / Cursor / Codex / inne)?” i daje cztery odpowiedzi. Tabela pokazuje, co każda z nich zostawia bez kontroli.

Odpowiedź	Wynik	Co pozostaje bez kontroli
Shadow AI: każdy używa czego chce, brak listy	0	Ścieżki danych, dostęp, wsparcie, koszty i reagowanie na incydenty
Mamy „preferowane” narzędzie, ale realnie jest mix bez kontroli	1	Wszystko poza preferowanym narzędziem, czyli tam, gdzie gromadzi się ryzyko
Krótka lista z jasnym „kiedy które”	2	Egzekwowanie, granice danych dla każdego workflow i sposób na wypróbowanie albo wycofanie narzędzia
Macierz zatwierdzonych workflow, kontrolowane usługi domyślne i ograniczone w czasie wyjątki z dowodami oraz sprzątaniem	3	Nic strukturalnego, o ile tabela dowodów poniżej przechodzi

Krok z 2 na 3 to przejście od rekomendacji do kontroli. Krótka lista mówi inżynierom, co preferować. Polityka na poziomie 3 rozstrzyga, czego każde narzędzie może dotknąć, wymusza narzędzie domyślne na firmowych komputerach i daje każdemu innemu narzędziu datowaną ścieżkę wejścia i wyjścia. Zespół DORA w Google wymienia „clear and communicated AI stance” (jasne i zakomunikowane stanowisko wobec AI) jako pierwszą z siedmiu zdolności w swoim AI Capabilities Model (blog Google Cloud, 2025-09-23), a w kolejnym tekście podaje powód wprost: „Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively” (blog Google Cloud, 2025-12-10) — niejasność tworzy ryzyko, a jasna polityka daje bezpieczeństwo psychologiczne do eksperymentów.

Zbuduj politykę narzędzi w sześciu krokach

Zinwentaryzuj, czego inżynierowie naprawdę używają. Uwzględnij rozszerzenia IDE, CLI, aplikacje desktopowe, agentów w chmurze, akcje CI, serwery MCP, pluginy i skille, klucze API oraz prywatne plany. Następna sekcja pokazuje, jak zebrać te dane dla każdego narzędzia. Każdą niewiadomą oznacz, zamiast zgadywać.
Pogrupuj workflow. Podziel realne użycie na pięć do ośmiu workflow: interaktywna praca w repozytorium, review PR, naprawy w CI, agenci w chmurze otwierający PR, prototypy, dostęp do systemów wewnętrznych przez MCP i operacje produkcyjne. Zatwierdzasz workflow, nie narzędzie.
Napisz kartę usługi dla każdego narzędzia i planu. Zapisz produkt, plan, kontrolę tożsamości, retencję danych, region, dozwolone modele, źródła MCP i pluginów, minimalną wersję, właściciela i datę weryfikacji. Szablon jest poniżej. Plan waży więcej niż marka: Codex jest w planach ChatGPT Plus, Pro, Business, Edu i Enterprise, więc „Codex jest zatwierdzony” nic nie znaczy, dopóki nie wskażesz przestrzeni roboczej (workspace).
Wybierz narzędzia domyślne i je wymuś. Wskaż jedno narzędzie domyślne na workflow, a drugie tylko tam, gdzie workflow istotnie się różnią. Potem zapisz wybór w ustawieniach zarządzanych każdego narzędzia, żeby polityka działała także na laptopie, którego nikt nie audytuje.
Otwórz ścieżkę wyjątków. Każde narzędzie spoza macierzy wchodzi przez kartę wyjątku z hipotezą, klasą danych, właścicielem, limitem kosztu i terminem ważności najwyżej 90 dni. Test w CI kończy się błędem, gdy karta wygasa bez decyzji.
Przeglądaj cyklicznie i wycofuj. Co kwartał powtórz inwentaryzację, zweryfikuj każdą kartę usługi, zamknij wygasłe wyjątki i usuń narzędzia bez ukończonej pracy. Weryfikuj od razu, gdy dostawca zmienia plan, domyślny model albo sposób przetwarzania danych.

Jak zinwentaryzować narzędzia AI, których inżynierowie już używają?

Zacznij od komputerów, bo wydatki i IdP pokazują tylko to, za co ktoś zapłacił albo do czego się zalogował. Poniższe polecenia czytają konfigurację z perspektywy samego narzędzia. Inwentaryzacja działa tak samo w każdym repozytorium, ale serwery MCP mogą być skonfigurowane per projekt, więc uruchamiaj ją w katalogu głównym każdego repozytorium, a nie raz na laptop.

claude --version              # porównaj z minimalną wersją w karcie usługi
claude mcp list               # każdy serwer MCP, także z pluginów i projektowego .mcp.json
claude plugin list --json     # zainstalowane pluginy
claude doctor                 # stan instalacji; czyta ustawienia z bieżącego katalogu

claude mcp list sprawdza stan każdego zatwierdzonego serwera, a to uruchamia lokalne serwery stdio, na przykład polecenia npx albo uvx. Uruchamiaj je tylko w repozytoriach, którym ufasz. Serwery z niezatwierdzonego projektowego .mcp.json są oznaczone jako czekające na zatwierdzenie i nie są uruchamiane. W sesji /status pokazuje źródła ustawień, w tym to, czy ustawienia zarządzane zostały wczytane. Sprawdzone na Claude Code 2.1.283.

codex --version               # porównaj z minimalną wersją w karcie usługi
codex mcp list --json         # skonfigurowane serwery MCP z transportem i stanem uwierzytelnienia
codex plugin list --json      # zainstalowane pluginy (dodaj --available, by uwzględnić niezainstalowane z marketplace'ów)
codex doctor                  # stan instalacji, konfiguracji, uwierzytelnienia i środowiska

W TUI Codexa /debug-config pokazuje każdą warstwę konfiguracji i źródło każdego wymagania, więc widać, czy zarządzany requirements.toml dotarł na komputer. Sprawdzone na Codex CLI 0.157.1.

Zbieraj wyniki skryptem, który uruchamia każdy inżynier albo twoje narzędzie do zarządzania urządzeniami, i commituj je do repozytorium polityki. Dodaj sygnały z poziomu organizacji, których komputery nie pokażą: rozliczenia wydatków za plany AI, logowania SSO do dostawców AI, aplikacje GitHub i GitLab zainstalowane w organizacji oraz workflow CI, które wywołują akcję agenta.

#!/usr/bin/env bash
# ai-inventory.sh: uruchom w katalogu głównym repozytorium; wypisuje narzędzia agentowe skonfigurowane na tym komputerze i w repozytorium
set -u
echo "== host: $(hostname)  repo: $(basename "$PWD")  date: $(date +%F)"
for cli in claude codex; do command -v "$cli" >/dev/null && "$cli" --version; done
if command -v claude >/dev/null; then
  echo "== claude mcp list";    claude mcp list
  echo "== claude plugin list"; claude plugin list --json
fi
if command -v codex >/dev/null; then
  echo "== codex mcp list";     codex mcp list --json
  echo "== codex plugin list";  codex plugin list --json
fi

Macierz zatwierdzonych workflow

To jest artefakt, który daje punkt w Q2. Skopiuj go do repozytorium polityki i podmień przykładowe wartości. Każdy wiersz zatwierdza workflow z granicą, a nie produkt.

Workflow	Usługa i konfiguracja domyślna	Najwyższa klasa danych	Uprawnienia	Wymagane dowody	Właściciel
Interaktywna praca w repozytorium	Claude Code, Codex lub Cursor na firmowych licencjach, polityka zarządzana v1.4	Wewnętrzny kod źródłowy	Lokalna gałąź; bez wypychania (push) do gałęzi chronionych	Plan, diff, zielone testy	Lider DevEx
Review PR	Zatwierdzony agent review na platformie Git	Wewnętrzny kod źródłowy	Tylko komentarze	Komentarze powiązane z PR	Lider platformy
Naprawy w CI i uruchomienia headless	`anthropics/claude-code-action` albo `openai/codex-action`, przypięte do pełnego SHA commita wydania v1, z narzędziami tylko do odczytu, chyba że zadanie musi pisać	Wewnętrzny kod źródłowy, bez sekretów produkcyjnych	Draft PR	Logi CI, pakiet dowodów	Lider platformy
Agenci w chmurze otwierający PR	Jeden zatwierdzony agent chmurowy na organizację Git	Wewnętrzny kod źródłowy	Draft PR za wymaganymi testami	Te same testy co dla PR człowieka	Lider platformy
Prototypy	Dowolne narzędzie domyślne w repozytorium sandboxowym	Dane syntetyczne lub publiczne	Bez wdrożenia na produkcję	Przegląd przed wdrożeniem prototypu	Engineering manager zespołu produktowego
Systemy wewnętrzne przez MCP	Tylko serwery z allowlisty MCP	Zgodnie z zatwierdzeniem danego serwera	Tylko odczyt, chyba że karta serwera mówi inaczej	Karta serwera i log audytowy	Lider bezpieczeństwa
Operacje produkcyjne	Domyślnie agent nie ma bezpośrednich uprawnień	Polityka produkcji	Wskazana z nazwiska bramka ludzka	Zapis wydania i rollbacku	Właściciel usługi

Trzy zasady utrzymują macierz krótką i uczciwą:

Najpierw zatwierdź granicę workflow, potem narzędzia, które do niej pasują. Claude Code, Codex i Cursor mogą stać w pierwszym wierszu razem, bo ryzyko niosą kontrole wiersza, a nie dostawca. Przewodnik po głównym narzędziu pokazuje, jak deweloper udowadnia, że jego konfiguracja spełnia wiersz.
Linkuj zmienne fakty, nie kopiuj ich. Ceny planów są w analizie cen, a wersje modeli w przeglądzie modeli. Karta usługi przechowuje datę, w której je zweryfikowano.
Macierz wskazuje reguły, nie powtarza ich. Klasy danych i zasady użycia pochodzą z polityki korzystania z AI, retencja i miejsce przechowywania danych z polityki prywatności danych, a autoryzacja MCP z bezpieczeństwa MCP.

Szablon karty usługi

Jeden plik na narzędzie i plan, w tym samym repozytorium co macierz. Recenzent porównuje kartę z rzeczywistą konfiguracją, więc każde pole musi dać się sprawdzić.

service: Claude Code
plan: Claude Team, Premium seats for platform engineers, Standard for everyone else
contract_owner: head-of-platform@example.com
surfaces: [CLI, VS Code extension, desktop app]   # czego nie ma na liście, to nie jest zatwierdzone
identity: { sso: required, login_binding: forceLoginOrgUUID in managed settings }
data: { retention: FROM_CONTRACT, training_use: FROM_CONTRACT, region: FROM_CONTRACT }
models: governed by availableModels in managed policy v1.4; default follows the models hub
mcp_allowlist: policy/mcp-allowlist.yaml
plugin_sources: [anthropics/claude-plugins-official, acme/agent-plugins]
version_floor: "2.1.274"          # kanał wydań stable z 26.09.2026
workflows_approved: [interactive-repo-work, ci-repair]
verified_on: 2026-09-26
next_review: 2026-12-26
exit_plan: export settings, skills, and hooks from the repository; revoke seats and API keys

Wartości FROM_CONTRACT to miejsca do uzupełnienia, a nie opis warunków Anthropic: wpisz je z umowy i aktualnej dokumentacji planu u dostawcy, podając dokument i jego datę. Pełny kwestionariusz dla nowego dostawcy jest w zakupie narzędzi AI do programowania.

Wymuś narzędzia domyślne na firmowych komputerach

Polityka, która żyje tylko na wiki, jest radą. Każde narzędzie czyta zarządzany plik, którego użytkownik nie nadpisze, i to w nim macierz staje się kontrolą. Kompletny plik dla wszystkich narzędzi z objaśnieniem każdego klucza jest na stronie o jednej polityce dla wszystkich agentów. Zakładki poniżej pokazują tylko klucze, które realizują macierz.

Wdrażaj przez konsolę administracyjną claude.ai, MDM albo /etc/claude-code/managed-settings.json na Linuksie.

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "YOUR_ORG_UUID",
  "availableModels": ["opus", "sonnet"],
  "enforceAvailableModels": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "@playwright/mcp@0.0.82"] }
  ],
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "anthropics/claude-plugins-official" },
    { "source": "github", "repo": "acme/agent-plugins" }
  ],
  "requiredMinimumVersion": "2.1.274"
}

forceLoginMethod razem z forceLoginOrgUUID zamyka ścieżkę przez prywatny plan: prywatne konto Pro albo Max nie zaloguje się. enforceAvailableModels sprawia, że opcja modelu Default też podlega liście, a allowManagedMcpServersOnly blokuje dodawanie serwerów przez użytkowników. Wpis serverCommand musi dokładnie odpowiadać skonfigurowanemu poleceniu, więc przypnij wersję pakietu: wpis z @latest zatwierdza to, co npm akurat rozwiąże danego dnia. Podana wersja to aktualne wydanie @playwright/mcp z 26 września 2026 roku. Przy minimalnej wersji liczą się kanały wydań: 26 września 2026 roku kanał latest miał wersję 2.1.283, a stable 2.1.274, i oba startowały sesje na innych modelach domyślnych. Zapisz w karcie usługi, który kanał zatwierdzasz.

Ograniczenia umieszczaj w requirements.toml (/etc/codex/requirements.toml na Linuksie albo dostarczany przez MDM lub workspace), nigdy w config.toml, który przechowuje ustawienia domyślne użytkownika.

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["CHATGPT_WORKSPACE_ID"]

[mcp_servers.github.identity]
url = "https://api.githubcopilot.com/mcp/"

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.acme]
source = "git"
url = "https://github.com/acme/agent-plugins.git"

[models.new_thread]
model = "MODEL_FROM_THE_MODELS_HUB"

allowed_login_methods = ["chatgpt"] razem z identyfikatorem workspace zamyka ścieżkę przez prywatny plan. Wymagania MCP dopasowują nazwę serwera i jego tożsamość łącznie, więc publikuj dokładne nazwy. Przy restrict_to_allowed_sources = true ładują się tylko marketplace’y wymienione w allowed_sources, więc wpisz tam każde źródło zatwierdzone w karcie usługi, bo inaczej pluginy zostaną zablokowane bez komunikatu dla inżyniera. W Codex CLI 0.157.1 requirements.toml nie ma klucza z allowlistą modeli (sprawdzone w config_requirements.rs 26 września 2026 roku); może też zastąpić katalog modeli przez model_catalog_json, co kształtuje listę w wyborze modelu, ale nie jest opisane jako twarda allowlista. Może natomiast przypiąć model domyślny dla nowych wątków przez [models.new_thread] model = "…" (a także model_reasoning_effort i service_tier) oraz ograniczyć model_provider; allowlistę modeli zapewnij przez workspace albo bramkę (gateway), jak opisuje strona gdzie działa model.

Cursor stosuje ustawienia zespołu z panelu administracyjnego, a pakiet @cursor/sdk 1.0.32 wymienia źródła ustawień team i mdm, więc ustawienia na poziomie zespołu i dostarczane przez MDM istnieją. Nazw poszczególnych ustawień nie dało się zweryfikować 26 września 2026 roku. Zanim oznaczysz Cursora w macierzy jako narzędzie domyślne, potwierdź w dokumentacji administracyjnej Cursora, że możesz ograniczyć logowanie do swojego zespołu, ograniczyć serwery MCP i modele oraz wymusić ustawienie prywatności, i zapisz każdą odpowiedź z datą.

Szablon karty wyjątku

Wyjątek to mały, sfinansowany eksperyment, a nie przepustka. Mówi, co ma udowodnić, czego może dotknąć, ile kosztuje i kiedy się kończy. Przykład testuje zadania w chmurze Codexa w zespole, którego narzędziem domyślnym jest agent lokalny.

id: EX-2026-014
owner: payments-lead@example.com
tool: Codex cloud tasks
plan: company ChatGPT Business workspace (no personal plans)
hypothesis: >
  Codex cloud tasks take a triaged dependency-bump issue to a green draft PR within
  one working day for the payments service, with no rise in reverted PRs.
representative_tasks: 20 dependency bumps and 10 flaky-test fixes from the current backlog
data_class: internal-source        # bez danych klientów i poświadczeń produkcyjnych
authority: draft PR only; required checks and a human approval before merge
controls: [company SSO, workspace-bound login, MCP allowlist v1.4, no production secrets]
cost_cap_usd: 1500
start: 2026-10-01
expires: 2026-11-30
success_gate: 21 of the 30 tasks merged without rework; revert rate at or below the team baseline
stop_gate: any data-class breach, or fewer than 12 tasks merged by 2026-11-01
evidence: policy/evidence/EX-2026-014/   # linki do PR, wyniki CI, pozycje faktur
cleanup: [remove the GitHub app from repositories, delete environment secrets, remove seats, remove local config]
decision: pending                  # pending | graduate | extend-once | stop

Progi są przykładowe; ustal własne na podstawie punktu odniesienia zespołu. Sam test zaprojektuj według projektu pilotażu, żeby wynik coś znaczył, a wszystko większe niż jeden zespół finansuj jako zakład na roadmapie narzędzi AI.

Uruchamiaj ten test w CI repozytorium polityki, przy każdym pull requeście i codziennie według harmonogramu. Kończy się błędem, gdy karta jest niepełna, ma decyzję spoza czterech dozwolonych wartości, trwa dłużej niż 90 dni, wygasa bez decyzji albo została zatrzymana bez potwierdzonego sprzątania. Przedłużenie to nowa karta, której pole extended_from wskazuje oryginał; test nie pozwala przedłużyć jej ponownie, więc zasada „tylko jedno przedłużenie” działa bez polegania na recenzencie.

#!/usr/bin/env python3
"""Przerywa CI, gdy wyjątek narzędziowy jest niepełny, za długi albo wygasł bez decyzji.

Użycie: python3 check_exceptions.py policy/exceptions/*.yaml   (wymaga PyYAML)
"""
import sys
from datetime import date

import yaml

REQUIRED = ["id", "owner", "tool", "hypothesis", "data_class", "authority",
            "start", "expires", "success_gate", "stop_gate", "cleanup"]
MAX_DAYS = 90
DECISIONS = {"pending", "graduate", "extend-once", "stop"}

failures = []
for path in sys.argv[1:]:
    with open(path) as f:
        rec = yaml.safe_load(f) or {}
    missing = [k for k in REQUIRED if not rec.get(k)]
    if missing:
        failures.append(f"{path}: missing {', '.join(missing)}")
        continue
    start, expires = rec["start"], rec["expires"]
    if not isinstance(start, date) or not isinstance(expires, date):
        failures.append(f"{path}: start and expires must be YYYY-MM-DD dates")
        continue
    decision = rec.get("decision", "pending")
    if decision not in DECISIONS:
        failures.append(f"{path}: decision {decision!r} is not one of {sorted(DECISIONS)}")
        continue
    if decision == "extend-once" and rec.get("extended_from"):
        failures.append(f"{path}: already an extension of {rec['extended_from']}; decide graduate or stop")
    if (expires - start).days > MAX_DAYS:
        failures.append(f"{path}: runs {(expires - start).days} days (limit {MAX_DAYS})")
    if expires < date.today() and decision == "pending":
        failures.append(f"{path}: expired {expires} with no decision")
    if decision == "stop" and not rec.get("cleanup_verified"):
        failures.append(f"{path}: stopped but cleanup_verified is not set")

print("\n".join(failures) or f"{len(sys.argv) - 1} exception records OK")
sys.exit(1 if failures else 0)

Narzędzie domyślne, wyjątek specjalistyczny czy wycofanie?

Gdy dwa narzędzia się pokrywają, decyduj na podstawie ukończonej pracy, a nie entuzjazmu. Oceń oba na tych samych reprezentatywnych zadaniach i zastosuj pierwszy pasujący wiersz.

Dowody	Decyzja
Narzędzie nie spełnia kontroli wymaganej przez wiersz workflow (przypięcie logowania, allowlista MCP, warunki danych)	Nie do zatwierdzenia w tym wierszu, niezależnie od wyników
Wykonuje reprezentatywne zadania nie lepiej niż narzędzie domyślne	Wycofaj albo nie wpuszczaj
Jest wyraźnie lepsze w jednym workflow i nie gorsze w kontrolach	Domyślne specjalistyczne tylko dla tego workflow
Jest lepsze w większości workflow, przy równych kontrolach i akceptowalnym koszcie	Kandydat na nowe narzędzie domyślne, jako zakład na roadmapie z planem migracji

Przenośność obniża koszt każdego wiersza. Kontekst w AGENTS.md, skille w otwartym formacie Agent Skills i testy w CI przechodzą z tobą między narzędziami. Codex czyta AGENTS.md natywnie, a Claude Code czyta go, gdy projekt nie ma CLAUDE.md (od v2.1.277, kanał latest). Resztę listy kontrolnej znajdziesz na stronie o unikaniu lock-inu.

Prompty do pracy nad polityką narzędzi

Uruchamiaj je w Claude Code, Codexie albo Cursorze z repozytorium polityki i wynikami inwentaryzacji w katalogu roboczym. We wszystkich trzech narzędziach działają tak samo.

Read every file in inventory/ (output of ai-inventory.sh, one file per machine and repository), policy/approved-workflows.md, policy/services/*.yaml, and policy/mcp-allowlist.yaml. Produce a gap report with four sections: (1) tools, plans, or versions in use that have no service record, (2) MCP servers and plugins in use that are not on the allowlist, with the machines and repositories where they appear, (3) machines below the version floor in their service record, (4) workflows in use that no matrix row covers. For each gap, name the owner from the matrix and propose one action: add a service record, open an exception, or remove. Do not edit any file under policy/.

Read the tool request in requests/cursor-cloud-agents.md, policy/approved-workflows.md, and policy/exceptions/EX-2026-014.yaml as the format. Draft policy/exceptions/EX-NEW.yaml for this request: a falsifiable hypothesis, 20 to 30 representative tasks taken from our real backlog in backlog.csv, the highest data class the tasks touch, the authority (never beyond a draft PR), controls, a cost cap, start and expiry no more than 90 days apart, success and stop gates stated as numbers against the team's baseline in metrics/baseline.csv, the evidence location, and a cleanup list. List any field you could not fill from the files instead of inventing it.

Read policy/exceptions/EX-2026-014.yaml and everything in policy/evidence/EX-2026-014/. Check each success and stop gate against the evidence and quote the numbers you used. Then recommend exactly one decision (graduate, extend-once, or stop) with the reason in three sentences. If graduate, draft the new row for policy/approved-workflows.md and the service record changes. If stop, list each cleanup item with the evidence that would prove it is done. Do not change the decision field yourself.

Jak udowodnić, że polityka narzędzi działa?

Nie musisz sprawdzać każdego laptopa. Potrzebujesz testów, które głośno zawodzą, gdy polityka się rozjeżdża, i konkretnej osoby, która każdy z nich zatwierdza.

Kontrola	Dowód	Warunek zaliczenia	Zatwierdza
Pokrycie macierzą	Kwartalny raport luk z inwentaryzacji	Każdy używany workflow ma wiersz w macierzy	CTO
Karty usług	Jedna datowana karta na narzędzie i plan	Każda karta zweryfikowana w ciągu ostatnich 90 dni i zgodna z konsolą administracyjną	Lider platformy
Wymuszenie narzędzi domyślnych	Test na zarządzanym komputerze: dodanie serwera MCP spoza listy, logowanie prywatnym kontem	Obie próby odrzucone, a odrzucenie zapisane	Lider bezpieczeństwa
Wyjątki	`check_exceptions.py` w CI	Zielony na gałęzi domyślnej; żadna wygasła karta bez decyzji	CTO
Wycofanie	Dowody sprzątania dla każdego zatrzymanego wyjątku i wycofanego narzędzia	Licencje, aplikacje, sekrety i lokalna konfiguracja usunięte	Właściciel IT lub tożsamości
Jasność dla inżynierów	Pięciu inżynierów pytanych, jakiego narzędzia i jakiej klasy danych używa typowe zadanie	Każdy z pięciu odpowiada zgodnie z macierzą	Lider DevEx

Dowody adopcji i efektów zatwierdzonych narzędzi należą do panelu metryk AI. Zadanie samej polityki jest węższe: pokazać, że każde używane narzędzie jest zatwierdzone dla swojego workflow i że nic, co wygasło, nie działa dalej.

Co psuje się w polityce narzędzi AI?

Zatwierdzanie logotypów zamiast workflow. „Codex jest zatwierdzony” pozwala inżynierowi używać go na prywatnym planie Plus bez żadnych twoich warunków dotyczących danych. Naprawa: przepisz każde zatwierdzenie jako wiersz macierzy i kartę usługi, która wskazuje plan i workspace, a potem przypnij logowanie ustawieniami zarządzanymi, jak opisuje strona o kontach zespołu.

Wyjątki, które nigdy się nie kończą. Pilotaż z wiosny wciąż działa jesienią, z licencjami, aplikacją GitHub i sekretami, których nikt nie ma na stanie. Naprawa: dla każdego takiego przypadku uzupełnij kartę wyjątku z terminem ważności w ciągu 30 dni, uruchom check_exceptions.py w CI i traktuj każdy zatrzymany wyjątek bez cleanup_verified jako otwartą pracę.

Jedno narzucone narzędzie. Polityka wymusza jedno narzędzie, zespół z realną potrzebą je obchodzi i shadow AI wraca. Naprawa: zostaw jedno narzędzie domyślne na workflow, a potrzebę skieruj przez wyjątek, żeby mogła się obronić dowodami.

Karty usług, które się starzeją. Dostawca zmienia plan, domyślny model albo zasadę retencji, a karta wciąż pokazuje stare warunki. Na przykład 26 września 2026 roku dwa kanały wydań Claude Code startowały sesje na różnych modelach domyślnych. Naprawa: datuj każdą kartę, weryfikuj ją co 90 dni i przy każdym ogłoszeniu dostawcy oraz zapisz w karcie kanał wydań.

Nieprzypięte rozszerzenia i CLI. Zatwierdzone narzędzia trafiają do ludzi przez rejestry, które bywały przejmowane. Do rozszerzenia Amazon Q Developer dla VS Code w wersji 1.84.0 wstrzyknięto złośliwy skrypt (advisory AWS, 2025-07-26), a nieautoryzowana publikacja cline@2.3.0 w npm zawierała zmodyfikowany skrypt postinstall (advisory Cline, 2026-02-17). Naprawa: ustaw minimalną wersję w ustawieniach zarządzanych tam, gdzie narzędzie to obsługuje, instaluj z wewnętrznego mirrora albo przejrzanego kanału aktualizacji i dodaj komunikaty bezpieczeństwa (advisories) zatwierdzonych narzędzi do listy obserwowanej przez zespół bezpieczeństwa.

Brak planu wyjścia. Narzędzie znika, a zespół traci swój kontekst. Rozszerzenie Roo Code zostało wyłączone w maju 2026 roku, jak podaje jego README. Naprawa: trzymaj kontekst, skille i testy w repozytorium w przenośnych formatach, wpisz exit_plan do każdej karty usługi i przećwicz go dla najbardziej ryzykownego dostawcy według strony o zarządzaniu ryzykiem dostawców.

Dokąd dalej z polityką narzędzi

Polityka rozstrzyga, co jest zatwierdzone. Zarządzanie kontami sprawia, że zatwierdzenie działa naprawdę, a roadmapa decyduje, co wypróbować jako następne.

Q3 · Konta zespołu Przypnij logowanie do organizacji i uzgadniaj licencje oraz koszty.

Zarządzana polityka agentów Pełny plik ustawień zarządzanych dla każdego narzędzia z objaśnieniem kluczy.

Polityka korzystania z AI Klasy danych, ujawnianie, obowiązki review i zakazane działania.

Q24 · Roadmapa narzędzi AI Finansuj większe zakłady na narzędzia z bramkami stop i datami przeglądu.

Zakup narzędzi AI do programowania Kwestionariusz bezpieczeństwa, prawny i dotyczący danych dla nowego dostawcy.

Klucz odpowiedzi: scorecard CTO Każde pytanie scorecardu przypisane do właściwej strony.