AI proposes, the engineer decides: rules and skills for design checks

In design verification, artificial intelligence is only useful if it follows rules written by experienced people and if every result goes through a person. Here is how to build them.

Ask an AI system to “check a project” and you almost always get the same thing: a list of plausible, well-written remarks that change every time you repeat the question. Some are right, some are not, and none says what it is based on.

For whoever checks a design — an inspection body, the technical office of a contracting authority, the internal review of an engineering firm — such a result is useless. A check must be repeatable, justified and signed by someone who is accountable for it.

The problem is not the model. What is missing are the rules.

From checklists to skills

Every team that has been checking designs for years already owns a huge asset: checklists, findings from past projects, recurring mistakes, criteria from the Italian public procurement code (Annex I.7) turned into concrete checks. Usually it is scattered across spreadsheets, Word documents and, above all, the heads of the most experienced people.

A skill is that asset written down so that an AI system can follow it too. For each check it states four things:

• what to check, for example that the concrete class is the same in the structural report, the formwork drawing and the bill of quantities;
• on what basis: the reference criterion, whether a standard, the specification, the BIM execution plan or an internal rule;
• what to return: a finding with extracts of the documents it comes from and the criterion applied;
• what limits to respect: declared tolerances, and ambiguous cases that are never closed automatically.

A rule written this way runs the same check every time, always cites its basis and can be corrected when it is wrong. This is how the specialist knowledge of a few becomes common to the whole team.

Not just contradictions: three families of rules

When people talk about AI applied to design, they immediately think of contradictions between two sources: the report says C35/45, the drawing C32/40. They matter, but in real checks they are not most of the findings. Usually a finding comes from something else:

• missing content: vertical sections in the reinforcement schedules, the bearing capacity check in the geotechnical report, a required document that was never submitted;
• an outdated reference: a superseded standard cited as current, last year’s price list used in the bill of quantities;
• a contradiction between sources: the same figure written differently in report, drawing, bill or model.

Each family needs a different rule.

• Missing content. You need a list of what each type of document must contain, according to standards, specification and design stage. AI finds what is there, but it notices what is missing only if someone has written down what should be there.
• Outdated references. You need an up-to-date register of the standards and price lists in force, maintained by people: on its own, AI cannot be sure what changed after its training.
• Contradictions. You need to state which data to compare and with what tolerance.

What AI already checks, and what it does not yet

To write good rules you need to know where AI is reliable and where it is not. On consistency across 2D drawings, technical reports, bills of quantities and IFC models, this is the picture today.

It already does this well, with clear rules:

• technical reports with readable text: extracting declared values (material classes, thicknesses, loads, cited standards, referenced document codes) and comparing them with the other sources;
• bill of quantities: reading items, units and quantities, recalculating totals, finding items with no reference document or with descriptions that differ from reports and drawings;
• vector PDF drawings: reading title blocks, codes, revisions, scales, notes and text; checking cross-references between drawings and against the document register;
• IFC models: checking properties and parameters against the information requirements, elements with missing attributes and geometric clashes, and comparing model quantities with the bill when the model follows known rules;
• required content in text documents: checking that reports and specifications contain the parts on the list, for example the bearing capacity check in a geotechnical report;
• cited standards and price lists: comparing them with the register of those in force, provided the register is up to date.

It does this only in part, and it always needs review:

• reading a drawing as a drawing: linking a dimension or a note to the element it refers to, understanding a section or a construction detail. It works on simple cases, not yet in general;
• missing content in drawings: noticing that a schedule lacks vertical sections requires recognising the drawing, and today it must be confirmed by eye;
• scanned or raster drawings: text recognition introduces errors, and reading must be spot-checked;
• placing a model point on the right drawing: possible on plans with clear references, fragile with rotated views, different scales or poorly legible sheets;
• model vs bill quantities: measurement rules in the bill (openings, deductions, overlaps) do not match geometry, and the gap needs interpreting;
• structural calculation reports: AI reads declared inputs and results and compares them, but it does not redo or validate the calculation.

It does not do this, and should not:

• judge whether a design decision is correct or adequate: that is professional judgement;
• decide which source is right when report, drawing and bill disagree: the designer decides;
• understand the designer’s intent when a document is ambiguous;
• guarantee it has found everything: false negatives exist, and the engineer’s spot checks remain;
• sign and take responsibility for the check.

Human control on every finding

Even with well-written rules, AI signs nothing. Its job is to propose: find possible inconsistencies, collect evidence, prepare the finding. Deciding belongs to the engineer, finding by finding.

In practice each proposal has one of three outcomes:

• confirmed, and it becomes a finding of the check;
• reclassified, for example from non-conformity to observation, because the engineer sees a context the rule does not know;
• rejected, because it is a false positive.

Rejections are not wasted time. Each one shows where the rule needs to be sharper, and the improved rule makes fewer mistakes on the next project.

An invented example

A fictional lot of 180 documents across drawings, reports, bill of quantities and models. The team’s skills propose 64 findings, each with its extract and the criterion applied: 26 concern missing content, 17 outdated standards and price lists, 21 contradictions between sources. The discipline inspector reviews them:

• 41 are confirmed;
• 9 are reclassified, because they are observations rather than non-conformities;
• 14 are rejected as false positives. Eleven come from the same rule on dimensions, which is corrected before the next project.

The time saved does not come from AI “doing the check”, but from the engineer starting with an ordered, documented list instead of hundreds of files to open.

The law asks for it too

Italy’s AI law (Law 132/2025) states that in the intellectual professions AI should serve instrumental and support activities, with the professional’s intellectual work prevailing, and that clients must be informed of its use. Since 23 October 2026, Legislative Decree 179/2026, which aligns Italy with the EU AI Act, has also been in force.

Written rules and documented human control are the simplest way to stay within this framework: you know which tool did what, on what basis, and who decided.

Where to start

1. Collect the checklists and findings from completed checks.
2. Write the rules in the form what / basis / result / limits.
3. Test them on closed projects, where the outcome is known, and measure how many findings are confirmed.
4. Keep people at the centre: no finding leaves without the engineer’s approval, and every rejection updates the rule.

At Nexcommon we build the rules together with technical teams, starting from their experience: the rules belong to those who wrote them. At nexcommon.com you will find our consulting and training on AI in design processes.

▶ Watch the video on YouTube (55 seconds, on-screen text in Italian).

Organisations, names and figures in the example are invented. Legal references are a plain-language summary and do not constitute legal advice.