SOC 2 for AI Companies: Scoping Systems, Models, Data, and Evidence

AI companies do not need a separate version of SOC 2. They do need a control environment that accurately reflects how their service uses models, data, infrastructure, and third parties.

The AICPA Trust Services Criteria remain the basis of the examination. Security is the common category, while Availability, Confidentiality, Processing Integrity, and Privacy may be added based on commitments and customer needs. AI-specific risk can affect how those criteria are addressed, but marketing terms such as “responsible AI certified” should not be confused with the scope or conclusion of a SOC 2 report.

Define the system customers rely on

Scoping starts with the service and commitments presented to users. Document the product boundary, infrastructure, people, software, data, procedures, and relevant third parties. For an AI service, this may include:

• customer-facing APIs and applications;
• orchestration and prompt-management layers;
• model gateways and hosted model providers;
• retrieval systems and vector databases;
• training, fine-tuning, and evaluation pipelines;
• annotation or human-review providers;
• observability, abuse monitoring, and support tools;
• data stores for prompts, outputs, feedback, and telemetry.

A diagram alone is insufficient. The system description should explain how components interact, where customer data goes, which controls the company operates, and which controls depend on customers or vendors.

Do not exclude a model provider merely because the company does not host the model. If that provider materially supports the in-scope service, its role and the approach to vendor controls matter. Your auditor can explain how complementary subservice organization controls and carve-out or inclusive methods apply.

Translate AI risk into control objectives

“The model might hallucinate” is a risk statement, not a control. Translate risks into operational outcomes that teams can own and test.

For example, if inaccurate output could affect a consequential workflow, controls may include approved use cases, evaluation thresholds, user warnings, source citations, human review, rollback procedures, and monitoring. If prompt injection could expose restricted data, controls may include tenant isolation, retrieval authorization, input handling, output filtering, testing, and incident detection.

SOC 2 does not guarantee model accuracy, fairness, safety, or regulatory compliance. However, controls around risk assessment, communication, access, changes, monitoring, and incident response can include these risks when they are relevant to service commitments.

Control access across the AI stack

AI architectures create nontraditional privileged paths. Inventory access to production infrastructure as well as:

• model-provider consoles and API keys;
• prompt and evaluation repositories;
• training datasets and feature stores;
• vector indexes and retrieval sources;
• annotation portals;
• experiment tracking and model registries;
• support tools that display prompts or outputs.

Apply least privilege, strong authentication, joiner-mover-leaver processes, service-account governance, and periodic review. CC6.1 is a useful starting point, but operating evidence must reflect the real population.

Secrets in notebooks, environment files, and experiment logs are common failure modes. Centralize secret management, rotate credentials, and monitor use. Ensure production data is not copied into personal workspaces simply because experimentation moves quickly.

Make model and prompt changes traceable

An AI product can change without a conventional application deployment. A vendor may release a new model snapshot. A team may edit a system prompt, retrieval configuration, safety threshold, evaluation set, or routing rule.

Define which changes require review and approval. Keep a trace from request to test results, approval, release, and rollback plan. The rigor should match risk: correcting a typo is not the same as changing a model used in a regulated decision workflow.

Evaluation should be reproducible enough to support the release decision. Record dataset versions, model identifiers, configuration, metrics, known limitations, and approvers. If a third-party model uses a mutable alias, consider pinning a version or monitoring provider changes.

Emergency changes need their own path. Speed may be necessary to contain abuse or an outage, but retrospective review and evidence should still occur.

Govern data through its full lifecycle

State clearly whether customer inputs or outputs are used for training, evaluation, abuse monitoring, or product improvement. Contracts, privacy notices, product settings, and technical behavior must agree.

Classify datasets and document provenance. Track rights and restrictions for licensed, customer-provided, public, synthetic, and internally generated data. Restrict production data in development environments and define when de-identification is appropriate.

Retention controls should address logs, prompts, outputs, embeddings, feedback, fine-tuning files, and vendor copies. Deleting a source record may not remove a derived index automatically. Test the workflow rather than relying on a policy statement.

Assess model and infrastructure vendors

Vendor diligence should reflect the service provided. For model providers, evaluate security documentation, data use and retention terms, subprocessors, hosting locations, incident commitments, access controls, availability history, model-change practices, and exit options.

Collecting a vendor’s SOC 2 report is useful, but review its scope, period, opinion, exceptions, complementary user entity controls, and relevant subservice organizations. A report for a provider’s corporate IT environment may not cover the API your product uses.

Maintain fallback plans proportionate to availability commitments. This might mean retries, model routing, degraded modes, capacity limits, or a documented outage response—not necessarily a second provider.

Prepare AI-aware incident response

Incident scenarios should extend beyond infrastructure compromise. Consider cross-tenant retrieval, sensitive output, leaked prompts, poisoned data, unauthorized model changes, systemic harmful output, provider compromise, and abusive automation.

Define escalation criteria and decision authority. Preserve relevant logs while respecting privacy and retention commitments. Practice at least one scenario involving product, security, legal, privacy, communications, and model engineering.

The team should distinguish a security incident from a model-quality issue while recognizing that one event can be both. Customer notification and regulatory duties depend on facts and contracts, not the label chosen internally.

Build evidence as part of engineering

Evidence is strongest when generated by normal workflows: identity-provider logs, pull requests, deployment records, evaluation runs, access reviews, vendor reviews, incident tickets, and recovery tests. Screenshots assembled before fieldwork are fragile and expensive.

Start with a readiness assessment, identify controls that already operate, and remediate gaps before selecting the examination period. Align the system description with architecture and customer commitments. Teach control owners what evidence will demonstrate operation throughout the period.

A useful SOC 2 program does not slow every experiment. It defines boundaries around consequential changes, sensitive data, privileged access, and service commitments. For an AI company, the central challenge is not adding “AI” to policy titles. It is making a fast-changing technical system observable, governed, and explainable enough that controls can be tested.

Disclaimer: Educational only — not an audit opinion, legal advice, or assurance that any AI system is safe or compliant. Confirm scope and criteria with your independent CPA firm.