Ten Systems, One Signature

Before the detail — Decision: name the AI systems Meridian runs and who signed for each. Outcome: a defensible answer to the board in an afternoon instead of weeks. Artifact: a candidate list, every entry NEEDS-OWNER. Status of what follows: reusable guidance.

Prompt first: draft the candidate list, leave every fact blank

I am inventorying candidate AI systems for a utility. Here are three
exports: our source repositories [paste], a procurement export of
active software and service contracts [paste], and the admin-console
export of enabled features from our SaaS tenants [paste].

Draft a CANDIDATE list, one entry per thing that might be an AI
system touching our data, decisions, or customers:
  - a working name and which export it came from
  - what makes you think it is AI - quote the evidence
  - the fields I will need filled: owner, purpose, model or
    provider, data classes, deployment context, users, decision
    impact, stage - every one blank, marked NEEDS-OWNER
  - a DUPLICATE flag where two exports may describe the same system

Do NOT infer an owner from a committer, a purpose from a product
name, or a model from marketing. I supply every fact.

The agent drafts the structure; the human supplies every fact. A repo committer is not an owner, a feature name is not a purpose, and a product page is not a model version. What comes back is a list of questions, each addressed to a person who can answer it.

The board asks two questions

H. Lindqvist runs Regulatory Affairs at Meridian Utilities, a fictional utility. After a rate hearing, a board member asks two things: which AI systems does Meridian run, and who signed for each one? She pulls three exports — repositories from Enterprise IT, contracts from Supply Chain, enabled features from the SaaS tenants — and runs the prompt above. Ten candidates come back.

Some she knew: the customer portal assistant, the feeder outage predictor, her own team’s rate-case comment classifier, the grounded-answers service from the last training. Some she did not: a resume screener inside the applicant-tracking system, a meeting-notes generator switched on for every staff member as a suite feature, a code assistant, a procurement summarizer, an anomaly appliance on the OT (the operational technology running substations) network, and a drone-imagery scorer still in procurement.

The first question now has an answer. The second does not: each of the ten has a budget line, a contract, or a repository, and none has a named person who accepted the risk that the system is wrong.

The audit chair asks a third: for an answer a customer or an employee received last Tuesday, which model version produced it? MU-AI-004 can say, because Grounded Answers 6.1 — a separate training in this series — built its answer record to name the model version behind every answer. That training solved one bounded service. The portal assistant’s contract does not disclose the model family; the resume screener is a vendor add-on with a proprietary ranking model; the meeting-notes generator updates on the vendor’s schedule. Nine of ten cannot say what answered.

The accountability gap, named

The gap is not “no AI policy”; Meridian has one. The gap is that nobody has made a bounded, signed claim that a named system, at a named version, may run for a named purpose — and that the claim expires. Owning a budget is not accepting a risk. Supply Chain’s signature on a contract is a signature for the money, not for the decisions the system makes about applicants, customers, or crews. What is missing is assurance (the evidence-backed decision that a system may run) — missing as a capability, not as a document.

This training’s thesis, in one sentence: an AI release decision is a bounded, signed, time-limited claim about a named system and its version boundary, supported by evidence and a named risk acceptor — not, by itself, a certification or an ATO (the formal authorization for a system to operate). Lesson 1.4 unpacks every term; the two lessons between build what the claim is about — the register, and the consequence tier that decides how much evidence the claim needs.

Why now: the regime you assumed covers this does not

Where organizations have validated models at all, the discipline they borrowed is model-risk management (the banking discipline for validating quantitative models before use). Meridian is not a bank, but its finance team borrowed that framework for load forecasts and leadership assumed it stretched. In April 2026 the US banking regulators published the revised guidance jointly — the Federal Reserve as SR 26-2, the OCC (the regulator of national banks) as Bulletin 2026-13, and the FDIC alongside them — and it states that generative and agentic AI “are not within the scope of this guidance.” The one mature discipline for deciding whether a model may be used has declined, in writing, to cover the systems on Lindqvist’s list that generate text or take actions.

The second reason is what practitioners say about themselves. ISACA (the IT audit and governance professional association) published a poll of more than 3,400 digital trust professionals in May 2026: 38% of organizations have a formal, comprehensive AI policy, 56% do not know how long it would take to halt an AI system, and 39% do not know whether they have a documented process for shutting one down. If the resume screener had to stop today, who would stop it, and how long would it take? Nobody at Meridian can answer either question; on the second, more than half of ISACA’s respondents could not either — the poll does not ask who owns the halt.

A regulator, a plaintiff, or an insurer who asks “what framework governed this system” will hear “the one that excludes it” — contract and revenue risk carried with no name on it.

Stop and escalate when discovery turns up a system that makes decisions about people — hiring, credit, service disconnection — with no owner willing to put a name beside it. That is the stop case of Lesson 1.3 — the exit where the system does not deploy — not a gap to fill later, and the decision to keep it running belongs to the executive whose function uses it, made with the candidate list on the table.

The commercial starting practice is an IT asset register that happens to contain AI. The federal delta is that a covered agency must publish an annual AI use-case inventory with a high-impact flag (M-25-21, OMB’s April 2025 memo governing agency AI use), so the list is not optional and not private; the handoff artifact is the register 1.2 builds, exportable in the inventory’s schema for Meridian’s federal-task-order system. Not equivalent: a commercial register answers the board; the federal inventory answers the public.

Practice status — among organizations discovering what AI they run, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Meridian has ten AI systems on its register — seven in production, two in pilot, one proposed — and can name the model version behind the output of exactly one, because one bounded service was built with an answer record and nine were bought, built, or switched on without anyone signing for the decisions they make. That is the accountability gap: not a missing policy, a missing signed claim. The discipline leadership assumed covered this now excludes generative and agentic AI in writing, and ISACA’s poll says many surveyed practitioners could not say how their organization would halt one. The agent drafts the candidate list; a person supplies every fact. Lesson 1.2 turns to the register: six linked objects with a named owner each.

LEADERSHIP DECISION   commission the estate discovery and name the
                      office that will own the register - the board's
                      second question has no answer until someone does
PRACTITIONER ACTION   run the candidate-list prompt over repo,
                      procurement, and SaaS exports; leave every fact
                      NEEDS-OWNER; deliver a list of questions with
                      names on them
SUCCESS MEASURE       calendar time from "which AI systems do we run"
                      to a defensible list - an afternoon from a
                      register, not weeks of discovery