Policy & Compliance (PC)

Data Domain - HAIAMM v3.0

Practice Overview

Objective: 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.

Description: PC-Data codifies three priority policies specific to data flowing through AI/HAI systems, an AI Data Use Policy governing what data classes may be used for training, inference, and eval and under what consent basis; a Data Acceptable Use Policy governing what engineers and data scientists may do with AI data assets; and a Data Intake / Sanction Gate policy defining what every new data source feeding AI must produce before it is admitted. It maps those policies to the compliance regimes that directly apply: EU AI Act Art. 10 data governance and Annex IV documentation; GDPR Arts. 5/6/9/22/30/32/44–49 (lawful basis, special-category data, automated decisioning, records, security, transfers); ISO/IEC 42001 AIMS data governance; sector-specific (HIPAA PHI, PCI-DSS 3.4, FINRA model-input retention); SOC 2 CC6/CC7. At L1 the goal is not an exhaustive policy library, it is the minimum enforceable stack that gates data into AI systems and traces every relevant regulation to a single named policy.

Context: Most organizations inherit data-governance policies written for classic data warehouses and application databases. None of those policies answer the questions AI/HAI data raises: Which data classes may be used as fine-tuning input without privacy-officer sign-off? Who may authorize a new retrieval source for a production RAG pipeline? What consent basis is required before inference inputs containing personal data are logged into a prompt/completion corpus? How does GDPR Art. 10 special-category data prohibition apply to a medical training corpus? Without AI-specific data policies and an explicit compliance map, regulated data flows into training datasets, retrieval stores are populated from unclassified sources, and prompt/completion logs accumulate personal data past retention limits, all before anyone realizes the obligation exists. PC-Data closes that gap by governing what the organization feeds into AI/HAI systems, in contrast to PC-Software which governs what the organization builds.

Maturity Level 1

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

At this level, the organization ships the minimum viable policy stack for AI/HAI data governance, maps each policy to the regulations and standards that make it auditable, and implements the sanction gate through which every new data source feeding AI must pass.

Dependencies

• SM-Data L1 (required): the AI/HAI data inventory, archetype taxonomy, and program charter are the substrate the policies govern, PC-Data L1 cannot be operational without the inventory PC references.
• Alignment (not a hard dependency): enterprise Legal/Privacy/DPO function for data-handling obligations; existing data-governance program if one exists; engineering and data-science management authority to enforce the sanction gate.
• Supports / unblocks: EG-Data L1 (workforce training needs published policies as the teaching object); SR-Data L1 (requirements packs inherit policy guardrails); SA-Data L1 (reference patterns operationalize the policy's archetype controls); IM-Data L1 (exception and violation handling flows from policy).

Desired Outcomes

• Three short, AI-specific data policies exist, are approved by Legal/Privacy/DPO and Security, are accessible to every engineer and data scientist handling AI data, and are acknowledged at hire and annually.
• A one-page priority compliance map lets auditors and regulators trace each requirement to the single policy that carries it.
• No new data source enters AI/HAI production use without passing the sanction gate; the gate produces a required-artifacts checklist for each data archetype.
• Every regulated data asset in AI production use (training corpus with PII, retrieval store with customer data, prompt/completion log corpus with personal data) has a named data steward and a logged gate decision.
• Shadow data surfaces for retroactive intake through an amnesty path rather than going deeper underground.
• The program demonstrates EU AI Act Art. 10 data governance obligations with a documented chain from policy → intake → gate decision → named data steward.

Activities

A) Publish the three priority AI/HAI data policies

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

1. AI Data Use Policy, what data may be used for what AI purposes: - Permitted use per archetype by data class: regulated PII / PHI / PCI / customer confidential as a fine-tuning input requires explicit privacy-officer approval and documented legal basis (GDPR Art. 6/9 or sector equivalent); same data at inference requires DPA coverage of the inference provider; same data in a prompt/completion log corpus requires retention-limit policy and deletion capability. - Consent-basis requirements: personal data used in training requires a lawful basis under GDPR Art. 6 (and Art. 9 for special-category data); basis must be documented in the asset's inventory record before the training run begins; scraped data without verified consent basis is prohibited for training on personal data without Legal sign-off. - Cross-border restrictions: personal data transferred to a third country for training, inference, or storage triggers GDPR Art. 44–49; no cross-border transfer permitted without an adequacy decision, SCC, IDTA, or BCR on file; sector-specific localization rules (HIPAA, ITAR, financial data residency) override where stricter. - Use-change notification: data originally collected for purpose A may not be repurposed for AI training without a GDPR Art. 5(1)(b) compatibility assessment and Legal sign-off. - Special-category data prohibition: GDPR Art. 9 special-category data (health, biometric, political opinion, religion, sexual orientation, racial/ethnic origin, criminal records) prohibited in training or fine-tuning without explicit consent or another Art. 9(2) basis documented and reviewed by the DPO.

