This page is about the artifact rather than the work. If you want the order the work happens in, that is how to create an AI governance program, and this page deliberately does not repeat it.
What follows is what changes hands at the end of a governance engagement: the documents you keep, who owns them, what has to be true before you accept them, and what happens to them when the person who commissioned the work leaves.
What changes hands at the end
A governance engagement is not a system and it is not a subscription. What you are buying is a set of documents and a set of decisions that have been made, recorded and agreed. If an engagement ends and you cannot point at both, something has gone wrong.
The deliverable set is small and each part answers a question somebody will eventually ask you.
- An inventory of the AI systems in use, with an owner against each.
- A risk classification applied to those systems, with the scheme written down.
- A governance structure: who decides, who may decline, and what escalates.
- A policy set, short enough that staff read it.
- An approved list and the route onto it.
- A gap list, ordered, with an owner and a date against each item.
- A decision record: what was approved, by whom, on what basis.
Notice what is not on that list. There is no platform, no licence and no score. Governance produces documents, and an organization that has these seven can answer a customer questionnaire in an afternoon rather than a fortnight.
Each artifact also has a shelf life, and the deliverable should say so on its face. The inventory goes stale fastest, because staff adopt tools between reviews. The governance structure is the most durable, and usually survives a reorganisation with a name change. The policy set sits in between: it survives until either the technology or the law underneath it moves, and in 2026 both are moving. An engagement that hands over seven documents with no stated review interval has handed over seven documents that will all be treated as permanent, which is the wrong assumption for six of them.
What the roadmap contains
The gap list is the part most often called a roadmap, and it is the part most often disappointing, because a list of everything wrong with an organization is not a plan.
A roadmap that is worth having states, for each gap: what is missing, what it exposes the organization to, who owns closing it, roughly what it costs in effort rather than money, and what has to happen first. That last column is the one that turns a list into a sequence. Several gaps cannot be closed until the inventory exists, and saying so is more useful than ranking them by severity.
It should also say what you are not going to do. An organization that decides against a formal committee, or against certification, or against covering a low-risk category this year, has made a governance decision, and recording it is what stops the same conversation happening every quarter.
The shape that works is a table rather than prose, one row per gap, because a paragraph invites hedging and a row does not. A row that reads no record of which systems process student data | exposure under state privacy law | owner: data protection lead | effort: two weeks | blocked by: inventory can be worked. A paragraph saying the organization should improve its understanding of data flows cannot.
Sizing matters more than completeness. A roadmap with forty items produces no action. One with three items for this quarter, a named owner against each, and the rest parked with a review date, produces three closed gaps.
Who owns it, and what you may do with it
Establish this in the scope of work rather than at the end. The documents describe your organization, your systems and your decisions, and you should own them outright, be able to change them without asking, and be able to show them to an auditor, an insurer or a customer without a permission conversation.
That is not automatic. Some engagements deliver a report that references a supplier's proprietary model or scoring scheme, which leaves you holding a document you cannot fully explain or reuse. Ask, before signing: do we own the output, may we modify it, may we show it to a third party, and does anything in it depend on a tool we will not have after you leave.
The same question applies to the format. A governance artifact you cannot edit is a governance artifact that will be out of date within a quarter and will stay that way. A slide deck is a presentation of findings, not a deliverable you can maintain; a document you can open, amend and re-issue is. If an engagement offers to keep the master copy and send you updates, you are buying a subscription rather than an artifact, and that is a different purchase with different consequences when it lapses.
Confidentiality runs the other way and is worth agreeing at the same moment. The inventory names systems and often names their weaknesses, which makes it a document you will want to share selectively. Deciding in advance which parts are safe to hand to a customer, and which are internal, saves an awkward redaction exercise the first time somebody asks.
What makes the deliverable acceptable
Four tests, and they are worth writing into the engagement rather than applying afterwards.
It is specific to you. A deliverable that would read identically for another organization in your sector has described a category rather than a client. The inventory, the owners and the gap list should be unrecognisable as anyone else's.
Someone who was not there can act on it. The test is whether a manager who joins next month can read the gap list and know what to do first, without the consultant in the room.
It says what was decided and why. Including the things decided against. A recommendation with no recorded rationale is a preference, and it will be reopened.
It distinguishes evidence from judgement. What the inventory found is a fact. What risk tier a system belongs in is a judgement, and the deliverable should not present the second in the voice of the first.
A fifth test is worth applying informally: could you hand the deliverable to the next supplier. Governance work changes hands more often than people plan for, and a document that only makes sense with the authoring consultant present has locked you in without anyone intending it.
The GAO AI Accountability Framework is a useful external reference here, not because it binds anyone outside federal agencies, but because it is written with auditors and third-party assessors in mind. If a deliverable would let someone outside your organization form a view on your governance, it is doing its job.
Using it after the engagement ends
The deliverable has three ongoing uses, and organizations reliably use only the first.
Closing the gaps. Obvious, and it happens.
Answering questions. Customer security questionnaires, insurer forms, procurement due diligence and board papers all draw on the same documents. Keep them where the person who has to answer can find them, which is usually not where the consultant left them.
Deciding the next thing. A new tool arrives, and the inventory, classification scheme and approval route already exist to handle it. This is the use that repays the engagement, and it only works if the documents are maintained rather than archived.
Set a review date on the deliverable itself, not only on the systems in it. A governance document with no stated review interval gets treated as permanent, and the inventory will be wrong within a quarter. Federal reviewing bodies have found repeatedly that organizations fail to capture what they learned in a form later work can use, most recently in GAO-26-107859, and a deliverable nobody revisits is the same failure one step earlier.
Surviving a staff change
The most common way governance work is wasted is not that it was wrong. It is that the person who commissioned it left, and nobody else knew the documents existed.
Three cheap protections. Name an owner for the deliverable set as distinct from the systems it covers, so somebody is responsible for the documents themselves. Store it where the organization stores things rather than in a personal drive or an email thread. And write a one-page summary at the front that a successor can read in five minutes, covering what exists, where it is, and what is outstanding.
An engagement that produces excellent work nobody can find has produced nothing. That is a low bar and it is missed often.
The same reasoning applies to the gap list rather than the documents. Gaps are assigned to people, and people move. Assign each one to a role as well as a name, so that when the network manager leaves, the item follows the post rather than the person. It is a one-column change and it is the difference between a roadmap that degrades gracefully and one that stops the day somebody resigns.
Where to go next
The domains a deliverable should cover are in the AI governance framework. To judge your current position before commissioning anything, the AI governance checklist is quicker than an assessment. Whether the engagement was worth it is a separate question, covered in measuring the value of AI governance.
LABUSA's AI governance engagements produce the deliverable set described here, owned by you, in formats you can edit. If you want to agree what changes hands before committing to anything, that is a reasonable first conversation and we are happy to have it.