Policy & Compliance (PC)

Endpoints Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Endpoint Assurance program enforceable, so every AI/HAI-enabled endpoint and user-facing AI interface the organization operates is governed by a documented set of rules, gated before it goes live, and defensible to auditors and regulators.

Description: PC-Endpoints codifies three priority policies specific to the Endpoints domain: an Endpoint AI Acceptable Use Policy governing what AI tools may be installed on managed endpoints and what data may flow through them; an AI Browser-Extension Policy establishing an extension allowlist with DLP integration and per-extension data-class restrictions; and a Customer-Facing AI Endpoint Disclosure Policy capturing EU AI Act Art. 50 disclosure UX requirements for own-built chatbots, voice interfaces, and multi-modal AI surfaces. It maps those policies to the compliance regimes that directly apply to the endpoint AI assets the organization operates: EU AI Act Art. 50 (transparency obligation for user-visible AI), Art. 26 (deployer duties), Art. 9 (risk management), GDPR Art. 22 (automated decision via endpoint), Art. 32 (security including endpoint), Art. 25 (privacy by design), ISO/IEC 42001 AIMS, ISO/IEC 27001 endpoint controls, SOC 2 CC6, and sector-specific obligations (HIPAA, PCI-DSS, FERPA, COPPA). At L1 the goal is not exhaustive policy coverage, it is the minimum enforceable stack needed to gate endpoint AI before it goes live and trace every relevant regulation to a single named policy.

Context: Most organizations that manage endpoints inherit a generic Acceptable Use Policy and an IT security policy that mentions "authorized software." Neither answers the questions that AI/HAI endpoints raise: Which AI browser extensions are permitted and under what data-class restrictions? Who may enable M365 Copilot for a team that processes regulated data? What disclosure must appear in the UI of an own-built customer chatbot to satisfy EU AI Act Art. 50? What consent basis applies when a mobile AI app accesses device microphone or camera for multi-modal interaction? What does the deployer-duty obligation under Art. 26 require from the product team that shipped the chatbot? Without AI-specific policies and an explicit compliance map, endpoint AI accumulates outside governance, customer-facing AI surfaces go live without mandatory disclosures, and auditors cannot trace a regulation to a control. PC-Endpoints closes that gap at the endpoint layer, it governs what the organization operates at endpoints, in contrast to PC-Software (what it builds) and PC-Vendors (what it consumes from third parties).

Maturity Level 1

Objective: Publish the three priority AI/HAI endpoint policies, map them to the priority compliance requirements, and operate the intake gate that prevents ungated endpoint AI from going live

At this level, the organization ships the minimum viable policy stack for AI/HAI endpoint governance, maps each policy to the regulations and standards that make it auditable, and implements the intake gate through which every significant endpoint AI asset must pass before going live or being formally sanctioned.

Dependencies

• SM-Endpoints L1 (required): the AI/HAI endpoint inventory and archetype taxonomy are the substrate the policies govern, PC-Endpoints L1 cannot be operational without the inventory PC references.
• Alignment (not a hard dependency): enterprise Legal/Privacy function for transparency and consent obligations; existing IT security policy stack; MDM / browser-extension admin infrastructure to enforce the policies technically.
• Supports / unblocks: EG-Endpoints L1 (workforce and practitioner training needs published policies as the teaching object); SR-Endpoints L1 (requirements packs inherit policy guardrails); SA-Endpoints L1 (reference architectures operationalize the policy's archetype controls); IM-Endpoints L1 (exception and violation handling flows from policy).

Desired Outcomes

• Three short, AI-specific endpoint policies exist, are approved by Legal/Privacy and Security, are accessible to every managed-endpoint user and IT/engineering team, and are acknowledged at onboarding and annually.
• A one-page priority compliance map lets auditors and regulators trace each requirement (EU AI Act Art. 50/26/9, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, sector-specific) to the single policy that carries it.
• No own-built customer-facing AI surface goes live without passing the intake gate; the gate produces a required-artifacts checklist for each archetype including an Art. 50 disclosure UX review.
• Every own-built customer-facing or decision-affecting AI endpoint in production has a named deployer-duty owner and a logged go-live decision.
• Shadow endpoint AI surfaces for retroactive intake through an amnesty path rather than going deeper underground.
• The organization demonstrates EU AI Act Art. 50 compliance with a documented chain from policy to disclosure UX specification to go-live gate review to named responsible party.

Activities

A) Publish the three priority AI/HAI endpoint policies

