Building AI Systems That Survive an Exam

Source note: The patterns below are how Nolte builds and audits AI-enabled insurance systems, drawn from our delivery work across MGAs, insurtechs, and claims platforms. No single client is described. The reference framework is the pending NAIC AI Risk Evaluation Supplement and its 12-state pilot.

The premise

The Supplement does not ask whether you have AI. It asks you to produce, per model, a version number, an implementation date, a risk classification, a validation method, a last test date, the data elements and their sources, and how the model is monitored on an ongoing basis (Exhibit C refs 1 to 9; Exhibit D). Then it asks the carrier to describe its oversight of the MGAs using those models (Exhibit B Q4).

Every one of those is an artifact. An exam is a request for artifacts. So the build question is not “how do we govern AI” but “which artifact does each production behaviour leave behind, and can we produce it without asking an engineer to go look.”

That reframes governance as an engineering property. What follows is the set of controls that produce the artifacts, what each one costs, and what happens without it.

What we keep finding

Before any of these controls gets built, Nolte audits the estate. Nothing changes in production during the audit; that is written into the spec. Across engagements the same findings recur, and none of them is unusual. Most are the normal state of a product built fast by a small team and then handed between vendors. The point is that against Exhibit C, every one is an unanswerable question.

• Decision parameters hard-coded in the application and changed without review or alerting. Iteration limits, confidence thresholds, temperature. These are the values that decide the outcome of a claim or a quote. Nothing distinguishes a threshold change from any other commit, and nothing alerts anyone when one lands.
• Production prompts living in a prompt-management SaaS that appears in no vendor register. A prompt is runtime configuration: edit it and the system decides differently, immediately, with no deploy.
• Configuration and tokens binding at application startup. A value changed in the parameter store is not live until the consuming service restarts. Anyone assuming a save is a change is wrong and finds out when something misbehaves.
• BI tools querying the production database directly, full access, no read replica, outside every pipeline. PII exposure with no audit trail.
• Schema migrations applying themselves on startup, shipped by the same pipeline as code. No human checkpoint between merge and execution against production. Hotfix branches cut from production tags drift the schema.
• No release version visible in production. Asked whether you can confirm what shipped, the answer is no.
• Rollback never rehearsed. Teams fix forward. Database snapshots are the safety net.
• Post-deploy verification as a manual smoke test. Open an incognito window and buy a policy.

“Last date of model testing.” “How the model is validated prior to deployment and monitored on an ongoing basis.” “Model version number.” You cannot answer these from an estate in this state, and the carrier cannot answer Exhibit B Q4 on your behalf.

The nine controls

Each control names the artifact it produces, the NAIC reference it satisfies, the build pattern, and the failure it prevents. They are ordered by dependency: you cannot do 4 without 2 and 3.

Control 1: The AI system register, as code

Artifact: one ai-system.yaml per AI system, in the repository, validated in CI. NAIC: Exhibit A (counts by operational area); Exhibit C refs 1 to 7, 10.

# ai-systems/claim-adjudicator.yaml
id: claim-adjudicator
name: Claims adjudication assistant
version: 2.4.1            # bumped on any prompt, param, or model change
operational_area: claims  # Exhibit A row
autonomy: augment         # support | augment | automate (Supplement definitions)
consumer_impact: direct
financial_impact: material
risk_class: high
risk_rationale: >
  Produces approve/deny recommendation on first-party claims up to the
  authority limit. Adverse outcome = wrongful denial or delay.
model:
  provider: <vendor>
  model_id: <model-id-pinned>
  origin: third_party
  retirement_date: 2026-12-15  # vendor deprecation date; CI fails as it nears
implemented: 2025-11-03
owner: <role, not person>
prompt_ref: prompts/claim-adjudicator/v2.4.1.md
params_ref: config/claim-adjudicator/v2.4.1.yaml
data_elements: [loss_experience, image_video_analysis, geocoding]  # Exhibit D categories
validation:
  method: internal        # internal | external | both
  last_test: 2026-08-15
  report: validation/claim-adjudicator/2026-08-15.md
monitoring:
  dashboard: <link>
  drift_threshold: approval_rate_delta > 8pp over 7d

Build pattern: a CI check fails the build if any code path calls a model provider without a register entry, if last_test is older than the review cadence, if model.retirement_date falls within the next review cycle, or if version did not change when prompt_ref or params_ref did. The retirement_date is read from the vendor’s deprecation page: vendors retire models on a schedule, and on that day the API call simply fails. The failing build forces a planned, tested migration instead of the rushed model swap Control 6 exists to prevent.

Failure prevented: the model nobody categorised as AI. Vendor-embedded models inside rented platforms go in the register too, with origin: third_party and the vendor named. Exhibit C ref 4 and Exhibit D column 5 both require the vendor name.

Cost: an afternoon per system to write. Near zero to maintain once CI enforces it.

Control 2: Prompts under version control

Artifact: every production prompt in the repository, reviewed by pull request, tagged with a content hash. NAIC: Exhibit C ref 1 (version), ref 8 (validated prior to deployment); checklist 3h (SDLC).

Build pattern:

1. Export the prompt set from wherever it lives (prompt-management SaaS, database, inline strings) into prompts/<system>/.
2. The application loads prompts from the repository artifact at deploy time, not from the SaaS at runtime. The SaaS becomes an authoring and evaluation tool, not the source of truth.
3. Every prompt file carries a SHA-256 in its header. That hash is logged on every decision (Control 4).
4. A prompt change is a pull request. Review is mandatory for risk_class: high. Merge bumps the register version.
5. If you must keep runtime prompt editing, the edit must emit a change event to the same log as a deploy, and the system must refuse to load a prompt whose hash is not in the register.
6. If the prompts must stay in the SaaS, an approval-gated promotion pipeline is a legitimate alternative artifact: a change opens a diff, an approval gates it, and only then does it apply, with the audit trail carried end to end and the diff and approval retained outside the tool, so the SaaS is still not the only copy. An examiner reads that trail the way they read a pull request.

Failure prevented: a prompt edited in a SaaS console at 4pm on a Friday changing claim outcomes with no artifact anyone can point to afterwards. This is the finding that made us reclassify prompts from “content” to “configuration”.

What this is not: it is not a ban on prompt tooling. It is a rule that the tool cannot be the only copy.

Control 3: Decision parameters as versioned, observable configuration

Artifact: a config file per system, per version, with a change log; a startup log line that prints the effective config and its hash. NAIC: Exhibit C ref 1, ref 8; Exhibit B narrative Q1d (how effectiveness is assessed and modified).

The parameters that decide outcomes (confidence thresholds, iteration caps, temperature, retry policy, authority limits, fallback behaviour) get the same treatment as prompts.

Build pattern:

• Config lives in the repository, not in a console. Console stores (parameter store, feature flag service, environment properties) are deployment targets written by infrastructure-as-code, never edited by hand.
• Startup binding is a first-class fact. On boot, the service logs the effective configuration and a hash of it. A config change that has not restarted the service is not live, and the log proves which config a given decision was made under. If the service hot-reloads config from a parameter store on a timer instead of only at boot, the same rule applies to every reload: emit the change event and log the effective-config hash, or a mistyped param goes live within minutes, and a deleted one silently reverts the service to its code default, which is only safe if that default fails closed.
• A flag or threshold that changes AI behaviour is a risk_class: high change and follows the same PR review as a prompt.
• Feature flags that gate AI paths are enumerated in the register. A flag flip emits a change event.

Failure prevented: two incidents in one. The silent edit (nobody knows the threshold moved), and the phantom edit (someone moved it and it never took effect).

Cost: moving values out of code and console into files is a day. The startup log is ten lines. The discipline is the cost.

Control 4: The decision record

Artifact: an append-only log, one row per AI decision, sufficient to reconstruct any single outcome. NAIC: Exhibit C ref 8 (monitored on an ongoing basis); checklist 3a, 3c, 3m; Exhibit B Q4a (testing and verification).

This is the control that turns telemetry into exam evidence. Without it, “ongoing monitoring” is a dashboard someone looks at. With it, you can answer “why was claim 41877 denied on 12 March” from the log alone.

Minimum schema:

