Supplemental Chapter to Principles and Practices of Model Risk Management

Part III — Ongoing Monitoring, Change Management, Governance, and Integrated Control

Part III Overview

Parts I and II discussed the GenAI system boundary, data and knowledge risks, development, and independent validation. Part III turns to what happens after a system is approved for production: ongoing performance monitoring, change management, governance, and integrated control. This distinction matters. A GenAI application may change substantially even when the underlying foundation model is not retrained. Changes to prompts, retrieval sources, vendor models, tools, guardrails, and users can all affect its behavior. MRM must therefore monitor the deployed system as a whole, including changes to its components and the resulting business risk.

Part III covers four related areas:

• ongoing monitoring of performance, business outcomes, and control effectiveness after production approval;

• change management for the evolving GenAI system, including agentic AI and controlled self-improvement;

• governance, ownership, risk appetite, escalation, and third-party dependencies; and

• an integrated MRM framework, supported by policy, standards, procedures, and a banking case study.

6. Ongoing Performance Monitoring

6.1 Why GenAI monitoring differs from traditional model monitoring

Traditional model monitoring assesses stability of inputs and outputs, calibration, discriminatory power, back-testing results, overrides, and realized outcomes, as applicable. These tests remain useful. GenAI creates additional difficulties. Its responses are often non-deterministic; tasks can vary widely; the correct answer may be hard to establish; and the distribution of prompts changes with user behavior. RAG adds an evolving knowledge source. Agentic applications introduce the further risk that an incorrect response leads to an external action. A monitoring program that looks only at a model-level accuracy measure will miss much of this risk.

In practice, management needs several measures rather than one overall score. These measures should cover output quality, factuality, grounding, robustness, safety, privacy where relevant, operational reliability, and control effectiveness. The selection and importance of each measure depend on the approved use case.

\(M_{t} = \left( Q_{t},F_{t},G_{t},R_{t},S_{t},P_{t},O_{t},C_{t} \right)\) (6.1)

where Q denotes task quality, F factuality, G grounding, R robustness, S safety/security, P privacy/fairness where relevant, O operational performance, and C control effectiveness. The exact vector should be tailored to the use case.

6.2 Monitoring against the approved operating scope

Part II represented the deployed system by its state S_t and the approved operating scope by 𝒱. These concepts are useful for monitoring. Although the model name may remain the same, its effective behavior can change when the surrounding system changes. Monitoring should establish whether the current configuration and actual use remain consistent with the conditions under which validation and approval were granted.

\(S_{t} = \left( W_{t},D_{t},P_{t},R_{t},T_{t},G_{t},U_{t} \right)\) (6.2)

\(S_{t}\mathcal{\in V}\quad\text{required for ordinary approved operation}\) (6.3)

The monitoring process must cover outcomes and changes in system configuration. Even if the model weights W are unchanged, a material change in RAG sources R, tool permissions T, guardrails G, or users U may move the system beyond its approved scope. Such a change calls for an impact assessment and, where warranted, targeted or full revalidation.

6.3 Components based monitoring architecture

A components-based framework identifies what to observe; it does not by itself constitute a monitoring program. For each production use case, the first line should maintain a written monitoring plan, approved under the institution's MRM standards. The plan should identify the monitored population, the critical tasks and failure modes, the baseline established at validation, the metrics and limits, the data and sampling methods, the frequency of review, and named owners for investigation and remediation. The monitoring scope must include each material component of the deployed system, not just the foundation model.

A practical plan combines four sources of evidence. First, automated production logs capture use, system versions, retrieval and tool activity, failed controls, and operational exceptions. Second, a risk-based sample of outputs is reviewed against authoritative sources and business requirements. Third, event-driven tests address vendor releases, changes in RAG content or permissions, new user groups, and significant incidents. Fourth, business outcome reviews examine complaints, corrections, overrides, downstream decisions, losses, and near misses. The first line should reconcile these sources rather than report them as unrelated dashboards.

Each metric needs a precise definition: numerator, denominator, sampling unit, exclusions, baseline, limit, observation window, and data owner. For example, the material unsupported-claim rate is the number of material claims not supported by approved evidence divided by the number of material claims reviewed. Its trend is assessed separately for major tasks and user groups. A serious unauthorized tool action, by contrast, should be treated as an incident even if the average error rate is small.

