Strategy & Metrics (SM)

Data Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/SM-Data-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Governance

Objective: Stand up AI data governance, inventory every corpus AI touches, and baseline the metrics that prove regulated data is not leaving governed stores for AI services.

Description: A program at this level knows which data its AI systems consume and produce. One inventory covers all seven data archetypes, from training corpora through retrieval stores to the prompt and completion logs that are themselves a regulated corpus most organizations forget they created. Data-loss prevention on AI egress is the domain's shadow-AI mechanism, and canary-tagged datasets make unsanctioned flows detectable rather than theoretical. Every corpus has a named steward, a classification, and a lineage record, so the question of whether customer data reached a model has an answer that does not require an investigation.

---

Maturity Level 1, Foundational

Objective: Stand up AI data governance, inventory every corpus AI touches, and baseline the metrics that prove regulated data is not leaving governed stores for AI services.

A program at this level knows which data its AI systems consume and produce. One inventory covers all seven data archetypes, from training corpora through retrieval stores to the prompt and completion logs that are themselves a regulated corpus most organizations forget they created. Data-loss prevention on AI egress is the domain's shadow-AI mechanism, and canary-tagged datasets make unsanctioned flows detectable rather than theoretical. Every corpus has a named steward, a classification, and a lineage record, so the question of whether customer data reached a model has an answer that does not require an investigation.

Dependencies

• Required: None.
• Alignment (not blocking): Existing data governance and records-management programs, so AI data classification extends the enterprise scheme rather than inventing a parallel one; FinOps allocation for retrieval, embedding and training compute
• Supports / unblocks: PC-Data-L1; TA-Data-L1; SR-Data-L1; SA-Data-L1; ML-Data-L1; IM-Data-L1; Required by: DR-Data-L1, EG-Data-L1, EH-Data-L1, IR-Data-L1, SM-Data-L2, ST-Data-L1

Desired Outcomes

• Every corpus an AI system consumes or produces is inventoried, classified and attributed to a named data steward.
• Prompt and completion logs are governed as a regulated corpus in their own right, with a defined retention period.
• Unsanctioned data flows to AI services are detectable through data-loss prevention on AI egress and canary tagging.
• Data lineage from source to model is recorded well enough to answer a subject-access or regulator request without an investigation.
• Cross-border AI data flows are known and mapped to a lawful transfer basis.

Activities

A) Charter AI data governance and name the stewards

Publish an AI data governance charter within the first 30 days, sponsored jointly by the CISO and the Chief Data Officer or equivalent, and co-signed by Privacy counsel. The charter names the seven in-scope archetypes, being training corpus, fine-tuning dataset, inference input stream, retrieval store, embedding store, prompt and completion log corpus, and evaluation or test set; it assigns a named data steward per corpus rather than per system, because corpora outlive the systems that created them; it establishes three priority policies, being AI Data Use, Data Acceptable Use for AI, and the data intake and sanction gate; and it defines decision rights over which data classes may reach which model deployments, who approves an exception and who owns the revocation path when a flow must stop. The working group includes Data Governance, Privacy and Legal counsel, AI/ML engineering, Compliance and the platform team that operates the stores.

B) Inventory the corpora and instrument AI-egress detection

Build one AI data inventory recording, per corpus, the archetype, steward, classification against the enterprise scheme, volume and growth rate, lineage from originating source, the model deployments that consume it, whether it is used at training or inference or both, retention period and legal basis, cross-border flow and its transfer mechanism, and subject-access exposure. Seed it from the data catalogue, pipeline telemetry, training-run registries, cloud storage inventories and access-control groups. Then instrument the domain's shadow-AI mechanism: data-loss prevention rules on egress to model-provider endpoints, tuned to the classified data patterns that matter rather than to everything, and canary records seeded into governed stores so that a canary appearing in a model output or an external log is unambiguous evidence of an ungoverned flow. Treat prompt and completion logs as a first-class corpus in the inventory; they accumulate regulated data by default, they are frequently replicated to observability vendors, and they are the corpus most often missed at the first inventory pass.

