ИИ в государственных учреждениях
Центр компетенций по ИИ
От первой задачи к работающему пилоту
Как собрать команду, проверить пользу и подготовить решение для других учреждений.
Материал к вебинару «ИИ в государственном учреждении» · 2 октября, 11:00 мск.
Программа и регистрация на nvidia-russia.ru →
«Как вы можете нам помочь в создании Центра компетенции по ИИ»
За ним стоит несколько практических решений: какие задачи взять первыми, кто будет отвечать за результат и что понадобится команде после запуска. Начать проще, когда есть понятная рабочая задача и способ проверить, стало ли лучше.
Разберём путь от первого запроса до работающего сервиса — и покажем, что меняется, когда к нему подключается второе учреждение. По дороге будут разные версии документов, ошибка помощника и решение команды о дальнейшей работе.
С какой задачи начинается центр
Далее — вымышленный пример для объяснения подхода. Это не описание выполненного проекта QBS и не обещание конкретных результатов.
В учреждении сотрудники регулярно уточняют, как согласовать служебную записку. Кто-то ищет инструкцию в общей папке, кто-то спрашивает опытного коллегу. Руководитель предлагает проверить помощника, который находит ответ и показывает нужный пункт документа.
Команда начинает с одного процесса и небольшой группы пользователей. До разработки она выясняет, какие вопросы повторяются, сколько времени занимает поиск и кто сможет проверить ответы. Так появляется первая задача центра — с владельцем, границами и критериями результата.
Центр берёт на себя организацию этой работы. В предлагаемой модели у него пять основных функций:
- Собирать задачи. Выяснять, где сотрудники тратят время, как часто повторяется процесс и можно ли измерить улучшение.
- Проверять решения. Сравнивать подходы на одинаковых заданиях и данных, фиксировать ошибки и выбирать подходящий инструмент.
- Поддерживать общие компоненты. Организовать доступ к моделям, поиску по документам, вычислительным ресурсам и средствам контроля качества.
- Передавать опыт. Готовить инструкции, обучать пользователей, сохранять требования и результаты пилотов для повторного использования.
- Отвечать за развитие. Принимать запросы на изменения, контролировать работу сервисов и планировать следующие проекты.
Работающий пилот на понятной задаче, проверенные результаты и команда, которая умеет его поддерживать. Количество купленных GPU само по себе не показывает пользу центра.
Для одного учреждения
На старте можно выделить рабочую группу из существующих подразделений. Её задача — довести один сценарий до использования сотрудниками и описать, как запускать следующие. Отдельный штат и собственная серверная определяются объёмом работы.
Какая команда нужна и кто за что отвечает
При сборе документов обнаруживаются две версии регламента. Обе лежат в общей папке, и по названию непонятно, какая действует. Если просто загрузить их в помощника, он может дать убедительный ответ по устаревшему порядку.
Владелец процесса вместе с ответственным за документы выбирает действующую версию. Инженер настраивает поиск, ИТ- и ИБ-специалисты проверяют доступ. Эта небольшая ситуация объясняет, зачем центру нужны разные роли. Часть из них можно совмещать или закрывать совместно с подрядчиком.
| Роль | За что отвечает | Что должно быть на выходе |
|---|---|---|
| Руководитель центра | Приоритеты, ресурсы, взаимодействие с учреждениями | План работ и решение по результатам пилота |
| Владелец рабочего процесса | Реальная задача, пользователи, проверка пользы | Описание процесса и согласованные критерии приёмки |
| Разработчик / инженер ИИ | Прикладное ПО, модели, интеграции, тесты | Рабочее решение и воспроизводимые проверки |
| ИТ и эксплуатация | Размещение, доступность, резервные копии, мониторинг | Порядок запуска, восстановления и поддержки |
| Ответственный за документы и данные | Актуальность источников, качество, права на использование | Подготовленный набор данных и порядок обновления |
| ИБ, юридическая и закупочная функции | Условия обработки данных, договорные и закупочные требования | Согласованные ограничения и требования к проекту |
Обучение стоит строить вокруг будущей работы: пользователи учатся проверять ответы, специалисты — обновлять источники и разбирать ошибки, руководители — читать показатели пилота. Инструкции и документация должны оставаться у команды центра.
Как проверить, что помощник действительно помогает
Для первого проекта удобен ограниченный внутренний процесс: есть владелец задачи, доступны согласованные данные и можно сравнить работу до и после внедрения. Ниже — варианты для обсуждения, а не описание выполненных проектов QBS.
Поиск по регламентам
Сотрудник получает ответ со ссылками на документы. Измеряем время поиска, правильность источников и долю вопросов, на которые система обоснованно отказалась отвечать.
Подготовка черновиков
Система помогает собрать проект документа по утверждённому шаблону. Измеряем полное время доработки и число исправлений. Финальный текст утверждает сотрудник.
Разбор входящих обращений
Система предлагает тему, краткое содержание и исполнителя. Проверяем правильность распределения и пропущенные важные обстоятельства. Решение по обращению остаётся у уполномоченного специалиста.
Перед выбором оцените каждый сценарий по пяти вопросам: насколько часто он возникает, сколько времени занимает, готовы ли данные, какова цена ошибки и кто будет пользоваться результатом. Если документы ещё не собраны, первым этапом проекта станет их подготовка.
Один рабочий вопрос
«Как согласовать служебную записку?»
- 01Найти нужную папку и регламент
- 02Проверить, что версия действующая
- 03Прочитать документ и найти нужный пункт
Сотрудник сам собирает ответ из источников.
- 01Задать вопрос обычными словами
- 02Получить краткий ответ и ссылки на пункты
- 03Открыть источник и проверить ответ
Помощник собирает ответ. Сотрудник его проверяет.
Пример сценария для пилота. Качество ответов и изменение времени работы нужно измерить на документах учреждения.
На проверке появляется ошибка. Что делает команда?
В нашем учебном сценарии помощника спрашивают о сроке согласования. Он уверенно называет два рабочих дня. Сотрудник открывает источник: в документе описан маршрут, но срока нет. Такой ответ нельзя принимать, даже если рядом стоит ссылка.
Учебная демонстрация QBS · заранее подготовленный пример
Можно ли доверять этому ответу?
Это разбор на вымышленном документе, а не работа подключённой ИИ-системы. Все варианты ответов написаны для демонстрации проверки.
«За сколько дней согласуют служебную записку?»
«Служебную записку согласуют за два рабочих дня. Основание: У-01, пункт 3».
Ссылка есть. Но подтверждает ли она срок?
Учебный регламент У-01, версия 2, пункт 3:
«Автор направляет служебную записку руководителю подразделения. После согласования документ передаётся ответственному исполнителю».
В этом фрагменте нет срока согласования.
3. Посмотреть корректный вариант ответа
«В предоставленном пункте регламента срок согласования не указан. Описан только маршрут: руководитель подразделения → ответственный исполнитель. Для ответа о сроке нужен другой действующий источник или уточнение у владельца процесса».
Что проверили: каждый существенный вывод должен подтверждаться источником. Отсутствие ответа тоже нужно уметь распознавать.
У-01 — вымышленный документ только для этого примера. Он не устанавливает порядок работы какой-либо организации.
Команда сохраняет ошибку в наборе проверочных вопросов, разбирается в её причине и дорабатывает решение. Затем повторяет проверку, включая вопросы без ответа и запросы к закрытым документам. Одной исправленной реплики недостаточно для запуска.
Что нужно пройти до передачи в работу
- Ограничить задачу. Выбрать один процесс и определённую группу пользователей. Например, ответы на вопросы по согласованию служебных записок.
- Подготовить источники. Собрать действующие регламенты, убрать устаревшие версии, назначить ответственного за обновление и определить доступ.
- Составить тестовые вопросы. Включить типовые ситуации, неоднозначные вопросы и случаи, когда ответа в документах нет. Отдельно проверить запросы к закрытым разделам.
- Сравнить результаты. Сотрудники выполняют сопоставимые задания с помощником и без него. Учитывается время чтения источника, проверки и исправления ответа.
- Принять решение. Запустить решение, доработать его или остановить проект, если качество либо затраты не соответствуют согласованным критериям.
Полное время выполнения задачи; долю правильных ответов; наличие подтверждающих источников; число существенных исправлений; нарушения доступа; стоимость обработки и сопровождения. Пороговые значения согласуют до тестирования.
В учебном сценарии команда сравнивает сопоставимые задания с помощником и без него: учитывает поиск, чтение источника и исправления. Если критерии не выполнены, пилот дорабатывают или останавливают. Если выполнены — согласуют запуск и поддержку.
Сэкономленное время показывает высвободившуюся ёмкость команды. Оно превращается в экономию бюджета только при соответствующем изменении расходов. Для учреждения результатом может быть и обработка большего числа задач тем же составом сотрудников.
Первый сервис заработал. Как подключить второе учреждение?
Появляются дополнительные вопросы: кто принимает заявки, как распределяются ресурсы, кто оплачивает сопровождение и как разделяются данные. Общими могут быть методика проверки, программные компоненты и инфраструктура. Доступ к документам каждого ведомства должен задаваться отдельно.
В нашем примере второе учреждение просит такой же поиск по регламентам. Можно повторно использовать часть ПО, методику тестирования и инструкции. Документы, права пользователей и качество ответов проверяют заново. Здесь опыт первого пилота становится общей компетенцией центра.
Что понадобится для работы сервиса
Сотруднику нужен сервис, встроенный в его работу. Помимо модели, в него входят подготовка документов, поиск, интерфейс, управление доступом, интеграции и средства контроля. Для вопросов по регламентам можно рассмотреть поиск нужных фрагментов с последующим формированием ответа на их основе — подход RAG. Ссылки помогают проверить ответ, но сами по себе не гарантируют его правильность.
Как выбрать размещение
| Вариант | Когда рассматривать | Что проверить |
|---|---|---|
| Имеющиеся ресурсы | Если они позволяют проверить выбранную задачу | Совместимость ПО, свободную память и влияние на действующие системы |
| Аренда GPU | Для пилота или переменной нагрузки, когда допускается выбранное внешнее размещение | Условия обработки, изоляцию, доступность, стоимость и выгрузку данных при завершении |
| Локальный GPU-сервер | При требованиях к размещению внутри организации или обоснованной постоянной нагрузке | Модели, производительность, питание, охлаждение, поддержку и резервирование |
| Общая платформа центра | При подключении нескольких учреждений и сервисов | Разделение доступа и ресурсов, очереди, учёт потребления и ответственность за эксплуатацию |
Конфигурацию GPU подбирают по моделям, объёму контекста, числу одновременных запросов и допустимому времени ответа. Дополнительно рассчитывают CPU, оперативную память, хранилище и сеть. Производительность проверяют на целевом ПО и типовых заданиях; конкретную модель сервера выбирают после этого.
Локальное размещение требует проверки всего потока данных: куда обращается ПО, что попадает в журналы и резервные копии, кто может читать документы. До подключения рабочих данных ИТ- и ИБ-специалисты заказчика согласуют границы системы, источники, доступы и порядок эксплуатации.
Как спланировать бюджет и результат каждого этапа
Бюджет центра складывается из подготовки задач и данных, разработки или лицензий, интеграций, вычислений, обучения и дальнейшей эксплуатации. Для сравнения предложений полезно просить одинаковый состав работ и отдельно показывать разовые и регулярные затраты.
| Этап | Что получает заказчик | Основание для следующего шага |
|---|---|---|
| Обследование и концепция | Задачи центра, перечень сервисов, роли, ограничения, варианты запуска и предварительный бюджет | Выбраны первый процесс и ответственные |
| Подготовка пилота | Паспорт пилота, требования к ПО, данные, тестовые задания и критерии приёмки | Понятно, что и на чём проверять |
| Разработка и проверка | Рабочий прототип, результаты тестов и расчёт ресурсов | Есть измеренный эффект и перечень доработок |
| Запуск и передача | Рабочая версия, инструкции, обучение, порядок поддержки и восстановления | Команда готова обслуживать пользователей |
| Тиражирование | План подключения новых учреждений и обновлённый расчёт нагрузки | Подтверждены качество, доступы и эксплуатационная готовность |
В предложении подрядчика стоит зафиксировать, какие права на ПО и результаты работ получает заказчик, как передаются документация и настройки, кто оплачивает лицензии, как обновляются модели и что происходит при смене поставщика. Эти условия влияют на самостоятельность центра после пилота.
Как это делают в России и за рубежом
Ниже — опубликованный опыт других организаций. Эти проекты не являются проектами QBS; их результаты нельзя автоматически переносить на новое учреждение.
Россия · практика внедрения
Татарстан: знакомые рабочие задачи
По сообщению Минцифры Татарстана от 2 июня 2026 года, сервисом «ГосПромпт» пользовались более 4 000 человек. Он помогает госслужащим и учителям работать с документами и информацией. Это пример применения ИИ в повседневной работе; число пользователей само по себе не показывает экономию времени или бюджета. Сообщение Минцифры Татарстана.
Сингапур · рабочий процесс
Сингапур: ответ можно проверить
В кейсе Pair Search описана работа сотрудника финансового подразделения People's Association: раньше он вручную искал нормативную информацию для ответов коллегам. Сервис помогает находить материалы с источниками для проверки; сотрудники других подразделений могут самостоятельно выполнять первоначальный поиск. Кейс показывает рабочий процесс и экраны, но не даёт универсальной численной оценки экономии. Кейс команды Pair.
Великобритания · исследование
Великобритания: результат вместе с методом измерения
В испытании Microsoft 365 Copilot участвовали 20 000 государственных служащих. В опубликованном 2 июня 2025 года отчёте приведена средняя оценка экономии — 26 минут в день. Авторы уточняют: это время, оценённое самими пользователями, а не независимый хронометраж. Поэтому цифра полезна как результат конкретного исследования, но не как обещание для другого проекта. Отчёт Government Digital Service.
Выбрать конкретную работу, дать сотруднику способ проверить ответ и заранее определить, как измерять результат. Сравнивать стоит не красоту демонстрации, а весь процесс выполнения задачи.
Чем может помочь QBS
QBS предлагает обсудить проект по этапам: подготовка концепции и требований, разработка пилотного ПО, подбор и поставка GPU-инфраструктуры либо организация аренды, интеграции, обучение работе с решением и сопровождение. Состав команды, работ, сроки и стоимость фиксируются в предложении под вашу задачу.
Что предложим сделать первым
Начнём с обсуждения одного процесса: кто им пользуется, какие документы доступны и где возникают задержки или ошибки. В предложении зафиксируем состав обследования и его результат — описание задачи, список источников и ограничений, роли команды, критерии проверки и варианты запуска с предварительной оценкой затрат.
Если договоримся о пилоте, отдельно согласуем прототип, набор тестовых заданий, отчёт о проверке и условия передачи решения вашей команде. Сроки и стоимость определим после знакомства с задачей.
Какая повторяющаяся задача больше всего мешает вашей команде? Напишите пару строк — даже если пока непонятно, подходит ли для неё ИИ. Можно начать с описания процесса без служебных документов. Обсудим первый шаг письменно.
Рассказать о своей задачеПочта: da@qbs.ru · О компании QBS · GPU- и AI-серверы
Семь вопросов для первого обсуждения
- Кому будет помогать центр: одному учреждению или нескольким ведомствам?
- Какие два-три процесса сейчас требуют больше всего ручной работы?
- Кто станет владельцем первого пилота и кто проверит результат?
- Какие документы и данные уже доступны для тестирования?
- Какие ограничения по доступу, размещению и интеграциям известны?
- Какие специалисты, ПО и вычислительные ресурсы уже есть?
- По каким признакам вы решите, что пилот стоит запускать в постоянную работу?
«ИИ в государственном учреждении: от задачи к работающему пилоту» — 2 октября 2026 года, 11:00 мск. Разберём выбор задачи, требования к данным и инфраструктуре, оценку результата.
Программа и регистрация →Источники и подход к материалу
Материал подготовлен редакцией QBS. Обновлено 27 сентября 2026 года: добавлены российский и зарубежные примеры, учебный сценарий и разбор ответа по источнику. Учебные эпизоды вымышлены; факты о внешних проектах снабжены ссылками. Источники проверены 27 сентября 2026 года.
- Government Digital Service: AI Playbook for the UK Government — команда, выбор задач и жизненный цикл решения.
- HM Treasury: Guidance on the Impact Evaluation of AI Interventions — оценка эффекта и исходного процесса.
- NIST: AI Risk Management Framework — добровольная рамка управления рисками ИИ.