Skip to content
Practical AI Program PlaybookNicholas Vidal

Sheet 00 · Executive view

Practical AI Program Playbook

A working demonstration of how I approach responsible AI adoption—from intake and risk review through pilots, enablement, and leadership reporting.

Scattered AI experimentation becomes a program when someone makes the path visible: one front door, review effort matched to risk, named owners for every decision, and honest measurement of what it produced.

This is how I read the role, how I would approach it, and the playbook I would use to build and mature the program.

I built this from the public job description. It is a proposed operating model, not a description of your environment — I have no visibility into your systems, policies, existing pilots, governance structure, or the work already underway, and this playbook assumes none.

Everything shown runs on a fictional organization with fictional records. The value is in the structure: how a request enters, how review effort is matched to risk, who decides what, how pilots are measured, and what leadership sees. The specifics would change after discovery. The structure is what I would bring on day one.

The last section lists what I would need to learn before adapting any of this. That list is longer than the playbook, which is the honest ratio.

Registered use cases
10
Pilots underway
4
Recorded decisions
6
Tools inventoried
5

Sample data for Northshore Design Group, a fictional organization. Sample data covers January–August 2026.

How a request moves

Seven stages, one route. Counts show where the ten sample use cases sit right now. Select a stage for its purpose, owner, and the decision made there.

Discover

Find the work already happening. In a decentralized firm, AI use starts before any program exists — the first job is seeing it rather than pretending it began the day the program did.

Primary owner
AI Program Manager, with practice group and shared services leaders
What the program does here
Runs discovery conversations, maintains the inventory, and surfaces duplicate efforts across offices.
Required information
  • What people are already using and why they chose it
  • Where a manual process is causing real pain
  • Which teams have quietly solved something worth reusing
  • Existing tools, contracts, and shadow subscriptions
Expected output
An entry in the use-case register or the tool inventory, whichever fits.
Typical decision
Is there a problem here worth someone's time?
Typical duration
Continuous

Review effort matched to risk

Three pathways rather than one queue. A meeting summary should never wait behind a recruiting workflow, and a recruiting workflow should never move at the speed of a meeting summary.

Standard enablement

Get out of the way. These requests are answered with guidance, not review — the goal is same-week resolution.

Sample use cases
2
Target timeline
Answered in the weekly triage, typically within five business days
Structured review

One coordinated review with the two or three functions that actually have a stake, held on a scheduled date rather than routed through separate queues.

Sample use cases
5
Target timeline
Two to three weeks from complete submission to decision
Elevated review

Slow down on purpose. These use cases can affect people's livelihoods, rights, safety, money, or the firm's professional standing, and the review has to be able to withstand scrutiny later.

Sample use cases
3
Target timeline
Four to six weeks, longer if the evidence a reviewer needs does not exist yet

See how a request is classified, and which answers put it there

What the program commits to

  • Enable useful adoption

    The program's job is to help good ideas reach production safely, not to reduce the number of ideas.

  • Govern in proportion to risk

    Three pathways with published expectations. Most requests take the shortest one.

  • Keep accountability with people

    A person signs off on consequential output. Tools assist; they do not decide.

  • Make decisions and ownership visible

    Registers and logs anyone can read, with a named owner on every line.

  • Start with the business problem

    Tool-first requests get sent back with one question: what is the problem worth solving?

  • Measure outcomes, not activity

    Licenses issued is not adoption. Hours saved that nobody can reproduce is not value.

  • Treat governance as enablement

    If people route around the process, the process is the defect.

Nicholas Vidal

Nicholas Vidal is a technology and governance program leader who helps organizations turn complex security, risk, and AI requirements into practical programs people can understand and use. His background spans enterprise technology operations, cross-functional leadership, responsible AI adoption, governance, training, and audit readiness.

He is not an AI developer or data scientist. His work is connecting strategy, governance, technology, risk, and the people who have to live with the result.

Contents