Генеративный ИИ для руководителя — 14 июня 2026 г. в 18:00:03.495
Генеративный ИИ для руководителя Часть 5 из 7. Как из модели проектируют цифрового ассистента В предыдущих статьях мы разобрали: ИИ начинается с данных, модель работает с токенами, обучение строится на прогнозе следующего фрагмента текста, а качество результата зависит от подготовки данных. Теперь вопрос: как из языковой модели сделать цифрового ассистента для работы ведомства? Ошибка многих ИИ-проектов — считать, что достаточно подключить модель и дать сотрудникам чат. Так появляется не ассистент, а неконтролируемый канал работы с информацией. Модель умеет писать текст. Но ассистент должен решать задачу: искать документы, учитывать права доступа, ссылаться на источники, соблюдать инструкции и передавать результат человеку на проверку. Сама по себе модель — еще не продукт. Ассистент появляется, когда она встроена в систему: с ролями пользователей, сценариями, ограничениями, источниками данных, журналированием и ответственностью человека. Первый этап — проектирование. Начинать нужно не с вопроса “какую нейросеть подключить?”, а с вопроса “какую задачу мы решаем?”. Например: сократить время подготовки справок, ускорить обработку обращений, помочь сотрудникам ориентироваться в регламентах. Для каждого сценария нужно описать: кто пользователь, какие данные нужны, какой результат должен получить, где нужна проверка человеком и какие действия ИИ выполнять не должен. Ассистент для обращений может группировать темы, предлагать проект ответа и указывать, каких данных не хватает. Но он не должен сам отправлять официальный ответ. Второй этап — архитектура решения. На этом этапе создается не “чат”, а цифровая система: интерфейс, база знаний, поисковый слой, языковая модель, системные инструкции, права доступа и журнал запросов. Схема: запрос сотрудника → поиск в базе знаний → проверка прав доступа → ответ модели → ссылка на источник → проверка человеком Часто используется подход RAG — Retrieval-Augmented Generation. Система сначала ищет нужные фрагменты в проверенной базе знаний, а потом модель формирует ответ. Это нужно, чтобы модель работала с документами организации, а не “вспоминала” ответ из общих знаний. Третий элемент — инструкции для модели. Это правила поведения ассистента: отвечать только на основе источников, не придумывать нормативные ссылки, отделять факты от предположений, предупреждать, если данных недостаточно, не раскрывать информацию без прав доступа и передавать спорные случаи человеку. Такая настройка называется prompt engineering (оперативное проектирование) — проектирование инструкций и шаблонов запросов. Четвертый элемент — интеграции. Ассистент должен работать рядом с системами организации: СЭД, базами знаний, реестрами, внутренними сервисами. Для этого используются API-интеграции — каналы обмена данными между системами. Пятый элемент — разграничение прав. Один сотрудник может видеть справочные материалы, другой — служебные документы, третий — данные по обращениям. Поэтому нужны RBAC или ACL — механизмы доступа по ролям. Без этого ассистент может показать лишнее. Шестой элемент — контроль качества. Для оценки ассистента используют evals — наборы контрольных вопросов и ожидаемых ответов. Для пилота можно подготовить 100–200 запросов: найти регламент, подготовить проект ответа, ответить при недостатке данных, проверить ситуацию без доступа, обработать конфликтующие источники. Проверяется не только грамотность текста, но и поведение системы: дает ли она источники, не придумывает ли факты, соблюдает ли права доступа и передает ли спорные случаи человеку. Главный вывод: цифровой ассистент — это не языковая модель с интерфейсом, а спроектированная система, встроенная в рабочий процесс. Эффект дает не сама нейросеть, а контур вокруг нее: задача, данные, роли, инструкции, интеграции, права доступа и контроль качества. В следующей статье разберем внедрение и сопровождение: самообновляемая база знаний, ИИ-агент и почему систему нельзя “запустить и забыть”.