Part I: Foundations, Risk Taxonomy, and Data Risk Management
September 2026
Generative artificial intelligence (GenAI or GAI) changes the object of model risk management. Traditional MRM generally evaluates a bounded quantitative model whose inputs, methodology, parameters, outputs, and intended use can be identified with reasonable precision. A production GenAI application is more naturally understood as a dynamic AI system: a foundation model combined with prompts, context, retrieval, tools, guardrails, users, and changing external information. This distinction is the organizing idea of this supplemental chapter.
The purpose of Part I is to establish three foundations. Section 1 explains why GenAI requires an extension of traditional MRM rather than a rejection of it. Section 2 develops a GenAI model-risk taxonomy that separates component-level model risk from system-level model risk. Section 3 develops a data-risk framework spanning pre-training, adaptation, retrieval, runtime inputs, evaluation, feedback, and monitoring.
Regulatory context. The U.S. banking agencies’ revised MRM guidance, SR 26-2 (April 17, 2026), succeeds SR 11-7. It explicitly states that generative AI and agentic AI are not within the scope of that guidance because they are novel and rapidly evolving. At the same time, it states that banking organizations’ risk-management and governance practices should determine appropriate controls for tools, processes, and systems outside its scope. This creates a practical need to extend established MRM principles to GenAI without pretending that traditional validation techniques are sufficient by themselves. [1,2]
After completing Part I, a student should be able to:
The central premise of traditional MRM remains valid: models can produce adverse consequences because they are incorrect, incomplete, validation failure, poorly implemented, used outside their intended purpose, or insufficiently governed. SR 26-2 continues to emphasize a risk-based framework for development, implementation, use, validation, governance, and controls. It also preserves an important principle for third-party models: limited access to proprietary code, data, or methodology does not eliminate the institution’s responsibility to understand conceptual soundness, development data, performance, and limitations. [1,2]
GenAI therefore does not make traditional MRM obsolete. Instead, it changes the structure and dimensionality of the risk. A conventional model can often be represented as
\[Y = f(X;\theta),\]
where \(X\) denotes inputs, \(\theta\) denotes estimated or calibrated parameters, \(f\) is a specified methodology, and \(Y\) is the model output. Although real models can be complex, the model boundary is usually identifiable.
A production GenAI application is better represented as
\[Y_{t} = F\left( M_{t},P_{t},C_{t},R_{t},T_{t},G_{t},U_{t},\epsilon_{t} \right),\]
where:
This formulation immediately produces an MRM consequence: a system can change materially even when the underlying model weights do not change—a major difference from many traditional models. A new system prompt, an updated retrieval corpus, a different tool permission, a vendor model update, or a new user population may change the risk profile.
A traditional regression might estimate
\[Y = \beta_{0} + \sum_{j = 1}^{p}\beta_{j}X_{j} + \varepsilon.\]
A conventional machine-learning model can be summarized as
\[\widehat{y} = f_{\theta}(X),\]
where the output is typically a prediction, score, class, or numerical estimate within a predefined output space.
A large language model instead estimates a conditional probability distribution over tokens:
\[P_{\theta}\left( x_{t + 1} \mid x_{1},\ldots,x_{t} \right).\]
Generation proceeds recursively by sampling or selecting a next token and then conditioning on the expanded sequence:
\[x_{t + 1} \sim P_{\theta}\left( \cdot \mid x_{\leq t} \right).\]
Here, x₁,…,xₜ are the tokens already observed; xₜ₊₁ is the next token; Pθ denotes the probability distribution implied by model parameters θ; and x≤t denotes the entire token sequence available through position t. At each generation step, the model produces a probability distribution over the vocabulary, selects or samples a token according to the decoding rule, appends that token to the context, and repeats the process.
This matters for MRM because a language model is not directly optimized to maximize factual truth, regulatory compliance, suitability, or business correctness. Its pre-training objective is principally to predict tokens well. Alignment, fine-tuning, retrieval, system instructions, guardrails, and human oversight are layered on top to make the system useful and safer for particular purposes.
A fluent answer is therefore not equivalent to a correct answer:
\[P(\text{linguistically plausible}) \neq P(\text{factually correct}).\]
This simple inequality captures one of the most important differences between GenAI output risk and traditional model error.
Table 1. MRM comparison across model generations
| Dimension | Statistical / econometric | Traditional ML | GenAI / LLM system |
|---|---|---|---|
| Typical objective | Projection based on estimate relationship / parameter | Predict or classify | Generate content / reason / interact |
| Output space | Usually bounded and structured | Usually bounded and structured | Extremely large and open-ended |
| Inference behavior | deterministic with statistical boundaries | deterministic with statistical boundaries | Often stochastic / configuration-sensitive |
| Training data | controlled, often predefined | Larger, often predefined | Massive, heterogeneous, often partially opaque |
| Interpretability | Often relatively high | Variable | Generally limited at parameter level |
| Intended use | Narrow | Usually bounded | Potentially broad / general-purpose |
| User interaction | Limited | Limited | Continuous and conversational |
| Prompt sensitivity | Not applicable | Usually immaterial | Material |
| Hallucination | Not applicable | Not applicable | Core factuality/grounding risk |
| External knowledge | Explicit input data | Explicit input data | May include RAG, web, tools, memory |
| Security surface | Model + implementation | Model + pipeline | Model + prompts + retrieval + tools + agents |
| Change frequency | Periodic | Periodic | Potentially continuous at system level |
| Agency | None | Usually none | Increasingly possible |
| Validation target | Model | Model + data/feature/serving pipeline | Risk-bearing AI system |
The table should not be interpreted as implying that all statistical models are transparent or that all GenAI systems are autonomous. Rather, it identifies the direction in which MRM complexity increases.
A useful distinction is between a foundation model and a business AI system. A financial institution may license a third-party model, add a proprietary system prompt, retrieve internal policies through RAG, connect calculation tools, impose access controls, and embed the result in a credit or compliance workflow. The risk experienced by the institution arises from the integrated system, not solely from the vendor’s base model.
Figure 1. Conceptual GenAI system stack
| Layer | Example | Principal MRM question |
|---|---|---|
| Training foundation | Pre-training corpus/dataset, architecture, weights | What is known about capabilities, limitations, data, and training? |
| Adaptation | Fine-tuning, preference optimization | What behavior changed and how was it tested? |
| Prompt/control | System prompt, policy instructions | Are instructions controlled, versioned, and robust? |
| Retrieval/context | RAG, vector database, conversation context | Is retrieved information relevant, authorized, current, and safe? |
| Tools/agency | Calculator, database, workflow action | What can the system do, with what permissions and reversibility? |
| Guardrails | Filters, policy checks, access controls | Do controls work under adversarial and edge-case conditions? |
| Use | Human interaction and business process | Is use consistent with approval, expertise, and accountability? |
| Output/decision | Draft, recommendation, action | Is output verified before consequential use? |
Proposed MRM principle 1 — System boundary principle. (to have this in a box) The primary inventory and validation object should generally be the smallest risk-bearing system that captures the material interaction among model, data, prompts, retrieval, tools, controls, and use. Component-level assessments remain necessary, but component validation should not be mistaken for end-to-end system validation.
Traditional validation frequently relies on conceptual soundness, process verification, benchmark comparison, outcomes analysis, and ongoing monitoring. Those principles remain useful, but GenAI complicates each of them.
First, behavior is high-dimensional. A model can be accurate on one task and unsafe on another. Second, performance is distribution-dependent: benchmark prompts may differ sharply from actual user prompts. Third, outputs can be stochastic, making repeatability itself a risk dimension. Fourth, the application can incorporate changing external data and tools. Fifth, adversarial users or documents can alter behavior through prompt injection. The Open Worldwide Application Security Project (OWASP) notes that prompt injection can be direct or indirect and can lead to sensitive-information disclosure, unauthorized functions, arbitrary commands in connected systems, or manipulation of decisions; RAG and fine-tuning do not by themselves eliminate this vulnerability. [5]
NIST’s GenAI Profile is useful because it treats GenAI risk as a lifecycle problem and organizes risk-management actions around governance, mapping, measurement, and management. It explicitly focuses on risks that are novel to, or exacerbated by, generative AI. [3,4]
A practical GenAI MRM program needs a taxonomy broad enough to capture system risk but structured enough to support inventory classification, validation planning, issue management, and monitoring. This chapter proposes nine interacting categories.
Scope risk arises when the organization has not correctly identified what is being governed. Consider an internal research assistant built on a third-party LLM. If the inventory records only the vendor model, it may omit material risks introduced by the institution’s own RAG corpus, system prompts, tool permissions, workflow, and users. If it records only the application, it may obscure dependencies on model version and vendor changes.
Scope controls should therefore identify: the business use; the foundation model and version; adaptation methods; system/developer prompts; RAG components; embedding models; external tools; permissions; guardrails; user population; output consumers; and downstream decisions.
A useful decomposition is
\[R_{\mathrm{system}} \neq \sum_i R_{\mathrm{component},i}.\]
The inequality emphasizes interaction and dependency risk, not merely the sum of component risks. Individually acceptable components can create an unacceptable system when combined because prompts affect retrieval, retrieved context affects model output, model output can trigger tools, and guardrails or user behavior can amplify or mitigate the resulting exposure. Accordingly, GenAI model risk should be assessed systematically at both the component level and the integrated system level; component assessments should be combined with end-to-end testing of material interactions.
GenAI data risk includes conventional quality problems plus provenance, privacy, intellectual-property rights, representativeness, toxicity, poisoning, contamination, and runtime retrieval risk. Data enter the system at multiple points: pre-training, fine-tuning, preference/alignment, evaluation, RAG, user prompts, tool outputs, and feedback loops.
The EU AI Act’s GPAI obligations illustrate the growing governance importance of data transparency. Providers generally must maintain technical documentation, provide downstream information about capabilities and limitations, implement a copyright-compliance policy, and publish a sufficiently detailed summary of training content; systemic-risk GPAI models face additional risk-management and cybersecurity requirements. [7,8]
Model risk includes architecture limitations, weak reasoning, poor calibration, hallucination, memorization, insufficient generalization, context limitations, multimodal failure, and emergent behavior. A critical MRM question is not merely whether the model is powerful, but whether its design is suitable for the approved task.
For some use cases, a deterministic rules engine, conventional statistical model, search system, or database query may be safer and more auditable than GenAI. Therefore conceptual soundness begins with the question: Why is GenAI appropriate for this use case?
A technically capable system may create model risk when used outside its approved purpose. Examples include using a summarization assistant to make final credit decisions, using a general-purpose chatbot for legal advice without review, or allowing an agent to execute transactions beyond its approved authority.
Usage risk should be analyzed along at least four dimensions:
\[U_{risk} = f\left( \text{purpose},\text{user},\text{consequence},\text{autonomy} \right).\]
The same model may therefore require very different controls in low-consequence drafting and high-consequence decisioning.
GenAI can generate content that is syntactically coherent and semantically plausible while being unsupported, fabricated, incomplete, or subtly wrong. Output risk includes factual error, unsupported attribution, false citation, omitted qualification, numerical inconsistency, and inappropriate confidence.
For MRM purposes, hallucination should not be treated only as a model-development defect. It is a system risk affected by prompts, retrieval quality, context, temperature/sampling, task difficulty, user expectations, and verification controls.
GenAI expands the attack surface. Important risks include prompt injection, jailbreaks, sensitive-information disclosure, supply-chain vulnerabilities, data/model poisoning, improper output handling, excessive agency, and unauthorized tool use. OWASP’s 2025 LLM/GenAI taxonomy treats these as application-lifecycle risks rather than purely model-level defects. [5,6]
Indirect prompt injection is particularly important for RAG and agentic systems. A malicious instruction can be embedded in a document or other retrieved content. If the system fails to distinguish data to be analyzed from instructions to be followed, an apparently benign retrieval operation can change system behavior.
Validation itself can fail. Benchmark data may be contaminated by training data; evaluation sets may not represent actual use; human reviewers may disagree; automated evaluators may introduce their own bias; and a vendor may change the underlying model after validation.
If an LLM is used as a judge, the evaluation becomes a model-dependent measurement:
\[\widehat{Performance} = J_{\phi}(Y,Reference,Criteria),\]
where \(J_{\phi}\) is itself a model. The validator must therefore assess the reliability, bias, and limitations of the judging mechanism rather than treating its score as ground truth.
Validation has a defined boundary. Independent validation can assess conceptual soundness, implementation, performance, robustness, security, and limitations within an approved use case and test environment, but it cannot by itself prevent every misuse, malicious user action, or future system change. Effective GenAI model-risk management therefore requires validation to operate together with production monitoring, access controls, incident management, change management, and business accountability.
Governance risk arises when ownership, approval authority, escalation, human accountability, documentation, change control, or third-party responsibilities are unclear. GenAI can make accountability particularly ambiguous because multiple parties may contribute to one system: foundation-model provider, cloud provider, application developer, data owner, business owner, validator, cybersecurity function, and end user.
A sound governance design should make clear that automation does not transfer accountability to the model.
A GenAI application’s behavior may change because of model-version upgrades, prompt changes, RAG updates, new tools, modified permissions, new user populations, or feedback-driven adaptation. True recursive self-improvement (RSI) is a more advanced special case and should not be confused with ordinary system evolution.
A later section of this chapter will formalize a validation boundary. For Part I, the key insight is:
\[Risk_{t + 1} \neq Risk_{t}\quad\text{even if}\quad W_{t + 1} = W_{t},\]
where \(W_{t}\) denotes model weights. This is why change management and continuous monitoring are integral to GenAI MRM.
Recursive self-improvement (RSI) refers to a system that can materially modify its own models, prompts, tools, policies, code, or learning process in ways that increase or alter its future capabilities with limited human intervention. Most current enterprise GenAI applications do not exhibit unrestricted RSI; ordinary vendor upgrades, prompt revisions, RAG refreshes, and human-controlled fine-tuning should not be mislabeled as self-improvement.
From an MRM perspective, the relevant risk is not the label but the degree of adaptive autonomy. As systems gain the ability to propose, test, deploy, or retain changes, traditional point-in-time validation becomes less sufficient. Controls should therefore address authorization of self-modification, separation between experimentation and production, immutable audit logs, rollback capability, bounded permissions, pre-deployment testing, post-change monitoring, and explicit human approval for material changes.
A useful conceptual decomposition is:
R_adaptive = f(A_change, P_deploy, O_oversight, V_rollback, M_monitoring)
where A_change is the system’s authority to generate changes, P_deploy is its permission to deploy them, O_oversight is the strength of human oversight, V_rollback is reversibility, and M_monitoring is the effectiveness of post-change detection. Risk increases when change and deployment authority expand faster than oversight, reversibility, and monitoring.
Table 2. GenAI risk taxonomy and control map
| Risk category | Illustrative failure | Primary control | Validation evidence |
|---|---|---|---|
| Scope/boundary | RAG/tool omitted from inventory | System architecture + lineage | End-to-end inventory reconciliation |
| Data | Stale, biased, copyrighted, poisoned data | Provenance, curation, access control | Data lineage and sampling tests |
| Model | Hallucination / poor reasoning | Model selection, tuning, guardrails | Independent task and stress testing |
| Usage | Use outside approved purpose | Use restrictions + training | Use-case testing and usage monitoring |
| Output | False citation / unsupported claim | Grounding + human verification | Factuality and groundedness testing |
| Security | Prompt injection triggers tool action | Least privilege + isolation | Red-team/adversarial tests |
| Validation | Benchmark contamination | Independent evaluation design | Contamination and representativeness review |
| Governance | No accountable owner | Roles, approval, escalation | Governance/documentation review |
| Dynamic change | Vendor upgrade changes behavior | Versioning + change triggers | Regression testing/revalidation |
Data risk is not a preliminary step that ends when training is complete. In GenAI, data enter throughout the lifecycle and can alter behavior at inference time. The data-risk framework must therefore cover both development data and dynamic runtime data.
A simplified sequence of data stages across the GenAI system lifecycle is:
\[Acquire \rightarrow Select \rightarrow Transform \rightarrow Train/Adapt \rightarrow Validate \rightarrow Retrieve \rightarrow Generate \rightarrow Monitor \rightarrow Feedback.\]
Each transition creates different risks and controls. Pre-training may involve internet-scale corpora. Fine-tuning may use smaller proprietary datasets. RAG may introduce internal documents minutes before inference. User prompts may contain confidential information. Feedback may later become training or evaluation data.
The MRM data inventory should therefore classify data by purpose and lifecycle stage, not merely by database or file location.
At minimum, a GenAI system may use:
For each source, provenance should answer: Who created it? Under what rights? When? For what purpose? How was it collected? What transformations were applied? What population does it represent? Can it contain sensitive or prohibited information? Can it be changed, and by whom?
A practical lineage record can be represented as
\[L(d) = \{ source,owner,time,rights,transformations,version,controls,use\}.\]
If these attributes cannot be established for material data, the uncertainty itself should be treated as a model-risk limitation.
Data treatment can include deduplication, normalization, language identification, quality filtering, PII detection/removal, toxicity filtering, copyright filtering, document parsing, chunking, and metadata creation. Every transformation can improve one risk dimension while degrading another.
For example, aggressive deduplication can reduce memorization but may remove legitimately repeated evidence. PII filtering can reduce privacy risk but may impair use cases that require authorized customer identifiers. Document chunking can improve retrieval efficiency but destroy context if chunks are too small.
Therefore transformations should be governed as model-relevant design choices, not invisible preprocessing.
A student does not need deep AI training to understand the basic mechanism. Text is first converted into tokens. Each token \(x_{i}\)can be mapped to a numerical representation:
\[x_{i} \rightarrow e_{i} \in \mathbb{R}^{d}.\]
Here, xᵢ denotes token i and eᵢ is its d-dimensional embedding vector. An embedding is a learned numerical representation: tokens that are useful in similar linguistic or semantic contexts tend to occupy related regions of the vector space. The embedding is not a human-assigned meaning score; it is a high-dimensional representation learned from data and subsequently transformed by the Transformer as context is processed.
For RAG, a query and candidate documents may be embedded into a common vector space. A common similarity measure is cosine similarity:
\[\cos\left( e_{q},e_{d} \right) = \frac{e_{q}^{\top}e_{d}}{\parallel e_{q} \parallel \, \parallel e_{d} \parallel}.\]
In the cosine-similarity equation, e_q is the embedding of the query and e_d is the embedding of a candidate document or chunk. The numerator e_qᵀe_d is their dot product, while the denominator normalizes by their vector lengths. Cosine similarity therefore measures the angle between the two vectors: values closer to 1 indicate stronger directional similarity. In RAG, it is commonly used as one signal for ranking which document chunks are semantically closest to the query.
A retrieval engine may rank documents by this score and pass the top-k chunks to the LLM. This introduces several data risks: the embedding model may not capture domain meaning; chunking may separate key facts; metadata filters may fail; relevant documents may not rank highly; and malicious documents may be retrieved.
Thus, even if the LLM itself is unchanged, a poor embedding or retrieval design can materially alter output quality.
Traditional data-quality dimensions remain relevant:
accuracy, completeness, consistency, timeliness, uniqueness, and validity.
GenAI requires additional dimensions:
provenance, legal right to use, privacy, copyright/IP, toxicity, bias/fairness, contamination, semantic relevance, adversarial integrity, and temporal currency.
NIST AI 600-1 emphasizes that GenAI risks arise across the lifecycle and that organizations should govern, map, measure, and manage risks associated with data, models, systems, and use. [3] OWASP separately highlights data and model poisoning: manipulated pre-training, fine-tuning, or embedding data can introduce vulnerabilities, backdoors, bias, or degraded performance. [6]
A dataset can be “high quality” for one purpose and inappropriate for another. A ten-year archive of credit policies may be complete and accurate as a historical record but dangerous as a RAG source for current policy advice if superseded documents are not filtered. Data quality must therefore be assessed relative to intended use:
\[DQ = f\left( \text{data properties},\text{use case},\text{time},\text{controls} \right).\]
GenAI data controls must consider not only statistical quality but also whether the organization has the right and authority to use the data. The EU AI Act illustrates this shift by requiring GPAI providers to implement copyright policies and publish training-content summaries, with technical documentation requirements intended in part to help downstream providers understand model capabilities and limitations. [7,8]
For a financial institution, data controls should address at least: customer privacy; confidential supervisory or business information; contractual restrictions; intellectual-property rights; record retention; cross-border data restrictions; fair-lending/fairness concerns where applicable; and unauthorized inclusion of secrets, credentials, or personally identifiable information.
These controls should apply to prompts and RAG data as well as training data. Sensitive information can enter an LLM application at inference time even when the foundation model was trained appropriately.
For traditional predictive models, distribution shift is often expressed as
\[P_{train}(X) \neq P_{production}(X).\]
GenAI adds an important evaluation mismatch:
\[P_{\mathrm{benchmark}}(X) \neq P_{\mathrm{actual\ user\ prompts}}(X).\]
A model may perform well on polished benchmark questions but poorly on ambiguous, multilingual, abbreviated, adversarial, or domain-specific production prompts. Representativeness should therefore be assessed at several levels: subject matter, language, user population, task complexity, risk severity, time period, and adversarial behavior.
For consequential applications, validation sets should deliberately overweight rare but high-impact cases, rather than simply matching average production frequency.
RAG creates a major change from conventional model development: information can enter the model’s effective decision context after validation and immediately before generation.
A simplified RAG process is
\[q \rightarrow E(q) \rightarrow \operatorname{Retrieve}(D,k) \rightarrow C(q) \rightarrow \operatorname{LLM}(q,C(q)) \rightarrow y.\]
>In this flow, q is the user query; E(q) is its embedding; D is the authorized document corpus; k is the number of retrieved items; Retrieve(D,k) selects the top-ranked relevant chunks; C(q) is the context assembled from those retrieved chunks; and y is the generated answer. The important MRM point is that the LLM does not operate on q alone: its effective input includes dynamically retrieved information, so retrieval quality and authorization become part of model performance and control.
The control environment should address:
A useful control principle is retrieval least privilege: the system should retrieve only information that the user and use case are authorized to access. The LLM should not become a mechanism for bypassing existing data-entitlement controls.
The classical requirement is conceptual independence among development and evaluation data:
\[D_{train} \cap D_{test} = \varnothing.\]
For foundation models, proving this condition can be difficult. Public benchmarks, books, websites, code repositories, and question-answer sets may have appeared directly or indirectly in large pre-training corpora. Near-duplicates may exist even when exact records differ.
This creates benchmark contamination risk: apparent performance may reflect memorization or prior exposure rather than generalization.
A stronger conceptual condition is therefore needed:
\[Information\left( D_{validation};D_{train} \right) \approx 0\]
for the information specifically needed to answer the validation task. In practice, perfect independence may be impossible to prove, so validators should use multiple defenses: private holdout sets; newly created questions; time-based holdouts; paraphrased and counterfactual variants; canary items; contamination searches; and production-like challenge sets.
Memorization occurs when the model reproduces or relies heavily on specific training examples. Generalization occurs when learned structure supports correct behavior on materially new examples.
A simple conceptual test is:
\[\mathrm{Generalization\ Gap}=\mathrm{Performance}_{\mathrm{train-like}}-\mathrm{Performance}_{\mathrm{novel}}.\]
A large gap can indicate overfitting, contamination, or insufficient generalization, although interpretation requires care because task difficulty may also differ.
For a material GenAI application, the MRM file should contain sufficient evidence to reconstruct the data environment. At minimum, this should include data-source inventory and lineage; ownership and access rights; transformation documentation; RAG corpus/version controls; privacy/IP/compliance assessment; representativeness analysis; training/test/validation separation methodology; contamination assessment; known data limitations; and monitoring/escalation triggers.
The objective is not to demand impossible transparency from every foundation-model provider. The objective is to identify what is known, what is unknown, how material the uncertainty is, and what compensating controls are necessary.
Proposed MRM principle 2 — Data uncertainty principle. Lack of visibility into foundation-model training data does not make data risk disappear. It converts part of the risk from a directly testable exposure into model uncertainty, which should be documented, challenged, bounded through independent testing, and reflected in use restrictions where appropriate.
Consider an internal GenAI assistant used by bank employees to answer questions about current credit policy. The foundation model is supplied by a third party; the bank adds a system prompt and retrieves policy documents from an internal vector database. This simple application illustrates why GenAI data risk is continuous rather than confined to model training.
Suppose the authorized corpus D contains both the current policy d_current and an obsolete policy d_old. For a user query q, the retrieval layer ranks chunks by a similarity score such as
s(q,d) = [E(q)ᵀE(d)] / [‖E(q)‖ ‖E(d)‖]
If d_old is semantically closer to the wording of q, it may rank above d_current even though it is no longer valid. The LLM may then produce a fluent, well-grounded answer that is nevertheless wrong from a business and compliance perspective. The failure is not necessarily a defect in the foundation model; it can arise from document governance, metadata, retrieval ranking, or missing effective-date filters.
The end-to-end control objective can be expressed conceptually as
P(acceptable answer) = P(authorized retrieval) × P(relevant/current context | retrieval) × P(correct generation | context) × P(effective verification)
The multiplicative form is illustrative rather than a literal independence assumption. Its purpose is to show that strong model performance cannot compensate fully for weak data authorization, stale retrieval, or absent verification. Validation should therefore test the entire chain: corpus governance, metadata and entitlement filters, retrieval precision/recall on policy questions, stale-document challenges, citation traceability, answer factuality, and escalation when sources conflict.
Example control evidence: (1) approved corpus inventory and owners; (2) document effective dates and retirement rules; (3) embedding and index version; (4) retrieval test set with known relevant sources; (5) entitlement tests; (6) adversarial/poisoned-document tests; (7) answer-to-source citation checks; and (8) monitoring for retrieval drift and policy updates.
Part I establishes three conclusions that will carry through the remainder of the chapter.
First, GenAI MRM should govern the risk-bearing AI system, not only the foundation model. Prompts, retrieval, tools, guardrails, users, and changing data can materially alter behavior.
Second, GenAI risk is multidimensional. Traditional model risk remains relevant, but it must be extended to include output factuality, prompt/context sensitivity, security, data provenance, third-party opacity, dynamic change, and potentially agency.
Third, data risk persists throughout the lifecycle. Training data matter, but so do fine-tuning data, evaluation data, RAG corpora, user prompts, tool outputs, and feedback. In GenAI, data governance and model governance become deeply intertwined.
Part II will build on these foundations by explaining the technical development of LLM systems and then constructing a GenAI validation framework covering conceptual soundness, independent testing, hallucination and groundedness, prompt-sensitivity testing, RAG validation, robustness, security, privacy, effective challenge, implementation controls, and the proposed GenAI Validation Vector.
The chapter’s central organizing idea—the risk-bearing AI system as the principal MRM object—is strong and should remain the anchor for Parts II and III.
The traditional-ML comparison is retained because it provides an important bridge from conventional MRM to GenAI. To avoid diluting the GenAI focus, it should remain concise and be used mainly to show continuity in pipeline and implementation risk.
The validation section now states the validation boundary more explicitly: validation is necessary but cannot, by itself, control malicious use, misuse, or future system change. Monitoring and operational controls are complementary rather than substitutes for validation.
Recursive self-improvement is added as a distinct advanced risk topic, but the text distinguishes it from ordinary vendor updates, RAG refreshes, prompt changes, and human-controlled fine-tuning.
Section 3.1 is renamed “Data stages across the GenAI lifecycle” to address the concern that the original sequence described stages rather than a literal birth-to-death lifecycle.
A worked RAG policy-assistant example is added to Section 3 to connect provenance, metadata, retrieval, stale data, entitlements, validation, and monitoring in one end-to-end case.
Reference 2 appears potentially overlapping with Reference 1. Before publication, verify whether it is a distinct interagency document and, if not, consolidate the two citations. This V4 leaves both references in place rather than guessing at the intended source.
For publication quality, all displayed equations should be maintained as Word equation objects (OMML) or regenerated from the corresponding LaTeX source so symbols remain editable and searchable.