Права, аудит и обезличивание

Иллюстрация. Конфиденциальность до модели: чувствительные данные нужно минимизировать и обезличивать до вызова LLM.

У корпоративного ассистента есть одна опасная особенность: он делает доступ к данным удобным.

Это звучит как преимущество, и часто так и есть. Сотруднику больше не нужно искать документ в десяти папках, вспоминать,

где лежит договор, открывать несколько систем, собирать статус вручную или просить коллегу переслать файл. Он может поставить задачу ассистенту, а тот найдет, сопоставит, кратко объяснит и подготовит результат.

Но именно удобство создает риск.

Если раньше данные были защищены хотя бы сложностью доступа, то теперь ассистент может стать быстрым проводником к информации. Если права и аудит не продуманы, компания получает новый канал утечки, ошибочного действия или внутреннего нарушения.

Поэтому AI-Native компания должна проектировать права, аудит и обезличивание с самого начала.

Не после пилота. Не “когда появятся чувствительные данные”. Не “когда служба безопасности попросит”.

С самого начала.

Принцип минимально необходимого доступа

Первый принцип прост:

Ассистент должен получать только те данные и действия, которые нужны человеку для конкретной задачи.

Не больше.

В обычной ИТ-безопасности это называется принципом минимальных привилегий. В AI-Native контуре он становится еще важнее, потому что ассистент может быстро соединять данные из разных источников.

Например, менеджеру по продажам может быть разрешено видеть карточку своего клиента, историю встреч и коммерческие предложения. Но это не означает, что через ассистента он должен видеть все сделки компании, финансовые документы, переписку других менеджеров или договоры клиентов другого направления.

Инженер может иметь доступ к репозиторию своего проекта. Но это не означает, что агент разработки может менять секреты, права доступа, инфраструктурные настройки или выполнять опасные операции.

Руководитель может видеть сводный статус отдела. Но это не означает, что он должен получать персональные детали, которые не нужны для управленческого решения.

Минимально необходимый доступ задается не только по человеку, но и по контексту:

кто пользователь;

какая роль;

какой skill;

какой ресурс;

какое действие;

какая цель;

какой уровень чувствительности данных.

Это сложнее, чем просто “дать ассистенту токен”. Но иначе корпоративный ассистент быстро становится слишком сильным и слишком опасным.

Права человека и права агента

В старой модели компания выдавала права человеку.

Человек входил в систему, открывал документ, менял задачу, создавал счет, смотрел карточку клиента. Система проверяла его роль и разрешения.

В AI-Native модели появляется посредник: ассистент или агент.

Теперь нужно ответить на вопрос: от чьего имени действует агент?

Плохой вариант — дать агенту общий технический доступ ко всем системам.

Так проще запустить демонстрацию. Агент “все видит” и “все может”. Но для компании это опасная архитектура. Непонятно, какой человек получил данные, зачем, по какому основанию и имел ли он право.

Хороший вариант — агент действует в контексте конкретного пользователя и конкретной задачи.

Если менеджер просит ассистента подготовить информацию по клиенту, MCP-шлюз проверяет права менеджера на этого клиента. Если инженер просит агента изменить код, проверяются права инженера на проект. Если руководитель просит сводку, система возвращает только те данные, которые разрешены его роли.

Агент не должен быть тайным суперпользователем.

Он должен быть усилителем прав человека, а не обходом этих прав.

Чтение и запись — разные уровни риска

Важно разделять чтение и запись.

Читать документ, подготовить черновик, найти факт, собрать summary — это один уровень риска.

Изменить данные, отправить письмо, создать задачу, обновить карточку клиента, поменять статус, выдать доступ, удалить файл, запустить миграцию — другой уровень риска.

На первой волне внедрения почти всегда разумно начинать с режимов:

Read — читать и анализировать;

Prepare — готовить черновик;

Review — проверять результат;

Suggest — предлагать действие.

Write-действия нужно вводить осторожно.

Для них должны быть:

явные права;

журналирование;

подтверждение человека;

возможность отката;

ограничение по типу ресурса;

запрет на опасные операции без отдельного согласования.

Например, ассистент может подготовить черновик письма клиенту, но не отправлять его без подтверждения. Может создать черновик задачи, но не менять критичный статус проекта. Может предложить изменения в документе, но не утверждать договор. Может подготовить запрос на изменение кода, но не сливать его в

основную ветку без проверки.

Так компания получает скорость без потери контроля.

Аудит: что нужно журналировать

Если ассистент участвует в работе, его действия должны оставлять

след.

Аудит нужен не только для расследования инцидентов. Он нужен для доверия, улучшения качества и управляемости.

Минимально нужно знать:

кто пользователь;

какой ассистент или агент использовался;

какой skill был вызван;

какие инструменты были вызваны;

какие источники читались;

какие данные были переданы модели;

какие действия были предложены;

какие действия были выполнены;

где человек подтвердил результат;

где произошла ошибка;

сколько времени заняла задача;

какой результат был сохранен.

Это не значит, что нужно хранить все сырые данные вечно.

Журналирование тоже должно быть безопасным. В логах не должны случайно оказываться пароли, токены, персональные данные, коммерческие секреты или полные тексты чувствительных документов без необходимости.

Хороший аудит отвечает на вопрос:

Можем ли мы понять, что произошло, не создавая новую

утечку в самих логах?

Обезличивание до LLM

Одна из самых частых ошибок — думать об обезличивании после того, как данные уже попали в модель.

Например, сотрудник загружает в ассистента переписку, договор или таблицу с персональными данными, а потом просит: “Сделай summary без персональных данных”.

Для итогового текста это может помочь. Но с точки зрения безопасности поздно: сырые данные уже были переданы модели.

