Enterprise AI readiness is the ability to give an AI system the right business records, current context, bounded authority, and a way to prove what happened. A stronger model does not fix duplicate products, stale inventory, unclear ownership, excessive permissions, or missing recovery paths. Start with one operating decision and make its data, policy, action, and evidence reliable end to end.
For Commerce and Retail teams, that decision might be whether to enrich a product attribute, change a price, publish an offer, reserve inventory, or contact a customer. Each decision crosses systems and teams. That is why a model-first AI program often looks convincing in a demo but stalls before production.
This guide replaces the old year-led AI-readiness checklist with an evergreen operating model built around five readiness planes: data, context, control, evidence, and ownership.
The five-plane readiness test
A use case is ready to move beyond a prototype when all five planes have a clear answer.
- Data: Which business objects and fields does the decision require, and which system owns each value?
- Context: How will the workflow resolve identity, relationships, source, version, freshness, and conflicts at decision time?
- Control: What may the agent read, propose, approve, or change, under which limits?
- Evidence: How will the team verify the destination state, trace exceptions, and recover from a wrong or partial action?
- Ownership: Who owns the business outcome, policy, data contract, and production response?
This is a Boost.space editorial framework, not an industry standard. Its purpose is practical: expose the work that a model benchmark or prompt review cannot see.
AI readiness starts with a decision, not a model
"Use AI in ecommerce" is not an executable job. "Propose missing material attributes for products in this category using approved supplier sources" is much closer.
The second version has a target object, scope, source rule, and output. A team can inspect its exceptions and decide whether a person must approve every proposal. The broad version hides those choices inside a prompt.
Write the operating decision before choosing a model:
- business outcome and named owner;
- target records, fields, markets, and channels;
- sources the workflow may use;
- actions it may propose or perform;
- policy thresholds and approval rules;
- evidence required to call the case complete;
- prohibited actions and recovery owner.
NIST's AI Risk Management Framework is voluntary and addresses the design, development, use, and evaluation of AI systems. NIST says AI RMF 1.0 is being revised, so treat it as risk-management guidance rather than a fixed compliance certificate. Its lifecycle view supports the same operating point: readiness continues after deployment.
Plane 1: Make business data usable and accountable
Putting documents into a retrieval system is not the same as making operational data ready.
A commerce decision usually depends on structured objects and relationships: product, variant, SKU, offer, supplier, market, channel, inventory location, order, customer, currency, promotion, and policy. If those objects are duplicated or joined by unstable names, the model receives a plausible story rather than a dependable case.
For each required field, define a data contract:
- stable business identifier;
- authoritative source;
- expected type and allowed values;
- required relationships;
- acceptable age;
- conflict rule;
- missing-value behavior;
- owner and correction path.
GS1's Data Quality Framework describes an industry-developed cycle for data governance, management, assessment, and improvement of master data. It also provides a self-assessment scorecard and KPI checklist. The useful lesson for AI work is not that every company needs the same master-data design. It is that data quality needs an operating cycle, not a one-time cleanup before a pilot.
A governed operational data layer can centralize and synchronize records across systems. It does not remove the need to decide which source owns price, stock, description, consent, or customer status. Technology can carry the contract. The business still has to define it.
A quick data-readiness probe
Choose 20 real cases from the intended workflow, including awkward ones. For every field used in the decision, ask:
- Can the workflow resolve the correct record without guessing?
- Can it name the source and observation time?
- Can it detect a conflict between sources?
- Does it stop or route the case when a required value is missing?
- Can a person correct the source rather than patching the prompt?
If the answer is no, stay in analysis or proposal mode. Do not compensate by asking the model to sound more certain.
Plane 2: Build context at the moment of decision
Context is not a large prompt. It is the smallest current set of records, relationships, policy, and history needed for one decision.
Consider a price proposal. The model may need cost, currency, tax treatment, inventory, competitor availability, active promotions, channel fees, floor and ceiling rules, and the current published price. These values change at different speeds. A weekly export can be current enough for one field and dangerously stale for another.
A useful context packet includes:
- case and target identifiers;
- source and version for every material value;
- observation time and maximum permitted age;
- relationships used to assemble the case;
- unresolved conflicts and missing fields;
- applicable policy version;
- prior proposal, approval, and action history.
The packet should be assembled at runtime from approved sources. If the workflow uses MCP to reach live business data, the connection is only the transport. The workflow still needs the identity, source, freshness, and policy rules above.
Keep "unknown" as a valid state. A workflow that stops on missing context is more useful than one that quietly fills the gap with a likely answer.
Plane 3: Separate access from authority
A credential that can write to an ERP or PIM does not mean an agent should inherit every operation available to that credential.
NIST SP 800-207 describes zero trust around users, assets, and resources. It rejects implicit trust based only on network location or ownership. Applied to an AI workflow, authorization should follow the exact subject, resource, and operation.
Separate at least four capabilities:
- read approved context;
- create a structured proposal;
- approve a specific proposal;
- execute a bounded action.
Then limit them by record type, field, market, channel, value range, environment, time window, and case. A catalog agent that may update descriptions should not automatically change cost. A pricing workflow for one country should not receive global write access.
The June 18, 2025 MCP authorization specification defines optional transport-level authorization for HTTP-based MCP implementations and uses resource-specific OAuth flows when authorization is supported. That can protect access to an MCP server. It does not define the retailer's business rule for who may change a live price or publish a product claim. Keep transport authorization and business authority as separate controls.
Put policy outside the model response
Models can interpret evidence and prepare a proposal. Deterministic policy should decide whether that proposal may proceed.
Policy checks can validate schema, protected fields, source freshness, currency, market, value limits, approval requirements, and record version. Store the policy version and result with the case. If the underlying record changes after approval, require a new decision rather than applying an old proposal to new state.
Start with reversible authority:
- read-only analysis;
- structured proposals;
- human-approved writes;
- narrow automatic writes with verification;
- wider authority only after real exception evidence supports it.
Plane 4: Prove the result and plan recovery
An accepted API request is not proof that the intended business state exists.
A write can succeed in a source system but fail to reach a marketplace. A retry can duplicate an action. Another user can change the record between proposal and execution. A multi-system workflow can finish its first step and fail its second.
For every material action, keep these states separate:
- proposal created;
- policy passed;
- approval valid;
- request accepted;
- source record changed;
- downstream surface synchronized;
- intended value observed;
- case reconciled or recovered.
Read the authoritative destination after the write. For channel-facing changes, verify the intended channel when feasible. Use stable operation IDs and destination-supported idempotency for retries, but do not confuse duplicate protection with business correctness.
OpenTelemetry's observability primer explains that instrumented applications emit signals such as traces, metrics, and logs. Those signals help investigate a technical request. A production AI case also needs business evidence: target record, source versions, proposal, policy result, approval, before value, observed value, exception, and owner.
Define recovery before launch. The permitted next action may be refresh context, seek correction, request approval, retry safely, reconcile, compensate, roll back, or close without action. A queue of failed cases is not a recovery process unless somebody owns it.
Plane 5: Give the system a business owner
AI readiness is often distributed across Data, Architecture, Security, Operations, Ecommerce, and Legal. Distributed input is sensible. Distributed accountability is not.
Name one business owner for the workflow. That person does not have to build every control, but must be able to answer:
- What outcome is this workflow responsible for?
- Which errors are acceptable, and which require an immediate stop?
- Who owns each source and policy?
- How quickly must high-impact exceptions be handled?
- What evidence allows authority to expand?
- Who can pause or revoke access?
Review the workflow when its model, data source, destination, policy, action scope, or owner changes. Also review it on an operating cadence based on volume and consequence. There is no universal interval that fits every use case.
Apply the model to product enrichment
Product enrichment is a useful first enterprise Commerce case because the team can separate low-risk descriptive work from protected claims.
A bounded workflow might:
- resolve a product and variant through stable identifiers;
- find a missing material attribute;
- retrieve evidence from approved sources;
- standardize the value against the PIM contract;
- attach source, observation time, and confidence;
- route conflicting or protected attributes to a person;
- write only approved fields;
- read the PIM record back and record the result.
The current Product Enrichment Agent page describes finding missing attributes, standardizing values, and flagging products that cannot be verified with confidence. Before production use, the retailer still needs to set approved sources, protected fields, confidence behavior, and write authority for its own catalog.
This example is intentionally narrow. Pricing, inventory, order, return, and customer actions need different limits because their consequences differ.
An enterprise AI readiness review in one meeting
Bring one real workflow and one failed or ambiguous case. Do not start with a platform diagram.
For that case, map:
- the business decision and owner;
- every record and source used;
- identity and join rules;
- freshness and conflict rules;
- read, proposal, approval, and write permissions;
- deterministic policy checks;
- destination verification;
- exception and recovery ownership;
- the business measure that decides whether to continue.
The result should be a short readiness register, not a vague transformation roadmap. Mark every missing item as a blocker for automatic action, a limitation for proposal mode, or an accepted risk with a named owner.
Choose the next step based on evidence
If the data and ownership contract are unclear, map the workflow before adding another model. If the records are reliable but execution is risky, keep the agent in proposal mode while the team builds policy, approval, and verification. If the full case is observable and recoverable, test one reversible write under narrow limits.
For Commerce teams that need to connect readiness work to a measurable catalog or market problem, the Commerce Revenue Blueprint maps one product feed against observed market evidence before a larger implementation. Review the pricing and engagement path if you need the current scope before deciding.
Frequently asked questions
Does enterprise AI readiness mean choosing the right LLM?
No. Model choice matters for task quality, cost, latency, and operating constraints, but readiness also requires reliable data, runtime context, bounded authority, verification, recovery, and ownership. A better model cannot repair an unresolved product identity or an over-permissioned production credential.
Do we need to centralize every company record before using AI?
No. Start with the records required for one decision. They need stable identity, source ownership, acceptable freshness, and a defined conflict path. Expand the data surface only when the workflow requires it.
When can an AI agent write to a production system?
After one bounded operation has current authoritative context, narrow permissions, deterministic policy, appropriate approval, duplicate and concurrency protection, destination read-back, and an owned recovery path. Analysis and proposal mode are safer starting points while those controls are incomplete.
Last reviewed: August 10, 2026.
