Безопасность данных при внедрении AI: что нельзя отдавать наружу

Главный вопрос: что именно покидает ваш периметр

Любое внедрение AI начинается с картинки движения данных, а не с выбора модели. Нужно нарисовать простую схему: что подаётся на вход, куда физически уходит этот текст или файл, кто имеет к нему доступ на той стороне, сколько он там хранится и что возвращается обратно.

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

Что нельзя отдавать наружу без специальной проработки

• Персональные данные в исходном виде. ФИО вместе с телефоном, адресом, паспортными данными, датой рождения. Особенно — специальные категории сведений (здоровье и подобное), где требования строже всего.
• Данные, составляющие банковскую, врачебную и иную охраняемую законом тайну. Здесь режим определяется отдельным регулированием, и общий подход «мы же обезличили» может не сработать.
• Коммерческую тайну. Себестоимость, условия договоров с ключевыми контрагентами, клиентская база целиком, внутренние методики. Формально это не персональные данные, но утечка бьёт по бизнесу напрямую.
• Учётные данные и ключи доступа. Логины, пароли, токены, ключи API — их нельзя вставлять в переписку с моделью ни при каких обстоятельствах, включая «просто чтобы модель поняла контекст».
• Документы, где перемешано всё сразу. Договор с физлицом содержит и персональные данные, и коммерческие условия. Такой файл не «немного чувствительный» — он чувствительный целиком.

Что требует закон о персональных данных

Обработку персональных данных в России регулирует Федеральный закон № 152-ФЗ «О персональных данных». Он не запрещает использовать AI — он предъявляет требования к тому, как и зачем вы обрабатываете сведения о людях. Ключевые вещи, которые нужно понимать собственнику, без ухода в детали:

• Нужно правовое основание обработки. Чаще всего это согласие субъекта персональных данных либо исполнение договора с ним, либо иное основание, прямо предусмотренное законом. Само по себе «нам так удобнее» основанием не является.
• Цель должна быть определённой и заранее заявленной. Данные, собранные для доставки заказа, нельзя молча начать использовать для другой цели. Если появляется новая цель — она должна быть оформлена.
• Объём обработки должен соответствовать цели. Избыточные сведения собирать и передавать нельзя.
• Передача обработки другому лицу оформляется. Если вы поручаете обработку подрядчику или сервису, отношения должны быть оформлены документально, с указанием состава данных, целей, перечня действий и обязанности обеспечивать конфиденциальность и безопасность.
• Трансграничная передача требует отдельного внимания. Отправка персональных данных в сервис, расположенный за рубежом, — это передача за пределы страны, для которой законом предусмотрены специальные требования и уведомительные процедуры. Это тот случай, когда решение принимается не разработчиком, а после консультации с юристом.
• Ответственность остаётся на операторе. То есть на вашей компании. Подрядчик отвечает перед вами по договору, но перед субъектом и регулятором отвечаете вы.

Мы сознательно не приводим номера конкретных статей и не даём юридических заключений: цена ошибки в этой теме высока. Задача статьи — чтобы вы знали, какие вопросы задать своему юристу до запуска, а не после.

Обезличивание: самый практичный инструмент

Большая часть задач, ради которых бизнес идёт в AI, не требует знать личность человека. Модели всё равно, кто именно написал претензию — ей важны суть обращения, тон и суммы. Отсюда простой приём, который снимает основную долю риска.

Перед отправкой в модель идентифицирующие фрагменты заменяются метками: ФИО → КЛИЕНТ_1, телефон → ТЕЛЕФОН_1, номер договора → ДОГОВОР_1. Модель работает с обезличенным текстом, а после получения ответа ваша система подставляет реальные значения обратно — уже внутри периметра. Наружу при этом ушёл смысл, но не личность.

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

Локальные и облачные модели: честное сравнение

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

Что должно быть в договоре с подрядчиком

Здесь бизнес теряет больше всего — не от утечек, а от того, что через год выясняется: работающее решение принадлежит не ему. Минимальный набор пунктов, который стоит проверить.

1. Состав передаваемых данных и цели. Прямо перечислить, какие данные подрядчик получает и для чего. Всё, что не перечислено, — не передаётся.
2. Оформление поручения обработки. Если подрядчик работает с персональными данными ваших клиентов или сотрудников — отношения оформляются в соответствии с требованиями законодательства о персональных данных.
3. Запрет на использование ваших данных для посторонних целей. В частности — для обучения собственных моделей подрядчика и для демонстрации другим клиентам.
4. Конфиденциальность и срок её действия. Обязательства должны переживать окончание договора.
5. Субподряд и перечень используемых сервисов. Вы должны знать, какие сторонние сервисы участвуют в обработке. Смена — только с вашего согласия.
6. Права на результат. Ключевой пункт. Что именно вы получаете: исключительные права или лицензию, и на что конкретно — исходный код, промпты и системные инструкции, настройки, базу знаний, документацию.
7. Передача материалов при завершении. Обязанность выгрузить и передать всё перечисленное, а также удалить ваши данные на своей стороне, с подтверждением.
8. Ответственность за нарушение конфиденциальности. Реальная и измеримая, а не декларативная.

Проверочный вопрос, который экономит годы: если завтра мы расстаёмся с подрядчиком, что именно останется у нас в руках и продолжит работать? Если ответ «не знаем» — договор нужно переписывать до начала работ, а не после. — команда Aivonix

Правила для сотрудников: короткий регламент

Технический контур бесполезен, если сотрудник обходит его через личный аккаунт в браузере. Что должно быть написано и доведено до людей:

• Какими сервисами можно пользоваться для рабочих задач — закрытый список, а не «на своё усмотрение».
• Что нельзя вставлять никогда: паспортные данные, полные клиентские выгрузки, доступы, документы с грифом.
• Как обезличивать текст перед отправкой, если это делается руками.
• Куда обращаться, если задача требует чувствительных данных, — должен быть разрешённый способ, иначе люди придумают свой.
• Что результат работы модели проверяется человеком перед использованием — это одновременно и про безопасность, и про качество.

Запретительный регламент без разрешённой альтернативы не работает: сотрудники всё равно решают свою задачу, просто скрытно. Поэтому политика безопасности и внедрение корпоративного AI-ассистента обычно делаются вместе — вы даёте удобный легальный инструмент и одновременно закрываете обходные пути.

Порядок действий до запуска

1. Нарисовать схему движения данных для конкретного процесса.
2. Определить, какие сведения действительно нужны модели, и убрать остальные.
3. Решить, что обезличивается, что обрабатывается локально, что уходит в облако.
4. Согласовать конфигурацию с юристом — особенно если задействованы зарубежные сервисы.
5. Закрепить состав данных, цели и права на результат в договоре.
6. Написать короткий регламент для сотрудников и дать им разрешённый инструмент.

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

FAQ

Можно ли загружать персональные данные клиентов в облачную нейросеть?

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

Что такое обезличивание и когда его достаточно?

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

Локальная модель или облачная?

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

Кому принадлежит результат работы AI, который сделал подрядчик?

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