The Workplace
AI Enablement
Playbook

The RUDI Workplace AI Enablement Method

The method is one system with five layers. Each layer answers a different leadership question, and none of them works alone.

The operating methodology describes what the organization does. The maturity progression describes what changes as a result. RESPECT describes how every decision along the way is evaluated. Governance is who holds the pen.

How to use this playbook

This is a working document, not a reading assignment. Every numbered section ends with a Field Work block in a consistent format:

If you complete every Field Work block in order, you finish the playbook holding a complete, signed, evidence-backed AI enablement program: charter, baseline, opportunity maps, task disposition maps, RESPECT assessments, pilot charters, and a measurement dashboard.

Leadership conversations about AI stall when the same words mean different things to different people in the room. Establish these distinctions early and use them consistently:

AI literacy is understanding: what the technology does, where it fails, what responsible use requires. Literacy is measured by what people know and how they judge situations, not by whether they use tools.

AI enablement is equipping: approved tools, data access, role-relevant training, policies people can actually follow, and somewhere to go with questions. An organization can have high literacy and poor enablement — people who understand AI but have no sanctioned way to use it. That gap is where shadow AI grows.

AI adoption is behavior change: people using AI in real work, repeatedly, in ways that show up in how the work gets done. Adoption is measured in workflows, not license counts.

AI capacity is durability: the organization can identify opportunities, evaluate tools, redesign workflows, and support employees on its own, repeatedly, after the consultants leave.

AI transformation is organizational change: new services become possible, roles are redesigned around new task mixes, and strategy accounts for capabilities that did not exist before.

Skipping stages is the most common failure pattern. Training without enablement produces awareness with no outlet. Tool purchases without literacy produce shelfware. Pilots without governance produce risk.

Work is a collection of tasks. A job title bundles those tasks together with things a task list does not capture: accountability for outcomes, relationships with colleagues and clients, institutional knowledge, and judgment built over years. Both halves of that sentence matter.

The task view is what makes AI strategy tractable. "Can AI do a case manager's job" is unanswerable and threatening. "Which of the forty tasks in this case management workflow involve summarizing documents, and which involve earning a family's trust" is answerable and useful. When you decompose work into tasks, decisions, handoffs, and human interactions, most workflows turn out to contain some tasks where AI helps enormously, some where it helps a little, and some where it does not belong.

The human-elements view is what keeps the redesign honest. If task analysis strips out accountability and relationships, the redesigned workflow will look efficient on paper and fail in practice, because the parts that made it work were never on the task list.

Analyze at the task level. Redesign at the job level.

For an organization of roughly fifty people or more, AI enablement cannot be delegated entirely to IT or left to individual enthusiasts. IT can provision a tool but cannot decide which workflows matter. Enthusiasts can demonstrate what is possible but cannot commit budget or accept risk on the organization's behalf. The gap between those two groups is where a council belongs.

One refinement before forming the council: name the executive sponsor and one accountable enablement lead first. A committee can make decisions, but an individual must own execution. Without a named lead, every council member can support the work while nobody owns the outcome, and the initiative dies between meetings.

Minimum viable council

These are five functions, not necessarily five different people. In a smaller organization, one person may cover more than one function and legal or compliance expertise may be external or on call. The risk function may not attend every working session, but it must have a named owner and a defined review path before Gate 1. Do not let the absence of internal counsel become the absence of legal or compliance review.

Expanded council for larger or regulated organizations

When the organization is regulated or routinely handles sensitive data, make the risk, legal, compliance, or privacy function a standing council seat rather than an on-call reviewer. As the organization grows, also add: HR / learning and development (role changes, training, communication, adoption); finance or procurement (business cases, vendor contracts, budget discipline, benefits validation); data or analytics (data availability, quality, permissions, measurement); and operational leaders from the functions that own priority workflows.

The council charter

Form the council with a short written charter, one to two pages, that names: the executive sponsor; the accountable program lead; members and the functions they represent; scope and the business outcomes the work serves; decision rights — what the council decides, recommends, and delegates; budget authority; the use-case intake process; risk and approval pathways; meeting cadence; initial 90-day deliverables; and measures of success.

