Transparency That Holds Over Time
Submission to Innovation, Science and Economic Development Canada
Public consultation: Enhancing trust in artificial intelligence through increased transparency
Submitted by: Luisa Ferreira, Founder & CEO, Ainfore — Ontario, Canada
Contact: Luisa.Ferreira@ainfore.com | ainfore.com
September 2026
1. About this submission
Ainfore is a Canadian decision-intelligence company based in Ontario. We build and deploy AI-enabled platforms for mid-market operations — in logistics, foodservice, and manufacturing — and work alongside their leaders on the questions that determine whether those systems can be trusted: data quality, decision processes, and where AI genuinely improves the business. Before founding Ainfore, I spent close to two decades in forecasting and advanced analytics — twelve years building and running the passenger-volume forecasts at the Greater Toronto Airports Authority, and later leading data science teams at Circana.
This submission responds to the discussion paper, “Enhancing trust in artificial intelligence through increased transparency.” It addresses Theme 3 (Information about AI Systems), Theme 5 (AI Agents), the relationship between those themes and AI incident visibility (Theme 4), and the cross-cutting questions. This submission focuses on the questions I know from direct experience: how mid-market businesses receive, evaluate, and act on information about the AI systems they deploy.
It speaks for the mid-market deployer: the businesses that buy AI rather than build it. Statistics Canada data cited in the discussion paper show that 19.2% of Canadian companies reported using AI to produce goods or deliver services in the year preceding the second quarter of 2026, up from 12.2% a year earlier. For most of them, AI arrives embedded in forecasting tools, routing software, customer service platforms, and ERP modules. They are the businesses AI for All counts on for adoption, and they are on the receiving end of the transparency this consultation is about: they read disclosures; they do not write them. Any measure should be designed around what they can use.
2. Summary of recommendations
R1. Establish a standardized, plain-language, deployer-facing disclosure — a “deployment summary” covering intended uses, unsuitable uses, known failure modes, expected human oversight, and update practices — developed through the Standards Council of Canada and the implementation guide to the Voluntary Code of Conduct, not through legislation. [Theme 3]
R2. Make notification of material changes in a hard condition of the planned Trusted AI Certification program and federal procurement of AI-enabled systems. A system should not carry a “trusted” designation if the organizations relying on it are not told when it materially changes. [Theme 3]
R3. For AI agents, establish baseline visibility as the default: action logs that deployers can access and retain, clear disclosure of the permissions an agent has been granted, and documentation of human oversight points — advanced through the Voluntary Code of Conduct and emerging observability standards. Legislation specific to agents would be premature. [Theme 5]
R4. Apply one principle across all measures: obligations sit with developers; benefits flow to deployers. No measure should create new documentation or reporting duties for SME deployers. [Crosscutting: SMEs]
R5.Sequence deliberately. Use standards, certification, and procurement now, and commit to a public review within 24 months: if developer disclosure practices have not converged, mandatory disclosure duties on developers — not deployers — would be justified. The European Union’s experience shows why this order matters. [Cross-cutting: sequencing and international coherence]
3. The core issue: systems change after the moment of trust
Most transparency measures under discussion describe an AI system at a single moment: the moment of release or procurement. Model cards, capability statements, and training disclosures document the system as it was built. The deployer’s problem is the system as it operates.
Vendors update models and AI-enabled tools on their own schedule. Behaviour shifts — sometimes subtly, sometimes materially — while the documentation that justified adoption stays frozen. The validation an organization performed when it adopted a tool quietly expires, and nothing tells the organization that this has happened. The result is a widening gap between accountability and visibility: Canadian organizations are accountable for decisions and outputs shaped by systems they cannot see into. The discussion paper’s own case studies illustrate the accountability side — a dealership held publicly to a chatbot’s erroneous offer, and Moffatt v Air Canada, where a tribunal held a company responsible for its chatbot’s statements. What those cases do not show is the visibility side: the deployer often has no practical way to know that a system’s behaviour has changed since it was last validated.
I saw this dynamic long before the current AI cycle. For twelve years I built and ran passenger-volume forecasts at Canada’s largest airport. In early 2020, every forecasting model in aviation failed at once — not because the models had changed, but because the world underneath them had, and for a time organizations everywhere kept acting on outputs whose assumptions had quietly died. The lesson was not that models are unreliable; it is that the trustworthiness of any analytical system is perishable and must be re-established whenever the conditions around it — or the system itself — change. AI sharpens this old problem into a new one: now the system itself also changes, continuously, on a vendor’s schedule, out of the deployer’s sight.
The same pattern appears wherever decisionmakers consume data produced upstream. In my later work leading data science teams in syndicated retail measurement, methodologies and panels were periodically revised — as they must be — and I saw how numbers that organizations had already acted on could be restated after the fact. The recipients’ problem was rarely the revision itself; it was learning it late, or in terms they could not connect to the decisions they had already made.
In our advisory work with mid-market operators, this is the recurring pattern. An organization adopts an off-the-shelf tool with embedded AI — demand planning, routing, document processing, customer service. Updates arrive without meaningful notice, or with release notes written for developers rather than for the operations leaders accountable for the output. The organization remains responsible for decisions the tool now shapes, with less visibility into that tool than it would tolerate from any human employee.
One engagement illustrates the pattern. A performance review for a mid-sized Canadian operator revealed that key operational dates were missing or incorrect in its system of record for a meaningful share of transactions. Nothing in the tooling flagged this; the reports built on that data continued to look normal and continued to be relied on. The gap surfaced only through independent validation — capacity most mid-market firms do not have on staff, which is precisely why disclosure and notification defaults matter.
We experience the AI version of this directly in our own practice. The models inside the tools we use are updated or replaced on the provider’s schedule; workflows validated on one version can behave differently on the next; and notice, where it exists at all, is written for developers rather than for the people accountable for the output.
The conclusion I draw for this consultation: transparency that supports trust must include change. Information about what a system can and cannot do is necessary but not sufficient; vendors must also tell deployers, in terms they can act on, when capabilities, limitations, or intended uses materially shift — so the deployer can re-validate, adjust its safeguards, or inform the people affected before decisions go wrong, rather than after.
4. Theme 3 — Information about AI systems
The discussion paper is candid about the current state: documentation practices are inconsistent across the industry, there is no common standard governing what should be disclosed when, to whom, and in what format, and the growing volume and technical complexity of model cards makes them difficult to assess. From the mid-market deployer’s seat, this understates the problem. A lengthy technical model card is not transparency for a chief operating officer; it is documentation. What deployers need is decision-grade information. My responses to the consultation questions follow.
What kinds of information about AI would you like to know to help you make informed choices about when and how to use AI? When and for which types of AI products is this information most important?
Four things, in plain language: what the product is designed for; what it should not be used for; the conditions under which its outputs become unreliable; and how it is updated, including whether I will be told when its behaviour changes. This information matters most for systems whose outputs feed consequential decisions — forecasting, pricing, scheduling, customer commitments, and anything that evaluates people — and least for tools whose failures are immediately visible and low-stakes. The CanLII review cited in the paper, in which dozens of Canadian courts encountered fictitious AI-generated case law, shows what happens when fluent tools are used outside their intended context by users who were never clearly told the limits.
What kind of information do businesses need to adopt AI safely and responsibly? Do businesses currently have access to the information that they need? How can the Government best balance increased transparency against the protection of confidential business information?
Businesses need what I call a deployment summary (Recommendation 1): a short, standardized, plain-language disclosure covering intended uses, unsuitable uses, known failure modes, the human oversight the vendor assumes, and update practices — comparable across vendors precisely because it is standardized. Today, mid-market businesses do not have access to this. Available information sits at two unusable extremes: marketing claims on one end, and technical documentation written for machine learning practitioners on the other. Between them there is very little a chief operating officer can act on — and almost nothing anywhere about change over time.
On confidential business information: the balance is more workable than the debate suggests, because deployers do not need to see inside the system. We need transparency about behaviour, not internals — capabilities, limitations, failure conditions, and material changes can all be disclosed without revealing model weights, architectures, training pipelines, or other proprietary methods. Behavioral disclosure of this kind is the same category of information any serious vendor already provides for non-AI enterprise software. Input transparency for rightsholders raises genuinely harder trade-offs, but they should not be allowed to stall the behavioral disclosure that adoption depends on.
Who in the AI value chain is best placed to provide what information about AI systems, how they are created, and their capabilities and limitations?
The obligation to disclose should follow knowledge. Developers know what their systems can do and what has changed, so system information and change notification belong with them. Deployers know the context of use, so communicating what a system or a change means for affected customers, employees, or decisions belongs with them. This division keeps each party responsible for what it can see — and it is why measures aimed at developers can benefit SMEs without burdening them.
Are existing disclosure practices and legal frameworks sufficient? If not, where do gaps remain and what actions should the Government take?
They are not sufficient, and the gaps are specific: comprehensibility (documentation is written for practitioners, not decision-makers), comparability (no standard structure, so vendors cannot be evaluated side by side), and continuity (no norm of telling deployers when a system materially changes — the largest gap and the least discussed). The right instruments now are standards and guidance for the deployment summary (Recommendation 1), and certification and procurement for change notification (Recommendation 2). The planned Trusted AI Certification program will fail its own name if a certified system can change materially without the organizations relying on it being told: a system cannot credibly be called trusted if the deployer is not notified when it materially changes. For this purpose, a change is material when it alters a system’s capabilities, failure modes, or appropriate uses in a way that could reasonably have affected the deployer’s decision to adopt the system or the safeguards placed around it. The obligation is deliberately light. Notification means a plain-language notice to the deployer’s designated contact when a material change ships — what changed, what it may affect, and what, if anything, the deployer should re-check — plus a cumulative, dated changelog the deployer can consult at any time. A vendor that maintains release notes already produces most of this; the change is writing it for the person accountable for the output rather than for another developer. Federal procurement is the single most effective lever available — it changes vendor behaviour without imposing any new obligation on SME deployers, and disclosure practices built for federal contracts tend to become market practice. Legislation is not the right first instrument here, for reasons set out under the cross-cutting questions — but it should remain visibly available (Recommendation 5).
5. Theme 5 — AI agents
Agents differ from other AI systems in kind, not just degree: they act. For a deployer, the essential transparency questions are what an agent did, what it was permitted to do, and whose instruction. My responses to the consultation questions follow.
Are you concerned about the use of AI agents? In what context is it most important to know when an AI agent is in use?
As an adviser whose work is helping organizations adopt AI, I am not concerned about agents as such — I am concerned about the gap between what agents are being permitted to do and what their deployers can see. Visibility matters most where an agent acts toward third parties on the organization’s behalf: spending money, making commitments, communicating with customers, or touching personal and commercially sensitive data. It matters least for agents operating in constrained internal workflows whose outputs are reviewed before anything leaves the building.
Who should be responsible for disclosing the use of AI agents? What kinds of information should be recorded regarding their activities, what disclosures should be made, and to whom?
Consistent with the principle that obligations follow knowledge: developers and platform providers should record and expose — to the deploying organization, by default — what the agent did (actions and tool use, with timestamps), what permissions and system access it held, and where human checkpoints sat in the workflow. Deployers, in turn, are the right party to disclose the use of agents to the customers and individuals affected, because only they know the context. The recipient hierarchy matters: the first audience for agent activity records is not a regulator or the public — it is the organization accountable for the agent’s actions.
What kinds of information do businesses need in order to confidently and safely use AI agents? Do businesses currently have access to the information they need?
Three things: action logs the organization can access and retain; a clear statement of the permissions the agent has been granted; and documentation of where human oversight is expected. Access today is uneven at best. Observability is frequently packaged as a premium platform feature rather than a default, which prices exactly the wrong organizations out of visibility. And the market’s current allocation of responsibility makes the gap worse: as the paper notes, some vendors have taken the position that users are responsible when agents do not behave as directed. That position is untenable when the user lacks the records needed to establish what happened. Whoever bears responsibility must hold the evidence.
Are existing technical solutions, market practices, and legal frameworks sufficient? If not, where do gaps remain and what actions should the Government take?
Not yet — but this is the one area where I would caution the Government against reaching for legislation. The paper rightly observes that the technology, its uses, and the supporting standards are all evolving quickly; a statute written now would encode today’s architectures — the cost of that sequence is visible in the European experience described under the cross-cutting questions. The constructive path is Recommendation 3: advance baseline visibility — logs, permissions, oversight documentation — through the Voluntary Code of Conduct and the standards work already under way, including the Open Telemetry conventions for AI systems, and support the emerging market of independent third-party attestation the paper describes. “Premature to legislate” is not “premature to act”: certification and federal procurement can require baseline agent visibility ahead of any statute, exactly as in Recommendation 2.
6. A note on Theme 4 — incidents
I will not respond to the incident questions in full, but one connection between Themes 3, 4, and 5 deserves to be on the record. From the deployer’s seat, an unannounced material change that degrades a system is often indistinguishable from an incident — outputs deteriorate, and the organization cannot tell whether it is looking at a malfunction, a misuse, or simply a different system than the one it validated. Incident visibility therefore depends on the measures discussed above: an organization cannot detect, characterize, or report incidents in systems it cannot see into. Whatever incident framework emerges from this consultation, two design constraints follow. Deployers should not carry reporting obligations for systems whose changes and actions vendors do not disclose to them; and change notification and agent activity logs should be understood as preconditions of any workable incident regime, not as separate topics.
7. Cross-cutting questions
When is AI transparency most important, and are there areas where action would be premature?
Transparency is most important, and most absent, where AI shapes consequential decisions inside businesses — the deployer-facing information and change-notification gaps described under Theme 3. That is where I would concentrate on action. Agent-specific legislation is the clearest case where action would be premature (Theme 5), and the same caution applies to any measure that would freeze a fast-moving technical practice into statute before standards mature.
How should any measures account for the circumstances of small and medium-sized enterprises?
Through one principle, applied without exception: obligations sit with developers; benefits flow to deployers (Recommendation 4). A 200-person distributor cannot absorb new reporting duties, and it also cannot negotiate disclosure terms with a global software vendor. The Government’s role is to shift the market default so that SMEs receive transparency without having to ask for it — through standards, certification, and procurement — while ensuring that no measure requires SME deployers to produce new documentation. Any compliance burden placed at the deployer end will suppress precisely the adoption of AI for All is designed to accelerate.
How should Canada ensure coherence between federal measures and provincial, territorial, and international frameworks? What approaches in other jurisdictions could inform Canada’s thinking?
Two lessons, one positive and one cautionary, both from the European Union. The direction of the EU’s deployer-facing transparency provisions is right: the AI Act entitles deployers of high-risk systems to information about capabilities and limitations, and downstream integrators of general-purpose models to documentation about the models they build on. Canada should align with that destination — and with Ontario’s disclosure-based approach in areas such as AI use in hiring — so that one disclosure can serve many jurisdictions and SMEs are not caught between inconsistent regimes.
The cautionary lesson is about order. The EU legislated ahead of the standards and tools businesses needed to comply. By July 2025, the gap was visible enough that dozens of major European companies — including Airbus, Mercedes-Benz, and Lufthansa — signed an open letter urging a two-year pause on the Act’s key obligations. The Commission responded with the Digital Omnibus on AI, proposed in November 2025 and in force by late July 2026, days before the original deadline: the high-risk obligations were deferred — to December 2027 for stand-alone systems and August 2028 for AI embedded in regulated products — and content-marking requirements were pushed to December 2026. Notably, the EU did not abandon its destination — the interaction-disclosure rules took effect in August 2026 as planned, and the deferred obligations remain in law. It corrected its route, at the cost of roughly two years of uncertainty for the businesses expected to comply with. Canada, moving later, can adopt the destination and avoid the detour (Recommendation 5): build the standards, certification, and procurement levers first, and commit now to a public review within 24 months. If, at that point, developer disclosure practices have not converged on the deployment-summary and change-notification norms described above, mandatory disclosure duties on developers — never on SME deployers — would be a proportionate next step. A voluntary approach with a defined review horizon is credible; a voluntary approach without one is a request to wait indefinitely.
How can Canada design measures to best account for the ongoing evolution in AI technologies and their use?
By designing for change rather than for a snapshot. Because the technology evolves continuously, any transparency measure anchored to a point in time — a card published at release; an assessment performed at procurement — will always age. Measures should instead attach to the system’s lifecycle: disclosure of update practices, notification of material changes, and retained activity records. This is the common thread of Recommendations 1 through 3, and it is the design property that keeps a transparency framework relevant as the technology underneath it moves.
8. Closing
For mid-market Canada, AI transparency is not a compliance topic; it is the precondition of adoption. Operations leaders will delegate real decisions to AI-enabled systems only when they can see what those systems are for, where they fail, what they are permitted to do, and when they change. The recommendations above are designed to deliver that visibility at zero added burden to the businesses doing the adopting.
A final note on standing. Ainfore occupies both seats in this consultation: we deploy AI-enabled platforms into mid-market operations, and we sit with the leaders who must decide whether to trust them. The recommendations here would bind our own products, and we hold ourselves to that standard — a deployment summary for what we ship, and notification to our clients when it materially changes. If a firm of our size can make that commitment, it is not a burdensome ask of the industry.
I would welcome the opportunity to contribute to any follow-up engagement, roundtable, or working group arising from this consultation, particularly on deployer-facing disclosure standards and SME adoption.
Luisa Ferreira
Founder & CEO, Ainfore
Annex A — Deployment summary: proposed structure
One page maximum, in plain language, versioned and dated, published by the developer and updated with each material change. For each section: what it contains, and the questions the developer answers to complete it — all answerable from knowledge the developer already holds.
1. Intended use — What is the system designed to do, stated in operational terms. The developer answers: What decisions or tasks is this system built to support? In what operating conditions, and with what inputs, does it perform as designed?
2. Unsuitable uses — Where the system should not be relied on. The developer answers: What uses has the developer not designed, not tested, or not validated the system for? Where has it seen the system misapplied?
3. Known failure modes — The conditions under which outputs become unreliable. The developer answers: Under what data, conditions, or edge cases do outputs degrade? How would a non-technical user recognize that this is happening?
4. Assumed human oversight — The review the vendor expects deployers to maintain. The developer answers: What checks does the developer assume a deployer perform before acting on outputs? Which outputs should never be acted on without review?
5. Updates and change — Update cadence, and how deployers are notified of material changes, per the definition in section 4. The developer answers: How often is the system updated, and on whose schedule? How does a deployer learn what changed, and where is the cumulative changelog?
A completed summary should still fit on one page.