Асистентам з розслідувань у корпораціях потрібні EA, LangGraph, MCP та RAG.

Корпоративна архітектура для асистента з розслідувань з кількох джерел — бек-офіс, журнали Grafana та підсумки транзакцій

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

Чому це проблема корпоративної архітектури, а не проєкт «чат-бота»

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

ADM у одному реченні

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

Попередня фаза — принципи перед запитами

Ще на початку слід домовитися про принципи: мінімальні повноваження, обов’язкове посилання або відмова, інструменти мають бути перевірені, тоді як RAG надає пояснення, а людина схвалює незворотні дії. Без принципів кожен новий з’єднувач створює власну модель довіри.

Фаза А — Бачення архітектури: проблеми у мові бізнесу

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

Фаза Б — Бізнес-архітектура: що означає розслідування

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

Фаза C — Архітектура даних: три істини, один часовий рядок

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

Фаза D — Технологічна архітектура: LangGraph, MCP, ролі RAG

LangGraph координує робочі процеси з розслідуванням із збереженням стану. MCP забезпечує доступ до керованих інструментів у ізольованих системах. RAG узагальнює та пояснює інформацію; він не створює баланси без підтвердження.

User question →
classify intent + extract entities (player_id, time window, txn id)
→ plan tools (which sources, in what order)
→ execute tools (parallel where independent)
→ reconcile (timeline merge, conflict detection)
→ answer (cited) OR escalate

Чому саме LangGraph? (Рішення ARB)

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

MCP — один протокол, багато корпоративних меж

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

RAG — пояснює; інструменти підтверджують

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

Етап E — можливості та рішення

Створюйте систему оркестрації власноруч; купуйте або повторно використовуйте конектори там, де постачальники вже інтегрують основні системи; уникайте переписування Grafana чи бухгалтерських книг.

Етап F — міграція: пілот без ризиків для банку

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

Етап G — Управління реалізацією

ARB фіксує рішення: які інструменти дозволені, де зберігаються секрети та як зберігаються сліди.

ADR-008:
Player investigation assistant
LangGraph orchestration, MCP tools, RAG for context onlyStatus:
Accepted Date: 03/01/2026
Deciders: Architecture Board, Support Ops, Fraud, Payments, SRE, Data Platform, Risk
Context: Support, fraud ops, and back office investigate player issues by manually querying transaction summaries, Grafana/Loki logs, and back-office APIs. Answers are slow, inconsistent, and hard to audit. A generic "chat with your data" approach risks hallucinated financial facts and unbounded database access.
Decision Build an internal player investigation assistant: LangGraph- stateful orchestration (classify → plan → execute tools → reconcile → answer or escalate). Chosen over linear chains and one-shot prompts because investigations branch (payment vs gameplay vs bonus), require explicit state for audit, and need deterministic edges (e.g. FAILED txn → always pull payment-service logs) that ARB can diagram and version in Phase H MCP servers - one bounded tool surface per system of
record: `transaction_summary` - read-only parameterized queries on summary views `grafana_loki` - time-bounded LogQL with service allowlist `back_office` - scoped REST for account flags and context RAG - embed docs only (schema, enums, runbooks, ADR snippets); never live txn rows or log streams Citations required - factual claims must reference tool output ids Fail closed on ambiguous `player_id` or conflicting tool resultsConsequences Positive: Faster investigations; consistent citations; reusable MCP servers for future automations; clear security boundary (tools vs retrieval). Negative: LangGraph flow maintenance; MCP server ownership per domain team; golden-question regression suite required on model changes. Obligations: No free-form SQL from the model; quarterly access review; version MCP schemas when summary views change; shadow mode before full rollout.Alternatives considered | Alternative | Why rejected | |-------------|--------------| | Single prompt with DB + Grafana credentials | Ungovernable; audit nightmare | | RAG over exported txn/log snapshots | Stale truth; PII surface area | | Buy vendor "AI ops" suite only | Poor fit to gaming txn + custom back office; lock-in | | Dashboards only | Solves visibility, not synthesis and audit trail | | Autonomous agent with write tools | Unacceptable risk on wallet/account paths for v1 |

Етап H — Управління змінами

Моделі постійно змінюються; політика розслідувань має залишатися незмінною. Використовуйте попередження про версії та інструменти на кшталт API; перепідготовлюйте співробітників, коли змінюється поведінка щодо відхилення запитів.

Що ми дізналися („та“, а не „проти“)

LangGraph та MCP та RAG співпрацюють: забезпечуючи оркестрацію, доступ та пояснення. Розглядати їх як конкурентів — це марна трата архітектури.

Коли не варто це створювати

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

Підсумок

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

Більш детальні примітки щодо приєднання до фази C

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

Більш детальні примітки щодо плану керування фази D

Стан LangGraph має містити ідентифікатор розслідування, ідентифікатор учасника, дозволений набір інструментів та список гіпотез. Описи інструментів MCP повинні вказувати клас побічних ефектів (читання чи запис). Колекції RAG поділяються за рівнем конфіденційності. ARB має відхиляти конструкції, які дозволяють моделі створювати SQL-запити до продакшн-сховищ; лише підготовлені інструменти можуть впливати на ці системи.

Критичні показники для оцінки

• Медіанний час до отримання першого посиланого доказу
• Відсоток відповідей з принаймні двома незалежними типами джерел
• Частка випадків людського втручання під час використання інструментів
• Частка відмов через недостатню кількість доказів
• Кількість спроб доступу від інших користувачів, які було заблоковано

Такі показники, як „кількість надісланих повідомлень“, не свідчать про цінність для розслідування.

Антипатерни

Створення мега-індексу всього без полів ACL; дозвіл ШІ обирати примітивні драйвери баз даних; пропуск фази H, через що запити змінюються щотижня без перевірки; використання Grafana як необов’язкового інструменту для кольорування замість першокласного каналу отримання даних про збої під час роботи.

Приклад з описом процесу

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

Знімки архітектури безпеки

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

Взаємозв’язок із існуючим ITSM

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

Навички проти базових інструментів (додатковий рівень)

У міру зростання каталогів інструментів навички аналізу можуть об’єднувати послідовності дій (отримання випадку → збір транзакцій → пошук у журналах → підсумування), тоді як MCP залишається шаром функціональностей. Це відображає загальний напрямок розвитку галузі та не вимагає створення нового стандарту, поки пілотний проект не доведе його корисність.

Короткий огляд для ARB

Просіть фінансування на основі скорочення часу обробки та покращеної можливості аудиту, а не на основі „наявності агента“. Покажіть демонстрацію послідовності змін „до/після“ з використанням трьох джерел інформації. Пообіцайте відмовитися від використання тарифів та тестів ACL як критеріїв випуску продукту. У такому формулюванні LangGraph та MCP є деталями реалізації схваленої архітектури, а не окремим науковим проєктом поруч із нею.

Контракти на дані для трьох істин

Опублікуйте невелику схему для CaseEvent, LogAnchor та LedgerPosting, якою користуються інструменти MCP та індексатори. Часові шкали розслідувань десеріалізують ці об’єкти, а не вільний текст. Якщо джерело не може надати певне поле, вкажіть його як null прямо, щоб синтезатор не міг вигадати значення. Контракти еволюціонують через той самий шлях ARB, що й сервіси — а не лише шляхом редагування запитів.

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