Безопасно ли давать ИИ доступ к данным
Обновлено: 11 июня 2026 · Юрий Бутенков
Коротко
Безопасно при правильной архитектуре. Данные хранятся на серверах в РФ, доступ разграничен по ролям, чувствительные поля маскируются, а персональные данные обрабатываются по 152-ФЗ. Риск создаёт не сам ИИ, а небрежная настройка — поэтому важно, кто и как внедряет.
Доступ ИИ к корпоративным данным — это управляемый риск, такой же, как доступ нового сотрудника: опасность создаёт не технология, а отсутствие правил. Правильная архитектура держится на четырёх элементах: персональные данные хранятся на серверах в РФ, ассистент видит только те данные, что нужны для его задачи, чувствительные поля — паспорта, карты, диагнозы — маскируются до передачи в модель, а каждое обращение к данным записывается в лог. При такой схеме ассистент знает о клиенте меньше, чем рядовой оператор с полным доступом к CRM, и в отличие от человека не может «вынести» базу или пересказать её знакомым. Эти требования мы закладываем в каждое из 40+ внедрений и фиксируем в договоре — поэтому вопрос «безопасно ли» на практике превращается в вопрос «кто и как настроил систему». Ниже — из чего складывается безопасная архитектура, что делать с публичными моделями и какие вопросы задать подрядчику.
Как снижаются риски на практике?
- Хранение в РФ. Персональные данные — на российских серверах.
- Разграничение доступа. Ассистент видит только то, что нужно для задачи.
- Маскирование. Чувствительные поля (паспорта, карты) скрываются.
- Логирование. Все обращения к данным фиксируются.
Какие вопросы задать подрядчику?
Пять вопросов, по которым видно зрелость исполнителя. Где физически хранятся персональные данные и чем это подтверждается? Какие поля уходят в языковую модель и как они обезличиваются? Кто из сотрудников видит диалоги и как разграничен доступ? Что попадает в логи и сколько они хранятся? Как ответственность за 152-ФЗ распределена в договоре? Внятные ответы на все пять — норма, а не подвиг: у нас они входят в стандартное ТЗ каждого внедрения. Если подрядчик отвечает «не переживайте, всё безопасно» без деталей — риск создаёт именно он, а не технология. Сравните: вы же не выдаёте новому сотруднику пароль администратора в первый день — с ассистентом действует тот же принцип минимально необходимого доступа, только соблюдается он строже, потому что прописан в коде, а не в инструкции.
Что делать с публичными моделями?
Если задача требует внешней модели, данные обезличиваются перед отправкой, а под строгие требования используется размещение в российском контуре (GigaChat, YandexGPT) или собственная модель. Выбор зависит от чувствительности данных.
Уровень защиты подбирается под отрасль: интернет-магазину достаточно маскирования контактов, клинике нужен полностью российский контур, потому что данные о здоровье — отдельная, более строгая категория по 152-ФЗ. Пережимать тоже не стоит: избыточные ограничения удорожают проект и режут качество ответов без реального снижения риска.
Частые вопросы
При корректной интеграции — нет. Используются режимы без сохранения и обучения на ваших данных, а чувствительные процессы держим в российском контуре.
Архитектуру и соответствие 152-ФЗ закладываем на этапе внедрения и фиксируем в договоре.
