Building Compliant AI Systems: SOC 2 + HIPAA + GDPR

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 II

SOC 2 Type II audits five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For AI tooling specifically, auditors 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 log — every signal, rule evaluation, and enforcement action is written to a cryptographic audit chain. SHA-256 chained hashes. Any modification to historical records is detectable.
• 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.

Our audit log export (available on Business+ plans) is formatted for SOC 2 auditor review with timestamps, actor identity, and change descriptions.

HIPAA

HIPAA applies when Protected Health Information (PHI) could be in scope. For engineering teams at healthcare companies, the risk is real: developers working on patient-facing features sometimes use real data for debugging, even when they shouldn't.

FORG's position on HIPAA: we are not in the PHI path. Because we never store prompt or completion content, and because we enforce that policy at the protocol level (the agent binary reads token counts from completion events, not conversation content), PHI cannot enter our systems through normal operation.

For Enterprise customers, we provide:

• Business Associate Agreement (BAA) — signed with your legal team as part of the Enterprise contract
• HIPAA-eligible configuration — audit log retention ≥ 6 years, encrypted exports, access logging for all dashboard views
• Breach notification SLA — 72-hour notification if any security incident could affect your data
• Data residency — US only (HIPAA requires US data residency for most covered entities)

Note: HIPAA compliance is a shared responsibility. FORG secures the observability infrastructure. Your responsibility is ensuring developers don't use production PHI in development contexts. FORG can help here: environment dimension rules can block certain models or emit alerts when production credentials are used in development environments.

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 Developer/Team plans, 1 year on Business, and configurable (up to 7 years) 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 sign a standard GDPR-compliant DPA with all Business+ customers. The DPA is available for review before signing.

Sub-processors: FORG uses Cloudflare (compute) and Supabase (storage). Both are GDPR-compliant with EU data residency options. 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: 1 year, HIPAA: 6 years, GDPR: per your retention policy)
• Configure data residency if required (EU for GDPR, US for HIPAA)
• Sign DPA (GDPR) or BAA (HIPAA) — contact your account manager
• 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.