Does a SOC 2 Type II report on the AI vendor satisfy the deployer's due care obligation?

The vendor's SOC 2 report attests to the vendor's controls. The deployer's obligation runs on the deployer's side of the request boundary. The deployer's controls on the requests the deployer's users issue against the vendor's API are the deployer's responsibility, and the deployer's per-decision evidence is what the deployer's auditor and the regulator read.

What is the difference between the vendor's audit logs and the inspection layer's audit records?

The vendor's audit logs describe the vendor's processing of the deployer's requests. The records carry the vendor's view of the request: the API method, the response status, the latency, the deployer's API key identifier. The inspection layer's records describe the deployer's view: the verified subject, the classifier output, the policy decision, the integrity metadata. The two record series answer different questions and the deployer needs both.

Can the deployer write the per-decision records inside the application itself?

The application can write records, but the records suffer from the self-attestation problem. The same application that makes the decision and writes the record can rewrite the record after the fact. The integrity guarantee the regulator expects has to come from a layer the application cannot rewrite. The inspection layer's write-path independence is the property that distinguishes a defensible record from an application-side log.

How does the inspection layer handle records the deployer wants to retain for the EU AI Act six-month minimum?

The layer ships records to durable, append-only storage with the integrity metadata bound to the entry. The retention window is configurable through the storage policy. The EU AI Act Article 12 six-month minimum is a floor, not a ceiling. Deployments that need longer retention (HIPAA's six-year minimum, DORA's lifetime obligation for operational events) configure the storage accordingly.

What happens during an audit when the regulator requests records for a specific user across a specific date range?

The deployer queries the inspection layer's record store for the user identifier and the date range. The records return with the per-decision evidence the regulator expects. The integrity metadata accompanying each record lets the regulator's auditor verify the chain from a known anchor point. The deployer produces the export with the cryptographic proofs the auditor's working papers reference.

Due Diligence Is Not Due Care: The AI Compliance Gap That Closes at the Request Layer

A common conversation pattern shows up in AI procurement reviews. The buying organization runs a vendor questionnaire on the AI vendor, reads the SOC 2 Type II report, signs the master services agreement with the BAA addendum, and treats the diligence file as complete. The deployment ships, the agents start producing decisions, and the compliance team treats the program as covered because the vendor file is in order. Eighteen months later a regulator asks for the per-decision evidence on a specific request from a specific user on a specific date, and the deployment cannot produce the record because the diligence file the team built is the procurement check, not the operational artifact. Due diligence is not due care.

I want to walk through the legal distinction between diligence and care, the regulatory regimes that depend on it, the operational evidence due care actually requires, and the request-layer architecture that produces the evidence on demand.

The legal distinction

Due diligence is the duty to investigate before entering a transaction. The diligence file is the record of the investigation: the vendor questionnaire, the third-party attestation reports, the contract clauses that allocate risk, the legal review of the vendor's data handling. The duty runs once, at the procurement gate, and again at renewal.

Due care is the duty to operate with the standard of attention a reasonable practitioner of the deployer's profession would apply. The duty runs continuously across the operating life of the system. The evidence due care produces is the per-decision record of the operation: who acted, what the inputs were, what the policy state was, what the outcome was, and the integrity proof that the record was written at decision time.

The diligence record is a paper artifact. The care record is a runtime artifact. The two records answer different questions. The diligence record answers "did the deployer investigate the vendor at the moment of the contract." The care record answers "did the deployer operate the system inside the policy across every decision the system produced."

Courts and regulators have treated the distinction as load-bearing for a long time. The 1972 Caremark line of cases established that directors owe a duty of care that runs continuously and depends on the existence of information systems that surface the operational state of the enterprise. The 2026 application of the same line of reasoning to AI deployments expects the deployer to maintain information systems that surface the per-decision state of the AI system at the moment of the decision.

The regulations that depend on the distinction

EU AI Act Article 12 expects automatic recording of events over the lifetime of the system. The clause is care language, not diligence language. The diligence the deployer ran on the model provider does not satisfy the clause. The recording that runs at decision time does.

NIST AI RMF MANAGE 1.3 expects evidence of action lineage for AI decisions. The framework names the diligence inputs separately (third-party attestation, vendor risk assessment) and the care outputs separately (per-decision evidence). The crosswalk between the two is the record series the deployment produces at runtime.

HIPAA 45 CFR 164.312 expects audit controls that record system activity for systems that handle PHI. The Business Associate Agreement covers the diligence side. The audit controls cover the care side. A BAA without audit controls does not discharge 164.312.

Fannie Mae LL-2026-04 expects per-decision evidence for AI-assisted lending decisions, with the lender producing the records on demand. The vendor file the lender holds on the AI vendor does not satisfy the per-decision requirement.

DORA Article 28 expects financial entities to maintain operational resilience evidence on the ICT third-party services they depend on. The diligence on the model provider is one part. The per-decision operational records the entity produces are the other part.

