Задача: успевать в срок по каждому обращению
Типовой орган власти или подведомственное учреждение: от пары сотен до тысяч обращений граждан в месяц — через интернет-приёмную, почту, ВИС-порталы и бумагу. Каждое обращение надо зарегистрировать, понять суть, классифицировать по рубрикатору, направить исполнителю, проконтролировать срок и подготовить ответ. Сроки рассмотрения и порядок жёстко регламентированы законом о порядке рассмотрения обращений граждан; просрочка — это не «минус в отчёте», а основания для ответственности. Задача контура: снять с исполнителей рутину классификации и подготовки черновиков, не отдавая модели ни одного юридически значимого решения.
Отдельная боль — типовые обращения: значительная часть потока повторяется, и на них уже есть проверенные ответы. Найти «тот самый ответ позапрошлого года» в архиве вручную — отдельная работа, которая отлично автоматизируется.
Почему это сложно
Первая сложность — сам язык обращений: эмоции, орфография, смешение нескольких вопросов в одном письме, приложения в виде фотографий и сканов. Вторая — рубрикаторы ведомств: многоуровневые, с внутренними правилами толкования; ошибочная маршрутизация стоит дней срока. Третья — юридическая значимость: черновик должен опираться на действующую норму и прецедент, а не на «мнение модели»; ссылка обязана существовать. Четвёртая — контроль сроков: контур обязан не просто готовить тексты, а показывать состояние каждого обращения по сроку. Пятая — персональные данные заявителей: обращения содержат ПДн, часто — чувствительные категории, и весь контур живёт под 152-ФЗ.
Архитектура: от письма до черновика
Архитектура контура обработки обращений (текстовая схема)
Каналы: интернет-приёмная · почта · бумага (скан + OCR) · порталы
▼
Разбор обращения: суть, список вопросов, приложения
(структурированный JSON: темы, вопросы, срочность, ПДн-признак)
▼
Классификация по рубрикатору ──► маршрут исполнителю
▼
RAG-подбор: норма (действующая редакция) + прецеденты ответов
по базе регламентов и архиву обезличенных ответов
▼
Черновик ответа: по шаблону, со ссылками на норму и прецедент
├──► исполнитель правит/дополняет ──► подпись должностного лица
└──► сомнительный случай ──► сразу человеку, без автогенерации
▼
Контроль: срок по каждому обращению · очередь · эскалации
▼
Журнал: каждое действие модели и исполнителя ──► отчётность
Модели: GigaChat API (российский контур) или закрытый on-premise LLM
Ключевые решения контура. Классификация и разбор идут через структурированные выходы LLM — обращение превращается в строгий JSON со списком вопросов, а не «одно мнение на всё письмо». Подбор норм и прецедентов — RAG по версионируемой базе: модель получает только действующие редакции, ссылка в черновике ведёт к реальному документу; паттерны — в кейсе «LLM + RAG по базе документов». В качестве языковой модели для госсектора типовой выбор — GigaChat API в российском контуре либо закрытый on-premise вариант для чувствительных потоков; сравнение с YandexGPT — в обзоре «интеграции YandexGPT». Бумажные обращения оцифровываются OCR-слоем до всей цепочки.
Этапы внедрения
| Этап | Что получается | Бюджет | Срок |
|---|---|---|---|
| Аудит процессов и рубрикатора | карта каналов и маршрутов, оценка рубрикатора, план метрик и контура безопасности | от 90 000 ₽ | 1–2 недели |
| Пилот на одном канале | классификация + RAG-подбор + черновики на одном потоке, замер против базовой линии | от 480 000 ₽ | 4–6 недель |
| Промышленный контур | все каналы, интеграция с СЭД ведомства, контроль сроков, роли, отчётность | 0,9–1,2 млн ₽ | по ТЗ |
| Сопровождение | обновление базы норм, контроль качества черновиков, донастройка рубрикатора | по регламенту | — |
Бюджеты — прайс НЬЮ-ССТ на сентябрь 2026, «от», без НДС (УСН, п. 2 ст. 346.11 НК РФ). Сроки — типовые вилки проектов этого класса.
Типовые метрики «до/после»
Ниже — типовые вилки результатов внедрений этого класса в органах власти, а не отчёт конкретного ведомства. Базовая линия замеряется до старта: среднее время классификации и подготовки ответа, доля соблюдённых сроков.
- Первичная классификация и маршрутизация: типовое сокращение времени на 70–90% — с часов до минут.
- Подготовка черновика ответа: −40–60% времени исполнителя на типовых обращениях.
- Соблюдение сроков: рост доли обращений, закрытых без нарушений срока, — типовая вилка +10–25 процентильных пунктов за счёт раннего старта и контроля.
- Повторное использование прецедентов: 30–60% обращений закрываются на основе найденных прецедентов с минимальной правкой.
- Разбор бумажного потока: OCR-слой снимает 50–70% ручного ввода регистраторов.
Безопасность, 152-ФЗ и границы автоматизации
Обращения содержат персональные данные заявителей, иногда — чувствительные. Типовой контур: хранение и обработка в российских информационных системах, разграничение доступа по ролям, журналирование, обезличивание архива для аналитики — всё под 152-ФЗ; для систем, попадающих под требования по защите информации, рядом идёт трек аттестации — состав работ и рынок разобраны в кейсе «Аттестация ИСПДн». Граница автоматизации фиксируется регламентом: модель не подписывает ответы и не принимает решений по существу обращения; всё, что уходит заявителю, проходит через должностное лицо. Там, где положен ответ по существу сложного вопроса, контур помогает материалами — и не больше.
Об этом разборе. Это обезличенное типовое внедрение из нашей практики проектирования: имена ведомств не раскрываются (NDA), метрики даны типовыми вилками класса проектов; фактические значения фиксируются в КП и на приёмке. Ссылки на нормы в черновиках всегда проверяемы — модель не придумывает реквизиты документов.