Working definition

Change the service—not only the tool.

Public-sector AI change management is the discipline of turning a change in AI capability, policy, data access, vendor service, or workflow into an authorized and measurable public-service transition.

Public-service test

Can the agency connect the AI-assisted action to public purpose, lawful authority, a responsible person, an accessible workflow, review and recourse, operating evidence, and a final disposition?

Operating position

Begin with one bounded service and its real users. Innovation is not the absence of controls; it is the ability to learn quickly inside a visible boundary. A pilot is complete only when an owner issues a source-linked decision to scale, proceed narrowly, revise, pause, or retire it.

Practitioner basis + public record

The method is tied to work you can inspect.

This playbook is first-party practitioner guidance, grounded in public records and source-backed operating research. It does not speak for a government employer, replace agency counsel, or turn Michael's starting guardrails into statutory requirements.

What the record establishes

Approved Nevada ITAB records identify Michael as chair of the Emerging Technologies/AI Working Group and as the presenter of statewide AI policy and governance recommendations.
Oregon's appointment record identifies Michael's current responsibilities across enterprise privacy, strategic communications, AI use-case review, and public trust, and separately documents his prior organizational-change and technology leadership experience.
The practitioner record keeps official public records, independent coverage, interviews, and Michael's own podcast and research distinct, so readers can assess each kind of evidence on its own terms.

Inspect the public evidence

Whole-service review

Six lenses around one public outcome.

Run the lenses together. A technically accurate system can still fail when authority, accessibility, records, workforce conditions, procurement terms, or service continuity are treated as downstream details.

01

Mission and public value

Which public service, statutory duty, employee task, or constituent outcome should improve—and for whom?

Receipt: Named service owner, intended benefit, affected population, baseline, and a measurable decision date.

02

Authority and accountability

Who may decide, approve, operate, challenge, suspend, and finally dispose of the AI-assisted work?

Receipt: Decision-rights map with one accountable owner and explicit escalation and suspension authority.

03

Data, privacy, and records

What enters the system, what is inferred, where it moves, how long it remains, and what becomes a public record?

Receipt: Purpose, minimum-needed data, classification, retention, disclosure, correction, and deletion path.

04

Civil rights and accessibility

Who could be excluded, burdened, misclassified, or denied a meaningful way to use or contest the service?

Receipt: Accessibility acceptance criteria, impact review, accommodation path, and human appeal route tested with affected users.

05

Workforce and operating change

Which tasks, judgment points, workload, skills, support needs, and labor obligations change for each role?

Receipt: Role-level before-and-after workflow, readiness evidence, support owner, feedback route, and required consultation record.

06

Acquisition and continuity

Can the agency inspect performance, preserve records, control changes, move its data, and continue service if the vendor or model changes?

Receipt: Acceptance measures, audit rights, change notice, export format, transition assistance, and witnessed rollback or continuity test.

Six receipts before scale

Every gate ends in a decision.

The gates are not a generic compliance checklist. They are evidence points that keep mission, people, controls, and delivery connected as the system changes.

1 · Frame
Should this public problem use AI at all?
Service baseline; affected people; non-AI alternative; benefit hypothesis; legal, policy, records, privacy, accessibility, security, and labor intake owners.
Hold whenThe problem, authority, population, or accountable service owner is unnamed.
2 · Bound
What may the system and its operators do?
Allowed, denied, and approval-required actions; user and credential scope; data boundary; human decision points; retention; vendor and model-change conditions.
Hold whenEffective permissions or high-impact decision boundaries cannot be inspected.
3 · Test
Does the workflow work for the people and conditions it will meet?
Representative task set; baseline comparison; accessibility and exception testing; red-team or misuse cases; error taxonomy; correction and appeal rehearsal.
Hold whenCritical accessibility defects, unmitigated high-impact errors, or materially worse task outcomes remain.
4 · Prepare
Can every affected role operate and support the change?
Role guidance; supervised practice; staffing and support plan; communications; labor and stakeholder actions; incident, escalation, and public-contact routes.
Hold whenA role with material responsibility has no guidance, practice evidence, or reachable support path.
5 · Release
Is limited production use justified by evidence?
Named release owner; approved population and duration; live monitoring; complaint and appeal intake; source-linked decision record; tested stop and rollback path.
Hold whenAny critical gate is open, evidence completeness is below 95%, or rollback completion is below 100% for the approved boundary.
6 · Reconcile
Did the change improve public outcomes while staying inside its boundary?
Adoption, task outcome, error, rights-impact, support, incident, cost, drift, and rollback signals reviewed together with a dated disposition.
Hold whenThe evidence cannot connect a system action to a responsible owner, human review, correction, and final outcome.

Starting release rule

Proceed to limited production only when no critical gate is open, sampled evidence completeness is at least 95%, required rollback steps have passed at 100%, task outcome is at or above baseline, and one authorized owner accepts the residual risk for a named population, duration, and data boundary. These are Michael's starting guardrails—not statutory thresholds.

Decision rights

A committee can advise. An owner must decide.

Use the role map to prevent governance from becoming a meeting without a disposition. Titles will vary; the responsibilities still need a named home.

