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

[MayaButo]

Очень откликнулся тезис о том, что ценность постепенно смещается от доступа к отдельным данным к связанному контексту. В прикладных AI-системах я вижу похожую проблему на меньшем масштабе: просто дать агенту доступ ко всем письмам, файлам, CRM и календарю недостаточно. Дальше всё равно приходится проектировать, какой контекст нужен для конкретного шага, что считать текущим state, какие связи можно подтягивать автоматически, а где нужны ограничения по ролям и human approval. Мне кажется, следующий важный слой после самого semantic graph — это policy над этим графом: кто, когда и для какой задачи может получить какой кусок контекста. Иначе мы решаем проблему доступности данных, но получаем новую — слишком широкий и плохо управляемый контекст для агента.
Как вы видите этот слой: он должен жить внутри самого graph/identity layer или уже на уровне agent orchestration?

[german_chebotarev]

Cпасибо за отличный вопрос! Вы затронули, пожалуй, одну из ключевых тем в проектировании ИИ‑инфраструктуры предприятия. Даже две. 

Выдать агенту избыточный контекст без четких рамок значит получить массу сюрпризов: галлюцинации, инциденты ИБ, рост костов. Положиться в вопросе определения рамок и контроля соответствия на уровень Agent Orchestration невозможно. Это было бы слишком большим доверием агенту или его оркестратору в нарушение принципа Zero Trust. И это было бы нарушением принципа Loose Coupling, слишком большой риск лок‑ин. На уровне agent orchestration — исполнение (Policy Enforcement Point, PEP) с опорой на выданный и уже отфильтрованный под его текущую роль контекст. Policy Layer должен быть распределенным, но его фундамент должен находиться на стыке Graph / Identity Layer. И я бы предложил посмотреть в сторону декларативных механизмов управления. Реализовать можно через Attribute‑Based Access Control (ABAC) и динамические графовые связи. 

И второй момент, Вы написали:

«...всё равно приходится проектировать, какой контекст нужен для конкретного шага, что считать текущим state, какие связи можно подтягивать автоматически, а где нужны ограничения по ролям и human approval...»

Это, на мой взгляд, самый хардкорный пласт темы. Думаю, здесь жизненно необходима generic‑модель, строгая семантическая онтология. С нуля делать ни в коем случае. Это кроличья нора. Но можно адаптировать существующие. Вариантов много, но мне в голову упорно лезет CIDOC‑CRM. Вообще она создавалась для музеев и оцифровки культурного наследия, но это в первую очередь чистокровная, монументальная Event‑Centric онтология верхнего уровня. Очень хорошо проработанная. Принята как ISO 21127. Лучше я не видел. Все связи между сущностями (людьми, вещами, местами) устанавливаются только через сущность E5 Event (Событие) или E7 Activity (Деятельность). Обязательно попробую смаппить ее на Matrix / JMAP.

[MayaButo]

Спасибо, вот разделение Graph / Identity → policy decision → orchestration как PEP как раз проясняет границу.
И тогда у меня возникает следующий вопрос — уже не столько про доступность контекста, сколько про его временную валидность. Допустим, в графе есть связь: человек состоит в проекте, документ относится к проекту, агент имеет право подтянуть этот контекст. Через неделю человек вышел из проекта или документ получил новый статус. Сам факт и старая связь в истории никуда не исчезли, но они больше не должны давать право на использование контекста. То есть помимо ABAC получается нужен ещё слой, который понимает не только кто → к чему связан, но и какая версия связи сейчас является действующей, кем она подтверждена и когда должна перестать влиять на policy decision.
Вы бы такую temporal validity тоже закладывали прямо в graph/identity layer — например, через события/версии/valid-from–valid-to — или держали бы её отдельным policy-state рядом с графом?
CIDOC-CRM здесь как раз интересно выглядит из-за event-centric модели, но мне пока неочевидно, где лучше провести границу между «историей того, что произошло» и «текущим фактом, который имеет право управлять доступом».