decision_id        uuid
timestamp          utc
system_id          claim-adjudicator
system_version     2.4.1
model_id           <pinned model id>
prompt_hash        sha256
config_hash        sha256
input_ref          pointer to the input snapshot (not the raw PII)
input_hash         sha256 of the canonical input
output             structured decision (approve | deny | escalate)
confidence         float
autonomy_applied   support | augment | automate
human_action       none | accepted | overridden | escalated
human_actor        role id (not name)
tokens_in/out      int
cost_usd           decimal
latency_ms         int
trace_id           for cross-service correlation

Build pattern:

• Written by the same code path that returns the decision. If the write fails, the decision fails closed to human review.
• Append-only store, separate from the transactional database. Retention aligned to the longest applicable exam lookback in your states (the state tracker is the source).
• PII stays out of the log. Store hashes and pointers; the pointer resolves through the same access controls as the source record.
• Reconstruction is a test case in CI: pick a random decision, replay it from the log, assert the decision and customer-facing fields match (not the raw response or confidence, which vary between runs).

Failure prevented: the unanswerable complaint. A consumer complaint tagged to an AI decision (checklist 3m) with no way to show what the system saw and why it decided.

Control 5: Human-in-the-loop as an enforced authority model

Artifact: an authority-limit table in the register; routing code that enforces it; override rate in the decision log. NAIC: Exhibit A (augment vs automate classification); Exhibit B narrative Q1g (autonomy, reversibility); Exhibit C ref 7; checklist 3c.

The Supplement’s three-level definition (support, augment, automate) is not a label. It is a routing rule.

Build pattern:

• Declare per decision class: below limit X the system may automate; between X and Y it augments and a human accepts or overrides; above Y it supports only. The limits live in the register and the config, not in someone’s head.
• Adverse decisions (deny, decline, non-renew, adverse rate) route to augment at minimum, regardless of confidence. Approving automatically and denying with a human is a defensible asymmetry. The reverse is not.
• Every human action is logged (Control 4). Override rate is a monitored metric. A rising override rate is a model problem; a falling one with rising complaints is a rubber-stamp problem. Both are findings.
• Reversibility is designed: an automated decision has a documented undo path with a time bound.

Failure prevented: “augment” on paper, “automate” in practice, because the human queue is a formality nobody reads.

What we find: authority-limit rules encoded partly in schema, partly in code, partly in nobody’s memory. Until they are written down, the autonomy classification on Exhibit A is a guess. Documenting them is always its own delivery. And we find the asymmetry inverted in the wild: a hard cap on approvals, none on denials, with the adverse decision going straight to the customer. That is the exact inverse of the defensible asymmetry above.

Control 6: Validation and observability as a producing system

Artifact: a dated validation report per model per cycle; a live dashboard; alert rules with owners; the last_test field in the register auto-updated by the validation job. NAIC: Exhibit B Q3a, 3b, 3c (validation procedures, frequency, scope, methodology); Exhibit C ref 8, ref 9.

Build pattern:

• Pre-deployment: an evaluation suite runs in CI, or as a gated pre-release job with recorded runs, on every version bump. Golden set of labelled cases (including adverse and edge cases), assertion thresholds, and a bias check across the sensitive categories in Exhibit D you have declared. The suite’s output is committed as the validation report. A failing suite blocks the deploy.
• Production: metrics from the decision log, at minimum: decision volume by class, approval and denial rates, override rate, escalation rate, confidence distribution, latency, cost per decision, and distribution shift on declared input features. Drift threshold from the register triggers a review ticket, not just an alert.
• Periodic: a scheduled re-run of the evaluation suite against a fresh sample of production decisions, on the cadence your register declares. The job writes the report and updates last_test. That field is then always true.
• Vendor models: the same suite runs against the vendor model. Vendor attestation is an input to your validation, not a substitute for it (Exhibit B Q3b).

Failure prevented: the validation report from launch that is eighteen months old when the examiner asks for the last test date.

Cost: the golden set is the real work. Budget a week to build one worth trusting for a high-risk model. Everything else is plumbing.

Control 7: Data provenance and PII isolation

Artifact: a data element map (Exhibit D categories to tables, sources, vendors); a read-replica for analytics; access logs on the source. NAIC: Exhibit D; checklist 3d.