During the first 90 days, the core council meets every two weeks; pilot teams may meet weekly. Once the operating model stabilizes, the council can move to monthly.

The council's first assignments

The council should not begin by writing a comprehensive AI policy or buying licenses for everyone. Its first assignments are narrower and generate the information every later decision depends on:

1. Inventory current AI use, including unofficial or "shadow" use
2. Establish interim acceptable-use guidance — enough to make experimentation safe, not a final policy
3. Identify important workflows and organizational pain points
4. Define a simple risk-tiering process
5. Select two or three pilot workflows
6. Assign each pilot an owner, users, a baseline, and success measures
7. Determine what tools, data, training, and approvals each pilot requires
8. Establish a feedback and support mechanism
9. Review results and decide what should scale

One committee should not be asked to do everything. Separate the structure into distinct groups with distinct jobs:

The employee-facing group deserves care in naming. Call it an AI champions network or AI community of practice rather than an employee resource group — ERGs conventionally refer to employee-led affinity and identity groups, and borrowing the term creates confusion for HR.

The champions network should include people from different departments who test approved tools and workflows, surface useful applications, identify friction and risks, demonstrate practices to colleagues, hold office hours, provide feedback to the council, and help translate training into everyday work.

The boundary matters as much as the role: champions inform adoption. They do not approve tools, set policy, or accept organizational risk. Those remain council decisions.

The council owns the process, portfolio, standards, and decisions for AI vendors and internal tools. It should delegate detailed technical, security, legal, and workflow evaluations to the appropriate specialists rather than performing every review itself — the council decides; specialists assess.

Council responsibilities: evaluating external AI vendors and implementation partners; approving internal AI tools and use cases; maintaining an inventory of approved, experimental, and prohibited tools; establishing evaluation and risk criteria; selecting and funding pilots and assigning implementation owners; monitoring adoption, outcomes, and risks; deciding whether pilots scale, change, or stop; and coordinating literacy, training, and capacity-building investments.

Vendor and tool evaluation rubric

Every evaluation should consider, at minimum:

1. Business and workflow fit — does it address a workflow the organization has actually prioritized?
2. Security and privacy — architecture, certifications, breach history, data handling
3. Data retention and model-training terms — does the vendor retain inputs? Train on them? Can that be turned off contractually?
4. Identity, access, and administration — SSO, role-based access, admin visibility
5. Integration requirements — what it must connect to, and what that costs
6. Accuracy and human-review requirements — error rates for this task, and the review burden they create
7. Accessibility and employee usability — can people across roles and abilities actually use it?
8. Training and support — what the vendor provides versus what the organization must build
9. Total cost and expected value — licenses plus integration, training, oversight, and administration
10. Vendor stability and exit options — what happens to your data and workflows if the vendor folds or the contract ends

The council's operating artifacts

The council runs on documents, not meetings. Its core artifact set: the vendor evaluation rubric; a tool and use-case intake form; the approved-tool registry; a risk-tiering and review process; the pilot charter template; the organizational baseline; an adoption and outcome dashboard; and an AI risk and decision register.

Before prescribing training, buying more tools, or selecting pilots, establish where the organization actually is. Use a short organization-wide survey, supplemented by departmental interviews or focus groups.

Comfort and familiarity are useful signals, but they are self-reported and they conflate three different things. The assessment should distinguish:

• Literacy — what people understand about AI, its limitations, and responsible use
• Adoption — how people are currently using AI in real work
• Readiness — whether tools, policies, leadership, workflows, and support make productive use possible

An organization can score high on one and low on the others, and the intervention differs in each case. Low literacy calls for education. Low adoption despite high literacy usually signals an enablement gap — no approved tools, unclear permission, or managers who discourage experimentation. Low readiness is a leadership and infrastructure problem no amount of employee training will fix.

Dimensions to measure

