Архитектура AI-автоматизации: от события до проверяемого действия

Проблема: ответ модели ещё не является автоматизацией

AI-автоматизация становится production-системой только тогда, когда реальное бизнес-событие проходит через явные контракты и заканчивается проверенным, атрибутируемым действием. Ответ модели в demo — лишь промежуточный артефакт. Production должен также знать, что запустило workflow, какая версия данных использовалась, что системе было разрешено сделать, кто согласовал consequential decision, приняла ли целевая система запись и как результат можно исправить.

Эта статья отвечает на узкий технический вопрос: как построить архитектуру AI-автоматизации от события до проверяемого действия? Она не заменяет широкие страницы услуги AI-автоматизации и AI-специалиста в Армении. Commercial discovery intent принадлежит этим landing pages; здесь собраны архитектурные критерии для оценки одного bounded workflow.

Первое решение — не выбор модели. Сначала нужна граница процесса:

• одно именованное бизнес-событие;
• один ожидаемый результат;
• один владелец процесса;
• определённый набор разрешённых действий;
• representative normal, ambiguous и failure cases;
• наблюдаемое условие завершения;
• recovery path, который не требует восстанавливать скрытые рассуждения модели.

Если эти элементы нельзя сформулировать, workflow не готов к автономной записи. Он всё ещё может подойти для discovery, summarization или draft mode. Аудит готовности данных помогает понять, пригодна ли evidence base, а матрица выбора первого AI-пилота — стоит ли начинать именно с этого process slice.

Требования до архитектурной схемы

Архитектура должна начинаться с последствий отказа и способа проверки, а не с happy-path prompt. Практический requirements brief покрывает пять групп вопросов.

1. Контракт события

Что именно запускает workflow? У события должны быть стабильный identifier, источник, время создания, версия схемы и correlation ID. Формулировка «пришло новое письмо» недостаточна: письмо может быть доставлено повторно, переслано, изменено или получено через несколько каналов. Контракт должен отличать исходное событие от попыток его доставки.

Intake boundary отклоняет malformed events, сохраняет original payload там, где это допускает политика, и фиксирует решения по нормализации. Он не должен молча превращать отсутствующий customer ID в пустую строку или придумывать currency, language либо timezone.

2. Контракт решения

Что AI вправе предложить, а что не должен решать самостоятельно? Decision contract определяет output schema, разрешённые значения, требования к evidence, поведение при uncertainty и условия обязательного human review.

Это не просто «верни JSON». Это бизнес-граница. Например, support workflow может подготовить черновик ответа и классифицировать urgency, но не должен обещать возврат денег, раскрывать restricted account data или закрывать претензию без уполномоченного reviewer.

3. Контракт действия

Какая запись разрешена в target system? Каждому действию нужны idempotency key, target resource, precondition, authorization scope и ожидаемый acknowledgement. Executor принимает только validated commands, а не свободный текст модели.

Контракт также определяет success. HTTP 200 может означать rejected business operation, queued state или partial write. Проверка должна читать durable state целевой системы либо authoritative receipt.

4. Операционный контракт

Кто владеет alerts, approvals, retries и incident decisions? Каков latency budget? Сколько может ждать approval? Какие ошибки retriable? Когда run попадает в dead-letter queue? Какие изменения требуют rollback?

Архитектура без оператора — схема, а не сервис.

5. Контракт evidence и retention

Какие inputs, source references, model configuration, policy version, decisions, actions и receipts нужно хранить? Retention должен соответствовать бизнес- и legal-требованиям. Sensitive raw content нельзя копировать в каждую строку логов только потому, что системе нужна observability.

TRACE-9: авторская архитектура event-to-action

TRACE-9 — reference architecture, созданная для этой статьи. Она разделяет девять контрактов, чтобы каждый этап можно было независимо тестировать, повторять и аудировать.

Аббревиатура описывает маршрут, а девять стадий устраняют распространённую ошибку: inference нельзя считать execution. Модель участвует в Evaluate. Она не владеет Trigger, authorization, final validation, execution, reconciliation или operational diagnosis.

Typed process envelope

Normalized envelope — контракт между ingestion и decision logic. Он переносит business state вместе с control state:

type ProcessEnvelope = {
  eventId: string;
  correlationId: string;
  tenantId: string;
  processType: "support_triage";
  schemaVersion: "1.0";
  occurredAt: string;
  receivedAt: string;
  input: unknown;
  permittedActionTypes: readonly string[];
  policyVersion: string;
  sourceRefs: readonly { id: string; version: string }[];
  attempt: number;
};

Точная implementation language не важна. Важно, что identity, versioning, authorization context и retry state явны. Prompt, собранный из произвольных строк, не может быть system of record.

Ключевые компоненты и их контракты

