ChatGPT for Structural Engineers: What Is Safe and What Never Is

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for ChatGPT for Structural Engineers: What Is Safe and What Never Is.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for ChatGPT for Structural Engineers: What Is Safe and What Never Is.

A structural engineer can safely use ChatGPT for writing: fee proposals, client letters, meeting summaries, plain-English report summaries and marketing text, always checked by a named person. It must never be given calculations, member sizing, load assumptions or design sign-off. If a wrong answer could put a building at risk, ChatGPT does not touch it.

The rule has to come from the practice owner, because the engineer at the desk is already deciding alone, often late in the day with a deadline. A policy that says only "use with care" gets ignored. One that lists safe tasks, banned tasks and a sign-off step gets followed, and it gives you something to show a client or insurer if questions come later.

Follow me on Instagram@sagnikteaches

Why calculations are the line, not a preference

ChatGPT predicts plausible text. When you ask it for a beam size it returns something that looks like a design answer, with numbers, units and a confident tone. It has no model of your structure, cannot see the loads and may mix methods or standards without saying so. It can also make an arithmetic slip while sounding sure, and it may agree with whatever you suggest.

Connect on LinkedInSagnik Bhattacharya

The problem for an engineer is not that the answer is always wrong. It is that you cannot tell from the answer when it is. In writing, a bad sentence gets caught by a reader. In a calculation, a plausible wrong number may pass a rushed check and end up in a drawing. That asymmetry is the whole policy: use it where errors are visible and cheap, never where they are hidden and costly.

Subscribe on YouTube@sagnikteaches

The firm-owner policy in one table

Pin this to the wall or paste it into the staff handbook. It is deliberately short, because a policy people remember beats a thorough one they do not.

TaskStatusCondition
Fee proposal and scope wordingSafePartner checks fees, exclusions and assumptions
Client letters and emailsSafeRedact names; author reads before sending
Meeting notes and action listsSafeChecked against the author's notes
Plain-English summary of a signed reportSafeSummary adds nothing to the report
Website and tender narrativeSafeNo unproven claims of experience
Rewording a design note you wroteSafe with careEngineer re-reads for changes of meaning
Calculations of any kindBannedNo exceptions, including "just checking"
Member sizing, connections, foundationsBannedDesign tools and engineers only
Load assumptions and combinationsBannedTaken from the project design basis
Interpreting a standard or clauseBannedRead the standard itself
Design sign-off, certification, site approvalsBannedThe responsible chartered or licensed engineer only
The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Safe use 1: a fee proposal drafted from a scope sheet

Fee proposals are repetitive, and the wording of the scope and exclusions is where practices lose money. Give ChatGPT a short scope sheet and ask for a draft in the practice's layout. The draft is a starting point for the partner, who owns the numbers.

Illustrative: a five-person practice quoting a two-storey rear extension. The engineer pastes a scope sheet with the stages, the fee of $2,400 for design and drawings, the assumption that the client supplies a measured survey, and the exclusions. The model returns a 450-word proposal in about a minute. The partner changes two assumptions the model softened, adds an exclusion for ground investigation and checks the fee figure, then sends it in 12 minutes instead of 40. The full workflow is in the structural engineer fee proposal tutorial.

Draft a fee proposal from this scope sheet in the practice's plain tone.
Use only the facts below. Do not invent fees, dates, standards or exclusions.
If something is missing, write "TBC".
List assumptions and exclusions as separate numbered lists.
Do not describe any design approach or method.

SCOPE SHEET:
[paste redacted scope sheet]

The last instruction in that prompt matters. A model asked to write a proposal will volunteer a method statement, and a sentence such as "the existing walls will be assessed for loadbearing capacity" commits the practice to something nobody agreed. Check step: the partner reads every sentence and strikes any that describes design work not in the scope sheet.

Safe use 2: letters that say no without sounding evasive

Engineers write many awkward letters: the client wants a steel beam removed with no calculations, a builder asks for sign-off on something unseen, a neighbour's party wall query. Paste the facts and ask for a firm, civil reply that states what the practice can and cannot confirm.

Before: "We can't just say it's fine without seeing it." After: "Hi [first name], thank you for the photos. We can't confirm the adequacy of the existing lintel from photographs alone. To advise, we need to inspect it on site and see the loads above. Our inspection visit is quoted at [fee], and we can attend on [date] if that suits." The reply is clear, polite and creates a paid next step. Check step: the engineer confirms the letter makes no statement about the condition or capacity of anything not inspected.

Safe use 3: meeting summaries and action lists

Take the author's own notes from a design team meeting and ask for decisions, open items and owners. This is low risk because the notes already exist and the output is easy to check. The failure to watch for is a decision recorded that was only discussed. Sample output, illustrative: "Decision 3: Transfer beam to be steel" when the meeting actually agreed "to explore steel". Check step: the author reads each decision against their notes.