C) Baseline the data scoreboard and open the retrieval ledger

Instrument and report quarterly: inventory coverage against discovered corpora, the share of corpora carrying a classification and a named steward, regulated-data flows to AI services that lack a sanctioned path, canary-trigger events, and the share of corpora with a defined retention period. Open the consumption side of the ledger for this domain, recording retrieval cost per query, embedding re-index cost per indexed document, and training-run cost per run, each attributed to the corpus and the owning team. Retention cost belongs in the ledger explicitly, because it is the mechanism by which log corpora get silently truncated to save money, taking with them the evidence that monitoring and deployer-duty obligations depend on. Record the denominator per archetype rather than reporting absolute storage or query spend, and where corpus-level cost allocation does not exist, record the ledger as blocked on allocation and raise the tagging requirement with FinOps.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
AI data inventory coverage against discovered corpora	first catalogue reconciliation	≥85% within 12 months	Data catalogue reconciled against pipeline and storage telemetry
Corpora carrying a classification and a named steward	first inventory pass	100% of regulated and confidential corpora	AI data inventory steward and classification fields
Regulated-data flows to AI services without a sanctioned path	first month of DLP telemetry	0 for regulated classes, and falling for confidential	DLP rules on AI-endpoint egress
Canary-trigger events indicating an ungoverned corpus flow	first quarter after canary seeding	0 sustained, with every trigger investigated within 5 business days	Canary detection log
Corpora with a defined retention period and legal basis	first inventory pass	≥90%, and 100% for prompt and completion log corpora	AI data inventory retention field

Process Metrics (leading)

• DLP rule coverage for AI egress is reviewed monthly against the current model-provider endpoint list.
• Canary seeding refreshed quarterly across governed stores, with seeding coverage recorded.
• Inventory freshness: ≥80% of corpus records reviewed within 90 days.
• Data steward roster reconciled against HR records quarterly so departures do not orphan a corpus.

Effectiveness Metrics (business value)

• Time to answer a subject-access or regulator question about whether specific data reached a model falls quarter over quarter.
• Documented cases where canary or DLP detection caught an ungoverned flow before it became a reportable event.
• Reuse of sanctioned retrieval stores rises relative to teams standing up their own.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Retrieval cost per query, by retrieval store	per retrieval query	retrieval amplification, where a single request fans out across a store, and systematic extraction reconnaissance, which is expensive and shows in the cost profile before it shows in the access logs	Vector-store and gateway telemetry joined to corpus inventory
Embedding re-index cost per indexed document	per indexed document	unbounded re-indexing loops and over-collection, where corpora grow faster than their governance, driving cost that nobody attributes to a steward	Embedding pipeline job telemetry with cost-allocation tags
Log-retention cost per retained prompt-completion record	per retained record	retention silently shortened for cost reasons, removing the corpus that monitoring detection and EU AI Act deployer-duty evidence both depend on	Storage cost-allocation tags joined to the log corpus inventory record

Level of Effort (incremental over the level below)

• Stand-up: 180 hours · Ongoing: 90 hours/quarter
• Program Manager / Practice Lead — primary, 28 days/year
• Legal / Privacy Counsel — regular, 14 days/year
• AI/ML Engineer — regular, 10 days/year
• Compliance / Audit — low, 6 days/year
• Executive Sponsor — low, 3 days/year
• Material new tooling: DLP rules extended to AI-provider egress endpoints, Canary record seeding and detection across governed stores

Success Criteria

• An AI data governance charter is published and jointly sponsored, with three priority policies and a named steward per corpus.
• One AI data inventory covers all seven archetypes at 85% or better coverage, including prompt and completion log corpora.
• DLP on AI egress and canary tagging are both operating, with zero unsanctioned regulated-data flows sustained.
• At least 90% of corpora carry a retention period and legal basis, and 100% of log corpora do.
• A retrieval and training consumption ledger is open with a declared denominator per archetype, or explicitly recorded as blocked on allocation.

---

Maturity Level 2, Comprehensive

