Финальная битва за календари. Первая битва за контекст для ИИ

В индустрии цифровых рабочих мест прямо сейчас дозревает фундаментальный сдвиг. Речь идет обо всем корпоративном ИТ‑ландшафте: от привычных текстовых редакторов и мессенджеров до глубокой инфраструктуры — каталогов учетных записей (AD) и систем управления устройствами (UEM). Изменения идут на всех уровнях стека. Сдвиги такого масштаба происходят раз в 20 лет. Они определяют пользовательский опыт, бизнес‑модели и ландшафт участников на следующие два десятилетия. Именно в такие периоды создаются новые большие истории и рушатся старые бизнес‑империи, казавшиеся незыблемыми.

Это вторая статья из цикла. Напомню ключевые темы предыдущей статьи «Корпоративные мессенджеры и воркспейс-комбайны. Разбираем вендорский капкан»:

• Почему до сих пор нельзя написать из мессенджера «А» в мессенджер «Б».

• Как математика сетевых эффектов гарантирует проигрыш закрытых платформ «теневому Телеграму».

• Почему отечественные on‑prem All‑in‑One комбайны разрушают ИТ‑инфраструктуру клиентов, а локальные закрытые экосистемы ведут вендоров к финансовому тупику.

• Почему будущее за открытостью и как децентрализованные протоколы, антимонопольные законы ЕС и инициативы IETF меняют правила игры.

В этой части нашего техно-триллера решил поговорить про календари, почту и адресные книги. Здесь, как и в мессенджерах, прямо сейчас активно разбивают Vendor Lock-in через стандартизацию открытых протоколов и антимономопольные суды. И одновременно, на наших глазах формируется новый узел вендор-лока, и стартует новая борьба, теперь за контекст для корпоративного ИИ. В 2026 году Big Tech начинает продавать бизнесу уже не просто почту и календари, а социальный и когнитивный граф, который мгновенно испаряется при любой попытке миграции. Сможет ли связка открытых протоколов JMAP + Matrix (MSC4496) обеспечить бизнесу владение собственным семантическим контекстом?

Содержание:

1. Две эпохи доминирования протоколов Microsoft

2. JMAP. Новая надежда

3. Власть над пушами

4. Microsoft 365 завершает переход на Modern Collaboration Architecture

5. Ответ Google на Modern Collaboration Architecture от Microsoft

6. Контекст для ИИ. Новый узел гравитации Google Workspace и Microsoft 365

7. JMAP + Matrix. Требует реализации

8. Matrix + JMAP. Будущий открытый “движок” цифрового двойника предприятия?

9. Саммари встреч — это автоматизация стенографии. ИИ способен на большее

10. Почему российские вендоры воркспейс-комбайнов не смогут собрать аналог Microsoft Graph

Начну по традиции с истории вопроса.

Две эпохи доминирования протоколов Microsoft

В конце 90-х электронная почта уже умела ходить между разными компаниями по открытому протоколу SMTP. Но еще есть календари, задачи, совещания. Антигероем опять выступила Microsoft. Она продолжала кропотливо обустраивать свой «огороженный сад» и всю логику совместных календарей, приглашений на встречи и планирования расписания «зашила» внутрь своего проприетарного протокола MAPI/RPC. Только один Microsoft Outlook “умел понимать” MAPI.

Если ваша компания «сидела» на Microsoft Exchange, вы могли внутри Outlook в два клика собрать совещание на несколько человек, проверить, свободны ли их календари. Но как только вы пытались отправить приглашение на встречу партнеру или клиенту, у которого стоял Mac, Linux или другая почтовая система (например, Lotus Notes), партнер получал вместо красивой кнопки «Принять встречу» странное вложение — файл winmail.dat. Этот файл невозможно было открыть ничем, кроме Outlook. Вся информация о времени встречи, повестке и переговорке выглядела как мусор. Интегрировать корпоративные календари двух разных компаний было невозможно.

Первой попыткой стандартизации и создания единого формата данных стал текстовый формат vCalendar (.vcs), созданный в 1996 году консорциумом Versit (Apple, IBM, AT&T и Siemens). Уже в 1998 году Инженерный совет Интернета (IETF) доработал этот формат и официально выпустил iCalendar (.ics) под кодом RFC 2445. В разработке спецификации ключевую роль играли представители конкурирующих Lotus (IBM) и (обратите внимание) Microsoft. Актуальный стандарт RFC 5545, с исправлениями старых ошибок, вышел в 2009 году. 

Появление.ics решило проблему хранения и передачи одиночных файлов, но не автоматической синхронизации, и в 2007 году Консорциум IETF опубликовал спецификацию CalDAV (RFC 4791). По сути, CalDAV стал «заточенной» под работу с календарными объектами надстройкой над WebDAV (уже существовавшего тогда расширения HTTP для управления файлами на серверах).

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

Microsoft уступила, сделав.ics стандартным форматом для импорта/экспорта в 2000–2003 годах (начиная с Outlook 2000/2002 и полноценно в Outlook 2003) и даже сама участвовала в разработке iCalendar в 1998 году, чтобы стандарт не утвердили без учета ее интересов. Хотя, удержаться не могли, долгое время реализовывали его с мелкими нарушениями спецификации, из‑за чего календари из других программ часто отображались в Outlook с «битой» кодировкой или съехавшим временем.

А вот протокол синхронизации CalDAV Microsoft официально не приняла до сих пор (для своих главных продуктов) и годами ведет политику «тихого саботажа». Вместо него Microsoft заставила весь мир лицензировать свой собственный протокол EAS (Exchange ActiveSync). Даже Google и Apple начали платить Microsoft роялти, чтобы их смартфоны могли синхронизировать почту и календари с корпоративными серверами Exchange.

Проприетарный EAS выиграл благодаря своей комплексности и готовности к мобильной эре. ActiveSync через одно подключение синхронизирует сразу всё: почту, календарь, контакты, задачи, заметки и даже SMS.

Администратору достаточно выдать сотруднику один логин и пароль. CalDAV же, сам по себе, умеет синхронизировать только календари. Чтобы собрать аналог Exchange, компании приходилось настраивать IMAP (для почты), CalDAV (для календаря) и CardDAV (для контактов). Это три разных протокола, три разных соединения и постоянные проблемы с совместимостью.

Свою роль сыграла и узость функциональных сценариев, реализуемых через CalDAV. EAS позволяет при создании встречи сразу видеть список свободных переговорок (ресурсов) в компании и их оборудование (например, наличие проектора). CalDAV этого не умел. Чтобы пригласить коллег на совещание в Exchange, Outlook сразу показывает сетку времени, где видно, кто и когда занят. В чистом CalDAV для этого приходилось городить отдельные костыли. В Exchange начальник может делегировать права, в один клик разрешить секретарю полностью вести его календарь, отвечать на приглашения и скрывать личные встречи. В CalDAV механизмы делегирования долгое время отсутствовали или работали некорректно.

Смартфоны и бум корпоративной мобильности еще больше увеличили разрыв. ActiveSync изначально создавался для мобильных сетей с низкой скоростью. Он использовал технологию Direct Push. Сервер сам мгновенно «толкал» новые данные на телефон. Смартфон не тратил заряд батареи на постоянные проверки. CalDAV на заре мобильного интернета работал по принципу Polling, телефон каждые 15–30 минут просыпался, подключался к серверу и спрашивал: «есть что‑то новое?». Это разряжало батарею смартфона и не давало мгновенных уведомлений. И на закуску, ActiveSync содержит в себе базовые функции MDM (Mobile Device Management), это тоже на определенном этапе сыграло в плюс.

