Cohere Compliance: Match Evidence to the Deployment Route

Cohere compliance starts with one deployment question: where does inference run? The answer changes who can access prompts and generations, which published retention statements apply, and which evidence belongs in the provider file. A private deployment and a third-party cloud AI service create data paths that differ from the Cohere SaaS Platform.

The enterprise still owns a second file. That file proves the approved use case and acting identity. It also records the content classification, model destination, policy decision, and operating tests for any request path the enterprise controls.

TL;DR

• Cohere says it receives no customer prompts or generations in private deployments or deployments on third-party cloud AI and ML platforms.
• Cohere's SaaS commitments describe training choice and security monitoring. They also cover logged prompt and generation retention, exceptions, and approved zero-data-retention arrangements.
• Provider certifications and policies support due diligence. Enterprise approval and routing rules require separate evidence, as do request decisions and tests.
• DeepInspect covers deliberately routed HTTP traffic between authenticated users or agents and LLM endpoints. Cohere internals and traffic outside that route remain out of scope.

Deployment determines the evidence boundary

Cohere's Enterprise Data Commitments distinguish private and third-party platform deployments from the Cohere SaaS Platform. For private deployments and deployments on third-party cloud AI and ML platforms, Cohere says it receives no customer inputs or outputs. The same page says enterprises can bring Cohere models along with North and Compass to private infrastructure or third-party platforms, while the SaaS option runs on Cohere-managed infrastructure.

That distinction should appear on the first page of the compliance file. Record the exact deployment type and service. Name the cloud account or private environment and region. Add the endpoint, model, and contract. Add the network path and administration owner. Preserve the date of the review.

A label such as "Cohere enterprise" is too broad because it leaves data custody ambiguous. Two teams can use the same model family under different access and retention conditions. The AI vendor risk assessment template provides the procurement structure. Cohere deployment evidence supplies the vendor-specific facts that complete it.

The SaaS data controls need their own baseline

For the Cohere SaaS Platform, the Enterprise Data Commitments say customers can opt out of having prompts and generations used to train Cohere models through Data Controls in dashboard settings. The page says the change applies to data created after the setting changes. That timing belongs in the evidence file alongside the captured setting.

The same source says Cohere logs and monitors SaaS use for customer-agreement and Usage Policy compliance and for security risks to the service. Its safety and security teams may review prompts and generations along with logs after possible misuse is detected. The page also describes aggregation of flagged content after customer identifiers are removed for safety evaluation and policy enforcement.

Capture the current Data Controls state and the account or organization identifier. Add the administrator who can change the setting and the date it was checked. Preserve the applicable commercial agreement and Data Processing Addendum where personal information is involved. A screenshot becomes useful when it is joined to a configuration owner and a review record.

My opinion is that "training disabled" deserves one line in a control file, while the deployment route and request authorization deserve the next ten.

Retention claims require the exceptions beside them

Cohere's published SaaS commitment says logged prompts and generations are automatically deleted after 30 days. It lists exceptions for a legal requirement or customer contract. Another exception covers usage flagged as potentially violating Cohere terms, including the Usage Policy. Data allowed for training may be retained separately under the customer agreement.

The same source says approved zero-data-retention arrangements result in Cohere logging no customer prompts or generations. Its FAQ distinguishes prompt and generation data from log data and usage data. It describes log data such as organization identifiers and action dates. Usage data can include frequency, duration, accessed features, preferences, and aggregate input-token counts.

Write the full statement into the control description. "Thirty-day retention" by itself drops the exceptions and adjacent metadata categories. "Zero retention" also needs the approval record and contract scope. Ask which services and accounts the arrangement covers, then test the configured route.

On the evidence desk, place the retained policy printout beside the contract clause. Highlight each exception in yellow. The visual forces the reviewer to reconcile public language with the customer's actual terms before signing the control.

Privacy documents separate enterprise data from account data

Cohere's Privacy Policy, last updated May 1, 2026, distinguishes people according to how they use the service. Separate treatment applies to enterprise accounts and application end users. Trials and research participants also receive separate treatment. Customer Data, defined there as inputs and outputs associated with Enterprise Users under an enterprise agreement, is governed by the enterprise agreement and any applicable Data Processing Addendum. Enterprise customers are directed to the separate Enterprise Data Commitments.

The policy also says Cohere generally acts as processor or service provider for end-user data in applications built by enterprise customers. The enterprise application provider remains the source of the privacy notice for those end users. For private and third-party deployments, the policy says Cohere lacks access to the data processed through the models or products in those environments.

These statements help assign documents and roles. Record the controller and processor analysis for the actual use. Keep the DPA and subprocessor material with the transfer mechanism and end-user notice under legal and privacy ownership. The enterprise remains responsible for purpose, collection, disclosure, access, correction, retention, and deletion decisions that apply to its use case.

Security attestations support provider due diligence

Cohere's security page says its hosted API platform is SOC 2 Type II compliant. It also says Cohere performs annual third-party audits and penetration tests. Cohere uses threat detection to monitor suspicious activity. The page links to Cohere's Trust Center for reports and other compliance resources.

For private deployment, the security page says Cohere can deploy through a VPC or on premises, including through Cohere-managed Model Vault. It says customers can customize security configuration and that Cohere lacks access to customer computing infrastructure or data in private deployments. For third-party cloud deployments, the page says the models can run on OCI, Azure, AWS, and Google Cloud Platform, with the platform's security standards and certifications forming part of the control environment.

