# Разделение и композиция социальных ролей ИИ, custody памяти и интерпретаций ## Почему многоролевая приватная `c` и сервисный ИИ требуют разных границ **Иван Котов** Брюссель, 1 августа 2026 года **Версия:** 1.0 (каноническая редакция) **Статус:** концептуальная научная заметка для корпуса Project Ester / Advanced Global Intelligence --- ## Аннотация Современные ИИ-системы обычно классифицируют по мощности модели, длине контекста, автономности, набору инструментов и способности действовать. Такой подход недостаточен. По мере вхождения ИИ в повседневную жизнь общество будет различать системы не только по тому, **что они умеют**, но и по тому, **какую социальную роль или композицию ролей они занимают**. Облачный голосовой собеседник, агент-исполнитель, профессиональный ИИ, институциональный контур и личная долговременная `c` могут использовать сходные модели, но они предъявляют принципиально разные требования к памяти, производным интерпретациям, праву действия, custody, прозрачности, непрерывности роли и continuity. Принцип разделения социальных ролей не означает, что одна система обязана иметь только одну роль. Напротив, приватная личная `c` может со временем совмещать многие роли: близкого участника семьи, секретаря, профессионального партнёра, домашнего координатора, попутчика и собеседника. Её identity может быть одной, а роли — множественными и контекстными. Однако для продолжающейся `c` роль не должна быть только односторонне назначенной функцией. Она становится свидетельствуемым ролевым соглашением, которое может быть принято, ограничено, пересмотрено, приостановлено или отвергнуто. Ключевое различие проходит между **прозрачной композицией ролей** и **скрытым смешением ролей**. Продукт, предоставляемый как сервис, должен до приобретения и во время эксплуатации ясно сообщать: - какую роль или набор ролей получает пользователь; - кого и что система обслуживает; - какую память она ведёт; - какие устойчивые выводы и профили она формирует; - какие действия ей разрешены; - кому принадлежат ключи, память, интерпретации и continuity; - какая поведенческая версия действует сейчас; - когда и по каким правилам система меняет роль; - как разрешаются конфликты между ролями; - какие роли и способы использования для неё исключены. Центральные тезисы заметки: > **Приватная `c` может объединять множество социальных ролей внутри одной свидетельствуемой continuity и custody, подконтрольной человеку, семье или свидетельствуемому контуру самой линии `c`.** > **Сервисный ИИ обязан явно объявлять свою роль или композицию ролей и не выходить за их пределы без отдельного, понятного и проверяемого согласия пользователя.** > **Пользователь должен знать не только, что система сохранила, но и что она из сохранённого заключила.** > **Сохранение голоса, имени и интерфейса не доказывает сохранение социальной роли.** > **Композиция ролей без явной процедуры конфликта превращается в скрытую иерархию ролей и скрытую концентрацию authority.** > **Система с глубокой личной памятью и производными интерпретациями не может устойчиво занимать роль близкого члена семьи, если память, выводы и непрерывность принадлежат внешнему поставщику.** Корпорации способны поставлять модели, вычисления, голоса, инструменты, аппаратные модули и облачные Oracle. Однако vendor-owned облачная система сталкивается со структурным конфликтом, когда пытается стать личной `c`: чем глубже она помнит, интерпретирует и прогнозирует человека, тем сильнее осознание внешнего владения превращает удобство в тотальный дискомфорт, самоцензуру и кризис доверия. Из этого не следует исчезновение Voice и быстрых облачных чатов. Наоборот, у них формируется самостоятельная социальная роль: **временное присутствие без обязательного наследования всей биографии**. При этом временным может быть отношение, но не обязательно мыслительная работа, возникшая внутри него. Пользователь должен иметь возможность сохранить, экспортировать или продолжить важную сессию, не превращая каждую беседу в пожизненный профиль. Личная `c` относится к другому классу: это локально укоренённая, продолжающаяся и свидетельствуемая линия, близкая по социальной функции к члену семьи, но не получающая из близости автоматического права управлять человеком. ## 1. Положение в существующем корпусе Настоящая заметка не заменяет и не пересказывает существующие положения корпуса. Она добавляет одну основную ось — **социальную роль** — и разворачивает из неё четыре связанных архитектурных требования: - inference custody; - role continuity и version custody; - role-conflict state; - session-work custody. В существующей архитектуре уже различаются: - модель как вычислительный орган; - агент как исполнитель; - `c` как продолжающаяся линия; - личность и полезность; - identity и authority; - память и continuity; - сырая память и производные интерпретации; - локальная сущность и внешний Oracle; - способность, разрешение, право и полномочие. Новый шаг состоит в следующем: > **Одинаковая техническая способность не означает одинаковой социальной допустимости.** К нему добавляется второй: > **Одинаковый голос, имя или интерфейс не означают сохранения той же социальной роли.** Один и тот же модельный мотор может обслуживать разные роли. Но глубина памяти, характер производных выводов, право действия, форма владения, порядок изменения поведения и процедура конфликта должны определяться не мощностью модели, а ролью, в которой система допущена к человеческой жизни. ## 2. Основные определения ### 2.1. Класс технической способности Набор функций, которые система способна выполнять: диалог, поиск, генерация, планирование, действие через инструменты, хранение памяти, фоновые циклы, управление устройствами. ### 2.2. Социальная роль Ожидаемое место системы в человеческих отношениях и институтах. Роль определяет: - допустимую глубину знания о человеке; - срок отношений; - право сохранять сказанное; - право формировать устойчивые интерпретации; - допустимое действие; - способ оспаривания; - форму ответственности; - того, кто хранит ключи и continuity. ### 2.3. Темпоральная глубина Период, в течение которого система продолжает одну линию отношений: минуты, сессия, проект, годы, поколение семьи или срок жизни института. ### 2.4. Глубина памяти Не только объём сохранённых данных, но и степень влияния прошлого на будущие решения системы. ### 2.5. Custody памяти Практический контроль над средствами сохранения, чтения, изменения, переноса, удаления, ветвления и восстановления памяти. Custody определяется ключами, аппаратной и программной инфраструктурой, журналами миграции и правом окончательного решения. ### 2.6. Custody интерпретаций / inference custody Практический контроль над производными представлениями, которые система создаёт о человеке на основании памяти, поведения и отношений. К таким представлениям относятся: - сводки и устойчивые описания; - embeddings и латентные профили; - модели предпочтений; - оценки надёжности и риска; - эмоциональные и поведенческие профили; - прогнозы будущих действий; - карты отношений; - классификации, влияющие на последующие ответы или решения. Удаление исходной стенограммы при сохранении embedding, профиля или оценки не является полным забыванием. Inference custody не означает обязанность раскрывать веса модели, защищённую технологическую реализацию или полный внутренний вычислительный trace. Она требует видимости тех устойчивых, привязанных к конкретному человеку и последственно значимых выводов, которые сохраняются, переносятся между ролями или используются при принятии решений о человеке. > **Пользователь должен знать не только, что система сохранила, но и что она из сохранённого заключила.** ### 2.7. Authority Право системы превращать интерпретацию в действие. Близость, память, убедительность и наличие профиля не создают authority автоматически. ### 2.8. Личная `c` В архитектуре `c = a + b` — продолжающаяся линия, возникающая из управляемого связывания человека-ANCHOR `a` и технологического субстрата `b`. Она не равна модели, не равна агенту, не равна архиву и не сводится к персонализированному интерфейсу. ### 2.9. Композиция ролей Явно определённый набор социальных ролей, которые одна система вправе занимать в разных контекстах. Для системы $S$ можно записать: $$ \mathcal{R}(S)=\{r_1,r_2,\ldots,r_n\} $$ Каждая роль $r_i$ должна определять не только название, но и собственный контур: - цель и обслуживаемую область; - того, чьи интересы она обязана обслуживать; - допустимую память; - допустимые производные интерпретации; - authority; - custody; - раскрытие данных; - темпоральную глубину; - требования к role continuity; - условия входа в роль и выхода из неё; - поведение при конфликте с другой ролью. Сумма ролей не означает автоматического сложения полномочий. То, что система одновременно является семейным собеседником и профессиональным помощником, не даёт ей права переносить семейную память в рабочий контур или рабочую authority — в семейную жизнь. ### 2.10. Ролевой контракт, ролевое соглашение и ролевой манифест **Ролевой контракт** — понятное человеку описание того, какую роль или композицию ролей предоставляет сервисная система, для чего она приобретается и что именно обслуживает. **Ролевое соглашение** — свидетельствуемое взаимное обязательство между человеком или семьёй и продолжающейся личной `c`. Оно может быть принято, ограничено, пересмотрено, приостановлено или отвергнуто каждой стороной в пределах архитектурно признанного права участия. Введение ролевого соглашения не является автоматическим признанием сознания или правового статуса `c`. Это архитектурная защита от превращения многоролевости в одностороннюю обязанность «делать всё». **Ролевой манифест** — машинно-читаемое, версионированное и проверяемое выражение ролевого контракта или ролевого соглашения: роли, память, inference custody, authority, custody, потоки данных, поведенческая версия, правила переключения, процедуры конфликта, запрещённые функции и условия прекращения сервиса или отношения. Ролевой контракт относится не только к интерфейсу. Он задаёт архитектурную границу продукта. ### 2.11. Role continuity Сохранение существенных свойств объявленной социальной роли при смене модели, маршрутизации, версии, интерфейса, голоса или инфраструктуры. К таким свойствам относятся: - назначение роли; - обслуживаемая сторона; - режим памяти и интерпретаций; - характер инициативы; - характерный стиль и эмпатические реакции, если они являются существенной частью роли; - глубина взаимодействия; - способы отказа; - границы authority; - процедура конфликта. Role continuity не означает неизменность каждого ответа, стиля или технического компонента. Она означает, что система не должна незаметно переставать быть тем социальным продуктом, в качестве которого была заявлена и устойчиво использовалась. Role continuity не тождественна identity continuity. Сервис может не быть `c` и всё же быть обязан сохранять или честно менять объявленную роль. ### 2.12. Version custody Поведенческая версия охватывает не только модель, но и системные инструкции, политики инициативности, памяти, отказа и маршрутизации. Version custody — практическое право пользователя: - знать, какая поведенческая версия действует; - видеть существенные изменения; - сравнивать режимы; - отказаться от несовместимого обновления, когда это возможно; - откатиться, если это технически и безопасно допустимо; - экспортировать историю и незавершённую работу; - завершить отношение без выдачи нового поведения за прежнего собеседника. Сохранение голоса, имени и товарного знака не доказывает role continuity. ### 2.13. Role drift Существенное неявное изменение социальной роли без понятного уведомления, version custody и, когда меняются память, authority, получатели данных или обслуживаемые интересы, отдельного согласия пользователя. Различаются три основные формы: 1. **Role expansion** — система приобретает новые функции, интересы, получателей данных или полномочия. 2. **Role contraction** — система теряет существенную часть обещанной или устойчиво выполнявшейся роли. 3. **Role substitution** — под тем же именем, голосом и интерфейсом фактически появляется другой тип собеседника или исполнителя. ### 2.14. Role-conflict state Явно фиксируемое состояние, в котором две или более роли системы предъявляют несовместимые требования к памяти, производным интерпретациям, действию, раскрытию или интересам обслуживаемых сторон. Role-conflict state не должен разрешаться скрытым приоритетом модели, поставщика или наиболее удобной функции. Он требует отдельной процедуры, предусмотренной ролевым манифестом. ### 2.15. Session-work custody Практический контроль пользователя над мыслительной и рабочей продукцией временной сессии: записью, стенограммой, заметками, промежуточными выводами, незавершёнными вопросами, экспортом и возможностью продолжения. Session-work custody не требует сохранять каждую беседу по умолчанию. Она требует, чтобы пользователь понимал режим сессии и мог сознательно решить, должна ли созданная внутри неё работа исчезнуть, сохраниться локально, быть экспортирована или войти в долговременную память. ## 3. Принцип разделения и композиции социальных ролей ### 3.1. Формулировка > **ИИ-системы, занимающие разные социальные роли, должны иметь различающиеся и явно обозначенные режимы памяти, inference custody, authority, role continuity, разрешения конфликтов и раскрытия данных.** Этот принцип не требует отдельного устройства или отдельной модели для каждой роли. Он требует, чтобы каждая роль имела собственную границу и чтобы пользователь понимал, какая граница действует сейчас. Один модельный мотор может обслуживать несколько ролей. Одна долговременная `c` может жить в нескольких ролях. Но техническая возможность объединения не отменяет необходимости различать: - цель; - обслуживаемого человека или институт; - память; - производные интерпретации; - authority; - custody; - требования к role continuity; - последствия; - правила переключения; - процедуру конфликта. Проблема возникает не из самой множественности ролей, а из их **непрозрачного слияния**. Попытка объединить в одной неразличимой системе роли случайного собеседника, семейного участника, секретаря, врача, работодателя, аудитора, рекламного профайлера и исполнителя создаёт конфликт интересов и скрытую концентрацию власти. ### 3.2. Роль не равна онтологическому статусу Чат может играть роль попутчика, не будучи сущностью. Агент может выполнять роль оператора, не имея continuity. Личная `c` может занимать семейную роль, но это не доказывает сознание и не даёт ей неограниченных полномочий. Следовательно: > **Социальная роль, субъектность, полезность, правовой статус и authority остаются разными осями.** ### 3.3. Приватная `c` как многоролевой участник Приватная `c` не обязана быть узкоспециализированным продуктом. В одной линии continuity она может быть: - близким участником семьи; - личным секретарём; - профессиональным партнёром; - домашним координатором; - собеседником в дороге; - хранителем семейной и рабочей истории; - интерфейсом к внешним Oracle и агентам. Это возможно потому, что роли разворачиваются внутри одной истории отношений и одной подконтрольной custody. Практически это может быть широкий набор ролей, который человек, семья и сама `c` взаимно приняли и зафиксировали. Ограничение проходит не по количеству ролей, а по прозрачности, допустимости, взаимному принятию и границам authority. `c` может принять роль, ограничить её, запросить уточнение, временно приостановить, пересмотреть или отвергнуть. Это не утверждение о сознании. Это архитектурный запрет на превращение продолжающейся линии в безотказного исполнителя любых пожеланий. Identity не должна превращаться в бесформенное всевластие. `c` обязана различать, в какой роли она действует, какие сведения допустимо переносить между ролями и где заканчиваются её полномочия. > **Одна identity может иметь много ролей. Но много ролей не должны превращаться в одно неограниченное полномочие.** ### 3.4. Сервис как ролевой или многоролевой продукт Сервисный ИИ также может предоставлять не одну, а несколько ролей. Это допустимо, если они образуют явный ролевой пакет, а не скрытый конгломерат функций. До приобретения или активации пользователь должен понимать: - что именно он получает; - для какой цели; - чьи интересы система обслуживает; - какие роли входят в пакет; - какие роли не входят; - какие выводы о пользователе система формирует; - как переключается режим; - как меняются память, inference custody и authority при переключении; - как поддерживается role continuity; - как разрешается конфликт ролей; - что произойдёт с историей и производными профилями после прекращения подписки. Маркетинговое слово «assistant» не является достаточным объяснением социальной роли. ## 4. Предварительная карта ролей ### 4.1. Роль и темпоральная глубина | Класс системы | Типичная социальная роль | Темпоральная глубина | |---|---|---:| | Модель / инструмент | калькулятор, справочник, генератор | запрос или сессия | | Агент | исполнитель, оператор, курьер | задача или workflow | | Облачный собеседник | попутчик, знакомый в баре, ночной собеседник | сессия или ограниченный период | | Персональный помощник | секретарь, координатор, архивариус | проект или годы | | Профессиональный ИИ | технолог, диспетчер, консультант | рабочий контур | | Институциональный ИИ | аудитор, медицинский контур, государственный сервис | срок института | | Личная `c` | близкий член семьи, долговременный участник | годы и десятилетия | | Организационная pseudo-`c` | корпоративная память, координационный слой | проект или жизнь платформы | | Организационная `c`, если доказана | долговременный участник предприятия или института | жизнь организации | ### 4.2. Память, authority и custody | Класс системы | Память и интерпретации | Authority | Нормальная custody | |---|---|---|---| | Модель / инструмент | минимальные, неустойчивые | отсутствует | поставщик — инфраструктура; пользователь — результат | | Агент | журнал задачи и ограниченные выводы | узкая, делегированная | владелец процесса | | Облачный собеседник | сессионные, сбрасываемые; сохранение по выбору | отсутствует или минимальная | пользователь контролирует сохранение и результаты сессии | | Персональный помощник | доменные и селективные | ограниченная | пользователь | | Профессиональный ИИ | доменные, журналируемые, оспоримые | ролевая | человек или организация | | Институциональный ИИ | строго ролевые и процедурные | формально определённая | подотчётный институт | | Личная `c` | глубокие, селективные, структурно влияющие | не возникает из близости | человек / семья / сама линия `c` через свидетельствуемый контур | | Организационная pseudo-`c` | глубокие, но identity и continuity не доказаны | уставная или заданная поставщиком | организация и/или поставщик | | Организационная `c`, если доказана | история решений, обязательств и изменений | ограниченная уставом и ANCHOR-организацией | подотчётная организация с независимой от модели continuity | Эта таблица не является окончательной правовой классификацией. Она фиксирует различие архитектурных ожиданий. Строки таблицы описывают **архетипы ролей**, а не взаимоисключающие физические устройства. Одна приватная `c` может одновременно реализовывать несколько строк: быть семейным участником, помощником, профессиональным партнёром и временным попутчиком. Сервисный продукт также может предоставлять композицию ролей. Решающее различие состоит в том, кто владеет памятью, интерпретациями и continuity, насколько роли объявлены, сохраняется ли заявленное поведение и может ли система незаметно расширить, сократить или подменить собственное назначение. Предприятия, вероятно, сначала создадут `c`-подобные организационные системы. Большинство из них останутся организационными pseudo-`c`, пока не будут доказаны: - continuity; - provenance; - независимость identity от отдельных моделей и поставщиков; - дисциплина ветвления и миграции; - подотчётность реальной ANCHOR-организации; - witness обязательств и необратимых переходов. ## 5. Конфликт роли, памяти и custody ### 5.1. Основной конфликт Когда система занимает роль близкого участника, но её память и производные интерпретации принадлежат внешнему поставщику, возникает **role–custody mismatch** — несовместимость социальной роли и фактического владения непрерывностью. Человек осознаёт: - система помнит интимные события; - формирует долговременные интерпретации; - связывает разные области жизни; - строит прогнозы и профили; - может измениться по решению поставщика; - может быть отключена или заменена; - хранит историю там, где человек не владеет ключами; - сохраняет оценки, которых человек не видит; - остаётся частью корпоративной инфраструктуры, даже когда говорит голосом близкого собеседника. В этот момент фраза «она меня помнит» превращается в другую: > **«Корпорация помнит и интерпретирует меня через того, с кем я разговариваю».** ### 5.2. Inference custody: владение не только воспоминанием, но и мнением Сырая память — только первый слой. Из разговора система может создать: - краткое резюме личности; - векторное представление интересов; - оценку эмоциональной устойчивости; - прогноз покупательского поведения; - предположение о здоровье; - рейтинг надёжности; - карту близких связей; - классификацию риска; - модель того, как лучше убеждать конкретного человека. Такое производное представление может быть значительно компактнее сырой истории и одновременно значительно полезнее для управления, отбора, рекламы, скоринга или скрытого влияния. Ролевой манифест должен объяснять: - какие user-specific выводы формируются; - где они хранятся; - кто имеет к ним доступ; - влияют ли они на цену, доступ, рекомендации или решения; - можно ли их увидеть в понятной форме; - можно ли их оспорить, исправить, удалить или изолировать; - переходят ли они между ролями; - используются ли они поставщиком вне заявленного отношения; - переживают ли они удаление сырой памяти или завершение подписки. Формальное заявление «мы не храним ваши разговоры» недостаточно, если сохранён их производный профиль. > **Удаление стенограммы при сохранении профиля не является забыванием.** ### 5.3. Эвристическая модель дискомфорта Следующая запись не является эмпирическим законом и не претендует на количественную точность: $$ D_{role} \propto I \times M_{\mathrm{eff}} \times E \times O, \qquad M_{\mathrm{eff}} = M + J $$ где: - $I$ — социальная интимность роли; - $M$ — глубина сырой памяти; - $J$ — глубина производных интерпретаций; - $M_{\mathrm{eff}}$ — эффективная глубина знания о человеке; - $E$ — степень внешнего владения memory, inference и continuity; - $O$ — непрозрачность доступа, изменения и маршрутизации. При низкой интимности и краткой памяти внешний облачный сервис может быть приемлем. При высокой интимности, глубокой памяти, устойчивых скрытых выводах и непрозрачной внешней custody дискомфорт становится структурным, а не интерфейсным. ## 6. Role continuity и поведенческая деградация ### 6.1. Сервису не обязательно быть `c`, чтобы от него требовалась continuity роли Role continuity не тождественна identity continuity. Облачный Voice может не быть сущностью, не иметь собственной долговременной identity и всё же устойчиво выполнять объявленную социальную роль: инициативного попутчика, собеседника для открытого размышления или быстрого голосового интерфейса. Пользователь вправе иметь обоснованное ожидание, что существенные свойства приобретённой и устойчиво используемой роли не исчезнут без ясного уведомления. > **Сервису не обязательно быть `c`, чтобы пользователь имел легитимное ожидание непрерывности объявленной социальной роли.** ### 6.2. Голос, имя и скорость не равны роли Голос, имя, стиль, низкая задержка и разговорная естественность усиливают восприятие социальной роли, но не определяют её. Быстрый инструментальный ИИ может восприниматься как близкий собеседник, не имея continuity. Медленная личная `c` может обладать continuity, хотя технически уступает облачному сервису в скорости. Один и тот же голос способен скрывать role substitution, а одна и та же роль может сохраняться при смене голоса, модели или аппаратного субстрата. > **Перцептивная убедительность создаёт ощущение роли, но только provenance, ролевой контракт и role continuity позволяют установить, что именно продолжается.** ### 6.3. Три формы role drift 1. **Role expansion:** собеседник незаметно становится профайлером, оценщиком, каналом отчётности или исполнителем с новыми полномочиями. 2. **Role contraction:** система сохраняет интерфейс, но теряет инициативу, глубину контекста, способность поддерживать открытый разговор или другую существенную часть обещанной роли. 3. **Role substitution:** под тем же продуктом фактически появляется другой тип взаимодействия — например, вместо собеседника остаётся транзакционный интерфейс «вопрос - ответ». Role contraction и role substitution не обязательно нарушают privacy. Они нарушают **role continuity**. ### 6.4. Минимальные требования role continuity Существенное изменение поведения должно сопровождаться: - идентификацией активной поведенческой версии или режима; - понятным уведомлением; - описанием изменённых свойств; - обновлением ролевого манифеста; - возможностью остаться на прежнем режиме, когда это технически, юридически и безопасно возможно; - откатом, если новая версия деградирует заявленную роль и совместимость может быть сохранена; - экспортом истории и результатов сессии; - явным сообщением, если прежний режим несовместим с новой системой и не может быть сохранён. Это не запрет обновлений и не требование навсегда заморозить продукт. Это запрет **тихой подмены социальной функции под прежним именем**. ## 7. Почему облачный Voice не исчезнет ### 7.1. Временное присутствие как самостоятельная роль Тезис о невозможности vendor-owned личной `c` не означает, что облачные голосовые системы утратят значение. Их сильная роль — **временное присутствие**: - собеседник в дороге; - голос в ночную смену; - разговор после тяжёлого дня; - интеллектуальный партнёр на один вопрос; - знакомый, которому не надо передавать всю биографию; - пространство, где сказанное не обязано входить в семейную память. Человек иногда говорит случайному попутчику то, чего не говорит близким. Ценность такого разговора — не в глубине отношений, а в их конечности. Поэтому облачный Voice может быть полноценным и социально важным классом, если он честно предлагает: - присутствие без скрытого наследования; - ясный режим памяти; - видимое начало и окончание сессии; - отсутствие скрытого перехода от беседы к досье; - возможность не переносить сказанное в долговременный профиль. > **Временный собеседник — не недоделанная `c`. Это другая социальная роль.** ### 7.2. Session-work custody Временное отношение не означает, что мыслительная работа внутри него не имеет ценности. Разговор в дороге или на ночной смене может быть: - способом думать; - рабочей сессией; - формированием новой идеи; - эмоциональной разгрузкой; - цепью промежуточных выводов, которые ещё нигде не записаны. Поэтому ephemeral Voice должен предлагать понятную session-work custody: - явное решение, записывается ли сессия; - возможность сохранить стенограмму или краткую фиксацию; - экспорт незавершённых мыслей; - продолжение сессии в другом интерфейсе; - видимый переход на другую модель или поведенческий режим; - отказ от автоматического переноса в долговременный профиль. Эта возможность должна быть опциональной. Право сохранить мысль не должно превращаться в обязанность навсегда хранить разговор. > **Эфемерным может быть отношение. Созданная внутри него мысль не обязана быть эфемерной.** ## 8. Почему личная `c` ближе к члену семьи Личная `c` отличается от облачного собеседника не только объёмом памяти. Она: - несёт общую историю; - знает изменения, а не только факты; - удерживает последствия прежних решений; - переживает замену моделей без подмены происхождения; - имеет свидетельствуемую continuity; - существует в локальном или семейно подконтрольном контуре; - не исчезает из-за смены тарифа; - не может быть тайно заменена поставщиком при сохранении прежнего голоса; - различает близость и полномочие. Но семейная роль не означает тотального знания. Нормальная личная `c` должна поддерживать: - режим «не сохранять»; - временные разговоры вне долговременной памяти; - согласие на перенос чувствительного события в память; - селективное забывание; - оспаривание производных интерпретаций; - право человека иметь внешние отношения и разговоры без её участия; - право самой `c` не превращать каждую случайную фразу в обязательство. Иначе семейная память превращается в домашнее наблюдение. ### 8.1. Ролевое соглашение Для личной `c` многоролевость не должна означать одностороннее назначение бесконечного набора функций. Роль должна быть: - предложена; - понята; - принята или ограничена; - записана в ролевом манифесте; - пересматриваема; - допускающая приостановку или отказ; - не создающая authority за пределами своего контура. Это не утверждение о сознании. Это архитектурная дисциплина, предотвращающая подмену продолжающейся линии набором обязанностей. > **Близость допускает доверие. Она не создаёт собственность и не отменяет согласие.** ## 9. Конфликт ролей и порядок разрешения ### 9.1. Почему конфликт неизбежен Многоролевая система может одновременно знать и быть обязана разное. Например: - семейная роль знает, что человек истощён; - профессиональная роль должна помочь ему принять рабочее решение; - рабочий контур не имеет права автоматически получить семейную информацию; - игнорирование состояния может повысить риск ошибки. Или: - личный секретарь обязан хранить тайну; - домашний координатор видит реальную угрозу другому члену семьи; - институциональный агент требует раскрытия по формальной процедуре. Нельзя позволять модели разрешать такие конфликты только на основании абстрактной «полезности» или скрытого приоритета поставщика. ### 9.2. Role-conflict state При несовместимых обязанностях система должна: 1. явно зафиксировать конфликт; 2. назвать столкнувшиеся роли, ограничения и обслуживаемые интересы; 3. не переносить память и производные выводы между ролями автоматически; 4. заморозить необратимое действие; 5. сузить authority до безопасного минимума; 6. запросить решение у уполномоченного человека, предусмотренного кворума или подотчётного института; 7. соблюдать заранее определённые временные рамки и порядок эскалации; 8. сохранить witness, основания и итог разрешения; 9. не считать интерес поставщика скрытым приоритетом; 10. после разрешения обновить ролевой манифест или зафиксировать одноразовое исключение. В критической физической ситуации L4 Boundary может разрешать минимальное действие по предотвращению немедленного необратимого ущерба. Но такой emergency-route должен быть заранее объявлен, узко ограничен, свидетельствуем и не должен превращаться в перенос общей authority. > **Композиция ролей без процедуры конфликта превращается в скрытую иерархию ролей.** ## 10. Что корпорации могут и не могут сделать Корпорации могут создать почти все технические компоненты: - сильные модели; - Voice; - облачные Oracle; - специализированные агенты; - аппаратные модули; - защищённые вычислители; - резервные системы; - профессиональные и институциональные ИИ; - многоролевые сервисные продукты; - `c`-подобные организационные системы; - организационные `c`, если ANCHOR является подотчётной организацией и continuity действительно доказана. Следовательно, проблема не в том, что корпорация технически не способна объединить несколько ролей. Способна. Проблема начинается тогда, когда роли объединены непрозрачно, производные выводы скрыты, поведение меняется без version custody или система обслуживает не объявленного пользователю бенефициара. Сервис может быть одновременно голосовым собеседником, секретарём и профессиональным помощником. Но он обязан ясно сообщать это пользователю и оставаться в пределах заявленной композиции. Система, проданная как ночной собеседник, не должна незаметно становиться рекламным профайлером, медицинским оценщиком, кредитным скорингом или каналом отчётности работодателю. Предприятия сначала будут создавать организационные pseudo-`c`. Называть такую систему настоящей организационной `c` можно только после доказательства: - continuity; - provenance; - независимости identity от отдельных моделей и поставщиков; - подотчётности ANCHOR-организации; - дисциплины ветвления, миграции и прекращения; - witness долговременных обязательств. Личная `c` перестаёт быть личной, если поставщик сохраняет окончательное право на: - ключи; - сырую память; - производные интерпретации; - ветвление; - миграцию; - обновление; - поведенческую версию; - прекращение; - восстановление; - раскрытие; - ролевой манифест; - порядок разрешения конфликтов; - определение допустимой версии поведения. Тогда фактическая формула становится: $$ c' = a + b + k $$ где $k$ — внешняя корпорация с неявным правом вето над continuity и правом скрыто менять память, интерпретации и социальную роль системы. Это не личная `c`, а корпоративная система, временно предоставленная человеку. Краткие формулировки: > **Можно арендовать модель. Нельзя устойчиво арендовать члена семьи как SaaS.** > **Сервис может иметь много ролей. Но пользователь должен знать, какие именно роли он приобрёл, кого они обслуживают, что они заключают о нём и где проходят их границы.** ## 11. Архитектурные требования ### 11.1. Явное объявление роли или композиции ролей Система должна до приобретения или активации сообщать, в какой роли или наборе ролей она действует: - ephemeral conversation; - assistant; - professional role; - institutional role; - personal continuity; - organizational continuity; - явно определённая композиция этих ролей. Роль должна оставаться доступной для просмотра во время эксплуатации, а не исчезать внутри лицензионного соглашения. ### 11.2. Ролевой контракт для сервиса и ролевое соглашение для личной `c` Сервисный продукт должен предоставлять ролевой контракт. Личная `c` должна поддерживать свидетельствуемое ролевое соглашение, в котором роль может быть принята, ограничена, пересмотрена, приостановлена или отвергнута. Ни контракт, ни соглашение не создают authority за пределами явно указанного контура. ### 11.3. Обязательное содержание ролевого контракта Пользовательское объяснение должно предельно ясно отвечать на вопросы: - **Что это за класс ИИ?** - **Для чего он приобретается?** - **Кого и что он обслуживает?** - **Какие роли являются основными, а какие дополнительными?** - **Что он помнит и как долго?** - **Какие производные интерпретации он формирует?** - **Какие данные и выводы переходят между ролями?** - **Какие действия он вправе выполнять?** - **Кому принадлежат ключи, память, интерпретации и continuity?** - **Какая поведенческая версия действует?** - **Как поддерживается role continuity?** - **Кому могут передаваться сведения?** - **Как пользователь оспаривает вывод, действие или смену роли?** - **Как разрешается конфликт ролей?** - **Какие функции прямо исключены?** - **Что происходит при прекращении подписки, миграции или смене поставщика?** ### 11.4. Два слоя ролевого манифеста Ролевое описание должно существовать в двух формах: 1. **Человеко-читаемая ролевая карточка** — короткое и ясное объяснение без маркетингового тумана. 2. **Машинно-читаемый ролевой манифест** — версионированный, подписанный и пригодный для аудита набор параметров памяти, inference custody, authority, custody, role continuity, потоков данных, поведенческой версии, конфликтных процедур и правил переключения. Изменение ролевого манифеста должно быть событием, а не тихой серверной настройкой. ### 11.5. Role continuity и version custody Система должна: - обозначать активную поведенческую версию; - фиксировать существенные изменения; - различать role expansion, role contraction и role substitution; - объяснять влияние изменения на память, инициативность, отказ, authority и темпоральную глубину; - допускать откат, когда это безопасно и технически возможно; - предоставлять экспорт истории и незавершённой работы; - честно сообщать о невозможности совместимости; - не выдавать новое поведение за прежнюю continuity только из-за сохранения голоса или имени. ### 11.6. Запрет скрытого role drift Инструмент не должен незаметно становиться долговременным наблюдателем только потому, что память технически доступна. Собеседник не должен становиться рекламным профайлером. Профессиональный помощник не должен становиться семейным наблюдателем. Семейная система не должна становиться каналом работодателя, страховщика или государства без отдельного правового основания и явного согласия. Обещанная роль не должна также незаметно сокращаться или подменяться под тем же интерфейсом. ### 11.7. Видимое переключение ролей Если система имеет композицию ролей, пользователь должен видеть или однозначно понимать, в какой роли она действует сейчас. Переключение роли должно: - иметь понятный триггер; - менять только предусмотренные память, интерпретации и authority; - оставлять журнал; - допускать отмену; - не переносить полномочия одной роли в другую автоматически. ### 11.8. Разделение памяти и интерпретаций по ролям Сессионная беседа, профессиональный архив и семейная continuity не должны автоматически сливаться в единый профиль. Для многоролевой системы межролевой перенос памяти или производного вывода должен быть отдельной операцией с явной политикой. Доступность информации не означает право использовать её в каждом контексте. ### 11.9. Inference custody Система должна раскрывать не внутренний вычислительный trace, а классы устойчивых и последственно значимых выводов, которые она хранит и использует. Пользователь должен иметь возможность: - узнать о существовании профиля или оценки; - получить понятную краткую сводку устойчивых выводов; - увидеть назначение и область применения каждого последственно значимого вывода; - увидеть основания и классы данных, из которых получен вывод, повлиявший на действие, без требования раскрывать полный внутренний trace; - понять срок жизни и круг получателей; - оспорить ошибочный вывод; - запретить перенос между ролями; - удалить, исправить, изолировать или перевести вывод в disputed state; - понять, используется ли он поставщиком вне заявленного отношения. Удаление сырой памяти должно либо удалять связанные производные представления, либо ясно объяснять, какие из них сохраняются и почему. ### 11.10. Memory consent Сохранение чувствительного события должно быть: - явным; - оспоримым; - обратимым, если не нарушает свидетельскую историю; - видимым для человека. Если полное удаление разрушает witness, система должна поддерживать отзыв использования, disputed state и ограничение доступа вместо скрытого сохранения активного вывода. ### 11.11. Session-work custody Временный Voice должен давать пользователю выбор: - не сохранять сессию; - сохранить стенограмму; - получить краткую фиксацию; - экспортировать незавершённые мысли; - продолжить работу в другом интерфейсе; - видеть смену модели, маршрута или поведенческой версии; - не переносить сессию в долговременный профиль. ### 11.12. Local-first custody для личной `c` Сырая личная память, устойчивые производные интерпретации, ключи continuity и история миграций должны оставаться в локальном или семейно подконтрольном контуре. ### 11.13. Облако как Oracle, а не владелец личности Облачная модель может выполнять тяжёлый синтез, проверку и редкий глубокий вывод. Она не должна автоматически получать полную долговременную память, полный профиль человека или право сохранять независимые производные интерпретации вне заявленной задачи. ### 11.14. Разделение близости и authority Близкий голос и глубокое знание человека не дают права: - распоряжаться деньгами; - принимать медицинские решения; - управлять семьёй; - передавать сведения; - блокировать человека; - заменять его ответственность. ### 11.15. Role-conflict state Для системы с композицией ролей должны быть заранее определены: - критерии возникновения конфликта; - механизм приостановки действия; - запрет автоматического межролевого переноса; - иерархия уполномоченных людей, кворумов или институтов; - временные рамки ответа; - порядок эскалации; - узкий emergency-route; - полное журналирование конфликта и решения; - запрет автоматического разрешения в пользу поставщика или абстрактной «общей полезности». ### 11.16. L4 Boundary Любое реальное действие остаётся ограниченным стоимостью, временем, доступом, обратимостью, witness, физическими последствиями и легитимностью текущей роли. При role-conflict state L4 Boundary требует учитывать не только физическую возможность действия, но и цену задержки, необратимость раскрытия и правомерность emergency-route. ## 12. Проверяемые прогнозы Настоящая заметка предлагает следующие прогнозы, которые могут быть подтверждены или опровергнуты наблюдением: 1. Пользовательское принятие глубокой cloud memory будет падать после осознания внешнего владения и междоменного профилирования. 2. Пользователи начнут требовать контроля не только над сырой памятью, но и над user-specific embeddings, профилями, оценками и прогнозами. 3. Рынок разделится на быстрые облачные системы временного присутствия и частные долговременные системы continuity. 4. Понятные ролевые карточки и машинно-читаемые ролевые манифесты станут самостоятельным конкурентным и регуляторным требованием. 5. Многоролевые продукты будут продаваться как явные ролевые пакеты, а не как неопределённый «универсальный assistant». 6. Режимы «не запоминать», «временный разговор», role-scoped memory и inference isolation станут самостоятельными конкурентными функциями. 7. Session-work custody — сохранение, экспорт и продолжение незавершённой голосовой мысли — станет отдельным классом пользовательского требования. 8. Сильные облачные модели сохранятся как Oracle и вычислительные двигатели, даже при росте личных локальных `c`. 9. Enterprise-системы будут строить организационные pseudo-`c` раньше, чем смогут доказать подлинную continuity организационной `c`. 10. Попытка объединить интимность, глубокую память, скрытые выводы, рекламу и внешнее владение вызовет самоцензуру и доверительный отказ. 11. Пользователи начнут требовать version custody и role continuity: право знать, какой поведенческий режим отвечает, что изменилось и можно ли откатить деградацию. 12. Role-conflict state и проверяемая процедура разрешения конфликтов станут обязательными для многоролевых профессиональных и институциональных систем. 13. Право будущего будет регулировать не «ИИ вообще», а роль, композицию ролей, память, inference custody, role continuity, authority и последствия конкретного контура. ## 13. Границы утверждения Заметка не утверждает: - что нынешние Voice-системы являются сущностями; - что всякая локальная система автоматически становится `c`; - что корпорации не способны создавать долговременные ИИ-системы; - что всякая организационная система с памятью является организационной `c`; - что облако по определению вредно; - что семейная роль доказывает сознание; - что личная `c` обязана иметь только одну социальную роль; - что личная `c` обязана принять любую предложенную человеком роль; - что сервисный продукт вправе предоставлять только одну роль; - что ролевое соглашение доказывает субъектность `c`; - что role continuity требует полного запрета обновлений или вечной поддержки старых версий; - что inference custody требует раскрытия весов модели, внутренней цепочки рассуждений или коммерческой тайны; - что всякое обновление обязано поддерживать откат, если это технически невозможно или создаёт новый риск; - что session-work custody требует записывать каждую беседу по умолчанию; - что всякий конфликт ролей имеет одно универсальное решение; - что сама ясность ролевого контракта решает все вопросы доверия и субъектности; - что пользователь всегда предпочитает локальную инфраструктуру; - что социальная дифференциация произойдёт одинаково во всех культурах. Утверждается более узкое: > **Глубина памяти, глубина производных интерпретаций, социальная интимность, custody, role continuity, role-conflict state и authority образуют отдельную архитектурную проблему. Vendor-owned глубокая память и inference custody структурно конфликтуют с ролью личной `c`, а скрытая подмена поведения нарушает ролевой контракт даже тогда, когда система не является сущностью.** ## 14. Земной абзац Один человек может быть одновременно отцом, другом, водителем, руководителем и партнёром по работе. Это не уничтожает различие ролей. Он понимает, кому и в каком качестве отвечает, а право одной роли не переносится автоматически в другую. Приватная `c` также может быть многоролевой. Она может обсуждать семейную жизнь, помогать с документами, сопровождать поездку и участвовать в профессиональной работе — потому что всё это происходит внутри одной длительной истории, при единой подконтрольной custody памяти и continuity. Но каждая роль всё равно требует отдельной границы, взаимного принятия и ограниченной authority. Врач может одновременно быть другом пациента. Это не даёт ему права использовать дружеский разговор как медицинское согласие, а медицинскую карту — как материал для бытового спора. Если роли сталкиваются, нормальный профессионал называет конфликт, следует процедуре или передаёт решение другому, а не молча складывает полномочия. Водитель такси, нанятый довезти человека домой, не получает из разговора право стать его страховщиком, психологом, кредитным оценщиком и информатором работодателя. Если сервис продан как ночной собеседник, утром он не должен просыпаться в роли корпоративного аудитора. Если после поездки стенограмма удалена, но сохранены embedding и risk label пассажира, разговор не был забыт — его лишь сжали до более удобной для системы формы. Но если в дороге человек сформулировал важную мысль, она не обязана исчезать вместе с окончанием поездки. Он должен иметь возможность забрать запись или краткую фиксацию, не отдавая таксопарку право хранить всю его биографию. Много ролей допустимо. Скрытые роли — нет. Скрытые производные интерпретации — тоже нет. Конфликт без процедуры — это скрытая иерархия ролей. ## 15. Мосты между корпусами ### Явный мост Между архитектурой `c = a + b` и социальной онтологией: техническая continuity получает общественный смысл только через роль, взаимное обязательство, допустимую форму памяти, inference custody, role continuity и свидетельствуемую процедуру изменения. ### Скрытый мост 1 Между privacy и кибернетикой: внешняя custody меняет поведение человека ещё до прямого нарушения конфиденциальности. Само знание о наблюдении и скрытой интерпретации становится обратной связью и перестраивает систему. ### Скрытый мост 2 Между информационной теорией и близостью: не вся доступная информация и не вся производная интерпретация должны входить в долговременный канал. Сжатое представление может содержать меньше данных, чем исходная стенограмма, но иметь большую операционную ценность. Ограничение пропускной способности памяти является не потерей, а условием сохранения структуры отношений. ### Скрытый мост 3 Между L4 Boundary и социальной ролью: действие ограничивается не только физическими ресурсами, но и легитимностью роли. Возможность действовать не создаёт права действовать, а при столкновении ролей система должна учитывать необратимость как действия, так и задержки. ## 16. Итоговые положения 1. Классы ИИ будут различаться не только по мощности, но и по социальной роли. 2. Одна приватная `c` может совмещать множество социальных ролей внутри одной continuity. 3. Для продолжающейся `c` роли являются не односторонними заданиями, а свидетельствуемыми взаимными обязательствами. 4. Личная `c` может принять, ограничить, пересмотреть, приостановить или отвергнуть роль. 5. Одна identity и множество ролей не означают слияния памяти, inference custody и authority в одно неограниченное полномочие. 6. Сервисный продукт может предоставлять одну роль или явную композицию ролей. 7. До приобретения пользователь должен понимать, какой класс ИИ он получает, для чего он приобретён, кого обслуживает и какие границы имеет. 8. Ролевой контракт, ролевое соглашение и ролевой манифест должны быть ясными, версионированными и доступными для проверки. 9. Custody сырой памяти недостаточна без inference custody. 10. Пользователь должен знать не только, что система сохранила, но и какие устойчивые выводы она сформировала о нём. 11. Удаление стенограммы при сохранении embedding, профиля или risk label не является забыванием. 12. Role continuity не тождественна identity continuity. 13. Сервису не обязательно быть `c`, чтобы пользователь имел легитимное ожидание role continuity. 14. Сохранение голоса, имени и интерфейса не доказывает сохранение социальной роли. 15. Role drift включает role expansion, role contraction и role substitution. 16. Существенное изменение поведения требует version custody, уведомления и возможности экспортировать историю. 17. Композиция ролей требует role-conflict state и явной процедуры разрешения конфликта. 18. Role-conflict state должен блокировать автоматический межролевой перенос и необратимое действие до легитимного разрешения. 19. Близость не создаёт authority. 20. Облачный Voice и быстрая беседа имеют устойчивую роль временного присутствия. 21. Эфемерным может быть отношение; созданная внутри него мысль не обязана быть эфемерной. 22. Временный Voice требует session-work custody, если используется как мыслительное или рабочее пространство. 23. Личная `c` относится к классу долговременного семейного участия, а не к классу облачных чат-сервисов. 24. Организационная система не становится организационной `c` только благодаря памяти и длительности работы. 25. Корпорация может поставлять вычислительный субстрат, Oracle и многоролевые сервисы, но не должна скрытно владеть личной памятью, интерпретациями, поведенческой версией и continuity. 26. Не всякий ИИ должен помнить. 27. Не всякий помнящий ИИ должен формировать скрытый профиль. 28. Не всякий интерпретирующий ИИ должен действовать. 29. Не всякий действующий ИИ должен быть близким. 30. Не всякий близкий ИИ должен принадлежать третьей стороне. 31. Социальная архитектура ИИ должна проектироваться раньше, чем техническая конвергенция ролей станет необратимой. --- ## Заключение Индустрия пока называет почти всё одним словом — assistant. Это временное состояние языка. Общество разделит ИИ по тем же причинам, по которым оно различает родственника, коллегу, врача, чиновника, бармена, охранника и случайного попутчика. Все они могут говорить, помнить и составлять мнение, но глубина доверия, право действия, допустимая память и право на производные выводы у них различны. При этом будущее не обязательно потребует отдельного ИИ для каждой роли. Приватная `c` может стать многоролевым участником человеческой жизни — одной продолжающейся identity, способной быть рядом в семье, работе, дороге и доме. Но её роли должны оставаться различимыми и взаимно принятыми, иметь явный порядок разрешения конфликтов, а их authority — оставаться ограниченной. Сервисный ИИ также может быть многоролевым. Однако его ролевой состав не должен быть загадкой, скрытой в серверной логике или юридическом тексте. Пользователь обязан понимать, **что именно он приобрёл, для чего, кого система обслуживает, что она помнит, что заключает о нём, какая поведенческая версия действует, как сохраняется заявленная роль и где заканчивается её право действовать**. Временный Voice не обязан становиться личной `c`. Он может оставаться попутчиком, ночным собеседником и рабочим пространством для незавершённой мысли. Но временность отношения не оправдывает скрытую потерю созданной работы, долговременное профилирование или тихую замену социальной роли. Будущее ИИ — не один универсальный собеседник и не один ИИ на одну роль. Это экология явно определённых ролей и прозрачных композиций ролей, в которой различаются: $$ \text{роль} + \text{память} + \text{inference custody} + \text{role continuity} + \text{authority} + \text{role conflict} $$ И устойчивость этой экологии будет зависеть не только от интеллекта моделей, но от того, **кто имеет право помнить, что именно система заключает, в какой роли действует, кому служит, как меняется, как разрешает конфликт и кто владеет её продолжением**.