AI use-case для госорганов: каталог типовых сценариев

Зачем нужен каталог типовых AI сценариев

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

Каталог AI use-case нужен как единая витрина проверенных сценариев. Он помогает выбрать, что запускать первым, и сразу зафиксировать минимальные требования к данным, интеграциям и безопасности. Тогда обсуждение начинается не с абстрактного «давайте внедрим AI», а с конкретного процесса и измеримого результата.

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

Важно помнить и обратную сторону: AI не всегда нужен. Если задача решается простыми правилами (например, проверка формата ИИН/БИН) или процесс жестко регламентирован без вариантов, дешевле и надежнее сделать обычную автоматизацию. А там, где много текста, много исключений и нужны подсказки «по смыслу», каталог сценариев быстро показывает, где AI даст реальную пользу.

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

Шаблон карточки use-case: как описывать сценарий

Хорошая карточка use-case помогает быстро понять, стоит ли запускать пилот, какие данные нужны и как измерять успех. Для госорганов и квазигоссектора это особенно важно: один и тот же запрос может упираться не в модель, а в доступы, сроки хранения и юридическую значимость ответа.

Начните с короткого описания одним предложением. Например: «Сотрудник находит ответ в регламенте за 30 секунд вместо 10 минут» или «Система заполняет реквизиты из входящего письма в карточку обращения». Чем проще формулировка, тем легче согласовать проект.

Дальше зафиксируйте входные данные: источники (НПА, регламенты, архив обращений, сканы писем, записи звонков), форматы (PDF, DOCX, скан, аудио, поля в CRM) и доступность. Обязательно уточните, где данные хранятся, кто владелец, есть ли ограничения по персональным данным. Частая ошибка - писать «данные есть», не уточнив качество сканов и долю документов без распознанного текста.

Опишите выход: что именно получает сотрудник и где это появится. Это может быть ответ с цитатой из регламента, черновик письма, заполненные поля (ИИН/БИН, номер договора, даты), краткое резюме звонка, подсказка оператору в окне контакт-центра. Если не указать место использования (ЭДО, СЭД, CRM, портал обращений), результат легко «выпадет» из реального процесса.

По метрикам обычно достаточно 3-4 показателей:

• точность (например, доля верно извлеченных реквизитов),
• время обработки (до и после),
• доля автоответов или автозаполнения без правок,
• процент случаев, где все равно нужен человек (эскалации).

Отдельно пропишите ограничения: язык(и) (русский, казахский), можно ли давать ответ «как решение» или только как подсказку, сроки и место хранения, требования к журналированию, запрет на передачу данных вовне. Эти пункты часто определяют архитектуру и то, можно ли внедрять сценарий в защищенном контуре.

Use-case 1: поиск по регламентам и нормативным документам

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

Работает это как справочник с диалогом: пользователь задает вопрос обычными словами (например, про сроки рассмотрения обращения, перечень документов, порядок согласования), а система находит релевантные фрагменты и формирует короткий ответ. Рядом должны быть источники внутри базы знаний: название документа, версия, дата и раздел.

Какие данные нужны минимум

Нужна актуальная библиотека документов: внутренние регламенты, приказы, методички, НПА, а также их структура (разделы, пункты) и контроль версий. Если один и тот же регламент существует в нескольких копиях, поиск начнет путаться, а ответы будут расходиться.

Что дает эффект и как измерять

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

Для контроля подойдут простые метрики:

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

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

Use-case 2: обработка обращений граждан и организаций

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

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

Что подготовить до пилота

Важно определить, где AI может предлагать варианты, а где только подсказывать. На практике помогает зафиксировать:

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

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

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

Use-case 3: извлечение реквизитов и заполнение карточек

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

Обычно извлекают ИИН и БИН, номера и серии, даты, суммы, адреса, наименования организаций, банковские реквизиты, контактные данные. Это особенно полезно для полуструктурированных документов, где нужная информация может быть в разных местах (письма, акты, доверенности).

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

Ключевые требования к данным и качеству

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

Удобная практика - делить результат на уровни:

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

Эффект и метрики

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

Для оценки смотрят на точность по полям (например, отдельно по ИИН, датам, суммам), долю документов, прошедших без вмешательства, и среднее время обработки одного документа. Если оператор раньше тратил 5-7 минут на карточку, то после внедрения проверка может занимать 1-2 минуты, а часть документов пройдет полностью автоматически.