Ship these three policies in their smallest useful form, short, readable, and specific enough to be enforceable against IT, engineering, and user decisions. Each is a distinct lever; all three must exist at L1.

1. Endpoint AI Acceptable Use Policy, what AI tools may be installed on managed endpoints and what data may flow through them: - Sanctioned AI tools: tools on the approved AI/HAI endpoint inventory are permitted; tools not in inventory require intake before installation or regular use. - Personal-account prohibition: AI tools that require sign-in must be used with the organization's identity (SSO / managed account), not personal accounts, to ensure data-handling terms apply; data entered under personal accounts has no organizational DPA protection. - Data-class restrictions by tool category: regulated data (PHI / PCI / regulated PII / customer confidential / source code) may not be input into AI tools unless the tool's DPA explicitly covers that data class and Privacy has approved the use; this applies to prompts, paste actions, uploaded files, and screen-shared content. - Browser AI extensions: AI-capable browser extensions require prior approval through the AI Browser-Extension Policy; unapproved extensions must be removed within the enforcement grace period. - AI-augmented productivity: SaaS AI features (M365 Copilot, Slack AI, Notion AI, Google Workspace Gemini) may be enabled only by IT or SaaS admins with documented approval; self-service AI feature enablement in productivity tools is prohibited. - Own-built endpoint AI: engineers and product teams may not ship customer-facing chatbots, mobile AI apps, or edge AI devices without completing intake and go-live gate review. - Attestation required at onboarding and annually; violations routed through the program sponsor and Legal.

2. AI Browser-Extension Policy, extension allowlist, DLP integration, and per-extension data-class restrictions: - Allowlist-only enforcement: AI-capable browser extensions are subject to allowlist enforcement via browser enterprise policy (Chrome Enterprise Admin, Edge Admin Center, Firefox Enterprise Policy); extensions not on the allowlist are blocked on managed browsers or flagged for removal. - Review and approval process: a browser extension with AI capabilities may be added to the allowlist after a review covering vendor identity and DPA status, data transmitted to vendor AI backends, permission scope (clipboard, browsing history, page content, stored credentials, network access), and user-population scope on managed endpoints. - Per-extension data-class annotation: the allowlist record for each approved extension states the data classes permitted through it (e.g., public web content only; no org-confidential documents; no form fields on internal applications); DLP rules are configured per these annotations. - DLP integration: browser-level DLP (Microsoft Purview, Google Chrome DLP, CASB browser agent) is configured to match the data-class restrictions in the allowlist, flagging or blocking regulated-data entry into AI extension interfaces where technically feasible. - Unapproved extension inventory: IT documents discovered unapproved AI extensions per the SM-Endpoints discovery process; users receive removal guidance within 5 business days of discovery. - Exceptions logged with owner, rationale, and 90-day review date.

3. Customer-Facing AI Endpoint Disclosure Policy, EU AI Act Art. 50 disclosure UX requirements for own-built chatbots, voice interfaces, and multi-modal AI: - Scope: this policy applies to all own-built AI surfaces that interact directly with end users (customers, citizens, employees in automated-service contexts), chatbots and conversational UIs, voice AI interfaces, multi-modal AI interfaces (image, video), and AI-augmented support or sales tools with AI-generated outputs visible to users. - Mandatory disclosure triggers: where own-built AI generates outputs a user might mistake for a human-produced response (chatbot, voice AI), the interface must notify users they are interacting with an AI system, prior to or at the start of interaction; the notification must be clear, prominent, and accessible. - Synthetic media and AI-generated content: where own-built AI generates synthetic images, video, or audio visible to users, the content must be marked or disclosed as AI-generated, per Art. 50 obligations. - Accessibility: disclosure UX must meet WCAG 2.1 AA accessibility standards; disclosures must not be buried in terms-of-service text discoverable only by scrolling; screen-reader-compatible disclosure is required. - Sector overlay: customer-facing AI interfaces subject to sector-specific disclosure requirements (HIPAA patient-facing AI, COPPA children-facing AI, FERPA student-facing AI) must include sector-required notices in addition to Art. 50 requirements. - Go-live gate integration: the disclosure UX specification is a required go-live artifact for all customer-facing AI surfaces; no customer-facing AI surface goes live without a documented disclosure UX review against this policy. - Deployer-duty owner: every customer-facing AI surface must have a named deployer-duty owner responsible for maintaining disclosure compliance after go-live and for notifying users of material changes to the AI system.