Objective: Tier the corpora by sensitivity and exposure, calibrate governance intensity per tier, and bound the consumption of high-tier retrieval and training workloads.

At this level governance intensity follows the data rather than treating every corpus alike. A published rubric derives a tier from classification, lineage quality, cross-border posture, training-versus-inference use, decision-affecting use and subject-access exposure, and a treatment matrix states what each tier receives in access control, lineage depth, retention discipline, monitoring and testing. High-tier retrieval and training workloads operate inside declared budgets, because extraction reconnaissance and re-indexing loops are both economically visible before they are behaviourally obvious. Tier movement follows the data, so a store that begins ingesting customer content is re-tiered rather than quietly left where it was.

Dependencies

• Required: SM-Data-L1, PC-Data-L1, TA-Data-L1
• Alignment (not blocking): Enterprise data classification scheme, so AI tiers compose with existing labels
• Supports / unblocks: PC-Data-L2; TA-Data-L2; SR-Data-L2; SA-Data-L2; DR-Data-L2; IR-Data-L2; ST-Data-L2; EH-Data-L2; IM-Data-L2; ML-Data-L2; Required by: EG-Data-L2, SM-Data-L3

Desired Outcomes

• Every corpus carries a tier derived from auditable dimensions rather than from the sensitivity its steward feels it has.
• Governance intensity is differentiated per tier across access control, lineage depth, retention, monitoring and testing.
• Corpora are re-tiered automatically when their content or exposure changes, rather than retaining a stale classification.
• High-tier retrieval and training workloads operate inside a declared budget with a defined behaviour at the cap.
• The quarterly scoreboard reports per tier, so a Critical-tier gap is not averaged away by healthy Low-tier coverage.

Activities

A) Publish the corpus risk-tier rubric

Define four tiers derived deterministically from six auditable dimensions. Data classification is the floor, where regulated personal, health, payment or customer-confidential content places a corpus at Critical or High. Training-versus-inference use elevates, because a corpus that shapes model weights carries a permanence that an inference input stream does not, and cannot be retracted by deleting a record. Decision-affecting use elevates to Critical where the corpus feeds a system making decisions with legal or significant effect under GDPR Art. 22 or falling within EU AI Act Annex III. Cross-border flow elevates where the transfer basis is anything other than adequacy. Subject-access exposure elevates where records are attributable to identifiable individuals and therefore carry erasure and portability obligations that must be executable against a model, not only against a store. Lineage quality lowers confidence and therefore elevates tier where provenance is incomplete, because a corpus of unknown origin cannot be defended. Publish the rubric with its derivation rule, permit overrides only with recorded rationale, and re-derive tiers automatically when a classification or exposure field changes.

B) Calibrate governance intensity and budgets per tier

Publish a tier-treatment matrix covering, per tier: access-control model from broad read to per-request authorization with purpose binding; lineage depth from source attribution to full transformation provenance; retention discipline and deletion-propagation obligations including whether erasure must propagate to embeddings and fine-tuned weights; encryption and residency requirements; monitoring detections including extraction-pattern detection on retrieval stores; testing obligations including poisoning-resistance and extraction-resistance batteries; and re-review triggers on material change. Add the consumption row: Critical- and High-tier retrieval stores and training workloads carry declared budgets with a defined behaviour at the cap, because systematic extraction against a retrieval store and an unbounded re-index loop both present first as cost. Treat a retention reduction, a sampling change or a cache extension on a Critical-tier corpus as a material change triggering re-review, since each alters the evidence base that monitoring and regulatory obligations rest on.

C) Report per tier and govern corpus tier movement

