Mapping your company’s AI tool use to the NIST AI Risk Management Framework

Why this matters to you

Your 2-minute quick win

Open your company risk register or policy tracker and add one new line called AI systems inventory. In the owner field, enter the name of the person who can answer why each AI system is used and how personal data enters it. You are done when one named owner exists and the line is visible in the same place as your other governed risks.

Many firms can prove they use AI. Fewer can show how they manage its risk. That gap matters in regulated sectors.

The NIST AI Risk Management Framework gives you a structure for this work. It helps you move from ad hoc tool adoption to repeatable governance.

Even if your business is not based in the United States, the framework is useful. It gives clear buckets for roles, context, measurement, and management.

The CNIL guidance adds a strong EU lens. It explains what changes when AI development uses personal data and why that must be built in from the start.

That point is vital for enterprise teams. Regulators usually ask who decided the purpose, who chose the data, and what safeguards were applied.

If your answers live in emails, slide decks, and vendor forms, you do not have a usable control system. You have fragments.

This guide shows how to turn those fragments into a map. The map links each AI use case to purpose, role, legal basis, data need, and safeguards.

Once that map exists, you can align it to NIST AI RMF functions. Then you can show not only what is deployed, but how risk is handled over time.

What the framework helps you explain

NIST AI RMF is most useful as a common language. It lets legal, security, procurement, data teams, and business owners discuss the same system with the same labels.

That matters because AI risk is rarely owned by one team. A model can be bought by procurement, configured by IT, used by HR, and challenged by compliance.

The CNIL guidance supports the same discipline. It starts with a defined finality, then moves to responsibility, legal basis, and data minimisation.

Those steps fit well with an enterprise mapping exercise. They force each AI system to be described in plain terms before it is defended in policy terms.

What you are protecting

You are protecting people first. The CNIL stresses that training data can include personal data about real people and that its use creates risks for rights and freedoms, including privacy.

You are also protecting your organisation’s ability to justify decisions. A regulated company must explain why a system exists, what it does, and what data it needs.

In practice, your map should protect at least six things.

• Purpose clarity. The CNIL says an AI system using personal data must have a finality that is determined, explicit, and legitimate.
• Role clarity. You need to know whether your company is acting as controller, joint controller, or processor for a given system.
• Legal basis. If personal data is used, the processing needs a lawful basis under the GDPR.
• Data boundaries. The point of setting a finality is to limit what personal data is collected, stored, and used for training.
• Reasonable expectations. The CNIL says people should not be surprised by how their data is reused, especially when data is collected from public websites.
• Evidence of safeguards. You need records of the measures chosen to reduce risk, such as anonymisation, pseudonymisation, limits on memorisation risk, and routes for objections or erasure requests.

For large enterprises, there is a second asset to protect. It is consistency. Two teams using similar AI tools should not produce opposite answers about ownership, legal basis, or excluded uses.

A good map also protects procurement decisions. If a vendor offers a general purpose model, your map should state the intended capacities, foreseeable higher risk capacities, and excluded functions by design.

That approach follows the CNIL guidance for general purpose AI. It says the purpose cannot be defined too broadly as simply developing and improving an AI system.

Instead, the description should refer to the type of system, such as a large language model, computer vision system, or generative system for images, video, sound, or code, and to technically foreseeable functionalities and capacities.

What it costs you if you skip this

The first cost is confusion. Teams will describe the same AI service in different ways. One team will call it research. Another will call it production. A third will call it experimentation.

The second cost is weak accountability. If nobody can say who decided the purpose and means, you cannot cleanly identify the controller or processor role.

The CNIL makes that distinction concrete. If you determine the why and the how of personal data use, you are the controller. If you act on another party’s instructions, you may be the processor.

Without a map, that line is often guessed too late. By then, contracts, notices, and internal approvals may already be wrong.

The third cost is poor data discipline. A vague purpose leads to broad collection. Broad collection increases the chance of using personal data that is unnecessary or too intrusive.

The fourth cost is a legal basis that does not match reality. Consent may be named in a policy, while the real practice relies on data scraped from public sources with no direct relationship to the person concerned.

The fifth cost is weak protection against downstream harm. The CNIL points to measures that reduce memorisation and the chance of extraction or regurgitation. If you never map those risks, you rarely set controls for them.

The sixth cost is bad audit posture. Auditors and regulators tend to ask for linked evidence. They want to see the purpose, owner, data source, legal basis, safeguards, and review route tied together.

If that evidence sits in separate silos, your organisation looks less mature than it may really be. The issue is not only risk. It is explainability of governance.

Step by step

