{
  "index": 99,
  "slug": "editorial-2025-04-practice-ai-data-privacy",
  "title": "Перед AI-инструментом данные должны пройти четыре независимые проверки",
  "excerpt": "Как не отправить код, лог или тикет за пределы компании по ошибке: разделяем класс данных, условия сервиса, сетевой маршрут и полномочия человека.",
  "contentHtml": "<p>Инженер копирует в AI-инструмент десять строк лога, чтобы быстрее найти причину ошибки. В строках оказываются email, внутренний идентификатор и часть заголовка запроса. Интерфейс принимает текст. Ответ выглядит полезным. Через неделю никто не может точно сказать, какой контекст ушёл, к какому режиму сервиса он относился и кто разрешил передачу. Симптом проявился как удобная подсказка, а цена ошибки — потеря контроля над данными и дорогое расследование без исходного payload.</p>\n<p>Проблема не решается одной настройкой «корпоративный тариф» или запретом на секреты в prompt. Передача должна пройти четыре независимые проверки: что находится во фрагменте, допускает ли policy и договор такую обработку, куда технически пойдёт запрос и кто разрешил именно этот объём данных. Если один вопрос подменяет остальные, команда получает ложное зелёное состояние.</p>\n<h2>Тезис: класс данных не равен разрешению</h2>\n<p>Класс описывает содержимое. Например, <code>public</code>, <code>internal</code> или <code>restricted</code>. Он не говорит, можно ли передавать запись внешнему сервису. Это решает policy с учётом договора, режима хранения, обучения, региона и выбранного endpoint. Даже если policy разрешает класс, сеть должна вести запрос в нужное место, а сотрудник должен иметь право передать конкретный record.</p>\n<p>Разделяйте эти факты в карточке контекста. Запишите идентификатор и версию записи, класс, основание допустимости, проверенное условие сервиса, символическое имя назначения, requester, владельца и срок разрешения. Не заполняйте неизвестное значение словом «внутреннее». Не переносите approval с соседнего файла. При неполном evidence путь закрывается.</p>\n<figure><img src=\"/assets/editorial/2025/ai-data-privacy-2025-context-boundary.svg\" alt=\"Пять границ перед передачей контекста AI-инструменту: класс данных, допустимость сервиса, технический egress, полномочия человека и безопасная передача вопроса без внешнего запроса.\" loading=\"lazy\" /><figcaption>Передача допускается только после независимой проверки содержимого, условий сервиса, маршрута и полномочий. Отсутствие одного доказательства ведёт к остановке.</figcaption></figure>\n<h2>Как возникает утечка контекста</h2>\n<p>Пользователь видит поле prompt, но поставщик может обрабатывать его вместе с контекстом продукта. Это может быть открытый файл, история диалога, выбранный репозиторий или дополнительный поиск. Поэтому проверяйте не только видимый текст, но и конкретную поверхность, включённые функции и endpoint. Такой анализ относится к режиму продукта, а не ко всем AI-инструментам сразу.</p>\n<p>Сетевое правило отвечает на узкий вопрос: может ли трафик достичь назначения. Allow-list не классифицирует payload. DPA или другая договорённость описывает обязательства, но не доказывает, что firewall отправил запрос только в нужный endpoint. Разрешение владельца показывает полномочия, но не меняет класс записи и не продлевает истёкший срок. Каждый контроль должен иметь собственную проверку.</p>\n<h2>Учебный пример: решение без внешнего запроса</h2>\n<p>Ниже приведён учебный JavaScript-пример. Он работает только с заранее заданными объектами в памяти. Он не вызывает модель, не читает файл, не отправляет лог и не утверждает ничего о production. Его задача — показать порядок проверок и отрицательный путь.</p>\n<pre><code>const context = {\n  id: 'example-17',\n  version: 3,\n  dataClass: 'synthetic-public',\n  serviceCondition: 'synthetic-retention-reviewed',\n  egressScope: 'fixed-ai-boundary-alpha',\n  requester: 'alice',\n  access: 'synthetic-read',\n  authority: { owner: 'data-steward', scope: 'example-17', expires: '2026-12-31' }\n};\n\nfunction decide(record, policy, route, today) {\n  const checks = [\n    record.dataClass === policy.allowedClass,\n    record.serviceCondition === policy.requiredCondition,\n    record.egressScope === route.allowedScope,\n    record.access === 'synthetic-read',\n    record.authority.scope === record.id,\n    record.authority.expires &gt;= today\n  ];\n\n  return checks.every(Boolean)\n    ? { status: 'review-ready', egressPerformed: false }\n    : { status: 'stop', egressPerformed: false };\n}\n\nconst result = decide(\n  context,\n  { allowedClass: 'synthetic-public', requiredCondition: 'synthetic-retention-reviewed' },\n  { allowedScope: 'fixed-ai-boundary-alpha' },\n  '2026-08-02'\n);</code></pre>\n<p>Статус <code>review-ready</code> не означает, что запрос отправлен или что поставщик гарантирует нужный режим. Он означает только: фиксированная карточка прошла локальные проверки и может перейти к полномочному решению. Если изменить <code>egressScope</code>, срок или <code>serviceCondition</code>, функция возвращает <code>stop</code>. В реальной системе нужны собственные справочники, журнал решения и проверка фактического маршрута.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика передачи контекста</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>В prompt попал production-лог</td><td>Класс записи не определён до копирования</td><td>Найти record и назначение класса у владельца данных</td><td>Остановить передачу, удалить локальную копию из рабочего контекста, запросить классификацию</td></tr><tr><td>Есть DPA, но неизвестен endpoint</td><td>Договор приняли за доказательство маршрута</td><td>Сверить plan, endpoint, proxy и сетевой журнал</td><td>Разрешать только явно названное назначение; иначе закрыть egress</td></tr><tr><td>Firewall пропускает запрос</td><td>Технический доступ приняли за допустимость payload</td><td>Сопоставить destination с policy и классом записи</td><td>Оставить сеть, но запретить payload до решения владельца</td></tr><tr><td>Approval есть в чате</td><td>Нет scope, срока или версии record</td><td>Проверить requester, record id, version, destination и expiry</td><td>Получить датированное разрешение; старое общее «можно» не переносить</td></tr><tr><td>Ответ модели содержит лишний контекст</td><td>Включён repository context, история или поиск</td><td>Проверить настройки конкретного режима и фактический запрос</td><td>Отключить дополнительный контекст или выбрать режим с проверенным scope</td></tr></tbody></table></div>\n<h2>Порядок pre-flight проверки</h2>\n<ol><li><strong>Назовите запись.</strong> Зафиксируйте record id, версию, источник и владельца до открытия внешнего инструмента.</li><li><strong>Классифицируйте содержимое.</strong> Отделите публичное описание от персональных данных, секретов, клиентского кода и внутренних деталей. Не угадывайте класс по имени файла.</li><li><strong>Проверьте policy и договор.</strong> Найдите условие для выбранного сервиса и режима: хранение, обучение, регион, субподрядчик и срок. Если условие относится к другому плану, оно не подходит.</li><li><strong>Проверьте маршрут.</strong> Укажите разрешённый endpoint, proxy и правило egress. Наличие соединения не является разрешением на данные.</li><li><strong>Сверьте полномочия.</strong> Requester должен иметь доступ к записи. Владелец должен разрешить именно этот scope, destination и срок.</li><li><strong>Проверьте дополнительные источники контекста.</strong> Уточните, не добавляет ли режим историю, файлы репозитория, поиск или другие поля запроса.</li><li><strong>Оставьте отрицательный путь.</strong> При неизвестном поле не маскируйте данные и не переходите в другой аккаунт или интерфейс. Запишите вопрос, владельца и условие возобновления.</li></ol>\n<h2>Что нельзя считать доказательством</h2>\n<p>Название инструмента, значок щита, корпоративная почта и доступ к приложению не доказывают допустимость конкретного payload. Слово «анонимизированный» тоже недостаточно: нужно знать, какие поля удалены, можно ли восстановить субъекта и кто проверил преобразование. Маскирование email не очищает токен в заголовке или идентификатор в URL.</p>\n<p>Не смешивайте учебную карточку с реальной политикой. В примере используются значения с префиксом <code>synthetic-</code>; они не описывают вашу систему, vendor contract или фактическое хранение. Пример показывает форму fail-closed решения. Он не даёт production-результата и не заменяет legal, security или data-owner review.</p>\n<h2>Ограничения и критерий готовности</h2>\n<p>Подход не отвечает за правильность самой классификации. Он делает неизвестность видимой. Если каталог данных устарел, approval выдан не тому владельцу или сетевой журнал неполон, проверка должна остановиться. Она также не доказывает, что ответ модели верен, что поставщик не изменит условия или что будущая функция инструмента сохранит прежний маршрут.</p>\n<p>Материал готов к применению в конкретной команде, когда для одного реального типа контекста можно предъявить четыре связанные записи: версионированный class, policy/contract condition для выбранного режима, проверенный egress и датированное scoped authorization. Отрицательный тест должен показать stop при истёкшем сроке, чужом scope или неизвестном endpoint. После этого команда может передавать только разрешённый минимальный фрагмент и восстановить, почему решение было принято.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://github.com/github/docs/blob/0d17a12af77011b390abd8aea9e8626e153e0522/content/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-chat-in-github.md\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Responsible use of GitHub Copilot Chat in GitHub</a> — официальное описание конкретной поверхности и возможного дополнительного контекста. Документ не определяет класс ваших данных, договор, retention или полномочия сотрудника.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/207/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-207: Zero Trust Architecture</a> — официальная архитектурная публикация о проверке аутентификации и авторизации для конкретного ресурса. Она не является DPA и не подтверждает маршрут конкретного AI-сервиса.</li><li><a href=\"https://csrc.nist.gov/pubs/ai/100/1/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST AI 100-1: Artificial Intelligence Risk Management Framework 1.0</a> — официальная рамка управления рисками AI. Она помогает разделять управление, mapping, measurement и management, но не классифицирует конкретную запись за команду.</li></ul>"
}