Waarom is dit belangrijk?
Bij elke AI-oplossing duikt dezelfde vraag op: draait dit in de cloud, of moeten we het zelf hosten? En betalen we dat met een abonnement of met een API-key? Mensen gooien die zaken vaak op één hoop, terwijl het drie verschillende dingen zijn. Wie ze uit elkaar houdt, kiest sneller de juiste opzet en weet meteen wat het kost en wie wat beheert.
De drie dingen die je moet scheiden
- Hoe je het model aanspreekt: met een abonnement (voor mensen) of met een API-key (voor software).
- Waar de toepassing errond draait: in de cloud van de leverancier, of op je eigen infrastructuur of die van de klant.
- Waar het model zelf draait: dat is altijd bij de leverancier. Die vraag is dus eigenlijk al beantwoord.
Vraag 1: abonnement of API-key?
Dit gaat over de manier waarop je toegang krijgt en betaalt.
- Een abonnement (zoals een betaalplan op claude.ai) is bedoeld voor mensen die interactief werken: chatten, schrijven, analyseren, plus de lichte automatisaties die die persoon zelf opzet. Je betaalt een vast bedrag per gebruiker en valt onder gebruikslimieten. Ideaal voor persoonlijke en teamproductiviteit.
- Een API-key is bedoeld voor software: je eigen code of toepassing roept het model aan. Je betaalt per gebruik en het schaalt mee. Dit heb je nodig zodra iets in een product zit, onbemand draait of veel eindgebruikers bedient. Zo'n sleutel is zelf een geheim dat je veilig moet bewaren en beheren.
Vuistregel: abonnement = mens, API-key = software. Een product voor klanten bouw je nooit op een persoonlijk abonnement. Dat vraagt altijd een API-key.
Vraag 2: cloud of eigen infrastructuur?
Dit gaat niet over het model, maar over de toepassing errond: de code, de opslag, de koppelingen met je systemen, de gebruikersinterface.
- In de cloud van de leverancier: de leverancier draait alles, jij bouwt weinig of geen infrastructuur. Denk aan de kant-en-klare apps en aan geplande agents die in de cloud lopen.
- Op je eigen infrastructuur of die van de klant: je draait de code zelf, op je eigen server, je eigen cloud of de cloud van de klant. Nodig bij maatwerk, integratie in bestaande systemen, of strikte controle over de data. Je beheert dan ook zelf de sleutels en toegangen.
Het model draait altijd bij de leverancier
De grote taalmodellen (Claude, GPT) host je nooit zelf, de modelgewichten zijn niet beschikbaar. "In onze eigen cloud" betekent dus niet het model zelf draaien, maar het model aanspreken via de cloud van de klant (AWS, Google Cloud, Azure) met de toepassing in hun infrastructuur. Dat is de route wanneer data de eigen cloud niet uit mag.
Wil je echt een model dat volledig op je eigen servers draait, dan heb je een open-weights model nodig. Let ook op het verschil tussen waar het model staat en waar je data verwerkt wordt: zie EU-hosting en zero-retention.
Concreet naast elkaar
Twee herkenbare opties, elk een typische combinatie van de twee vragen hierboven: de Claude-app met Routines tegenover een eigen, op maat gebouwde toepassing.
De Claude-app op je computer of telefoon, met connectoren en Routines (geplande taken die automatisch op je account lopen) is het kant-en-klare ecosysteem op een abonnement. Let op: de app op je toestel is enkel een venster, het model en de Routines draaien in de cloud van de leverancier, niet op je toestel zelf.
Een eigen toepassing is maatwerk op een API-key, gehost op je eigen servers of die van de klant, gekoppeld aan bestaande systemen. Wij bouwden er zelf één om ons team aan te sturen: hij leest mails, meetings en tickets en stuurt het werk aan, volledig onbemand.
Het verschil per onderdeel:
- Hoe je het aanspreekt: een abonnement per gebruiker, tegenover een API-key die per gebruik afrekent.
- Wat je moet bouwen en beheren: niets, de leverancier doet de infrastructuur en de toegang, tegenover een echte toepassing die gebouwd, gehost en onderhouden wordt, inclusief het veilig bewaren van sleutels en wachtwoorden.
- Voor wie: één persoon of een team dat interactief werkt, plus lichte eigen automatisaties via Routines, tegenover veel gebruikers en processen die onbemand en ingebouwd in je bedrijfssystemen draaien.
- Wat je ermee kan: chatten met je eigen documenten via connectoren en geplande taken op je account, tegenover een eigen datamodel, eigen schermen, eigen logica en koppelingen met je bestaande software.
- Maatwerk en integratie: beperkt tot wat de app en de connectoren aanbieden, tegenover volledig op maat van je processen.
- Hoe snel je start: meteen, geen project nodig, tegenover een ontwikkeltraject waarin je investeert.
Kort: het Claude-ecosysteem is ideaal om als mens sneller te werken en lichte zaken te automatiseren zonder iets te bouwen. Een eigen toepassing kies je wanneer AI een vast onderdeel van je bedrijfsvoering wordt, onbemand, voor meerdere mensen en verweven met je eigen systemen.
Wanneer kies je wat?
- Een paar mensen die interactief willen werken ("help mij sneller werken") → abonnement, geen infrastructuur nodig.
- Lichte geplande interne automatisatie op iemands account → een cloud-agent op een abonnement. Draait vanzelf, niets te hosten.
- Onbemand, ingebouwd in de systemen van de klant, voor veel gebruikers of als productfeature → API-key, plus hosting. Die hosting kan bij de leverancier of op eigen of klant-infrastructuur.
- "Onze data mag onze cloud niet uit" → het model aanspreken via de cloud van de klant, met de toepassing in hun eigen infrastructuur.
Abonnement = mens. API-key = software. Hosting = waar de toepassing errond leeft. Het model zit altijd bij de leverancier.
Verwante begrippen
- EU-hosting en zero-retention: waar je data staat en of ze gebruikt wordt voor training, los van waar het model draait.
- Open-weights model: de enige manier om een model echt op je eigen infrastructuur te draaien.
