AI in construction: where processes break down on site
On site, project data lives in three or four disconnected places: messenger chats, nested spreadsheets, scanned acts, and photos from the site. The same elevation or grid line arrives in several versions, and no one can say with confidence which is current on Monday morning.
This is fragmented site data — not a metaphor but a specific set of files without a common link to rooms and structures.
Then it is not project complexity that kicks in, but a delay in transmitting a change. The contractor learns about a new decision last, already with purchased material, and the discrepancy is discovered after installation — during as-built surveying.
The cost is dismantling, idle time for two crews, and a schedule shift that is then made up in crash mode. Construction schedule slippage rarely begins with a calculation error; more often it begins with a drawing version that the person installing the formwork did not see.
AI in construction closes exactly this gap: the system brings drawings, acts, technical supervision comments, and site reports into a single object data model and links everything to grid lines and rooms.
Then a new version of a discipline automatically highlights what it affects — and this is visible before installation begins, not after.
Implementing AI in design delivers the greatest effect not at the visualization stage, but in version reconciliation and finding inconsistencies between adjacent disciplines.
We break down how this is closed in practice: from an audit of sources and matching rules to the moment when the system warns about a discrepancy before it turns into rework.
What changes after implementing models in projects
While the model lives only in drawings, inconsistencies between disciplines — a ventilation route against load-bearing structures, reinforcement against embedded parts — surface on site, when rework has already consumed weeks.
In a shared model, these same clashes are caught by a check before release to production: the share of inconsistencies closed at the design stage reaches 90%.
The model is assembled in Autodesk Revit and transferred via IFC — the exchange remains open, without locking into a single vendor.
The approval cycle is shortened because comments are linked to coordinates and elements rather than retold in letters: the responsible person sees a specific node with revision history, response time to a deviation drops from days to hours, and repeated rounds on the same joint almost disappear.
Work volume control stops depending on who recalculated the quantities and when. Specifications and volumes are generated from the model, so the discrepancy between the design quantity sheet and actual execution is visible at every iteration, not at the end of the stage.
The schedule forecast is built on accumulated data, not on an expert "I think we'll make it." The system compares actual rates by work sections with the plan and shows deviation in advance — the manager retains slack to redistribute crews instead of a last-week crunch.
The effect holds only with data discipline: a model that is not maintained in a current state produces the same unreliable forecast as manual summaries.
Implementation formats: cloud, closed loop, hybrid
The deployment scheme is chosen not by taste but by where the data lies and who owns it. If a project has drawings, estimates, or secure facilities, the question rests on security service requirements, not on model capabilities. Therefore, we first examine the constraints, then assemble the environment.
The difference between schemes shows up in three places: how quickly the model updates, what happens when the channel breaks, and who is responsible for data safety. Below is a comparison without embellishment, including cases when an option does not fit.
| Implementation option | When it fits | Limitations |
|---|---|---|
| Cloud scheme | Fast start, peak loads, distributed crews and contractors, no security requirements | Data leaves the perimeter, exchange depends on the communication channel, some industry regulations do not allow such a scheme |
| Closed loop | Secure facilities, commercial secrets, requirement to store data only on your own site | We maintain the model and computations ourselves, updates arrive less often, development is limited by purchased equipment |
| Hybrid scheme | Sensitive data stays inside, heavy computations and training are moved outside | Harder to maintain: you need to separate flows and ensure only depersonalized fragments go outside |
We fix the choice in a data flow scheme: what is stored where, what is processed on site, and what goes outside. The security service and the operating team use the same document — during an audit, they do not have to reconstruct the picture from correspondence.
Implementation stages: from data audit to handover
Implementation begins not with model selection but with analyzing what has already been accumulated. Estimates lie in spreadsheets, drawings in project files, photo reports in chats, work logs on paper.
Until it is clear which data arrays are suitable for processing, any timeline estimate is guesswork.
Then each stage relies on the verified previous one:
- Survey and data audit. We look at how the task is solved today and how much time it takes, what is suitable for processing: volume of history, availability of labeling, completeness of logs and acts.
- Solution design. We divide the task: what is fully automated, what the model offers as an option, what remains with the specialist. We fix integrations with current systems and exchange formats.
- Prototype assembly on historical data. We take completed projects with known outcomes and check whether the model reproduces the actual result. A dead end in the approach is visible here, not six months later.
- Model tuning for the domain. We further train on your data and label disputed cases together with engineers. We set the threshold: what is more dangerous — a miss or a false positive.
- On-site validation. A trial run on an active site, reconciliation with your specialists' conclusion. We calculate the share of matches, analyze discrepancies, and correct data or logic.
- Embedding into the workflow. We connect the solution to what the team already uses, describe roles and the procedure when the model is uncertain.
- Handover and team training. We provide configurations, documentation, and access, train specialists on their tasks, and support the first work cycles.
Composition of transferred materials and settings
The project ends not with a working model but with a package by which the solution lives without us.
We transfer not a set of settings but documentation and regulations sufficient for your team to operate the system, accept changes, and, if necessary, change the contractor without losing context.
- Integration schemes. What exchanges data with what, in what format and at what frequency, what happens when any party is unavailable — with a list of failure points and default behavior.
- Configured processing scenarios. Step-by-step logic: completeness check, reconciliation with design documentation, classification of deviations, and generation of comments for each object type.
- Access policies and roles. Who enters data, who approves deviations, which actions are recorded in an immutable log, and what exactly goes into it.
- Instructions for site crews. Short memos: from what point to capture, how to check data correctness before sending, what to do when in doubt — without references to the solution's internal workings.
- Operating regulations. Error review procedure, who is responsible on the customer side, in what timeframes we connect, how improvements and logic updates are formalized.
- Solution documentation. Description of components and applicability boundaries: on which object types accuracy is higher, where manual verification is mandatory, which errors are considered acceptable.
- Metrics and reporting. Share of comments confirmed without correction, number of manual refinements per object, time from capture to conclusion — so the effect is measured, not claimed.
We agree on each item at the acceptance stage: you verify it on your objects, not on demonstration data. Describe the task — we will return with an estimate and a handover plan.
Case: AI in construction — quality control
Before implementation, quality control on site relied on walkthroughs and manual reconciliation: an engineer photographed structures, and in the evening compared the images with design documentation and entered comments into a log.
One floor inspection cycle took three to four days, and some discrepancies — shifted embedded parts, incorrect reinforcement spacing, geometry deviations — surfaced at the next stage, when rework costs many times more. Up to 12% of defects reached acceptance unnoticed.
What was changed
Site images are linked to coordinates and compared with the design model: we convert the export from Autodesk Revit into an open format so reconciliation is based on geometry, not drawings.
Computer vision finds discrepancies, classifies them by criticality, and puts them into a list linked to grid line and elevation. The sensitivity threshold was tuned together with technical supervision — the system flags what exceeds tolerance, not every glare on formwork.
What became
The floor inspection cycle was reduced to one working day: the engineer does not search for discrepancies but confirms or rejects a ready list.
The share of missed defects fell to 3% — the remainder are defects that are physically unreadable in an image, such as an unpainted joint behind insulation.
Feedback to the crew goes out the same day, so rework moves from the "after acceptance" category to the "before concreting" category.
How machine vision differs from a photo report
A photo report is an archive, not a measurement. The foreman walks the site, captures nodes, links frames to date and caption, and puts them in a log.
Data exists, but it is not compared with the design solution: to see a deviation, an engineer opens the image, finds the corresponding working documentation sheet, and compares manually. On a site with hundreds of nodes, such sampling is always incomplete.
Machine vision starts with the same frame but ends not with a file but with coordinates of the discrepancy.
The frame is linked to the spatial model of the object, the element is recognized and compared with the design position — the system calculates deviation by geometry, by position of embedded parts, by presence of reinforcement. The engineer receives not "look at the photo" but a specific area with a number.
The difference in defect recognition is at the level of task formulation. A human looks for what they were warned about and reviews selectively.
The algorithm checks every frame against the same set of features: a fine crack, formwork displacement, a missing anchor — this is classification and segmentation on labeled frames of a specific object, not a generic "neural network for construction."
There is also the cost of error. A photo report does not produce false positives simply because it measures nothing.
Machine vision does, so sensitivity thresholds and mandatory engineer review of disputed areas are introduced into the loop — the final decision is still with the human.
The comparison of approaches converges to one thing: a photo report records what was, machine vision shows how much it diverges from the design.
The first is needed for history and acceptance, the second for decisions right at the time of work, while the deviation is still cheap to correct.
Doubts about data, labeling, and model accuracy
The first question at the start is whether the already accumulated documentation is enough. It is enough if the corpus is homogeneous: a single formatting standard, repeating nodes, comparable scale of objects.
If drawings come from different bureaus and in different formats, the model confuses similar elements — then we first describe labeling rules and bring the corpus to a unified form.
Labeling is done by our engineers together with your specialists: you confirm what we consider the correct answer, we cover the volume. Disputed fragments go to a second review, and we measure disagreement between labelers — if it grows, the rule is ambiguous.
We calculate model accuracy on a holdout sample with a confidence threshold: below it, the decision goes to an engineer.
Is the available data enough?
We calculate by coverage: which types of nodes actually occur at your sites. High-volume ones are covered by training, one-off ones by a rule or human review.
What to do if standard solutions change?
The system is assembled modularly: node recognition, code compliance checking, and specification reconciliation live separately. One module changes, the rest keeps working, and the previous version remains for rollback.
How is design documentation protected?
Processing takes place in your environment: role-based access, access log, prohibition on external export. Drawings and labels remain your property.
How long does model training take?
The timeframe is set by the volume of labeling and homogeneity of the corpus, not by the chosen technology.
The "labeling — training — holdout validation" cycle runs iteratively: the first working result comes on the first iteration, then model accuracy grows on your corrections from real sites.
Let's discuss the task: stages and work plan
The first conversation takes about an hour and does not require a ready technical specification — we analyze the task, not present a solution.
To make it substantive, bring what already exists: an export from the estimate system, examples of design documentation, a site walkthrough log, a list of approvers. The closer the materials are to real ones, the shorter the path to a timeline estimate.
Then we proceed step by step:
- We fix the process boundaries: where the task begins, what result we consider ready, who accepts the work.
- We analyze the data: in what form drawings, estimates, photos, and reports arrive, what we bring to a unified format, and in what volume.
- We determine integration points with the accounting system and document storage: exchange, access rights, change log.
- We agree on metrics: share of items processed automatically, report preparation time, number of errors the system is obliged to catch.
- We assemble an implementation plan by stages with an intermediate result, so value arrives before the final launch.
- We plan a trial run on one object or section — with rollback to manual mode without stopping work.
- We return with a timeline estimate and plan: what we do, what remains on your side, what data is needed to start.
If there are no ready materials, we will start with a process description — that is enough for the first step. Describe the task, and we will return with a timeline estimate and work plan.
