AI-ассистент отвечает не по магии.
Он отвечает по тем данным, которые ему дали.
Если в базе лежат старые прайсы, три версии регламента, сканы без пояснений, таблицы с непонятными сокращениями и документ «финал_точно_новый_последний_3.pdf», ассистент не станет мудрым архивариусом. Он найдёт похожий фрагмент и построит на нём ответ.
Иногда правильный.
Иногда нет.


Снаружи это выглядит так, будто «ИИ ошибся». На деле часто ошиблась не модель, а база. Вернее, компания не подготовила документы так, чтобы по ним можно было безопасно и точно отвечать клиентам или сотрудникам.
Поэтому подготовка документов — это не скучный технический этап перед внедрением AI-ассистента. Это фундамент. Без него даже хорошая модель будет работать как стажёр, которому в первый день выдали архив за пять лет и попросили «быстро разобраться».
В компании почти всегда есть знания. Есть инструкции, регламенты, FAQ, таблицы, договоры, презентации, старые коммерческие предложения и переписки, где менеджеры уже сотню раз отвечали на одни и те же вопросы.
Формально информации много.
Но для AI-ассистента это ещё не база знаний.
База знаний — это не папка с файлами. Это управляемый набор актуальных источников, где понятно, какой документ действует сейчас, какой устарел, что можно показывать клиенту, что доступно только сотрудникам и кто отвечает за обновление.
Если этого нет, ассистент начинает работать по хаосу. А хаос он пересказывает уверенно. В этом и опасность.
Человек хотя бы может сказать: «Я не уверен, надо уточнить». AI-ассистент часто звучит так, будто он знает. Даже когда опирается на старый документ, который давно надо было убрать из рабочей базы.
На старте часто возникает понятная мысль: «У нас уже всё есть. Давайте загрузим документы, и ассистент будет отвечать».
Звучит логично. Работает не всегда.
AI-ассистент не знает внутреннюю историю компании. Он не понимает, что документ «Прайс апрель» уже неактуален, если рядом лежит «Прайс май». Он не знает, что регламент из старой папки отменили устно на планёрке. Он не догадается, что таблица была понятна только Марине из отдела продаж, потому что Марина сама её и вела.
Старые версии создают противоречия. Дубли мешают выбрать главный источник. Черновики могут попасть в ответы. Таблицы без пояснений дают обрывки смысла. Документы с персональными данными и внутренними пометками могут открыть лишнее не той аудитории.
Пример простой. В одном файле написано, что доставка занимает 5 дней. В другом — 10 дней. В третьем — «срок зависит от направления». Для сотрудника это может быть история изменений. Для ассистента — три возможных источника ответа.
Клиент спрашивает: «Когда будет доставка?»
Ассистент отвечает по старой версии.
Клиент недоволен.
Менеджер говорит: «Бот ерунду написал».
А бот просто прочитал то, что ему оставили.

