How UMAI Helps You Pass SOC 2 Type II with AI Systems in Scope

The AI Compliance Gap in SOC 2

SOC 2 Type II audits evaluate whether your organization's controls are operating effectively over a period of time. For most companies that covers infrastructure, access management, data handling, and incident response. But when AI systems are in scope — and auditors are increasingly putting them there — most teams discover a painful gap: they have no systematic way to demonstrate that their AI systems are governed.

This post walks through how UMAI maps directly to SOC 2 Trust Services Criteria and what evidence your auditors actually need.

Why Auditors Are Putting AI in Scope

Three trends are driving this:

Regulatory pressure. The EU AI Act, NIST AI RMF, and sector-specific guidance (OCC for banking, FDA for healthcare) all emphasize AI governance. Auditors are following.

Data flow risk. AI systems process, generate, and sometimes hallucinate sensitive data. If your SOC 2 boundary includes customer data and your AI system touches that data, the AI system is in scope.

Customer demand. Enterprise buyers increasingly ask "how do you govern your AI?" in security questionnaires. Your SOC 2 report is where they expect to find the answer.

Mapping UMAI to Trust Services Criteria

CC6.1 — Logical Access Controls

What auditors want: evidence that access to AI systems is restricted to authorized users with appropriate permissions.

What UMAI provides: every API request to UMAI includes an authenticated identity (API key, JWT, or service account). UMAI's audit log records the identity, timestamp, source IP, and policy evaluation result for every request. Role-based access controls determine which policies apply to which users and environments.

Evidence artifact: export UMAI's access log for the audit period, showing all authenticated requests and any access denials.

CC6.6 — Security Event Monitoring

What auditors want: evidence that security events related to AI systems are detected, logged, and investigated.

What UMAI provides: UMAI's real-time policy engine detects and logs prompt injection attempts, data leakage, PII exposure, and policy violations. Each event includes a severity level, the triggering content (redacted if necessary), and the enforcement action taken — block, redact, or alert.

Evidence artifact: UMAI's security event dashboard with filtering by severity, time range, and event type. Export event logs with hash-chain verification for tamper evidence.

CC7.2 — System Change Management

What auditors want: evidence that changes to AI governance policies are authorized, tested, and documented.

What UMAI provides: UMAI's policy version history tracks every change to guardrail policies — who changed it, when, what the diff was, and whether it went through the approval workflow. Policies can be promoted through environments (dev → staging → production) with required approvals.

Evidence artifact: policy change log with approval chain, diff history, and deployment timestamps.

CC8.1 — Data Classification and Handling

What auditors want: evidence that data processed by AI systems is classified and handled according to policy.

What UMAI provides: UMAI's PRE_LLM and POST_LLM layers detect and enforce data handling policies in real time. PII detection catches social security numbers, credit card numbers, email addresses, and custom patterns. Content policies prevent the model from generating or processing data types that violate classification rules.

Evidence artifact: data handling policy configuration in UMAI, with detection statistics and enforcement action logs.

A1.2 — Availability Monitoring

What auditors want: evidence that AI system availability is monitored and maintained.

What UMAI provides: UMAI's health dashboard reports uptime, latency percentiles (p50, p95, p99), and error rates. UMAI is designed for five-nines availability with automatic failover. If UMAI is temporarily unreachable, the configurable fail-open/fail-closed behavior is documented and logged.

Evidence artifact: uptime report and latency dashboard for the audit period.

The Tamper-Evident Advantage

One of the most common audit findings is "we can't verify that these logs weren't modified." UMAI solves this with hash-chained audit evidence.

Every audit record includes a SHA-256 hash of the previous record, creating a tamper-evident chain. If any record is modified or deleted, the chain breaks and the tampering is detectable.

Auditors can independently verify the hash chain using UMAI's verification endpoint or by running the verification locally against exported logs.

This is the single feature that has saved our customers the most time in audits. One financial services customer reduced their AI-related audit cycle from 14 weeks to 1 week after deploying UMAI.

Getting Started

If you are preparing for a SOC 2 audit with AI systems in scope, here is what we recommend:

Identify your AI data flows. Map which AI systems process customer data, where prompts come from, and where responses go.

Deploy UMAI inline. UMAI sits between your application and the AI model, so deployment requires a single API endpoint change.

Configure policies. Start with UMAI's compliance templates for SOC 2, then customize for your organization's specific requirements.

Run for at least one audit period. SOC 2 Type II requires evidence over time. The sooner you start logging, the sooner you will have a complete audit trail.