AI in je software bouwen, of je software aansluiten op AI?

Timo is backend developer bij Linku. Ik zit naast hem en hij laat me een intern dashboard van Linku zien. We gebruiken het om overzicht te houden over de techniek waarop onze projecten draaien.

Normaal log je in, bekijk je de projecten en zoek je op wat aandacht nodig heeft. Timo heeft daar iets aan toegevoegd: een MCP-server. Daardoor kan hij via zijn AI-tool Claude vragen stellen aan het dashboard.

Welke projecten lopen achter? Waar zit een security warning? Wat kan ik vandaag oppakken? De antwoorden komen uit hetzelfde systeem. Alleen hoeft hij het dashboard zelf niet meer te openen.

We schreven eerder al over MCP. Toen vooral over de stap van AI als “chatvenster” naar AI die ook iets kan doen. Dit experiment van Timo maakt een volgende toepassing concreet: je hoeft AI niet altijd in een applicatie te bouwen. Je kunt een bestaande AI ook gecontroleerd toegang geven tot jullie software.

MCP staat voor Model Context Protocol. Het is een standaard waarmee AI-systemen verbinding kunnen maken met andere software.

Steeds meer bekend diensten zoals Gmail, Slack en Notion bieden zulke koppelingen inmiddels zelf aan. Daardoor kan een AI bijvoorbeeld een agenda bekijken, informatie uit Slack ophalen of een conceptmail schrijven.

Bij bedrijfssoftware is dat niet vanzelfsprekend. Een eigen platform, backoffice, klantportaal of intern dashboard verschijnt niet vanzelf tussen de connectors van Claude, ChatGPT of Copilot.

Timo heeft daarom onderzocht hoe we zo’n verbinding zelf kunnen toevoegen. “Een soort stekker waarmee je AI-tools op onze systemen aansluit”, zegt hij.

Die vergelijking klopt technisch gezien ook goed. Een gewone API verbindt systemen met elkaar. MCP doet iets vergelijkbaars, maar dan speciaal voor AI: het maakt duidelijk welke informatie en functies een AI kan gebruiken.

In ons dashboard zijn dat bijvoorbeeld twee vrij eenvoudige functies: een lijst met projecten ophalen en de details van één project bekijken.

Normaal klik je daarvoor zelf door het dashboard om de informatie te vinden. Een AI hoeft dat niet. Die kan de informatie rechtstreeks opvragen en krijgt die terug in een vorm die hij begrijpt. In andere woorden: een AI heeft geen schermen nodig.

Daarmee verandert de manier waarop iemand een systeem gebruikt. Het gaat niet langer om: waar moet ik klikken? Maar direct: wat wil ik weten of gedaan krijgen?

Veel organisaties gebruiken al zakelijke versies van Copilot, Claude of ChatGPT. Medewerkers gebruiken die om te schrijven, informatie samen te vatten of ergens over te sparren.

Daarnaast staan vaak nog allerlei andere systemen open. Een CRM. Een intern portaal. De mail. Jira. Een planningstool. Een maatwerkapplicatie.

Timo ziet daar een interessante toepassing. Hij gebruikt Claude zelf bijvoorbeeld samen met Slack, Google Calendar, Jira en Todoist. In de ochtend kan hij laten verzamelen wat er sinds de vorige dag is gebeurd: nieuwe taken, relevante reacties en dingen waar nog actie op nodig is.

Ons eigen dashboard kan nu onderdeel worden van datzelfde ecosysteem. Dat betekent niet dat er weer een aparte AI-assistent nodig is. De AI die Timo of een collega al gebruikt, krijgt er een bron bij.

Voor organisaties die intern al met AI werken, kan het dus logischer zijn om bestaande systemen daarop aan te sluiten dan in ieder systeem opnieuw AI te bouwen.

Zodra AI bij interne software kan, wordt een andere vraag belangrijk: wie mag waarbij?

Dat is precies een vraag waar Timo scherp op is. Binnen Linku houdt hij zich veel bezig met veiligheid, en als je AI toegang geeft tot interne software, moet je ook goed regelen wie waarbij kan.

Een MCP-server beschikbaar maken is tegenwoordig redelijk goed te doen. Maar je wilt natuurlijk niet dat iemand die het webadres vindt of intikt, zomaar toegang krijgt tot de achterliggende gegevens.