Durable intake вместо хрупкой цепочки webhooks

Webhook handler аутентифицирует источник, проверяет outer schema, назначает или проверяет identifiers, сохраняет событие и быстро отвечает. Длинный model call и запись в target system не должны выполняться внутри request lifecycle, если источник может дождаться timeout и повторить доставку.

Queue сама по себе не гарантирует надёжность. Нужны visibility timeout, maximum attempts, dead-letter handling и replay rules. Replay сообщения не должен повторять уже завершённое business action.

Context builder с permission filtering

Context builder извлекает только evidence, разрешённое для данного tenant, пользователя, процесса и purpose. Access control применяется до передачи контента модели. Фильтрация generated text после inference не отменяет unauthorized disclosure.

Каждый источник должен иметь stable ID и version. Тогда reviewer видит, на чём основано решение, а test воспроизводит его без зависимости от последней mutable версии документа.

Bounded inference adapter

Model adapter изолирует provider-specific детали: request format, timeout, structured output, model identifier, prompt или policy version, token limits и fallback. Business workflow зависит от typed proposal, а не от raw response конкретного provider.

Retries должны быть bounded. Три повтора одного invalid prompt — это не resilience, а повторные расходы. Schema error может оправдать одну constrained repair attempt. Rate limit — delayed retry. Policy failure нельзя повторять как transient error.

Детерминированные validators

Validators проверяют то, что код способен проверять надёжно: schema, required evidence, ranges, permissions, version freshness, prohibited actions и cross-field consistency. Model self-critique может дополнять evaluation, но не заменяет deterministic policy checks.

Результат должен быть явным: accept, human_review, reject или retryable_error. Boolean valid скрывает причину маршрута.

Human approval service

Human review требует durable queue, evidence packet, named authority, decision timestamp, reason и expiry behavior. Reviewer видит proposed action, material source evidence, uncertainty, policy flags и эффект согласования.

Approval связывается с точным proposal и актуальной версией ресурса. Если account, order или document изменились во время ожидания, executor повторно валидирует состояние и не применяет stale decision.

Idempotent action executor

Executor принимает validated command, выводит stable idempotency key и выполняет минимально разрешённую запись. Он отличает transport success от business acceptance.

Если target system не поддерживает native idempotency, нужен execution ledger по event, action type и target. Read-before-write иногда снижает duplicates, но не всегда закрывает race condition. Предпочтительны conditional writes или version checks.

Reconciliation и observability

После действия система читает authoritative state или проверяет durable receipt. Reconciliation отвечает на вопрос «стал ли ожидаемый business postcondition истинным?». Request log отвечает лишь «отправили ли мы запрос?».

Observability связывает event, proposal, validation, approval, action и receipt одним correlation ID. Полезные operational signals: completion rate по маршрутам, human-review rate, severe validation failures, duplicate suppression, reconciliation mismatch, latency по стадиям и cost per successfully verified action.

Это определения для instrumentation, а не заявления о показателях aicoding.am или клиентских систем.

Архитектурные компромиссы

TRACE-9 не означает, что каждый pilot обязан сразу получить отдельный сервис на каждую стадию. Контракты важнее количества deployable units. В небольшом bounded workflow Trigger, Record и Adapt могут работать в одном приложении, а Gate и Act — в другом модуле того же runtime. Разделять их на microservices стоит только при независимом scaling, разных security boundaries, разных владельцах или необходимости отдельного release cadence.

Синхронный путь проще читать, но плохо переносит длинный inference, внешние approvals и rate limits. Асинхронный путь лучше изолирует задержки и retries, однако добавляет очередь, ordering, correlation, dead-letter handling и eventual consistency. Практический критерий: если source не может безопасно ждать весь workflow или событие должно пережить restart, intake должен стать durable до ответа источнику.

Единая transaction между AI workflow и внешней CRM, ERP либо messenger обычно невозможна. Поэтому architecture должна проектировать postconditions и compensation, а не обещать distributed rollback. Для reversible действий можно сохранить previous value и выполнить compensating write. Для необратимых действий — отправки денег, юридически значимого уведомления, удаления данных — human gate и pre-action revalidation важнее автоматического compensation.

Кэш context снижает latency и cost, но создаёт риск stale evidence и permission drift. Cache key должен учитывать tenant, policy version, source version и purpose. Critical fields перед consequential action читаются заново из authoritative source, даже если inference использовал cached context.

Model fallback тоже является компромиссом. Замена модели может изменить output distribution, language quality и failure profile. Fallback допускается только как versioned route с теми же schema и evaluation thresholds. Если equivalence не доказана, безопаснее перейти в human review или degraded assistive mode, чем незаметно выполнить действие другим model path.