B) Map the three policies to the priority compliance requirements

Build a one-page priority compliance map. At L1 the goal is not exhaustive coverage, it is traceability: an auditor asking "how does EU AI Act Art. 50 get met for the org's customer-facing chatbot?" reaches one row in this table, one policy, and one artifact.

C) Operate the intake gate and track foundational compliance outcomes

Policies without an enforced gate do not reduce shadow endpoint AI. L1 closes the loop by putting the three policies behind a single intake checkpoint and measuring whether the gate catches endpoint AI assets before they reach users.

Gate mechanics at L1: - Single intake ticket queue; single SLA (triage within 5 business days; fast-track provisional approval within 10 BD for Low-tier assets, developer-only coding assistant with no regulated data, read-only access, no customer exposure). - Artifacts checklist is archetype-keyed, the requestor or product team submitting intake receives the checklist for their archetype; missing artifacts block go-live for Critical/High assets. - Customer-facing AI surfaces: the go-live checklist includes a required disclosure UX specification reviewed against the Customer-Facing AI Endpoint Disclosure Policy; no customer-facing AI goes live without a disclosure review record. - Integration with SM-Endpoints inventory: gate approval creates or updates the inventory record with artifact links and deployer-duty owner. - Amnesty path: AI endpoint assets already in production without gate passage may enter through retroactive intake without penalty; the inventory record is created and the gap in artifacts is tracked as an open IM finding. - Exceptions logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review.

Outcome Metrics (L1)

Process Metrics (leading)

• Intake SLA adherence, ≥90% of intakes triaged within 5 BD; ≥90% of Low-tier intakes provisionally approved within 10 BD.
• Disclosure UX review completion, no customer-facing AI surface reaches production without a disclosure review record; zero exceptions without a logged compensating control.
• Policy exception aging, exceptions open >90 days reviewed by program sponsor; target: 0 exceptions past expiry.
• Compliance map refresh, reviewed and updated when a new regulation comes into force or a new archetype enters the inventory; at minimum annually.

Effectiveness Metrics (business value)

• Engineering and product cycle-time impact, time from intake submission to provisional approval should not increase as the gate matures; the gate is an enabler, not a bottleneck.
• Retroactive catch rate, % of own-built customer-facing AI surfaces discovered through amnesty or shadow-AI discovery that would have gone live without a disclosure UX review; rising catch rate signals the gate is working.
• Auditor evidence turnaround, a compliance or external audit asking "show me Art. 50 disclosure evidence for this customer chatbot" is satisfied within 5 business days from the go-live record.

Success Criteria

• Three priority policies published, approved by Legal/Privacy and Security, and communicated to all managed-endpoint users and relevant engineering/product teams.
• One-page priority compliance map published covering all rows in the table above; linked from each policy.
• Intake gate operational with a published SLA, a per-archetype artifacts checklist, a required disclosure UX review for customer-facing surfaces, and an amnesty path.
• ≥95% of managed-endpoint users have acknowledged the Endpoint AI AUP in the current year.
• ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months passed the intake gate (100% for Critical/High-tier).
• Every own-built customer-facing and decision-affecting AI/HAI endpoint surface in production has a named deployer-duty owner and a disclosure UX record.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per endpoint AI risk tier, automate disclosure UX attestation and artifact assembly from the SM-Endpoints tier rubric, and produce audit-ready evidence trails continuously

At this level, policy depth is calibrated to the risk tier assigned in SM-Endpoints L2. Critical customer-facing AI endpoints carry deeper consent management controls, explicit executive and privacy-officer sign-off requirements, sector-specific disclosure evidence, and continuously assembled compliance evidence bundles. Low developer-only assets stay fast-tracked. Evidence for EU AI Act Art. 50 deployer duties, GDPR Art. 22/32/25 obligations, and ISO/IEC 42001 AIMS controls assembles automatically for every Critical/High-tier asset.

