Taxonomy-Driven Analysis of Open-Source AI Risk Mitigation Tools

Afreen Alam; Ana Gjorgjevikj; Dimitar Trajanov; Evgenija Popchanovska; Irena Vodenska; Lubomir T. Chitkushev; Maryan Rizinski

REVIEW 3 major objections 4 minor 22 references

Taxonomy-Driven Analysis of Open-Source AI Risk Mitigation Tools

T0 review · 3 major / 4 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that an LLM-assisted mapping protocol can reliably map 21 open-source AI risk-mitigation tools to a 32-category risk taxonomy, and that the resulting matrix shows dense technical coverage but near-empty governance, legal…

desk verdict A useful 21x32 tool-risk mapping that is undercut by a partly circular validation and a coverage-gap finding that is partly built into the tool-selection criteria. read the letter →

arxiv 2608.07446 v1 pith:V3YUES2V submitted 2026-08-07 cs.SE cs.AIcs.CY

Afreen Alam , Evgenija Popchanovska , Ana Gjorgjevikj , Maryan Rizinski , Lubomir T. Chitkushev , Irena Vodenska , Dimitar Trajanov This is my paper · ORCID

classification cs.SEcs.AIcs.CY

keywords AIriskmitigationtaxonomyopen-sourceLLMtoolstoolcapabilitymappingretrieval-augmentedgenerationevaluationandguardrailsgovernanceenterprisemanagementtaxonomy-drivenanalysis

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Enterprises moving LLM applications from pilots to production need to know which open-source tools actually mitigate which risks, but the tools are documented in engineering language that does not line up with risk taxonomies. This paper tries to close that gap by mapping the code-level capabilities of 21 prominent open-source evaluation, guardrail, red-teaming, and observability tools onto the 32 subcategories of an extended AI risk-mitigation taxonomy. Its central claim is that an LLM-assisted, retrieval-augmented reading of each repository can act as a scalable substitute for full manual review, achieving a 75.5% F1 score against a three-reviewer consensus, and that the resulting Tool×Risk matrix reliably shows where tool coverage clusters and where it is empty. The matrix shows dense coverage of technical and operational controls and near-empty coverage of governance oversight, legal and regulatory remedies, and financial and market interventions, which the paper uses to argue that no purely technical stack can provide end-to-end assurance and that a layered architecture with human and institutional layers is needed.

What carries the argument

The load-bearing object is the 21×32 Tool×Risk capability matrix, populated by a three-prompt LLM-assisted retrieval-augmented protocol. The protocol's engine is a chain of prompts: an anchor prompt enforcing a strict auditor persona with a "code-only" rule (a capability counts only if it would still exist with all documentation removed), an extraction prompt that records explicit or derived mappings with citations to concrete functions, classes, or metrics and writes explicit true negatives, and a synthesis prompt using a deterministic left-join rule that keeps every taxonomy row and tool column even when empty. This machinery converts loosely documented developer tools into an auditable coverage map and also produces the validation set used to score the pipeline against human consensus.

What would settle it

Run a fresh validation on a different stratified sample in which reviewers see only raw repository content, never the LLM-produced capability summaries; if the consensus labels change enough that the pipeline's F1 drops well below 75.5%, the claimed reliability is not independent of the system being tested. Separately, repeat the cohort selection without the functional-relevance criterion; if governance-oriented open-source tools can be found and they fill the currently empty governance, legal, and financial cells, the central 'skewed landscape' result would be shown to be partly an artifact of the inclusion criteria.

Watch

Extended reading notes

Core claim

