← All posts

Compliance & Regulation

402 posts on compliance & regulation.

AI Data Lineage for Audit: Tracing a Model Decision Back to Its Inputs

AI data lineage for audit traces a model decision back to the inputs that produced it: the prompt content, the retrieval-augmented documents, the policy in force, the identity of the caller, and the version of the model. Most deployments produce lineage that stops at the prompt and never reaches the retrieval source. The lineage that survives a regulatory inquiry has eight elements, lives outside the application, and is signed at the gateway.

data-lineageauditai-governancecomplianceeu-ai-actrag
Read post →

AI DPIA: How the GDPR Article 35 Assessment Changes When the Processing Runs Through an LLM

GDPR Article 35 has required a DPIA for high-risk personal-data processing since 2018. The EU AI Act adds the Fundamental Rights Impact Assessment for high-risk AI deployers. The two documents overlap in the personal-data section, diverge in the AI-system section, and converge again in the audit and remediation sections. A useful AI DPIA reuses the GDPR template, attaches the AI-specific evidence the regulator now expects, and ties to the per-decision audit log the gateway produces. This walkthrough covers the structural overlap, the new evidence items, and the audit fields the assessment commits to.

gdprdpiaeu-ai-actfriacompliance
Read post →

NYC Local Law 144: What the Bias Audit Requires Three Years In, and Where the AI Gateway Fits

New York City Local Law 144 began enforcement on July 5, 2023. Three years in, the law is the first US statute that requires an independent bias audit before an automated employment decision tool reaches an applicant. The enforcement record now exists: a small but growing set of fines, public disclosures, and audit firms whose methodology has been tested in practice. This walkthrough covers what the bias audit requires, where the per-decision audit log fits, and how the NYC rule lines up with the EU AI Act Article 27 FRIA and the Colorado SB 26-189 deployer obligations.

nyc-local-law-144aedthiring-aibias-auditcompliance
Read post →

California AB 2013: What the Training Data Disclosure Means for Your AI Procurement

California AB 2013 took effect January 1, 2026. The law requires developers of generative AI systems made available to Californians to publish high-level documentation about the data used to train each model, including the source categories, the time period of collection, and whether personal information was included. The procurement team now has a public record to read before signing, and the audit team has a citable artifact for vendor due diligence. This walkthrough covers what the disclosure must contain, what it does not contain, and how the per-decision audit log fits.

california-ab-2013ai-transparencytraining-dataprocurementcompliance
Read post →

EU AI Act Article 19: What the Six-Month Log Retention Rule Requires

Article 19 of the EU AI Act tells deployers of high-risk AI systems what to put in the automatically generated logs Article 12 requires, and how long to keep them. The retention floor is six months. The content has to support traceability for risk monitoring and post-market surveillance. The August 2, 2026 deadline applies. Most application logging stacks miss the identity, classification, and policy-state fields the Article 19 reading actually calls for.

eu-ai-actarticle-19complianceaudithigh-risk-airetention
Read post →

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 →