ASC for Compliance-Heavy Industries: Audit Trails, Data Residency, and Per-Tenant Guardrails

When a compliance officer at a healthcare organisation asks whether AI features in a patient-facing system are auditable, the answer needs to be concrete. Not "we log requests," but: which fields are recorded, how long are they retained, who can query them, can they be tampered with, how are they exported for an external audit, and how do we demonstrate that no PHI left the approved processing boundary? The same level of specificity is required for GDPR data processing documentation, SOC 2 evidence collection, and HIPAA BAA reviews.

Vanilla AI APIs are not built for this. They provide usage dashboards and billing history, not the granular, queryable, tamper-evident audit records that compliance functions require. AIARCO ASC is built for exactly this gap.

The Compliance Problem in AI Systems

Adding AI capabilities to a regulated product introduces compliance obligations across three dimensions.

Audit evidence. Regulators and auditors want to know what the system did. For AI systems, this means: what model was used, when, by whom, with what input, and with what output. For financial services, this supports model risk management. For healthcare, it supports clinical decision support audit requirements. For any organisation with SOC 2 commitments, it is evidence for the availability, processing integrity, and confidentiality categories.

Data handling. Prompts sent to AI models contain the same user data that your other systems handle. If your product is GDPR-regulated, prompts are data processing activities that require a legal basis and may involve personal data. If you operate under HIPAA, prompts may contain PHI. The question is not whether AI requests are covered by your data handling framework — they are — but whether your infrastructure enforces the required controls.

Configuration governance. Regulated systems require that changes to configuration affecting data processing are controlled, documented, and reversible. The ability to change which model handles which type of request, which content policies apply, and which credentials are in use needs to be governed as carefully as other changes to production infrastructure.

The Audit Trail: Design and Implementation

ASC's audit log records every request and response processed by the gateway. Each record contains:

• Request metadata: tenant identifier, caller identity, request timestamp, target model and provider, request ID
• Token accounting: prompt tokens, completion tokens, total tokens, estimated cost in USD
• Latency data: time to first token, total response time, provider response time
• Policy decisions: which policies were evaluated, which were triggered, what action was taken
• Request and response bodies: stored encrypted, accessible to tenant administrators and audit tooling with appropriate permissions
• Routing decisions: which provider was selected, which fallback chain was evaluated, which circuit breakers were open

The log is append-only. Records cannot be modified or deleted through the management API. The underlying storage uses a hash chain: each record includes the hash of the previous record, creating a verifiable chain of custody. An auditor or audit tooling can verify that no records have been altered since ingestion.

Querying the audit log. The ASC management API provides a structured query interface for the audit log. You can filter by tenant, time range, model, provider, policy trigger, cost threshold, or caller identity. Results are paginated and include a cursor for efficient traversal of large result sets.

For organisations that want to integrate the audit log with existing SIEM or data analytics infrastructure, ASC supports streaming export to Splunk HEC, Datadog Logs, Elasticsearch, and S3/GCS. The streaming pipeline delivers records with a typical lag of under 30 seconds.

Retention. Audit log retention is configurable per tenant. The default is 90 days of hot storage (immediately queryable) with configurable archival to object storage for longer retention periods. Organisations with 7-year retention requirements for financial records can configure archival accordingly.

Data Residency: Architecture and Enforcement

Data residency requirements specify that data must be processed and stored within a defined geographic boundary. In the context of an AI gateway, this means that prompts, responses, and associated metadata must not transit or be stored outside the approved region.

ASC enforces data residency at three layers.

Request routing. Each tenant can be configured with a residency constraint: eu-central, us-east, ap-southeast. The routing fabric evaluates this constraint before selecting a provider. If no provider endpoint exists within the required region for the requested model, the request is rejected with a clear error rather than silently routed outside the boundary.

Data plane placement. The audit log, credential store, and tenant configuration are stored in a data plane instance pinned to the tenant's residency region. Metadata about a tenant in the EU is stored in EU infrastructure. There is no replication of tenant data to infrastructure in other regions unless explicitly configured by the tenant administrator.

Provider endpoint selection. ASC maintains a registry of provider endpoints by region. For providers with regional endpoints — Azure OpenAI Service, for example, has endpoints in East US, West Europe, and Southeast Asia — ASC routes to the endpoint within the residency boundary. For providers without regional endpoints, ASC's residency enforcement rejects the request and records a policy violation in the audit log.

Audit of residency compliance. ASC's audit log records the provider endpoint used for each request. This provides an evidence trail demonstrating that every request was routed within the approved boundary. Residency policy violations are recorded as policy events and can trigger alerts.

Per-Tenant Guardrails

In a multi-tenant AI deployment — a SaaS product where each customer has isolated AI capabilities, or an enterprise platform where each business unit has separate cost centres — per-tenant guardrails are essential.

