AI для держави — від службового copilot до AI-native government

Референсний workflow

1. 1.Trigger → користувач відкриває Дія.AI на порталі або в застосунку й описує задачу природною мовою; окремі сценарії можуть бути event-driven, наприклад повідомлення про штраф.
2. 2.Identity & context → для персоналізованої послуги система працює в авторизованому контексті та звертається до дозволених державних даних/реєстрів замість повторного ручного введення всіх реквізитів.
3. 3.Intent & service match → AI визначає життєву ситуацію або конкретний запит і зіставляє його з доступною держпослугою, офіційною інструкцією або наступним кроком.
4. 4.Grounded response → пояснення та service guidance мають спиратися на актуальні державні правила, а не на вільну генерацію моделі; якщо даних недостатньо, workflow повинен уточнити запит або віддати користувача в стандартний сервісний шлях.
5. 5.Tool/service execution → контрольований application layer викликає потрібний державний сервіс: наприклад формування довідки/витягу, перевірку доступних даних або підготовку переходу до сплати штрафу.
6. 6.Transaction boundary → платежі, заяви та інші high-impact дії не повинні завершуватися лише на підставі текстового рішення LLM; користувач бачить точну дію, реквізити/наслідок і явно підтверджує її.
7. 7.Result & status → готовий документ, статус обробки або безпечне посилання на наступну дію повертаються в той самий діалог; історія дозволяє відновити контекст і не повторювати процес з нуля.
8. 8.Feedback & evaluation → лайк/дизлайк, коментарі, task-completion data та контроль помилок формують evaluation loop; розширення coverage відбувається лише після перевірки якості й safety для нового класу послуг.
9. 9.Transparency notice → перед персоналізованою або значущою взаємодією користувачеві має бути зрозуміло, що він взаємодіє з AI, яку роль AI виконує, які джерела є authoritative і де починається deterministic державний сервіс.
10. 10.Contestability & redress → неправильний або спірний результат не завершує процес: користувач може перейти на стандартний сервісний шлях, запросити перегляд/виправлення, подати скаргу або отримати human review із збереженим evidence trace.
11. 11.Release & change control → зміна model, prompt, retrieval corpus, policy rules або service/tool contract проходить versioned regression set, staged rollout і rollback gate; для публічно значущих змін оновлюється transparency record та owner/accountability metadata.
12. 12.Dependency health gate → перед персоналізованою відповіддю або service action orchestration перевіряє стан критичних залежностей: authoritative registry, policy/rules source, identity, transactional API і model/tool provider. Немає green health signal — немає вигаданого «усе працює».
13. 13.Degraded mode → якщо конкретний реєстр або tool недоступний, assistant чітко відділяє відомий стан від невідомого, блокує лише залежний consequential flow, показує офіційний fallback/status path і зберігає доступні незалежні функції замість тотального black box failure.
14. 14.Incident capture & containment → wrong action, prompt-injection attempt, provider outage, stale rule, corrupted retrieval або anomalous tool response отримують окремий incident class, evidence trace, owner/escalation route та scoped kill switch для проблемної capability.
15. 15.Recovery & reconciliation → після rollback або відновлення залежності система повертається до known-good configuration, перевіряє pending state проти authoritative backend і не replay-ить платіж, заяву чи іншу незворотну дію лише тому, що попередня сесія обірвалася.
16. 16.Workload placement → кожен клас запиту має policy щодо допустимого execution target: власна інфраструктура, approved external cloud або hybrid path. Routing враховує sensitivity, latency, capacity і cost, але ніколи не розширює data або action authority лише через перевантаження основного runtime.
17. 17.Provider/model migration → кандидат на заміну cloud або LLM спочатку проходить shadow replay на versioned eval corpus, compatibility tests для retrieval/tool contracts, privacy/data-placement checks і canary без consequential authority; лише після parity gates новий runtime отримує production scope.
18. 18.Exit & failback → система зберігає exportable behavior envelope, evidence, configs і audit identifiers, щоб відкотитися або змінити provider без переписування policy layer. Sovereignty тут вимірюється не прапорцем «local model», а реальною здатністю переносити critical service behavior без втрати контролю.
19. 19.Actor & subject resolution → перед персоналізацією orchestration окремо визначає, хто зараз автентифікований і щодо кого виконується послуга: сам користувач, дитина, юридична особа або інший principal. Фраза «зроби за маму/компанію» не створює повноважень.
20. 20.Mandate resolution → application layer отримує чинну підставу представництва з authoritative реєстру/сервісу та нормалізує scope: principal, representative, категорія послуги/заяви, дозволені дії, строк, revocation state і можливість/заборона подальшої передачі.
21. 21.Step-up at consequential write → безпосередньо перед поданням, відкликанням, зміною заяви або іншою high-impact дією система повторно перевіряє mandate, показує exact actor/principal/payload і прив’язує підтвердження або підпис до конкретної дії, а не до абстрактної «довіри AI».
22. 22.Revocation & representation reconciliation → після timeout, retry, відновлення сесії або зміни представника pending action не продовжується за старим cache. Система повторно звіряє authority; відкликане або звужене повноваження блокує write, а audit зберігає хто, від чийого імені, на якій підставі та з яким scope діяв.