Collect the report that matches the service and review period in scope. Record exceptions and complementary customer controls. An attestation supports provider assurance. It gives no proof that a payroll analyst was permitted to include employee bank details in one prompt.

The enterprise request file proves authorized use

Create a separate operating file for every approved use case. Name the business owner and technical owner. State the purpose and users. Record roles, input and output data classes, Cohere model and endpoint, deployment route, downstream actions, and prohibited uses. Link the file to vendor evidence instead of copying provider claims into every control.

For each enterprise-controlled request path, preserve these fields:

• correlation identifier and timestamp;
• authenticated user or agent identity supplied by the application;
• role and approved use-case identifier;
• prompt and response classifications;
• Cohere model and endpoint, plus deployment type and destination region;
• policy version and permit, redact, block, or escalation outcome;
• record signature or integrity evidence;
• application transaction or workflow identifier.

The AI request authorization model explains the decision context at this boundary. The AI data classification guide provides the content categories needed to turn a policy sentence into an executable rule.

Sample one permitted request and one prohibited request with synthetic data. A provider document describes the service. The paired tests prove how the enterprise used it.

Model and route changes reopen the review

Cohere compliance evidence needs event-based review. A move between SaaS and Model Vault changes the data path and control inheritance. The same applies to a move into a customer VPC, on-premises infrastructure, or a third-party cloud platform. A new region or endpoint can change transfer and residency analysis. A new model may change quality and safety tests as well as performance tests.

Other triggers include a Data Controls change and a new zero-data-retention approval. A revised contract, DPA update, subprocessor change, and Trust Center report covering a new period also trigger review. Add new use cases and roles to the trigger list. Include new data classes, connectors, and downstream actions. A routing layer that selects models dynamically also needs review because a stable application endpoint can hide a changed destination.

Require change approval and regression evidence before production release. Preserve the previous policy version and the first decision record under the new version. The AI governance audit framework supplies the wider cadence for provider review and operating tests, including findings and closure.

Runtime controls differ by deployment model

A private deployment places more infrastructure operation with the customer. The enterprise owns cloud or on-premises access, network routes, secrets, encryption, capacity, logging, patching, and recovery according to the selected architecture. Cohere's lack of access to prompt and generation data reduces one provider-access path while increasing the customer evidence burden.

A third-party cloud platform divides the record between the enterprise and cloud provider, with Cohere documentation supplying another part. The customer should identify which service logs show model invocation and which identity reaches the endpoint. It should also identify which regions or accounts process the request. The cloud agreement and service configuration become material evidence.

The Cohere SaaS route relies more heavily on Cohere-hosted controls and published data commitments. The enterprise still owns its user access and API-key custody. It also owns use-case approval, prompt policy, downstream actions, and request evidence. Put each control beside the party and system that operates it. Shared responsibility becomes auditable only after every requirement has one evidence source.

Monitoring should reconcile policy with observed traffic

Review the approved-use register against observed Cohere destinations and models. Look for unknown API keys, accounts, projects, endpoints, or model versions. Sample requests for expected identity and classification. Check the policy version and decision outcome. Review blocks and exceptions for repeat patterns.

Provider evidence needs monitoring too. Track Cohere policy and commitment revisions along with Trust Center report periods. Track contract changes, DPA updates, and subprocessor notices. Recheck the Data Controls setting and any zero-data-retention approval on a defined schedule. Keep proof of the review and assign findings.

A compliance dashboard can show counts, but sampled traces establish control quality. Select a permitted request and a refused request. Then select a configuration change. Follow each into approval and evidence. Missing identity or an unexplained destination should open remediation. A change without a matching review should reopen the use-case assessment.

The HTTP boundary stays explicit

DeepInspect can cover a Cohere request when an enterprise deliberately routes authenticated HTTP traffic through the gateway before the Cohere endpoint. The application supplies identity and role. The gateway can classify prompt and response content and evaluate destination and model authorization. It can also apply versioned policy and record the decision.

Traffic sent directly to Cohere outside that route remains beyond the gateway's visibility. Native activity inside Cohere products may follow a provider-controlled path. Model training and provider administration require Cohere evidence. Cohere safety review and service operations also require Cohere evidence. Private infrastructure security remains with the customer and its cloud or data-center controls. Local inference and STDIO tool calls also sit outside the HTTP boundary.

The gateway also leaves source-data permission and model-output accuracy with the enterprise. Human review and downstream business decisions remain there as well. State those boundaries in the architecture diagram and control register. A clear line gives auditors an honest answer and exposes any path that still lacks an owner.

DeepInspect

DeepInspect sits inline on deliberately routed HTTP traffic between authenticated users or agents and Cohere endpoints. It evaluates application-supplied identity and role with content classification. Model destination and versioned enterprise policy enter the same decision. The resulting action can permit, redact, block, or escalate before forwarding the request or returning the response.

Each decision produces a signed, tamper-evident record outside the calling application's write path. That record strengthens the enterprise operating file for routed Cohere traffic. It can join to provider attestations and deployment configuration, plus approval history. Cohere service operations and native product activity remain with Cohere evidence sources. Private infrastructure, IAM, source permissions, output review, and business action remain with their respective enterprise owners.

Book a technical deep dive at deepinspect.ai.