Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
EU AI Act Annex III lists eight high-risk AI use-case categories, including biometrics, education, employment, credit scoring, law enforcement, and justice. See the covered systems, Article 6(3) exception, and the provider and deployer obligations that follow.
Read post →This CMMC AI controls mapping connects Level 2 security requirements drawn from NIST SP 800-171 Revision 2 to the authenticated HTTP path between a defense contractor user or agent and an LLM. Each entry names the control point, owner, assessment objective test, retained artifact, and the boundary where an AI gateway stops contributing and IAM, endpoint, media protection and incident teams take over.
Read post →An EU Data Act AI compliance checklist covers the parts of Regulation (EU) 2023/2854 that reach an AI deployment: the switching obligations in Chapter VI, the international governmental access safeguards in Article 32, the contractual transparency duty in Article 28, and the connected-product data rules in Chapter II. Each check has an owner, a pass condition, evidence fields, and a boundary line.
This GLBA AI controls mapping takes the elements of 16 CFR 314.4 and assigns each one a control point, an owner, a repeatable test, a retained artifact, and a boundary on the authenticated path from a user or agent to an LLM. It shows where an HTTP enforcement point gives direct coverage for access limits and monitoring, and where the qualified individual, IAM, cryptography, procurement and incident response teams stay accountable.
Read post →GLBA AI audit evidence has to show that a financial institution monitored and logged what authorized users did with customer information when they sent it to a model endpoint. This guide builds the package around 16 CFR 314.4(c)(8), the written risk assessment at 314.4(b), the access limits at 314.4(c)(1), the 30 day FTC notice at 314.4(j), and the annual report at 314.4(i).
Read post →A GLBA AI compliance checklist runs against the elements in 16 CFR 314.4, not against a generic security questionnaire. This guide grades LLM traffic on the qualified individual, the written risk assessment, access controls, encryption, monitoring and logging of authorized user activity, service provider oversight, the incident response plan, and the annual board report, with an evidence field and a boundary line for each.
Read post →This NIS2 AI controls mapping takes the ten measures in Article 21(2) of Directive (EU) 2022/2555 and assigns each one a control point, an owner, a repeatable test, a retained artifact, and a stated boundary on the authenticated path from a user or agent to an LLM. It marks where an HTTP enforcement point contributes directly and where identity, endpoint, continuity and reporting teams stay accountable.
Read post →NIS2 AI audit evidence has two customers: a competent authority testing Article 21 measures, and a CSIRT reading an incident notification written against the clocks in Article 23(4). This guide builds one evidence package that serves both, covering population definition, sample binding, integrity, retention, and the boundary where an AI gateway stops contributing.
Read post →A NIS2 AI compliance checklist has to grade the ten measures in Article 21(2) against the AI request path, not against a generic security policy. This guide gives each check an owner, a pass condition, an evidence field, and a boundary line, then keeps the 24 hour, 72 hour, and one month reporting clocks from Article 23 attached to the systems that can actually meet them.
Read post →The ECB has identified frontier AI as a structural cyber-resilience challenge for banks. This guide separates the operational-resilience controls a policy gateway can evidence from the patching, legacy-modernisation, and crisis-management controls it cannot replace.
Read post →A bank running LLMs answers to model risk guidance, operational-resilience rules, fair-lending law, and data-protection statutes at the same time. This article maps SR 11-7, DORA, ECB supervisory signals, ECOA, and the EU AI Act, then shows the operational thread that joins them at the AI request layer.
Read post →The Digital Operational Resilience Act (DORA) treats LLM providers as critical ICT third parties when usage reaches scale. EU banks have to register, monitor, and document exit strategies for these dependencies. The deadline for the consolidated ICT third-party register goes live in January 2027. This article walks through the register requirements, the exit-strategy mandate, the concentration-risk test, and what changes when bank inference runs through OpenAI, Anthropic, and AWS Bedrock simultaneously. Gateway-level audit logs satisfy the per-decision evidence requirement DORA assumes.
Read post →