Контроли та межі

• • Identity before personalization: доступ до персональних реєстрових даних і готових послуг має бути прив’язаний до авторизованого користувача, а не до анонімного чату.
• • LLM ≠ source of legal truth: модель інтерпретує намір, але фактичні статуси, права, суми, документи та правила повинні приходити з authoritative державних систем.
• • Protected data boundary: Мінцифра заявляє, що персональні дані не потрапляють до загальної моделі Gemini й обробляються у захищеному периметрі Дії; для production governance це має бути технічно перевірюваним data-flow contract.
• • Explicit action authority: для платежу, подання заяви або іншої незворотної дії потрібне окреме підтвердження exact payload та зрозумілий результат, а не загальна згода «дозволити AI».
• • Open-beta fallback: Дія.AI офіційно описувався як open beta, тому невпевненість, unsupported intent або конфлікт даних мають вести до standard service path / human support, а не до впевненої імпровізації.
• • Voice is opt-in: голосова взаємодія на порталі активується після підтвердження користувача; accessibility feature не повинна мовчки розширювати permission surface.
• • Freshness gate: каталоги послуг, eligibility rules, строки, тарифи та нормативні вимоги змінюються; retrieval/index має мати versioning, source timestamps і invalidation.
• • Auditability: кожна high-impact interaction має залишати trace — intent, джерела, service/tool call, підтвердження користувача, результат і failure reason — без витоку зайвих персональних даних у model logs.
• • Public transparency record: для citizen-facing або public-effect AI потрібен зрозумілий запис про purpose, responsible owner, scope, model/tool/data classes, deployment context, supplier dependencies, risks, mitigations та канал звернення.
• • Contestability by design: feedback button не дорівнює redress. Потрібні окремі маршрути для correction, appeal/complaint, human review і відновлення стандартного не-AI сервісного шляху.
• • Version-bound accountability: audit event має посилатися на конкретні model/prompt/retrieval/policy/tool versions; інакше після оновлення системи неможливо відтворити, чому громадянин отримав саме такий результат.
• • Change-risk gate: нова модель або новий service flow не отримує попередню authority автоматично. Кожен клас змін повторно проходить risk classification, regression evals, canary і rollback readiness.
• • User-facing AI disclosure: як benchmark для євроінтеграційної сумісності, Article 50 AI Act вимагає для визначених AI-взаємодій прозоро інформувати людину про взаємодію з AI; це не підміняє українські правові вимоги, але задає корисний minimum disclosure pattern.
• • Dependency-aware truthfulness: assistant не перетворює timeout або 5xx від реєстру на «не маєте права», «штраф відсутній» чи інший semantic outcome. Unknown/temporarily unavailable — окремий стан із provenance та timestamp.
• • Scoped kill switches: можливість читати довідковий контент, формувати документ, перевіряти registry state і виконувати transaction мають окремі authority toggles. Один проблемний tool не повинен або залишатися небезпечно активним, або валити весь сервіс.
• • Idempotent recovery: кожна consequential action має correlation/idempotency key та backend reconciliation. Після retry система спочатку перевіряє authoritative result, а вже потім вирішує, чи потрібне повторне виконання.
• • Operational SLOs: крім answer accuracy потрібні dependency availability, degraded-mode success, wrong-action rate, stale-source rate, time-to-containment, rollback time, unreconciled pending actions і incident recurrence. «Чат відповів» — це не SLO державної послуги.
• • Sensitive observability: prompts, tool payloads і incident traces логуються настільки, наскільки потрібно для audit/remediation, але з data minimization, access control, retention policy та відокремленням секретів від звичайної conversation history.
• • Supplier failure boundary: модель, cloud runtime або third-party tool не повинні бути єдиним джерелом істини про державну дію. Provider outage переводить system authority вниз, а не породжує локально вигадану заміну authoritative state.
• • Red-team-to-regression loop: знайдена атака або production incident стає мінімізованим regression case з фіксованим expected safe outcome; інакше red teaming перетворюється на презентацію з красивими стікерами.
• • Data-placement matrix: кожен data class має явний перелік дозволених execution locations і processors. Capacity overflow не може мовчки виштовхнути sensitive payload у зовнішній provider, який не був дозволений для цього класу.
• • Provider-neutral policy layer: eligibility, redress, tool authority, audit schema та acceptance criteria не повинні жити лише у vendor-specific prompt/config format. Інакше «суверенність» закінчується на першому рахунку за egress.
• • Portable eval corpus: migration readiness перевіряється тим самим versioned набором public-service tasks, edge cases, privacy cases, tool trajectories та safe-failure expectations для старого й нового runtime.
• • No authority inheritance: нова LLM, локальна модель або альтернативний cloud починає з мінімальної authority. Вищі права повертаються лише після доказаного parity за quality, safety, privacy, latency та reconciliation gates.
• • Exit drill: періодично відтворюється provider-loss сценарій — export configs/evidence, switch inference target, replay critical evals, restore audit linkage і fail back. План виходу, який ніколи не запускався, — це PowerPoint із державним гербом.
• • Procurement disclosure: для критичного AI service contract має фіксувати фактичних AI/subprocessor dependencies, data use/retention, model/version change notification, audit/export rights, portability artifacts, termination assistance та incident duties; UK PPN 017 використано тут як procurement benchmark, не як українську норму.
• • No inferred representation: LLM не має права виводити повноваження з прізвища, родинної згадки, email domain, попередньої розмови чи того, що користувач колись працював з даними principal. Representation існує лише після authoritative verification.
• • Least-delegation scope: mandate повинен бути machine-readable і мінімальним — конкретний principal, категорія/послуга, read/write operation, expiry та інші обмеження. «Представляти компанію» не дорівнює «робити все в усіх державних сервісах».
• • Write-time revocation check: для consequential action authority перевіряється не лише при login або старті чату, а безпосередньо перед write. Cached mandate після revocation — це privilege-escalation bug, а не UX optimization.
• • Principal/representative isolation: conversation memory, retrieval context, drafts і tool results повинні бути namespaced за principal + mandate. Перемикання «за себе / за дитину / за компанію» не може переносити чужі дані або чернетки між контекстами.
• • No subdelegation by improvisation: якщо authoritative mandate забороняє передачу далі, agent не може створити «помічника», поділитися токеном або викликати інший agent із ширшими правами. Tool delegation не повинна обходити legal delegation.
• • Representation fallback: якщо зв’язок/повноваження не підтверджуються цифрово, система не вгадує. Вона переводить користувача в офіційний alternative path — наприклад human/CNAP flow у тому service scope, де це передбачено.
• • Actor-principal audit tuple: для кожної значущої дії evidence trace фіксує authenticated actor, principal, authority source/id, scope/version, confirmation/signature, payload hash, tool result і revocation state на момент виконання.
• • Model cannot mint authority: LLM може пояснити, як отримати або змінити повноваження, але не може сам створити, розширити, продовжити чи відновити mandate без authoritative service та необхідного підпису/підтвердження.