Дев’ять архітектурних елементів для систем штучного інтелекту промислового рівня.

Пробіл між демо-версією та продакшном, про який ніхто не говорить

Створити прототип штучного інтелекту за вихідні — це легко.

Під’єднайте LLM до циклу виклику інструментів, підключіть його до бази даних векторів, додайте інтерфейс чату — і раптово у вас є щось, що виглядає вражаюче у демонстрації. Керівництво задоволене. Інженери сповнені ентузіазму. Хтось пише на дошці „Пілотний проєкт у 3-му кварталі“.

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

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

Неприємна реальність полягає у наступному:

Вибір моделі ніколи не був складною частиною. Справжня складність полягає у структуруванні системи навколо цієї моделі.

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

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

Наш приклад: Aurora Bank

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

Aurora Bank — це середній роздрібний банк із 4 000 працівниками. Вони впроваджують "Aurora Assistant" — платформу на основі агентів, призначену для: — відповідей співробітникам на запитання щодо правил та вимог, — підтримки обробки кредитів (завантаження документів, перевірка деталей, складання рішень), — а також керування завданнями обслуговування клієнтів, такими як повернення коштів, перевірка рахунків та направлення заявок.

Обмеження, з якими стикається Aurora, відображають ті проблеми, з якими стикаються більшість реальних компаній:

1. Персональні дані клієнтів не можуть виходити за межі інфраструктури самого банку.
2. Будь-яке автоматизоване рішення має бути пояснюваним регулятору за його запитом.

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

Асистент повинен взаємодіяти з понад 20 внутрішніми системами (SAP, Salesforce, платформи банківських послуг, ServiceNow та іншими).

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

Пам’ятайте про ці п’ять обмежень під час подальшого читання — кожен із дев’яти принципів створений саме для подолання таких обмежень.

П’ять керівних принципів

Перш ніж перейти до самого опису принципів, корисно зрозуміти підставну філософію:

1. Розглядайте модель як один із багатьох компонентів, а не як саму архітектуру. Моделі замінюються кожні кілька місяців; ваша архітектура повинна витримати таку зміну.
2. Зберігайте ймовірнісне мислення всередині системи, але робіть її межі детермінованими. Штучний інтелект може думати вільно, проте дії мають виконуватися через фіксований код.
3. Переконайтеся, що кожна дія створює запис. Якщо ви не можете повторно виконати рішення, ви не зможете його захистити пізніше.
4. Ізолюйте компоненти за рівнем довіри та опосередковуйте кожен запит на доступ. Агенти є здатними, і саме тому вони становлять ризик — свідомо обмежуйте цей ризик.
5. Створюйте систему так, ніби має відбутися аудит та ніби вам зателефонують о 3 годині ранку. Рано чи пізно обидва ці сценарії стануть реальністю.

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

Елемент 1 — Логічна архітектура: чому шість шарів є правильними

Питання тут просте у формулюванні: які є основні складові системи, і який шар несе відповідальність за що?

Платформа з агентами складається з шести логічних шарів.

Чому саме шість, а не три чи дев’ять?

Традиційна трьохрівнева модель — презентація, логіка, дані — ігнорує саме ті елементи, які роблять систему з агентами унікальною: оркестрацію, вибір моделей, інтеграцію інструментів та межі довіри. З іншого боку, розділення на дев’ять окремих компонентів схильне роз’єднувати функціональні елементи, які насправді мають залишатися разом.

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

1. Шар досвіду (L1) постійно змінюється — нові інтерфейси, нові канали, нові вимоги до фронт-енду.
2. Оркестрація (L2) змінюється з кожним новим випадком використання, який додається.
3. Міркування (L3) змінюються щоразу, коли з’являється більш потужна модель, тому її потрібно можливість заміни без впливу на інші елементи.
4. Інтеграція (L4) змінюється щоразу, коли бізнес під’єднує нову систему.
5. Дані (L5) поступово змінюються самостійно, але правила управління, пов’язані з ними, змінюються в міру розвитку регуляцій.
6. Управління (L6) існує окремо як скрізь присутня компонента, а не як нижній шар, оскільки ідентифікація, аудит, оцінка, захисні механізми та контроль витрат потребують впливу на кожен інший шар, а не обмежуються лише основою стеку.

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

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