SOC 2 Type II's processing-integrity criterion expects evidence that the system processed inputs completely and accurately across the audit period. The vendor's own SOC 2 report covers the vendor's processing integrity. The deployer's SOC 2 report has to cover the deployer's processing integrity, which means the per-decision records the deployer produces.

What due care evidence actually contains

Due care evidence is a per-decision record of seven fields the regulator and the customer auditor consume.

The identity field carries the verified subject identifier (the natural person, the agent identity, the service account) and the verification method. The field answers the regulator's question "who issued this request."

The route field carries the route identifier (which application, which model endpoint) and the policy bundle binding active at the moment of the request. The field answers the question "which policy applied."

The data classification field carries the inspection layer's classifier output on the prompt and the retrieved context. The field answers the question "what data did the request expose to the model."

The policy version field carries the version hash of the policy bundle the decision point read. The field makes the decision reproducible. A regulator with the same inputs and the same policy version produces the same decision.

The decision outcome field carries pass, block, or modify with the rule identifier that produced the outcome and the reason code. The field answers the question "what did the policy decide."

The model and version field carries the upstream LLM identifier the request forwarded to. The field answers the question "which model handled this request."

The integrity metadata field carries the cryptographic signature on the record, the chain hash to the prior record, and the trusted timestamp. The field answers the question "was this record written at decision time, and has it been altered since."

The seven fields compose a record schema the EU AI Act, NIST AI RMF, HIPAA, DORA, Fannie Mae, and SOC 2 reviewers all read the same way.

Why the application's own logs do not produce due care evidence

The application that makes the AI decision can write logs about what the application did. The application's logs are self-attestation: the application both produces the decision and writes the record of the decision. The structural problem is that an attacker who controls the application also controls the record. The reviewer's question "how do you know this record was not edited after the decision was made" has no defensible answer.

The application's logs also tend to omit the policy version, the classifier output, the identity verification method, and the integrity metadata. The application's developers added the logs to support troubleshooting, not regulatory evidence. The fields the application logs include serve the developer's needs, not the regulator's.

The diligence path that procurement runs on the application vendor does not change the structural problem. A vendor's SOC 2 report attests to the vendor's controls. The deployer's evidence obligation runs on top of the vendor's controls, not as a substitute.

The request-layer architecture that produces due care evidence

The architecture places an inspection layer at the HTTP boundary between the application and each upstream the application calls. The layer reads the prompt, the retrieved context, the model identifier, and the identity the application propagates. The layer evaluates identity-aware policy and commits the per-decision record before the response forwards.

The layer is decoupled from the application. The application cannot rewrite the records the layer commits because the layer's write path is independent. The signing keys live in an HSM or KMS service the application cannot access. The chain hash binds each record to the prior record so the regulator's replay catches any later mutation.

The layer commits records that are interoperable across regimes. A single record series satisfies EU AI Act Article 12, DORA Article 19, HIPAA 45 CFR 164.312, NIST AI RMF MANAGE 1.3, Fannie Mae LL-2026-04, and ISO 42001 from the same pipeline. The deployer maintains one record schema rather than one per regime.

The procurement workflow that bridges diligence and care

A procurement workflow that produces both diligence and care evidence runs in three steps.

The diligence step is the existing procurement gate. The vendor questionnaire, the SOC 2 report, the BAA addendum, and the legal review of the contract. The artifacts populate the diligence file.

The care step is the inspection layer deployment. The deployer places the layer in front of every AI endpoint the application calls and configures the policy that governs the decisions. The policy bundle, the classifier configuration, and the record schema land in the change-management system.

The bridge step is the audit pre-rehearsal. The deployer runs a sample of historical requests against the layer and confirms the records satisfy the audit questions a regulator or a customer auditor would ask. The pre-rehearsal surfaces the gaps before the regulator does.

The three steps move the program from a diligence-only posture to a care posture without abandoning the diligence work. The diligence file remains the input. The care records become the output the regulator consumes.

DeepInspect

This is the gap DeepInspect closes for AI deployments that need due care evidence. DeepInspect sits inline at the HTTP boundary between the application and each upstream the application calls. The inspection layer reads the prompt, the retrieved context, the response, and the identity the application propagates. It evaluates identity-aware policy and commits per-decision audit records to durable, append-only storage with a cryptographic integrity signature.

The record series carries the seven fields the diligence file does not include: the verified subject identifier, the classifier output, the policy version, the decision outcome, the model identifier, the integrity metadata, and the rule identifier. The series satisfies EU AI Act, DORA, HIPAA, NIST AI RMF, Fannie Mae LL-2026-04, and ISO 42001 record-keeping obligations from a single pipeline. If you are running an AI deployment and the diligence file the team built does not produce the per-decision evidence the regulator will ask for, let's talk today.