Report the scoreboard per tier and per archetype quarterly to the sponsor. Report inventory state, classification and steward coverage, unsanctioned-flow counts, canary triggers, retention conformance and per-tier service-level adherence, with every Critical-tier corpus as its own row. Report the Assured Spend Ratio for retrieval and training consumption per tier, targeting full attribution at Critical. Maintain a tier-movement log capturing every corpus that changed tier, with the triggering dimension recorded, and review it quarterly; corpus tier movement is more common than software tier movement because content drifts continuously, so a store that starts with public documentation and gradually accumulates customer tickets must surface as an upgrade rather than persist under its founding classification. Reconcile the steward roster against HR records each quarter so that departures produce a reassignment rather than an orphan.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Corpora carrying a current tier assignment	L1 inventory coverage	100% of inventoried corpora, with tier age under 6 months	AI data inventory tier field
Critical-tier corpora receiving full-scope treatment in the last 12 months	first tier-treatment audit	≥95%	Cross-practice records joined to corpus tier
Erasure requests propagated to embeddings and derived artifacts within the statutory window	first quarter of DSAR telemetry	100% within 30 days for Critical and High tier	DSAR workflow log joined to corpus lineage
High- and Critical-tier retrieval stores with extraction-pattern detection active	first detection audit	≥95%	Monitoring detection registry joined to corpus tier
Assured Spend Ratio for retrieval and training consumption at Critical tier	L1 ledger baseline	100% of Critical-tier consumption attributed to a corpus and steward	Consumption ledger joined to corpus inventory

Process Metrics (leading)

• Tier re-derivation runs whenever a classification or exposure field changes, and the run is logged.
• Quarterly calibration: 20 corpora re-tiered by a second reviewer, with drift recorded.
• Steward roster reconciled against HR quarterly, and reassignments completed within 10 business days.
• Retention-change and sampling-change events on Critical-tier corpora routed to re-review within the tier window.

Effectiveness Metrics (business value)

• Time to execute an erasure request across stores, embeddings and derived artifacts falls quarter over quarter.
• Reviewer effort concentrates on Critical and High tiers relative to L1.
• Documented cases where tier-differentiated detection caught extraction or poisoning activity earlier than a flat control would.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Retrieval cost per query at Critical tier against the store's rolling median	per retrieval query	systematic extraction reconnaissance against a high-value store, which is costly by nature and therefore visible economically before the access pattern alone looks anomalous	Vector-store telemetry joined to corpus tier
Training and fine-tuning compute cost per completed run, by corpus tier	per completed training run	unbounded or repeatedly failing training runs consuming budget, and unsanctioned runs against high-tier corpora appearing on the bill before they appear in the registry	Training-job telemetry with cost-allocation tags
Retention cost per retained record at Critical tier, tracked against retention conformance	per retained record	cost pressure driving retention below the longest applicable regulatory requirement, which trades a visible invoice line for an invisible evidence gap	Storage cost-allocation tags joined to inventory retention field

Level of Effort (incremental over the level below)

• Stand-up: 140 hours · Ongoing: 110 hours/quarter
• Program Manager / Practice Lead — primary, 24 days/year
• Legal / Privacy Counsel — regular, 16 days/year
• Security Architect — regular, 10 days/year
• AI/ML Engineer — regular, 10 days/year
• Compliance / Audit — low, 6 days/year
• Material new tooling: Automated tier re-derivation triggered by catalogue field changes, Extraction-pattern detection on retrieval stores

Success Criteria

• A corpus tier rubric is published and applied to 100% of the inventory, with tiers re-derived automatically on classification or exposure change.
• A tier-treatment matrix is published covering access control, lineage depth, retention, monitoring and testing, and downstream Data-domain L2 practices are calibrated to it.
• Erasure requests propagate to embeddings and derived artifacts within the statutory window for all Critical- and High-tier corpora.
• Critical- and High-tier retrieval stores and training workloads operate inside declared budgets with a tested at-cap behaviour.
• A corpus tier-movement log is maintained with the triggering dimension recorded, and reviewed quarterly with the sponsor.

---

Maturity Level 3, Industry-Leading

Objective: Drive corpus tiering and lineage from live pipeline signals, benchmark data-governance unit economics externally, and contribute data-attack intelligence back to the ecosystem.

