Корпоративный ИИ-ассистент: как не превратить его в игрушку

Почему корпоративные ИИ-ассистенты часто не приживаются

Главная причина — отсутствие конкретной задачи. Компании запускают общий чат и предлагают сотрудникам «использовать ИИ в работе», но не определяют, какие операции он должен ускорить, какие данные ему доступны и кто отвечает за качество. В результате каждый применяет инструмент по-своему, а руководство не может оценить эффект.

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

Подход к единой рабочей точке и подключению внутренних источников подробнее разобран в статье о внутреннем ИИ-портале.

Сценарии, которые дают пользу

Лучше всего подходят повторяющиеся задачи, где сотрудник тратит время на поиск, сбор данных или подготовку первого варианта, но окончательное решение остаётся человеку.

• Поиск по регламентам: краткий ответ со ссылкой на конкретный документ и раздел.
• Подготовка документов: черновик письма, заявки, протокола или отчёта по утверждённой структуре.
• Разбор обращений: определение темы, извлечение фактов и передача готового контекста ответственному.
• Сводки для руководителя: объединение данных по задачам, встречам и отклонениям без автоматического управленческого вывода.
• Подсказки по процессу: последовательность действий, обязательные поля и условия передачи на согласование.

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

Доступы, база знаний, документы и роли

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

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

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

Пример: ассистент помогает подготовить документ

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

1. Сотрудник описывает задачу обычными словами и прикладывает исходные данные.
2. Ассистент определяет подходящий утверждённый шаблон и проверяет права пользователя.
3. Система извлекает известные значения и задаёт вопросы только по отсутствующим обязательным полям.
4. Формируется черновик с указанием использованного шаблона и источников данных.
5. Сотрудник проверяет документ и самостоятельно отправляет его на согласование.

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

Метрики использования

Количество открытий чата само по себе не показывает пользу. Для пилота нужны метрики, связанные с выбранным процессом.

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

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

План запуска пилота

1. Выберите одну операцию. У неё должны быть понятные участники, входные данные и измеримый результат.
2. Соберите источники. Оставьте только действующие документы и назначьте владельцев.
3. Опишите ограничения. Зафиксируйте доступы, запрещённые действия и случаи передачи человеку.
4. Подготовьте проверочные примеры. Используйте реальные типовые и пограничные запросы без лишних персональных данных.
5. Запустите небольшую группу. Пилот должен дать обратную связь до масштабирования.
6. Сравните показатели. Проверьте время, качество, повторное использование и стоимость обработки.

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