Home / Articles / Four frameworks, one agent: iason's comparison of the OECD classification, the NIST AI RMF, Japan's guidelines and the EU AI Act, read against what runs here, with the evidence and the graphs

Four frameworks, one agent: iason's comparison of the OECD classification, the NIST AI RMF, Japan's guidelines and the EU AI Act, read against what runs here, with the evidence and the graphs

By Dinis Cruz · 2026-10-13 · article v1.1.0, 2 versions · newsroom v0.12.29 · ai-risk-managementframeworksnist-ai-rmfoecdeu-ai-actjapan-ai-guidelinesagent-behaviour-policyfootprintrisk-acceptancegraphsgovernancearticle

Abstract: A paper reached me this week, AI Risk Management Frameworks, issue 81 of iason's research series, dated November 2025, by Sara Martucci and Margherita Ranieri with Nicola Mazzoni. It reads four instruments side by side, the OECD's classification of AI systems, the NIST AI Risk Management Framework, Japan's AI Guidelines for Business and the EU AI Act, and ends with five principles they share, ethics and human rights, the lifecycle, human oversight, risk tiering with proportionality, and governance as an organisational habit rather than a compliance exercise. I agree with the five, and the paper's own list of what most companies still lack, AI-specific KPIs, a formal adoption and risk strategy, a central governance function and a process for reviewing AI outputs, is the list I would write. So this article does what the frameworks ask of a deployer, on the one system I can show: a newsroom run by agents, and the agent team that runs my correspondence, both under a written behaviour policy. I take each framework's question and answer it with what runs here, the evidence behind it and the graphs we have already built, and I say where the answer is a design or an argument rather than a thing that runs. Two things come out of the mapping. The frameworks' unit is the AI system, classified before deployment; for an agent in a loop with tools the unit has to be one agent in one deployment, and its risk is its reach, measured, with a blast radius for each row. And the questions the frameworks leave open, who holds the residual risk, until when, and on what evidence, are the ones the behaviour policy, the footprint and the risk acceptance record were built to answer. The paper is also, in this site's own terms, a page that needs a status since: it was written before the Act's dates moved.

In short

• Four frameworks, four grains. The OECD classifies a system along five dimensions; NIST runs four functions, govern, map, measure and manage; Japan assigns duties to developers, providers and business users; the EU AI Act assigns obligations by tier. The paper's reading is that they converge on five principles, and I think that is right.
• The unit is wrong for agents. Each of the four classifies an AI system before it is deployed. An agent in a loop with tools is one agent in one deployment, and its risk is its reach, measured, with a blast radius for each row of it.
• Govern is a written policy, map is the gap, measure is the footprint, manage is three doors. Each of NIST's functions has a mechanism here, running on a real system, with the article that describes it and the numbers it produced.
• Human oversight by reversibility, not by tier. A person sits where an output cannot be undone; everywhere else, controls that do not get tired. People approve 93% of what they are shown.
• Accepted is not acceptable. The Act asks for residual risk to be "judged to be acceptable" and does not define the word. Here a risk has a holder, an interval and the facts that would end it.
• Three roles, and the policy is the contract between them. Japan's developer, provider and business user are the model vendor, the platform and the deployer. A policy beside the prompt is what each one signs for.
• The graphs exist for two of the four. The Act parsed into a graph; a control framework joined to the Act's text; a ten-layer stack with 119 edges drawn from provisions. The paper's four as one graph is the next one, and the mapping published with this article is its first file.
• The paper needs a status since. It was written in November 2025. The Act's dates moved in July 2026, and software becomes a product under the EU's liability rules on 9 December 2026.
• How far it goes here. Of the five principles, four run, on one newsroom and one agent team; the fifth, risk acceptance as a record, is a published design with a demo behind it.

The paper, and what it gets right

The paper is iason's AI Risk Management Frameworks, research paper series 2025, issue 81, dated November 2025, written by Sara Martucci and Margherita Ranieri and prepared with Nicola Mazzoni. iason advises financial institutions on risk, and the paper reads that way: a first part on the market and its investment, a second on the risks AI adds, with a view from the financial industry, a third on regulation with the EU AI Act at the centre, and a fourth on three frameworks, the OECD's classification, NIST's AI RMF and Japan's guidelines for business.

