Executive Summary

Traditional cybersecurity frameworks know exactly what they are defending. What the NIST Cybersecurity Framework (CSF) protects is the confidentiality, integrity, and availability of code and data. Software, once deployed, is a deterministic asset (the same input yields the same output), and the threats mostly come from outside. Intruders, ransomware, denial-of-service attacks: the goal is to keep out forces pushing across the perimeter.

AI systems break nearly all of those premises. The same input can produce different outputs probabilistically, and behaviors no one explicitly programmed emerge during training. Above all, a large share of the threat comes not from outside but from within, specifically from the training data. Biased data produces biased decisions; data in which a particular group is underrepresented produces systematic error against that group. This is why NIST AI RMF 1.0 was written fresh rather than borrowing the grammar of the CSF wholesale. This framework takes as its unit of risk not code but the behavior of the model, and the effect that behavior has on individuals, organizations, and society. The RMF calls this sociotechnical risk: what gets managed is not only technical accuracy but also the harm that arises when the technology operates inside a society.

Set the two worlds side by side along four axes and the direction of the shift becomes clear.

The third row of the table is where this report begins. In traditional IT, the data question was "who has access." In AI, the data question is "what has hardened inside the model." The asset to protect in AI is not the code but what the training data has hardened into as the model's internal representation. Biased data leaves a biased representation; data with no lineage leaves a representation you cannot audit; stale data leaves a representation out of step with reality.

And this work is genuinely hard. The finding that 83% of organizations use AI tools while only 25% have a strong governance regime (Compliance Week, 2026) is not a number that reveals organizational laziness. Much of that gap opens up because the MAP and MEASURE data work we will see later is engineering work, not paperwork. Reading a regulation and instrumenting a pipeline with lineage, fairness, and drift gauges are tasks of an entirely different order of difficulty.

The AI RMF treats risk management not as a one-time inspection but as a repeating cycle, and four functions hold that cycle up. GOVERN is the foundation that plants accountability and culture across the organization; MAP grasps the context the system sits in; MEASURE quantifies the risk; and MANAGE actually responds to the measured risk. GOVERN wraps the other three, and inside it MAP → MEASURE → MANAGE flows.

This report's thesis lives inside that picture. GOVERN and MANAGE are the organizational and operational layer of "who is accountable and what do we act on"; MAP and MEASURE are the cognitive layer of "what do we know and what do we measure." And that cognitive layer is the very body of the data work. We will first cover GOVERN and MANAGE briefly, then spend the next two sections unpacking MAP and MEASURE from the data perspective.

GOVERN: build a risk-aware culture

GOVERN is the foundation that plants accountability in the organization so that the other three functions actually run. In practice it usually comes down to three things. First, stand up an oversight body — say, an AI safety committee — with legal, engineering, and compliance all at the table. Second, track every foundation model, third-party API, and fine-tuning dataset the organization uses as an asset. Third, set the boundaries of acceptable model error and deployment risk explicitly — that is, define risk tolerance. Without that asset inventory and those tolerance thresholds, the MAP and MEASURE that follow spin without a baseline.

MANAGE: turn what you measured into action

MANAGE turns the risks MAP and MEASURE surface into actual responses. The canonical moves are automated fail-safes (kill switches) that take an erratic or compromised model offline immediately, content filters and programmatic guardrails that block toxic or illegal outputs, and manual fallbacks that route high-risk decisions to a human. But knowing what to take down and what to filter ultimately rests on the numbers MEASURE produced. The quality of the action cannot exceed the quality of the measurement.

MAP is the function that, before a model is deployed, grasps the environment it sits in, its intent, and the limits of its operation. In the RMF document MAP is presented as three strands of action: profile users and vulnerable groups; identify the data gaps where the model should not decide on its own; and categorize the dependency risk coming from open-weight models, cloud infrastructure, and third-party training pipelines. These three are written in governance language, but brought down to the pipeline they all turn into questions about data.

Representativeness: who is missing from the data

