Какие данные нельзя отправлять в ИИ: практическая проверка перед запросом

Главная ошибка при работе с ИИ часто происходит до получения ответа — в момент, когда человек вставляет в запрос лишние данные. Удобный интерфейс похож на обычный чат, поэтому в него легко перенести договор, переписку, список клиентов или внутренний отчёт целиком. Но простота ввода не означает, что любой материал разрешено передавать внешнему сервису.

Безопасная привычка состоит из трёх действий: определить чувствительность данных, сократить их до необходимого минимума и проверить правила выбранного инструмента. Если хотя бы один пункт неясен, используйте обезличенный пример или остановитесь до консультации с ответственным за безопасность и данные.

Начните с запретной категории

Никогда не вставляйте пароли, ключи API, коды восстановления, закрытые ключи, данные платёжных карт и другие секреты доступа. Это не материал для анализа, а средство управления системами и деньгами. Если секрет уже оказался в запросе, его следует считать раскрытым и действовать по внутренней процедуре отзыва и замены.

Отдельно проверьте коммерческую тайну, документы под соглашением о конфиденциальности, непубличные финансовые показатели, исходный код закрытых продуктов и сведения о будущих сделках. Разрешение на доступ к документу внутри компании не всегда означает разрешение отправить его внешнему поставщику ИИ.

Персональные данные требуют отдельного основания

Имена, контакты, идентификаторы, записи разговоров, сведения о здоровье, оценках сотрудников и поведении клиентов могут относиться к персональным данным. Замена имени на инициалы не всегда делает набор анонимным: человека можно узнать по должности, редкому событию или сочетанию других признаков.

Риск-ориентированное руководство ICO рекомендует оценивать цель обработки, необходимость данных, влияние на людей и меры снижения риска. На практике сотрудник не должен самостоятельно решать сложный юридический вопрос в момент составления промпта. Нужна утверждённая политика: какие сервисы разрешены, для каких целей и с какими категориями информации.

Минимизируйте вход

Перед запросом спросите: без какого фрагмента задача всё ещё решается? Для проверки тона письма обычно не нужны настоящее имя клиента, номер договора и история платежей. Для создания структуры отчёта достаточно заголовков и вымышленных значений. Для извлечения полей можно подготовить синтетический пример того же формата.

Минимизация уменьшает последствия ошибки и одновременно улучшает управляемость запроса. Короткий релевантный контекст легче проверить, в нём меньше противоречий и устаревших сведений. Удаляйте не только явные идентификаторы, но и комментарии, метаданные, подписи, скрытые листы и длинные цитаты из переписки, если они не нужны для результата.

Проверьте инструмент и режим

Уточните, кто предоставляет сервис, где обрабатываются данные, сохраняются ли запросы, используются ли они для улучшения моделей, как управляется срок хранения и какие администраторы имеют доступ. Ответы должны подтверждаться договором, настройками и официальной документацией, а не предположением сотрудника.

Корпоративный и личный аккаунты могут иметь разные условия. Даже разрешённый продукт может быть безопасен только в конкретном рабочем пространстве с настроенными политиками. Не переносите данные в личный чат ради удобства и не обходите ограничение через скриншот, фотографию или другой формат файла.

Используйте проверку перед отправкой

Остановитесь на десять секунд и проверьте запрос по списку: нет ли секретов доступа; можно ли узнать человека; есть ли закрытые договорные сведения; нужен ли весь документ; разрешён ли этот сервис и аккаунт; сможете ли вы объяснить цель передачи ответственному за данные. Один сомнительный пункт означает паузу, а не попытку угадать.

Командам полезно подготовить разрешённые шаблоны задач и синтетические наборы данных. Тогда безопасное поведение становится самым простым. NCSC подчёркивает, что безопасность ИИ должна быть встроена в проектирование и эксплуатацию, а ответственность не должна перекладываться только на отдельного пользователя.

Что делать, если данные уже отправлены

Не пытайтесь скрыть инцидент удалением сообщения и продолжением работы. Зафиксируйте время, сервис, рабочий или личный аккаунт и категорию переданных данных, не копируя чувствительное содержимое в новый отчёт. Сообщите ответственному по утверждённому каналу как можно быстрее.

Если в запросе были пароли, ключи или коды восстановления, инициируйте их отзыв и замену. Простое удаление диалога не доказывает, что секрет нигде не сохранился. Для платёжных и других регулируемых данных действуйте по специальной процедуре организации.

Ответственный оценивает настройки сервиса, договор, срок хранения, доступ и круг затронутых людей. В зависимости от данных могут потребоваться действия службы безопасности, юриста, специалиста по приватности или владельца процесса. Пользователь не должен самостоятельно обещать, что последствий нет.

После первичных мер разберите причину: неясная политика, отсутствие разрешённого инструмента, неудобное обезличивание или недостаток обучения. Исправление процесса важнее обвинения сотрудника, иначе следующий похожий случай просто останется незаявленным.

Добавьте безопасную альтернативу: синтетический шаблон, локальную обработку, утверждённое корпоративное пространство или отказ от задачи. Инцидент должен привести к более понятному рабочему пути, а не только к ещё одному запрету в длинном документе.

Короткий вывод

Не отправляйте в ИИ секреты доступа, неразрешённые персональные данные и закрытую информацию. Для остальных задач сокращайте вход до минимума, используйте утверждённый рабочий аккаунт и останавливайтесь при неопределённости. Хороший результат не оправдывает нарушение границ данных.