AI-native should describe a system design, not a product ambition.
The useful review is not how many models or agents the product contains. It is how model behavior changes customer value, system ownership, learning, economics, and recovery.
Five questions make that dependency visible.
1. What disappears when the model is switched off?
Name the customer outcome, not the technical feature.
If the model removes steps from an otherwise intact workflow, the system may be AI-enabled. If a major workflow degrades, AI may be central. If the product's differentiated outcome disappears, the system has accepted a deeper dependency.
The distinction matters because dependency determines how much of the product must be evaluated, operated, and recovered around model behavior.
Write the answer in one sentence:
Without the model, the customer can still ________, but can no longer ________.
If the team cannot complete that sentence, the design is using the label before it has defined the value dependency.
2. Which parts of the system were actually redesigned?
Adding generated output to an existing screen is an interface change. An AI-dependent system may require changes to workflow, data, evaluation, permissions, exception handling, pricing, support, and decision rights.
List the parts that changed because model behavior is uncertain and variable.
Then list the parts that still assume deterministic software.
The gap between the two lists is operating risk. A product can become dependent on the model before the organization redesigns how it will control that dependency.
3. How does use create reliable learning?
Logging prompts and outputs creates a record. It does not create a learning loop.
The loop needs five connected steps:
intent -> model action -> observed outcome -> evaluation -> change
For the workflow under review, identify the evidence used at each transition. Then name which product, context, model, policy, or operating decision can change because of that evidence.
If feedback accumulates without a decision it can influence, the system is collecting activity rather than learning.
This has a direct cost. Teams pay for telemetry, evaluation, and review while known problems remain unresolved or reappear in another part of the workflow.
4. Who owns the outcome when the model is wrong?
Component ownership does not automatically produce outcome ownership.
Engineering may own availability. Data may own context. A provider may own the model. Product may own the interface. Operations may own manual exceptions.
One accountable owner still needs authority to decide whether the organization should change the model, the context, the workflow, the policy, or the customer promise.
Test the ownership by describing one failure that crosses component boundaries. Who can make the final decision? Who can narrow or stop the automated path? Who owns the extra human work until the problem is resolved?
If the answer is only a committee or escalation meeting, the decision boundary remains unclear.
5. What is the credible fallback or exit path?
A fallback is more than an error message.
It defines what the customer can still do, how unfinished work is handled, when a person intervenes, which guarantees remain, and who decides to restore or replace the model path.
The exit question is broader. What would the organization need to change if model economics, provider terms, regulation, quality, or product strategy made the current dependency unacceptable?
Estimate the change surface:
- customer workflows;
- data and context pipelines;
- evaluation and monitoring;
- operating procedures;
- pricing or service promises; and
- downstream consumers that assume the current behavior.
The larger that surface becomes, the more evidence the original dependency should require.
Use the answers to choose the structure
The review can support several legitimate outcomes.
Keep AI bounded when it adds convenience or local value while the primary outcome remains strong without it.
Make AI central when a major workflow depends on the model and the organization has redesigned evaluation, ownership, and fallback around that fact.
Call the system AI-native only when differentiated value, learning, economics, workflow, and operating responsibility are designed around model behavior.
The label comes last.
First decide how much dependency the customer value justifies, which costs the organization is prepared to own, and how it will recover when the model is not enough.
This five-question review is a conceptual decision aid. It does not score maturity or describe a specific organization.