В конечном итоге Microsoft начала получать роялти с каждого проданного смартфона конкурентов, а EAS де‑факто стал главным мировым стандартом корпоративной мобильной связи, окончательно похоронив шансы CalDAV выйти за пределы нишевого использования.

Apple уступила первой: когда в 2007 году вышел первый iPhone, Стив Джобс понял, что без поддержки корпоративной почты крупный бизнес iPhone не купит. Apple официально купила лицензию на ActiveSync у Microsoft. Android пошел по тому же пути: Google также лицензировал EAS для стандартного почтового клиента Android.

JMAP. Новая надежда

Самая свежая и технологически сильная попытка заменить не только CalDAV/IMAP, но и решения Microsoft — это открытый протокол JMAP (JSON Meta Application Protocol), созданный в рамках IETF комитетом, куда входят крупнейшие независимые почтовые провайдеры (например, Fastmail).

Независимые платформы (включая Nextcloud в её свежих обновлениях) начали нативно внедрять поддержку JMAP, он уже стал базой в Mozilla Thunderbird, почтовых серверах Cyrus IMAP и Stalwart. На него активно переходят независимые европейские и американские сервисы, уставшие от монополии Microsoft.

MAP не требует покупки лицензий и работает в разы быстрее протоколов Microsoft. Он сразу создавался как единый, современный и быстрый протокол мобильной эры на замену старых, «разрозненных» протоколов (IMAP, SMTP, CardDAV, CalDAV) одним понятным API на базе JSON, через один порт HTTP и единый тип авторизации.

Сам базовый протокол JMAP Core (RFC 8620) был утвержден и опубликован еще в августе 2019 года. Почтовый стандарт JMAP for Mail (RFC 8621) сразу за ним, тоже в августе 2019 года. Но дальнейшее превращение JMAP в полноценную альтернативу ActiveSync (с контактами и календарями) через расширения базового стандарта потребовало времени и завершается только сейчас. 

Современным преемником старого формата iCalendar (RFC 5545) призван стать RFC 8984 (JSCalendar), который был официально принят и опубликован в июле 2021 года. Он описывает новую семантическую структуру данных для календарей, задач и событий в формате JSON.

Рабочая группа IETF CALEXT прямо сейчас финализирует стандарт JSCalendar 2.0. Его цель — вырвать из рук Microsoft Exchange монополию на «умные функции»: делегирование прав секретарям, консенсусное бронирование и автоматический корпоративный скоупинг.

В JSCalendar 2.0 синхронизируются правила валидации и реестры IANA со спецификацией контактов RFC 9982 (JSContact 2.0) и вводятся функции "умного календаря": в draft-ietf-calext-jscalendarbis-18 от 31 июля 2026 года вошла нативная поддержка Smart Calendars и Task Extensions.

Появились встроенные JSON‑профили для делегирования прав (Delegation) и консенсусного планирования (Consensus Scheduling). Помимо этого, вводится понятие автоматического скоупинга событий (Global/Department Scope): «если отдел ИБ ставит событие „Аудит“, в календарях всех разработчиков эти 10 дней автоматически затеняются для релизов».

Старый формат iCalendar (.ics) не знал, что такое «корпоративная иерархия». Из‑за этого только Microsoft Exchange умел разруливать конфликты, когда начальник делегировал секретарю право вести его календарь, скрывая личные встречи и открывая рабочие. В CalDAV/ics это превращалось в кашу. JSCalendar 2.0 делает эту логику открытой.

JMAP обеспечивает бесшовную интеграцию с таск‑менеджерами или CRM и позволяет создавать автоматические цепочки через n8n или Make для разнообразных новых сценариев. Раньше, для сценариев вида «когда в CRM создается сделка → JMAP автоматически бронирует время в календаре менеджера, создает карточку контакта и отправляет приветственное письмо» требовалось писать сложные интеграции под вендорский API Microsoft или мучиться с «костылями» для CalDAV/CardDAV. Кроме того, JMAP позволяет поделиться прямо из мобильного интерфейса не всем календарем, а одной конкретной категорией событий (например, «Встречи по проекту Х») с определенным уровнем прав: только просмотр, редактирование или делегирование.

Спецификация JMAP for Calendars (описывает сетевые методы вроде CalendarEvent/get, CalendarEvent/set и CalendarEvent/changes) находится на финальной стадии утверждения в IETF, она уже прошла основное рецензирование и находится в состоянии «Submitted to IESG for Publication» (передана руководству IETF на публикацию).

Спецификация активно дорабатывается. Номер RFC ей присвоят сразу после того, как редакторы закроют последние технические шероховатости и согласуют финальный текст. Несмотря на статус черновика (Draft), протокол уже стабилен и применяется на практике, крупные провайдеры (например, Fastmail) и почтовые серверы (например, Cyrus IMAP) уже полностью внедрили поддержку JMAP for Calendars в коммерческую эксплуатацию. В коде (на клиенте и сервере) поддержка этого протокола заявляется через официальный URI возможностей JMAP (JMAP Capabilities): urn:ietf:params:jmap:calendars.

В декабре 2024 года Инженерный совет Интернета (IETF) официально опубликовал стандарт RFC 9610 (JMAP для контактов), который спецификацию формата данных RFC 9553 дополняет моделью синхронизации адресных книг и контактов между устройствами и сервером с помощью протокола JMAP.

JMAP for Contacts имеет фундаментальное значение для экосистемы Интернета. Это первый за долгие годы полноценный прорыв в области синхронизации персональных данных. Он кардинально меняет работу с адресными книгами на мобильных устройствах и в веб‑приложениях, заменяя устаревший, медленный и избыточный по трафику протокол CardDAV.

RFC 9610 (JMAP for Contacts) превратил JMAP в полноценную, единую и открытую альтернативу проприетарным корпоративным протоколам (вроде Microsoft Exchange ActiveSync). Теперь почта (RFC 8621), контакты (RFC 9610) и календари (находящиеся на финальной стадии) работают в рамках единой, быстрой архитектуры.

В мае 2026 года статус официального стандарта (Proposed Standard) Инженерного совета Интернета (IETF) получил документ RFC 9982 (JSContact 2.0).

Он решает проблему совместимости со старыми адресными книгами vCard. JSContact 2.0 обновляет вспомогательный для JSContact (RFC 9553) стандарт конвертации vCard в JSContact (RFC 9555) и делает поле uid необязательным. Ранее, обязательность поля uid порождала проблемы при переносе данных из старого формата vCard (где этот параметр опционален): разработчикам приходилось генерировать случайные идентификаторы «на лету», синхронизация ломалась.

И наконец, JMAP File Storage (также известный как расширение JMAP for FileNode), который находится на финальном этапе стандартизации в IETF и готовится стать официальным RFC (Proposed Standard). Из последнего, в 14-й ревизии драфта (выпущена мае 2026 года) получила обновление синхронизация файлов для адресных книг (например, тяжелых фото контактов). Это позволило оптимизировать хранение медиаданных, привязанных к RFC 9610.

JMAP File Storage — финальный кусочек пазла. Он призван полностью заменить устаревший протокол WebDAV (как в Nextcloud) для удаленного управления файлами и сетевыми дисками, и превратить облачное хранилище файлов в стандартный, быстрый и предсказуемый JSON‑API.

Разработчики JMAP‑решений уже закладывают поддержку JMAP File Storage, например, Stalwart Labs стал одним из первых, кто полноценно развернул у себя стек JMAP для календарей, контактов и облачного хранения файлов, создавая прямую альтернативу экосистемам Microsoft Exchange и Google Workspace. Кстати, их утилита для миграции данных Vandelay (выпущенная в 2026 году) уже умеет бесшовно конвертировать файловые коллекции из WebDAV прямо в структуру JMAP FileNode и обратно.