Build pattern:

• Audit the schema first. Every table, every migration, every consumer. You cannot map Exhibit D categories to data you have not enumerated. We run this as a standalone delivery because three others depend on it.
• Tag columns to Exhibit D categories in the schema documentation, with source (internal or third_party: <vendor>).
• Analytics and BI read from a replica, never production. Move existing direct-to-production queries before anything else; they are the highest PII exposure in most estates.
• The AI system’s input snapshot (Control 4) is the authoritative record of which data elements a decision consumed. Exhibit D column 3 (“how the company uses the data”) is answered from that.
• Sensitive categories (age, gender, ethnicity, medical, criminal, income, geo-demographics) are either absent from model inputs or have a written justification and a proxy check in the validation suite.

Failure prevented: geocoding and geo-demographic features flowing into a rating or adjudication model with nobody having written down that they do.

Control 8: Release control, migration gating, and rollback

Artifact: a version marker readable in production; a release checklist; a rehearsed rollback runbook; pipeline configuration in code. NAIC: checklist 3h (SDLC); Exhibit C ref 3 (implementation date), ref 8 (validated prior to deployment).

This is where AI governance meets ordinary engineering hygiene, and where most estates are weakest.

Build pattern:

• Version in production. An endpoint or a log line that returns the deployed application version, the AI system versions, and the config hashes. Without it, “implementation date” on Exhibit C is a guess.
• Migration gating. Auto-applying migrations on startup is convenient and dangerous. At minimum: a pre-deploy check that lists pending migrations and the tables they touch, and blocks if a high-risk AI system reads any of them. Hotfix branches carry a migration diff check against the mainline.
• Rollback rehearsed. Not documented, rehearsed. A rollback that has never run is not a control. Run it in staging on a schedule.
• Pipeline as code. Click-configured pipelines are undocumented configuration (Control 3 applies). Move them into the repository.
• Post-deploy verification is an automated check on the critical path, not an incognito window.
• The release checklist includes: register diff reviewed, validation suite passed, prompt and config hashes match the register, version marker updated, decision log receiving.

Failure prevented: a schema change landing in production with no human checkpoint, silently altering what the model reads.

How we sequence it: when we inherit a manual production cadence behind an approval button, the engineering instinct is to replace it on day one. We don’t. You cannot replace a process you cannot run. The checklist and runbook come first; the cadence changes after we have run it ourselves. That sequencing is itself a governance decision worth writing down.

Control 9: The dependency and vendor register

Artifact: a register of every external dependency the AI system relies on, with owner, admin, billing, renewal, and what fails if it lapses. NAIC: Exhibit B Q3 (use and oversight of material AI system vendors); checklist 3l (procurement standards); Exhibit C ref 4; Exhibit D column 5.

Build pattern:

• Enumerate from evidence, not memory: cloud billing, DNS, environment variables, secrets store, package manifests, outbound network logs. Every hostname the production service talks to is a candidate.
• Each entry: what it does, which environments, admin holder, billing holder, renewal terms, and the failure mode if it disappears.
• Mark each entry as verified by sign-in or recorded from documentation only. Unverified is a finding.
• The model provider, the prompt tool, the observability tool, and the evaluation tool are all AI vendors under the Supplement’s definition of third party. They go in this register and on Exhibit B Q3b.

Failure prevented: a live production dependency holding your prompts that nobody can name an owner for. We find this more often than not. It is never hidden. Nobody wrote it down.

Cost, said plainly

Roughly three to five engineer-weeks for the first high-risk system. Subsequent systems inherit most of it. Token cost per decision is a line in the decision record (Control 4), so cost governance falls out of the same artifact as compliance evidence.

That is a Proof of Partnership sized piece of work, which is not a coincidence.

Evidence map

What you hand the carrier when Exhibit B Q4 arrives.

What this guide does not cover yet

• State-specific disclosure obligations (checklist 3n). The state tracker owns that.
• Generative outputs to consumers (customer-facing chat). Same controls apply; the decision record schema needs an output-content field and a content review path. Separate section planned.
• Version 5.0 of the Supplement, and whatever the Working Group’s late-August 2026 session changed. Each revision gets a changelog entry and a methodology update where needed.