For a design-team summary, add a rule to the prompt: "Mark anything discussed but not decided as 'for decision', never as a decision." That single instruction removes most of this error. If drawings were discussed, list the numbers and revisions yourself, since the model should not be trusted to transcribe them from a recording.

Safe use 4: a plain-English summary of a signed report

Clients rarely read a technical report. A summary in plain words helps them, as long as it adds nothing the report does not say. Paste the signed report's findings and recommendations and ask for 200 words at a reading level a homeowner can follow, with no new conclusions.

Illustrative: a report on cracking in a 1930s semi-detached house concludes that movement is historic and the cracks are cosmetic, with a recommendation to monitor for 12 months. The summary says exactly that, in six sentences. The engineer's check is to put the two side by side and confirm each statement in the summary is in the report, in no stronger or weaker form. Words like "safe", "stable" and "no risk" are the ones to hunt for, because they tend to appear in summaries when the report never used them. A fuller approach, with a report layout, is in the plain-English report summary tutorial, and for inspection work see photos and notes to a report draft.

The banned list, with a real-looking mistake for each

Staff break rules when they cannot see the harm, so give them cases.

Calculations: a junior asks for the size of a timber floor joist over a 4.2 m span, gets "C24 47 x 195 at 400 centres", and the answer sounds standard. It ignores the loading, the support condition and the deflection limit for the finish. Nobody can see that without redoing the work, so the answer saves nothing and adds a risk.

Standards: asking "what does the clause say about minimum cover?" yields a number delivered with confidence. The model may quote a superseded edition, a different material or a clause that does not exist. Read the standard.

Loads: "what imposed load for a roof terrace?" feels like a lookup. The correct answer depends on the use category and the design basis. It comes from the project's agreed basis, not from a chat.

Sign-off: asking for "a statement that the structure is adequate" produces fluent wording that a layperson will read as a certificate. Never ask for it, and never let a draft containing it near a client.

Code and spreadsheets: a model-written macro that sizes members is a design tool. If the practice uses one, it needs the same validation as any other software: hand-worked test cases, version control and a named owner. Most small practices are better off banning it than running that validation.

Safe use 5: marketing text and tender narrative without false claims

Practice websites and tender answers are a quiet risk because they describe capability. ChatGPT is happy to write that you have "extensive experience of heritage structures" when you have done two. Give it a factual list instead: number of years trading, project types with counts you can prove, the software and survey tools you actually use, and the qualifications held by named staff. Ask it to use only those facts.

Illustrative: a practice pastes six facts and asks for a 150-word "about us" paragraph. The first draft says the team "delivers innovative solutions to complex structural challenges", which says nothing. The owner asks for "plain statements, no adjectives", and the second version reads, "We are a five-person practice. We design extensions, loft conversions and small commercial refits, and we inspect and report on existing buildings." That is true, short and quotable. Check step: another partner reads every claim and asks "can we prove this?" A claim that fails goes.

Three decisions a partner will face in the first month

Policies fail at the edges, so rehearse three cases with the team before they arise.

Case one, the graduate who "only wanted a sanity check". She asks ChatGPT whether her calculated deflection is reasonable. The answer is no exception: the check is a calculation task. The partner's reply should be to offer the proper route, which is a second engineer's review or the practice's documented design software, not a chatbot's opinion. Make that route easy, because people use the quick option when the right one is slow.

Case two, the client who asks whether you used AI. Answer honestly and specifically: "We use it to help draft letters and summaries, and an engineer checks everything. Calculations and design are done by our engineers and our design software, never by a chatbot." That reply reassures more than a flat denial and stays true under scrutiny.

Case three, the report that arrives from a subcontractor or another consultant with obvious chatbot phrasing and a number you cannot trace. Treat it as you would any unsourced figure: ask for the basis. You are entitled to see the working behind any number you rely on, however the document was written.

A small prompt library for the safe tasks

Store three or four prompts so people stop inventing risky ones. Each carries the same two safeguards: use only supplied facts, write TBC for gaps.

CLIENT LETTER
Rewrite my draft below as a firm, civil letter. Use only my facts.
State clearly what we can and cannot confirm without a site visit.
Do not assess the condition or capacity of any structure.
[paste redacted draft]

MEETING SUMMARY
Summarise my notes as: decisions, items for decision, actions (owner, date).
Anything discussed but not agreed goes under "for decision".
[paste notes]

REPORT SUMMARY
Write a 200-word plain-English summary of the findings and recommendations
below for a homeowner. Add no conclusions and no reassurance that the
report does not contain.
[paste signed findings]

Notice what the library omits: no prompt asks the model to assess, size, check or certify. If a staff member wants a prompt that does, the answer is already in the policy table.