The instruction to profile users and vulnerable groups becomes, once moved into data, the representativeness question: "is this group sufficiently present in the training data?" In decisions that divide people's lives, such as hiring or loan approval, a model trained on data where a particular group is underrepresented will be systematically wrong about that group. Some studies attribute up to 30% of the model error arising from unrepresentative datasets to exactly this kind of sampling bias. A representativeness audit is the work of surfacing that error before deployment. It means slicing the data by group and counting coverage — seemingly simple, but in practice possible only when labels and metadata are in place.

The boundary of the distribution: where the model should stay silent

The item about identifying where the model must not decide on its own is the work of drawing the boundary of the training distribution. A model is reasonably trustworthy in the regions where the training data is dense, but in the regions where the data was empty it hands back confidently wrong answers. Only by marking with data where the distribution is inside and where it is outside does MANAGE's fallback rule — "here the model should not decide; hand it to a human" — gain a basis. Without knowing the boundary, you cannot know where to hang the fallback.

Lineage: can you say what you trained on

Dependency assessment is the most nakedly data-centric of all. If you fine-tuned an open-weight model, you have to be able to trace what the original model was trained on; if you mixed in a third-party dataset, you have to be able to trace its source and license. This is data and model provenance/lineage. Without lineage, when a bias or copyright problem later erupts you cannot trace which data caused it, and the audit itself falls apart. Behind the data lineage and observability tooling market, estimated at roughly $2–4 billion as of 2026 and growing 12–24% a year, is a shift in which lineage tracking moves from best practice to compliance requirement, as the EU AI Act begins to demand data lineage and quality logging for high-risk systems (market figures are cited as a range because definitions differ across research firms).

If MAP is the map, MEASURE is the instrument panel. Where MAP grasps qualitatively "what you trained on and what got left out," MEASURE turns that risk into a number for how large it is right now. In the RMF, MEASURE comes in three strands: audit bias (bias audit), simulate adversarial attacks (red-teaming), and track drift. Each translates into a measurable data-quality metric.

Bias audit: no single metric proves it

A bias audit starts by distinguishing the type of bias. NIST SP 1270 divides bias into three kinds — systemic, statistical, and human-cognitive. Then you compute fairness metrics per protected attribute. The canonical ones are demographic parity, which checks whether each group receives a positive decision at the same rate; equalized odds, which checks whether the decision is the same when the true answer is the same; and disparate impact, which checks whether adverse outcomes pile up on a particular group. The important thing is that these metrics must be measured on both the training data and the inference outputs, and that no single metric can prove fairness. Metrics can even conflict with one another — satisfying one can break another — so the substance of an audit is choosing metrics that fit the context and documenting the basis for that choice.

Red-teaming: knock to see whether the data leaks

Red-teaming is the work of knocking on the model through an attacker's eyes. It tests whether a prompt injection can bypass the guardrails, whether a data extraction attack makes the original text used in training spill out verbatim, and whether membership inference can reveal that a specific individual's data was included in training. When the latter two succeed, it means training data is leaking through the model. The success rate of red-teaming therefore becomes a direct metric of data privacy. How far you can trust benchmark and red-team results is itself a separate topic, which we covered further in the trustworthiness of AI agent benchmarks.

Drift: catching what slowly goes wrong

Drift tracking is the ongoing work of re-measuring, after deployment, whether the model is still right. It splits into three axes: accuracy decay, where performance metrics slowly fall; concept drift, where the relationship between input and correct answer itself changes; and covariate shift, where the distribution of the input data moves. Drift's nastiest property is that it is gradual degradation, not a sharp outage. When a server goes down you know at once, but a model getting slightly worse tends to surface only after it has already touched customers, employees, and decisions. So monitoring at least one drift metric continuously after deployment is MEASURE's final requirement.

Why this measurement is so urgent can be summed up in a single gap. 85% of failed AI projects name data quality as a cause, yet only 12% of organizations hold data good enough to sustain AI (Gartner, 2025). It means the majority of organizations are not doing what MEASURE demands. In fairness, though, one should add that this 85% is a self-reported figure from a survey. A different study that did post-hoc root-cause analysis on 140 enterprise cases found that only 23% of failures were actually model, data, or integration problems, while the rest were on the strategy, governance, and change-management side. The two numbers use different methods (self-reported survey vs. retrospective analysis), so they are less a contradiction than two truths seen from different angles. The direction, though, is clear: trust without measurement is just a claim.

