Enterprise AI Zonder Enterprise Budget
Enterprise AI wordt verkocht als iets dat alleen grote bedrijven kunnen betalen. Dat hoeft niet. De reden is structureel: de protocol-laag eronder absorbeert het werk waar je vroeger een AI-platform voor nodig had.
In drie maanden tijd heb ik bij één middelgroot engineering-bedrijf (geen software-bedrijf) AI operationeel gemaakt in het hele bedrijf. Negen MCP-servers in productie die ERP, BIM, wagenpark, calculaties, gebouwautomatisering, energie en operationele logs ontsluiten. Geen platform-team, geen framework-afhankelijkheden, geen eigen chat-UI. Projectleiders, monteurs en operationele collega's bevragen elke dag de data van het hele bedrijf in natuurlijke taal. De lopende kosten: ongeveer €19/seat/maand voor de medewerkers die het gebruiken, plus de engineering-tijd om de MCP-laag te bouwen.
Dit stuk gaat over de architectuur die dat haalbaar maakte, en waarom hij haalbaar is voor kleine en middelgrote bedrijven die te horen hebben gekregen dat enterprise AI buiten hun bereik ligt.
Het standaardpad is duur
Wanneer een mkb-bedrijf besluit AI binnen te halen, krijgen ze meestal hetzelfde pad voorgeschoteld: bouw een eigen chat-UI op de API, hang hem aan interne auth, beheer prompts in-house, voeg eventueel een RAG-pijplijn toe op de bedrijfsdocumenten, optioneel een orkestratie-framework voor "agent workflows," en steeds vaker een observability-platform om alles te monitoren. Dat pad bestaat echt, en op voldoende schaal is het misschien de juiste keuze. Ik heb deze architectuur niet gedraaid op de schaal van een grote multinational met honderden heterogene systemen en complexe tenancy-eisen, dus ik kan niet zeggen of dezelfde houding daar nog opgaat. Mijn vermoeden is dat de MCP-laag verder reikt dan de framework-industrie aanneemt (meer servers, diepere tool-hiërarchieën, zorgvuldiger geschreven schemas) en niet een fundamenteel andere architectuur vraagt. Maar dat is een hypothese vanuit één schaal, geen rapport vanuit een andere.
Voor een bedrijf met twintig belangrijke systemen en een paar honderd medewerkers verdient het standaardpad zich niet terug. Het is op drie manieren duur die met elkaar samenhangen. Die drie uit elkaar trekken legt een eenvoudiger architectuur eronder bloot.
De chat-client. Een eigen chat-UI is een frontend-team, een design-traject, infrastructuur voor gesprekshistorie, attachment-handling, multi-modale invoer, een admin-paneel, model-routing, prompt-management. De vendor (Anthropic, OpenAI, Google) levert dat allemaal als onderdeel van het abonnement, en elk kwartaal komt er weer iets bij. In-house bouwen betekent engineering-uren steken in een commodity-laag waar de vendor structurele voordelen heeft die geen intern team kan evenaren.
Het model. Een eigen chat-UI zit vrijwel altijd vast op één specifieke modelversie, voor de stabiliteit. Zes maanden later schuift de frontier op, en het vastgepinde model ligt een generatie achter. Upgraden betekent elke prompt en elke tool opnieuw valideren, dus de meeste teams doen het niet. Ondertussen had elke Claude Team-abonnee Opus 4.7 op de ochtend dat het uitkwam, zonder ook maar één engineer-uur.
De facturatie. API-facturatie gaat per token. Dat betekent dat de kosten een functie zijn van gebruikersgedrag dat nog niet heeft plaatsgevonden. In een personeelsbestand van 50 tot 500 mensen rijdt ongeveer 20% van de gebruikers 80% van het verbruik in zodra de adoptie stabiliseert. Gepubliceerde analyses van zwaar gebruik zetten de API-vs-abonnement-ratio op 15-30x; voor gemiddelde gebruikers is het veelvoud kleiner (3-10x), en voor lichte gebruikers kan API juist voordeliger uitvallen. Het getal dat ertoe doet is niet het gemiddelde. Het is de variantie.
Deze drie kosten staan niet los van elkaar. Ze komen voort uit dezelfde wortelbeslissing: bouwen we onze eigen chat-UI, of gebruiken we die van de vendor. Bouwen koppelt alle drie in één klap aan elkaar. Het standaardpad legt een kleiner bedrijf tegelijk vast op een bouw-budget, een onderhoudsteam, een verouderend model en een onvoorspelbare rekening.
Het eenvoudiger pad
Gebruik de chat-client van de vendor. Betaal per seat. Verbind je bestaande identity-provider. Steek je engineering-uren vervolgens daar waar de waarde zich opstapelt: in MCP-servers die je domein vastleggen.
Dit is de architectuur in productie. Medewerkers gebruiken Claude via de standaard-client (web, desktop, mobile). De client authenticeert tegen de bedrijfsidentity-provider, net als elk ander corporate systeem. Via die client hebben medewerkers toegang tot negen MCP-servers die de volledige operationele keten dekken. Elke MCP-tool is RBAC-afgeschermd tegen dezelfde IdP-rollen die elk ander systeem regelen. Een monteur ziet alleen zijn eigen tijdboekingen; een controller ziet geaggregeerde financiële cijfers; een gast-gebruiker ziet niets.
Wat ik niet heb gebouwd: een chat-UI. Een model-gateway. Een prompt-management-platform. Een vectordatabase. Een retrieval-pijplijn. Een agent-observability-stack. Een "AI-platform" in welke vorm dan ook. Geen van die lagen bestaat in de stack, want de abonnement-client levert alles boven de MCP-laag en de IdP levert alles eromheen.
Een concreet voorbeeld. Het meest gepitchte AI-project bij een mkb-bedrijf is "RAG over onze documenten": hak alle SharePoint- of Google Drive-content in stukken, embed het, bouw een vector-store, hang die aan een retrieval-laag, en host en onderhoud de hele pijplijn. Zelfs als die pijplijn goedkoop te bouwen is, is het een extra laag die je in leven moet houden. Herindexeren als documenten veranderen, hertunen als de retrieval-kwaliteit zakt, opnieuw rechten zetten als de toegangsregels schuiven, opnieuw hosten als het embedding-model wordt uitgefaseerd. Ondertussen zijn de Microsoft 365- en Google Workspace-integraties die met Claude, ChatGPT en Gemini meekomen zelf MCP-servers, gepubliceerd door de vendors, onderhouden door de vendors, met permissions die de bestaande IdP overneemt en versheid die bovenaf wordt afgehandeld. De "document search"-capability waar een eigen RAG-pijplijn noodzakelijk voor lijkt is al een MCP-server die je in je admin-console kunt aanzetten. De keuze is niet goedkoop tegen duur. De keuze is een extra laag onderhouden of geen extra laag. En zodra je stopt met de data de schuld te geven en de betekenis-laag begint te repareren, wordt de case voor een eigen RAG-pijplijn nog dunner.
Dat scherpt de architectonische regel aan. MCP is geen categorie die alleen binnen je perimeter leeft; het is het protocol dat het hele ecosysteem spreekt, en vendors publiceren al servers voor de commodity-laag: productiviteits-suites, code-hosts, ticket-systemen, design-tools. Je engineering-investering gaat naar de MCP-servers die alleen jij kunt schrijven: je ERP, je BIM-data, je operationele logs, je calculatie-historie. De systemen die uniek zijn voor jouw bedrijf en waar geen vendor ooit een connector voor heeft of zal hebben. Al het andere consumeer je. Daar stapelt de investering zich op, en elders niet.
Het kostenplaatje keert om. Claude Team is ongeveer €19/seat/maand op het jaarplan; ChatGPT Enterprise en Gemini for Workspace zitten in dezelfde range. De vendor eet de facturatie-variantie. Elke seat krijgt het nieuwste frontier-model de dag dat het uitkomt. Geen frontend om te onderhouden, geen platform-team om in te richten, geen orkestratie-platform om te kopen.
Wat dat opent
Wat deze architectuur interessant maakt, en wat hem haalbaar maakt voor kleine bedrijven, is de vorm van de MCP-laag.
De domein-laag is model-agnostisch. MCP-servers zijn getypeerde interfaces met tool-descriptions en schemas. Dezelfde servers werken vandaag met Claude, morgen met Gemini, volgend kwartaal met GPT. Niets van de domeinlogica zit vast aan een model-vendor. De engineering-investering is overdraagbaar over de hele frontier-model-markt.
Identity leeft op de tool-grens. RBAC wordt afgedwongen binnen de MCP-server, tegen je bestaande IdP. Een model dat is prompt-injected kan alleen tools aanroepen waarvoor de geauthenticeerde gebruiker al gemachtigd is. Het beveiligingsmodel is hetzelfde model dat je bedrijf al draait voor elk ander systeem. Geen AI-specifieke identity-laag, geen prompt-firewall, geen model-gateway. De tool-grens is de trust-grens.
De engineering-vorm is klein. Een MCP-server is in mijn ervaring één engineer die een paar weken met één domeinexpert samenwerkt per domein. Dat is het hele bezettingsmodel. Negen servers in productie in drie maanden, geen platform-team, geen specialisten. De mensen die de onderliggende bedrijfssystemen beheren kunnen het meeste werk zelf doen, met engineering-ondersteuning.
Dit is wat de aanpak haalbaar maakt. Een mkb-bedrijf hoeft geen AI-platform-team aan te nemen om deze stack te draaien. De chat-client wordt gehuurd bij een vendor, tegen een prijs die vergelijkbaar is met een productiviteits-suite-seat. De MCP-laag wordt incrementeel gebouwd door de engineers en domeinexperts die toch al op de loonlijst staan. Er is geen inkooptraject voor een "AI-platform," geen consultancy-opdracht om de uitrol te dimensioneren, geen infrastructuur om te provisioneren.
Wat je huurt, wat je bezit
| Wat je huurt | Wat je bezit |
|---|---|
| De chat-client (Claude, ChatGPT, Gemini, naar keuze) | De MCP-servers die je domein vastleggen |
| Gesprekshistorie, attachments, multi-modale UI | Tool-descriptions, query-strategieën, bedrijfslogica |
| Enterprise SSO, audit logs, retentie-policies | Identity-gestuurde tool-toegang via je bestaande IdP |
| Frontend-updates, model-upgrades, security-patches | Domeinkennis vastgelegd in schemas |
| Het model zelf, nieuwste versie op dag één | De integratie met ERP, BIM, wagenpark, energie, calc |
| Voorspelbare per-seat-facturatie | Eén engineer, één domeinexpert, per server |
Wat je huurt is de commodity-laag: het spul waar vendors op concurreren en wat ze continu uitleveren. Wat je bezit is het deel dat geen vendor voor je kan bouwen, omdat geen vendor weet wat jouw data betekent.
Hetzelfde patroon, een verdieping lager
De reden waarom dit haalbaar is gaat een laag dieper dan de chat-client. Dezelfde logica geldt voor de framework-laag eronder: LangChain, LangGraph, CrewAI, RAG-pijplijnen, vector-DBs, agent-observability-stacks. Bovenop die lagen bouwen is één vorm van architectuur; MCP-servers direct tegen een frontier-model bouwen is dezelfde architectonische houding zonder die extra laag.
Elke release van de MCP-spec sluit een categorie problemen die voorheen een framework-laag vereiste. Tool calling, resource management, prompts, sampling, elicitation, UI-primitives via MCP Apps, en enterprise identity-integratie op de 2026-roadmap. Elk daarvan zat ooit in een framework boven MCP, en elk daarvan zit nu in het protocol zelf. De framework-laag wordt niet bestreden; hij wordt geabsorbeerd. Bedrijven die vandaag bovenop frameworks bouwen, bouwen bovenop een laag die het protocol bezig is in te slikken.
Beide lagen belonen hetzelfde antwoord: huur het oppervlak, bezit het domein. Gebruik de client van de vendor. Gebruik de identity-integraties van de vendor. Gebruik de model-upgrades van de vendor. Sla de framework-laag over. Steek je engineering in het deel dat echt van jou is: de MCP-servers die je operationele data omzetten in iets waar een agent over kan redeneren.
Zo ziet "MCP is het platform" er in de praktijk uit. Geen stack die je bouwt, een perimeter die je trekt. Binnen de perimeter: je domein, je tools, je IdP, je data. Daarbuiten: het model, de client, de vendor. De lijn ertussen is MCP.
Als je begint
Neem een abonnement op Claude Team, ChatGPT Enterprise of Gemini for Workspace. Verbind je bestaande identity-provider. Kies dan het ene systeem waarvan je collega's de data het liefst in natuurlijke taal willen bevragen, en schrijf één MCP-server tegen dat systeem. Lever die op. Kijk hoe ze hem gebruiken. Bouw de volgende. De praktijkgids loopt het volledige zevenstappen-recept door.
Dat is de hele startbeweging. Geen vendor-selectietraject voor een AI-platform. Geen headcount-plan voor een platform-team. Geen inkooptraject voor orkestratie-software. Een abonnement, een identity-koppeling en één MCP-server is genoeg om aan het eind van een maand in productie te staan met echte gebruikers.
Drie maanden daarvan over een echt bedrijf levert op wat ik nu heb: negen servers in productie, geen framework-afhankelijkheden, geen eigen chat-UI, geen API-rekening, geen platform-team, en een bedrijf dat elke frontier-model-upgrade gratis krijgt op de dag dat hij uitkomt.
Deze architectuur is geen slimme work-around voor het moment. Het is een vroege versie van hoe enterprise AI eruit gaat zien zodra de protocol-laag klaar is met de platform-laag erboven te absorberen. De bedrijven die nu zo bouwen krijgen een voorsprong op een stack die over twee jaar niet ongebruikelijk lijkt. Hij gaat dan vanzelfsprekend lijken.
Enterprise AI vereist geen enterprise-budget. Het vereist dat je de juiste perimeter trekt.
Verder lezen: lees het volledige practitioner report, The Missing Layer (Engels), of bekijk de werkende code in de mcp-metadata-demo server.