Blog

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

AI Gateway vs API Gateway: What Changes When the Payload Is a Prompt

An API gateway enforces auth, rate limits, and routing on REST and gRPC calls. An AI gateway adds prompt classification, identity-bound policy at the request payload level, and per-decision audit records. The two answer different questions about the same network position. This piece walks through the architectural distinction, the auth model differences, what an API gateway cannot enforce at the prompt layer, and where the two should sit together in production.

Platform & Architectureai-gatewayapi-gatewayengineeringarchitecturepolicy-enforcement
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.

Compliance & Regulationeu-ai-actfriacompliancefundamental-rightsauditregulation
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.

Compliance & Regulationeu-ai-actcomplianceauditregulationprovider-obligations
Read post →

AI Gateway vs LLM Router: The Architectural Distinction That Matters for Enforcement

An LLM router picks the cheapest or fastest model for a given prompt. An AI gateway evaluates whether the request is permitted before any model receives it. The router optimizes cost and latency. The gateway enforces identity-bound policy and produces a per-decision audit record. This piece walks through the architectural distinction, where the two functions overlap, and why an enterprise running regulated workloads needs the gateway capability regardless of whether routing is in scope.

Platform & Architectureai-gatewayllm-routerengineeringarchitecturepolicy-enforcement
Read post →

AI gateway circuit breakers: limiting blast radius when an LLM provider degrades

An AI gateway circuit breaker adapts the microservice resiliency pattern to LLM traffic. The per-provider state machine moves between closed, open, and half-open based on error rate, latency p99, and token-cost spikes. The trip thresholds, the half-open probe budget, and the breaker telemetry tie to DORA Article 19 incident reporting and produce a recovery audit trail.

Platform & Architectureai-gatewaycircuit-breakerresiliencydora-article-19incident-responsellm-traffic
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.

Compliance & Regulationai-vendor-riskthird-party-riskdoraeu-ai-actiso-42001soc-2
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.

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

AI provider rotation strategy: how to swap OpenAI for Anthropic without breaking policy or audit

AI provider rotation is the operational mechanism that lets a deployer move traffic between OpenAI, Anthropic, Google and other endpoints without breaking the policy decision or the audit trail. The mechanism requires a provider-agnostic policy model, the model identity recorded on every per-decision log, per-route routing rules that decouple the policy from the endpoint, fail-over semantics that hold the policy invariant under provider rate-limit or outage, and a documented concentration-risk posture against DORA Article 28. Rotation is the operational expression of the regulatory expectation that the deployer remains accountable across provider changes.

Platform & Architectureai-provider-rotationmulti-providerdora-article-28concentration-riskai-gatewaypolicy-portability
Read post →

AI prompt classification taxonomy: building the label set your gateway enforces against

AI prompt classification is the labelling step that produces the inputs a policy engine evaluates. The label set has to cover four dimensions: data sensitivity (PII, PHI, PCI, IP, public), intent (query, generation, code execution, agent action), risk surface (egress, lateral, instruction injection), and regulatory scope (EU AI Act high-risk, HIPAA PHI, GDPR Article 22). The policy decision joins the four dimensions against the per-user role and the per-route rule. The taxonomy is the artefact the regulator inspects when the gateway answers an audit question about why a given prompt was redacted, blocked or allowed.

Platform & Architectureai-prompt-classificationtaxonomypolicy-engineowasp-llmdata-classificationai-policy
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.

Compliance & Regulationai-audit-logseu-ai-acthipaadoralog-retentioncompliance
Read post →

AI policy version control: how to treat gateway policy like code

AI gateway policy that governs which users can call which models with which data lives in YAML, evolves with the organization, and carries the same regression risk as application code. Treating the policy as code means git-backed storage, semantic versioning of policy bundles, audit-log tagging of decisions with the policy version hash, blue/green policy rollout, and shadow-mode evaluation before promotion. The NIST AI RMF MAP and MANAGE functions ask the questions the version-control discipline answers.

Platform & Architectureai-policy-version-controlpolicy-as-codenist-ai-rmfblue-green-deploymentshadow-modegitops
Read post →

AI gateway observability: the metrics, traces, and logs a policy decision point should emit

An AI gateway emits four signal categories that serve four different audiences. Per-decision audit logs serve the regulator under EU AI Act Article 12. Per-request traces serve the engineering team debugging a request. Per-policy metrics serve the operations team measuring policy effects. Per-model latency histograms serve the capacity-planning team sizing the LLM provider relationship. OpenTelemetry alignment lets the four signal categories share a transport without conflating their consumers.

Platform & Architectureai-gateway-observabilityopentelemetryaudit-logseu-ai-act-article-12policy-metricslatency-histograms
Read post →