Blog

Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.

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.

Compliance & Regulationcalifornia-ab-2013ai-transparencytraining-dataprocurementcompliance
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.

Compliance & Regulationnyc-local-law-144aedthiring-aibias-auditcompliance
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.

Compliance & Regulationgdprdpiaeu-ai-actfriacompliance
Read post →

AI Acceptable Use Policy Template: A Working Baseline for Enterprise AI Governance

An AI acceptable use policy that lists banned tools is already outdated by the time the ink dries. A useful policy describes the categories of allowed use, the data classifications each category may touch, the enforcement mechanism that prevents drift, and the audit posture that makes a breach reconstructable. This template covers the policy structure, the per-role permissions, the enforcement plane that turns the policy from advisory into binding, and the audit record that survives the post-incident review.

Compliance & Regulationacceptable-useai-policygovernanceshadow-aicompliance
Read post →

AI Vendor Due Diligence Checklist: 27 Questions the Security Review Has to Ask

A vendor security review built for SaaS does not catch the questions an AI vendor introduces. Where the model runs, who trained it, what data goes into the training, how the vendor logs the per-decision audit, and where the EU AI Act obligations land are questions the standard SIG and CAIQ do not ask. This 27-question checklist covers the AI-specific surface across model provenance, identity and access, data flow, logging and audit, and regulatory mapping. The checklist is designed to be added to an existing vendor-risk workflow without replacing it.

Compliance & Regulationvendor-managementai-procurementcompliancedue-diligencesecurity-review
Read post →

AI Gateway Multi-Cloud: The Single Control Plane Across OpenAI, Anthropic, Bedrock, and Vertex

Enterprise AI traffic now spans OpenAI direct, Anthropic direct, AWS Bedrock, Azure OpenAI, and Google Vertex in the same week, often in the same application. Each provider has its own auth, its own request shape, its own error semantics, and its own audit emission. A multi-cloud AI gateway is the single control plane that normalizes identity, classification, policy, and audit across all of them. This walkthrough covers the normalization layer, the per-provider adapters, and the audit record that survives the regulator regardless of which provider the request hit.

Platform & Architectureai-gatewaymulti-cloudopenaianthropicbedrockvertex
Read post →

Fail-Closed vs Fail-Open AI Gateway: The Decision That Survives the Post-Incident Review

A gateway whose policy plane is unreachable has to decide whether to forward the request anyway or refuse it. The decision is architectural and the cost of getting it wrong shows up as either a regulatory finding or a production outage. Fail-closed for policy decisions and fail-open for cached bundles is the pairing that survives the post-incident review. This walkthrough covers the failure modes, the per-route defaults, and the operational runbook for the brief window where the policy plane is unavailable.

Platform & Architecturefail-closedai-gatewayavailabilitypolicy-enforcementarchitecture
Read post →

AI Tool Call Policy Enforcement: Why the Tool Surface Is the Real Attack Surface

A chatbot that only generates text has a small attack surface. The same chatbot wired to ten tool functions that read files, query databases, and call external APIs has the attack surface of those ten functions plus the model that decides when to call them. AI tool call policy enforcement evaluates each function invocation against the identity that triggered it, the data classification of its arguments, and the policy version in force. This walkthrough covers the boundary where the gateway sees tool calls, the rules that scale across hundreds of functions, and the audit record per invocation.

AI Security Solutionstool-callsai-gatewayfunction-callingpolicy-enforcementagentic-ai
Read post →

MCP Policy Enforcement: Treating Model Context Protocol Calls Like AI Traffic, Not Plugin Traffic

Model Context Protocol turned a model conversation into a fan-out of tool calls and resource reads against external systems. Each fan-out arm now carries its own identity, its own scope, and its own data classification, and the policy plane has to evaluate every arm before the model receives the result. MCP policy enforcement sits at the boundary where the agent reaches the MCP server, inspects the call as AI traffic rather than plugin traffic, and produces an audit record per tool invocation. This walkthrough covers the boundary, the policy fields a Principal Engineer expects to see, and the audit fields the regulator expects.

AI Security Solutionsmcpai-gatewaytool-callspolicy-enforcementagentic-ai
Read post →

AI Policy Versioning: Why the Audit Record Has to Carry a Policy Version, Not Just a Decision

A per-decision audit record without a policy version is a decision without a rule. When the regulator asks why the model was allowed to produce the response, the answer requires the exact rule set in force at the moment of the decision. AI policy versioning treats the policy plane as code, attaches a version identifier to every decision, and stores the policy text the version refers to in a registry the audit pipeline can reach. This walkthrough covers the versioning scheme, the rollout patterns that survive contention, and the audit-record fields the regulator expects.

AI Security Solutionspolicy-versioningai-gatewayauditgovernance-as-codecompliance
Read post →

AI Rate Limiting by Identity: Why Per-Key Quotas Miss the Actual Risk

A per-API-key rate limit lets one runaway service consume the whole quota for its tenant. An identity-bound rate limit accumulates against the verified caller and produces a defensible refusal at the request layer. This walkthrough covers the four identity dimensions a useful rate limit accumulates against, the algorithms that hold under burst traffic, and the audit-record fields that make a refusal admissible.

Platform & Architecturerate-limitingai-gatewayidentityengineeringcost-governance
Read post →

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.

Compliance & Regulationdata-lineageauditai-governancecomplianceeu-ai-actrag
Read post →