"ИИ нельзя, у нас данные закрытые" - можно: как собрать ассистента в закрытом контуре
Почти в каждом проекте по внедрению ИИ сначала происходит одно и то же. Бизнес хочет автоматизировать поддержку, ускорить проверку документов, перестать вручную сводить отчёты и разгрузить сотрудников от повторяющихся операций. Но как только обсуждение доходит до информационной безопасности, звучит возражение: "Наши данные нельзя отправлять наружу".
После этого обычно выбирают один из двух неудачных сценариев. Проект полностью закрывают, объявляя искусственный интеллект неподходящим для компании. Либо сотрудники начинают самостоятельно пользоваться публичными чат-ботами, а спустя месяцы выясняется, что в сторонние сервисы попали фрагменты договоров, персональные данные или внутренняя переписка.
Проблема в том, что внедрение ИИ и передача информации во внешнее облако - не одно и то же. Языковая модель может работать внутри корпоративной инфраструктуры, на собственном сервере или даже непосредственно на компьютере сотрудника без подключения к интернету. Вопрос заключается не в том, использовать ИИ или нет, а в том, где разместить модель, какие данные ей разрешить читать и какие действия оставить под контролем человека.
Где может работать модель
Перед началом проекта нужно определить уровень конфиденциальности данных и выбрать подходящее место для запуска модели. Условно варианты можно расположить от наиболее открытого к максимально изолированному.
Публичное облако
Это самый быстрый путь к современным моделям и высокому качеству ответов. Приложение отправляет запросы во внешний API и получает готовый результат. Такой подход удобен для прототипирования, экспериментов и работы с обезличенными либо синтетическими данными.
Однако при использовании публичного API содержимое запроса покидает корпоративный периметр. Даже если провайдер заявляет о мерах защиты, необходимо отдельно изучать условия хранения, обработки и удаления информации. Для договоров, медицинских сведений, финансовых документов и коммерческой тайны такой вариант часто оказывается неприемлемым.
Облачный аккаунт компании
Модель можно развернуть в облачной инфраструктуре, которой организация уже пользуется для хранения и обработки данных. В таком случае информация не отправляется в открытый пользовательский сервис, а работает внутри выделенного аккаунта, виртуальной сети и настроенных политик доступа.
Это компромиссный вариант: компания получает масштабируемость и удобство облака, но сохраняет больше контроля над сетью, журналами, разрешениями и размещением данных. При этом необходимо учитывать требования законодательства, договоры с провайдером и ограничения конкретной модели.
Серверы организации
Модель запускается на собственном оборудовании - в дата-центре компании или в изолированном серверном сегменте. Данные физически не покидают контролируемую инфраструктуру. Такой вариант востребован в финансовом секторе, медицине, промышленности, госсекторе и организациях, работающих с коммерческой тайной.
Минусы очевидны: потребуются мощные видеокарты или специализированные ускорители, специалисты для обслуживания, резервирование и мониторинг. Зато компания получает максимальный контроль над жизненным циклом данных и поведением системы.
Локальный запуск на рабочем устройстве
Небольшую модель можно установить непосредственно на компьютер сотрудника. При корректной настройке она работает без интернета: анализирует документы, помогает составлять тексты и отвечает на вопросы по локальной информации.
Такой режим подходит не для всех задач. Ограничения по памяти и производительности могут снизить качество ответов, а обновление моделей и централизованное управление окажутся сложнее. Зато для автономной работы с чувствительными файлами это один из самых закрытых сценариев.
Доступ к данным - это не один переключатель
После выбора места размещения модели обсуждение обычно переходит к разрешениям. Здесь часто допускают архитектурную ошибку: говорят, что "ИИ дадут доступ к данным", не уточняя, что именно он сможет делать.
На практике есть как минимум три разных уровня.
Read - чтение информации. Ассистент получает доступ к базе знаний, регламентам, документам или заявкам, чтобы искать сведения, отвечать на вопросы и готовить черновики.
Write - внесение изменений. Система обновляет карточку клиента, меняет статус заявки, записывает результат обработки или редактирует запись в базе данных.
Execute - выполнение действий с внешними последствиями. Например, отправка письма, проведение платежа, публикация документа, создание заказа или вызов стороннего API.
Для большинства полезных бизнес-сценариев достаточно только режима Read. Ассистент может изучить инструкции и подготовить ответ оператору, но не иметь технической возможности отправить сообщение или изменить запись. Если эти функции отсутствуют в его инструментах и правах, модель не сможет выполнить их даже по ошибке.
Такое разделение помогает сделать согласование с безопасностью предметным. "Читать внутренние регламенты" и "самостоятельно проводить платежи" больше не выглядят как единая и одинаково опасная функция.
Почему полностью исключить ошибки невозможно
Нельзя гарантировать, что ИИ никогда не ошибётся. Он способен неверно интерпретировать документ, перепутать контрагента, пропустить важное условие или уверенно сформулировать неправильный вывод. Поэтому безопасность строится не на обещании безошибочной работы, а на ограничении последствий.
Для разных операций должны действовать разные правила. Ошибка в черновике внутреннего письма и неверный счёт, отправленный партнёру, - несопоставимые по риску ситуации.
Оптимальная схема выглядит так: в пределах заранее заданных полномочий ассистент работает самостоятельно, а критические действия передаёт человеку. Он может разобрать заявку, извлечь реквизиты, сравнить версии договора, заполнить шаблон или подготовить отчёт. Но перед отправкой документа, изменением финансовых данных или запуском необратимой операции система показывает результат сотруднику и ждёт подтверждения.
Это и есть принцип human-in-the-loop - участие человека в контуре принятия решений. Пользователь не выполняет всю работу с нуля, а проверяет уже подготовленный результат. В итоге автоматизация сохраняется, но окончательная ответственность за рискованные действия не передаётся модели.
Как устроить закрытого корпоративного ассистента
Практическая архитектура обычно состоит из нескольких уровней. Интерфейс принимает запрос сотрудника, отдельный сервис проверяет его права, затем поисковый компонент находит релевантные документы, а модель формирует ответ на основе разрешённого контекста.
Для работы с внутренними знаниями часто применяют подход, при котором модель не обучают на всей корпоративной базе, а перед каждым запросом передают ей только найденные фрагменты. Это позволяет быстрее обновлять документы, ограничивать область поиска и не включать в контекст сведения, к которым у сотрудника нет доступа.
Важно, чтобы права ассистента не были шире прав пользователя. Если менеджер не видит зарплатные документы, система не должна находить их через общий поисковый индекс. Проверку разрешений нужно выполнять до передачи фрагментов модели, а не надеяться на то, что она сама "поймёт", какую информацию следует скрыть.
Логи, аудит и защита от утечек
Закрытый контур не означает, что можно отказаться от контроля. Необходимо журналировать запросы, использованные документы, решения системы и действия пользователей. При этом в логах не следует без необходимости хранить полные персональные данные и содержимое конфиденциальных файлов.
Полезно внедрить маскирование реквизитов, телефонов, паспортных данных и другой чувствительной информации. Отдельно контролируются попытки вывести системные инструкции, обойти ограничения или заставить ассистента раскрыть данные из чужого контекста.
Для каждой функции нужно определить срок хранения запросов, порядок удаления информации и правила доступа администраторов к журналам. Чем выше критичность сценария, тем подробнее должен быть аудит.
С чего начать внедрение
Не стоит начинать с идеи "сделаем универсального цифрового сотрудника". Безопаснее выбрать один узкий процесс с понятным результатом и ограниченным набором данных. Например, поиск ответа по внутренним регламентам, классификация обращений или подготовка черновиков.
На пилоте проверяют не только качество ответов, но и устойчивость к ошибкам: что произойдёт при неполном документе, противоречивых правилах, вредоносной инструкции внутри файла или попытке получить чужие сведения.
После этого фиксируются разрешённые источники, список запрещённых операций, обязательные этапы проверки и метрики качества. Только затем имеет смысл расширять контур и подключать запись изменений или автоматическое выполнение действий.
Итог
Фраза "ИИ нельзя, потому что данные закрытые" не является техническим приговором. Можно выбрать локальное или серверное размещение модели, ограничить доступ режимом чтения, разделить подготовку результата и его исполнение, а критические операции передать на подтверждение сотруднику.
Главное - не воспринимать ИИ как единого робота, которому сразу выдают доступ ко всей компании. Безопасный ассистент - это набор строго ограниченных компонентов с понятными правами, журналированием и контролируемыми точками принятия решений. Такой подход позволяет получить пользу от автоматизации, не превращая корпоративные данные в бесконтрольный источник риска.