The first 90 days of an AI governance program

What to do in month one, two, and three when you are asked to stand up AI governance from a standing start.

Most AI governance programs are kicked off the same way. An executive announces, in a town hall or a board meeting, that the organisation will take AI governance seriously. A leader is appointed, often without a clear mandate. A budget is allocated, often without a clear scope. The new leader is given ninety days to show progress, and at the end of the ninety days they will be expected to present something tangible to the board or the executive team.

The temptation in this situation is to begin by selecting a framework. ISO 42001, NIST AI RMF, the EU AI Act compliance program, some combination. This is the wrong instinct. Framework selection is a tool for organising work that you already understand. If you do not yet understand the work, choosing a framework first will produce a plan to govern an organisation that does not exist.

What follows is a more useful sequence: inventory in the first month, classification in the second, governance ritual in the third. Each phase builds on the previous one. Each phase produces a tangible artefact that can be shown to the board. By day ninety, the program has a foundation that subsequent work can build on, rather than a plan that subsequent work will quietly ignore.

Month one: inventory, not architecture

Day one of the program should be spent walking teams. Not meetings about AI strategy, not workshops on risk appetite, but conversations with the people who are actually building and operating AI systems. The goal of month one is a single, complete, honest list of every AI system in the organisation. Name, owner, data source, output, current status. Nothing else.

This is harder than it sounds. The inventory will start with the systems the central team already knows about, which in most organisations is a small fraction of what exists. Shadow AI lives in pockets: a marketing team using a generative tool to draft campaigns, a finance team running a forecasting model in a spreadsheet, an engineering team prototyping with foundation models against production data. None of these will appear in the central systems registry. All of them are governance scope.

The way to find them is to ask, system by system, team by team, what AI is involved in the work you do. Not what AI projects are you running, which produces a tidy and incomplete answer. Where in your workflow is a model influencing a decision, automating a step, generating content, or scoring an outcome. This question produces a longer and more accurate list. It also begins to teach the central team what kinds of AI use are common in the organisation, which informs every subsequent decision.

By the end of month one, the inventory should be complete enough that adding new systems is the exception, not the rule. There will still be gaps. There always are. But the central team should be able to say, with confidence, here is what we run.

Month two: classification against actual obligations

With the inventory in hand, month two is classification. The goal is to know, for each system on the list, what obligations apply to it. This requires being specific about which obligations the organisation is in scope for. EU AI Act? ISO 42001? Sector-specific regulation: financial services, healthcare, employment? Internal policies that the organisation has committed to?

Each obligation framework has its own classification logic. The EU AI Act uses Annex III categories with deployment context modifiers. ISO 42001 uses a risk-based approach mapped to clauses. Sector regulations vary. The work of month two is to apply each relevant framework to each system in the inventory and produce a matrix: rows for systems, columns for obligations, cells indicating what applies and at what level.

This is not yet a control framework. It is a classification. The distinction matters. A classification tells you what protection a system needs. A control framework tells you how to provide it. Month two produces the first; month three begins the second.

The classification should be peer-reviewed before it is presented. The categories under each framework are ambiguous at the edges, and a classification by a single individual will reflect that individual's interpretation. Two people working through the same matrix independently will disagree on perhaps twenty percent of the cells, and the disagreements are where the most interesting questions live. Resolve them explicitly, document the reasoning, and the classification becomes defensible.

Month three: the first governance ritual

Month three is when the program acquires a heartbeat. The goal is a single, recurring, well-defined governance ritual that runs from this point forward. Not a framework, not a binder, not a strategy document. A meeting, with a published agenda, named participants, and minutes that live in the same place as every other engineering decision.

The ritual should be small. A thirty minute standing review, weekly or fortnightly, covering new systems entering the inventory, classification decisions on those systems, material changes to existing systems, and any incidents or near-incidents from the period. The participants should include the leader of the program, a senior engineering representative, a representative from legal or compliance, and the system owner for anything being reviewed that week.

The ritual matters more than the output. Once it exists, the program has a working surface. Decisions get made. The inventory stays current because there is a forum in which new entries are reviewed. The classification matrix stays current because changes are reviewed in the ritual. The risk register, when it eventually exists, lives in the same forum.

Without the ritual, the program is a project with a beginning and an end. With it, the program is an ongoing function with a cadence, and everything else, framework selection, control design, audit preparation, can be built on top of it.

What to present at day ninety

The board or executive presentation at day ninety should be short and concrete. Three artefacts: the inventory, with a count of systems and a brief description of what was found, including any surprises; the classification matrix, showing which obligations apply to what; the governance ritual, with a description of how it works, who participates, and what it has already decided in its first few weeks of operation.

The presentation should not include a multi-year roadmap. It should include a proposed next quarter of work, building on the foundation that has been laid. The roadmap, if one is needed, comes after the program has run long enough to know what the organisation actually needs. Most organisations that present a multi-year roadmap at day ninety end up replacing most of it within six months.

What to resist

There are three temptations in the first ninety days that should be resisted.

The first is tool procurement. There will be pressure to select a GRC tool, a model registry, a governance platform. None of these decisions should be made in the first quarter. Tool selection in advance of operating experience produces tools that do not fit. Run the governance ritual on a shared document and a spreadsheet for at least a quarter before selecting any dedicated tool.

The second is policy writing. There will be pressure to publish an AI policy, an acceptable use policy, an ethics policy. Policies written before the inventory is complete will be either too general to be useful or too specific to be accurate. Wait until month four or later, when the policy can be written from observed reality rather than assumption.

The third is external announcement. There will be pressure to publish, to speak at conferences, to demonstrate leadership. The first ninety days are not the time. Speak externally once the program has been running long enough to have something honest to say. Premature external positioning creates expectations that the program then has to spend its second quarter meeting, rather than building the foundation that would have made the second quarter genuinely productive.

The state at day ninety-one

On day ninety-one, the program should look modest from the outside and substantive from the inside. A complete inventory. A classification matrix. A governance ritual that has run several times. A small backlog of decisions made, and a clear sense of what the next quarter needs to address. No framework selected yet, no policies published yet, no tools procured yet. Those will come, and they will be better for having waited.

The point of the first ninety days is not to finish anything. It is to establish a foundation that the next ninety days can build on without rework. Most programs fail because they try to build the cathedral in the first quarter, and discover in the second quarter that they laid the foundations in the wrong place.