Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
Canonical source-of-truth:
../practices/PC-Endpoints-OnePager.md. The canonical v3.0 model:../HAIAMM-v3.0-Framing.md.
Practice: Policy & Compliance (PC) Domain: Endpoints Purpose: 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. Scoring Model: Evidence + Outcome Metrics
| Tier | Score | Criteria |
|---|---|---|
| Fully Mature | 1.0 | Evidence complete + ≥3 outcome metrics meet targets |
| Implemented | 0.67 | Evidence complete + 2 outcome metrics meet targets |
| Partial | 0.33 | Evidence partially complete + <2 outcome metrics meet targets |
| Not Implemented | 0.0 | No substantive evidence |
Practice maturity level achieved = highest level where all 3 questions score ≥ 0.67.
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.
Q1.1: Have you published and formally approved all three AI/HAI endpoint policies, Endpoint AI Acceptable Use Policy, AI Browser-Extension Policy, and Customer-Facing AI Endpoint Disclosure Policy, with sanctioned-tools enforcement, data-class restrictions, allowlist-based extension governance, and EU AI Act Art. 50 disclosure UX requirements?
Evidence Required: - [ ] Endpoint AI Acceptable Use Policy approved by Legal/Privacy and Security, covering: sanctioned AI tools list (tools not in inventory require intake before use), personal-account prohibition (organizational identity required for sign-in), data-class restrictions (PHI/PCI/regulated PII/customer confidential/source code prohibited in AI tool prompts, uploads, or screen-share without DPA coverage and Privacy approval), SaaS AI feature enablement controls (admin-only, no self-service), and own-built endpoint AI intake requirement - [ ] AI Browser-Extension Policy establishing allowlist-only enforcement via browser enterprise policy (Chrome Enterprise Admin, Edge Admin Center, Firefox Enterprise Policy), review and approval process for new extensions covering vendor identity/DPA status/data transmitted/permission scope, per-extension data-class annotations, and DLP integration (browser-level DLP configured to match data-class restrictions) - [ ] Customer-Facing AI Endpoint Disclosure Policy defining: scope (own-built chatbots, voice AI, multi-modal AI surfaces), mandatory disclosure triggers (prior to or at start of AI interaction), synthetic media and AI-generated content marking requirements, accessibility requirements (WCAG 2.1 AA), sector overlays (HIPAA patient-facing, COPPA children-facing, FERPA student-facing), and deployer-duty owner requirement for every customer-facing AI surface - [ ] All three policies require attestation at onboarding and annually for managed-endpoint users; violations routed through program sponsor and Legal - [ ] Amnesty path for previously ungated endpoint AI assets is linked from the intake form and the Endpoint AI AUP
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % managed-endpoint users with acknowledged Endpoint AI AUP (current-year attestation) | measure | ___ | ≥95% | ☐ | | | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | Three priority policies approved by Legal/Privacy and Security | n/a | ___ | Yes (all three) | ☐ | | | AI Browser-Extension Policy includes allowlist enforcement and DLP integration requirement | n/a | ___ | Yes | ☐ | |
Metric Collection Guidance: - AUP attestation rate: Query HR/LMS for current-year Endpoint AI AUP acknowledgment completions divided by total managed-endpoint user headcount; run monthly. - Compliance map publication: Verify the one-page compliance map is in the document registry with an approval date within the last 12 months and is linked from each policy. - Policy approvals: Verify Legal/Privacy and Security sign-off records exist for all three policies in the document management system. - Browser-extension policy completeness: Confirm the AI Browser-Extension Policy includes an active allowlist record format (with DPA status, data transmitted, permission scope, and per-extension data-class annotations) and a documented DLP integration requirement.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q1.2: Is there a published one-page priority 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, and sector-specific obligations (HIPAA/PCI-DSS/FERPA/COPPA), to the specific AI/HAI Endpoint policy that carries it?
Evidence Required: - [ ] One-page compliance map exists in the document registry, linked from each of the three policies, covering all priority requirements - [ ] EU AI Act Art. 50 transparency obligation row traces to Customer-Facing AI Endpoint Disclosure Policy (disclosure UX specification, synthetic-content marking requirements) - [ ] EU AI Act Art. 26 deployer duties row traces to Endpoint AI AUP (own-built endpoint AI controls, deployer-duty owner requirement) and go-live gate (deployer-duty owner assignment, logging baseline confirmation) - [ ] GDPR Art. 32 security of processing row traces to Endpoint AI AUP (data-class restrictions, DLP enforcement requirement) and AI Browser-Extension Policy (DLP integration, data-class annotation per extension) - [ ] GDPR Art. 25 privacy by design row traces to Customer-Facing AI Endpoint Disclosure Policy (consent and disclosure before AI data collection) and Endpoint AI AUP (data-class restrictions) - [ ] ISO/IEC 27001 A.8.7 protection against malware row traces to Endpoint AI AUP (sanctioned-tool enforcement via MDM/policy) and AI Browser-Extension Policy (allowlist technical enforcement); sector-specific rows (HIPAA endpoint controls, PCI-DSS endpoint controls, FERPA educational endpoints, COPPA children-facing AI) are mapped to the specific policy and artifact that carries them; compliance map has a documented review frequency and was reviewed within the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | % own-built customer-facing AI surfaces in production with a documented disclosure UX record | measure | ___ | 100% | ☐ | | | % own-built customer-facing and decision-affecting endpoint AI with a named deployer-duty owner | measure | ___ | 100% | ☐ | | | Auditor evidence turnaround for Art. 50 disclosure inquiry | measure | ___ | satisfied within 5 BD (last 12 months) | ☐ | |
Metric Collection Guidance: - Compliance map review: Check document registry for version date and approval record within the past 12 months; verify all priority requirement rows are present including sector-specific rows. - Disclosure UX record coverage: Query SM-Endpoints inventory for own-built customer-facing AI surfaces; verify each has a disclosure UX record filed (disclosure UX specification reviewed against the Customer-Facing AI Endpoint Disclosure Policy). - Deployer-duty owner coverage: Query SM-Endpoints inventory for own-built customer-facing and decision-affecting endpoint AI surfaces; verify each has a named deployer-duty owner field populated. - Auditor turnaround: Review any compliance or external audit requests for Art. 50 evidence in the last 12 months; confirm the team produced a gate record and disclosure UX record within 5 business days.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q1.3: Is the AI/HAI endpoint intake gate operational with a published SLA, a per-archetype artifacts checklist including a required disclosure UX review for customer-facing surfaces, 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-tier)?
Evidence Required: - [ ] Single intake ticket queue exists with a published SLA (triage ≤5 BD, provisional approval ≤10 BD for Low-tier assets, developer-only coding assistant with no regulated data, read-only access, no customer exposure) - [ ] Per-archetype artifacts checklist is published; the go-live checklist for customer-facing AI surfaces includes a required disclosure UX specification reviewed against the Customer-Facing AI Endpoint Disclosure Policy; no customer-facing AI surface goes live without a disclosure review record - [ ] Amnesty path is linked from the intake form and the Endpoint AI AUP; AI endpoint assets already in production without gate passage may enter through retroactive intake without penalty; retroactive intake records exist in SM-Endpoints inventory - [ ] Gate approval creates or updates the SM-Endpoints inventory record with artifact links and deployer-duty owner; exceptions logged with owner, rationale, and review date; no exception open longer than 90 days without re-review - [ ] SM-Endpoints inventory and intake queue can be queried to confirm gate-coverage rate for the last 12 months - [ ] Browser-extension allowlist is actively maintained and technical enforcement (browser enterprise policy) is confirmed operational
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % own-built AI/HAI endpoint surfaces going live that passed the intake gate | measure | ___ | ≥85% within 12 months; 100% for Critical/High archetypes | ☐ | | | % own-built customer-facing AI surfaces in production with a documented disclosure UX record | measure | ___ | 100% | ☐ | | | Intake SLA adherence (triaged within 5 BD) | measure | ___ | ≥90% | ☐ | | | Policy exception aging, exceptions open >90 days | measure | ___ | 0 exceptions past expiry | ☐ | |
Metric Collection Guidance: - Gate coverage rate: Divide own-built endpoint AI surfaces with a gate record in the last 12 months by total new own-built endpoint AI surfaces in the SM-Endpoints inventory for the same period; split Critical/High separately. - Disclosure UX record coverage: Query SM-Endpoints inventory for own-built customer-facing AI surfaces; verify each has a disclosure UX review record on file. - SLA adherence: From the intake ticket queue, calculate the % of tickets where triage timestamp minus submission timestamp is ≤5 BD. - Exception aging: Query the exception register for open entries where review-due date is in the past; target is zero.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
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.
Q2.1: Have the three priority policies been extended with tier-specific addenda using the SM-Endpoints L2 tier rubric, and do Critical customer-facing AI surfaces require explicit executive (CISO or CPTO) and privacy-officer sign-off, EU AI Act Art. 50 disclosure UX specification reviewed by Legal, GDPR Art. 22 safeguards reviewed by Privacy, and a consent-management implementation confirmed with accessibility audit?
Evidence Required: - [ ] Tier-specific addenda exist for Critical, High, Medium, and Low endpoint AI asset tiers, referencing the SM-Endpoints L2 rubric tier definitions - [ ] Critical tier (customer-facing public AI surfaces with regulated data or action capability) requires: full SR pack with REM, executive (CISO or CPTO) and privacy-officer sign-off 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 - [ ] Critical tier requires re-review within 14 days of any material change (model swap, new capability, scope expansion, new user population) - [ ] High tier requires 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 - [ ] Policy-exception framework requires named owner, compensating control description, Legal/Security reviewer acknowledgment, and expiry date (max 12 months); Critical-tier missing go-live artifacts (including missing disclosure UX records for customer-facing AI) are blocking IM findings with no amnesty post-L2 - [ ] Gate records show executive and privacy-officer sign-off for Critical assets in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical assets with explicit executive + privacy-officer sign-off at go-live | measure | ___ | 100% | ☐ | | | % Critical customer-facing AI surfaces with current disclosure UX attestation | measure | ___ | 100% | ☐ | | | % Critical/High endpoint AI assets with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Regulatory inquiry turnaround (evidence bundle and disclosure UX record within 5 BD) | measure | ___ | Yes (last 12 months) | ☐ | |
Metric Collection Guidance: - Critical sign-off rate: Query gate records in SM-Endpoints inventory for Critical-tier assets in the last 12 months; verify each has both CISO/CPTO and privacy-officer sign-off timestamps. - Disclosure UX attestation currency: For each Critical customer-facing AI surface, verify the disclosure UX attestation (disclosure UX specification version, last accessibility review date, last compliance review date) is within the 90-day staleness threshold. - Evidence bundle completeness: For each Critical/High asset, check that all required bundle elements (TA snapshot, SR REM, SA confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, disclosure UX attestation) are present and within refresh windows. - Auditor turnaround: Review any regulatory or auditor inquiries in the last 12 months; confirm each was answered within 5 business days including a current disclosure UX attestation.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q2.2: Is a compliance evidence bundle continuously maintained for every Critical and High endpoint AI asset, including TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and current disclosure UX attestation, with staleness inside tier-specific targets?
Evidence Required: - [ ] Evidence bundle structure is defined and implemented; bundle elements include: current TA threat snapshot, SR REM with gap status and owner, SA reference-pattern confirmation or DR-approved deviation, latest DR decision, latest IR attestation, ST evidence (test battery last run, prompt-injection corpus, action-scope boundary test), ML logging-baseline confirmation, 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), 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 are defined and enforced for Critical tier: TA snapshot ≤90 days, IR attestation ≤6 months, ST evidence ≤30 days, disclosure UX attestation ≤90 days; staleness triggers a PC-Endpoints finding routed to IM - [ ] Disclosure UX attestation is re-verified after model upgrades, UX redesigns, or material changes to own-built AI surfaces, not treated as a one-time go-live check - [ ] Browser-extension allowlist quarterly review is on calendar; extensions with material vendor changes (new data transmitted, new permission scope, vendor acquisition) are flagged for re-review within 30 days - [ ] The evidence bundle is the primary artifact delivered to regulators or auditors; a completed bundle can be assembled for any Critical/High asset without specialist intervention - [ ] Evidence registry is queryable to report completeness and staleness across Critical/High asset bundle elements
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High endpoint AI assets with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Median staleness of evidence-bundle elements for Critical assets | measure | ___ | ≤30 days past refresh window | ☐ | | | % Critical customer-facing AI surfaces with current disclosure UX attestation | measure | ___ | 100% | ☐ | | | Audit findings on AI/HAI endpoint controls, repeat findings | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Bundle completeness: For each Critical/High asset, check each required element is present and within its refresh window; count assets where all elements are current; divide by total Critical/High assets. - Median staleness: For each Critical asset's evidence bundle, calculate days since each element's last refresh; compute median across all Critical assets. - Disclosure UX attestation currency: For each Critical customer-facing AI surface, verify the disclosure UX attestation is within the 90-day staleness threshold; count surfaces where attestation is current; divide by total Critical customer-facing surfaces. - Repeat findings: Review the last completed compliance or external audit report; count findings that also appeared in the prior audit cycle.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q2.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, browser-extension allowlist reviewed quarterly, and sector-specific evidence bundles (HIPAA / PCI-DSS / FERPA / COPPA) complete for in-scope assets?
Evidence Required: - [ ] Exception register is integrated with the intake gate; no exception is approved without tier-appropriate compensating control definition and expiry date (max 12 months); monthly exception aging review is scheduled and conducted - [ ] Exceptions more than 90 days past expiry auto-escalate to the program sponsor; Critical-tier assets with missing go-live artifacts (including missing disclosure UX records) are blocking IM findings, no amnesty applies post-L2 - [ ] Browser-extension allowlist formal quarterly review is on calendar; 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; no overdue reviews - [ ] Sector-specific evidence bundles are generated from the compliance evidence bundle: HIPAA patient-facing AI bundle (patient consent record, disclosure UX specification with HIPAA notice, provider BAA), PCI-DSS endpoint bundle (CDE endpoint control evidence), FERPA educational AI bundle (student-data handling record, FERPA notice), COPPA children-facing AI bundle (parental consent mechanism confirmation, no-behavioral-targeting record); completeness is tracked per asset - [ ] Policy-exception volume is tracked quarterly and is not increasing - [ ] Disclosure UX issues identified by reviews are corrected before customer complaints or regulator inquiries
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Exception register: % exceptions with named owner, compensating control, and expiry date | measure | ___ | 100% | ☐ | | | Browser-extension allowlist quarterly review on calendar, overdue reviews | measure | ___ | 0 | ☐ | | | Sector-specific evidence bundle completeness for in-scope assets | measure | ___ | 100% | ☐ | | | Policy-exception volume trend | measure | ___ | trending down QoQ | ☐ | |
Metric Collection Guidance: - Exception register completeness: Audit every entry; each must have a named owner, compensating control description with reviewer acknowledgment, and a documented expiry date. - Browser-extension allowlist review: Verify the quarterly review meeting minutes exist for each of the last four quarters; confirm no cycle was skipped and extensions with material vendor changes were flagged for re-review within 30 days. - Sector bundle completeness: For each asset in scope of HIPAA, PCI-DSS, FERPA, or COPPA, verify the corresponding sector evidence bundle is assembled and all documents are present and current. - Exception volume trend: Count new exceptions opened per quarter over the last four quarters; confirm the count is not increasing.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
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.
Q3.1: Does a continuous attestation pipeline auto-update evidence bundles from MDM app catalog 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?
Evidence Required: - [ ] 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 is implemented: any regulatory or auditor request produces a provenance-complete evidence pack, 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 - [ ] Attestation currency SLO is ≤24 hours latency after a triggering event; completeness SLO is ≥99% of active Critical/High assets continuously attested - [ ] On-call paging is configured when evidence-pipeline feed staleness thresholds are exceeded - [ ] SLA performance (≤3 BD on-demand pack generation) is documented and met in the last 12 months - [ ] Policy-refresh cycle is on calendar with zero missed cycles in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Attestation-pack generation SLA for regulator / auditor | measure | ___ | ≤3 business days | ☐ | | | Attestation currency SLO for Critical/High assets | measure | ___ | ≤24h latency post-triggering event | ☐ | | | % Critical/High assets continuously attested | measure | ___ | ≥99% of active Critical/High assets | ☐ | | | Material audit findings on AI/HAI endpoint controls in last 12 months | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Pack generation SLA: From evidence-ops telemetry, measure time from regulator/auditor request to evidence pack delivery; compute % of requests met within 3 BD. - Attestation currency SLO: From evidence pipeline telemetry, measure time between a triggering event (MDM app update, SaaS-admin AI-feature change, chatbot version deployment) and the evidence bundle update; compute % of events where latency is ≤24 hours. - Continuous attestation completeness: Divide Critical/High assets with a fresh evidence bundle (within SLO) by total active Critical/High assets. - Material audit findings: Review the last completed compliance or external audit report; count findings designated as material or high-severity related to AI/HAI endpoint controls.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q3.2: Does the program operate a quarterly, telemetry-driven policy-refresh cycle, drawing from ML-Endpoints detection trends, IM-Endpoints incident learnings, tier-movement data, and a regulatory-motion tracker, with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update?
Evidence Required: - [ ] Quarterly policy-refresh cycle is on calendar and has been executed without a missed cycle in the last 12 months - [ ] Refresh inputs are documented per cycle: ML-Endpoints detection trends (endpoint AI violation classes rising, unauthorized extensions, productivity AI data-exposure, chatbot prompt-injection events), IM-Endpoints incident learnings (policy gaps that created incident conditions), tier-movement data (endpoint AI archetypes growing fastest), external regulatory 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 guidance from HHS/OCC/NYDFS/FDA) - [ ] Versioned changelog exists for each of the three policies; each change entry cites the specific signal or regulatory update that prompted the change - [ ] EG-Endpoints training content is updated within 30 days of any policy change; SM-Endpoints inventory archetypes and tier rubric are reviewed for needed updates - [ ] Regulatory-motion tracker is maintained: a log of open regulatory instruments with expected effective dates, mapped to the policy they will affect, reviewed quarterly by the working group - [ ] 100% of policy changes in the last 12 months are traceable to named signals or regulatory updates in the changelog
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Policy refresh cadence met | measure | ___ | quarterly, on calendar | ☐ | | | % policy changes traceable to ML/IM telemetry or named regulatory update | measure | ___ | 100% | ☐ | | | Regulatory-motion tracker reviewed quarterly, open instruments missed | measure | ___ | 0 | ☐ | | | Policy changes measurably close endpoint AI incident classes identified in prior quarters | measure | ___ | trending down | ☐ | |
Metric Collection Guidance: - Refresh cadence: Verify quarterly policy-review meeting minutes exist for each of the last four quarters; confirm no cycle was skipped. - Traceability: Review the policy changelog; for each change entry, verify it cites either a specific ML/IM signal (with date and source) or a named regulatory update (with citation and effective date). - Regulatory tracker: Review the regulatory-motion tracker document; verify it was reviewed in each of the last four quarters and no open regulatory instruments are missing. - Incident reduction: Compare the count of endpoint AI incidents per quarter over the last four quarters; verify that classes targeted by policy changes are not recurring.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
Q3.3: Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI endpoint policy and transparency topics, including disclosure UX reference patterns, browser-extension governance frameworks, or SaaS AI feature governance playbooks, with documented external recognition?
Evidence Required: - [ ] Contribution log exists tracking all public comments, standards submissions, and forum participations with dates, submitting body, and topic - [ ] At least 2 substantive contributions per year submitted to relevant 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) - [ ] Contributions are technical artifacts implementing bodies can use, 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, not deadline-only comment letters - [ ] Contributed artifacts are maintained and versioned; disclosure UX patterns are updated when EU AI Act Art. 50 implementing acts are issued or updated; last-updated dates confirm they are current - [ ] External recognition is documented: citations in published guidance, standards-body acknowledgment, working-group invitations, or peer adoption metrics
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Public regulatory / standards contributions per year | 0 | ___ | ≥2 | ☐ | | | External recognition (citations, adoptions, invitations) | 0 | ___ | tracked, trending up | ☐ | | | Contributed disclosure UX patterns and governance artifacts maintained and current | measure | ___ | Yes (≤12 months since last update, consistent with current Art. 50 implementing acts) | ☐ | | | Regulator / auditor / customer feedback on Art. 50 disclosure and endpoint AI attestation posture | measure | ___ | explicitly positive | ☐ | |
Metric Collection Guidance: - Contribution count: Review the contribution log; count entries for the current year where the contribution is a substantive technical artifact submitted to a named standards body or regulatory forum. - External recognition: Check the contribution log for documented acknowledgments, citations in published guidance, standards-body acknowledgment, peer-adoption metrics, or working-group invitations. - Artifact maintenance: Review the last-updated dates for all contributed artifacts, especially disclosure UX reference patterns; verify none are more than 12 months stale and they are consistent with current Art. 50 implementing acts. - Regulator feedback: Review any written feedback from regulators, auditors, or customers in the last 12 months; note whether Art. 50 disclosure and endpoint AI attestation posture is characterized positively.
Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)
Evidence Location: ___ Metric Validation Date: ___ Notes: ___
| Level | Q1 | Q2 | Q3 | Avg | Achieved? |
|---|---|---|---|---|---|
| L1 | __ | __ | __ | __ | ☐ |
| L2 | __ | __ | __ | __ | ☐ |
| L3 | __ | __ | __ | __ | ☐ |
Practice maturity level achieved: ___ (highest level where all 3 questions score ≥ 0.67)
Document Version: HAIAMM v3.0 Practice: Policy & Compliance (PC) Domain: Endpoints Last Updated: 2026-05-15 Author: Verifhai
Instructions: