ЕМДЕВ

Разграничение идет на уровне прав доступа как и при работе обычного сотрудника с порталом. LLM в этой схеме выступает лишь как инструмент обработки текста, она не управляет правами доступа и не имеет прямого неограниченного доступа к системам.
Вот как именно это работает на практике, если сотрудник спрашивает: «Какая зарплата у Иванова?»:
1. Когда сотрудник задает вопрос, система Инкоманд точно знает его идентификатор (через корпоративную аутентификацию, SSO). Весь дальнейший процесс выполняется от имени этого конкретного пользователя, а не от имени некоего абстрактного «супер-админа ИИ».
2. Прежде чем какие-либо данные будут запрошены из 1С или других систем (в том числе через MCP), платформа Инкоманд обращается к матрице ролей и доступов. Система видит: «У пользователя Петрова нет прав на просмотр фонда оплаты труда или зарплат коллег».
3. Поскольку прав нет, платформа физически не извлекает эти данные из 1С. В контекст (промпт), который отправляется в языковую модель, эта информация просто не попадает. Нейросеть не может «случайно проговориться» о том, чего она не видела.
4. Получив запрос, но не получив разрешенных данных для его выполнения, ИИ-агент сгенерирует стандартный ответ в рамках своей инструкции: «У вас нет прав доступа к информации о заработной плате сотрудников. Для получения этих данных обратитесь в отдел кадров или к вашему руководителю».

Отсылка к модели ситуационной осведомленности (Situational Awareness) Endsley очень точна: наши уровни контекста действительно ложатся на её триаду «восприятие-осмысление-прогнозирование».
Вопрос о конфликте операционного (текущий статус) и процессного (ожидаемый маршрут) контекстов это, пожалуй, самый критичный момент при внедрении ИИ в реальный бизнес.
Мы видим решение этой задачи через механизмы обработки исключений (exception handling) и жесткую бизнес-логику:
1. Приоритет процессных правил. Процессный контекст задает жесткие рамки (BPM-схемы, регламенты). Если операционные данные (например, «бюджет проекта превышен на 20%» или «согласующий находится в длительном отпуске») выходят за рамки стандартного маршрута, ИИ-агенту программно запрещено самостоятельно «придумывать» обходные пути.
2. Флагирование аномалий и эскалация. Сверяя операционный статус с процессными правилами, агент фиксирует рассинхрон. Вместо автоматического выполнения действия он генерирует алерт для человека или переводит задачу в специальную ветку процесса «Обработка исключений» (например, требует внеочередного согласования у руководителя направления или комплаенс-офицера).
3. Механизм обратной связи. Решение, которое принимает человек в такой нестандартной ситуации, фиксируется в карточке процесса. Это создает петлю обратной связи: операционный опыт не ломает систему, а документируется. В дальнейшем администраторы системы могут использовать эти данные для актуализации самих бизнес-процессов или настройки новых правил для ИИ.
Итого: ИИ-агент в Инкоманд выступает как аналитик, который подсвечивает конфликт между «как должно быть» и «как есть», и предлагает сотруднику стандартные, заранее настроенные процедуры выхода из такой ситуации.

Будем рады продолжить дискуссию! Если тема зайдет, мы готовы подготовить отдельный разбор архитектуры обработки исключений и способов настройки «предохранителей» для ИИ.

Для Энтакси это как раз привычная задача интеграционной шины: единая точка управления взаимодействием систем, маршрутизацией, доступами и контролем интеграций. MCP-сервисы просто становятся новым участником этой экосистемы. А значит Энтакси вполне может стать тем самым «диспетчером», который не даст MCP-своре превратиться в интеграционный зоопарк

В корпоративной архитектуре MCP сам по себе решает задачу стандартизации взаимодействия AI-систем с инструментами, но не закрывает весь контур эксплуатации: управление доступом, маршрутизацию, безопасность, обработку ошибок, мониторинг и взаимодействие с существующими корпоративными системами.

Здесь и появляется роль Энтакси как интеграционного слоя между AI-агентами и корпоративным ИТ-ландшафтом. Мы переносим значительную часть этой инфраструктурной логики на уровень интеграционной платформы, чтобы MCP-сервисы можно было подключать, маршрутизировать и контролировать в единой архитектуре.

В итоге MCP становится не отдельным экспериментальным компонентом, а частью управляемого корпоративного интеграционного контура.

Согласны. И здесь как раз появляется задача, которую мы в Энтакси уже решаем - по мере роста числа MCP-сервисов важно автоматизировать не только их подключение, но и управление всей экосистемой, т.е. маршрутизацию, доступы, взаимодействие и контроль. Чем больше сервисов подключается, тем важнее единая точка управления ими.

В целом согласны: инвентаризация действительно часто заметно уменьшает объём активной миграции и делает смету реалистичнее.
Но важно не превратить критерий популярности в критерий ценности. Документ, который не открывали три года, не обязательно бесполезен. Это может быть договор, кадровый документ, проектная история, материал для аудита, финансовая первичка или юридически значимое доказательство. Такие данные могут редко использоваться в ежедневной работе, но должны сохраняться в соответствии с внутренними регламентами, требованиями ИБ и сроками хранения.
Поэтому корректнее разделять контент не только по частоте обращений, а по назначению:
- активные документы и рабочие реестры — в новый портал в первую очередь;
- редко используемые, но обязательные для хранения материалы — в управляемый архив;
- дубли, черновики и неактуальные данные — на удаление только после согласования с владельцами и ответственными подразделениями.
Так и удешевим миграцию, и сохраним важную корпоративную историю.