Dependencies

• PC-Endpoints L1 (required): three priority policies, compliance map, and intake gate must be live.
• SM-Endpoints L2 (required): the risk-tier rubric and tier-treatment matrix drive the differential policy depth. PC-Endpoints L2 inherits tier definitions from SM-Endpoints L2.
• Supports / unblocks: EG-Endpoints L2 (tier-calibrated reviewer training needs tier-aware policies); TA-Endpoints L2 (per-asset deep threat models for Critical/High customer-facing surfaces); IR-Endpoints L2 (drift detection confirms policy adherence post-go-live); IM-Endpoints L2 (tier-aware incident playbook enforces policy SLAs).

Desired Outcomes

• Policy depth visibly differs by tier, Critical customer-facing AI surfaces require explicit executive and privacy-officer sign-off, sector-specific disclosure evidence, and consent-management review; Low developer-only assets use fast-track with base SR pack only.
• Every Critical and High endpoint AI asset has a live compliance evidence bundle that a regulator can open today.
• Art. 50 disclosure UX compliance is continuously verified for customer-facing surfaces, not checked once at go-live and forgotten.
• Sector-specific compliance obligations (HIPAA patient-facing AI, PCI-DSS cardholder endpoint, FERPA educational, COPPA children-facing) are operationalized per artifact, not generically acknowledged.
• Policy exceptions have finite lifespans with named owners; no stale exceptions accumulate.

Activities

A) Tier-calibrated policy depth and sign-off requirements

Extend the three L1 policies with tier-specific addenda using the SM-Endpoints L2 tier rubric (Critical / High / Medium / Low):

• Critical (customer-facing public AI surfaces with regulated data or action capability): full SR pack with REM required; executive (CISO or CPTO) and privacy-officer sign-off required before go-live; EU AI Act Art. 50 disclosure UX specification reviewed by Legal; GDPR Art. 22 safeguards reviewed by Privacy; consent-management implementation confirmed (UI/UX review, accessibility audit against WCAG 2.1 AA); sector-specific disclosure package required where applicable (HIPAA, COPPA, FERPA); Art. 26 deployer-duty checklist completed and named human-oversight owner assigned; re-review mandatory on every material change (model swap, new capability, scope expansion, new user population) within 14 days.
• High (authenticated customer surfaces or employee-facing AI processing regulated data): full SR pack + REM; CISO-delegated security lead sign-off; EU AI Act and GDPR assessments required; disclosure UX review required for customer-facing surfaces; re-review on material change within 30 days.
• Medium (employee-general AI with internal data access or limited action capability): base SR pack + REM; fast-lane DR or DR waiver for sanctioned reference-pattern implementations; re-review annually or on material change within 60 days.
• Low (developer-only coding assistants, read-only, no customer exposure, no regulated data): base SR pack only; self-attested artifact checklist; re-review at annual review.

Policy-exception framework: deviations from any tier's required controls require a named owner, a compensating control description, a Legal / Security reviewer acknowledgment, and an expiry date (max 12 months without re-review). Critical-tier assets have no amnesty path for missing go-live artifacts after L2 is established, missing artifacts are a blocking finding routed through IM.

B) Continuous compliance evidence assembly and disclosure UX attestation tracking

For every Critical and High endpoint AI asset, maintain a live compliance evidence bundle that auto-assembles: - Current TA threat snapshot (age vs. last material change threshold) - Current SR REM with gap status and owner for each open gap - SA reference-pattern confirmation or DR-approved deviation record - Latest DR decision and date - Latest IR attestation and date (or finding log if IR found drift) - ST evidence: test battery last run date, prompt-injection corpus last run date, action-scope boundary test last run date - ML logging-baseline confirmation with last-validated date - Deployer-duty record: named human-oversight owner, disclosure mechanism confirmation, Art. 26 and Art. 50 obligations checklist - Disclosure UX attestation: current disclosure UX specification version, last accessibility review date, last compliance review against Customer-Facing AI Endpoint Disclosure Policy (for Critical/High customer-facing assets) - Sector compliance artifacts where applicable: HIPAA patient-facing AI consent record, COPPA parental consent mechanism confirmation, FERPA student-data handling record, PCI-DSS cardholder-environment endpoint control evidence

