MAP 1.6 System requirements from AI actors: evidence guide

What MAP 1.6 asks for when requirements come from AI actors

MAP 1.6 asks that system requirements come from the people who will build, use, be affected by and oversee an AI system, and that design decisions reflect the social and technical context the system operates in. If a customer or assessor asks how AI requirements were gathered, the answer should name who was consulted, how their needs were written down, and where those needs changed the design. MAP 1.6 is an outcome in the Map function, described in NIST AI 100-1, not a checklist or ordered set of steps. Nothing in the framework is certified. NIST describes the AI RMF as voluntary, and no body issues an AI RMF certificate, so any claim of conformance is one the organization must document and be able to explain.

The risk MAP 1.6 targets is a familiar one. When written requirements are missing or incomplete, the NIST AI RMF Playbook notes that teams may overlook stakeholder needs, lean on implicit assumptions and groupthink, and focus only on computational requirements such as accuracy and latency. The Playbook also says AI development can move faster than documentation practices built for traditional software, which is why requirements tend to drift. A practical check is to ask whether the requirements record includes non-functional needs such as respect for user privacy, fairness for affected groups, and how to escalate when the system behaves unexpectedly, and whether each of those needs traces to a named stakeholder source. Confirm with the product owner which sources were used, such as product requirement documents, user stories or UI/UX research, and keep the record current as the system changes.

Which AI systems, teams and stakeholders fall under MAP 1.6

MAP 1.6 asks who must be consulted for system requirements and how those requirements account for socio-technical effects. The decisions below set the boundary of that work before any requirements are written, and each one changes who is paid to do what, and what evidence the organization must keep.

Built in-house or bought

A system built in-house means the organization writes its own requirements and owns every design choice, so MAP 1.6 work sits with the team that makes those choices. A bought system shifts part of the requirement elicitation to the vendor, but the organization still has to state its own needs, such as privacy expectations and affected user groups, and check the vendor's documentation against them. Confirm early which party holds the requirements record and who signs it off.

End users and operators

End users and operators are the people who interact with the system or act on its output, and their needs often differ. Users may care about accuracy and clear explanations, while operators need to know when to override the system and how much proficiency their staff require. Requirements elicited from only one of these groups tend to miss the other, so record both groups and the method used to reach them, such as user stories or UI/UX research.

Affected communities and civil society

Affected communities are people who do not use the system but are subject to its decisions, such as applicants, patients or customers in a scoring process. The Playbook suggests including affected communities and civil society in setting priorities. Check whether the organization has a documented way to reach these groups, how their input is recorded, and whether their concerns change any requirement or only get noted.

Domain experts and independent reviewers

Domain experts, such as clinicians, underwriters or legal staff, know the context of use and the harms that a generic development team may not see. Their input matters most where the Playbook warns that missing written requirements lead teams to focus only on computational requirements and to rely on shared assumptions. Confirm which experts sit on the requirements review and whether anyone outside the build team can challenge a requirement.

Third-party models and data

Pre-trained models, external datasets and vendor APIs bring requirements the organization did not write, such as data provenance, retention limits or privacy terms. Requirements for these components must be stated as conditions the supplier has to meet, then checked against contract terms and documentation. Ask suppliers for the information needed to test those conditions, and record which requirements the supplier cannot meet.

How an assessor tests MAP 1.6 requirements

This table compares what an assessor or internal auditor typically reviews for MAP 1.6, what evidence they expect to see, and where requirements work usually fails. Assessor practice varies, so treat the test approach as a general pattern and confirm the expected depth with your reviewer before fieldwork. The main takeaway is that a requirement only passes review when its traceable path to a design decision is documented.

