Waarom AI-projecten stranden op de integratielaag

Uit onderzoek van de RAND Corporation - gebaseerd op interviews met 65 data scientists en engineers - blijkt dat meer dan 80 procent van alle AI-projecten faalt. Dat is twee keer zo veel als bij reguliere IT-projecten. Maar de meeste analyses focussen op de verkeerde oorzaken: datakwaliteit, tekort aan talent of onduidelijke doelstellingen. Dat zijn reële problemen. Maar de meest voorkomende stille doder? De integratielaag. Het onzichtbare, onopvallende werk om een capabel AI-model te verbinden met de systemen die een bedrijf daadwerkelijk draaiende houden.

We zien het voortdurend. Een team bouwt een briljant prototype. Een frontier model geeft indrukwekkende antwoorden. De demo overtuigt het management. En dan vraagt iemand: "Mooi, maar hoe koppelen we dit aan ons ERP-systeem? En ons CRM? En hoe zit het met de AVG?" En dáár strandt het project - soms maanden, soms definitief.

Dit artikel ontleedt waarom integratie het kerkhof van AI-ambitie is en welke architectuurpatronen het wél overleven in productie.

Het air gap-probleem

De meeste AI-demo's bestaan in een vacuüm. Ze nemen een prompt, roepen een LLM API aan en geven een antwoord terug. Schoon, elegant en volledig losgekoppeld van de werkelijkheid.

In productie doet een AI-agent niet alleen maar tekst genereren. Hij moet lezen uit een documentmanagementsysteem, rechten controleren in Active Directory, schrijven naar een ticketsysteem, prijzen ophalen uit een ERP en elke interactie loggen voor compliance. Elk van die integraties heeft zijn eigen authenticatiemodel, dataformaat, rate limits, faalscenario's en - onvermijdelijk - een stoffige SOAP API waar niemand aan wil zitten.

Dit is de air gap: de kloof tussen wat een AI-model kan en wat je bedrijfssystemen toestaan. De kloof is niet technisch in de informaticazin - het is technisch in de loodgieterszin. Authenticatie, autorisatie, datatransformatie, foutafhandeling, retry-logica, circuit breakers, audit trails. Niets ervan is intellectueel moeilijk. Alles is tijdrovend, breekbaar en essentieel.

Het RAND-onderzoek identificeerde specifiek dat "organisaties mogelijk niet over adequate infrastructuur beschikken om hun data te beheren en voltooide AI-modellen te deployen" als primaire oorzaak van projectfalen. In de praktijk betekent dit: het model werkt, maar het omringende systeem bestaat nog niet. De AI is klaar; de integratie niet.

De laatste kilometer is de moeilijkste

In de logistiek is de laatste kilometer - het pakket van het depot naar je voordeur - goed voor meer dan de helft van de totale bezorgkosten. AI-deployment kent een vergelijkbaar probleem.

Een LLM accuraat laten antwoorden kost misschien een paar weken. Diezelfde LLM accuraat laten antwoorden, vanuit jouw data, via jouw systemen, met juiste toegangscontrole, PII-afhandeling, foutherstel en audit logging - dat kost maanden. De verhouding is vaak 20 procent modelwerk en 80 procent integratiewerk. Toch worden budgetten en tijdlijnen meestal andersom gepland.

Dit is wat de laatste kilometer er in de praktijk uitziet bij een enterprise AI-deployment:

• Model routing - Verschillende queries vereisen verschillende modellen. Een simpele FAQ-lookup heeft geen frontier model nodig; een complex multi-step reasoning-vraagstuk wel. Zonder intelligente routing betaal je te veel of presteer je te weinig.
• PII-redactie - Klantgegevens die door een LLM stromen zijn een AVG-rechtszaak die wacht om te gebeuren. Je moet persoonsgegevens strippen voordat ze het model bereiken en ze terugzetten op de terugweg.
• Fallback- en retry-logica - LLM API's gaan plat. OpenAI heeft storingen. Azure throttlet. Je productiesysteem kan niet simpelweg een foutmelding geven; het moet graceful terugvallen op een andere provider.
• Kostentracking - Tokenkosten lopen snel op. Zonder per-project, per-team of per-klant kostenattributie trekt de CFO de stekker eruit zodra de factuur binnenkomt.
• Guardrails - Outputvalidatie, contentfiltering, JSON schema-afdwinging. Het model kan alles teruggeven; je systeem heeft garanties nodig.
• Legacy-systeemconnectiviteit - Je AI-agent is slechts zo nuttig als de systemen die hij kan bereiken. En bij de meeste enterprises zijn de systemen die het meest tellen ook de oudste.

Elk van deze punten is een op zichzelf staand engineeringprobleem. Samen vormen ze de integratielaag - en dat is waar projecten komen te sterven.

AI Gateways: de ontbrekende infrastructuur

Traditionele API gateways - de Kongs en Apigees van deze wereld - zijn gebouwd voor een request-response wereld. Ze regelen routing, rate limiting en authenticatie voor REST API's. Maar AI-workloads zijn fundamenteel anders. Requests zijn non-deterministisch. Responses zijn duur (zowel in latency als kosten). Payloads bevatten gevoelige data die real-time transformatie nodig heeft. En je moet de onderliggende provider kunnen wisselen zonder een regel applicatiecode aan te passen.

Daarom is er een nieuwe categorie infrastructuur ontstaan: de AI gateway. Een AI gateway zit tussen je applicatie en de LLM-providers en fungeert als een unified control plane voor al het AI-verkeer. Zie het als een API gateway die tokens, modellen en prompts begrijpt in plaats van alleen HTTP-requests.

Het landschap is snel volwassen geworden. Diverse open-source en commerciële oplossingen pakken dit probleem nu aan:

LiteLLM en de unified API-aanpak

LiteLLM vertaalt calls naar meer dan 100 LLM-providers naar één enkel OpenAI-compatibel formaat. De proxy server functioneert als een gecentraliseerde gateway met authenticatie, spend tracking per project en gebruiker, en router-gebaseerde fallback-logica over deployments. Als Azure OpenAI uitvalt, wordt je request automatisch omgeleid naar een direct OpenAI-endpoint of een Anthropic-model - zonder dat je applicatie het verschil merkt. Dit is geen nice-to-have; voor productiesystemen is het basisvereiste.

Portkey en het guardrails-patroon

Portkey kiest een andere invalshoek. Ja, het doet routing en fallbacks. Maar de echte kracht zit in het guardrails-on-the-gateway patroon: het real-time verifiëren van LLM-inputs en -outputs met checks variërend van regex-matching en JSON schema-validatie tot prompt injection-detectie. Bij een falende guardrail kun je het request weigeren, terugvallen op een ander model, opnieuw proberen, of loggen en doorgaan. Portkey verwerkt momenteel meer dan 25 miljoen requests per dag - bewijs dat dit patroon werkt op schaal. Hun edge-architectuur voegt slechts 20-40ms latency toe, vaak terugverdiend door caching- en routingoptimalisaties.

Kong AI Gateway en enterprise governance

Kong - de gevestigde API gateway-partij - heeft zijn platform uitgebreid met AI-specifieke mogelijkheden. Hun AI gateway regelt multi-LLM security, routing en kostenbeheersing over OpenAI, Azure AI, AWS Bedrock en GCP Vertex. Het voegt semantische caching toe voor redundante prompts, AI-specifieke analytics dashboards en zelfs automatische MCP server-generatie. Voor enterprises die Kong al gebruiken voor hun traditionele API's is dit een logische uitbreiding. Voor greenfield AI-projecten biedt het een governance-first aanpak die compliance-teams waarderen.

Model routing: de multi-model realiteit

