AI for Engineering Design: What a Small Consultancy Can Automate

A small consultancy can hand AI the preparation and comparison work around design: sorting requirements, drafting specification text, extracting drawing notes and highlighting calculation or revision discrepancies. The responsible engineer must select the design basis, validate calculations, resolve conflicts, approve drawings and sign off the issued work. AI output remains a draft until those checks are recorded.

“Automate design” describes several very different actions. Turning meeting notes into a requirements list is not equivalent to selecting a structural member or approving a safety-critical detail. Set a boundary around the smallest task with a visible source and a clear reviewer. The more an output affects safety, compliance or cost, the more independent its verification must be.

Follow me on Instagram@sagnikteaches

The design boundary starts at the brief

Before testing a tool, draw a line through the consultancy's process: brief, survey or input data, concept options, calculations, drawings, specification, coordination, issue and change control. For each stage, identify the source of truth and the person who can resolve an ambiguity. A client email saying “allow for future expansion” is not a measurable load case. AI can surface that phrase as a question, but the engineer must obtain a requirement and document the design basis.

Connect on LinkedInSagnik Bhattacharya

A small mechanical and electrical consultancy may receive a room schedule, an equipment list, a drawing set and minutes from three meetings. An AI comparison can identify that Room 204 appears on the schedule but not on the equipment list. That is useful because the designer can investigate it. It becomes dangerous if the model fills the gap with a guessed unit or treats an old drawing as authoritative. Require every finding to show document, revision and page or element identifier.

Subscribe on YouTube@sagnikteaches

Separate three statuses: “candidate issue” means a tool spotted something; “confirmed issue” means a designer found supporting evidence; “resolved” means an authorised person accepted a correction or documented why no change was needed. Do not allow a candidate issue to modify the controlled drawing automatically. The same rule applies to a model suggestion that appears sensible: plausibility is not approval.

Professional engineering guidance on AI calls for validation, documentation and responsibility by the professional using the tool. It says professionals remain responsible for work that incorporates or is based on AI output, and it poses questions worth copying into a pilot plan: is the output a support aid that can be checked, or a decision tool whose output cannot be fully verified before it is relied on? Can the result be validated for this specific application, and how often? The exact duties differ with the project and the engineer's professional framework. Treat this as an operating principle and have the person responsible for the design approve the firm's detailed method.

Use AI to prepare requirements, then freeze the baseline

Ask AI to transform unstructured project material into a requirements register with fields for ID, wording, source, revision, discipline, measurable acceptance test, owner and open question. A requirement without a measurable test should not be silently completed. “Comfortable lighting” could mean several things; the model should mark it for clarification rather than invent a numerical target. Designers can then review the register with the client and freeze an approved version.

An illustrative example starts with an email: “The new workshop has 12 benches; we may add four later; keep the power arrangement flexible.” AI proposes two entries: current provision for 12 benches and a question about the capacity and timing of expansion. A poor output would state “design for 16 benches” as an approved requirement. The project engineer checks the actual supply, layout and client instruction, then records the agreed design provision. This turns an ambiguity into a controlled decision.

A second example concerns a drawing note that says “use existing opening”, while the survey shows two possible openings. The model can locate the conflicting references. It cannot know which is structurally suitable or even whether the survey is current. The engineer issues a query, obtains the missing measurement and records which opening the design uses. This is a short delay that prevents a precise but baseless drawing revision.

Do not use a general model as a substitute for a project document controller. It may summarise a superseded note without recognising the revision hierarchy. Feed only the documents needed for the test, label their revisions and ask the tool to cite them. Then check that every cited source exists. If the project platform already provides a controlled document register, use it as the authority; AI may read from it but should not replace its approval state.

Draft specifications from approved selections

Specification drafting is a good candidate once the design choice has been made. Provide the approved equipment schedule, project standard and a section template. Ask for a draft with explicit blanks for unresolved performance, installation and testing criteria. The engineer checks every claimed standard, rating and interface. A fluent sentence about “compliance with all relevant standards” is too vague to be issued and may conceal an unverified reference.

