Building Compliant AI Systems: SOC 2, GDPR & CCPA

The AI Compliance Problem

AI tooling in 2025 is a compliance nightmare if you're not careful. The core problem: most AI observability products work by proxying all LLM traffic through their infrastructure. Every prompt, every completion, every tool call passes through their servers. If your developers are pasting database query results, internal architecture docs, or customer data into Claude Code for context — and they are — that data is now in a third-party system you may not have audited, contracted with properly, or disclosed to your customers.

FORG takes a different approach. By observing only metadata (tokens, cost, latency, model, session IDs) and never touching prompt content, we sidestep the core problem entirely. You can't accidentally exfiltrate what you never capture.

SOC 2 Type I (in progress)

FORG is formalizing controls for SOC 2 Type I. No audit has been completed, and no SOC 2 report exists yet. For AI tooling specifically, reviewers are increasingly asking about:

• Audit trails: can you demonstrate who made what AI calls, when?
• Access controls: are AI tool credentials managed per-user?
• Change management: when rules or policies changed, is there a record?
• Incident response: if an AI system behaves unexpectedly, can you investigate?

FORG provides:

• Tamper-evident audit evidence — the license audit chain is HMAC-chained and implemented. The broader admin-action audit ledger is being formalized as a hash-chained admin_audit_log.
• Per-user access controls — FORG issues credentials per user (license key + session key derived per session). No shared credentials.
• Rule change history — all rule additions, modifications, and deletions are versioned and logged with the identity of the user who made the change.
• Incident investigation surface — the signal timeline lets you reconstruct any anomalous usage period with full metadata context.

Enterprise audit exports are intended to provide supporting evidence for SOC 2 reviews while Type I work is in progress; there is no Type II report yet.

Healthcare and HIPAA status

HIPAA applies when Protected Health Information (PHI) could be in scope. FORG does not offer HIPAA compliance today, and we cannot sign a BAA yet. A HIPAA BAA is on the Enterprise roadmap and must be advertised only once it is actually available.

The truthful risk-reduction angle is architectural: FORG is metadata-only and zero-trace. We never store prompts, completions, or AI-generated content — only metadata such as timing, token counts, model names, and rule results. That reduces the PHI exposure surface because prompt or completion content does not transit FORG in normal operation.

For healthcare organizations evaluating FORG today:

• No BAA today — a HIPAA BAA is on the Enterprise roadmap, not available for signature yet.
• Metadata-only telemetry — FORG does not store prompt content, completions, or AI-generated content.
• Implemented security controls — AES-256 encryption at rest, TLS 1.3 in transit, admin MFA, daily Supabase PITR backups, and GDPR/CCPA deletion workflows.
• Production-data guardrails — environment rules can flag or block risky production AI usage patterns.

Do not treat FORG as HIPAA-compliant or HIPAA-eligible today. Your responsibility remains ensuring PHI is not placed into development prompts or tools unless your own covered-entity or business-associate controls allow it.

GDPR

GDPR is the most directly relevant framework for most FORG customers. The regulation's key principles — data minimization, purpose limitation, storage limitation, and data subject rights — map naturally to our architecture.

Data minimization: We collect the minimum data needed to operate the service. No prompt content. No file paths. No conversation structure. Just the metadata required for cost attribution, budget enforcement, and compliance reporting.

Purpose limitation:Signal data is used exclusively for observability and cost management. We don't use your usage data to train models, build products, or serve advertising.

Storage limitation: Signal data is retained for ~90 days on Solo, ~24 months on Team, and configurable retention on Enterprise. You can configure shorter retention if your policies require it.

Right to erasure: Deleting a user from your FORG organization triggers deletion of all signals associated with their user dimension within 30 days. For GDPR right-to-erasure requests, the API supports immediate deletion with confirmation.

Data Processing Agreement: We offer a standard DPA for Enterprise customers. The DPA is available for review before signing.

Sub-processors: FORG uses Cloudflare (compute) and Supabase (storage). Review their data processing terms and available residency options against your own GDPR requirements. Our full sub-processor list is published on the Trust page.

Where the Frameworks Overlap

Practical Implementation Checklist

If you're deploying FORG in a compliance-sensitive environment, here's the checklist:

• Enable audit log retention appropriate for your framework (SOC 2 evidence and GDPR/CCPA: per your retention policy)
• Configure data residency if required for your privacy program
• Sign a DPA for GDPR where required; do not rely on a HIPAA BAA because FORG cannot offer one today
• Set up environment dimension rules to flag production AI usage
• Enable webhook notifications for rule enforcement events
• Document FORG as a sub-processor in your own privacy policy
• Test the data subject deletion flow before your audit

Questions about your specific compliance scenario? Reach out to hello@forg.pro — we work with your security and compliance teams directly.