The first ninety days of an AI governance program

The program that fails is the one that starts with a policy

Most AI governance programs begin the same way. Someone writes a policy document, circulates it for comment, publishes version 1.0, and announces the program. Six months later nobody can answer a customer asking how many models are in production, which ones touch personal data, or who approved the chatbot that started answering billing questions in March. The policy is real. The program is not. That gap is the whole problem, and it comes from starting with the artifact that is easiest to produce instead of the one everything else depends on.

The dependency runs the other way. You cannot write a useful policy about systems you have not counted, tier risk on an inventory you do not have, or produce evidence for a control that was never wired into a pipeline. So the ninety days have an order: find the systems, sort them by how much damage they can do, put real gates on the ones that matter, and generate evidence automatically from the day the gate exists. Policy comes last, because by then you are describing what the company already does rather than what you hope it will.

The forcing function varies. An enterprise customer's third-party AI questionnaire, a federal buyer citing NIST AI RMF in a solicitation, EU AI Act obligations landing on a product sold into Europe. The first ninety days do not vary much at all.

Days 1 to 20: count the systems, including the ones nobody told you about

The inventory is the foundation and it is always worse than the sponsor expects. Two numbers matter and they are never close: how many AI or ML systems leadership believes exist, and how many actually run in production, counting vendor features, embedded models, and things an analyst built in a notebook that a business process now depends on.

Interviews alone will not close the gap, because people do not report what they do not think of as AI. A spreadsheet with a forecasting add-in, a SaaS product whose new release added summarization, a fraud rule set someone replaced with a gradient-boosted model two years ago: none come up when you ask a director to list their AI systems. Run three passes in parallel. Interview the engineering leads and the business owners. Pull technical signals: outbound calls to model-provider API endpoints in egress logs, imports of the common ML libraries across repositories, GPU instance types in cloud billing, model artifacts in object storage. Then read the vendor list, because in most companies more than half the AI in production arrived inside software somebody bought.

Each entry needs six fields and no more, or the inventory never gets finished: what it does in one sentence, who owns it, what data goes in, what decision comes out, whether a human reviews that decision before it takes effect, and whether it is built, bought, or fine-tuned from someone else's base model. That last field decides who is responsible when it misbehaves, the question every downstream process eventually asks.

Budget three to four weeks of one experienced person's time at a company with a few hundred engineers. The output is a list, not a document, and it goes somewhere queryable from day one. The version that lives in a spreadsheet attached to an email is stale within a month and everyone knows it.

The top row is the one that changes procurement behavior. A company can govern everything it builds and still be surprised by a model it never chose, arriving inside a product renewal it approved without reading the release notes. That is a contract-language problem before it is an engineering problem.

Days 20 to 35: one tier that changes what happens

Risk tiering is where governance programs go to die, usually by producing a rubric with fourteen weighted dimensions that yields a number nobody acts on. The test is simple. If moving a system from tier 2 to tier 1 changes nothing an engineer has to do, the tiering is decoration.

Three tiers is enough, drawn on consequence rather than technology. A system is high risk if its output materially affects a person's access to money, employment, housing, healthcare, or legal standing, if a wrong answer creates physical safety exposure, or if it acts without a human reviewing the action. Customer-facing but reversible is medium. Internal tooling with a human reading every output is low. That is the whole rubric, and it applies to a two-hundred-system inventory in a week.

The EU AI Act uses a comparable consequence-based structure, and its Annex III list of high-risk uses reads almost exactly like the paragraph above. It is worth reading even with no European exposure, as the most concrete published articulation of where regulators draw the line. NIST AI RMF does not tier for you, but Map is where tiering belongs, and mapping your definitions to Map 1.1 and Map 5.1 saves an argument later with any assessor working from the framework.

Then attach obligations to each tier, and make them things a person does rather than things a document says. High risk: documented evaluation before launch, a named human accountable for the decision, a red-team pass on any language-model surface, monitoring with an alerting threshold, and review annually or on any material change. Medium: registered, evaluation results recorded, owner named. Low: registered, and nothing more. The tier that imposes nothing on low-risk systems is what buys compliance with the tier that imposes a lot on high-risk ones.