For a worked miniature, an illustrative ventilation schedule lists a design airflow of 1,200 cubic metres per hour, two duty fans and one standby unit. AI drafts a paragraph that calls for three duty fans. A schedule-to-spec comparison catches the mismatch if it reports “schedule: two duty plus one standby; draft: three duty”. The engineer corrects the text and checks whether the standby arrangement still suits the design. The model has found a conflict; it has not established what the correct design should be.

The comparison instruction matters as much as the tool. A version that keeps the model to evidence:

Compare the attached equipment schedule (revision C) with
specification section 23-34 (draft 2). For every scheduled
item, list: tag, schedule value, specification wording,
clause number, match / mismatch / not mentioned.
Quote both sources exactly. Do not propose a corrected value,
do not judge which source is right, and do not summarise.

An illustrative output row: "F-01 to F-03 | schedule: two duty, one standby | spec clause 2.3: 'three duty fans' | mismatch." A second row: "Silencer | schedule: required | spec: not mentioned." A realistic first-run problem is a row marked "airflow matches" for a clause that quotes the superseded revision B figure, because an earlier prompt did not say which revision governs. Naming the governing revision in the instruction, as above, prevents that false match; the designer still checks every row.

Another useful check is omission detection. A draft section specifies capacity and controls but no test or commissioning evidence. AI can return “commissioning acceptance criterion absent” with the relevant paragraph number. The engineer decides which test belongs in the contract, who performs it and what result passes. This distinction matters because a generic AI-generated test could impose a requirement that was never priced or could miss the actual performance risk.

Keep clause provenance. If a model borrows from a previous project, the old text may contain a client-specific product, obsolete revision or restricted design. A specification reviewer should see which clauses are standard, which are project-specific and which were newly generated. A controlled library helps; copying a whole old specification into an open prompt without access and confidentiality checks does not.

For the adjacent topic of proposals rather than design, the engineering proposals and specifications tutorial explores communication tasks. Here the limit is stricter: the issued technical specification must match a design the responsible engineer can defend.

Drawing comparison is a search task, not approval

AI can help compare drawing sheets, schedules and model exports for inconsistent labels, missing references and revision differences. Work from a reproducible export and record exactly which revisions were compared. A screenshot without a scale, layer context or sheet revision is a poor source for geometric decisions. Where the tool cannot read a line or symbol reliably, mark the item for manual inspection.

One illustrative drawing set shows a pump as P-07 on a schematic and P-17 on a plan. A comparison tool flags both labels. The designer checks the schedule and the original model, then corrects the wrong tag. Another set uses the same tag for two different pumps; a simple text comparison may not catch that because each label exists. The reviewer needs a uniqueness check on equipment IDs and a visual check of where each instance sits.

Revision change summaries can be valuable for the engineer responsible for review. A useful summary says “Sheet M-03 revision C adds a valve symbol at grid B4; no matching schedule row found.” A weak one says “minor changes to services”. Demand location, change type and affected reference. The designer still examines the actual mark-up, because the model may miss a moved connection or misunderstand a deleted line.

Do not let a tool “clean up” drawing notes in the issued file without change control. A grammatical edit can change a tolerance, a condition or a responsibility. Keep generated suggestions in a separate review layer, accept each change through the normal process and preserve the previous revision. The approved drawing is the source of contractual meaning, not the AI diff.

Calculation checks need independent methods

A model can help structure a calculation sheet, identify missing units and recompute simple arithmetic. It may also produce a convincing answer built on the wrong formula or load case. Use it as a challenge tool: ask what assumptions are missing and what would falsify the result. The engineer decides the method, validates inputs and checks output using an independent calculation or trusted engineering software whose limits are understood.

