What is SOC 2 for AI?

“SOC 2 for AI” is informal shorthand for applying a SOC 2 examination to a service that uses AI. SOC 2 is an established reporting engagement for controls relevant to security, availability, processing integrity, confidentiality, and privacy. It is not a separate official AICPA AI certification, and there is no universal SOC 2 requirement that every AI service use one particular model, evaluation suite, logging format, or fairness metric.

The key question is not simply whether a company uses AI. It is whether the system description and control environment adequately address the risks and commitments relevant to the service being examined. AI can change the risk profile because outputs may be probabilistic, model behavior can change after updates, prompts and retrieved data may contain sensitive information, and external model providers can become critical dependencies.

Here are the important things to note:

• Define the in-scope service, boundaries, AI components, data flows, model providers, and customer commitments.
• Select the Trust Services Criteria relevant to the service. Security is the common baseline, the other categories are included when applicable to the engagement.
• Translate AI-related risks into specific controls with owners, frequency, evidence, escalation paths, and remediation.
• Test controls in operation and retain evidence that is reliable, appropriately protected, and tied to the period under examination.
• Use AI-specific risk frameworks as complementary sources of risk-management practices, not as substitutes for SOC 2.

SOC 2 fundamentals

1. What is SOC 2

SOC 2 is an independent CPA examination and report concerning controls at a service organization relevant to one or more Trust Services Criteria. The report helps intended users understand the service, its system boundaries, controls, and where applicable tests performed and results. The scope and report wording matter: a report is not a blanket certification of an entire company or all of its products.

2. Type 1 and Type 2

3. The system description and boundaries

The system description should accurately explain the service and the system in scope. For an AI-enabled service, consider documenting the user-facing product, APIs, applications, infrastructure, model-serving layer, model and embedding providers, retrieval systems, data stores, monitoring, support processes, relevant people, and subservice organizations. Avoid implying that components are covered by the examination when they are excluded or managed by another party.

4. Complementary user-entity and subservice controls

Some controls depend on customer actions or on controls operated by a subservice organization. Identify these dependencies and explain them clearly. For example, a customer may be responsible for configuring access to its workspace, while the service provider is responsible for enforcing tenant isolation. A cloud or model provider may operate controls on which the service relies, the SOC report should accurately reflect the treatment of those dependencies.

5. What SOC 2 does not prove

• It does not automatically certify that an AI model is accurate, fair, safe, explainable, or suitable for every use case.
• It does not establish universal legal compliance. Legal obligations depend on jurisdictions, data types, contracts, use cases, and applicable laws.
• It does not mean every possible risk has been eliminated, it reports on a defined system, criteria, period or date, and control set.
• It does not prescribe one universal AI logging schema or require unrestricted retention of all prompts and outputs.
• It does not make a vendor’s SOC report proof that the customer’s own configuration, use, or downstream decisions are controlled.

Trust Services Criteria in AI contexts

The AICPA Trust Services Criteria provide the basis for selecting and evaluating relevant controls. The following descriptions are practical summaries, use the official criteria and engagement guidance for authoritative wording and applicability decisions.

Selection is risk- and commitment-dependent. Do not include a category merely because an AI product exists, and do not omit a category that is relevant to the service commitments or system risks. The engagement team determines the applicable criteria and evaluates the evidence.

AI system and risk terms

AI (Artificial Intelligence): A broad term for computational systems performing tasks associated with capabilities such as prediction, generation, classification, planning, or perception.

AI system: A system that uses one or more AI components within a product or workflow, including its data, interfaces, people, infrastructure, and operating processes.

Machine learning (ML): Methods that infer patterns from data to perform tasks such as prediction, classification, ranking, or generation.

Large language model (LLM): A model trained on large-scale data to process or generate language and, in multimodal variants, other content.

Generative AI: AI that generates new content such as text, images, audio, video, code, or structured output.

Foundation model: A broadly trained model that can be adapted or used across multiple downstream tasks.

