Перейти к основному содержанию
Когда аудитор просит «докажите, что эти контроли действительно применялись», скриншот вашей консоли не выдержит проверки — он не подписан, он ваш, и он редактируем. OrcaRouter генерирует подписанный отчёт комплаенса: самодостаточный пакет доказательств, снятый снимком с ваших живых контролей шлюза, хэшированный SHA256 и подписанный Ed25519, так что любой, у кого есть отчёт, может проверить, что он произведён OrcaRouter и не был изменён с тех пор. Эта страница проходит сценарий от начала до конца — сгенерировать отчёт, передать его и дать аудитору проверить его независимо. По поводу каталога фреймворков и того, с чем сопоставляется каждый пакет, см. Фреймворки и Содержимое пакета.

​
1. Что содержит подписанный отчёт ai-комплаенса

Отчёт генерируется на фреймворк за выбранное вами временное окно и снимает восемь секций доказательств на момент генерации, так что артефакт остаётся валидным даже после того, как лежащие в основе логи устареют по вашей политике хранения.
Каждый отчёт покрывает одни и те же упорядоченные секции, так что два отчёта сравнимы:
  • Coverage — каким контролям фреймворка сопоставляются ваши установленные пакеты, каждый помечен covered / observe / gap / attested.
  • Enforcement — совпадения guardrail и вердикты firewall (allowed / blocked / audited), реально записанные за окно.
  • Consent — записанное состояние согласия за период, классифицированное valid / stale / revoked / none.
  • Change log — история guardrail и строки аудита рабочего пространства за окно.
  • Admin access — кто держал admin и какие привилегированные действия выполнялись.
  • Gaps — контроли, которые не покрыты, включая организационные (люди/процессы) клаузы, которые никогда не могут быть автоматизированы шлюзом. Отчёт раскрывает их как честные пробелы, а не подразумевает 100% автоматизированный комплаенс.
  • AI supply chain — вышестоящие провайдеры (субпроцессоры) и модели, достижимые рабочим пространством, чтобы доказать в свете ваших DPA.
  • Access reviews — API-ключи рабочего пространства и реестр привилегированных участников для гигиены ротации ключей.
Канонический JSON доказательств хэшируется SHA256 (строчный hex). Этот хэш содержимого подписывается Ed25519, а подпись плюс короткий id ключа (например, orca-…) встроены в артефакт. Измените один байт доказательств — и хэш больше не совпадает; подделайте хэш — и подпись больше не проверяется по публичному ключу OrcaRouter.
  • PDF — читаемая человеком передача аудитору, с напечатанными на ней подписью и id ключа.
  • JSON — машиночитаемый экспорт доказательств. (Подпись вычисляется над канонической формой доказательств, а не над сырыми байтами файла, так что проверяйте её через публичный verify-эндпоинт, а не перехэшируя артефакт сами — см. Проверка отчёта.)
  • CSV — плоский табличный экспорт для таблиц и GRC-инструментов.
По умолчанию email участников и акторов замаскированы в каждом экспорте. Включайте нередактированные PII явно для каждого отчёта, когда это нужно вашему аудитору.
Отчёты проштампованы регионом. Каждый артефакт хранится и отдаётся под заявленным регионом резидентности данных вашего рабочего пространства (us / eu / uk / ap / cn / global); отчёт, произведённый для одного региона, не отдаётся под другим. Установите резидентность до генерации, если это важно для ваших обязательств.

​
2. Кто может сгенерировать

Просмотр каталога фреймворков, установленных пакетов и готовности открыт каждому участнику рабочего пространства и бесплатен. Генерация отчёта требует Admin рабочего пространства, а экспорт шлюзован по плану:
  • Бесплатный план включает один PDF-отчёт, так что вы можете продемонстрировать артефакт.
  • Экспорт CSV / JSON и дополнительные отчёты требуют платного плана.
Оба правила применяются на стороне сервера — нет обхода только на клиенте.
Генерируйте из консоли: откройте Compliance → Reports, выберите фреймворк и временное окно, выберите формат и нажмите generate. Генерация асинхронна — строка отчёта появляется как pending, проходит до generating и попадает в ready (или failed, без частичного артефакта). Всё это работает на маршрутах /api/compliance/* под вашей консольной сессией — релейный ключ (sk-orca-…) не задействован.

​
3. Один конкретный разбор

Аудитор SOC 2 хочет доказательства применения за Q1. Рабочий процесс:
1

Установите фреймворк (один раз)

Как Admin на платном плане установите пакет SOC 2 из Compliance → Frameworks. Установка материализует guardrails и политики firewall, которые сопоставляются с контролями фреймворка. См. Установку пакета.
2

Сгенерируйте отчёт

В Compliance → Reports выберите soc2, задайте период вашему окну Q1, выберите PDF и сгенерируйте. Дождитесь, пока строка достигнет ready, затем скачайте.
3

Передайте аудитору

Отправьте им PDF (или создайте read-only ссылку-шеринг для аудитора, чтобы они могли скачать его сами). Подпись и id ключа напечатаны на отчёте.
4

Они проверяют его независимо

Аудитору никогда не нужно доверять вашей консоли. Они перехэшируют доказательства, получают публичный ключ OrcaRouter и проверяют подпись — всё по публичным, неаутентифицированным эндпоинтам (следующая секция).

​
4. Как аудитор это проверяет

Проверка не требует ни аккаунта, ни релейного ключа — она работает по двум публичным эндпоинтам на api.orcarouter.ai. Сначала получите активный публичный ключ: 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
Затем отправьте хэш содержимого, подпись и id ключа отчёта: 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
valid: true означает, что хэш доказательств был подписан OrcaRouter и не менялся с тех пор. Аудитор, который предпочёл бы не вызывать наш эндпоинт вовсе, может взять опубликованный публичный ключ Ed25519 и проверить подпись над хэшем любой стандартной крипто-библиотекой — отчёт проверяем офлайн.
Предпочитаете не отправлять PDF вложением? Создайте read-only ссылку-шеринг для аудитора — токенизированный URL, который отдаёт отчёт (и его подпись) напрямую, без логина. См. Экспорт доказательств.

​
5. Куда это вписывается

Подписанный отчёт — это артефакт в конце цикла комплаенса. Части вокруг него:

Фреймворки

Полный каталог — SOC 2, HIPAA, GDPR, EU AI Act, ISO 27001/42001, NIST AI RMF, PCI DSS, OWASP LLM Top 10 и региональный набор.

Установка пакета

Материализуйте guardrails и политики firewall фреймворка, прежде чем отчитываться по нему.

Резидентность данных

Проштампуйте и зафиксируйте регион, под которым хранится и отдаётся ваш подписанный отчёт.

Проверка отчёта

Процесс проверки в глубину — публичный ключ, хэш и офлайн-проверки.
Доказательства внутри отчёта приходят из контролей, которые вы настроили. Чтобы усилить то, о чём отчитывается, настройте ваши Guardrails и Firewall и пересмотрите границу того, что шлюз может и не может заверить, в Разделённой ответственности.