If that gap sounds like an abstract warning, look at how the bill for skipping measurement gets served. In the iTutorGroup case handled by the U.S. Equal Employment Opportunity Commission (EEOC), hiring software automatically rejected female applicants over 55 and male applicants over 60; the confirmed victims alone numbered more than 200. The company settled for $365,000. Had a fairness audit measuring pass rates by age band run even once before deployment, this bias would have surfaced first as a metric on a dashboard rather than as a line in a lawsuit. This is exactly what bias auditing and drift monitoring do — they pull forward, into numbers before and after deployment, the outcome that would otherwise be confirmed belatedly in a courtroom, and the source of those numbers is always the data the model trained on.

The RMF defines trustworthy AI along seven dimensions. They sound like abstract virtues, but in fact a good many of them decompose into sets of data-quality metrics. First, laid out, the seven are as follows.

• Valid & Reliable — performs its intended task accurately and consistently under diverse conditions.
• Safe — does not threaten human life, health, or property.
• Secure & Resilient — withstands data poisoning, model inversion attacks, and unexpected inputs.
• Accountable & Transparent — logs data flows and retains an audit trail for critical outputs.
• Explainable & Interpretable — the basis for a prediction and how it works can be understood.
• Privacy-Enhanced — respects data ownership and prevents exposure through training and use.
• Fair — identifies, mitigates, and governs systemic and computational bias.

Four of these are rooted directly in data. Translate what each demands into data work and it looks like this.

The remaining three — Safe, Secure & Resilient, and Accountable & Transparent — are entangled with the data layer too, but their center of gravity sits on the system and organizational side. Safe leans more on fail-safe design in the deployment environment, Secure & Resilient on infrastructure and attack-surface management, and Accountable & Transparent on logging policy and governance procedures. Even so, these three are not entirely free of data. The moment you decide what was poisoned and what has to remain in the audit trail, you are back to data lineage. Trustworthiness, in this way, settles not into an abstract slogan but into a bundle of measurable data-quality metrics.

There is a wide gap between reading a framework as a document and moving it into practice. To close that gap, NIST released several companion resources alongside the RMF, and industry wrapped them in certification standards and automation tooling. Here we lay out that path briefly.

Playbook and ISO/IEC 42001: the what, and the proof

The RMF Playbook is a companion resource that spells out, for each of the four functions, "specifically what to do," in the form of suggested actions. A separate profile (NIST AI 600-1) was added for generative AI. Overlay ISO/IEC 42001 on top and the picture is complete. If the RMF defines what to do, ISO 42001 is the certifiable shell that documents it as a management system and proves it through external audit. The two do not compete. You fill in the substance of execution with the RMF and prove that execution with ISO 42001 — they map together. That ISO 42001 (36%) and NIST AI RMF (33%) appeared for the first time in a 2025 enterprise survey and, in their debut year, recorded citation rates second only to GDPR shows how fast a voluntary standard hardens into a de facto benchmark (Stanford HAI AI Index 2026).

AI-SPM and observability: putting gauges on the pipeline

Doing the MAP and MEASURE data work by hand alone is hard. Tool categories such as AI security posture management (AI-SPM), data lineage and observability, and drift monitoring are growing by claiming to automate this work. But you have to weigh what a tool covers by its actual features, not its marketing copy. Lineage tracking automates MAP's dependency assessment and drift monitoring automates MEASURE's tracking, yet judgments such as which fairness metric to look at in which context remain a human matter. Automation only installs the gauges; the organization decides what to measure and how to read it.

The regulatory landscape: a reprieve, not a repeal

The regulatory timeline has changed significantly of late, and getting the facts right here matters. The EU AI Act's high-risk deadline — commonly reported as "August 2026" — was pushed to December 2, 2027, by the Digital Omnibus package finalized on June 29, 2026. But that is a reprieve, not a repeal. Transparency obligations such as disclosing interaction with AI and labeling AI-generated content (Article 50) stay unchanged, and the watermarking requirement takes effect in December 2026. On the U.S. side, Colorado's so-called safe harbor disappeared. The original SB 24-205 was replaced by SB 26-189 (scheduled to take effect January 1, 2027, currently in litigation), and the assumption that RMF alignment is itself a legal defense does not hold. We covered the specifics of that amendment in our analysis of Colorado SB 26-189.

