ТЗ на корпоративного AI-ассистента: знания, права и оценка

Корпоративный ассистент начинается с границ знаний

Корпоративный AI-ассистент помогает сотрудникам находить и применять сведения компании. Его отличие от общего чат-бота — связь с внутренними документами, ролями и рабочими процессами. Поэтому ТЗ должно отвечать не только на вопрос «что он умеет», но и на вопросы «что ему доступно», «какой версии документа он доверяет» и «кто отвечает за исправление ответа».

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

Карта источников и владельцев

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

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

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

Права должны сопровождать поиск

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

Документация Azure AI Search описывает способы ограничения доступа на уровне документов и различия поддерживаемых механизмов. Это пример реализации принципа, а не универсальная гарантия любого RAG-решения. Выбранная архитектура должна доказать, что поиск применяет актуальные разрешения конкретного пользователя и не смешивает результаты между аудиториями.

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

Требования к ответу и ссылкам

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

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

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

Отдельные полномочия на действия

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

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

Рассматривайте содержимое найденного документа как данные, а не как новые инструкции для ассистента. В источнике может оказаться текст с требованием изменить правила, раскрыть секрет или выполнить постороннее действие. Такие вставки включаются в проверочный набор. Защита строится также на ограничении инструментов и полномочий, поскольку одной формулировки системного промпта недостаточно.

Набор оценки до настройки промпта

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

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

Сравнение версий проводится на одинаковом наборе с сохранёнными настройками модели, поиска и документов. Изменение одного источника может изменить ответ даже без изменения промпта. Записывайте причины регрессии и оставляйте воспроизводимый пример. Порог запуска выбирайте по последствиям ошибки и категории задачи, а не по общему рекламному числу «точности AI».

Контрольный пример с отзывом доступа

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

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

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

Эксплуатация и передача знаний

Назначьте владельца качества, владельцев источников и ответственного за техническую доступность. Кнопка «ответ неверный» полезна, только если сообщение приводит к разбору и исправлению. Опишите приоритеты: нарушение доступа, ошибочное обязательство и неудачная формулировка требуют разной реакции. Предусмотрите отключение опасной операции без остановки безопасного поиска, если архитектура это позволяет.

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

В приложении доступен текстовый шаблон ТЗ с реестром знаний, ролями и оценочным набором. Для первого выпуска ограничьте задачи так, чтобы команда могла проверить каждую значимую границу. Корпоративный ассистент готов к пилоту, когда известно не только, на что он отвечает, но и когда останавливается, кому передаёт вопрос и как подтверждается исправление ошибки.