← All posts

Compliance & Regulation

140 posts on compliance & regulation.

The EU AI Act high-risk deadline just moved to December 2027. Here is what still hits on August 2, 2026

The EU Council gave final approval to the Digital Omnibus on AI on June 29, 2026, deferring standalone Annex III high-risk obligations from August 2, 2026 to December 2, 2027. Embedded high-risk systems slide to August 2, 2028. Article 50 transparency obligations still apply on August 2, 2026, and the grace period for AI-content labeling was cut from six to three months, landing on December 2, 2026. A new prohibition on non-consensual intimate imagery generation applies from December 2026. The workstreams a policy gateway supports keep their 2026 deadlines.

eu-ai-actcomplianceregulationai-governanceomnibusaudit
Read post →

SOC 2 AI Controls Mapping: Which Trust Services Criteria a Policy Gateway Actually Evidences

SOC 2 auditors are asking about AI systems this year. The Trust Services Criteria did not change, but the scope of the audit expanded to cover AI request handling, model access controls, and AI-produced data. This piece maps CC6, CC7, and PI trust services categories to the inspection-layer controls that produce SOC 2 evidence for AI systems on a per-decision basis.

soc2ai-compliancetrust-services-criteriaauditai-governance
Read post →

AI Audit Log Retention Under the EU AI Act: What Six Months Actually Means at the Storage Layer

Article 19 of the EU AI Act sets a minimum log retention floor of six months for high-risk AI systems, and existing sectoral rules extend it far beyond that. This piece walks through what the six-month floor means at the storage layer, how the retention interacts with GDPR, HIPAA, and financial-services record rules, and the inspection-layer architecture that produces logs suitable for both the retention window and the reconstruction test a regulator applies during an audit.

eu-ai-actai-audit-logscompliancelog-retentionai-governancearticle-19
Read post →

PCI DSS 4.0 AI Controls: Where an LLM Deployment Touches the Cardholder Data Environment

PCI DSS 4.0 does not name AI systems in its 12 requirements. It does describe the cardholder data environment and the controls that apply to systems that store, process, or transmit cardholder data. An LLM deployment that touches cardholder data joins the CDE. This piece walks through the PCI DSS 4.0 requirements that apply to LLM deployments, the cardholder-data flow patterns that pull the LLM into scope, and the audit evidence a QSA accepts for the AI-specific controls at the gateway boundary.

pci-dsscompliancecardholder-dataai-securityllm-dlpai-gateway
Read post →

NIST GenAI Profile (NIST AI 600-1): The Government's Baseline for Generative AI Risk

NIST published the Generative AI Profile (NIST AI 600-1) in July 2024 as a companion to the AI Risk Management Framework 1.0. The Profile catalogs 12 GenAI-specific risks and maps mitigation actions to the AI RMF's GOVERN, MAP, MEASURE, and MANAGE functions. Federal agencies operating under OMB M-24-10 use the Profile as the reference for their generative AI risk assessments. Enterprises subject to executive orders, government contract clauses, or sector-specific guidance also rely on the Profile. This piece walks through the 12 risk categories, the mapping to the four RMF functions, the specific mitigation actions the Profile lists at the deployment layer, and the audit records a deployer produces to demonstrate the mitigations.

nist-ai-rmfgenai-profilenist-ai-600-1omb-m-24-10compliancefederal
Read post →

ISO 42001 Annex A Controls: The 38 AI Management Controls and Where Each One Lands in the Deployment

ISO 42001 Annex A lists 38 controls across nine areas (A.2 through A.10) that an organization implementing an AI Management System (AIMS) has to consider. The auditor's Statement of Applicability records which controls the organization has implemented, which controls it has excluded (with justification), and which controls are partially implemented with a target date for completion. This piece walks through each of the nine areas, the controls each area contains, the deployment layer where each control operates (policy, application, gateway, model provider), and the evidence artifacts a certification body's auditor accepts as satisfaction of the control.

iso-42001annex-aaimsai-management-systemai-compliancecertification
Read post →

SOC 2 Common Criteria for AI: Mapping CC5, CC6, CC7, and CC8 to LLM Deployment Controls

