How does OWASP LLM09 misinformation map to compliance frameworks?

OWASP LLM09 misinformation lines up with three families of requirements: validity and reliability testing in the NIST AI RMF, accuracy declarations for high-risk systems in EU AI Act Article 15, and management system duties in ISO/IEC 42001. None of them names LLM09. You build the link by showing how you test, disclose and monitor accuracy.

This is a crosswalk for planning, not legal advice or an audit opinion. Whether the EU AI Act applies to a system depends on how it is classified, so confirm that with counsel.

What does LLM09 actually say?

OWASP defines misinformation as false or misleading information from an LLM that appears credible. Hallucination is a major cause, though biases and incomplete training data also contribute. A related problem is overreliance, where users trust output without checking it.

OWASP's examples include factual inaccuracies, unsupported claims, misrepresentation of expertise and unsafe code generation. Its listed mitigations are retrieval from verified sources, fine-tuning, cross-verification and human oversight, automatic validation of key outputs, risk communication, secure coding practices, interface design that labels AI content, and user training.

NIST AI RMF

The AI RMF is voluntary and built around four functions: Govern, Map, Measure and Manage. Several subcategories line up with the LLM09 mitigations.

• MEASURE 2.5 asks that the AI system to be deployed is demonstrated to be valid and reliable, and that limitations of generalizability beyond the conditions of development are documented. That is where your accuracy testing and your written list of known weaknesses live.
• MEASURE 2.4 asks that functionality and behavior are monitored in production. That fits sampling live answers for factual errors.
• MAP 3.5 asks that processes for human oversight are defined, assessed and documented. That fits the OWASP call for cross-verification and trained reviewers.
• MANAGE 4.1 covers post-deployment monitoring plans, including mechanisms for capturing user input, appeal and override, incident response and change management.
• GOVERN 6.1 addresses risks from third-party entities. If your answers depend on a model provider or a retrieval source you did not build, this is where that dependency is recorded.

Because the AI RMF is voluntary, there is no certificate. You show alignment with documents and records.

EU AI Act, Article 15

Article 15 applies to high-risk AI systems. It says they must be designed and developed to achieve an appropriate level of accuracy and cybersecurity, along with technical resilience, and to perform consistently in those respects throughout their lifecycle. It also says the levels of accuracy and the relevant accuracy metrics must be declared in the accompanying instructions of use, and that systems which continue to learn must address feedback loops that could bias future inputs.

For LLM09, the useful takeaways are the declaration and the lifecycle. If a system is in scope, you need to know your accuracy metric, publish it where the user will read it, and keep measuring after release. A chatbot with no stated accuracy and no monitoring is the opposite pattern. Many systems are not classed as high-risk, so Article 15 may not bind them, but it is still a reasonable yardstick.

ISO/IEC 42001

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. Its scope says it is for organizations that provide or use products or services that use AI systems, and that it helps develop, provide or use AI responsibly. It is a management system standard, so it does not tell you how to test for hallucination. It asks whether you have a defined process, owners, objectives and a review cycle, and whether you follow them.

Evidence for LLM09 would include a documented accuracy objective for each system, test results, a record of reviews, and corrective actions after bad outputs. Your auditor sets the exact expectations.

A short crosswalk

• Test for accuracy before release: NIST MEASURE 2.5, EU AI Act Article 15 for in-scope systems, and your 42001 objectives.
• Monitor in production: NIST MEASURE 2.4 and MANAGE 4.1, Article 15's lifecycle consistency, and 42001 monitoring and review.
• Human oversight: NIST MAP 3.5 and OWASP's cross-verification mitigation.
• Tell users the limits: Article 15's declaration of accuracy metrics and OWASP's risk communication.
• Third-party model and sources: NIST GOVERN 6.1 and your supplier controls under 42001.
• Unsafe code suggestions: your secure development practices, with dependency checks on anything a model proposes.

What to do

1. Pick an accuracy metric for each AI feature, with a method to measure it on a fixed question set.
2. Write the limitations in the same place users see the output.
3. Sample live answers weekly and log errors with a root cause.
4. Define who reviews answers in high-stakes flows, and train them on overreliance.
5. Record your model and retrieval providers, and what you do if one changes.
6. Review the mapping when your system, or its risk classification, changes.

Quick check

Sources

• OWASP Gen AI Security Project, LLM09:2025 Misinformation
• NIST, AI Risk Management Framework 1.0 (NIST AI 100-1)
• NIST, AI Risk Management Framework overview
• EU Artificial Intelligence Act, Article 15
• ISO/IEC 42001:2023 scope, as listed by Genorma

Last reviewed: 18 October 2026.