Przejdź do głównej treści
Pierwsze pytanie audytora nigdy nie brzmi „czy masz politykę?” — brzmi „pokaż mi, klauzula po klauzuli, która kontrola ją spełnia, i udowodnij, że działała”. Macierz kontroli odpowiada dokładnie na to: jeden wiersz na klauzulę w zakresie, płaszczyzna, na którą się mapuje, żywy obiekt polityki, który ją egzekwuje, i czy ta kontrola jest covered, wciąż w observe, ujawnioną gap czy poświadczoną przez właściciela (attested). OrcaRouter buduje tę macierz za ciebie z pakietów, które instalujesz — to samo mapowanie, które napędza podpisany raport, więc widok gotowości i dowody nigdy nie mogą się rozjechać. Ta strona pokazuje, jak czytać i składać macierz kontroli zgodności AI dla twojej przestrzeni roboczej, z jedną konkretną klauzulą przeprowadzoną od początku do końca. Co do tego, co pakiet faktycznie zawiera, podążaj za linkami na końcu.

1. Czym jest tu macierz kontroli zgodności AI

Macierz to suma dwóch list per framework:
  • klauzule, które zainstalowany pakiet pokrywa — każda połączona z dokładną polityką guardrail lub firewall, którą zmaterializowała instalacja;
  • klauzule, które nigdy nie mogą być zautomatyzowane przez bramę — szkolenie pracowników, umowy z podmiotami przetwarzającymi, fizyczny dostęp — autorowane jako uczciwe luki, więc macierz ujawnia je, zamiast sugerować fałszywe 100%.
Macierz to widok, nie drugi silnik. Każdy pokryty wiersz wskazuje na prawdziwą, edytowalną regułę guardrail lub politykę firewall, którą już posiadasz — otwórz ją, przeczytaj, stroij. Macierz po prostu rejestruje, która z nich odpowiada na którą klauzulę.
Każda klauzula mapuje się na dokładnie jedną z dwóch płaszczyzn:

Płaszczyzna guardrail

Klauzule treści — poufne PII, sekrety, wymagane ujawnienia — mapują się na regułę guardrail z akcją block, mask lub flag.

Płaszczyzna firewall

Klauzule akcji — nadmierna sprawczość, niebezpieczne wywołania narzędzi, egress — mapują się na regułę firewall z werdyktem allow / audit / deny na powierzchni inbound, response, mcp lub egress.

2. Stany gotowości, które wiersz może nieść

Każdy wiersz macierzy niesie jeden stan. To są słowa, które czyta audytor, więc oznaczają dokładnie to, co mówią:
StanCo oznacza
coveredKontrola pakietu jest zainstalowana i egzekwuje klauzulę.
observeZainstalowana, ale tylko-loguj — zbiera dowody by-zablokowano, jeszcze nie egzekwuje.
gapŻadna zainstalowana kontrola nie pokrywa klauzuli (lub jest organizacyjna i nie może).
attestedKlauzula organizacyjna, którą Admin poświadczył jako właściciel, zamiast zautomatyzować.
gap to nie porażka — to uczciwość. Klauzula organizacyjna jak szkolenie pracowników HIPAA 45 CFR §164.308(a)(5) nigdy nie może być egzekwowana przez proxy, więc macierz wyświetla ją jako ujawnioną lukę (lub, gdy Admin poświadczy własność, jako attested), zamiast udawać, że brama ją pokrywa.
Jest też nakładka drift: jeśli mapowanie zainstalowanego pakietu pozostaje w tyle za aktualną wersją katalogu, jego wiersze renderują się jako drift, więc wiesz, by ponownie zainstalować, zanim polegniesz na dowodach.

3. Odczytaj macierz (jedno konkretne wywołanie)

Endpoint gotowości zwraca całą macierz — procenty pokrycia per-framework, uszeregowane największe ryzyka w oknie i jeden wpis coverage_rows na klauzulę. Przeglądanie gotowości jest otwarte dla każdego Członka przestrzeni roboczej i jest darmowe, więc twoi recenzenci bezpieczeństwa i audytu mogą obserwować macierz bez dostępu do zapisu. Konsola napędza tę trasę zarządzania pod twoją sesją — nigdy nie wręczasz klucza relay sk-orca-… trasie zgodności:
GET /api/compliance/readiness?window=30d
Authorization: Bearer <your console session>
Pojedynczy pokryty wiersz wygląda tak — klauzula, płaszczyzna, stan i żywe id polityki, z którym się łączy:
{
  "framework": "soc2",
  "control_id": "soc2.confidentiality",
  "clause": "TSC CC6.1 Logical access controls",
  "reference": "https://www.aicpa-cima.com/resources/...",
  "plane": "guardrail",
  "state": "covered",
  "guardrail_id": 41,
  "observe_count": 0,
  "organizational": false
}
guardrail_id (lub firewall_policy_id na płaszczyźnie firewall) to pole nośne: wiąże klauzulę wprost z obiektem, który możesz otworzyć w konsoli i edytować jak każdy inny. To linia, którą audytor przechodzi — klauzula → id kontroli → egzekwująca polityka → dopasowania, które wyprodukowała.
Odczyt macierzy to darmowa zdolność Członka. Zbudowanie jej — zainstalowanie pakietu, by jego kontrole zaludniły wiersze — to akcja Admina przestrzeni roboczej na płatnym planie, a serwer egzekwuje obie. Widz lub darmowa przestrzeń robocza nie może zmaterializować pokrycia, wywołując API bezpośrednio. Zobacz Bramkowanie planami.