1. Create one master file called AI systems inventory. Put it in the same governed location as your policy library or risk register. Add columns named system name, business owner, supplier, purpose, deployment status, personal data used, role under GDPR, legal basis, safeguards, excluded uses, and evidence link. Done correctly looks like one live table where each row is one AI system or one distinct use case.

2. Fill the purpose column with a specific finality. Do not allow entries such as improving AI or innovation. For each row, write the operational aim or, for general purpose AI, the type of system and technically foreseeable functionalities and capacities. Done correctly looks like a sentence that a non specialist can understand and that is narrower than general improvement.

3. Add an excluded uses field and complete it for every row. The CNIL notes that excluded functionalities by design are a good practice for general purpose systems. Done correctly looks like clear lines such as not to be used for employee performance scoring or not to be retrained on customer support transcripts without separate approval.

4. Assign the GDPR role in a dedicated field. Use controller, joint controller, or processor. If another organisation decides the objective and the means with you, mark joint controller. If you process data on a client’s instructions, mark processor. Done correctly looks like one selected role per row, not a blank cell and not multiple roles for one single use case.

5. Add a linked contract or governance note for role evidence. For processor cases, link the data processing contract. For joint controller cases, link the arrangement that splits duties. Done correctly looks like a working link in the evidence column that opens the relevant document.

6. Record the legal basis in its own column. Use one of the GDPR bases named by the CNIL, such as consent, contract, legal obligation, public task, vital interests, or legitimate interests. Done correctly looks like one chosen basis and a short note that matches how the data is actually obtained and used.

7. If the basis is legitimate interests, add a three part note. The CNIL says the interest must be legitimate, the processing must be necessary, and the impact on privacy must not be disproportionate. Done correctly looks like three short fields completed for each of those points, not a simple yes or no.

8. Add a data source field and name the source type. State whether data comes from people directly, from a client, from internal records, from open data, or from publicly accessible internet sources. Done correctly looks like a specific source description rather than other or mixed.

9. For public web data, add a reasonable expectations check. The CNIL says reuse may fall outside reasonable expectations if collection does not exclude sites with restrictions such as terms of use, robots.txt, or CAPTCHA. Done correctly looks like a note that says whether such sources are excluded and where that rule is documented.

10. Add a safeguards field with named measures. Use measures the CNIL explicitly mentions where relevant, such as anonymisation at short notice, pseudonymisation, measures to limit model memorisation and reduce extraction or regurgitation, a discretionary and prior right to object, a discretionary right to erasure from the training set, and measures to identify people when they exercise rights. Done correctly looks like named safeguards tied to the actual use case.

11. Map each row to NIST AI RMF functions. Add four columns named Govern, Map, Measure, and Manage. In Govern, record the policy owner and approval route. In Map, record the context, purpose, actor roles, and likely affected people. In Measure, record how the team checks legal and operational assumptions. In Manage, record the decision, mitigation, and review cycle. Done correctly looks like each column containing concrete entries rather than empty placeholders.

12. Add an evidence link for each NIST AI RMF column. Link the policy, design note, privacy assessment, contract, or test note that supports the entry. Done correctly looks like no row progressing to production without at least one evidence link per function.

13. Sort the file by deployment status and finish the live systems first. Mark rows as proposed, pilot, active, or retired. Done correctly looks like every active AI use case mapped before new pilots are added.

14. Store the file where audit teams can find it. Put the file in your controlled compliance repository, not in a personal drive. Done correctly looks like a stable location, version history, and named access owners.

Illustrative example

Claire is Head of AI Governance at a European bank. Her problem is familiar. Different teams already use AI tools, but no one can show one joined up picture.

She starts with one spreadsheet called AI systems inventory in the compliance repository. She asks each business unit to submit one row for every AI tool and one row for every separate business use.

The retail team lists a support assistant that drafts replies for agents. The fraud team lists a model that helps detect suspicious behaviour. HR lists a summarisation tool used on internal policy documents.

Claire rejects the first draft because the purpose column is too vague. It says productivity, automation, and model improvement.

She sends it back with a rule. Each team must write a finality that is determined, explicit, and legitimate.

The retail team rewrites its row. It now says the system assists human agents by drafting suggested replies to customer account questions inside the service desk workflow. That is specific enough to govern.

The fraud team writes that its system helps detect fraudulent content and behaviour patterns. The CNIL gives fraud detection as an example of a legitimate interest that may be valid if the wider conditions are met.

Next, Claire adds a GDPR role column. The bank is controller for the support assistant because it decides why the system is used and how customer data enters the workflow.

For an external development project, the bank is a client and the vendor builds to the bank’s instructions. Claire marks that case as processor on the vendor side and controller on the bank side, then links the contract.

She then forces a legal basis entry. The fraud case uses legitimate interests, so the team must complete three extra cells. They explain the interest, why the data is necessary, and what safeguards reduce the privacy impact.

