Southern Bancorp

How corporate risk teams should update vendor due diligence and model validation now that AI is embedded in nearly every enterprise service. Almost every enterprise vendor now ships AI inside their product, often without saying so on the contract. A scheduling tool quietly added a generative summarizer. A managed-detection provider routes alerts through a proprietary classifier. A spreadsheet add-in calls a third-party LLM behind the scenes. Third-party risk programs built for traditional SaaS were not designed to surface these dependencies and the model risk frameworks banks have relied on for a decade need to stretch to cover them. Two reference points should anchor the refresh: the NIST AI Risk Management Framework (AI RMF 1.0) and its Generative AI Profile (NIST AI 600-1) and the MIT AI Risk Repository, a database of more than 1,700 documented AI risks organized across seven domains. Together they give risk teams a defensible structure for what to ask and a catalog of what could go wrong.

Updating Third-Party Risk Assessments for Ai Services

The first move is to add AI-specific questions to every vendor intake — not as a separate "AI questionnaire" that lives in a parallel process, but as required fields inside the existing TPRM workflow. Align the questions to the NIST AI RMF’s four functions (Govern, Map, Measure, Manage) so vendor responses map cleanly to internal governance and use the MIT AI Risk Repository’s seven-domain taxonomy, covering everything from discrimination and privacy to misuse, misinformation and AI system failures, as a checklist to make sure no risk class is overlooked. At a minimum, the assessment should establish:

• Purpose and function. What does the AI do, (e.g., content generation, decisioning, anomaly detection, automation, customer interaction) and is its output material to a regulated process?

• Model provenance. Is the model proprietary, open source or a wrapped third-party model? Sub-processor disclosure now must extend to the model layer.

• Training and tenancy. Is customer data used to train or fine-tune the model?Can you opt out? Is the environment isolated or shared?

• Input and output controls. DLP, prompt-injection defenses, output filtering and human-in-the-loop checkpoints for high-impact decisions.

• Bias, accuracy and drift management. How is the model tested pre-release, monitored in production and retrained when performance degrades?

• Transparency and contestability. Can the vendor explain a decision to a regulator, auditor or affected customer?

Two practical changes follow. First, tier vendors by AI risk, not just by data sensitivity. A low-data vendor making automated decisions may carry more risk than a high-data vendor doing static reporting. Second, refresh contracts to add AI-specific reps and warranties, restrictions on training with corporate data, notice when a vendor introduces new AI capabilities and audit rights that reach the model layer.

"What changes is what "model" means and how often the underlying behavior shifts. Ai systems update more frequently, depend on data pipelines that change without notice and are often hosted by third parties whose internals are not directly observable."

Criteria for Model Risk Reviews in the age of Ai

In baking, model risk management guidance, long anchored in supervisory expectations under SR 11-7 and recently updated SR 26-2 and OCC 2026-13 for sound development, independent validation and strong governance, still works. What changes is what "model" means and how often the underlying behavior shifts. AI systems update more frequently, depend on data pipelines that change without notice and are often hosted by third parties whose internals are not directly observable. NIST AI 600-1 translates these realities into controls across the Govern, Map, Measure and Manage functions and ISO/IEC 42001:2023 offers a certifiable management-system layer on top. Reviews should be calibrated accordingly:

• Effective challenge. Independent reviewers, separate from developers and business owners, critically test inputs, assumptions and outputs — including for vendor-supplied models.

• Conceptual soundness. Document the logic, training methodology and known limitations. For opaque thirdparty models, demand model cards and evaluation results.

• Independent validation. Formal, periodic, documented review proportional to materiality.

• Outcomes analysis. Compare model output to actual results on a defined cadence, not just at go-live.

• Data integrity. Verify accuracy, lineage and relevance of training and inference data, including for fine-tuned and Retrieval-Augmented Generation (RAG) systems.

• Continuous monitoring. Track performance, data drift and stability to catch changes before they create harm.

• Vendor model assessment. Validate third-party models as rigorously as internal ones; document every customization, prompt template and guardrail.

• Governance. Maintain a model inventory that includes embedded vendor models, with oversight tiered to materiality.

What this Looks Like in Practice

Two artifacts make the frameworks above operational. Start with a lightweight AI inventory. A single tracker, owned by the risk function, with one row per AI system or embedded AI capability. At minimum, capture:

• Tool / system name, vendor and deployment type (cloud, on-prem, hybrid, desktop)

• AI capability type (generative, predictive, agentic, classification) and primary purpose

• Business owner and technical owner • Risk tier, data types used and retention treatment

• Approved use cases, approval date and status (active, POC, in review, retired)

Pair the inventory with an AI Working Group, (a standing cross-functional body (risk, security, compliance, IT, legal and an executive sponsor) that reviews new AI use cases against the questionnaire and decides go / no-go, POC or conditional approval. The inventory feeds the AIWG agenda; the AIWG’s decisions update the inventory. That loop is what governance actually looks like once the frameworks are off the page.

AI does not require a new risk discipline so much as a more rigorous application of the ones that already exist, mapped against authoritative references. Refresh the vendor questionnaire against the NIST AI RMF and MIT taxonomies, document the inventory, update contracts and adapt model risk management to cover the systems your vendors are already running on your behalf. The frameworks are sound; the scope just needs to catch up.