Ottawa asked the right question about AI transparency. The answer is not a label.

Pillar 05 · Algorithmic

ISED opened a public consultation on AI transparency on July 23. It closes September 23, which gives anyone who cares about this two months to write something down.

The discussion paper covers five areas: detecting AI-generated content, telling people when they're talking to a machine, publishing consistent information about what a system can and can't do, tracking serious incidents, and tracking what AI agents actually do. Those are the correct five. I have no complaints about the scope.

My complaint is about the assumed answer. Every one of those five is being approached as a disclosure question. Who has to say what, to whom, and how prominently. That framing produces rules that are satisfied by a statement.

A statement is made by the operator of the system. The operator of the system is the party with the most to lose if the statement is inconvenient. We have run this experiment already, in privacy, in security certification, in ESG reporting, and in cloud residency. It ends the same way every time.

Why labelling doesn't hold

Watermarking works until someone doesn't want it to. There is a whole literature on removal attacks and it is not a close fight. C2PA content credentials are better engineering, but the metadata comes off the first time content passes through a platform that re-encodes on upload, which is most of them, and it comes off entirely if you screenshot the thing. Neither approach was designed to survive a motivated adversary, and neither is what you want underneath a legal obligation.

Model documentation has a different problem. It's self-reported. A vendor writes a card describing capabilities and limitations, and the card is accurate in the sense that nothing in it is false. What you get is a marketing name and a version string. "Version 4.2" is not an identity. Two systems shipping under the same product name in the same month can behave differently, because weights get updated, safety layers get tuned, routing gets changed underneath you. If the register records the name, the register records nothing useful.

And the interaction disclosure, the "you are chatting with an AI" banner, is real but shallow. It tells you what the operator decided to display. It tells you nothing about what happened.

None of this is fraud. It's just what you get when a trust regime is built out of assertions.

The question that actually matters

Can a third party verify the claim, after the fact, without the vendor's cooperation, and detect whether the record was changed?

If yes, you have transparency. If no, you have disclosure, which is a different product sold under the same name.

The mechanism for yes is not exotic and it is not expensive. Sign the output at the point of generation, inside the runtime that produced it, binding a content hash to the identity of the model and the time. Identify the model by the hash of its weights rather than by what marketing calls it. Write the record to an append-only log with periodic published checkpoints, so that altering history requires forging a chain rather than running an UPDATE statement. Ed25519 signatures and Merkle accumulators. This is 2018 technology being asked to do a 2026 job, and it can.

The incident tracking piece is where this stops being philosophical. You cannot investigate an event using logs that the subject of the investigation could have edited. What you get is the vendor's account of the event, with a timestamp on it. Any serious incident regime without immutable logging underneath is a reporting exercise, and it will be discovered to be one at the worst possible moment, probably during something involving a hospital or a benefits system.

Agents are harder and more urgent. The paper flags them, correctly. An agent takes actions on your behalf. You can't label an action. What you can do is emit an attested record for each one: which model, which weights, what inputs it saw, under whose delegated authority it acted, what it changed. That's chain of custody. Every regulated industry in the country already knows what a chain of custody looks like and why it exists. We should stop pretending this is a novel problem in need of a novel vocabulary.

The jurisdiction problem

Here's the part that gets skipped.

An attestation you can't verify from inside Canadian legal authority isn't much of an attestation.

AI for All, launched June 4, names digital sovereignty as a goal. Bill C-36 and Bill C-34 are moving. The intent is not in question. But if the provenance registry, the incident log, and the agent audit trail sit in infrastructure operated by a foreign-controlled provider, they are reachable by that country's legal process, and they are rewritable by whoever holds the keys. Data residency doesn't fix it. A log stored in Toronto and controlled from Redmond is controlled from Redmond. I've made this argument about the CLOUD Act enough times that people have started finishing the sentence for me, and it applies with more force to an audit trail than it does to a file share, because the whole value of the audit trail is that nobody can quietly change it.

The fix is structural rather than contractual. Encrypt before it leaves the customer's control. Split the material across independent custodians in independent jurisdictions so no single one of them can reconstruct it. Hold the keys under Canadian authority. Then a compelled-disclosure order doesn't get argued in court, it gets answered with the fact that the party receiving it cannot comply. That is a better answer than a strongly worded clause.

If you're writing a submission

Five things I'd ask for, and none of them requires a new agency:

Provenance bound at generation rather than applied afterward. Model identity as an artifact hash. Append-only audit logs that a third party can verify without asking the vendor's permission. Attested action records for agents, including the authority the agent acted under. And verifiability that survives inside Canadian jurisdiction, by construction rather than by assurance.

Four of those five are a quarter of engineering work for a competent team. They're cheap because the cryptography is old and well understood. What's expensive is standing up a trust regime that people eventually learn not to trust, and then having to do it again.

Two months. Use the word verifiable more than you use the word responsible. Only one of them can be tested.

https://www.canada.ca/en/innovation-science-economic-development/news/2026/07/government-of-canada-launches-public-consultation-on-ai-transparency.html

Bias declaration: I run SkyeConnex. We build cryptographic data custody and sovereign AI infrastructure, including attested runtimes, append-only provenance, and key architectures designed so that no single party can be compelled to reconstruct anything. A transparency regime built on verifiable mechanism is good for my business. I was making this argument before there was a consultation to make it to, but you should read it knowing where I sit.