Подготовка базы начинается не с загрузки файлов. Сначала нужно понять, что у вас вообще есть.
Самый простой первый шаг — сделать реестр документов. Не надо начинать с идеальной системы. Достаточно таблицы, где команда соберёт основные источники и проставит статус.
| Документ | Раздел | Статус | Владелец | Что сделать |
|---|---|---|---|---|
| FAQ по доставке | Поддержка | Требует проверки | Руководитель поддержки | Обновить сроки и условия |
| Прайс на услуги | Продажи | Актуально | Коммерческий директор | Добавить дату актуальности |
| Регламент обработки заявки | Продажи / CRM | Устарел | Руководитель продаж | Переписать под новый процесс |
| Инструкция для сотрудников | Обучение | Актуально частично | Руководитель отдела | Убрать старые ссылки |
| Типовой договор | Документы | Требует пояснений | Юрист | Подготовить краткое описание условий |
Обычно выясняется, что часть документов актуальна, часть устарела, часть никто не открывал год, а часть вообще живёт только в голове одного сотрудника. Прекрасный сотрудник, конечно. Но база знаний на одном человеке — это не база знаний, а риск с человеческим лицом.
После этого документы нужно разделить по задачам: продажи, поддержка, обучение, клиентский сервис, документы, оплата, логистика, статусы заявок, внутренние процессы. Это нужно не ради аккуратности. Разные сценарии требуют разных источников.
Клиентскому боту на сайте не нужны все внутренние регламенты. Ассистенту отдела продаж не нужны кадровые документы. Внутреннему помощнику сотрудников не стоит подмешивать рекламные тексты, если ему нужны точные инструкции.
У каждого раздела должен быть владелец. Не абстрактный «отдел», не «кто-нибудь из менеджеров», а конкретный человек или роль. Если раздел про доставку — отвечает логистика или поддержка. Если про цены — коммерческий блок. Если про договоры — юрист или ответственный за документы.
Без владельцев база быстро стареет. Все думают, что её обновляет кто-то другой. Кто-то другой, как известно, очень занят.
Хорошие документы для AI-ассистента — это не обязательно красивые документы. Главное, чтобы они были понятными, актуальными и полезными для ответа на реальные вопросы.
| Тип документа | Зачем нужен ассистенту | Что проверить перед подключением |
|---|---|---|
| FAQ | Отвечать на типовые вопросы клиентов или сотрудников | Актуальность, полноту, отсутствие дублей |
| Регламенты | Объяснять порядок действий | Не изменился ли процесс |
| Инструкции | Давать пошаговые подсказки | Понятны ли шаги и исключения |
| Описания услуг | Объяснять, что предлагает компания | Совпадают ли условия с сайтом и продажами |
| Тарифы и условия | Отвечать на вопросы о цене, сроках и правилах | Есть ли дата актуальности |
| Скрипты продаж | Помогать в консультации и квалификации | Нет ли устаревших обещаний |
| Методички | Обучать сотрудников | Нет ли противоречий |
| Правила эскалации | Передавать сложные вопросы человеку | Ясно ли, когда ассистент должен остановиться |
FAQ лучше собирать не из головы, а из реальных обращений. Если клиенты спрашивают «где мой заказ», а в FAQ есть только «каковы конкурентные преимущества компании», ассистенту будет трудно помочь. Он, конечно, может красиво рассказать про преимущества. Клиент в этот момент будет хотеть статус заказа.
Регламенты и инструкции полезны для внутренних ассистентов. Они помогают сотрудникам понять, как обработать заявку, какие документы запросить, какой статус поставить и когда подключить руководителя.
Описания услуг тоже нужны, но не в рекламном виде. Фразы вроде «индивидуальный подход» и «широкий спектр решений» ассистенту не помогают. Ему нужны конкретные ответы: что входит в услугу, что не входит, для кого она подходит, какие есть ограничения, какие данные нужны от клиента и когда стоимость считается отдельно.
Отдельно стоит подготовить правила эскалации. AI-ассистент должен знать не только как отвечать, но и когда не отвечать. Если клиент спорит по оплате, просит возврат, задаёт юридический вопрос или описывает нестандартную ситуацию, лучше собрать данные и передать обращение человеку.
Нормальный ассистент не геройствует. Он помогает там, где может, и передаёт дальше там, где должен.

