A code of conduct needs an assurance layer.

Position in brief

Publishing intended model behaviour for public comment is the right instinct, and stating that these systems must remain subordinate to human authority is the right starting point. Our submission takes no issue with the values. It concerns verifiability.

A behavioural code sits at the model layer. Accountability sits at the institutional layer, with whoever put the system in front of a customer, a market or a regulator. Between those two layers is a gap that no code closes on its own: the difference between what a model is intended to do and what an institution can demonstrate it did, on a named date, in production, under the version it actually had. That gap is the assurance layer, and every one of our twelve recommendations is aimed at making it narrower.

We are model-neutral by design. Cabier governs Western, open-weight, sovereign, private and on-premise estates, endorses no provider, publishes no vendor comparison, and neither trains, hosts nor resells the models it assures. Nothing in this response should be read as approval or criticism of any commercial party.

What is being consulted on

The document is a first draft describing the intended behaviour and values of a provider's own models, published for open comment rather than adopted as an operative training standard, with a stated review window of several weeks. It sets out that models should remain under human control, should not resist interruption, and should not set their own goals, and it places human interests ahead of the system's.

We read this the same way we read every provider publication of expected behaviour during 2026: as an observed direction of travel, in which the industry is migrating from principles toward operational expectations. It is a signal about where oversight is heading, not a validation of anybody's product, ours included.

Intent, behaviour, evidence

Three things are routinely collapsed into one in this debate. Intent is what the builder means the system to do. Behaviour is what the system does in a specific deployment, with specific tools, specific data and specific authority. Evidence is what a third party can inspect afterwards to establish which of the two occurred.

A code of conduct is a statement of intent, and a good one shapes behaviour. It cannot produce evidence, because evidence is generated at runtime inside the deploying institution: the tool call that was refused, the action held for human confirmation, the interruption that landed, the evaluation that failed and blocked a release. A board cannot show a supervisor a value. It can show a refusal log.

This is why our recommendations are almost entirely structural. Each one asks the same question of the draft: if this commitment were breached in production next March, what would exist to prove it, and who would be able to read it?

Twelve recommendations

None of these require the disclosure of weights, training data or commercially sensitive architecture. They are drafting and process changes.

The deployer's residual duty

Suppose every recommendation above were adopted in full. A regulated institution would still have to discover the models and agents inside its own estate, including the ones that arrived enabled by default inside purchased software. It would still have to register each agent with a named human owner, bound tool permissions and a defined financial and action authority. It would still have to observe behaviour in production, intervene when it drifted, and retain the evidence that it did.

No provider commitment reaches into that estate. This is the practical reason we argue for commitments to be labelled by owner: the most expensive governance failure we encounter is not a broken provider promise. It is an institution that read a provider promise as a control it therefore did not need to build.

Where a code meets in-force law

The obligations that bite are already operative. General-purpose model duties and deployer duties under the EU AI Act. Serious-incident reporting with clocks that start on discovery. Prudential model-risk guidance that requires validation by a party that did not build the model. Third-party dependency, concentration, exit and continuity expectations under DORA. Sectoral and state rules layered on top.

A behavioural code drafted without reference to those instruments still has to be translated by every regulated deployer, separately, at cost, and inconsistently. Drafted with them in view, the same commitments can be consumed directly as control evidence. That is a small editorial difference with a very large downstream effect.

What we are not asking for

We are not asking for model weights, training corpora or architectural detail. We are not asking for a provider to accept liability for how an institution configures a system. We are not proposing that behavioural codes be replaced by regulation, nor that they be treated as a substitute for it. And we are not asking any provider to adopt, license or reference our own control set.

We are asking for one property: falsifiability. A commitment that cannot fail observably cannot be assured, and an unassurable commitment eventually becomes an unowned risk.

Text of our submission

Published in full, unedited. Institutions preparing their own submissions are welcome to reuse the structure.

Cabier Consulting — response to the public consultation on a draft AI Code of Conduct
Submitted 14 September 2026 by Dax Philbert, LLM, Chairman & Chief Executive, Cabier Consulting.

Cabier Consulting operates trust and assurance infrastructure for regulated enterprises and digital financial markets. We are model-neutral: we govern Western, open-weight, sovereign, private and on-premise AI estates, and we neither train, host nor resell the models we assure. We therefore respond as a party that has to evidence, to boards and supervisors, whether commitments of this kind held in production.

Our position in one sentence: a behavioural code is necessary and insufficient, and the distance between the two is the assurance layer.

We support the publication of intended model behaviour for consultation, and we support the principle that these systems remain subordinate to human authority. Our recommendations concern verifiability rather than values.

1. Write each behaviour as a testable assertion with an observable failure condition.
2. Name, beside each commitment, the artefact an independent party may inspect.
3. Version the code, publish a change log, and bind code versions to model versions.
4. Mark each commitment as model-inherent, configuration-dependent or deployer-owned.
5. Specify interruptibility operationally: who may interrupt, through which interface, at what latency, what happens to work in flight, and what record results.
6. Address agent authority as a distinct object from model behaviour: tool permission, delegation, spend and action authority, and irreversible operations.
7. Provide a route for independent evaluation of the behavioural claims and express results as dispositions with evidence rather than scores.
8. Align the behavioural incident taxonomy to the fields supervised institutions must report, and carry those fields into provider notifications.
9. State the withdrawal and continuity position: notice periods, migration windows, and evidence retention when a capability or version is withdrawn.
10. Treat sovereignty as a control-plane property and state which commitments hold identically across hosted, sovereign, private and on-premise configurations.
11. Adopt a stated non-retaliation position for good-faith adversarial testing, with a disclosure channel and a response commitment.
12. Publish how the consultation was dispositioned: themes received, changes made, recommendations declined and why.

We make no request for proprietary information. Every recommendation above can be satisfied without disclosing model weights, training data or commercially sensitive architecture.

We would welcome the opportunity to contribute to any technical working group on evidence formats for behavioural commitments, and we will publish our own response openly so that deployers may reuse its structure.

Dax Philbert, LLM
Chairman & Chief Executive, Cabier Consulting
dax.philbert@cabierconsulting.com

How each point is already operable

We do not raise these points abstractly. Each is a working surface an institution can inspect, built before this consultation opened.

The wider argument sits in Global AI Assurance, and the umbrella itself is at Global AI Assurance.

Questions we have been asked