Test step	What the assessor looks for	Common finding
Review requirements artifacts	Documented system requirements, such as product requirement documents, user stories or UI/UX research notes, that name relevant AI actors and their needs	Requirements cover only computational performance, such as accuracy or latency, with no stated user, privacy or fairness needs
Trace requirements to design	Design records showing how each stated requirement, including privacy and socio-technical needs, maps to architecture, features or constraints	Requirements exist but no design artifact refers back to them, so the link cannot be shown
Trace requirements to test records	Test cases, evaluation results or acceptance criteria that check each requirement, including requirements about affected groups	Tests measure only the metrics the team already had, and no test addresses the stated stakeholder needs
Check stakeholder participation records	Attendance, consultation notes or outreach logs showing that affected users, domain experts and communities were asked for input	No record of who was consulted, or consultation happened only inside the development team
Check stakeholder sign-off	Dated approvals from the business owner, a risk or compliance function and, where relevant, representatives of affected users	Requirements approved by the project lead alone, or sign-off missing for later revisions
Look for socio-technical decisions	Evidence that a socio-technical impact changed a decision, such as a scoped feature, an added human review step or a withdrawn use case	The impact was discussed, but the documentation does not show what decision it influenced
Review feedback handling	A log linking stakeholder feedback to requirement changes, with the reason for each accepted or rejected item	Feedback was collected but no record shows how it changed design, or why it was declined
Check documentation currency	Requirements updated when the system, its data or its deployment context changed, with version history	Requirements written at project start and never revisited, even after scope or user population changed

Steps to elicit system requirements and record design decisions

This sequence turns stakeholder needs into written, reviewed system requirements that reflect socio-technical impacts, so design decisions can be traced back to the people they affect. Each step ends with a named artifact that the next step builds on.

Identify the relevant AI actors and their needs
Start by listing everyone whose requirements should shape the system: product owners, operators, end users, affected communities, legal and privacy staff, and people who will maintain the system. The AI risk lead or product owner compiles the list and records why each actor is included and what they can affect or be affected by. The step is complete when the actor register is approved by the team that owns the context decisions in MAP 1.2 and MAP 1.3, and each actor has a named contact or representative.
Elicit requirements through structured methods
Gather requirements with product requirement documents, user stories and UI/UX research sessions, and record which actor each requirement came from. Product managers and UX researchers run the sessions, and the Playbook's note that written requirements can be missing or incomplete is a reason to probe beyond functional needs, including privacy, fairness and oversight expectations. The output is a requirements backlog where every item has a source actor, a rationale and a status.
Translate trustworthy characteristics into requirements
Convert each relevant trustworthy characteristic from AI 100-1 (validity and reliability, safety, security and resilience, accountability and transparency, explainability, privacy enhancement, and fair treatment with harmful bias managed) into testable requirements, such as acceptance criteria or documented limits. The product owner and risk lead do this together and flag any characteristic the team decides does not apply, with the reason. The step closes when every characteristic has either a linked requirement or a recorded justification for exclusion.
Standardize impact assessment across the lifecycle
Adopt one impact assessment template that the team uses at design, before deployment and at each significant change, so impacts on people and communities are compared the same way over time. The risk lead owns the template and reviewers from outside the build team check that it asks about affected groups, foreseeable misuse and socio-technical effects. The output is a completed assessment for the current design, stored with a version date and linked to the requirements it informed.
Review conflicts with affected communities and stakeholders
Take the draft requirements and impact assessment back to the actors identified in step one, including affected communities or their representatives where feasible, and record where their priorities conflict with business or technical goals. The accountable executive or governance body decides how each conflict is resolved, which ties this step to the feedback process in GOVERN 5. The output is an adjudication log that states each conflict, the options considered, the decision and the person who made it.
Record adjudicated decisions in version-controlled documentation
Write the final requirements, design decisions and adjudication outcomes into a documentation system that keeps a history of changes, who made them and when, and that restricts who can approve edits. The document owner sets review roles so that the people who wrote a decision are not the only people who approve it. Teams can check the step against the Playbook's documentation prompts for MAP 1.6, and it is complete when every requirement links to its source actor, its design decision and its adjudication entry.
Review requirements when the system changes
Re-run the actor review and impact assessment whenever the model, data, use case, deployment setting or affected population changes in a way that could alter socio-technical effects. The product owner triggers the review, and the same reviewers sign off on whether requirements still hold. The output is a dated revision of the requirements record with a change note that points to the decision it modifies, and teams should confirm their own change-triggering criteria in advance because the Playbook does not set one.