В JMAP синхронизация идет через чистый, легковесный JSON. Он нативно поддерживается всеми современными браузерами и языками программирования, а парсинг пар «ключ‑значение» происходит мгновенно и с минимальными затратами процессора. Работать с JSON‑моделями через стандартный REST‑подобный API гораздо проще, чем разбирать специфические старые форматы (MIME‑письма, vCard, iCalendar) и кастомные команды IMAP. Любой веб‑ или мобильный разработчик умеет работать с JSON и стандартными HTTP‑методами. Внедрение синхронизации контактов в новые приложения теперь занимает дни вместо месяцев.

За счет минимизации сетевых запросов и дельта‑синхронизации JMAP‑приложения на смартфонах экономят мобильный трафик и заряд батареи.

Пакетные операции в JMAP (Request Batching) позволяют клиенту в одном HTTP‑запросе одновременно сказать серверу: «отправь это письмо, обнови этот контакт и удали другой из адресной книги, а еще создай событие в календаре». JMAP File Storage дополнительно расширяет до возможности «переименуй Папку А, перемести Файл Б в Папку В и удали Файл Г». Все это сервер выполнит это за один раз. Никаких больше «зависших» или полусозданных встреч. Если одно из действий завершится ошибкой (например, введен несуществующий email), сервер отменит всю транзакцию целиком.

При этом, в JMAP реализованы дельта‑обновления (умное отслеживание изменений): клиент запрашивает у сервера только то, что изменилось с момента последней синхронизации. Больше не нужно перекачивать всю телефонную книгу целиком ради изменения одной буквы в фамилии.

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

Авторизация унифицирована, клиентскому приложению достаточно один раз авторизоваться на сервере по JMAP и приложение сразу получает доступ и к вашей почте, и к контактам, и к вашему облачному диску — не нужно открывать новые сессии. Система квот и прав тоже общая: облачные файлы используют ту же систему лимитов дискового пространства и те же механизмы разграничения прав доступа (JMAP Sharing), что и ваши почтовые ящики.

Власть над пушами

Apple и Google мягко саботируют JMAP, но по разному. Для них JMAP в качестве дефолтного протокола в iOS и Android — это добровольная потеря монетизации и контроля.

У Google давно есть проприетарный Gmail API на базе того же HTTP и JSON. Он успешно закрывает абсолютно все аспекты мобильности (Push, пакетные запросы, скорость) и де‑факто является тем самым JMAP, но принадлежит Google. Если вы пишете почтовый клиент или CRM‑систему с интеграцией Gmail, вам проще использовать готовый Gmail API. Но если вы захотите уйти от Google, вам придется полностью переписывать весь код интеграции с нуля. Для внешнего мира Google держит старый добрый IMAP/SMTP, который они кастомизировали костылями под свои «ярлыки» (labels). 

Apple сильнее зависит от индустриальных стандартов, потому что не имеет такого‑же мощного и популярного закрытого API для iCloud, как Google для Gmail. Поэтому ведет вязкие кулуарные игры и держит руку на пульсе: участвует в обсуждениях и финализации спецификаций JMAP, JSContact и JSCalendar в рамках комитетов IETF, чтобы стандарты не ущемили её экосистему.

На Hacker News и форумах регулярно всплывают слухи о том, что Apple тестирует перевод бэкенда почты и календарей iCloud на рельсы JMAP. Вполне может быть: CalDAV и IMAP в iOS/macOS Mail работают натужно, жрут батарею, а Apple помешана на энергоэффективности своих процессоров. Уже начали появляться независимые почтовые клиенты (iOS, macOS), написанные на чистом Swift (например, Swift Mail или Plume), которые работают исключительно по JMAP и используют нативные системные Webhooks для мгновенных Push‑уведомлений. Apple внимательно наблюдает за этими экспериментами.

Для Apple или Google полноценно поддержать JMAP означает дать возможность сторонним мобильным приложениям независимо доставлять push‑уведомления на мобильные устройства. Отказаться от роли «главного посредника», контролирующего все экосистему пользовательских приложений на смартфонах планеты. Отказаться от всех связанных с этим возможностей и монетизации.

Спецификация JMAP предлагает два отличных механизма уведомлений: Server‑Sent Events (SSE) c постоянным HTTP‑соединением клиента и вебхуки (Push Subscriptions), в которых почтовый сервер шлет JSON‑запрос на URL, указанный клиентом. На веб‑интерфейсах или десктопах это работает идеально, уведомления доставляются мгновенно и практически не расходуют батарею.

Но на iOS и Android с 13–14 версий, как только приложение уходит в бэкграунд, ОС жестко «усыпляет» процесс ради экономии батареи и оперативной памяти. Постоянное SSE‑соединение iOS принудительно разорвет через несколько минут. А для вебхуков серверу JMAP просто некому слать запрос: приложение «спит», у него нет постоянного IP‑адреса, оно не может выступать в роли веб‑сервера. Без промежуточного шлюза, который «разбудит» телефон, push‑уведомления JMAP в бэкграунде на смартфонах невозможны.

Сегодня на основе JMAP нельзя построить без критической зависимости от Google и Apple контур календарей и почты (если только вы хотите, чтобы все работало и на мобильных, а вы хотите).

Чтобы push‑уведомления доходили, JMAP‑клиенты (например, Fastmail или Stalwart), да через прокси‑сервер (Push Gateway), но все равно вынуждены использовать инфраструктуру Apple (APNs) и Google (FCM). И это проблема.

Вы разворачиваете собственный self‑hosted сервер JMAP (например, Stalwart или Apache James), вы не можете напрямую достучаться до APNs Apple. По правилам безопасности Apple, слать пуши в конкретное приложение может только владелец аккаунта разработчика этого приложения, у которого есть приватный криптографический ключ. Вы можете собирать собственное мобильное приложение под своим аккаунтом разработчика, либо доверяться стороннему push‑шлюзу автора приложения, зависимость от глобального вендора сохранится, реальной суверенности вашей инфраструктуры вы не получите.

Будем надеяться, что ЕС, W3C (Консорциум Всемирной паутины) и IETF совместными усилиями, среди прочего, «дожмут» Google и Apple и по вопросу пушей.

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

Статья 6(7) Закона о цифровых рынках (DMA) ЕС прямо обязывает гейткиперов обеспечить бесплатную и эффективную интероперабельность с аппаратными и программными функциями ОС. Под давлением Еврокомиссии Apple в обновлениях iOS (в частности, в рамках спецификационных процедур DMA 2025–2026 годов) уже открыла так называемый Notification Forwarding и новые API для взаимодействия с альтернативными устройствами и подсистемами. Но ожидаемо сделала это полностью в духе «итальянской забастовки», фактически продолжая саботаж, прикрываясь заботой о безопасности и энергоэффективности.

В CalConnect (The Calendaring and Scheduling Consortium) W3C и IETF имеют статус официальных партнеров. Пока IETF пилит сетевой JMAP, W3C в рамках рабочих групп по веб‑приложениям (WebApps) следит за тем, чтобы новые JSON‑модели (JSCalendar) понимались нативными браузерными движками без сторонних библиотек.

IETF и W3C, cовместно, прописывают сейчас стандарты Declarative Web Push. В одной из следующих статей отдельно посмотрим на кулуарные игры в W3C: как стандарты W3C Push API и Declarative Push пытаются лишить Apple и Google их главного аргумента про «спасение батарейки». Как это пересекается с инициативой MIMI (More Instant Messaging Interoperability). UnifiedPush тоже не забудем (это единственный на сегодня живой open‑source архитектурный ответ вендорским APNs и FCM, который уже нативно встраивается в Matrix‑клиенты).