Model provider: An organization that develops, hosts, or supplies access to a model. Its contractual terms, security posture, and operational controls can affect the service.

Inference: The process of using a trained model to produce a prediction or output from an input.

Prompt: Input instructions or context supplied to a generative model. Prompts may contain confidential information, personal data, or malicious instructions.

System prompt: Higher-priority instructions configured by an application or provider to shape model behavior. It should not be treated as a security boundary by itself.

Token: A unit used by a model to represent text or other input/output elements. Token limits can affect context size, latency, and cost.

Context window: The amount of input and generated content a model can process in a single request. It is not the same as long-term memory.

Embedding: A numerical representation of data used for similarity search, retrieval, clustering, or related tasks.

Vector database: A system that stores vector representations and supports similarity search, it may contain or point to sensitive source data.

Retrieval-augmented generation (RAG): A pattern that retrieves relevant external content and supplies it to a generative model to ground responses in that content.

Agentic system / AI agent: A system that uses model outputs to plan or take steps, sometimes calling tools or changing external state. Tool permissions and action boundaries are important control points.

Tool calling / function calling: A model-mediated request for an application to invoke a defined function or external tool. The application—not the model’s text alone—must authorize and validate actions.

Fine-tuning: Additional training on selected data to adapt a model’s behavior. Dataset provenance, approvals, evaluation, and rollback can be relevant controls.

Training data: Data used to fit model parameters. It may be controlled by the organization, a supplier, or both.

Evaluation dataset: A curated dataset used to test system behavior against defined tasks, risks, or acceptance criteria.

Model card: Documentation describing a model’s intended use, characteristics, evaluation, and limitations. It is useful input, not independent assurance.

Data lineage: A record of where data originated, how it was transformed, where it moved, and how it was used.

Model/version provenance: Information identifying the model, version, configuration, provider endpoint, and related artifacts used for a deployment or decision.

Prompt injection: Malicious or untrusted instructions embedded in user input or retrieved content that attempt to alter system behavior or bypass intended controls.

Jailbreak: An input or interaction pattern intended to circumvent model restrictions or application safeguards.

Data leakage: Unauthorized exposure of sensitive information, whether through model output, logs, retrieval, training, tools, or configuration.

Hallucination / confabulation: A plausible-sounding output that is unsupported, incorrect, or fabricated. The term alone does not define a measurable control objective.

Bias: Systematic differences in model behavior or outcomes. Its significance depends on context, affected groups, use, and consequences.

Fairness: A family of context-dependent objectives about equitable treatment or outcomes, no single metric establishes fairness for every use case.

Explainability / interpretability: Methods for making aspects of a system’s behavior understandable. The appropriate level depends on the system and decisions involved.

Robustness: Ability to behave acceptably under expected variation, edge cases, perturbations, or adversarial inputs.

Drift: Change over time in data, environment, or model behavior that may reduce performance or invalidate assumptions.

Human-in-the-loop (HITL): A workflow in which a person reviews, approves, or can intervene in model-assisted processing or actions.

Guardrail: A technical or procedural measure intended to constrain inputs, outputs, or actions. A guardrail should be tested and monitored, not assumed effective.

Red teaming: Structured adversarial testing intended to discover weaknesses, misuse paths, or harmful behavior.

Evaluation / eval: A repeatable assessment against defined tasks, datasets, criteria, and thresholds. Results are meaningful only relative to their design and limitations.

Output validation: Checks applied to model outputs before use, such as schema, policy, authorization, factual support, or domain-specific validation.

Least privilege: Granting only the permissions needed for a role, service, or process, for the required period.

Tenant isolation: Controls that prevent one customer or tenant from accessing another tenant’s data, context, files, or results.

Subservice organization: A third-party organization whose services or controls are part of the service organization’s system or control dependencies.

Complementary user-entity controls (CUECs): Controls expected to be implemented by customers or user entities for the service organization’s controls to achieve their intended objectives.

