← All posts

Compliance & Regulation

305 posts on compliance & regulation.

GDPR Article 22 Automated Decision-Making: What LLM-Driven Workflows Owe Data Subjects

Article 22 of the GDPR gives data subjects the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significant effects. AI and LLM-driven workflows that screen candidates, approve credit, set insurance prices, or trigger fraud holds fall inside the article when no meaningful human review breaks the chain. The control that survives a regulator review proves identity of the human reviewer, classification of the input data, the policy state at decision time, and the outcome returned. This walkthrough covers the article text, the meaningful-human-review test, and the audit-record content that satisfies a Data Protection Authority.

gdprarticle-22automated-decision-makingcomplianceai-governanceeu-regulation
Read post →

AI System Cards: What Goes Inside, Which Regulators Expect Them, and Where the Operational Evidence Comes From

An AI system card documents the AI system as deployed: the intended use, the operating environment, the human oversight mechanisms, the policies in effect, the audit-trail format, and the decommissioning plan. System cards extend the model-card concept from a model artifact (Mitchell et al., 2018) to a deployed-system artifact. Regulators expect system cards under EU AI Act Article 11 technical documentation, ISO 42001 Clause 7.5 documented information, NIST AI RMF MAP function, and Fannie Mae LL-2026-04 Pillar 1 inventory. This walkthrough covers the eight fields a system card needs, where the operational evidence comes from, and how the per-decision audit log feeds the card.

ai-system-cardeu-ai-actdocumentationai-governancecomplianceaudit-evidence
Read post →

The AI Governance Alliance: What the WEF Working Groups Have Shipped and Where Their Recommendations Land in Your Architecture

The AI Governance Alliance is the World Economic Forum initiative coordinated through three working groups: Safe Systems and Technologies, Responsible Applications and Transformation, and Resilient Governance and Regulation. Its outputs land in three places: model-level safety research, enterprise deployment patterns, and regulator-facing guidance for cross-border AI rules. The Alliance has shipped published frameworks since 2024 that map directly to NIST AI RMF MANAGE function, EU AI Act Article 13 transparency requirements, and the OECD AI principles. This walkthrough covers which Alliance outputs are operational, which are still aspirational, and where the recommendations need an enforcement layer.

ai-governancewefai-governance-alliancecomplianceframeworksglobal-governance
Read post →

AI Transparency Disclosure: What EU AI Act Article 13 Requires from Providers and What Deployers Owe Their Users

AI transparency disclosure obligations come from three layers. EU AI Act Article 13 requires high-risk AI system providers to deliver instructions of use, system characteristics, capabilities, limitations, and the means for human oversight to deployers. Article 26 extends the obligation: deployers have to inform natural persons that they are subject to an AI system. The horizontal transparency obligations under Articles 50 through 53 cover labelling synthetic content, disclosing AI interactions, and watermarking generated media. Each layer has a different recipient, a different artifact, and a different timing. This walkthrough covers the three layers and the audit-record fields that prove the disclosures actually fired.

ai-transparencyeu-ai-actarticle-13disclosurecomplianceai-governance
Read post →

DORA Third-Party AI Risk: How EU Banks Have to Treat LLM Vendors Under the ICT Critical-Provider Regime

Under the Digital Operational Resilience Act, EU financial entities have to maintain a register of all ICT third-party service providers including LLM vendors, classify which ones support critical or important functions, run pre-contract diligence on those, and meet specific contract content rules under Article 30. The European Supervisory Authorities can designate certain LLM vendors as Critical ICT Third-Party Providers under the CTPP regime, with direct supervisory powers. The Jan 17, 2025 enforcement date is in the rear-view; the question now is whether your AI usage shows up correctly in the register and whether your audit evidence survives an ESA review.

dorathird-party-riskfinancial-servicescomplianceeu-regulationai-governance
Read post →

AI audit log retention: how long EU AI Act, HIPAA, and DORA expect you to keep per-decision records