Use-case 4: помощник оператора и контакт-центра

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

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

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

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

Оценивать результат удобно по метрикам:

• средняя длительность звонка,
• доля решенных с первого контакта (FCR),
• доля переводов на вторую линию,
• оценка качества (QA) и жалобы,
• доля корректно заполненных резюме и карточек.

На практике помощника часто запускают на собственной инфраструктуре, чтобы данные и записи не покидали контур. Здесь важны надежные серверы, интеграции и поддержка 24/7.

Пример сценария: один процесс, четыре AI функции

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

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

Связка из четырех функций превращает процесс в понятный конвейер:

• поиск по регламентам и НПА: вопрос своими словами, ответ с выдержкой и источником;
• классификация обращения: тема, тип услуги, приоритет и маршрут (в какое подразделение);
• извлечение реквизитов: ИИН/БИН, номер договора, адрес, даты, исходящий номер;
• помощник оператора: черновик ответа и список уточняющих вопросов, если чего-то не хватает.

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

Эффект лучше фиксировать замерами до и после на одном подразделении: среднее время обработки, доля возвратов на уточнение, число ручных исправлений реквизитов, доля ответов в срок. Через 2-4 недели пилота обычно уже видно, где AI реально помогает, а где требуется чистка данных или уточнение регламентов.

Требования к данным и интеграциям: что нужно заранее

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

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

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

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

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

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

Безопасность, доступы и соответствие требованиям

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

Первое - права доступа. Разделяйте доступ к источникам (реестры, внутренние базы, НПА, служебные письма) и доступ к интерфейсу. Часто сотруднику достаточно видеть ответ и документ-основание, но не иметь права открыть полный текст или выгрузить массив данных.

Второе - логирование. Полезно фиксировать, что спросили, что ответила система и на каких документах строился ответ. Это помогает при разборе жалоб, внутреннем аудите и обучении: «почему система сказала так».

Как снизить риск утечек

Обычно хватает базовых ограничений:

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

Юридическая аккуратность и размещение

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

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

Как внедрять по шагам: от пилота до тиражирования

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

Рабочая схема выглядит так:

• выберите один процесс и назначьте владельца результата (бизнес-заказчика), который принимает решение по качеству;
• соберите 50-200 типовых примеров из реальной работы и заранее задайте метрики;
• запустите пилот в ограниченном контуре с журналированием и обязательной ручной проверкой спорных случаев;
• встроите MVP в рабочее место сотрудника: кнопка, подсказка, черновик ответа;
• после стабилизации показателей расширяйте на подразделения и обучайте сотрудников короткими правилами «когда не доверять и эскалировать».

Если вы делаете поиск по НПА, на пилоте достаточно одного департамента и одной подборки документов. Сначала разберите причины ошибок: устаревшая редакция, похожие термины, отсутствие контекста. Эти причины важнее «средней точности».

Отдельно продумайте инфраструктуру и поддержку. В госсекторе часто критичны локальное размещение, контроль доступа и предсказуемая поставка оборудования. Здесь может помочь системный интегратор, который закрывает и вычисления, и внедрение, и поддержку 24/7. Например, GSE.kz как технологический производитель и интегратор в Казахстане поставляет рабочие станции и серверы локального производства и берет на себя сопровождение.

Частые ошибки и ловушки при запуске AI сценариев

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

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

Чаще всего встречаются такие ошибки:

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

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

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

Короткий чеклист и следующие шаги

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

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

Чеклист перед пилотом:

• назначен владелец процесса и согласованы метрики качества, скорости и экономии времени;
• составлен перечень источников данных и подтвержден доступ (включая требования по хранению и обезличиванию);
• подготовлен набор примеров и эталонов для теста и приемки;
• решено, где работает решение: на рабочих местах, на серверах в организации или в дата-центре;
• определены интеграции: куда возвращается результат (СЭД, CRM, контакт-центр, портал).

Следующий шаг простой: выберите 1-2 сценария с быстрым эффектом и понятными данными, соберите пилот на своей инфраструктуре и заложите время на настройку процессов вокруг него. Если параллельно нужно закрыть вопросы по серверам, рабочим местам, внедрению и сопровождению, это часто удобнее делать вместе с интегратором, который умеет работать в защищенных контурах и поддерживать решения 24/7, например GSE.kz.