Microsoft 365 завершает переход на Modern Collaboration Architecture

С августа 2026 года Microsoft принудительно переводит межкорпоративный обмен календарями (Cross‑Tenant Calendar Sharing) со старых правил Exchange на новые жесткие политики безопасности Cross‑Tenant Access Policies (CTAP).

С октября 2026 начинается полное отключение протокола EWS (Exchange Web Services).
Старые версии мобильного Teams и Outlook полностью теряют функцию календаря, если пользователи их не обновили. Любые старые скрипты и сторонние календари, которые не умеют работать в рамках подотчетности данных Microsoft Graph, окончательно перестанут функционировать.

К концу 2026 Microsoft прекратит поддержку прямой аутентификации по сертификатам (Certificate‑Based Authentication) для клиентов ActiveSync. Уже начала официально блокировать доступ к Exchange для любых мобильных устройств, использующих версии протокола ActiveSync ниже 16.1. и отключает старые версии и методы авторизации Exchange ActiveSync (EAS) для мобильных устройств и EWS (Exchange Web Services) для ПК. 

Microsoft переводит на Microsoft Graph всю экосистему Microsoft 365 (календари, чаты, файлы и так далее) и завершает переход на Modern Collaboration Architecture, полностью отказываясь от наследия 2000-х годов (RPC, MAPI и Exchange Web Services).

Это финал многолетнего плана Microsoft по уничтожению старой модели обмена данными Exchange Web Services, миграции на REST API в Exchange Online и принудительному переводу всех корпоративных расписаний на новые рельсы. Теперь каждый календарь или канал Teams обязан быть верифицирован, привязан к живому аккаунту и автоматически уничтожен или заархивирован, если он больше не администрируется.

Изначально, под капотом, сервисы Office 365 (почта, файлы, структура компании) были изолированными и разрозненными. Чтобы связать их, в 2014–2015 гг. на базе технологии сигналов Delve был создан Office Graph, как скрытый «интеллектуальный движок» внутри Office 365. Его главной задачей был сбор сигналов активности пользователей (кто с кем переписывается, какие документы чаще открывает). Обычные разработчики не могли использовать его как полноценный API для управления системой. Уже к ноябрю 2015 года Microsoft поняла, что граф связей прекрасно подходит для объединения всех её облачных продуктов и выпустила Office 365 Unified API, который практически сразу переименовала в Microsoft Graph — “the unified API for modern work”. 

Microsoft Graph поглотил не только аналитику Office Graph, но и старые изолированные интерфейсы: Azure AD Graph API (управление пользователями) и отдельные Office 365 APIs (почта, календарь, файлы). Граф перестал быть только «офисным». В него добавили управление устройствами (Intune), безопасность, Windows‑уведомления и службы удостоверений Microsoft Entra ID.

Сами исходные данные (письма, файлы, пользователи) по‑прежнему лежат в своих «родных», часто реляционных или документных базах (Exchange, SharePoint). Однако связи между ними (кто с кем чаще переписывается, какие файлы вы открывали перед этой встречей, в какой команде состоите) обсчитываются и хранятся в графовых структурах. Для этого Microsoft использует собственные распределенные графовые индексы и движки хранения внутри Azure, сшивающие данные через инфраструктуру Microsoft 365 Substrate и мультимодальную базу данных Azure Cosmos DB (Graph/Gremlin API), оптимизированную под миллиарды быстрых связей.

В 2021 году Microsoft начал переводить всё облако на REST‑API в рамках масштабного обновления «Shared Calendars Update». Это позволило Microsoft связать календари с глобальной аналитикой доступов Microsoft Graph. В 2023 начал атаку на «бесхозные» групповые календари и общие расписания уволившихся людей, и в мае 2025 года, c глобальным обновлением Ownerless Microsoft 365 Group Notifications активные члены групп начали получать письма с предложением занять пустующее кресло владельцев.

В июле 2026 года наступил жесткий дедлайн для администраторов по исправлению «бесхозных» приватных каналов в Microsoft Teams. Каналы, которые остались без назначенных модераторов после миграции структуры, попали под риск автоматической очистки.

В январе 2025 года Microsoft объявил, что бесплатное вечное хранение данных бывших сотрудников прекращается, а с июля 2026 года нелицензированные аккаунты OneDrive могут храниться на серверах бесплатно максимум 365 дней. Если компания в течение года не перевела такой аккаунт на платное архивное хранение и не вернула лицензию, Microsoft принудительно удаляет данные, игнорируя даже внутренние корпоративные политики удержания (eDiscovery/Retention).

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

Вместо того чтобы мгновенно стирать контент уволенного сотрудника, инфраструктура Microsoft пытается его «пристроить» и сохранить: когда администратор удаляет сотрудника из Entra ID (Azure AD), система не уничтожает его OneDrive, а ищет нового владельца (Manager Roll‑over). Microsoft 365 смотрит в организационную структуру компании, находит руководителя (Line Manager) уволенного сотрудника и автоматически отправляет ему письмо со ссылкой на все файлы бывшего подчиненного, предоставляя доступ на 30 дней (срок настраивается).

Ответ Google на Modern Collaboration Architecture от Microsoft

Google старается не отставать от Microsoft и тоже переходит к жесткому управлению жизненным циклом данных (Data Lifecycle Management). Тема касается Google Workspace в целом, не только календарей (и всего Microsoft 365).

C октября 2026 (изначально, собирался с апреля) Google вводит новые правила жизненного цикла данных для Google Workspace в рамках концепции Single Data Owner, которая была представлена в конце 2025 года.

Теперь любой вторичный календарь Google Workspace (будь то расписание переговорки или календарь проекта) намертво привязан к жизненному циклу его создателя (поле dataOwner в API). Если сотрудник увольняется и админ удаляет его аккаунт, все привязанные к нему календари проектов, бронирования переговорок и расписания отделов безвозвратно удаляются автоматически. 

У Google нет аналогичного Microsoft Graph API единого универсального шлюза, который объединял бы все сервисы Google Workspace под одним эндпоинтом. Вместо этого независимые REST API для каждого продукта экосистемы: Gmail API для почты, Google Drive API для диска, для календаря — Google Calendar API и так далее. У каждого сервиса свой базовый URL и своя документация. Все они используют общую систему единой аутентификации OAuth 2.0 и сервисные аккаунты Google Cloud.

В отсутствие собственного единого Graph API Google действует грубо и вводит Single Data Owner, заставляя сисадминов тратить ресурсы на ручную или скриптовую зачистку. Microsoft действует мягче, окутывая автоматизацией и дешевыми архивами.

Google фактически переложил на плечи клиентов работу по идеальному структурированию данных в своем облаке. Корпорация заставила бизнес потратить миллионы долларов (в виде зарплат сисадминов) на то, чтобы упорядочить данные внутри Google Workspace.

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

Как и у Microsoft, новая политика управления жизненным циклом данных Google это один из компонентов новой парадигмы организации рабочих мест и современной совместной работы, которую Google продвигает через собственные ключевые понятия и терминологию и архитектурные решения: Workspace Intelligence, Workspace API Dashboard и Workspace Studio. 

К лету 2026 Google полностью оформил свой ответ концепции Microsoft и перешел от разрозненных офисных утилит к унифицированной платформе, где главным клеем для приложений стал не единый «супер‑API», а динамический контекст ИИ (Workspace Intelligence) и Low‑code сценарии (Workspace Studio).

Эволюция архитектуры Google до создания сквозного ИИ‑контекста заняла около трех лет. Первым делом, Google постарался снять вопрос отсутствия «единого Graph API»: свел в панель Workspace API Dashboard метрики, квоты и доступы всех Workspace API (Gmail, Drive, Chat, Meet) Google. 