Content policies. Each tenant can have an independent content policy configuration. ASC's Prompt Shield module evaluates incoming prompts against a set of configurable content classifiers: PII detection, toxic content classification, topic restriction, and custom pattern matching. The policy can be configured to block requests, redact detected content, or pass the request with a policy warning recorded in the audit log.

Output policies apply the same evaluation to model responses before they are returned to the caller. For use cases where model responses might contain PII that was hallucinated or inferred from context, output filtering provides an additional safety layer.

Rate limiting. Per-tenant rate limits are applied at the gateway layer. Limits can be expressed in requests per minute, tokens per day, or cost per month. When a tenant reaches a limit, subsequent requests receive a rate limit response; the calling application can implement appropriate backoff and user messaging.

Rate limits serve two purposes: cost protection (preventing a runaway integration from generating an unexpectedly large bill) and fair-use enforcement (preventing one tenant's usage from affecting other tenants' access to provider capacity).

Model allowlists. Tenants can be restricted to a defined set of models. A tenant configured for HIPAA compliance might be restricted to models whose providers have signed Business Associate Agreements. A tenant handling highly sensitive material might be restricted to self-hosted models only. Model restriction is evaluated at the routing layer; attempts to access a model outside the allowlist are rejected and recorded.

Budget caps. Each tenant can have a hard budget cap per billing period. When a tenant's accumulated spend reaches the cap, subsequent requests are rejected until the billing period resets or an administrator increases the cap. Budget alerts can be configured to notify at 50%, 75%, and 90% of the cap, giving administrators advance warning before service is interrupted.

HIPAA Compliance Considerations

For organisations subject to HIPAA, deploying AI through ASC involves several specific considerations.

Business Associate Agreement. AIARCO enters into a BAA with healthcare organisations using ASC for workflows that may involve PHI. The BAA covers ASC's role as a business associate and documents the safeguards in place.

PHI in prompts. HIPAA does not prohibit sending PHI to an AI model in all circumstances; it requires that PHI be handled with appropriate safeguards. Relevant safeguards include: encryption in transit (HTTPS is required for all ASC communication), access controls (ASC's RBAC limits who can view audit records), audit logging (ASC records all request metadata), and minimum necessary access (ASC's prompt screening can detect and alert on PHI in prompts).

De-identification. For use cases where the clinical workflow allows it, prompts can be de-identified before reaching the AI model. ASC's Prompt Shield module includes a PII detection capability; detected PII can be redacted before the request is forwarded and re-inserted into the response.

SOC 2 Evidence Collection

ASC's audit log provides direct evidence for several SOC 2 trust service categories.

Availability. The audit log records provider uptime events, fallback routing activations, and circuit breaker state changes. This provides evidence that the system's availability controls — specifically its failover mechanisms — are operating as designed.

Processing Integrity. Each request has a recorded routing decision, policy evaluation result, and response. An auditor can trace any request from input to output and verify that the system processed it in accordance with the configured policies.

Confidentiality. Access controls on the audit log, encrypted credential storage, and TLS for all API communication are each recordable as evidence items. ASC's credential store maintains an access log showing which system identities retrieved credential material and when.

Security. Authentication and authorisation events — API key creation, SAML login attempts, permission changes — are recorded in ASC's system event log, separate from the request audit log.

GDPR Article 28 Considerations

GDPR Article 28 requires that data controllers enter into data processing agreements with processors. If you use ASC in SaaS mode, AIARCO is a processor; ASC's data processing agreement documents the legal basis, purposes, and safeguards for processing.

Article 28 also requires that processors do not engage sub-processors without the controller's authorisation. In ASC's context, the AI model providers are sub-processors. ASC's tenant configuration records which providers a tenant is authorised to use; routing is restricted to authorised providers, providing a control that maps to the sub-processor authorisation requirement.

For ASC deployed in self-hosted mode, the Article 28 relationship is between your organisation and the model providers directly. ASC's routing configuration serves as the technical implementation of the sub-processor authorisation list.

Conclusion

Compliance in AI systems is not a checkbox at the end of a project; it is an architecture requirement from the beginning. The audit trails, data residency controls, and per-tenant guardrails that regulated industries require cannot be retrofitted into a system built on a direct provider API without significant rework.

AIARCO ASC provides these capabilities as configuration rather than custom engineering. The audit log is always on; data residency enforcement is always active; content policies and rate limits are applied consistently to every request. The compliance function gets the evidence it needs; the engineering team does not need to build bespoke compliance tooling for each AI feature.

---

Evaluating AI infrastructure for a regulated environment? AIARCO ASC provides the audit trails, data residency controls, and per-tenant guardrails that compliance-heavy industries require. Request a security review or start a free trial.