Anthropic представила EFS: мониторинг ИИ с хранением данных под контролем бизнеса

Что объявлено: данные у заказчика, обнаружение — средствами Anthropic

По сообщению компании, EFS разрабатывали совместно с более чем сотней заказчиков из финансового сектора, здравоохранения, промышленности, юридической практики и других отраслей. В работе также участвовали облачные партнёры Amazon Web Services, Google Cloud и Microsoft Azure.

Anthropic объясняет необходимость решения тем, что опасная активность может складываться из действий в разных сеансах и аккаунтах. Проверки отдельного взаимодействия с немедленным удалением данных недостаточно, чтобы сопоставить такие события. Именно этим компания обосновывает введённое начиная с Fable 5 хранение данных в течение 30 дней.

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

Среди отслеживаемых признаков Anthropic называет попытки развития наступательных кибервозможностей или биологических возможностей, а также признаки украденных либо раскрытых учётных данных. Для разбора предупреждений участие сотрудников Anthropic не требуется: проверку выполняют люди на стороне клиента.

Поддержка заявлена для Claude Code, Claude Enterprise, Claude Platform и перечисленных компанией партнёрских облачных платформ. Развёртывание будет поэтапным. До готовности EFS подходящим под условия заказчикам предоставят режим нулевого хранения данных, ZDR, на Fable 5 и Fable 5.1.

Бизнес-сценарий: согласовать работу ИИ с режимом конфиденциальности

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

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

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

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

Ограничения и контроль: что не следует считать гарантией

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

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

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

Anthropic не взимает плату за EFS. При размещении данных в своём облачном аккаунте заказчик оплачивает провайдеру хранение, чтение, запись и исходящий трафик. Также компания заявляет, что не обучала и не будет обучать модели на корпоративных данных без явного разрешения.

Практический чек-лист перед подключением

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

• Уточнить право организации на доступ к EFS и готовность нужного способа подключения Claude.
• Определить состав сохраняемых сведений, место хранения и правила доступа к чувствительному содержимому.
• Выбрать необходимые опции хранения, управления ключами и автоматизированной проверки, не предполагая их включение по умолчанию.
• Назначить получателей предупреждений и закрепить порядок подтверждения нарушений, отклонения ложных сигналов и реагирования.
• Оценить облачные расходы и проверить, как выбранная схема соотносится с внутренними требованиями к аудиту.

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

Сцена по теме: Корпоративный контроль ИИ →