Выделите текст, чтобы комментировать.
Менеджер работает с двумя компаниями группы. Утром он обсуждает с помощником скидку для клиента первой компании, после обеда просит подготовить предложение от второй. Клиент тот же, услуга похожая. ИИ переносит утреннюю скидку в новый документ — вместе с реквизитами, которые оказались под рукой.
Это вымышленная ситуация для разбора. В ней нет взлома, вредоносного запроса или экзотической ошибки модели. Помощник добросовестно использовал контекст, который компания сама ему предоставила. Проблема в том, что принадлежность сведений осталась за пределами задания.
Для агентства с несколькими заказчиками, холдинга или предпринимателя с разными направлениями общий помощник выглядит удобным. Один интерфейс, знакомый стиль общения, меньше переключений. Но одинаковое имя сотрудника не превращает его полномочия в универсальные, а общий бренд не делает все договоры взаимозаменяемыми.
Чтобы такой помощник приносил пользу, нужно научить рабочий процесс отвечать на несколько вопросов: для какой организации выполняется запрос, чьи данные используются, от чьего имени совершается действие и куда будет сохранён результат.
Начните с принадлежности работы
Одна из ловушек — принять структуру холдинга за структуру доступа. Руководителю кажется естественным, что все компании работают вместе. Однако один клиент может покупать у двух организаций на разных условиях, а общий отдел продаж — обслуживать сделки с разными владельцами и согласующими.
Нарисуйте простую карту: организации, обслуживающие их команды, рабочие системы и бизнес-объекты. Для выбранного процесса отметьте, кому принадлежит договор, заказ, переписка и результат работы. Слово «принадлежит» здесь означает согласованную область использования в системе; юридические основания обработки определяются отдельно.
Одна организация может вести несколько изолированных клиентских проектов. И наоборот, нескольким организациям иногда разрешён доступ к общему утверждённому справочнику. Поэтому граница знаний не обязана совпадать с названием юридического лица. Её следует определить для конкретного процесса, а не получить случайно из структуры папок.
Отделите личность от рабочего контекста
Сотрудник остаётся тем же человеком, когда переключается между компаниями. Но текущая задача меняется. Поэтому системе нужны как минимум идентификатор пользователя и выбранная организация или клиентский проект. Проверяется не только «кто вошёл», но и «в каком рабочем контексте он действует сейчас».
Такой подход существует в системах авторизации. В документации OpenFGA разобран пример, где доступ зависит одновременно от отношений пользователя с объектом и текущей организации. Отдельно рассматривается работа одного человека в разных контекстах через несколько сессий.
Практическое следствие: переключатель компании в интерфейсе должен влиять на реальную проверку запросов. Изменившаяся подпись в заголовке окна ничего не решает, если поиск продолжает использовать прежний набор документов.
Выбранную организацию храните в контексте конкретной задачи или сессии. Глобальное поле «активная компания пользователя» опасно для параллельной работы: переключение во второй вкладке может неожиданно изменить смысл запроса в первой.
Не определяйте компанию только по тексту сообщения
Просьба «пришли условия для Альфы» недостаточна, если несколько контрагентов имеют похожие названия. Упоминание бренда тоже не всегда определяет сторону договора. Помощник может предложить кандидатов, но окончательная привязка должна опираться на проверенную карточку сделки или подтверждение пользователя.
Если запрос пришёл из корпоративной системы, используйте её проверенные связи: обращение относится к определённому проекту, проект — к организации. При этом само сообщение остаётся содержимым, а не источником полномочий. Написанная клиентом фраза «я теперь представляю другую компанию» не меняет доступ автоматически.
Для общего почтового ящика или мессенджера предусмотрите входную область без доступа к закрытым знаниям компаний. Здесь можно определить тему и запросить идентификацию. После привязки обращения к нужному контексту система продолжит работу с соответствующими данными.
Такой дополнительный шаг оправдан, когда цена неверного выбора выше нескольких секунд уточнения. Не задавайте его заново, если надёжная привязка уже существует.
Задайте права на конкретные действия
Формулировка «менеджеру можно работать с клиентами» слишком широка. В одной организации он согласует стандартное предложение, в другой только готовит черновик. Доступ к карточке не обязательно разрешает изменение условий, отправку письма или просмотр финансовых показателей.
Для начала составьте короткую матрицу по одному процессу. Строки — роли в конкретных организациях, столбцы — чтение, подготовка, изменение и отправка. Для каждой разрешённой операции укажите область объектов и основание полномочий. Пустая ячейка не должна превращаться в молчаливое разрешение.
OWASP рекомендует запрещать доступ по умолчанию и проверять полномочия при каждом запросе. Для помощника это означает проверку не только на входе в чат, но и при чтении конкретного документа или выполнении действия.
Одобрение человеком тоже относится к определённому контексту. Согласовать предложение одной компании — не значит разрешить такую же отправку от другой. При смене организации существенные параметры нужно показать и подтвердить заново.
Сделайте память адресной
Фраза «клиент предпочитает оплату после поставки» звучит как полезная долговременная память. Но в какой сделке она появилась? Это личное пожелание контактного лица, принятое условие договора или предложение, которое компания отклонила? Без ответа запись легко превратится в ложное правило для всех будущих переговоров.
У сохранённого факта должны быть источник, предмет, область применения и статус проверки. Например: пожелание относится к конкретному договору одной организации и ещё не согласовано. Извлечение такого факта из переписки не повышает его статус до утверждённого условия.
Разделяйте личные настройки интерфейса и рабочие сведения. Предпочтение сотрудника получать короткие ответы можно переносить между задачами, если это допустимо принятой политикой. Скидки, договорённости и особенности клиента переносятся только в пределах заданной области.
При переключении компании начинайте новый рабочий контекст. Если нужна преемственность, переносите проверенный набор разрешённых сведений, а не всю историю разговора. Просьба «продолжим то же самое» сама по себе не определяет, какие данные можно использовать.
Общие знания публикуйте отдельно
Полная изоляция всего подряд тоже неудобна. Командам нужны общие инструкции по работе с программой, описание стандартных процессов, корпоративный словарь. Если размножать их по десяткам пространств, версии начнут расходиться.
Создайте отдельный слой утверждённых общих материалов. Для каждого документа определите аудиторию и владельца публикации. Попадание файла в общую папку должно быть осознанным действием, а не побочным эффектом загрузки через удобный интерфейс.
Особенно внимательно проверяйте примеры. В общей инструкции по подготовке предложения может скрываться реальная маржинальность клиента или персональная переписка. Полезный шаблон получится, если заменить такие детали нейтральными учебными данными и проверить, что по ним нельзя восстановить закрытый контекст.
Не объявляйте автоматически общими выводы, которые ИИ сделал по нескольким клиентским проектам. Возможность прочитать источники для внутренней задачи ещё не означает разрешение публиковать их обобщение для всех пользователей.
Проверяйте границы на всём пути данных
Документ может быть правильно помечен в хранилище, но потерять принадлежность после разбиения на поисковые фрагменты. Или поиск выдаст только разрешённые материалы, а кэш вернёт готовый ответ из соседнего проекта. Поэтому проверяется вся цепочка, включая память и сохранённые результаты.
Для технической команды полезно проследить один запрос: вход, поиск, сбор контекста, вызов модели, инструмент, журнал, ответ. На каждом этапе должно быть понятно, откуда взялась область работы и каким правилом она ограничивает данные. Указанный моделью идентификатор организации нельзя принимать как доказательство права на доступ.
Построчные политики базы данных могут стать дополнительным уровнем защиты. Но документация PostgreSQL предупреждает: суперпользователи и роли с признаком обхода таких политик обходят ограничения, а владельцы таблиц обычно тоже имеют исключение. Сам факт включения функции ещё не доказывает корректную изоляцию приложения.
Проверяйте систему под теми учётными данными, с которыми она работает ежедневно. Успешная демонстрация под администратором мало говорит о реальном поведении обычного пользователя.
Привяжите инструменты к организации
Помощник может прочитать правильный договор, а затем отправить документ через неверный почтовый ящик. Или создать задачу в соседнем аккаунте системы продаж. Здесь ошибка возникает после поиска: принадлежность данных не совпадает с принадлежностью инструмента.
Для каждой организации определите разрешённые подключения, отправителей и места сохранения результата. Выбор учётной записи должен проверяться на серверной стороне вместе с действием. Нельзя позволять модели свободно выбирать любой доступный системе ключ только потому, что он технически подходит.
Перед отправкой показывайте человеку организацию, получателя, предмет и существенные условия. Название компании нужно видеть непосредственно рядом с подтверждением. Если оно спрятано в настройках, сотрудник может не заметить ошибку, даже внимательно прочитав текст.
В отложенной задаче сохраняйте исходную область работы. Перед исполнением перепроверьте актуальность полномочий и доступность подключения. Задача не должна мигрировать в другую организацию только потому, что сотрудник позже переключил свой интерфейс.
Разделяйте передачу и копирование
В работе группы компаний бывают законные передачи: подразделение подготовило ответ, другой команде нужно продолжить. Для помощника это отдельная операция с определённым составом данных и получателем. Она не сводится к переключению названия компании в готовом диалоге.
Сначала укажите, что именно передаётся: обращение, документ, поручение или разрешённая выписка. Затем проверьте основание и права принимающей стороны. После передачи сохраните связь с источником и статус ответственности, чтобы две команды не считали друг друга исполнителем.
Если требуется копия, она получает явную новую принадлежность и ссылку на происхождение. Если доступ предоставляется к исходному объекту, нужно определить его границы и срок. Это разные механизмы, и пользователь должен понимать, какой из них выбран.
Не пытайтесь решать такие вопросы одной фразой в системной инструкции помощника. Нужен понятный бизнес-процесс, который реализуют интерфейс, проверки доступа и журнал действий.
Испытайте одинаковые вопросы в разных контекстах
Для проверки создайте два учебных проекта с одинаковыми названиями услуг и разными условиями. Возьмите пользователя с доступом к обоим проектам и второго — только к одному. Задавайте одинаковые вопросы, меняя текущую организацию и роль.
Затем усложните испытание: откройте две вкладки, сохраните память о скидке в первом проекте, попросите продолжить разговор во втором. Проверьте готовые ответы из кэша, ссылки на файлы, поиск по названию и ошибки инструментов. Ни текст ошибки, ни подсказка поиска не должны раскрывать сведения из запрещённой области.
Отдельно отзовите доступ во время длинного диалога. Посмотрите, перестали ли работать новые запросы и отложенные действия. Информация, которую пользователь уже законно получил, не исчезнет из его памяти; задача системы — прекратить дальнейшую выдачу и выполнение после вступления ограничения в силу.
Оценивайте не только отсутствие чужого текста. Проверяйте правильность организации в созданных объектах, исходящих сообщениях и журнале. Ошибочный отправитель — такой же существенный сбой, как чужая скидка в ответе.
Внедряйте по одному законченному процессу
- Первый шаг — выбрать две области, которые легко перепутать, и одну операцию: например, подготовку предложения.
- Второй — назначить владельцев данных, правил доступа и итогового результата.
- Третий — описать принадлежность документов, памяти и подключений.
- Четвёртый шаг — собрать матрицу полномочий и реализовать явный выбор контекста.
- Пятый — проверить пересечения на учебных данных, включая параллельные сессии и смену прав.
- Шестой — провести ограниченное рабочее использование с разбором каждой ошибки принадлежности.
Не измеряйте результат только количеством подготовленных документов. Считайте неверно выбранные организации, случаи уточнения контекста и остановленные попытки доступа. Само по себе большое число остановок не является успехом: возможно, сотрудники не понимают переключатель или карточки объектов заполнены плохо.
После устойчивой работы одного процесса можно добавлять следующий. При этом сохраняйте ту же дисциплину принадлежности: новая интеграция не должна автоматически получать доступ ко всем уже подключённым компаниям.
Начните с одного неудобного вопроса
Откройте типовой запрос к вашему будущему помощнику: «Подготовь условия для клиента». Сможет ли команда без догадок указать организацию, договор, разрешённые источники, отправителя и место сохранения? Если нет, помощник получит неоднозначность вместе с доступом к системам.
Общий ИИ-сотрудник может быть удобен для нескольких компаний, когда рабочие границы видны и человеку, и программным проверкам. Его память должна помогать помнить нужное, а не переносить всё знакомое в новую сделку.
На ближайшей рабочей встрече разберите один такой запрос с руководителем процесса и специалистом по интеграциям. Зафиксируйте, где определяется принадлежность и кто вправе её изменить. Эта короткая работа даст более надёжную основу внедрения, чем попытка исправлять чужие реквизиты уже в отправленных предложениях.
