Your first 90 days of utility AI

An AI program becomes useful when someone can point to a piece of work that now gets done better. Start there: a customer enquiry resolved with less searching, a regulatory response assembled with traceable evidence, or an inspection exception routed to the right engineer.

The following 90-day sequence is a planning template, not a promise about procurement or deployment time. Adjust it to the consequence of the work, your approvals, and the systems involved. A small utility can follow the same sequence with a small team.

Days 1–15: choose the work

Bring together the person accountable for the outcome, a practitioner who does the work, and colleagues responsible for data and technology. Watch several real tasks from beginning to end. Capture handoffs, searches, spreadsheets, waiting time, and corrections.

Write a one-sentence charter: “Help our regulatory analysts assemble evidence for information requests, with every material claim linked to an approved source and a named reviewer.” A charter should describe a deliverable someone can accept.

Shortlist three candidates from the use-case library. Customer representative assistance, filing consistency checks, and data exception triage are useful patterns to consider. Their suitability depends on your access, process, and review capacity. Use the selection guide to compare them.

Record the baseline before the team changes its habits: volume, elapsed time, active staff effort, rework, and quality. Name the failure that would make the pilot unacceptable.

Deliverable: one workflow, one owner, a baseline, and clear acceptance criteria.

Days 16–30: assemble the minimum foundation

Identify the records needed to complete that workflow. A document assistant might need approved procedures and a small filing collection. An asset workflow might need a bounded GIS export, inspection history, and a way to reconcile asset identifiers.

Check permissions, source ownership, update frequency, and missing information. Preserve original files and record where each imported field came from. Create an exception queue for unresolved conflicts. This is the point to start cleaning data with AI, alongside the workflow.

Agree on what the system may read, propose, and change. A prototype can start with read access and a reviewable output. Decide how people return to the existing process if the service fails.

Deliverable: a bounded dataset, access rules, a review process, and a working fallback.

Days 31–60: test on representative work

Use historical examples that reflect normal work and difficult cases. Include incomplete records, conflicting documents, stale information, and cases where the correct response is to ask a person for help.

Keep some examples out of development so they can provide an honest final check. Compare the new workflow with the existing process using the same inputs. Review the entire result, including source accuracy and the effort needed to correct it.

For an illustrative regulatory pilot, an attractive draft is insufficient. Reviewers should check whether citations support the claims, numbers reconcile, the correct filing version was used, and unsupported questions are identified. A fast draft that creates a longer review is not yet a useful improvement.

Run a small supervised trial with actual users. Make it easy to reject an output and record why. Fix repeated failure patterns before adding new features.

Deliverable: evaluation results, user feedback, and a revised workflow.

Days 61–90: prove the operating model

Expand to a controlled group if quality meets the agreed threshold. Track total effort, including review and exception handling. Record how often users finish the workflow, revert to the old process, or encounter missing data.

Assign responsibility for source refreshes, access changes, model updates, incidents, and the budget. A useful workflow needs someone who keeps it useful after the project team leaves.

At the decision meeting, choose to expand, revise, or stop. Expansion should have evidence behind it: acceptable quality, repeat use, manageable costs, and a real outcome. Stopping an unsuitable pilot is a valid result when the learning is documented.

Deliverable: a measured decision and an operating owner.

The first meeting checklist

• Which repeated task are we improving, and for whom?
• What does an accepted result look like?
• Which sources are essential, and who owns them?
• What must a person approve?
• How will we measure the complete workflow?
• Who can pause it, and how does work continue?

Build the reusable pieces as you go. Source access, identity matching, evaluation examples, and review screens can support the next workflow. That is how one practical project starts to become a foundation.