Правильный принцип:

Чувствительные данные нужно очищать до передачи в

LLM.

Это особенно важно, если используется внешний сервис.

Обезличивание может включать:

удаление персональных данных;

замену имен на роли;

замену email и телефонов на маски;

обобщение сумм;

удаление реквизитов;

скрытие токенов, ключей и паролей;

удаление коммерчески чувствительных условий;

передачу только нужных полей вместо всего документа.

Например, для анализа нагрузки команды ассистенту не всегда

нужны имена сотрудников. Достаточно ролей, количества задач, сроков и статусов.

Для анализа договора не всегда нужны реквизиты сторон. Можно передать условия, риски и структуру документа.

Для подготовки управленческого summary не всегда нужны полные тексты переписок. Можно передать очищенные факты, решения и открытые вопросы.

Обезличивание — не попытка обмануть модель. Это нормальная инженерная гигиена.

Уровни чувствительности данных

Чтобы не решать каждый раз заново, компания должна классифицировать данные.

Простая рабочая шкала может выглядеть так.

Публичные данные.

Информация, которую можно безопасно использовать во внешних сервисах: публичные страницы, открытые описания продуктов, опубликованные кейсы, общие регламенты без секретов.

Внутренние данные.

Рабочие документы компании, которые не являются секретными, но не предназначены для внешней публикации: инструкции, шаблоны, проектные заметки, обычные задачи.

Конфиденциальные данные.

Клиентские документы, договоры, коммерческие условия, финансовые данные, внутренняя стратегия, непубличные предложения, персональные данные.

Критичные данные.

Пароли, токены, секреты инфраструктуры, приватные ключи, доступы, данные с юридическими ограничениями, особо чувствительная персональная информация.

Для каждого уровня должны быть правила:

можно ли использовать внешнюю модель;

нужен ли закрытый контур;

нужно ли обезличивание;

можно ли сохранять в память;

кто имеет право читать;

кто имеет право передавать ассистенту;

какой аудит обязателен.

Без такой классификации сотрудники будут принимать решения на глаз.

А “на глаз” в безопасности не работает.

Роли в управлении доступом

Управление доступом к AI-Native контуру — это не только задача ИТ.

Здесь участвуют несколько ролей.

Бизнес-владелец процесса отвечает за то, какие действия нужны

для работы и где человек принимает решение.

Владелец source of truth отвечает за актуальность данных и правила доступа к источнику.

Технический руководитель отвечает за архитектуру, MCP-шлюз, интеграции, хранение секретов, аудит и надежность.

Служба безопасности отвечает за классификацию данных, правила использования внешних моделей, требования к закрытому контуру и проверку рисков.

Юристы отвечают за персональные данные, договорные ограничения, согласия и юридически значимые действия.

Руководитель компании отвечает за баланс: не задушить

внедрение страхом, но и не открыть данные без контроля.

Если оставить права только ИТ, они могут не понять бизнес- контекст.

Если оставить права только бизнесу, можно недооценить технические риски.

Если оставить все службе безопасности, внедрение может остановиться.

Нужна совместная модель.

Типовые ошибки

Первая ошибка — дать ассистенту общий доступ “для удобства”.

Так быстрее на демо, но опаснее в эксплуатации.

Вторая ошибка — не разделять чтение и запись.

Подготовить черновик и выполнить действие — разные уровни ответственности.

Третья ошибка — хранить секреты в настройках агента, локальных файлах или инструкциях.

Агент не должен владеть секретами. Секреты должны храниться в управляемом контуре.

Четвертая ошибка — не логировать действия.

Если непонятно, что ассистент делал, компания не сможет расследовать ошибку и улучшить процесс.

Пятая ошибка — передавать сырые чувствительные данные в LLM и надеяться на последующее обезличивание.

Обезличивание должно быть до модели.

Шестая ошибка — считать, что закрытый контур автоматически

решает все проблемы.

Даже внутри периметра нужны права, аудит, классификация данных и правила качества.

Что сделать руководителю

Попросите команду описать модель прав и безопасности для первого AI-Native контура.

Не в общем виде, а на конкретном сценарии.

Например: подготовка коммерческого предложения, проверка договора, анализ тендера, протокол встречи, инженерный агент для задачи.

Ответьте:

Какие данные используются?
Какой у них уровень чувствительности?
Кто имеет право их читать?
Что ассистент может делать сам?
Что он может только подготовить?
Где требуется подтверждение человека?
Какие данные нужно обезличивать до LLM?
Можно ли использовать внешний сервис или нужен закрытый

контур?

Что журналируется?
Кто владелец правил доступа?

Если на эти вопросы нет ответа, запускать сценарий в широкую эксплуатацию рано.

Вопросы для руководителя

Есть ли у вас классификация данных для AI-сценариев?

Понимаете ли вы, какие данные можно отправлять во внешний сервис, а какие нет?

Может ли ассистент получить больше прав, чем пользователь?

Разделены ли чтение, подготовка и запись?

Где хранятся токены и секреты?

Можете ли вы восстановить цепочку действий ассистента после ошибки?

Обезличиваются ли чувствительные данные до передачи в LLM?

Кто утверждает права для нового skill?

Главная мысль главы

AI-Native компания не может строиться на неконтролируемом доступе к данным.

Чем удобнее ассистент, тем важнее права, аудит и обезличивание.

Зрелая модель проста по принципу и сложна в дисциплине: ассистент действует от имени человека, получает минимально необходимые данные, проходит через управляемый слой доступа, очищает чувствительную информацию до LLM, оставляет след действий и останавливается там, где решение должен принять

человек.

Так компания получает скорость без потери доверия.