Days 35 to 60: the gate goes in the pipeline, not in the policy

A governance requirement that lives only in a document gets met by whoever remembers it. To make it stick, put it where the work already flows: the deployment pipeline and the change-management system, the two places every production change passes through regardless of who is watching.

The mechanism is a registration check. A service that calls a model endpoint, loads a model artifact, or carries an AI tag cannot deploy to production unless it resolves to a registered inventory entry with a current tier, a named owner, and evaluation results dated after the last material change. That is a few hundred lines of code plus the API in front of the inventory. It is the difference between an inventory that decays and one that stays true, because from that day forward it is maintained by the people shipping code rather than by an annual survey.

Two design details decide whether engineers route around it. The check must give a specific, fixable message: name the missing field, link to the form that fills it. A gate that says "AI governance check failed" produces a Slack thread and a workaround. And there has to be a documented exception path with a time limit and an owner, because the alternative to a sanctioned exception is an unsanctioned one. An exception that expires in thirty days and pings its owner is a control. One with no expiry is a permanent hole with paperwork.

Cost for this phase: four to eight engineering weeks for the inventory service, the registration API, and the pipeline check, driven by how many deployment paths exist. One path gets the low number. A monorepo plus a legacy path plus three acquired units on their own tooling gets the high one, and the legacy path will be the one that quietly bypasses everything for another year.

Days 60 to 75: evaluation that produces a record

Every tier-1 system needs an evaluation, and the useful definition is narrow: a repeatable procedure, run against a held-out set, producing a dated artifact with numbers someone signed off on. Not a demo. Not a confidence statement from the team that built it.

What goes in the procedure depends on the system. A classifier needs performance broken out by the subgroups that matter for the decision it informs, not an aggregate. SR 11-7, the Federal Reserve and OCC model risk guidance, has demanded this of banks since 2011 and remains the clearest short statement of what validation means: conceptual soundness, ongoing monitoring, and outcomes analysis, done by people independent of the developers. It transfers cleanly to any model whose output affects a customer.

For a language-model surface, evaluation means an adversarial fixture set run against the live endpoint. The OWASP Top 10 for LLM Applications gives the categories worth covering, with prompt injection, insecure output handling, and excessive agency producing the real incidents. MITRE ATLAS supplies a technique taxonomy specific enough to build fixtures from, and using its identifiers as your index means the evidence maps to something an external reviewer recognizes. Run the set on every model, prompt, and retrieval-index change. Guardrails are probabilistic, so score a rate across repeated runs rather than pass or fail, and alarm on a drop.

The part teams skip is retiring fixtures. An adversarial prompt the model provider has since trained against will pass forever and tell you nothing. A suite green for six months has usually stopped asking hard questions. Retire what has not failed in a year and add new cases from current research.

Days 75 to 90: write down what you already do

Now the policy. It is short, because it describes an existing practice rather than proposing one, and short policies get read. Four or five pages: scope, tier definitions, the obligation table, the exception process, the roles and who holds them, the review cadence. Anything longer is a policy nobody consults, so engineers follow the gate and ignore the document, which is fine right up until an assessor asks why the two disagree.

Map the policy to whichever framework your customers cite. NIST AI RMF is the common reference for federal and defense-adjacent buyers, and its Govern and Map functions align almost one to one with the inventory and tiering work. ISO/IEC 42001 is what enterprise procurement asks about because it is certifiable, and its clauses on monitoring, measurement, and internal audit presume the evidence trail the gate already produces. If a security program on NIST SP 800-53 or 800-171 exists, hang the AI controls on that skeleton rather than building a parallel one.

The one thing worth writing that is not a control is the intake path. New AI proposals need an obvious front door with a committed response time. Governance teams that cannot answer within a week get bypassed, and every bypass costs more to clean up than the review would have cost to run.

