Why the contract risk has already started
The construction sector is watching the EU AI Act as if the risk starts on a regulatory deadline. That is too comfortable. The contract risk has already started.
AI tools are moving into design review, document control, progress monitoring, worker management, programme analysis, bid support and automated reporting. Some are low-risk productivity tools. Some may become safety critical. Some may influence employment, access, payment or compliance decisions. Yet most construction contracts still treat digital tools as background machinery. They rarely say who selected the AI system, who configured it, what data it relied on, who checked the output, who owns the generated material, or who carries liability when the output contributes to a defect, delay or safety incident.
That gap is now becoming harder to ignore.
What the EU AI Act changes
The EU AI Act is risk-based. It places heavier obligations on systems classified as high risk, including requirements around risk management, data quality, logging, documentation, transparency to deployers, human oversight, robustness, accuracy and cybersecurity. Earlier industry commentary focused heavily on 2 August 2026 as the point at which much of the Act would apply. The latest European Commission guidance now points to a revised enforcement timetable following the political agreement on the AI Omnibus, with rules for standalone applications in areas such as critical infrastructure, education, employment, migration and border control applying from 2 December 2027, and product-embedded systems such as robotics and industrial machinery applying from 2 August 2028.
That does not mean construction can relax. It means the sector has a short window to clean up its governance and contract positions before the law, the technology and the disputes converge.
The contract is where AI becomes accountable
Policies are useful. Training is necessary. But when a live project goes wrong, the contract is where responsibility is argued. If an AI-assisted design review misses a clash, does responsibility sit with the consultant, the contractor, the software provider, the person who approved the output, or the employer that mandated the tool? If an AI-driven progress monitoring system feeds a payment decision, what happens when the image data is incomplete? If a worker monitoring tool misclassifies behaviour, who checks bias, accuracy and proportionality?
The liability problem in simple words
Tim Claremont at Browne Jacobson states the core problem plainly:
"The fundamental challenge remains: when an AI system makes a decision or recommendation that contributes to a defect, delay or safety incident, determining liability between the contractor, AI system provider and other parties is complex."
That complexity is not theoretical. Construction already struggles with causation when information is fragmented across designers, consultants, contractors, specialists and suppliers. AI adds another layer: system design, training data, prompt configuration, model behaviour, user oversight and output approval.
The contract questions are already visible. Design checking and coordination need clear rules on who verifies AI output before issue. Programme risk analysis raises the question of whether AI-generated conclusions can support notices or claims. Worker monitoring brings transparency, consent, privacy and oversight into the project governance conversation. Autonomous machinery and robotics require clarity on configuration, maintenance and incident logs. Automated document review needs a defined status, whether advisory, evidential or contractual.
Deployment obligations also sit with users
Many construction firms may assume the AI Act mainly affects software developers. That is risky. Latham and Watkins highlights deployer obligations for risky AI systems, including AI literacy, training and support for overseers, technical and organisational measures, input data quality management, human oversight, continuous monitoring, operational logs, incident notifications, GDPR compliance and cooperation with authorities.
In practice, that means construction organisations using hazardous AI cannot simply point to the vendor. They may need to show that the people operating the system were trained, that input data was appropriate, that logs were retained, that outputs were monitored and that the system was suspended where risk or poor performance appeared.
The legal position also becomes more complicated when a deployer white labels, substantially modifies or repurposes a system. A contractor or consultant that heavily adapts an AI tool for a project workflow may find itself closer to provider-style responsibilities than expected.
Standard forms are lagging the technology
Browne Jacobson’s construction horizon scanning note makes the contractual problem explicit:
"Standard form contracts have not kept pace with AI adoption, creating uncertainty about how existing liability provisions apply to AI-generated outputs."
That is the sentence every project leader should print before the next digital strategy meeting. Our industry loves standard forms because they create familiarity. But familiarity can become false comfort when the toolchain changes faster than the clauses.
Bespoke AI provisions should not be treated as exotic legal drafting. They are becoming practical project controls. At minimum, major projects should clarify disclosure requirements, permitted tools, prohibited uses, human sign-off obligations, audit rights, data protection duties, record-keeping, output reliance, IP ownership and liability allocation.
The date debate should not distract from readiness
The Digital Omnibus uncertainty matters. If high-risk deadlines shift to late 2027 and 2028, organisations get more time. They do not get a free pass. AI literacy obligations and governance expectations are already moving. Clients are asking questions. Insurers will ask more. Disputes will not wait for perfect regulatory clarity.
Addleshaw Goddard’s commentary on the Commission’s draft classification guidance is useful here:
"Although the guidelines are not yet final, organisations can use them to assess whether their products and services may fall within the high-risk category."
That is the practical move. Do not wait for a final enforcement date before mapping exposure. Create an AI use register. Identify which tools touch safety, employment, critical infrastructure, automated decisions or project controls. Classify the risk. Decide what evidence you would need if a client, regulator, insurer or adjudicator asked how the system was governed.
What a sensible project clause should cover
We would expect more AI schedules to appear in construction contracts over the next year. They should be written for delivery teams, not only lawyers. Good clauses should answer five simple questions. What tools are being used? What data can they access? What outputs can be relied upon? Who must review and approve them? What records must be kept?
The point is not to ban AI. The point is to stop invisible AI usage from becoming invisible risk.
Takeaway
• Start with an AI use register. You cannot govern, insure or contract for tools you have not identified.
• Separate low-risk productivity from high-consequence workflows. A meeting summary and a safety-related design recommendation should not sit under the same approval rules.
• Update contracts before the dispute. Clarify disclosure, human oversight, reliance, IP, audit rights, data obligations and liability allocation.
• Treat deployer obligations seriously. Construction firms using AI may need training, logs, monitoring, incident processes and stronger evidence than vendor assurances.
• Do not let deadline uncertainty create inertia. Even if high-risk enforcement shifts, clients and disputes will move sooner.
Call to Action
For more practical coverage of AI governance, regulation and risk in the built environment, subscribe to the Project Flux newsletter. We help project leaders understand what new rules mean before they become live project problems.
Links and Stuff
All content reflects our personal views and is not intended as professional advice or to represent any organisation.
/
1