MAP-2.2: Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making decisions and tak

MAP-2.2 is an execution requirement disguised as a documentation requirement. If the only artifact you have is a model card in a shared drive, you will fail the intent: the people making decisions with AI output must understand the system’s knowledge limits and the required human oversight steps at the moment of use. The requirement also applies beyond your data science team. “Relevant AI actors” includes business users, supervisors, product owners, incident responders, legal/compliance reviewers, and third parties operating the system on your behalf.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat MAP-2.2 as a control: assign an owner, define standard templates, embed them in your SDLC/change management, and collect recurring evidence that the documentation is current and used. Your end state is simple: if an examiner asks, “How do your employees know when the system is wrong and what must they do before acting on its output?”, you can point to clear documents, training, and workflow records that match actual operations. This page gives requirement-level guidance aligned to NIST AI RMF MAP-2.2, with concrete steps and artifacts you can implement quickly ¹.

Regulatory text

Requirement (MAP-2.2): “Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making decisions and taking subsequent actions.” ¹

What the operator must do: Maintain documentation that is practical for decision-makers. It must (a) describe knowledge limits (where the system is likely to be unreliable, out of scope, or prone to error) and (b) prescribe human oversight (how outputs are reviewed, approved, challenged, and monitored in real workflows) ¹.

Plain-English interpretation (what MAP-2.2 is really asking)

You must be able to answer, in writing and in operational practice:

1. Where can this AI system be wrong, and how would a user recognize that?
   Knowledge limits should include scope boundaries, known blind spots, likely error patterns, and conditions that degrade performance (for example: novel inputs, rare edge cases, distribution shift, ambiguous prompts, missing context).

2. What are humans allowed to do with the output, and what must they never do?
   Spell out permitted uses vs. prohibited uses. If output is advisory, say so. If output can trigger actions, document the required approvals and checks.

3. Who is accountable for the final decision?
   Map roles to responsibilities: requestor, reviewer/approver, accountable business owner, model owner, and compliance sign-off when needed.

If your documentation is written only for technical readers, or it does not reach the people taking action, you are not meeting MAP-2.2 as an operational requirement ¹.

Who it applies to

Entities: Any organization developing, deploying, or operating AI systems, including where an AI capability is provided by a third party ².

Operational contexts where it shows up in audits:

• Decision support in regulated functions (credit, fraud, claims, HR screening, healthcare operations).
• Generative AI used for customer communications, legal summaries, coding, security investigations, or policy drafting.
• Third-party AI tools embedded into enterprise workflows (CRM copilots, call center assistants, monitoring and triage tools).
• High-impact workflows where errors cause customer harm, discrimination risk, safety risk, or material financial reporting risk.

What you actually need to do (step-by-step)

Treat this as a control with a defined lifecycle: draft → approve → publish → train → monitor → update.

Step 1: Identify “relevant AI actors” by workflow

Build a simple RACI-style map per AI use case:

• Users/operators: people who read the output and act.
• Reviewers/approvers: supervisors, QA, second-line checks.
• Accountable owner: business owner of the decision.
• Model/system owner: product or ML owner responsible for performance and change control.
• Risk/compliance stakeholders: who must be consulted for certain uses or incidents.

Deliverable: “AI Actor Map” per use case ¹.

Step 2: Document the system’s knowledge limits in operator language

Create a “Knowledge Limits” section that includes:

• Intended purpose and scope: what it was built to do.
• Out-of-scope uses: explicit “do not use for” list tied to decisions (example: “Do not use output as the sole basis for adverse action.”)
• Known failure modes: hallucination risk, sensitivity to incomplete inputs, bias risks, brittleness to novel categories, inability to cite sources reliably (if applicable).
• Input constraints: required fields, required context, supported languages, unsupported data types.
• Confidence and uncertainty handling: whether the system provides confidence signals; if it does not, say that clearly.
• Performance boundaries: where performance is known to degrade (for example: low-volume segments, rare events, new product lines).

Keep it usable: bullets, examples, red flags (“stop signs”), and “if you see X, do Y” instructions ¹.

Step 3: Define “human oversight” as concrete workflow steps

Write oversight so a supervisor can enforce it:

• When is human review required? Before sending to a customer, before making an eligibility decision, before publishing externally, before code deployment, etc.
• What does the reviewer check? Factual accuracy, policy alignment, harmful content, protected-class sensitivity, completeness of supporting evidence, citation checks.
• What are acceptable actions? Accept with rationale, edit, reject, escalate, request additional data.
• How are disagreements handled? Escalation path and tie-breaker authority.
• What must be logged? Approval, edits, overrides, rationale, and any exception granted.

If oversight differs by risk tier, document the tiering logic and attach it to the workflow ¹.

Step 4: Package the documentation into role-specific artifacts

One document rarely serves all audiences. Create a small set:

• Operator job aid (1–2 pages): red flags, prohibited uses, required checks, escalation.
• Supervisor checklist: what to verify, sampling approach, override review.
• System card / model documentation: deeper technical detail for model owners and risk reviewers.
• Third-party addendum: what the provider is responsible for vs. you, and what evidence you receive.

Publish these where work happens (ticketing system, intranet, CRM knowledge base), not only in GRC tooling.

Step 5: Embed MAP-2.2 into change management and onboarding

Add gates so docs stay current:

• New model / new use case cannot launch without approved MAP-2.2 documentation.
• Material changes (model update, prompt changes, new data sources, new user group) trigger doc review and retraining.
• Onboarding for new users includes the operator job aid and an acknowledgment.

Step 6: Prove it operates (not just that it exists)