2. Data Acceptable Use Policy (AI), what engineers and data scientists may and may not do with AI data assets: - Permitted: use sanctioned data sources listed in the SM-Data inventory; use sanctioned vector-store clients and embedding models for retrieval stores; use sanctioned inference providers covered by a current DPA; log prompt/completion events to sanctioned log stores with defined retention. - Requires approval before doing: add a new data source to a training corpus or fine-tuning dataset; add a new collection to a production retrieval store; change the inference provider receiving personal data; export embeddings or fine-tuning datasets outside the org's governed environment; use a prompt/completion log corpus for a new purpose (e.g., switching from audit logging to model training). - Prohibited without named sign-off: training on GDPR Art. 9 special-category data without DPO approval and documented Art. 9(2) basis; sending regulated data to an inference endpoint not covered by a current DPA; retaining prompt/completion logs past the defined retention limit; transferring embeddings or fine-tuning datasets to a country without an Art. 44–49 transfer mechanism. - Disclosure obligation: engineers and data scientists must surface new AI data assets to the SM-Data inventory, including side-project training datasets, ad-hoc retrieval store indexes, and eval sets built from production traffic. - Attestation required at hire and annually; violations routed through the program sponsor and Legal.

3. Data Intake / Sanction Gate, what every new data source feeding AI must produce before admission: - Gate required before any new data asset enters production AI use for any archetype (training, inference input, retrieval, logging, embedding, eval); experimental and staging uses must be in the inventory but do not require full gate passage. - Required gate artifacts by archetype (minimum at L1): - All archetypes: data classification label, lineage and provenance record (source, license or consent basis, collection method), named data steward and owning team. - Training corpus / fine-tuning dataset: legal-basis documentation (Art. 6/9 basis or sector equivalent), no-regulated-PII confirmation or privacy-officer approval if regulated data included, cross-border-transfer mechanism on file if applicable, retention and deletion plan. - Inference input stream: DPA coverage of the inference provider confirmed, cross-border transfer mechanism if data leaves jurisdiction, retention-limit policy for prompt/completion logs. - Retrieval store: source-document classification confirmed (labels propagate to the index), retrieval-poisoning risk noted in TA snapshot, deletion-capability confirmed (right-to-erasure support). - Prompt/completion log corpus: retention policy defined and enforced, access controls documented, secondary-use restriction (logs may not be used for training without a new gate passage). - Embedding store: source-data classification documented, inversion-defense controls noted, retention policy defined. - Evaluation / test set: source classification confirmed, no production PII included without anonymization or privacy-officer approval. - Amnesty path: assets already in AI production use 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. - Gate authority: the program sponsor (or delegated DPO / data-governance lead) issues the gate decision; the decision and artifact checklist are logged permanently.

B) Map the three policies to the priority compliance requirements

Build a one-page priority compliance map. At L1 the goal is traceability: an auditor asking "how is GDPR Art. 5 data-minimization principle met for training data?" reaches one row, one policy, and one artifact.

C) Operate the sanction gate and track foundational compliance outcomes

Policies without an enforced gate do not reduce shadow data in AI. L1 closes the loop by putting the three policies behind a single gate checkpoint and measuring whether the gate catches new data sources before they reach production AI use.

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 data assets, public domain, no personal data, no cross-border transfer). - Artifacts checklist is archetype-keyed, the engineer or data scientist submitting intake receives the checklist for their archetype. - Integration with the SM-Data inventory: gate approval creates or updates the inventory record with artifact links. - Amnesty path is visible: linked from the AUP, the intake form, and the engineering/data-science team channels. - Exceptions logged with owner, rationale, and review date; no exception open longer than 90 days without re-review.

