Working on AI Products You Have Doubts About

Anyone who works on AI products will have reservations at some point. A feature may be promised before it has been tested, a metric may flatter the result, or a team may be asked to ship something whose failures would land on people who were never consulted. Raising the concern is part of the job. How it is raised decides whether it changes anything at all.

Naming the concern in specific terms

A vague objection such as "this feels risky" is easy to dismiss, because nobody can test a feeling. A specific concern names the failure, the people affected, why it could happen, and what check would reveal it. For example: if the summary tool drops a dosage change, a clinician could act on the old instruction, and the test set has no cases that involve changed dosages. That sentence can be argued with, tested and settled. A concern written in that form also tells the team which information would change the decision, which keeps the conversation on evidence rather than on who is right.

The mechanism matters. A specific concern turns a disagreement about taste into a question about evidence. Once the question is about evidence, the team can agree on what would count as enough, and everyone knows what they are agreeing to. Specificity also protects the person raising it. It shows the problem has been thought through, and it makes it harder for the concern to be recast as a personal preference.

Turning concerns into checks

After naming a concern, propose a check that could resolve it. Options include a test set covering the risky cases, a threshold the feature must meet before release, a rollback plan that can be executed quickly, and a weekly sample of outputs reviewed by a person. Offering to build the check, or to scope it with someone who can, moves the role from objector to the person who makes the decision verifiable.

Be realistic about what a check can show. A test set reflects the cases someone thought to include. A sampled review catches what the sample happens to contain. Saying so when the check is proposed keeps the team from treating a passing result as proof of safety. A check that is honestly described is more credible than one that is oversold, and it is easier to maintain as the feature changes. Where the check is a sample, agree in advance on its size, who reviews it, and what result counts as a failure, so the review cannot be quietly redefined later.

Options between shipping and refusing

Refusing outright is rarely the only option, and it is often not the most useful one. Several middle paths change the risk without ending the work:

• narrow the launch to internal users or a small group who have agreed to report problems
• add a confirmation step before the system takes any action that cannot be undone
• route a defined category of cases to a human reviewer
• hold back one capability while shipping the rest
• state clearly, in the place users will see it, what the feature does not do

Each option moves risk somewhere else. A narrower launch slows learning. Human review adds cost and can become a rubber stamp if reviewers are overloaded. Naming what each option leaves open allows the decision to be made with its trade-offs visible rather than hidden behind a deadline. A narrower launch can also be paired with a date for widening it, tied to the results of the check, so the limit has an end condition rather than becoming permanent by default.

When and how to escalate

Escalation is appropriate when the risk reaches people outside the team, when a check was declined without a reason, or when a launch date is being set to override a result that did not pass. It is not a threat. It is a request for a decision from someone with the authority to make it, and it should be treated that way by everyone involved.

The escalation works best as a short note. It states the facts, the concern in specific terms, the check proposed, the result of any check already run, and the decision needed. The tone stays factual, and other people's motives are not guessed at. The internal path should be known before it is needed. Some organizations have a formal review process for AI features, while others rely on a product lead or a safety team. Practices differ widely, so it is worth asking early how such decisions are made. If the answer is unclear, a written question to the product lead, asking who decides and by when, is a reasonable first step and leaves a record.

Protecting your own judgment

Keep a dated record of what was raised, what was decided and why. The record protects the person if a decision later goes wrong, and it helps them notice patterns in their own concerns, such as which kinds of risk tend to be dismissed. It also helps the team learn from disagreement instead of forgetting it when the people involved move on.

Practice with a feature already worked on. Write a three-paragraph concern note: the failure, the people it would affect and the check that would be run. Then state the decision wanted and the date it is needed by. Give the note to a colleague who disagrees and ask them to read it. The test is simple. Would a reader who disagrees still know what to test? If they would, the note is doing its job, whatever the outcome turns out to be. Reading the note aloud to someone outside the project can also reveal jargon that hides an unclear claim.