1. Awareness — understanding of available AI capabilities and common limitations
2. Current use — tools being used, frequency, tasks, and whether usage is approved or informal
3. Practical capability — ability to apply AI to actual workflows, evaluate outputs, and maintain human oversight
4. Risk judgment — understanding of privacy, confidential data, intellectual property, bias, accuracy, and escalation
5. Confidence and willingness — comfort experimenting, perceived usefulness, concerns, fear of displacement or surveillance
6. Access and support — approved tools, data access, technical support, policies, examples, manager encouragement
7. Workflow opportunity — repetitive tasks, bottlenecks, knowledge gaps, administrative burdens, and quality problems employees believe AI might improve

Sample scaled items (five-point agreement scale)

• I understand what generative AI can and cannot do.
• I know which AI tools I am permitted to use at work.
• I know what organizational information I may enter into an AI system.
• I can identify tasks in my role where AI may be useful.
• I feel capable of reviewing AI output for errors or unsupported claims.
• I currently use AI for work at least once per week.
• My manager encourages responsible experimentation with AI.
• I know where to go when I have an AI-related question.
• I am concerned that using AI may negatively affect how my work is evaluated.
• I have repetitive or time-consuming tasks that may benefit from AI assistance.

Open-ended items

Which tasks consume disproportionate time? Where do handoffs or approvals create delays? What AI tools are you already using? What concerns prevent you from using AI? What would help you feel capable and confident? What is one workflow you would nominate for exploration?

Scenario items

Include a few scenario-based questions so the baseline measures judgment, not only confidence — self-assessed confidence and actual judgment routinely diverge. For example:

An employee wants to paste a confidential client document into a publicly available AI assistant to summarize it faster. What should they do?

Protect employee trust

The survey instrument should state explicitly: this is not a performance evaluation; individual responses will not be shared with managers; do not submit confidential prompts, data, or client information in your answers; the purpose is to design appropriate tools, training, policies, and support; findings will be reported in aggregate.

Without these protections the data is worthless: employees conceal unofficial AI use, and answers drift toward what people believe leadership wants to hear. The survey's honesty depends entirely on whether employees believe answering honestly is safe.

Do not reduce the results to one organization-wide score. A single number hides exactly the variation the council needs to act on. Produce instead:

• An organization-wide literacy baseline
• Department-level readiness profiles
• A current tool and usage inventory
• A shadow-AI risk map
• Role-based learning cohorts
• An employee concern and confidence profile
• An initial workflow opportunity inventory
• A list of functions requiring additional governance or support

This segmentation is what lets you avoid generic training. One group may need basic literacy; another may need workflow-design workshops; managers may need change-leadership preparation; technical teams may need evaluation and governance practices.

The survey informs strategy; it does not set it alone. The baseline gives the council its strategic hypotheses — which departments need foundational support, where unofficial adoption is already happening, where the greatest risks sit, which functions are ready for pilots, what concerns leadership must address, and where tools, policy, or access create barriers. The departmental interviews in Part V then test those hypotheses against how work actually happens.

The first training should not be a tool tutorial. Its purpose is to establish a common organizational vocabulary before departments are asked to evaluate their own work. Skip this step and the departmental interviews produce requests shaped by fear, hype, or a narrow view of what is possible — people cannot nominate good workflows for a technology they misunderstand.

The foundational training should cover:

1. What AI is and is not
2. What generative AI can and cannot reliably do
3. The distinction between automation, assistance, and decision-making
4. Approved tools and data boundaries — what may go into which systems
5. Human responsibility and oversight — the person remains accountable for the output
6. The RESPECT principles (Part VII)
7. Concrete examples of low-, medium-, and high-risk uses drawn from this organization's work
8. How employees can nominate a workflow for exploration
9. Where to go for support or escalation

The measure of success for this training is not completion rates. It is whether the departmental interviews that follow are productive — whether employees arrive able to talk about their tasks, their friction, and realistic possibilities in a shared language.

With shared language established, move from organization-wide data to departmental depth. The interviews should examine work — not simply ask "where would you like to use AI?" That question invites wish lists. Examining work surfaces the real material:

• Repetitive tasks and high-volume information processing
• Delayed decisions and manual handoffs
• Difficult knowledge retrieval and documentation burdens
• Quality inconsistencies
• Work dependent on a few experienced employees
• Customer or employee pain points
• High-stakes activities where AI may be inappropriate
• The outcomes the department is accountable for

Structure the interviews with the 5D framework — the RUDI workflow method. Humans define and validate the work; AI helps structure, analyze, prototype, and test it:

Humans validate before the work advances. New evidence returns the team to Discuss.

The output of each interview is a structured departmental opportunity map, not an unfiltered wish list: candidate workflows, the friction inside them, the constraints around them, and the department's own judgment about where AI does not belong.

For each workflow surfaced in the interviews, document: purpose; owner; participants; inputs and outputs; systems and data involved; decisions made within it; exceptions and their frequency; handoffs; baseline performance (time, volume, quality, cost — whatever the department already tracks); and current problems.

The baseline row is the one leaders skip and later regret. Without a documented starting point, no pilot can demonstrate improvement, and the council ends up debating anecdotes.

Break each prioritized workflow into its components:

• Tasks — the units of activity
• Decisions — points where someone exercises judgment
• Handoffs — transfers between people, teams, or systems
• Human interactions — moments where relationship, empathy, or legitimacy is part of the work
• Oversight responsibilities — existing review, approval, and quality-control activity

For each task, document: purpose, owner, frequency, time required, inputs and outputs, systems and data involved, required judgment, variability and exceptions, consequences of error, human interaction requirements, current pain points, and baseline performance.

Classify every task into one of four dispositions. The verbs are deliberate: each names a decision the organization makes, not a property the task has.

Automate

AI or automation performs most or all of the task within established controls. The best candidates share a profile: repeated steps, clear inputs and outputs, stable decision rules, sufficient volume to justify the setup cost, detectable errors, manageable consequences, and limited need for empathy or contextual judgment. Automation may still require review, exception handling, and escalation.

Example: Extracting standard fields from invoices and routing exceptions to an employee.

Augment

AI assists a person; the person retains judgment, responsibility, and control. Strong candidates involve analysis, drafting, research, preparation, comparison, summarization, scenario development, and complex or contextual decisions. Most early organizational use cases will fall here, and that is appropriate — augmentation delivers value while the organization is still building the oversight muscle that automation requires.

Example: AI prepares a summary of employee survey responses; a leader interprets the findings and decides how to respond.

Avoid

The organization deliberately decides not to use AI for a task, or restricts it to tightly controlled supporting functions. Grounds for avoidance include: high consequences of error, unreliable or unverifiable outputs, sensitive personal or organizational data, legal or regulatory restriction, essential human relationships, decisions requiring empathy or moral accountability, absence of meaningful human review, or insufficient value relative to risk.

Avoid is a design decision, not resistance to innovation. An organization that cannot articulate what it will not use AI for has not finished thinking. Documented avoidance decisions also protect the organization later — they are the evidence that risk was considered, not overlooked.

Example: AI does not independently make a final hiring, termination, medical, disciplinary, or benefits-eligibility decision.

Add

AI makes a valuable new task, service, control, or capability possible — or creates new work required to use AI responsibly. This includes new personalized services, new forms of analysis, continuous quality evaluation, AI-output review, use-case inventory management, model and vendor monitoring, prompt and agent maintenance, incident escalation, AI coaching and office hours, and documentation and audit activity.

Add matters because it corrects the framing everyone brings into the room. AI transformation is not only subtraction. Some of the highest-value outcomes are analyses and services that were previously too expensive to produce at all, and some of the new work — review, monitoring, coaching — is the price of doing the rest responsibly.

Example: A department begins a monthly analysis of customer-support patterns that was previously too time-consuming to produce.

Worked example: a hiring workflow

For each classification, record the reasoning, supporting evidence, identified risks, and required human oversight. The classification is a claim; the documentation is what makes it reviewable when circumstances change.

RESPECT is the cross-cutting decision lens applied to vendors, internal tools, workflows, task dispositions, pilots, and scaled deployments. It answers a question the 4A analysis does not: a task may be technically automatable and still fail as a human-centered design.