Якщо проігнорувати це: кожен новий випадок використання перетворюється на редагування одного великого, заплутаного файлу. Заміна моделей стає непрактичною. Ніхто не може з упевненістю сказати, де саме знаходиться логіка аудиту.

Висновок: шари існують для позначення місць, де дозволено вносити зміни. Їхнє правильне проектування означає проектування «швів» системи, а не лише її компонентів.

Основа 2 — Фізична архітектура: чому суверенне розгортання є можливим

Питання, на яке потрібно відповісти: де фізично працює система, і що — якщо взагалі щось — дозволено передавати за межі вашого простору?

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

Чому цей варіант існує зараз, якщо кілька років тому він був нереалістичним?

1. Моделі з відкритою структурою скоротили розрив із закритими моделями. Тепер такі моделі, як Llama 3.x, Qwen 2.5 та Mistral, можна розмістити на власному сервері та все одно отримувати результати високої якості для класифікації, вилучення інформації, стиснення та відповідей на запитання за допомогою технології RAG.
2. Квантування робить їх доступними за ціною. Технології 4-бітного квантування дозволяють одній 80-ГБ відеокарті обслуговувати моделі з 70 мільярдами параметрів, а менші моделі потребують ще менше обладнання.
3. Інфраструктура для обробки даних вже розвинена. vLLM забезпечує безперервну обробку даних у пакетах та високу продуктивність для серійної експлуатації, Ollama ідеально підходить для розробки, а Kubernetes може керувати їхньою роботою так само, як будь-якою іншою слугою.

Економічна доцільність підтримується. Для організації середнього розміру, яка використовує кешування та групування операцій, достатньо невеликого пулу GPU для обслуговування трафіку у масштабах внутрішнього асистента.

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

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

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

Висновок: межі системи — це рішення, яке ви повинні ухвалити свідомо. Якщо ви не зробите це прямо, стандартна конфігурація постачальника зробить це замість вас.

Основа 3 — Модель C4: правильна документація

Питання: Як документувати систему так, щоб кожна аудиторія бачила саме той рівень деталей, який їй потрібен?

Модель C4, створена Саймоном Брауном, пропонує чотири рівні зумування — уявіть собі це як панорамування та зумування на карті.

Чому модель C4 так добре підходить для агентних систем?

1. Агентні системи за своєю природою є заплутаними. На запитання „Де насправді знаходиться агент?“ немає однозначної відповіді. Модель C4 змушує бути точним: агент — це не просто окрема клітинка на діаграмі, а сукупність контейнерів (середовище виконання, шлюз, різні сховища), які обмінюються повідомленнями. Модель C4 висвітлює ці процеси обміну, замість того щоб їх приховувати.

Жодна діаграма не може задовольнити потреби трьох різних користувачів. Регулятор хоче бачити перспективу „Контекст“ — ту, що відображає дані клієнтів. Спеціаліст з безпеки потребує перспективи „Контейнер“ — ту, яка показує процес, що фактично зберігає облікові дані. Інженер хоче бачити компоненти. C4 надає кожному з них власний рівень зуму, тож ніхто не мусить сперечатися про те, які елементи мають бути на чиїй діаграмі.

Розгляд діаграм як коду забезпечує актуальність документації. Коли діаграми зберігаються у Structurizr, Mermaid чи PlantUML, потрапляють до репозиторію та проходять перевірку через pull-request, вони змінюються разом із самим кодом — а не застигають у презентаційних слайдах, до яких ніхто не торкався з часу останньої реорганізації.

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

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

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

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

Основа 4 — Мережі з нульовою довірою: чому саме п’ять зон

