Appendix A — AI Tool Register Template
The canonical record format for sanctioned AI tools. One entry per product, with AI features and workflows enumerated beneath as deployments. Required fields, tier assignment per deployment, named entry owner, conditions, halt method, last-reviewed record.
What the Register is
The canonical, living record of every governed AI system in the organization: what it is, where it is deployed, what tier each deployment occupies, and who owns verifying its output.
The Register is the artifact that makes the second corollary of the Accountability Principle operable. An organization that cannot say what it has deployed cannot answer for what it deployed.
Entry model
One entry per product. AI features and workflows are enumerated beneath the product as deployments.
A deployment is one AI feature or workflow, used by one business unit, for one purpose. The same feature used by two business units for similar or different purposes is two deployments, and the two may carry different tiers as well.
Two reasons for this shape:
- Product-level identification lets auditors and executive leadership see the breadth of AI usage across business units at a glance.
- Deployment-level detail is where the tier and the verification owner live, because the tier is a property of the deployment rather than of the product or the model.
An internally built harness is a deployment beneath the product entry for the model it runs on. No separate taxonomy is required.
What is registered, and what is prohibited
Registration follows account and control, not cost.
Registered. Any governed AI system the organization accesses or executes under its own identity and contractual control, whatever it costs. This includes AI products purchased, AI capability a vendor added to a product already in use, open-weight or self-hosted models running on corporate infrastructure, no-cost tiers used under an enterprise agreement, and deployments built internally on a procured model.
Prohibited. AI accessed or executed through a personal account, or otherwise outside the organization’s identity and contractual control. This is prohibited rather than registered, which is what keeps the Register free of a lightweight entry class for trivial usage: everything in the Register is organizationally controlled and therefore worth a full entry.
Product-level fields
| Field | What it records |
|---|---|
| Register ID | Unique identifier for the product entry. |
| Product name | As the organization knows it. |
| Vendor | Supplier of record. “Internal” where the organization is its own supplier. |
| Category | Vendor-neutral category description. |
| Acquisition path | One of: AI product purchased; AI capability added by a vendor to a product already in use; open-weight or self-hosted model; internally built on a procured model; no-cost tier under an enterprise agreement. |
| Register entry owner | Named person, with business unit. Accountable for keeping this entry accurate. |
| Commercial approval reference | Pointer to the record in the organization’s existing technology purchase process. “None — no purchase” is a valid value. |
| Evaluation reference | Pointer to where the completed evaluation is filed. The Register records that the evaluation happened and where its record lives. |
| Contract terms | Data processing addendum; indemnification; audit rights; training-data retention; right to disable specific behaviors; termination assistance. Each recorded as status (in place / sought and declined / not applicable) plus a pointer to where the evidence lives. Where a term was not obtained, the exception is required. The Register carries status and pointers, not the text of the terms. |
| Status | Active · Pending · Restricted · Retiring · Retired |
| Last reviewed | Date, and which existing review process performed it. |
Deployment-level fields
Repeating. One record per AI feature per business unit context.
| Field | What it records |
|---|---|
| Deployment ID | Unique identifier, child of the product entry. |
| Feature or workflow name | The specific AI capability, not the product. |
| Business unit and context | Who runs it and in what part of the business. |
| Intended use | What work this deployment performs. Plain language. |
| Trust and Harness Tier | Tier 1 through 4, per Chapter 4. |
| Production reach | Yes / No. Where yes, the systems and data it can touch. This is the line at which an internally built harness must be registered. |
| Data classifications approved for | Recorded here; the matrix that governs the combinations is Chapter 6. |
| Verification owner | Named role-holder. |
| Domain custodians affected | The custodians whose domains this deployment’s output reaches. |
| Operator population | Who uses it, by role or group. |
| Audit trail location and export path | Where the record lives, and how it is exported. Relevant at retirement, when vendor-console-only logs are lost. |
| Change management reference | For internally built harnesses, the change record under the owning department’s existing process. Does not substitute for this entry. |
| Halt method | How this specific deployment is stopped: revoke access; disconnect the corpus or disable the endpoint; revoke agent credentials and scoped permissions; stop the event trigger. |
| Status and date | Deployment status, with effective date. |
| Retirement record reference | Populated at retirement. |
Register conventions
Review rides on existing processes. The Register does not carry a review cadence of its own. AI usage discovery and Register currency are folded into the review and discovery processes the organization already runs: internal technology audit, vendor and contract renewal review, access recertification, the change advisory process for internally built harnesses, and the annual policy review. Access recertification is the strongest of these, because it already enumerates who has access to which application.
Reconciliation is the control. The Register is reconciled against procurement and accounts payable records, the identity provider’s application inventory, the software renewal calendar, and business unit self-declaration, each within the existing process named above.
Ownership is distributed, accountability is not. Each entry has a named owner inside the requesting business unit. The Policy Owner owns the Register as a whole. Central maintenance of a distributed inventory is the failure mode that produces stale configuration databases, and it will produce a stale Register for the same reason.
Baseline build sequence. The first task in standing up a Register is a sweep of the existing software estate for AI capability the organization already owns and did not purchase as AI. Three inventories the organization already holds make the sweep finite: the identity provider’s application list, accounts payable and the renewal calendar, and the release notes for products on those lists.