At this level the data picture maintains itself. Lineage, classification and tier are derived from pipeline events rather than curated by hand, and a published service-level objective states how quickly the picture reflects reality. Extraction and poisoning detection are tuned from the organization's own telemetry rather than from vendor defaults. The program benchmarks retrieval and training unit economics against peers, which is the only way to know whether a cost profile is efficient or merely familiar, and it contributes observed data-attack techniques back to ATLAS and the wider community rather than only consuming published ones.

Dependencies

• Required: SM-Data-L2, ML-Data-L2, EG-Data-L2
• Alignment (not blocking): FinOps at Run maturity for retrieval, embedding and training cost attribution
• Supports / unblocks: Every other Data-domain practice at L3, which inherits automated lineage and tier data from this cell

Desired Outcomes

• Corpus lineage, classification and tier are derived from pipeline events, with human curation reserved for exceptions.
• The freshness of the data picture is expressed as a published latency objective rather than an assessment-cycle artefact.
• Extraction and poisoning detections are tuned from first-party telemetry rather than from vendor defaults.
• Retrieval and training unit economics are benchmarked externally, so efficiency is a comparison rather than a habit.
• Observed data-attack techniques are contributed back to ATLAS and the wider ecosystem.

Activities

A) Automate lineage, classification and tier from pipeline events

Derive the data picture from the pipelines themselves rather than from periodic curation. Emit lineage events from every extract, transform, embed, train and evaluate step, so a corpus record is assembled from what the pipeline actually did rather than from what a steward believed it would do. Run automated classification over corpus samples on a schedule and on ingest, so content drift triggers re-classification and therefore re-tiering without waiting for a human to notice that a documentation store has begun accumulating customer tickets. Wire tier changes to open the downstream obligations automatically across access control, monitoring, testing and retention. Publish a data-quality service-level objective covering lineage completeness, classification freshness and tier correctness within 48 hours of a material content change. Reserve human curation for three cases: corpora whose provenance cannot be established automatically, conflicting classification signals, and genuinely novel archetypes that the existing seven do not describe.

B) Benchmark data-governance unit economics and detection efficacy

Publish a semi-annual brief comparing the program against named peers on at least five metrics: corpus inventory coverage, erasure propagation time, extraction-detection precision and recall, retrieval cost per query by store archetype, and training cost per completed run. Unit economics matter here more than in any other domain, because retrieval and embedding costs are the ones most often optimised without a security review; a store whose cost per query is far below the peer median may be efficient, or it may be skipping the authorization and logging that peers pay for. Draw comparison data from FinOps Foundation AI-scope working groups for the economics, and from MITRE ATLAS practitioner exchanges, sector information-sharing bodies and CSA AI Safety Initiative groups for detection efficacy. Name the peer cohort and defend its selection; record where the program trails as explicitly as where it leads, and route the deltas into the next investment cycle.

C) Contribute observed data-attack intelligence and compute the domain return

Contribute at least four substantive artifacts per year drawn from the organization's own telemetry: poisoning and extraction techniques observed against first-party corpora submitted to MITRE ATLAS, retrieval-store and embedding-store attack patterns contributed to OWASP LLM working groups, data-governance reference patterns published through OpenSSF AI, responsibly disclosed findings submitted to the AI Vulnerability Database, and NIST AI RMF Playbook data-chapter contributions. Anonymize and legally vet every submission, and count only artifacts that external bodies accept, because talks and press releases do not move the ecosystem. Alongside this, compute the domain's return from the consumption ledger rather than asserting it: reclaimed re-indexing waste, avoided retention overspend where retention was right-sized to the longest applicable obligation rather than to habit, extraction attempts contained valued at burn rate multiplied by detection time, and storage reclaimed by retiring corpora that no model consumes. Reconcile the result with Finance annually.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Corpus lineage completeness derived from pipeline events rather than curated by hand	L2 curated lineage coverage	≥90% event-derived	Lineage event pipeline telemetry
Classification and tier correctness latency after a material content change	L2 review cycle time	≤48 hours at the 99th percentile	Classification pipeline event log
Extraction-detection precision on retrieval stores	first quarter of tuned-detection telemetry	≥80% precision with recall tracked and published	Detection telemetry with analyst disposition labels
Peer-comparable metrics in the semi-annual brief	0	≥5 metrics with a named and defended peer cohort	Published benchmarking brief
Data-attack intelligence artifacts accepted externally per year	0	≥4 accepted, excluding talks and press	Contribution log with external acceptance references

