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, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . 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, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021, . 18.2. Informative References [EU-AI-ACT] European Parliament and Council, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence", June 2024, . [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, . [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, . [I-D.reilly-cogsov] Reilly, L. J., "Cognitive Sovereignty", Work in Progress, Internet-Draft, draft-reilly-cogsov-00, 2026, . [I-D.reilly-mws] Reilly, L. J., "Machine-Web Symbiosis (MWS)", Work in Progress, Internet-Draft, draft-reilly-mws-00, 2026, . 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, . [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, . [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, . [ISO-42001] International Organization for Standardization, "ISO/IEC 42001: Information technology, Artificial intelligence, Management system", December 2023, . [NIST-AI-RMF] National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", January 2023, . 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]