A voluntary code needs a control map
Signing a code can clarify a compliance route, but only a mapped set of owners, controls, evidence, and exceptions makes the commitment operational.
A signature is easy to communicate. It creates a visible commitment and can align teams around a shared framework. It does not, by itself, identify which model is covered, which measure applies, who owns it, which evidence proves implementation, or how a departure is handled. The operational work begins where the announcement ends.
The Commission's current Q&A describes the General-Purpose AI Code of Practice as a voluntary tool with transparency, copyright, and safety and security chapters, and notes that providers may demonstrate compliance through the Code or alternative adequate means. A signatory still needs a system that maps relevant commitments to its models and practices.
A control map should not copy the code into a spreadsheet and call every row complete. It should translate each selected measure into scope, implementation, evidence, owner, dependency, exception, test, and review cadence. Where the organization uses an alternative method, the map should state the rationale and the evidence that makes the alternative adequate for the obligation in question.
Map commitments to releases
Bind the map to model families and versions. A measure implemented for a hosted flagship may not apply identically to an open-weight release, a fine-tuned derivative, or a model placed on the market earlier. The mapping should resolve which commitment governed each release, when it became effective, and whether later changes reopened the assessment.
Preserve interpretations and dissent. Cross-functional teams may disagree about the scope of a measure, confidentiality of a report, or sufficiency of a test. Record the decision owner, competing views, evidence cutoff, and recheck trigger. Forced consensus can produce a clean map while erasing precisely the uncertainty a reviewer needs to understand.
The code is the shared language; the control map is the institution's accountable implementation.
Dependencies should be explicit. Evaluation coverage may depend on a benchmark, incident reporting on a detection pipeline, cybersecurity on a cloud control, and training summaries on data lineage. If the dependency changes or fails, the mapped measure should enter review rather than remain green because the policy text did not change.
Internal audit should sample effects, not only documentation. Select a model and follow the relevant commitments into test results, risk decisions, public artifacts, incident exercises, and release gates. Then select an operating control and trace it back to the commitment. Bidirectional traceability catches both unmapped duties and ornamental controls.
When the Code changes, diff commitments before changing status. Identify new, narrowed, clarified, or retired measures; assess release impact; and preserve the prior map for historical accountability. A living code requires versioned adoption, not a policy page that always points to the newest text.
Make the obligation operational
Begin with the code version, selected measures, covered model releases, alternative means, exceptions, and dependencies that define the organization's implementation route. Express it as a control object rather than a policy summary: scope, triggering condition, applicable system or model version, permitted exception, effective time, evidence source, and the consequence when the control cannot establish compliance. This lets engineering, product, legal, and operations examine the same boundary without pretending their responsibilities are interchangeable.
The minimum receipt should retain commitment-to-control mapping, owner, effective date, release scope, test and effect, alternative rationale, dissent, dependency state, and review receipt. Keep the record proportionate and protect confidential information, but make it possible to determine which rule, artifact, system version, and accountable decision governed the event. A folder of undated screenshots may show that work occurred; it rarely proves that the operative control held for the affected release.
Test the implementation by sampling commitments into live controls and live controls back to commitments across model families, release dates, exceptions, and a simulated code revision. Include ordinary cases, boundary cases, degraded dependencies, and known exceptions. Preserve the starting state, observed output, machine-readable evidence, user-visible result, and any human intervention. Re-run the test after changing a model, content pipeline, interface, standard, provider, or policy interpretation.
The code implementation owner with independent assurance review should decide whether the evidence supports continued operation, a narrower scope, a compensating control, or a hold. The owner needs authority over the affected release and access to the evidence. Record unresolved interpretation separately from a technical defect so an engineering patch does not masquerade as a legal conclusion.
Monitor both presence and effectiveness. A marker can exist but be stripped downstream. A disclosure can render but arrive after exposure. A document can be submitted but refer to an obsolete model. Pair a control-presence measure with a consequence or comprehension test, give the claim a review date, and reopen it when a dependency changes.
Maintain a dependency register for the control. Model endpoints, editing pipelines, content formats, user interfaces, identity services, submission portals, vendors, and external standards can change the evidence without changing the policy text. Name which changes invalidate the last test and which monitoring signal proves that the dependency remains inside the reviewed state.
Exercise the exception path as carefully as the ordinary path. Record who can invoke it, which facts they must supply, how long it lasts, what capability or distribution is reduced, and which compensating evidence remains. An exception without expiry and re-entry criteria becomes a second operating model that can silently outlive the reason it was approved.
Keep public and executive claims no broader than the tested boundary. Say which systems, releases, formats, routes, and dates the evidence covers, and identify material exclusions. When a control fails or a dependency moves, update the claim and the remediation record together. A transparent limitation protects more credibility than a universal statement built from a narrow passing test.
— Dispatches · Summit Cognitive
Continue from here
Turn the argument into a practice.
Get new dispatches, assess how your organization handles consequential decisions, or explore Summit Cognitive.