Outcome Metrics (L1)

Process Metrics (leading)

• Gate intake SLA adherence, ≥90% of intakes triaged within 5 BD; ≥90% of Low-tier intakes provisionally approved within 10 BD.
• 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, a new archetype is added, or a regulatory enforcement decision materially changes interpretation; at minimum annually.
• Gate-checklist accuracy, archetype-keyed required-artifacts checklists reviewed quarterly.

Effectiveness Metrics (business value)

• Data-team cycle-time impact, time from "intake submitted" to "provisional approval issued" should not increase as the gate matures; the gate is an enabler, not a bottleneck.
• Retroactive catch rate, % of assets discovered through amnesty or shadow-data discovery that would have reached AI production without the gate.
• Auditor evidence turnaround, a compliance or external audit asking "show me the GDPR Art. 6 basis for this training corpus" is satisfied within 5 business days from the gate record.

Success Criteria

• Three priority policies published, approved by Legal/Privacy/DPO and Security, and communicated to all engineers and data scientists handling AI data.
• One-page priority compliance map published, covering all rows in the table above; linked from each policy.
• Sanction gate operational with a published SLA, a per-archetype artifacts checklist, and an amnesty path for previously ungated data assets.
• ≥95% of engineers and data scientists handling AI data have acknowledged the AI Data AUP in the current year.
• ≥85% of new data sources entering AI production use in the last 12 months passed the gate (100% for Critical/High-tier).
• Every regulated data asset in AI production use has a named data steward logged in SM-Data inventory.

Maturity Level 2

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

At this level, policy depth is calibrated to the risk tier assigned in SM-Data L2. Critical training corpora and fine-tuning datasets carry deeper legal-basis requirements, explicit DPO and privacy-officer sign-off, DPIA closure, and continuously assembled compliance evidence. Low public eval sets stay fast-tracked. Evidence for EU AI Act Art. 10 obligations, GDPR processing records (Art. 30), and ISO/IEC 42001 AIMS data-governance controls assembles automatically for every Critical/High-tier data asset rather than at audit time.

Dependencies

• PC-Data L1 (required): three priority policies, compliance map, and sanction gate must be live.
• SM-Data L2 (required): the risk-tier rubric and tier-treatment matrix drive differential policy depth. PC-Data L2 inherits the tier definitions from SM-Data L2 and cannot operate without them.
• Supports / unblocks: EG-Data L2 (tier-calibrated reviewer training needs tier-aware policies); TA-Data L2 (per-asset deep threat models for Critical/High need the policy constraints to bound scope); IR-Data L2 (drift detection confirms policy adherence post-gate); IM-Data L2 (tier-aware incident playbook enforces policy SLAs).

Desired Outcomes

• Policy depth visibly differs by tier, Critical training corpora require DPIA closure, DPO sign-off, and encryption upgrade before gate passage; Low public eval sets use fast-track with base documentation only.
• Every Critical and High AI/HAI data asset has a live compliance evidence bundle (classification label, lineage record, legal-basis document, DPIA if applicable, retention policy confirmation, Art. 30 record, transfer mechanism if cross-border, access-controls attestation) that a regulator can open today.
• DPIA gate is operational for all Critical-tier training data and fine-tuning datasets, and for any High-tier asset that meets GDPR Art. 35 triggers (large-scale, special-category, or systematic profiling).
• Policy exceptions have finite lifespans with named owners; no stale exceptions accumulate unnoticed.
• Sector-specific obligations (HIPAA for clinical AI training data, PCI-DSS 3.4 for payment-context training input, FINRA/SEC model-input retention) are operationalized for the assets they apply to.

Activities

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

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

• Critical: full classification review + 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 and on file; HSM-rooted encryption at rest confirmed before data is used; retention policy defined, enforced, and tested; re-review mandatory on every material change (new data class added, new consumer added, cross-border flow changes, use changes from inference to training) within 14 days.
• High: full classification review + DPIA if Art. 35 trigger present; DPO-delegated data-steward sign-off; legal-basis documentation required; transfer mechanism confirmed; managed encryption with key audit; re-review on material change within 30 days.
• Medium: base classification review + lineage record; fast-track gate if no personal data and no cross-border transfer; re-review annually or on material change within 60 days.
• Low: lineage record only; self-attested checklist; re-review at annual review.

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