Phase	What you build	Rough effort	What it proves to a reviewer
Days 1–20 · Inventory	Queryable list of every AI system, six fields each, built from interviews plus egress logs, repo scans, cloud billing, and the vendor list	3–4 weeks, one person	You know what you run. Every later claim depends on this one.
Days 20–35 · Tiering	Three consequence-based tiers, with a distinct obligation set attached to each	2 weeks, plus owner reviews	Effort is aimed at consequence rather than spread evenly.
Days 35–60 · The gate	Registration API plus a deployment check that blocks unregistered AI systems, with a time-limited exception path	4–8 engineering weeks	The inventory stays true without an annual survey.
Days 60–75 · Evaluation	Held-out evaluation for tier 1, disaggregated performance, adversarial fixture suite for LLM surfaces	1–2 weeks per tier-1 system	Claims about behavior have dated numbers behind them.
Days 75–90 · Policy and intake	Four pages describing the practice, mapped to NIST AI RMF or ISO 42001, plus a front door with a response commitment	1–2 weeks	The document and the systems agree, which is rare enough to notice.

What ninety days does not buy

Being straight about the ceiling protects the program from the first hard question. Ninety days gets a true inventory, a tiering people apply, a gate that holds, evaluations on the systems that matter most, and a policy that matches reality. It does not get continuous monitoring on every model, an ISO 42001 certificate, a bias audit program, or vendor AI clauses renegotiated across an existing contract portfolio.

Those are quarters two and three, and each is far easier from here because each consumes the inventory. Monitoring needs to know which systems warrant it. Vendor clause work needs the list of which vendors ship models. A certification audit needs the evidence trail the gate has accumulated since day 60. Sequencing is most of the value.

The failure mode worth naming is the program that tries all of it at once and finishes none of it. Six months in it has a polished policy, a partial inventory, a monitoring pilot on two systems, and no gate, so the inventory is already drifting. Every piece is defensible alone and the combination proves nothing.

Staffing it, and what it costs

The working structure is one accountable owner at director level, one engineer building the inventory service and the gate, and a part-time claim on legal or privacy for tier definitions and vendor questions. The owner should not be a full-time governance hire in the first ninety days. A governance specialist hired before there is anything to govern produces documents. An engineer reporting to a director with authority produces controls.

Cash cost for a ninety-day build at mid-market engineering rates lands between $120,000 and $250,000 depending on how many deployment paths need the gate and how many tier-1 systems need evaluation from scratch. Companies with an existing model registry or a mature deployment platform land near the bottom. Companies with acquired business units on separate stacks land at the top and should scope the first ninety days to one unit rather than trying to cover everything thinly.

Set that against the alternative in the same currency. An enterprise deal delayed a quarter over an unanswerable questionnaire. A federal award where the governance factor scores low against a competitor who did this work. A model making decisions nobody reviewed, discovered by a customer rather than by you.

What a reviewer actually wants to see

Whether the reviewer is a federal assessor, an enterprise security team, or an auditor working an ISO 42001 clause, they are asking one question in different words: does the described practice match the operating reality. The artifacts that answer it are specific.

A query against the live inventory, run in front of them, showing counts by tier. A deployment log showing the gate blocking an unregistered service, with the exception record that resolved it. A dated evaluation report for a tier-1 system with disaggregated numbers and a named signer. A guardrail score history with the dips explained. Each is a record of the system behaving rather than a claim about it, and reviewers have a well-developed instinct for which artifacts are load-bearing.

The reverse is worth saying plainly. A program whose only evidence is documents invites the reviewer to spend their time testing whether the documents are true, and that conversation has no natural end.

Bottom line

Ninety days is enough to build AI governance that holds, provided the order is right. Count what you run before you write rules about it. Tier on consequence and make the tier change behavior. Put the gate in the pipeline where the work already passes. Evaluate the systems that can hurt someone, with a procedure you can rerun. Write the policy last, describing what is already happening. The programs that fail invert this and start with the document, which is the one artifact that can be produced without changing anything at all.

Frequently asked questions