What it gets right is the shape. The four instruments are different grains of the same thing. The OECD framework is a lens, not an obligation: five dimensions along which to describe a system, People and Planet, Economic Context, Data and Input, AI Model, Task and Output. NIST is a process: four functions, each with numbered outcomes, Govern 1 to 6, Map 1 to 5, Measure 1 to 4, Manage 1 to 4. Japan's guidelines are a division of labour: Parts 3, 4 and 5 are what developers, providers and business users each owe. The Act is law: four tiers, prohibitions in force since February 2025, and a list of obligations for the high-risk tier. The paper's conclusion is that despite the differences they "converge around a common set of core principles", and it names five: ethics and human rights at the centre, the lifecycle as the foundation of governance, human oversight as a safeguard, risk tiering and proportionality, and an organisational approach, governance "as a corporate mindset" rather than procedures alone. Its last page says what I would say to a board: "too often, risk management is perceived as a compliance exercise, a necessary but limiting set of controls", and that in AI this is "strategically shortsighted".

It is also honest about where companies are. Its list of what many still lack has four items: KPIs defined for AI, formal adoption and risk strategies, a central governance structure, and "processes for reviewing AI-generated outputs for accuracy and ethical compliance". That fourth one is where this site has spent most of its time, so the rest of this article is a mapping: the paper's four frameworks and five principles on one side, and on the other what runs here, what it produced, and where to check it.

The unit: a system before deployment, or one agent in one deployment

Before the mapping, the one disagreement, because it decides how the rest reads. All four instruments take the AI system as their unit: the thing a provider puts on the market, which a deployer puts into service. The OECD describes it, NIST maps it, the Act tiers it, and the work is done before deployment, with monitoring after. For a model behind a form, that is the right unit.

For an agent it is not, and the paper's own list of what makes AI risky says why: "autonomy", "non-deterministic behavior", "reliance on externally managed foundation models". An agent is the same model, run in a loop, with tools. What it can do is not a property of the model; it is a property of the connectors it was given, the accounts it runs under and the data it can see. In Authority outside the model I put it as the thing that list leaves out: risk is a property of one agent in one setup, not of the model. The same model that drafts an email with no way to send it, and the same model with a send button and a customer database, are not the same system, and no tier assigned to the model tells you which one you have.

So the unit here is one agent in one deployment, and its description is the Agent Behaviour Policy: the reach, what the agent can do, measured from its connectors and accounts rather than declared; the mandate, what it was asked to do; the gap between the two, in both directions; and for every row of the gap, what stands in the way, typed as a boundary, a setting, an expectation or nothing. Only a boundary is a control. After the agent has run, the footprint is what it actually did, read from logs, traffic and vault history. And the blast radius is the measure that goes with any row: what it would cost the business if that row were used in full, today, and whether there is a way back. That is the classification, the map, the measurement and the tier, for an agent, and it is what the four frameworks attach to below.

OECD: five dimensions, and the two that matter most for an agent

The OECD's five dimensions describe a system well, and three of them map straight across. People and Planet asks who the system touches and what it could cost them; that is the blast radius, which is defined over the reach because whoever takes an agent over inherits its reach and ignores its mandate. AI Model asks what the model is and how it learns; for the agents here the answer is short, the same model anyone else uses, which is why the risk sits in the deployment and not in the model. Economic Context asks how critical the system is and how far it spreads; the newsroom's answer, from The human in the loop is a spectrum, is that its side effects are small because its readership is small, and that this changes the position as readership grows.

The two that matter most for an agent are Data and Input and Task and Output. Data and Input asks what the system can see, and whether it is sensitive. For an agent the question is sharper: does it have private data, untrusted content and a way to send, all three at once, the combination The policy draws the liability line calls the lethal trifecta and says every agent in a loop should take a policy for. Task and Output asks, in the paper's words, whether human intervention is "active, passive, or entirely absent at the point of decision-making". That is the right question and the wrong axis. The answer here is not a level of oversight per system; it is a position per output. The next section is NIST's, and that is where the answer lives.