Control owner: A person accountable for operating a control and maintaining evidence that it operated as designed.

Control evidence: Records that support whether a control was designed and operated as described, such as approvals, tickets, logs, test results, and configuration snapshots.

Exception / deviation: A case in which a control did not operate as expected or evidence shows a departure from the defined procedure, it should be assessed, documented, and remediated as appropriate.

System boundary: The defined people, processes, technology, data, and locations included in the description and scope of the examination.

Type 1 report: A SOC 2 report addressing the suitability of control design at a specified date.

Type 2 report: A SOC 2 report addressing design and operating effectiveness over a specified period.

Trust Services Criteria (TSC): AICPA criteria covering Security and, when relevant, Availability, Processing Integrity, Confidentiality, and Privacy.

NIST AI RMF: NIST’s voluntary AI Risk Management Framework intended to help organizations manage AI risks throughout design, development, deployment, use, and evaluation.

ISO/IEC 42001: An international standard specifying requirements for an AI management system, including establishing, implementing, maintaining, and continually improving that system.

Governance, security, and operational controls

1. Governance and accountability

• Assign accountable owners for the AI-enabled service, model integrations, data processing, risk acceptance, security, privacy, and incident response.
• Maintain an inventory of AI use cases and components: purpose, owner, data categories, model/provider, tools, deployment environment, criticality, and review date.
• Define approval gates for new AI features, material model changes, new data uses, new tool permissions, and high-impact workflow changes.
• Create an exception process with documented rationale, approving authority, expiry or review date, and compensating measures where appropriate.
• Provide role-appropriate training on data handling, acceptable use, prompt injection, output limitations, and escalation.

2. Identity, access, and secrets

• Use unique identities, strong authentication, role-based access, least privilege, and periodic access reviews for model consoles, APIs, datasets, vector stores, and evaluation systems.
• Store API keys and service credentials in approved secrets-management systems, prohibit hard-coded credentials and rotate/revoke credentials according to risk and policy.
• Separate production from development and testing, limit access to production prompts, customer data, model configuration, and logs.
• Authorize tool calls server-side. Validate the user, tenant, requested action, and target resource before executing any model-proposed operation.

3. Data governance and privacy

• Classify data and identify personal, confidential, regulated, customer-provided, and proprietary information before it enters prompts, retrieval indexes, training, or evaluation.
• Document purpose, lawful basis or other applicable authority where required, retention, access, deletion, and provider-sharing arrangements.
• Minimize prompt and context data. Redact or tokenize sensitive fields where feasible, do not retain full prompt/output content by default without a defined need and approved retention rules.
• Validate tenant boundaries and retrieval permissions at query time. Do not rely solely on model instructions to prevent cross-tenant disclosure.
• Assess whether providers use submitted data for training, how long they retain it, where it is processed, and how deletion and incident notifications work.

4. Secure development and change management

• Use code review, testing, dependency scanning, secrets scanning, vulnerability management, and approved deployment pipelines for AI application code.
• Version prompts, model identifiers, retrieval configuration, safety settings, tool definitions, evaluation datasets, and policy rules where practical.
• Require risk-based review and approval before production changes, document tests, approver, deployment time, rollback path, and post-deployment checks.
• Protect training and evaluation datasets from unauthorized modification. Record provenance and access, and use integrity checks against trusted references when appropriate.

5. AI-specific testing and monitoring

• Define task-specific acceptance criteria and evaluate representative normal, edge, and adversarial cases before release.
• Test relevant failure modes such as prompt injection, unauthorized tool use, sensitive-data leakage, malformed output, retrieval access errors, and unsafe fallback behavior.
• Monitor operational indicators such as errors, latency, timeouts, token usage, cost, provider availability, and relevant output-quality or safety indicators.
• Re-evaluate after material changes to models, prompts, retrieval corpora, policies, tools, data distributions, or provider behavior.
• For consequential outputs, use domain-appropriate validation and human review where warranted, record reviewer responsibility and escalation criteria.

