MAP: Why Many AI Failures Are Context Failures

MAP is the function of the NIST AI Risk Management Framework¹ that establishes context: what each AI system is for, who built it and who runs it, what data it consumes, who it affects, and what could plausibly go wrong. It sits between GOVERN's ground rules and MEASURE's testing for a reason. You cannot test what you have not defined, and you cannot define risk for a system whose purpose, users, and blast radius nobody has written down.

The uncomfortable truth MAP is built around: many AI systems that cause harm were working as designed. The model did what it was trained to do. The failure was contextual: the system was applied to a population it was never validated on, wired into a decision it was never meant to make, or trusted with an authority nobody consciously granted. A résumé screener trained on one decade's hiring data can quietly encode that decade's biases into the next. A clinical model validated at an academic medical center can underperform at a rural hospital with a different patient mix. A chatbot built for product questions can become, through nothing but user behavior, an unlicensed advisor. In each case the model was fine. The map was wrong, or missing.

Intended use is a boundary, not a description

The first discipline MAP imposes is a written statement of intended use for every system and, just as important, of unintended use. What is this system authorized to do? What decisions may it inform, and which may it never make alone? What populations, geographies, and data types is it validated for?

Written this way, intended use becomes a boundary you can detect crossings of. When the sales team starts feeding the support chatbot into contract negotiations, that is now a policy event, not an anecdote. When a scoring model built for one product line gets copied to another, someone can ask the question MAP exists to force: was it ever validated for this?

Documentation: the system, not just the model

MAP's documentation outcomes go beyond a spreadsheet row. Mature programs maintain, per system, something like a model card or system profile: purpose and intended use; owner and operator; training data provenance where knowable; inputs and outputs; dependencies, including the foundation model or vendor service underneath; integration points; known limitations; and validation status.

The word system is doing heavy lifting. A modern AI deployment is a model plus an orchestration layer plus retrieval sources plus the tools it can invoke plus the identity and access controls around all of it. Model safety is insufficient; system safety is the issue. Mapping only the model is like inspecting the engine and calling the aircraft airworthy.

For purchased AI, which is most AI, mapping means looking under the vendor's hood: which foundation model powers the feature, where inference happens, what leaves your tenant. "The vendor handles that" is not a map. It is a blank spot with a logo on it.

Impact analysis: who is on the other end

MAP requires identifying who the system affects and how, including not just users but people subject to its outputs: applicants scored, patients triaged, claims adjudicated, employees monitored. For each affected group, the questions are direct. What happens to a person when the system is wrong? Is there a path to contest or appeal an outcome? Could performance differ across demographic groups in ways that matter legally or ethically?

This is where AI risk stops being an IT concern and becomes an enterprise one. Disparate impact in a lending or hiring model is a civil rights exposure. An unappealable automated denial is a regulatory finding waiting for a docket number. The organizations that handle this well treat impact analysis as a standing artifact, reviewed when the system changes, not performed once at launch and embalmed.

Risk identification, including the generative kind

With context and impacts established, MAP closes by enumerating what could go wrong: technical failures like drift and data quality decay, and contextual ones like misuse and over-reliance. For generative systems, NIST's Generative AI Profile (AI 600-1)² supplies the additions: confabulation (fluent, confident, wrong output), prompt injection, training-data and context leakage, intellectual-property contamination, and harmful or synthetic content. These are not exotic edge cases; they are the ordinary failure modes of the tools most organizations adopted first.

The output of good risk identification is unglamorous: a per-system risk list, tied to the documented context, feeding directly into what MEASURE will test and what MANAGE will monitor. If a risk appears on no list, no one will measure it, and its first appearance will be in an incident report.

The maturity signal

A common pattern separates early and mature programs. Organizations early in the journey have a tools list: names of products people use. Mature organizations have a system map: purposes, owners, data flows, affected populations, risk tiers, and validation status, kept current as systems change. The distance between those two artifacts is most of the MAP function, and closing it is mostly diligence rather than expertise.

Next in the series: MEASURE, and why "the model works" and "the model is trustworthy" are different claims, and what testing regime tells them apart.

Frequently asked questions

What is the difference between an AI tools register and an AI system inventory? A tools register lists approved products. A system inventory documents each deployment in context: purpose, owner, data, dependencies, affected parties, and risk tier. The register is a gate; the inventory is a map. Mature programs maintain both.

What is a model card? A short structured document describing a model or AI system: its intended use, training data characteristics, performance, limitations, and validation results. Model cards make context portable; reviewers, auditors, and future owners can see what the system is for without archaeology.

How often should AI systems be re-mapped? On any material change (new use case, new population, new data source, new underlying model version) and on a periodic cycle (annually is a common floor). Generative AI vendors ship model updates frequently, which makes "no change on our side" an unreliable assumption.