Staleness rules: any element past its tier-specific refresh window triggers a PC-Endpoints finding routed to IM. Critical staleness thresholds, TA snapshot: 90 days; IR attestation: 6 months; ST evidence: 30 days; disclosure UX attestation: 90 days.

C) Exception management and tier-aware enforcement

• Exception register integrated with the intake gate; no exception approved without tier-appropriate compensating control and expiry.
• Monthly exception aging review, exceptions more than 90 days past expiry auto-escalate to the program sponsor.
• Sector-specific evidence bundles (HIPAA patient-facing AI bundle, PCI-DSS endpoint bundle, FERPA educational AI bundle, COPPA children-facing AI bundle) generated from the compliance evidence bundle for the artifacts they apply to; completeness tracked.
• Enforcement asymmetry: Critical-tier assets with missing go-live artifacts (including missing disclosure UX records for customer-facing AI) are blocking findings; no amnesty applies post-L2.
• Browser-extension allowlist review cycle: the allowlist is formally reviewed quarterly; approved extensions with material vendor changes (new data transmitted, new permission scope, vendor acquisition) are flagged for re-review within 30 days of the change.

Outcome Metrics (L2)

Process Metrics (leading)

• Evidence-bundle refresh cadence honored by tier (Critical: TA ≤90d, IR ≤6mo, ST ≤30d, disclosure UX ≤90d; High: TA ≤180d, IR ≤12mo, ST ≤60d).
• Exception aging reviewed monthly; zero exceptions past expiry un-escalated.
• Browser-extension allowlist quarterly review on calendar; no overdue reviews.
• Sector-specific evidence bundles tracked; completeness monitored monthly.

Effectiveness Metrics (business value)

• Regulatory inquiry turnaround, evidence bundle and disclosure UX record open time for a regulator or auditor request ≤5 business days.
• Audit findings on AI/HAI endpoint controls trending down; repeat findings = 0.
• Policy-exception volume trending down as tier-calibrated controls become the default path for IT, engineering, and product teams.
• Art. 50 disclosure UX reviews identified and corrected UX issues before customer complaints or regulator inquiries.

Success Criteria

• Three priority policies extended with tier-specific addenda; tier-appropriate sign-off in place for ≥100% of Critical assets in the last 12 months.
• Compliance evidence bundle live for every Critical/High asset; staleness inside target.
• 100% of Critical customer-facing AI surfaces have a current disclosure UX attestation.
• Exception register comprehensive; reviewed monthly; zero exceptions past expiry un-escalated.
• Sector-specific evidence bundles complete for all in-scope assets.
• Regulatory / auditor inquiry SLA (≤5 BD) met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation from MDM, SaaS-admin, and endpoint telemetry; drive policy updates from monitoring signals and regulatory motion; and contribute to AI endpoint and transparency standards development

At this level, compliance is a byproduct of the endpoint management and product release pipeline rather than a separate artifact-assembly step. MDM events, SaaS-admin AI-feature telemetry, browser-extension policy changes, and own-built AI surface deployment events feed the compliance evidence bundle continuously. Policy updates are data-driven, IM-Endpoints incident learnings and ML-Endpoints detection trends refresh the policy stack on a known cadence. The program contributes to AI endpoint and transparency standards development, regulators, standards bodies, and the engineering community receive evidence-backed artifacts from operating a mature AI/HAI Endpoint Assurance program.

Dependencies

• PC-Endpoints L2 (required): evidence bundle and exception register must be running.
• SM-Endpoints L3 (required): automation substrate, signal-driven inventory and tier updates feed the continuous attestation pipeline.
• ML-Endpoints L2+ (required): endpoint telemetry, extension-egress logs, and SaaS-admin AI-feature signals feed the policy-refresh cycle.
• Supports / unblocks: PC-Endpoints L3 evidence posture enables the other 11 Endpoints-domain practices to claim continuous attestation rather than periodic evidence snapshots.