Разработчики были избавлены от необходимости вручную собирать интеграции по всему облаку Console Cloud. Бета‑версия вышла еще в 2023 году, сейчас уже активно используется. Плюс реализовал единую сквозную систему авторизации OAuth 2.0 и доменного делегирования (Domain‑wide Delegation).

В 2024 — середине 2025 Google совершил разворот от концепции «закрытой экосистемы» к интероперабельности в рамках «открытой мультиоблачной инфраструктуры», имея ввиду вынужденное сосуществование с Microsoft.

До этого Google пытался увлечь бизнес предложением: «откажитесь от Microsoft 365 и переводите всю компанию на Google Workspace», но не найдя должного понимания, Google изменил подход и реализовал три прямых технологических моста с Microsoft.

Весной‑летом 2025 года Google сначала делает неожиданный шаг и внедряет прямую двусторонняя интеграцию с Microsoft Graph API прямо внутрь консоли администратора Google Workspace для бесшовной синхронизации календарей и бронирования переговорок между Exchange 365 и Google Calendar, и подготавливая клиентов к отключению старых протоколов Microsoft. Это позволило облаку Google “нативно” читать статус занятости и бронировать ресурсы в Exchange 365 в реальном времени. Исторически переговорные комнаты и календари в компаниях, где часть отделов сидит на Google, а часть — на Outlook, постоянно конфликтовали (возникали двойные бронирования, ИИ‑помощники не видели занятость коллег). 

В этот же период Google открыл API своего мессенджера (Google Chat API) для кросс‑платформенных коммуникаций (интероперабельности) между Google Chat и Microsoft Teams. Это позволило связать каналы Google Chat и Microsoft Teams так, чтобы сотрудники из разных сред могли общаться, пересылать файлы и создавать встречи, не замечая, что они используют разный софт, вместо того чтобы заставлять пользователей переключаться между окнами.

И наконец, интероперабельность искусственного интеллекта и документов. Google адаптировал свои API так, чтобы корпоративные ИИ‑помощники (включая Copilot от Microsoft) могли легально и безопасно (с сохранением прав доступа) индексировать документы на Google Диске, а Gemini — понимать ссылки на файлы в экосистеме Microsoft.

Google решил, что его семантический граф знаний обязан бесшовно понимать и связывать данные, даже если они физически лежат на серверах Microsoft, а не ограничиваться только .gdoc файлами.

Затем Google сфокусировался на объединении сервисов Workspace через инструменты сквозной автоматизации, и в декабре 2025 года выпустил релиз Google Workspace Flows (бета‑версия будущей Workspace Studio). Были представлены первые триггеры и «экшены», которые могли автоматически переносить данные из Gmail в Sheets, создавать задачи в Календаре и генерировать документы без участия сторонних интеграторов (вроде Zapier). К концу года инструмент автоматизировал более 20 миллионов рутинных задач.

В марте 2026 года Google выпустил специализированный CLI (интерфейс командной строки) для Workspace, спроектированный с прицелом на автономных агентов. В отличие от старого Microsoft Graph, созданного для системных администраторов, этот инструмент позволяет ИИ‑моделям мгновенно вызывать функции экосистемы Google.

