Ten Questions I Would Ask When Evaluating a Clinical Development AI Tool

A fluent demonstration shows that a tool can produce content. Adoption requires judging whether the output can be trusted and maintained in your own workflow. These ten questions can be sent to a vendor before evaluation or used internally. They are a proposed framework, not a regulator’s scoring form.

1. Which task and decision does it support?

Describe inputs, outputs and users. Organizing public trials differs from assessing real patient eligibility. Ask about excluded materials, diseases, languages and decisions rather than generalizing from one task.

2. Where does each consequential fact come from?

Ask to open the source, date, version and location during the demonstration. A link to a whole paper may not support a particular cell. Clarify what happens when paid or internal material cannot be accessed.

3. How are missing and conflicting information represented?

Test incomplete material. Does the tool mark uncertainty, preserve disagreement or invent a definite answer? For eligibility, unreported, permitted and prohibited are different states. There should be a clear route for unresolved information.

4. Do evaluation materials resemble our work?

Ask about design, sources, reference standard, languages and difficulty. An external paper supports a defined finding, not local performance. The original TrialGPT study, for example, has specific evaluation tasks and boundaries; its results cannot establish every matching product’s usefulness.

5. What happens with errors that change conclusions?

Beyond overall accuracy, examine reversed negation, omitted timing, confused analysis populations and fabricated citations. Ask whether errors are detected and how people handle them. Reject accuracy claims without a denominator and decision method.

6. How much review is required to accept an output?

Demonstrate source navigation, correction, checking and issue closure. Include review and rework in a pilot rather than timing only draft generation. If measurements are unavailable, retain time savings as a hypothesis to test.

7. What data are processed, retained and accessible?

Check permissions, storage, deletion, system transfers and possible use for later model improvement. Public-material tools and tools for internal protocols or patient information need distinct boundaries. Explanations should agree with contracts, configuration and internal procedures.

8. Which changes affect evaluated tasks?

Models, prompts, retrieval collections and transformations can change results. Ask about notification, version records, rollback and reevaluation. An unchanged product name does not establish an unchanged workflow.

9. Who handles exceptions and failures?

Request examples of unavailable sources, conflicts, service interruption and consequential errors. Define internal ownership of suspension, escalation and recovery. Make “human review” specific to roles and actions.

10. What exactly is the claimed regulatory status?

Distinguish publications, principles, guidance, recognition of a method and authorization of a product. The FDA’s AI document for drug regulatory decisions was still draft when checked and concerns credibility in a defined context. It does not prove any AI tool is approved.

Attach documents, demonstration findings and open tests to each answer. A gap need not automatically eliminate a product, but it should affect scope, pilot design or adoption conditions. Decide in advance which unresolved issues prevent formal use and which permit bounded testing.

The adoption case should concern a real workflow: repeatable deliverables on representative material, review cost, control of consequential errors and ongoing ownership. These questions turn advertised capabilities into arrangements the team can verify and take responsibility for.