Because one pilot proposes public web data, Claire adds a source restriction note. The row cannot proceed unless the collection plan excludes sites with terms of use restrictions, robots.txt, or CAPTCHA controls.

She adds a safeguards column. The retail support tool includes pseudonymisation of training records and measures intended to limit memorisation and reduce extraction or regurgitation.

For rights handling, the bank adds a route for objections and a route for erasure requests from the training set where applicable. Claire links the procedure note in the evidence field.

Finally, she maps each row to the NIST AI RMF functions. Govern links to policy ownership. Map links to purpose, actors, and affected people. Measure links to the privacy and control checks. Manage links to approval status, safeguards, and review dates.

At the next internal audit meeting, Claire does not start with marketing slides. She opens the inventory and filters it to active systems. Each row shows purpose, role, legal basis, source, safeguards, and evidence in one place.

The outcome is not perfection. It is something more useful. The bank can now explain how it governs AI use case by use case, with a structure that can be updated.

The near-miss

In a replay of the same scenario, Claire skips the source restriction check for one pilot. The team says the data is public, so it must be fine.

The row enters the inventory with a broad purpose and a legal basis note that only says legitimate interests. No one records whether restricted sites are excluded.

Weeks later, compliance asks whether the collection respected reasonable expectations. Claire opens the row and finds no note about terms of use, robots.txt, or CAPTCHA.

The team then has to pause the pilot and reconstruct the collection logic after the fact. They cannot show a clear rule that limited what was gathered.

The concrete consequence is delay, rework, and a weaker governance story. The issue is not that the pilot used AI. The issue is that the key check was skipped before data collection moved ahead.

How to check it worked

Start with coverage. Compare the AI systems inventory against procurement records, software catalogues, approved vendor lists, and business unit declarations. The lists should reconcile well enough that active AI use is not hiding in side tools.

Next, test clarity. Pick five rows at random and ask the owner to explain the purpose in one sentence. If they cannot do that without drifting into vague claims, the finality field is too broad.

Then test accountability. For every active row, open the evidence link for role and legal basis. You should be able to see why the company is acting as controller, joint controller, or processor and why the chosen legal basis fits the real use.

After that, test data discipline. Look for rows with personal data marked yes but no safeguards listed. Those rows are incomplete.

Check public data cases carefully. If a row uses publicly accessible internet data, the evidence should show whether restricted sources such as terms of use limits, robots.txt, or CAPTCHA were excluded.

Check rights handling too. If the system uses personal data in development, there should be a route for notices, objections, or erasure where applicable and a way to identify the person making the request.

Finally, check NIST AI RMF alignment. Every active row should have entries for Govern, Map, Measure, and Manage, plus at least one evidence link per function.

If a row has only purpose and supplier fields, you do not have framework mapping. You have an asset list.

Test yourself

Question: Why is a vague purpose like general AI improvement not enough?

Answer: Because the CNIL says the finality must be determined, explicit, and legitimate, and broad wording does not set clear data limits.

Question: What extra check is needed when data comes from public websites?

Answer: You should record whether collection excludes restricted sources such as terms of use limits, robots.txt, or CAPTCHA.

Question: What shows that an AI inventory is mapped to NIST AI RMF rather than just listed?

Answer: Each active row has concrete entries and evidence for Govern, Map, Measure, and Manage.

Common mistakes

Using one row for one vendor instead of one use case

A single vendor can support many uses with different risks. Mapping by vendor alone hides purpose, data source, and legal basis differences.

Writing a purpose that is too broad

The CNIL explicitly warns against defining the purpose as simply developing and improving an AI system. Use the type of system, foreseeable capacities, and intended operational use instead.

Forgetting that role depends on facts

Teams often label themselves processor because a client is involved. The CNIL notes that if you decide the objective and the means, you may still be the controller.

Choosing a legal basis first and checking the facts later

That reverses the order. Start with the actual data flow and use context, then record the lawful basis that fits.

Treating public data as risk free data

The CNIL makes clear that public accessibility does not remove privacy duties. Reasonable expectations, source context, and restrictions still matter.

Listing safeguards as generic security words

Do not write secure by design and stop there. Name the actual measure, such as pseudonymisation, anonymisation at short notice, or measures to reduce memorisation and extraction risk.

Calling an AI list a governance map

A true governance map links purpose, role, legal basis, data source, safeguards, evidence, and review state. A plain inventory does not.

Level up

Add one more field to your inventory called deployment route. For each general purpose AI system, state whether it will be open source, commercialised, made available as SaaS, or exposed by API, because the CNIL lists these as useful conditions of use when refining the objective of a system.