Process Metrics (leading)

• Lineage event-feed freshness and error rate monitored, with on-call paged on staleness breach.
• Automated classification runs on ingest and on a scheduled sweep, with both run timestamps published.
• Detection tuning cycle runs quarterly using analyst disposition labels from the previous quarter.
• Contribution pipeline carries at least two artifacts in draft or external review at all times.

Effectiveness Metrics (business value)

• Sponsor and Data Protection Officer decisions cite benchmark deltas rather than internal trend lines alone.
• Retrieval and training unit cost converges toward or beats the peer median without a corresponding fall in detection coverage.
• Computed domain return is reconciled with Finance annually and survives without restatement.
• External adoption of published data-governance reference patterns by peer organizations.

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Retrieval cost per query benchmarked against the external peer cohort median	per retrieval query	a cost profile far below peers that reflects skipped authorization, logging or filtering rather than genuine efficiency, which internal trend lines cannot distinguish	Consumption ledger compared against the semi-annual benchmarking brief
Reclaimed re-indexing and retention waste	per indexed document retained	embedding stores and log corpora growing without a consuming model, which is pure carrying cost and also pure unnecessary exposure	Consumption ledger joined to corpus consumption telemetry
Extraction-attempt containment value: burn rate multiplied by time to detect	per contained extraction attempt	extraction reconnaissance running long enough to be commercially material, which is the component of return that only the ledger can quantify	Detection telemetry joined to the consumption ledger

Level of Effort (incremental over the level below)

• Stand-up: 220 hours · Ongoing: 70 hours/quarter
• Program Manager / Practice Lead — primary, 18 days/year
• AI/ML Engineer — regular, 20 days/year
• DevOps / Platform Engineer — regular, 15 days/year
• Legal / Privacy Counsel — low, 6 days/year
• Compliance / Audit — low, 4 days/year
• Material new tooling: Lineage event emission across extract, transform, embed, train and evaluate steps, Automated content classification on ingest and on schedule

Success Criteria

• Lineage, classification and tier are event-derived at 90% or better, with a published latency objective met at the 99th percentile.
• Extraction and poisoning detections are tuned from first-party telemetry, with precision and recall both published rather than precision alone.
• A semi-annual benchmarking brief covers at least five peer-comparable metrics including retrieval and training unit economics, with the peer cohort named and defended.
• At least four data-attack intelligence artifacts are accepted by external bodies per year, anonymized and legally vetted.
• The domain return is computed from ledger arithmetic and reconciled with Finance annually.

---

Key Success Indicators

Level 1:

• An AI data governance charter is published and jointly sponsored, with three priority policies and a named steward per corpus.
• One AI data inventory covers all seven archetypes at 85% or better coverage, including prompt and completion log corpora.
• DLP on AI egress and canary tagging are both operating, with zero unsanctioned regulated-data flows sustained.
• At least 90% of corpora carry a retention period and legal basis, and 100% of log corpora do.
• A retrieval and training consumption ledger is open with a declared denominator per archetype, or explicitly recorded as blocked on allocation.

Level 2:

• A corpus tier rubric is published and applied to 100% of the inventory, with tiers re-derived automatically on classification or exposure change.
• A tier-treatment matrix is published covering access control, lineage depth, retention, monitoring and testing, and downstream Data-domain L2 practices are calibrated to it.
• Erasure requests propagate to embeddings and derived artifacts within the statutory window for all Critical- and High-tier corpora.
• Critical- and High-tier retrieval stores and training workloads operate inside declared budgets with a tested at-cap behaviour.
• A corpus tier-movement log is maintained with the triggering dimension recorded, and reviewed quarterly with the sponsor.

