Архитектура корпоративного ассистента

Иллюстрация. Граница MCP: агенты работают через управляемый шлюз, а не держат прямые ключи к корпоративным системам.

Когда руководитель слышит слово “архитектура”, он часто ожидает техническую схему, которую можно отдать CTO и больше не думать.

С AI-Native так не получится.

Архитектура корпоративного ассистента — это не только технический вопрос. Это способ управлять доверием: кто имеет доступ к данным, что может делать ассистент, где проходит граница безопасности, как проверяется результат, что сохраняется в памяти компании и где человек принимает решение.

Если архитектура не продумана, ассистент быстро превращается в риск.

Он может получить слишком широкие права. Начать читать документы, которые пользователь не должен видеть. Использовать устаревшие данные. Отправить чувствительную информацию во внешнюю модель. Выполнить действие без проверки. Оставить компанию без понятного журнала: кто что запросил, на основании каких данных и какой результат получил.

Поэтому зрелый AI-Native контур начинается с простого принципа:

Агент не должен иметь прямой хаотичный доступ к

корпоративным системам.

Ему нужен управляемый слой между человеком, моделью и

данными.

Базовая схема

Упрощенно архитектура корпоративного ассистента выглядит так:

сотрудник ↓

единый интерфейс ассистента ↓

слой ассистентов и агентов ↓

skills ↓ MCP-шлюз

↓ корпоративные системы, документы, память, инструменты

Каждый слой выполняет свою задачу.

Сотрудник ставит задачу и остается владельцем решения.

Интерфейс дает понятную точку входа: чат, рабочее приложение, IDE, портал, мессенджер или встроенный помощник в корпоративной системе.

Слой ассистентов и агентов выполняет работу: анализирует, готовит, проверяет, запускает инструменты, задает уточняющие вопросы.

Skills задают рабочие протоколы: как выполнять конкретную задачу, какие источники использовать, какие ограничения соблюдать.

MCP-шлюз управляет доступом к данным и действиям.

Корпоративные системы остаются источниками правды и местами фиксации результата.

Такая архитектура нужна не для красоты. Она нужна, чтобы компания могла масштабировать ИИ без потери контроля.

Единый вход для сотрудника

В компании может быть много моделей, инструментов и агентов. Но для сотрудника вход должен быть простым.

Если человек должен думать, куда идти за каждой задачей, внедрение быстро распадается.

Для одного сценария он открывает ChatGPT. Для другого — внутренний бот. Для третьего — IDE. Для четвертого — отдельную страницу. Для пятого — просит коллегу из ИТ. Через месяц никто не понимает, где что находится, какие данные можно загружать и какой инструмент согласован.

Поэтому зрелая модель строится вокруг понятных входов.

Это может быть:

корпоративный ассистент в портале;

ассистент в мессенджере;

агентная среда для разработчиков;

помощник внутри CRM или системы задач;

автономный агент для фоновых процессов.

Главное — не количество интерфейсов, а ясность:

для какой роли этот вход;

какие задачи через него решаются;

какие skills доступны;

какие данные можно использовать;

где находится результат;

кто отвечает за поддержку.

Единый вход не означает один экран на всю компанию. Он означает единый принцип работы.

Слой ассистентов и агентов

В книге мы используем два близких слова: ассистент и агент.

Ассистент обычно работает рядом с человеком. Он отвечает, уточняет, готовит черновик, помогает думать, проверяет результат.

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

В реальной архитектуре компании могут быть разные среды:

диалоговый ассистент для бизнес-пользователя;

инженерный агент для разработки;

агент в IDE;

автономный агент для регулярных проверок и отчетов;

специализированный агент для продаж, закупок, поддержки, финансов или управления проектами.

Важно не то, как называется конкретный инструмент.

Важно, чтобы все они подчинялись общим правилам:

используют утвержденные skills;

ходят к данным через управляемый слой;

соблюдают права пользователя;

оставляют след действий;

не получают секреты напрямую;

передают важные решения человеку.

Если каждый агент живет по своим правилам, компания получает новый хаос.

Если агенты подключены к общей архитектуре, они становятся разными исполнителями в одной операционной системе.

Skills как слой поведения

Skills находятся между человеком и инструментами.

