Skip to main content
Compliance Center gives organization administrators one place to connect supported AI provider compliance feeds, verify access, and investigate normalized activity. Planck runs the collection pipeline and keeps the exact provider pages alongside the searchable activity projection, so your team does not need to build and operate its own polling, Kafka, object-storage, and analytics stack.
Compliance Center is available to Enterprise organizations and organizations with the Compliance entitlement. An inference BYOK key does not grant access to a provider’s administrative or compliance data.

​
Current source coverage

Unsupported capabilities stay visible as Not validated or Not supported. Planck does not infer compliance coverage from an existing provider integration, contract, or BYOK inference key.

​
Connect a source

  1. Create the provider’s compliance or organization-administration credential with the narrowest scope that covers the activity feed.
  2. In Planck, open Settings → Compliance.
  3. Select Configure for Claude or OpenAI API Platform.
  4. Choose the credential type, enter a display name and Planck retention period, then provide the credential.
  5. Planck encrypts the credential, validates it from the dedicated compliance worker, and reports the capabilities the provider actually returns.
The current release permits one non-revoked connection for each provider source in an organization. The plaintext credential is accepted only during setup. It is envelope-encrypted for the selected organization and is not returned by the API or displayed again.
Revalidation tests the stored credential. Credential replacement, pause/resume, revocation, content export, legal hold, and provider-side deletion are not self-service operations in the current activity-only release.

​
How collection works

For each provider page, Planck:
  1. Binds the page to its sync run, page sequence, cursor transition, event count, and raw-response hash.
  2. Reserves durable evidence before uploading the exact compressed provider response.
  3. Stores an encrypted, versioned object and records its checksum and version.
  4. Publishes bounded provider-neutral activity envelopes to Kafka.
  5. Commits the cursor only after Kafka acknowledges publication.
  6. Projects the events into a tenant-scoped ClickHouse table for the Activity explorer.
Kafka is a transient projection buffer, not the customer archive. The source topic must use delete cleanup, no more than 12 hours of retention, and segments that roll at least hourly. Both compliance workers verify those effective topic settings and fail closed before publishing or consuming when they cannot be verified. Temporal workflows bound page counts, retry provider and infrastructure failures, continue long history walks safely, and recover expired run leases. Provider cursors remain opaque and are never interpreted by Planck.

​
Searchable activity and exact evidence

The Activity explorer normalizes the fields that are useful across providers:
  • Provider event type and occurrence time
  • Actor type, stable provider ID, email when supplied, key or session identifiers, IP address, and user agent
  • Resource type and provider ID for recognized chats, files, projects, users, keys, and administrative resources
  • Connection and provider organization identifiers
  • Provider request ID and the checksum/reference for the exact raw page
Provider schemas evolve. Unrecognized fields remain in the exact raw page even when Planck does not yet map them into an Activity explorer column. For Anthropic, the Activity Feed includes authentication, chat, file, project, administrative, platform, and Compliance API access activity. A *_viewed event indicates that a Claude application loaded a resource; it should not be treated as proof that a person viewed it. See Anthropic’s Activity Feed documentation. Anthropic’s activity recording is not retroactive: it begins when the Compliance API is enabled. Planck can walk the provider-recorded history that is available to the credential, but it cannot recover activity from before Anthropic began recording it. For OpenAI, this release uses the API Platform organization audit-log endpoint. ChatGPT Enterprise workspace conversations, uploaded files, memories, GPT configuration, and ChatGPT compliance logs require the separate ChatGPT Compliance Platform integration, which is not included yet.

​
Retention and deletion

The retention value selected for a source is a Planck archive policy, not the provider’s own source-retention period.
  • The raw object version and its ClickHouse activity rows receive the same explicit retain_until deadline based on the Planck ingestion time.
  • ClickHouse removes activity rows with table TTL enforcement.
  • An independent hourly Temporal retention workflow permanently deletes the exact expired object version and records the deletion result.
  • Raw-object retention has a fail-closed legal-hold state, but this release does not expose hold management or claim legal-hold coverage for searchable ClickHouse activity.
  • Collection failures do not advance the provider checkpoint. The source is marked degraded when a run lease expires or validation fails.

​
Access model

Compliance Center uses the signed-in Planck organization context. Only organization owners and administrators with settings-management access can open it or configure a source. Every Postgres and ClickHouse read is bound to the selected organization. This release does not issue customer Compliance API keys and does not expose a public Planck-compatible content or activity API. The current read endpoints support the authenticated Planck UI. A customer-facing API, external destinations, content retrieval, exports, and remediation will be introduced only after their authorization and retention contracts are implemented. Planck rechecks the Enterprise or Compliance entitlement before claiming work and again before decrypting a stored provider credential. When the entitlement is removed, new collection is blocked and the connection reports an entitlement collection error; restoring access allows scheduled collection to recover.

​
Regional deployment boundary

A compliance connection is pinned to one managed regional plane. The first successfully created Planck-managed destination transactionally pins that regional plane for the organization, and later provider sources must use the same region. A multi-region Planck deployment must provide separate regional object storage and KMS configuration, region-qualified Temporal task queues and Schedules, regional Kafka topics and consumer groups, and a regional ClickHouse plane. This release does not treat a shared global Kafka or ClickHouse data plane as a residency-safe configuration, and it does not provide cross-region fallback or automatic compliance-data migration. Operators should not make a residency claim until those regional planes and their backup and recovery boundaries have been verified.

​
Before enabling production polling

Your Planck deployment operator must complete the compliance migrations and provide:
  • A private versioned object-storage bucket with the configured encryption key
  • PostgreSQL, Kafka, ClickHouse, and Temporal connectivity
  • A Kafka source topic with cleanup.policy=delete, retention.ms<=43200000, segment.ms<=3600000, plus worker permission to describe topic configuration
  • The dedicated compliance worker and projection worker
  • The independent retention schedule
  • Monitoring for provider failures, expired leases, projection DLQ events, and object-deletion failures
Provider polling is intentionally deployment-gated. Validation and the UI being available do not by themselves prove that a production polling schedule has been enabled.