A report drafted with AI is still the engineer's report when every finding in it comes from the engineer, and it stops being the engineer's report the moment the tool starts making findings of its own. Everything below is how to apply that: a three-question test for whether a report is yours, where the boundary between helping and authoring actually sits, and how to disclose AI use in a report you own.
What ownership of a report actually means
The seal on an engineering report attests that the substance is the engineer's: the observations, the interpretations, the recommendations. Ownership is not about who typed. It is about whose judgment the document contains, and it is the thing that makes a report defensible when someone relies on it. So the useful question about any drafting tool is not whether it is AI; it is whether the document that comes out still contains only your judgment. That question has a precise answer, and it fits in three checks.
The three-question test
A report is the engineer's work if it passes three questions:
- Is every observation in the report one the engineer made?
- Can the engineer point to where each one came from?
- Did the tool add anything that was not in the engineer's own account?
A report that passes all three is the engineer's report, whatever software was involved in producing it. A report that fails any of them has an authorship problem, and it would have the same problem if the added material had come from an unsupervised junior instead of a model. One structural engineer worked through these questions with us and landed in the same place without being pushed there.
Transcription has never been authorship
The test explains a fact engineers already rely on: voice-to-text has been in reporting workflows for years, and nobody calls a report AI-generated because dictation software turned speech into characters. The transcription is a recording device, and the same logic covers assembling the engineer's own transcribed observations into the firm's report format. Forming sentences from the engineer's account is transcription with better grammar; the substance still has one author.
That points at the boundary that actually matters. Call it the authorship line: on one side, the tool arranges content the engineer supplied; on the other, it generates content of its own. Everything on the first side is a recording device, however sophisticated. Anything on the second side is a second author in your report.
Crossing the authorship line: when the tool interprets
A tool crosses the authorship line the moment it decides what a photograph shows, infers a cause, or grades a severity. Those are acts of engineering judgment, and a document containing someone else's judgment, human or machine, is no longer entirely yours.
This is why using ChatGPT the default way fails the test. Give it your site notes and photographs and ask for a report, and it will interpret the images and fill the narrative gaps, because producing complete-sounding text is what it is built to do. The draft reads well, and somewhere in it are findings the tool invented: observations nobody made, causes nobody diagnosed, stated with the same confidence as everything real. Review does not fully repair that, because the reviewer cannot reliably tell the observed sentences from the invented ones. The report fails question three, and often questions one and two with it.
The practical consequence for evaluating any drafting tool: ask the vendor, in writing, whether the model can introduce a finding the engineer never made. Everything else about the tool is detail; this is the question that decides which side of the line it lives on.
The precedent is ordinary professional practice
Engineering already has the framework for drafting help, because reports have never required the sealing engineer to type every word. A junior drafts, a dictation tool transcribes, a subconsultant supplies lab results, and the seal has always attested to the engineering rather than to the keystrokes. Liability follows the same path: the engineer who seals a software-drafted report carries the same standard of care as for a report drafted by a junior, and what changes is only what they should be able to show they verified. A workflow in which every observation traces to the engineer's own account is easier to defend than one where it does not, which is the practical reason the mechanism matters more than the label.
Owning it includes saying how it was made
A report you own is one you can describe the making of. Write down what actually happens to your words between the site and the document: who observed, who interpreted, what the software did to the text. Most engineers can describe it in four or five sentences, and a client who reads them knows exactly what they are getting. A workable disclosure paragraph looks like this; adapt it to your own workflow and only say what is true of it:
Reports are prepared using software that transcribes and assembles the responsible engineer's own dictated site observations into the firm's report format. The software does not generate findings: every observation, interpretation, and recommendation originates with the engineer, who reviews the assembled draft and takes responsibility for the complete document before issue.
Disclose on your own initiative rather than waiting to be asked; where a client agreement restricts AI-generated reports, this same description is what you bring to that conversation, and the decision is the client's. Firms that handle this well also write down what the tool may and may not do, in the same register they would use for a subconsultant.
How Tenera is built to stay on your side of the line
Tenera Reports is drafting software built for exactly the test above. The report is drafted from the engineer's spoken narration, and the model cannot assert a finding the engineer never called: a defect that appears in the draft is one the engineer named on site. By default the model does minor image interpretation, at the level of describing what a photograph shows, and a template instruction can switch even that off. Template sections also carry scope instructions, so a structural section stays structural. Those instructions control scope; the inability to invent findings is the architecture, present whether or not anyone writes an instruction.
Run the three-question test yourself
Book a demo and bring one report type: we will draft it from real field documentation, and you can run the three-question test on the output yourself.