Why requirements for AI systems drift from the documented record

Requirements for AI systems tend to drift away from what is written down, and MAP 1.6 asks organizations to close that gap before design decisions harden. The NIST AI RMF Playbook notes that AI system development can move faster than documentation processes built for traditional software. When written requirements are missing or incomplete, the Playbook warns that AI actors may overlook stakeholder needs, lean on implicit biases such as confirmation bias and groupthink, and focus only on computational requirements. In practice, a team can ship a model that meets its accuracy target while nobody has recorded the privacy expectations of the people whose data trains it, or the fairness concerns of the users it will affect. Those gaps are hard to find later because no document shows what was agreed.

A practical response starts with treating requirements as living records rather than a one-time specification. Ask the team to name which artifacts count as the requirement set for each system, such as a product requirement document, user stories, UI/UX research notes and the impact assessment, and to assign an owner and a review trigger for each. Triggers should include a new model version, a change in training or input data, a new deployment setting or user group, and any change in the business use. Versioned wikis and repositories help here. For example, XWiki keeps a version history of each page with what changed, when and by whom, and GitLab protected branches can require review before changes to shared requirement documents or configuration files are merged. Confirm how your chosen tools record approvals before relying on them as evidence.

Keep the review focused on the people who were missing from the first round. Re-run stakeholder elicitation when the user population or the operating context changes, and record which affected groups and civil society representatives were consulted, what they said and how the team responded. Standardize the impact assessment so that it is repeated across the lifecycle rather than completed once before launch. Finally, set a rule that a requirement is not closed until its owner confirms it still matches the system in production. Confirm with your auditor or assessor which of these records they will ask to see, since the same evidence supports several related MAP and GOVERN outcomes.

Evidence that shows MAP 1.6 requirements are working

MAP 1.6 is only as credible as the records behind it. The artifacts below show who was asked for requirements, what was decided, how those decisions were tested and whether feedback changed the design. Each card names what to keep current between assessments so the record reflects the system as it runs today.

Versioned requirements documents

These are the written system requirements, including the trustworthy characteristics the team chose to build in, such as privacy and fairness. The Playbook's discussion of MAP 1.6 warns that missing or incomplete written requirements let teams overlook stakeholder needs and focus only on computational requirements. Keep every revision in version control with the author and date of each change. Check that the current requirement set matches what was built and that superseded versions remain retrievable.

Stakeholder elicitation records

These records show which relevant AI actors were consulted, how, and what they said. Methods named in the Playbook include product requirement documents, user stories and UI/UX research, and affected communities and civil society should appear where the system affects them. Record the participants, the method, the date and the requirements that came out of each session. Refresh the record when the user population or deployment context changes, and note any group that was not reached.

Impact assessment outputs

An impact assessment states the socio-technical effects the team expects the system to have on people and groups, and how those effects shaped the requirements. The Playbook suggests standardizing these assessments across the lifecycle, so the same template should apply from design through change. Keep each completed assessment with its reviewers and the requirements it produced. Re-run the assessment when the system's purpose, data or user group changes, and confirm that the earlier version is still on file.

Traceability from requirements to tests

A traceability matrix links each system requirement to the design decision, the test that checks it and the result. For a MAP 1.6 requirement such as respecting user privacy, the matrix should point to a test or review that would fail if the requirement were broken. Use a tracker in which every requirement has an identifier and each test cites it. Between audits, flag requirements with no linked test and tests that no longer map to any requirement. Static analysis such as Semgrep Community Edition can run in CI/CD and provide repeatable evidence for code-level checks that support those links.

Decision logs for feedback-driven changes