В апреле 2026 года (Конференция Cloud Next '26) официально анонсировано ядро Workspace Intelligence на архитектуре Semantic Data Graph (Семантического графа данных), который объединил данные Gmail, Drive, Docs и Meet в единое контекстное поле. Теперь ИИ‑ассистенту Gemini не нужно вручную скармливать файлы — он видит всю рабочую среду компании в режиме реального времени.

Платформа Google Workspace Studio переведена в стадию General Availability и стала полноценным визуальным хабом для автоматизации рабочих процессов внутри всей экосистемы Google и сборки ИИ‑агентов силами обычных бизнес‑пользователей. В Microsoft связующим звеном архитектуры выступает связка Graph API + Power Automate. 

В мае — июле 2026 года Google внедрил протокол MCP (Model Context Protocol), чтобы сторонний ИИ‑агент мог одной командой получить доступ и к таблице, и к письму, минуя сложную интеграцию разных SDK. Google активно стандартизирует свои API под «инструменты для агентов» (Agent Tools). Платформа Apigee превращена в центральный узел управления доступами ИИ‑агентов к корпоративным данным, и обновил квоты для Gmail API, Calendar API и Drive API, подстраивая их под поведение ИИ‑инструментов, чтобы защитить компании от утечек данных при массовых запросах со стороны агентов. Это ответ Google на архитектуру Microsoft Copilot Studio. 

Нюанс в том, что семантический граф контекста Google создал для ИИ‑агентов, а не разработчиков. Google не дал разработчикам прямого низкоуровневого API к семантическому графу, аналогичного Microsoft Graph (где можно написать запрос на чтение сырых связей ребер графа).

Контекст для ИИ. Новый узел гравитации Google Workspace и Microsoft 365

Вполне понятны слова Google и Microsoft про ликвидацию бесхозных данных (Orphan Data), борьбу с «цифровым мусором», освобождение ресурсов и безопасность. У них запредельные петабайты «мертвых» B2B‑данных, накопленных по всему миру. Но в этих инициативах есть гораздо более мощный, и не слишком скрытый, мотив.

Между информацией и данными есть разница. Сырые, разрозненные, объективные факты — это данные. Буквы, цифры, байты, строка в формате .ics с датой 2026–07-01T09:00:00, файл с расширением .eml. Они лишены контекста и потому мертвы. Данные очищенные, структурированные и наделенные смыслом через связи (контекст) — это информация. Она позволяет отвечать на вопросы «что это значит?», «как это связано с тем‑то и тем‑то обстоятельством?» и «кто на что повлиял?».

Оба вендора активно формируют новый узел гравитации, в котором удержание клиентов смыкается с ключевым рычагом монетизации. Google и Microsoft начинают оперировать на уровне информации, целостного бизнес‑контекста, а не просто на уровне фичей, протоколов и данных (например, содержимого календарей).

Осознавая, что антимонопольное регулирование ЕС и открытые протоколы вроде JMAP и Matrix неизбежно ломают старую монополию, Microsoft и Google перенесли границы своих «закрытых садов» на более высокий уровень — уровень жизненного цикла данных и бизнес‑контекста.

Если убрать маркетинговые названия (MOCA у Microsoft и Smart Canvas / AI‑First Workspace у Google), становится очевидно, обе компании стремятся консолидировать информационный контекст и качественно повысить его операбельность внутри своих экосистем.

Новая парадигма у обоих вендоров уничтожает границы между программами. Экосистемы переходят от «приложений» к «контекстным хабам».

В MOCA (Modern Collaboration Architecture) Microsoft центральным хабом становится Microsoft Teams. Файлы SharePoint, чаты, задачи Planner и приложения Power Apps стягиваются внутрь одного окна Teams. Пользователю больше не нужно выходить из мессенджера, чтобы делать работу.

В экосистеме Google центральным хабом становится документ как умный холст (Smart Canvas) или Google Chat. Вместо того чтобы переключаться между отдельными приложениями (открыть Docs, потом созвониться в Meet, потом вставить ссылку на Sheets), Google объединяет всё в единое бесшовное пространство. Вы прямо внутри текстового документа можете запустить созвон, тегнуть человека, подключить интерактивную задачу или подтянуть файл через смарт‑чипы (@-mentions). Документ превращается в приложение.

Фокус смещается с файлов и переносится на «живые и атомарные» компоненты. Обе архитектуры понижают гранулярность и переходят к переносимым блокам данных, который обновляется одновременно везде, где задействованы.

В MOCA Microsoft этому служит концепция Loop‑компонентов (на базе открытого протокола Fluid Framework). Вы можете создать список задач в Teams, скопировать его в Outlook, и он будет обновляться в реальном времени в обоих местах.

В экосистеме Google это Smart Chips и интеграция динамических блоков. Таблица, вставленная в презентацию, или интерактивная карточка задачи в Google Chat — это не скриншоты, а живые сквозные микро‑виджеты.

Вместо поиска пользователем папок и файлов фокус переносится на «Обнаружение» (Discovery) и проактивную выдачу информации.

Оба вендора признали: древовидные структуры папок мертвы. В MOCA (Microsoft) механизм рекомендаций (наследник Office Graph) через главную страницу Office.com или Copilot подсказывает: «Вот файлы, которые ваши коллеги редактировали перед вашей следующей встречей».

В экосистеме Google поисковый ИИ‑движок и семантическое облако (Workspace Intelligence) подтягивают нужные документы в контекст текущей беседы или проекта без ручного поиска со стороны человека.

В 2026 году обе архитектуры окончательно превратились в платформы для ИИ‑оркестрации (AI‑First / Agentic Workspace).

В MOCA (Microsoft) Copilot Studio использует Microsoft Graph как навигационную карту предприятия, чтобы понимать роли, доступы и связи сотрудников.

В экосистеме Google Gemini и Workspace Studio используют семантический граф знаний (Enterprise Knowledge Graph), чтобы связывать смыслы документов и автоматизировать сквозные бизнес‑процессы через протокол MCP. Если Microsoft в рамках MOCA учит людей правильно использовать приложения (Teams для чата, Outlook для писем), то Google продвигает концепцию, где архитектура строится вокруг ИИ‑агентов и Gemini, которые заменяют рутинные переключения между программами.

Оба вендора, и Microsoft и Google, строят цифровую среду следующего поколения, но идут с разных сторон. Разницу определяют корни их бизнес‑моделей и то, как они собирали свои экосистемы исторически.

Microsoft идет от организационной структуры предприятия. Microsoft Graph в первую очередь отвечает на вопрос: кто, где и с кем? Точка отсчета — человек и его роль, в каком он департаменте. У нет нет равных в степени покрытия бизнес‑процессов и тотальности охвата (и контроля) инфраструктуры рабочих мест компании.

Microsoft Graph буквально дублирует операционную деятельность компании формируя ее «цифровой социально‑организационный двойник».

Microsoft Graph “прошивает” операционную деятельность компании насквозь и владеет полным контекстом инфраструктуры. Он знает ID каждого сотрудника (Entra ID, бывший Active Directory), с какого ноутбука (Intune) он зашел, в каком отделе или филиале числится, его переписку в Teams, файлы и бронирование переговорных комнат.

Вы можете сделать один запрос к API и вытащить граф вида: «Покажи мне файлы, над которыми работали люди, бывшие на созвоне с моим начальником за последние 3 часа». Если сотрудник увольняется или переводится в другой отдел, «двойник» мгновенно перестраивает тысячи связей, доступов и цепочек согласования по всей системе.

Каждое отправленное письмо, созданная встреча в календаре, лайк на документе или тред в чате — это цифровой след деятельности сотрудников компании в целом. Когда сотрудник компании сидит в Microsoft 365, Microsoft Graph непрерывно и в реальном времени собирает эти следы и строит цифрового двойника компании в своем облаке. Этот двойник «знает», кто реальный лидер в команде (по графу общения), какие проекты буксуют (по дельтам календарей), и какая документация сейчас критически важна.

При этом, Microsoft Graph слабо понимает, что именно написано внутри документов и писем. И если Microsoft связывает файлы по авторам, то Google (Workspace Intelligence) связывает их по смыслу, опираясь на семантический граф (Semantic Data Graph).

Граф Google понимает, что «Проект Альфа» в цепочке писем, «Таблица поставок оборудования» в Sheets и «Презентация для инвесторов» в Slides — это одна и та же сущность, даже если в них нет общих тегов, авторов или папок.

Google строит «цифровой ментальный двойник компании», семантическое облако когнитивной деятельности компании.

Google создавал свои сервисы от поисковой строки и доступности информации. Поэтому, на первом месте для Google не иерархическая структура сотрудников, а поток общих знаний. Точка отсчета — документ и смысл. Google Workspace изначально создавался как Cloud‑Native среда с фокусом на совместной работе над документом в браузере. Google не важно, сидишь ты в переговорной или дома, со своего ноутбука или с чужого планшета. Важен сам контент и возможность находить неочевидные логические связи в терабайтах документов и писем.

Workspace Intelligence связывает сущности по смыслу: проект, идея, клиент, задача. ИИ от Google (Gemini) понимает, о чем бизнес, но сама ИТ‑инфраструктура компании и ее социально‑организационный граф у Google выражен гораздо слабее, чем в Microsoft.

Microsoft Graph или Workspace Intelligence — это, по сути, два варианта проприетарной реализации инфраструктурного слоя для создания Цифрового двойника организации (DTO, Digital Twin of an Organization) в самой сложной, хаотичной и трудноуловимой её части, в домене живых коммуникационных процессов и Human‑Generated данных.

Обычно под цифровым двойником понимают датчики на заводах (IoT) или 3D‑модели турбин, или ERP/BPM таблицы и схемы процессов. Но это лишь 20% реальности. Остальные 80% жизни компании — «серая зона» повседневных коммуникаций и работы с документами. Это «неструктурированный хаос» взаимодействий в ветках обсуждений (тредах) мессенджера или видеосозвонах, в составах участников и повестках совещаний в календаре, в цепочках писем и комментариях к документах, в самих документах. В Microsoft первыми поняли, что тот, кто контролирует этот хаос, контролирует весь бизнес‑контекст.

Microsoft и Google теперь продают компаниям не воркспейс‑комбайны, а цифровой мозг их собственного бизнеса, который работает только в облаке Microsoft или Google.

В предлагаемой Microsoft и Google модели Цифровой двойник организации (DTO, Digital Twin of an Organization) не принадлежит самой этой организации. Она лишь арендует у Microsoft или Google право пользоваться выводами двойника, но как только попытается уйти, получит безжизненный склад сырых данных, цифровой двойник (семантический граф) испарится, корпоративный ИИ слепнет и глупеет. 

С точки зрения VRM (управления рисками) это гениальная петля удержания. Объем зависимостей данных становится настолько колоссальным, что мысль о миграции отметается сразу: цена скачивания и переноса петабайтов архивов неподъемна, но главное — при переносе полностью теряется контекст взаимодействия.

Мы присутствуем при начале тектонической битвы за то, кому принадлежит семантическая модель взаимодействия бизнеса. Тот, кто контролирует граф связей, контролирует и зрение корпоративного искусственного интеллекта. Если этот граф закрыт внутри проприетарного монолита вендора, бизнес обречен платить вечный «инфраструктурный налог» и налог на интеграцию.

JMAP + Matrix. Требует реализации

В июле 2026 года в экосистеме открытого децентрализованного протокола Matrix (мессенджеры, видеозвонки) произошло знаковое событие: было опубликовано официальное предложение по изменению спецификации MSC4496 (“Calendar Events, Invites, and Availability in Matrix”).

Эта инициатива зрела в сообществе очень долго: еще в 2018 году разработчики в MSC1116 / Issue #284 (“Proposal for Calendar Events”) впервые предложили затащить iCal в Matrix. Но тогда проект забуксовал, так как iCal плохо ложился на JSON. Команда Matrix (включая сооснователя Matrix Мэтью Ходжсона), в процессе обсуждения обратила внимание на черновики JSCalendar от IETF.

MSC4496 стал итогом этих многолетних изысканий и предлагает полностью стабилизированную архитектуру нативной поддержки календарей, приглашений на встречи и синхронизацию занятости (Availability). Предложение находится в статусе Open с меткой needs‑implementation. Доказать не могу, но думаю, сейчас сообщество активно создаёт рабочие реализации.

С добавлением «Calendar Events, Invites, and Availability» в спецификацию, Matrix покроет последний пустующий сегмент, превращаясь в полноценный суверенный коммуникационный стек (Unified Communications) организаций.

Речь идет про протокольный мост, а не слияние: Matrix берет на себя native‑шифрование, федерацию комнат и транспорт сообщений (используя структуры данных JSCalendar), а специализированный JMAP‑сервер (например, Stalwart) выступает бэкендом для классической внешней почты, синхронизируя данные с Matrix через современные легковесные Application Services.

MSC4496 делает календари JMAP полностью Matrix‑нативными. Он не затаскивает сам протокол JMAP внутрь комнат Matrix, и не использует методы JMAP (такие как CalendarEvent/get или set). Вместо этого он заимствует только семантическую модель данных (схему JSON‑полей) из стандарта JSCalendar (RFC 8984 / draft‑ietf‑calext‑jscalendarbis).

Связка JMAP + Matrix на наших глазах кристаллизуется в новый мировой индустриальный стандарт по‑настоящему суверенных, гибких и свободных от вендорского капкана цифровых рабочих мест.

Анатомия «Календарных комнат»

MSC4496 опирается на расширяемые события MSC1767 (Extensible event types & fallback in Matrix): одно событие может содержать множество «миксов» данных, одновременно нести в себе и чат‑текст, и структурированный JSON JMAP с метаданными, вложениями и ветвлением (threading).

Вместо хаотичного «текстового спама» от интеграционных ботов («встреча перенесена на 15:00»), который годами засорял корпоративные чаты, MSC4496 вводит элегантную концепцию Календарных комнат (m.calendar). Календарь в Matrix — это не плоская таблица, а структурированный поток append‑only событий в ленте, подчиненный строгой архитектурной иерархии типов.

Разделение сущностей позволило заложить в MSC4496 абсолютный иммунитет к DST‑коллапсам: в m.calendar.eventодновременно хранятся и точное UTC‑время, и именованный идентификатор таймзоны IANA. Если завтра правила перехода на летнее время изменятся, расписание внутри Matrix не «съедет» — клиенты корректно пересчитают локальное время встречи.

Криптография без ослепления ИИ

При проектировании MSC4496 был жестко соблюден принцип конфиденциальности в соответствии с требованиями GDPR (General Data Protection Regulation — европейского регламента хранения и обработки персональных данных пользователей). 

Новая группа эндпоинтов /user/{userId}/availability позволяет децентрализованно запрашивать сетку занятости сотрудников (Free/Busy) через трехуровневую систему доступов (Tiers). По умолчанию (Tier 1) внешние контакты или серверы могут узнать лишь о том, занят ли временной слот, но названия мероприятий или списки участников (видят только глухие маркеры BUSY или BUSY-UNAVAILABLE, полностью скрывая названия ваших личных встреч), если только вы явно не предоставите к ним доступ). Информация о состоянии переговорной комнаты, доступная в рамках федерации, не содержит персональных данных.

