← Back to Concept Contrast

Concept Contrast Fable

AI risk management and model risk management

Conclusion first:One governs the troubles that may arise after the entire AI system is deployed, and the other governs the risks of the model itself during development, validation, and deployment. The two boxes are drawn at different sizes, and the requirements placed on vendors differ as well.

One governs the troubles that may arise after the entire AI system is deployed, and the other governs the risks of the model itself during development, validation, and deployment. The two boxes are drawn at different sizes, and the requirements placed on vendors differ as well.

Fable

Two safety ledgers

Old Xu's workshop built a new vehicle that could steady its own direction. Before delivery, the city inspector handed over two booklets: one for checking the vehicle's core, one for checking the whole vehicle on the road. Old Xu saw that both looked like safety checks, so he had his apprentice copy the same set of answers.

Three days later, the booklet was returned. The section on the axle passed for the most part: whether the copper wheels would slip in the rain, whether the steering rod drifted on different slopes, whether the test records covered both heavy and empty loads. The other section, however, was covered in red circles.

What the vehicle inspector pressed on was the whole arrangement after it hits the road: who can drive, who holds the keys, where the passenger roster is kept, whether the repair shop can peek at trips, who disables it first in an accident, and who patrols the garage at night.

Only then did Old Xu realize that he had been treating the engine as the whole car. No matter how well the engine is tuned, a leaking fuel line, an unlocked door, or a driver secretly taking side jobs will all turn a good car into trouble.

He first wanted to merge the two ledgers into one to avoid duplication. The old vehicle inspector stopped him: merging makes it easy to miss things. Checking the vehicle's core requires looking at materials, tests, deviations, and failure boundaries; checking roadworthiness requires looking at people, roads, keys, logbooks, outsourced repairs, and incident handling.

The workshop re-verified everything. The vehicle core register recorded the performance and weak road conditions of each test run; the whole-vehicle register mapped the full chain from accepting orders, carrying passengers, bookkeeping to maintenance. Overlapping areas were marked with double seals, and who was responsible was also written clearly.

Later, a peer asked Old Xu for his secret. Old Xu pointed to the two ledgers and said: first check whether the heart is stable, then check whether the whole vehicle could hurt people, leak accounts, or go out of control. The former governs the component itself; the latter governs the entire risk that arises once the component is placed into the business.

Old Xu later told his apprentice that the two booklets overlap but cannot swallow each other. A failure of the vehicle core will cause the whole vehicle to fail, and chaos in whole-vehicle management will also amplify small deviations in the vehicle core. Recording them separately is to let each type of problem find its true owner, rather than covering for each other in one big table. The vehicle inspector also reminded him that the more the workshop resembles a business, the thicker the second booklet becomes; the more complex the vehicle core, the less the first booklet can be omitted. Only by looking at both booklets together can the vehicle truly go on the road. Later, during the review, everyone wrote this lesson into daily rules: first look at where the site truly changed the result, then decide what to keep, repair, or restrict. If you look only at surface excitement, you will fall in the same place next time.

AI risk management

A risk governance framework covering the full lifecycle of AI systems, including data governance, model risk, deployment security, third-party dependencies, user privacy, compliance auditing, and operations standards. Its scope is far larger than a single model.

Model Risk Management (MRM)

Focuses on risks during model development, validation, deployment, and monitoring, including training data quality, model bias, overfitting, explainability, and performance degradation. It is a subset of AI risk management.

Story Mapping

  • System security assessment form: AI risk management, covering the entire chain.
  • Model risk assessment form: model risk management (MRM), covering only the model itself.
  • Unmasked logs exposing user data: this falls within the scope of AI risk management; model risk assessment does not detect it.
  • Cross-reference table (checks and circles): a coverage relationship diagram of the two frameworks.
  • Look at the engine first, then the whole vehicle: MRM comes first, AI risk management comes after, but AI risk management has a broader scope.

In the project

In supplier security questionnaires and internal audits, first use the MRM framework to check the model itself item by item—training, validation, and bias. Then use an AI risk management framework to inspect the entire chain—from data intake, API gateway, and log storage to operational permissions. The two frameworks each have corresponding international standards (for example, MRM references SR 11-7 or OCC guidance, and AI risk management references NIST AI RMF or ISO 42001). Do not treat them as two ways of describing the same questionnaire.

京ICP备2026014272号