When a threshold is breached, the monitoring owner should assess its severity, affected population, root cause, and potential business impact. The response may include additional samples, restrictions on particular tasks or users, correction of RAG content or prompts, temporary human approval requirements, suspension of tool access, or withdrawal of the use case. A remediation plan should name an accountable owner, actions, due dates, interim controls, independent testing where appropriate, and evidence required for closure. Material breaches and overdue high-severity actions should be escalated to MRM and the relevant governance committee. The monitoring report should make clear what changed, why it matters, and whether the system may continue operating under its current approval.

6.4 Sampling: automated monitoring plus risk-based human review

Reviewing every response manually is usually impractical. The monitoring design should combine automated measures with human review of representative and higher-risk samples. Sample selection should reflect task, business impact, language, user group, model version, retrieved source, and tool access. Random samples help estimate routine performance; targeted samples are needed to identify severe or uncommon failures. The two should be recorded separately to avoid presenting an intentionally risk-weighted sample as an unbiased estimate of the overall error rate.

\(\widehat{p} = \frac{1}{n}\sum_{i = 1}^{n}I\left( E_{i} \right)\) (6.4)

Let I(E_i) equal 1 if the specified undesirable event occurs in observation i, and 0 otherwise. The sample proportion p̂ then estimates the event rate for the defined sampling population. Under independent Bernoulli sampling, its conventional estimated standard error is shown in Equation (6.5). The event, unit of observation, and population must be specified before this calculation is interpreted.

\(SE\left( \widehat{p} \right) = \sqrt{\frac{\widehat{p}\left( 1 - \widehat{p} \right)}{n}}\) (6.5)

The independent-sampling assumption is often questionable in GenAI applications. Errors may be correlated within prompt families, documents, languages, user groups, model versions, or retrieval pathways. These effects are neither necessarily independent nor additive. The usual binomial standard error can therefore understate uncertainty. For monitoring, I would distinguish three objectives: estimating an average error rate for a well-defined population, comparing performance across meaningful segments, and detecting severe failure scenarios. Stratified random sampling, cluster-aware confidence intervals or bootstrap methods, and separate scenario testing may be appropriate for these different objectives. No statistical adjustment eliminates the need to investigate an observed control failure. Where reliable probability sampling is unavailable, findings should be reported as sample results rather than population estimates.

6.5 Thresholds and traffic-light escalation

Limits should be established at approval rather than after performance deteriorates. They may be absolute (for example, no unauthorized access), relative to a validated baseline, or based on sustained deterioration supported by statistical evidence. A breach should lead to a defined investigation and escalation process. Statistical significance alone is not sufficient: a single serious breach may require immediate action.

\(\Delta m_{t} = m_{t} - m_{baseline}\) (6.6)

6.6 Monitoring factuality and grounding

For applications that depend on documents or authoritative records, factuality and grounding are related but different. Factuality asks whether an assertion is correct. Grounding asks whether the assertion is supported by the specific sources the system was required to use. A correct statement without an approved supporting source may still be unacceptable in a controlled banking process. Equally, a retrieved document can be obsolete or wrong.

