This checklist is for product managers shaping an AI feature, not writing the code or the security policy behind it, but making the early decisions that determine how much risk that feature carries once it ships. A PM rarely sets the authorization logic or the fail-closed behavior directly, but decisions about what the feature does, who it's for, and what counts as done shape every risk choice that follows. Work through this during initial scoping and again before a launch review, not only when security raises a concern. The aim is a feature spec that makes its own risk surface explicit rather than one that leaves it for engineering or security to reverse-engineer later.
Scoping the feature's actual behavior
Confirm the spec states the feature's intended use plainly enough that someone unfamiliar with the project could describe what it's supposed to do and, just as importantly, what it's explicitly not supposed to do. Writing the prohibited use down matters as much as writing the intended one, since most scope creep happens quietly through a feature drifting into adjacent territory nobody explicitly ruled in or out. Confirm the data classification the feature will touch is identified up front: whether it reads or writes personal data, financial data, or internal-only information, since that classification drives what protections the rest of the spec needs to require. Confirm the boundary between the feature's core use case and any adjacent capability someone might be tempted to bolt on later is drawn deliberately, not left to whoever implements it first, and that any such addition later goes through the same scoping questions rather than riding in on an existing feature's momentum.
Requirements that account for action risk
Confirm the spec lists every real-world action the feature can take through the model, not just the ones that are obviously visible in the interface, and that each action's reversibility is noted next to it. Confirm any action that is difficult or impossible to reverse, a payment, a deletion, a message sent to an external party, is flagged for a decision about whether human approval belongs in that step before it ships. Confirm the spec states what should happen when the feature is uncertain or the model's confidence is low, rather than leaving that behavior to whatever the implementation happens to default to.
Bringing security and legal in early
Confirm security is looped into the conversation while the feature is still being scoped, not for the first time at a pre-launch review where the cost of changing course is highest. Confirm legal or privacy review happens early enough to catch a data handling or disclosure issue while the feature can still be adjusted, particularly for anything touching personal data or regulated information. Confirm feedback from these reviews is tracked as part of the feature's requirements, not left as a conversation nobody wrote down.
Defining what "ready" means beyond feature-complete
Confirm the launch criteria for this feature include security and operational conditions, an audit trail, a fail-closed behavior for critical dependencies, a way to disable the feature quickly, alongside functional completeness. Confirm rollout happens in stages, by user segment, by data sensitivity, or by usage volume, rather than as a single full release, so a problem surfaces at a smaller scale first. Confirm there's an explicit go or no-go decision point at each stage rather than an assumption that rollout will simply continue on schedule. Confirm the criteria for moving from one stage to the next are written down before rollout starts, not decided informally in the moment based on whichever metrics happen to look reassuring at the time.
Owning the feature after launch
Confirm a specific person or team is named as the owner of this feature's risk once it's live, distinct from whoever happens to still be answering support tickets about it. Confirm there's a defined trigger for re-review: a change in the underlying model, an expansion of the feature's tools or data access, or a meaningful shift in how users actually use it compared to how it was designed. Confirm the feature has a usage and incident review on some regular cadence, not only when something visibly breaks.
Where TELEON fits
The specific technical controls this checklist points toward, an audit trail of the feature's AI activity, runtime policy enforcement at points where the model takes an action, and a fast way to restrict or disable behavior, are things a gateway deployed between the feature and its model or tool calls can provide directly. Deciding what the feature should do, which actions need approval, and who owns it afterward remain product decisions no infrastructure can make on a team's behalf.
The checklist in short form
- Intended use and explicitly prohibited use stated plainly.
- Data classification identified before implementation begins.
- Every real action listed with its reversibility noted.
- Human approval considered for irreversible or high-impact steps.
- Security and legal looped in during scoping, not at launch review.
- Launch readiness defined beyond feature-complete, with staged rollout.
- A named owner and a defined trigger for re-review after launch.
Scale how much of this checklist a given feature needs to its actual exposure. A feature that only summarizes a user's own notes for that same user carries a different risk profile than one that can message other people or move money on someone's behalf, and the second deserves a slower, more deliberate pass through every section here. Re-run the relevant parts whenever the feature's scope grows past what this original pass assumed.