Self-Hosted AI Compliance Architecture

The architecture that regulated enterprises actually buy for AI compliance is not a cloud dashboard or a managed service. It is a self-hosted evidence pipeline that runs inside their own infrastructure, produces reviewable records, and exports regulator-facing evidence packs — all without moving data outside the security boundary.

This post explains the architecture that makes that possible, from evidence collection through cryptographic audit trails to export delivery.

System boundary

RADAR deploys as a single service beside the existing agent stack. It connects to three types of endpoints:

• LLM gateways and agent frameworks: Evidence sources where agent activity happens (LangChain, CrewAI, AutoGen, OpenAI, Anthropic, custom frameworks)
• SIEM and monitoring receivers: Destinations for structured events (Splunk, Microsoft Sentinel, syslog, data warehouses)
• Identity providers: Authentication sources for dashboard access (OIDC, SAML 2.0)

There are no outbound connections to RADAR infrastructure. No telemetry, no phone-home, no license-check endpoints. The service operates fully offline in air-gapped environments.

Evidence collection patterns

RADAR supports four collection patterns, each suited to a different deployment topology:

Gateway ingestion

For teams using LLM gateways (Portkey, Helicone, custom proxies), RADAR connects to the gateway's log stream or webhook endpoint. Every request and response flowing through the gateway is captured as evidence. This is the most common pattern because it requires zero agent code changes.

SDK instrumentation

For Python-based agent stacks, the RADAR SDK provides a RadarMonitor.wrap() call that instruments existing LLM clients and tool invocations. The SDK captures inputs, outputs, timing, and policy context. It is designed to be added to existing agents without refactoring: wrap the LLM client, and evidence collection starts automatically.

REST API push

For custom frameworks or non-Python stacks, RADAR provides a REST ingestion endpoint. Events are pushed as structured JSON with session context, event type, and evidence payload. The API validates schema, enforces retention policy, and returns a Merkle proof receipt.

Log file parsing

For legacy systems or air-gapped environments where direct network connectivity is restricted, RADAR can ingest evidence from structured log files. The collector watches configured paths, parses events, and writes them to the evidence store.

Evidence storage and retention

The evidence store is a local SQLite or PostgreSQL database that lives inside the customer's infrastructure. Every event is written with:

• A timestamp with nanosecond precision
• A session identifier linking related events
• A policy evaluation result (allow/deny/escalate)
• A Merkle chain hash linking the event to the previous event

Retention is enforced at the database level with configurable policies. When an event reaches the end of its retention period, it is purged and a purge attestation is recorded. This prevents the auditor question: "What happened to the records outside your retention window?"

Audit trail integrity

The cryptographic audit trail is the foundation of RADAR's evidence model. Every event is part of a Merkle chain that provides tamper-evident integrity verification:

An auditor can verify the chain root using the RADAR CLI or an independent verification tool. No network access is required — the chain is self-contained in the evidence pack. If any event was modified after the chain was signed, the hash verification fails.

Export pipeline

Evidence packs are generated on demand or on a schedule. The export pipeline assembles traces, findings, control mappings, and the Merkle proof into a single deliverable. Formats:

• JSON: Machine-readable, suitable for SIEM ingestion or programmatic analysis
• HTML: Human-readable, designed for compliance team review and auditor presentation
• PDF: Print-ready, suitable for procurement packages and regulator submissions

Each export includes the digital signature, the chain root hash, and a signed retention attestation. The export is self-validating: an auditor can verify the evidence without contacting RADAR or AKIOUD AI.

Deployment modes

RADAR supports three deployment modes, all self-hosted:

• Docker Compose: Single-node evaluation with SQLite, auto-generated trial license, healthcheck, resource limits. Recommended for evaluation.
• Kubernetes: Production deployment with persistent volumes, liveness probes, horizontal scaling. Helm chart available.
• Air-gapped: Fully offline operation with license validation via embedded cryptographic keys. No outbound connections required.

Deploying for evaluation takes one command. RADAR starts collecting traces immediately — no configuration needed beyond pointing it at your agent endpoints:

$ docker compose up radar
  Creating network radar_default ... done
  Creating radar_collector    ... done
  Creating radar_store        ... done
  Creating radar_review       ... done
  Radar ready. Connect agents at http://localhost:8080

  $ radar sources add --type gateway --name my-agents
  Source connected: my-agents
  Collecting traces from 3 endpoints

  $ radar status
  Sources:      1 connected
  Traces:       247 recorded (14.2/min)
  Evidence hash: SHA-256 a1b2c3d4...
  Status:       Healthy — all hashes verified

The architecture is designed so that an evaluation instance — deployed via Docker Compose in a sandbox VPC — uses the same binary and same evidence pipeline as a production Kubernetes deployment. Evaluation results are directly representative of production behavior.