Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
FTC guidance tells businesses to limit service-provider access, require reasonable safeguards, put security expectations in contracts, and verify compliance. Ecommerce teams need to carry those expectations into each model request that contains account, order, support, return, loyalty, or payment-related information.
Store, loyalty, merchandising and omnichannel systems can add customer profiles, transaction histories and payment-related fields to an AI request. Retail protection should exclude prohibited authentication data, minimize the remaining context and enforce the approved model account before transmission, while leaving ecommerce and pricing decisions with their existing owners.
Accounting, audit and tax teams can expose client information when an AI request includes workpapers, return data or matter context. Protection should minimize the assembled request, bind it to the responsible professional and permit only an approved model destination before transmission, while keeping professional review and engagement records with their existing owners.
Read post →Pharmaceutical AI requests can carry batch records, adverse-event narratives, unpublished regulatory material and commercial information. Protection starts by classifying the assembled request, minimizing or redacting unnecessary fields and authorizing the exact model destination before transmission.
Read post →Municipal AI requests can collect resident identifiers, case notes and restricted records after a worker enters a harmless-looking instruction. Cities need to minimize the assembled payload, redact fields the service does not require and authorize the exact employee, model account and downstream recipient before transmission.
Dropbox Dash indexes content across connected sources and answers questions over the combined result. The security property that matters is the fan-in: content from a dozen systems, each with its own permission model and its own history of over-sharing, converges into a single retrieval corpus and a single prompt. This piece walks the connector paths, explains why inherited over-permissioning surfaces at retrieval time, and sets out where classification and per-decision records belong.
Read post →Dental practices should minimize PHI in an AI request, bind the request to a named user and permit transmission only to an approved model destination. This article applies the HIPAA minimum-necessary and Security Rule standards to chairside AI workflows while separating gateway controls from BAA review, clinical judgment and record retention.
Read post →Health payer AI controls should minimize ePHI, bind each request to an authenticated workflow and enforce the contracted model destination before transmission. This article applies HIPAA privacy and security standards to payer model routes while keeping coverage decisions, CMS records, vendor oversight and non-routed inference outside the gateway boundary.
Read post →K-12 AI controls should classify the complete student-data request, remove fields the classroom task does not need, enforce an approved provider account and set retention before transmission. This article applies FERPA and COPPA to managed LLM routes while keeping educational judgment, consent administration and bypass traffic outside the gateway boundary.
An ISO/IEC 23894-aligned evidence packet should let a reviewer trace one AI risk from assessment to treatment, test, approval and later monitoring. This example supplies an artifact index, owners, dates and a retrieval walkthrough for a support summarizer. It distinguishes request-level decision records from model evaluation and business approvals, and it avoids treating illustrative artifacts as ISO-mandated forms.
Read post →An AI controls mapping is a chain of decisions, not a list of products. This example starts with one support summarizer and maps four different risk scenarios to a control, accountable owner, test, evidence and residual-risk decision. It distinguishes an organization's selected controls from the customizable ISO/IEC 23894 risk-management guidance and marks where a request gateway has no coverage.
Read post →A practical ISO/IEC 23894 AI risk checklist starts with a named system, a risk owner and a dated decision. Work through scope, risk identification, analysis, treatment, monitoring and review. Each check below has a pass condition and an artifact to retain. The list is an implementation aid for customizable guidance, not an ISO certification test or a statement of legal duties.
Read post →