B) Continuous compliance evidence assembly

For every Critical and High AI/HAI data asset, maintain a live compliance evidence bundle that auto-assembles: - Current classification label and last-updated date. - Lineage and provenance record (source, consent/license basis, collection method, date). - Legal-basis document (Art. 6 or Art. 9 basis, or sector equivalent) with DPO review date. - DPIA status: complete / accepted-residual-risk / not-triggered, with last-review date. - Retention policy: defined / enforced / last-tested date; deletion log for any assets past retention. - GDPR Art. 30 record entry linked to this asset. - Cross-border transfer mechanism: adequacy decision / SCC / IDTA / BCR or not-applicable, with last-validated date. - Access-controls attestation with last-review date. - Data steward and owning team, with contact for subject-access-right responses. - Inference-provider or storage-provider DPA status (current / expired / not-applicable) with last-validated date.

Staleness rules: any element past its tier-specific refresh window triggers a PC-Data finding routed to IM. Critical staleness thresholds, classification label: 90 days; DPIA: review if risk profile changes; retention test: 90 days; legal-basis document: review on regulatory update; provider DPA: 90 days. The evidence bundle is the primary artifact a regulator or auditor receives when asking about any specific AI/HAI data asset.

C) DPIA gate and sector-specific evidence bundles

• DPIA gate is a mandatory step in the sanction gate for all Critical-tier training corpora and fine-tuning datasets, and for High-tier assets meeting any of: large-scale processing of personal data, special-category data (Art. 9), systematic evaluation of data subjects (profiling). The DPIA must be conducted before the data enters any training run or production retrieval store.
• Sector-specific evidence bundles generated from the compliance evidence bundle for applicable assets: HIPAA PHI bundle (BAA, minimum-necessary assessment, de-identification confirmation if used), 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). Completeness tracked.
• Exception register integrated with the gate: no exception approved without tier-appropriate compensating control and expiry. Monthly exception aging review.

Outcome Metrics (L2)

Process Metrics (leading)

• Evidence-bundle refresh cadence honored by tier (Critical: classification ≤90d, DPIA reviewed on risk change, retention test ≤90d, provider DPA ≤90d).
• Exception aging reviewed monthly; zero exceptions past expiry un-escalated.
• DPIA tracker reviewed monthly; no Critical training corpus in production without a closed or accepted DPIA.

Effectiveness Metrics (business value)

• Regulatory inquiry turnaround, evidence bundle assembled for a regulator or auditor request within 5 business days.
• Audit findings on AI/HAI data-governance control set trending down; repeat findings = 0.
• DPIA findings drive data-minimization decisions, training datasets reduced in scope when DPIA identifies unnecessary data-class inclusion.

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.
• DPIA gate operational; 100% of Critical training corpora have a closed or accepted DPIA before production training use.
• 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 catalog, lineage, and classifier signals; drive policy updates from monitoring signals and external regulatory motion; and contribute to AI data-governance standards development

At this level, compliance is a byproduct of the data-governance pipeline rather than a separate artifact assembly step. Catalog events, lineage API updates, and classification-scanner findings feed the compliance evidence bundle continuously. Policy updates are data-driven, IM-Data incident learnings and ML-Data detection trends refresh the policy stack on a known cadence. The program contributes to AI data-governance standards, EU AI Act implementing acts on data, EDPB AI guidance, ISO/IEC 42001 community, DAMA, and sector regulators receive evidence-backed input from the organization's experience governing AI/HAI data at scale.

Dependencies

• PC-Data L2 (required): evidence bundle, DPIA gate, and exception register must be running.
• SM-Data L3 (required): automation substrate, signal-driven inventory and tier updates feed the continuous attestation pipeline.
• ML-Data L2+ (required): classification-scanner telemetry and prompt/completion log anomalies feed the policy-refresh cycle.
• Supports / unblocks: PC-Data L3 evidence posture enables the other 11 Data-domain practices to claim continuous attestation rather than periodic evidence snapshots.

Desired Outcomes