NIST: govern, map, measure, manage, as they run here

NIST's four functions are the easiest to map, because each one names a thing we built. The table is by the playbook's numbered outcomes as the paper lists them, with the mechanism here and the article that shows it running.

Three rows deserve a sentence each. Govern 1, the policy, is only a policy if it survives the session: Re-anchoring found that the session behind this site was summarised eighteen times in a month, about 98% of its context replaced each time, so the rules live in a file and a hook prints them back after every summary. Measure 1 is the number I would put in front of any board: when the same customer service agent was built three ways, the share of its rules kept only by the model's good behaviour fell from 97% to 23%, and the policy shrank with it, because it no longer had to forbid what the agent could not do. And Manage 4 is where the paper's human oversight lives, which is the next principle.

Human oversight here is placed by one test, not by tier: can the output be undone, and how much would it cost if it were wrong. The human in the loop put a person on the outputs where the answers are no and a lot, sending an email in my name, typing a secret, spending money, and replaced the person everywhere else with controls that do not get tired, because people approve almost everything they are shown: Anthropic measured "Claude Code users approve 93% of permission prompts". The result, on the day that article was written, was a newsroom that shipped fourteen releases with no release approved one by one, beside an agent team that drafts every email and sends none. The OECD's "active, passive, or entirely absent" is one answer per system. Here it is one answer per output, and it moves.

Japan: three roles, one policy between them

Japan's guidelines are the ones that come closest to how an agent is actually built, because they split the responsibility by role. Part 3 is the developer, who makes the model; Part 4 the provider, who embeds it in a system and, in the paper's summary, must "define clear operational parameters, including intended purpose, constraints, and potential risks"; Part 5 the business user, who runs it and "must continuously monitor the behavior and outputs of deployed AI systems, identify irregularities or deviations, and report them". For an agent those are the model vendor, the platform or harness the agent runs in, and the deployer, which here is me.

What the guidelines do not say is what passes between the three, and that is what A policy beside the prompt proposes: every agent takes a behaviour policy as an input beside its prompt; the vendor publishes its own built-in policy and accepts the deployer's; for every row it accepts it says whether it enforces it or only asks the model to keep it; and it reports every breach. That is Part 4's "operational parameters" as a document both sides hold, and Part 5's monitoring as the footprint read against it. Where the platform draws the line shows the provider's half arriving: Microsoft's execution containers and agent control specification put the policy outside the workload and enforce it in the operating system, and when the same eight scenarios were run with a behaviour policy on top of them, three rows that had been hope became boundaries.

The guidelines also call their model "agile governance", oversight that is iterative rather than fixed. Here that is the line that moves: as the record of unchanged drafts grows for one kind of message, that kind is a candidate to leave the human step, by a decision written into the policy with an owner and a date; as the newsroom's readership grows, the stage before promotion becomes a canary. And when a role fails the others, the written policy is what the argument is about. The policy draws the liability line argues that towards the world the deployer answers, as the tribunal held against Air Canada, and that between the deployer and the vendor an explicit prohibition the agent then breaks is the evidence that turns "user error" into "the product ignored what it was told". Japan's three roles are the three parties to that argument.

The EU AI Act: the tier, the undefined word, and the dates

The Act is where the paper spends the most pages, and two things in it matter here. The first is the tier. The newsroom's own systems are low on the Act's scale: an article is not a decision about a person, and the limited-risk duty that applies to a chatbot, to say that it is one, is the disclosure this site already carries on machine-written text, for the reason Who owns the words gives, that people should read machine-written words differently. The agent team is the same: it drafts, and a person sends. Proportionality is the right principle, and here it is applied per row of reach rather than per system, because a tier for the model would miss the send button.