Питання: Якщо щось потрапляє під загрозу — а рано чи пізно це трапиться, — як обмежити збитки?

Нульова довіра означає відсутність будь-якої неявної довіри: кожен запит підлягає автентифікації (за допомогою mTLS та ідентифікації робочих навантажень), авторизації через перевірку політики та шифруванню, навіть для трафіку, який ніколи не виходить за межі вашої мережі. Для агентної платформи правильна сегментація складається з п’яти зон:

Чому саме п’ять?

Оскільки кожна межа повинна розділяти справді різний рівень довіри — а агенти вводять рівень довіри, про який традиційні архітектури просто ніколи не мусили турбуватися:

1. Z1, Edge — там, де спочатку надходить ненадійний трафік. Він постійно піддається атакам, тому можна припустити, що він вже порушений.
2. Z2, шар додатків — безпосередньо обслуговує кінцевих користувачів. Напівнадійний.

Z3, зона агентів — ризикований новачок. Агенти використовують довільні інструменти, споживають ненадійний контент, отриманий з Інтернету (що відкриває шлях до вставки команд), та генерують результати, яким у кращому випадку можна надати лише часткову довіру. Об’єднання Z3 з Z2 дозволило б викликам інструментів агента успадковувати той самий рівень довіри, що й у авторизованого користувача — що є небезпечним наслідком. Надання агентам власної зони означає, що їхні облікові дані будуть використовуватися виключно для дій агента, без будь-яких інших цілей.

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

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

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

Aurora на практиці: зловмисник вводить команду через компрометовану веб-сторінку, намагаючись обманом змусити дослідницького підагента отримати дані про зарплати співробітників. Політика зони повністю блокує шлях від Z3 до HR, оскільки сфера дії цього розділу просто не включає системи HR. Хаб фіксує спробу, а зловмисник залишається без чогось, крім публічних даних з вебу. Агент був скористаний; дані банку залишилися недоторканими.

Без такої сегментації: один лише витеклий ключ API-з’єднувача надасть зловмиснику — або зловмисному агенту — безперешкодний доступ до всього рівня даних.

Висновок: агенти значно підвищують ризик бічного переміщення в мережі. Правильна зонування перетворює компрометованого агента з причини порушення безпеки на звичайну записану подію.

Основа 5 — Інтеграція типу «хаб та споки»: ідеальна модель для агентів

Питання: як агентам підключатися до 20 та більше корпоративних систем, не перетворюючи шар інтеграції на некерований хаос?

Відповідь — це єдиний Інтеграційний хаб, навколо якого розташовані сертифіковані споки.

Чому це особливо важливо для агентів? Подивіться на арифметику. Пряме підключення всього дає 10 систем на 8 агентів, тобто 80 окремих інтеграцій. Якщо ж все направляти через хаб, то знадобиться лише 10 споків плюс 8 підключень агентів — загалом 18 з’єднань.

Кожен прямий посилання типу «точка-до-точки» є місцем, де облікові дані залишаються закодованими, журнали подій ігноруються, а поведінка системи поступово відхиляється від решти системи. Якщо помножити це на 80 з’єднань, вийде 80 місць, куди аудитор не може повністю заглянути. Агенти погіршують ситуацію, а не покращують її, оскільки кожен новий агент, як правило, прагне отримати доступ до всього.

Централізація через хаб дає можливість контролювати чотири дуже важливі аспекти:

1. Посередництво у автентифікації — хаб зберігає справжні облікові дані Salesforce, тоді як агенти мають лише обмежений та скасовуваний токен хабу. Скасувавши один токен, ви обмежуєте дії лише одного агента, і нічого більше. 2. Переклад схеми — слово „клієнт“ може означати три різні речі залежно від того, чи мова йде про SAP, CRM чи службу підтримки. Хаб узгоджує це один раз, замість того щоб змушувати вісім окремих кодових баз агентів робити це самостійно. 3. Надійність — обмеження швидкості та механізми захисту в хабі запобігають тому, щоб один нестабільний агент спричинив серію повторних спроб у всій групі агентів. 4. Єдиний точка контролю для аудиту — єдиний послідовний формат журналу, єдине місце для відповіді на запитання „який агент змінив яку запис, коли та в яких межах?“