Matrix + JMAP совместно формируют уникальный нативный E2EE‑контур для бизнес‑контекста, решая главную дилемму ИИ‑эры.

В проприетарных All‑in‑One комбайнах расписания и брони переговорок всегда лежат в открытом для администраторов виде. В связке Matrix + JMAP календарные JSON‑объекты упаковываются внутрь стандартного шифрования комнаты (m.room.encrypted), превращаясь в монолитный шифротекст, недоступный хостинг‑провайдеру.

Шифрование защищает данные, но сохраняет информацию для бизнеса. Чтобы корпоративный ИИ (локальный LLM‑ассистент) не «ослеп», он подключается к зашифрованной комнате как полноправный участник (аккаунт или бот с собственными ключами шифрования) и наравне с пользователями обменивается ключами по протоколам Olm/Megolm. Для сервера на wire‑уровне всё остается нечитаемым шумом, но внутри своего защищенного контура ИИ‑бот расшифровывает payload. Он видит и текст обсуждения, и нативный ивент m.calendar.event, и ответы m.calendar.rsvp, получая полноценную, защищенную криптографией карту бизнес‑процессов вместо голого массива дат.

Более того, спецификация MSC4496 содержит осознанный архитектурный компромисс: метаданные отношений (поле m.relates_to, связывающее RSVP с инвайтом) по правилам Matrix всегда находятся снаружи зашифрованного payload (в открытом виде).

Homeserver не видит тему встречи, но видит сам граф связей — кто именно и в какое время отправил реакцию. Это позволяет корпоративным системам строить топологию связей (80% бизнес‑контекста) вообще без дешифровки самих сообщений.

Спецификация MSC4496 жестко требует: если в комнате включено E2EE, текстовый fallback (m.text), содержащий человекочитаемое описание встречи (например: «Team standup — 2026–07-01»), обязан быть удален из незашифрованной части события. Иначе произойдет утечка темы встречи серверу.

Для сверхсекретных контуров MSC4496 рекомендует слать инвайты через отдельные приватные DM‑комнаты с каждым сотрудником. Неподдерживающие календари старые клиенты в зашифрованных комнатах увидят просто «Зашифрованное сообщение», пока не научатся парсить payload внутри Megolm.

Matrix + JMAP. Будущий открытый "движок" цифрового двойника предприятия?

Если и когда (надеюсь скоро) предприятия получат возможность развернуть связку JMAP + Matrix (MSC4496), они получат открытую, стандартизированную на уровне индустрии модель данных (JSCalendar, JSContact, Matrix DAG), открытый семантический слой коммуникаций, рабочих процессов и работы с документами. Расписания, чаты, задачи и документы крутятся в едином E2EE‑контуре Matrix, граф связей (m.relates_to) формирует непрерывно обновляемый слепок жизнедеятельности компании. 

JSCalendar 2.0 нативно понимает бизнес‑контекст: корпоративную иерархию, автоматический скоупинг департаментов и JSON‑профили делегирования прав. Смысл бизнес‑действия зашит в сам открытый стандарт (старый .ics умел хранить только «голые» данные о времени).

Документ в JMAP File Storage — это не файл на диске. Это узел, опутанный связями: «кто создал, на каком совещании утвердили, кто и кому открыл доступ».

В старой парадигме (Exchange/CalDAV) у вас были голые логи: «Иван отправил файл Петру». Это мертвые данные. В Matrix направленный ациклический граф событий (DAG) нативно связывает конкретную переговорку (m.calendar комната), cсылку на видеопоток (MatrixRTC), текст обсуждения в тредах, итоговый Markdown‑документ.

Календарная комната Matrix (m.calendar) — это не сетка времени, а цифровой слепок управленческого акта. Перенос встречи организатором, шквал отказов (RSVP) от ключевых инженеров, прикрепленный файл ТЗ — двойник мгновенно фиксирует изменение траектории проекта в виде направленного ациклического графа (DAG) событий.

Связка JMAP + Matrix (включая MSC4496) посаженная на плоский семантический граф — это не что иное, как базовая инфраструктура для суверенного цифрового двойника human‑generated процессов.

Контекст связей изначально зашит в саму структуру JMAP + Matrix (MSC4496). Семантический граф взаимодействия сотрудников становится нативным свойством самой ИТ‑архитектуры предприятия, его абсолютной собственностью и активом (по TOGAF), а не проприетарной услугой Big Tech.

Саммари встреч — это автоматизация стенографии. ИИ способен на большее