Desired Outcomes

• Compliance attestation for any endpoint AI asset is generated on demand in hours, with full provenance from MDM, SaaS-admin, and deployment events that constitute the evidence.
• Policy refresh is evidence-driven and externally anchored, monitoring trends, incident learnings, EU AI Act implementing acts on Art. 50, GDPR EDPB AI guidance, US state AI transparency laws, and sector guidance feed a versioned, dated policy changelog.
• The program is a recognized voice in AI endpoint and transparency regulation, EU AI Act implementing guidance for Art. 50, NIST AI RMF Playbook updates, CSA and OASIS standards receive substantive contributions from operators.
• Contributed disclosure UX reference patterns, policy templates, and evidence schemas are adopted by external engineering and compliance communities.

Activities

A) Continuous compliance attestation from MDM, SaaS-admin, and deployment signals

• Evidence bundles auto-update from: MDM app catalog events (AI app version update triggers IR recurrency check), SaaS-admin AI-feature events (M365 Copilot license change, Slack AI feature activation triggers inventory and tier re-check), browser-extension allowlist policy changes (new extension approved, existing extension permission-scope change triggers re-review), own-built AI surface deployment events (chatbot version release triggers disclosure UX attestation refresh, mobile AI app release triggers SR recency check), edge-device firmware events (on-device model update triggers TA snapshot recency check), identity-OAuth events (new AI service authorization triggers intake flag).
• Attestation-generation pipeline: any regulatory or auditor request produces a provenance-complete evidence pack for any endpoint AI asset, regulation-keyed (EU AI Act Art. 50 evidence pack, GDPR Art. 32/22 pack, ISO 42001 AIMS evidence set, sector-specific) or asset-keyed, within 3 business days.
• SLO: all Critical/High assets continuously attested; attestation currency SLO ≤24 hours latency after a triggering event; attestation completeness ≥99% of active Critical/High assets.

B) Telemetry-driven policy refresh and regulatory-motion tracking

• Quarterly policy-refresh cycle driven by: ML-Endpoints detection trends (what endpoint AI violation classes are rising, unauthorized extensions, productivity AI data-exposure, chatbot prompt-injection events), IM-Endpoints incident learnings (which policy gaps created the incident conditions), tier-movement data (which endpoint AI archetypes are growing fastest and at what risk level), external regulatory and standards updates (EU AI Act Art. 50 implementing acts, EDPB guidance on AI and consent, FTC AI disclosure guidance, US state AI transparency laws, COPPA amendments, sector-specific AI guidance from HHS / OCC / NYDFS / FDA).
• Refresh output: versioned changelog for each of the three policies, approved by Legal/Privacy and Security; EG-Endpoints training content updated within 30 days of any policy change; SM-Endpoints inventory archetypes and tier rubric reviewed for needed updates.
• Regulatory-motion tracker: a maintained log of open regulatory instruments with expected effective dates, mapped to the policy they will affect; the working group reviews it quarterly.

C) Standards contribution and external engagement

• Participate in AI endpoint and transparency standards forums: EU AI Act Art. 50 implementing acts consultations, GDPR EDPB AI guidance rounds, NIST AI RMF Playbook working groups, OASIS conversational AI standards, CSA AI Safety Initiative endpoint AI controls, sector regulators (HHS patient-facing AI guidance, NYDFS Part 500, FTC AI disclosure, FDA digital health AI).
• Contribute AI-endpoint-specific artifacts to public standards: disclosure UX reference patterns for chatbot and voice AI (Art. 50 implementation reference), browser-extension governance framework, SaaS AI feature enablement governance playbook, mobile AI app consent UX patterns, edge-AI model integrity verification reference.
• Target: at least 2 substantive public comments or standards contributions per year on AI/HAI endpoint policy and transparency topics.

Outcome Metrics (L3)

Process Metrics (leading)

• Evidence-pipeline change-detection health monitored; on-call paged when a feed staleness threshold is exceeded.
• Policy-refresh cycle on calendar; zero missed cycles in last 12 months.
• Regulatory-motion tracker reviewed quarterly; no open instrument missed.
• Contribution pipeline ≥2 items in-flight at any time.

Effectiveness Metrics (business value)