• Compliance attestation for any AI/HAI data asset is generated on demand in hours, with full provenance from catalog events, lineage metadata, and classification-scanner findings that constitute the evidence.
• Policy refresh is evidence-driven and externally anchored, monitoring trends, DPIA findings, EU AI Act implementing acts on data, EDPB guidance, US state privacy-law enforcement, and GDPR enforcement decisions feed a versioned, dated policy changelog.
• The program is a recognized voice in AI data-governance regulation, EU AI Act Art. 10 implementation guidance, EDPB AI data-processing opinions, ISO/IEC 42001 community receive substantive input from practitioners, not only vendors.

Activities

A) Continuous compliance attestation from catalog, lineage, and classifier signals

• 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 auto-opens a PC-Data finding).
• Attestation-generation pipeline: any regulatory or auditor request produces a provenance-complete evidence pack for any data asset, 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.
• SLO: all Critical/High data assets continuously attested; attestation currency ≤24 hours latency after a triggering event; completeness ≥99% of active Critical/High assets.

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

• Quarterly policy-refresh cycle driven by: ML-Data detection trends (what data-class violations are rising in classification-scanner findings), IM-Data incident learnings (which policy gaps created the incident conditions), DPIA outcome patterns (which asset types consistently generate high-residual-risk DPIAs), external regulatory and standards 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 by lead supervisory authorities, sector-specific guidance from FDA/FINRA/OCC/HHS).
• Refresh output: versioned changelog for each of the three policies, approved by Legal/Privacy/DPO and Security; EG-Data training content updated within 30 days of any policy change.
• Regulatory-motion tracker: a maintained log of open regulatory instruments with expected effective dates, mapped to the policy they will affect; working group reviews it quarterly.

C) Standards contribution and external engagement

• Participate in AI data-governance standards and regulatory 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).
• Contribute AI-data-specific artifacts to public standards: sanction-gate schemas, DPIA templates for AI training data, compliance evidence bundle templates, cross-border-transfer checklist for AI inference providers, Art. 30 record templates for AI data assets, through CSA AI Safety Initiative, IAPP AI data-governance track, DAMA, EDM Council, OpenSSF AI.
• Target: at least 2 substantive public comments or standards contributions per year on AI/HAI data policy and compliance 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 by the working group; no open instrument missed.
• Contribution pipeline ≥2 items in-flight at any time.

Effectiveness Metrics (business value)

• Regulator / auditor / DPA feedback explicitly positive on attestation posture.
• Material audit findings on AI/HAI data-governance controls = 0 in the last 12 months.
• Policy changes measurably close incident classes identified in prior quarters (repeat-class regulated-data-in-AI exposure rate trends down).
• Contributed DPIA templates and Art. 30 record schemas adopted externally, measured by citations, downloads, standards-body acknowledgment.

Success Criteria

• On-demand attestation pack generation inside 3 business days for any active AI/HAI data asset; SLA met in last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High data 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 data policy.
• External recognition documented.
• Zero material audit findings on AI/HAI data-governance controls in the last 12 months.

Key Success Indicators

Level 1: - Three priority policies published and approved by Legal/Privacy/DPO and Security: AI Data Use Policy, Data Acceptable Use Policy (AI), Data Intake / Sanction Gate. - One-page priority compliance map published, covering EU AI Act Art. 10 / Annex IV, 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). - Sanction gate operational with a per-archetype artifacts checklist, published SLA, and amnesty path for previously ungated data assets. - ≥95% of engineers and data scientists handling AI data have acknowledged the AI Data AUP in the current year. - ≥85% of new data sources entering AI production use in the last 12 months passed the gate; 100% for Critical/High-tier.

