← All posts

Compliance & Regulation

402 posts on compliance & regulation.

HubSpot Breeze Compliance Starts With the CRM Fields the Agents Can Read

HubSpot documents Breeze Assistant alongside a set of Breeze agents for customer conversations, record analysis, prospecting research, content generation and project automation, each consuming HubSpot Credits. A compliance assessment has to work out which CRM records those agents can read, which outputs reach customers and what evidence exists per interaction. This article sets out the scoping questions and where the evidence has to come from.

ai-complianceai-governanceaudithubspotdata-protection
Read post →

IBM watsonx Compliance Covers Model Governance, Not the Request Path

IBM markets watsonx.governance around a governance graph, shadow AI detection, continuous monitoring, policy enforcement and traceability of governance activities, decisions and model changes, with mapping to the EU AI Act, NIST AI and ISO 42001. Those are lifecycle artifacts about models. A compliance file also needs per-request evidence about traffic. This article separates model-lifecycle governance from request-path enforcement and shows which obligations each one answers.

ai-complianceai-governanceauditwatsonxiso-42001
Read post →

Hugging Face Compliance Splits Between Hub Controls and Your Inference Traffic

Hugging Face documents SOC 2 Type 2 certification, GDPR compliance, SSO, resource groups, MFA, commit signing and malware, pickle and secrets scanning on the Hub. Those controls govern who touches a repository. A compliance file for an AI system also needs records of inference traffic: which identity called which model endpoint, with what data, under which policy. This article separates the repository controls from the request controls.

ai-complianceai-governanceaudithugging-facemodel-supply-chain
Read post →

Gemini Enterprise Compliance Rests on Evidence You Generate Yourself

Google documents that Gemini for Google Cloud does not use customer prompts or responses to train its models, and that prompt data is encrypted in transit to the underlying model. Those are provider-side commitments. A compliance file still needs enterprise-side evidence: which identity sent which prompt, what data class it carried, which policy was in force and what the decision was. This article separates the two and shows what each regime asks for.

ai-complianceai-governanceauditgeminieu-ai-act
Read post →

EU AI Act Open Source: The Open-Weight Exemption

The EU AI Act exempts some open-source model-provider duties. Article 26 still requires high-risk-system deployers to retain logs, monitor use, oversee people, and document their system. Read the licensing test and the evidence a high-risk deployment must retain.

eu-ai-actopen-source-aicompliancedeployer-obligationsarticle-12
Read post →

AI Risk Reporting for CTOs: Decisions, Drift, Controls, and Evidence

A CTO needs AI risk reporting that connects each deployment to an owner and business purpose, plus its technical route and current risk decision. Operating evidence completes the chain. This guide sets out a report built around inventory changes and policy outcomes, with incidents and supplier changes tracked alongside overdue actions. It keeps a clear boundary between executive governance and HTTP AI traffic controls.

ai-governanceai-complianceai-securitynist-ai-rmfauditpolicy-enforcement
Read post →

AI Risk Reporting for SOC Analysts: The Incident Handoff Record

A SOC analyst needs an AI risk report built for alert and incident handoff. The record should bind an authenticated caller to the route, data class, provider and model, policy decision, denied attempts, response classification, correlation ID, timeline, and escalation evidence within a clearly stated HTTP AI traffic boundary.

ai-securityincident-responseforensic-auditauditinline-enforcementsoc-operations
Read post →

AI Risk Reporting for Security Architects: The Evidence Packet

A security architect needs an AI risk evidence packet that survives design review and remains useful after operational handoff. The packet should connect the HTTP route map, trust boundaries, supplied identity context, provider and model inventory, policy decisions, exceptions, failure behavior, and per-request records to named owners and acceptance tests.

ai-securityai-governancezero-trustarchitecturepolicy-enforcementaudit
Read post →

AI Risk Reporting for Internal Auditors: Evidence Before Dashboards

AI risk reporting for internal auditors should connect the AI inventory, risk assessment, control owner, test procedure, sampled evidence, exception and remediation date. This structure gives the audit committee a defensible view of control operation while preserving Internal Audit independence and the boundary between HTTP traffic evidence and broader assurance work.

auditforensic-auditai-governancenist-ai-rmfpolicy-enforcement
Read post →

AI Risk Reporting for Platform Engineers Starts with the Route

Platform engineers need AI risk reporting that exposes live routes, supplied identity context, provider and model inventory, policy outcomes, latency, failures, and bypass conditions. This guide turns gateway and provider telemetry into a report tied to deployments and owners, while keeping managed HTTP traffic separate from local inference and other paths outside the platform boundary.

ai-securityai-governancecloud-securityarchitectureinline-enforcementaudit
Read post →

AI Risk Reporting for Data Protection Officers: Evidence Before Summaries

A DPO needs AI risk reporting that connects processing purposes, personal-data categories, recipients, transfers, DPIA status, rights handling, incidents, and live control evidence. This guide separates controller decisions from managed HTTP model-traffic evidence and shows how to build a report that supports advice, monitoring, escalation, and supervisory review.

ai-governanceai-compliancegdprnist-ai-rmfauditpolicy-enforcement
Read post →

AI Risk Reporting for Risk Managers: The Recurring Evidence Pack

AI risk reporting for a risk manager should show current exposure by route, policy exceptions, denied requests, model changes, vendor assessment expiry, incidents, evidence gaps, residual-risk decisions, and sign-off provenance. The recurring report turns operating evidence into reviewable decisions after risk appetite and runtime controls already exist.

ai-governanceai-compliancenist-ai-rmfauditpolicy-enforcementcompliance
Read post →