6. Availability and resilience

• Map critical dependencies and define recovery objectives appropriate to service commitments.
• Test backup, restoration, disaster recovery, failover, rate-limit handling, and queue recovery where applicable.
• Design bounded retries, timeouts, circuit breakers, quotas, and safe degraded modes to prevent cascading failures or uncontrolled costs.
• Assess whether alternate models or providers can be used safely, verify that fallback behavior does not silently change important output or data-handling properties.

7. Incident response

• Extend incident playbooks to include prompt injection, unauthorized tool actions, model-provider compromise or outage, data leakage through output, poisoned or compromised retrieval content, and unexpected model changes.
• Define triage, containment, evidence preservation, escalation, customer communication, regulatory assessment, and recovery responsibilities.
• Conduct exercises using realistic AI scenarios and record lessons learned, corrective actions, owners, and closure evidence.

8. Vendor and subservice risk

• Perform risk-based due diligence on model, cloud, data, monitoring, and evaluation providers, including independent assurance reports where available.
• Review contract terms for data use, retention, deletion, confidentiality, access, security incidents, service availability, model changes, and audit or assurance information.
• Map provider responsibilities and dependencies to the organization’s own controls, track exceptions and reassess critical providers periodically.
• Do not treat a provider’s SOC report or marketing statement as proof that all AI-specific risks or the organization’s own controls are covered.

Illustrative risk-to-control mapping

This table is a planning aid, not an official AICPA mapping. Confirm the applicable criteria and control design with the engagement team. A single control may support multiple criteria, and the same risk can require several controls.

Potentially relevant criteria are suggestions only. Applicability depends on the service, commitments, risk assessment, system description, and engagement scope.

Evidence and audit-trail design

1. Evidence quality principles

• Relevant: directly supports the control objective being tested.
• Attributable: identifies the system, environment, actor or service identity, and event where appropriate.
• Time-bound: includes timestamps and relates to the period or date in scope.
• Complete enough: includes context needed to interpret the record, without claiming that a partial record proves more than it does.
• Protected: access is restricted and retention is defined, evidence is not casually editable by the same people whose actions it records.
• Minimized: captures only the sensitive content needed for the control purpose and uses redaction or metadata where feasible.

2. Useful event fields

There is no universal SOC 2-mandated AI event schema. The following fields are a practical design starting point, choose them based on risk, privacy, cost, system architecture, and investigation needs.

3. Evidence examples by control

4. Avoid evidence overcollection

Capturing every prompt and output can create a secondary sensitive-data repository and may conflict with minimization, confidentiality, or retention commitments. Prefer event metadata and outcome records where they adequately demonstrate control operation. If content capture is necessary, document the purpose, access restrictions, encryption, retention period, redaction strategy, and deletion process.

AI lifecycle and third-party risk

1. Lifecycle checkpoints

2. Third-party and model-provider assessment

Assess the provider in the context of the actual integration. Questions can include what data is transmitted, whether inputs or outputs are retained or used for training, the provider’s access and incident practices, where processing occurs, how model changes are communicated, what availability commitments exist, how deletion works, whether assurance reports cover the relevant service, and what happens if the provider is unavailable or terms change. Record answers, contractual commitments, gaps, risk decisions, and reassessment dates.

3. AI risk frameworks alongside SOC 2

Implementation roadmap