Некоторые документы выглядят полезными, но могут навредить, если подключить их без подготовки.
Старые коммерческие предложения часто содержат индивидуальные условия. Один клиент получил скидку, другому считали старый тариф, третьему обещали срок под конкретную ситуацию. Если такие файлы попадут в базу, ассистент может принять частный случай за общее правило.
Договоры тоже требуют осторожности. В них много юридических формулировок, условий, исключений и ссылок на пункты. Ассистент может пересказать их слишком свободно. Если договоры нужны в базе, лучше подготовить отдельные пояснения: что можно объяснять клиенту, что нельзя трактовать автоматически и когда вопрос нужно передать юристу или менеджеру.
Переписки — ещё более рискованный источник. В них есть реальные вопросы и ответы, это полезно. Но там же есть персональные данные, эмоции, частные обещания, ошибки менеджеров и контекст, которого нет в самом сообщении. Лучше не загружать переписки напрямую, а извлекать из них типовые вопросы и нормальные ответы.
Таблицы без пояснений тоже часто дают сбои. Сотрудник понимает, что значат «Т1», «Коэф.» и «Доп.», потому что живёт с этой таблицей каждый день. Ассистент — нет. Для таблиц нужно пояснять колонки, сокращения, дату актуальности и правила чтения.
Главный принцип простой: если документ может быть неправильно понят, его нужно подготовить. Если документ содержит закрытую информацию, его нужно ограничить. Если документ устарел, его не должно быть в рабочей базе ассистента.
По каждой важной теме должен быть один главный источник.
Не пять документов «почти про одно и то же». Не презентация, FAQ, прайс и таблица, где условия немного отличаются. Один актуальный документ или раздел, которому доверяют все остальные материалы.
По тарифам — один актуальный прайс. По возвратам — один документ с правилами. По обработке заявки — один рабочий регламент. По доставке — один источник с текущими сроками и условиями. По услугам — одно согласованное описание.
Остальные документы либо ссылаются на главный источник, либо уходят в архив.
Важно: если ассистенту дали несколько противоречивых источников, ошибка — вопрос времени. Проблема будет не в модели, а в управлении знаниями.
Пример.
Компания подключила к ассистенту старый и новый прайс. Клиент спросил стоимость услуги. Ассистент нашёл старый документ и назвал прежнюю цену. Клиент сделал скриншот. Менеджер потом объяснял, что «бот ошибся».
На самом деле бот не ошибся. Он нашёл документ, который ему разрешили использовать.
AI-ассистент не должен выбирать между прошлым и настоящим. Это должна сделать команда до запуска.
Структура нужна не для красоты. Она помогает ассистенту находить правильные фрагменты, понимать контекст и меньше ошибаться.
Плохая структура — это папки «Разное», «Новое», «Для сайта», «Старое, но нужно» и «Документы 2024». Человеку ещё можно объяснить, что там лежит. Ассистенту лучше не устраивать квест.
Нормальная структура строится по темам и сценариям: оплата, доставка, возврат, обработка заявки, документы клиента, статусы заказа, работа с претензиями, частые вопросы, инструкции для сотрудников, обучение новых менеджеров.
Название файла тоже должно объяснять содержание. Не надо заставлять человека и систему гадать, чем «новый прайс 3» отличается от «прайс финал обновлённый».
| Плохо | Нормально |
|---|---|
| Прайс новый финал 2.pdf | Тарифы на услуги — клиентская версия — актуально с 01.05.2026 |
| Возвраты обсуждение.docx | Правила возврата оплаты: условия, сроки, исключения |
| Инструкция общая.docx | Обработка заявки клиента: этапы, статусы, ответственные |
| FAQ сайт старый.docx | FAQ для клиентского ассистента: доставка, оплата, документы |
| Скрипт менеджера.docx | Первичная консультация клиента: вопросы, ограничения, передача менеджеру |
Внутри документов тоже нужны понятные заголовки. Длинный файл без структуры плохо подходит для поиска ответов. Лучше разбить текст на разделы: когда применяется правило, что должен сделать клиент, что должен сделать сотрудник, какие есть исключения, когда вопрос передаётся специалисту.
Если документ огромный и в нём смешаны тарифы, договоры, инструкции для менеджеров, ответы клиентам и история изменений, его лучше разделить. Один большой файл кажется удобным для хранения, но часто неудобен для поиска.
Особенно важно указывать дату актуальности. Цены, сроки, условия доставки, правила оплаты, регламенты и описания услуг меняются. Если дата не указана, через несколько месяцев никто не понимает, можно ли доверять документу.
И ещё одно правило: клиентскую информацию нужно отделять от внутренней. В одном документе не должно быть публичного ответа клиенту и служебной кухни менеджера.
Плохо: «Клиенту говорим, что срок 5–7 дней. Если начнёт спорить, можно предложить скидку, но не больше 10%. Руководителю не говорить без согласования».
Такой документ нельзя подключать к клиентскому ассистенту. Его нужно разделить на клиентскую версию, внутреннюю инструкцию и закрытые правила для ответственных ролей.