4. Złóż macierz dla swoich frameworków

Budujesz macierz, instalując pakiety. Każda instalacja scala swoje kontrole w jeden guardrail i jedną politykę firewalla oznaczone proweniencją pakietu, a jego klauzule zaczynają zaludniać coverage_rows:
  1. Wybierz swoje frameworki. Instalacja odbywa się z konsoli pod Compliance → Catalog, jako Admin przestrzeni roboczej. Katalog obejmuje reżimy bezpieczeństwa i zarządzania AI (soc2, iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, owasp_llm), reżimy sektorowe (hipaa, pci_dss, glba, nist_800_53) oraz szeroki zestaw regionalnych przepisów o ochronie prywatności (gdpr, uk_gdpr, ccpa i więcej). Przeglądaj zestaw na żywo na Frameworkach.
  2. Zainstaluj najpierw w obserwacji. Świeża instalacja ląduje w trybie obserwacji — akcje guardrail wymuszane na flag, polityka firewalla w trybie cienia — więc każdy nowy wiersz zaczyna jako observe i produkuje dowody by-zablokowano, zanim zaczyna egzekwować.
  3. Obserwuj, jak wiersze się wypełniają. Ponownie pobierz gotowość w prawdziwym oknie. Pokryte wiersze pokazują swój observe_count; luki pozostają ujawnione; klauzule organizacyjne czekają na poświadczenie.
  4. Przejdź na żywo. Gdy wiersze czytają się czysto, Admin przestrzeni roboczej przechodzi na żywo, a wiersze observe przełączają się na egzekwowanie covered.
OWASP Top 10 dla aplikacji LLM jest w katalogu jako pakiet owasp_llm — jego klauzule (na przykład LLM05:2025 Supply Chain) lądują w macierzy tak samo jak każdego innego frameworka, zmapowane na żywe kontrole lub ujawnione jako luki. Zobacz OWASP LLM Top 10.

5. Od macierzy do podpisanych dowodów

Macierz, którą czytasz w konsoli, to te same dane pokrycia, które serializuje raport — więc gdy generujesz dowody, audytor widzi identyczne stany per-klauzula, plus liczniki egzekwowania, które każda kontrola wyprodukowała w okresie. Klauzula, która zablokowała 4000 żądań, i klauzula z zerowymi dopasowaniami czytają się bardzo różnie, a raport pokazuje obie. Raporty są haszowane SHA-256, podpisane Ed25519 i publicznie weryfikowalne.
Dokładne obiekty guardrail i firewall, które pakiet materializuje, i jak każda klauzula łączy się ze swoją egzekwującą polityką — zobacz Zawartość pakietu.
Dlaczego każdy wiersz zaczyna w obserwacji, co loguje i jak przejście na żywo go przełącza — zobacz Obserwacja vs egzekwowanie.
Jak macierz renderuje się dla audytora, ze stanami per-klauzula i licznikami egzekwowania — zobacz Podpisany raport.

6. Gdzie iść dalej

Zainstaluj pakiet

Pełny przepływ instalacji, który zaludnia macierz — wybór kontroli, tryb obserwacji i przejście na żywo.

Wszystkie frameworki

Katalog na żywo frameworków, których klauzule możesz zbudować w macierz.

Guardrails vs Firewall

Dwie płaszczyzny, na które wiersz macierzy może się mapować, i jak resolver uruchamia je razem.

Współdzielona odpowiedzialność

Dlaczego niektóre klauzule są egzekwowalne przez bramę, a inne pozostają twoje — granica, którą odzwierciedla każdy wiersz luki.
Macierz kontroli to most między listą kontrolną regulatora a twoją działającą bramą: jeden wiersz na klauzulę, połączony z żywą kontrolą, która ją egzekwuje, uczciwy co do tego, czego proxy nie może pokryć, i identyczny z podpisanymi dowodami, które wręczasz audytorowi.