ISO/IEC 42001, NIST AI RMF i dowody SOC 2 z potoku agentów

Potok agentów oparty na pakiecie dowodów już dziś wytwarza większość tego, czego wymagają ISO/IEC 42001, NIST AI Risk Management Framework i badanie SOC 2. Specyfikacje, wyniki akceptacji, ewaluacje, zatwierdzenia, telemetria i proweniencja odpowiadają konkretnym klauzulom, podkategoriom i kryteriom. Pozostaje jednorazowo je zmapować, archiwizować i testować kontrole.

Okres twojego raportu SOC 2 Type II kończy się w grudniu. Kwestionariusz klienta pyta, czy jesteście „zgodni z NIST AI RMF”, dział sprzedaży chce pisać „ISO/IEC 42001 w toku”, a audytor zauważył, że jedna trzecia zmergowanych w tym roku pull requestów pochodzi od Claude Code albo Codeksa. Nikt nie chce drugiego programu zgodności. Musisz wiedzieć, które artefakty twojego potoku już liczą się jako dowody i gdzie są luki.

Ta strona jest dla CTO, który odpowiada na to pytanie. To inżynierska lektura, a nie porada audytowa ani prawna: projekt kontroli uzgodnij z audytorem lub jednostką certyfikującą. Strona opiera się na kontrolach rozdziału obowiązków i archiwum z merge’u opisanych w inżynierii agentowej w branżach regulowanych.

Źródła i sposób weryfikacji

Teksty frameworków odczytano 2026-09-26 z maszynowo czytelnych kopii: NIST AI RMF 1.0 z repozytorium Splunka security_content, a tytuły ISO/IEC 42001:2023 i Trust Services Criteria (2017, zmienione 2022) z biblioteki CISO Assistant, bo iso.org, nist.gov i aicpa-cima.com były niedostępne. Strona cytuje wyłącznie tytuły ISO; przed napisaniem deklaracji stosowania przeczytaj licencjonowany tekst.

Co ta strona daje CTO przed audytem systemu zarządzania AI

• Decyzję o zakresie: które kontrole ISO/IEC 42001 dotyczą używania agentów, a które dostarczania funkcji AI.
• Tabelę kontroli i dowodów, która przypisuje każdy artefakt potoku do ISO/IEC 42001, NIST AI RMF i SOC 2.
• Plik mapy dowodów z zapytaniem, właścicielem i częstotliwością dla każdej kontroli.
• Ustawienia telemetrii dla Claude Code, Codeksa i Cursora, skrypt inwentarza i trzy prompty do skopiowania.

Czego wymagają ISO/IEC 42001, NIST AI RMF i SOC 2?

Każdy z trzech frameworków odpowiada na inne pytanie, więc jeden zestaw dowodów może obsłużyć wszystkie.

Framework	Czym jest	Co otrzymujesz	Na co patrzy oceniający
ISO/IEC 42001:2023	Certyfikowalny system zarządzania AI: klauzule 4–10 oraz 38 kontroli referencyjnych w załączniku A, w dziewięciu celach od A.2 do A.10	Certyfikat akredytowanej jednostki certyfikującej	Ocenę i postępowanie z ryzykiem AI, deklarację stosowania (Statement of Applicability) i dowody, że kontrole działają
NIST AI RMF 1.0 (NIST AI 100-1)	Dobrowolny framework z czterema funkcjami: GOVERN, MAP, MEASURE i MANAGE, podzielonymi na kategorie i podkategorie	Brak certyfikatu; deklaracja zgodności, o którą pytają kwestionariusze klientów	To, co wybierze do próby klient lub audyt wewnętrzny: zwykle polityki, role, inwentarz, testy, monitoring i incydenty
SOC 2	Raport atestacyjny AICPA o twoich kontrolach wobec Trust Services Criteria; bezpieczeństwo obejmują Common Criteria CC1–CC9	Raport Type I (projekt kontroli w danym momencie) albo Type II (działanie przez okres)	Próbę zmian, nadań dostępu i incydentów, testowaną wobec opisanych kontroli

