Самая дорогая ошибка в работе с AI-контекстом часто происходит без утечки, сбоя или громкого инцидента. Команда уже не может восстановить решение: был ли фрагмент разрешён, к какому plan он относился, куда шёл трафик и кто согласовал срок. Цена ошибки — остановка внедрения, повторная инвентаризация и риск принять второе решение по памяти вместо фактов. Особенно плохо, когда evidence распределён между настройкой IDE, DPA, сетевым правилом и устным «можно».
Причина — попытка сделать один артефакт универсальным. Classification не равна policy, policy не равна contract, contract не равен egress, egress не равен authorization. Они пересекаются только в том, что все относятся к одной передаче. М8-автор не предлагает «самую строгую» кнопку: он строит короткую цепочку, в которой каждое звено отвечает на свой вопрос и честно оставляет границу видимой.
Разложить решение на четыре оси
Data classification описывает содержимое локальным языком команды: public, internal, restricted, personal-data-shape или другой явно определённый class. Это вход в решение, а не вывод о поставщике. Policy задаёт допустимость: например, class может требовать отдельного review или прямо закрывать внешнюю передачу. Contract уточняет, какие обязательства проверены для выбранного service scope: retention, processing, training terms, region или subprocessor — ровно те, которые важны организации. Нельзя заменить неизвестное условие словом «корпоративный».
Technical egress отвечает уже на другой вопрос: есть ли путь к конкретному destination и соответствует ли он разрешённой конфигурации. Firewall allow-list, proxy rule, DNS policy или network segmentation полезны, но они работают с route и endpoint, а не со смыслом фрагмента. Human authorization отвечает на третий слой принятия решения: какой owner рассмотрел record, requester, destination и срок. Владелец не должен переопределять deny-class молча, а сеть не должна доказывать его полномочия.
Матрица доказательств: какой артефакт имеет какой scope
| Вопрос | Нужное evidence | Что может помочь | Чего этого недостаточно доказать |
|---|---|---|---|
| Какой class у record? | версионированная карточка и owner vocabulary | название папки или тега | допустимость внешней передачи |
| Допустим ли class? | policy decision и contract condition для service scope | DPA или UI setting как вход в review | фактический destination и применимость к конкретному plan |
| Куда может пойти трафик? | проверенный destination, route и egress control | firewall allow-list | что payload соответствует class или что contract покрывает usage |
| Кто разрешил передачу? | dated authorization с record, requester и scope | лицензия пользователя или одобрение продукта | права на другой record, срок или destination |
| Что делать при пробеле? | reason, citation, stop condition и owner question | общее «надо уточнить» | обход через другой account, device или tool |
Это не бюрократическая таблица ради таблицы. Она сокращает конфликт review. Когда security говорит «endpoint разрешён», а privacy отвечает «record не классифицирован», оба могут быть правы, просто отвечают на разные вопросы. Правильное действие — не голосовать, чей control сильнее, а сохранить два факта и закрыть egress до тех пор, пока policy/contract факт не появится. Так stop остаётся техническим решением о неполном evidence, а не личной оценкой осторожности коллеги.
Механизм fail-closed: сначала проверки, затем только hand-off
В P86 одинаково важны порядок и отрицательный результат. Модель сначала проверяет exact keys и canonical form request, потом вытаскивает только known fixed records. Далее она оценивает allowability и retention label, сравнивает egress scope, access label и датированную authorization. Нельзя начать с approval: иначе оно станет способом скрыть restricted class. Нельзя начать с network: иначе успешный route станет ложным доказательством допустимости.
const restricted = createFixedSyntheticContextRequest('restricted-class-stop');
const decision = assessSyntheticAiEgress(restricted);
const stop = stopSyntheticAiEgress(decision);
console.log(decision.classificationDecision);
// denied-by-fixed-class-or-allowability
console.log(decision.authorizationDecision);
// not-consulted-as-an-override
console.log(stop.egressPerformed);
// falseНизкий уровень реализации здесь нарочно скучный. Record ids, authorization и expected fields не принимаются «похожими». Лишний key, missing key, sparse array, cyclic value или forged authorization не получают частичный accept: fixture возвращает closed decision. Это защищает учебный пример от обычной ошибки автоматизации, когда сериализатор или удобный spread silently добавляет неоговорённую информацию. В production нужны другие controls, но fail-closed форма полезна уже до выбора tool.
Retentions и training terms — отдельная проверка, не магический label
Retention label в примере называется synthetic-contract-retention-reviewed. Он не утверждает, что какой-либо vendor реально не хранит prompt, не обучается на нём или не передаёт его subprocessors. Он говорит гораздо уже: для одной synthetic карточки в учебной модели существует проверяемое условие, без которого hand-off закрыт. В реальной работе label должен ссылаться на документ и версию, applicable plan, region, accounts, features и исключения. Если термины меняются, изменяется не только ссылка, но и вывод.
Именно здесь полезна дисциплина immutable sources. GitHub Docs на закреплённом commit фиксирует, что конкретная chat surface может сочетать user input с дополнительным context и при включённом Bing отправлять сформированный query в Bing Search API. Это не доказывает retention или training для вашего продукта, но помогает задать правильный вопрос: какой контекст собирает именно этот surface и есть ли дополнительные outbound paths? Необходимо проверять не только marketing page, а технический режим, который включён команде.
Egress control и zero trust: полезный, но ограниченный слой
GitHub SKU isolation описывает plan-specific endpoint и firewall allow/block list. Такой control может снизить риск того, что сотрудник в корпоративной сети использует не тот subscription path. Но данные не приобретают класс в момент TLS connection. Поэтому в таблице egress gate идёт после class и contract, а не вместо них. Если proxy разрешил host, остаются вопросы: какой feature включён, какой context он добавляет, соответствует ли record нужному scope и есть ли human authorization на этот date.
NIST SP 800-207 формулирует эту мысль шире: network location сама по себе не даёт implicit trust, а access к resource опирается на policy и отдельные authentication/authorization functions. В этой статье AI-инструмент не объявляется enterprise resource из NIST и не переносится схема стандарта один к одному. Важен принцип разделения: факт «путь существует» не отвечает на вопрос «данный субъект вправе передать данный record по этому пути».
Порядок review, который можно повторить
- Соберите одну строку identity. Record id, version, class и owner должны быть видны до обсуждения prompt.
- Спросите policy/contract question. Какое условие допустимости и retention/training evidence нужно именно для этой surface, plan и destination?
- Спросите egress question. Какая техническая граница разрешена и кто подтвердил её применимость, не подменяя этим class?
- Спросите authority question. Кого достаточно для решения, какой requester и date покрыты, а какие нет?
- Сделайте один outcome. Hand-off в отдельный authorised workflow или safe stop с reason, citation и следующим владельцем. Не делайте send в ходе review.
Ограничения и следующий проверяемый шаг
Ни матрица, ни fixture не являются privacy impact assessment, договором или архитектурой DLP. Они не обнаруживают PII, не проверяют endpoint, не читают logs, не знают region, не вызывают model и не оценивают legal basis. В фиксированных strings намеренно нет customer data, secret, исходного кода, реального тикета или telemetry. Поэтому положительный synthetic outcome нельзя превращать в разрешение на любой настоящий prompt, а отрицательный нельзя использовать как общий запрет на технологию.
Следующий шаг: для одного включённого AI feature создайте four-column evidence sheet: class/owner, policy+contract, egress, authorization. В каждой колонке оставьте URL или immutable reference, date и boundary: что этот факт не доказывает. Затем возьмите один известный gap и проверьте, что система безопасно останавливается без доступа к payload. Результат должен быть короче policy memo, но достаточен, чтобы другой reviewer повторил вопрос.
Историческая граница апреля 2025
Пакет опирается на GitHub Docs commit от 30 апреля 2025 и на финальные NIST публикации 2020 и 2023. Он не предполагает, что поведение, storage, model routing или product terms позднее не изменятся. При реальном внедрении документация поставщика, договор и конфигурация проверяются заново на дату решения; эта статья показывает форму проверки, а не переносимый verdict.
Проверяемые источники
- GitHub Docs: Responsible use of GitHub Copilot Chat in GitHub (immutable GitHub Docs commit 0d17a12af77011b390abd8aea9e8626e153e0522, 30 April 2025) — На закреплённой ревизии GitHub описывает, что prompt предварительно обрабатывается и сочетается с контекстом; модель может получать дополнительный repository context, а при включённом Bing query строится из prompt и доступного context и передаётся Bing Search API. Ограничение: Это описание конкретной поверхности Copilot Chat на указанной ревизии. Оно не устанавливает класс данных, срок retention, обучение модели, договор конкретной организации или разрешение сотруднику передавать фрагмент.
- GitHub Docs reusable: Copilot SKU isolation (immutable GitHub Docs commit 0d17a12af77011b390abd8aea9e8626e153e0522, 30 April 2025) — Документ описывает, что firewall allow-list плановых endpoint может разрешать Business или Enterprise endpoint и block-list может запрещать Individual endpoint внутри корпоративной сети. Ограничение: SKU isolation относится к маршрутизации и выбору plan endpoint. Он не показывает payload, не проверяет data class, не подтверждает retention или training terms и не заменяет human authorization.
- NIST SP 800-207: Zero Trust Architecture (NIST SP 800-207, final publication 11 August 2020) — NIST не считает network location основанием для неявного доверия и описывает authentication и authorization как отдельные функции перед доступом к enterprise resource; доступ определяется policy для конкретного resource. Ограничение: Публикация не даёт vendor DPA, список AI endpoint, схему классификации или доказательство того, что конкретный внешний сервис не хранит и не использует переданные данные.
- NIST AI 100-1: Artificial Intelligence Risk Management Framework 1.0 (NIST AI 100-1, January 2023 final PDF) — AI RMF организует управление риском вокруг GOVERN, MAP, MEASURE и MANAGE и рассматривает privacy вместе с организационными и техническими практиками, а не как одну настройку продукта. Ограничение: AI RMF — добровольная рамка управления риском. Она не создаёт юридический вывод, не классифицирует запись за команду и не заменяет договор, техническое измерение egress или полномочия владельца.