Internal AI Adoption Strategy: An Operating Model

An effective internal AI adoption strategy changes more than tool access. It gives leaders responsibility for sponsorship and barriers, managers responsibility for capacity and scale decisions, and practitioners responsibility for identifying useful process problems. It also sets a bounded method for selecting and testing use cases, with milestones that fit different roles.

The practical answer is to connect visible leadership sponsorship with department-level ownership, a controlled path from problem discovery to pilot, and role-relevant expectations. Measure employee adoption separately from workflow reliability and project impact. A completed training task is not proof that a workflow works, and a successful workflow is not automatically proof of business value.

This guide adapts organizational ideas reported by Make into proposed operating patterns. Make’s figures describe its own internal program and are not universal targets. The technical workflows below are illustrative designs using documented Make building blocks, not official Make templates.

What should an internal AI adoption strategy change?

It should change who discovers and owns use cases, who can provide time and approval, and what employees are expected to learn or deliver. Without those decisions, enthusiasm tends to create scattered experiments rather than repeatable workflows with owners, controls, and review dates.

Treat each proposed use case as an operational change. The intake should identify a process owner, current input, intended outcome, data classification, narrow AI task if AI is warranted, validation step, destination, exception path, and review date.

What Make’s reported results do and do not show

In its first-party account of its internal adoption program, Make reports that its measure of employees using and building AI agents increased from 8% to 96% among more than 350 people automating. The article describes leadership sponsorship, managers controlling capacity and scale decisions, and individual contributors identifying relevant work.

Make also reports embedding departmental AI automation champions called Samurai, with a 70-20-10 allocation across project work, teaching, and maintenance. It says 23 of 32 projects achieved business impact on core KPIs and that it introduced a role-specific AI bar in September 2025. These are Make’s reported results, not independently audited benchmarks. The article does not publish the adoption instrument, denominator definition, observation period, project KPI definitions, selection criteria, or AI-bar rubric. It also does not establish that the AI bar alone caused the reported increase.

The article applies Everett Rogers’s conventional adopter categories, in which innovators represent 2.5% and early adopters 13.5%, totaling 16%. A University of Oklahoma summary of Diffusion of Innovations explains the categories. Their arithmetic does not establish that most companies plateau at 16% AI adoption.

The useful lesson is not to copy a percentage. It is to ask who sponsors the work, who can allocate departmental time, who understands frontline friction, and what observable milestone counts as appropriate for each role.

Build the ownership model before choosing projects

Assign decision rights rather than creating a champion group with unclear authority:

• Executives sponsor and unblock: set priorities, provide access to decision-makers, and resolve resource or policy barriers.
• Department managers allocate capacity: decide which proposals receive discovery time, who can test them, and whether results justify scaling.
• Practitioners identify friction: describe where work slows down, what exceptions occur, and whether a proposed workflow fits actual work.
• A transformation lead connects the work: translate business needs into bounded tests, coordinate implementation and change management, and remain accessible to frontline teams.

Department champions can be a named responsibility or a dedicated role sized to demand. Make’s reported full-time Samurai roles and 70-20-10 allocation are one company’s example, not a staffing benchmark. Begin with an intake record containing department, process owner, problem statement, source system, expected outcome, data classification, proposed metric, reviewer, and stable source-event identifier where applicable.

Choose processes where AI has a defined job

Map the process before choosing a model or agent. If a deterministic rule can make the decision reliably, use the rule. Exact matches, required fields, allowlists, thresholds, date windows, and duplicate checks belong in ordinary logic. AI is more useful for interpreting ambiguous language, extracting information from unstructured text, summarizing, or ranking candidates.

Do not advance a proposal if it lacks a stable input, an accountable owner, permission to use its data, or a way to assess whether the result helped. Define the baseline and intended measure before building. For a support process, that might mean median routing time and the percentage sent to manual review, rather than the number of agent executions.

Pattern	Trigger and AI job	Validation and fallback	Destination and owner
Use-case intake	Form, supported app trigger, webhook, or on-demand scenario receives a structured proposal. AI classifies or summarizes only complete, permitted submissions.	Require owner, process, source, outcome, classification, and reviewer. Route missing or sensitive fields to a person.	Proposed-use-case register or review queue. The department manager decides.
CRM classification	CRM event or webhook supplies a stable event and record ID. Deterministic checks run first; AI classifies ambiguous text into an allowed label.	Reject unknown labels, malformed fields, missing evidence, mismatched IDs, and low-confidence results. Require approval for consequential changes.	Proposal queue first, then an authorized CRM update. The CRM process owner handles exceptions.
Milestone tracking	Employee or manager submits evidence for an agreed role milestone. AI is optional and limited to summarizing evidence.	Validate employee, milestone, period, reviewer, and approved exception code using deterministic rules.	Restricted tracking register and aggregate report. The line manager reviews evidence.

These patterns share a design principle: AI proposes or interprets within a defined boundary, while a named human or deterministic control decides whether the result can move forward.

Turn role-level expectations into observable milestones

Make says its AI bar, introduced in September 2025, defined AI use for different roles. The actual rubric is not public. A practical local rubric can vary by job while asking employees to identify an eligible use case, test it with approved sample data, document an exception path, assign an owner, and review evidence with the process owner.