Ще однією перевагою є те, що сервери інструментів у стилі MCP дозволяють елементам мережі стати підключуваними, стандартизованими компонентами замість одноразового коду інтеграції.

Як це працює в Aurora: запуск ServiceNow як системи №21 означає створення одного такого елемента. Починаючи з наступного дня, кожен агент може використовувати його за тією самою моделлю автентифікації, тими самими обмеженнями швидкості та тією самою історією аудиту, що й інші 20 систем. Якби ми використовували підхід «точка-до-точки», це вимагало б вісьмох окремих проектів інтеграції та вісьмох окремих передач даних облікових записів.

Без цього підходу: кожен агент зберігає власну копію пароля Salesforce. Неможливо визначити, який агент змінив певну інформацію про клієнта. Додавання нового інструменту вимагає цілого кварталу роботи інженерів.

Висновок: цей хаб виконує для інструментів ту саму функцію, що й керівник — для агентів: єдиний, повністю оснащений точка входу.

Основа 6 — Архітектура даних: чому потрібні окремі рівні

Питання: як слід структурувати дані, щоб можна було відтворювати результати, скасовувати записи за потребою та зберігати контроль над усім процесом?

Відповідь — п’ять рівнів, розташованих у вигляді конвеєра:

T0 — Джерельні системи. Це системи зберігання первинних даних. Ви не є їхніми власниками, і вони змінюються за власним графіком, без попередження. T1 — Необроблена зона зберігання. Копії всього матеріалу у форматі, в якому він надходить. Це основна точка для будь-якого відновлення; її ніколи не редагують та не видаляють, окрім як згідно з чітко визначеною політикою зберігання. T2 — Опрацьовані дані. Дані, очищені від дублікатів, розділені на частини, позначені щодо персональної інформації та доповнені ідентифікаторами походження. T3 — Шар обслуговування. Векторні індекси, графи знань, семантичні кеші — усі це об’єкти, які можна відновити та які можна створити знову з T2 за потреби. T4 — Дані, створені агентом. Журнали розмов, „спогади“, сліди та результати діяльності. Цей рівень призначений лише для додавання нових даних, рідко планується заздалегідь та часто містить найбільш конфіденційну інформацію в усій системі.

Чому саме п’ять рівнів?

Якщо це нагадує знайому архітектуру медалей — бронза, срібло, золото — це навмисно; рівні T1–T3 є саме такою усталеною схемою. Те, що додає контекст агентів, — це два рівні на кожному кінці: чіткий кордон на вході (T0, оскільки потрібно чітко визначити умови отримання даних) та рівень для результатів роботи агента (T4, оскільки продукти роботи агентів також є даними, які мають власні вимоги щодо зберігання, конфіденційності та аудиту).

Структурування даних у рівні перетворює дві інакше складні проблеми на звичайну роботу:

1. Відтворюваність. Замість того, щоб фраза „ми змінили стратегію розділення даних, і тепер відповіді інші“ перетворювалася на кризу, ви просто перебудовуєте T3 з T2 протягом ночі. Якщо модель пошкоджується, ви генеруєте T2 заново з T1. Вам ніколи не доводиться заново сканувати початкові системи даних.

2. Видалення. Коли клієнт скористається своїм правом на видалення згідно з GDPR, чітка ієрархія означає, що запит на видалення детерміновано проходить через T1, T2, T3 та T4 за допомогою ідентифікатора — без необхідності ручного пошуку.

Основне правило, яке лежить в основі всього цього: векторний індекс — це кеш, а не джерело істини.