Когда документы собраны и разделены, начинается чистка.
Цель чистки — убрать всё, что может привести к неправильному ответу.
Старые версии нужно вынести из рабочей базы. Архив может храниться отдельно, но ассистент не должен видеть старый документ как действующий источник. Не стоит надеяться, что он «поймёт по названию». Иногда поймёт. Иногда нет. Для бизнес-процесса это слабая стратегия.
Дубли нужно объединить. Если условия оплаты есть на сайте, в FAQ, в коммерческом предложении, в инструкции менеджера и в регламенте поддержки, надо решить, какой источник главный. Остальные документы должны либо ссылаться на него, либо содержать сокращённое описание без противоречий.
Противоречия нужно разобрать до запуска. Особенно в ценах, сроках, договорных условиях, возвратах, статусах заявок, скидках и порядке обработки претензий. AI-ассистент не должен быть арбитром между отделом продаж, поддержкой и бухгалтерией.
Мутные формулировки нужно переписать. Фразы «обычно можно», «по согласованию», «как правило», «при необходимости» и «срок зависит от ситуации» часто требуют пояснения.
Например, плохо: «Возврат возможен по согласованию».
Лучше: «Возврат рассматривает менеджер поддержки. Ассистент не принимает решение о возврате самостоятельно. Если клиент просит возврат, нужно уточнить номер заказа, причину обращения и передать вопрос менеджеру».
Персональные данные и служебные комментарии нужно убрать или ограничить. Если данные не нужны для ответа ассистента, им не место в базе. Если нужны — значит, нужно отдельно продумать доступы, сценарий использования и ограничения.
Одна общая база для всех — плохая идея.
У клиентского ассистента, внутреннего помощника, ассистента продаж и ассистента поддержки разные задачи. Значит, источники тоже должны быть разными.
| Документ | Сценарий | Уровень доступа | Тип ассистента |
|---|---|---|---|
| Клиентский FAQ | Ответы на сайте | Публичный | Бот на сайте |
| Регламент поддержки | Помощь сотрудникам | Внутренний | Ассистент поддержки |
| Скрипты продаж | Первичная квалификация | Ограниченный | Помощник менеджера |
| Договорные условия | Проверка сложных вопросов | Закрытый | Ассистент для ответственных ролей |
| Инструкция по CRM | Обучение сотрудников | Внутренний | Внутренний AI-помощник |
| Финансовые правила | Коммерческие решения | Закрытый | Ассистент руководителя или менеджера |
Клиентский ассистент должен видеть только то, что можно показывать клиенту: FAQ, публичные условия, инструкции, описания услуг, статусы, правила обращения и список документов.
Внутреннему помощнику нужны регламенты, инструкции, правила работы в CRM, порядок обработки заявок, обучающие материалы и шаблоны ответов. Но даже внутри компании доступы могут отличаться. Новому менеджеру не всегда нужны финансовые правила. Сотруднику поддержки не всегда нужны управленческие документы.
Ассистент продаж может работать с описаниями услуг, квалификационными вопросами, типовыми возражениями и правилами передачи лида. Но он не должен обещать цену, срок или результат, если для этого нужна оценка специалиста.
Для поддержки важны типовые проблемы, порядок диагностики, готовые ответы, статусы обращений и правила эскалации. Это зона повышенного риска: клиент может быть недоволен, раздражён или уже потерял время. Здесь ассистент должен быть особенно аккуратным.