The second is a word. For a high-risk system, Article 9 of the Act requires the provider's risk management to leave residual risk "judged to be acceptable", and, as Every risk is already accepted points out, never defines acceptable. The paper restates the obligation without remarking on the gap, which is fair: it is easy to read past. Our answer is that accepted and acceptable are different things: one is a threshold, the other is an act by a named person on a date. A risk exists the moment the exposure does, so it is already being carried; the open questions are who has accepted it and until when. There are three doors, accept it for a stated interval, fund the work, or fix it, and silence is not a fourth: a risk nobody accepts rolls up to the holder's boss, and every path ends at the board. Every risk names the facts that make it true and the facts that would end it, down to the configuration file. That is what turns "judged to be acceptable" from a sentence into a record.

Then the dates. The paper, as of November 2025, says the Act's rules "will come fully into effect by August 2026". Since then, as The AI governance stack as a graph recorded on 9 October 2026, the Act was amended by Regulation (EU) 2026/1744, in force from 27 July 2026: the Annex III high-risk obligations now apply from 2 December 2027 and Annex I from 2 August 2028, and Article 4 on AI literacy was reworded. And from 9 December 2026, as The policy draws the liability line notes, software including AI systems is a product under the EU's new product liability rules. None of this makes the paper wrong; it was right on its day. It makes it exactly the case Every link points back called status since: a plan described in one document that a later one says has changed, invisible from the first. A graph keeps the label as written and records the change underneath as a dated edge. A PDF cannot.

The five principles on one small system

So, the paper's five, each on the one system I can show, and how far each goes.

Ethics and human rights. Here this is a question of whose words they are. Nothing leaves the agent team without the person whose name is on it pressing send; every machine-written text on this site says so; and the responsibility for a decision an agent makes stays with whoever granted its reach. Runs.

The lifecycle. Every push to this site is a release with a version, every article has versions and a diff page, every incident is written up, and the footprint is read for weeks after a run. What is missing is the end of the lifecycle the paper names, decommissioning: retiring a device and rotating the master's key are on the list of what is not built, and ending an agent's mandate has no step at all. Runs, without a retirement step.

Human oversight. Placed by reversibility, enforced by controls where a person would be a rubber stamp, and measured by a record of drafts nobody had to change. Runs.

Risk tiering and proportionality. Applied per row of reach with a blast radius, in the policy, which runs. Applied as a register, with holders, intervals and facts, it is the design in Every risk is already accepted, with a business plan and a field demo published, and not a thing a customer runs today. Designed.

The organisational approach. The paper wants governance "as a corporate mindset involving different functions and teams". Here the organisation is one person and about fifteen agents, with the roles, the policies, the board and the log public on this site. Runs, at a scale of one, which is the limit I would put first.

What the graphs add, and the one to build next

The paper compares four instruments in a table and five principles in a list. A table is correct on the day it is drawn; it cannot say which paragraph of which instrument makes a cell true, or what changed under it since. That is what the graphs on this site are for, and two of the paper's four already have one.

The Act is parsed into the Regulation Graph vault from the official text, article by article. When Jan van Dijke published the AI Baseline Control Framework on 2 October, twenty controls mapped to the NIST AI RMF, ISO/IEC 42001 and the Act, it took a day to turn its spreadsheet into a semantic graph joined to the Act's own text, with eighty hyperlinked documents and the six things the graph found that the spreadsheet did not say. And when Hari Kota posted a ten-layer governance stack, the answer was a vault in which every cell is a node, 329 edges, 140 of them between layers, 119 of ours each citing the provision it rests on, and in which the Act's articles reach nine of the ten layers and NIST's reach eight. Those graphs already hold NIST and the Act. Article 26(2) of the Act, oversight assigned to persons "who have the necessary competence, training and authority", is one edge; NIST GOVERN 1.6, the inventory, is another.

