Een AI toepassing kan alleen iets met je bedrijfsprocessen als ze via een API bij je gegevens en functies kan. Daarvoor vraagt ze vijf dingen van je systemen: leesbare API's, schrijfrechten met duidelijke grenzen, gebeurtenissen, actuele data en rechten per gebruiker. Heeft een systeem geen bruikbare API, dan bouw je eerst die toegang en pas daarna de AI.
De meeste organisaties die met AI aan de slag gaan, hebben een concrete wens. Een medewerker wil de status van een order opvragen in gewone taal, een planner wil een voorstel voor de week van morgen, een accountmanager wil een concept offerte op basis van de klanthistorie. Het taalmodel is daarbij het makkelijke deel. Het werk zit in het ERP, het CRM, de planningssoftware en de eigen applicatie waar die gegevens staan.
Hieronder lees je wat een AI toepassing van je API's nodig heeft, hoe je je applicatielandschap daarop scant, wat je doet met systemen zonder API en waar het Model Context Protocol past. We schrijven vanuit ruim dertig jaar koppelingen bouwen. Voor ons is AI een nieuwe afnemer van dezelfde API's.
Waarom AI begint bij de API
Een taalmodel weet niets van jouw orders, voorraad of klanten. Het kent alleen wat een toepassing het op het moment van de vraag meegeeft, en het kan alleen handelen via functies die een toepassing beschikbaar stelt. Daarmee is elke AI toepassing een afnemer van je systemen, net als een klantportaal of een API koppeling met een leverancier.
Bij veel organisaties zit daar het knelpunt. Het Connectivity Benchmark Report 2026 van MuleSoft telt gemiddeld 957 applicaties per organisatie, waarvan 27% met elkaar gekoppeld is. Voor het onderzoek zijn eind 2025 1.050 IT verantwoordelijken in negen landen ondervraagd, waaronder Nederland. Van hen zegt 96% dat het succes van AI agents afhangt van gegevensintegratie tussen alle systemen. Volgens 94% moet de IT architectuur daarvoor meer op API's gaan draaien.
Ontwikkelaars zien hetzelfde beeld. In het State of the API Report 2025 van Postman, gebaseerd op ruim 5.700 ontwikkelaars, architecten en managers, ontwerpt 24% zijn API's al met AI agents als afnemer in gedachten. De grote meerderheid bouwt nog voor menselijke gebruikers en bekende koppelpartners.
Wat een AI toepassing van je systemen nodig heeft
Een AI toepassing stelt dezelfde eisen als elke andere afnemer, alleen strenger. Ze leest documentatie letterlijk, roept functies vaker aan dan een mens en weet niet vanzelf wat ze beter kan laten. Deze vijf eigenschappen bepalen of een systeem bruikbaar is.
- Leesbare API's. Endpoints die gegevens teruggeven in een vaste structuur, met een beschrijving per veld. Een veld dat "status2" heet zonder uitleg, levert bij een AI toepassing gokwerk op.
- Schrijfrechten met afbakening. Een aparte, smalle functie per handeling: een concept offerte aanmaken, een afspraak voorstellen, een notitie toevoegen. Algemene schrijftoegang tot tabellen hoort er niet bij.
- Gebeurtenissen. Een melding zodra er iets verandert, zoals een nieuwe order of een verschoven levering, via webhooks of een berichtenwachtrij. Dan hoeft de toepassing niet steeds opnieuw te vragen of er iets veranderd is.
- Actuele data. Een antwoord op basis van de voorraad van gisteravond heeft een planner niets aan. Nachtelijke exports volstaan voor rapportages; voor AI die meedenkt in de operatie heb je gegevens van dit moment nodig.
- Rechten per gebruiker. De AI toepassing ziet wat de vragende medewerker mag zien, en niets meer. Dat lukt alleen als de API weet namens wie een verzoek binnenkomt.
Het laatste punt krijgt vaak te weinig aandacht. In hetzelfde onderzoek van Postman noemt 51% ongeautoriseerde of overmatige API aanroepen door AI agents als zorg, en 49% vreest dat AI systemen gegevens inzien die ze niet horen te zien. Beide risico's worden kleiner wanneer de API zelf de rechten afdwingt, in plaats van te vertrouwen op een AI toepassing die voorzichtig moet zijn.
Zo scan je je applicatielandschap op API's voor AI
Begin bij de processen waar AI moet helpen en werk van daaruit terug naar de systemen die eraan meedoen. Een scan van het hele landschap in één keer levert vooral een lange lijst op. Twee of drie processen met hun systemen geven sneller een bruikbaar beeld. Stel per systeem deze vragen.
| Vraag | Waar je op let |
|---|---|
| Is er een API? | Gedocumenteerd, met versiebeheer en beschikbaar binnen je licentie |
| Wat kun je lezen? | Welke objecten en velden, met welke filters en zoekmogelijkheden |
| Wat kun je schrijven? | Losse handelingen, met validatie door het systeem zelf |
| Hoe actueel is het? | Direct uit de bron of via een kopie met vertraging |
| Namens wie werkt het? | Eén algemene servicegebruiker of de rechten van de ingelogde medewerker |
| Meldt het wijzigingen? | Webhooks, berichten of alleen periodiek opvragen |
Documentatie is vaak de zwakke plek. Van de ondervraagden bij Postman worstelt 55% met documentatie die inconsistent, verouderd of afwezig is. Een beschrijving volgens de OpenAPI specificatie helpt hier direct. Die legt endpoints, velden en foutmeldingen vast in een vorm die ontwikkelaars lezen en die tools gebruiken om er functies voor een AI toepassing van te maken.
Na de scan valt elk systeem in een van drie groepen:
- Klaar. Een gedocumenteerde API met functies om te lezen en te schrijven, rechten per gebruiker en actuele gegevens.
- Bruikbaar met aanpassingen. Er is een API, maar er ontbreken functies, documentatie of een koppeling met de rechten van de gebruiker.
- Geen bruikbare toegang. Gegevens zijn alleen te bereiken via het scherm, een export of rechtstreeks in de database.
Wat je doet met systemen zonder API
Vooral oudere maatwerksystemen en afgeschermde pakketten vallen in de derde groep. Daarvoor zijn drie routes, van licht naar ingrijpend.
- Een API bouwen op het systeem zelf. Bij een eigen applicatie is dit meestal de netste route. De bedrijfsregels blijven in de applicatie en de API maakt ze bereikbaar. Dit is het werk van API development: ontwerp, beveiliging, documentatie en versiebeheer.
- Een koppellaag ernaast. Kun je het systeem zelf niet aanpassen, dan biedt een tussenlaag een nette API aan. Die leest uit een afgeschermde databaseview of uit bestanden en schrijft via de bestaande invoerroutes van het systeem. Zo'n laag valt onder software integratie en bedient meteen ook andere afnemers.
- Moderniseren. Zit de logica in een systeem dat niemand meer goed kent, dan is een API alleen een pleister. Een gerichte modernisering van het deel dat AI nodig heeft, maakt het systeem ook voor de volgende koppeling bruikbaar.
Twee routes raden we af. Laat een AI toepassing nooit rechtstreeks in de database schrijven, want dan omzeil je elke controle die het systeem zelf uitvoert. Schermautomatisering is een noodoplossing: die breekt bij elke wijziging in het scherm en maakt rechten per gebruiker lastig te volgen.
Waar het Model Context Protocol past
Het Model Context Protocol (MCP) is een open standaard voor de verbinding tussen AI toepassingen en externe systemen. Anthropic introduceerde MCP eind 2024. Sinds 9 december 2025 valt het onder de Agentic AI Foundation van de Linux Foundation, opgericht door Anthropic, Block en OpenAI. Bij die overdracht waren er meer dan 10.000 gepubliceerde MCP servers.
De specificatie, waarvan de meest recente versie van 28 juli 2026 is, beschrijft drie bouwstenen die een MCP server aanbiedt:
- Resources: context en gegevens die de gebruiker of het model kan gebruiken.
- Prompts: vaste berichtsjablonen en werkstromen voor gebruikers.
- Tools: functies die het AI model kan uitvoeren.
Voor je applicatielandschap betekent dit dat een MCP server een dunne laag bovenop je bestaande API's is. Die laag vertaalt je API naar tools en resources die elke AI toepassing met MCP ondersteuning kan ontdekken en aanroepen. Zonder goede API eronder heeft een MCP server niets aan te bieden. De volgorde is daarom altijd: eerst de API, daarna de MCP laag.
Ook de rechtenvraag komt in die laag terug. Voor verbindingen via HTTP bouwt de autorisatie in MCP op OAuth 2.1, met scopes per handeling en tokens die alleen gelden voor de server waarvoor ze zijn uitgegeven. Een API die al rechten per gebruiker kent, sluit daar zonder omwegen op aan.
AI werkt het best met mensen dichtbij
Onze visie is nuchter: AI werkt het best wanneer mensen er dichtbij blijven. In de bouw van API's voor AI vertaalt dat zich in een paar vaste keuzes.
- Begin met lezen. Een AI toepassing die gegevens opzoekt en samenvat, levert snel waarde op met weinig risico.
- Maak schrijfacties een voorstel. De toepassing zet een concept klaar en een medewerker bevestigt het.
- Leg elke aanroep vast, met de gebruiker namens wie die gebeurde.
- Houd functies klein, zodat je per handeling kunt bepalen wie hem mag gebruiken.
De MCP specificatie zelf wijst dezelfde kant op: een toepassing moet expliciete toestemming van de gebruiker vragen voordat ze een tool aanroept.
Isatis bouwt al ruim dertig jaar koppelingen en API's, van onderhoudssoftware voor de luchtvaart tot een platform voor subsidieadministratie en RFID in de supply chain. Met 30+ engineers in Nijmegen en Sarajevo, meer dan 100 projecten en certificering volgens ISO 9001 en ISO 27001 weten we hoe je een systeem openstelt zonder de controle erover te verliezen. Op onze pagina over data en AI lees je hoe we dat aanpakken. Plan een gesprek als je wilt weten welke systemen in jouw landschap klaar zijn voor AI. We lopen de scan dan samen met je door.
Veelgestelde vragen
Wat is een API voor AI?
Een API voor AI is een programmeerinterface die een AI toepassing gebruikt om gegevens te lezen of handelingen uit te voeren in een bedrijfssysteem. Technisch is het een gewone API. Het verschil zit in de eisen: duidelijke beschrijvingen per veld, smalle functies per handeling, actuele gegevens en rechten die per gebruiker gelden.
Heeft mijn ERP of CRM een API nodig om AI te gebruiken?
Ja, zodra de AI toepassing met actuele gegevens moet werken of iets in het systeem moet vastleggen. Veel standaardpakketten hebben een API. Controleer wel wat die API binnen jouw licentie kan lezen en schrijven, en of hij de rechten van de ingelogde medewerker volgt.
Vervangt het Model Context Protocol mijn API's?
MCP werkt bovenop bestaande API's. Een MCP server vertaalt je API naar tools en resources die AI toepassingen kunnen ontdekken en aanroepen. Zonder bruikbare API onder de MCP server is er niets om aan te bieden.
Waar begin je als je systemen geen API hebben?
Begin bij één proces waar AI echt helpt en kijk welke systemen daarvoor nodig zijn. Per systeem kies je daarna tussen een API op het systeem zelf, een koppellaag ernaast of een gerichte modernisering. Rechtstreeks schrijven in de database is geen goede route.
