Карта і рейки: будівництво безпечної архітектури для корпоративного штучного інтелекту

Перша частина закінчилася твердженням: корпоративний штучний інтелект буде успішним, коли установи навчаться будувати сам цикл. Цей есе про те, на чому стоїть цей цикл. Агент, який працює в реальній компанії, потребує двох речей, яких компанія майже напевно не має сьогодні: карти роботи та рейок для наслідків.

Карта

Ось незручна правда під більшою частиною затихлих програм штучного інтелекту: компанія не може передати агенту опис своєї роботи, бо такого опису не існує. Більшість компаній відмітили свої іменники — бази даних, повні клієнтів, рахунків, заяв, контрактів. Але майже жодна не відмітила роботу: що можна зробити з цими речами, ким, під яких умов та що відбувається після. Ця інформація живе в головах досвідчених людей та в процесі, який описує, як робота була спроєктована п’ять років тому, а не як вона працює сьогодні.

Новий працівник закриває цю прогалину шляхом учнівства — спостереженням, спробами, питанням. Агент не вчиться так. Йому потрібна робота, написана на папері: речі, які обробляє бізнес, де кожна з них зараз знаходиться, робота, виконана над ними, рішення, яке вибирає наступний шлях, хто дозволений рухати речі вперед, та що відбувається, коли вони це роблять — запис, який змінюється, затвердження, яке йому потрібно, спосіб, яким його можна скасувати. Ця написана опис — це карта.

Три правила тримають карту в живих. Її потрібно написати людьми, які володіють роботою, та зробити її безпечною за допомогою інженерів — карта, яку тільки інженери можуть оновлювати, застаріває, а карта, яку тільки оператори можуть редагувати, стає небезпечною. Її потрібно версіонувати, бо агент ніколи не повинен діяти проти значення, яке змінилося потай. І її потрібно опублікувати — зробити її читаною для агента, рецензента та аудитора. Якщо агент мусить дізнаватися про ваш бізнес, склеюючи API-запити, ви виказали системи, а не описали роботу. API — це те, як речі виконуються. Карта — це те, як робота розуміється.

Карта має значення з причини, яка довше триває, ніж будь-який цикл продукту: агент не є тривалим активом. Карта — це тривалий актив. Моделі покращуватимуться та будуть замінені, фреймворки агентів з’являтимуться та зникатимуть — а опис вашої роботи, з його правилами, винятками та накопиченими виправленнями, є тим, що кожен майбутній агент успадкує в перший день.

Рейки

Карта каже, що може статися. Рейки — це те, що робить це саме.

Частина роботи, яку агент торкається, — це судження: читання заплутаного електронного листа, зважування винятку, рекомендація шляху. Але більша частина роботи — це повторення — те саме перевірка, те саме оновлення, те саме розміщення, тисячі разів. Повторенню не потрібно інтелекту. Йому потрібно бути точним. Модель є ймовірнісною за конструкцією, а для виконання їй потрібно бути точно: розміщення платежу не має прийнятної варіації, незалежно від того, наскільки хороша модель. Стабільна робота належить на рейки — детерміністична автоматизація, яка працює однаково кожен раз, нічого не коштує на кожен запуск та залишає чистий слід аудиту.

Це місце, де дві криві розходяться. Будівництво рейок стає легшим, бо опис роботи, генерація коду, написання тестів та ремонт зламаних шляхів — це саме та робота, яку прискорює штучний інтелект. Розгортання вільних агентів всередині наслідків процесів не стає легшим з такою ж швидкістю, бо чим ближче агент підходить до дії, тим більше йому потрібно межі, докази, затвердження, аудит та власники. Наслідок є складним, і він залишається складним. Отож, дайте агентам досліджувати, і дайте їм допомогти вашим командам вивчити роботу — потім перемістіть кожен шлях на рейки, як тільки він перестане змінюватися. Не залишайте високооб’ємну, стабільну роботу всередині ймовірнісного циклу, бо агенти модні.