Using a three-prompt chain that first anchors a strict "code-only" auditor persona, then extracts per-tool capabilities with mandatory citations to implementation artifacts, and finally synthesizes a master Tool×Risk matrix by a left-join against the taxonomy, the paper produces a 21×32 coverage map. On a stratified 25% sample of 168 cells, three independent reviewers reached moderate agreement (Fleiss' κ = 0.509), majority vote was treated as ground truth, and the LLM pipeline scored 84.5% accuracy, 78.4% precision, 72.7% recall, and 75.5% F1. The resulting landscape shows that evaluation and red-teaming tools converge on model alignment, safety engineering, and content safety; guardrail tools saturate content filtration and refusal behavior; observability platforms support testing, auditing, and post-deployment monitoring; while governance oversight, transparency beyond documentation, and legal, financial, and market remedies are nearly empty. The paper concludes that tool-based controls can instrument and constrain model behavior but that organizational governance and regulatory layers must supply the missing categories, and proposes a four-layer architecture: technical controls, observability and operations, organizational governance, and regulatory and market mechanisms.

Load-bearing premise

The map's usefulness rests on the assumption that the 21 chosen tools fairly represent the open-source AI risk-mitigation ecosystem, even though the selection rules only allowed tools whose primary function is evaluation, guardrails, red-teaming, or observability, and on the assumption that the human votes used as ground truth were independent even though all three reviewers started from the same automated capability summaries the pipeline produced.

Editorial extensions

If this is right

Risk teams can ask which taxonomy categories their tool stack covers, covers redundantly, or leaves exposed, instead of comparing tools by brand alone.
The near-empty governance, legal, and financial columns imply that automated tooling must be wrapped by board-level oversight, whistleblower protections, regulatory reporting, and compensation or market-access mechanisms.
The same extraction protocol can be applied to proprietary platforms when documentation or audit material is available, extending the coverage map to commercial tools.
At 75.5% F1, roughly one in four LLM-generated labels disagrees with the human consensus, so the unvalidated 75% of the matrix carries residual error, though macro-level patterns are probably stable.
The four-layer architecture gives a concrete pattern for composing red-teaming, guardrails, tracing, and human governance into a single mitigation pipeline.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The empty governance and legal columns are partly an artifact of the cohort selection: the paper's own inclusion criterion restricted entry to tools whose primary function is evaluation, guardrails, red-teaming, or observability, so governance-focused open-source tools could not enter. A cohort that included such tools would likely fill some of those cells, so the observed skew should be read as a
Because the human reviewers were given the same LLM-generated capability summaries as a starting point, the validation ground truth is not fully independent; if reviewers annotated straight from repositories, the measured F1 might shift. This is an untested confound that a replication study could resolve.
The reported F1 could be turned into per-cell confidence estimates: propagating the 75.5% reliability into cell-level uncertainty would let enterprises distinguish "probably covered" from "probably absent" rather than treating the matrix as binary.
A direct next test is scenario-based evaluation of layered stacks (red-teaming plus guardrails plus observability) against concrete harms like prompt injection and PII leakage; the coverage map predicts which combinations should work, and that prediction is falsifiable by deployment experiments.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The real contribution here is the artifact: a 21-tool by 32-category Tool×Risk matrix, built with a documented three-prompt LLM extraction protocol and supplemented by a detailed appendix of per-tool mappings, prompts, and a public repository. That is genuinely useful for enterprises trying to see where open-source tooling covers the MIT-derived taxonomy and where it does not. The layered architecture they propose as a consequence is a sensible synthesis, not a stretch. They also deserve credit for reporting the moderate Fleiss' Kappa (0.509) and for acknowledging the closed nature of NotebookLM and the interpretive difficulty of the task in their limitations section.

The soft spots are real and load-bearing, though they do not destroy the paper's descriptive value. First, the F1=75.5% is computed against a human consensus that was itself seeded by the same NotebookLM-generated capability summaries the pipeline produced. Reviewers used those summaries as their starting point and only went to the GitHub repository when summaries were absent or ambiguous. So the F1 partly measures self-consistency, not fully independent accuracy. The paper states the summaries were a starting point, not the sole basis, but that still anchors the human judgments to the automated extraction. Second, the headline finding that governance, legal, and financial categories are "largely unaddressed" is substantially a consequence of inclusion criterion 4, which restricts the cohort to tools whose primary functionality is evaluation, runtime guardrails, red-teaming, or observability. Governance and legal/financial tools are definitionally excluded. The paper acknowledges this only partially, saying these gaps reflect both fundamental limits of code-level tooling and the orientation of open-source efforts, but it does not fully separate the structural from the empirical.

That said, the matrix remains a reasonable baseline map. The macro-level coverage patterns would likely survive a more independent validation, and the detailed appendix lets readers judge individual mappings for themselves. The paper is clearly written and does not oversell its reproducibility, listing NotebookLM's closedness as a limitation.

Who is this for? Practitioners and researchers working on AI governance tooling, enterprise risk mapping, or LLM operations. A serious referee should engage with it, mainly to push the authors to re-frame the validation and to distinguish structural gaps from discovered gaps. It is not a fully reliable validation of the pipeline, but it is a reasonable descriptive contribution that deserves peer review.

Referee Report

3 major / 4 minor

Summary. The paper proposes a taxonomy-driven protocol for mapping open-source LLM risk-mitigation tools onto the 32 subcategories of the extended MIT AI Risk Mitigation and Response Taxonomy. A NotebookLM-based retrieval-augmented generation pipeline extracts capabilities from GitHub repositories of 21 tools, and three human reviewers validate a 25% stratified sample of the resulting 21×32 matrix. The authors report moderate inter-rater agreement (Fleiss' κ = 0.509), an F1 of 75.5% for the LLM-assisted mapping against the human majority consensus, and a highly skewed coverage landscape in which technical and operational controls are well served while governance, legal/regulatory, and financial/market categories remain largely empty. The paper closes with a four-layer risk-mitigation architecture that combines technical controls, observability, organizational governance, and regulatory mechanisms.

Significance. If the mapping protocol is reliable, the paper provides a practical bridge between high-level AI risk taxonomies and the terminology of open-source engineering tools, and its gap analysis would be a useful input for enterprise architecture decisions. The authors make a commendable effort to share prompts and code, and the explicit treatment of true negatives and the emphasis on implementation-level evidence are good methodological instincts. However, the paper's two central quantitative claims — that the LLM-assisted protocol is reliable and that the ecosystem lacks governance/legal/financial coverage — are weakened by the seeded validation loop and by the structural effect of the inclusion criteria. The contribution is therefore best viewed as a descriptive, reproducible mapping artifact whose stronger inferential claims need additional support.

major comments (3)

[Section 3.5, Table 3] The F1=75.5% is computed against a human consensus whose participants were given NotebookLM capability summaries as a starting point, and those summaries are the same outputs produced by the LLM pipeline. This creates a partial validation loop: a reviewer who reads an LLM-generated positive summary is more likely to label the cell as Yes, so the agreement partly measures self-consistency rather than independent correctness. To substantiate the claim that the protocol is reliable, the authors should provide an additional validation round in which reviewers judge cells from raw repository evidence without access to the summaries, and report the F1 on that independent subset.
[Section 3.3, criterion 4; Section 4] The inclusion criteria restrict the cohort to tools whose primary functionality is LLM evaluation, runtime guardrails, adversarial red-teaming, or observability. Governance, legal, financial, and market-oriented tools are therefore excluded by construction. The headline finding that categories 1.x, 4.x, 6.x, and 7.x are largely unaddressed by open-source code is thus partly a consequence of the selection rules, not an empirical discovery about the ecosystem. The paper should either expand the cohort to include tools whose primary purpose is governance/compliance reporting, legal/contractual controls, or financial risk management, or explicitly restate the claim as applying only to evaluation/guardrail/red-teaming/observability tools.
[Section 3.5] The paper states that a Kappa of 0.509 is 'expected and acceptable' and that an F1 of 75.5% supports using LLM labels for the remaining 75% of cells, but no benchmark, confidence interval, or sensitivity analysis is provided. Given the moderate inter-rater agreement and the 27.3% false negative rate, the authors should report the variability of F1 across bootstrap resamples or demonstrate via a worst-case analysis over the unvalidated cells that the macro-level coverage pattern — the paper's second central claim — is robust to plausible annotation error rates.

minor comments (4)

[Section 2] There is a typo in 'ddressing trustworthiness' in the survey paragraph; it should read 'addressing trustworthiness.'
[Section 3.4.1] Because NotebookLM is a closed commercial product, the retrieval process is not fully reproducible; the authors should document the specific model version, date, and any configuration options used, and note this limitation in the main text rather than only in the methodology narrative.
[Figure 1] The caption describes filled circles as active mitigations, but the figure does not distinguish explicit from derived mappings, even though Section 3.4 makes that distinction methodologically important; adding a marker type or separate figure would improve interpretability.
[Appendix C] Several detailed mappings appear overgenerous, e.g., Langfuse's 'Comprehensive Audit Trails (ISO 27001, SOC 2, GDPR, HIPAA)' mapped to 6.2 'Regulatory Policy & Legal Mandates' equates compliance certifications with regulatory mandates; the authors should clarify the criteria used to accept such derived mappings in the validation phase.

Circularity Check

2 steps flagged · score 6.0 of 10

F1 validation is looped through the same NotebookLM summaries used to generate the mappings, and the governance/legal gap is partly enforced by selection criterion 4; the central reliability claim is partially circular.

self definitional [Section 3.5, Human Validation and Final Results (F1 metric vs. human consensus)]
"Three independent reviewers audited the sampled matrix cells using tool-specific capability summaries generated through NotebookLM. They referenced the summaries of each tool's capabilities which served as a starting point rather than as the sole evidentiary basis for each decision."

The F1=75.5% is computed against the three-rater consensus, but the raters' binary Yes/No judgments were anchored to NotebookLM-generated capability summaries, i.e., outputs of the same LLM-assisted pipeline whose mappings are being validated. The human consensus is therefore not an independent ground truth: it partly reflects judgments seeded by the system under test. Agreement between the LLM and this consensus can be inflated by the shared source material, so the paper's claim that the result 'supports the use of LLM-generated labels as a reliable approximation of ground truth for the remaining 75% of matrix cells' rests on a validation loop rather than on a fully external audit.
self definitional [Section 3.3 (Tool Selection, criterion 4) and Section 4 (Landscape Aggregation and Analysis)]
"A tool's primary functionality had to address at least one of the following areas: LLM evaluation, runtime guardrails, adversarial red-teaming, or system observability. ... the open-source tools (selected based on criteria defined in Section 3.3) provide dense coverage across technical security and operational process controls, but offer little direct support for governance oversight, legal and regulatory remedies, or financial and market-level interventions."

Criterion 4 restricts the cohort to tools whose primary functionality is evaluation, guardrails, red-teaming, or observability. Any tool whose primary function is governance oversight, legal/regulatory enforcement, or financial/market intervention is excluded by construction. The headline finding that categories 1.x, 4.x, 6.x, and 7.x are largely empty is therefore not a purely empirical discovery about the open-source ecosystem; it is partly a restatement of the inclusion rule. This does not make the matrix useless, but it weakens the claim that the observed skew is an independent landscape property rather than a scoping consequence.

full rationale

The central circularity is in the validation of the LLM-assisted mapping protocol. F1=75.5% is presented as evidence of reliable mapping against human consensus, yet the human reviewers used the same NotebookLM-generated capability summaries as their starting point, so the consensus is contaminated by the system being measured. This is a specific, quotable loop in Section 3.5, not a general concern about LLM evaluation. A second, partly structural issue is that tool-selection criterion 4 restricts the cohort to evaluation, guardrails, red-teaming, and observability tools, which makes the sparse governance/legal/financial columns in the matrix partly definitional. The paper is transparent about some limitations, acknowledging moderate inter-rater agreement and NotebookLM's closed nature, and the descriptive tool-by-risk matrix remains valuable as a snapshot. The self-cited taxonomy [8] is also used, but it is documented in Appendix A and is not the main source of the circularity. Because the paper's headline reliability claim is partially reduced to self-consistency with the pipeline's own summaries, and the coverage-gap claim is partly enforced by inclusion criteria, the appropriate score is 6: partial circularity in a central quantitative claim rather than full equivalence of the derivation to its inputs.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The mapping rests on the taxonomy and on the validity of static code inspection, sample representativeness, and human consensus. The paper introduces no free parameters or invented entities. The most fragile assumption is cohort representativeness, because the inclusion criteria guarantee that governance, legal, and financial categories will be nearly empty.

assumptions (5)

domain assumption The extended MIT AI Risk Mitigation and Response Taxonomy [8] is an appropriate and comprehensive set of risk categories.
The entire mapping and coverage analysis uses these 32 subcategories as the fixed row template; Section 3.4.2 enforces a left-join on this taxonomy. The paper acknowledges in Section 5 that other taxonomies could change the coverage profile.
domain assumption Capabilities of a tool can be inferred from static repository artifacts, including source code, documentation, and configuration files, without executing the tools.
The protocol ingests GitHub repositories and uses an LLM to extract capabilities from code and documentation, as described in Section 3.4.1. No runtime testing is performed, and the paper itself notes in Section 5 that documented functionality may differ from actual behavior.
domain assumption The 25% stratified sample of 168 matrix cells is representative of the full 672-cell matrix.
Validation metrics are extrapolated to the unvalidated 75% of cells, as stated in Section 3.5. The paper provides no confidence intervals or cell-level analysis to support this extrapolation.
domain assumption Human majority-vote consensus is a reliable ground truth for mapping decisions.
The consensus is used as the target for F1 computation in Section 3.5. The assumption is weakened because reviewers were given NotebookLM-generated summaries as a starting point, reducing the independence of the consensus.
ad hoc to paper The 21-tool cohort reflects the wider open-source AI risk-mitigation ecosystem.
Inclusion criterion 4 restricts primary functionality to evaluation, runtime guardrails, adversarial red-teaming, or observability, so governance, legal, and financial tooling could not enter the cohort. This makes the observed governance and legal/financial gaps partly structural, as detailed in Section 3.3.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Taxonomy-Driven Analysis of Open-Source AI Risk Mitigation Tools." pith.science (2026). https://pith.science/paper/V3YUES2V

@misc{pith2026260807446,
  author       = {Pith},
  title        = {Pith review of: Taxonomy-Driven Analysis of Open-Source AI Risk Mitigation Tools},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/V3YUES2V}},
  note         = {Machine review of arXiv:2608.07446}
}

