Безопасный ИИ для компании: как внедрить без утечек, штрафов и остановки бизнеса

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

Ниже — практический разбор того, как выглядит безопасный ИИ для компании на российской инфраструктуре: от выбора контура до журналирования действий агентов.

Почему безопасность ИИ нельзя «докрутить потом»

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

Второй момент — регуляторный. Если в промпт попадает ФИО клиента, номер договора или медицинская информация, вы работаете с персональными данными. Передача их во внешний зарубежный сервис — это уже нарушение 152-ФЗ, независимо от того, случилась утечка или нет. Штрафы за такое в России растут, а репутационные потери обычно дороже.

Какие риски ИИ реально бьют по бизнесу

Разделим угрозы на четыре группы — так проще назначить ответственного за каждую.

Утечка данных через промпт. Сотрудник копирует в чат-бот выгрузку из 1С, чтобы «быстро посчитать». Данные уходят на чужой сервер.

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

Избыточные права агента. ИИ-агент с доступом «на запись» во все разделы CRM может массово испортить сделки при сбое логики.

Незаметные ошибки. Модель уверенно выдаёт неверную цифру в отчёте, и решение принимается на её основе. Без журналирования источников это не отследить.

Три сценария внедрения: облако, гибрид, приватная LLM

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

Гибрид — компромисс: обезличенные запросы уходят наружу, всё, что касается клиентов и финансов, обрабатывается внутри. Требует дисциплины: классификатор данных должен работать автоматически, а не «на честном слове».

Приватная LLM на своих серверах — единственный вариант, когда в контур попадают договоры, медицинские карты, зарплатные ведомости, конструкторская документация. Модель физически не имеет канала наружу, а логи остаются у вас.

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

Как устроен приватный контур на локальных серверах

Типовая архитектура выглядит так:

• Слой модели. Открытые LLM (Qwen, Llama, Mistral в квантованных версиях) разворачиваются на GPU-серверах в дата-центре компании или в российском облаке с изоляцией тенанта. Никаких внешних API.
• Слой данных. Векторная база и документы лежат во внутренней сети. Доступ — по сервисным учёткам, а не по логинам сотрудников.
• Слой доступа. Шлюз, который проверяет права пользователя перед тем, как отдать ему ответ модели. Бухгалтер не должен видеть фрагменты HR-документов, даже если спросит.
• Слой контроля. Логи запросов, ответов и использованных источников. Хранятся отдельно от модели, чтобы администратор ИИ не мог их подчистить.

Ключевая идея: безопасность обеспечивается не «умной моделью», а тем, что вокруг неё выстроено.

Персональные данные и 152-ФЗ: где чаще всего ошибаются

Три типичные ошибки при внедрении ИИ в компании:

1. Обезличивание «на глаз». Замена фамилии на «Клиент №1» не помогает, если в тексте остался номер телефона или адрес доставки.
2. Отсутствие основания обработки. Даже внутри компании обработка ПДн для обучения модели требует согласия субъекта или иного законного основания. Это редко прописывают в политике.
3. Трансграничная передача по умолчанию. Любой зарубежный сервис — это передача данных за границу. Уведомление в Роскомнадзор нужно до запуска, а не после.

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

Безопасный RAG: знания внутри периметра

RAG — самый востребованный сценарий: ИИ отвечает по внутренней базе знаний. Чтобы он не стал дырой, важны три вещи.

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

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

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

ИИ-агенты: минимальные права и полный аудит

Агент, который сам создаёт задачи, отправляет письма и меняет статусы сделок, — самый рискованный тип ИИ в компании. Базовые правила:

• Принцип минимальных привилегий. Агенту выдаётся отдельная учётная запись с доступом только к нужным объектам. Не «аккаунт администратора, чтобы не возиться».
• Подтверждение критичных действий. Отправка клиенту коммерческого предложения или изменение суммы в сделке — только после одобрения человеком.
• Полный журнал. Каждый вызов инструмента логируется: кто инициировал, что запросил, что получил.
• Ограничение по частоте. Это защищает и от сбоев логики, и от попыток использовать агента для массовых операций.

OCR и документы: где утекает чаще всего

Распознавание сканов — недооценённый канал риска. Скан паспорта или договора, отправленный в публичный OCR-сервис, — это передача ПДн третьей стороне. Решение — OCR внутри контура: на своём сервере или в изолированном российском облаке, с автоматическим удалением исходников после обработки.

Интеграция с 1С и CRM: контрольные точки

ИИ редко живёт сам по себе — он встраивается в 1С, Bitrix24, amoCRM. Здесь важно:

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

Чек-лист безопасного внедрения ИИ

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

Что в итоге

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

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