# 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.

| Priority requirement | What it demands for AI/HAI data | Which L1 policy carries it |
|---|---|---|
| **EU AI Act, Art. 10 (data governance)** | Training data governance for high-risk AI: relevance, representativeness, absence of errors, completeness; special-category data handling; data-governance practices documented in Annex IV technical documentation | AI Data Use Policy (training data class restrictions, consent basis, special-category prohibition) + Sanction Gate (lineage + legal-basis artifact at go-live) |
| **EU AI Act, Annex IV (technical documentation)** | Documentation of training data sources, processing operations, labeling methodology, data-governance measures | Sanction Gate (lineage and provenance record constitutes Annex IV data section) + Data AUP (provenance disclosure obligation) |
| **EU AI Act, Art. 9 (risk management)** | Iterative data-quality review and bias mitigation as part of the risk-management system | Sanction Gate (gate artifacts include TA snapshot noting data-quality risk; classification label required) |
| **GDPR, Art. 5 (data principles)** | Lawfulness, fairness, transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality | AI Data Use Policy (purpose limitation, use-change notification, cross-border restrictions) + Data AUP (prohibited data flows) |
| **GDPR, Art. 6 (lawful basis)** | Documented lawful basis before any personal data is processed (including in training, inference, retrieval) | AI Data Use Policy (consent-basis requirements) + Sanction Gate (legal-basis artifact required at gate) |
| **GDPR, Art. 9 (special-category data)** | Explicit prohibition on processing health, biometric, political, religious, sexual-orientation, criminal-record data without Art. 9(2) basis | AI Data Use Policy (special-category prohibition for training/fine-tuning) + Sanction Gate (DPO approval artifact if Art. 9 data present) |
| **GDPR, Art. 22 (automated decision-making)** | Safeguards when AI output materially drives a decision with legal or significant effect | AI Data Use Policy (decision-affecting-use flag triggers Art. 22 safeguards) + Sanction Gate (Art. 22 safeguards checklist for decision-affecting inference input streams) |
| **GDPR, Art. 30 (records of processing)** | Records of processing activities including AI training and inference processing; must be maintained by controller and processor | Sanction Gate (lineage record + named data steward constitutes the Art. 30 entry for this data asset) |
| **GDPR, Art. 32 (security of processing)** | Appropriate technical and organizational measures for data security, including encryption and access control | AI Data Use Policy (DPA coverage required for inference providers) + Sanction Gate (classification label triggers tier-appropriate encryption and access controls from SM-Data L2 tier-treatment matrix) |
| **GDPR, Art. 44–49 (international transfers)** | Lawful transfer mechanism before personal data reaches a third country for training, storage, or inference | AI Data Use Policy (cross-border restrictions) + Data AUP (prohibited without named transfer mechanism) + Sanction Gate (transfer mechanism artifact at gate) |
| **GDPR, Art. 35 (DPIA)** | Data Protection Impact Assessment required before processing likely to result in high risk (large-scale processing, special-category data, systematic profiling, all common in AI training) | Sanction Gate (DPIA gate for Critical-tier training corpora and fine-tuning datasets; DPIA artifact required at gate for applicable assets) |
| **ISO/IEC 42001 (AIMS)** | AI management system data-governance controls; supplier data processing; data quality and provenance | Program charter (SM-Data) + all three L1 policies serve as AIMS data-governance evidence |
| **SOC 2, CC6 / CC7 (logical access / system operations)** | Access controls and monitoring for data assets used in AI systems | Sanction Gate (access-controls documentation at gate) + Data AUP (prohibited unauthorized data export) |
| **HIPAA (sector: clinical AI / PHI)** | PHI in AI training or inference requires Business Associate Agreement with any data processor; minimum-necessary standard | AI Data Use Policy (PHI requires DPA/BAA) + Sanction Gate (BAA artifact required for PHI assets) |
| **PCI-DSS 3.4 (sector: payment AI)** | Cardholder data in model training input must meet PCI-DSS storage and encryption controls; model-input data retention restrictions | AI Data Use Policy (PCI cardholder data prohibited in training without Security Council waiver) + Sanction Gate (PCI scope assessment at gate for payment-context assets) |
| **FINRA / SEC model-input retention (sector: financial AI)** | Model input data and inference logs subject to record-retention obligations (17a-4 / FINRA 4370) | Sanction Gate (retention plan artifact at gate for financial-context inference input streams and prompt/completion log corpora) |

**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)

| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| % of new data sources entering AI production use that passed the sanction gate | measure | ≥85% within 12 months; 100% for Critical/High assets | Intake queue vs. SM-Data inventory |
| % of regulated data assets in AI production use with a named data steward | measure | 100% for PII/PHI/PCI/customer-confidential assets | SM-Data inventory |
| % engineers and data scientists with acknowledged AI Data AUP (current-year) | measure | ≥95% | HR / LMS attestation |
| Priority compliance map published and reviewed in last 12 months | n/a | Yes | Document registry |
| Retroactive amnesty intake items opened and tracked as IM findings | measure | trending down QoQ (coverage increasing) | Intake queue tagged "amnesty" |

#### 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)

| Metric | Baseline | L2 Target | Source |
|---|---|---|---|
| % Critical/High data assets with complete compliance evidence bundle | measure | ≥95% | Evidence registry × SM-Data inventory |
| Median staleness of evidence-bundle elements for Critical assets | measure | ≤30 days past refresh window | Evidence registry |
| DPIA gate completion rate for Critical training corpora and applicable High assets | measure | 100% | DPIA register |
| Exception register: % exceptions with named owner, compensating control, and expiry | measure | 100% | Exception register |
| Sector-specific evidence bundle completeness for in-scope assets | measure | 100% | Sector evidence artifact |

#### 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)

| Metric | Baseline | L3 Target | Source |
|---|---|---|---|
| Attestation-pack generation SLA for regulator / auditor | measure | ≤3 business days | Evidence-ops telemetry |
| Attestation currency SLO for Critical/High data assets | measure | ≤24h latency post-triggering event | Evidence pipeline telemetry |
| Policy refresh cadence met | measure | quarterly, on calendar | Policy changelog |
| % policy changes traceable to ML/IM telemetry or named regulatory update | measure | 100% | Policy change rationale |
| Public regulatory / standards contributions per year | 0 | ≥2 | Contribution log |
| External recognition (citations, adoptions, invitations) | 0 | tracked, trending up | External artifacts |

#### 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