Sign-off steps that leave a trail

Write a three-step routine into the job procedure so the trail exists whether anyone is looking or not. Step one: the author notes in the job file where ChatGPT was used and for what, such as "draft wording, section 3". Step two: the reviewer, a named person other than the author where the practice is big enough, reads the output against the source and initials it. Step three: for anything leaving the office under the practice's name, the responsible partner or chartered (or licensed) engineer signs.

The record takes one line a document. It is the difference between "a person wrote and checked this" and "someone pasted it from a chatbot", which matters if there is a complaint or a claim. Illustrative time cost: about two minutes per document for the note and initials. Compare that with the 28 minutes the fee proposal draft above saved.

Data: what to keep out of the prompt

Writing tasks still mean pasting something. Keep client names, site addresses, access details and any commercially sensitive figures out of the prompt, and replace them with [client] and [site]. Prefer a business plan, which does not train on your content by default, or turn off the model-improvement setting on an individual plan, and check the current wording on OpenAI's own pages because settings are renamed. Ask your professional indemnity broker whether the policy has conditions about AI tools and keep the answer on file. For the wider data rules, see the guide to keeping customer data private when your team uses AI, and for removing details before you paste, redacting personal data from documents.

Rolling the policy out in a small practice

Hold a 20-minute session rather than sending an email. Show one safe use live, such as the fee proposal draft, and one banned case, such as the joist question and what the model returned. People remember the joist. Give the policy table to everyone and ask them to sign that they have read it. Agree one place in the job file for the usage note.

After a month, take ten recent job files and look for the notes. If half have none, either people are not using it or they are using it quietly, and both are worth knowing. Revisit the table every quarter. The tutorial on rolling out an AI policy goes through the staff side in more detail.

A quarterly audit that takes under an hour

A policy nobody checks decays within a few months. Once a quarter, pull ten job files at random and run four tests. First, usage notes: does each file that contains AI-assisted wording say so, with initials? Second, banned content: search the correspondence and reports for numbers or statements that could only have come from a calculation or clause lookup done outside the design process. Third, tone drift: do letters promise things the practice does not normally promise? Fourth, data: has anyone pasted a client name, address or access detail into a prompt, visible in a shared history or an exported chat?

Illustrative result for a seven-person practice: of ten files, six had notes, two used AI without notes, and two did not use it at all. One letter had promised "a full structural survey" where the practice offers a visual inspection. Nothing unsafe reached a client, but the missing notes and the over-promise gave the partner two concrete items for the next team meeting. The audit costs about 45 minutes and produces a specific action list rather than a vague worry. Record the date and findings in the same folder as the policy, so a client or insurer who asks how you supervise AI use sees evidence of a routine, not a promise.

What this policy does not cover, and when to ask for help

This policy covers ChatGPT and other chat assistants used for writing. It does not cover structural analysis packages, finite element software or drawing tools with AI features. Those are engineering software, and they need validation, version control and an engineer who understands their limits. It also does not give legal or insurance advice. Contract terms, liability limits and cover conditions belong with your solicitor and your broker.

If you would rather build the policy with someone, that is what my AI implementation consultation covers; use the contact page if you want to talk it through. For the wider view of AI across professional services, the AI hub lists every tutorial.

Questions practice owners ask about ChatGPT and design work

Can ChatGPT check my hand calculations?

Not reliably. It may agree with a wrong calculation or flag a correct one, and it cannot show that its arithmetic was done properly. If you want a second check, use a second engineer or independent calculation software with a documented method, and record who checked what.

Can it write Python or spreadsheet code for calculations?

It can draft code for a tool, but that is a design tool once the practice relies on it. Treat any generated sheet or script like new software: verify it against hand-worked cases, version it and have a named engineer approve it. Many firms ban it outright for simplicity.

Is it safe to paste a drawing or a client brief?

Only after redaction, and only on a plan whose data terms you have read. Client names, addresses, site security details and commercially sensitive figures stay out. A brief with those removed is usually enough for a letter or summary.

Should staff tell me when they used it?

Yes. A simple line in the job file, such as 'ChatGPT used for draft wording of section 3, checked by [initials]', gives you a record if a client or insurer asks later.

What does my insurer need to know?

Ask your professional indemnity broker in writing whether the policy has any conditions about AI tools, and keep the reply on file. Wording differs between policies, so do not assume cover without checking.

Further reads

Sources: OpenAI ChatGPT help and data-controls pages; the practice's own illustrative figures. No engineering standards are quoted.

Want an AI policy your engineers will actually follow?

On a 1:1 call we'll turn the safe and banned lists into a one-page policy for your practice and decide how sign-off gets recorded in the job file.

Book a 1:1 call with me