Verifiable AI Governance and Data Privacy Records
draft-reilly-aigov-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr | ||
| Last updated | 2026-08-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-aigov-00
Network Working Group L. J. Reilly
Internet-Draft REM Technologies & Consulting, LLC
Intended status: Standards Track 16 August 2026
Expires: 17 February 2027
Verifiable AI Governance and Data Privacy Records
draft-reilly-aigov-00
Abstract
Organizations deploying artificial intelligence systems are
increasingly required to state which systems they operate, what data
those systems process, on what authority, and under what human
oversight. Today these statements are produced as unverifiable self-
assertions: spreadsheets, questionnaire responses, and policy
documents that cannot be checked by a relying party and cannot be
shown to have existed before an incident.
This document defines an evidence layer for AI governance. It
specifies five record types (the AI System Record, the Governance
Event Record, the Register Completeness Attestation, the Erasure
Record, and the Selective Disclosure Response), a hash-linked append-
only AI System Register that carries them, and verification
procedures that let an auditor, a regulator, or a counterparty
confirm what an operator asserted and when the assertion was made.
The record format is built on salted per-field commitments so that a
register can be published, audited, and retained for long periods
without publishing the underlying data, and so that personal data can
be erased while the integrity of the register survives. This
property is referred to here as Erasure-Compatible Permanence.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Reilly Expires 17 February 2027 [Page 1]
Internet-Draft AI Governance and Privacy Records August 2026
This Internet-Draft will expire on 17 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Relationship to Other Work . . . . . . . . . . . . . . . 4
1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Roles and Trust Model . . . . . . . . . . . . . . . . . . 7
3.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Register Structure . . . . . . . . . . . . . . . . . . . 8
4. Field Commitments . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Construction . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Public Fields . . . . . . . . . . . . . . . . . . . . . . 9
5. The AI System Record . . . . . . . . . . . . . . . . . . . . 10
5.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Governance Event Records . . . . . . . . . . . . . . . . . . 13
7. Register Completeness Attestation . . . . . . . . . . . . . . 15
8. Data Privacy Constructs . . . . . . . . . . . . . . . . . . . 16
8.1. Minimization Requirements . . . . . . . . . . . . . . . . 16
8.2. Purpose Binding . . . . . . . . . . . . . . . . . . . . . 16
8.3. Selective Disclosure . . . . . . . . . . . . . . . . . . 17
8.4. Erasure-Compatible Permanence . . . . . . . . . . . . . . 18
8.5. Data Subject Requests . . . . . . . . . . . . . . . . . . 19
9. Linkage to Related Records . . . . . . . . . . . . . . . . . 19
9.1. Usage Preference Compliance . . . . . . . . . . . . . . . 19
9.2. Autonomous Agent Provenance . . . . . . . . . . . . . . . 19
9.3. Curation and Epistemic Autonomy . . . . . . . . . . . . . 20
10. Verification . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Permanence and Anchoring . . . . . . . . . . . . . . . . . . 21
11.1. Hash Migration . . . . . . . . . . . . . . . . . . . . . 21
Reilly Expires 17 February 2027 [Page 2]
Internet-Draft AI Governance and Privacy Records August 2026
12. Register Interface . . . . . . . . . . . . . . . . . . . . . 22
13. Deployment Considerations . . . . . . . . . . . . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14.1. AI Governance Record Types Registry . . . . . . . . . . 23
14.2. AI Governance Event Types Registry . . . . . . . . . . . 23
14.3. AI Governance Data Category Codes Registry . . . . . . . 23
14.4. Media Types . . . . . . . . . . . . . . . . . . . . . . 24
15. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15.1. Commitment Guessing on Low-Entropy Fields . . . . . . . 25
15.2. Omission and Selective Registration . . . . . . . . . . 25
15.3. Key Compromise and Rotation . . . . . . . . . . . . . . 25
15.4. Anchor Dependency . . . . . . . . . . . . . . . . . . . 25
15.5. Assurance Overreading . . . . . . . . . . . . . . . . . 26
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
16.1. Design Posture . . . . . . . . . . . . . . . . . . . . . 26
16.2. The Register Is About Systems, Not People . . . . . . . 26
16.3. Metadata Leakage . . . . . . . . . . . . . . . . . . . . 27
16.4. Relying Party Overreach . . . . . . . . . . . . . . . . 27
16.5. Cross-Register Correlation . . . . . . . . . . . . . . . 27
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
18.1. Normative References . . . . . . . . . . . . . . . . . . 27
18.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Worked Example: Register Entry Through Erasure . . . 29
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
An organization that deploys artificial intelligence systems is now
routinely asked four questions: which systems are in use, what data
enters them, under what authority the processing occurs, and who is
accountable for the outcome. These questions arrive from regulators,
from customers performing vendor diligence, from auditors, from
insurers, and after an incident from litigants.
The answers are almost always produced as prose. An operator
maintains an inventory in a spreadsheet, fills out a questionnaire,
and signs a policy attestation. Nothing in that workflow binds the
answer to a point in time, and nothing prevents the inventory from
being revised after the fact to describe the deployment the operator
wishes it had made. A relying party is asked to accept assertions
that are, in the cryptographic sense, unverifiable.
The gap is not a policy gap. Policy frameworks describing what
operators should record already exist and continue to multiply; see
[NIST-AI-RMF], [ISO-42001], and [EU-AI-ACT]. The gap is an evidence
gap. There is no interoperable format for the record itself, no
Reilly Expires 17 February 2027 [Page 3]
Internet-Draft AI Governance and Privacy Records August 2026
mechanism that makes the record's time of creation checkable by a
third party, and no way to disclose one field of a record to a
regulator without disclosing the rest.
1.1. Approach
This document treats the governance inventory as a transparency
problem rather than a documentation problem. It specifies:
* an AI System Record (ASR), the registered description of one
deployed system, with each field individually committed;
* a Governance Event Record (GER), which records a lifecycle event
against a registered system: revision, evaluation, incident,
suspension, or decommissioning;
* a Register Completeness Attestation (RCA), a periodic signed claim
about the boundary of the register itself, which addresses the
omission problem that inventories otherwise cannot speak to;
* an Erasure Record (ER), which documents the destruction of the
opening material for a committed field and thereby renders the
committed value permanently unopenable;
* a Selective Disclosure Response (SDR), which opens named fields to
a named relying party without exposing the remainder of the
record;
* an append-only, hash-linked AI System Register that carries these
records, publishes a Register Head, and is anchored so that the
head value at a given time can be corroborated independently of
the operator.
The design goal is narrow and worth stating plainly. This document
does not attempt to determine whether an AI deployment is lawful,
safe, fair, or well governed. It makes an operator's own statements
about that deployment durable, time-bound, minimally disclosed, and
checkable. Assessment remains a human and institutional activity;
this specifies the substrate that assessment can rely on.
1.2. Relationship to Other Work
This document composes several existing constructs rather than
restating them:
Preference compliance: [I-D.reilly-aipref-compliance] defines the AI
Reilly Expires 17 February 2027 [Page 4]
Internet-Draft AI Governance and Privacy Records August 2026
Usage Compliance Record (AUCR), evidence that a stated usage
preference was honored during acquisition. An ASR references
AUCRs to connect a registered system to the corpus provenance
behind it (Section 9.1).
Agent behavior provenance: [I-D.reilly-cbpi] defines Reinforcement
Event Records, the Operant Provenance Chain, and the Behavioral
Drift Index for autonomous agents. A registered system that is an
autonomous agent references its provenance chain rather than
duplicating it (Section 9.2).
Human epistemic autonomy: [I-D.reilly-cogsov] defines the Curation
Disclosure Record and Sovereignty Fallback. Where a registered
system curates information presented to people, the ASR carries
the disclosure and fallback posture as registered fields.
Human and machine interface: [I-D.reilly-mws] frames the division of
labor between human and machine participants. The oversight
fields in Section 5.1 follow that framing.
Record permanence: [I-D.reilly-rem-protocol] defines dual-layer
anchoring: an external timestamp layer plus an archival deposit
layer. Section 11 applies it to the Register Head.
Audit-scale proofs: [I-D.reilly-plants-bulk-subtree-proofs] defines
bulk subtree consistency proofs, used in Section 10 so that an
auditor examining thousands of records does not require a separate
inclusion proof for each.
Commitment-based accountancy: [I-D.reilly-vsr] applies salted per-
field commitments and selective disclosure to material accountancy
under long retention horizons. The commitment construction in
Section 4 is the same construction applied to a different
accountancy problem.
The record format itself is a signed CBOR structure ([RFC8949],
[RFC9052]) and is intended to be carriable as a SCITT signed
statement where a transparency service is already deployed.
1.3. Non-Goals
* This document does not define a risk taxonomy, a model evaluation
methodology, or a conformity assessment procedure.
* This document does not define what an operator must register.
Scope obligations come from law, contract, or internal policy;
this defines how a registration is expressed and verified.
Reilly Expires 17 February 2027 [Page 5]
Internet-Draft AI Governance and Privacy Records August 2026
* This document does not establish legal compliance with any statute
or regulation. Section 13 is informative only.
* This document does not specify per-inference logging. A register
is an inventory of systems and lifecycle events, not a request
log.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
AI System: A deployed configuration of one or more machine learning
models, together with the software, data flows, and operating
rules that place it in service for a stated purpose. Two
deployments of the same underlying model for different purposes
are two AI Systems for the purposes of this document.
Deploying Organization: The entity accountable for the operation of
an AI System, which maintains the register entries describing it.
Register Operator: The entity that operates the AI System Register.
It MAY be the Deploying Organization itself, a group parent, or an
independent service.
AI System Register: An append-only, hash-linked sequence of records
describing AI Systems and events affecting them.
Register Head: The hash of the most recent register entry, together
with the entry count and timestamp, signed by the Register
Operator.
Relying Party: Any party that consumes register evidence: an
auditor, a regulator, a customer performing diligence, a data
protection officer, or a downstream integrator.
Data Subject: A natural person to whom personal data processed by a
registered AI System relates.
Field Commitment: A salted hash of a single record field, computed
as defined in Section 4, which conceals the field value while
binding the operator to it.
Opening Material: The plaintext field value and its salt, which
together allow a Relying Party to verify a Field Commitment.
Reilly Expires 17 February 2027 [Page 6]
Internet-Draft AI Governance and Privacy Records August 2026
Erasure-Compatible Permanence: The property of a register in which
the permanent, replicated, externally anchored artifacts contain
no personal data in recoverable form, so that destruction of
Opening Material removes the ability to recover a field value
while leaving the register's integrity chain intact and
verifiable.
Register Completeness Attestation: A periodic signed statement of
the scope boundary the Register Operator claims the register
covers, together with the discovery procedure used to detect
systems within that boundary.
3. Architecture
3.1. Roles and Trust Model
A Relying Party is not asked to trust the Deploying Organization's
assertions. It is asked to accept a much smaller claim: that a
particular assertion existed, in a particular form, at a particular
time, signed by a particular key. Everything else the Relying Party
may judge for itself.
The trust assumptions are as follows:
* The Deploying Organization is trusted to describe its own systems.
Registers cannot detect a determined liar; they can make the lie
fixed in time and attributable.
* The Register Operator is trusted for availability but not for
integrity. Chain linkage, signatures, and external anchoring
allow detection of retroactive modification.
* The anchoring layers are trusted only to the extent that they are
independent of the Register Operator and of each other.
* No party is trusted to hold personal data on behalf of Relying
Parties. Personal data does not enter the register in recoverable
form, as required by Section 8.1.
3.2. Layering
Reilly Expires 17 February 2027 [Page 7]
Internet-Draft AI Governance and Privacy Records August 2026
+--------------------------------------------------------------+
| Assessment layer (out of scope) |
| auditors, regulators, DPOs, customers, insurers |
+--------------------------------------------------------------+
^ ^ ^
| SDR | proofs | RCA
+--------------------------------------------------------------+
| Evidence layer (this document) |
| ASR Governance Event Record RCA ER SDR |
| salted field commitments + COSE_Sign1 |
+--------------------------------------------------------------+
| | |
+--------------------------------------------------------------+
| Register layer |
| append-only hash-linked log, Register Head, subtree proofs|
+--------------------------------------------------------------+
| |
+---------------------------+ +------------------------------+
| Timestamp layer | | Archival layer |
| external, independent | | independent deposit, |
| time attestation | | long retention |
+---------------------------+ +------------------------------+
\___________ dual-layer anchoring ___________/
Figure 1: Register layering
The evidence layer and the register layer are normative here. The
assessment layer is deliberately out of scope. The two anchoring
layers are specified by reference (Section 11).
3.3. Register Structure
The register is a sequence of entries. Entry 0 is the register
genesis entry. Each subsequent entry contains a sequence number, the
hash of the preceding entry, the record it carries, and the Register
Operator's signature over both.
The Register Operator MUST NOT modify or delete a published entry.
Corrections are made by appending a record of type system.revision
that supersedes an earlier record; the superseded record remains in
the chain. Withdrawal of a record's readable content, where lawfully
required, is performed by erasure of Opening Material as specified in
Section 8.4, not by removal of the entry.
The Register Operator MUST publish a Register Head at least daily
while the register is active, and MUST publish a Register Head
immediately following any entry that carries a record of type
system.incident or system.suspension.
Reilly Expires 17 February 2027 [Page 8]
Internet-Draft AI Governance and Privacy Records August 2026
4. Field Commitments
Every field of every record defined in this document is committed
individually. This is what makes selective disclosure and erasure
possible; it is also the source of the guessing risk discussed in
Section 15.1.
4.1. Construction
For each field with name n and canonical value v:
1. The operator generates a salt s of at least 128 bits from a
cryptographically secure random source. A salt MUST NOT be
reused across fields, across records, or across register entries.
2. The operator computes the field commitment c = H(n || 0x00 ||
s || 0x00 || v), where H is the register's hash function (SHA-256
by default, [RFC6234]) and || denotes concatenation of byte
strings. The field name is included so that a commitment opened
for one field cannot be replayed as the opening of another.
3. The commitments for all fields of the record are sorted by field
name in byte order and placed at the leaves of a Merkle tree
constructed as in [RFC9162]. The resulting root is the record's
Field Commitment Root.
The record published to the register carries the Field Commitment
Root, the ordered list of field names, and the field commitments. It
does not carry salts or field values, except for fields explicitly
marked as public in Section 5.1.
Opening Material MUST be retained by the Deploying Organization under
access control, and MUST NOT be published to the register, to an
archival layer, or to any party other than through a Selective
Disclosure Response.
4.2. Public Fields
Some fields are useless when concealed. A register in which every
field is hidden cannot be searched, indexed, or usefully summarized.
A record therefore MAY publish a field in the clear by including it
in the public map in addition to committing it. A field MUST NOT be
published in the clear if it contains personal data, and a Deploying
Organization MUST evaluate that condition before publication rather
than relying on a field's default classification.
Field classifications given in Section 5.1 are defaults, not
permissions.
Reilly Expires 17 February 2027 [Page 9]
Internet-Draft AI Governance and Privacy Records August 2026
5. The AI System Record
An AI System Record describes one deployed AI System. It is the
foundational record type; every other record type in this document
references an ASR.
5.1. Fields
system_id (MUST, public)
Stable identifier for the system within the register.
name (MUST, public)
Human-readable name of the deployment.
purpose (MUST, public)
The stated purpose the system is deployed to serve.
status (MUST, public)
One of: evaluation, pilot, production, suspended, decommissioned.
operator (MUST, public)
Identifier of the Deploying Organization.
accountable_role (MUST, committed)
The organizational role accountable for the system. See
Section 16.2: this field identifies a role, not a named
individual.
model_identity (MUST, public)
Provider, model family, and version or digest as known to the
operator.
hosting (MUST, public)
One of: vendor_api, private_tenancy, self_hosted, on_device.
data_categories (MUST, committed)
Categories of data that enter the system, as codes from the
registry in Section 14.3.
personal_data (MUST, public)
Boolean: whether any input, output, or telemetry constitutes
personal data.
special_categories (MUST, committed)
Whether special or sensitive categories of personal data are
involved, and which.
Reilly Expires 17 February 2027 [Page 10]
Internet-Draft AI Governance and Privacy Records August 2026
lawful_basis_ref (SHOULD, committed)
Reference to the operator's recorded basis for the processing. A
reference, not the assessment itself.
purpose_binding (MUST, committed)
The mapping of data categories to permitted purposes. See
Section 8.2.
retention (MUST, committed)
Retention period applied to inputs, outputs, and telemetry.
training_use (MUST, public)
Whether inputs may be used to train or improve any model, by the
operator or by the provider.
subprocessors (SHOULD, committed)
Downstream processors receiving data from the system.
regions (SHOULD, committed)
Processing and storage regions.
oversight_mode (MUST, public)
One of: human_in_loop, human_on_loop, autonomous_with_review,
autonomous. Follows the framing of [I-D.reilly-mws].
autonomy_bounds (SHOULD, committed)
Actions the system may take without human confirmation.
curation_disclosure (MAY, public)
Reference to a Curation Disclosure Record where the system curates
information presented to people ([I-D.reilly-cogsov]).
provenance_chain (MAY, public)
Reference to an Operant Provenance Chain for autonomous agents
([I-D.reilly-cbpi]).
usage_compliance (MAY, public)
References to AI Usage Compliance Records
([I-D.reilly-aipref-compliance]).
evaluations (SHOULD, committed)
References to evaluations performed, with dates and digests of the
reports.
risk_class (SHOULD, public)
The operator's own classification, with the scheme named.
Reilly Expires 17 February 2027 [Page 11]
Internet-Draft AI Governance and Privacy Records August 2026
registered_at (MUST, public)
Time of first registration, as asserted by the operator.
An implementation MUST reject an ASR that omits a field marked MUST.
An implementation MUST accept unrecognized fields and MUST include
them in commitment computation, so that vocabulary extension does not
break verification.
The risk_class field deserves a caution. It records what the
operator classified the system as, under a named scheme. It does not
record what the system is. A register that is read as though the two
were the same will mislead its readers.
5.2. Example
The following is a non-normative JSON rendering of an ASR. The wire
format is CBOR ([RFC8949]) wrapped in COSE_Sign1 ([RFC9052]); JSON is
shown for readability. Commitments are truncated for presentation.
Reilly Expires 17 February 2027 [Page 12]
Internet-Draft AI Governance and Privacy Records August 2026
{
"type": "aigov.asr",
"version": 1,
"system_id": "asr:acme:support-triage-01",
"registered_at": "2026-08-16T14:02:11Z",
"public": {
"name": "Customer support triage assistant",
"purpose": "Classify inbound tickets and draft first replies",
"status": "production",
"operator": "acme-corp",
"model_identity": "vendor-x/model-family/2026-05",
"hosting": "private_tenancy",
"personal_data": true,
"training_use": false,
"oversight_mode": "human_in_loop",
"risk_class": {"scheme": "internal-v3", "value": "elevated"},
"usage_compliance": ["aucr:acme:2026-06-19/8f21c0"]
},
"field_names": [
"accountable_role", "autonomy_bounds", "data_categories",
"evaluations", "lawful_basis_ref", "purpose_binding",
"regions", "retention", "special_categories", "subprocessors"
],
"field_commitments": [
"9a3f...c012", "4b71...ee90", "0d55...a731", "77ac...12bf",
"e109...5d4a", "2c6e...b088", "aa41...903c", "5f18...67d2",
"b0d3...4e15", "38ff...c6a9"
],
"field_commitment_root": "6e2b91d4...f07c",
"prev_entry_hash": "1d90aa47...b3e8",
"sequence": 4127
}
A reader of the register learns that a support triage system is in
production, processes personal data, does not feed training, and runs
with a human in the loop. A reader does not learn which data
categories, which subprocessors, or which regions. Those become
available to a specific Relying Party through a Selective Disclosure
Response, and to nobody else.
6. Governance Event Records
A registry that records only initial state decays quickly.
Governance Event Records carry the lifecycle.
Reilly Expires 17 February 2027 [Page 13]
Internet-Draft AI Governance and Privacy Records August 2026
+=======================+==================================+
| Type | Meaning |
+=======================+==================================+
| system.registration | First registration of an ASR. |
+-----------------------+----------------------------------+
| system.revision | A change to one or more |
| | registered fields, superseding |
| | an earlier record. |
+-----------------------+----------------------------------+
| system.evaluation | An evaluation was performed; |
| | carries the report digest and |
| | outcome. |
+-----------------------+----------------------------------+
| system.incident | An event with actual or |
| | suspected adverse effect on |
| | people, data, or the operator. |
+-----------------------+----------------------------------+
| system.suspension | The system was taken out of |
| | service pending review. |
+-----------------------+----------------------------------+
| system.resumption | A suspended system returned to |
| | service. |
+-----------------------+----------------------------------+
| system.decommission | The system was permanently |
| | withdrawn. |
+-----------------------+----------------------------------+
| data.subject_request | A data subject request affecting |
| | the system was received and |
| | resolved. Carries no identifier |
| | of the requester (Section 8.5). |
+-----------------------+----------------------------------+
| data.erasure | Opening Material was destroyed; |
| | see Section 8.4. |
+-----------------------+----------------------------------+
| register.completeness | A Register Completeness |
| | Attestation. |
+-----------------------+----------------------------------+
Table 1: Governance event types
Every GER MUST carry the system_id it concerns (except
register.completeness, which concerns the register), the event type,
the operator's asserted event time, and a field commitment root
computed over its own fields as in Section 4.
Reilly Expires 17 February 2027 [Page 14]
Internet-Draft AI Governance and Privacy Records August 2026
A system.revision record MUST carry the field commitments for the
changed fields only, and MUST reference the sequence number of the
record it supersedes. A verifier reconstructs current state by
walking the chain forward from registration, applying revisions in
order.
Where a system.incident record concerns individuals, the record MUST
describe the class and scale of effect and MUST NOT identify the
affected individuals, whether in the clear or by commitment. A
commitment to a name is still a means of confirming a name to anyone
who can guess it, and incident records are exactly where such
confirmation does harm.
7. Register Completeness Attestation
Every inventory has the same weakness, and it is worth naming rather
than designing around: an inventory proves what was written down. It
says nothing about what was left out. The systems an organization
most needs to know about are frequently the ones nobody registered.
A Register Completeness Attestation does not solve this problem. It
makes an operator state a boundary and a method, so that omission
becomes a checkable failure against the operator's own claim rather
than an unstated gap.
An RCA MUST contain:
scope: The boundary the operator claims the register covers: which
legal entities, business units, environments, and procurement
channels.
discovery_method: How systems within scope are detected. For
example: expense and vendor review, network egress inspection,
identity provider application inventory, code repository scanning,
or self-declaration only.
discovery_period: The interval covered by this attestation.
known_gaps: Areas within scope the operator knows are not covered by
the discovery method.
systems_registered: Count of active registered systems at the time
of attestation, and the Register Head the count refers to.
attesting_role: The accountable role making the attestation.
Reilly Expires 17 February 2027 [Page 15]
Internet-Draft AI Governance and Privacy Records August 2026
An RCA whose discovery_method is self-declaration only is a valid
RCA. It is also an honest signal, and Relying Parties SHOULD treat
it as such. The value of the field lies in the operator having had
to write it down before an incident rather than after one.
A Register Operator SHOULD publish an RCA at least quarterly. A
Register Operator MUST publish an RCA whenever the scope boundary
changes.
8. Data Privacy Constructs
8.1. Minimization Requirements
These requirements are the foundation of everything else in this
section, and they are absolute.
* A record MUST NOT contain personal data in the clear.
* A record MUST NOT contain model inputs, model outputs, prompts,
completions, or samples thereof, in the clear or by commitment.
* A record MUST NOT contain a direct identifier of a data subject,
including by commitment. Commitments conceal, but they also
confirm; a committed identifier is an oracle for anyone holding a
candidate value.
* A record MUST NOT record AI usage attributed to an identified or
identifiable individual employee. See Section 16.2.
* A record SHOULD refer to data categories, volumes, and classes
rather than instances.
A register that follows these rules can be published, mirrored,
archived for decades, and handed to an adversary without disclosing a
single data subject. That is the intended posture.
8.2. Purpose Binding
The purpose_binding field maps each declared data category to the
purposes for which it may be processed by the system, expressed as a
list of pairs. Its function is comparative: it fixes a claim at time
T so that a later observation of processing outside the binding
becomes a discrepancy against a signed prior statement rather than a
matter of recollection.
Reilly Expires 17 February 2027 [Page 16]
Internet-Draft AI Governance and Privacy Records August 2026
A change to a purpose binding MUST be recorded as a system.revision
before the changed processing begins. An operator that revises a
binding after the fact produces a register in which the revision
timestamp postdates the anchored head that preceded it, which is
precisely the condition an auditor is looking for.
Purpose binding is a statement of intent under commitment. It is not
an enforcement mechanism, and this document does not claim that it
constrains the running system.
8.3. Selective Disclosure
A Selective Disclosure Response opens named fields of a named record
to a named Relying Party. It MUST contain:
1. the system_id and sequence number of the record;
2. for each disclosed field: the field name, the plaintext value,
and the salt;
3. the Merkle path from each disclosed field commitment to the Field
Commitment Root;
4. the identifier of the Relying Party the response was issued to;
5. the issuance time and, if applicable, an expiry;
6. a signature by the Deploying Organization over all of the above.
The Relying Party recomputes each commitment from the disclosed name,
salt, and value; verifies the Merkle path to the Field Commitment
Root; verifies that the root matches the record in the register; and
verifies the record's inclusion in the register as described in
Section 10. A Relying Party MUST perform all four checks. Verifying
an opening without verifying register inclusion proves only that
someone signed a value.
Because the Relying Party identifier is inside the signed structure,
a disclosure leaked onward is traceable to the party it was issued
to. Deploying Organizations SHOULD issue distinct SDRs per Relying
Party even where the disclosed content is identical.
Reilly Expires 17 February 2027 [Page 17]
Internet-Draft AI Governance and Privacy Records August 2026
8.4. Erasure-Compatible Permanence
Append-only registers and erasure obligations are usually presented
as being in direct conflict. They are in conflict when personal data
is written into the append-only structure. The construction here
avoids the conflict by never placing recoverable personal data there
in the first place.
Erasure proceeds as follows:
1. The Deploying Organization destroys the Opening Material for the
affected fields: the plaintext values and their salts, in all
copies under its control, including backups, according to its
documented destruction procedure.
2. The Deploying Organization appends an Erasure Record
(data.erasure) naming the affected record sequence and field
names, the erasure time, and the basis for the erasure. The ER
MUST NOT identify the requesting data subject.
3. The field commitment remains in the register. It is now a hash
of a value that no party can produce and a salt that no party
holds. It cannot be opened; it can still be verified as part of
the Merkle tree and the chain.
The result is that the register retains its integrity and its
historical structure while the erased value becomes unrecoverable.
The register can still demonstrate that a field existed at a point in
time and that it has not been altered since.
Three honest limitations apply, and implementers should not be
allowed to overlook them:
* Erasure of Opening Material is effective only against parties that
did not already hold the plaintext. A Relying Party that received
an SDR before the erasure retains what it received. Contractual
controls, not cryptography, govern that copy.
* A commitment to a low-entropy value remains guessable after
erasure. Where a field's value space is small, the commitment is
not equivalent to deletion. See Section 15.1.
Reilly Expires 17 February 2027 [Page 18]
Internet-Draft AI Governance and Privacy Records August 2026
* Whether a residual salted commitment satisfies a given legal
erasure obligation is a question of law, and the answer is not
settled in any jurisdiction known to the author. This document
describes a technical property. It does not assert a legal
conclusion, and operators subject to erasure obligations should
obtain advice specific to their jurisdiction rather than treating
this construction as sufficient on its own.
Given the third point, Deploying Organizations SHOULD prefer to keep
fields likely to carry personal data out of the register entirely,
referencing an internal system of record instead, and reserve
committed fields for organizational facts.
8.5. Data Subject Requests
A data.subject_request record notes that a request of a given class
was received and how it was resolved. It MUST NOT identify the
requester, MUST NOT carry a commitment to the requester's identity,
and SHOULD aggregate where request volume is low enough that a single
record would be identifying by timing alone.
Where a data subject asks which AI systems process their data, the
public portion of the register answers most of the question directly,
without any per-subject disclosure: the systems, their purposes,
their oversight modes, and their training use are already published.
9. Linkage to Related Records
9.1. Usage Preference Compliance
Where a registered system was trained or tuned on acquired content,
the usage_compliance field references AI Usage Compliance Records as
defined in [I-D.reilly-aipref-compliance]. This connects the
deployment side of governance to the acquisition side: a register
entry can show not only what a system does, but that the corpus
behind it was gathered under honored preferences.
A Relying Party verifying an AUCR reference follows the verification
procedure of that document. This document adds no requirements to
it.
9.2. Autonomous Agent Provenance
Where oversight_mode is autonomous_with_review or autonomous, the ASR
SHOULD carry a provenance_chain reference to the system's Operant
Provenance Chain ([I-D.reilly-cbpi]), and the operator SHOULD append
a system.evaluation record when the Behavioral Drift Index crosses
the threshold the operator has set.
Reilly Expires 17 February 2027 [Page 19]
Internet-Draft AI Governance and Privacy Records August 2026
The register records that a threshold exists and that it was crossed.
The behavioral record itself stays where it belongs, in the
provenance chain, and is not duplicated into the register.
9.3. Curation and Epistemic Autonomy
Where a registered system selects, ranks, filters, or summarizes
information presented to people, the ASR SHOULD carry a
curation_disclosure reference to a Curation Disclosure Record and
SHOULD register whether a Sovereignty Fallback is offered
([I-D.reilly-cogsov]). Registering the absence of a fallback is as
informative as registering its presence.
10. Verification
A Relying Party verifies a claim about a registered system as
follows:
1. *Signature.* Verify the COSE_Sign1 signature on the record
against a key attributable to the Deploying Organization at the
record's asserted time.
2. *Chain.* Verify that the record's prev_entry_hash matches the
preceding entry and that the sequence numbers are contiguous
across the range examined.
3. *Inclusion.* Verify that the entry is included in a Register Head
the Relying Party holds. When verifying many records at once, as
an auditor typically does, use a bulk subtree consistency proof
as defined in [I-D.reilly-plants-bulk-subtree-proofs] rather than
an inclusion proof per record.
4. *Anchoring.* Verify that the Register Head, or a head that
supersedes it, is attested by the timestamp layer and present in
the archival layer (Section 11). This is the step that makes the
operator's asserted times checkable rather than self-reported.
5. *Opening.* For each disclosed field, recompute the commitment
from name, salt, and value; verify the Merkle path to the Field
Commitment Root; and verify that the root is the one in the
verified record.
6. *Current state.* Walk revisions forward from registration to
determine the state of the system at the time of interest. A
record read in isolation may have been superseded.
Reilly Expires 17 February 2027 [Page 20]
Internet-Draft AI Governance and Privacy Records August 2026
A verifier MUST report failure of any step rather than degrading to a
partial result. In particular, a verifier MUST NOT report a record
as verified when step 4 could not be completed, since without
anchoring the register's timeline rests entirely on the operator's
own assertion.
11. Permanence and Anchoring
The Register Head is anchored using dual-layer anchoring as defined
in [I-D.reilly-rem-protocol]: an external timestamp layer that
establishes that a value existed before a point in time, and an
archival deposit layer that establishes that the value remains
retrievable independently of the Register Operator. Neither layer
alone is sufficient: a timestamp over a value nobody can retrieve
proves little, and an archived value with no attested time proves
less.
Requirements:
* A Register Operator MUST anchor the Register Head to the timestamp
layer at least daily while the register is active.
* A Register Operator MUST deposit the Register Head, and SHOULD
deposit the full register content excluding Opening Material, to
at least one archival layer that is operationally independent of
the Register Operator.
* Anchoring artifacts MUST be retrievable by Relying Parties without
credentials issued by the Register Operator.
11.1. Hash Migration
Governance records have long lives. Retention obligations of ten
years are ordinary and longer horizons are common, which is long
enough that the register's hash function may weaken within the
retention period.
A Register Operator migrating to a new hash function MUST publish a
bridging record that contains the final Register Head under the old
function, the genesis entry of the continued register under the new
function, and a signature over both, and MUST anchor the bridging
record under both functions. This follows the bridging construction
of [I-D.reilly-vsr]. Verification across a migration boundary
consists of verifying each side under its own function and the
bridging record's signature over the junction.
Reilly Expires 17 February 2027 [Page 21]
Internet-Draft AI Governance and Privacy Records August 2026
12. Register Interface
A Register Operator that exposes an HTTP interface SHOULD provide the
following resources. This section is RECOMMENDED, not required; the
record formats above are independent of transport.
+============================+=================================+
| Resource | Returns |
+============================+=================================+
| /aigov/head | Current signed Register Head. |
+----------------------------+---------------------------------+
| /aigov/systems | Public portions of active ASRs. |
+----------------------------+---------------------------------+
| /aigov/systems/{system_id} | Record history for one system. |
+----------------------------+---------------------------------+
| /aigov/entries/{sequence} | One register entry. |
+----------------------------+---------------------------------+
| /aigov/proof | Inclusion and bulk subtree |
| | proofs for a requested range. |
+----------------------------+---------------------------------+
| /aigov/completeness | Most recent and historical |
| | RCAs. |
+----------------------------+---------------------------------+
| /aigov/anchors | Anchoring artifacts for |
| | published heads. |
+----------------------------+---------------------------------+
Table 2: Recommended resources
Responses SHOULD use the media types registered in Section 14.4. A
public register MUST NOT expose Opening Material through any
resource; SDR issuance is an authenticated, per-party operation and
is out of scope for the public interface.
13. Deployment Considerations
This section is informative. It illustrates how register records
correspond to obligations that operators commonly face. Nothing here
establishes compliance with any instrument, and a register conforming
to this document may still fall short of an operator's obligations.
Inventory obligations: The set of active ASRs is the inventory. The
RCA states what the inventory claims to cover.
Records of processing: The data_categories, purpose_binding,
retention, subprocessors, and regions fields carry the processing
description under commitment, disclosable field by field.
Reilly Expires 17 February 2027 [Page 22]
Internet-Draft AI Governance and Privacy Records August 2026
Risk management processes: [NIST-AI-RMF] describes govern, map,
measure, and manage functions. Register records provide the
artifacts those functions produce: registration and completeness
for govern, ASR fields for map, evaluation records for measure,
and incident, suspension, and revision records for manage.
Management system evidence: [ISO-42001] requires documented
operational information under change control. An append-only
anchored register is change control with an external witness.
Technical documentation and logging obligations: [EU-AI-ACT] imposes
documentation, record-keeping, and human oversight requirements on
certain systems. The oversight_mode, autonomy_bounds, and
evaluations fields express the operator's position on these; the
anchoring layer establishes when the position was taken.
Operators should resist the temptation to treat the register as the
governance program. It is the evidence layer beneath one.
14. IANA Considerations
14.1. AI Governance Record Types Registry
IANA is requested to create a registry named "AI Governance Record
Types" with the registration policy Specification Required. Each
entry contains a type name, a brief description, and a reference.
Initial contents: aigov.asr, aigov.ger, aigov.rca, aigov.er, and
aigov.sdr, all with reference to this document.
14.2. AI Governance Event Types Registry
IANA is requested to create a registry named "AI Governance Event
Types" with the registration policy Specification Required, whose
initial contents are the event types listed in Table 1, with
reference to this document.
14.3. AI Governance Data Category Codes Registry
IANA is requested to create a registry named "AI Governance Data
Category Codes" with the registration policy Expert Review. Initial
contents:
Reilly Expires 17 February 2027 [Page 23]
Internet-Draft AI Governance and Privacy Records August 2026
+===================+========================================+
| Code | Description |
+===================+========================================+
| dc.public | Data already lawfully public. |
+-------------------+----------------------------------------+
| dc.internal | Non-personal organizational data. |
+-------------------+----------------------------------------+
| dc.customer | Personal data relating to customers. |
+-------------------+----------------------------------------+
| dc.employee | Personal data relating to workers. |
+-------------------+----------------------------------------+
| dc.health | Health or medical data. |
+-------------------+----------------------------------------+
| dc.financial | Financial account or transaction data. |
+-------------------+----------------------------------------+
| dc.biometric | Biometric identifiers or templates. |
+-------------------+----------------------------------------+
| dc.location | Precise location data. |
+-------------------+----------------------------------------+
| dc.communications | Contents of communications. |
+-------------------+----------------------------------------+
| dc.minors | Data relating to children. |
+-------------------+----------------------------------------+
| dc.special | Other categories treated as sensitive |
| | by applicable law. |
+-------------------+----------------------------------------+
Table 3: Initial data category codes
Designated experts should evaluate proposed additions for
distinctness from existing codes and for the absence of identifying
granularity: category codes describe classes of data, and a code
narrow enough to identify individuals defeats the purpose of the
field.
14.4. Media Types
IANA is requested to register the media types application/aigov-
record+cbor and application/aigov-record+json in the Standards Tree,
with this document as the specification and the author as the change
controller.
15. Security Considerations
Reilly Expires 17 February 2027 [Page 24]
Internet-Draft AI Governance and Privacy Records August 2026
15.1. Commitment Guessing on Low-Entropy Fields
Salting defeats precomputation but not enumeration when the salt is
known to the guessing party, and it does not conceal a value from
someone who can obtain the salt. More importantly, several fields in
Section 5.1 draw from small value spaces: special_categories is
nearly boolean in practice, and regions and subprocessors draw from
enumerable sets. An adversary who obtains a salt through an SDR for
one field learns nothing about others, because salts are per-field
and unique. An adversary who obtains no salt cannot enumerate at
all.
The residual risk is therefore concentrated in SDR handling: a
Relying Party that receives openings for many records accumulates a
picture the register does not otherwise expose. Deploying
Organizations SHOULD scope SDRs narrowly and SHOULD apply expiry.
15.2. Omission and Selective Registration
An operator that never registers a system produces no evidence about
it. The RCA (Section 7) converts this from an invisible gap into a
discrepancy against a signed scope claim, but it does not detect the
omission. Relying Parties SHOULD compare register contents against
independent signals such as vendor spend, egress destinations, and
identity provider application lists, and SHOULD treat a register
whose discovery method is self-declaration only as weak evidence of
completeness.
15.3. Key Compromise and Rotation
Compromise of a Deploying Organization's signing key permits forged
records from the time of compromise forward, and permits backdated
records that are nonetheless bounded by anchored heads: a forged
record cannot be inserted before a head that already committed to a
different chain state. Operators MUST anchor frequently enough that
the unanchorable window is short relative to the sensitivity of the
register, and MUST record key rotations as register entries so that
verifiers can select the correct key for a given time.
15.4. Anchor Dependency
An anchoring layer that is unavailable, discontinued, or in fact
controlled by the Register Operator provides less assurance than it
appears to. Operators SHOULD use at least two mutually independent
anchoring services per layer, and verifiers SHOULD treat correlated
anchoring failure as a verification failure rather than a transient
condition.
Reilly Expires 17 February 2027 [Page 25]
Internet-Draft AI Governance and Privacy Records August 2026
15.5. Assurance Overreading
The most likely failure of this specification in practice is not
cryptographic. It is that a verified register is read as a governed
deployment. Verification establishes that an operator asserted
something at a time and has not silently changed it. It establishes
nothing about the accuracy of the assertion, the quality of the
system, or the adequacy of the oversight. Implementations that
render verification results SHOULD present them in those terms, and
SHOULD NOT use language such as compliant, approved, or safe.
16. Privacy Considerations
16.1. Design Posture
The register is designed to be publishable. Personal data does not
enter it in recoverable form (Section 8.1), openings are per-party
and signed (Section 8.3), and erasure destroys opening capability
without breaking integrity (Section 8.4). The intended result is
that publishing a register improves transparency about systems
without creating a new exposure surface for the people those systems
affect.
16.2. The Register Is About Systems, Not People
A governance inventory sits one small step away from a surveillance
instrument. An organization that begins by recording which AI
systems it operates can slide, with no change in format and no
obvious moment of decision, into recording which employees used which
system when.
Therefore: a record defined in this document MUST NOT record AI usage
attributed to an identified or identifiable individual, and the
accountable_role field MUST name a role rather than a person. An
implementation MUST NOT provide a field, extension, or convention for
per-individual usage attribution. Organizations with a genuine need
to monitor individual usage have separate obligations of notice,
basis, and proportionality, and MUST NOT discharge them by writing
the data into a register whose entire design assumes it contains
nothing of the kind.
Reilly Expires 17 February 2027 [Page 26]
Internet-Draft AI Governance and Privacy Records August 2026
16.3. Metadata Leakage
Even a fully committed register leaks structure. Entry timing
reveals organizational activity; a burst of system.suspension records
reveals an incident before any incident record is published; the
count of registered systems reveals scale; commitment sizes reveal
field presence. Operators for whom this is material SHOULD batch
entries on a fixed schedule and SHOULD pad optional fields to a
uniform set rather than omitting them.
16.4. Relying Party Overreach
Selective disclosure makes it easy to request everything, since the
marginal cost of an additional field is near zero for the requester
and nonzero for the subject organization. Relying Parties SHOULD
request the minimum set of fields their purpose requires. Deploying
Organizations MAY record disclosure requests and their scope as
register entries, which makes the pattern of requests as visible as
the pattern of registrations.
16.5. Cross-Register Correlation
Where multiple organizations publish registers, references to shared
model providers, subprocessors, and evaluation reports permit
correlation across organizational boundaries. This is largely a
benefit for systemic-risk analysis; it is a disclosure risk for a
small operator whose supply chain is identifying. Small operators
MAY commit rather than publish model_identity and hosting, accepting
reduced register utility in exchange.
17. Acknowledgements
This work builds on the transparency log constructions of the
Certificate Transparency community and on the SCITT working group's
framing of signed statements and transparent registries.
18. References
18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
Reilly Expires 17 February 2027 [Page 27]
Internet-Draft AI Governance and Privacy Records August 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
18.2. Informative References
[EU-AI-ACT]
European Parliament and Council, "Regulation (EU)
2024/1689 laying down harmonised rules on artificial
intelligence", June 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
[I-D.reilly-aipref-compliance]
Reilly, L. J., "Verifiable Compliance Records for AI Usage
Preferences", Work in Progress, Internet-Draft, draft-
reilly-aipref-compliance-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-aipref-
compliance/>.
[I-D.reilly-cbpi]
Reilly, L. J., "Cognitive Behavioral Provenance and
Integrity (CBPI) for Autonomous AI Agents", Work in
Progress, Internet-Draft, draft-reilly-cbpi-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-cbpi/>.
[I-D.reilly-cogsov]
Reilly, L. J., "Cognitive Sovereignty", Work in Progress,
Internet-Draft, draft-reilly-cogsov-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-cogsov/>.
[I-D.reilly-mws]
Reilly, L. J., "Machine-Web Symbiosis (MWS)", Work in
Progress, Internet-Draft, draft-reilly-mws-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-mws/>.
Reilly Expires 17 February 2027 [Page 28]
Internet-Draft AI Governance and Privacy Records August 2026
[I-D.reilly-plants-bulk-subtree-proofs]
Reilly, L. J., "Bulk Subtree Consistency Proofs for Merkle
Tree Certificates", Work in Progress, Internet-Draft,
draft-reilly-plants-bulk-subtree-proofs-01, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-plants-
bulk-subtree-proofs/>.
[I-D.reilly-rem-protocol]
Reilly, L. J., "REM Protocol: Dual-Layer Digital
Permanence and Prior Art Records", Work in Progress,
Internet-Draft, draft-reilly-rem-protocol-02, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-rem-
protocol/>.
[I-D.reilly-vsr]
Reilly, L. J., "Verifiable Safeguards Records (VSR) for
Nuclear Material Accountancy", Work in Progress, Internet-
Draft, draft-reilly-vsr-00, 2026,
<https://datatracker.ietf.org/doc/draft-reilly-vsr/>.
[ISO-42001]
International Organization for Standardization, "ISO/IEC
42001: Information technology, Artificial intelligence,
Management system", December 2023,
<https://www.iso.org/standard/81230.html>.
[NIST-AI-RMF]
National Institute of Standards and Technology,
"Artificial Intelligence Risk Management Framework (AI RMF
1.0)", January 2023,
<https://www.nist.gov/itl/ai-risk-management-framework>.
Appendix A. Worked Example: Register Entry Through Erasure
This appendix is non-normative. It follows one system through
registration, revision, disclosure, and erasure.
*Entry 4127, registration.* The operator registers the support triage
assistant shown in Section 5.2. Ten fields are committed; nine are
public. The head is anchored the same evening.
*Entry 4390, revision.* The operator adds a subprocessor. A
system.revision record carries a new commitment for subprocessors and
a new Field Commitment Root, and references sequence 4127. Nothing
in entry 4127 changes.
Reilly Expires 17 February 2027 [Page 29]
Internet-Draft AI Governance and Privacy Records August 2026
*Disclosure.* A customer's diligence team asks which regions process
its data. The operator issues an SDR opening regions and
subprocessors only, naming the customer, expiring in ninety days.
The customer verifies the openings, the Merkle paths, the record
inclusion at head H, and the anchoring of H. It learns two fields.
It learns nothing about lawful basis, retention, or evaluation
history.
*Entry 5102, incident.* A misconfiguration exposes draft replies to
the wrong tenant for four hours. The operator appends a
system.incident record describing the class and scale of effect, and
a system.suspension record. A head is published immediately, as
required by Section 3.3. The published head is what later makes the
timeline non-negotiable.
*Entry 5140, erasure.* A field committed during registration is found
to contain a value that must be erased under an obligation the
operator has determined applies. The operator destroys the plaintext
and salt, appends a data.erasure record naming sequence 4127 and the
field name, and publishes a head. The commitment remains at leaf
position in the tree of entry 4127. Entry 4127 still verifies. The
value is gone.
A verifier arriving in 2034 can still confirm the chain from entry 0,
confirm that entry 4127 was anchored before entry 5102, confirm that
the erased field was present and unaltered, and confirm that it
cannot be opened. That combination is the point of the design.
Change Log
draft-reilly-aigov-00: initial version.
Author's Address
Lawrence John Reilly Jr.
REM Technologies & Consulting, LLC
Tampa, FL
United States of America
Email: lawrencejohnreilly@gmail.com
Reilly Expires 17 February 2027 [Page 30]