ИИ в госуправлении: как делать полезные сервисы для государства

Чем госзаказ отличается от бизнеса

Среди наших заказчиков Правительство Московской области, муниципальный округ Истра, Рузский муниципальный округ и Одинцовский городской округ. Первой своей госзакупки мы, честно говоря, боялись. Сейчас реализованных госзаказов больше 20, и вот что здесь устроено иначе.

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

Что уже работает

• Голосовой помощник для жителей. Для Одинцовского округа мы сделали голосового ИИ-агента, который работает по большой базе знаний округа и помогает жителям по самым разным вопросам.
• Проверка закупочной документации. ИИ разбирает документы, сравнивает заявки и собирает выводы со ссылками на источники, а специалист их проверяет.
• Ответы сотрудникам. Ассистент находит ответ в регламентах и показывает, на какой документ опирается.
• Аналитика. Обращения и публичные обсуждения группируются по темам, и руководитель получает сводку с опорой на исходные материалы. За такой аналитикой общественного мнения к нам приходят часто.

Осенью 2025 года мы за короткий срок реализовали пять ИИ-проектов в разных категориях.

Какие ошибки нашлись на настоящих документах

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

• предлагал заменить верную ставку НДС 22 % на 20 % и считал 2026 год будущим;
• требовал три коммерческих предложения там, где цена рассчитана сметным или тарифным методом;
• автоматически требовал лицензию на отходы;
• объявлял работы по содержанию капитальным строительством и требовал допуск СРО;
• считал точные и круглые числа подозрительными;
• если документа не было в базе, делал вывод, что ГОСТ отменён;
• ссылался на постановления, которых нет в приложении;
• выдавал итог «33 находки», хотя сумма по категориям давала 31.

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

Какая была ошибка и что мы поменяли

Ошибка

Что поменяли

• Считал 2026 год будущим
  Текущая дата передаётся в анализ
• Выдумывал требования по одному слову
  Сначала определяет предмет работ и применимость требования
• Обязательно находил замечания
  Убрали обязательную квоту замечаний
• Цитировал то, чего нет
  Вся цитата проверяется по оригиналу
• «Нет в базе» = отменён
  Отсутствие в базе не считается доказательством
• Итоги не сходились
  Счётчики и резюме строятся из итоговых находок

После исправлений мы прогнали настоящий архив заказчика: обработаны 39 документов, ложные выводы о ставке НДС, цене, обеспечении и толщине слоя не повторились, 18 автоматических проверок прошли. Последнюю правку проверяли точечно, без нового прогона всего архива. В итоговом отчёте осталось 0 критических находок и 2 предупреждения, но само по себе это не мера качества. Настоящие замечания при этом остались. В контрольном примере, где в задании указано 12 стульев на 24 000 рублей, а в спецификации 10 на 20 000, система расхождение нашла. Без такой проверки легко было бы просто заглушить ИИ и радоваться, что замечаний стало меньше.

Какие правила мы из этого вынесли

Какой путь должна пройти найденная ошибка

1. НайтиНа настоящих документах
2. Понять причинуПравило, данные или неполный текст документа
3. ИсправитьПричину, а не один случай
4. Закрепить автотестомАвтоматической проверкой, чтобы ошибка не вернулась

1. Принимать работу на настоящих документах. На подготовленных примерах всё работает всегда.
2. Каждую найденную ошибку превращать в автотест. Иначе следующая правка вернёт её обратно.
3. Показывать источник каждого вывода. Цитата с указанием документа экономит специалисту больше времени, чем сам вывод.
4. Не считать число находок мерой качества. Их может стать меньше, потому что система стала точнее, а может, потому что она стала слепой.
5. Честно говорить, что проверено. В отчёте заказчику мы разделяли три статуса: проверено на его документах, проверен общий механизм, нужен исходный пакет. Случаи без документов мы не называли закрытыми, и успешные проверки не гарантируют, что других ошибок нет.

Три статуса в отчёте заказчику

• Проверено на пакетеРезультат подтверждён на присланных документах
• Проверен общий механизмЕсть автотест или контрольный пример, а конкретная закупка не воспроизведена
• Нужен исходный пакетСлучай нельзя считать закрытым без документов

Решение по документам при этом всегда принимает человек. ИИ готовит материал со ссылками, а специалист отвечает за вывод.

Как быть с данными

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

Другой подход — обезличивать данные на лету. Лёгкая модель в контуре заменяет названия организаций, ФИО и суммы на метки, обезличенный запрос уходит за пределы контура во внешнюю, в том числе зарубежную, модель, а настоящие данные подставляются обратно уже внутри. Подойдёт ли это в конкретном проекте, решается вместе со службой безопасности заказчика и с учётом требований, включая 152-⁠ФЗ, а для государственных и муниципальных информационных систем и приказ ФСТЭК № 117. Для таких систем эта схема, скорее всего, не подойдёт. Подробнее в статье про нейросети и персональные данные.

С 1 марта 2027 года к этому добавляется закон об ИИ 243-⁠ФЗ: Правительство определит случаи, где можно применять только суверенные и национальные модели, а действующие системы получат отсрочку при условии, что данные обрабатываются и хранятся в России. Сроки проекта стоит сверять с этой датой.

Как подготовиться к такому проекту

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