Личный ИИ довольно быстро перестаёт быть только личным. Сначала им пользуется один человек: задаёт вопросы, подключает заметки, настраивает привычный тон, постепенно доверяет ему всё больше контекста. Потом возникает естественная мысль: почему бы не дать доступ ещё кому-то?
Тут удобный помощник внезапно становится задачей про границы. Он уже знает слишком много, чтобы просто открыть общий вход и надеяться на аккуратное поведение. В его контексте могут быть рабочие обсуждения, личные заметки, календарь, история решений и действия, которые разрешены только владельцу.
Я столкнулся с этим, когда захотел оставить одного Jarvis, но дать другому человеку отдельный, сильно ограниченный режим. Изначально задача казалась простой: добавить ещё одного пользователя в список разрешённых и дать ему другую инструкцию. На практике этого оказалось недостаточно.
Когда списка разрешённых пользователей мало
Список разрешённых пользователей отвечает только на один вопрос: кто вообще может войти. Он ничего не говорит о том, куда человек попадёт после входа.
Если два человека обращаются к одному и тому же помощнику, система может узнать обоих и всё равно отправить их в общий контекст. Тогда новый пользователь получает не отдельного ассистента, а тот же Jarvis, который помнит разговоры владельца, знает его привычки и умеет выполнять его команды.
Это похоже на пропуск в офис. Сам факт, что человека пустили через турникет, не означает, что ему автоматически можно заходить во все кабинеты, открывать документы и подписывать что-то от имени директора.
Первый важный вывод для меня был таким: доступ к ИИ и доступ к его возможностям — разные вещи. Их нельзя описывать одной галочкой.
Граница начинается с личности
Чтобы разделить людей, система должна надёжно понимать, кто перед ней. Имя или ник для этого не подходят: их можно изменить, написать с ошибкой или скопировать. Нужна подтверждённая учётная запись, которую канал связи передаёт вместе с каждым сообщением.
Но и здесь легко остановиться слишком рано. Проверить личность — значит только узнать человека. Дальше нужно принять отдельное решение: какой помощник должен ему отвечать, какую память можно подключить и какие действия разрешить.
Я стал рассматривать входящее сообщение как последовательность вопросов:
Кто пишет → куда направить → какой контекст открыть → что разрешить → что запретить
Если хотя бы на один вопрос нет точного ответа, безопаснее остановиться. Для личного ИИ неопределённость не должна превращаться в полный доступ.
Отдельный маршрут, а не другой тон
Самая опасная иллюзия — считать, что отдельной инструкции достаточно. Можно сказать общему помощнику: «с этим человеком не обсуждай личное», но он всё равно остаётся внутри того же пространства. У него уже загружена память владельца, доступны прежние инструменты и сохраняется общий след разговоров.
Я пошёл другим путём: для второго пользователя создал отдельный маршрут. После проверки личности сообщение попадало не в основного Jarvis, а в самостоятельный профиль со своими инструкциями и отдельным рабочим пространством.
Разница здесь принципиальная. Это не один помощник, который старается вспомнить, кому что можно показывать. Это два изолированных режима, которые встречаются только на общем входе.
Основной Jarvis продолжал работать для владельца со всеми привычными возможностями. Ограниченный профиль умел только отвечать в заданных рамках. У него не было доступа к памяти владельца, его файлам и действиям.
Контекст нужно разделять физически
Когда говорят о приватности ИИ, часто представляют фильтр, который должен не дать модели произнести лишнюю фразу. Для меня этого мало. Если чужие данные уже попали в контекст, защита зависит от того, насколько хорошо модель соблюдёт инструкцию в конкретном ответе.
Надёжнее устроить систему так, чтобы лишних данных там не было изначально.
Поэтому отдельному профилю нужны собственная история диалога, собственные инструкции и отдельная память — либо вообще никакой долговременной памяти, если она не нужна. Тогда человек не может случайным вопросом добраться до чужого контекста: этого контекста просто нет в его рабочем пространстве.
Этот принцип оказался полезнее самой конкретной настройки. Не просить ИИ «забыть лишнее», а не передавать ему лишнее. Не надеяться на правильный отказ, а сделать запрещённые данные недоступными на уровне устройства системы.
Разрешения лучше начинать с запрета
Второй важный выбор — откуда строить список возможностей.
Можно дать профилю обычный набор инструментов, а затем запрещать опасное: почту, календарь, файлы, команды, заметки. Но такой список почти всегда неполон. Система развивается, появляются новые функции, и однажды новая возможность может оказаться доступной просто потому, что её забыли добавить в запреты.
Я выбрал обратную модель: по умолчанию не разрешено ничего. Профиль получает только те возможности, которые нужны для его узкой задачи. Если достаточно ответа модели, значит действия, файлы и личная память вообще не подключаются.
Это делает систему менее впечатляющей на демонстрации, зато гораздо предсказуемее в жизни. Ограниченный помощник честно скажет, что не может выполнить действие, вместо того чтобы попытаться воспользоваться полномочиями владельца.
Конфигурация может быть правильной и всё равно ошибаться
Самый полезный урок появился не из удачной настройки, а из первой ошибки.
Я нашёл механизм маршрутизации, заполнил нужное поле, проверил конфигурацию — она была формально валидной. Но сообщение направлялось не по личности пользователя. Система воспринимала значение как идентификатор самого канала, а не человека внутри него.
На бумаге всё выглядело правильно. В реальном Telegram маршрут работал не так, как я ожидал.
Я откатил изменение и проверил путь сообщения целиком: от конкретного собеседника до того профиля, который действительно получил запрос. Только после этого нашёл отдельное правило именно для прямого диалога с подтверждённой учётной записью.
С тех пор я не считаю границы доступа проверенными только потому, что файл настроек принят системой. Нужно убедиться, что один пользователь попадает в свой профиль, другой остаётся в основном, их истории не смешиваются, а запрещённая команда действительно получает отказ.
Как я теперь проверяю доступ
Перед тем как подключить ещё одного человека к личному ИИ, я задаю пять вопросов.
Первый: по какому неизменному признаку система узнаёт человека?
Второй: ведёт ли эта личность в отдельный профиль, а не просто добавляется в общий список?
Третий: какие данные физически доступны этому профилю?
Четвёртый: что он умеет делать и почему каждая возможность ему действительно нужна?
Пятый: что произойдёт с неизвестным пользователем или непонятной командой?
Хороший ответ на последний вопрос обычно звучит скучно: система ничего не сделает и попросит отдельное разрешение. Для безопасности это правильная скука.
Итог
Границы личного ИИ начинаются не с красивого предупреждения в инструкции. Они начинаются с устройства системы: подтверждённая личность, отдельный маршрут, изолированный контекст, минимальные разрешения и запрет по умолчанию.
Для меня это изменило сам взгляд на «общего» помощника. Один интерфейс ещё не означает одного внутреннего пространства. Люди могут обращаться к одному Jarvis и при этом получать разные, изолированные режимы — без смешивания памяти и без доступа к чужим действиям.
Чем больше личного знает ИИ, тем важнее не объяснять ему границы словами, а делать эти границы реальными.