Przy ustalaniu zakresu pomagają dwa powiązane dokumenty: NIST AI 600-1, profil generatywnej AI (2024-07-26), który wymienia dwanaście ryzyk generatywnej AI, oraz ISO/IEC 42005:2025 o ocenie wpływu (oba SECONDARY, z wyciągów wyszukiwarki ze stron NIST i ISO, 2026-09-26). Mapowanie poniżej używa AI RMF 1.0 w opublikowanej wersji.

Czy twoi agenci kodujący wchodzą w zakres systemu zarządzania AI?

Rozstrzygnij to najpierw i na piśmie, bo od tego zależy, które kontrole z załącznika A trafią do deklaracji stosowania. Używając Claude Code, Codeksa lub Cursora, jesteś użytkownikiem systemów AI stron trzecich; dostarczając chatbota, system rekomendacji albo funkcję agentową, jesteś też twórcą. Większość firm programistycznych jest jednym i drugim.

Sytuacja	Kluczowe kontrole ISO/IEC 42001	Nacisk w NIST AI RMF	Nacisk w SOC 2
Używasz agentów kodujących do budowy oprogramowania, które nie zawiera AI	A.4.4 zasoby narzędziowe, A.9.2–A.9.4 odpowiedzialne i zamierzone użycie, A.10.3 dostawcy, A.6.2.8 dzienniki zdarzeń, A.3.2 role	GOVERN 1, 2, 6; MANAGE 3 (zasoby stron trzecich i modele wstępnie wytrenowane)	CC8.1 zmiany, CC6 dostęp tożsamości agentów, CC7.2 monitoring, CC9.2 dostawcy
Dodatkowo dostarczasz funkcje AI zbudowane z pomocą tych agentów	Wszystko powyżej plus kontrole cyklu życia A.6.2.2–A.6.2.7, kontrole danych A.7 i ocena wpływu A.5 dla każdej funkcji	Wszystkie cztery funkcje dla każdego systemu AI, z ewaluacjami MEASURE 2 przy każdym wydaniu	To samo, z kryteriami integralności przetwarzania, jeśli raport je obejmuje

Wyłączenie potoku agentów z zakresu jest dopuszczalne, ale każdą wyłączoną kontrolę z załącznika A musisz uzasadnić. „Programiści używają agentów kodujących w ramach naszego standardowego procesu zmian” to uzasadnienie, które jednostka certyfikująca może sprawdzić; „agenci kodujący są poza zakresem” już nie.

Certyfikaty dostawcy to dowód dla kontroli dostawców, a nie twoja kontrola

Strona bezpieczeństwa Claude Code odsyła do raportu SOC 2 Type 2 i certyfikatu ISO 27001 w Anthropic Trust Center (sprawdzone 2026-09-26). Równoważne raporty zamów od każdego dostawcy agentów. Są dowodem dla twojej kontroli dostawców (A.10.3, GOVERN 6.1, CC9.2), a nie tego, jak twoje zmiany są autoryzowane, testowane i zatwierdzane.

Tabela kontroli i dowodów

Każdy wiersz to jeden cel kontroli, klauzula, podkategoria i kryterium, które spełnia, oraz artefakt, który na nie odpowiada, zbudowany w innym miejscu serwisu: pakiet dowodów, klasy ryzyka z zarządzania i autonomii, polityka zarządzana, telemetria, ewaluacje i rejestr incydentów.