Они описывают, как ассистент должен выполнять работу.

Без skills агент слишком универсален. Он может многое, но каждый раз по-разному. Один сотрудник получает хороший результат, другой — слабый. Один агент использует правильный источник, другой — нет. Один помнит ограничения, другой их пропускает.

Skills задают повторяемость.

Например:

подготовить коммерческое предложение;

разобрать договор;

проверить счет;

составить протокол встречи;

подготовить статус проекта;

провести задачу разработки до запроса на внесение изменений;

подготовить закупщика к переговорам;

разобрать тендерную документацию.

Каждый skill должен знать:

кто владелец роли;

какие входы нужны;

где source of truth;

какие действия разрешены;

какие действия запрещены;

где нужна проверка человека;

что сохраняется после выполнения.

Так skills становятся не набором подсказок, а слоем поведения корпоративного ассистента.

MCP-шлюз

MCP можно понимать как способ подключать ассистента к инструментам и данным.

Но в корпоративной архитектуре важен не только сам протокол, а роль шлюза.

MCP-шлюз — это управляемая граница между агентами и корпоративными системами.

Через него ассистент может:

искать документы;

читать карточки задач;

получать данные из CRM;

работать с репозиторием;

получать шаблоны;

обращаться к календарю;

находить решения и протоколы;

писать в корпоративную память;

создавать черновики задач или документов;

запускать разрешенные проверки.

Но главное — не “может”.

Главное — “может только если разрешено”.

MCP-шлюз должен проверять:

кто пользователь;

каким агентом он работает;

какой skill вызван;

какой ресурс нужен;

какое действие запрошено;

есть ли право на чтение или запись;

нужно ли обезличивание;

нужно ли журналировать действие;

нужно ли требовать подтверждение человека.

Без такого слоя ассистенту приходится выдавать прямые токены к системам. Это плохая модель.

Прямые токены трудно контролировать, отзывать, ограничивать, проверять и безопасно хранить. Кроме того, агент начинает жить как отдельный технический пользователь, а не как помощник конкретного человека в конкретной роли.

В зрелой модели агент не владеет корпоративными секретами. Он обращается к инструментам через шлюз.

Права доступа

Права должны быть не общими, а контекстными.

Недостаточно сказать: “этому ассистенту можно читать CRM”.

Нужно понимать:

какой пользователь работает;

к какому клиенту он имеет доступ;

какую задачу решает;

какой skill используется;

какие поля нужны;

можно ли передавать эти данные в модель;

можно ли выполнять запись;

требуется ли подтверждение.

Например, менеджер может читать своих клиентов, но не

клиентов другого отдела. Руководитель может видеть сводку по направлению, но не все персональные детали. Ассистент может подготовить черновик задачи, но не менять статус без подтверждения. Инженерный агент может читать репозиторий проекта, но не менять секреты, права доступа или выполнять опасные операции без отдельного разрешения.

Права должны описывать не только “кто что видит”, но и “кто что может поручить ассистенту”.

Это новый слой безопасности.

Раньше компания выдавала права человеку в системе. Теперь нужно выдать права человеку, который действует через ассистента.

Память

Корпоративному ассистенту нужна память, но память нельзя путать с source of truth.

Source of truth — это место, где хранится официальная правда.

Память — это рабочий контекст, который помогает ассистенту не

начинать каждый раз с нуля.

Условно можно выделить три уровня.

Короткая память:

текущая задача;

текущая сессия;

загруженные документы;

уточнения пользователя;

временные решения.

Средняя память:

контекст проекта;

профиль клиента;

повторяющиеся предпочтения команды;

резюме прошлых встреч;

факты, полезные для работы роли.

Длинная память:

знания, подтвержденные источниками;

решения;

шаблоны;

регламенты;

архитектурные записи;

проверенные выводы.

Память должна быть source-backed, то есть опираться на источники. Иначе она сама превращается в источник устаревших догадок.

В архитектуре важно определить:

что можно запоминать;

на какой срок;

кто видит память;

как ее удалить;

как связать память с источниками;

какие данные нельзя сохранять;

как использовать память в следующей задаче.

Закрытый контур

Не каждая компания может отправлять данные во внешние сервисы.

