Applying the NIST AI Risk Management Framework and ISO 42001 in a Law Firm

NIST AI RMF and ISO 42001, briefly

The NIST AI RMF is a voluntary US framework organizing AI risk into four functions: Govern (set policy and accountability), Map (identify context and risks), Measure (assess and track them), and Manage (act on them). ISO/IEC 42001 is a certifiable international standard for an AI management system, the AI equivalent of ISO 27001 for security. One is a flexible framework; the other is an auditable management system ^[1][2].

The two are complementary rather than competing. The NIST AI RMF, released in January 2023, is voluntary and flexible: it does not certify anything, but it gives a common structure for thinking about AI risk through its Govern, Map, Measure, and Manage functions. Govern sits at the center, establishing policy, roles, and accountability that the other three functions operate within.

ISO/IEC 42001, published in December 2023, is the first international standard for an AI management system, and unlike the NIST framework it is certifiable, meaning an accredited auditor can assess conformance. It defines a managed, auditable process for how an organization develops, provides, and uses AI, in the same family as ISO/IEC 27001 for information security.

For a firm, the practical difference is intent. Use the NIST AI RMF as the thinking tool that structures your program, and treat ISO/IEC 42001 as the target if you ever want an external certification to show clients or insurers. Most firms start with the former and grow toward the latter only if the market demands it.

Mapping the frameworks to your ethics obligations

The frameworks map cleanly onto duties you already hold. Govern aligns with the supervision duty under Model Rules 5.1 and 5.3; Map aligns with competence under Rule 1.1, understanding the tools you use; Measure and Manage align with the confidentiality duty under Rule 1.6, tracking and controlling how client data is exposed. Framed this way, adoption is formalizing existing obligations, not adding new ones ^[3].

The fastest way to make these frameworks concrete for a firm is to stop treating them as foreign and map each function to the Model Rule it already serves. The table below does that.

A phased adoption path for a firm

Adopt in three phases. Phase one is Govern: write an AI policy, name an owner, and inventory the tools in use. Phase two is Map and Measure: classify each tool's data exposure and confidentiality risk. Phase three is Manage: apply controls, log use, and add incident response. A small firm can complete phase one in weeks and mature through the others rather than attempting everything at once.

Trying to stand up a full AI management system in one project is how firms stall. Phase the work so each stage delivers something defensible on its own.

Phase one, Govern, is the foundation and the fastest win: a written AI policy, a named person accountable for it, and an inventory of the AI tools actually in use. Our guide on building a defensible AI policy covers the policy itself. Phase two, Map and Measure, classifies each tool by what data it touches and how much confidentiality risk it carries, which is where the audit work from a firm-wide AI inventory feeds in. Phase three, Manage, applies the controls: access rules, usage logging, vendor requirements, and an incident-response plan.

Because these frameworks are voluntary for a firm, you set the depth. The value is not a certificate; it is that each phase makes an existing duty operational, and the sequence lets a firm show steady, documented progress rather than an all-or-nothing effort.

What to document at each phase

Document enough to show the program is real: in Govern, the written policy and the accountable owner; in Map and Measure, the tool inventory and a risk classification per tool; in Manage, the controls applied, the usage log, and the incident-response plan. The documentation is both the governance and the evidence, because a framework you followed but cannot show is indistinguishable from one you skipped.

The documentation is not bureaucracy for its own sake; it is what converts a governance intention into something a client, insurer, or regulator can credit. Keep it proportionate to the firm, but keep it.

In the Govern phase, retain the written AI policy and a record of who owns it. In Map and Measure, keep the tool inventory and the risk classification you assigned to each tool, including which handle privileged data. In Manage, document the controls you applied, the log of AI use, and the incident-response plan, along with evidence that the plan has been tested. Where the program touches how AI acts on client matters, tie the documentation to the specific tools, which is where the agentic AI governance gap becomes concrete.

A living set of these documents is what an ISO/IEC 42001 auditor would look for and what an insurer increasingly asks about, so building them during adoption serves both the duty and any later external review.