Define recurring evidence collection:

• Training completion or attestation for relevant users.
• Periodic supervisor sampling results (for example: review a set of decisions and confirm oversight occurred).
• Records of overrides and escalations, with rationale and disposition.
• Incident tickets where knowledge limits were breached and the corrective action (docs updated, workflow adjusted).

A common pattern is to map MAP-2.2 to a control owner and calendar-based evidence requests so you are not scrambling during audits ¹.

Required evidence and artifacts to retain

Keep artifacts versioned, dated, and attributable to an owner.

Core artifacts (minimum set):

• MAP-2.2 control narrative (purpose, scope, owner, frequency, tools).
• “Knowledge Limits & Human Oversight” document per AI system/use case, with version history.
• Role-based job aids (operator and supervisor).
• Training materials and completion logs (or attestations).
• Workflow evidence: screenshots/config showing approval steps, QA queues, or human-in-the-loop checkpoints.
• Override/escalation logs (or ticket extracts) showing how human oversight occurred.
• Change management records tying model/prompt changes to doc updates.
• Third-party documentation received (where applicable) and your gap assessment.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me where you document knowledge limits for this specific use case.” Auditors will reject generic AI policies that do not name the system and workflow.
• “How do users see the limits at the moment of use?” If it’s buried in a PDF, you will struggle.
• “How do you know humans are actually overseeing outputs?” They will ask for workflow records, approvals, sampling results, and override logs.
• “What changed since the last version?” They will look for versioning and change control.
• “How do you handle third-party AI?” They will ask what you rely on from the provider and what you validate internally.

Frequent implementation mistakes (and how to avoid them)

1. Writing documentation for model builders, not operators.
   Fix: create a one-page job aid with stop signs, examples, and required checks.

2. Vague oversight language (“human review occurs”).
   Fix: define who reviews, what they check, and what gets logged.

3. No explicit prohibited uses.
   Fix: add a “Do not use for” list tied to decisions, customer communications, or adverse actions.

4. Docs don’t match the tool configuration.
   Fix: align documentation with actual workflow controls (approvals, queues, gating, access roles).

5. Third-party reliance without documented limits.
   Fix: write a third-party addendum that states what the provider does not guarantee and what your humans must verify.

Enforcement context and risk implications

NIST AI RMF is a framework, not a regulator, but MAP-2.2 maps cleanly to risks that do trigger regulatory scrutiny: misleading customer communications, unfair or unsupported decisions, inadequate governance, and weak oversight of automated tools. Practically, weak MAP-2.2 controls increase the chance of:

• Operators over-trusting AI outputs and failing to detect errors.
• Inconsistent decisions across teams because “oversight” is informal.
• Post-incident inability to show what users were told and what they were required to do.

From a risk standpoint, MAP-2.2 is also a defensibility requirement: you need to show you anticipated limitations and designed human oversight to manage them ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize and publish)

• Pick the highest-risk AI use cases in production.
• Assign a control owner and approvers (business + compliance).
• Publish an operator job aid and supervisor checklist per use case.
• Implement a lightweight attestation: users acknowledge they read knowledge limits and oversight steps.

Days 31–60 (embed into workflows)

• Add MAP-2.2 gates to change management for model/prompt updates.
• Align tool configuration to oversight requirements (approval steps, QA queues, restricted actions).
• Stand up an override/escalation logging mechanism (ticket tags, form fields, or workflow states).
• Train supervisors on sampling and escalation.

Days 61–90 (prove operating effectiveness)

• Run a supervisory sampling cycle and document results and remediation.
• Test incident response for a knowledge-limit breach (document updates, retraining, workflow changes).
• Extend to lower-risk use cases and third-party AI tools.
• Create a recurring evidence calendar so audits do not become a scramble ¹.

How Daydream fits (without changing your operating model)

If you are coordinating multiple AI use cases across business units and third parties, Daydream can act as the system of record for MAP-2.2 evidence: mapping the requirement to a control owner, storing versioned documentation, and running recurring evidence collection so you can show both design and operation without rebuilding your SDLC ¹.

Frequently Asked Questions

Do we need a separate MAP-2.2 document for every model?

Create documentation per use case, not only per model, because knowledge limits and oversight depend on how output is used in decisions. If the same model supports multiple workflows, publish role-specific job aids per workflow ¹.

What counts as “knowledge limits” for a generative AI assistant?

Document common failure modes relevant to your workflow: unsupported topics, lack of authoritative sourcing, sensitivity to missing context, and conditions that increase error risk. Add a “do not use for” list tied to your business decisions ¹.

How do we show auditors that humans are overseeing outputs?

Pair written procedures with operating evidence: approvals in the workflow, QA sampling records, and override/escalation logs. Auditors generally want to see that the oversight steps are both defined and performed ¹.

Our tool is from a third party. Can we rely on their documentation?

You can incorporate provider materials, but you still need internal documentation that explains how your staff must oversee outputs in your workflows. Add a third-party addendum that clarifies responsibilities and any gaps you must control ².

Where should we publish the documentation so it actually gets used?

Put the operator job aid inside the tools and processes where decisions happen (case management, CRM knowledge base, runbooks). A central repository is fine for recordkeeping, but it does not replace in-workflow guidance ¹.

What triggers an update to MAP-2.2 documentation?

Update when you change the model, prompts, training data sources, decision workflow, user population, or any risk assumptions tied to knowledge limits and oversight. Tie updates to your existing change management process so the refresh is not optional ¹.

Footnotes

1. NIST AI RMF Core

2. NIST AI RMF program page