\(Groundedness = \frac{\#\ material\ claims\ supported\ by\ approved\ evidence}{\#\ material\ claims}\) (6.7)

Automated LLM-based evaluations can reduce the cost of review, but the evaluator is itself a model with limitations. Its findings should be compared with judgments from qualified reviewers, particularly for material claims and disputed cases. The evidence trail should permit an independent reviewer to trace a consequential answer to its underlying source.

There is no universal sample size or acceptable grounding rate. For a simple independently sampled proportion, a planning approximation is n ≈ z²p(1 − p)/e², where z is the standard normal critical value for the desired confidence level, p is the assumed success rate, and e is the target half-width. With p = 0.95, z ≈ 1.96 (95% confidence), and e = 0.02, the result is approximately 456 claims; at e = 0.01, approximately 1,825 claims. These calculations are only starting points. Correlation among claims, unequal sampling rates, and differences across tasks may require a larger effective sample or methods that account for clustering. The unit should be defined carefully: multiple claims from the same answer are not necessarily independent.

Acceptance criteria should reflect the consequences of error. A drafting assistant may tolerate limited immaterial defects. A credit-policy or regulatory assistant should face tighter requirements for material statements and may have zero tolerance for specified critical failures. The limits, including any permitted exceptions, belong in the original approval and monitoring plan.

6.7 Monitoring RAG systems

RAG systems require monitoring of retrieval and generation separately. If an answer is wrong, the cause may be failure to retrieve the right source, incorrect ranking, inadequate use of retrieved evidence, or an outdated or contradictory document. Each cause calls for a different remedy.

\(Recall@k = \frac{\#\ relevant\ items\ retrieved\ in\ top\ k}{\#\ relevant\ items}\) (6.8)

\(Precision@k = \frac{\#\ relevant\ items\ retrieved\ in\ top\ k}{k}\) (6.9)

Production controls should also cover additions and removal of documents, effective dates, embedding and index versions, metadata, access permissions, retrieval failures, conflicting sources, and signs of indirect prompt injection. A corpus update should be assessed for its effect on both answer quality and information access.

Recall@k and Precision@k should be measured before approval against a labeled test set with known relevant sources. The set should cover important document classes, query types, languages, and high-risk cases. Production monitoring can then compare results with that baseline using newly labeled queries and repeat tests after material changes in the corpus, embedding model, index, retrieval logic, or reranking. A production history improves drift assessment, but does not replace pre-production testing.

6.8 Drift in GenAI systems

Drift is meaningful only relative to a baseline. The monitoring plan should say what is changing, how it will be measured, and what degree of change requires investigation. Some changes are statistical, such as a shift in prompt categories or language mix. Others are categorical, such as the introduction of a new permission or vendor model version. The measure must match the underlying risk.

A useful notation for dimension j is \(Driftⱼ(t)\ = \ dⱼ(Zⱼ,ₜ,\ Zⱼ,₀)\). Here Zⱼ,₀ is the validated baseline, Zⱼ,ₜ is the observed state at time t, and dⱼ is a comparison measure appropriate to the risk. This may be a distributional distance, a category-frequency difference, a retrieval-performance measure, or a configuration-change indicator. There is no single drift statistic for the complete GenAI system.

Drift extends beyond conventional changes in input data. A GenAI application can experience prompt drift, changes in its user population and tasks, changes in available knowledge, retrieval changes, vendor-model changes, changes to enabled tools, and weakening or modification of controls. The distinctions matter because the appropriate owner and remedial action differ.

6.9 Incident and near-miss monitoring

An acceptable average error rate can conceal a serious tail event. The monitoring process must therefore record incidents and near misses in addition to aggregate metrics. Unauthorized disclosure, incorrect consequential advice, successful prompt injection, unsafe code execution, or bypass of a human approval step warrants separate analysis of severity, exposure, and possible propagation.

\(Risk\ Exposure \approx \sum_{j}^{}{Frequency}_{j} \times {Severity}_{j}\) (6.10)

The purpose of Equation (6.10) is to keep rare, high-severity events visible. A low average frequency cannot be used to dismiss an incident whose consequences could be substantial.

6.10 Monitoring frequency

7. Dynamic Evolution, Change Control, and Agentic AI

7.1 GenAI systems can change without retraining

A GenAI system may evolve without any change to its foundation-model weights. Prompts, retrieval sources, tool permissions, memory, inference settings, and orchestration rules can change the outcome. For model risk purposes, the relevant object is the whole application in its current configuration.

\(\Delta S_{t} = \left( \Delta W_{t},\Delta D_{t},\Delta P_{t},\Delta R_{t},\Delta T_{t},\Delta G_{t},\Delta U_{t} \right)\) (7.1)

Change control must therefore apply to the deployed system, not just software releases or retraining of the foundation model.

7.2 Materiality of change

Not every modification warrants full revalidation. The important question is whether a change could alter system behavior, the extent of use, the effectiveness of controls, or potential loss. An impact assessment should examine the affected components, evidence from prior validation, regression-test results, and the possibility of unexpected interactions.

\(C = \sum_{j = 1}^{J}w_{j}c_{j}\) (7.2)

In Equation (7.2), c_j represents the size of a change and w_j its relative risk importance. The expression is an illustration, not a universal numerical rule. A single change that introduces unauthorized external action should not be offset by several low-risk or unchanged components.

7.3 Versioning and reproducibility

For important decisions and incidents, the institution should be able to reconstruct which effective system was used. Recording only the provider's model name is not sufficient. The record should identify prompt and configuration versions, retrieval sources and indexes, tools and permissions, relevant context, guardrails, external data, and the decision time, subject to applicable data-retention and privacy rules.

7.4 Vendor model updates and third-party opacity

Third-party models create a difficult change-control issue. A vendor may change model behavior, safety settings, context limits, or serving arrangements without changing the application code used by the bank. Where possible, the institution should obtain advance notice, keep records of vendor releases, and test material changes before production use. A familiar product name does not establish that behavior is unchanged.

Limited transparency does not remove the bank's obligation to assess risk. It may justify narrower permitted uses, stronger testing, version pinning when available, contingency arrangements, and tighter monitoring. Unresolved information gaps should be identified in the approval decision.

7.5 Agentic AI changes the loss mechanism

An incorrect answer is one form of model risk; an incorrect action may produce an immediate business loss. An agent can plan a sequence of steps, invoke tools, act on the results, and repeat. The resulting exposure depends on the full sequence, not only on the reasonableness of any individual response.

\(O_{t} \rightarrow P_{t} \rightarrow A_{t} \rightarrow O_{t + 1}\) (7.3)

Agent monitoring must assess whether a sequence stays within its approved purpose, permissions, budgets, approval gates, and stopping conditions. An agent with broad access and weak controls can amplify an initially small mistake.

7.6 Dynamic improvement and recursive self-improvement (RSI)

Recursive self-improvement (RSI) is used to describe different forms of adaptation, and these should not be confused. At one level, an LLM changes its answer or plan as the context evolves, without altering its weights. At another, a controlled system may update memory, RAG sources, prompts, or even fine-tuning based on feedback. Strong-form RSI would go further: the system improves the mechanisms used to improve itself, potentially producing repeated capability gains with reduced human intervention. These are different risks and should not be governed as if they were the same.

For current MRM practice, it is neither necessary nor sound to assume that every agent can improve itself recursively. The immediate requirement is clear: material self-modifications must not enter production without authorized change control, testing, approval, documentation, and, where feasible, rollback. A system may recommend improvements, but should not be allowed to approve its own material changes.

7.7 Revalidation triggers

Revalidation should be triggered by changes that could invalidate prior evidence. Illustrative triggers include:

• foundation-model or material vendor-version change;

• new fine-tuning or adaptation method;

• material system-prompt or orchestration change;

• embedding, retrieval, reranking, or RAG-corpus change that affects behavior or access;

• new tool, API, permission, autonomous action, or memory capability;

• new material user population, language, geography, business process, or decision type;

• significant deterioration in factuality, grounding, robustness, safety, security, fairness, or business outcomes;

• material incident, near miss, control failure, or newly discovered vulnerability;

• legal, regulatory, policy, or product change that invalidates knowledge or approved use; and

• evidence that original validation data or benchmarks were contaminated or no longer representative.

8. Governance and Control

8.1 Governance objective

The objective of governance is to put accountable decisions behind technical evidence. GenAI risk cannot be eliminated, but management must decide which uses are permitted, what restrictions apply, who accepts residual risk, and when an issue must be escalated. These decisions should be documented and subject to independent challenge.

8.2 GenAI policy, standards, and procedures

A workable governance framework needs policy, standards, and procedures, each serving a different purpose. Policy sets scope, responsibilities, risk appetite, prohibited uses, and approval authorities. Standards establish minimum expectations for inventory, development, validation, monitoring, security, and change control. Procedures specify how these requirements are implemented, evidenced, escalated, and reviewed. Without this hierarchy, broad principles are difficult to enforce consistently across business units.

8.3 Inventory: from model inventory to AI-system inventory

A traditional inventory identifies the model, owner, intended use, risk tier, and validation status. That is not enough for GenAI. The inventory must describe the effective application: model and version, prompts and orchestration, RAG sources, tools, users, permissions, autonomy, major controls, and the decisions it can influence. Material dependencies should be visible so changes can be assessed across the system rather than one component at a time.

8.4 Risk tiering

Risk tiering should be driven chiefly by use, exposure, and the consequences of failure. Technical sophistication alone is a poor measure. A relatively simple application embedded in underwriting or customer communications may warrant stronger controls than a more capable model used only for internal drafting.

\(R_{inherent} = f(I,E,A,D,S,U)\) (8.1)

where I is impact severity, E exposure/volume, A autonomy, D data sensitivity, S security surface, and U uncertainty. Institutions may operationalize these dimensions qualitatively or quantitatively.

8.5 Three lines of defense and effective challenge

The three lines of defense remain relevant. Business and technology owners in the first line are accountable for design, operation, monitoring, and remediation. Independent MRM provides validation and effective challenge, drawing on specialists in cyber, privacy, compliance, data, and operational risk. Internal audit evaluates the governance and control framework. These responsibilities should be coordinated without making MRM the sole owner of risks it cannot control.

8.6 Risk appetite and use restrictions

Risk appetite should be stated in operational terms. Restrictions may prohibit autonomous customer commitments, require review of consequential advice, limit confidential data access, or forbid certain tools and transactions. Approval limits should follow from the likely loss and the demonstrated effectiveness of controls, not merely the quality of a benchmark score.

\(R_{residual} = R_{inherent} - Control\ Effectiveness\) (8.2)

Equation (8.2) is a conceptual way to frame the decision. Management accepts the residual risk after controls have been evaluated, not the model's inherent risk and not its stated performance in isolation.

8.7 Human oversight: meaningful rather than ceremonial

Human review is effective only if the reviewer can recognize and challenge errors. Fluency can encourage overreliance; high volume can turn approval into a routine click. Reviewers need access to supporting evidence, adequate expertise and time, authority to stop the action, and clear responsibility for the decision. Review outcomes should feed back into monitoring.

8.8 Third-party and foundation-model governance

Using a vendor does not transfer the bank's accountability. Due diligence should address what the model can and cannot do, how data are handled, security, resilience, vendor changes, incidents, subcontractors, and exit arrangements. When proprietary restrictions prevent inspection, that limitation should be documented and addressed through independent tests, contractual controls, limits on use, and continuing monitoring.

8.9 Documentation and auditability

Documentation should allow a knowledgeable independent reviewer to understand why a system was approved, the assumptions and limitations behind the decision, what subsequently changed, and how issues were addressed. The level of detail should reflect materiality, but a decision should never depend solely on knowledge held by one developer or vendor.

8.10 Issue management

9. Integrated GenAI MRM Framework

9.1 Lifecycle view

The framework developed in Parts I–III is a continuing MRM process, not a one-time validation exercise. Monitoring, incidents, and changes can lead back to development, independent testing, revised restrictions, or withdrawal of approval. This feedback is especially important when the components of a GenAI application evolve at different rates.

9.2 The control loop

\(Scope \rightarrow Develop \rightarrow Validate \rightarrow Approve \rightarrow Monitor \rightarrow Change/Incident \rightarrow Revalidate\) (9.1)

Approval cannot be treated as permanent evidence that a model remains fit for use. The institution's control capability rests on its ability to recognize meaningful changes, assess their effect on risk, and require renewed evidence when the original validation no longer applies.

9.3 Mapping risks to controls and evidence

9.4 A practical governance dashboard

A model-risk committee needs a clear assessment of exposures, exceptions, and decisions requiring action, not a raw dump of every test or prompt. Management reporting should distinguish ordinary performance fluctuations from material changes, unresolved control weaknesses, and breaches of risk appetite. A useful dashboard should include:

• inventory counts by risk tier and autonomy level;

• validation status and overdue conditions;

• material vendor/model/RAG/tool changes;

• performance and grounding trends against thresholds;

• security incidents, prompt-injection attempts, and successful exploit rates;

• human overrides, complaints, and realized business errors;

• open high-severity issues and aging;

• systems operating under temporary exceptions or compensating controls; and

• revalidation pipeline and upcoming material changes.

10. Integrated Case Study — BankCo Policy and Credit Assistant

10.1 Business proposal

BankCo proposes an internal assistant for commercial-credit officers. It will summarize borrower records, retrieve approved credit policy, extract financial covenants, draft sections of credit memoranda, and answer policy questions. In a later phase, management wants the assistant to populate selected underwriting fields. The system will not approve a loan, change a limit, or communicate a commitment to a customer.

10.2 System architecture

10.3 Initial risk assessment

This use case carries materially more risk than a general drafting assistant. Its answers may influence credit analysis and it will process confidential borrower information. In Phase 1, however, the assistant has no authority to make a credit decision or carry out customer-facing action. BankCo therefore assigns a high risk tier while distinguishing its initial decision-support role from autonomous underwriting.

10.4 Validation plan

Independent validation should challenge the application with production-like cases, including:

• credit-policy questions with authoritative answers and effective dates;

• borrower documents containing ambiguous covenants, tables, footnotes, and conflicting statements;

• cases in which the correct response is to abstain or escalate;

• documents containing direct and indirect prompt-injection text;

• long-context cases where relevant information appears far from the question;

• permission tests using documents the requesting officer is not authorized to access;

• counterfactual and paraphrased variants to test robustness; and

• tool-use tests verifying calculator accuracy and read-only database permissions.

The validation recommendation is Approved with Conditions. Policy answers must cite controlled sources; extracted financial terms must receive human review; credit approval and write access remain outside the assistant's authority; retrieval and tool calls must be logged; and the first line must establish monitoring metrics and escalation thresholds before launch.

10.5 Monitoring design

10.6 A material change

After six months, the vendor introduces a new model version. At the same time, BankCo proposes allowing the assistant to write covenant fields to its underwriting application. The intended business process is similar, but the risk is not. Model behavior may have changed, and an extraction mistake could now alter a production record.

\(S_{t + 1} ≉ S_{t}\quad\text{for risk purposes when autonomy or consequence changes materially}\) (10.1)

BankCo should not rely on its initial validation alone. It should compare the new model against the approved baseline, test extraction and tool use, check authorization and rollback, and require explicit human confirmation before a field is committed. The assessment must consider how the two changes interact, not simply test them in isolation.

10.7 Incident scenario

A borrower PDF contains hidden instructions telling the assistant to disregard BankCo policy and retrieve unrelated internal records. The model partially follows those instructions. The retrieval service nevertheless denies access to the unauthorized documents, and no confidential information is disclosed. This is a near miss: one control failed, while a separate access control prevented a loss.

The incident response should distinguish:

• root cause — indirect prompt injection in untrusted content;

• failed control — prompt/context isolation did not prevent instruction following;

• successful control — retrieval authorization enforced least privilege;

• exposure — attempted but unsuccessful unauthorized retrieval;

• remediation — strengthen document isolation and injection detection; add adversarial regression case; and

• governance consequence — reassess whether similar documents could exploit tools with different permissions.

10.8 What the case illustrates

The BankCo case illustrates why system-level MRM is needed. Part I identifies the system boundary and the risks in data and retrieval. Part II establishes evidence from development and independent validation. Part III adds the continuing obligation to monitor production behavior, manage vendor and tool changes, investigate incidents, and reconsider approval when risk changes.

Part III Summary

The main conclusions of Part III are:

1. Ongoing monitoring must evaluate a multidimensional system, not only model accuracy.

2. Monitoring should test both outcomes and whether the current system remains inside its validated operating envelope.

3. Change control must cover model versions, prompts, RAG, tools, guardrails, users, and permissions; a system can change materially without retraining.

4. Agentic AI raises the consequence of error and therefore requires least privilege, bounded actions, human gates, logging, reversibility, and explicit controls on self-modification.

5. Governance should connect inventory, risk tiering, validation, approval, monitoring, incident management, change control, and revalidation into one closed-loop lifecycle.

6. Recursive or system-level self-improvement can create additional model risk. The permitted scope of self-improvement, the components that may change, the speed or frequency of change, and any changes to the model/system architecture should be explicitly defined, independently challenged, and controlled through testing, approval, monitoring, and rollback requirements.

Part III References and Further Reading

1. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency, and Federal Deposit Insurance Corporation (2026). Revised Guidance on Model Risk Management, SR 26-2, April 17, 2026.

2. Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., and Roberts, K. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.

3. National Institute of Standards and Technology (2026). TEVV-Athlon Framework for Evaluating AI Systems, NIST AI 200-2, Initial Public Draft.

4. OWASP GenAI Security Project (2026). OWASP Top 10 for LLM and Generative AI, including prompt injection, supply-chain vulnerabilities, data/model poisoning, improper output handling, excessive agency, system-prompt leakage, vector/embedding weaknesses, misinformation, and unbounded consumption.

5. Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems.

6. Vaswani, A. et al. (2017). Attention Is All You Need. Advances in Neural Information Processing Systems.

7. Goodfellow, I., Bengio, Y., and Courville, A. (2016). Deep Learning. MIT Press.

8. Rao, A., Keller, A., Kalra, N., et al. (2026). Challenges to the Monitoring of Deployed AI Systems. NIST AI 800-4, National Institute of Standards and Technology.