Чому AI-розробка для GovTech буксує на пілотах
Демонстраційний сценарій збирається швидко: беруть один набір даних, розмічують, показують працюючу модель на закритому стенді. На цьому етапі все сходиться — і саме тому AI-проєкти в держсекторі так часто зупиняються тут. Експлуатація починається там, де закінчується вітрина, і там же проявляються три системні перепони.
Перше — дані. Відомості про громадян та об'єкти інфраструктури розкладені по відомствах, у незвідних довідниках і реєстрах, частина — у сканах і вивантаженнях без структури.
Перш ніж щось навчати, потрібно привести сутності до спільного ідентифікатора й домовитися про правила звіряння. Це не робота з моделлю, це робота з даними, і вона з'їдає основну частину термінів проєкту.
Друге — відповідальність. Впровадження AI у відомстві впирається не в точність, а в питання, хто відповідає за рішення системи, якщо воно помилкове.
Поки регламент не розводить випадки, де підпис залишається за людиною, а де система лише готує проєкт рішення, ніхто не переведе процес у промислову експлуатацію.
Третє — приймання. Результат перевіряють вручну на вибірці: фахівець відкриває відповіді моделі й розбирає їх по одному. Відтворюваної метрики такий розбір не дає і деградацію не ловить.
Автоматизація відомчих процесів потребує фіксованого контрольного набору й метрик за часткою помилок кожного класу — тоді якість обговорюється в цифрах, а не в думках.
Розбираємо, як кожен із трьох бар'єрів закривається на рівні підготовки даних, регламентів і вимірюваного приймання.
Що змінюється в роботі відомства після впровадження AI
Ефект від впровадження AI у відомстві вимірюється не точністю моделі, а часткою процесів, де ручне рішення більше не потрібне. Розбір вхідного звернення, скану заяви, доданої довідки — перший кандидат на автоматизацію.
Методологічну рамку беремо з Принципів відповідального ШІ ОЕСР: рішення моделі пояснюване, а співробітник бачить, на якій підставі обрано маршрутизацію.
Скорочення ручного розбору звернень
Типові звернення — довідка, продовження, повідомлення, скарга на об'єкт міської інфраструктури — проходять без оператора: поля документа витягуються автоматично, звіряються з відомчими реєстрами, проєкт відповіді формується заздалегідь.
Ручний розбір залишається на нетипових і спірних випадках; за масовими потоками 70–80% звернень закриваються без дотику людини. Час проходження заявки скорочується з днів до годин — зникає очікування на етапі «передати в потрібний відділ».
Єдиний реєстр звернень і рішень
Кожне звернення, витягнуті поля, обраний маршрут і ухвалене рішення записуються в єдиний реєстр з історією змін.
Це прибирає окремий клас помилок розподілу: заявка не губиться між відомствами і не йде повторно не тому виконавцю, бо маршрут зафіксовано один раз і видно всім учасникам.
Звітність — прострочення, повернення, частка вирішених з першого разу — будується за реєстром без ручного звіряння.
Формати робіт: пілот, контур під ключ, супровід
Формат робіт обирають за готовністю даних і за тим, чи є в замовника команда, яка прийме систему в експлуатацію. Нижче — три режими та їхні обмеження.
Пілот на одному процесі
Пілот AI-проєкту бере один процес із вимірюваним результатом — розбір звернень або перевірку заявки на відповідність регламенту. Дані обмежуємо історичним зрізом, а метрику (частку автоматично закритих звернень, точність на контрольній вибірці) узгоджуємо до старту.
Обмеження: це перевірка гіпотези на зрізі даних, без відмовостійкості, рольової моделі та інтеграцій.
Повний контур під ключ
AI-система під ключ — це етапність впровадження від схеми даних до передачі в експлуатацію: інтеграції з відомчими системами, рольовий доступ, журналювання рішень моделі, регламент оновлення.
Потрібні доступ до продуктивного середовища на етапі тестування й виділений власник процесу з боку замовника.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пілот AI-проєкту | Один вузький процес, є історичні дані | Результат на зрізі, немає інтеграцій і відмовостійкості |
| AI-система під ключ | Процес критичний, доступи й регламенти потрібні з першого дня | Потребує продуктивного середовища для тестів і власника з боку замовника |
| Супровід AI-системи | Контур працює, змінюються дані або навантаження | Без метрик якості ефект не виміряти |
Супровід AI-системи закриває дрейф даних, деградацію метрик і оновлення моделей — це окремий режим, а не продовження контуру за замовчуванням.
Етапи інженерної роботи: від обстеження до передачі
Порядок робіт фіксуємо до старту: кожен етап закривається артефактом, який можна перевірити, а не звітом про витрачений час. Етапи впровадження AI йдуть послідовно — від обстеження процесів до передачі в експлуатацію.
- Обстеження процесів і даних: інтерв'ю з операторами, реєстр джерел, обмеження щодо персональних даних.
- Схема рішення: які моделі та правила використовуються, де зберігаються дані, як вбудовуємося в чинні регламенти.
- Складання й налаштування: підготовка даних, навчання й калібрування моделей, інтерфейс оператора, службовий моніторинг.
- Перевірка на історичних даних: прогін на розмічених минулих періодах, розбір помилок за класами.
- Навчання співробітників: регламенти роботи із системою, розбір спірних випадків, ролі відповідальних.
- Приймання AI-системи: здача за узгодженими метриками, доступи, документація, резервні копії.
- Передача в експлуатацію та супровід: моніторинг якості, дообучення на нових даних, планові оновлення.
Перевірка на історичних даних
Проганяємо рішення на розмічених даних минулих періодів і дивимося не середню точність, а розбір помилок за класами: де плутаються схожі категорії, які звернення йдуть оператору на ручну обробку. Приймання AI-системи відбувається за метриками, зафіксованими на старті.
Навчання й передача експлуатації
Навчаємо операторів і адміністраторів: як читати звіти про якість, що робити із сумнівними відповідями, куди ескалювати збій. Передача в експлуатацію включає доступи, регламенти, документацію та порядок оновлення моделей; супровід триває після запуску.
Комплект постачання: схеми, політики доступу, регламенти
Система вважається переданою не тоді, коли модель відповідає на демонстраційних запитах, а коли в команди, що приймає, є комплект документів, за яким вона може експлуатувати, розвивати й перевіряти рішення без нас.
Документація на AI-систему збирається по ходу проєкту й збігається з фактичною конфігурацією, а не дописується перед здачею.
Політики доступу та розмежування ролей
- Схема рішення: компоненти, потоки даних між ними, межі довіри та точки стикування з міськими інформаційними системами.
- Матриця ролей і доступів: хто працює з сирими даними, хто бачить лише агрегати, хто керує налаштуваннями моделі.
- Політики доступу: порядок надання й перегляду прав, журналювання звернень, розділення середовищ розробки та експлуатації.
- Опис контурів обробки: де лежать дані, що йде в зовнішні сервіси, що не залишає захищений периметр.
Регламенти й інструкції для операторів
- Регламент роботи з даними: від надходження до архівації, терміни зберігання, порядок знеособлення та розбору інцидентів.
- Інструкції для операторів: як опрацювати спірне спрацювання, кому ескалювати, які дії неприпустимі.
- Набір перевірних сценаріїв: еталонні приклади з очікуваним результатом — за ними команда перевіряє систему після дообучення або оновлення налаштувань.
- Порядок змін: як узгоджується правка логіки моделі та хто закріплює нову версію в документації.
Такий комплект знімає залежність від підрядника: нові співробітники вводяться в роботу за інструкціями, а не за усними поясненнями.
Кейс: обробка звернень у міській службі
До міської служби щодня надходять тисячі звернень — через форму на сайті, гарячу лінію та месенджери. Раніше вони потрапляли в одну чергу, і рішення залежало від оператора: він читав текст, визначав тему, оббирав виконавця й вручну ставив термін.
Розберемо на проєкті Єдиний центр звернень, що дала автоматична обробка та які метрики це підтверджують.
Як працювали до
Середній час від надходження звернення до призначення виконавця становив близько дев'яти годин: заявка чекала, поки до неї дійде оператор.
Тему визначали за ключовими словами в заголовку, тому «яма у дворі» та «не вивозять сміття» регулярно йшли не в той відділ — частка помилок розподілу трималася на рівні 18%.
Ручне втручання було потрібне практично завжди: навіть типове звернення про графік вивезення проходило через людину, а термінові губилися в загальній черзі.
Що змінилося після запуску
Модель розмічує звернення за категорією та підкатегорією, витягує адресу й ознаки терміновості, а правила розподілу за нормативними термінами одразу обирають виконавця.
Призначення відбувається в момент приймання: середній час скоротився до 12 хвилин, частка рішень без ручного втручання зросла до 74%, помилки розподілу — до 3,5%.
Оператор підключається лише до спірних випадків: система віддає їх в окрему чергу разом з оцінкою впевненості, тому розбір іде помітно швидше. Кожне виправлення оператора йде в перенавчання, і частка автоматичних рішень зростає без переписування правил.
Закритий контур чи хмара: як обирати розміщення
Вибір між закритим контуром і хмарою визначають не звички команди, а клас даних і вимоги до захисту.
Якщо в системі персональні дані громадян, службова геоінформація або вивантаження з відомчих реєстрів, спочатку відповідаємо на одне питання: чи можуть трафік і самі дані залишати периметр. Ця відповідь відсікає половину варіантів ще до обговорення стеку.
| Варіант розміщення | Коли підходить | Обмеження |
|---|---|---|
| Закритий контур | Дані не можна виносити за периметр, є власний вузол | Оновлення йдуть через узгоджений канал, зростання впирається в залізо |
| Хмара з ізоляцією | Потрібні швидкий старт і еластичні ресурси | Потрібне підтверджене розміщення даних, власні ключі та журнали доступу |
| Гібрид | Навчання на знеособлених наборах, результат виводиться в контур | Два контури обміну, потрібна простежуваність версій моделей |
Закритий контур — це не лише відсутність зовнішнього маршруту. Модель постачається як артефакт і оновлюється через узгоджений канал, телеметрія назовні не йде, а кожне звернення до сервісу логується на стороні замовника.
У хмарі ту саму ізоляцію дають виділений сегмент з окремими ключами, розмежування ролей і мережеві політики: дані шифруються, доступ підтверджується журналом.
На практиці рішення ухвалюють за трьома перевірками: де фізично лежать дані та резервні копії, у кого залишаються ключі шифрування, як відкотитися на попередню версію моделі без втрати накопиченого стану.
Вимоги регулятора — ФСТЕК Росії та галузеві регламенти — задають нижню межу, нижче якої розміщення просто не погодять.
Сумніви замовника: якість, дані, відповідальність
Сумніви замовника — частина інженерної роботи: їх розбирають до старту, а не після запуску. Чотири питання найчастіше вирішують долю проєкту в держсекторі та розумному місті — відповідаємо на них без обіцянок, які не можна перевірити.
Чи вистачить даних для навчання моделі?
Нестача даних — часта причина, через яку проєкти не доходять до впровадження, тому починаємо з інвентаризації реєстрів, журналів звернень і архіву, а потім оцінюємо досяжну якість на розміченій вибірці.
Якщо реальних прикладів мало, додаємо синтетику та правила для рідкісних сценаріїв — і фіксуємо, який результат вважаємо достатнім для запуску.
Що якщо система помилиться?
Абсолютної безпомилковості не буває, тому якість AI-рішення задається числом до розробки: цільова частка правильних відповідей і припустима частота пропусків.
Там, де рішення має юридичні наслідки, оператор залишається в контурі ухвалення рішення, а система підсвічує спірні випадки й веде журнал висновків, за яким розбирається кожна помилка.
Хто відповідає за результат?
Відповідальність підрядника — за узгоджені метрики на тестовому наборі та за працюючу експлуатацію AI-системи, а не за неможливість помилки.
Гарантійний період, регламент перенавчання при зміні даних і передача знань вашій команді закріплюються договором — система не залишається заручником автора.
Дані закриті — як вести роботу і що після акта?
Навчання й налагодження йдуть у вашому контурі: дані не залишають інфраструктуру замовника, доступ — за регламентом і з журналюванням, для перевірок використовуємо знеособлені зрізи.
Після підписання акта залишаються документація, артефакти моделей і план супроводу, включно з оновленням при зміні вхідних даних.
Обговоримо задачу: з чого почнемо і що потрібно від вас
Оцінка AI-проєкту в держсекторі тримається не на моделі, а на контурі: де живуть дані, хто їхній власник і які погодження потрібні до першого запуску.
Тому старт робіт починається з розбору процесів і обмежень, а не з вибору інструментів — так оцінка спирається на реальний обсяг робіт, а не на припущення.
- Процеси: як задача вирішується зараз, хто в ній бере участь, скільки часу йде на ручні операції та де губиться результат.
- Дані: приклади вивантажень, формати, обсяг, частка нерозмічених записів, наявність персональних даних і вимоги до знеособлення.
- Контур: де припустимо розгорнути систему — ізольована мережа замовника, закрита хмара або гібридна схема, які канали зв'язку дозволені.
- Інтеграції: з якими відомчими та внутрішніми системами потрібно пов'язати рішення, у якому форматі та з якою частотою йде обмін.
- Терміни: бажана дата першого результату, що вважаємо пілотним запуском і за якими метриками підтверджуємо ефект.
- Відповідальні: власник процесу з боку замовника, фахівець для надання доступів, той, хто приймає роботу.
- Обмеження: нормативні вимоги до обробки даних, правила журналювання та пояснюваності рішень.
Опишіть задачу в цьому обсязі — повернемося з оцінкою та планом впровадження: етапи, склад робіт, точки перевірки й метрики, за якими будемо рахувати результат.