A minimum viable set for small teams

A full RMF implementation is daunting. But most of the risk is caught by four things. First, record the lineage of what data you trained and tuned on. Second, check target-group coverage before deployment. Third, monitor at least one drift metric after deployment. Fourth, keep a fallback that brings a human into high-risk decisions. The grace period is time to put these four in place, not time in which you can do nothing. The road from framework to practice runs not through complying with a document but through hanging lineage, fairness, and drift gauges on the data pipeline.

Why Pebblous Cares

This report's argument converges in one direction. The threats the RMF addresses — dataset bias, training leakage, system drift — all reduce to a single sentence: the model's internal representation inherits the defects of its training data intact. Biased data makes a biased representation; data without lineage makes a representation you cannot audit; drifted data makes a stale representation. If so, the RMF's abstract trust dimensions also circle back to the problem of training-data quality.

References

Centered on NIST's primary documents, we have organized the standards, policy, and statistical sources cited in the text. Citation information can be downloaded with the buttons below.

Academic · Standards · Government Primary Documents

• 1.National Institute of Standards and Technology. (2023-01). "Artificial Intelligence Risk Management Framework (AI RMF 1.0)." NIST AI 100-1.
• 2.National Institute of Standards and Technology. "NIST AI RMF Playbook." Trustworthy & Responsible AI Resource Center.
• 3.National Institute of Standards and Technology. (2024-07). "Artificial Intelligence Risk Management Framework: Generative AI Profile." NIST AI 600-1.
• 4.National Institute of Standards and Technology. (2022-03). "Towards a Standard for Identifying and Managing Bias in Artificial Intelligence." NIST SP 1270.
• 5.National Institute of Standards and Technology. (2021-09). "Four Principles of Explainable Artificial Intelligence." NIST IR 8312.
• 6.International Organization for Standardization. (2023-12). "ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system."
• 7.Hardt, M., Price, E., & Srebro, N. (2016). "Equality of Opportunity in Supervised Learning." NeurIPS 2016. (fairness metric: equalized odds)
• 8.Gama, J., et al. (2014). "A Survey on Concept Drift Adaptation." ACM Computing Surveys, 46(4).

Policy · Statistics · Market Data

• 9.Stanford Institute for Human-Centered AI. (2026). "Artificial Intelligence Index Report 2026." (regulatory-framework citation rates: GDPR 60%, ISO 42001 36%, NIST AI RMF 33%; absence of responsible-AI policy 24%→11%)
• 10.Gartner. (2025). "Data Quality and AI Readiness." (85% of failed AI projects name data quality; 12% hold AI-ready data; $12.9M average annual loss from poor data quality)
• 11.Compliance Week. (2026). "2026 AI Governance Survey." (83% use AI vs 25% with strong governance)
• 12.RAND Corporation. "The Root Causes of Failure for Artificial Intelligence Projects." (AI project failure rate 80%+)
• 13.European Union. (2026-06-29). "Digital Omnibus on AI — Council final approval." (EU AI Act Annex III high-risk deadline deferred to 2027-12-02; cross-confirmed by multiple law firms)
• 14.Colorado General Assembly. (2026-05-14). "SB 26-189." (replaces SB 24-205; scheduled effective 2027-01-01, in litigation)
• 15.Financial Supervisory Service (Korea). (2026-01-15). "Introduction of a financial-sector AI Risk Management Framework (AI RMF)." (three domains — governance, risk assessment, risk control; self-regulatory)

Pebblous Adjacent (Cross-links)

• 16.Pebblous Data Communication Team. "Colorado Rewrote Its Own AI Law — Five Questions SB 26-189 Asks of ADMT." Pebblous Blog.
• 17.Pebblous Data Communication Team. "The Trustworthiness of AI Agent Benchmarks." Pebblous Blog.