Добрый день! Спасибо за отличный и очень правильный технический вопрос. Вы абсолютно правы: маппинг ACL, сохранение версионности и разрешение коллизий при двусторонней синхронизации — это «сердце» любого сложного миграционного проекта, и именно на этом этапе обычно сыпется большинство самописных или коробочных решений.

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

Конфликты версий при одновременном редактировании решаются не «магией», а строгим алгоритмом на основе нативных API изменений (Change Tokens в SharePoint и аналогов в Инкоманд). Система отслеживает метаданные, временные метки и очередность транзакций, предотвращая случайную перезапись данных и формируя понятные логи коллизий для администратора. Маппинг прав доступа и версионность также зашиты в базовую логику модуля и обрабатываются автоматически.

Детальный разбор того, как именно работает наш движок синхронизации, как мы обрабатываем исключения и разрешаем конфликты версий, мы публиковали в отдельных статьях тут https://incomand.ru/ru/b/sharepoint_incomand_sync и тут https://habr.com/ru/articles/1028932/

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

Напишите нам в личные сообщения или оставьте контакты — с радостью согласуем удобное время для звонка и демо!

Спасибо за важное уточнение. Согласны - выбор между gateway, брокером и ESB стоит начинать с бизнес-инвариантов, владельца сущности и границ процесса.
Да, в примере с оплатой «событие доставлено» не равно «заказ исполнен». Брокер гарантирует передачу сообщения, но не завершение бизнес-операции. Владельцем итогового статуса должна быть система, которой принадлежит жизненный цикл сущности, например OMS или ERP для заказа. Она определяет допустимые статусы: «оплачен», «ожидает исполнения», «выполнен», «требует обработки».
Оркестратор не подменяет владельца. Его роль управлять межсистемными шагами - отправить данные в CRM и склад, собрать подтверждения, контролировать тайм-ауты, запускать повторные попытки и при необходимости компенсационные действия.
Если CRM обновилась, а склад недоступен, оркестратор фиксирует незавершенный шаг и пытается восстановить обмен. Владелец заказа при этом сохраняет корректный бизнес-статус, например ожидает подтверждения склада.

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

Фраза «Интранет — это слепок корпоративной культуры» бьет в самую точку, её можно смело брать как эпиграф к любой статье о внутренних коммуникациях.
Действительно, никакие технические настройки и умные алгоритмы не заменят здоровую культуру общения и базовое уважение к времени коллег. Если в компании принято считать, что «важно всё и для всех», то даже самый совершенный портал превратится в шумную ленту.
Но мы смотрим на сегментацию немного иначе: не как на «таблетку», которая маскирует проблему, а как на мягкий инструмент, который помогает эту самую культуру выстраивать. Когда система при публикации новости ненавязчиво подсказывает: «Этот материал актуален в первую очередь для отдела логистики», она помогает авторам контента (включая руководителей) принимать более осознанные решения об аудитории.
Технологии не меняют ДНК компании в одночасье, но они создают для здоровых привычек удобные «рельсы». А когда сотрудники начинают замечать, что им приходит только то, что действительно важно для их ежедневной работы, общее чувство уважения к их времени в компании начинает расти автоматически.

Спасибо за вопрос.
Если коротко: витрина, сделанная левой ногой, — это просто цифровые закладки. Единая точка доступа (Single Entry Point) — это управляемый процесс.

Давайте разберем по пунктам, где заканчивается «витрина» и начинается нормальный продукт:

1. Ссылка vs. Действие
Витрина левой ноги: Это страница с 30 красивыми иконками. Вы нажимаете «Заказать пропуск», вас перекидывает на внешний сайт службы безопасности, там слетает сессия, вы вводите пароль, а форма все равно просит указать ваш табельный номер, который система и так должна знать.
Единая точка доступа: Действие происходит здесь и сейчас. Вы нажимаете кнопку, открывается контекстная форма, где ваше имя, отдел и табельный номер уже подставлены. Портал сам через API отдает эти данные в нужную бэкенд-систему. Для пользователя это один бесшовный сценарий, а не прыжки по вкладкам.
2. Информационная черная дыра vs. Сквозной трекинг
Витрина левой ноги: Вы отправили заявку и начинаете гадать: «Она ушла? Ее увидели? Или она упала в /dev/null?». Чтобы узнать статус, нужно писать в чат, звонить или идти ногами к админу Лене.
Единая точка доступа: Работает как трекинг в доставке еды. У заявки есть жизненный цикл и прозрачные статусы: «Создана» → «На согласовании у руководителя» → «В работе у АХО» → «Выполнено». Пользователь видит ответственного и сроки, а поддержка получает один управляемый контур, а не разрозненные письма и стикеры.
3. «Всем всё» vs. Контекстная персонализация
Витрина левой ноги: Одинакова для стажера, гендиректора и главбуха. В результате стажер тонет в ненужных ему кнопках «Согласовать бюджет», а директор не может найти «Заказать канцелярию» среди 50 других ссылок.
Единая точка доступа: Использует сегментацию и ролевую модель. Новичку при входе показывают чек-лист онбординга и базовые HR-сервисы. Руководителю — виджет входящих согласований. Портал адаптируется под пользователя, а не заставляет пользователя адаптироваться под структуру портала.
4. Архитектура: картинка vs. Данные
Витрина левой ноги: Это просто фронтенд-оболочка. Она ничего не знает о бизнес-логике. Если процесс меняется, нужно звать разработчика, чтобы он переверстал страницу или поменял URL ссылки.
Единая точка доступа: Строится на единой модели данных (объекты «Сервис» и «Заявка», связанные между собой). Изменить форму, добавить новый этап согласования или скрыть сервис для определенного филиала может бизнес-аналитик или HR-администратор через no-code/low-code конструктор за 15 минут. Без ТЗ, спринтов и очереди в IT-отдел.