Як це відбувається в Aurora: відділ QA виявив, що логіка розділення даних потайки видаляла рядки таблиць. Aurora протягом ночі повторно вставила два мільйони документів з T2 за допомогою виправленого інструменту розділення, без необхідності повторного сканування будь-якої вихідної системи та без паніки через втрату історичних даних. Через місяць команда змогла відтворити та порівняти, як було б відповідати на певне запитання до та після виправлення.

Без рівнів зберігання: сховище векторів стає єдиною копією даних. Видалення в вихідній системі ніколи не поширюється далі. На запитання на кшталт „Що сказав асистент цьому клієнту у березні?“ просто неможливо відповісти.

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

Стовпчик 7 — Агентний дизайн: чому керівник із підагентами кращий за моноліт

Питання полягає у тому: як слід структурувати „суспільство“ агентів, які складають вашу систему?

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

Чому розподіл обов’язків кращий за створення одного величезного агента з п’ятдесятьма доданими інструментами?

1. Контекст швидко розмивається. Коли одному агенту доводиться використовувати п’ятдесят інструментів та досягати невизначеної мети, його продуктивність значно падає — неправильний вибір інструментів, забуття обмежень, втрата контексту завдання. Спеціаліст, який має п’ять інструментів та чітко визначений обсяг роботи, є набагато надійнішим. 2. Це можна фактично протестувати. Не існує змістовного способу проведення модульних тестів для величезних мегапромптів. Але можна створити окремий набір тестів для кожного підагента — наприклад, 200 тестових випадків для дослідника та 50 для письменника. Це перетворює тестування на регресії агентів на щось реальне та повторюване. 3. У вас є єдиний контрольний пункт. Керівник стає місцем, де ви встановлюєте бюджети (ліміт у 12 кроків або 0,40 євро за завдання), керуєте повторними спробами, ініціюєте втручання людини та забезпечує контроль під час кожної передачі завдань. 4. Робота виконується паралельно, а компоненти можна замінювати.

Підагенти можуть працювати одночасно, і будь-кого з них можна замінити — на потужніший LLM, дешевший варіант чи алгоритм пошуку з повною детермінованістю — без порушення роботи решти системи.

Варто підкреслити, що «підагент» не означає «LLM на кожному рівні». У конфігурації Aurora підагент калькулятора доступності зовсім не містить LLM — це детермінований код, оформлений у вигляді інтерфейсу агента. Це передвіщає принцип 8 Pillar.

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

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

Висновок: розділення роботи — це не лише питання ефективності. У системах з агентами це є основою надійності.

Етап 8 — Детермінізм проти міркувань: найважливіше рішення

Питання: саме де в системі ви дозволяєте ймовірнісному розуму ШІ брати на себе керування, а де поведінка залишається визначеною кодом та правилами?

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

Керівний принцип простий:

LLM пропонують. Детерміністичні системи приймають рішення.

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

На практиці це означає розглядати ваші робочі процеси як машини станів, де LLM може голосувати лише у конкретних, перелічених точках прийняття рішень, а звичайний код керує всім іншим.

Чому цей вибір є найважливішим у дизайні? Тому що він впливає на все інше, що слідує після нього:

1. Надійність — шляхи, пов’язані з грошима, не допускають несподіваної поведінки. 2. Перевірюваність — оскільки можливі варіанти рішень є перелікованими, ви можете вказати кожну точку, де було прийнято рішення. 3. Контроль витрат — ви уникаєте витрачання токенів на завдання, які проста конструкція if вже вирішує безкоштовно. 4. Цілісність архітектури — системний керівник з Розділу 7 встановлює цей кордон, хаб з Розділу 5 забезпечує його дотримання на рівні інструментів, зони з Розділу 4 містять усі помилки, а сховище доказів з Розділу 9 пізніше підтверджує, що насправді сталось.

Aurora на практиці — процес повернення грошей:

1. LLM у зоні міркувань: читає електронний лист клієнта та витягує структуровані поля — сума: €145, причина: пошкоджені товари, настрій: розчарований. Цей крок є ймовірнісним, і це прийнятно, адже він лише заповнює форму.
2. Детерміністичний механізм прийняття рішень: суми до €200 автоматично схвалюються; суми від €200 до €1,000 підлягають перевірці за правилами; будь-які суми понад €1,000 вимагають підтвердження людини. LLM ніколи не має повноважень на переказ грошей — він може лише запропонувати суму, а сам код вирішує, що з нею робити.

