Фрагмент кода, лога или тикета часто выглядит безобидно, пока его не нужно вставить в AI-инструмент. Но у фрагмента уже есть происхождение, класс, владелец и возможные получатели контекста. Симптом — инженер видит полезный вопрос и отправляет «маленький кусок», не зная, что к prompt может добавиться контекст продукта или поиска. Цена ошибки — не абстрактная приватность: команда теряет возможность объяснить, что именно ушло за границу, кто это разрешил и какой договорный режим должен был работать.
Причина обычно в смешении четырёх разных решений. Data classification отвечает, что представляет запись. Policy и contract отвечают, допускается ли такой класс и при каких retention или training conditions. Технический egress отвечает, куда может пойти трафик. Human authorization отвечает, кто разрешил именно этот scope и на какой срок. Если заменить все четыре вопроса одним «у нас есть DPA» или «в интерфейсе выключена галочка», следующее расследование начнётся без исходных доказательств.
Передавать не текст, а описанную единицу контекста
Первый рабочий шаг — не редактировать prompt на глаз, а присвоить фрагменту versioned record. В нём нужны хотя бы record id, version, class, allowability, retention label, egress scope, required authority, access label, expiry и citation. Это не универсальная схема для права или закупки. Это инженерная карточка, благодаря которой человек может проверить ровно один фрагмент, а не спорить о слове «внутренний». Если значения неизвестны, карточка должна останавливаться, а не получать наиболее оптимистичный label.
Class — это не разрешение. Запись с class synthetic-public в учебной модели всё равно требует policy/contract label и отдельного разрешения владельца. И наоборот, даже корректный человек не получает права поднять synthetic-restricted до допустимого класса одной подписью. Такое разделение неприятно в первый день, потому что прибавляет несколько полей. Зато на следующем review не приходится угадывать, относим ли мы обсуждение к содержимому, маршруту или полномочиям.
Минимальная карточка: какие поля отвечают на какие вопросы
| Поле | Проверяемый вопрос | Пример label | Чего поле не доказывает |
|---|---|---|---|
| dataClass | Какой локальный класс у содержимого? | synthetic-public или synthetic-restricted | условия vendor contract и сетевой маршрут |
| allowability | Можно ли вообще рассматривать egress? | allow-after-human-authorization | что разрешение уже выдано конкретному requester |
| retentionLabel | Есть ли проверенное условие хранения/обучения для нужного scope? | synthetic-contract-retention-reviewed | фактический payload, endpoint или будущую версию сервиса |
| egressScope | Какой symbolic destination разрешён карточке? | fixed-external-ai-boundary-alpha | что firewall действительно пропустил данные или что payload безопасен |
| authorityRequired и expiry | Кто и до какой даты вправе одобрить hand-off? | synthetic-data-steward до 20 апреля | права всех будущих пользователей или другой record |
| citation | На какую карточку и решение можно сослаться? | synthetic://p86/… | доказательство реальной политики вне учебной модели |
В реальном процессе поля могут жить в каталоге данных, тикете, policy-as-code или системе заявок. Место не важно для этой статьи; важна связь. Если class записан в одном месте, contract в другом, egress в третьем, а approval лежит в личной переписке, review не может собрать их в один проверяемый chain. Тогда короткий prompt экономит минуту, но создаёт дорогой вопрос «почему мы решили, что это допустимо?».
Воспроизводимый пример: только фиксированные записи в памяти
Ниже не показан запрос к модели и не передаётся даже синтетический payload. Скрипт создаёт заранее заданную карточку, проверяет равенство class, contract label, egress scope и dated authorization, а затем возвращает decision. Даже положительный outcome заканчивается на hand-off: поле egressPerformed остаётся false. Такая форма полезна для обучения review, потому что нельзя случайно выдать пример за интеграцию.
import {
createFixedSyntheticContextRequest,
assessSyntheticAiEgress,
stopSyntheticAiEgress,
} from './upgrade-2025-04.mjs';
const request = createFixedSyntheticContextRequest('authorized-public-summary');
const decision = assessSyntheticAiEgress(request);
const boundaryStop = stopSyntheticAiEgress(decision);
console.log(decision.accepted); // true: fixed hand-off only
console.log(decision.egressPerformed); // false
console.log(boundaryStop.stopped); // true: no external request existsУ модели есть и отрицательные cases: internal record без settled contract label, restricted log shape, requester без нужного access label, expired authorization и другой egress scope. Каждый возвращает reason, citation, stop condition и next action. Важна формулировка stop: «на этом evidence нельзя открыть путь», а не «данные навсегда запрещены». Внешний мир может содержать дополнительные договоры и технические меры; эта модель просто не имеет права их придумывать.
Как проводить короткий pre-flight review
- Назовите единицу. Запишите record id, version и class до того, как копировать фрагмент в prompt или подключать инструмент к репозиторию.
- Разведите policy и contract. Сверьте allowability с нужным retention/training condition для данного service scope; не переносите вывод с другого plan или старой версии.
- Проверьте egress отдельно. Сопоставьте destination, route и технический allow-list. Наличие сети или лицензии не делает payload допустимым.
- Сверьте access и authority. Requester должен иметь доступ к record, а владелец — выдать scoped, dated решение. Approval без scope не переносится на соседний фрагмент.
- Запишите safe stop. Если один факт неизвестен, оставьте payload локально, укажите owner question и не ищите обход через другой UI или account.
Почему интерфейс и договор не закрывают весь маршрут
Фиксированный GitHub Docs на апрель 2025 показывает полезную инженерную деталь: prompt может обрабатываться вместе с контекстом, а отдельные возможности могут собирать repository context или сформировать Bing query при включённом поиске. Это не утверждение о каждом AI-инструменте. Оно показывает, почему проверять только видимый кусок текста недостаточно: нужно знать, какая поверхность и какие дополнительные источники контекста включены в данном режиме.
Другой GitHub документ описывает SKU isolation через plan-specific endpoint в firewall. Это хороший пример технического control: он может ограничить, какой plan endpoint используют люди в сети. Но он не видит data class, не сравнивает условие retention, не проверяет, что человек вправе раскрыть record, и не заменяет решение владельца. NIST SP 800-207 так же отделяет policy-based access от одного лишь network location. В статье это не юридическая консультация, а причина не считать один control доказательством всех остальных.
Ограничения и следующий проверяемый шаг
Весь пример — versioned fixed synthetic JavaScript literals в памяти. Здесь нет customer code, PII, secret, реального лога, тикета, файла, Git, CI, telemetry, сети, clock, model call или production side effect. Labels synthetic-public, synthetic-restricted и synthetic-contract-retention-reviewed не описывают ни одну вашу систему и не доказывают фактическое хранение или обучение у поставщика. Они нужны только для проверки формы решения и fail-closed пути.
Следующий шаг: возьмите один тип контекста, который команда реально хочет использовать с AI, но не копируйте его в шаблон. Сначала создайте пустую карточку с class, allowability, contract/retention evidence, egress scope, owner, expiry и citation. Если хотя бы одно поле нельзя честно заполнить, результат review уже полезен: это safe stop и конкретный вопрос к data, security, legal или service owner.
Историческая граница апреля 2025
Здесь используются только источники, существовавшие к 30 апреля 2025: два immutable GitHub Docs commit, NIST SP 800-207 final 2020 и NIST AI RMF 1.0 final 2023. В текст не перенесены поздние model names, provider terms или функции агентов. Любая будущая проверка должна заново закрепить версию документа и применимость к своему plan, region, contract и маршруту.
Проверяемые источники
- 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 или полномочия владельца.