read the original abstract

Rapid adoption of large language models (LLMs) in enterprise settings has introduced operational, security, and governance risks. As generative AI applications move from pilot to production, manual harm identification and mitigation are becoming difficult to scale. Although many tools support model evaluation, adversarial testing, runtime guardrails, and observability, the tooling landscape remains fragmented. Tools are typically designed for specific engineering tasks and described in technical terms that do not align with governance frameworks or risk taxonomies, making it difficult to determine which tools address which risks and where critical gaps remain. This paper proposes a structured protocol to automate AI risk mitigation through a taxonomy-driven analysis of open-source LLM evaluation and security tools. We map the capabilities of 21 prominent open-source tools to the 32 subcategories of the extended MIT AI Risk Mitigation and Response Taxonomy. An LLM-assisted retrieval-augmented generation pipeline analyzes source code and documentation to extract capabilities for each taxonomy category. Reliability assessment yielded moderate agreement (Fleiss' Kappa = 0.509) among three independent reviewers. The analysis reveals a highly skewed landscape in which tools cluster around technical and operational controls, while governance, legal and regulatory, and financial and market controls remain largely unaddressed. This motivates a layered risk-mitigation architecture combining tool-based controls with organizational and regulatory processes. The mapping protocol achieved an F1 score of 75.5% after majority voting. Overall, the study provides a practical mapping between enterprise AI risk categories and open-source mitigation capabilities, identifies where human oversight remains necessary, and presents a taxonomy-driven framework applicable to open-source and proprietary solutions.

Figures

Figures reproduced from arXiv: 2608.07446 by the authors.

**Figure 1.** Tool × Risk Capability Matrix: Filled circles (•) denote active framework risk mitigations or analytical tool capabilities extracted from the taxonomy configuration. Therefore, this three-prompt chain-anchor, extraction, and synthesis was used to (i) fix a conservative, implementation-centric interpretation of “capability,” (ii) separate the extraction of the - tool from the cross-tool synthesis to reduce cognitiv… view at source ↗

**Figure 2.** Four-layer architecture aligning tools with the extended AI risk miti [PITH_FULL_IMAGE:figures/full_fig_p021_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 16 canonical work pages

[1]

Foundational challenges in assuring alignment and safety of large language models,

U. Anwar, A. Saparov, J. Rando, D. Paleka, M. Turpin, P. Hase, E. S. Lubana, E. Jenner, S. Casper, O. Sourbut, B. L. Edelman, Z. Zhang, M. G¨ unther, A. Korinek, J. Hernandez-Orallo, L. Hammond, E. Bigelow, A. Pan, L. Langosco, T. Korbak, H. Zhang, R. Zhong, S. ´O h ´Eigeartaigh, G. Recchia, G. Corsi, A. Chan, M. Anderljung, L. Edwards, A. Petrov, C. S. d...

arXiv 2024
[2]

Evaluating Reliability Gaps in Large Language Model Safety via Repeated Prompt Sampling

K. Broadwater, “Evaluating reliability gaps in large language model safety via repeated prompt sampling,” 2026. [Online]. Available: https://arxiv.org/abs/2604.09606

work page Pith review arXiv 2026
[3]

Large language models in fi- nance,

S. Borovkova, “Large language models in fi- nance,” LSEG White Paper, 2024. [Online]. Avail- able: https://www.lseg.com/content/dam/data-analytics/en us/ documents/brochures/lseg-large-language-models-in-finance-brochure.pdf

work page 2024
[4]

Opportunities and challenges of generative-ai in finance,

A. P. Desai, T. Ravi, M. Luqman, G. Mallya, N. Kota, and P. Yadav, “Opportunities and challenges of generative-ai in finance,” in2024 IEEE International Conference on Big Data (BigData). IEEE, Dec. 2024, p. 4913–4920. [Online]. Available: http://dx.doi.org/10.1109/BigData62323. 2024.10825658

work page arXiv 2024
[5]

Financial stability implications of artificial intelligence,

Bank for International Settlements, Financial Stability Institute, “Financial stability implications of artificial intelligence,” FSI Brief, June 2025, 2025. [Online]. Available: https://www.bis.org/fsi/fsisummaries/ exsum 23904.htm

work page 2025
[6]

Holistic evaluation of language models,

P. Liang, R. Bommasani, T. Lee, D. Tsipras, D. Soylu, M. Yasunaga, Y. Zhang, D. Narayanan, Y. Wu, A. Kumar, B. Newman, B. Yuan, B. Yan, C. Zhang, C. Cosgrove, C. D. Manning, C. R´ e, D. Acosta-Navas, D. A. Hudson, E. Zelikman, E. Durmus, F. Ladhak, F. Rong, H. Ren, H. Yao, J. Wang, K. Santhanam, L. Orr, L. Zheng, M. Yuksekgonul, M. Suzgun, N. Kim, N. Guha...

arXiv 2023
[7]

Monitoring adoption of artificial in- telligence and related vulnerabilities in the financial sector,

Financial Stability Board, “Monitoring adoption of artificial in- telligence and related vulnerabilities in the financial sector,” FSB Report, 2025. [Online]. Available: https://www.fsb.org/2025/10/ monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/ 55

work page 2025
[8]

When ai fails, what works? a data-driven taxonomy of real-world ai risk mitigation strategies,

E. Popchanovska, A. Gjorgjevikj, M. Rizinski, L. Chitkushev, I. Vodenska, and D. Trajanov, “When ai fails, what works? a data-driven taxonomy of real-world ai risk mitigation strategies,” 2026. [Online]. Available: https://arxiv.org/abs/2603.04259

work page arXiv 2026

Show all 22 references

[9]

Llm-safety evaluations lack robustness,

T. Beyer, S. Xhonneux, S. Geisler, G. Gidel, L. Schwinn, and S. G¨ unnemann, “Llm-safety evaluations lack robustness,” 2026. [Online]. Available: https://arxiv.org/abs/2503.02574

2026 arXiv
[10]

Revolutionizing finance with llms: An overview of applications and insights,

H. Zhao, Z. Liu, Z. Wu, Y. Li, T. Yang, P. Shu, S. Xu, H. Dai, L. Zhao, H. Jiang, Y. Pan, J. Chen, Y. Zhou, Z. Zhang, R. Sun, G. Mai, N. Liu, and T. Liu, “Revolutionizing finance with llms: An overview of applications and insights,” 2025. [Online]. Available: https://arxiv.org...

2025
[11]

Artificial intelligence risk management framework (ai rmf 1.0),

National Institute of Standards and Technology, “Artificial intelligence risk management framework (ai rmf 1.0),” NIST Special Publication,
[12]

Artificial intelligence risk management framework: Generative artificial intelligence profile,

——, “Artificial intelligence risk management framework: Generative artificial intelligence profile,” NIST AI 600-1, 2024. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

2024
[13]

Large language models (llms) in finance – a survey of applications, methods, and challenges,

M. STA W ARZ, “Large language models (llms) in finance – a survey of applications, methods, and challenges,”IBIMA Conference Proceedings, 2025. [Online]. Available: https://ibima.org/accepted-paper/ large-language-models-llms-in-finance-a-survey-of-applications-methods-and-challenges/

2025
[14]

Treasury guidance brings urgency to ai governance for financial institutions,

Grant Thornton LLP, “Treasury guidance brings urgency to ai governance for financial institutions,” 2026, accessed: 2026-06-22. [Online]. Available: https://www.grantthornton.com/insights/articles/ banking/2026/treasury-guidance-brings-urgency-to-ai-governance

2026
[15]

Financial services AI risk man- agement framework (FS AI RMF),

U.S. Department of the Treasury, “Financial services AI risk man- agement framework (FS AI RMF),” Press release and framework document, 2026. [Online]. Available: https://cyberriskinstitute.org/ artificial-intelligence-risk-management/

2026
[16]

Sound practices for responsible adoption of artificial intelligence (ai),

Financial Stability Board, “Sound practices for responsible adoption of artificial intelligence (ai),” Consultation re- port, 2026. [Online]. Available: https://www.fsb.org/2026/06/ sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-consultation-report/

2026
[17]

Conformity assessments and post-market monitoring: A guide to the role of auditing in the proposed european ai regulation,

J. M¨ okander, M. Axente, F. Casolari, and L. Floridi, “Conformity assessments and post-market monitoring: A guide to the role of auditing in the proposed european ai regulation,”Minds and Machines, 2022. [Online]. Available: https://doi.org/10.1007/s11023-021-09577-4

2022 doi
[18]

Llm observability tools compared: Langfuse vs langsmith vs opik,

I. Syn-Hershko, “Llm observability tools compared: Langfuse vs langsmith vs opik,” Technical article, 56
[19]

Open problems in technical ai governance,

A. Reuel, B. Bucknall, S. Casper, T. Fist, L. Soder, O. Aarne, L. Hammond, L. Ibrahim, A. Chan, P. Wills, M. Anderljung, B. Garfinkel, L. Heim, A. Trask, G. Mukobi, R. Schaeffer, M. Baker, S. Hooker, I. Solaiman, A. S. Luccioni, N. Rajkumar, N. Mo¨ es, J. Ladish, D. Bau, P. Br...
[2023]

Available: https://airc.nist.gov/airmf-resources/playbook/

[Online]. Available: https://airc.nist.gov/airmf-resources/playbook/
[2025]

Available: https://arxiv.org/abs/2407.14981 57

[Online]. Available: https://arxiv.org/abs/2407.14981 57

arXiv
[2026]

Available: https://bigdataboutique.com/blog/ llm-observability-tools-compared-langfuse-vs-langsmith-vs-opik

[Online]. Available: https://bigdataboutique.com/blog/ llm-observability-tools-compared-langfuse-vs-langsmith-vs-opik

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Foundational challenges in assuring alignment and safety of large language models,

U. Anwar, A. Saparov, J. Rando, D. Paleka, M. Turpin, P. Hase, E. S. Lubana, E. Jenner, S. Casper, O. Sourbut, B. L. Edelman, Z. Zhang, M. G¨ unther, A. Korinek, J. Hernandez-Orallo, L. Hammond, E. Bigelow, A. Pan, L. Langosco, T. Korbak, H. Zhang, R. Zhong, S. ´O h ´Eigeartaigh, G. Recchia, G. Corsi, A. Chan, M. Anderljung, L. Edwards, A. Petrov, C. S. d...

arXiv 2024

[2] [2]

Evaluating Reliability Gaps in Large Language Model Safety via Repeated Prompt Sampling

K. Broadwater, “Evaluating reliability gaps in large language model safety via repeated prompt sampling,” 2026. [Online]. Available: https://arxiv.org/abs/2604.09606

work page Pith review arXiv 2026

[3] [3]

Large language models in fi- nance,

S. Borovkova, “Large language models in fi- nance,” LSEG White Paper, 2024. [Online]. Avail- able: https://www.lseg.com/content/dam/data-analytics/en us/ documents/brochures/lseg-large-language-models-in-finance-brochure.pdf

work page 2024

[4] [4]

Opportunities and challenges of generative-ai in finance,

A. P. Desai, T. Ravi, M. Luqman, G. Mallya, N. Kota, and P. Yadav, “Opportunities and challenges of generative-ai in finance,” in2024 IEEE International Conference on Big Data (BigData). IEEE, Dec. 2024, p. 4913–4920. [Online]. Available: http://dx.doi.org/10.1109/BigData62323. 2024.10825658

work page arXiv 2024

[5] [5]

Financial stability implications of artificial intelligence,

Bank for International Settlements, Financial Stability Institute, “Financial stability implications of artificial intelligence,” FSI Brief, June 2025, 2025. [Online]. Available: https://www.bis.org/fsi/fsisummaries/ exsum 23904.htm

work page 2025

[6] [6]

Holistic evaluation of language models,

P. Liang, R. Bommasani, T. Lee, D. Tsipras, D. Soylu, M. Yasunaga, Y. Zhang, D. Narayanan, Y. Wu, A. Kumar, B. Newman, B. Yuan, B. Yan, C. Zhang, C. Cosgrove, C. D. Manning, C. R´ e, D. Acosta-Navas, D. A. Hudson, E. Zelikman, E. Durmus, F. Ladhak, F. Rong, H. Ren, H. Yao, J. Wang, K. Santhanam, L. Orr, L. Zheng, M. Yuksekgonul, M. Suzgun, N. Kim, N. Guha...

arXiv 2023

[7] [7]

Monitoring adoption of artificial in- telligence and related vulnerabilities in the financial sector,

Financial Stability Board, “Monitoring adoption of artificial in- telligence and related vulnerabilities in the financial sector,” FSB Report, 2025. [Online]. Available: https://www.fsb.org/2025/10/ monitoring-adoption-of-artificial-intelligence-and-related-vulnerabilities-in-the-financial-sector/ 55

work page 2025

[8] [8]

When ai fails, what works? a data-driven taxonomy of real-world ai risk mitigation strategies,

E. Popchanovska, A. Gjorgjevikj, M. Rizinski, L. Chitkushev, I. Vodenska, and D. Trajanov, “When ai fails, what works? a data-driven taxonomy of real-world ai risk mitigation strategies,” 2026. [Online]. Available: https://arxiv.org/abs/2603.04259

work page arXiv 2026