What MAP 4.1 asks for when AI components come from outside
MAP 4.1 expects an organization to have approaches for mapping the technology and legal risks of its AI components, including third-party data and software and the risk of infringing third-party intellectual property or other rights. Those approaches must be in place, followed and documented. The NIST AI Risk Management Framework is voluntary and has no certification, so nobody issues a badge for meeting MAP 4.1. The evidence is your own practice: a defined method, records that show it runs, and an inventory that proves it covers the components you actually use. For a team that builds AI from pre-trained models, open-source libraries and purchased datasets, that practice is the difference between knowing what sits inside a system and discovering it during an incident or a customer audit.
Two things usually make this hard. The first is ownership. The component list is spread across machine learning engineers who pull models, platform teams who install libraries, and data teams who buy or scrape datasets, and no one is accountable for the complete list. The second is legal terms. Licenses, warranties, terms of service and data-use restrictions sit in procurement folders, contract repositories and developer READMEs, so the question "can we use this model commercially and for this purpose?" cannot be answered quickly. Start by naming one accountable owner for the inventory, then ask each team to list every model, library, dataset and API it depends on, including versions and sources.
Once the list exists, decide which entries need a legal and technical review and record the outcome. Ask legal to confirm the license terms for each open-source model and library, the usage rights for purchased data, and whether the vendor's terms give you any indemnity for intellectual property claims. Ask engineering to confirm how each component is versioned and how changes reach production. Confirm these points with the vendor or with your own counsel, because the answers depend on the specific agreement and jurisdiction, not on general practice. The output is a register that links each component to its risks and its reviewer, which is the documented approach MAP 4.1 is looking for.
Which components and third parties fall under MAP 4.1
MAP 4.1 applies to every AI component your organization did not build from scratch, along with the legal and technology risks those components bring. The cards below cover the scoping decisions that set how large the mapping workload becomes, and they should be settled with system owners before any inventory work starts.
Which AI systems are in scope
Start with the AI systems your organization builds, buys or operates, including internal tools and pilots that never reached production. Each system needs an entry in the inventory so that its components can be mapped. The most important check is whether shadow tools used by individual teams are recorded at all, because unrecorded systems carry the same third-party exposure as approved ones. Confirm the list with each system owner rather than relying on a central register alone.
Third-party foundation and pre-trained models
Foundation and pre-trained models usually carry the largest technology and legal exposure, because their training data, licenses and usage terms come from a party outside your organization. Record the model name, version, provider, license and any acceptable use restrictions. The licence terms of each model often differ from the terms of the product built on top of it, so review both.
Open-source software and libraries
Open-source frameworks, model runtimes and data processing libraries are components in their own right, and each carries a license that governs how it can be used, modified and distributed. Generate a software bill of materials for each deployed system so that transitive dependencies are visible. Check license compatibility with your intended use, including any copyleft obligations that could apply when you modify a component.
Third-party and purchased datasets
Purchased, scraped, licensed and public datasets all fall under MAP 4.1 when they feed training, fine-tuning, evaluation or retrieval. For each dataset, record its source, license, permitted purposes, and whether it contains personal or sensitive data. A dataset may be lawfully obtained yet still restricted in how it can be used for a particular model, so confirm the permitted purpose with legal counsel for each use.
Hosted AI APIs and fine-tuned models
Hosted AI APIs fall within MAP 4.1 even though the provider runs the model, because your data, prompts and outputs pass through their systems under their terms. Ask whether a model you fine-tune on top of a third-party base counts as a separate component with its own risk record. In most programs it should, since fine-tuning changes behavior and can change the license position. Confirm this treatment with your system owners before setting the inventory format.
Contractors and data providers
Contractors who build, label, tune or host AI components, and data providers who supply inputs, bring technology and legal risk through their contracts and their own subcontractors. Identify who has access to your data or models, which intellectual property terms apply to their deliverables, and whether they use further third parties. Ask each contractor to confirm its subcontractor list and how it handles changes to those components.
How an assessor tests MAP 4.1
This table lists the checks an assessor typically runs against MAP 4.1 and the evidence each check asks for. Because NIST AI RMF has no certification, the assessor reviews your own documented approach and whether you follow it, not a NIST grade.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Mapping approach is documented | A written method for identifying technology and legal risks of AI components, its owner, review date and approval record | Practice exists only in tribal knowledge; no owner or review cycle is named |
| Component inventory covers third-party data, software and models | Inventory listing each dataset, library, open-source package, API and pre-trained model, with source, version and business owner | Inventory lists internal systems only; open-source dependencies and model sources are missing |
| License and IP terms were reviewed | Records of license review for each component, including license identifiers, usage restrictions and any IP indemnity terms | Licenses are assumed permissive without review; data terms of use are never checked |
| Vendor change management is considered | Vendor release notes, change notices, and the internal process for re-assessing a component after an update | Updates are applied automatically with no reassessment of risk or license changes |
| Third-party evidence is reviewed | Audit reports, test results, warranties and service terms on file, with the date each was last reviewed | Vendor reports are collected but never read, or they are out of date |
| Support redundancy is assessed | Documented contingency for each critical third-party component, such as an alternative supplier or a fork plan | No assessment exists for single-supplier or single-maintainer dependencies |
| Approach is followed in practice | Sample of recent AI projects showing the mapping steps completed, with sign-off by the named owner | Projects skip the mapping step, or records are created after deployment |
| Findings feed back into controls | Link between mapped risks and the MAP 4.2 internal controls and MANAGE 3 monitoring tasks | Identified risks have no assigned control, owner or follow-up action |
How to build the MAP 4.1 mapping approach step by step
This sequence turns MAP 4.1 into a working, documented approach: a defined scope of AI components, an inventory of them, a review of their legal and technology risks, and a written record with a named owner.
Define what counts as an AI component
Agree in writing which parts of your AI systems fall inside the mapping: third-party models (including foundation models), datasets, open-source libraries, hosted APIs, plugins and the infrastructure they run on. The AI governance lead and the system owner usually sign off on this definition, and legal and procurement should confirm it covers contracted services. The step is done when a short definition exists and each system in scope has been checked against it.
Build the component inventory
Record each in-scope component with its source, version, owner, the AI systems that depend on it, and where it is hosted. Asset and software inventory tools can supply part of the list. For self-hosted platforms, GLPI's Assets module and Wazuh's Syscollector can record installed software and hosts, and Trivy can produce a software bill of materials for container images and code dependencies. Models and datasets usually need manual entries. The step closes when every component has one inventory record and an accountable owner.
Review legal and license terms for each component
For each component, collect the license, terms of service, warranties and any third-party audit reports, then record the obligations they create, such as attribution, copyleft conditions, usage limits and restrictions on training or redistribution. Legal counsel should review anything that is contract-specific or unclear, and the output is a license register that flags components with unresolved terms. OWASP Dependency-Track can track license identifiers by component when the SBOM uses SPDX IDs. The step is complete when each component has a recorded license status and every open question has an owner.
Assess technology risks and vendor change practices
Assess each component for known vulnerabilities, outdated or modified versions, dependency on a single supplier, and how the supplier releases and communicates changes. Ask vendors for their release and change management practices, and note how quickly they fix security issues. Dependency-Track can identify components with known vulnerabilities and outdated versions, and Trivy can scan images and SBOMs against vulnerability data. Record the redundancy of third-party support where a failure would affect the system. The step closes with a risk entry for each material finding, including the component affected and the likelihood and effect as your team understands them.
Document the approach and assign its owner
Write a short procedure that states the scope, the inventory fields, the legal and technology review steps, the review frequency, and the escalation path for findings. Name one accountable owner for the mapping, and record who approves changes to the procedure. Keep the inventory, license register and risk entries linked to the procedure so an assessor can trace a component from scope to finding. The step is done when the procedure is approved and the owner has confirmed the first complete cycle.
Evidence that passes a MAP 4.1 review
A MAP 4.1 review checks whether the approach for mapping technology and legal risks of AI components is in place, followed and documented. The six artifacts below connect the written method to the records that show it was used, and each one needs a routine owner so it stays current between reviews.
Written mapping approach
A short, dated procedure that states which AI components are in scope, which third-party data, software and models must be mapped, who performs each review, and which legal and intellectual property questions every component must answer. Reviewers look for a document that names the owner, the trigger for a new review (such as a new model version or a changed data source) and the approval record. Confirm that the procedure references the Playbook suggested actions your organization adopted, and that teams actually follow it.
Component inventory with owners
A register of every third-party dataset, open-source package, foundation model and vendor service in the AI system, with the version in use, the internal owner and the deployment where it runs. Reviewers test whether the inventory matches what runs in production, so reconcile it against scanner output and host inventory each cycle. An entry without a named owner or version is a finding in most reviews.
License and IP review records
For each component, a record of the license terms (identified by license ID where one exists), the permitted uses, any attribution or copyleft duties, and the sign-off by legal or the responsible reviewer. For generative AI, this record also shows the process for responding to intellectual property infringement claims. Keep the record tied to the component version, because a license can change between releases.
Vendor audit reports and warranties
Copies or links to the third-party audit reports, testing results, warranties and terms of service for each vendor supplying AI components, with the date each document was received and the period it covers. Reviewers ask whether the organization read these documents and recorded what they did and did not cover. Set a recurring task to request updated reports before the previous one expires, and confirm the contract terms still match the report scope.
Vendor change notices and review log
A log of vendor release notes, deprecation notices and change management announcements for each third-party component, with the internal decision taken on each one. Reviewers want to see that a change to a model or library triggered a re-assessment of its risks, including any re-evaluation of models fine-tuned on top of a third-party model. Route vendor notices to a shared mailbox or ticket queue so none are missed.
Dated review history
A record of each mapping review: the date, the reviewers, the components covered, the risks found, the actions assigned and their closure dates. This history shows the approach is followed over time rather than written once for an audit. Keep prior versions of the mapping approach so reviewers can see what changed and why, and schedule a review at a fixed interval and after each significant change.
What meeting MAP 4.1 costs in money and effort
This table lists each cost component of mapping technology and legal risks for AI components, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since no fixed price or duration for MAP 4.1 is published and the figures depend on your own component count and change rate.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Internal engineering time to build the component inventory | One-time, then recurring upkeep | Number of models, datasets, libraries, APIs and hosted AI services in use, and how many teams build AI | Start from existing asset and software inventories, and limit the first pass to systems in production or in scope for the AI inventory |
| Legal and procurement review of licenses, terms and warranties | One-time per contract, recurring at renewal | Number of third-party contracts, license types (open-source, commercial, model-specific terms), and negotiation of indemnities | Group open-source components by license type, and reuse standard review checklists for recurring vendor terms |
| Tooling and licenses | Recurring for commercial tools, usually zero license cost for open-source tools | Scanner coverage, number of endpoints or projects, hosting of the tool, and whether vendor support is bought | Self-host open-source options such as Dependency-Track, Trivy, GLPI and Wazuh, but budget staff time to deploy and operate them |
| Recurring inventory upkeep as components change | Recurring | Release cadence of models and libraries, fine-tuning of third-party models, and change management at vendors | Automate SBOM generation and asset discovery in the build pipeline, and set a review trigger for each model or dataset update |
| External legal or intellectual property review | Per review, recurring for high-impact components | Use of copyrighted or personal data in training, generated outputs that may infringe, and jurisdictions involved | Limit outside review to components with unresolved license or data-rights questions, and scope it in writing before work starts |
| Assessor sampling time | Recurring at each audit or assessment cycle | Number of components an assessor samples, how complete the documentation is, and how many evidence requests are needed | Keep inventory records, license files and review sign-offs in one place so samples can be produced without rework |
| Staff time that open-source tools do not remove | Recurring | Analyst time to triage license and vulnerability findings, and reconciling tool output with contracts | Assign named owners for triage and set a regular review cadence, since tooling cuts license spend but not this work |
| Quote items to request in writing | Set once per engagement | The agreed scope, deliverables, roles of each party and the assumptions behind effort estimates | Ask for a fixed-scope quote listing components covered, review hours by role, tool deployment steps and handover of evidence |
Open-source tools that produce MAP 4.1 evidence
MAP 4.1 expects an organization to know what third-party data, software and models sit inside its AI systems and what risks they carry. The tools below produce inventory and component records that feed that review, though none of them makes the legal or intellectual property call. Confirm each tool's coverage in your own environment before you rely on its output.
Software bill of materials and license tracking
OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components, and tracks license use by component using SPDX license IDs. For MAP 4.1, this gives a running list of open-source packages inside an AI system and a first pass at license risk. Check which of your AI components (libraries, model-serving code, notebooks) actually appear in the SBOMs it receives, and who reviews flagged licenses.
OS and dependency inventory scanning
Trivy (Apache-2.0) identifies the OS packages and software dependencies present in a target, can produce them as a software bill of materials, and can scan existing SBOMs. It supports the inventory of AI runtime images, containers and build artifacts that the NIST Playbook asks organizations to track for third-party software. Confirm which target types your pipeline scans, and whether model files and datasets fall outside what the scanner can see.
Asset and software records
GLPI (GPL-3.0-or-later) manages computers, servers, network equipment and software records in its Assets module, entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. For MAP 4.1, it holds the organization's record of where AI systems run and which licensed software and hosting arrangements apply to them. Confirm that AI hosts and SaaS or procured tools are recorded, since automated inventory will miss services that have no agent.
Endpoint software inventory
Wazuh (GPL-2.0-only) runs its Syscollector module on each endpoint to collect hardware, operating system, installed software, services and users, storing the results in the Wazuh indexer for inventory views and reports. This helps confirm which software actually runs on the machines that host AI workloads, so the technology review reflects reality rather than the procurement record. Confirm the agent coverage across development, training and production hosts, and whether containers and cloud workloads are included.
Who owns, who prepares and who assesses MAP 4.1
The organization owns MAP 4.1. NIST AI 100-1 describes the outcome as approaches that are in place, followed and documented, and those approaches only work if named people in the organization make the decisions, accept the residual risk and keep the mapping current. No partner or auditor can take on that accountability, so the in-house team must settle it before any outside help starts.
- Accountable owner: One named executive or risk owner signs off the approach for mapping third-party data, software and model risks, and decides which components are in scope.
- Legal sign-off: Counsel reviews license terms, warranties, data rights and intellectual property exposure, then records what the organization accepts.
- Business decisions: Product and procurement leads decide whether a third-party component is acceptable, what conditions apply and when a component is replaced.
- Ongoing operation: Named staff review the mapping on a set schedule and after material changes to vendors, models or data sources.
- Governance linkage: The owner reports open technology and legal risks to the forum that handles AI risk decisions.
Confirm with your own counsel and risk owner which decisions they will sign personally before a partner begins the inventory work.
An implementation partner prepares the systems, inventory and evidence that the organization reviews. For MAP 4.1 this is the work most often outsourced, because it involves collecting component records from many sources and configuring tools that produce them consistently. The partner does not decide whether a risk is acceptable and does not certify that the approach meets any standard.
- Component inventory: The partner helps build a record of third-party data, open-source software and models, with versions, licenses and the systems that use them.
- Tool configuration: The partner installs and configures inventory and software composition tools, such as those that generate software bills of materials and track license risk, in the client's own environment.
- Review templates: The partner drafts templates for reviewing vendor audit reports, testing results, warranties, terms of service and license agreements.
- Evidence assembly: The partner gathers the records, exports and review logs that show the approach was followed, and organizes them for the owner and the assessor.
- Documentation handover: The partner documents how the tools and templates work so the in-house team can run them after the engagement.
Ask for the written scope to list each artifact, who reviews it and what the organization keeps after the engagement ends.
An independent auditor, assessor or certification body tests the approach and issues any report or certificate. The AI RMF itself has no certification program, so any formal opinion on MAP 4.1 comes from an assessor the buyer engages under a separate contract, such as a customer audit or a third-party assessment. The partner cannot make that judgment, because it prepared the evidence being judged.
- Testing the approach: The assessor checks whether the mapping approach exists, is followed in practice and is documented, rather than accepting the inventory at face value.
- Sampling evidence: The assessor selects components and traces them from the inventory to the license review, the vendor documentation and the owner's decision.
- Reporting: Only the assessor issues a report, attestation or opinion, and states the scope and limits of its work.
- Independence: The assessor should not have designed or configured the controls it tests.
- Scope agreement: The assessor and the organization agree in writing on the standard or customer requirement used as the test basis.
Before engaging an assessor, confirm which report or letter your customer or regulator will accept and whether the assessor has no conflict with the partner.
Where MAP 4.1 programs usually fall short
MAP 4.1 programs tend to fail in the same places: the inventory is incomplete, nobody owns the mapping, and the legal terms and vendor changes that create risk go unread or unwatched. Each card below names one gap, why it matters for mapping technology and legal risks of components, and the action that closes it.
Inventory lists models, not every component
Many inventories record the model a team chose and omit the datasets, open-source libraries, container base images and pre-trained weights beneath it. MAP 4.1 expects third-party data, software and models to be inventoried, so the gap leaves licensing and vulnerability risk invisible. Close it by generating a software bill of materials for each system and reconciling it with the asset register. Ask whether every dataset and library has an entry with its source and license.
License terms never read after signing
Teams often accept vendor terms of service, data licenses and open-source licenses without anyone checking restrictions on commercial use, training data reuse, attribution or output ownership. The Playbook suggests reviewing warranties, terms of service and license agreements for this reason. Close it by assigning a legal reviewer to each third-party component and recording the key restrictions in the component record. Confirm that a review happens before procurement signs, not after deployment.
No named owner for the mapping
When the mapping is shared across engineering, procurement and legal, no one is accountable for keeping it current, and it goes stale after the first release. MAP 4.1 expects approaches that are in place, followed and documented, which requires a named owner. Close it by assigning a single accountable role for the technology and legal map, with defined handoffs to procurement and the AI governance lead. Confirm the owner appears in the AI inventory entry for each system.
Fine-tuned models treated as original work
A model fine-tuned on a third-party foundation model inherits that model's license, usage limits and data provenance, yet teams often record it as internally built. The Generative AI Profile asks organizations to re-evaluate models fine-tuned on top of third-party models, which makes this inheritance a mapping item. Close it by recording the base model, its license and the fine-tuning data source on the derived model's entry, and re-checking those terms when the base model changes. Ask who signed off on the base model's license.
No review trigger when a vendor changes a model
Vendors update models, change data handling and alter release cadence without a new contract, so a mapping approved at purchase can stop matching what runs in production. The Playbook suggests reviewing vendor release and change management practices for this reason. Close it by requiring the vendor to notify the organization of material model changes, and by setting a review trigger in the change process for any such notice. Confirm whether the contract requires advance notice and what counts as a material change.
Evidence created only for the audit
Some programs produce a mapping spreadsheet just before an assessment and never update it during operations. Assessors and regulators look for records that match the system as it runs, including inventory exports, scan outputs and dated review notes. Close it by generating inventory and vulnerability evidence from the tooling on a schedule, and storing review decisions in the same system. Ask which records would still exist if the audit were cancelled.
Questions buyers ask about MAP 4.1 cost, effort and outsourcing
Is there an AI RMF certificate I can buy for MAP 4.1?
No. The NIST AI Risk Management Framework has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of it. What you can show is evidence that your MAP 4.1 approach is in place, followed and documented. If a customer or regulator asks for proof, an independent assessor can review that evidence against your own program, but the assessor's review is an opinion on your practice, not an AI RMF certificate. Ask any vendor who offers an AI RMF "certification" to explain exactly what is issued and by whom.
How long does a first MAP 4.1 mapping take, and what drives it?
The duration depends mainly on how many AI components you run and how many of them come from third parties. No researched figure is available for a typical timeline, so ask for one tied to your own inventory. The main drivers are the number of third-party models, datasets and software packages, whether licenses and vendor contracts are easy to retrieve, whether an inventory of software already exists, and how many business owners must confirm what each component does. Mapping goes faster when a current software and asset inventory already exists, and slower when teams must discover components by interview.
Can one internal team complete MAP 4.1 on its own?
A single team can start the work, but MAP 4.1 touches more than engineering. The Playbook tags it to third-party entities, procurement, operation and monitoring, and governance and oversight, so one group usually lacks the contract, license and operational context. A capable security or platform team can build the component inventory and draft the mapping. Legal, procurement and business owners then need to confirm terms, obligations and accountability. Many organizations decide with their implementation partner which parts their own staff can do and which need outside support, based on a written scope.
What does MAP 4.1 need from legal and procurement teams?
Legal and procurement own the evidence that sits outside your systems. The Playbook suggests reviewing third-party audit reports, testing results, warranties, terms of service and license agreements, along with vendor release and change management practices. Legal should review license terms and intellectual property exposure for models, datasets and open-source packages. Procurement should keep contracts, renewal dates and vendor notices in a place the mapping team can reach. Ask both teams to name an owner for each third-party component so the mapping stays current when contracts change.
Which parts of MAP 4.1 can be outsourced, and which must stay in house?
Outsourcing is useful for technical inventory and documentation, while accountability stays with your organization. Implementation partners can help set up inventory tooling, collect software bills of materials and prepare mapping documents. Legal opinions, risk acceptance decisions and vendor negotiations belong to your organization or your counsel. Independent auditors or assessors issue any assurance reports. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports or certifications. Agree the split in writing before work starts, so each deliverable has a named owner.
How often does the MAP 4.1 mapping need to be refreshed?
The mapping should be refreshed whenever a component changes and on a schedule your governance sets, since the framework does not fix a frequency. Trigger a review when you add or replace a model, dataset or package, when a vendor changes its terms, releases a major version or changes its own dependencies, or when a license changes. Generative AI guidance in NIST AI 600-1 also expects periodic monitoring of generated content for exposure of personal or sensitive data, which feeds back into the mapping. Confirm your review cadence with your risk owners and record it in your governance documentation.
How does MAP 4.1 differ from MAP 4.2?
MAP 4.1 maps the technology and legal risks of AI components, including third-party data, software, models and intellectual property exposure. MAP 4.2 covers the internal risk controls your organization applies to those same components, including traditional procurement, security and privacy controls. In practice, MAP 4.1 tells you what risk each component carries, and MAP 4.2 records which controls address it. Build the component inventory once and use it for both, so the controls in MAP 4.2 trace back to the risks identified in MAP 4.1.
How DeployOpen prepares MAP 4.1 evidence
DeployOpen helps organizations prepare the systems, inventories and documentation that show how technology and legal risks of AI components are mapped. The organization owns its risk decisions and contracts, and DeployOpen prepares the evidence and self-hosted tooling behind them. NIST AI RMF has no certification, so no independent party issues a MAP 4.1 certificate for this work.
How we scope
- Agree in writing which AI systems, components and third-party sources fall inside the MAP 4.1 scope before work starts.
- Define which third-party data, software and models need an inventory entry, and which legal documents must be collected for each.
- Confirm with your legal and procurement teams which license, terms and IP documents the evidence must reference, and who owns each.
How we build
- Deploy self-hosted inventory and software composition tooling inside your own cloud accounts, data centers or air-gapped networks.
- Configure OWASP Dependency-Track to track CycloneDX SBOMs and SPDX license IDs for each component in the AI system.
- Set up Trivy scans and GLPI or Wazuh asset records so third-party software and hosts appear in one reviewable register.
How we hand over
- Deliver a documented component register mapping each third-party dependency to its owner, license, source and review date.
- Provide written procedures for reviewing vendor audit reports, warranties, license terms and release and change management practices.
- Hand over runbooks and training so your team can keep the register current, with your independent assessor reviewing the evidence.
How we support
- Offer ongoing support as a retainer for upgrades, tooling maintenance and periodic refreshes of the component register.
- Support periodic reviews when license terms, model versions or vendor contracts change, updating the documented mapping.
- Confirm with your team which Playbook suggested actions for MAP 4.1 your organization adopts, and record the reasons for any it does not.
