Why the Default Is an Expert—and What Could Replace One
The proposed Rule 707 answers the burden question by assigning the reliability showing to the party offering the AI inference and by making an expert the ordinary foundation for that showing. This chapter examines why the draft prefers an expert, what an expert contributes beyond operating software, and why the Committee left a narrow alternative for validation-based proof. The distinction helps the reader evaluate an exception correctly: it is an alternative way to prove reliability, not a presumption that the output is reliable.
The choice reflects a problem specific to an expert-like conclusion offered without a human witness. A jury can question an expert through cross-examination and weigh the expert’s explanation, qualifications, assumptions, and concessions. An AI output cannot answer a question about why it made a particular inference. The proposed framework therefore tries to preserve a strong foundation even when the normal human source of explanation is absent.
An Expert Is the Ordinary Route Because Someone Must Explain the Method
The revised draft says that admissibility ordinarily requires the proponent to provide an expert who explains how the AI system reliably produced the evidence. The word “proponent” is important. The party seeking to place the inference before the factfinder has chosen to rely on the output, so the proposed rule does not begin by requiring the opponent to disprove an opaque conclusion. Nor does it treat the fact that a computer produced the output as a reason to presume that the output is neutral.
An expert’s role is not simply to announce that the software is accurate. The expert would need to connect the system to the reliability gates described earlier: why the output helps with the issue, why the facts and data are sufficient, why the principles and methods are reliable, and why the method was reliably applied in this case. The expert may also need to explain the system’s training, validation, error information, assumptions, and limitations. The precise evidence would depend on the output and the dispute, but the essential function is explanation.
That function is different from operation. A technician may know how to enter a prompt, select a file, run an extraction, or print a result. They may be able to testify about when the software was used and what it returned. Those facts can matter for preservation and provenance. They do not necessarily establish that the method supports the conclusion. A person can operate a system accurately while knowing little about the population used to validate it, the assumptions built into its model, the conditions in which it fails, or the meaning of its score.
The distinction is easiest to see in a recurring courtroom situation. Suppose a party offers an AI-generated assessment and calls the technician who obtained it. The opposing party asks what data trained the system, whether the case resembles the validation conditions, what the output means, and how often comparable conclusions are wrong. If the technician can answer only which menu was selected, the testimony may show proper operation without showing reliable inference. The draft’s expert default prevents operating knowledge from silently standing in for methodological knowledge.