Ons dashboard bevat interne informatie. Die willen we niet openbaar maken.

Daarom heeft Timo de MCP-koppeling zo gebouwd dat we onze bestaande Google Workspace-accounts kunnen gebruiken. Als ik vanuit Claude verbinding maak met het dashboard, log ik in met mijn Linku-account. Zo weet het systeem dat ik degene ben die toegang vraagt. Verdwijnt mijn account, dan vervalt ook mijn toegang via Claude.

Timo heeft deze aanpak inmiddels ook gedeeld met de Symfony-community. In zijn technisch blog beschrijft hij hoe hij de bestaande Google-login en de beveiligde MCP-verbinding met elkaar combineert.

Dat sluit aan op hoe de toegang tot onze software al geregeld is. Alleen medewerkers met het juiste account komen binnen. Vertrekt iemand bij Linku en verdwijnt het Google-account, dan vervalt ook de toegang via Claude.

De AI vormt dus geen achterdeur naar het systeem. De bestaande inlog blijft gewoon gelden.

De AI die je gebruikt weet uit zichzelf niets van jullie klanten, projecten, planning of interne processen. Die informatie zit in de software waar jullie iedere dag mee werken. Met MCP kun je delen daarvan beschikbaar maken voor AI.

Welke delen, dat bepaal je zelf. Timo vergelijkt het met het ontwerpen van een scherm. Daar zet je ook niet alle informatie en functies van een systeem op. Je laat zien wat iemand nodig heeft om een taak uit te voeren.

Met MCP werkt dat vergelijkbaar. Wil je dat AI projectinformatie kan opvragen, dan kun je die informatie beschikbaar maken zonder ook functies voor aanpassen of verwijderen mee te geven. Zo geef je AI toegang tot een specifiek deel van een systeem, voor een specifiek doel.

Zodra AI niet alleen informatie ophaalt, maar ook iets kan uitvoeren, wordt controle belangrijker.

Timo vergelijkt AI daarom met een collega aan wie je werk uit handen geeft. Je spreekt af wat iemand zelfstandig mag doen en wanneer je eerst wilt meekijken. Zelf doet hij dat bijvoorbeeld met Claude en Slack. Claude mag een bericht voor hem opstellen, maar niet versturen. Timo controleert het concept en drukt zelf op verzenden.

Die grens kun je per handeling bepalen. Een afspraak bekijken vraagt misschien geen controle. Een bericht versturen of gegevens aanpassen mogelijk wel. Want dat AI een handeling uitvoert, verplaatst de verantwoordelijkheid niet. Als organisatie bepaal je wat je AI laat doen en waar je controle houdt.

Of zoals Timo zegt: “De computer heeft het gedaan” is geen valide excuus.

De meest interessante vraag. Want de informatie die je AI nodig heeft, zit lang niet altijd in de systemen waar AI standaard mee kan verbinden. Misschien zit die informatie in jullie eigen backoffice, klantportaal, platform of andere maatwerksoftware.

Als we zo’n systeem voor jullie hebben gebouwd, kunnen we daar een MCP-koppeling aan toevoegen. Vaak kunnen we daarbij voortbouwen op wat er al is, zoals de login en functies die de applicatie via de back-end aanbiedt.

Ook als we de software niet zelf hebben gebouwd, zijn er mogelijkheden. Heeft het systeem een API, dan kunnen we een tussenlaag bouwen die de vertaling naar MCP maakt.

Dat vraagt om een andere manier van kijken naar AI-integratie. De vraag is niet alleen: waar kunnen we AI toevoegen aan onze software? Draai het ook om: hoe zorgen we dat de AI die we al gebruiken met onze software kan werken?

Dat is precies wat Timo met ons dashboard heeft gedaan. Claude zit niet in het dashboard. Het dashboard is beschikbaar gemaakt voor Claude.

Je hoeft niet voor ieder systeem opnieuw een AI-oplossing te bouwen. Je kunt bestaande software aansluiten op de AI die jullie al gebruiken, en daarbij zelf bepalen welke informatie en functies beschikbaar zijn.

Dus, welk systeem zou jij willen aansluiten op je AI?