Het tijdperk van het single model is voorbij. Elk productie-AI-systeem dat de moeite waard is, gebruikt meerdere modellen, en de redenen zijn pragmatisch, niet ideologisch.

Neem een customer support agent. Simpele begroetingen en FAQ-lookups kunnen afgehandeld worden door een snel, goedkoop model als Claude Haiku of Mistral Small. Complexe troubleshooting die diep redeneren vereist heeft een krachtig reasoning model nodig. Gestructureerde data-extractie uit facturen werkt misschien het beste met een fine-tuned open-source model dat on-premises draait. En als je in Europa opereert onder de AVG, moeten bepaalde requests wellicht volledig op soevereine infrastructuur blijven.

Intelligente model routing is het patroon dat dit werkend maakt. In plaats van een model hard te coderen in je applicatie, definieer je routingregels op gateway-niveau: route op taakcomplexiteit, op datagevoeligheid, op kostenbudget of op latency-eisen. De applicatiecode blijft schoon. De routinglogica blijft gecentraliseerd en auditeerbaar.

Dit lost ook het vendor lock-in probleem op waar CTO's wakker van liggen. Wanneer je AI gateway de provider abstraheert, kun je wisselen van OpenAI naar Anthropic naar een self-hosted Llama-model zonder je applicatie aan te raken. Je zet niet langer je hele productiesysteem in op de API-stabiliteit of prijsbeslissingen van één bedrijf.

PII-redactie: het compliance-knelpunt waar niemand op plande

Een scenario dat zich bij vrijwel elk enterprise AI-project afspeelt: het prototype werkt prachtig met testdata. Dan bekijkt juridische zaken de architectuur en vraagt waar klantnamen, e-mailadressen en BSN-nummers terechtkomen. Het antwoord - "in de API van OpenAI" - triggert een compliance-review die een project maanden kan vertragen.

PII-redactie op gateway-niveau lost dit architecturaal op. Voordat een request het LLM bereikt, identificeert en vervangt de gateway persoonsgegevens door tokens. "Jan de Vries op [email protected]" wordt "[PERSOON_1] op [EMAIL_1]". Het model verwerkt de gesanitiseerde input. Op de terugweg herstelt de gateway de tokens met de originele waarden. Het LLM ziet nooit de echte data. Je compliance-team slaapt 's nachts.

Dit is niet iets dat je er later aan vastplakt. Het moet vanaf dag één onderdeel zijn van de architectuur. Wanneer PII-redactie een bijzaak is, eindig je met één van twee uitkomsten: een productiesysteem dat gevoelige data lekt, of een project dat nooit productie haalt omdat compliance niet aftekent.

Onder de AVG - en de aankomende EU AI Act - is dit niet optioneel. Organisaties die persoonsgegevens naar externe AI-providers sturen zonder adequate waarborgen riskeren boetes tot 4 procent van de jaarlijkse wereldwijde omzet. PII-redactie op gateway-niveau is de meest praktische manier om krachtige cloud-hosted modellen te gebruiken met behoud van datasoevereiniteit.

Legacy-systemen: waar goede intenties sterven

De gemiddelde enterprise draait honderden applicaties, waarvan veel tientallen jaren oud. Deze systemen zijn niet gebouwd voor AI-integratie. Ze zijn gebouwd voor betrouwbaarheid, en die hebben ze - het zijn de ruggengraat van het bedrijf. Maar ze verbinden met moderne AI-mogelijkheden vereist een vertaallaag die beide werelden begrijpt.

We hebben AI-projecten zien falen omdat niemand rekening hield met de zes weken die nodig waren om leestoegang tot een legacy ERP-systeem te krijgen. Of omdat het documentmanagementsysteem een SOAP API exposed die niet aangeroepen kan worden vanuit een moderne cloud function zonder een custom adapter. Of omdat de authenticatieflow een VPN-tunnel vereist die de cloud-hosted AI-service niet kan bereiken.

