Sheet 11
What I’d need to learn
Everything else on this site is a proposal built from the outside, running on invented records. This page is the counterweight, and it is the one I would want read most carefully.
Said plainly
I do not know your environment. I have not seen your systems, your policies, your existing pilots, your governance structure, your client agreements, or the AI work already underway across your offices. Nothing on this site is a claim about any of them.
What the 12 sheets show is a structure: how a request enters, how review effort gets matched to risk, who decides what, how a pilot is measured, and what leadership sees. That structure is what I would bring on day one. Almost every specific inside it — the thresholds, the cadences, the pathway definitions, the artifact fields — is a starting proposal, and discovery should change a good number of them.
The 21 questions below are longer than the playbook they would reshape. That ratio is the honest one for someone proposing an operating model for an organization they have not worked in, and I would rather show it than round it off.
What I would need to learn
21 questions across 6 areas. This is not a list of things I would eventually get to — it is the work of the first thirty days, and most of it is conversations rather than documents. The answers would tell me which parts of this playbook survive contact and which were solving a problem you do not have.
- 01
What already exists
4 questions- What AI work is underway right now, formally and informally, and who is doing it?
- Which tools are in use, which are approved, and which arrived through an expense report?
- What has already been tried that did not work, and why do people believe it failed?
- What existing policy, guidance, and responsible-use expectations are already published, and who owns each?
- 02
How decisions actually get made
4 questions- Who genuinely decides on security exceptions, vendor contracts, client data handling, and changes to employment processes?
- What governance bodies already exist, what do they decide, and how full is their agenda?
- Where do decisions currently get stuck, and what unsticks them?
- What escalation paths do people already trust, and which ones do they route around?
- 03
Client and contractual obligations
3 questions- What do client agreements say about processing project material in third-party services, and how much do they vary?
- What professional liability and disclosure considerations apply to AI-assisted deliverables in this practice area?
- What retention obligations attach to AI-generated artifacts, prompts, and decisions?
- 04
Data and systems
3 questions- What data classification scheme is in place, and do people understand it well enough to apply it?
- Which document collections are well enough maintained to be worth making searchable, and which are not?
- What is the current tenant configuration, identity model, and licensing position?
- 05
People and culture
4 questions- Where is enthusiasm concentrated, where is resistance, and what is each one actually about?
- Who are the people others already ask, whether or not anyone appointed them?
- How do offices outside headquarters actually get information, and what do they feel is decided without them?
- What has leadership said publicly about AI and workforce impact, and what do employees believe was said?
- 06
Measurement and reporting
3 questions- What does leadership currently see, and which of it do they act on?
- What baselines exist today, and which would have to be built before anything can be claimed?
- What counts as value here — hours, quality, win rate, risk reduction — and who decides?
What this playbook assumes
Every model rests on assumptions, and most models do not say what theirs are. These are mine. Each is stated as something discovery should confirm or overturn — if one turns out to be wrong, the part of the playbook resting on it changes rather than being defended.
- 01
That an AI governance body exists or is intended, with a cadence and a chair. If not, the first task is proposing one at the smallest workable size rather than building the full structure shown here.
- 02
That policy and responsible-use guidance already exist and are owned by functional leaders. This playbook implements and communicates policy; it does not author it.
- 03
That the practical constraint is attention, not process design. Every artifact here is sized to be maintained by one person alongside the rest of the role.
- 04
That most requests are low risk. The pathway model only pays off if the short path is genuinely short — if the real distribution is different, the thresholds move.
- 05
That existing records live somewhere already. Registers would be built in the systems in use rather than as new tools, wherever that is possible.
- 06
That the first 90 days are for learning. Everything in this playbook is a starting proposal that discovery should change.
Why this page exists
A playbook presented without this page invites a reasonable objection: that it was written for an organization that does not exist and would be imposed on one that does. That is the most common way a program like this fails in its first year — a framework arrives fully formed, does not fit, and people build their own path around it.
The structure transfers. The content is illustrative. Knowing the difference between those two things is most of the job.
- Reading the role — what I understood the posting to be asking for.
- First 90 days — how these questions get answered, and in what order.