Обидва крайні варіанти є небезпечними, тому необхідно дотримуватися середнього шляху:

Якщо дозволяти ШІ вирішувати все („Просто нехай агент цим займається“), то в результаті може з’явитися електронний лист, створений за допомогою спеціального запиту, який схвалює повернення 50 000 євро. Якщо ж дозволяти правилам вирішувати все, це означає систему, яка навіть не може розпарсити звичайний електронний лист — фактично повернення до умов 1995 року.

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

Основа 9 — Пов’язування з доказами/Цитування: чому це підтримує можливість аудиту

Питання: Як зробити кожен результат захищеним — через місяці чи навіть роки після подій, для аудитора, який активно шукає недоліки?

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

Чому це витримує перевірку? Тому що це забезпечує три гарантії одночасно:

1. Блокування галюцинацій. Якщо немає посилання, то немає публікації. Коли етап генерації відповіді не може надати достовірне джерело, результат отримує позначку або пригнічується. Це перетворює принцип „просто довіряйте моделі“ на обов’язкове до виконання механічне правило.

2. Повна можливість повторного відтворення. Якщо хтось запитає: «Чому система відреагувала так 3 березня?», ви можете відтворити точну послідовність — початкове запитання, отримані уривки, версію запиту, версію моделі, створену відповідь та її посилання. Замість фрази «ми вважаємо» ви наводите самі фактичні записи.

3. Чіткість первинної причини. Коли результат виявляється неправильним, ви можете негайно визначити тип помилки: чи це була неправильна заготівка інформації (були взяті неправильні докази), чи помилка у міркуваннях (були взяті правильні докази, але їх неправильно інтерпретували)? Для виправлення цих ситуацій потрібні зовсім різні підходи, і без переконливих доказів неможливо їх розрізнити.

Аврора на практиці: Асистент відповідає на запитання щодо умов штрафів, посилаючись на credit_policy_v12.pdf, сторінка 14, sha256:9f2c…. Пізніше, коли виходить версія політики 13, ця попередня відповідь все ще точно відображає те, що було актуальним у момент її надання, оскільки посилана інформація фіксується за допомогою хеша, а не завантажується знову динамічно. Оглядач вимог може схвалити її, тому що вся ланцюгова структура є відтворюваною, захищеною від змін та правильно позначеною часом.

Якщо пропустити це, то: вашим єдиним захистом під час інциденту або аудиту стане твердження „так сказав модель“. Ви втрачаєте можливість розрізняти проблеми з якістю даних та помилки у міркуваннях. Регулятори назвуть таку систему „чорною скринькою“ — а чорні скриньки закривають.

Висновок: якщо система не може посилатися на джерело, її не публікують.

Як взаємопов’язані дев’ять стовпів

Ці дев’ять елементів — це не просто список окремих аспектів; вони утворюють єдину цілісну структуру з ядром:

Якщо видалити будь-який зі стовпів, решта починає руйнуватися. Якщо прибрати шар „центр-спиці“ (5), детермінізм (8) більше не може застосовуватися на рівні виклику інструментів. Якщо прибрати рівні зберігання даних (6), у механізму підтвердження наявності доказів (9) не залишається нічого надійного для посилання. Якщо прибрати документацію C4 (3), ви втрачаєте можливість навіть пояснити решту архітектури під час аудиту. Вони функціонують лише як сукупність — або всі дев’ять елементів працюють, або вся структура руйнується.

Що буде у цій серії

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

Останні думки

До 2026 року наявність потужної моделі більше не є конкурентною перевагою — ключ API може отримати кожен.

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

Дев’ять основ. Дев’ять рішень. Потрібно виконати їх усі правильно одночасно.

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