AI audit log retention is governed by four overlapping regimes that produce different minimum windows on the same record. The EU AI Act Article 12 expects logs across the deployment lifecycle for high-risk systems, with Article 19 fixing a 10-year period for the records the conformity-assessment file references. HIPAA 45 CFR 164.530(j) fixes six years from creation or last effective date. DORA Article 19 fixes a minimum of five years for ICT-related incident records, with longer windows where the supervisor requests them. The retention schedule has to be set to the longest applicable window per record and the storage tiering, tamper-evidence and GDPR deletion handling have to be designed against that window.

ai-audit-logseu-ai-acthipaadoralog-retentioncompliance
Read post →

AI compliance reporting automation: turning per-decision audit records into board-ready evidence

AI compliance reporting automation turns the per-decision audit records the inspection layer writes into three artifacts the auditor, the control owner, and the board each consume. The raw log substrate covers EU AI Act Article 12 and DORA Article 19. The per-control evidence summary covers SOC 2 TSC and NIST AI RMF MEASURE. The board KPI rolls up to a single page. The three-layer stack is the automation target.

ai-complianceaudit-automationeu-ai-actnist-ai-rmfsoc-2evidence-pack
Read post →

AI vendor risk assessment: the questions a Head of Security should ask any LLM provider in 2026

An AI vendor risk assessment in 2026 lives at the intersection of EU AI Act Annex IV documentation, DORA Article 28 third-party register requirements, SOC 2 vendor management, and ISO 42001 AIMS controls. The 30 questions cover training-data lineage, sub-processor disclosure, retention policy, deployer audit-log access, fine-tuning isolation, prompt logging consent, incident notification SLA, and exit-strategy artifacts.

ai-vendor-riskthird-party-riskdoraeu-ai-actiso-42001soc-2
Read post →

AI Vendor Due Diligence Checklist: 30 Questions Your SIG and CAIQ Miss

30 questions a standard SIG Lite or CAIQ never asks an AI vendor: where the model runs, who trained it, how the vendor logs a single AI decision for audit, what is behind the vendor in the AI supply chain, and where the EU AI Act obligations land. This checklist covers model provenance, identity and access, data flow, logging and audit, regulatory mapping, and the AI supply chain, the AI-specific surface a SaaS vendor review leaves untouched. It is designed to be added to an existing vendor-risk workflow without replacing it.

vendor-managementai-procurementcompliancedue-diligencesecurity-review
Read post →

EU AI Act Substantial Modification: When an Update Turns Your Deployer Into a Provider

Article 25 of the EU AI Act says a deployer who substantially modifies a high-risk AI system becomes a provider for that modified system. The provider obligations are heavier than the deployer obligations. Most enterprise teams discover this rule after they have fine-tuned a model, added a retrieval layer, or changed the intended purpose. This piece walks through what the regulation defines as substantial modification, the three updates most likely to trigger it, and the records you need to track every change at the AI request boundary.

eu-ai-actcomplianceauditregulationprovider-obligations
Read post →

Fundamental Rights Impact Assessment (FRIA): The Article 27 Document Most Deployers Are Missing

Article 27 of the EU AI Act requires public bodies and private deployers of certain high-risk AI systems to perform a Fundamental Rights Impact Assessment before first use. The FRIA is a documented process covering intended purpose, persons affected, specific risks of harm, and human-oversight arrangements. It is distinct from a GDPR DPIA. This piece walks through what the FRIA includes, who has to perform one, the August 2026 trigger, and how per-decision records at the AI request boundary feed the FRIA evidence base.

eu-ai-actfriacompliancefundamental-rightsauditregulation
Read post →

What to Log for AI Compliance: The Eight Fields Every Per-Decision Record Needs

EU AI Act Article 19, Fannie Mae LL-2026-04, HIPAA, and SOC 2 with AI all converge on a per-decision record. The vocabulary differs across regimes. The fields do not. This piece walks through the eight fields every per-decision record needs to satisfy the converged requirement: identity of the natural person, identity of the agent, role and scopes, data classification, policy version, model and route, decision outcome, and a tamper-evident timestamp.

ai-audit-logscomplianceeu-ai-actauditregulation
Read post →