Корпоративные ассистенты на базе ИИ обещают быстрый эффект, но на практике часто становятся источником новых рисков — от утечек данных до ошибочных решений. Почему «умный чат» — это еще не рабочий инструмент для бизнеса и какую инженерную инфраструктуру он требует на самом деле — разбирает IT-World. Текст о том, где проходит граница между полезной автоматизацией и дорогим заблуждением.
Когда в компании появляется первый сильный LLM, почти всегда повторяется одна и та же сцена. Кто-то из руководителей говорит: дайте модели доступ к документам, CRM, почте, и через неделю у нас будет умный помощник. Через месяц выясняется, что помощник действительно быстрый, но вместе со скоростью пришли новые проблемы. Сотрудники понесли в промпты лишние данные. В векторную базу попали документы, которые не должны были видеть все подряд. Модель стала уверенно отвечать там, где ей стоило промолчать. А потом ей захотели дать право что-то делать.
Здесь и возникает главная ошибка. Корпоративный ИИ до сих пор часто внедряют как отдельный инструмент. На практике его надо проектировать как часть управляемой экспертной системы. Не как чат с красивым интерфейсом, а как рабочий контур, у которого есть границы данных, права, источники, журналирование и понятная зона ответственности.
За последний год я слишком часто видел одну и ту же картину. Компания уже попробовала пару популярных моделей, сотрудники привыкли, что текст собирается за секунды, и в какой-то момент у руководства возникает ощущение, что до полноценного корпоративного ассистента остался один шаг. Обычно в этот момент и начинается самое дорогое заблуждение. Кажется, что если модель хорошо пишет, значит, она уже готова работать с внутренними процессами. На деле между красивым ответом в чате и рабочим помощником в бизнесе лежит целый пласт инженерии, который снаружи почти не виден.
Безопасный ИИ. Почему RAG-системы — это новая головная боль для службы безопасности
Именно в такой модели виртуальные ассистенты руководителя, коммерческого блока, поддержки или операционного управления начинают приносить реальную пользу. Они умеют быстро собирать картину по KPI, искать отклонения, поднимать регламенты, сравнивать факты из нескольких систем, готовить черновики решений. Но они не должны жить в режиме полной свободы.
Где корпоративный ИИ действительно помогает
Лучше всего ИИ работает там, где у людей много однотипной умственной рутины и где первая ошибка не оборачивается скандалом. Я бы отнес сюда черновики писем и справок, короткие выжимки из длинных документов, поиск по внутренней базе знаний, разбор повторяющихся запросов, первичную аналитику, утренние сводки по цифрам и отклонениям.
Готов ли российский бизнес к эре цифровых сотрудников? Обзор рынка ИИ-агентов
В одном из проектов мы собирали ассистента для руководителя коммерческого блока. До этого каждое утро аналитик вручную сводил цифры из CRM, задач, отчетов по воронке и комментариев от регионов. На подготовку уходило несколько часов, а к моменту встречи часть информации уже устаревала. После внедрения ассистент стал готовить утренний дайджест автоматически: показывал просадку по этапам, задержки по сделкам, аномальные отклонения по филиалам и ссылки на первоисточники. Ключевое слово здесь — «ссылки». Мы сразу заложили правило: никакого ответа без опоры на разрешенный источник. Если данных недостаточно, ассистент так и пишет, что информации не хватает.
Похожая история была и в сервисном контуре, где команде приходилось вручную разбирать поток заявок, следить за SLA и постоянно сверяться с меняющимися правилами маршрутизации. На бумаге сценарий казался простым: дать модели доступ к базе знаний, тикетам и внутренним инструкциям. На практике оказалось, что без аккуратной нарезки источников и жесткого разграничения ролей ассистент начинает смешивать оперативные подсказки для первой линии с внутренними комментариями руководителей. Снаружи это выглядит как мелкая настройка. Внутри проекта именно такие мелочи и решают, станет ИИ опорой для команды или источником лишней нервозности.
Где начинается лишняя работа
Сбой обычно начинается не на модели, а раньше — когда команда влюбляется в саму технологию и перестает честно обсуждать сценарий, ради которого все это затевалось. Первая зона риска — контекст. Люди очень быстро осваивают простую мысль: в чат можно кинуть письмо клиента, кусок договора, внутреннюю переписку, скриншот с цифрами и еще пару файлов сверху. Для компании это означает, что появился еще один рабочий канал, по которому поехали данные. А раз так, его надо вести примерно с той же дисциплиной, что почту, файлообмен и мессенджеры. Иначе все уходит в обход: документы начинают таскать через ИИ просто потому, что так быстрее.
Вторая зона риска — RAG и векторные базы. На словах все выглядит безопасно: мы не дообучаем модель на корпоративных данных, а просто даем ей доступ к документам. На практике появляется дополнительный риск. Кто имеет право загружать документы в индекс? Наследуются ли права доступа от исходной системы? Что происходит с устаревшими версиями документов? В одном пилоте мы остановили запуск буквально на сухом тесте, когда заметили, что ассистент по поддержке видит больше инструкций, чем должен видеть оператор первой линии. Проблема была не в модели. Проблема была в том, что в индекс попало слишком много.
На демо, как назло, все почти всегда красиво. Три вопроса, три ровных ответа, несколько ссылок на документы — и кажется, что осталось только пустить систему в работу. Настоящая проверка начинается позже, когда задаешь неприятные вопросы про исключения, старые версии регламентов, внутренние пометки и спорные кейсы. У нас не раз бывало, что после удачного прототипа приходилось не расширять, а сужать контур доступа. Просто потому, что именно там и «сидел» основной риск.
Третья зона риска — действия. Пока ассистент только отвечает, ущерб обычно ограничен качеством ответа. Но когда ему дают право создавать задачу, менять статус, отправлять письмо, инициировать платеж или вызывать внешние инструменты, уровень риска меняется принципиально. Здесь действует простое правило: читать можно шире, чем действовать. Для действий нужен отдельный контур подтверждения.
Самая недооцененная угроза
Самая неприятная история сейчас связана не столько с прямой утечкой, сколько с подменой инструкций через внешние источники. Модель читает письмо, вложение, веб-страницу, PDF, тикет или карточку в базе знаний и не всегда понимает, где заканчивается полезный материал и начинается чужая команда. Если в документ подмешана вредоносная инструкция, агент может принять ее за часть рабочего контекста. Поэтому сценарии, где ассистент читает внешние документы и при этом еще может что-то сделать, я бы вообще относил к повышенному риску. Здесь нельзя отстреляться одной настройкой и забыть. За такой системой нужно смотреть весь ее рабочий цикл.
Как выглядит безопасная архитектура
У безопасного корпоративного ассистента нет одной серебряной пули. Работает только многослойная конструкция.
Сначала определяется матрица сценариев. Для каких ролей нужен ассистент, какие задачи он решает, какие данные ему доступны, какие действия разрешены, а какие запрещены всегда. Уже на этом этапе обычно становится ясно, что одному ассистенту нужен доступ только к KPI и регламентам, а другому нельзя показывать финансовые документы или персональные данные без обезличивания.
Потом проектируется контур источников. Я сторонник простого принципа: у каждого ответа должен быть адрес. Если ассистент не может показать, откуда именно он взял вывод, этот ответ не должен попадать в управленческий контур. В наших проектах хорошо работает правило: нет цитаты — не ответа.
Следующий слой — права и журналирование. У ассистента не должно быть магического доступа ко всему подряд. Права на чтение надо наследовать от исходных систем, а не раздавать заново в RAG. Все чувствительные запросы, скачивания и вызовы инструментов должны логироваться так, чтобы потом можно было разобрать инцидент. Отдельный слой — подтверждение действий. Хороший ассистент не отправляет письмо клиенту, не меняет статус критичной сделки и не запускает чувствительный процесс молча. Он предлагает действие, объясняет, почему оно нужно, и ждет подтверждения человека.
Еще один обязательный слой — DLP и политика данных. С ИИ в компании приходится обращаться примерно так же, как с корпоративной почтой: завести правила, ограничения и понятный журнал. На практике это выливается в маскирование чувствительных полей, предупреждения пользователю, блокировку запрещенных типов данных, контроль вложений и сроки хранения.
Облако, частный контур и вопрос зрелости
Спор «облако или on-prem-развертывание» часто начинают слишком рано. Сначала нужно ответить на другой вопрос: какие данные и какие действия вы вообще готовы доверить ИИ? Для части сценариев облако вполне работает: например, черновики, суммаризация обезличенных материалов, низкорисковая аналитика. Для HR, финансов, юридической службы, внутренних регламентов, чувствительной клиентской истории и сценариев с привилегированным доступом планка уже другая. Там без частного контура, локализации данных, журналов доступа и понятной договорной модели разговор обычно получается слишком рискованным.
Когда доходит до выбора поставщика, я обычно смотрю не на размер модели и не на красивую демку. Гораздо важнее приземленные вещи, которые потом и спасают проект: уходит ли клиентский контент в обучение, где и как он хранится, можно ли его удалить без танцев с бубном и что вообще останется в журналах.
С чего начинать
Если компания только начинает путь, не надо сразу строить всевидящего корпоративного агента. Лучше начать с одного узкого сценария, где эффект понятен, а риск ограничен. Например, ассистент руководителя по утренней сводке, ассистент поддержки по регламентам или ассистент продаж по отклонениям в воронке. Важно, чтобы у него были разрешенные источники, режим «только чтение», журналирование и обязательная проверка выводов человеком.
На старте почему-то почти все мечтают о универсальном ассистенте для всей компании. По моему опыту, это верный способ быстро прийти к хаосу. Намного полезнее первые две недели потратить не на гонку за самой модной моделью, а на неприятные вопросы. Какие решения мы вообще готовы доверить машине? Где у нас действительно есть качественные источники? Кто владелец сценария? Кто будет разбирать инцидент? И кто нажмет стоп, если система пойдет не туда? Обычно именно на этом разговоре и видно, есть у проекта шанс на взрослое внедрение или он снова закончится красивым прототипом.
Корпоративный ИИ начинает приносить деньги и экономить время не там, где ему дали максимальную свободу, а там, где ему задали понятные границы.
Если совсем коротко, безопасный ИИ начинается не с выбора самой умной модели. Он начинается с нормальной инженерии вокруг нее. Когда у системы есть внятные права, понятные источники, журналы и человеческая проверка, она действительно помогает. Когда этого нет, компания получает не магию, а еще один источник утечек, ошибок и лишней самоуверенности.