8 lines
17 KiB
JSON
8 lines
17 KiB
JSON
{
|
||
"index": 98,
|
||
"slug": "editorial-2025-04-mechanism-ai-data-privacy",
|
||
"title": "Передача данных в AI: четыре проверки до отправки контекста",
|
||
"excerpt": "Класс данных, условия обработки, сетевой маршрут и полномочия отвечают на разные вопросы. Разбираем, как соединить их в один fail-closed контроль и остановить передачу при пробеле в доказательствах.",
|
||
"contentHtml": "<p>Симптом обычно выглядит безобидно: инженер копирует в AI-инструмент кусок лога, тикет или stack trace, а потом не может точно сказать, что именно ушло наружу. В настройках включён корпоративный тариф, сеть разрешает нужный домен, коллега устно подтвердил «можно». Но эти факты не доказывают одно и то же. Цена ошибки — раскрытие персональных данных или секрета, нарушение договорного условия, невозможность восстановить решение и остановка всего сценария до повторной проверки.</p>\n<p>Тезис статьи простой: передача контекста допустима только тогда, когда сходятся четыре независимых доказательства. Нужно знать класс записи, применимую policy и договорные условия, конкретный технический маршрут и полномочия человека на эту запись в этот срок. Если один слой неизвестен, система должна остановить hand-off и вернуть причину. Нельзя заменить отсутствующий факт более удобным фактом из другой колонки.</p>\n<h2>Почему одного разрешения недостаточно</h2>\n<p>Класс описывает содержимое. Например, <code>public</code>, <code>internal</code> или <code>restricted</code>. Это не название папки и не ощущение автора фрагмента. Класс должен иметь владельца и правило, по которому его присвоили. Удаление имени из строки тоже не меняет автоматически класс: структура события, редкий идентификатор и сочетание полей могут оставаться чувствительными.</p>\n<p>Policy отвечает на вопрос «допустима ли такая обработка». Договор уточняет условия для конкретного сервиса, тарифа, региона и функции: retention, обучение моделей, subprocessors или запрет внешнего хранения. Слово «корпоративный» не заменяет проверку этих условий. Одобрение продукта не является автоматически разрешением на любой payload.</p>\n<p>Egress отвечает на другой вопрос: куда и каким путём может уйти запрос. Это endpoint, proxy, firewall, DNS-политика или другой сетевой control. Разрешённый маршрут не делает данные допустимыми. Authorization отвечает ещё на один слой: какой владелец разрешил конкретную запись, конкретному requester, для конкретного destination и до какой даты.</p>\n<figure><img src=\"/assets/editorial/2025/ai-data-privacy-2025-egress-review.svg\" alt=\"Маршрут проверки AI-контекста от класса записи и условий обработки через сетевой egress и полномочия к hand-off или безопасной остановке\" loading=\"lazy\" /><figcaption>Каждый слой проверяет свой вопрос. Несовпадение на любом переходе закрывает передачу и сохраняет причину остановки.</figcaption></figure>\n<h2>Механизм: четыре доказательства должны описывать одну операцию</h2>\n<p>Рассмотрим запрос на анализ ошибки в платёжном сервисе. Инженер хочет передать AI фрагмент журнала. В нём есть время, тип операции, идентификатор клиента и текст исключения. Даже если значение идентификатора заменили на <code>client-17</code>, нужно отдельно решить, что осталось в записи и какой класс ей присвоен.</p>\n<p>Первое доказательство — карточка контекста. В ней есть стабильный идентификатор записи, версия, класс, владелец, срок действия и ссылка на правило классификации. Второе — policy и contract evidence для выбранной поверхности. Ссылка должна покрывать именно тот plan и тот режим, в котором работает инструмент. Третье — проверенный egress scope: destination и технический control должны совпадать с карточкой. Четвёртое — датированное решение владельца. Оно содержит record id, requester, destination, срок и причину.</p>\n<p>Проверка не должна начинаться с approval. Иначе человек сможет невольно «перекрыть» запрет класса. Она не должна начинаться с сети. Иначе доступный endpoint станет ложным доказательством допустимости. Сначала проверяют форму запроса и запись, затем допустимость, маршрут, доступ и срок полномочий. Только после этого можно передать результат в отдельный разрешённый workflow.</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>«В логе нет имени, значит можно»</td><td>Редактура смешана с классификацией</td><td>Сверить остаточную структуру, класс и owner rule</td><td>Не передавать; запросить классификацию или заменить запись на публичный пример</td></tr><tr><td>«У нас Enterprise-тариф»</td><td>План принят за договорное условие</td><td>Проверить policy, retention и training terms для нужной функции</td><td>Закрыть hand-off до появления ссылки и применимого scope</td></tr><tr><td>«Firewall уже разрешил домен»</td><td>Сетевой control принят за решение о данных</td><td>Сопоставить destination, route и egress scope с карточкой</td><td>Использовать только подтверждённый маршрут; не искать обход</td></tr><tr><td>«Коллега разрешал это раньше»</td><td>Approval не привязан к record, requester или сроку</td><td>Сверить id записи, роль, requester, destination и expiry</td><td>Получить новое датированное решение или остановить передачу</td></tr><tr><td>«Неизвестно, что вернёт интеграция»</td><td>Дополнительный context и внешние запросы не учтены</td><td>Проверить документацию конкретной surface и включённые функции</td><td>Оставить данные локально до подтверждения всех outbound paths</td></tr></tbody></table></div>\n<h2>Учебный пример с отрицательным путём</h2>\n<p>Ниже — ограниченный пример на JavaScript. В нём используются только фиксированные строки, нет настоящего лога, PII, секрета, файла, сети, вызова модели или production side effect. Функция не отправляет payload. Она показывает только контракт: запись с запрещённым классом должна остановиться до проверки approval.</p>\n<pre><code>const request = createFixedContextRequest('restricted-log-shape');\nconst decision = assessEgress(request);\nconst result = stopWhenClosed(decision);\n\nconsole.log(decision.accepted); // false\nconsole.log(decision.reason); // class-not-allowed\nconsole.log(result.payloadReleased); // false\nconsole.log(result.nextAction); // ask-data-owner\n\n// В этом учебном примере нет HTTP-вызова.</code></pre>\n<p>Реальная реализация должна проверять строгую схему входа. Не принимайте лишние поля, отсутствующий scope, поддельную authorization или просроченную дату как частично корректный запрос. Fail-closed означает конкретный результат: <code>accepted: false</code>, причина, ссылка на проверенный источник и следующий владелец вопроса. Это не доказывает, что технология всегда запрещена. Это доказывает только, что текущих фактов недостаточно для данной передачи.</p>\n<h2>Как выполнить проверку</h2>\n<ol><li><strong>Остановите копирование.</strong> Назовите record id и не открывайте AI-поверхность ради «быстрой проверки».</li><li><strong>Опишите класс.</strong> Зафиксируйте содержимое, версию классификации, owner и правило. Не считайте редактирование доказательством безопасности.</li><li><strong>Сверьте policy и contract.</strong> Проверьте plan, feature, region, retention и другие условия, которые относятся к выбранной surface.</li><li><strong>Проверьте маршрут.</strong> Запишите destination, route и сетевой control. Убедитесь, что они совпадают с разрешённым scope.</li><li><strong>Проверьте полномочия.</strong> Сопоставьте requester, access к record, роль владельца, record id и expiry. Старое общее одобрение не переносится автоматически.</li><li><strong>Выберите outcome.</strong> При полном совпадении передайте только разрешённый контекст в authorised workflow. При пробеле сохраните payload локально, запишите reason и назначьте следующий вопрос.</li></ol>\n<h2>Что могут и чего не могут доказать официальные документы</h2>\n<p>Документация конкретного AI-продукта может описывать обработку prompt, добавление repository context или отдельный внешний поиск. Это помогает обнаружить дополнительные границы egress. Но такая документация не классифицирует ваш лог и не выдаёт сотруднику право на его раскрытие.</p>\n<p>Сетевое правило снижает риск неправильного endpoint, но не видит смысл payload. DPA и условия сервиса помогают ответить на вопрос о permitted processing, но не подтверждают, что человек имеет доступ к записи. NIST описывает policy-based access и неявное доверие к network location как разные вещи. Эти источники формируют вопросы для проверки; они не дают универсального вердикта «можно передавать».</p>\n<h2>Ограничения</h2>\n<p>Четыре проверки не заменяют DLP, data inventory, юридическую оценку, access control или технический мониторинг. Классификация может ошибиться. Документ поставщика может измениться. Proxy может быть настроен не так, как написано в схеме. Поэтому в рабочей системе храните версию evidence, дату проверки, применимый scope и границу, которую документ не покрывает.</p>\n<p>Не обещайте результат, которого не измеряли. Эта статья не утверждает, что конкретная интеграция сохраняет или не сохраняет prompt, не обучает на нём модели и не гарантирует отсутствие утечки. Учебный код не является доказательством свойств production. Его проверяемый результат уже: запрещённый класс не приводит к передаче.</p>\n<h2>Критерий готовности</h2>\n<p>Контроль готов к ограниченному применению, когда другой инженер может взять одну карточку без payload и воспроизвести весь вопрос: какой класс, какая policy и договорная версия, какой destination и route, кто разрешил, какой срок. Для каждого пробела система возвращает <code>accepted: false</code>, reason, citation и next action; ни один отрицательный case не вызывает внешний запрос. Положительный outcome допускает только тот scope, который совпал во всех четырёх доказательствах. Если эти условия нельзя проверить, готов не hand-off, а только следующий вопрос владельцу данных.</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> — документация конкретной поверхности и её контекста; не является классификацией данных или разрешением на передачу.</li><li><a href=\"https://github.com/github/docs/blob/0d17a12af77011b390abd8aea9e8626e153e0522/data/reusables/copilot/sku-isolation.md\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Docs: Copilot SKU isolation</a> — пример контроля endpoint через сетевые правила; не доказывает retention, training terms или полномочия requester.</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> — официальный источник о policy-based доступе к конкретному ресурсу и ограниченности доверия к сетевому расположению.</li></ul>"
|
||
}
|