Level 2: - Tier-specific policy addenda in place; Critical data assets carry DPIA gate passage, DPO sign-off, and HSM-rooted encryption before production training use; compliance evidence bundles live for all Critical/High assets with staleness inside tier-specific targets. - Exception register comprehensive with named owners, compensating controls, and expiry dates; monthly aging review active; Critical-tier missing gate artifacts treated as blocking findings. - Sector-specific evidence bundles (HIPAA PHI / PCI-DSS 3.4 / FINRA/SEC 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 data policy; external recognition documented. - Zero material audit findings on AI/HAI data-governance controls in the last 12 months.

Common Pitfalls

Level 1: - ❌ Reusing the generic data-governance policy without AI-specific clauses, no rule on training-data consent basis, no archetype-specific controls, no cross-border restriction for inference providers; auditors cannot trace GDPR Art. 6 to a training corpus. - ❌ Sanction gate applies only to data sources formally proposed through data engineering, misses training datasets uploaded by researchers, retrieval stores added by engineering teams, and prompt/completion log corpora accumulating in object storage without review. - ❌ Compliance map lists frameworks but does not say which policy carries which regulation, auditors must trace coverage themselves and typically conclude it is untraceable. - ❌ No amnesty path, data scientists with ungoverned training datasets hide them rather than surface them; shadow-data inventory stays incomplete. - ❌ Gate checklist is archetype-agnostic, a training corpus and a retrieval store receive the same list; training-corpus-specific controls (DPIA trigger assessment, Art. 6 basis, retention plan) are never actually required. - ❌ Named data steward role not assigned, regulated data assets in AI production use have no named accountability; EU AI Act Art. 10 and GDPR Art. 30 obligations are acknowledged in policy but not operationalized. - ❌ Inference-provider DPA status never checked at gate, the team trusts the vendor's privacy page rather than a current contract.

Level 2: - ❌ DPIA gate exists on paper but is conducted after the training run begins, the DPIA finding arrives too late to influence data-minimization decisions. - ❌ Compliance evidence bundle is a folder of PDFs that only the DPO can navigate, a second reviewer cannot assemble the regulator pack without them. - ❌ Evidence staleness thresholds exist but no alert fires when they are exceeded, the legal-basis document ages past its review window for a Critical training corpus and nobody notices until an audit. - ❌ Sector-specific bundles are treated as "covered by the general DPA", HIPAA BAA specifics or PCI-DSS 3.4 evidence are not operationalized for training-data assets in scope. - ❌ Exception register exists but expiry dates are never enforced, stale exceptions from the amnesty window quietly become the permanent state for a significant fraction of the inventory.

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 is needed. - ❌ Policy refresh is cadence-only, quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain what DPIA finding prompted which change. - ❌ External regulatory contributions are deadline-only comment letters rather than technical artifacts that implementing bodies use in guidance. - ❌ Contributed DPIA templates and Art. 30 schemas are published once and then go stale, external practitioners stop trusting the program because they find outdated versions. - ❌ ROI narrative omits compliance cost-reduction evidence, the biggest L3 business case (lower DPIA preparation overhead, lower regulatory-inquiry response time, faster data-source onboarding) is never measured.

Practice Maturity Questions

Level 1: 1. Have you published and formally approved the three priority 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? Is there a one-page 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, sector-specific) to the specific policy that carries it? 2. Is the sanction gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), 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)? 3. Are ≥95% of engineers and data scientists handling AI data covered by a current-year AI Data AUP acknowledgment, and does every regulated data asset in AI production use have a named data steward logged in the SM-Data inventory?

Level 2: 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Data L2 rubric), and do Critical data assets carry DPIA gate closure, DPO sign-off, HSM-rooted encryption confirmation, and legal-basis documentation before production training use, with a live compliance evidence bundle covering classification label, lineage record, legal-basis document, DPIA status, retention policy, Art. 30 record, transfer mechanism, access-controls attestation, and provider DPA status? 2. Is the DPIA gate operational for all Critical training corpora and applicable High assets (meeting Art. 35 triggers), with 100% of Critical training corpora having a closed or accepted DPIA before production training use, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing gate artifacts treated as blocking findings, and sector-specific evidence bundles (HIPAA / PCI-DSS 3.4 / FINRA/SEC as applicable) complete for in-scope assets?

Level 3: 1. Does a continuous attestation pipeline auto-update evidence bundles from catalog events, lineage API updates, classification-scanner findings, retention-enforcement events, and cross-border-transfer changes, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High data assets continuously attested? 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Data classification trends + IM-Data incident learnings + DPIA outcome patterns + regulatory-motion tracker) 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 data-governance topics (EU AI Act Art. 10 implementing guidance, EDPB AI data-processing opinions, NIST AI RMF, ISO/IEC 42001, DAMA, sector regulators), with documented external recognition?

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