Level 3:

• Lineage, classification and tier are event-derived at 90% or better, with a published latency objective met at the 99th percentile.
• Extraction and poisoning detections are tuned from first-party telemetry, with precision and recall both published rather than precision alone.
• A semi-annual benchmarking brief covers at least five peer-comparable metrics including retrieval and training unit economics, with the peer cohort named and defended.
• At least four data-attack intelligence artifacts are accepted by external bodies per year, anonymized and legally vetted.
• The domain return is computed from ledger arithmetic and reconciled with Finance annually.

---

Common Pitfalls

Level 1:

• ❌ Omitting prompt and completion logs from the inventory, which is the corpus most likely to accumulate regulated data and most likely to be replicated to an observability vendor.
• ❌ Classifying corpora once at creation and never revisiting, so a store that began with public documents and later ingested customer tickets retains its original classification.
• ❌ Tuning DLP for AI egress so broadly that it generates unactionable volume, after which the alerts are muted and the control exists only nominally.
• ❌ Assigning stewardship to systems rather than corpora, so a corpus is orphaned the moment its originating pipeline is decommissioned.
• ❌ Reporting storage and query spend in absolute terms, which grows with adoption and reveals nothing about whether the corpus is governed.

Level 2:

• ❌ Tiering corpora once and never re-deriving, so a store whose content drifted from public documentation to customer tickets keeps its founding classification indefinitely.
• ❌ Treating erasure as a store-level operation, so records are deleted from the source while their contribution persists in embeddings and fine-tuned weights.
• ❌ Assuming extraction against a retrieval store will look anomalous in access logs alone, when its most reliable early signal is the cost profile.
• ❌ Publishing a tier-treatment matrix that downstream practices treat as advisory, so detection and testing remain uniform and the tiering achieves nothing.
• ❌ Reducing log retention on a Critical-tier corpus as a cost measure without routing it through change governance.

Level 3:

• ❌ Automating lineage without a completeness objective, so gaps accumulate invisibly and stewards revert to trusting their own notes.
• ❌ Publishing detection precision while withholding recall, which makes a narrow detector look excellent and hides everything it never fires on.
• ❌ Benchmarking retrieval cost per query without checking detection coverage, so skipped controls read as efficiency.
• ❌ Treating automated classification as authoritative for corpora whose provenance was never establishable, rather than routing them to human curation.
• ❌ Counting submitted rather than accepted contributions, which converts a quality gate into an activity count.

---

Practice Maturity Questions

Level 1:

1. Is there a published AI data governance charter with a named steward per corpus, three priority policies covering AI data use, acceptable use and the intake gate, and explicit decision rights over which data classes may reach which model deployments?
2. Does one AI data inventory cover all seven archetypes including prompt and completion log corpora, recording classification, lineage, retention, legal basis, cross-border flow and subject-access exposure, at 85% coverage or better against discovered corpora?
3. Are DLP on AI-endpoint egress and canary tagging both operating as the domain's shadow-AI mechanism, with regulated-data flows lacking a sanctioned path standing at zero and every canary trigger investigated within five business days?

Level 2:

1. Is every corpus assigned a tier from a published rubric covering classification, training-versus-inference use, decision-affecting use, cross-border flow, subject-access exposure and lineage quality, re-derived automatically when classification or exposure changes?
2. Is there a published tier-treatment matrix covering access control, lineage depth, retention and deletion propagation, encryption and residency, monitoring detections and testing obligations, with at least 95% of Critical-tier corpora having received full-scope treatment in the last 12 months?
3. Do erasure requests propagate to embeddings and derived artifacts within the statutory window for all Critical- and High-tier corpora, and do Critical-tier retrieval and training workloads operate inside declared budgets with a tested behaviour at the cap?

Level 3:

1. Are corpus lineage, classification and tier derived from pipeline events at 90% or better against a published data-quality service-level objective covering correctness within 48 hours of material content change, with human curation reserved for unestablishable provenance and conflicting signals?
2. Does the semi-annual benchmarking brief compare at least five peer-comparable metrics including retrieval cost per query and training cost per run, with a named peer cohort whose selection is defended and where the program trails recorded as explicitly as where it leads?
3. Does the program contribute at least four externally accepted data-attack intelligence artifacts per year from its own telemetry, and is the domain return computed from ledger arithmetic covering reclaimed waste and contained extraction rather than asserted?

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Do you know which datasets your AI systems were trained on?
• Are your prompt and completion logs treated as a governed data corpus?
• Would you detect regulated data being sent to an AI service today?

Level 2:

• Does every dataset your AI uses carry a risk tier?
• If someone asked you to delete their data, would it leave the embeddings?
• Is there a budget limit on queries against your most sensitive retrieval store?

Level 3:

• Does your data lineage come from the pipeline or from a person?
• Do you know how your retrieval cost per query compares with peers?
• Have you contributed a data-attack technique back to the community this year?

---

Tracking

Level 1 — Jira Epic, labels haiamm-sm-data-l1, haiamm-governance

• Done when: Corpus inventory coverage at or above 85% with zero unsanctioned regulated-data flows to AI endpoints, sustained across two consecutive quarterly reports, and every log corpus carrying a retention period.
• Git artifacts: data-governance/ai-data-charter.md, data-governance/corpus-inventory.json, data-governance/dlp-ai-egress-rules.yaml, data-governance/canary-seeding.json
• Git signal: corpus-inventory.json is regenerated by the catalogue reconciliation job monthly, and dlp-ai-egress-rules.yaml carries a commit within every monthly endpoint-list review.
• CI check: ai-data-egress-audit

Level 2 — Jira Epic, labels haiamm-sm-data-l2, haiamm-governance

• Done when: Corpus tier coverage at 100% with erasure propagation to embeddings and derived artifacts completing within 30 days for every Critical and High tier request across two consecutive quarters.
• Git artifacts: data-governance/corpus-tier-rubric.md, data-governance/tier-treatment-matrix.md, data-governance/tier-movement-log.json, privacy/erasure-propagation.json
• Git signal: tier-movement-log.json records the triggering dimension for every tier change, and erasure-propagation.json is regenerated by the DSAR workflow rather than hand-maintained.
• CI check: corpus-tier-and-erasure-audit

Level 3 — Jira Epic, labels haiamm-sm-data-l3, haiamm-governance

• Done when: Event-derived lineage at or above 90% and classification latency within 48 hours at the 99th percentile, sustained two quarters, with the benchmarking brief and contribution log current within their intervals.
• Git artifacts: lineage/pipeline/, data-governance/classification-rules.versioned.json, governance/benchmarking-brief.md, governance/contribution-log.json
• Git signal: classification-rules.versioned.json carries a monotonic version with a replay test in CI, and lineage events are emitted by pipeline steps rather than backfilled by a scheduled job.
• CI check: lineage-slo-check

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	RA	AML.T0010, AML.T0018, AML.T0020, AML.T0024, AML.T0025, AML.T0029, AML.T0115	LLM02, LLM04, LLM08, LLM10	GDPR Art. 5; GDPR Art. 17; GDPR Art. 30; GDPR Art. 44-49; EU AI Act Art. 10; ISO/IEC 42001 7.5
L2	RA, AGH	AML.T0018, AML.T0020, AML.T0024, AML.T0115	LLM02, LLM04, LLM08	GDPR Art. 17; GDPR Art. 22; GDPR Art. 32; EU AI Act Art. 10; EU AI Act Annex III; ISO/IEC 42001 8.3
L3	RA, AGH	AML.T0018, AML.T0020, AML.T0024, AML.T0025, AML.T0115	LLM02, LLM04, LLM08	GDPR Art. 30; GDPR Art. 32; EU AI Act Art. 10; EU AI Act Art. 72; ISO/IEC 42001 9.1; NIST AI RMF MEASURE 2.7

---

Document Version: HAIAMM v3.5 (generated) / Practice: Strategy & Metrics (SM) / Domain: Data