AI governance is an operating model, not a policy.

Most organizations begin AI governance by drafting a policy. That is necessary, but it is not the work itself. A policy tells people what the organization believes and expects. It rarely answers the operational questions that determine whether an AI initiative should proceed, who can approve it, what evidence is enough, or what happens when the system behaves differently in production.

The better frame is an AI governance operating model: the repeatable system of decision rights, workflows, evidence, controls and feedback that connects principles to delivery.

Why this matters now

For federal institutions within the scope of the Directive on Automated Decision-Making, existing automated decision systems developed or procured before June 24, 2025 had until June 24, 2026 to comply with the new or updated requirements. The directive applies to production systems used to make an administrative decision or a related assessment about a client.

In Québec, IA-RI-2025-003-OP was formulated and took effect on December 5, 2025. It applies to public bodies covered by section 2 of the Loi sur la gouvernance et la gestion des ressources informationnelles des organismes publics et des entreprises du gouvernement, allowed a maximum six-month implementation period ending June 5, 2026, and repealed IA-RI-2025-001-OP.

Why the distinction matters

The regulatory dates create urgency. The major frameworks explain the operating shape. The NIST AI Risk Management Framework treats Govern as a cross-cutting function that shapes the other work across the AI lifecycle. ISO/IEC 42001 defines an AI management system around policies, objectives, processes and continual improvement, not a one-time document.

Seven operating decisions

1. Define what enters the system

Start with an inventory boundary that follows the use case, not the team that built it. The common failure is to treat the AI inventory as a data-science model registry. That captures custom models, but misses the AI that increasingly shapes real work: purchased features inside business software, embedded copilots, models reached through APIs, automations that consume model outputs, and shadow tools employees use in business processes.

The governing unit is the use of the system in context, not the vendor logo or platform name. The same copilot can rewrite a low-impact internal note in one workflow and influence a decision about a person in another. If those uses are recorded as one platform entry, the organization cannot assign the right owner, evidence gate, monitoring or approval path to either one.

2. Assign decision rights

Give every initiative a business owner accountable for the outcome and a technical owner accountable for the system. Then state who may accept residual risk, approve production use, grant an exception and stop the system. Committees can advise; named roles must decide.

3. Create one intake and risk-tiering path

Use a short intake that asks about the decision being supported, affected people, data sensitivity, autonomy, reversibility and regulatory context. The answers should place the initiative into a risk tier that changes the review depth. A writing assistant and an automated eligibility recommendation should not face the same gate.

4. Set evidence gates before deployment

For each tier, define the minimum evidence required to proceed: intended-use statement, data lineage, privacy and security review, evaluation results, human-oversight design, failure modes, vendor evidence and a monitoring plan. The gate should produce a recorded decision: approve, approve with conditions, return for work, or stop.

5. Govern vendors, data and architecture together

Procurement cannot be a separate lane. Contract terms, data residency, model changes, audit rights, retention, subcontractors and exit plans affect the architecture and the risk decision. Build a common review so vendor claims are tested against the actual operating context.

6. Continue after launch

Approval is not the finish line. Define indicators for performance, harmful outcomes, drift, override rates, incidents and complaints. Assign thresholds that trigger investigation, rollback or reapproval. Material model, data, purpose or user changes should return the system to review.

7. Put governance on the delivery cadence

The operating model should fit portfolio intake, architecture review, security assurance, change management and product delivery. Reuse existing forums when they can make the decision; add a new committee only when a real decision has no owner. Governance that lives outside delivery becomes paperwork, and delivery routes around it.

A practical 90-day start

1. Days 0–30: establish visibility and ownership. Define the inventory boundary, identify live and planned uses, name accountable owners and document who can approve, condition, stop or accept risk.
2. Days 31–60: design the path. Create the intake, risk tiers, minimum evidence and decision record. Connect procurement, privacy, security, architecture and legal review around one flow.
3. Days 61–90: pilot on real work. Run three different initiatives through the model. Observe delays, duplicated reviews and missing evidence. Adjust the design, publish a small dashboard and set the first improvement cycle.

Do not wait for a perfect enterprise inventory or a universal risk taxonomy. Start with enough structure to make three real decisions consistently, then improve from evidence.

What leadership should ask next

• Can we name every AI system influencing a material decision or handling sensitive data?
• Can the accountable owner explain why production use was approved and show the evidence?
• Would we notice if the system's behaviour, vendor model or data changed?
• Who has the authority, and the operational ability, to stop it?

Those questions reveal more about governance maturity than the existence of a policy document.

If any of these four questions has no clear answer, the AI Governance & Compliance Readiness is designed to resolve that gap.

Sources and scope

Primary references: NIST AI RMF Core; ISO/IEC 42001; the Treasury Board Directive on Automated Decision-Making, especially sections 1.2.1, 5.1 and 8.1; and Québec's IA-RI-2025-003-OP, especially sections 2, 23 and 25. This article provides general operational guidance, not legal advice. Applicability depends on sector, jurisdiction and use case.