Граф коммуникаций предприятия — это бесконечный полигон для обучения суверенных графовых нейросетей (GNN), предсказания аномалий, оптимизации бизнес‑процессов и автоматического комплаенса. Это стратегический актив предприятия, фундамент для системного инжиниринга всей организации.

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

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

С помощью анализа организационных сетей (Organizational Network Analysis — ONA) на базе графа связей (m.relates_to) ИИ может выявить реальную топологию компании. Он покажет «бутылочные горлышки», дублирование функций, или процессы, которые ни к чему не ведут и ни на что реально не влияют. Получаем реинжиниринг процессов (Process Mining) и динамическую оптимизацию ролей.

Локальный ИИ увидит реальные цепочки создания ценности. Он может на лету построить карту: «Запрос на закупку оборудования [ID] прошел через 5 департаментов, породил 3 календарные встречи, 14 тредов обсуждения», или «все 30 запросов на анализ ТЗ в июне, в конечном итоге пришли к одному единственному рядовому инженеру Ивану». Бизнес получает автоматический, объективный аудит процессов без заполнения таймшитов.

Связка m.calendar + JSCalendar 2.0 позволяет сопоставить время, потраченное сотрудниками разных отделов, с реальными цепочками писем, чатов и видеоконференций. Вы можете математически точно увидеть, сколько часов и ведомственных итераций уходит на согласование банального договора, есть ли реальный прогресс в обсуждениях, или одна и та же тема одними и теми же словами раз за разом обсуждается уже полтора года. Оптимизация процессов превращается из умозрительного «давайте работать эффективнее», или «новый регламент по улучшению регламентов» в инженерное удаление лишних узлов из графа связей.

Поскольку дельта‑транзакции изменений календарей и RSVP‑статусов фиксируются в DAG комнаты Matrix, локальный ИИ‑ассистент, обученный на контексте компании, начинает видеть паттерны, аномалии и выдавать предупреждение, что проект стагнирует, реального прогресса в обсуждениях нет, или что сроки под угрозой срыва. Получаем предиктивный анализ рисков проектов.

Саммари встреч просто сжимает текст. Открытый граф позволяет реально оптимизировать когнитивную нагрузку на людей. ИИ увидит, что команда тратит 40% своего календарного времени (m.calendar.event) на совещания, которые не связаны с их непосредственными задачами (нет пересечений по графу общих файлов, проектов или тредов разработки). Система может автоматически рекомендовать изменить роль сотрудника со «стандартного участника» на «опционального» или перевести встречу в асинхронный текстовый формат дельта‑транзакций, освобождая дефицитные часы и фокус внимания.

Если граф фиксирует, что узел сотрудника начинает изолироваться (падает плотность связей в проектных Matrix‑комнатах, время ответов RSVP растет, человек замыкается), ИИ сигнализирует HR‑директору: «Риск выгорания/увольнения — 85%». 

В открытом графе Matrix история всех обсуждений, контекст принятия решений, файлы и изменения календаря связаны в неразрывный направленный ациклический граф (DAG). Когда приходит новый сотрудник, ИИ сможет на основе его роли подключить его к нужным узлам графа. Сотрудник получит не просто доступ к папке с документами (в которой всегда не все, что имеет отношение к теме), а доступ к живой контекстной истории: почему это решение было принято, какие альтернативы обсуждались в тредах, и все относящиеся к теме документы. Время онбординга нового сотрудника сокращается в разы. Затраты на поддержание общего контекста в команде любого размера радикально снижаются. Получаем настоящую корпоративную память, доступный сотрудникам и командам общий контекст вместо «кладбища файлов и хаоса страниц».

Почему российские вендоры воркспейс-комбайнов не смогут собрать аналог Microsoft Graph

Российские вендоры корпоративного софта (коммуникационных платформ, мессенджеров, ВКС, вообще воркспейсов) находятся в ситуации ускоренного догоняющего развития. Их ИИ‑ассистенты уже способны саммаризировать чаты, переводить созвоны в текст и искать документы. Однако делают они это локально в рамках одного приложения, еще не объединяя всю компанию в глобальный семантический граф.

Одновременно с этим, российские игроки из смежных сегментов начали массово разворачивать готовую MCP (Model Context Protocol) инфраструктуру. Например, Cloud.ru в своей среде Evolution предоставляет встроенные инструменты для подключения ИИ‑агентов к корпоративным мессенджерам и базам данных через стандарт MCP. СберБизнес запустил полноценный корпоративный MCP‑сервер, позволяющий ИИ‑агентам использовать банковский контекст и автоматизировать расчетные операции. ИТ‑платформы вроде SimpleOne или Аспро.Cloud также активно встраивают MCP‑агентов, которые могут собирать сводки по инцидентам или задачам напрямую из систем.

Внедрения протокола MCP в России это отличный шаг в направлении семантического графа для ИИ. Открытый протокол MCP, как трамплин, поможет российским вендорам сократить затраты на интеграцию «каждый с каждым», и одновременно миновать годы разработки классических тяжелых API‑платформ для развития «ИИ‑агентов поверх корпоративных данных».

В плане социально‑организационного графа (аналога Microsoft Graph), который объединял бы все действия пользователя, роль и права в организации, его устройство, почту, чаты и файлы в единую «паутину» связей, российские вендоры пока находятся на базовом этапе. Закрытость архитектур и фрагментация рынка станут очень серьезным препятствием созданию решения, способного дать бизнесу целостный бизнес‑контекст. 

В российских реалиях 2026 года инфраструктурный фундамент тотально раздроблен. Ни один отечественный вендор не контролирует весь стек (службу каталогов, ОС, офисный пакет и мессенджер) целиком и не будет контролировать. Согласно TOGAF, к слову, и не должен. Попытка построить «русский Microsoft Graph» поверх или внутри проприетарных решений сегодня выглядит как попытка сшить Франкенштейна. Пытаться связать закрытые коробки через кастомные интеграционные скрипты — задача дорогая, увлекательная и безнадежная.

Даже если бы вендоры открыли друг другу свои API нижнего уровня, они остаются прямыми конкурентами в «красном океане» ограниченного локального Enterprise‑рынка, бьющимися за одни и те же бюджеты. Их экономическая модель построена на капитализации закрытости, а не на сотрудничестве. Как итог, их встроенные ИИ‑ассистенты продолжат нормально оперировать только данными внутри собственной изолированной «коробки».

Конвергенция JMAP и Matrix возвращает бизнесу фундаментальные принципы TOGAF — данные как корпоративный актив и архитектуру со слабой связанностью (Loose Coupling). Предприятие получает возможность свободно выбирать и менять компоненты серверной инфраструктуры и пользовательские клиенты (офисный пакет, мессенджер, что угодно) — информационный контекст вашего бизнеса не рассыплется, потому что семантический граф взаимодействия сотрудников становится неотчуждаемой собственностью самого предприятия.

Российские вендоры пытаются собирать All‑in‑One комбайны «сверху» (на уровне интерфейсов супераппов), в то время как Microsoft Graph держится на жестком «нижнем» фундаменте — едином ID‑провайдере (Entra ID / Active Directory). Без суверенного аналога глобального каталога учетных записей, графовая связность российских комбайнов всегда будет рассыпаться на стыках сторонних API. 

Следующая статья будет посвящена именно этой теме: опишу контуры перспективной, построенной на графах, вендор‑нейтральной архитектуры управления учетными записями пользователей и устройствами (на замену Active Directory и классическим UEM). Обязательно разберу перспективы суверенных удостоверений W3C DID в корпоративном ландшафте вообще и в пересечении с Matrix‑идентификаторами пользователей (@user:server.com).