Framework comparisons are usually written in the abstract, which is why they do not help. This one takes a single plausible agent and works through it.
The agent
Internal IT ticket triage. It reads incoming tickets, classifies them by type and urgency, assigns them to a queue, drafts a first response, and escalates what it cannot handle.
It has read and write access to the ticketing system, read access to an internal knowledge base, and it keeps context across tickets from the same requester.
Nothing exotic. This is close to what most organisations deploy first, because the work is high-volume, low-stakes and well-bounded.
Where the three frameworks agree
Most of the way, which is the useful headline.
All three want you to identify the system and its purpose, assess risk in context, define human oversight, monitor performance in operation, and keep records. NIST publishes a crosswalk mapping 71 AI RMF requirements to ISO 42001 clauses, so that overlap is documented rather than asserted.
If you have done the work once, you have done most of it for all three. The gaps below are the remainder, and they are worth knowing precisely because they are the part that will not already exist.
Gap 1: Annex IV technical documentation
The EU AI Act specifies a documentation structure: system description, design specifications, architecture, data requirements, validation procedures, and more.
Neither NIST nor ISO 42001 covers it. Both require documentation in general terms, and neither specifies this structure.
The practical consequence: a certified ISO 42001 management system does not produce an Annex IV file as a by-product. It produces the governance around the system. The technical dossier is separate work.
For the triage agent this means writing down the model and version, the prompt and tool configuration, what data flows in and out, what the escalation logic is, and how the whole thing was validated before deployment. Most teams have this knowledge distributed across people and never assembled.
Gap 2: automatic logging as a design requirement
This is the one that costs money if you find it late.
The Act does not simply require you to keep logs. It places a design obligation on the system to automatically generate records over its lifetime — the capability has to be built in.
NIST asks you to monitor. ISO 42001 asks you to keep records of the management system. Neither imposes a design requirement on the AI system itself.
For the triage agent, the difference is concrete. Monitoring is satisfied by dashboards showing throughput and accuracy. A design-level logging obligation means the system must record what it decided and on what basis, in a form that survives and can be produced later.
Adding that before you build is a configuration decision. Adding it to a deployed agent means changing how it runs.
Gap 3: Article 10 data requirements
Training, validation and testing data requirements, including examination for bias.
NIST asks you to consider bias, in the sense of making it a risk category you address. The Act tells you what to examine and what evidence to retain.
For an agent built on a general-purpose model rather than a trained one, this gap is narrower than it first appears — you are not training on your own data. It does not vanish: the examples in your prompt, the retrieval corpus and the escalation thresholds all encode decisions with the same character. A triage agent that systematically deprioritises tickets phrased a particular way is producing an outcome the Article is about, whether or not any training took place.
The part the frameworks do not do
Here is the pass that matters more, and it takes twenty minutes.
Run the same agent against the OWASP Top 10 for Agentic Applications, and ask which risks your control set actually mitigates.
ASI01, goal hijack. Tickets are text written by whoever opened them, arriving through a channel the agent trusts completely. An instruction embedded in a ticket body is read alongside its actual instructions. Does anything constrain what the agent can do after processing a hostile ticket?
ASI03, identity and privilege abuse. The agent authenticates to the ticketing system somehow. Under its own identity, or a shared service account? If a ticket was closed incorrectly last Tuesday, can you tell whether the agent did it, and on whose behalf?
ASI06, memory poisoning. It keeps context across tickets. That context is state that influences future decisions, and it is written to by the contents of tickets. Who can write to it, and would you know afterwards?
A complete, well-executed compliance mapping addresses none of those three directly. It will produce a risk register entry that says the risks were considered.
Why run both
The frameworks tell you what to document and how to govern. They are how you demonstrate to a customer, a regulator or an auditor that the system is managed.
OWASP tells you what will actually go wrong.
The organisations that get this wrong are not the ones that skip compliance. They are the ones that finish the compliance work, produce a genuinely good file, and treat the security question as answered because a control was named in a document.
Do the mapping. Then spend twenty minutes on the second pass, and expect the answer to be fewer risks covered than you would guess.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.