LLM в госсервисах: где нужен отказ по умолчанию и передача человеку

Почему догадка опасна в госсервисе

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

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

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

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

Риск появляется, когда модель не видит данные из реестра или внутренней очереди, когда в обращении нет номера дела, даты или нужного документа, когда решение зависит от региона, категории льготы или нового регламента. Он особенно высок там, где ответ меняет выплату, срок, право или обязанность человека.

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

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

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

Где система должна сразу остановиться

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

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

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

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

В госсервисе спор о фактах почти всегда требует человека. Если заявитель пишет: "я подал справку вовремя, но в системе ее нет", модель не должна решать, кто прав. Она должна зафиксировать причину остановки, назвать, чего не хватает для ответа, и передать обращение сотруднику вместе с журналом входных данных.

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

Как настроить отказ по умолчанию

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

Что отделить сразу

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

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

На каждом таком шаге нужны стоп-условия. Лучше писать их не общими словами, а как проверяемые правила. Например: нет обязательного поля, дата в документе не читается, в разных частях заявления указан разный состав семьи, пользователь просит "сказать точно, положено мне или нет".

Как закрепить правила

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

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

Если команда использует инфраструктуру вроде RU LLM, полезно сразу включить маскирование PII и аудит-трейлы. Это уменьшает риск лишней передачи персональных данных по внутренним каналам и помогает быстро понять, почему система остановилась на конкретном запросе.

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

Какие сигналы запускают передачу человеку

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

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

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

Обычно хватает пяти триггеров:

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

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

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

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

Пример с заявлением на льготу

Гражданин подает заявление на льготу, заполняет форму и прикладывает фото справки. LLM читает текст на снимке и помогает разобрать документ быстрее, чем ручная проверка каждого файла.

Представим простую ситуацию. Анна фотографирует справку на телефон после приема у врача. На экране все выглядит нормально, но нижний угол бликует, и дата "действительна до" почти не видна.

Модель распознает фамилию, номер документа и название учреждения. Но срок действия она не видит. Именно здесь многие команды делают опасный шаг: позволяют системе достроить ответ по косвенным признакам и написать что-то вроде "документ принят".

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

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

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

Пользователь тоже должен видеть понятный следующий шаг. Например: "Мы получили заявление, но не смогли проверить срок действия справки по фото. Загрузите более четкий снимок или дождитесь проверки сотрудником". Такое сообщение не путает человека и не создает ложных ожиданий.

Так и работает отказ по умолчанию. Система помогает там, где данные читаются уверенно, и останавливается там, где ошибка меняет право человека на льготу. Это чуть медленнее, зато честнее для заявителя и спокойнее для службы, которая потом отвечает за решение.

Как сформулировать отказ без путаницы

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

Хуже всего работают расплывчатые ответы вроде "запрос требует дополнительной проверки" или "возникла сложность при обработке". Человек не понимает, отказали ему, что именно сломалось и нужно ли что-то делать самому. Такая неясность быстро превращается в жалобы и повторные обращения.

Понятный отказ строится из четырех частей:

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

Одной причины обычно достаточно. Если перечислить сразу пять возможных проблем, пользователь не поймет, что исправлять первым. Если не хватает справки о доходах, так и нужно писать. Если данные в заявлении не совпали с реестром, лучше назвать именно это, а не прятаться за фразой "обнаружены несоответствия".

Хороший текст выглядит так:

Система не может принять решение по заявлению на льготу автоматически. Не хватает сведений о доходах за последние 12 месяцев. Загрузите справку о доходах. После этого заявление проверит сотрудник ведомства. Ответ придет в личный кабинет в течение 3 рабочих дней.

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

Не стоит прятать отказ внутри длинного текста про правила сервиса, правовые основания и порядок рассмотрения. Такой блок можно показать отдельно, если он нужен по регламенту. Сам отказ должен отвечать на четыре вопроса: что произошло, почему, что сделать сейчас и кто продолжит работу.

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

Где команды чаще всего ошибаются

В таких проектах ошибка редко выглядит как явный сбой. Чаще система отвечает спокойно и убедительно, хотя по правилам должна была остановиться. Из-за этого команде долго кажется, что все работает нормально.

Первая частая ошибка - разрешить модели толковать норму закона под частный случай. Если человек пишет: "Я ухаживаю за родственником, мне положена льгота или нет?", модель легко достраивает ответ по похожим примерам. Но право на льготу зависит от деталей, документов и новых регламентов. Здесь нельзя просить модель "думать как специалист". Она должна либо вернуть общий порядок действий, либо передать вопрос сотруднику.

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

Не меньше вреда приносит пустая передача оператору. Модель остановилась, но человеку приходит только фраза "нужна ручная проверка" и исходное сообщение. Оператору приходится заново читать обращение, искать риск и восстанавливать контекст. На таких шагах теряются минуты, а иногда и смысл запроса. Лучше передавать короткую сводку: что спросил гражданин, какие данные нашлись, на каком правиле система остановилась.

Еще одна ошибка - прятать причину стопа за туманной формулировкой. Фраза "невозможно обработать запрос" только раздражает. Гораздо лучше написать прямо: "Система не может определить право на выплату без проверки документов. Запрос передан сотруднику". Это снижает путаницу и помогает при разборе жалоб.

Многие команды слишком долго смотрят только на скорость. Да, автоответ за 5 секунд красиво выглядит в демо. Но если один неверный ответ отправит человека по ложному маршруту, цена такой экономии слишком высока. В госсервисе полезнее медленный отказ с понятной передачей человеку, чем быстрый и уверенный вымысел.

Есть и более тихая проблема: команда не сохраняет причину остановки в логах и аудит-трейле. Потом трудно понять, где правило сработало правильно, а где модель ушла в догадку. Для систем с персональными данными и требованиями 152-ФЗ это уже не мелочь, а рабочий риск.

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

Короткая проверка перед запуском

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

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

Перед релизом стоит проверить пять вещей:

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

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

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

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

Что сделать дальше

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

Хороший пилот обычно узкий. Когда команда пытается сразу автоматизировать все обращения, она почти всегда пропускает опасные случаи и начинает исправлять их уже на живых пользователях.

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

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