Это особенно важно для отраслей с чувствительными данными: финансы, медицина, государственный сектор, промышленность, крупная торговля, юридические и договорные контуры, персональные данные, коммерческая тайна.

AI-Native архитектура может быть реализована в закрытом контуре.

Это означает:

модели работают внутри периметра компании или доверенного облака;

используются открытые модели или модели, доступные для локального развертывания;

данные не уходят во внешний сервис;

MCP-шлюз работает внутри контура;

права, аудит и обезличивание контролируются компанией;

журналы действий хранятся в собственной инфраструктуре.

Закрытый контур не является магическим решением.

Он требует инфраструктуры, экспертизы, обновления моделей, проверки качества, управления стоимостью и поддержки. Иногда внешний сервис дает лучшее качество и скорость. Иногда закрытый контур обязателен. Иногда нужна смешанная модель.

Главное — архитектура должна позволять выбирать режим по типу данных и задаче.

Наблюдаемость

Если ассистент становится частью работы компании, его действия

нужно наблюдать.

Наблюдаемость отвечает на вопросы:

кто вызвал ассистента;

какой skill использовался;

какие инструменты были вызваны;

какие источники читались;

какие данные были переданы модели;

какой результат получен;

где человек подтвердил решение;

где возникла ошибка;

сколько времени заняла задача;

сколько стоил вызов;

какие сценарии используются чаще всего.

Без наблюдаемости руководитель снова видит только поверхность: “люди пользуются ИИ”.

С наблюдаемостью можно понять:

какие skills реально работают;

где ассистент часто ошибается;

какие источники недоступны;

где не хватает прав;

где сотрудники обходят процесс;

какие сценарии дают эффект;

где есть риски безопасности.

Наблюдаемость нужна не для контроля ради контроля. Она нужна, чтобы улучшать систему.

Почему архитектура нужна CEO

CEO не должен проектировать каждую интеграцию.

Но он должен понимать принципы архитектуры, иначе не сможет отличить зрелую модель от опасной демонстрации.

Если команда показывает ассистента, руководитель должен спросить:

где source of truth;

какие skills используются;

через какой слой агент ходит в системы;

чьи права применяются;

что журналируется;

как защищаются чувствительные данные;

где человек подтверждает решение;

что остается в памяти;

можно ли запустить это в закрытом контуре;

как измеряется качество.

Эти вопросы не техническая придирка. Это управленческая гигиена.

AI-Native компания не может строиться на вере в красивый ответ модели.

Она строится на архитектуре доверия.

Что сделать руководителю

Попросите технического руководителя описать архитектуру корпоративного ассистента не в терминах технологий, а в терминах доверия.

Минимальная схема должна ответить:

Где сотрудник ставит задачу?
Какие ассистенты и агенты есть в контуре?
Где хранятся skills?
Как ассистент получает доступ к source of truth?
Есть ли MCP-шлюз или аналогичная управляемая граница?
Как проверяются права пользователя?
Какие данные обезличиваются?
Где хранится память?
Какие действия требуют подтверждения человека?
Что журналируется?
Какие сценарии можно запускать во внешнем сервисе, а какие

только в закрытом контуре?

Если на эти вопросы нет ответа, значит, компания пока не готова масштабировать ассистентов.

Она может проводить эксперименты, но ей рано говорить об операционном ядре.

Вопросы для руководителя

Есть ли у ваших ассистентов прямые ключи к корпоративным системам?

Можно ли понять, от чьего имени ассистент читает данные?

Есть ли единое место, где описаны доступные skills?

Как ассистент понимает, где source of truth?

Какие действия ассистент может сделать без человека?

Какие данные нельзя передавать во внешние модели?

Есть ли журнал действий ассистента?

Можно ли отозвать доступ быстро и централизованно?

Есть ли сценарии, которые требуют закрытого контура?

Главная мысль главы

Архитектура корпоративного ассистента — это архитектура доверия.

Ее задача не в том, чтобы “подключить модель ко всему”. Ее задача — дать человеку и ассистенту возможность работать с данными, инструментами и памятью так, чтобы компания сохраняла контроль.

Единый вход, слой агентов, skills, MCP-шлюз, права, source of truth, память, наблюдаемость и контроль человека — это не технические детали. Это основа AI-Native компании.