Cel kontroli	ISO/IEC 42001	NIST AI RMF	SOC 2	Dowód z potoku agentów
Polityka AI, która jest egzekwowana, a nie tylko opublikowana	5.2, A.2.2, A.2.3	GOVERN 1.1, 1.2, 1.4	CC5.3	Polityka użycia AI oraz pliki ustawień zarządzanych (/etc/claude-code/managed-settings.json, /etc/codex/requirements.toml, ustawienia administracyjne Cursora) wersjonowane w git; zdarzenie managed_settings_resolved w Claude Code pokazuje, jaka polityka obowiązywała w każdej sesji
Role, rozliczalność i nadzór człowieka	5.3, A.3.2	GOVERN 2.1, 3.2; MAP 3.5	CC1.3, CC1.5	Macierz RACI z modelu operacyjnego; provenance.human_owner w każdym pakiecie; CODEOWNERS dla wrażliwych ścieżek; zasada, że agent może pisać i recenzować, ale nigdy zatwierdzać
Inwentarz narzędzi AI, modeli i rozszerzeń	A.4.2, A.4.4	GOVERN 1.6; MAP 4.1	CC9.2; opis systemu	Kwartalny inwentarz z provenance.agent i provenance.model (skrypt niżej) oraz listy dozwolonych serwerów MCP, skilli i pluginów z polityki zarządzanej
Ocena ryzyka AI i postępowanie z nim	6.1, 8.2, 8.3	MAP 1.5, 4.2; MANAGE 1.2, 1.3	CC3.2, CC3.4	Model zagrożeń dla agentów; klasy ryzyka wyliczane przez CI z diffu; rejestr autonomii pętli działających bez nadzoru
Ocena wpływu	6.1, 8.4, A.5.2–A.5.5	MAP 5.1	—	Jedna ocena potoku agentów plus jedna na każdą dostarczaną funkcję AI; kiedy funkcja zmienia twoje obowiązki, opisuje strona o AI Act
Wymagania przed budową	A.6.2.2, A.6.2.3	MAP 1.1, 3.3	CC8.1 (autoryzacja, projekt)	spec.link i spec.delta w pakiecie; specyfikacja, plan i zadania z łańcucha artefaktów
Weryfikacja i walidacja	A.6.2.4	MEASURE 2.1, 2.3, 2.5	CC8.1 (testy)	Wyniki acceptance i checks; evals względem baseline; wynik mutacyjny z siły wyroczni; oracle_changes dowodzące, że żadnego testu nie poluzowano bez recenzji właściciela kodu
Kontrolowane wdrożenie i zatwierdzanie zmian	A.6.2.5	MANAGE 1.1	CC8.1 (zatwierdzenie, wdrożenie)	Ruleset bez listy obejść, kontrola rozdziału obowiązków, środowisko produkcyjne z zakazem samozatwierdzenia i zapisy stopniowego wdrażania
Działanie i monitoring	A.6.2.6, 9.1	MEASURE 2.4, 3.1; MANAGE 4.1	CC7.2	Obserwowalność agentów: OpenTelemetry z każdego agenta, odmowy tool_decision i wyniki sandboksa, połączone z pull requestami
Dzienniki zdarzeń, które przetrwają	A.6.2.8	MEASURE 2.8	CC7.2, CC4.1	Telemetria przechowywana w SIEM i podpisane archiwum z merge’u: pakiet, recenzje i przebiegi checków (actions/attest)
Dostęp tożsamości agentów	— (kontrola dostępu należy do ISO/IEC 27001)	GOVERN 3.2	CC6.1, CC6.2, CC6.3	Osobne GitHub Apps dla agentów, krótko żyjące tokeny i zapisy unieważnień z tożsamości i sekretów agentów; reguły deny w ustawieniach zarządzanych
Dane trafiające do kontekstu agenta	A.7.4, A.7.5	MEASURE 2.10	CC6.7	Klasy danych i zatwierdzone trasy do modeli z prywatności danych i hostingu modeli; reguły deny dla ścieżek z sekretami i danymi regulowanymi
Dostawcy i modele wstępnie wytrenowane	A.10.2, A.10.3	GOVERN 6.1, 6.2; MANAGE 3.1, 3.2	CC9.2	Raporty dostawców z procesu zakupowego; przypięte wersje narzędzi; wyniki ewaluacji przy każdej zmianie modelu według playbooka nowego modelu
Incydenty i możliwość zatrzymania agenta	A.3.3, A.8.4	GOVERN 4.3; MANAGE 2.3, 2.4, 4.3	CC7.3, CC7.4, CC7.5	Rejestr incydentów agentów i postmortemy; procedura zamrożenia (unieważnij tożsamość, wstrzymaj pętle, wypchnij restrykcyjną politykę); ustalenia zamienione w ewaluacje albo zmiany polityki
Kompetencje i umiejętności w zakresie AI	7.2, 7.3, A.4.6	GOVERN 2.2	CC1.4, CC2.2	Zapisy szkoleń ze strony o podnoszeniu kwalifikacji
Audyt wewnętrzny i ciągłe doskonalenie	9.2, 9.3, 10.2	MEASURE 1.2, 1.3, 2.13; MANAGE 4.2	CC4.1, CC4.2	Kwartalne metryki kontroli, testy kontroli, które na żądanie kończą się porażką, i protokoły przeglądu zarządzania, które na nie reagują

