{
  "index": 97,
  "slug": "editorial-2025-04-field-ai-data-privacy",
  "title": "Перед AI-инструментом данные должны пройти четыре проверки",
  "excerpt": "Почему удаление имён из лога не делает контекст безопасным: разбираем классификацию, договорные условия, маршрут передачи и полномочия на конкретный фрагмент.",
  "contentHtml": "<p>Инженер копирует в AI-чат фрагмент ошибки, удаляет имя пользователя и ждёт подсказку. Симптом исчезает из текста, но риск остаётся. В логе могут сохраниться время операции, редкий тип события, идентификатор запроса, структура платежа или сочетание полей, по которому запись узнают. Если сервис добавляет к prompt историю диалога, файлы проекта или поиск, наружу уходит не только выделенная строка.</p>\n<p>Цена ошибки складывается из нескольких частей. Команда теряет контроль над копией данных. Нельзя быстро доказать, куда она попала и как долго хранилась. Нельзя уверенно ответить на запрос владельца данных. В худшем случае один удобный ответ превращается в инцидент, расследование и остановку инструмента для всей команды.</p>\n<h2>Тезис</h2>\n<p>Безопасный AI-review начинается не с маскирования и не с выбора модели. Сначала нужно доказать, что конкретный фрагмент можно передать конкретной поверхности по конкретному маршруту. Для этого разделите четыре решения: какой класс у данных, какие условия обработки действуют, куда пойдёт запрос и кто имеет право его отправить. Если хотя бы один факт неизвестен, путь должен закрыться.</p>\n<p>Эта граница важнее названия продукта. Один vendor может иметь несколько поверхностей: веб-чат, расширение редактора, API, поиск и агент с доступом к репозиторию. Они могут собирать разный контекст и использовать разные настройки хранения. Одобрение «AI разрешён» не покрывает автоматически каждый экран и каждый тип записи.</p>\n<h2>Как возникает ошибка</h2>\n<p>Входной фрагмент обычно рассматривают как строку. Система должна рассматривать его как объект с контекстом: <code>recordId</code>, версией, владельцем, классом, целью, destination и сроком действия разрешения. Redaction меняет содержимое. Он не назначает класс и не подтверждает договорные условия. Поле, заменённое на <code>[redacted]</code>, всё ещё может быть чувствительным по структуре.</p>\n<p>Следующий слой — маршрут. Запрос может пройти через прокси, региональный endpoint, подключённый поиск, плагин или сервис-посредник. Успешное TLS-соединение доказывает только доступность канала. Оно не доказывает, что выбранный destination разрешён для этого класса данных. Так же firewall allow-list не превращает restricted record в public.</p>\n<p>Последний слой — полномочия. Разрешение относится к ресурсу, цели, requester и сроку. Старое согласование для синтетического примера не даёт права отправить production-лог. Доступ к инструменту не равен праву передавать ему все доступные пользователю данные.</p>\n<h2>Учебный пример: запрос, который обязан остановиться</h2>\n<p>Ниже приведён синтетический пример. Он не читает лог, не содержит PII, секретов, клиентских идентификаторов и настоящего endpoint. Названия намеренно фиксированы. Цель примера — показать отрицательный путь: при restricted-классе функция закрывает передачу до проверки разрешения. Это не готовая DLP-система и не доказательство безопасности какого-либо AI-сервиса.</p>\n<pre><code>const request = {\n  recordId: 'synthetic-log-shape-v1',\n  dataClass: 'restricted',\n  allowExternalEgress: false,\n  destination: 'fixed-external-ai-boundary-alpha',\n  requester: 'synthetic-engineering-read',\n  expiresAt: '2025-04-20T00:00:00Z'\n};\n\nfunction decide(request, now) {\n  if (request.dataClass === 'restricted') {\n    return { decision: 'stop', reason: 'class-denies-external-egress' };\n  }\n\n  if (!request.allowExternalEgress) {\n    return { decision: 'stop', reason: 'contract-not-proven' };\n  }\n\n  if (new Date(request.expiresAt) &lt;= now) {\n    return { decision: 'stop', reason: 'authorization-expired' };\n  }\n\n  return { decision: 'hand-off' };\n}\n\nconst result = decide(request, new Date('2025-04-19T12:00:00Z'));\n// { decision: 'stop', reason: 'class-denies-external-egress' }</code></pre>\n<p>Порядок проверок здесь принципиален. Сначала система видит запрет класса. Она не использует наличие пользователя или действующий срок как override. Если заменить класс на допустимый, нужно всё равно проверить условия хранения, destination, requester и дату. Положительный результат в таком fixture означает только, что фиксированные входы соответствуют фиксированным правилам учебной модели.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика передачи контекста в AI-инструмент</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>«Мы удалили имена, значит всё можно»</td><td>Redaction перепутали с классификацией</td><td>Проверить остаточную структуру, owner и правило класса</td><td>Остановить передачу до решения владельца данных</td></tr><tr><td>«Продукт уже разрешён»</td><td>Surface, plan или route отличаются</td><td>Зафиксировать фактический destination и дополнительные источники context</td><td>Сверить конкретный маршрут с policy и договором</td></tr><tr><td>«Сеть пропускает endpoint»</td><td>Технический egress приняли за право на данные</td><td>Сопоставить data class, destination и условия обработки</td><td>Не отправлять payload при любом несовпадении</td></tr><tr><td>«Есть approval от команды»</td><td>Разрешение не имеет scope или истекло</td><td>Проверить record, requester, цель, issuer и expiresAt</td><td>Запросить новое датированное решение или выбрать локальный путь</td></tr><tr><td>«Ассистент ответил, значит утечки нет»</td><td>Проверили output, но не весь outbound path</td><td>Проверить request, журналы, включённые интеграции и retention terms</td><td>Считать результат недоказанным до проверки маршрута</td></tr></tbody></table></div>\n<h2>Граница передачи</h2>\n<figure><img src=\"/assets/editorial/2025/ai-data-privacy-2025-egress-review.svg\" alt=\"Схема проверки передачи: класс данных, условия обработки, маршрут, полномочия и решение; любое несовпадение ведёт в остановку без внешней отправки\" loading=\"lazy\" /><figcaption>Учебная схема показывает порядок вопросов. Она не изображает реальный сетевой trace и не подтверждает настройки конкретного поставщика.</figcaption></figure>\n<p>На схеме нет шага «попросить модель оценить риск». Модель может помочь сформулировать вопрос, но не должна сама становиться источником разрешения на доступ к данным. Сначала работает детерминированный gate. Он возвращает один из двух исходов: hand-off в заранее разрешённый workflow или stop с причиной и владельцем следующего решения.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Зафиксируйте объект.</strong> Запишите record ID, версию, владельца и минимально необходимую цель. Не вставляйте исходный payload в заявку на согласование.</li><li><strong>Назначьте класс.</strong> Проверьте, какое правило относится к данным после всех преобразований. Если class неизвестен, считайте его неизвестным, а не public.</li><li><strong>Проверьте условия обработки.</strong> Найдите документ, версию, plan, регион, retention, training terms и подключённые функции для этой поверхности. Не переносите вывод с другого продукта или аккаунта.</li><li><strong>Опишите маршрут.</strong> Укажите endpoint или сервис, прокси, поиск, расширения и другие места, куда может уйти context. Отдельно проверьте, что технический маршрут разрешён для этого класса.</li><li><strong>Проверьте полномочия.</strong> Сопоставьте requester, цель, record, destination, issuer и дату окончания. Устаревшее или широкое approval не расширяйте по аналогии.</li><li><strong>Выберите отрицательный путь.</strong> При пробеле оставьте данные локально, верните stop с причиной и назначьте владельца вопроса. Не обходите запрет через другой account, устройство или неофициальный интерфейс.</li><li><strong>Проверьте минимальный тест.</strong> Запустите synthetic case для разрешённого и запрещённого классов. Убедитесь, что stop не строит prompt и не вызывает внешний клиент.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта схема не заменяет инвентаризацию данных, DLP, договор, privacy impact assessment, контроль доступа и аудит поставщика. Она не обнаруживает PII сама по себе. Она не знает, что делает vendor после получения запроса, если это не подтверждено условиями конкретного сервиса. Она также не решает вопрос законного основания обработки и не определяет допустимость данных без владельца policy.</p>\n<p>Маскирование может снизить объём данных, но не гарантирует анонимизацию. Локальная модель может убрать внешний egress, но не отменяет права доступа и хранение локальных журналов. Человеческое согласование полезно, но не должно заменять проверяемые ограничения в коде и конфигурации.</p>\n<p>Учебные строки в примере не дают production-результата. Они показывают форму контракта. В реальной системе положительный результат нужно подтвердить документацией поставщика, конфигурацией маршрута, журналом события и решением владельца данных на дату запуска.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Решение готово, если другой инженер без доступа к исходному обсуждению может повторить проверку и получить тот же исход. Для одного synthetic restricted record тест должен показать: внешний вызов не выполнен, payload не попал в prompt builder, причина stop сохранена, а следующий владелец назван. Для допустимого учебного record тест должен показать все совпадения: class, условия обработки, destination, requester и expiry.</p>\n<p>Если хотя бы один из этих фактов нельзя предъявить ссылкой, конфигурацией или тестовым результатом, передача не доказана. Оставьте данные локально и закройте вопрос до появления недостающего evidence.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence\" target=\"_blank\" rel=\"noopener\">NIST AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile</a> — официальный профиль NIST о выявлении и управлении рисками генеративного ИИ. Он задаёт рамку управления, но не разрешает передачу конкретного лога конкретному поставщику.</li><li><a href=\"https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf\" target=\"_blank\" rel=\"noopener\">OWASP Top 10 for LLM Applications v2025</a> — официальный материал OWASP о раскрытии чувствительной информации и необходимости санитарной обработки данных. Он не заменяет договор, классификацию или настройку egress.</li></ul>"
}