A role with strict data restrictions may have a different approved path or an explicit exception. The point is to make the expectation observable without encouraging irrelevant or unsafe automation. Record each milestone as an employee, milestone, and measurement period, with evidence and any approved exception. Avoid treating logins, scenario creation, or a vague count of uses as proof of useful adoption.

Put a departmental pilot through a controlled path

Consider a proposed intake workflow for a Customer Operations team. A supported Make app trigger, instant webhook, scheduled trigger, or on-demand scenario receives the submission. Structured scenario inputs check required fields and data classification before any AI step. If the submission is eligible, an AI agent may classify the proposed process or summarize its description. It must not approve the project or invent missing requirements.

Make documents agent instructions, tools, testing, and structured scenario inputs and outputs. It also documents validation against a defined structure. Those are building blocks, not a complete governance design. See Make’s first-agent guide and scenario input and output documentation.

An illustrative submission could contain:

{
  "department": "Customer Operations",
  "process_owner": "[email protected]",
  "problem_statement": "Categorize requests that miss existing rules",
  "source_system": "Support platform",
  "expected_outcome": "Reduce manual routing time",
  "data_classification": "Internal",
  "proposed_metric": "Median routing time",
  "reviewer": "[email protected]",
  "source_event_id": "submission_illustrative_1042"
}

Require the department, owner, process description, source system, expected outcome, sensitivity classification, reviewer, and stable submission identifier. Send incomplete submissions to a named person rather than asking the agent to fill gaps. Save the eligible proposal and AI summary separately from the manager’s decision. Measure the test against its baseline, including time spent on exceptions and review.

For organizations implementing a bounded agent workflow, AI agent implementation is relevant when translating the task, output contract, and review path into a governed build.

Add controls before an AI-assisted workflow writes to a CRM

A second proposed pattern classifies ambiguous customer text before a CRM update. Receive an event from a supported CRM trigger or webhook, normalize the fields, and check eligibility with deterministic rules. Send only eligible content to classification. Require an allowed label, valid structured output, matching record identity, evidence spans, and a review flag. Save the proposal to a review queue. After approval, use the authorized workflow to update the CRM. Keep the original source record and approval record separate from the proposed change.

An illustrative output contract might include a category, confidence, evidence spans, source record ID, agent version, prompt version, and review status. The category must come from an explicit enum. Reject an unknown label, missing evidence, malformed fields, a confidence value outside the permitted range, or a record ID that differs from the triggering record. Use human approval for consequential customer, financial, legal, permission, or regulated-data changes. Lower-risk internal routing or draft creation may be automated when the existing review process remains in place.

Duplicate handling must match the event grain. For one source event, a proposed processing key is source_system + event_type + source_event_id. Store processing status, approval state, execution reference, and destination-write status against that event. If several proposals can be made for the same CRM field, include the field name and source event ID in the proposal key. If several model runs are retained, include the run ID, model version, or prompt version as appropriate. Do not use only an entity and date when multiple runs can occur on the same day.

Make documents that instant webhooks process in parallel by default. Sequential processing can control order, but it does not deduplicate events. A separate lookup followed by a create can race when concurrent executions arrive. Where concurrency matters, use a database-enforced unique key or a supported atomic upsert. Make’s webhook and data-store documentation describe relevant primitives, while its error-handling guidance covers execution failures. Safe retries still depend on the destination write design.

Measure adoption, reliability, and impact separately

Choose the reporting unit before collecting numbers:

• Adoption: one employee, one defined milestone, and one measurement period. Evidence might be a reviewed test or approved exception.
• Workflow reliability: one source event processed by one scenario execution. Record success, review, failure, retry, and downstream-write status.
• Project impact: one project evaluated against a named KPI baseline, with inclusion rules, owner, source, and observation window.
• Run provenance: one model or agent execution for one input and prompt or instruction version when reproducibility matters.

Choose a small number of operational measures that fit the process, such as eligible cases handled, exception rate, processing time, rework, or a defined service KPI. Record the metric owner, baseline, measurement period, inclusion criteria, and source. Review exceptions and human workload alongside headline results. Activity counts or a before-and-after percentage alone do not establish causation.

Scale only when the process owner can show that agreed quality and operational thresholds held over the review period. Otherwise, revise the workflow or stop it.

A practical 30-day starting sequence

1. Week 1: appoint an executive sponsor and operating lead. Select one department and one process with a named owner, reviewer, and baseline.
2. Week 2: map the current trigger, inputs, decision, action, and exceptions. Classify data and decide whether deterministic rules are sufficient or AI has a specific interpretation task.
3. Week 3: test representative and adversarial cases. Define allowed outputs, validate fields, preserve provenance, and keep consequential writes behind human approval.
4. Week 4: review quality, operational measures, exceptions, and reviewer workload. Make one decision: stop, revise, continue under supervision, or scale with an owner and monitoring plan.

Make’s AI Agent documentation describes agent concepts and tools, while its first-agent guide covers a basic build path. The reviewed documentation described the new AI Agent app as being in open beta on October 16, 2026, so current product and account requirements should be checked before implementation. The documentation provides workflow building blocks, not automatic approvals, output correctness, auditability, idempotency, or safe retries.

For teams building the scenario and its operational handoffs, Make automation services may be useful. The practical test is not whether a team can demonstrate an AI tool. It is whether a named owner can show a repeatable workflow, handle its exceptions, and make a defensible decision to stop, revise, or scale it.