Security, Ethics, Privacy, and Governance › Documentation, Access Control, and Accountability

This section covers how teams operate, audit, and maintain controls in deployment. Missing ownership or auditability can undermine those processes even when a mechanism retains a bounded technical effect. Document both the mechanism's guarantee and the responsibilities for using it.

Model cards (Mitchell et al., 2019) and datasheets for datasets (Gebru et al., 2021) provide structured information for people who did not build a system. They complement source inspection, tests, system specifications, and independent audits rather than replacing those forms of evidence.

Auditors, incident reviewers, procurement teams, and legal reviewers may need to answer questions about a system they did not train. Documentation should make the relevant assumptions, evidence, and responsibilities available to them.

Keep generic model-card fields and add temporal, dynamical, and closed-loop information where the application needs it. Corpus confidentiality and service availability also remain relevant; not every failure is a control-system failure.

• Assumptions. Markovity, stationarity, and the causal assumptions relating observations to state. If the model assumes the world's dynamics are fixed, say so, and say what breaks when they change.
• Coverage. The temporal, geographic, and behavioral range of the training data. "Trained on household video" is not coverage; "trained on 300 homes in two countries, daytime, single-floor, no pets, no children under five" is.
• Action semantics. What the control input means, its units, its bounds, and how it was recorded. For human demonstrations, specify the original embodiment and any inferred or retargeted action representation. Validate the mapping to the deployment's action space rather than assuming embodiments are interchangeable.
• Uncertainty calibration. How well the model's stated uncertainty matches its actual error, and over what regions. As discussed in Part XII, Ch 2: Robustness, Calibration, and Safe Control, calibration is a prediction-quality concern with safety consequences when a controller relies on it.
• Closed-loop evaluation. Not one-step error, and not rollout error in isolation, but tracked performance under a controller, including the disturbance conditions tested. The poisoning experiment above is the reason: prediction and bounded-control error both deteriorated, so each should be reported separately.
• Known failure regions and triggers. Where the model is known to be wrong, and any conditions where it has been observed to behave discontinuously.
• Privacy accounting. Which populations appear in the data, what consent was obtained, what the retention policy is, and what measured leakage looks like.
• Provenance. Data sources, licences, and the identity of every party who could modify the training pipeline.

Documentation also needs version control. Bind each card to the model and data versions it describes, and check those bindings during release and audit. Content-derived identifiers can detect a mismatch when checked; hashes alone do not keep prose accurate or prevent someone from publishing an unmatched card.

The interface determines which operations and information an attacker can access. The extraction experiment measures one interface, not a universal ordering of security. Consider these release options against the application's threat model:

• Open weights. Recipients can inspect and modify the released parameters without hosted-interface restrictions. Evaluate rights, retained sensitive information, misuse capability, and the benefits of reuse. Small model size alone does not make release appropriate, and withholding weights alone does not secure every other interface.
• Fine-tuning API. The provider can restrict adaptation and inspect or reject requests. Whether the interface permits extraction depends on its outputs and permissions. Qi et al. (2023) found safety compromises for particular aligned LLMs and fine-tuning settings; that does not mean every fine-tuning operation removes safety controls.
• Query API. Functionality copying depends on the model class, output precision, query distribution, and error target. Budget and monitor queries where appropriate, but validate the protection experimentally. Action-only outputs can still identify parameters in the scalar counterexample above.
• Mediated structured access. Vetted users, defined scope, logging, and revocation can constrain access under specified assumptions. Assess compromised accounts, retained copies, operational costs, and legitimate research needs; mediation is not a universal strongest option.

Whatever the posture, three implementation habits matter: log access at the level of individual queries, make the scope of each grant explicit and narrow, and design revocation as a first-class operation rather than an emergency.

Accountability needs enough relevant records to investigate events, identify responsibilities, and support remedies. Define log coverage, integrity protections, access, and retention in advance, including privacy constraints. A log is not automatically complete, and recording every possible event is not the only way to support a scoped investigation.

The chain is longer than it first appears: the data provider, the annotator, the model developer, the deployer who integrated it, the operator who ran it, and the person who pressed the button. Assign responsibility across that chain in advance, in writing.

The toy hash chain detects edits that are not accompanied by recomputed hashes. An attacker with write access can rebuild the entire unkeyed chain, and suffix truncation leaves the retained prefix valid. Completeness or authenticated origin therefore needs an independently trusted checkpoint, protected append-only storage, or signatures with managed keys. The card check only checks field presence; it does not verify the truth of the fields or certify a release as safe or compliant.

Distinguish governance guidance from binding law. The United States NIST AI RMF 1.0, released in January 2023, is voluntary guidance, not a universal compliance certificate. For an EU deployment, consult the AI Act, Regulation (EU) 2024/1689 together with current amendments and the Commission's implementation guidance. Assess system classification, organizational role, and the applicable dates; the original regulation's timetable alone may be outdated. Physical proximity to people alone does not classify every robot as high-risk. As of this chapter's 5 October 2026 review date, this discussion supplies engineering questions, not an individualized legal determination; a schema-valid card does not establish compliance with any jurisdiction's law.

Finally, plan for the moment a control fails.

• Containment. Revoke affected access, consider model rollback, and preserve the implicated training data under controlled access. Rollback speed and safety depend on the deployment. Deleting a provider's copy does not erase copies already held by others; assess downstream copies and model remediation separately rather than promising universal recall.
• Attribution. Use provenance records and the audit log to determine which data or which interface was the entry point.
• Notification. Determine the jurisdiction, organizational role, affected data, and risk threshold before deciding whom to notify. For example, EDPB guidance on GDPR breaches distinguishes documenting breaches, notifying the supervisory authority unless risk is unlikely, and communicating to individuals when high risk is likely, subject to exceptions. Not every security incident is a personal-data breach, and not every breach requires the same notification. Record the assessment and obtain the appropriate legal review.
• Correction. Determine whether the failure involved a poisoned source, miscalibration, an information-exposing interface, or another mechanism. Test a repair against the failure class as well as the observed instance. Incident evidence is one source of continual correction alongside planned tests, new data, and monitoring, as discussed in Part XII, Ch 5: Sim-to-Real Deployment and Continual Correction. Preserve evidence before modifying artifacts, under appropriate access and retention controls.