• Regulator / auditor / customer feedback explicitly positive on Art. 50 disclosure and endpoint AI attestation posture.
• Material audit findings on AI/HAI endpoint controls = 0 in the last 12 months.
• Policy changes measurably close incident classes identified in prior quarters.
• Contributed disclosure UX patterns and governance artifacts adopted externally, measured by citations, standards-body acknowledgment, or peer adoption.

Success Criteria

• On-demand attestation pack generation inside 3 business days for any active endpoint AI asset; SLA met in last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High assets.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
• ≥2 substantive public regulatory or standards contributions per year on AI/HAI endpoint policy and transparency topics.
• External recognition documented.
• Zero material audit findings on AI/HAI endpoint controls in the last 12 months.

Key Success Indicators

Level 1: - Three priority policies published and approved by Legal/Privacy and Security: Endpoint AI Acceptable Use Policy, AI Browser-Extension Policy, Customer-Facing AI Endpoint Disclosure Policy. - One-page priority compliance map published, covering EU AI Act Art. 50/26/9/Annex III, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, HIPAA/PCI-DSS/FERPA/COPPA sector-specific obligations. - Intake gate operational with a per-archetype artifacts checklist, a required disclosure UX review for customer-facing surfaces, published SLA, and amnesty path. - ≥95% of managed-endpoint users have acknowledged the Endpoint AI AUP in the current year. - ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months passed the gate; 100% for Critical/High-tier; 100% of Critical customer-facing surfaces have a disclosure UX record.

Level 2: - Tier-specific policy addenda in place; Critical assets carry explicit executive + privacy-officer sign-off; evidence bundles live for all Critical/High assets with staleness inside tier-specific targets. - 100% of Critical customer-facing AI surfaces have a current disclosure UX attestation reviewed against the Customer-Facing AI Endpoint Disclosure Policy. - Exception register comprehensive with named owners, compensating controls, and expiry dates; monthly aging review active; Critical-tier missing artifacts treated as blocking findings with no amnesty. - Sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA as applicable) complete for in-scope assets. - Regulatory / auditor inquiry evidence SLA (≤5 BD) met in the last 12 months.

Level 3: - Continuous attestation pipeline operational; ≤3 BD on-demand evidence pack generation and ≤24h currency SLO met. - Quarterly telemetry-driven policy refresh operating with versioned changelog; 100% of changes traceable to ML/IM telemetry or named regulatory update. - ≥2 substantive public regulatory or standards contributions per year on AI/HAI endpoint policy and transparency (EU AI Act Art. 50, NIST AI RMF, CSA, OASIS); external recognition documented. - Zero material audit findings on AI/HAI endpoint controls in the last 12 months.

Common Pitfalls

Level 1: - ❌ Reusing the generic AUP and IT security policy without AI-specific clauses, no rule on personal-account prohibition for AI tools, no data-class restriction for AI prompts, no disclosure requirement for customer-facing chatbots; auditors cannot trace Art. 50 compliance to any artifact. - ❌ Intake gate applies only to net-new customer-facing products announced through product management, misses AI features enabled in productivity SaaS by SaaS admins, browser extensions installed by users, mobile AI apps downloaded from the app store, and edge AI devices provisioned by IT without product security review. - ❌ Compliance map lists frameworks but does not say which policy carries which regulation, an auditor asking "which policy covers EU AI Act Art. 50?" has to trace coverage manually and typically concludes it is untraceable. - ❌ Customer-Facing AI Endpoint Disclosure Policy written as a legal notice rather than an operational UX specification, product engineers cannot implement it; disclosures are invented per feature rather than standardized. - ❌ No amnesty path, product teams with ungated customer-facing AI surfaces hide them rather than surface them; shadow inventory stays incomplete; Art. 50 violations accumulate silently. - ❌ Browser-extension policy is a PDF list with no enforcement mechanism, extensions are on the "prohibited" list but IT has no technical control to block them on managed browsers. - ❌ Deployer-duty owner role not assigned, customer-facing chatbots go live with no named Art. 26 / Art. 50 responsible party; EU AI Act obligations are acknowledged in policy but operationalized in no artifact.

