MAP: context and AI use

How to identify, document and assess AI systems and their risks

NIST AI RMF function: MAP Guide sections: MP-1 to MP-5

The section labels below organise this implementation guide. Consult the NIST mapping for the distinction between this structure and official NIST categories and subcategories.

1. Overview of MAP

MAP develops an understanding of the context in which an AI system operates and the risks associated with that context.

Objective	Description
Context	Understand intended use and the operational environment
Stakeholders	Identify people and organisations affected by the system
Risks	Identify potential risks and impacts
Classification	Assess risk and applicable legal categories
Documentation	Record the evidence and reasoning behind the assessment

2. MP-1: Intended purpose and context

2.1 Define intended use

Document the following for each AI system:

## AI SYSTEM: [Name]

### 1. Primary purpose
- What does the system do?
- Which business problem does it address?
- What metric defines success?

### 2. Intended users
- Who will use the system?
- What is their level of AI literacy?
- How can they access its outputs?

### 3. Intended beneficiaries
- Who benefits from the system's outputs?
- Are they the same people as the users?

### 4. Operational context
- In which environment will the system operate?
- What time or location constraints apply?
- How critical is the system?

### 5. Known limitations
- What does the system NOT do?
- What edge cases are known?
- What are its performance limits?

### 6. Potential misuse
- How could the system be misused?
- Which preventive measures are in place?

2.2 Map the context

3. MP-2: Identify stakeholders

3.1 Stakeholder groups

Group	Description	Examples
AI actors	Those developing or deploying AI	Developers, operators
Direct users	Those interacting with the system	Employees, customers
Affected individuals	People affected by its use	People subject to a decision
Affected communities	Wider communities affected by AI	Demographic groups
Oversight bodies	Those responsible for oversight	Regulators, auditors

3.2 Example stakeholder matrix

Stakeholder	Interest	Influence	Engagement approach
End users	High	Medium	Information and training
Affected individuals	High	Low	Transparency and ways to exercise rights
Regulators	Medium	High	Applicable compliance and reporting processes
Management	High	High	Decisions and governance
Data subjects	High	Low	GDPR rights and information about processing

This is a starting point. Actual interests and influence vary by system and context. Consent is one possible legal basis for processing, not a default requirement for every AI use.

3.3 Assess impacts on stakeholders

For each group, consider:

Impact	Questions	Severity
Economic	Does the system affect income, finances or employment?
Health	Could it cause physical or psychological harm?
Legal	Does it affect a person’s legal position?
Social	Does it affect social status or reputation?
Autonomy	Does it restrict freedom of decision?

4. MP-3: AI system inventory

4.1 Inventory template

# AI SYSTEM INVENTORY

## System ID: AI-YYYY-XXX

### Basic information
| Field | Value |
|---|---|
| Name | |
| Description | |
| Department | |
| Status | Development / Testing / Production / Retired |

### Classification
| Field | Value |
|---|---|
| Type | Internal / Third-party / Embedded |
| Technology | ML model / Generative AI / Rule-based / Hybrid |
| Organisation's role | |
| Intended purpose | |
| AI Act assessment and legal basis | |
| Applicable obligations and dates | |
| Internal risk rating and rationale | |

### Data
| Field | Value |
|---|---|
| Training data sources | |
| Inference data types | |
| Contains personal data? | Yes / No |
| Special categories under GDPR Article 9? | Yes / No |

### Technical details
| Field | Value |
|---|---|
| Model type and architecture | |
| Hosting | On-premises / Cloud / Hybrid |
| Integration points | |

### Governance
| Field | Value |
|---|---|
| System owner | |
| Pre-deployment review date | |
| Last review date | |
| Next review date | |
| DPIA required, and why? | |
| DPIA completed? | Yes / No / Not applicable |

Record legal classification separately from an internal risk score. Labels such as “limited” or “minimal” are explanatory shorthand and do not replace an assessment of specific obligations.

4.2 Categorise systems

By technology

Category	Description	Examples
ML/DL models	Statistical models	Churn prediction, image classification
Generative AI	Models that generate content	Text or image generation
Rule-based systems	Expert systems and decision rules	Business rules engines
Robotic process automation	Process automation	UiPath, Power Automate workflows
Embedded AI	AI within a product	Smart devices, vehicles

These are inventory categories. A rule-based workflow or an RPA tool does not automatically meet the AI Act’s definition of an AI system.

By deployment model

Model	Control over data	Control over the model	Examples
In-house development	Broad, subject to rights and obligations	Broad, depending on components used	In-house ML
Fine-tuned model	Depends on data, access and contract	Depends on the base model and deployment	Fine-tuned LLM
API/SaaS	Depends on role, purpose and contract	Limited to the interface and configuration available	External model API
Embedded	Depends on role and product or system purpose	Depends on integration and supplier capabilities	AI within a product

5. MP-4: Identify risks

5.1 EU AI Act assessment