• Set scope: Identify the product, service commitments, system boundary, AI use cases, data flows, environments, providers, and subservice dependencies.
• Select criteria: Work with compliance and the independent CPA firm to determine which Trust Services Criteria are relevant and how the system will be described.
• Inventory risks: Record AI-specific and conventional risks, including access, confidentiality, privacy, processing correctness, availability, third-party dependency, and change risk.
• Map controls: For each risk, define the objective, control activity, owner, frequency, system of record, evidence, exception handling, and related commitments.
• Implement minimum viable evidence: Make control operation observable. Use tickets, access reviews, deployment records, monitoring, and evaluation reports that can be reproduced and traced.
• Run a readiness review: Sample controls internally, identify gaps, validate evidence completeness, and remediate before the examination period or requested testing.
• Operate and monitor: Keep evidence current, review exceptions, track remediation, and reassess material AI or provider changes.
• Coordinate with the auditor: Confirm the scope, requested evidence, sampling approach, system description, treatment of subservice organizations, and examination timing.
• Improve after reporting: Track findings and changes in architecture, providers, data use, customer commitments, and applicable requirements.

Control specification template

Working checklists

1. Scope and inventory

• System boundary and service description are current.
• AI components, models, prompts/configuration, data stores, tools, and providers are inventoried.
• Data flows and tenant boundaries are documented.
• Relevant customer commitments and Trust Services Criteria are identified.
• Subservice dependencies and customer responsibilities are described.

2. Control readiness

• Each control has an owner, frequency, evidence source, and exception process.
• Access and privileged access are reviewed and evidenced.
• Production changes are approved, tested, traceable, and reversible where appropriate.
• AI evaluations are tied to defined use cases and acceptance criteria.
• Monitoring, incident response, and recovery procedures include relevant AI failure modes.
• Provider due diligence and reassessment are documented.
• Evidence is protected, time-bound, relevant, and retained according to policy.

3. Before the examination

• Confirm period, system scope, criteria, and requested evidence with the CPA firm.
• Perform internal sample testing and resolve avoidable evidence gaps.
• Prepare accurate descriptions of controls, architecture, data flows, and dependencies.
• Track exceptions and remediation without rewriting historical evidence.
• Make limitations and out-of-scope components clear, do not imply broader assurance than the report provides.

Frequently Asked Questions

1. Is “SOC 2 for AI” a separate official certification?

No. It is commonly used informally to describe SOC 2 readiness or examination for a service that uses AI. The engagement remains grounded in applicable SOC 2 requirements and Trust Services Criteria.

2. Does SOC 2 require every AI company to measure bias?

There is no universal rule that every AI service must use one specific bias metric. The organization should assess relevant risks, commitments, and applicable requirements, some use cases may need defined fairness or impact evaluations.

3. Must every prompt and response be logged?

No universal SOC 2 rule mandates full prompt/output logging. Choose evidence that supports the control objectives while respecting confidentiality, privacy, minimization, and retention requirements.

4. Does a model provider’s SOC 2 report cover my application?

Not automatically. Review the exact service, scope, report period, criteria, exceptions, subservice treatment, and complementary user-entity controls. Your own integration and configuration remain your responsibility.

5. Can SOC 2 prove that model outputs are true?

No. SOC 2 is not a guarantee of factual correctness. Output validation and task-specific evaluation may support processing-integrity objectives when relevant to the service commitments.

6. Can an organization use NIST AI RMF instead of SOC 2?

They serve different purposes. NIST AI RMF is a voluntary risk-management framework, SOC 2 is an independent examination and report against applicable criteria.

7. Does ISO/IEC 42001 replace SOC 2?

No. ISO/IEC 42001 specifies an AI management-system standard, while SOC 2 examines controls for a defined system against selected Trust Services Criteria. They can be used together.

8. Do hashes make audit logs tamper-proof?

A hash can help detect changes when compared with a trusted reference, but it does not by itself establish completeness, authenticity, or truthful event capture. Combine integrity measures with access controls, trusted timestamps, protected storage, and monitoring.

9. Should every AI decision require human approval?

Not universally. Human review should be determined by risk, consequence, commitments, and applicable requirements. Where used, define reviewer authority, criteria, escalation, and evidence.

10. What if a model is updated by the provider without notice?

Document the dependency and provider terms, monitor behavior and service notices where possible, evaluate material changes, and define mitigation or rollback options. The available level of version control varies by provider.

‍