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 vroeger een AI-platform voor nodig was.
Over drie maanden bij één mid-sized engineering-bedrijf (geen software-bedrijf) heb ik AI operationeel gemaakt over het hele bedrijf. Negen productie MCP-servers die ERP, BIM, vloot, calculaties, gebouwautomatisering, energie en operationele logs dekken. Geen platform-team, geen framework-afhankelijkheden, geen custom chat-UI. Projectleiders, monteurs en operationele collega's bevragen de data van het hele bedrijf in natuurlijke taal, elke dag. De draaiende kost is 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 bereikbaar maakte, en waarom hij bereikbaar is voor kleine en mkb-bedrijven die te horen kregen dat enterprise AI buiten hun bereik ligt.
Het standaardpad is duur
Wanneer een mkb-bedrijf besluit AI binnen te halen, ziet het pad waar ze meestal heen worden gewezen er hetzelfde uit: bouw een merkbare chat-UI op de API, bedraad hem aan interne auth, beheer prompts in-house, voeg eventueel een RAG-pijplijn toe tegen bedrijfsdocumenten, optioneel een orkestratie-framework voor "agent workflows," en steeds vaker een observability-platform om alles te monitoren. Dat pad is reëel, en op voldoende schaal kan het de juiste keuze zijn. 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 geldt. Mijn vermoeden is dat de MCP-laag zelf verder reikt dan de framework-industrie aanneemt (meer servers, diepere tool-hiërarchieën, zorgvuldigere schemas) en niet een totaal andere architectuur vraagt. Maar dat is een hypothese van één schaal, geen rapport van een andere.
Voor een bedrijf met twintig belangrijke systemen en een paar honderd medewerkers verdient het standaardpad zich niet terug. Het is duur op drie gekoppelde manieren, en de drie uit elkaar trekken legt een eenvoudigere architectuur eronder bloot.
De chat-client. Een merkbare chat-UI is een frontend-team, een design-effort, conversatie-historie-infrastructuur, attachment-handling, multi-modale invoer, een admin-paneel, model-routing, prompt-management. De vendor (Anthropic, OpenAI, Google) levert dit allemaal als onderdeel van het abonnement en blijft elk kwartaal nieuwe mogelijkheden toevoegen. 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 custom chat-UI pint vrijwel altijd aan een specifieke modelversie voor stabiliteit. Zes maanden later beweegt de frontier, en het vastgepinde model is nu een generatie achter. Upgraden betekent elke prompt en elke tool opnieuw valideren, dus de meeste teams doen het niet. Ondertussen kreeg elke Claude Team-abonnee Opus 4.7 op de ochtend dat hij uitkwam, zonder enige engineering-arbeid.
De facturatie. API-facturatie gaat per-token, wat betekent dat de kost een functie is van gebruikersgedrag dat nog niet heeft plaatsgevonden. In een personeelsbestand van 50-500 mensen drijft ongeveer 20% van de gebruikers 80% van het verbruik zodra adoptie stabiliseert. Gepubliceerde analyses van zwaar gebruik zetten de API-vs-abonnement-kostenratio op 15-30x; voor gemiddelde gebruikers is het veelvoud kleiner (3-10x), en voor lichte gebruikers kan API juist voordeliger uitvallen. Het relevante getal is niet het gemiddelde. Het is de variantie.
Deze drie kosten staan niet los van elkaar. Ze vloeien voort uit dezelfde wortelbeslissing: bouwen we onze eigen chat-UI, of gebruiken we die van de vendor. Bouwen sluit alle drie tegelijk vast. Het standaardpad bindt een kleiner bedrijf gelijktijdig aan een bouw-budget, een onderhoudsteam, een verouderend model, en een onvoorspelbare rekening.
Het eenvoudigere pad
Gebruik de chat-client van de vendor. Betaal per seat. Verbind je bestaande identity-provider. Steek je engineering-uren vervolgens waar de waarde compoundt: in MCP-servers die je domein encoderen.
Dit is de architectuur in productie. Medewerkers gebruiken Claude via de standaard-client (web, desktop, mobile). De client authenticeert tegen de corporate identity-provider, hetzelfde 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 vector-database. Een retrieval-pijplijn. Een agent-observability-stack. Een "AI-platform" van welke soort 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 voor een mkb-bedrijf is "RAG over onze documenten": knip alle SharePoint of Google Drive-content in stukken, embed het, bouw een vector-store, bedraad het aan een retrieval-laag, host en onderhoud de hele pijplijn. Zelfs als die pijplijn goedkoop te bouwen is, is het een laag die je in leven moet houden. Re-indexeren als documenten veranderen, hertunen als retrieval-kwaliteit zakt, herrechten als toegangsregels schuiven, herhuisvesten 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 overgenomen van de bestaande IdP en versheid bovenaf afgehandeld. De "document search"-capability die een custom RAG-pijplijn nodig laat klinken is al een MCP-server die je in je admin-console kunt aanzetten. De keuze is niet goedkoop vs. duur. Het is een extra laag die je onderhoudt vs. helemaal 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 custom RAG-pijplijn nog dunner.
Dat verscherpt de architecturale regel. 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. Dat is waar de investering compoundt, en waar niet.
Het kostenplaatje keert om. Claude Team is ongeveer €19/seat/maand op het jaarplan; ChatGPT Enterprise en Gemini for Workspace zitten in vergelijkbaar terrein. De vendor eet de facturatie-variantie. Elke seat krijgt het nieuwste frontier-model de dag dat hij uitkomt. Geen frontend om te onderhouden, geen platform-team om in te richten, geen orkestratie-platform om te kopen.
Wat dit opent
Het interessante aan deze architectuur, en het deel dat hem bereikbaar 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 met één domeinexpert een paar weken per domein samenwerkt. Dat is het hele bezettingsmodel. Negen productie-servers over 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 bereikbaar 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 vergelijkbaar met een productiviteits-suite-seat. De MCP-laag wordt incrementeel gebouwd door de engineers en domeinexperts die 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 encoderen |
| Conversatie-historie, attachments, multi-modale UI | Tool-descriptions, query-strategieën, businesslogica |
| Enterprise SSO, audit logs, retentie-policies | Identity-gated tool-toegang via je bestaande IdP |
| Frontend-updates, model-upgrades, security-patches | Domeinkennis geschreven in schemas |
| Het model zelf, nieuwste versie op dag één | De integratie met ERP, BIM, vloot, 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 continu uitleveren. Wat je bezit is het deel dat geen vendor voor je kan bouwen, want geen vendor weet wat je data betekent.
Hetzelfde patroon, één verdieping lager
De reden dat dit bereikbaar 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 bouwen is één vorm van architectuur; MCP-servers direct tegen een frontier-model bouwen is dezelfde architecturale houding zonder de extra laag.
Elke MCP-spec-release sluit een nieuwe categorie problemen die voorheen een framework-laag vroegen. Tool calling, resource management, prompts, sampling, elicitation, UI-primitives via MCP Apps, en enterprise identity-integratie op de 2026-roadmap. Elk leefde voorheen in een framework boven MCP, en elk 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 omvormen tot 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. Buiten: het model, de client, de vendor. De lijn ertussen is MCP.
Als je begint
Abonneer je 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 zeven-stappen-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-wire-up en één MCP-server volstaan om aan het eind van een maand in productie te zijn met echte gebruikers.
Drie maanden daarvan over een echt bedrijf produceert wat ik nu heb: negen productie-servers, geen framework-afhankelijkheden, geen custom chat-UI, geen API-rekening, geen platform-team, en een bedrijf dat elke frontier-model-upgrade gratis krijgt 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 de platform-laag erboven klaar is met absorberen. De bedrijven die nu zo bouwen krijgen een voorsprong op een stack die over twee jaar niet ongebruikelijk zal lijken. Hij zal vanzelfsprekend lijken.
Enterprise AI vereist geen enterprise-budget. Het vereist de juiste perimeter trekken. De volledige methode staat in het white paper (Engels).