An illustrative beam calculation takes a span of 4.0 metres, but a transcribed drawing dimension is 4.8 metres. AI repeats the 4.0 figure from an old note and produces a tidy capacity table. A spot check of the formula will not catch the wrong input. A reviewer should trace geometry back to the current drawing, confirm units and load combinations, and check the result's sensitivity to the 0.8-metre difference. The numbers illustrate a failure mode; they are not design guidance.

Another calculation uses a pressure of 250 kPa in a source document but treats it as 250 Pa in the draft sheet. The arithmetic may be internally consistent and off by orders of magnitude. Add automated unit checks where possible and require a human to inspect them. A row headed “value, unit, source, conversion, reviewer” makes the error visible. Agreement between two model responses generated from the same bad input does not validate the input.

Check boundaries as well as central values. A sizing result may work at normal demand but fail at peak demand or a single-component outage. AI can list the scenarios the engineer has specified; it cannot decide that an omitted scenario is irrelevant. Record the load cases, environmental assumptions, maintenance conditions and criteria that govern the design. Where a tool proposes a new case, treat it as a question for the engineer.

The professional ethics case on AI-assisted engineering (a 2024 board of ethical review case) illustrates why a finished output needs more than a surface review. In it, an engineer used AI drafting tools to generate preliminary design documents, gave them only a cursory review, and the client then found problems in them; the board framed its analysis around competence, direction and control, client privacy and attribution. A responsible engineer should have enough control over the design process to explain the choices and checks, including where AI contributed.

A small consultancy's bounded pilot

Imagine an illustrative six-person consultancy preparing a 24-sheet design issue with 40 scheduled items. It spends 14 staff hours on a manual cross-check of notes, tags and specification references. For a pilot, it selects four sheets, one approved schedule and one specification section. AI is asked only to identify mismatches with a citation; it cannot edit the source files or approve the issue.

1. Define the test set. The engineer creates ten known discrepancies and five legitimate variations in a copy of the files. The tool must find issues without treating every variation as an error.
2. Set output fields. Each finding needs drawing and revision, exact location, conflicting source, suggested question and a confidence label. “No source” means the finding cannot advance.
3. Review the pilot. A designer checks every AI finding and inspects the test files for missed issues. The engineer reviews any consequential correction, not merely the summary count.
4. Measure full effort. Log preparation, tool operation, verification, rework and final engineering review. Compare with a similar manual cross-check.
5. Keep a stop rule. A missed high-consequence discrepancy or a fabricated drawing reference pauses expansion until the cause and control are understood.

Suppose the tool finds eight of the ten planted discrepancies, wrongly flags two variations and misses one changed capacity note. The result does not support an unattended check, even if the tool ran in minutes. It may still be useful as an extra search pass that gives a human reviewer eight early leads. The consultancy should improve the inputs or narrow the task and test again on a fresh set.

If the team wants a value estimate, compare total staff minutes per issue resolved, not clicks or generated pages. For example, 90 minutes of setup, 60 minutes of tool review and 120 minutes of designer checking total 270 minutes for the four-sheet pilot. The equivalent manual process might take 240 minutes. That pilot costs more, but it may reveal which finding types are valuable and whether setup can be reused. Do not advertise a saving before a comparable issue set supports one.

Keep the pilot out of a live issue deadline. Under time pressure, people may accept a polished output because it appears complete. An engineer should decide whether a candidate fix enters the controlled model, and the ordinary checker should still inspect the final drawing. The AI check is an added source of leads until evidence supports a different workflow.

Protect the client file and the design record

A design package may include proprietary processes, security-sensitive layouts, supplier data and information provided under a confidentiality agreement. Before uploading, check the engagement terms and tool contract: access, retention, reuse of inputs, export and deletion. Use a synthetic test set when the vendor cannot answer these questions. Restrict each pilot to the smallest relevant excerpt rather than an entire project archive.

