Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
A Business Associate Agreement with an AI vendor transfers HIPAA obligations under specific conditions. OpenAI, Anthropic, Microsoft, AWS, and Google offer BAAs to enterprise tiers. The agreement covers what the vendor does with PHI; it does not eliminate the covered entity duty to record disclosures.
Read post →FERPA protects the confidentiality of education records. Schools and the edtech vendors operating on their behalf are now putting student data through AI tools for tutoring, grading assistance, behavioral analytics, and parent communication. The "school official" exception in FERPA covers vendors only when specific written agreement, legitimate educational interest, and direct control conditions are satisfied. Most AI vendor relationships were not constructed with those conditions in mind. This piece walks through what FERPA actually requires when AI processes education records, where the school official exception breaks for AI vendors, and the architecture that satisfies the disclosure controls.
Read post →DORA took effect January 17, 2025. The regulation treats AI vendors as ICT third-party service providers. Financial entities must maintain a register of contractual arrangements, monitor concentration risk, and demonstrate exit strategies. AI inference sits squarely inside the obligation.
Read post →Azure AI Content Safety runs inside the Azure-hosted classification path. The product covers text, image, prompt-shield, groundedness, and protected-material checks the deployer composes through the Content Safety endpoint. This piece walks through the request path, the API surfaces, the policy categories, the audit records the deployer receives through Azure Monitor and the Foundry observability stack, and the deployment patterns the Azure-only customer and the multi-cloud customer should each consider.
Read post →AI governance sets the policies, roles, and accountability for AI use. Risk management identifies, measures, and treats the AI-specific risks the governance framework recognizes. The two programs share inputs (data classification, use case inventory, vendor list) and produce different outputs (policies versus risk treatments). This piece walks through how the programs fit together under NIST AI RMF, ISO 42001, and SR 11-7, the shared infrastructure they depend on, and the per-request evidence both programs need to demonstrate operation.
Read post →Article 99 of the EU AI Act sets three penalty tiers reaching 35M EUR or 7% of global turnover for prohibited practices, 15M EUR or 3% for high-risk non-compliance, and 7.5M EUR or 1% for supplying misleading information. The mandate takes effect August 2, 2026.
Read post →NIST AI RMF 1.0 defines four functions: Govern, Map, Measure, Manage. The framework is voluntary, but federal procurement and state AI laws increasingly cite it as the baseline. Implementation runs to dozens of decisions across identity, classification, policy enforcement, and audit. Most deployments stop at Govern.
Read post →Multi-tenant AI deployments share infrastructure across tenants and have to enforce isolation at the request boundary. Tenant context attached at authentication time has to flow through every policy decision, every tool invocation, every retrieval call, and every audit record. A gateway that maintains the tenant boundary at all four touch points is the architectural pattern that keeps multi-tenant AI safe under load. This piece walks through where the tenant context has to land and what the audit record looks like when isolation holds.
Read post →Article 72 of the EU AI Act requires providers of high-risk AI systems to set up and document a post-market monitoring system that actively and systematically collects data on the performance of the AI throughout its lifetime. The monitoring has to feed back into the risk management process under Article 9 and into the technical documentation under Article 11. The architectural requirement is for a runtime evidence pipeline, not for periodic reporting. Most providers run product analytics and call it post-market monitoring, and the regulator will not accept that under inspection.
Read post →AI vendor due diligence happens at the procurement gate, runs against a standard questionnaire, and produces an attestation file. The questionnaire most teams inherited from cloud SaaS vendors does not cover the questions a regulator will actually ask about AI use. The Fannie Mae LL-2026-04 framework, the EU AI Act, and the NIST AI RMF all expect ongoing due care, not one-time due diligence. This piece walks through the question categories an AI-aware procurement gate has to cover, the answers that have to live in the file, and the runtime evidence that closes the gap between due diligence and due care.
Read post →System prompts carry the AI applications instructions, role assignments, tool definitions, retrieved context, and sometimes credentials or routing keys. A leaked system prompt exposes the application logic to an attacker, including the role boundaries, the tool catalog, and any sensitive context the prompt happened to include. The leakage modes are well-understood. The mitigations live at the AI request boundary, not inside the model. This piece walks through the leak surfaces, the demonstrated attack techniques, and the architectural pattern that prevents leakage.
Read post →A retrieval-augmented generation pipeline fetches documents from a vector store, concatenates them into the prompt context, and sends the assembled prompt to the LLM. The fetched chunks can carry data the requesting user is not authorized to see. The model has no way to distinguish authorized content from leaked content. An AI gateway that redacts at the context-assembly boundary, with identity-bound policy on each retrieved chunk, is the architectural pattern that stops cross-tenant data leakage in RAG.
Read post →