← All posts

Compliance & Regulation

402 posts on compliance & regulation.

EU CRA AI Risk Assessment: A Product-Level Method for LLM Calls

Article 13 of the EU Cyber Resilience Act requires manufacturers to assess and document cybersecurity risks throughout a product's lifecycle. For a product that depends on hosted LLM inference, the assessment must connect intended purpose, foreseeable use, assets, request paths, third-party components, and Annex I controls. This article provides a product-level method without treating every standalone model API or cloud service as directly regulated by the CRA.

complianceregulationai-governanceai-securityaudit
Read post →

EU CRA AI Incident Reporting: The 24-Hour Evidence Workflow

Cyber Resilience Act reporting duties apply from 11 September 2026. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents through the Single Reporting Platform. This article turns the 24-hour, 72-hour, and final-report deadlines into an evidence workflow for products that make LLM calls, while keeping standalone cloud services and model APIs outside the scope unless they meet the Act's product or remote-processing tests.

complianceregulationai-governanceai-securityaudit
Read post →

Dropbox Dash Compliance: Connect Assurance to Each Data Path

Dropbox Dash compliance needs a provider assurance file and a deployment file for connected work apps, indexed content, access controls, AI processing, exclusions, administrative settings, and evidence retrieval. Dropbox documents Dash security, SOC 2 Type II and ISO/IEC 27001 scope, GDPR support, connector behavior, ACL enforcement, logging, and current US storage. The customer remains responsible for configuration, approved use, source permissions, retention, testing, and control ownership.

ai-complianceai-governancecomplianceauditllm-securitypolicy-enforcement
Read post →

DeepSeek Compliance: Approve the Route, Data, and Evidence Together

DeepSeek compliance depends on the service and deployment route an enterprise selects. The current public privacy policy, terms, and API documentation establish important facts about controller responsibility, input handling, training use, storage, model outputs, and the provider-facing interface. An enterprise approval should connect those terms to allowed data, user identity, model route, human review, retention, testing, change control, and per-request evidence.

ai-complianceai-governancecomplianceauditllm-securitypolicy-enforcement
Read post →

Databricks Mosaic AI Compliance: Build the Deployment Evidence File

Databricks Mosaic AI compliance needs two connected evidence sets: provider assurance for the Databricks service and operating evidence for each enterprise deployment. Unity Catalog and Unity Gateway can support access control, lineage, service policy, and audit records. The enterprise still has to document approved use, data scope, model routes, configuration, control tests, changes, retention, and accountable ownership.

ai-complianceai-governancecomplianceauditllm-securitypolicy-enforcement
Read post →

CSA CCM LLM Requirements: A Baseline for Hosted Model Traffic

CSA CCM v4.1 applies to hosted LLM use as cloud consumption. The application baseline spans IAM identity and authorization, DSP data handling, AIS API security, STA supplier responsibility, LOG evidence and SEF incident response. This guide groups those requirements around a production inference request, names the artifact each group should produce and separates authenticated HTTP traffic from model training, weights, endpoints, local execution and provider infrastructure owned elsewhere.

ai-complianceai-governancecompliancellmllm-securitycloud-security
Read post →

CSA AICM LLM Requirements: An Application Provider Baseline

CSA AICM v1.1 gives application providers an LLM control baseline spanning identity, data handling, logging, model documentation, continuous monitoring, failure management, supply-chain inventory and incident response. This guide groups those controls around a production inference request and explains the evidence each group should produce. It also distinguishes the authenticated HTTP user or agent-to-LLM boundary from model training, weights, endpoints and local execution outside that path.

ai-complianceai-governancecompliancellmllm-securitycloud-security
Read post →

Cohere Compliance: Match Evidence to the Deployment Route

Cohere compliance depends on the deployment route. Private and third-party cloud deployments keep prompts and generations outside Cohere access, while the Cohere SaaS Platform has published controls for training choice, logging, monitoring, retention, and approved zero-data-retention arrangements. An enterprise still needs separate evidence for its approved use case, identity, data class, destination, policy decision, and request path.

ai-complianceai-governancecomplianceauditllmpolicy-enforcement
Read post →

CSA CCM AI Risk Assessment: Put Every Model Route Under an Owner

CSA CCM v4.1 requires a formal, documented and leadership-sponsored risk management program covering identification, evaluation, ownership, treatment and acceptance. A useful AI assessment starts with a deployed use case, traces identities, data and model destinations, then tests controls against concrete scenarios. This workflow records inherent exposure, control effectiveness, treatment and residual-risk ownership while separating the authenticated HTTP request boundary from endpoint, provider, training and business risks owned elsewhere.

ai-complianceai-governancecomplianceauditai-securitypolicy-enforcement
Read post →

CSA AICM AI Risk Assessment: Turn Model Use into Owned Decisions

CSA AICM v1.1 requires a leadership-sponsored AI risk management program with documented identification, evaluation, ownership, treatment and acceptance. A useful assessment starts with the deployed use case and actor role, traces data and model dependencies, tests the authenticated HTTP request path and records residual risk with a named owner. This workflow separates request-boundary controls from model, endpoint, training, cloud and business-process risks owned elsewhere.

ai-complianceai-governancecomplianceauditai-securitypolicy-enforcement
Read post →

COBIT AI LLM Requirements: Write Testable Controls for Every Route

COBIT AI LLM requirements become useful when governance intent is translated into testable statements for each use case and model route. This guide maps ownership and data requirements to COBIT objectives, then covers security, change, service operation, monitoring, and evidence while keeping the authenticated HTTP user or agent-to-LLM boundary explicit.

ai-governanceai-securitycompliancellmpolicy-enforcementidentity-and-authorization
Read post →

CSA AICM AI Incident Reporting: Build the Record Before the Alert

CSA AICM v1.1 treats AI incident reporting as an operating chain across Security Incident Management and Logging and Monitoring controls. Application providers need defined severity thresholds, communication paths, tested containment, useful metrics and a secure incident repository. This guide turns those requirements into a reporting workflow for incidents that cross the authenticated user or agent-to-LLM HTTP boundary, while separating endpoint, model-training and regulatory notification work owned elsewhere.

ai-complianceai-governancecomplianceauditforensic-auditai-security
Read post →