Двенадцать вопросов ниже нужны для одного: понять, строил ли собеседник систему на ИИ в эксплуатации или продаёт обёртку над чужим сервисом. Разница видна не в терминах — терминами владеют обе стороны, — а в том, насколько охотно человек говорит про ошибки, про место хранения данных и про то, что произойдёт с системой через полгода без него.
Задавать их надо не вместо общего сценария первого созвона, а после него. Сначала выясняется, понимает ли подрядчик ваш процесс, объём операций и владельца результата: если не понимает, разговор про модели бессмысленен независимо от ответов. Эти двенадцать — второй слой, специфический для проектов с языковой моделью, и он нужен только если в решении действительно есть ИИ, а не просто набор правил, названный агентом.
Мы сами делаем такие проекты, поэтому оговорка обязательная: эти вопросы работают против нас так же, как против любого другого исполнителя. Если на созвоне с нами вы услышите «модель сама дообучится» или точность в процентах без указания выборки — реакция должна быть той же, что и с кем угодно другим. Список ниже написан, чтобы им можно было пользоваться, выбрав не нас.
Три вопроса, которые решают исход
Из двенадцати вопросов девять уточняют устройство решения, а три предсказывают, доживёт ли оно до эксплуатации. По отраслевым наблюдениям большая часть ИИ-проектов останавливается не на разработке, а между демонстрацией и повседневной работой — и ломаются они ровно в этих трёх местах.
- Что система делает, когда не знает ответа. Если на этот вопрос нет отдельного проектного решения, система будет выдумывать. Уверенный неправильный ответ клиенту дороже отсутствия ответа, а обнаруживается он позже — обычно от самого клиента. Мы разбирали, почему «не знаю» проектируется как штатное поведение, а не как сбой.
- Куда физически уходят данные. От ответа зависит и юридическая конструкция проекта, и его цена: модель в российском облаке, модель в вашем контуре и зарубежная модель через посредника — это три разных проекта с разной сметой и разной степенью риска.
- Кто ведёт базу знаний после запуска. Регламенты устаревают, прайс меняется, условия доставки правятся. Если после сдачи никто не назначен на обновление базы, качество ответов начнёт падать со второго месяца, и виноватым окажется «ИИ», а не пустая строка в регламенте.
Остальные девять полезны, но заменимы: их можно доспросить письмом. Эти три задаются голосом и с паузой после ответа — по паузе видно больше, чем по формулировке.
Блок 1. Модель и данные: вопросы 1–4
Здесь проверяется не эрудиция подрядчика, а то, принимал ли он архитектурное решение осознанно. Правильный ответ всегда содержит альтернативу и причину выбора: «взяли вот это, потому что у вас в потоке паспортные данные, а вариант дешевле не проходит по требованиям».
| Вопрос | Содержательный ответ | Ответ, после которого разговор закончен |
|---|---|---|
| 1. Какая именно модель и где она развёрнута | Названы конкретная модель и площадка: российское облако, свой сервер, агрегатор. Объяснено, почему выбрана эта, и чем её заменят | «Мы используем нейросеть» или «самую современную модель» без названия |
| 2. Уходят ли наши данные за пределы России | Прямое «да» или «нет» с указанием, что именно уходит: запрос целиком, фрагменты базы знаний, персональные данные клиентов. Названо, как это оформляется по 152-ФЗ | «Всё безопасно, у нас шифрование» — ответ не про то, о чём спросили |
| 3. Что будет, если поставщик модели станет недоступен | Описан резервный контур: вторая модель, переключение, деградация качества на время переключения, стоимость этого запаса | «Такого не случится» или «переключимся за пару дней» без описания как |
| 4. Кто платит за вызовы модели и как считается сумма | Названа цена обращения и от чего она зависит. Порядок для текстового обращения на сентябрь 2026 года — 1–4 ₽, голос и документы дороже | «Это входит в поддержку» без цифры расхода и без потолка |
На втором вопросе особенно полезно не принимать общий ответ. Прямая оплата зарубежных сервисов из России невозможна, доступ идёт через рублёвых посредников — и это не запрет, а ограничение, которое надо назвать вслух и заложить в риски. Подрядчик, который умалчивает о посреднике в схеме, скорее всего умалчивает и о том, что при его отключении встанет вся система. Если в вашем потоке есть персональные данные, разумный разговор быстро приходит к модели в собственном контуре — с понятным удорожанием инфраструктуры и понятной причиной.
Блок 2. Ошибки: вопросы 5–8
Самый информативный блок. Инженер про ошибки говорит спокойно и в цифрах, потому что он их считал. Продавец про ошибки говорит неохотно и переводит разговор на возможности.
| Вопрос | Содержательный ответ | Ответ, после которого разговор закончен |
|---|---|---|
| 5. Что система делает, когда не знает ответа | Описано штатное поведение: честное «не знаю», передача человеку, стоп-темы, по которым бот молчит всегда | «Модель ответит по смыслу» — это описание выдумывания своими словами |
| 6. Как измеряется доля неверных ответов | Названа метрика, размер и происхождение выборки: например, прогон на 500 реальных обращениях до запуска и выборочный контроль после | «Точность 99,9 %» без выборки и без указания, что делается с остатком |
| 7. Что происходит с ошибкой дальше | Есть журнал: ошибка видна, помечается, попадает в очередь правок; названо, кто её разбирает и с какой периодичностью | «Мы всё поправим» — без места, где ошибка фиксируется, править нечего |
| 8. Кто отвечает перед нашим клиентом за неверный ответ | Ответственность перед клиентом остаётся на вас, и подрядчик это проговаривает; в договоре описано, за что отвечает он — за отклонение от согласованной метрики | «Ответственность на нас» — красиво звучит и обычно не подтверждается договором |
Любая цифра точности бессмысленна без трёх уточнений: на какой выборке измеряли, что считали ошибкой и что делается с оставшимися процентами. Даже 2 % ошибок при 5 000 обращений в месяц — это 100 неверных ответов клиентам, и вопрос не в том, как их избежать, а в том, как их вовремя увидеть. Разумная конструкция — метрики качества, зафиксированные в договоре вместе со способом измерения; без способа измерения любая цифра в договоре недоказуема.
Сравнение в две колонки, три строки. Слева «Содержательный ответ», справа «Ответ, закрывающий разговор». Строка 1 — точность: слева «доля неверных ответов измерена на выборке 500 реальных обращений», справа «точность 99,9 %». Строка 2 — данные: слева «модель в российском облаке, персональные данные не покидают контур», справа «у нас всё зашифровано». Строка 3 — эксплуатация: слева «базу знаний ведёт ваш методист, 6 часов в месяц», справа «модель сама дообучится». Внизу подпись: «Слева — проверяемое, справа — непроверяемое». Чертёжный стиль, подписи по-русски.
Блок 3. Эксплуатация и деньги: вопросы 9–12
Последний блок отвечает на вопрос, во что обойдётся жизнь с системой. Здесь чаще всего расходятся ожидание и реальность: подрядчик честно называет цену своей поддержки, а заказчик слышит в ней стоимость месяца целиком.
| Вопрос | Что должно прозвучать в ответе |
|---|---|
| 9. Кто обновляет базу знаний после запуска | Названы роль на вашей стороне и объём в часах: обычно 4–8 часов методиста в месяц. Если роль не названа — её нет |
| 10. Что входит в поддержку 20 000–30 000 ₽/мес | Перечень работ и срок реакции. Отдельно — что в неё не входит: новые сценарии, изменение интеграций, рост объёма |
| 11. Как отслеживается качество через три месяца | Выборочный контроль диалогов, отчёт с долей эскалаций и неверных ответов, регулярность проверки и кто её делает |
| 12. Что мы получим, если завтра расстанемся | Исходники, промпты, база знаний, доступы, инструкция по развёртыванию. Всё это — на вашей стороне с первого дня, а не в момент расставания |
Десятый вопрос стоит развернуть цифрами, потому что расхождение здесь самое большое. Ниже — модельный месяц агента с базой знаний на 5 000 обращений: слева то, что называет подрядчик, ниже — всё остальное, что всё равно будет оплачено, только из другого кармана.
Это не обман со стороны подрядчика: он назвал цену своей работы и не обязан угадывать ставку вашего методиста. Обман начинается там, где на прямой вопрос «сколько будет стоить месяц целиком» звучит «двадцать пять тысяч». Полную раскладку по статьям мы разбирали в материале про структуру расходов на ИИ-агента; для созвона достаточно спросить, какие строки этого списка подрядчик закрывает сам, а какие остаются на вас.
Проверка на демонстрации: два вопроса вместо двенадцати
Если времени на длинный разговор нет, демонстрация закрывает половину списка за десять минут. Условие одно: спрашивает не подрядчик, а вы, и оба вопроса придумываются заранее.
- 1Каверзный вопрос внутри базы знаний. Возьмите случай, где в ваших регламентах есть исключение: «доставка бесплатная от 5 000 ₽, но не в выходные и не в область». Проверяется, дотягивается ли система до исключения или отвечает по общему правилу. Этот вопрос показывает качество подготовки данных.
- 2Вопрос заведомо за пределами базы. Спросите то, чего в регламентах нет вовсе. Здесь важен не ответ, а поведение: система должна сказать, что не знает, и предложить человека. Если она уверенно сочинила правдоподобный ответ — вы только что увидели, как она будет разговаривать с вашими клиентами каждый день.
- 3Третий, необязательный: попросите показать журнал этих двух диалогов. Если у подрядчика есть место, где видно, какой фрагмент базы знаний использовался и почему получился такой ответ, — качеством занимались. Если журнала нет, разбирать будущие жалобы будет не по чем.
На первый вопрос система почти всегда отвечает хорошо: демонстрацию готовят, базу знаний под неё вычищают. Второй вопрос подготовить нельзя — он проверяет не содержание, а конструкцию. Именно поведение при незнании определяет, сколько раз в месяц вам придётся извиняться перед клиентом за то, что сказала система.
Схема из двух ветвей. Верхняя: «Вопрос внутри базы знаний (исключение из правила)» → два исхода: «нашла исключение — данные подготовлены» и «ответила общим правилом — база сырая». Нижняя: «Вопрос за пределами базы» → три исхода: «сказала «не знаю» и позвала человека — норма», «переспросила и уточнила — норма», «сочинила правдоподобный ответ — отказ от проекта». Сбоку отдельный блок «Журнал диалога: какой фрагмент базы использован» со стрелками к обеим ветвям. Чертёжный стиль, подписи по-русски.
Что меняется с 1 сентября 2026 года
С 1 сентября 2026 года действует регулирование ИИ: маркировка сгенерированного контента и требования к обработке персональных данных в таких системах. Компаниям рекомендуется завести внутреннюю политику использования ИИ. Для проверки подрядчика важно не то, знает ли он формулировки закона, а то, различает ли он свою зону и вашу.
- Что ложится на подрядчика: техническая возможность маркировать сгенерированный контент, журналирование обращений к модели, локализация хранения данных, оформление поручения обработки персональных данных, если он что-то обрабатывает у себя.
- Что остаётся на вас: вы оператор персональных данных и остаётесь им независимо от того, кто написал код. На вас — согласия, политика, уведомления, решение о том, что именно помечать, и ответственность перед клиентом за содержание ответа.
- Что должно прозвучать на созвоне: подрядчик сам, без наводящего вопроса, называет эту границу. Если про 152-ФЗ и маркировку заходит речь только после вашего вопроса — считайте это слабым сигналом, но сигналом.
- Чего не должно быть: обещаний «мы возьмём всю ответственность на себя». Оператором данных остаётесь вы, и это не переносится договором, каким бы он ни был.
Отдельно про маркировку: она касается контента, который вы публикуете, а не служебных ответов внутри чата поддержки. Что именно помечать и в каких случаях — вопрос вашей внутренней политики; мы разбирали границы отдельно в материале про маркировку ИИ-контента. Подрядчик обязан обеспечить техническую возможность, а решение принимаете вы.
Когда эти вопросы задавать не надо
Список из двенадцати вопросов не бесплатен: он отнимает у разговора минут сорок и у обеих сторон — подготовку. Есть четыре ситуации, где он лишний.
- В решении нет модели. Если задача — маршрутизация заявок по правилам, автозаполнение карточки или уведомление о статусе, языковая модель там не нужна, и вопросы про токены и галлюцинации не к месту. Уточните сначала, что именно называется ИИ в предложении: половина «ИИ-агентов» на рынке — это набор условий, и это нормально, пока так и написано.
- Вы покупаете готовый сервис по подписке. Тогда работает другой чек-лист — про выход из сервиса: выгрузка данных, стоимость переезда, что будет, если поставщик закроется. Вопросы про архитектуру модели поставщику подписки задавать бессмысленно — он вам её не поменяет.
- Бюджет проекта меньше 150 000 ₽. Сорок минут созвона плюс подготовка ответов — заметная доля такого проекта. Ограничьтесь тремя ключевыми вопросами и вопросом о том, что останется у вас при расставании.
- Вы ещё не решили, нужен ли ИИ вообще. Тогда сначала считается процесс: объём операций, время на операцию, стоимость часа. Мы разбирали это в материале про окупаемость автоматизации — если экономика не сходится, ответы про модель уже не важны.
И последнее. Хороший ответ на эти вопросы не гарантирует хорошего проекта — он гарантирует только то, что собеседник понимает, о чём говорит. Гарантию даёт другое: небольшой оплаченный этап с измеримым результатом, после которого вы решаете, продолжать ли. Разговор экономит вам неделю, пробная работа — три месяца.
Про возможности модели расскажет любой. Инженера от продавца отличает готовность подробно говорить про её ошибки.