Purpose and role: distinguish the model from the system, intended use and your organisation’s role. Building an application on an external API can make you the provider of that system.
Prohibited practices: assess the precise conditions and exceptions in Article 5. Not every assessment of people is prohibited social scoring, and the prohibition on emotion recognition at work has defined exceptions. Use the current text and the differing application dates of amended provisions.
High risk through a product: assess Article 6(1) and Annex I, including the safety component or product and the requirement for third-party conformity assessment; also account for the special rules in Article 6(1a)–(1c).
High risk through intended use: assess the specific Annex III use cases under Article 6(2), including Article 6(3) conditions and the required documented reasoning where an exception applies. An Annex III system that profiles natural persons is always high-risk. A provider relying on Article 6(3) must document the assessment before placing the system on the market or putting it into service and is subject to registration under Article 49(2). An industry name alone is insufficient.
Other obligations: assess Article 50 for the specific interaction or content, any GPAI obligations and other applicable legislation separately. Transparency duties can apply alongside other requirements.

The conclusion should state the evidence, role, relevant obligations, application dates and unresolved questions. See the classification guide and regulatory timeline.

5.2 NIST generative AI risk areas

NIST AI 600-1 describes 12 generative AI risk areas. The priorities below are illustrative internal ratings, not ratings assigned by NIST. Determine their relevance and priority for your context.

#	Risk area	Examples	Illustrative priority
R1	CBRN	Information that enables chemical, biological, radiological or nuclear harm	Critical
R2	Confabulation	False or misleading outputs	Critical
R3	Dangerous or violent content	Harmful content	Critical
R4	Data privacy	Exposure of personal data	Critical
R5	Environmental impacts	Energy use and carbon footprint	Medium
R6	Harmful bias and homogenisation	Discrimination and loss of diversity	Critical
R7	Human–AI configuration	Automation bias or overreliance	High
R8	Information integrity	Misinformation	Critical
R9	Information security	Cybersecurity risks	Critical
R10	Intellectual property	Copyright and other rights	High
R11	Obscene, degrading or abusive content	CSAM and non-consensual intimate imagery	Critical
R12	Value chain and component integration	Dependencies and supply chain risks	High

6. MP-5: Impact assessment

6.1 AI impact assessment (AIIA)

Use this as a general assessment template, adapting reviewers and approval authority to the organisation. It does not automatically satisfy a statutory assessment requirement.

# AI IMPACT ASSESSMENT

## 1. System overview
- System ID:
- Purpose:
- Owner:

## 2. Stakeholder analysis
| Stakeholder | Positive impact | Negative impact | Mitigation |
|---|---|---|---|
| | | | |

## 3. Impact on rights and freedoms
| Right or freedom | Impact level | Justification | Safeguards |
|---|---|---|---|
| Privacy | | | |
| Non-discrimination | | | |
| Human dignity | | | |
| Freedom of expression | | | |

## 4. Risk assessment
| Risk | Likelihood | Severity | Score | Mitigation |
|---|---|---|---|---|
| | Low/Medium/High | Low/Medium/High | | |

## 5. Proportionality
- Is AI necessary for this purpose?
- Are less intrusive alternatives available?
- Is the benefit proportionate to the risk?

## 6. Safeguards
| Safeguard | Implementation | Status |
|---|---|---|
| Human oversight | | |
| Appeal mechanism | | |
| Transparency notice | | |

## 7. Conclusion
- Approved: proceed with safeguards
- Approved with conditions
- Not approved: unacceptable risk

## 8. Review and approval
| Role | Name | Date | Opinion or decision |
|---|---|---|---|
| AI owner | | | |
| DPO, where relevant | | | |
| Legal, where relevant | | | |
| Accountable decision-maker | | | |

An appointed DPO advises and monitors compliance; the DPO’s opinion neither transfers the controller’s responsibility for processing nor acts as a universal approval signature.

6.2 Integrate the DPIA where required

A DPIA is required before processing likely to result in a high risk to individuals’ rights and freedoms. GDPR Article 35 includes, for example, extensive systematic evaluation of personal aspects based on automated processing on which decisions producing legal or similarly significant effects are based; large-scale processing of special categories of data; and large-scale systematic monitoring of publicly accessible areas. Check the relevant supervisory authority’s lists as well.

7. Implementation checklist

The timing below illustrates a project sequence; it is not a delivery commitment or a NIST requirement.

Phase 1: Inventory — weeks 1–2

Identify AI systems across the organisation.
Complete a basic inventory record for each system.
Categorise by technology and deployment model.
Assign owners.

Phase 2: Classification — weeks 3–4

Assess each system against the EU AI Act.
Identify high-risk systems and document the basis.
Map relevant generative AI risk areas.
Prioritise according to context and potential harm.

Phase 3: Impact assessment — weeks 5–8

Conduct AI impact assessments for priority systems.
Complete DPIAs where required.
Identify stakeholders and impacts.
Propose mitigation measures.

Phase 4: Documentation — ongoing

Maintain a central inventory.
Establish a review cycle.
Integrate reviews with change management.
Automate evidence collection where useful.

8. Tools and templates

Resource	Purpose
Inventory template above	Record AI systems and ownership
AI Act classification guide	Assess applicable legal categories and duties
Generative AI risks	Assess the 12 risk areas in context
Assessment overview	Select and coordinate relevant assessments

Continue to MEASURE for testing, evaluation and monitoring.

AI-Native Entry Framework | CC BY-NC-SA 4.0