Архитектура AI-автоматизации для финансовых компаний

Financial companies do not fail AI projects because the model is too dumb. They fail them because the architecture treated a regulated firm like a chatbot demo: keys in the prompt, writes without a gate, state in a vendor’s cloud, and no one who can explain a number six months later.

The architecture that survives a bank, a broker, or a serious finance team is boring on purpose. Isolation, brokerage, review, and files. Capability can jump 100×. The control plane should not have to be redesigned when it does. That is what we mean by AGI-ready architecture, applied to money.

This is the blueprint we recommend — and the one Neuro OS implements. It is not the only possible design. It is the one you can defend to risk, audit, and a CISO who has already said no to three copilots.

The constraints that are not optional

• Каждая цифра связана с источником. «Модель так сказала» не является контролем. Артефакт должен содержать запрос, выдержку или документ.
• Записи закрыты. Публикация, оплата, отправка клиенту или изменение доступа — это человеческое решение. Агент готовится; он не исправляет ситуацию молча.
• Учетные данные не хранятся в машине. Песочница, в которой хранится токен основного банка, является инцидентом. Брокер вызовов на стороне сервера.
• Вы можете поменять модель. Блокировка поставщика на уровне разведки представляет собой риск концентрации. Суверенитет является предметом комплексной проверки.
• Вы можете запустить его внутри своего периметра. Если личные данные и выдержки из бухгалтерской книги не могут быть удалены, платформа должна размещаться самостоятельно. Открытый исходный код — это то, как вы читаете то, что используете.
• Агенты — это принципалы. Проверка доступа, охватывающая людей, а не автоматизацию, — это половина проверки. См. ИТ и Финансы.

Пять слоев

1. A real machine per session, thrown away

Do not run finance agents in a shared notebook runtime or a long-lived container that accumulated last quarter’s extracts. Each session gets its own disposable Linux machine and its own branch. Sessions do not share a filesystem. An extract pulled for the close is not visible to the support agent.

This is slower to explain in a slide than “we use GPT.” It is the difference between a workspace and a blast radius.

2. Connectors as a gateway, not as env vars

Stripe, the ledger, the warehouse, Sheets, Outlook, Slack: each is a connector with its own Allow / Ask / Block. The agent sees tools. The keys stay on the platform, decrypted for the outbound call, then discarded.

Grant per agent. The reporting agent reaches the warehouse and Drive. It does not reach payroll because you did not list payroll. It cannot discover that the connector exists.

If a system has no API, do not pretend. The honest design is workbook-in, approval-out — the same position we take on the finance solution page.

3. Skills and policies as files in a repo you own

How your close works — matching rules, commentary style, what “material” means — must not live in a chat history. It lives in SKILL.md, scripts, and a manifest. You review it with git diff. You roll it back. A consultancy that leaves you a Notion full of prompts has not left you an architecture.

This is the opposite of a compiled proprietary workflow language. If the process is compiled into a runtime you cannot clone, you do not own the control environment. Who owns the code?

4. Human-in-the-loop as a protocol, not a slogan

Shipped defaults on most agent products are permissive: the action runs unless you said otherwise. For finance, that sentence should be in the risk register. Set:

• Allow on reads against systems you intended to connect.
• Ask on any create, update, send, or post. The run pauses with the exact payload.
• Block on irreversible payments, customer messages, and anything your policy already forbids a junior from doing unsupervised.

The approval object is the control. The transcript is the evidence.

5. Spend and identity on the work itself

Token capital is a budget, not a surprise. Caps belong on the agent and the task, with receipts attached to the session — the same way you would not give a contractor an open vendor card. Budgets. SSO (SAML), audit records per tool call, and a deployment story that is cloud, VPC, or on-prem.

What to reject

A reference topology

[Channels: Slack / email / cron]
        → session (isolated VM + branch)
            → skills + scripts from git
            → connector gateway (keys never in VM)
                 → ledger / warehouse / bank / Drive  (reads: Allow)
                 → posting / mail send                 (writes: Ask)
            → artifacts (workbook, note, query) on the branch
        → change request or approval
        → main / posted books  (human)

Triggers matter. The monthly pack is a cron. The “why is cloud over plan?” question is on-demand in a thread. The agent is the same; the isolation and the gates do not change with the trigger. That is heartbeats plus governance.

Where Pattern Automation sits

We are not a model lab and we are not an RPA vendor. Neuro OS is the AI management system: org chart of agents, connectors, budgets, review, and a git-backed company memory. You bring the models. You keep the files. You run it where the data is allowed to live.

If you are choosing a stack for a regulated finance function, score vendors on the table above, not on a demo that reconciled four rows in a sandbox spreadsheet. The demo will work. The architecture is what you live with after the audit letter arrives.

Узнать про Neuro OS →