Управління наслідками

З картою та рейками на місці залишається одне питання, перш ніж агент торкнеться реальної роботи: що йому потрібно дозволити робити? Промислова звичка відповідає на це питання у термінах трубопроводів — агент “використовує інструменти” — як ніби пошук політики, розрахунок варіації, складання листа, затвердження рахунку та оплата його були одним видом речі. Вони не є. Модель, яка шукає політику, не є такою ж, як модель, яка відмовляє в заяві. Модель, яка розраховує суму, не є такою ж, як модель, яка оплачує її. Читання інформації, зайняття позицією, підготовка дії, зміна запису та переміщення грошей — це різні види роботи, а різниця полягає в наслідках: що це коштує компанії, коли крок помилковий.

Управління повинно слідувати цій градації, а не трубопроводу. Робота, яка тільки читає, потребує контролю доступу. Робота, яка рекомендує, потребує людини, яка фактично приймає рішення. Робота, яка змінює запис, потребує дозволу, сліду аудиту, способу скасувати його, та названого власника. Робота, яка переміщує гроші, потребує всього цього, плюс гарантію, що напівзавершена зміна не може залишити компанію в стані, який просто неправильний. Управління наслідками та безпечне використання штучного інтелекту відкриваються швидко; управління всім однаково, і ви отримуєте або параліч, або інцидент.

Довіра здобувається робочим процесом

Ця градація також показує, як росте довіра. З картою та рейками довіра перестає бути відчуттям щодо моделі та стає властивістю роботи. Робочий процес — один описаний шматок бізнесу, з його брамою з першої частини — здобуває дозвіл крок за кроком, піднімаючись по тій же градації: спочатку він тільки складає, потім може рекомендувати, потім може підготувати дію, яку людина затверджує, потім він може виконувати звичайні випадки та ескалювати винятки, і, нарешті, він працює під аудитом, з людьми, які спостерігають результати, а не клікають на кожен випадок.

Кожен крок вгору здобувається з доказами з брами — перевірених рішеннях, виправленнях, причинах — і кожен крок вниз є автоматичним, коли продуктивність падає. Краща модель не здобуває права на дію.

Не просуньте модель. Просуньте робочий процес.

Почніть з одного робочого процесу

Нічого з цього не потребує корпоративної програми, і воно не повинно починатися як одна. Виберіть один CONSEQUENTIAL робочий процес з реальним об’ємом, реальною вартістю помилки та власником, який хоче його виправити. Відмітьте цю роботу. Покладіть її стабільні кроки на рейки. Встановіть її браму. Потім перевірте опис проти дев’яти простих питань:

• Які бізнес-об’єкти переміщуються?
• Де кожен з них зараз знаходиться?
• Яка робота виконується?
• Яке рішення вибирає наступний шлях?
• Що відбувається, якщо це затверджено?
• Що може використовувати агент?
• Що працює автоматично?
• Хто пропонує, хто затверджує, хто виконує, хто відповідає?
• Якщо щось пішло не так, що змінюється до наступного запуску?

Якщо люди, які володіють роботою, можуть відповісти на ці дев’ять питань для одного робочого процесу, агент може працювати всередині нього безпечно — пропонувати, бути перевіреним та дозволити рейкам виконувати. Якщо вони не можуть, жодна якість моделі не врятує розгортання.

Помилки так само впізнавані, як і шаблон. Чат-бот з доступом до чутливих систем, але без карти роботи. Шар відображення, який відповідає на питання політики, але не може показати джерело політики. Агент, який може затверджувати роботу, але не може сказати, хто володіє затвердженням. Рецензент, який бачить рекомендацію, але не наслідок затвердження. Робочий процес, просунутий до автономії, бо модель покращилася, а не бо робочий процес здобув довіру.

Карта, рейки та брама: це архітектура. Залишається питання, як побудувати це в одному робочому процесі — і це третя частина.