Table of Contents
Summarize and analyze this article with
Chat GPT
Perplexity
Grok
Google AI
Claude
Why you cannot get inherent risk by subtraction
Here is a question that arrives once a register matures: our AI register scores every system after controls are applied, and someone has started asking what the risk was before them. Can one inventory answer both? Yes, but not by subtraction. Where a register stores only the post-control rating, the control effect was never held as a value that can be added back; it was applied inside a scoring rubric and then discarded. Producing an inherent rating means recording two ratings and the evidence for the distance between them, which is a schema change rather than a reporting change. The work is small if it is done deliberately and large if it is done in a hurry.
The question became concrete in insurance when the National Association of Insurance Commissioners exposed version 5.0 of its AI Risk Evaluation Supplement for comment following its 31 August 2026 working-group meeting, with a 30-day comment period ending 29 September 2026. The NAIC summary of changes states that regulators are focused on the consideration of inherent risk, meaning the risk before the consideration of mitigating controls. That is an exposure draft: it has not been adopted, is not in force, and imposes no obligation on any insurer. The NAIC separately states that as of March 2026 the tool is being piloted by 12 participating states, with adoption anticipated at the Fall National Meeting, so the question is worth answering ahead of the answer being requested.
Store the two ratings as separate fields
Add an inherent rating and a residual rating as distinct persisted fields on the system record, each with its own rubric version and its own assessment date. Do not compute one from the other at read time. The two ratings age differently: an inherent rating changes when the use case, the data, or the decision authority changes, while a residual rating changes whenever a control is added, degraded, or retired. A register that derives one from the other will silently restate history every time a control is updated.
| Field | What to store | Why it matters |
|---|---|---|
| inherent_rating | Rating before controls, with its own rubric version and assessment date | Changes only when the use case, data, or decision authority changes |
| residual_rating | Rating after controls, with its own rubric version and assessment date | Changes whenever a control is added, degraded, or retired |
| Inherent inputs | Decision type, population affected, consequence if wrong, human position | Scored from the decision, never from the vendor or model family |
| Control delta | Controls credited, each with library ID, last test date, result, owner | The evidence for why the residual rating is lower |
| Materiality threshold | The inclusion rule, with the threshold version stored on each record | Defines what is in the inventory, applied mechanically and stated on request |
Make the inherent rating independent of who built the system
Inherent risk is a property of what the system decides and about whom, not of who supplied it. Score it from four attributes on the record: the decision type, the population affected, the consequence if the output is wrong and acted on, and whether a person is positioned in the process before the consequence lands. None of those four should reference the vendor, the model family, or the hosting arrangement. A bought system and a system built in house that make the same decision about the same population carry the same inherent rating, and that equivalence is the entire reason the rating is useful to someone reviewing from outside.
Record the control delta as evidence, not arithmetic
Between the two ratings sits a list. For each system, store the controls credited for the reduction, and for each control store its identifier in the control library, its last test date, its last test result, and the owner. That list is the answer to the only follow-up question a reviewer reliably asks, which is why the residual rating is lower. An untested control that still appears in the credited list is the finding, and finding it yourself is considerably cheaper than having it found.
Set and disclose your materiality threshold
An inventory that includes every script anyone has ever called a model becomes unreviewable, and one that includes only production systems with executive sponsorship will be judged incomplete. Write the threshold down as a rule, apply it mechanically, store the threshold version on each record, and be ready to state it. A threshold you can articulate and defend is a strong position. A threshold that emerged from whoever happened to fill in the spreadsheet is not a threshold.
What usually goes wrong
- Retroactive scoring : The inherent rating is assigned months later by someone reading the residual rating and adding a level or two, producing a column uniformly one step above another column. That is transparently an artifact, not an assessment.
- Third-party systems never get an inherent rating: The assessment template opens with questions about model development that the vendor will not answer. The fix is to score inherent risk from the decision rather than the build, which is why the vendor-independent scoring above comes first.
Where PiTech fits
PiTech Solutions helps regulated organizations build AI inventories that hold up when someone outside the organization reads them: the two-rating schema, decision-based inherent scoring that works for bought and built systems alike, a control-delta record tied to a tested control library, and a documented materiality threshold. The result answers a reviewer in one export rather than in six weeks of reconstruction. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. See AI, GenAI and ML, Data Solutions, and Process Solutions. PiTech Solutions Inc. is headquartered in Durham, North Carolina (UEI GNLRY5LNNVH6, CAGE 530K4) and is distinct from similarly named companies.
The bottom line
An inventory that records both ratings, the controls credited between them, and the threshold that governs inclusion answers a reviewer in one export. Store the two ratings as separate fields, score inherent risk from the decision, and hold the control delta as tested evidence.
Frequently Asked Questions (FAQs)
What is inherent risk in an AI inventory?
Inherent risk is the risk of an AI system before mitigating controls are considered, as distinct from residual risk, which is the risk that remains after controls are applied. In an AI inventory, inherent risk reflects what the system decides and about whom, judged from the decision type, the population affected, the consequence if the output is wrong and acted on, and where human review sits. It is a property of the use case, not of the vendor or model. Regulators, including in the NAIC’s exposed AI Risk Evaluation Supplement, have signalled a focus on inherent risk, which is why registers that store only a post-control rating are increasingly being asked a question they cannot answer.
Why can't I calculate inherent risk from my residual rating?
Because the control effect was never stored as a value that can be added back. When a register scores a system after controls, the reduction from controls is applied inside the scoring rubric and then discarded, so there is no recorded quantity to reverse. Deriving an inherent rating by adding a level or two to the residual rating produces an artifact, not an assessment, and it typically shows up as a column uniformly one step above another column. Recovering inherent risk properly means recording it as its own rating, scored independently from the decision, alongside the residual rating and the evidence for the distance between them. That is a schema change, not a calculation.
What is the difference between inherent and residual risk?
Inherent risk is the risk before controls; residual risk is the risk after controls. They answer different questions and age differently. An inherent rating changes when the use case, the data, or the decision authority changes, because those determine what the system decides and about whom. A residual rating changes whenever a control is added, degraded, or retired, because controls determine what risk remains. Storing them as separate fields, each with its own rubric version and assessment date, keeps both histories accurate. Deriving one from the other collapses that distinction and silently rewrites history every time a control is updated, which undermines the audit trail an inventory exists to provide.
How do I score inherent risk for a third-party AI system?
Score it from the decision, not the build. Third-party inherent ratings often go missing because the assessment template opens with questions about model development that the vendor will not answer. The fix is to rate inherent risk from four attributes you can observe without vendor cooperation: the decision type, the population affected, the consequence if the output is wrong and acted on, and whether a human is positioned before the consequence lands. None of these reference the vendor, model family, or hosting. A bought system and an in-house system that make the same decision about the same population carry the same inherent rating, which is exactly what makes the rating meaningful to an outside reviewer.
What is the control delta in an AI inventory?
The control delta is the recorded list of controls credited for reducing a system’s risk from its inherent rating to its residual rating. For each credited control, store its identifier in the control library, its last test date, its last test result, and its owner. The control delta is the evidence that answers the reviewer’s reliable follow-up question: why is the residual rating lower than the inherent rating. Storing it as tested evidence rather than as arithmetic means the reduction is defensible. An untested control still appearing in the credited list is itself a finding, and discovering it internally is far cheaper than having an examiner discover it during a review.
What is a materiality threshold for an AI inventory?
A materiality threshold is the rule that governs which systems are included in the inventory. Set too low, it captures every script anyone ever called a model and the inventory becomes unreviewable; set too high, it captures only executive-sponsored production systems and the inventory is judged incomplete. The threshold should be written down as a rule, applied mechanically, versioned, and stored on each record, so you can state and defend it on request. A threshold you can articulate is a strong position; one that emerged from whoever filled in the spreadsheet is not a threshold. Recording the threshold version per record also lets the inventory show how inclusion decisions were made over time.
Is the NAIC AI Risk Evaluation Supplement in force?
No. As of this writing, version 5.0 of the NAIC AI Risk Evaluation Supplement is an exposure draft, circulated for comment following the Big Data and Artificial Intelligence Working Group’s 31 August 2026 meeting, with a comment period ending 29 September 2026. It has not been adopted, is not in force, and imposes no obligation on any insurer. The NAIC has stated that the tool is being piloted by 12 participating states and that adoption is anticipated at the Fall National Meeting, so its direction, including a focus on inherent risk, is a strong signal of where examination expectations are heading. Insurers should confirm the current status directly, as the draft and its timeline may change.
How much work is it to add inherent risk to an existing register?
It is a schema change rather than a reporting change, so the effort depends on doing it deliberately. Adding two persisted rating fields, defining a decision-based inherent-scoring rubric, standing up a control-delta record tied to a tested control library, and writing down a versioned materiality threshold is a contained piece of work when planned. It becomes large and error-prone when attempted in a hurry under an examination request, because retroactive scoring and missing third-party ratings creep in. Doing it ahead of demand, in the order of scoring inherent risk from the decision first, keeps the change small and produces an inventory that answers a reviewer in one export rather than weeks of reconstruction.
Does this apply outside insurance?
Yes. The NAIC supplement made the question concrete for insurers, but the underlying principle, that a register scoring only post-control risk cannot produce inherent risk by subtraction, applies to any regulated organization maintaining an AI inventory. Banking, healthcare, and finance functions face equivalent expectations that they can show both what a system’s risk was before controls and what remains after, with evidence for the difference. The two-rating schema, decision-based inherent scoring, control-delta evidence, and documented materiality threshold are portable across sectors. The specific trigger differs by industry, but the inventory design that answers an outside reviewer cleanly is the same wherever the review comes from.
Does PiTech build AI inventories?
Yes. PiTech Solutions helps regulated organizations build AI inventories that hold up when someone outside the organization reads them: the two-rating schema with separate inherent and residual fields, decision-based inherent scoring that works for bought and built systems alike, a control-delta record tied to a tested control library, and a documented, versioned materiality threshold. The result answers a reviewer in one export rather than six weeks of reconstruction. Delivery runs under CMMI Level 3 and ISO 27001, 9001, and 42001 certifications. PiTech is positioned as a specialist partner for AI governance and inventory design in regulated industries at a mid-market price.