Je Data Is Prima. Je AI Begrijpt Het Alleen Niet.

Enterprise AI-investeringen verdrievoudigden naar $37 miljard in 2025. De resultaten passen niet bij de uitgaven. MIT ontdekte dat slechts circa 5% van enterprise AI-pilots snelle omzetversnelling realiseert. S&P Global rapporteert dat 42% van de bedrijven de meeste AI-initiatieven heeft gestaakt, tegenover 17% het jaar ervoor. RAND schat het faalpercentage van AI-projecten op meer dan 80%.

De branche wijst naar datakwaliteit. Elk onderzoek noemt het als het grootste obstakel. Maar MIT identificeert iets diepers: geen dataprobleem, maar een adaptatieprobleem. Generieke AI-tools werken voor individuen, maar lopen vast in enterprise-gebruik omdat ze niet leren van of zich aanpassen aan specifieke werkprocessen.

Schone data is niet hetzelfde als begrepen data.

De technicus die er niet was

Stel je een service management ERP voor. Een onderhoudsrecord heeft een veld "toegewezen technicus". De AI leest het, vindt het leeg en vertelt de gebruiker dat er geen technicus is toegewezen.

In werkelijkheid wordt dat veld nooit gevuld. De daadwerkelijke technicus is alleen te vinden via uurboekingen gefilterd op een specifiek werkordertype. De data is perfect schoon. De AI heeft simpelweg niet de interpretatielaag om te weten dat dit veld een doodlopende weg is.

Dit is een data-interpretatieprobleem, geen datakwaliteitsprobleem.

De markt lost het verkeerde op

De reactie volgt een vast patroon: los het transportprobleem op. RAG embedt documenten in vector stores, handig voor beleidsvragen maar nutteloos voor live operationele queries. Text-to-SQL vertaalt natuurlijke taal naar syntax, maar weet niet dat een "type"-veld een specifieke numerieke code nodig heeft of dat bepaalde schemavelden doodlopend zijn. AI van leveranciers heeft platformkennis maar bedient vooral standaard workflows, geen vrije toegang via natuurlijke taal tot domeinspecifieke datamodellen.

In alle gevallen leeft kennis in infrastructuurlagen (vector stores, prompt-templates, governance-dashboards) in plaats van in de tool-interface waar het LLM daadwerkelijk redeneert.

Skills: kookboeken bij de deur

Anthropic's skills-gids diagnosticeert het probleem correct (gebruikers verbinden een MCP-server maar weten niet wat ze moeten doen) en schrijft een client-side "kennislaag" van markdown-recepten voor. De diagnose klopt. Het recept behandelt het symptoom.

Skills bestaan omdat MCP-servers Level 1 zijn. Als de server de agent al had geleerd wat de data betekent, wanneer welke tool te gebruiken en hoe calls te chainen, zou er niets overblijven voor de skill om te onderwijzen. De keuken heeft geen recepten, dus delen ze kookboeken uit bij de deur.

En client-side kennis brengt dezelfde problemen terug die het beweert op te lossen: het veroudert wanneer de server updatet, fragmenteert over clients en versies, en helpt alleen de ene client die het heeft geladen. Een skill geüpload naar Claude helpt dezelfde server niet wanneer die verbonden is met Cursor, Copilot of een custom agent.

Waarom niemand de ontbrekende laag bouwt

Vier redenen.

Developer-mentaliteit. "Ik maak de API beschikbaar, het LLM is slim genoeg om de rest uit te zoeken." Voor GitHub of Slack werkt dit: het model weet wat een pull request is. Voor een mid-market ERP met branchespecifieke typecodes? Niets daarvan zit in de trainingsdata van welk model dan ook.

Geen complex domein. De meeste MCP-servers wrappen algemeen bekende API's. Een GitHub-server hoeft niet uit te leggen wat een commit is. Een ERP-server moet wél uitleggen wat een servicemelding (type 10) betekent versus een onderhoudsopdracht (type 13) versus een serviceplanning (type 48).

Geen feedbackloop. De meeste bouwers shippen en gaan door. Ze hebben geen powerusers die dagelijks tegen limieten aanlopen en onthullen welke metadata ontbreekt.

Nieuwe technologie. MCP is nog volop in ontwikkeling. Het idee dat een tool-description meerdere alinea's aan domeinkennis kan bevatten, is bij de meeste bouwers simpelweg nog niet opgekomen.

De oplossing is niet een ander transport of een client-side kennislaag. Het is bestaande servers vullen met domeinintelligentie, direct in de tool-descriptions en schema's waar de agent het daadwerkelijk leest.

Ik heb zes volwassenheidsniveaus in kaart gebracht om dit gat te duiden. Voor het volledige patroon om van Level 1 naar Level 4 te komen, inclusief de vijffasenmethode en de feedbackarchitectuur, download het practitioner report.