De bouwsector staat door de vergrijzing voor een grote uitdaging: meer doen met minder. Terwijl de uitstroom van kennis versnelt, beloven AI-agents de productiviteitssprong die elk jaarverslag eist. Toch blijft het bij een papieren belofte; waar de software-sector AI succesvol schaalt, blijft adoptie in de bouw achter.

Dat gebrek aan adoptie ligt niet aan een gebrek aan ambitie, maar aan software die ongeschikt is voor effectieve AI integratie van de engineer op de werkvloer.

In dit blog ga ik dieper in op cruciale lessen die de bouwsector móét kopiëren van de software sector om deze impasse te doorbreken en AI-agents daadwerkelijk te laten schalen in de toekomst.

Wat is een AI-Agent (en wat niet)?

Voordat we de diepte induiken, moeten we een hardnekkige mythe ontkrachten: een AI-agent is geen magische toverstaf. Simpel gezegd is het een geavanceerd systeem dat autonoom een bepaalde software-workflow doorloopt en de stappen daarin geautomatiseerd voor je invult.

Om dit succesvol te doen, heeft een agent directe, actieve toegang nodig tot de software en de onderliggende data. Maar niet iedere software-workflow is gelijk; de acties die een agent betrouwbaar kan uitvoeren, hangen volledig af van de omgeving waarin hij opereert.

De illusie van lineaire automatisering

Sommige software is gebouwd op simpele, lineaire workflows. Denk aan een agent die we willen trainen om een keuringsformulier in te vullen op basis van een foto. De in te vullen velden staan vast en de goedkeuringsstap is in beton gegoten. Dit is voorspelbaar, overzichtelijk en gemakkelijk te automatiseren.

Maar complexere software, zoals projectbeheersing, kent juist non-lineaire workflows. Stel dat je een eis wijzigt: in het ene geval vraagt dit om een aanpassing in de objectstructuur, inclusief de introductie van een nieuw risico. In het andere geval hoef je slechts een bestaande verificatie opnieuw uit te voeren.

De valkuil van de ‘single source of truth’

Een andere kritieke variabele is of de software acteert als een geïsoleerde werkomgeving of een “single source of truth” waar meerdere mensen live aan samenwerken.

Een agent inzetten werkt uitstekend zolang je in een geïsoleerde omgeving pioniert. Je experimenteert en schaaft de AI-output bij tot deze perfect is, zonder dat je collega's daar ook maar iets van merken.

Dit breekt in omgevingen die samenwerking faciliteren op basis van een “single source of truth”. Zodra de AI-agent itereert op data met discipline-overstijgende raakvlakken, zien anderen die mutaties direct terug in de live data. Het resultaat is chaos en data-wantrouwen. Om AI te schalen, moet je dus veilig kunnen itereren zónder de actuele projectstatus te verstoren.

De bouwsector loopt achteraan

Iedere sector experimenteert momenteel met AI-agents, maar de succesratio verschilt enorm. Uit recent onderzoek van McKinsey (onder bijna 2.000 respondenten over 11 sectoren) blijkt een pijnlijke waarheid: waar de softwaresector vooroploopt met het opschalen van AI, bungelt de bouw onderaan.

Terwijl software engineering koploper is met 24% AI-adoptie, blijft projectbeheersing in de bouw op 0% steken. Dit ligt niet aan een gebrek aan ambitie, maar aan legacy software die niet gebouwd is voor effectieve AI-integratie simpelweg blokkeert.

Strategieën voor succesvolle adoptie

Er zijn drie cruciale pijlers die bijdragen aan succesvolle AI-adoptie binnen de enterprise:

Hoewel alle drie de pijlers essentieel zijn, zoomen we in dit blog in op het centraal stellen van de mens en wat dat betekent voor IT-leiders bij het selecteren van toekomstbestendige software.

The ‘Human in the Loop’ als kwaliteitsbewaker

De grootste angst rondom het opschalen van AI? Onnauwkeurigheid. In het onderzoek van McKinsey geeft zo'n 30% van de organisaties ziet dit als het absolute toprisico, en ruim 54% neemt hier al actieve maatregelen tegen. De meest effectieve strategie voor geschaalde enterprise projecten is de zogenaamde Human-in-the-Loop, ook wel “HITL”.

Dit is een formeel proces waarbij je agents niet blind laat opereren of accorderen. Er is altijd een dwingende review-stap ingebouwd waarbij een inhoudelijk expert de output van het AI-model verifieert op basis van zijn/haar vakkennis, vóórdat het formeel onderdeel wordt van de de single source of truth.

AI-Native workflows om veilig te itereren

Software moet het beoordelingsproces voor de engineer niet alleen mogelijk maken, maar intuïtief faciliteren. Net als bij 'track changes' in Word moet de expert in één oogopslag kunnen zien wat de AI-voorstel is ten op zicht van de huidige waarheid; alleen dan kan hij met de snelheid en precisie beslissen die de moderne bouw vraagt.

In veel legacy enterprise software is dit onmogelijk; daar raakt elke mutatie direct de live-omgeving. Voor projectbeheersing software is een fundamenteel andere architectuur dan ook geen luxe, maar een absolute voorwaarde.

Waarom software ontwikkeling vooroploopt

Dat software ontwikkeling met 24% adoptie de absolute koploper is, komt niet simpelweg doordat developers tech-savvy mensen zijn. De echte reden? Hun onderliggende infrastructuur en tools waren al ingericht op gecontroleerde iteratie en ondersteuning van de Human-in-the-Loop.

Neem de ontwikkeling van een nieuwe feature:

In software engineering werken ontwikkelaars nooit direct in de productieomgeving, maar in een 'branch'. In deze veilige 'branch' kan een ontwikkelaar 1 razendsnel itereren met AI-output binnen zijn natuurlijke flow zonder dat het direct impact heeft op zijn peers.

Wanneer er een goed eindproduct staat, volgt er een formeel review-proces met peers uit andere disciplines. Pas na deze rigoureuze controle wordt het eindproduct veilig samengevoegd met de live productieomgeving. Geen chaos, geen push & pray, maar 100% traceerbaarheid.

Van software naar projectbeheersing

De parallellen tussen het bouwen van software en een brug zijn één-op-één door te trekken. Het enige wat we hoeven te doen, is de vocabulaire uit de software sector te vervangen door die van de bouw.

Vervang productieomgeving door projectomgeving. Vervang een software-release door een project-baseline. En vervang feature-ontwikkeling door het uitwerken van een verificatieplan, wijzigen van een eis of het uitwerken van een ontwerp variant:

Strategische implicaties voor IT leiders

Het werk van de toekomst vraagt om een drastische koerswijziging. Voor IT-leiders betekent dit dat de evaluatiecriteria voor enterprise-software fundamenteel op de schop moeten. Concreet brengt dit drie harde implicaties met zich mee voor jouw softwarestrategie:

Bewezen methode, gebouwd voor de bouw

Levvr is gebouwd op de principes die de software sector tot koploper maakten. Hierdoor bieden wij een HITL-workflow voor projectbeheersing op bouwprojecten als veilig fundament waarop experts en AI-agents eindelijk écht kunnen samenwerken.

Wil je weten hoe dit voor jouw organisatie werkt? Neem contact met ons op en we laten je graag zien hoe het werkt.