Разработка AI-системы для GovTech и Smart City

Почему AI-разработка для GovTech буксует на пилотах

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

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

Второе — ответственность. Внедрение AI в ведомстве упирается не в точность, а в вопрос, кто отвечает за решение системы, если оно ошибочно. Пока регламент не разводит случаи, где подпись остаётся за человеком, а где система лишь готовит проект решения, никто не переведёт процесс в промышленную эксплуатацию.

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

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

Что меняется в работе ведомства после AI-внедрения

Эффект от внедрения AI в ведомстве измеряется не точностью модели, а долей процессов, где ручное решение больше не требуется. Разбор входящего обращения, скана заявления, приложенной справки — первый кандидат на автоматизацию. Методологическую рамку берём из Принципов ответственного ИИ ОЭСР: решение модели объяснимо, а сотрудник видит, на каком основании выбрана маршрутизация.

Сокращение ручного разбора обращений

Типовые обращения — справка, продление, уведомление, жалоба на объект городской инфраструктуры — проходят без оператора: поля документа извлекаются автоматически, сверяются с ведомственными реестрами, проект ответа формируется заранее. Ручной разбор остаётся на нетиповых и спорных случаях; по массовым потокам 70–80% обращений закрываются без касания человеком. Время прохождения заявки сокращается с дней до часов — исчезает ожидание на этапе «передать в нужный отдел».

Единый реестр обращений и решений

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

Форматы работ: пилот, контур под ключ, сопровождение

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

Пилот на одном процессе

Пилот AI-проекта берёт один процесс с измеримым результатом — разбор обращений или проверку заявки на соответствие регламенту. Данные ограничиваем историческим срезом, а метрику (долю автоматически закрытых обращений, точность на контрольной выборке) согласуем до старта. Ограничение: это проверка гипотезы на срезе данных, без отказоустойчивости, ролевой модели и интеграций.

Полный контур под ключ

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

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

Этапы инженерной работы: от обследования до передачи

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

1. Обследование процессов и данных: интервью с операторами, реестр источников, ограничения по персональным данным.
2. Схема решения: какие модели и правила используются, где хранятся данные, как встраиваемся в действующие регламенты.
3. Сборка и настройка: подготовка данных, обучение и калибровка моделей, интерфейс оператора, служебный мониторинг.
4. Проверка на исторических данных: прогон на размеченных прошлых периодах, разбор ошибок по классам.
5. Обучение сотрудников: регламенты работы с системой, разбор спорных случаев, роли ответственных.
6. Приёмка AI-системы: сдача по согласованным метрикам, доступы, документация, резервные копии.
7. Передача в эксплуатацию и сопровождение: мониторинг качества, дообучение на новых данных, плановые обновления.

Проверка на исторических данных

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

Обучение и передача эксплуатации

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

Комплект поставки: схемы, политики доступа, регламенты

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

Политики доступа и разграничение ролей

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

Регламенты и инструкции для операторов

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

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

Кейс: обработка обращений в городской службе

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

Как работали до

Среднее время от поступления обращения до назначения исполнителя составляло около девяти часов: заявка ждала, пока до неё дойдёт оператор. Тема определялась по ключевым словам в заголовке, поэтому «яма во дворе» и «не вывозят мусор» регулярно уходили не в тот отдел — доля ошибок распределения держалась на уровне 18%.

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

Что изменилось после запуска

Модель размечает обращение по категории и подкатегории, извлекает адрес и признаки срочности, а правила распределения по нормативным срокам сразу выбирают исполнителя. Назначение происходит в момент приёма: среднее время сократилось до 12 минут, доля решений без ручного вмешательства выросла до 74%, ошибки распределения — до 3,5%.

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

Закрытый контур или облако: как выбирать размещение

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

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

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

Сомнения заказчика: качество, данные, ответственность

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

Что если система ошибётся?

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

Кто отвечает за результат?

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

Данные закрытые — как вести работу и что после акта?

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

Обсудим задачу: с чего начнём и что нужно от вас

Оценка AI-проекта в госсекторе держится не на модели, а на контуре: где живут данные, кто их владелец и какие согласования нужны до первого запуска. Поэтому старт работ начинается с разбора процессов и ограничений, а не с выбора инструментов — так оценка опирается на реальный объём работ, а не на предположения.

• Процессы: как задача решается сейчас, кто в ней участвует, сколько времени уходит на ручные операции и где теряется результат.
• Данные: примеры выгрузок, форматы, объём, доля неразмеченных записей, наличие персональных данных и требования к обезличиванию.
• Контур: где допустимо развернуть систему — изолированная сеть заказчика, закрытое облако или гибридная схема, какие каналы связи разрешены.
• Интеграции: с какими ведомственными и внутренними системами нужно связать решение, в каком формате и с какой частотой идёт обмен.
• Сроки: желаемая дата первого результата, что считаем пилотным запуском и по каким метрикам подтверждаем эффект.
• Ответственные: владелец процесса со стороны заказчика, специалист для выдачи доступов, тот, кто принимает работу.
• Ограничения: нормативные требования к обработке данных, правила журналирования и объяснимости решений.

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

• Ждать идеальных данных и откладывать старт: пока ведомственные реестры сводятся к единому виду, задача не двигается. Рабочий подход — взять минимальный согласованный набор, зафиксировать правила обогащения и наращивать качество по ходу.
• Выбирать технологию раньше процесса: заказчик сразу спрашивает про модель, но не описывает, где именно теряется время сегодня и по какому показателю считать результат. Без карты «как есть» и «как должно быть» успех нечем измерить.
• Ставить цель «внедрить искусственный интеллект во все службы» одной поставкой. Один узкий участок с понятной метрикой даёт работающий результат, тогда как расползание по всем направлениям заканчивается набором несвязанных опытов.
• Не назначать владельца процесса: решения согласуются между подразделениями месяцами, требования меняются на ходу. Нужен один ответственный за результат и один за данные.
• Не описать, как сотрудник будет работать с подсказкой системы: кто принимает окончательное решение, как оспорить вывод, что фиксируется в журнале. Без этого система формально сдана, но в ежедневную работу не вошла.
• Отложить обезличивание и разграничение доступа «на потом»: схема данных переделывается в конце, а передача сдвигается. Порядок доступа и правила обработки персональных сведений проектируются на обследовании, а не после.
• Проверять систему на подготовленных примерах вместо реального потока обращений. Показательные случаи не отражают разброс формулировок, поэтому качество на живом входящем потоке оказывается ниже ожидаемого.
• Ждать безошибочности: не заложить сценарий, когда система не уверена, и передачу спорного случая человеку. Отсюда разочарование — вместо пользы возникает недоверие к инструменту.
• Не планировать сопровождение и обновление правил после передачи: меняются формулировки обращений, регламенты и структура документов, и качество постепенно падает без плановой перенастройки.