Comments 7
Очень откликнулся тезис о том, что ценность постепенно смещается от доступа к отдельным данным к связанному контексту. В прикладных AI-системах я вижу похожую проблему на меньшем масштабе: просто дать агенту доступ ко всем письмам, файлам, CRM и календарю недостаточно. Дальше всё равно приходится проектировать, какой контекст нужен для конкретного шага, что считать текущим state, какие связи можно подтягивать автоматически, а где нужны ограничения по ролям и human approval. Мне кажется, следующий важный слой после самого semantic graph — это policy над этим графом: кто, когда и для какой задачи может получить какой кусок контекста. Иначе мы решаем проблему доступности данных, но получаем новую — слишком широкий и плохо управляемый контекст для агента.
Как вы видите этот слой: он должен жить внутри самого graph/identity layer или уже на уровне agent orchestration?
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.
Спасибо, вот разделение Graph / Identity → policy decision → orchestration как PEP как раз проясняет границу.
И тогда у меня возникает следующий вопрос — уже не столько про доступность контекста, сколько про его временную валидность. Допустим, в графе есть связь: человек состоит в проекте, документ относится к проекту, агент имеет право подтянуть этот контекст. Через неделю человек вышел из проекта или документ получил новый статус. Сам факт и старая связь в истории никуда не исчезли, но они больше не должны давать право на использование контекста. То есть помимо ABAC получается нужен ещё слой, который понимает не только кто → к чему связан, но и какая версия связи сейчас является действующей, кем она подтверждена и когда должна перестать влиять на policy decision.
Вы бы такую temporal validity тоже закладывали прямо в graph/identity layer — например, через события/версии/valid-from–valid-to — или держали бы её отдельным policy-state рядом с графом?
CIDOC-CRM здесь как раз интересно выглядит из-за event-centric модели, но мне пока неочевидно, где лучше провести границу между «историей того, что произошло» и «текущим фактом, который имеет право управлять доступом».
С большим интересом прочитал обе ваши статьи, увы кармы нет плюсануть. Отличный материал на подумать. Много говорите о семантике, и раз знаете про CIDOC интересно знаете ли про труды Александра Болдачева в сторону темпоральной онтологии и его проект boldsea?
Это было интересно, я как-то был совсем не в курсе этой движухи (немного сталкивался с Intune и Azure AD из относительно нового).
Интересная мысль что если ты все общение и знание прокачиваешь через облако, то у тебя возникает какой-то материал для ИИ который хорошо знает компанию и может со временем что-то там делать. Руководитель такой "мне надо уволить 50 человек", а ИИ "вот этих можно смело" (помните это мемное сокращение Xsolla через "big data").
Не знаю, если бы я был бы владельцем компании стал бы вот так переводить все на облачную инфраструктуру. Если компания небольшая то вот эти Graph, Entra ID как будто не особо нужны. Если компания большая то можно держать свой IT для инфраструктуры.
Спасибо за комментарий. Все что не на локальных машинах пользователей строго говоря можно считать "облаком", вопрос лишь в том кто контролирует это облако и насколько это облако зависит от проприетарного стека. Про фундаментальные ограничения on-prem написал в первой статье "Корпоративные мессенджеры и воркспейс‑комбайны. Разбираем вендорский капкан".
Вообще, я думаю, все эти вещи быстрее и раньше взлетят как раз в сегменте малого и среднего бизнеса. Там другое отношение к вендор-риску и эффективности. Взлетят, если сделать развертывание простым и легким.
А Xsolla с кадрами своими управилась без всяких премудростей, шашкой махать "big data" не нужен :)
Финальная битва за календари. Первая битва за контекст для ИИ