AIRUS DataProcessorOps

Каждый вызов внешней модели — это передача данных обработчику. У обработчика есть юрисдикция, срок хранения, политика обучения на ваших данных, свои субобработчики и своя история инцидентов. «Роутинг в лучшую модель» без этого слоя — это неконтролируемая цепочка передачи ПДн. AIRUS превращает DPA в исполняемую политику маршрутизации: запрос уходит только тому обработчику, которого клиент разрешил договором и чья фактическая политика проходит гейт.

Юридический слой поверх роутинга

identify parties → bind legal role → verify retention/geography (Ф69)
→ compile DPA into routing policy → block noncompliant fallback
→ monitor policy changes → cascade incidents → prove the chain
DPA-as-Code
Договор поручения обработки компилируется в runtime-политику: allowlist обработчиков и стран, максимальный retention, запрет обучения, срок уведомления о смене субобработчика — с policy_hash (sha256). Не PDF в почте, а гейт на маршруте.
Реестр субобработчиков
Каждая сторона в цепочке имеет declared правовую роль (оператор / обработчик по поручению / нижестоящий обработчик / инфраструктурный). Клиент явно одобряет обработчиков — и fallback не наследует одобрение основного.
Трансграничный гейт (fail-closed)
Гейт — это allowlist явно-разрешённого (AND): любой недостающий или нерезолвящийся вход → deny. Поданное уведомление о трансграничной передаче — одно из условий, а не разрешение. Sensitive-класс требует обработки в РФ.
Provider Data Risk + Policy Change
8 взвешенных факторов → risk score (low/medium/high/critical). При материальном изменении политики провайдера (retention↑, обучение включено, регион сменился, добавлен субобработчик) sensitive-маршруты приостанавливаются до легального ревью.

Provider Data Assurance Receipt

Request: req-4471    Data class: personal_data
AIRUS role: processor_by_instruction (declared)
Provider: yandexgpt   Processing country: RU
Retention: 0d ≤ DPA 30d ✓   Training: forbidden ✓
Cross-border: none   DPA dpa-acme v3 valid ✓
Decision: compliant   receipt_sha256: 9f3c…

Каждое routing-решение выводится из записанных DPA + стороны + одобрения + фактической политики провайдера (retention/geography/training — single-source из DataLifecycleOps), а не из того, что заявил вызывающий.

Квитанция подписана sha256 и помечена authoritative=false с role_disclaimer: она фиксирует ЧТО ОЦЕНИЛ AIRUS, а не выносит юридическую квалификацию.

Честно про слой

  • Движки детерминированы: DPA-as-Code compiler, route gate (AND fail-closed), cross-border decision, provider data risk score, policy change detector, incident cascade, provider assurance receipt (sha256).
  • Правило зашито: route/authorize ВЫЧИСЛЯЕТ решение из ЗАПИСАННЫХ DPA + party + subprocessor approval + Ф69 ProviderRetention (retention/geography/training — single-source, не дублируется). Fallback оценивается по своей стороне и не наследует одобрение основного обработчика.
  • Fail-closed: гейт — allowlist явно-разрешённого; любой missing/unresolvable вход → deny. Истёкшее одобрение = нет одобрения. Поданное трансграничное уведомление ≠ разрешение.
  • Ключевой caveat: AIRUS записывает DECLARED политики провайдеров и DPA и оценивает routing-решения. Реальный provider policy crawling/verification, подача трансграничного уведомления в РКН, доставка incident cascade и wiring гейта в фактический hot-path роутинга — roadmap.
  • Правовая роль (оператор / обработчик / …) — declared моделирующий вход; требует квалификации профильным российским юристом и ответственным за ПДн (DPO). AIRUS не выносит юридическую квалификацию.
  • Деньги: слой договорно-правовой, money-ledger (append-only, rule #1) не затрагивается; raw prompts не логируются (rule #6).
  • Поверх, не вместо: DataLifecycleOps (retention/erasure), DataAuthorizationOps (ACL), Trust Center (152-ФЗ).