Проектирование интеграции для обеспечения соответствия требованиям

Производственная интеграция с Compliance API предполагает три проектных решения: как она потребляет Activity Feed (ленту активности), как её выходные данные сопоставляются с вашей системой «security information and event management» (управление информацией о безопасности и событиями безопасности), или SIEM, и где хранятся долгосрочные копии активности и контента. Эти решения не зависят от самих конечных точек; эта страница поможет вам оценить компромиссы.

Эта страница предполагает, что вы прочитали следующие страницы:

• Запрос Activity Feed, где определены параметры и контракт пагинации, на которые ссылается весь этот документ.
• Получение и удаление чатов, файлов и проектов, где определены конечные точки чатов, файлов и проектов, а также семантика deleted_at, упоминаемая в разделе Планирование хранения контента.
• Получение транскриптов сессий, где определены конечные точки локальных и удалённых сессий.

Выбор шаблона потребления ленты

Activity Feed поддерживает два шаблона потребления: периодический опрос окон (window polling), ограниченных параметрами created_at.gte и created_at.lt, и инкрементальное чтение на основе курсора (cursor-driven incremental reads), при котором курсор из одного ответа сохраняется и передаётся в следующем запросе. Оба возвращают идентичные объекты Activity; разница заключается в состоянии, которое ваш клиент сохраняет между вызовами.

Оба шаблона имеют следующие общие ограничения:

