SOC 2 for AI companies, model-aware.
AI startups have audit exposure traditional firms don't understand: foundation-model sub-processors, training-data controls, prompt logging, and vector-store isolation. Skadi is built for it. Our senior CPAs scope around model architecture, and we audit with a privacy-first local model so your evidence never leaves for a third-party LLM.
Audit challenges we solve for you.
Every hosted LLM you call is a sub-service org. Your system description, security review, and monitoring evidence must reflect that — and buyers now ask specifically about enterprise-tier data terms.
Customer data used for embeddings, RAG, or fine-tuning creates retention, lineage, isolation, and deletion obligations most SOC 2 templates miss entirely.
You sell privacy to customers, then hand screenshots and logs to auditors using public LLMs. Skadi's local-model audit closes that gap by design.
Prompts, model versions, and eval suites change weekly. Change-management controls that were fine for a stable app fail here without adaptation.
Controls that matter most for your business.
Who can call production models, deploy new prompts, or change fine-tunes. Role-based access, approvals, and audit trails on model gateways.
Data lineage, classification, opt-out handling, and deletion evidence — especially for tenants who contractually forbid their data being used for training.
Namespace or per-tenant index partitioning, prompt-context isolation, and evidence one customer's embeddings cannot surface in another's session.
Policy, technical enforcement, and retention windows aligned to customer contracts; access controls on logs that may contain sensitive inputs; scheduled deletion evidenced.
Formal inventory of OpenAI, Anthropic, Pinecone, Weaviate, and every inference/vector vendor — with DPA, enterprise-tier data terms, security review, and monitoring evidence.
Approvals and rollback for prompt changes, model version bumps, and eval-gated releases — the fastest-changing surface in an AI company, and the one auditors most often find under-controlled.
Documented evaluation cadence for safety, bias, and jailbreak resistance where contractually promised, with release gating evidenced from CI.
Deletion propagated to embeddings, fine-tune datasets, cached prompts, and evaluation corpora — not just the source database.
What actually fails in this vertical.
Real deviations we see in SOC 2 Type II fieldwork — and what your platform and security teams should fix before the observation window starts.
Production traffic routed through OpenAI/Anthropic default terms where inputs may be retained. Enterprise/zero-retention tier not enabled — the single most-cited AI-specific finding in 2025.
- Executed enterprise/zero-retention agreement with each model vendor
- Screenshot of API org settings showing zero-retention flag enabled
- Egress config or model-gateway policy pinning production to the enterprise endpoint
- Sub-processor register listing each model vendor + data-handling tier
Single Pinecone/Weaviate index storing embeddings for multiple customers with only application-layer filtering. One query bug and you have a cross-tenant leak — auditor calls this a design deficiency.
- Architecture diagram showing per-tenant namespace / index
- Terraform or vector-DB config snippet enforcing tenant filter
- Automated isolation test in CI with passing run logs
- Threat model doc covering cross-tenant retrieval risk
Contract promises 30-day deletion; logs sit in an S3 bucket for a year because no lifecycle rule was set. Deletion must be technical, scheduled, and evidenced.
- S3 lifecycle policy / log-store retention config
- Retention policy document referencing customer commitments
- Sample deletion-job log for the window
- MSA/DPA excerpt with the committed retention window
Opt-out flag exists in the app DB but the training pipeline reads a raw dump that ignores it. Data-lineage control fails on first walkthrough.
- Data-lineage diagram from source to training corpus
- Pipeline code / DAG showing opt-out filter
- Sample training-dataset manifest with opt-out counts
- Ticket for opt-out reconciliation run during the window
Prompts edited directly in a config dashboard, no PR, no reviewer, no rollback plan. Change management (CC8.1) exception on nearly every AI startup's first audit.
- Git history for prompts/model configs under version control
- PR with reviewer approval + CI evals passing
- Change-management policy covering prompts and model versions
- Rollback runbook with a recent execution log
Safety and regression evals exist but running them is not enforced in CI. Marketing claim exists ('we test for jailbreaks'); control to back it does not.
- CI workflow file with required eval job (branch protection references it)
- Eval report artifact for a sampled release
- Written eval policy with pass/fail thresholds
- Release ticket linking to eval artifact and approver
Why traditional auditors miss the risk
Most audit firms wrote their SOC 2 playbooks before generative AI existed. They treat an inference API as 'just another SaaS vendor' and miss the actual risks: training-data leakage, prompt injection into logging pipelines, and customer contracts that forbid third-party model training. Skadi's methodology was rebuilt around modern AI architecture from the ground up.
The AI-company evidence problem
AI companies face a specific paradox at audit time: they sell privacy and data protection, then are asked to upload screenshots and system exports to consultants who process them with public LLMs. Skadi's audit is performed by a local model running inside the audit environment. Evidence stays put, and the CPA reviews it in place — the same posture your customers demand of you.
Enterprise readiness for AI buyers
Enterprise procurement is now asking AI vendors questions no one asked two years ago: model provenance, training opt-outs, prompt logging retention, tenant isolation on vector stores, and deletion in embeddings. A SOC 2 Type II report that speaks to those specifically — instead of pretending the AI layer doesn't exist — is a practical way to unlock those deals.
Preparing for ISO 42001 and AI-specific frameworks
ISO/IEC 42001 (AI management systems) and the NIST AI RMF are becoming the next enterprise ask. We scope SOC 2 so the same governance, risk-assessment, and monitoring evidence extends cleanly to a 42001 program later. One control library, multiple attestations — instead of duplicated work across frameworks.
Questions we hear from teams like yours.
Ready to scope your SOC 2 Type II?
Book a call and we'll walk you through timeline, scope, and pricing for your company.