Save a review record that a colleague could reconstruct: source file versions, prompt or tool configuration, output, designer decisions, independent calculation references and final approval. If AI suggested a change later rejected, keep the reason. This matters when the design evolves and a later reviewer asks whether an old item was considered. It also helps the firm spot recurring model errors rather than rediscover them on each project.

A filled-in illustrative row might read: “Finding 17; Sheet E-05 revision B, note 12; schedule revision C lists 400 units, note lists 350; designer confirmed mismatch against approved schedule; engineer approved note correction; drawing revision C issued.” A second row could read: “Finding 18; apparent duplicate tag; designer confirmed two view references to one item; no change.” Both rows show how the team prevented a model suggestion from turning directly into an edit.

The MEP task-by-task tool guide can help a firm select software after the task boundaries are clear. Tool choice should follow the evidence the team needs to inspect, the file formats it uses and the professional review it can support. A feature promising automatic design is less useful than a modest comparison that accurately cites its sources.

Release only what the engineer can defend

Before issue, ask three questions. Can the engineer trace each consequential design input to an approved source? Can they reproduce or independently validate the calculations and understand the assumptions? Can they explain why each drawing and specification change was accepted? If any answer is no, the output remains a draft regardless of how complete it looks.

Review intensity should track consequence. A spelling change in an internal note needs a light check; a revised capacity, connection, load path or safety instruction needs technical review and possibly independent checking. The same principle applies if AI merely highlighted the issue: the engineer's professional responsibility follows the issued work, not the software's label.

Over several projects, measure missed discrepancies, false flags, correction time and reviewer confidence. Recheck the tool when document formats, project types or model versions change. A reliable workflow is one where the engineer has more visibility into the design basis and exceptions, not one where a machine produces more pages.

Changes after issue deserve their own control. Suppose a client requests a replacement component whose connection size differs from the approved schedule. AI can compare the request with the bill of materials and identify drawings, notes and calculations that may be affected. The engineer must determine whether the substitution is acceptable, what must be recalculated and which parties need a revised issue. Record the reason for acceptance or rejection, the affected revision and the person who approved it. The engineering change order tutorial gives the tracking pattern; the design judgement still belongs to the consultancy. If a suggested change touches another discipline, route it to that discipline's reviewer instead of treating a single model summary as coordination approval.

Engineering design questions before a pilot

Can an AI tool sign off an engineering drawing?

No. A tool may propose geometry, annotate a drawing or flag an inconsistency, but the responsible engineer must understand the work, verify the design basis and complete the applicable professional approval. A review limited to skimming the finished drawing is especially weak if nobody controlled the design decisions that produced it.

Should we use AI to check calculations?

Use it to identify missing inputs, transcribe a formula or perform a second, clearly labelled calculation. The engineer still checks units, load cases, assumptions, boundary conditions and the governing method with an independent calculation or validated tool. Agreement between two AI outputs is not independent validation if both repeat the same faulty assumption.

What is a low-risk first design use?

A controlled comparison of a draft specification against an approved requirements schedule is a reasonable pilot. Ask the tool to list each requirement with a source and document location, then have a designer check every finding. Keep the issued specification and change history under the consultancy's ordinary approval process.

Further reads

• AI for Consulting Engineers: Fee Proposals and Reports, Not Calculations — Separate proposal drafting from technical design.
• Engineering Company AI: Setup Plan and Costs for a Small Firm — Plan a small firm's broader rollout and spend.
• Engineering Proposal Software With AI: What Small Firms Pay — Compare proposal tools outside the design workflow.
• Engineering RFP Responses With AI: Win Themes and Compliance Matrix — Track tender obligations before contract award.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: EGBC, Practice Advisory: Use of Artificial Intelligence (AI) in Professional Practice (version 1.0, 22 November 2024); National Society of Professional Engineers, Board of Ethical Review Case 24-2: Use of Artificial Intelligence in Engineering Practice (2024). Checked November 2026.