A decision log records each change to the design that came from stakeholder or impact feedback, along with the feedback received and the reason for the outcome. This is the clearest evidence that elicitation affected the system rather than being recorded for form's sake. Each entry should name the approver and link to the requirement it changed. Protected branches in GitLab Community Edition can keep changes to requirement-related code and documents under review, so approval records stay attached to the change that made them.

Review records and access controls

Review records show who checked the requirements, when, and what they concluded, and access controls show who could change them. Assign edit rights to the people accountable for requirements and read rights to reviewers, using role-based permissions so that the access model is documented. BookStack, for example, derives user abilities from assigned roles and can override permissions per shelf, book, chapter or page. Confirm during each review that the permissions still match current roles and that no former staff member retains edit access.

What meeting MAP 1.6 costs in money and effort

This table breaks down the cost components of meeting MAP 1.6 by who is paid, whether each cost is one-time or recurring, and what moves it up or down. No figures were published for this work, so use the drivers and quote requests to compare offers on the same written scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Stakeholder time for requirement elicitation	Internal staff, product owners, affected users and community representatives	Mostly one-time, with recurring refresh at each major change	Number of relevant AI actors, depth of user research and how many requirement cycles are needed
Facilitation of elicitation sessions	Internal facilitator or an external consultant paid for workshop design and delivery	One-time per cycle	Whether the team already runs UI/UX research and product requirement reviews, and how many groups must be reached
Engineering time to trace requirements	Internal engineers or an implementation partner building traceability from requirements to design and tests	One-time build, recurring upkeep	Maturity of existing requirement templates and how many components and third-party models the system uses
Documentation tooling	Software vendors or self-hosted open-source platforms, plus the staff who administer them	License spend is recurring for commercial tools; open-source tools remove license spend but keep hosting and administration	Choice of wiki and repository tools, hosting location, and whether version history and role-based access already exist
Impact assessment work	Internal risk and legal staff, or external assessors where scope requires it	Recurring across the lifecycle, with rework after significant changes	Breadth of the standardized impact assessment practice and number of deployment contexts
External review of requirements	Independent reviewers or domain specialists engaged for specific questions	Recurring for each review cycle, often optional	Risk level of the system, regulatory expectations and whether internal reviewers are independent of the build team
Remediation of gaps found in review	Internal teams, with partner support if scope includes it	One-time per finding, plus follow-up checks	Quality of written requirements, since missing or incomplete requirements tend to surface late

Who owns MAP 1.6 and what an implementation partner can prepare

Your organization owns the system requirements. MAP 1.6 asks that requirements come from relevant AI actors and that design decisions reflect socio-technical implications, and only your people can decide whose needs count, which trade-offs are acceptable and what the system must never do. Those decisions belong to product owners, risk owners and the affected business functions, with input from users and, where the Playbook's suggested actions apply, affected communities and civil society.

Requirement decisions: Product, business and risk owners agree which requirements the system must meet, including privacy and fairness expectations, and record the reasons behind each one.
Stakeholder elicitation: Staff run and document the interviews, user research, user stories and requirement reviews that surface needs from people outside the AI team.
Trade-off decisions: Named decision makers resolve conflicts between trustworthiness characteristics and document the choice.
Sign-off: An accountable executive or governance body approves the requirement set before development proceeds and when it changes.
Ongoing ownership: Your team keeps requirements current as the context of use changes.

Confirm that each requirement has a named owner and an approval date before anyone outside the organization touches the documentation.

Common gaps in AI system requirements and how to close them

Most requirement failures under MAP 1.6 are not missing intent. They are requirements that are too narrow, too static, undocumented or editable by anyone. The cards below cover six gaps that assessors and internal reviewers commonly find, each with a fix the organization can verify in its own records.

Requirements limited to accuracy metrics

A requirement set that names only accuracy, precision or latency describes computational performance and nothing about the people the system affects. The Playbook's discussion of MAP 1.6 warns that AI actors who focus only on computational requirements can overlook stakeholder needs. Fix it by adding requirements for each trustworthy characteristic the system must meet, such as privacy, explainability and fairness, with a stated test for each. Check that every stakeholder group named in the context documentation has at least one requirement traced to it.

