Безопасность данных при использовании ИИ в компании

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

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

Почему тема стала критичной

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

• ФИО, телефоны, email и история заказов клиентов;
• договоры, счета, цены и скидки;
• коммерческие предложения и внутренние регламенты;
• фрагменты кода, токены, ключи доступа и конфиги;
• HR-данные, резюме и оценки сотрудников.

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

Какие данные особенно опасно передавать в ИИ

Не все данные одинаково чувствительны. Для бизнеса полезно разделить их хотя бы на четыре группы:

Типичная ошибка

Сотрудник копирует в публичный чат "для ускорения работы" заявку клиента, кусок договора или таблицу продаж. Модель помогает, но компания уже передала данные во внешнюю систему, которую не контролирует полностью. Даже если провайдер обещает защиту, без договора, политики хранения и ограничения доступа это слабое место.

Основные риски при использовании ИИ в компании

1. Утечка через промпты

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

2. Логи и история запросов

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

3. Избыточные права доступа

Если AI-бот подключён сразу к CRM, почте, базе знаний и ERP, но права не ограничены, любой сбой или неверный промпт может раскрыть лишнюю информацию. Для ИИ особенно опасен принцип "дадим доступ ко всему, потом разберёмся".

4. Провайдер и трансграничная передача

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

5. Галлюцинации с деловыми последствиями

Проблема не только в утечке. Если ИИ "уверенно" придумывает условия договора, обещает клиенту несуществующую скидку или неверно классифицирует обращение, бизнес получает прямой ущерб. Поэтому безопасность ИИ - это ещё и контроль качества решений, а не только защита базы.

Что бизнесу делать до запуска

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

1. Опишите сценарии использования. Кто и зачем отправляет данные в ИИ, откуда они берутся и куда возвращается ответ.
2. Разделите данные по чувствительности. Что можно отправлять в публичную модель, что - только в корпоративную, а что нельзя отправлять вообще.
3. Ограничьте доступы. Бот и сотрудники должны видеть только тот объём данных, который нужен для конкретной задачи.
4. Настройте маскирование. Убирайте из промптов ФИО, номера документов, реквизиты, токены и другие лишние идентификаторы.
5. Проверьте договоры с провайдером. Важны DPA, хранение логов, обучение на данных, регион обработки, subprocessors.

Практические меры защиты

Политика для сотрудников

Нужна короткая и понятная инструкция, а не абстрактный документ на 40 страниц. Сотрудник должен знать:

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

Технические меры

Для большинства компаний полезны такие базовые меры:

• SSO и разграничение ролей;
• журналирование обращений к ИИ;
• автоматическое маскирование персональных данных;
• запрет на передачу секретов и ключей;
• отдельный шлюз или middleware перед внешним API;
• лимиты на выгрузку данных из внутренних систем.

Организационные меры

Без процессов даже хорошая техника не спасает. Назначьте ответственных за:

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

Когда нужен корпоративный, а не публичный ИИ

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

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

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

Чеклист перед внедрением

Перед продакшеном полезно проверить:

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

Итог

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

Нужен безопасный сценарий внедрения ИИ для сайта, бота или внутренних процессов - напишите.

Часто задаваемые вопросы

Можно ли сотрудникам пользоваться обычным ChatGPT или Claude для рабочих задач?

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

Какие данные нельзя отправлять в ИИ без отдельной проверки?

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

Достаточно ли подписать NDA с сотрудниками и подрядчиками?

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

Как снизить риск утечки, если ИИ уже подключён к CRM и базе знаний?

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

Нужен ли отдельный ответственный за безопасность ИИ в небольшой компании?

Да, хотя бы в роли, а не обязательно в отдельной должности. Кто-то должен отвечать за правила доступа, согласование сценариев, работу с провайдером, пересмотр логов и разбор инцидентов. В малом бизнесе это может быть руководитель проекта, технический директор или внешний подрядчик, но зона ответственности должна быть названа прямо.