RESPECT is a human-centered framework for determining whether an AI-enabled workflow is not merely possible, but reliable, accessible, safe, privacy-preserving, worthwhile, controllable, and transparent.

RESPECT should not collapse into one vague score. A single score lets a strong efficiency rating paper over a privacy failure. Each proposed use case should instead receive: supporting evidence for each principle; identified concerns; required controls; an accountable owner; and a decision — go, revise, pilot, or reject.

Note the efficiency principle's phrasing: after accounting for oversight. A workflow that saves an hour of drafting and adds ninety minutes of review has negative efficiency, and RESPECT is designed to catch exactly that arithmetic before the pilot does.

By this point the organization has an opportunity inventory with 4A dispositions and RESPECT evaluations. Prioritization turns that inventory into a portfolio. Score candidates against:

1. Organizational value — impact on outcomes the organization is accountable for
2. Employee value — does it remove friction employees actually feel?
3. Feasibility — can it be built or configured with available capability?
4. Data readiness — does the required data exist, in usable form, with permission to use it?
5. Integration requirements — what it must connect to, and the cost of connecting
6. Adoption readiness — is the affected team willing and prepared?
7. Risk — from the RESPECT evaluation and risk tiering
8. Cost — total, including oversight and support
9. Measurability — can improvement be demonstrated against a baseline?
10. Reusability — does solving this teach the organization something it can apply elsewhere?

The first pilots should score well on employee value, feasibility, and measurability even if they are not the highest-value opportunities on paper. Early wins that employees feel build the trust the harder projects will need.

Every pilot gets a one-page charter before any work begins. No charter, no pilot. Each charter names: executive sponsor; workflow owner; participating users; baseline (documented before the pilot starts); intended outcome; approved tool; RESPECT evaluation summary; human-review plan; success measures; stop conditions; and review date.

Stop conditions deserve emphasis. A pilot without stop conditions cannot fail, and a pilot that cannot fail cannot produce evidence. Deciding in advance what result would end the pilot is what separates experimentation from commitment-by-drift.

Tools do not adopt themselves, and training alone does not change behavior. Build the surrounding support system:

• Manager enablement — managers set the local norms; an employee whose manager is skeptical will not use the tool no matter what the policy says
• Role-based learning — matched to the cohorts identified in the baseline
• Office hours — a standing, low-stakes place to bring questions
• AI champions — peer demonstration travels farther than central communication
• Help and escalation paths — known, named, and responsive
• Reusable playbooks — each solved workflow documented so the next team starts from the last team's work
• Internal demonstrations — real colleagues showing real work, not vendor demos
• Feedback loops — a route from user friction back to the council

Training completion and license counts measure spending, not change. The measurement system should track the full chain from access to outcome:

Report against the baselines documented in Parts III and V. The measurement question is always the same: compared to what?

The organization has developed capacity — the fourth stage of the maturity progression — when it can repeatedly, without outside help: identify worthwhile opportunities; evaluate tools and partners; redesign workflows; manage risk; implement pilots; support employees; measure results; scale what works; and stop what does not.

That last item is the one most organizations cannot do. Sunsetting a tool or ending a pilot feels like admitting error, so failed experiments linger, consuming licenses and attention. A council that has stopped something and survived has demonstrated more institutional maturity than one that has only launched things.

Transformation — the fifth stage — is not a project with an end date. It is what becomes possible once capacity exists: services redesigned around new capabilities, roles rebuilt around new task mixes, strategy that assumes the organization can absorb the next wave of tools because it has a working system for absorbing this one.

Running beneath the sequence: the maturity progression (Literacy → Enablement → Adoption → Capacity → Transformation) describes what changes in the organization; the operating sequence describes what the organization does; RESPECT describes how decisions are evaluated at every step; governance holds the pen throughout.

The central proposition:

AI transformation does not begin with eliminating occupations. It begins by understanding the tasks that constitute work and deliberately deciding what should be automated, augmented, avoided, or added.