Role	Minimum operating responsibility
Executive sponsor	Authorizes mission priority, resources, and unresolved risk acceptance within their authority.
Service owner	Owns the public or employee outcome, workflow design, operating baseline, and final disposition.
Technology + data	Documents architecture, data movement, identity, model and vendor changes, telemetry, and continuity.
Privacy, civil rights + legal	Interprets applicable requirements and reviews purpose, impact, disclosure, contestability, and authority.
Security + continuity	Tests abuse cases, access, incident response, recovery, rollback, and service continuity.
Accessibility + user experience	Defines acceptance criteria and tests the service with disabled people and representative users.
Records + procurement	Attaches retention, disclosure, auditability, performance, change-control, portability, and exit requirements.
Workforce + communications	Maps role impacts, consultation duties, practice, support, feedback, and public-facing explanations.
Frontline + affected people	Validate the real task, exceptions, burden, comprehension, recourse, and service outcome.

Run it in one quarter

A bounded 30 / 60 / 90-day path.

The schedule assumes one inspectable workflow—not an enterprise-wide transformation. Extend it when legal, labor, acquisition, security, accessibility, or public-engagement obligations require more time.

Days 0–30
Name one service and make the boundary visible.
- Choose one bounded workflow and one accountable service owner.
- Record the current service baseline, affected population, and non-AI alternative.
- Complete authority, data, accessibility, security, records, acquisition, workforce, and public-impact intake.
- Publish the allowed, denied, and approval-required action boundary internally.
Exit: A signed frame-and-bound decision with unresolved questions assigned by name and date.
Days 31–60
Test the actual task and prepare the people around it.
- Compare representative AI-assisted tasks with the service baseline.
- Test exceptions, accessibility, human review, appeal, record capture, and adverse or low-confidence outcomes.
- Run role-based practice with frontline, support, and oversight staff.
- Witness credential revocation, correction, export, and rollback within the agreed target time.
Exit: A test record showing task outcomes, known limits, owner-approved mitigations, and a working stop path.
Days 61–90
Release narrowly, monitor openly, and decide again.
- Limit population, duration, data, and connected actions to the approved pilot boundary.
- Review adoption, outcome, error, rights-impact, incident, support, cost, and evidence-completeness signals weekly.
- Give employees and the public a plain-language contact, correction, and appeal route where applicable.
- Issue a dated scale, revise, pause, or retire disposition with the evidence attached.
Exit: A final pilot disposition; launch is not the disposition.

Reusable artifact

One-page public-service change brief.

Copy the plain-text version or print this page. Keep the brief concise, but link each line to the evidence, reviewer, decision, and date behind it.

AI PUBLIC-SERVICE CHANGE BRIEF

Service / workflow:
Accountable service owner:
Decision date:
Affected employees / public:
Problem and current baseline:
Why AI / viable non-AI alternative:

ALLOWED
- Users:
- Data:
- Actions:

DENIED
- Users:
- Data:
- Actions:

APPROVAL REQUIRED
- Decision / action:
- Approver:
- Evidence required:

PUBLIC-SERVICE CONTROLS
- Accessibility acceptance:
- Privacy / civil-rights review:
- Records / disclosure path:
- Security / incident path:
- Workforce / consultation action:
- Complaint / correction / appeal route:
- Continuity / rollback target:

MEASURES
- Service outcome and baseline:
- Error / exception signal:
- Adoption / support signal:
- Evidence completeness:

DISPOSITION
[ ] Proceed narrowly  [ ] Revise  [ ] Pause  [ ] Retire
Decision owner / date:
Evidence links:
Next review trigger:

Method, limits + sources

A working aid—not a substitute for accountable review.

Michael’s practitioner synthesis connects operating change, public-sector delivery, and the six receipts before scale. Every organization remains responsible for applying its own authority, expertise, evidence, and risk tolerance.

Limitations

This is practitioner guidance, not legal, audit, labor-relations, procurement, records, privacy, security, civil-rights, or accessibility advice.
The starting thresholds are operating guardrails, not universal benchmarks. Replace them with the applicable law, policy, risk classification, service baseline, collective-bargaining obligation, and tolerance approved by your organization.
A completed template is not evidence by itself. Attach source records, test results, approvals, observed outcomes, and a final disposition.
Do not average away a critical failure. A material safety, rights, privacy, security, accessibility, or mission-continuity gap remains a stop condition even when the overall score looks strong.

Primary and public sources

Update history

Versioned in public.

August 5, 2026Added a practitioner-basis section connecting the playbook to official public records and canonical evidence.

What the record establishes

Inspect the public evidence

Mission and public value

Authority and accountability

Data, privacy, and records

Civil rights and accessibility

Workforce and operating change

Acquisition and continuity

Should this public problem use AI at all?

What may the system and its operators do?

Does the workflow work for the people and conditions it will meet?

Can every affected role operate and support the change?

Is limited production use justified by evidence?

Did the change improve public outcomes while staying inside its boundary?

Name one service and make the boundary visible.

Test the actual task and prepare the people around it.

Release narrowly, monitor openly, and decide again.

Limitations

Primary and public sources

Versioned in public.