Dwa wiersze wymagają oceny. MANAGE 3.2 mówi, że wstępnie wytrenowane modele używane w wytwarzaniu „are monitored as part of AI system regular monitoring and maintenance”: zestaw ewaluacji uruchamia się, gdy dostawca wypuszcza nowy model domyślny, a nie tylko przy zmianie twojego kodu. MANAGE 2.4 wymaga mechanizmów, by „supersede, disengage, or deactivate AI systems”: to twoja procedura zamrożenia, a audytor zapyta, kiedy ostatnio ją ćwiczyliście.

Jak zamienić tabelę w dowody gotowe na audyt?

Tabela opisuje projekt kontroli; audytor SOC 2 Type II testuje działanie przez cały okres. Pięć poniższych kroków sprawia, że na każdy wiersz odpowiada zapytanie, a nie spotkanie.

1. Zapisz deklarację zakresu i wiersze deklaracji stosowania dla potoku. Wskaż agentów kodujących jako systemy AI, których organizacja używa, i wypisz kontrole z załącznika A z tabeli zakresu wraz z uzasadnieniem. Trzymaj to obok kontroli, żeby obie zmiany trafiały do jednego pull requesta.

2. Uczyń pakiet dowodów obowiązkowym i archiwizuj go przy merge’u. Bramkę opisuje strona o pakiecie dowodów, a zadanie archiwizujące strona o branżach regulowanych.

3. Zacommituj mapę dowodów, która dla każdej kontroli podaje zapytanie, właściciela i częstotliwość. Audytor czyta ją jako pierwszą. Dopasuj właścicieli i repozytoria:

   controls/ai-evidence-map.yaml

   version: 3
   scope: "Coding agents used in acme/* repositories (AIMS scope statement v2)"
   controls:
     - id: change-approval
       iso42001: ["A.6.2.5"]
       nist_ai_rmf: ["MANAGE 1.1"]
       soc2: ["CC8.1"]
       evidence:
         - "Signed evidence archives for merged PRs (object-locked bucket, 7-year retention)"
         - "Ruleset regulated-default-branch export, bypass_actors = []"
       query: "Merged PRs in period without a passing 'sod' check on the head commit"
       expected: 0
       owner: "@acme/platform"
       frequency: quarterly
     - id: verification
       iso42001: ["A.6.2.4"]
       nist_ai_rmf: ["MEASURE 2.1", "MEASURE 2.3"]
       soc2: ["CC8.1"]
       evidence:
         - "evidence_bundle.acceptance and .checks in each archive"
         - "Mutation score per service from the nightly oracle-strength job"
       query: "Archives with any acceptance result other than pass, or a 'looser' oracle change without code-owner approval"
       expected: 0
       owner: "@acme/quality"
       frequency: quarterly
     - id: model-change
       iso42001: ["A.10.3"]
       nist_ai_rmf: ["MANAGE 3.2", "GOVERN 6.1"]
       soc2: ["CC9.2"]
       evidence:
         - "Eval run against baseline for every model or tool version adopted"
       query: "Models in the inventory with no eval run recorded before first use"
       expected: 0
       owner: "@acme/platform"
       frequency: on-change
     - id: agent-event-logs
       iso42001: ["A.6.2.8"]
       nist_ai_rmf: ["MEASURE 2.8", "MANAGE 4.1"]
       soc2: ["CC7.2"]
       evidence:
         - "OpenTelemetry logs from Claude Code and Codex in the SIEM, 400-day retention"
       query: "Active agent users in the period with no telemetry in the SIEM"
       expected: 0
       owner: "@acme/security"
       frequency: monthly