Where a small firm can stop and still be defensible

A small firm can stop after Govern and a light Map and Measure and still be defensible: a written AI policy, a named owner, a current tool inventory, a basic risk classification, and a simple usage log. Full ISO/IEC 42001 certification is optional and market-driven, not a duty. The defensible minimum is showing you know your tools, control your client data, and supervise their use.

Not every firm needs the full framework, and pretending otherwise is how good governance gets abandoned as too heavy. The honest floor is lower than the frameworks imply, because most of their weight targets AI builders.

For a small firm, a defensible program is a written policy, a named owner, a current inventory of the AI tools in use, a basic classification of which tools touch privileged data, and a simple record of use and any incidents. That set demonstrates competence, confidentiality control, and supervision, which are the duties that actually bind you. Scale up toward ISO/IEC 42001 certification only if clients, insurers, or your own risk appetite call for it.

The goal is proportion. A frame that is right-sized and actually maintained protects the firm and its clients far better than an enterprise program that looks impressive on paper and is never kept current.

Deployer, not developer: why most of the framework does not apply to you

Both frameworks were written with AI builders in view. A law firm almost always deploys tools others built, which makes large parts of each framework inapplicable rather than deferred. Knowing which parts you can set aside is what separates a governance program a firm will maintain from one it abandons as unmanageable ^[1][2].

The most common failure in law firm AI governance is not neglect. It is a firm reading a framework designed for organizations that train and ship models, concluding the program is enormous, and doing nothing.

Much of the NIST AI RMF's substance addresses questions a deployer cannot answer: training data provenance, model architecture decisions, bias testing of the underlying system, and validation of model performance across populations. A firm licensing a commercial drafting tool has no access to any of that and no ability to change it.

What remains for a deployer is genuinely smaller and entirely actionable. Which tools are in use and who authorized them. What categories of client data may enter each one. Who is accountable when something goes wrong. What the firm does when output is wrong. Whether people using the tools understand their limits. That is a real program, and it maps to duties the firm already carries under ABA Formal Opinion 512 rather than to obligations the frameworks invent ^[3].

The deployer framing also redirects one question outward. Where a firm cannot assess model-level risk itself, the framework's demand becomes a procurement demand: require the vendor to show its own governance, its audit posture, and its AI management program. The firm is not excused from the risk; it discharges the obligation by contracting and verifying rather than by testing a model it cannot see.

Read that way, ISO/IEC 42001 becomes most useful to a firm as a vendor-evaluation vocabulary rather than as a certification target. A vendor holding it, or documenting a program against it, is telling you something checkable about how it manages AI risk ^[2].

What makes a governance program survive its first year

A program fails between the policy and the practice. The three things that keep one alive are a named owner with actual authority, a review cadence tied to events rather than to good intentions, and an inventory that updates when tools change. Without those, a firm ends up with a current document describing a program nobody runs.

Most abandoned governance programs were not badly designed. They were designed once, adopted, and then not touched, while the tools they described kept changing underneath them.

A named owner is the first requirement, and the name has to belong to a person rather than a committee. The owner needs enough authority to say no to a tool, which is the test of whether the role is real. If the answer to "who decides whether we adopt this" is nobody in particular, the policy is descriptive rather than governing.

A review cadence works better when tied to events than to the calendar. An annual review will slip. A rule that any new AI tool requires an inventory entry and a data classification before use, and that any incident triggers a review of the relevant control, fires when something has actually changed and is therefore worth doing.

The inventory is where programs quietly die. A tool list assembled once and never updated becomes actively misleading, because it reads like knowledge while describing a state of the world that has passed. Tie inventory updates to the events that change it: procurement, a new integration in an existing product, and departure or role change for anyone who administered a tool.

The point is not to build toward certification. It is to be able to answer, on any given day, which tools the firm uses, what client data they touch, who approved them, and what happens when they are wrong. A firm that can answer those four questions has a defensible program, whatever it is called ^[3].