No record of affected communities

Requirements written without input from the people the system will affect tend to reflect the builder's assumptions. The Playbook suggests including affected communities and civil society in setting priorities. Fix it by keeping a register of affected groups, the method used to hear from each one (interviews, user research, public comment), and the requirements that came from that input. A reviewer should be able to trace any requirement back to a named source or to a documented decision not to consult.

Requirements not updated after changes

Requirements often stop changing once a system is approved, even as the data, model, use case or deployment setting moves. The Playbook notes that AI development can outpace documentation processes built for traditional software. Fix it by tying requirement review to defined change triggers, such as a new model version, a new user population or a new data source, and by recording the date and reason for each revision. Ask the team which trigger would have caused a requirement change in the last release.

Undocumented trade-offs

When two requirements conflict, such as explainability against accuracy or privacy against personalization, the decision often lives in a meeting note or someone's memory. MAP 1.6 expects design decisions to account for socio-technical implications, which requires a visible record of the choice. Fix it by logging each trade-off with the requirements involved, the option chosen, the reasons, the people who approved it and the residual impact. Link the entry to the risk tolerance set under MAP 1.5 so the decision can be checked against the stated limits.

No link between feedback and design decisions

Teams often collect user feedback, complaints or stakeholder comments without showing how any of it changed the requirements. An assessor testing MAP 1.6 will look for this chain: input received, input adjudicated, requirement changed or retained with reasons. Fix it by giving each feedback item an identifier, recording who reviewed it and what they decided, and linking accepted items to the requirement they modified. Items rejected should also carry a written reason.

Access controls that allow silent edits

If anyone with wiki or repository access can rewrite a requirement, no one can later prove what was agreed or when it changed. Requirements kept in a shared wiki need page version history and role-based permissions, and requirements kept in code repositories need protected branches that block direct pushes and disable force pushes. Fix it by restricting who can approve requirement changes, keeping every prior version retrievable, and reviewing the change log at each release. Confirm the exact permission model with the platform vendor before relying on it as evidence.

How much effort does MAP 1.6 take and can we do it ourselves?

What drives the effort of MAP 1.6 in practice?

The effort depends mainly on how many AI systems are in scope, how many relevant AI actors you must consult, and how much written requirement material already exists. MAP 1.6 asks that system requirements be elicited from relevant AI actors and that design decisions account for socio-technical implications. Teams with a single system, documented user research and existing product requirement documents usually have less to do than teams that must rebuild requirements for several systems at once. Effort also rises with the number of affected communities you need to consult and with the depth of impact assessment your sector expects. Ask any partner to size the work against these inputs in the written scope.

Does NIST certify that we meet MAP 1.6?

No. NIST does not certify, accredit or validate any organization's use of the AI RMF, and the framework has no conformity assessment program. Meeting MAP 1.6 is a self-directed effort that you can document and, if a customer or regulator asks, have reviewed by an independent party. Any report or attestation about your practice must come from an independent assessor or auditor, not from NIST or from an implementation partner. The NIST AI RMF page is the starting point for confirming the framework's voluntary status.

Can our own staff complete MAP 1.6 without outside help?

Often yes, if you have product owners who can write requirements, researchers who can run user studies, and someone who can run impact assessments. The work is mostly documentation and consultation, so the bottleneck is usually time and facilitation skill rather than technical depth. Teams without experienced risk or privacy staff, or with many systems in scope, often bring in outside help for the facilitation, the templates and an independent review of the results. Be honest with yourself about whether your team has done stakeholder elicitation before, because MAP 1.6 depends on it.

What does the work require from our internal staff?

Your staff remain the owners of the requirements and the decisions. You will need named people from product, engineering, legal or privacy, and at least one representative of the users or affected communities. Each requirement should have an owner who can explain why it exists and who approved the trade-offs. Staff must also keep the requirement records current as the system changes. Plan for these people to attend elicitation sessions and review drafts, since an external partner cannot make those decisions for you.