Подготовить документы один раз мало.
Бизнес меняется. Меняются цены, условия, регламенты, услуги, сотрудники, процессы, статусы и правила обработки заявок. Если база не обновляется, ассистент начинает отвечать по прошлому.
Иногда прошлое было прекрасным. Но клиенту нужен ответ из настоящего.
У каждого раздела должен быть владелец. Продажи отвечают за условия и скрипты. Поддержка — за FAQ и типовые обращения. Юрист — за договорные пояснения. Операционный руководитель — за регламенты. Руководители отделов — за обучение сотрудников.
Дата последнего обновления должна быть видна в документе или в реестре. Для цен это критично. Для регламентов — тоже. Для инструкций по сервисам — особенно после изменения интерфейса или процесса.
Полезно вести журнал изменений: кто изменил документ, что изменил и почему. Через полгода никто не будет помнить, почему правило сформулировали именно так. А если будет помнить — этот человек, скорее всего, в отпуске.
Поводом для обновления базы становятся не только плановые проверки. Новые вопросы клиентов, повторяющиеся ошибки ассистента, изменение тарифа, новый процесс, обновление CRM, новый договорной шаблон — всё это должно попадать в базу.
Если клиенты постоянно спрашивают одно и то же, а в базе нет нормального ответа, это не проблема клиентов. Это пробел в документах.
После подготовки базы нужно проверить не только сами документы, но и ответы ассистента.
Тестировать надо не на идеальных вопросах из презентации, а на реальных формулировках. Пользователь редко пишет: «Опишите, пожалуйста, регламент обработки моего обращения». Он пишет: «где заказ», «почему так долго», «а деньги вернёте?», «я уже оплатил, дальше что?»
Система должна выдерживать такую реальность.
Для проверки нужна компактная таблица тестов.
| Вопрос | Правильный ответ | Источник | Можно отвечать автоматически | Когда передавать человеку |
|---|---|---|---|---|
| Где мой заказ? | Уточнить номер заказа и проверить статус | Инструкция по статусам | Да, если есть доступ к статусу | Если статус не найден |
| Можно вернуть деньги? | Уточнить номер заявки и причину, передать менеджеру | Правила возврата | Частично | Всегда при спорной ситуации |
| Сколько стоит услуга? | Дать условия расчёта или диапазон | Актуальные тарифы | Да, если цена фиксирована | Если нужна индивидуальная оценка |
| Какие документы нужны? | Дать список по сценарию | FAQ / инструкция | Да | Если ситуация нестандартная |
| Почему срок изменился? | Объяснить возможные причины и передать специалисту | Регламент поддержки | Частично | Если клиент недоволен |
Важно смотреть не только на финальный ответ, но и на источник. Если ответ выглядит правильно, но ассистент опирается на старый документ, это проблема. Сегодня повезло. Завтра нет.
Отдельно нужно определить красные зоны: жалобы, претензии, возвраты, юридические вопросы, споры по оплате, персональные данные, нестандартные скидки, ситуации без источника. По таким вопросам ассистент может собрать данные, но не должен принимать решение сам.
Иногда лучший ответ AI-ассистента — не ответить, а вовремя передать вопрос человеку.
После запуска ошибки всё равно будут. Вопрос не в том, будут ли они. Будут. Вопрос в том, что вы с ними сделаете.
Каждая ошибка показывает слабое место: ассистент не нашёл документ, документ был устаревшим, в базе не было ответа, формулировка была мутной, не сработала эскалация или пользователь спросил не так, как ожидали.
Ошибка — это не только проблема модели. Часто это сигнал, что в документах не хватает ясности.
Перед подключением документов к AI-ассистенту проверьте базу по пяти направлениям.
Если хотя бы половина пунктов вызывает сомнения, лучше не торопиться с подключением ассистента к документам. Иначе вы автоматизируете не знания, а беспорядок.
Автоматизация беспорядка — штука быстрая. Но редко полезная.
AI-ассистенту не нужна свалка документов.
Ему нужна база, где понятно, что актуально, какой документ главный, что можно показывать клиенту, что доступно только сотруднику, кто отвечает за обновление и когда вопрос нужно передать человеку.
Хороший AI-ассистент начинается не с выбора модели. И даже не с промта.
Он начинается с нормальных источников.
Если документы подготовлены, ассистент помогает быстрее отвечать клиентам, поддерживать сотрудников, находить инструкции, снижать нагрузку на менеджеров и не терять знания внутри компании.
Если документы не подготовлены, ассистент просто ускоряет хаос.
А хаос, как известно, и без ИИ прекрасно справлялся.