Во время разбора ошибки инженеру хочется показать AI-инструменту «всего один лог и один тикет»: так легче получить гипотезу о причине. Но если у фрагмента нет class, нельзя сказать, допустим ли сам вопрос, а не только удобен ли ответ. Цена ошибки — потеря control над цепочкой: в следующем review никто не отличит разрешённый public example от restricted event shape, не увидит destination и не сможет доказать, что approval действовал в тот момент.
В этом кейсе нет настоящего лога, клиента, идентификатора, секретного значения, файла или сетевого запроса. Есть только fixed synthetic records с нарочно скучными placeholder. Это важно: пример учит остановить передачу до egress, а не демонстрирует «безопасный способ» отправить production context. Симптом — кто-то хочет дать ассистенту debugging material. Причина — четыре решения слились в просьбу «разрешите prompt». Проверка и действие разложены дальше по шагам.
Case 1. Class звучит как «log», но decision зависит от содержимого и rule
Первый record называется synthetic-restricted-log-shape-v1. Его payload не содержит события: это строка с symbolic labels actor=[symbolic label], token=[not-present] и request=[not-present]. Всё равно record получает class synthetic-restricted, allowability deny-external-egress и retention label synthetic-no-external-retention. Название «shape» не пытается спрятать риск; наоборот, заставляет review решить, нужен ли реальный schema owner до обсуждения материала.
Симптом: «мы же удалили значения, значит фрагмент можно передать». Причина: redaction, class и contract — разные операции. Проверка: спросить, кто утвердил class именно после преобразования, что осталось в structure, какие условия обработки применимы и есть ли evidence для конкретного tool surface. Действие: если class или allowability не доказаны, хранить фрагмент локально и открыть owner question. Нельзя поднять deny-class тем, что reviewer уверен в хороших намерениях автора.
Case 2. Egress gate закрыт даже при знакомом продукте
В model egressScope — символическая строка fixed-external-ai-boundary-alpha. Она не является hostname, proxy configuration или реальным endpoint. Её задача — показать правило сопоставления: record, request и authorization должны назвать один scope. Если request просит fixed-unapproved-egress-scope, decision закрывается до проверки human authorization. Это предотвращает подмену «у человека есть approval» на «он может выбрать любой путь».
Симптом: команда знает, что продукт закуплен, и поэтому считает любой его UI одинаковой границей. Причина: plan, surface, подключённый search, extension и route могут иметь разный context flow. Проверка: выписать destination как отдельную сущность и найти техническое evidence для этого режима. Действие: если destination не совпал с record scope, вернуть safe stop с reason и citation. Не искать удобный альтернативный account или device: он меняет путь, но не закрывает policy gap.
Case 3. Authorization имеет scope, access и expiry
В положительном fixed case approval принадлежит роли synthetic-data-steward, покрывает только synthetic-public-interface-summary-v1, только fixed-external-ai-boundary-alpha, requester label synthetic-engineering-read и заканчивается 20 апреля 2025. Он не покрывает restricted log shape и не действует после срока. Такая точность может казаться излишней для одного фрагмента, но без неё authorization становится переносимой печатью «можно AI».
Симптом: у человека есть старое одобрение, но никто не сверил requester и date. Причина: approval считают свойством tool или команды, а не решением для конкретного resource. Проверка: сопоставить record ids, destination, requester labels, issuer role, validFrom и expiresAt. Действие: при любом mismatch model возвращает safe stop; новый owner должен принять новое решение на свежем evidence. Не изменяйте expiry в старой карточке задним числом: это убирает историю, которая нужна следующему reviewer.
| Шаг | Наблюдение | Decision в модели | Следующее действие |
|---|---|---|---|
| Class | log-shape имеет synthetic-restricted и deny-external-egress | classification denied | не передавать payload; спросить owner о допустимой учебной замене |
| Contract | retention label — synthetic-no-external-retention | contract not accepted | не выводить условия vendor по аналогии с другим plan |
| Egress | scope request не совпадает с record | gate closed | уточнить destination/route у network и service owner |
| Access | requester не имеет required label | authorization mismatch | проверить право на record без расширения scope в prompt |
| Expiry | approval закончился до requestedAt | safe stop | запросить новое dated решение или отказаться от передачи |
Воспроизводимый negative path без внешнего контекста
В коде ниже case уже содержит fixed record id и fixed authorization. Он не читает лог, не строит prompt и не делает HTTP call. Именно поэтому его можно запускать как fixture: мы проверяем, что denied class закрывается до approval override, а safe stop не выдаёт payload. В настоящей системе этот пример не заменяет data inventory или access control; он даёт небольшой контракт для теста: если доказательства нет, функция не открывает путь.
const request = createFixedSyntheticContextRequest('restricted-class-stop');
const decision = assessSyntheticAiEgress(request);
const stop = stopSyntheticAiEgress(decision);
console.log(decision.accepted); // false
console.log(decision.classificationDecision); // denied-by-fixed-class-or-allowability
console.log(decision.nextAction); // owner question, no payload copy
console.log(stop.effect); // no-system-changeFixture добавляет более жёсткие границы, чем happy path. Extra key и missing key не проходят exact contract. Forged authorization и расширенный scope не совпадают с fixed request proof. Sparse array и cyclic value не становятся «пустым списком», а закрываются без исключения. Отдельные cases проверяют requester access, authorization expiry и wrong egress scope. Это не антифрод и не DLP; это проверка, что сам учебный gate не переходит от отсутствующих фактов к неявному разрешению.
Как оформить human review без ложного юридического вывода
Вопрос владельцу должен быть конкретнее, чем «можно ли использовать AI?». Например: «для record class X, surface Y и destination Z: какое allowability rule действует, каким immutable document подтверждается retention/training condition?»
В том же вопросе нужно назвать authority, requester и expiry. Такая формулировка не утверждает, что DPA сам по себе разрешает передачу или что UI setting гарантирует место обработки. Она просит evidence, по которому организация вправе сделать собственный вывод.
Полезно разделить роли. Data owner подтверждает class и преобразование. Service or legal owner сопоставляет policy/contract с выбранной surface. Network owner подтверждает path и egress control. Security or privacy owner проверяет access and authorization process. Один человек может совмещать роли в небольшой компании, но в review всё равно стоит записать, какой вопрос он закрыл. Это снижает риск «одобрения вообще» и позволяет вернуть только спорный слой на доработку.
Что дают источники, а чего они не дают
GitHub Docs на commit 30 апреля 2025 говорит, что в конкретной Copilot Chat surface prompt может обрабатываться вместе с context, а Bing search при включении отправляет сформированный query в Bing Search API. Это поддерживает постановку вопроса о расширенном context и отдельной внешней границе. Документ SKU isolation показывает пример endpoint-level firewall control. Он не описывает class конкретного лога, не подтверждает retention или training terms организации и не назначает человека, который может выдать approval.
NIST SP 800-207 поддерживает принцип явного, policy-based access вместо доверия к network location; NIST AI RMF помещает privacy и governance в постоянное управление риском. Оба источника не являются DPA, конфигурацией proxy или локальным classification policy. Поэтому они не используются для вывода «можно передавать». Их роль — удержать структуру решения: resource, scope, control, authority и documented risk должны быть видны раздельно.
Короткая последовательность для реального review
- Остановите копирование. Сначала назовите record и class, не открывая AI surface и не отправляя сокращённый «пример».
- Проверьте допускаемость. Сведите policy и contract evidence к выбранным plan, feature, destination и сроку, а не к бренду поставщика.
- Сверьте путь. Отдельно подтвердите egress scope и технический control; он должен совпасть с карточкой, а не просто существовать в сети.
- Сверьте людей и дату. Requester access, authority role, record ids и expiry должны относиться к одной операции.
- Выпустите outcome. Либо передайте evidence в authorised workflow, либо зафиксируйте safe stop без payload и назначьте следующего владельца вопроса.
Ограничения и следующий проверяемый шаг
Этот field case — полностью synthetic. Его text не содержит настоящего production log, source code, тикета, PII, secret, customer identifier, file path или network address. Скрипт не обращается к filesystem, Git, CI, network, telemetry, clock, AI model или production. A positive decision не отправляет даже synthetic string: egressPerformed всегда false, а stop object имеет effect no-system-change.
Следующий шаг: проведите tabletop review на пустой карточке одного реального use case. Пусть четыре владельца независимо заполнят class, policy/contract evidence, egress scope и authorization scope, не прикладывая payload. Затем внесите один deliberate gap: например, истёкший approval или неизвестный destination. Если процесс не может назвать reason, citation и next owner без копирования данных, сначала улучшите контур review, а уже потом подключайте инструмент к рабочему контексту.
Историческая граница апреля 2025
Все внешние утверждения ограничены immutable GitHub Docs commit от 30 апреля 2025 и финальными NIST документами 2020/2023. Нет предположений о функциях, contract terms, data routing или гарантиях, появившихся позднее. Перед фактическим use case необходимо повторить проверку обычным HTTPS GET для своих документов и зафиксировать актуальные scope, date и exceptions.
Проверяемые источники
- 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 или полномочия владельца.