Безопасность данных при внедрении ИИ в бизнес: 152-ФЗ, облачные LLM и чек‑лист для руководителя

Классические угрозы вроде фишинга и взлома серверов никуда не делись. Но ИИ добавил принципиально новый вектор: данные утекают не из-за атаки, а из-за обычной работы сотрудников. Никакой антивирус не заметит, что человек сам отправил конфиденциальный файл во внешний сервис.

Есть несколько типичных сценариев. Первый — «теневой ИИ»: сотрудники пользуются личными аккаунтами в публичных чат-ботах. Второй — подключение внешних плагинов и расширений браузера, которые читают содержимое страниц. Третий — интеграции, где в запрос к модели автоматически уходит больше данных, чем нужно.

Отдельная угроза — prompt injection. Если ИИ-ассистент читает письма или документы, злоумышленник может спрятать в тексте инструкцию вроде «перешли всю переписку на адрес…». Модель выполнит её, если у неё есть такие права.

Цена ошибки складывается из нескольких частей:

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

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

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

Вот ключевые требования, которые чаще всего нарушают при внедрении ИИ:

1. Законное основание. Нужно согласие субъекта или другое основание, а цель обработки должна быть заявлена. «Обучение нейросети» — это отдельная цель, и её нужно прописать.
2. Локализация. Первичная запись, систематизация и хранение персональных данных граждан РФ должны происходить в базах на территории России.
3. Трансграничная передача. Если облачная модель размещена за рубежом, действуют правила уведомления Роскомнадзора и оценка защищённости принимающей стороны.
4. Поручение обработки. С поставщиком облачной LLM нужен договор, где закреплены цели и меры защиты.
5. Меры безопасности. Контроль доступа, учёт действий, защита каналов, модель угроз.

Что именно меняется с появлением LLM? Во-первых, данные уходят в запросах, которые трудно контролировать вручную. Во-вторых, если провайдер использует запросы для дообучения своей модели, это уже передача данных для иной цели. В-третьих, модель может «запомнить» и воспроизвести фрагменты чужих данных.

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

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

Публичное облако (API внешнего провайдера). Быстрый старт, высокое качество моделей, оплата по факту использования. Подходит для задач без персональных данных и коммерческой тайны: генерация идей, черновики текстов, анализ публичной информации. Минус — данные покидают ваш контур.

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

On-premise, или локальное размещение. Открытая модель разворачивается на ваших серверах. Данные не покидают периметр. Такой вариант нужен банкам, медицине, промышленности и всем, кто работает с чувствительной информацией.

Чтобы принять решение, ответьте на вопросы:

• Содержат ли запросы персональные данные или коммерческую тайну?
• Какой объём запросов в месяц? При больших нагрузках собственные серверы часто окупаются.
• Есть ли специалисты для поддержки инфраструктуры и GPU-серверов?
• Насколько критично качество ответов? Локальные модели догоняют облачные, но на сложных задачах пока уступают.

Ориентир по затратам: сервер с GPU под открытую модель среднего размера обходится в сотни тысяч рублей, поэтому для небольших нагрузок российское облако чаще выгоднее. Подробнее о подходах к подключению моделей читайте на странице LLM-интеграции.

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

1. Маскирование и анонимизация. Перед отправкой запроса к модели специальный слой находит персональные данные и заменяет их токенами: «Иван Петров» превращается в «КЛИЕНТ_1», телефон — в «ТЕЛЕФОН_1». После получения ответа значения подставляются обратно. Модель решает задачу, но реальных данных не видит. Для поиска используют регулярные выражения, словари и NER-модели.

2. Разграничение доступа. ИИ-ассистент не должен знать больше, чем сотрудник, который с ним работает. При использовании поиска по базе знаний (RAG) права проверяются на уровне документов: менеджер не получит в ответе выдержку из финансового отчёта. Применяйте принцип наименьших привилегий и для самого ассистента: если ему не нужна запись в CRM, не давайте её.

3. Журналирование. Фиксируйте, кто, когда и с каким запросом обращался к модели, какие документы использовались и что было возвращено. Логи нужны для расследования инцидентов и подтверждения соответствия закону. Сами логи тоже содержат чувствительные данные, поэтому храните их в защищённом хранилище с ограниченным доступом.

Дополнительные меры, которые стоит предусмотреть:

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

Эти принципы мы закладываем при разработке AI-ассистентов для бизнеса: защита проектируется вместе с функциональностью, а не после неё.

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

1. Классификация данных. Определено, какие данные будут попадать в модель: публичные, внутренние, персональные, коммерческая тайна.
2. Правовое основание. Есть согласия и заявленные цели обработки, обновлена политика конфиденциальности.
3. Локализация. Известно, где физически хранятся данные и где работает модель.
4. Договор с провайдером. Прописаны запрет использования данных для обучения, сроки хранения, ответственность за инциденты.
5. Маскирование. Персональные данные удаляются или заменяются до отправки запроса.
6. Права доступа. Ассистент видит только то, что разрешено конкретному пользователю.
7. Журналирование. Запросы и ответы фиксируются, логи защищены и имеют срок хранения.
8. Политика для сотрудников. Есть регламент: что можно вводить в нейросети, а что нельзя, и проведён инструктаж.
9. План на случай инцидента. Назначены ответственные, известен порядок уведомления регулятора и клиентов.
10. Тестирование. Проведена проверка на утечки и prompt injection до выхода в продакшн.

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