Waarom 50% van de 'AI-projecten' iets anders wordt, en waarom dat een goed teken is

AI is vaak de snelste manier om de echte beperking te vinden. Niet het definitieve antwoord.

Hier is een patroon dat Sigli keer op keer opmerkt. Een team begint met een duidelijk verzoek: "We hebben AI nodig." Ze willen nieuwe voorspellende functies, geautomatiseerde inzichten, slimmere workflows en een flinke sprong voorwaarts in concurrentiekracht.

Dan begint de ontdekkingsfase, en verandert het "AI-project" stilletjes in iets anders: datapijplijnen en datavereisten, verbeteringen in workflow en modelimplementatie, infrastructuurbeperkingen (vaak beveiliging / datalocatie), documentatie en operationele betrouwbaarheid.

In eerste instantie kan dit aanvoelen als scope creep. Maar dat is het eigenlijk niet. Het is het project dat doet waarvoor het bedoeld is: de bottleneck vroegtijdig vinden, voordat iemand maanden verspilt aan het bouwen van een model dat niet betrouwbaar kan draaien, niet kan integreren, of niet te vertrouwen is.

Een simpele waarheid: als je "AI-project" een data-/proces-/integratieproject wordt, dan betekent dat vaak dat je de echte beperking vroeg hebt gevonden.

AI is niet altijd de uiteindelijke oplossing. Vaak is het de diagnose.

AI dwingt je tot ongemakkelijke specificiteit.

Op het moment dat je iets echt wilt opleveren, moet je vragen beantwoorden zoals:

• Wat gaat er precies in, en wat moet eruit komen?
• Waar komen de gegevens vandaan, en kunnen we erop vertrouwen?
• Hoe vaak moet dit draaien?
• Wat gebeurt er als het fout is?
• Waar in de workflow zullen mensen het daadwerkelijk gebruiken?

En dan ontdek je de realiteit: het model is het moeilijke deel niet. Het systeem eromheen wel.

Een concreet voorbeeld van een Sigli-client

In een van de casestudy's van Sigli wilde een vastgoeddataplatform "geavanceerde, up-to-date" machine learning implementeren om hun gegevens te verrijken en nieuwe klantfuncties mogelijk te maken.

Een typisch "AI-project", op papier.

Maar het werk dat er het meest toe deed, wat de AI daadwerkelijk opleverbaar maakte, zag er als volgt uit:

• samenwerken met het interne data science-team van de klant om nieuwe datapijplijnen te bouwen en ontwikkelworkflows te verbeteren, naast de ML-implementatie
• het ontwikkelen van tientallen pijplijnen om gegevensverwerking te stroomlijnen en uitbreiding van de functieset mogelijk te maken
• auditing and improving existing ML models that were slow and inefficient, because performance issues were blocking day-to-day workflows het controleren en verbeteren van bestaande ML-modellen die traag en inefficiënt waren, omdat prestatieproblemen de dagelijkse werkzaamheden blokkeerden
• werken onder een echte beperking: sommige datasets waren vertrouwelijk, dus de implementatie vond plaats op de on-site servers van de klant in plaats van in de cloud

Met andere woorden: het "AI-project" bracht onmiddellijk aan het licht dat het echte werk bestond uit datagereedheid + leveringsmechanismen + infrastructuurreality.

Het meest voorkomende "iets anders": AI-gereedheid van data

Wanneer mensen "datakwaliteit" zeggen, bedoelen ze vaak iets breders en praktischers:

• gegevens bestaan, maar zijn niet bruikbaar
• definities verschillen ("wat telt als 'op de markt'?" "wat is een prospect?")
• invoer-/uitvoervereisten zijn niet expliciet
• pijplijnen zijn niet herhaalbaar of snel genoeg
• belangrijke datasets kunnen niet vrij worden verplaatst vanwege vertrouwelijkheid

Daarom begint de driestappenaanpak van de casestudy met een evaluatie van de infrastructuur en een audit van bestaande modellen plus invoer-/uitvoerdatavereisten en pijplijnen, voordat er iets nieuws wordt gebouwd. En het is de reden waarom de levering zich richt op pijplijnen als "motoren achter nieuwe productfuncties", niet alleen op modellen. Als je het bot wilt zeggen: als je gegevens niet end-to-end kunt verplaatsen en vertrouwen, dan helpt het slimste model ter wereld niet.

Hoe "AI als diagnose" er in de praktijk uitziet

In het vastgoedplatformproject uitte de diagnose zich in vier duidelijke "bijstuurredenen":

1) Datagereedheid

Het project had meerdere / tientallen datapijplijnen nodig om de inzichten en functies van het platform op schaal mogelijk te maken. Dat is een klassiek signaal dat waarde afhangt van betrouwbare gegevensverplaatsing, niet van "meer AI".

2) Workflowrealiteit (prestaties en iteratie)

Bestaande ML-modellen waren traag en die traagheid verstoorde de werkprocessen. Dus het project werd: controleren, verbeteren en workflows opzetten die snellere functie-uitrol mogelijk maken.

3) Infrastructuurbeperkingen

Vertrouwelijke datasets dwongen tot een on-prem aanpak in plaats van een cloud-first architectuur. Die ene beperking verandert alles: tools, implementatie, monitoring en iteratiesnelheid.

4) Operationele schuld (vaak verborgen totdat AI-werk begint)

Het team moest werken met een gebrek aan documentatie, grote/complexe datasets en de gebruikelijke pijn van een technologiestapel-transitie. Dat is weer een "AI-diagnose" patroon: AI-werk legt de systemen bloot die je nog niet veilig kunt doorontwikkelen.

Dus... wat is er opgeleverd?

Wat werd opgeleverd was niet "alleen AI". Sigli en het interne team van de klant leverden infrastructuurupgrades, waaronder nieuwe pijplijnen, geavanceerde ML-functionaliteit en verbeterde workflows om sneller nieuwe functies uit te brengen. En die fundamenten maakten concrete productresultaten mogelijk, zoals uitgebreide functiemogelijkheden, waaronder vastgoedtracking en markttrendanalyse voor eindgebruikers.

Dit is precies waarom "iets anders worden" een goed teken is:

• je komt niet vast te zitten in prototype-land
• je bouwt de machinerie die inzichten herhaalbaar maakt
• je maakt de klant sterker, niet afhankelijk van een eenmalig model

Een snelle checklist: bouw je AI, of stel je een beperking vast?

Als je vroeg wilt weten of een AI-project "iets anders zal worden", stel dan deze vragen:

• Hebben we duidelijke invoer-/uitvoerdatavereisten?
• Kunnen we de gegevensstroom end-to-end betrouwbaar uitvoeren (al is het maar één keer)?
• Worden we beperkt door vertrouwelijkheid / datalocatie (on-prem versus cloud)?
• Blokkeren bestaande modellen/pijplijnen de werkprocessen omdat ze traag of kwetsbaar zijn?
• Hebben we de documentatie en eigenaarschap nodig om dit te onderhouden?

"AI-projecten die iets anders worden" is vaak het moment waarop een team stopt met het najagen van de hype en begint met opleveren.

De slechte uitkomst is niet een koerswijziging. De slechte uitkomst is een AI-demo die de confrontatie met echte systemen, echte beperkingen en echte gebruikers niet overleeft.

De goede uitkomst is wat deze casestudy laat zien: AI-werk dat fungeert als een diagnose en duurzame fundamenten creëert (datapijplijnen, leveringsworkflows, infrastructuurkeuzes) die toekomstige AI sneller, veiliger en daadwerkelijk waardevol maken.