Adopting AI is not a one-time project. Tools change, policies drift, and the gap between what your written approach says and what teams actually do widens quietly unless someone closes it on a schedule. This play is that schedule: a quarterly review, owned by an accountable engineering leader, that runs just before your regular quarterly planning so its findings feed real decisions.

When to use this play#

Run this once you have an AI approach in place and tools in active use — typically after the three-phase rollout has reached its later stages. It pairs with the tool evaluation and data-privacy plays, which feed it raw material. Give it a single named owner; shared ownership means no ownership.

Before the review: collect the data#

The review only works if someone gathers evidence beforehand. Treat this as a checklist completed in the week leading up to the meeting.

Compliance check

• Client consent documentation exists for every active project.
• New proposals and contracts include a clear disclosure of AI usage.
• Every AI tool adopted this quarter actually went through the evaluation process.
• Gateway and integration configurations are current, not drifted.

Incident review

• Gather any data-privacy incidents — including near-misses, which are the cheapest lessons you will ever get.
• Collect client complaints or concerns related to AI usage.
• Note any quality issues traced back to AI-assisted work.
• Document any findings from security assessments.

Adoption and friction

• Which approved tools are teams actually using day to day?
• Are teams asking for tools that are not on the approved list? That demand is a signal, not a nuisance.
• What are team leads saying is working and not working?

The review agenda#

With the data in hand, the meeting itself is short and structured.

1. Metrics review. Walk the numbers that matter: client consent rate (target one hundred percent), data-privacy incidents (target zero), code-quality trend (held steady or improved), and security-audit status.
2. Incident debrief. Walk through each incident and near-miss, find the root cause, and decide whether policy needs to change. The goal is a systemic fix, not blame.
3. Tool landscape. Review tools evaluated this quarter, tools now due for security re-assessment, and emerging tools worth evaluating next quarter.
4. Policy updates. Decide which sections of your AI approach need revision, what new regulatory considerations apply, whether the training program needs an update, and whether you are keeping pace with how fast the field moves.

Common traps#

• Letting it slip a quarter. The drift you are trying to catch is exactly what accumulates when the review is skipped.
• Counting only incidents, not near-misses. Near-misses are where you learn before a real one costs you a client.
• Producing decisions with no owner or date. A policy change nobody owns is a wish, not a change.
• Ignoring shadow tool demand. When people reach for unapproved tools, your approved set is missing something they need.

Signals it's working#

Consent and incident metrics stay on target quarter after quarter, the approved-tool list reflects what teams genuinely use, policy changes trace back to real incidents, and the review feels like routine hygiene rather than a fire drill.