Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
Canonical source-of-truth:
../practices/PC-Data-OnePager.md. The canonical v3.0 model:../HAIAMM-v3.0-Framing.md.
Practice: Policy & Compliance (PC) Domain: Data Purpose: Publish the priority policies and compliance map that make the AI/HAI Data Assurance program enforceable, so every data asset flowing into or out of AI/HAI systems is governed by a documented set of rules, reviewed before it enters production AI use, 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 data policies, map them to the priority compliance requirements, and operate the Data Intake / Sanction Gate that prevents ungoverned data from entering AI/HAI production use.
Q1.1: Have you published and formally approved all three AI/HAI data policies, AI Data Use Policy, Data Acceptable Use Policy (AI), and Data Intake / Sanction Gate, with archetype-specific controls, consent-basis requirements, cross-border-transfer restrictions, and a named-data-steward requirement?
Evidence Required: - [ ] AI Data Use Policy approved by Legal/Privacy/DPO and Security, covering permitted use per archetype by data class, consent-basis requirements (GDPR Art. 6/9 or sector equivalent), cross-border restrictions, use-change notification requirements, and special-category data prohibition for training/fine-tuning without an Art. 9(2) basis - [ ] Data Acceptable Use Policy (AI) specifying permitted/requires-approval/prohibited actions for engineers and data scientists handling AI data assets, including rules on fine-tuning datasets, retrieval stores, inference providers, prompt/completion log corpora, and a disclosure obligation for surfacing new AI data assets to the SM-Data inventory - [ ] Data Intake / Sanction Gate policy defining required gate artifacts by archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, evaluation/test set), amnesty path, and gate authority with permanent logging of decisions - [ ] Named data steward and owning team are required gate artifacts for all archetypes; regulated data assets require this even on the amnesty path - [ ] All three policies require attestation at hire and annually for engineers and data scientists handling AI data; violations are routed through program sponsor and Legal - [ ] Each policy is accessible to every engineer and data scientist handling AI data
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % engineers and data scientists with acknowledged AI Data 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/DPO and Security | n/a | ___ | Yes (all three) | ☐ | | | Data Intake / Sanction Gate policy includes per-archetype required-artifacts checklist | n/a | ___ | Yes | ☐ | |
Metric Collection Guidance: - AUP attestation rate: Query HR/LMS for current-year AI Data AUP acknowledgment completions divided by total engineering and data-science headcount handling AI data; 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/DPO and Security sign-off records exist for all three policies in the document management system. - Per-archetype checklist: Confirm the Sanction Gate policy document contains separate artifact lists for each of the six data archetypes, with training-corpus-specific controls (DPIA trigger assessment, Art. 6/9 basis, retention plan) explicitly required.
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. 10/Annex IV/Art. 9, GDPR Arts. 5/6/9/22/30/32/35/44–49, ISO/IEC 42001, SOC 2 CC6/CC7, and applicable sector-specific obligations (HIPAA, PCI-DSS 3.4, FINRA/SEC model-input retention), to the specific AI/HAI Data 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. 10 data governance row traces to AI Data Use Policy (training data class restrictions, consent basis, special-category prohibition) and Sanction Gate (lineage plus legal-basis artifact at go-live) - [ ] GDPR Art. 6 lawful basis row traces to AI Data Use Policy (consent-basis requirements) and Sanction Gate (legal-basis artifact required at gate) - [ ] GDPR Art. 30 records of processing row traces to Sanction Gate (lineage record plus named data steward constitutes the Art. 30 entry) - [ ] GDPR Art. 44–49 international transfers row traces to AI Data Use Policy (cross-border restrictions) and Data AUP (prohibited without named transfer mechanism) and Sanction Gate (transfer mechanism artifact at gate) - [ ] GDPR Art. 35 DPIA row traces to Sanction Gate (DPIA gate for Critical-tier training corpora and applicable High-tier assets); sector-specific obligations (HIPAA BAA, PCI-DSS 3.4, FINRA/SEC retention) are mapped to the AI Data Use Policy or Sanction Gate checklist rows
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | % regulated data assets in AI production use with a named data steward | measure | ___ | 100% for PII/PHI/PCI/customer-confidential assets | ☐ | | | Retroactive amnesty intake items opened and tracked as IM findings | measure | ___ | trending down QoQ (coverage increasing) | ☐ | | | Auditor evidence turnaround for GDPR Art. 6 basis 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. - Data steward coverage: Query SM-Data inventory for regulated data assets (PII, PHI, PCI, customer-confidential); verify each has a named data steward field populated. - Amnesty trend: Pull intake queue records tagged "amnesty" grouped by quarter; verify QoQ count is decreasing. - Auditor turnaround: Review any compliance or external audit requests for GDPR Art. 6 or Art. 10 evidence in the last 12 months; confirm the team produced a gate 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 Data Intake / Sanction Gate operational with a published intake SLA, a per-archetype artifacts checklist, and an amnesty path, and does ≥85% of new data sources entering AI production use 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, public domain, no personal data, no cross-border transfer) - [ ] Per-archetype artifacts checklists are published and keyed to each data archetype; training-corpus-specific controls (legal-basis documentation, no-regulated-PII confirmation or privacy-officer approval, cross-border transfer mechanism, retention and deletion plan) are explicitly required - [ ] Amnesty path is linked from the AUP, the intake form, and engineering/data-science team channels; retroactive intake records exist for previously ungated assets - [ ] Gate approval creates or updates the SM-Data inventory record with artifact links; gate authority (program sponsor or delegated DPO/data-governance lead) issues logged decisions - [ ] Exceptions are logged with owner, rationale, and review date; no exception open longer than 90 days without re-review - [ ] SM-Data inventory and intake queue can be queried to confirm gate-coverage rate for the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % new data sources entering AI production use that passed the sanction gate | measure | ___ | ≥85% within 12 months; 100% for Critical/High assets | ☐ | | | Gate intake SLA adherence (triaged within 5 BD) | measure | ___ | ≥90% | ☐ | | | Policy exception aging, exceptions open >90 days | measure | ___ | 0 exceptions past expiry | ☐ | | | Data-team cycle-time impact (intake-to-provisional-approval time) | measure | ___ | not increasing QoQ | ☐ | |
Metric Collection Guidance: - Gate coverage rate: Divide data assets with a gate record in the last 12 months by total new AI production data assets in the SM-Data inventory for the same period; split Critical/High separately. - 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. - Cycle-time trend: Track median days from intake submission to provisional approval by quarter; confirm the median 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: Deepen policy controls and compliance evidence per AI/HAI data risk tier, implement the DPIA gate for Critical training data, and produce audit-ready evidence trails continuously.
Q2.1: Have the three priority policies been extended with tier-specific addenda using the SM-Data L2 tier rubric, and do Critical data assets require DPIA gate closure, DPO and privacy-officer sign-off, HSM-rooted encryption confirmation, and legal-basis documentation reviewed by Legal before production training use?
Evidence Required: - [ ] Tier-specific addenda exist for Critical, High, Medium, and Low tiers, referencing the SM-Data L2 rubric tier definitions - [ ] Critical tier requires: full classification review plus DPIA gate (Art. 35 trigger assessed; DPIA conducted and closed or accepted-with-residual-risk before gate passage); DPO and privacy-officer sign-off at gate; legal-basis documentation reviewed by Legal; cross-border transfer mechanism confirmed; HSM-rooted encryption at rest confirmed before data is used; retention policy defined, enforced, and tested - [ ] Critical tier requires re-review within 14 days of any material change (new data class, new consumer, cross-border flow change, use change from inference to training) - [ ] High tier requires DPIA if Art. 35 trigger is present; DPO-delegated data-steward sign-off; legal-basis documentation; managed encryption with key audit - [ ] Policy-exception framework requires named owner, compensating control description, Legal/DPO reviewer acknowledgment, and expiry date (max 12 months); Critical-tier missing gate artifacts are blocking IM findings with no amnesty post-L2 - [ ] Gate records show DPO and privacy-officer sign-off for Critical data assets in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | DPIA gate completion rate for Critical training corpora and applicable High assets | measure | ___ | 100% before production training use | ☐ | | | % Critical/High data assets with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Exception register: % exceptions with named owner, compensating control, and expiry | measure | ___ | 100% | ☐ | | | Regulatory inquiry turnaround (evidence bundle within 5 BD) | measure | ___ | Yes (last 12 months) | ☐ | |
Metric Collection Guidance: - DPIA gate completeness: Query the DPIA register for all Critical training corpora and High-tier assets meeting Art. 35 triggers; verify each has a closed or accepted DPIA before the first production training run date. - Evidence bundle completeness: For each Critical/High data asset, check that all required bundle elements (classification label, lineage record, legal-basis document with DPO review date, DPIA status, retention policy confirmation, Art. 30 record, transfer mechanism, access-controls attestation, data steward, provider DPA status) are present and within refresh windows. - Exception register completeness: Audit every entry; each must have owner, compensating control with reviewer acknowledgment, and expiry date. - Auditor turnaround: Review any regulatory or auditor inquiries in the last 12 months; confirm each was answered 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: ___
Q2.2: Is a compliance evidence bundle continuously maintained for every Critical and High AI/HAI data asset, covering classification label, lineage record, legal-basis document, DPIA status, retention policy, Art. 30 record, transfer mechanism, access-controls attestation, data steward, and provider DPA status, with staleness inside tier-specific targets?
Evidence Required: - [ ] Evidence bundle structure is defined and implemented; bundle elements include: current classification label with last-updated date; lineage and provenance record; legal-basis document with DPO review date; DPIA status (complete/accepted-residual-risk/not-triggered) with last-review date; retention policy with last-tested date and deletion log; GDPR Art. 30 record entry linked to the asset; cross-border transfer mechanism or not-applicable declaration with last-validated date; access-controls attestation with last-review date; data steward and owning team; provider DPA status with last-validated date - [ ] Staleness rules are defined and enforced for Critical tier: classification label ≤90 days, retention test ≤90 days, provider DPA ≤90 days, legal-basis document reviewed on regulatory update; staleness triggers a PC-Data finding routed to IM - [ ] 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 - [ ] Median staleness of evidence-bundle elements for Critical assets is within target (≤30 days past refresh window) - [ ] DPIA findings that identify unnecessary data-class inclusion result in documented data-minimization decisions - [ ] Evidence registry is queryable to report completeness and staleness across Critical/High assets
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High data assets with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Median staleness of evidence-bundle elements for Critical assets | measure | ___ | ≤30 days past refresh window | ☐ | | | Sector-specific evidence bundle completeness for in-scope assets | measure | ___ | 100% | ☐ | | | Audit findings on AI/HAI data-governance controls, repeat findings | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Bundle completeness: For each Critical/High data 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. - Sector bundle completeness: For each in-scope asset subject to HIPAA, PCI-DSS 3.4, or FINRA/SEC, verify the corresponding sector evidence bundle is assembled with all required documents present and current. - 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 the DPIA gate operational for all Critical-tier training corpora and applicable High-tier assets meeting Art. 35 triggers, is an exception register operated with named owners and expiry dates reviewed monthly, and are sector-specific evidence bundles (HIPAA PHI / PCI-DSS 3.4 / FINRA/SEC as applicable) complete for in-scope assets?
Evidence Required: - [ ] DPIA gate is a mandatory step in the sanction gate for all Critical-tier training corpora and fine-tuning datasets; for High-tier assets meeting Art. 35 triggers (large-scale personal data, special-category data, systematic evaluation/profiling); DPIA must be conducted before data enters any training run or production retrieval store - [ ] Exception register is integrated with the gate; no exception is approved without tier-appropriate compensating control definition and expiry date; 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 gate artifacts are blocking IM findings with no amnesty - [ ] Sector-specific evidence bundles are generated and tracked: HIPAA PHI bundle (BAA, minimum-necessary assessment, de-identification confirmation), PCI-DSS 3.4 bundle (scope assessment, encryption evidence, cardholder-data handling record), FINRA/SEC model-input retention bundle (retention schedule, access log, disposal certification) - [ ] DPIA tracker is reviewed monthly; no Critical training corpus is in production without a closed or accepted DPIA - [ ] Completeness of sector-specific bundles is reported to the program sponsor
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | DPIA gate completion rate for Critical training corpora and applicable High assets | measure | ___ | 100% before production training use | ☐ | | | Exception register: % exceptions with named owner, compensating control, and expiry | measure | ___ | 100% | ☐ | | | Sector-specific evidence bundle completeness for in-scope assets | measure | ___ | 100% | ☐ | | | DPIA findings drive data-minimization decisions (documented) | measure | ___ | Yes | ☐ | |
Metric Collection Guidance: - DPIA gate completeness: Query DPIA register for all Critical training corpora; verify each has a closed or accepted DPIA with a date prior to the first production training run. - Exception register completeness: Audit every entry; each must have a named owner, compensating control description with reviewer acknowledgment, and a documented expiry date. - Sector bundle completeness: For each asset in scope of HIPAA, PCI-DSS 3.4, or FINRA/SEC, verify the corresponding bundle is assembled and all documents are present and current. - Data minimization: Review DPIA findings from the last 12 months; verify those identifying unnecessary data-class inclusion have corresponding documented decisions in the asset's record.
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 catalog, lineage, and classifier signals; drive policy updates from monitoring signals and external regulatory motion; and contribute to AI data-governance standards development.
Q3.1: Does a continuous attestation pipeline auto-update evidence bundles from data-catalog metadata events, model-registry lineage events, ETL/ELT pipeline events, classification-scanner findings, retention-enforcement events, and cross-border transfer changes, with an attestation currency SLO of ≤24 hours and ≤3 BD on-demand pack generation?
Evidence Required: - [ ] Evidence bundles auto-update from: data-catalog metadata events (new dataset, schema change, classification-label update), model-registry lineage events (new training-data source linked to a model version), ETL/ELT pipeline events (new destination is a retrieval or training store), classification-scanner findings (new regulated data class detected in an existing asset), retention-enforcement events (deletion log created when a prompt/completion corpus hits its retention limit), cross-border transfer changes (new inference provider in a different jurisdiction) - [ ] Attestation-generation pipeline is implemented: any regulatory or auditor request produces a provenance-complete evidence pack, regulation-keyed (EU AI Act Art. 10 evidence pack, GDPR processing-record pack, ISO 42001 AIMS data-governance set) 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 data 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 data assets | measure | ___ | ≤24h latency post-triggering event | ☐ | | | % Critical/High data assets continuously attested | measure | ___ | ≥99% of active Critical/High assets | ☐ | | | Material audit findings on AI/HAI data-governance 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 (catalog metadata change, classification-scanner finding) and the evidence bundle update; compute % of events where latency is ≤24 hours. - Continuous attestation completeness: Divide Critical/High data assets with a fresh evidence bundle (within SLO) by total active Critical/High data 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 data-governance 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-Data classification trends, IM-Data incident learnings, DPIA outcome patterns, 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-Data detection trends (data-class violations rising in classification-scanner findings), IM-Data incident learnings (policy gaps that created incident conditions), DPIA outcome patterns (asset types consistently generating high-residual-risk DPIAs), external regulatory updates (EU AI Act implementing acts on data, EDPB AI data-processing opinions, NIST AI RMF Playbook updates, US state privacy laws, GDPR enforcement decisions, sector-specific guidance from FDA/FINRA/OCC/HHS) - [ ] Versioned changelog exists for each of the three policies; each change entry cites the specific signal or regulatory update that prompted the change - [ ] EG-Data training content is updated within 30 days of any policy change - [ ] 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 | ☐ | | | Repeat-class regulated-data-in-AI exposure rate | 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. - Exposure rate: Compare the count of regulated-data-in-AI incidents per quarter over the last four quarters; verify the rate is not increasing in the most recent quarter.
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 data-governance topics, including sanction-gate schemas, DPIA templates for AI training data, Art. 30 record templates, or cross-border-transfer checklists, 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. 10 implementing-act consultations, EDPB AI data-processing guideline rounds, ISO/IEC 42001 community, DAMA DMBOK AI data-management chapters, NIST AI RMF Playbook Data working groups, sector regulators (FDA AI/SaMD data-governance requirements, FINRA model-input data obligations, HHS HIPAA AI guidance), or community bodies (CSA AI Safety Initiative, IAPP AI data-governance track, EDM Council, OpenSSF AI) - [ ] Contributions are technical artifacts implementing bodies can use, including sanction-gate schemas, DPIA templates for AI training data, compliance evidence bundle templates, cross-border-transfer checklists, Art. 30 record templates, not deadline-only comment letters - [ ] Contributed artifacts are maintained and versioned; last-updated dates confirm they are not stale - [ ] External recognition is documented: citations in published guidance, standards-body acknowledgment, working-group invitations, or community 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 artifacts maintained and not stale | measure | ___ | Yes (≤12 months since last update) | ☐ | | | Regulator / auditor / DPA feedback on 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, email confirmations from standards bodies, citations in published guidance, working-group invitations, or download/adoption metrics for published schemas. - Artifact maintenance: Review the last-updated dates for all contributed artifacts; verify none are more than 12 months stale without a planned update on record. - Regulator feedback: Review any written feedback from regulators, auditors, or DPAs in the last 12 months; note whether data-governance 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: Data Last Updated: 2026-05-15 Author: Verifhai
Instructions: