A pre-production review that consists of "does this look reasonable" tends to produce exactly that: a reasonable-looking sign-off that catches obvious problems and misses the specific gaps that actually cause incidents. A more useful review works through a short list of concrete questions, each tied to a category of AI-specific risk, rather than relying on a reviewer's general impression of whether the feature seems fine.
Start with what the feature can see
The first question is not about the model. It is about data: what can this feature retrieve or receive, and is that scoped to what the requesting user is actually authorized to see. If the answer involves retrieval, confirm specifically that authorization is applied before ranking, not assumed to be handled by asking the model to disregard unauthorized content. If the answer involves sensitive fields entering a prompt, confirm there is a reason those specific fields are needed for the task, rather than being included because they happened to be available in the same record.
Then ask what the feature can do
The second question covers action: can this feature call any tool that performs a real-world effect, and if so, what authorization and limits exist independent of the model's own judgment. For any tool that can act, confirm there is a hard limit on scale or rate that does not depend on the model behaving correctly, and confirm that genuinely high-impact or irreversible actions require an approval step with enough context for that approval to be meaningful, not a rubber-stamp click.
If the feature cannot call any tool and only produces text a human reads, this section of the review can move quickly, because the worst-case impact is bounded in a way it is not for an acting system. Matching review depth to actual risk keeps the process fast for low-risk features and focused where it matters for higher-risk ones.
Check what happens when something goes wrong
The third question covers failure behavior, which is often the least tested part of an AI feature before launch. What happens if the model provider is unavailable. What happens if a policy or approval service cannot be reached. What happens if the model returns something malformed or a tool call times out partway through. For every one of these, confirm the system fails toward denying or pausing the action rather than proceeding as if everything were normal, especially for anything with real-world effect.
Teams often test the happy path thoroughly and the failure path barely at all, because failure paths are less satisfying to demo. This is exactly why a review needs to ask about them explicitly rather than assuming they were covered.
Confirm there is something watching after launch
The fourth question covers monitoring: if this feature misbehaves in production, will anyone notice, and how quickly. Confirm there is logging sufficient to reconstruct what happened, that someone is actually watching relevant signals rather than logging into a system nobody checks, and that there is a clear, fast way to disable the feature if something looks wrong. A feature that passes every other part of the review but has no monitoring plan is still exposed to the failure mode where a problem runs undetected for far longer than it should.
Ask who owns this feature, specifically
The fifth question is about ownership, and it is worth asking explicitly rather than assuming an answer. Who is the specific person who can answer detailed questions about this feature's data, tools, and behavior. Who is authorized to make the call to pause it. If the honest answer is "the whole team" or "whoever is on call that week," that ambiguity itself is a finding, because it usually means nobody will feel individually responsible for noticing a slow-developing problem.
Prioritize the review by impact, not by feature novelty
Not every AI feature needs the same depth of review. A read-only, low-reach internal tool can move through this process quickly. A customer-facing agent with the ability to act deserves a more thorough pass through every section, because the cost of missing something is proportionally higher. Calibrating review depth to actual impact keeps the process from becoming either a rubber stamp for everything or an unsustainable bottleneck for low-risk features.
Where TELEON fits
Where a review identifies a specific tool that needs authorization limits or approval requirements, TELEON's policy enforcement, applied through the gateway or supported middleware, gives teams a place to implement that finding consistently, and its audit trail supports the monitoring requirement identified in the review.
The review itself, asking the right questions about data, tools, failure behavior, and ownership, is work a team has to do regardless of what runtime infrastructure it eventually enforces the findings with.
A short pre-production review checklist
- What can this feature see, and is that scoped to the user's actual
authorization?
- What can this feature do, and what limits and approvals apply
independent of the model?
- What happens when a dependency fails, and does it fail toward denying
sensitive actions?
- Who is watching this feature in production, and how would they notice a
problem?
- Who specifically owns this feature and can authorize pausing it?
- Is the review's depth matched to this feature's actual worst-case
impact?
A pre-production AI review earns its value by asking specific, checkable questions rather than seeking a general impression of readiness. The features that cause incidents are rarely the ones a specific question would have caught easily; they are the ones nobody thought to ask about at all.