4. Buduj inwentarz agentów i modeli z archiwów, a nie z arkusza kalkulacyjnego. A.4.4 i GOVERN 1.6 wymagają inwentarza, a blok proweniencji zapisuje go przy każdej zmianie. To polecenie wypisuje zmergowane w kwartale pull requesty z agentem, modelem i klasą ryzyka:

   # Terminal, read-only. Needs gh and jq.
   gh pr list --repo acme/payments-api --state merged \
     --search "merged:2026-07-01..2026-09-30" --limit 1000 --json number,body \
   | jq -r '.[] | (.body // "") as $b | [.number,
       (($b | capture("agent:[ \\t]*(?<v>[^\\r\\n]+)") | .v) // "none"),
       (($b | capture("model:[ \\t]*(?<v>[^\\r\\n]+)") | .v) // "none"),
       (($b | capture("class:[ \\t]*(?<v>[a-z]+)") | .v) // "none")] | @csv' \
   > inventory-2026-q3.csv

   Pogrupuj według agenta i modelu. Każdy model musi mieć przebieg ewaluacji sprzed pierwszego użycia (kontrola model-change), a wiersz z none to zmiana bez pakietu, czyli ustalenie samo w sobie. Wyszukiwanie zwraca najwyżej 1000 wyników, więc ruchliwe kwartały dziel na miesiące. Dla poświadczonych liczb uruchom ten sam filtr jq na podpisanych archiwach.

5. Testuj każdą kontrolę tak jak wyrocznię: przypadkami, które muszą się nie powieść. Otwórz trzy próbne pull requesty: jeden bez pakietu, drugi zatwierdzony tylko przez właściciela zmiany i trzeci z poluzowanym testem. Osobno spróbuj wypchnąć zmianę z tożsamości agenta z unieważnionym tokenem i zarchiwizuj odrzucone uwierzytelnienie (wpis w dzienniku audytu). Zapisz nieudane przebiegi i to odrzucenie jako dowód skuteczności działania dla SOC 2 i audytu wewnętrznego ISO/IEC 42001 (9.2).

Jak Claude Code, Codex i Cursor tworzą dzienniki zdarzeń?

Pakiet, rulesety i archiwum są takie same dla każdego narzędzia. Różni się dziennik zdarzeń: A.6.2.8 i CC7.2 wymagają zapisu tego, co zrobił każdy agent, a każde narzędzie eksportuje go inaczej. W każdym z nich trzymaj treść promptów i narzędzi poza eksportem: dziennik, który zapisuje prompty, zapisuje też zawarte w nich sekrety i dane osobowe.

Claude Code

Umieść eksporter w ustawieniach zarządzanych, żeby programiści nie mogli go wyłączyć (na Linuksie /etc/claude-code/managed-settings.json):

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.internal:4317",
    "OTEL_LOG_MANAGED_SETTINGS": "1"
  }
}

Claude Code 2.1.283 emituje zdarzenie claude_code.tool_decision dla każdego wywołania narzędzia: dozwolone czy odrzucone i czy zdecydowała konfiguracja, hook czy użytkownik. Zdarzenia niosą session.id oraz, gdy jest dostępny, user.email, co pozwala połączyć sesję z provenance.session w pakiecie. Tekst promptu ma wartość <REDACTED>, a argumenty narzędzi są pomijane, dopóki nie ustawisz OTEL_LOG_USER_PROMPTS=1 lub OTEL_LOG_TOOL_DETAILS=1; zostaw obie nieustawione, podobnie jak OTEL_LOG_TOOL_CONTENT, OTEL_LOG_ASSISTANT_RESPONSES i OTEL_LOG_RAW_API_BODIES.

OTEL_LOG_MANAGED_SETTINGS=1 (od v2.1.274, więc 2026-09-26 w obu kanałach, stable i latest) dodaje zredagowaną treść obowiązujących ustawień zarządzanych do zdarzenia claude_code.managed_settings_resolved, wysyłanego przy starcie i przy każdej zmianie. Ustaw ją jak wyżej: skrót SHA-256 (managed_settings.resolved_sha256) jest wysyłany tylko przy tej fladze, więc maszyny bez niej raportują swoje źródła, ale bez skrótu. Potwierdź to zdarzeniem testowym. Maszyny raportujące ten sam skrót działały pod tą samą polityką: to dowód działania kontroli dla wiersza o polityce (A.2.2, CC5.3). Skrót SHA-256 krótkiej polityki da się odwrócić, hashując kolejne zgadywane wartości, więc ogranicz w SIEM dostęp do odczytu tego pola. Zapisuj kanał wydań razem z wersją: 2026-09-26 kanał latest to 2.1.283, a stable to 2.1.274.

Codex

Umieść eksporter w tabeli [otel] pliku config.toml:

[otel]
environment = "prod"
log_user_prompt = false          # default; prompts are not exported

[otel.exporter.otlp-http]
endpoint = "https://otel-collector.internal:4318/v1/logs"
protocol = "binary"

Codex CLI 0.157.1 emituje między innymi codex.conversation_starts (polityka zatwierdzeń i sandboksa, poziom rozumowania, serwery MCP), codex.tool_decision (zatwierdzone lub odrzucone i przez kogo) oraz codex.sandbox_outcome. Domyślnie eksporter logów jest wyłączony.

To, gdzie umieścisz tę tabelę, decyduje, czy jest kontrolą. W 0.157.1 /etc/codex/config.toml i konfiguracja zarządzana z chmury mają niższy priorytet niż własny ~/.codex/config.toml programisty, a requirements.toml nie ma klucza otel, którym dałoby się zablokować eksporter (sprawdzone w kodzie źródłowym 0.157.1). Dlatego:

• Zarządzane laptopy: umieść [otel] w starszym pliku /etc/codex/managed_config.toml (lub zarządzanej konfiguracji z MDM na macOS), który 0.157.1 wczytuje ponad wszystkimi warstwami, także ponad --config. Potwierdź to zdarzeniem testowym i zapisz w mapie dowodów, że to mechanizm starszego typu.
• Niezarządzane laptopy: traktuj telemetrię Codeksa jako niegwarantowaną (zbieraną w miarę możliwości) i zapisz to w mapie dowodów.
• CI: wiarygodny zapis. Wskaż CODEX_HOME na katalog zapisywany przez workflow, przypnij CLI (npm install -g @openai/codex@0.157.1), a tryby sandboksa i listy dozwolonych serwerów MCP trzymaj w /etc/codex/requirements.toml.

Cursor

cursor.com był niedostępny 2026-09-26, więc ta strona nie opisuje eksportów administracyjnych Cursora. Zapytaj administratora Cursora, jakie dane o użyciu i audycie eksportuje wasz plan, zapisz odpowiedź z datą w mapie dowodów i do tego czasu traktuj Cursora jako ręczne źródło dowodów.

Komentarze z przeglądów Bugbota trafiają do pull requesta, więc archiwum z merge’u zapisuje je w reviews.json. Jeśli włączysz w Cursorze PR Routing & Approval, który może zatwierdzać pull requesty niskiego ryzyka, niech kontrola rozdziału obowiązków ignoruje jego zatwierdzenia: zatwierdzenie przez agenta nigdy nie liczy się jako niezależne zatwierdzenie, które CC8.1 bierze do próby.

Prompty do skopiowania na przygotowanie do audytu zarządzania AI

Te prompty czytają repozytoria i ustawienia; żaden nie zmienia kontroli. Są identyczne w Claude Code, Codeksie i Cursorze; uruchamiaj je w trybie planowania lub tylko do odczytu (plan mode w Claude Code, --sandbox read-only w Codeksie, tryb Ask w Cursorze). Niech człowiek sprawdzi każdy wiersz, zanim trafi do audytora.

Prompt do skopiowania: szkic mapy kontroli i dowodów z repozytorium

Read-only task. Build a first draft of controls/ai-evidence-map.yaml for the
repositories acme/payments-api and acme/ledger.

Inputs to read: .github/workflows/*.yml, .github/CODEOWNERS,
.github/evidence-policy.yml, .github/pull_request_template.md, the ruleset
JSON under docs/controls/, and any managed settings or requirements.toml
files under infra/agent-policy/.

For each of these control objectives: change approval, verification,
event logs, agent access, inventory, supplier and model change, incident
and freeze, write one entry with: id, the ISO/IEC 42001 Annex A control,
the NIST AI RMF 1.0 subcategory, the SOC 2 criterion, the evidence that
exists today (cite the file and job name), a query an auditor could run,
the expected result, and owner.

Where no file implements the control, write evidence: [] and add a
GAP comment saying what is missing. Do not invent job names or files.
Output only the YAML.

Prompt do skopiowania: odpowiedź na kwestionariusz klienta o zarządzaniu AI

A customer sent the security questionnaire in docs/customers/q-2026-10.xlsx
(export it to CSV first if needed). Answer only the questions about AI,
machine learning, coding assistants or automated code generation.

For each answer, cite the evidence from controls/ai-evidence-map.yaml by
control id, and quote the ISO/IEC 42001, NIST AI RMF or SOC 2 reference
it maps to. Answer "Yes", "Partially" or "No", then two sentences.
Use "Partially" whenever the map has a GAP comment for that control.
Never claim a certification, attestation or framework alignment that the
map does not show. List any question you could not answer from the map
at the end, with the control that would be needed.

Prompt do skopiowania: próba do audytu wewnętrznego

Read-only. Prepare an ISO/IEC 42001 internal audit sample (clause 9.2)
for the agent pipeline, period 2026-07-01 to 2026-09-30.

1. Read inventory-2026-q3.csv. Pick 25 merged pull requests: all rows
   with class high, then a random selection of the rest, and every row
   whose agent or model is "none".
2. For each one, use the gh CLI to fetch the reviews and the check runs on
   the head commit. Report: agent, model, risk class, whether "evidence"
   and "sod" passed, the approving reviewer and whether that reviewer
   equals the human_owner or the author.
3. For each distinct model in the sample, search evals/results/ for a run
   dated before that model's first appearance in the inventory.

Output a table per pull request, then a list of findings, each with the
control id from controls/ai-evidence-map.yaml. Write "not found" for
missing data and name the command you ran.

Skąd wiesz, że dowody się obronią?

Dowody się bronią, gdy ktoś inny niż ich autor może je sprawdzić bez twojej pomocy. Zapewniają to cztery praktyki.

• Niezależność oceniającego. MEASURE 1.3 wymaga udziału „internal experts who did not serve as front-line developers”; klauzula 9.2 ISO/IEC 42001 wymaga obiektywnego audytu wewnętrznego. Kwartalną próbę niech przeprowadza zespół bezpieczeństwa albo jakości, a nie zespół platformowy.
• Metryki z mianownikiem. Raportuj odsetek zmergowanych pull requestów z kompletnym pakietem, niezależnym zatwierdzeniem ostatniego commita i zapisaną ewaluacją modelu. Cel to 100%, a każdy wyjątek ma zgłoszenie. Kanoniczne definicje metryk są na stronie o frameworkach metryk.
• Przechowywany zapis, a nie bieżący. Licz każdą metrykę z podpisanych archiwów. Pull request edytowany po merge’u to inny zapis niż ten, który poświadczyliście.
• Podpis konkretnej osoby. CTO jako właściciel systemu zarządzania AI podpisuje przegląd zarządzania (klauzula 9.3), który czyta te metryki i decyduje o działaniach korygujących (klauzula 10.2). Agent może przygotować pakiet materiałów; podpisuje człowiek.

Nie przedstawiaj „% kodu napisanego przez AI” jako dowodu kontroli: mierzy adopcję, a żaden z trzech frameworków tego nie wymaga.

Co psuje się przy mapowaniu potoku agentów na standardy zarządzania AI?

Usterka	Jak się objawia	Jak naprawić
Zakres certyfikatu pomija agentów. System zarządzania AI obejmuje tylko funkcje AI.	Pytana o nadzór nad agentami kodującymi, deklaracja stosowania milczy.	Rozszerz deklarację zakresu o systemy AI, których używacie, dodaj wiersze A.4.4, A.9 i A.10.3 z dowodami i odnotuj zmianę w przeglądzie zarządzania.
Raport dostawcy przedstawiony jako twoja kontrola.	Opis systemu w SOC 2 powołuje się na raport SOC 2 dostawcy w części o zarządzaniu zmianą.	Przenieś go do wiersza CC9.2 o dostawcach; CC8.1 pokaż własnymi archiwami i zatwierdzeniami.
Ewaluacje nie uruchamiają się przy zmianie modelu. Dostawca wypuszcza nowy model domyślny, a zespół przechodzi na niego następnego dnia.	Inwentarz pokazuje model bez przebiegu ewaluacji sprzed pierwszego użycia.	Przypnij wersje w ustawieniach zarządzanych, wprowadzaj modele według playbooka nowego modelu i zapisz niezgodność z działaniem korygującym (klauzula 10.2).
Dziennik zdarzeń przechowuje prompty. Ktoś włączył logowanie promptów, żeby zdebugować sesję.	Sekrety albo dane osobowe w SIEM; ustalenie z zakresu ochrony danych.	Usuń te flagi, wyczyść dane zgodnie z zasadami retencji i dodaj check w CI pod tabelą, który zawodzi, gdy którykolwiek plik zarządzany włącza OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_RAW_API_BODIES albo w Codeksie log_user_prompt = true.
Polityka istnieje tylko jako dokument.	Audytor prosi o kontrolę, która egzekwuje dany zapis, i dostaje PDF.	Oznacz każdy zapis jako egzekwowany (ustawienia zarządzane, hooki) albo oparty na zaufaniu, tak jak robi to strona o polityce użycia; testuj te egzekwowane.
Telemetria Codeksa po cichu wyłączona. Własny config.toml programisty nadpisuje /etc/codex/config.toml.	Zapytanie kontroli agent-event-logs znajduje aktywnych użytkowników Codeksa bez zdarzeń w SIEM.	Na zarządzanych laptopach przenieś [otel] do /etc/codex/managed_config.toml, jak w zakładce Codex wyżej. W pozostałych przypadkach opieraj się na przebiegach CI i provenance w pakiecie.
Procedura zamrożenia nigdy nie była uruchomiona.	Testowane jest MANAGE 2.4 lub CC7.4 i nikt nie wie, jak zatrzymać pętlę działającą bez nadzoru.	Ćwicz ją co kwartał według playbooka incydentów agentów i archiwizuj ćwiczenie.

Check w CI dla wiersza o logowaniu promptów przerywa zadanie, gdy którykolwiek plik w katalogu polityki, łącznie z ukrytymi i pomijanymi przez .gitignore, włącza logowanie treści wartością 1 albo true. Przy awarii także blokuje: brak katalogu albo brak lub błąd rg zatrzymuje zadanie, zamiast je przepuścić. Przechodzi tylko kod wyjścia 1, czyli brak dopasowań.

dir=infra/agent-policy
test -d "$dir" || { echo "::error::$dir not found"; exit 1; }
status=0
rg -n -i --hidden --no-ignore \
  'OTEL_LOG_(USER_PROMPTS|TOOL_DETAILS|TOOL_CONTENT|ASSISTANT_RESPONSES|RAW_API_BODIES)"\s*:\s*"?(1|true)"?|log_user_prompt\s*=\s*true' \
  "$dir" || status=$?
case "$status" in
  1) echo "No managed file enables content logging." ;;
  0) echo "::error::content logging is enabled in the lines above"; exit 1 ;;
  *) echo "::error::rg exited $status (missing or failed)"; exit 1 ;;
esac

Dokąd dalej ze standardami zarządzania AI

Inżynieria agentowa w branżach regulowanych Rozdział obowiązków, ruleset i podpisane archiwum z merge'u.

Pakiet dowodów Kontrakt pull requesta, który wypełnia większość wierszy tabeli.

Ewaluacje agentów kodujących Zestawy ewaluacji, które wytwarzają dowody dla MEASURE 2 i A.6.2.4.

Obserwowalność agentów OpenTelemetry z każdego agenta połączona z pull requestami.

AI Act dla firm tworzących oprogramowanie z agentami Co AI Act dodaje, gdy używasz agentów kodujących lub dostarczasz funkcje AI.

Zakup narzędzi AI do kodowania Kwestionariusz dostawcy, który daje dowody dla kontroli dostawców.