Dit zijn geen technische uitdagingen in de traditionele zin - het is organisatorische en architecturale schuld. De oplossing is niet om legacy-systemen te vervangen (dat is een meerjarig, miljoenenproject). De oplossing is om een integratielaag te bouwen die kan bemiddelen tussen de AI-agent en de legacy-systemen, protocollen vertaalt, authenticatie afhandelt en de impedance mismatch beheert tussen moderne event-driven architecturen en batch-georiënteerde legacy-systemen.

Het Model Context Protocol (MCP) komt op als standaard voor precies dit: AI-modellen een gestructureerde manier geven om te interacteren met externe tools en databronnen. Maar MCP-endpoints moeten nog steeds gebouwd, beveiligd en verbonden worden met de onderliggende systemen. Het protocol is het makkelijke deel. De integratie is het moeilijke deel.

Patronen die productie overleven

Na het bouwen van productie-AI-systemen in meerdere sectoren zien we patronen die consistent werken en patronen die consistent falen. Dit overleeft:

Gateway-first architectuur

Elke LLM-call gaat vanaf dag één door een AI gateway. Niet nadat je ontdekt dat je fallback-logica nodig hebt. Niet na de eerste productiestoring. Vanaf het begin. De gateway regelt provider-abstractie, kostentracking, PII-redactie, guardrails en observability. Je applicatiecode roept één endpoint aan. De rest is configuratie.

Integratie-gedreven planning

Voordat je één prompt schrijft, breng elk systeem in kaart waarmee de AI-agent moet communiceren. Haal API-documentatie op. Test authenticatieflows. Identificeer rate limits en dataformaten. De integratie-audit hoort in week één, niet in maand drie.

Gelaagde architectuur

Scheid het AI-brein van de integratie-loodgieterij. Je reasoning engine hoeft niet te weten of hij praat met Salesforce of een custom PostgreSQL-database. Dat is de taak van de integratielaag. Schone scheiding betekent dat je modellen kunt wisselen, integraties kunt toevoegen en componenten onafhankelijk kunt schalen.

Compliance by design

PII-redactie, audit logging en dataresidentie-eisen zijn architectuurbeslissingen, geen bijzaken. Bouw ze in de gateway-laag en ze gelden automatisch voor elk request. Probeer ze later toe te voegen en je bent compliance aan het retroffitten in een systeem dat er nooit voor ontworpen was.

Hoe Laava de integratielaag aanpakt

Bij Laava structureren we elke AI-agent rondom een 3 Layer Architecture: Context (de metadata en kennis die de agent nodig heeft), Reasoning (het AI-brein dat beslissingen neemt) en Action (de integratielaag die verbindt met de echte wereld). Die derde laag - Action - is waar we het meeste engineeringwerk in steken, omdat het dáár is waar projecten slagen of falen.

De Action Layer is waar AI gateways, PII-redactie, model routing, legacy-systeemadapters, MCP servers en guardrails leven. Het is bewust gescheiden van de Reasoning Layer zodat de AI-logica schoon en portable blijft terwijl de integratiecomplexiteit onafhankelijk beheerd wordt.

Integratie is bij ons ook geen tweederangs burger. Het is één van Laava's vier gelijkwaardige DNA-pijlers - naast AI/ML, Software Engineering en Infrastructure. We hebben dedicated integratie-expertise omdat we keer op keer hebben geleerd dat een geweldig model dat met niets verbonden is, niets waard is.

Als je worstelt met de integratie-uitdagingen van AI naar productie brengen - of het nu gaat om koppelingen met legacy-systemen, het opzetten van model routing, het implementeren van PII-redactie of het ontwerpen van een gateway-architectuur - praten we graag met je. Bezoek onze AI Integration & Gateways pagina om te lezen hoe wij de integratielaag voor productie-AI structureren, of neem direct contact op om je specifieke uitdagingen te bespreken.