The First 90 Days of AI Governance

The new AI governance leader almost never inherits a blank slate. The general counsel has a backlog of tools that were never reviewed. The product manager has a customer-facing release already on the calendar. Engineering assumes the new committee will become a bottleneck. Finance wants to know why the company needs another control function. And multiple executives have brushfires they each want extinguished.

This is the real starting point, and those specifics change what the first three months are for. These early days are a test of whether the organization can install a working operating system for governance while the business continues to run around it.

Intellectual honesty is required from the outset, internally and with the C-suite, about what the first months can and cannot deliver. By Day 90, leadership should not expect every AI risk to be retired. It should expect a more useful foundation: visibility into the highest-consequence uses, named accountability, proportionate decision gates, an evidence trail, and a repeatable path from intake through monitoring.

What Has to Be True Before Day One

Three principles shape the development of a successful program, as each corrects a common pitfall.

An AI governance program is an operating system, not a document. The most common failure in the first 90 days is to produce a written policy artifact and mistake it for the governance program. A policy is not a control, and a committee is not an operating system. What follows is a sequence for standing up intakes that work, risk tiering that scales with consequence, monitoring with named owners, and an evidence trail that makes decisions defensible. In the steady state, governance should not materially add to cycle time. A team that knows on day one which evaluation results, data lineage, and sign-offs will be asked for produces them as it builds. Review then confirms a record that already exists.

Enterprise governance ownership and system ownership are different things. Two layers of ownership must be named, and they’re routinely conflated. At the enterprise layer, one executive is the enterprise governance owner, accountable for the AI governance program as a whole and for ensuring the three pillars function (Who Should Own Enterprise AI Governance?). If the AI governance leader holds that executive standing, the matter is settled; if not, another executive should serve as enterprise governance owner and sponsor the governance leader’s work while the leader runs day-to-day activities.

Additionally, across the enterprise, every AI system has one accountable owner, a business leader supported by a named technical lead who can change the system. Where a system’s tier or a categorical trigger requires formal review, a named risk or compliance partner joins them, responsible for identifying which obligations apply and confirming the required controls exist. The system owner remains accountable for the result the system produces, regardless of the use case. Put differently, the enterprise governance owner is responsible for the organizational operating system; system owners are responsible for the individual systems running inside it. A program that never distinguishes the two ends up with governance that everyone endorses and no one is accountable for.

The governance leader inherits an ongoing concern, not a white space. The program must address live problems while building something systemic, and the two paths must run in parallel. Every action taken to resolve an immediate concern should therefore become an instance of, or a step toward, the permanent framework.

A senior executive’s concern might become the first application of the risk-tiering method; an urgent deployment might become the first test of intake and approval (AI Risks Don’t Wait for Committees). Solving the general counsel’s outstanding concern in week three can earn the credibility needed to ask engineering for a sign-off gate in week seven. The loudest concern may determine which component gets built first, but it should not determine whether the remaining components get built at all.

Most companies already have some combination of security architecture review, privacy impact assessment, procurement and vendor diligence, software-development lifecycle gates, model-risk management, quality or clinical-safety review, and incident processes. Build on what exists, identify the genuinely AI-specific gaps, and define where AI review connects to each existing gate. The fastest way to lose engineering and finance in the first month is to stand up a second review process for questions the organization already knows how to answer.

With these three principles anchoring the approach, the 90-day clock begins. Every organization sequences this differently, and the calendar that follows is a target rather than a prescription. In most cases, the work falls into three phases: mapping the reality, installing a minimum viable control plane, and proving that the model scales.

Days 1 to 30: Establish Credibility and Map the Existing State

The first thirty days are for establishing authority, mapping the internal AI landscape and the controls already around it, and using one urgent concern to build the first element of the operating system. The deliverable is a sharp program assessment of manageable length with prioritized findings, not a fifty-page maturity model no one will read.

This phase runs two inventories in parallel. The first is the AI use-case and system inventory. The phrasing matters, because “systems inventory” alone invites teams to omit pilots, embedded vendor features, and informal uses, which is where the surprises live. Settle a practical definition of what enters the governance process before counting begins, since one group will count only generative AI while another includes every predictive model, and procurement may not recognize an embedded feature as a system at all. The definition need not resolve every taxonomic argument, but it must cover internally developed models, purchased products, embedded AI features, general-purpose tools, and shadow uses.

Two further notes. Registration and review are different goals, and confusing them makes governance feel like friction. Registration should be broad enough to create visibility, easy enough that complying beats hiding, and required of everything. Review is triggered by consequence, external impact, sensitive data, autonomy, or a categorical legal requirement. A team experimenting with a summarization feature should register it in minutes and hear nothing further; a team building a coverage-determination model should expect a conversation. This first pass will not be complete, since shadow uses resist a single census and some surface only once people have a reason to declare them. Organize the result by consequence rather than prominence, because high-profile systems attract scrutiny while lower-profile ones drift quietly through hotfixes.

The second inventory lists the specific concerns executives already hold, gathered through structured conversations across engineering, product, security, legal, and others. This one matters as much as the first, because it captures leadership prioritization and identifies which permanent component to build first.

With both inventories in hand, address the immediate bleeding with an eye toward the long-term design. Act on the chosen fire, but do so through the framework, so the fix leaves permanent structure behind it. In practice that means three artifacts by Day 30. The registry begins, with every entry carrying a provisional tier and a named owner. A pre-deployment checklist exists for the highest-consequence tier, since that tier is where the brushfire almost always sits. And a monitoring specification exists for that same tier, naming both the metrics watched and the response each one triggers. This is not the finished control plane. It is the first working component, built under pressure against a real system, which means the next thirty days generalize something already in use rather than design something from scratch.

Deliverable by Day 30: a prioritized program assessment; a working scope definition; a registry underway with provisional tiers and named owners; highest-tier deployment and monitoring requirements; and a mapped inventory of executive concerns.

In the full article on Substack, we address the second and third months, offer tests to assess the direction and progress, and offer historical perspectives.