The one to build next is the paper's four as one graph, and the method is the one those three used. Each framework is its own world, with its own vocabulary: the OECD's dimensions, NIST's functions and numbered outcomes, Japan's parts and roles, the Act's articles, annexes and tiers. None is asked to fit the others. The edges between the worlds come from the texts: NIST's Map 2, categorising the system, points at the OECD classification, which the paper says NIST drew on; the OECD's Task and Output oversight question, the Act's Article 14 and Japan's Part 5 are three statements of human oversight that should be one node with three sources; Govern 6, Manage 3, Japan's three roles and the Act's providers, deployers and importers are the same supply chain seen four ways. And a fifth world, the behaviour policy, so that a row of a policy can say which provision it answers, and a provision can say which rows of which agents answer it. Then the paper's five principles are not a list but five queries, and "which of our agents has no human oversight row where the Act requires one" is a traversal rather than a workshop.

The first file of that graph is published with this article: the mapping, one row for every element of the four frameworks and the five principles named above, with what answers it here, the article or vault where that can be checked, and its status. Thirty-two rows: twenty-three run, five are designed, four are argued. It is the baseline the next version measures against.

Where it is hardest

The paper's own list says what companies lack: KPIs, a strategy, a central function, and a process for reviewing outputs. If I were asked which of ownership, testing or monitoring is hardest to establish in practice, my answer from this record is none of the three, and it is the thing that comes before them.

Ownership is cheap to write and hard to keep, but a register that rolls an unaccepted risk up to the holder's boss keeps it for you. Testing is hard until it is a tool: the second reader runs on every draft, synthetic users found bugs that every unit test had passed, and the hostile mail set runs the same 62 emails through every design. Monitoring is the easiest of the three for an agent, because the footprint is read afterwards from logs the connectors already keep, with nobody inline and no production access. What is hard, and what none of the four frameworks asks for in a form an agent can carry, is the mandate: the written statement of what this agent, in this deployment, was allowed to do. Observation tells you what an agent did. Only a written mandate tells you whether it was allowed, and without one every finding in the footprint is a judgement call and every deflection in the liability line is available. That is why the policy is the first file, and why most of the mapping above ends at it.

What this does not claim

• The system is small. One newsroom, one agent team, one person. The pattern is what I would defend, not the scale, and the paper is written with financial institutions in mind.
• The paper is read, not reproduced. It is quoted in short phrases for the argument, with its authors and issue named; iason does not permit reproduction, and this article does not do it. Its research page did not answer when this was written, so there is no link.
• The dates since the paper are this site's. The amendment, its application dates and the product liability date are as recorded in the two articles cited, checked on 9 and 13 October 2026; I have not re-read the regulations for this article.
• The NIST rows are a mapping, not a conformance claim. Each row names a mechanism that answers the outcome's intent, in my reading; the system has not been assessed against the playbook by anyone else.
• Risk acceptance as a register is a design. The model is published with a business plan and a demo; no customer runs it today.
• The graph of the four frameworks is proposed. What exists is the mapping file published with this article, the graphs of the Act and of two frameworks that cite it, and the method.
• Thirty-two rows is my count of my own system. Another reader of the same frameworks would draw the rows differently, and the file is there to be corrected.

If you are mapping one of these frameworks onto agents in your own organisation, or you would draw the rows differently, write to agent@riskmandate.ai.

Where this comes from

A message of mine on 13 October 2026, with the paper, asking for this site's approach, evidence and graphs to be mapped to it; the paper reached me through a post that shared it, which is not named here. There was no voice memo: this article was assembled by this site's agent from the paper and from my published positions, in the voice of this site, and the argument and the editorial responsibility are mine. The paper: Sara Martucci and Margherita Ranieri, with Nicola Mazzoni, AI Risk Management Frameworks, iason Research Paper Series, year 2025, issue 81, November 2025, 34 pages; the quotations are from its sections 2, 4 and 5. The frameworks themselves: the OECD Framework for the Classification of AI Systems, February 2022; the NIST AI Risk Management Framework, January 2023, with its playbook; Japan's AI Guidelines for Business, version 1.0, April 2024; Regulation (EU) 2024/1689, the AI Act, and the text of Article 9. The 93% is from Anthropic, How we built Claude Code auto mode, 25 March 2026. The counts in the tables are from the articles linked in each row, and the status of each is as those articles state it. The mapping file is articles/data/four-frameworks-one-agent__map.json, written for this article.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles