Before any AI logic executes, the gateway resolves the requesting tenant's configuration record from the platform database. This record contains the tenant's approved AI provider, content policy level (MINIMAL, STANDARD, or STRICT), enabled feature set, rate limit thresholds, and cost cap settings. If a feature is not explicitly enabled for that tenant, the request is rejected at this stage with a structured error — no AI model is ever contacted. This means configuration is the first and primary control gate, not an afterthought enforced at the application layer.

The gateway queries the tenant's current usage counters — requests per minute, tokens consumed in the current billing window, and cumulative cost against the configured hard cap. These counters are maintained in a fast in-memory store and updated atomically to prevent race conditions under concurrent load. If the request would breach either the rate limit or the cost cap, it is queued or rejected with an appropriate status code before any PII scanning or model API calls begin, ensuring cost governance has zero latency impact on valid requests.

The full prompt — system message, user message, and any injected context — is passed through the PII scanner before the external API call is constructed. The scanner uses pattern-matching rules and entity recognition to detect patient identifiers (names, DOBs, subject IDs), unpublished trial identifiers, email addresses, and common regulatory document metadata that should not leave the platform. Under STRICT policy, any detected PII causes the request to be blocked entirely and logged. Under STANDARD policy, detected entities are replaced with typed placeholders (e.g., [PATIENT_ID]) and the redacted prompt is forwarded. The redaction mapping is stored server-side so responses can be re-hydrated if appropriate, and the redaction event is recorded in the audit trail regardless of policy outcome.

Prompt injection — where malicious or accidental input attempts to override the system prompt and redirect model behavior — is a specific risk in regulatory workflows where AI-generated content may be incorporated into submissions. The gateway applies a set of heuristic and structural checks to identify injection patterns: instruction override phrases, role-switching attempts, delimiter manipulation, and base64-encoded payloads that encode instructions the PII scanner would miss. Flagged prompts are either blocked (STRICT) or sanitized and logged (STANDARD). The injection detection runs independently of the PII scanner so that both checks complete before the API call is assembled.

The tenant's AI provider API key is stored in the platform's encrypted key vault using AES-256 encryption at rest, isolated by tenant. The gateway retrieves and decrypts the key at runtime for the duration of the API call only — keys are never persisted in application memory beyond the request lifecycle. The gateway then constructs the provider-specific API request (OpenAI, Anthropic, Azure OpenAI, or Google Vertex AI) using the appropriate SDK, including model selection, temperature, and max token limits configured per feature. This abstraction means a tenant can switch AI providers by updating a single configuration record without any application code changes.

When the AI provider returns a response, the gateway does not pass it directly to the application. The response content is validated against the tenant's content policy: checking for hallucinated regulatory citations, inappropriate content flags from the provider's own safety layer, and structural compliance with the expected response schema for the invoked feature. Under STRICT mode, responses containing unverifiable external citations or any content flagged by the policy engine are returned to the application as filtered with the original model output preserved in the audit log but excluded from the user-facing result. This creates a clean separation between what the model said and what the application surface shows.

After the request-response cycle completes — regardless of outcome — the gateway commits a complete audit record to the platform's immutable audit store. The record includes: timestamp (UTC), tenant ID, user ID and session token hash, the feature invoked, the AI provider and model version used, input token count, output token count, estimated cost, PII scan result, injection scan result, content policy applied, final disposition (pass/block/redact), and a SHA-256 hash of the sanitized prompt. This audit record cannot be modified or deleted by tenant administrators. It is formatted to satisfy 21 CFR Part 11 requirements for electronic records, including the ability to generate a human-readable audit trail report for regulatory inspection.