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

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

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

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

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

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

• Активности становятся доступными для запроса в течение 1 минуты после возникновения и хранятся 6 лет.
• Максимальное значение 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. Полный справочник по курсорам и токенам страниц, а также семантику повторных попыток см. в разделе Пагинация результатов.

Производственный цикл догоняющего чтения получает активности, записанные с момента вашего последнего опроса, управляя итерацией на основе 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; проверяйте дискриминатор перед их чтением. 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 не может вернуть контент, который уже удалён политикой хранения.
• Если рабочий процесс может инициировать жёсткое удаление через Compliance API (например, применение DLP), сначала получите и заархивируйте целевой контент. После жёсткого удаления окна восстановления нет; мягкие удаления из claude.ai остаются доступными для получения с заполненным полем deleted_at, но удаления через Compliance API — нет.

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

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

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

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

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

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

• Текст подсказок или ответы модели из рабочих нагрузок Claude Console или Claude API.
• Контент, удалённый политикой хранения вашей организации.
• Контент, жёстко удалённый через Compliance API.

Подробнее о том, что Compliance API фиксирует и не фиксирует, см. в FAQ по Compliance API.

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

Дальнейшие шаги