How long does MAP 1.6 take to complete?

The duration depends on the scope agreed in writing, so no fixed timeline applies across organizations. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed before work starts with DeployOpen. Your own schedule will also depend on how quickly stakeholders can attend sessions and approve requirements. Ask for a timeline tied to named deliverables, such as a requirements register per system, a stakeholder list and a documented impact assessment, rather than a generic duration.

How does MAP 1.6 relate to ISO/IEC 42001?

MAP 1.6 is part of the NIST AI RMF, a voluntary framework, while ISO/IEC 42001 is a certifiable AI management system standard with its own Annex A controls. The two address overlapping concerns, such as stakeholder requirements and impact assessment, but they are not interchangeable and this page does not provide a control-by-control mapping. If you pursue ISO/IEC 42001 certification, a certification body will assess against that standard, not against MAP 1.6. Confirm the relationship with your chosen auditor before you rely on shared evidence.

What should we ask a partner to include in a written scope?

Ask for a written scope that names the AI systems covered, the relevant AI actors to be consulted, the requirement sources and templates to be used, and the impact assessment method. The scope should list deliverables, such as the requirements register, stakeholder records and design decision log, along with who owns each deliverable after handover. Confirm what is excluded, such as independent review or audit support, and who performs each task. Ask how the partner will handle changes to scope and how the evidence will be stored, for example in a version-controlled wiki or repository under your control.

How DeployOpen scopes requirements evidence work

DeployOpen prepares the systems, documentation and evidence for MAP 1.6, but the organization owns the requirements and the decisions behind them. In practice, an engagement starts with a written scope that names the AI system, the actors whose requirements will be elicited, the artifacts to be produced and the environment where the work happens. That environment is the client's own: their cloud accounts, data centers or air-gapped networks. DeployOpen does not issue audits, attestations or certifications. NIST does not certify AI RMF use either, so no assessor or certification body is involved for this subcategory unless the client's contract or regulator asks for one. Before work begins, confirm with your own team which stakeholder groups are in scope, who signs off on requirements, and whether your internal documentation standard already defines a product requirements document or user story template.

Once scope is agreed, the work typically centers on capturing requirements in a form that survives later review. Ask the implementation partner to state exactly which pages, templates and approval records it will set up and who will maintain them after handover. Confirm in your environment whether your wiki or documentation platform keeps version history with change authorship and rollback, and whether branch protection or review rules apply to any repository holding requirement files. Confirm also how stakeholder input, including input from affected communities and users, will be recorded and resolved, since that record is the evidence an assessor or your own risk committee will ask to see. Any change to these items after signing should go through a written scope amendment.

How DeployOpen prepares MAP 1.6 evidence

DeployOpen plans and builds the self-hosted systems that hold MAP 1.6 requirement records, decision logs and design-review evidence inside your own infrastructure. Your organization owns the requirements and the decisions; DeployOpen prepares the systems and the evidence trail, and it does not decide or certify that the AI system meets MAP 1.6.

How we scope

The written scope lists which AI systems, teams and stakeholder groups the requirement records will cover.
We confirm where requirement sources live today, such as product requirement documents, user stories and UI/UX research notes.
The scope names who in your organization approves requirements, and who is responsible for capturing affected-community input.

How we build

We configure a self-hosted wiki with version history so every requirement change records what changed, when and by whom.
We set role-based permissions so requirement pages can be edited by the AI team and reviewed by governance owners.
We set up review workflows in a self-hosted Git platform, with protected branches so approved requirement documents cannot be changed silently.

How we hand over

You receive the documented requirement set, the templates for impact assessment and the access model for each system.
We provide a runbook explaining how to add requirements, record stakeholder input and retain prior versions for later review.
Handover covers what the evidence shows and what it does not show, so your team can brief any independent assessor accurately.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer for requirement records that change over time.
Confirm with your assessor or internal audit team which evidence formats they accept before the scope is signed.