• Активности доступны для запроса в течение 1 минуты после возникновения и хранятся 6 лет. Запись не является ретроактивной: она начинается с момента первого включения Compliance API для вашей организации, и активность до включения не восполняется задним числом.
• Максимальное значение limit для каждой страницы — 5 000.
• Значения курсора — это непрозрачные строки, которые вы не должны разбирать.
• Запросы ограничены 600 в минуту на родительскую организацию; этот лимит общий для всех ключей, всех связанных организаций и всех конечных точек /v1/compliance/*; в отличие от конечных точек локальных сессий, конечные точки удалённых сессий имеют дополнительный второй бюджет запросов. Заголовки ответа и контракт повторных попыток см. в разделе 429 Too Many Requests.

Опрос окон

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

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
  --data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
  --data-urlencode "limit=5000"

Когда в ответе указано has_more: true, окно содержит более одной страницы активностей. Либо выполняйте пагинацию внутри окна, передавая last_id из ответа в качестве after_id в следующем запросе (останавливаясь, когда has_more равно false), либо выберите меньшее временное окно. Полный контракт см. в разделе Пагинация результатов.

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

Инкрементальное чтение на основе курсора

first_id="activity_01XyDMpzjS89pFZXqSFUBDr6"  # first_id from a previous response

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "limit=5000" \
  --data-urlencode "before_id=$first_id"

Листайте страницы, пока has_more не станет false, затем сохраните first_id из последнего ответа и передайте его без изменений в качестве before_id при следующем запуске, чтобы получить активности новее сохранённого курсора. Чтобы двигаться в обратном направлении для восполнения истории, сохраните last_id и передавайте его в качестве after_id. Полный справочник по курсорам и токенам страниц, а также семантику повторных попыток см. в разделе Пагинация результатов.

Производственный цикл догоняющего чтения (catch-up) получает активности, записанные с момента вашего последнего опроса, управляя итерацией на основе has_more и first_id:

cursor = stored_cursor
loop:
  page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
  store(page.data)
  if page.first_id is not null:
    cursor = page.first_id
  if not page.has_more: break
persist(cursor)

Курсоры сохраняются при ротации ключей; см. раздел Управление ключами и их ротация.

Сопоставление с вашей SIEM

Каждый объект Activity содержит поля, которые можно соединять с событиями, уже имеющимися в вашей SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl или аналогичной):

actor.user_id и actor.email_address присутствуют, когда actor.type равен user_actor. actor.ip_address и actor.user_agent отсутствуют у некоторых типов акторов, таких как anthropic_actor и scim_directory_sync_actor. Проверяйте дискриминатор перед чтением любого из этих полей. user_id — это стабильный непрозрачный идентификатор учётной записи пользователя: он единообразен во всех конечных точках Compliance API и полезных нагрузках активностей и не меняется при изменении адреса электронной почты или отображаемого имени пользователя. Используйте user_id, а не email_address, в качестве основного ключа соединения.

Вызовы самого Compliance API порождают активности compliance_api_accessed. Принимайте их вместе с другими типами активностей, чтобы ваша SIEM фиксировала, кто и когда запрашивал данные о соответствии требованиям. Передайте activity_types[]=compliance_api_accessed, чтобы ограничить запрос, а затем в своём клиенте считывайте actor.api_key_id из каждой активности, у которой actor.type равен api_actor, чтобы отнести доступ к конкретному Compliance Access Key или ключу Admin API.

Планирование хранения контента

Пять горизонтов хранения определяют, что вы сможете получить позже:

Чтобы узнать, как остальная часть Claude Platform обрабатывает хранение данных, см. раздел API и хранение данных.

Выбирайте между экспортом с архивированием и получением через API по запросу следующим образом:

• Если ваш горизонт юридического удержания или аудита превышает 6 лет для метаданных активности или транскриптов сессий, экспортируйте страницы Activity Feed и транскрипты сессий в собственный архив по мере их приёма.
• Если ваша политика хранения контента короче вашего горизонта eDiscovery, экспортируйте контент чатов и файлов до истечения окна хранения; Compliance API не может вернуть контент, который уже удалён в соответствии с политикой хранения. То же относится к транскриптам локальных сессий, которые следуют пользовательскому периоду хранения разговоров вашей организации, если задан конечный период, даже когда этот период короче 6 лет. Конечные точки локальных сессий перестают возвращать сообщения старше текущего периода вашей организации сразу после изменения настройки, а последующее увеличение периода не восстанавливает уже истёкшие транскрипты, поэтому экспортируйте любой транскрипт, который вы должны хранить дольше этого периода.
• Если вы должны хранить контент чатов после того, как пользователи удалят его в claude.ai (например, в рамках юридического удержания), экспортируйте контент чатов, файлов и артефактов в собственный архив по мере его приёма; Compliance API не может вернуть контент, который пользователь уже удалил.
• Если рабочий процесс может выполнить безвозвратное удаление через Compliance API (например, при применении политик DLP), сначала получите и заархивируйте целевой контент. После безвозвратного удаления окна восстановления нет.

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

Гарантии доставки и полнота

Рассматривайте Activity Feed как систему с доставкой «at-least-once» (как минимум один раз): корректно выполненный обход с пагинацией возвращает каждую активность как минимум один раз, но повторная попытка после частичного сбоя может повторно доставить активности, которые вы уже сохранили. Выполняйте дедупликацию по полю id активности.

Конечные точки списков не возвращают поле total_count или контрольную сумму. Чтобы подтвердить полноту прогона экспорта, фиксируйте в журнале:

• Начальный курсор и конечный last_id.
• Количество экспортированных записей.
• Временную метку прогона и request-id последней страницы.

Объём активности не является проверкой полноты. Типы активностей claude_*_viewed, такие как claude_chat_viewed, следуют шаблону загрузки каждого приложения (см. раздел Понимание объекта Activity). Период с сообщениями чата, но без активностей claude_chat_viewed, сам по себе не указывает на отсутствие данных. Вместо этого полагайтесь на обход и проход с перекрытием или сверкой, описанный в разделе Опрос окон.

Конечные точки контента (чаты, файлы, проекты, вложения проектов, а также транскрипты локальных и удалённых сессий) обслуживают только данные Claude Enterprise. Activity Feed отображает административные и ресурсные события по всей организации. Compliance API не включает:

• Текст подсказок или ответы модели из Claude Console, а также из рабочих нагрузок Claude API, аутентифицированных с помощью ключа API.
• Активность на устройстве в локальных сессиях, которая никогда не отправляется в Anthropic, например локальные файлы, которые Claude не читал.
• Использование Claude Code, аутентифицированное с помощью ключа API Claude Console, выполняемое через стороннюю облачную платформу (Amazon Bedrock, Google Cloud или Microsoft Foundry) или выполняемое в Claude Code в веб-версии.
• Локальные сессии организаций с включённой готовностью к HIPAA, а также локальные сессии, для которых действует нулевое хранение данных.
• Блоки мышления, а также изображения и другой двоичный контент внутри транскриптов сессий (транскрипты содержат только подсказки пользователя, ответы ассистента и активность инструментов; в транскриптах локальных сессий на месте опущенного двоичного контента отображается блок-заполнитель text).
• Исходный файл вложения чата, который claude.ai сохранил в виде извлечённого текста, например некоторые загруженные файлы Word, PowerPoint и PDF (конечная точка содержимого файла возвращает извлечённый текст; см. раздел Получение файлов и артефактов).
• Системную подсказку локальных сессий (вместо неё используется сообщение-маркер).
• Определения инструментов и конфигурацию серверов MCP в транскриптах сессий (локальных или удалённых), а также метаданные цитирования в блоках text транскриптов локальных сессий.
• Содержимое транскриптов локальных сессий в организации, чей управляемый клиентом ключ шифрования в данный момент не может быть использован. Такие запросы возвращают 503 Service Unavailable, при этом метаданные сессий по-прежнему отображаются в списке.
• Контент, удалённый в соответствии с политикой хранения вашей организации.
• Содержимое чатов, которые пользователи удаляют в claude.ai (чаты по-прежнему отображаются в списке с заполненным полем deleted_at).
• Контент, безвозвратно удалённый через Compliance API.

Подробнее о том, что Compliance API фиксирует и не фиксирует, см. в разделе Часто задаваемые вопросы о Compliance API.

Для обеспечения цепочки ответственного хранения сохраняйте экспортированные записи с метаданными происхождения: исходная конечная точка, параметры запроса, временная метка прогона и хэш содержимого каждой записи.

Следующие шаги