SEI AI Adoption Framework

Status: Practitioner-reviewed framework reference; case application remains to be tested.

Framework promise

The SEI AI Adoption Framework helps an organization move from interest in artificial intelligence (AI) to sustained business value without treating technology acquisition as adoption.

An organization may arrive with a genuine desire to use AI and a candidate solution already in mind. The framework does not require it to prove that AI is worthwhile in the abstract or try to talk it out of AI. It makes the proposed use explicit, checks whether the AI workload and delivery mode fit the objective better than credible human or other non-AI responses, and establishes what must be true to operate it safely, detect failure, respond, recover, change, or exit. A non-AI or combined response remains a valid result when the evidence supports it.

It gives decision makers and practitioners a provider-neutral way to:

• choose valuable AI opportunities;
• match responsibility and control to the way AI is obtained and used;
• build only the organizational capability the situation requires;
• increase AI authority only when evidence supports it;
• operate, improve, replace, and retire AI deliberately; and
• create an actionable adoption roadmap rather than a maturity score alone.

The framework applies to organizations using commercial AI features, productivity tools, custom solutions, shared platforms, or autonomous and semi-autonomous agents. It is designed to remain useful across Microsoft, Amazon Web Services (AWS), Google Cloud Platform (GCP), and other providers.

Three terms to keep distinct

• Technology capability is what a tool or system can do, such as retrieve a policy page or produce an answer.
• Human competency is what a person can reliably do, such as judge whether that answer is appropriate and correct it.
• Organizational capability is what the organization can reliably deliver and sustain by combining technology, people, ownership, methods, and evidence.

The framework's 63 capabilities are organizational capabilities. A product feature or one skilled person may contribute to one, but neither alone demonstrates that the organization can sustain the outcome. Where a provider supplies important technology or competency, the organization still needs to know who owns the result, what evidence it accepts, and how it responds when the result fails or changes.

Central objective

Sustained business value is the objective. Trust is a required condition.

Value is not sustained when an AI capability produces a short-term benefit but cannot be governed, afforded, verified, operated, changed, or exited. Trust is not a separate workstream added after implementation. It is the evidence that permits people to rely on the capability for a defined purpose and consequence.

The framework therefore asks two questions together:

1. Is the AI capability producing an outcome worth its complete cost and effects?
2. Is there sufficient evidence to rely on it at its current scope and authority?

The framework at a glance

The unit that moves through the framework is an adoption case: a proposed or operating use of AI with a defined business objective, affected population, owner, and context. The case may begin as an opportunity, an existing capability that needs review, an unapproved use that needs disposition, or a capability facing material change or retirement.

Figure in words: A business objective anchors an adoption case. Workload and delivery mode are two separate classifications of that case.

The initiative remains; the AI solution may change

An initiative holds the continuing business and customer purpose: the problem to improve, the people affected, the accountable sponsor, and measures of customer and organizational value. An adoption case is a narrower, reviewable proposal or operating use of AI within that initiative. One initiative may contain several adoption cases over time, alongside non-AI changes. A particular feature, provider, model, or implementation is not the initiative itself.

This distinction lets an organization keep a meaningful longer-term direction without pretending it can specify one AI solution for a fixed three- or five-year period. Plan the outcome and constraints beyond the immediate release; make near-term investment and authority decisions against current evidence; keep later solution choices conditional. Do not treat a long-range technology forecast as an approved delivery plan.

At each decision and operating review, ask whether the current approach still creates customer value and whether that value justifies its complete cost, consequences, and dependencies. Revisit the workload, authority, delivery mode, applicable capabilities, evidence gates, and roadmap when customer needs, observed outcomes, provider behavior, technology, cost, obligations, or alternatives materially change. The resulting decision may be to continue, adjust, expand, replace, or stop the AI use while preserving the underlying customer objective. Record what changed and why so that a revised solution remains traceable to the initiative rather than becoming an unrelated AI project.

The framework tells one connected story:

An organization starts with a business objective, classifies the AI work and how it will be delivered, and moves the adoption case through its lifecycle. At each lifecycle decision, the organization draws on applicable capabilities. Target capability levels describe how reliably those capabilities must operate, while retained evidence determines whether the case can proceed. The gaps become a prioritized adoption roadmap. Measured outcomes and changed conditions then begin the next decision cycle.

The framework uses connected views rather than independent models. Each answers a different question about the same adoption case.

These views must be used together. A workload without a delivery mode hides responsibility. A target level without a business objective rewards maturity for its own sake. A lifecycle without evidence becomes a project checklist. A roadmap without exit conditions creates permanent dependency.

How the elements work together

Capability perspectives do not form another lifecycle, and capability levels do not represent project phases. The seven perspectives support decisions throughout the lifecycle. The four levels describe the required depth and reliability of an applicable capability at a particular scope.

Primary visual model

The AIAF architecture views show the framework's context, the sequence by which one case is assessed and moved, and the case information that persists. The context view depicts:

• the business objective as the anchor;
• workload and delivery mode as two independent classifications applied to the same case;
• the lifecycle as the decision path;
• the seven capability perspectives as support available across the entire path, not sequential steps;
• capability level as the required depth of each applicable capability;
• evidence as the basis for lifecycle decisions; and
• the roadmap as the response to gaps, with operating outcomes feeding back into the next cycle.

A companion workload-by-delivery-mode visual should demonstrate why the two classifications must remain separate. The three architecture views include linear text equivalents and do not rely on color alone. The phase-to-decision map is the working interpretation of decisions across the nine phases; the workbook must reflect it without turning every decision into a separate approval board.

For the instructional application, the current ten-course pathway map connects these framework views to one continuing Example Retailer case. The completed case-and-roadmap synthesis is a review companion, not a new evidence claim or an additional required framework output.

Four AI workload archetypes

Workloads describe the work AI performs, not the product category or provider.

W4 distinguishes three kinds of authority; these are not required steps in a sequence:

• Observe: retrieve public or authorized current information through a connected source or operational system without representing the organization or changing state.
• Communicate: send an independent message on a person's or the organization's behalf to another party within defined limits.
• Commit: create a transaction, obligation, permission, publication, or other consequential change in a connected system or with another party.

A customer assistant answering from approved reference content remains W3. If it retrieves a live order from a connected operational system, it remains W3 and adds W4 Observe even when that system is internal. A proposed communication or change requires its own authority and evidence; technical capability is not approval.

See the four workloads in one customer-service initiative

These examples classify the AI job, not the person's title, the application screen, or whether the organization built the tool. They are illustrative choices, not a requirement to use all four workloads.

The support-team macro example is a credible W1 / Mode C way to improve the shared knowledge work with no new development team dependency for the drafting itself. It does not remove the need for an authoritative source owner, verification, accessible customer routes, or a measured customer outcome. It may complement information repair and a guide without implying that a W3 assistant is needed.

Four delivery modes

Delivery modes describe how the organization receives, integrates, and controls AI.

Figure in words: Classify the AI job by workload and how AI is obtained by delivery mode. The two choices combine in one adoption case; neither determines the other.

The workload numbers W1-W4 identify kinds of AI work, not levels of maturity or organizational distance. The delivery letters A-D are also category identifiers, not an order from individual contributor to enterprise platform, and they do not line up with W1-W4. A staff member might use a separate productivity tool (Mode C) or an AI feature in an existing support product (Mode B) for the same W1 drafting job. A W3 customer assistant might be a distinct solution (Mode A) or a feature of the commerce platform (Mode B). A shared substrate (Mode D) can support several jobs. Pair a workload and mode for each proposed use; do not infer one from the other's number or letter.

Provider capability does not automatically become organizational capability. When a provider performs important work, the organization must still define the objective, judge the evidence, accept residual consequences, monitor continued fitness, and preserve continuity and exit options.

Complete adoption lifecycle

The lifecycle is iterative. Evidence can send work backward, constrain it, pause it, or stop it.

Replacement and retirement are designed from the beginning. AI providers, models, features, prices, obligations, and viable alternatives can change faster than traditional solution lifecycles.

Seven organizational capability perspectives

The capability catalog contains 63 capabilities grouped into seven perspectives:

Figure in words: Technology capability, human competency, and an owned practice with evidence contribute to an organizational outcome that can be sustained.

1. Strategy and value: direction, opportunity, investment, sourcing, value, boundaries, and horizon decisions.
2. People and operating model: literacy, roles, skills, work design, adoption, access, ownership, and organizational structure.
3. Governance, risk, and accountability: policy, inventory, consequence, approval, obligations, affected-party protections, oversight, and assurance.
4. Data, knowledge, and memory: fitness, rights, privacy, provenance, retrieval, retained context, quality, and lifecycle control.
5. Platform, engineering, and integration: runtime, engineering, integration, cost, portability, gateways, and observability.
6. Lifecycle, adoption, and operations: readiness, requirements, evaluation, deployment, monitoring, lineage, provider change, continuity, and exit.
7. Trust, security, and resilience: threats, identity, authority, records, supply chain, shared responsibility, incidents, adversarial resilience, vendors, and external commitments.

The perspectives are lenses, not departments. A useful adoption decision normally draws evidence from several perspectives.

Proportionate capability levels

The framework does not assume every organization or capability should reach the highest level.

Target levels depend on business importance, potential harm, reversibility, scale, affected population, AI authority, integration, dependency, change rate, lifespan, and external evidence needs.

Organizations may acquire experienced people, technology, consultants, or managed services to accelerate development. They may skip development history, but they cannot skip prerequisite outcomes and evidence. Competency can be bought or rented; accountability cannot.

Assessment and roadmap method

The framework produces decisions and action, not a single maturity number. These eight steps are applied proportionately and repeatedly as the adoption case moves through its lifecycle; they are not eight phases or a one-time checklist. The sequence view shows the feedback cycle.

Figure in words: At each relevant decision, apply the method to current evidence, take a bounded action, observe its effects, and revisit when results or conditions change. The full participant-and-decision sequence appears in the architecture views.

1. Define the objective. State the outcome, affected population, baseline, complete cost, material adverse effects, and stop conditions.
2. Classify the scenario. Identify workloads, W4 authority where relevant, delivery modes, lifecycle state, dependencies, and consequence tier.
3. Determine applicability. Mark each capability Required, Shared, Conditional, Lightweight, or Not applicable for the scenario, and record why when one is set aside.
4. Set target levels. Select only the level justified by the objective, consequence, dependency, and expected change.
5. Assess evidence. Record current evidence, provider evidence, organizational acceptance, uncertainty, and missing prerequisite outcomes.
6. Identify gaps and relationships. Distinguish capability gaps from integration, knowledge-transfer, continuity, and exit gaps.
7. Build the roadmap. Prioritize actions by decision dependency, consequence, value, effort, and urgency; assign owners, measures, and dates.
8. Review outcomes. Continue, change, expand, constrain, replace, or stop based on realized evidence.

The assessment should show capability profiles and scenario-specific gaps. Averaging them into one score can conceal a critical weakness and is not the primary result.

Required framework outputs

An application of the framework should leave behind the following evolving case record. These are ten output types, not ten sequential tasks or a requirement to create ten separate documents. The conceptual information model shows how evidence, decisions, capabilities, and roadmap actions relate:

Figure in words: Classification, a capability profile, and evidence support the decision and roadmap. Actions then produce new evidence for the same evolving case record.

• an objective and value record, including the comparison of AI and non-AI alternatives;
• workload, authority, and delivery-mode classification;
• consequence and applicability decisions;
• a current and target capability profile;
• an evidence and assumption register;
• shared-responsibility and dependency records;
• a prioritized adoption roadmap;
• measures, thresholds, and review triggers;
• continuity, replacement, and retirement conditions; and
• decisions to continue, change, expand, constrain, replace, or stop.

Reading the case record

The decision and roadmap workbook uses stable labels so a later choice can point to its objective, evidence, boundaries, gaps, and actions. These are references, not extra approvals or separate documents to complete.

Type each evidence entry plainly: an observation is something seen, an assumption is taken to be true but untested, a provider claim is asserted by a supplier, and a forecast is an expected result. Record uncertainty and what would change the decision. A label makes the basis traceable; it does not prove an outcome, establish cause, or grant authority.

Intended product and learning architecture

The durable framework should be expressed through five coordinated products:

1. Executive guide: the business case, framework map, critical decisions, and sponsorship responsibilities.
2. Practitioner reference: definitions for 63 capabilities, including 58 detailed records and five worked examples referenced by pointers; evidence, failure patterns, dependencies, and levels.
3. Decision and roadmap workbook: guided classification, applicability, target-setting, evidence assessment, prioritization, and action planning.
4. Role-based learning pathway: atomic courses that teach people to make and apply framework decisions, culminating in a usable roadmap.
5. Maintenance system: source register, change monitoring, review cadence, version history, and upgrade guidance.

The learning pathway should not require learners to memorize 63 capabilities. It should teach them to recognize their scenario, ask the right questions, obtain sufficient evidence, make proportionate decisions, and construct an adoption roadmap.

Distinctive position

The framework's working differentiation is the combination of:

• provider-neutral organizational capability;
• explicit separation of workloads from delivery modes;
• sustained business value as the objective and trust as a required condition;
• a complete lifecycle through replacement and retirement;
• proportionate evidence and capability targets rather than universal maturity;
• explicit treatment of provider responsibility and borrowed competency;
• authority-based treatment of agents and external action; and
• a learner-created roadmap as the principal outcome.

This position remains a hypothesis until external comparison and buyer validation show that intended audiences recognize and value it.

Boundaries and guardrails

• The framework does not replace legal, regulatory, security, privacy, accessibility, procurement, or professional advice.
• It does not certify that an AI system is safe, compliant, fair, or effective.
• It does not prescribe one provider, platform, operating model, or target level.
• External standards and provider frameworks are reference evidence, not reusable SEI content unless rights permit.
• Facts, SEI design decisions, inferences, and forecasts must remain distinguishable.
• Human and organizational accountability remains visible when AI or a provider performs the work.
• Important decisions must retain evidence, ownership, review triggers, and an exit path.

Ongoing validation questions

Before the capability records are treated as a baseline, confirm:

1. Does this overview explain the framework without relying on the research history?
2. Are workload, delivery mode, lifecycle, capability, and level clearly different concepts?
3. Is sustained business value visibly central without weakening trust, responsibility, or affected-party protections?
4. Can an executive understand what decisions the framework improves?
5. Can a practitioner see how assessment becomes a roadmap?
6. Is the framework provider-neutral but concrete enough to apply?
7. Does the scope feel complete without becoming a compliance checklist?
8. Is the product and learning architecture credible as a commercially valuable pathway?