SOC 2 reports use the AICPA Trust Services Criteria. The 2017 Common Criteria (CC1 through CC9) apply to every service organization's security engagement. When the service organization deploys an LLM as part of the service, the auditor tests the AI-related controls against the same criteria. CC5 (control activities), CC6 (logical access controls), CC7 (system operations), and CC8 (change management) get the most attention because the AI request path introduces new control gaps in each area. This piece walks through each criterion's AI-specific test, the control activities auditors accept as evidence, and the inspection-layer records that carry the evidence in a single audit pass.

soc-2trust-services-criteriaai-complianceauditcommon-criteriacc5cc6
Read post →

GDPR AI DPIA: When Article 35 Requires a Data Protection Impact Assessment for an AI System

GDPR Article 35 requires a Data Protection Impact Assessment when processing is likely to result in a high risk to the rights and freedoms of natural persons. Deploying an LLM against personal data almost always triggers the Article 35 threshold under the criteria the Article 29 Working Party and the European Data Protection Board have published. This piece walks through the Article 35 mandatory triggers, the EDPB Guidelines 3/2019 signals that apply to AI systems, the DPIA process steps under Article 35(7), the coordination with the EU AI Act Article 27 Fundamental Rights Impact Assessment, and the inspection-layer records that the DPIA references for the ongoing monitoring under Article 35(11).

gdprdpiaarticle-35privacyai-complianceedpb
Read post →

EU AI Act General-Purpose AI: Article 53 Obligations, the August 2 Deadline, and the Deployer Consequences

The EU AI Act separates general-purpose AI (GPAI) rules from the high-risk system rules. GPAI obligations under Articles 53 through 55 sit with the model providers (OpenAI, Anthropic, Google, Mistral, Meta) and take effect August 2, 2026. Downstream deployers absorb second-order obligations through the technical documentation and evaluation records upstream providers must supply. This piece walks through what Article 53 requires from GPAI providers, what the systemic-risk threshold under Article 55 changes for the frontier labs, and the practical inspection-layer records a deployer running GPT-5, Claude 4, or Gemini 3 needs to keep against Articles 12, 13, and 26 in parallel.

eu-ai-actgpaigeneral-purpose-aiarticle-53article-55compliance
Read post →

NIST AI RMF MEASURE Function: The Controls That Produce Auditable Evidence

The NIST AI Risk Management Framework organizes risk management into four functions: GOVERN, MAP, MEASURE, and MANAGE. MEASURE is the function that produces the operational evidence the other three functions depend on. The framework defines four categories under MEASURE, with 18 subcategories that specify what to assess and how to assess it. This article walks each category, the controls a deployer needs in production to satisfy them, the artifacts the controls produce, and where a stateless policy gateway sits in the evidence chain.

nist-ai-rmfcompliancerisk-managementmeasurementauditai-governance
Read post →

EU AI Act Conformity Assessment Bodies: Which Notified Bodies Will Sign Off Your High-Risk System

The EU AI Act requires high-risk AI systems to undergo a conformity assessment before being placed on the market. For some categories, the provider self-assesses. For others, the provider has to engage a notified body that the member state has designated under Article 31. With August 2, 2026 thirty-two days away, providers need a working understanding of which Annex III categories trigger third-party conformity assessment, how the notified body designation process works, and what the assessment record looks like when it lands in a market surveillance investigation.

eu-ai-actconformity-assessmentnotified-bodiescompliancehigh-risk-airegulation
Read post →

Serious Incident or Malfunction: The Article 73 Trigger That Decides Whether the Clock Starts

The EU AI Act Article 73 reporting obligation hinges on whether an event qualifies as a serious incident under the Article 3(49) definition. Operationally, the difference between a serious incident and an internal malfunction is the difference between a 15-day external reporting clock and an internal incident review. The provider that misclassifies a serious incident as a malfunction has missed the regulatory window. This article walks the Article 3(49) definition, the decision criteria the supervisory authorities apply, the borderline case patterns that recur in enterprise deployments, and the operational record the triage decision requires.

eu-ai-actincident-responsecompliancearticle-73high-risk-airegulation
Read post →