Level 2: - ❌ Tier-specific addenda published but disclosure UX review requirements never enforced, Critical customer-facing AI surfaces go live without accessibility audit or Art. 50 review because no one enforces the policy requirement. - ❌ Compliance evidence bundle is a folder of PDFs that only the compliance team can navigate, a second reviewer cannot assemble the regulator pack without specialist help. - ❌ Disclosure UX attestation treated as a one-time go-live check, chatbot disclosure language goes stale after a model upgrade or UX redesign and nobody re-reviews until a regulator asks. - ❌ Sector-specific bundles treated as "covered by the general Art. 50 disclosure", COPPA parental consent mechanism or HIPAA patient-facing AI notice specifics are never operationalized. - ❌ Browser-extension allowlist reviewed once at program launch and then never again, vendor changes (new data transmitted, new permission scope, acquisition) silently expand the data-egress surface.

Level 3: - ❌ Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the artifacts mean; the 3 BD SLO is met but a follow-up hearing is required. - ❌ Policy refresh is cadence-only, quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain what incident prompted which change. - ❌ External contributions are deadline-only comment letters rather than technical artifacts (disclosure UX reference patterns, governance frameworks) that implementing bodies use in guidance. - ❌ Contributed disclosure UX patterns published once and then go stale, external practitioners stop trusting them when they find patterns inconsistent with current Art. 50 implementing acts. - ❌ ROI narrative omits compliance cost-reduction evidence, the biggest L3 business case (lower audit preparation overhead, faster regulatory response, reduced Art. 50 enforcement exposure) is never measured or reported.

Practice Maturity Questions

Level 1: 1. Have you published and formally approved the three priority AI/HAI endpoint policies, Endpoint AI Acceptable Use Policy (sanctioned tools, personal-account prohibition, data-class restrictions, own-built surface intake requirement), AI Browser-Extension Policy (allowlist enforcement, DLP integration, per-extension data-class annotation), and Customer-Facing AI Endpoint Disclosure Policy (Art. 50 disclosure UX requirements, accessibility standards, sector overlays, deployer-duty owner requirement)? Is there a one-page compliance map that traces each priority requirement (EU AI Act Art. 50/26/9/Annex III, GDPR Art. 22/32/25, ISO/IEC 42001, ISO/IEC 27001 endpoint controls, SOC 2 CC6, HIPAA/PCI-DSS/FERPA/COPPA) to the specific policy that carries it? 2. Is the intake gate operational with a per-archetype artifacts checklist, a required disclosure UX review for customer-facing AI surfaces, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of own-built AI/HAI endpoint surfaces going live in the last 12 months have a gate record (100% for Critical/High)? 3. Are ≥95% of managed-endpoint users covered by a current-year Endpoint AI AUP acknowledgment, and does every own-built customer-facing or decision-affecting AI endpoint surface in production have a named deployer-duty owner logged in the SM-Endpoints inventory with a disclosure UX record on file?

Level 2: 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Endpoints L2 rubric), and do Critical customer-facing AI surfaces carry explicit executive plus privacy-officer sign-off at go-live, with a live compliance evidence bundle covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and current disclosure UX attestation? 2. Is a compliance evidence bundle continuously maintained for every Critical/High endpoint AI asset with staleness inside tier-specific targets, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days, including a current disclosure UX attestation for all Critical customer-facing AI surfaces? 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing go-live artifacts treated as blocking findings (no amnesty), and sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA as applicable) complete and current for in-scope assets?

Level 3: 1. Does a continuous attestation pipeline auto-update evidence bundles from MDM events, SaaS-admin AI-feature signals, browser-extension policy changes, own-built AI surface deployment events, and edge-device firmware events, with an attestation currency SLO of ≤24 hours and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High assets continuously attested? 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Endpoints detection trends + IM-Endpoints incident learnings + regulatory-motion tracker + tier-movement data) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? 3. Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI endpoint policy and transparency topics (EU AI Act Art. 50 implementing guidance, GDPR EDPB AI guidance, NIST AI RMF Playbook, OASIS, CSA, sector regulators), with documented external recognition?

Document Version: HAIAMM v3.0 Practice: Policy & Compliance (PC) Domain: Endpoints Last Updated: 2026-05-14 Author: Verifhai