Наконец, более высокая автономность не является целью сама по себе. Хорошая архитектура минимизирует необратимый blast radius и даёт оператору понятный способ остановить, проверить и восстановить процесс. Иногда лучший production-result — draft mode с быстрым human approval, а не fully autonomous agent.

Ошибки и failure modes

Повторная доставка

Источники повторяют запросы, очереди redeliver, операторы запускают replay. Без stable event identity и idempotent execution одно сообщение создаёт два тикета, а одно согласованное действие выполняется дважды.

Контроль: immutable event ID, execution ledger, target idempotency key и reconciliation.

Нарушение порядка событий

Update может прийти до create, а старое событие — повториться после появления более нового state.

Контроль: source sequence или resource version, conditional writes и explicit stale-event route.

Устаревшее согласование

Reviewer согласовал proposal на основании вчерашнего balance, inventory или policy.

Контроль: approval привязан к proposal hash и resource version; critical state повторно читается непосредственно перед action.

Неподтверждённое действие

Модель предлагает field, discount, recipient или tool call, для которых нет evidence либо permission.

Контроль: allowlisted action schema, требования к источникам, deterministic validation и abstention route.

Частичная запись

Одна система изменилась, а downstream dependency отказала. Blind retry может усугубить state.

Контроль: явный saga или compensation design, step-level receipts и incident route для необратимых действий.

Retry storm и усиление расходов

Provider outage или malformed response запускает повторы на уровнях webhook, queue, inference и executor.

Контроль: один retry owner на boundary, exponential backoff with jitter, attempt budget, circuit breaker и dead-letter queue.

Permission drift

Access rights или business rules изменились, а cached context остался доступен.

Контроль: short-lived authorization decisions, policy version в envelope и revalidation перед consequential write.

Observability без privacy boundary

Debug logs случайно сохраняют полные документы, personal data, tokens или secrets.

Контроль: structured redacted logs, reference IDs вместо raw content, отдельное protected evidence storage и reviewed retention windows.

Тестирование архитектуры

Production confidence создаётся слоями тестов, а не одним end-to-end demo.

Contract tests

Проверяйте event schemas, normalized envelopes, model proposal schemas, action commands и target receipts. Добавьте unknown fields, missing fields, version mismatch и malformed dates. Provider adapters проверяются на recorded safe fixtures или controlled sandbox.

Decision evaluation

Соберите versioned набор representative cases: normal, ambiguous, adversarial и prohibited. Оценивайте factual support, action correctness, abstention, policy compliance и severe-error count. Результаты разделяйте по material segments: язык, канал или process subtype.

Integration tests

Тестируйте queue redelivery, target timeouts, expired credentials, rate limits, stale versions и partial acknowledgements. Подтвердите, что retry не повторяет completed action.

Failure injection

Намеренно отключите model provider, повредите один context source, задержите approval, верните ambiguous target response и создайте reconciliation mismatch. Проверьте route, alert и информацию для operator.

Shadow и draft modes

Запустите архитектуру без consequential writes. Сравнивайте proposals с фактическими outcomes и decisions reviewer. Draft mode полезен, только если corrections сохраняются так, чтобы улучшать evaluation и правила.

Production-чек

До включения write path проверьте:

• named один process slice и один accountable owner;
• event, proposal и action schemas versioned;
• source permissions применяются до inference;
• consequential actions имеют explicit human boundaries;
• validators возвращают reasoned routes, а не opaque booleans;
• retries bounded и принадлежат одному слою;
• idempotency проверена duplicate и replay scenarios;
• approvals истекают, critical state revalidated;
• target success подтверждается authoritative state;
• dead-letter и repair queues имеют operators и service expectations;
• logs correlated, structured и redacted;
• model, policy и source versions traceable;
• severe errors блокируют release;
• rollback или compensation протестированы, где это возможно;
• cost и latency измеряются на verified action, а не на model call;
• runbooks определяют, кто может pause, replay, override и restore workflow.

Путь от прототипа к controlled production

Практический rollout состоит из четырёх gates.

1. Replay: исторические или synthetic cases без внешних действий. Проверяются contracts и decision evaluation.
2. Shadow: live events обрабатываются, но outputs не видны target users. Измеряются routing, freshness и operational behavior.
3. Draft: proposals показываются authorized operators; каждое consequential action остаётся ручным. Фиксируются corrections и stale-state cases.
4. Bounded action: включаются только allowlisted, reversible или строго contained действия. Scope расширяется после устойчивой reconciliation и incident evidence, а не после эффектного demo.

Architecture review должен закончиться решением: slice готов к bounded production, требует исправления, должен остаться assistive или пока не должен автоматизироваться. Кейсы показывают тип инженерного evidence, который поддерживает такое решение. Для конкретной системы стоит запрашивать архитектурное ревью только после того, как определены event, owner, intended action и последствия отказа.