Stel je voor: je klantenserviceplatform draait perfect. De servers zijn online, de database reageert razendsnel, en je netwerk is stabiel. Toch kunnen je medewerkers geen klanten helpen. De reden? Het AI-taalmodel dat je slimme chatbot aanstuurt is onbereikbaar. Geen foutmelding in je eigen monitoring, geen alert van je hostingpartij — maar je applicatie functioneert niet.
Dit is geen hypothetisch scenario. Op 11 februari 2026 registreerde het statusdashboard van Anthropic — maker van Claude — opnieuw een incident met verhoogde foutpercentages. Claude.ai had over de afgelopen 30 dagen een uptime van 99,32%. Dat klinkt hoog, maar vertaalt zich naar bijna 5 uur downtime per maand. Voor bedrijfskritische toepassingen is dat aanzienlijk.
Bij Universal.cloud zien we dagelijks hoe organisaties AI integreren in hun kernprocessen. Van automatische documentverwerking tot intelligente klantinteractie, van compliance-checks tot code-analyse. De afhankelijkheid groeit exponentieel, maar het beleid rond beschikbaarheid loopt achter. In deze blog delen we onze visie op een vraagstuk dat elk bedrijf met AI-ambities moet adresseren.
AI-modellen als infrastructuurcomponent
Traditioneel bestond je applicatie-infrastructuur uit bekende componenten: compute, storage, networking en databases. Elk van deze onderdelen heeft een volwassen ecosysteem van monitoring, redundantie en SLA-afspraken. Wanneer je een virtuele machine draait in Azure, AWS of Google Cloud, krijg je een SLA van 99,9% of hoger. Je database heeft failover, je storage heeft replicatie, en je netwerk heeft meerdere paden.
Met de intrede van AI-taalmodellen in het applicatielandschap is er een fundamenteel nieuwe afhankelijkheid ontstaan. Een LLM-API (Large Language Model — het type AI achter tools als ChatGPT en Claude) is geen bijzaak meer — het is een essentiële component in de keten. Als het model niet beschikbaar is, werkt je applicatie niet, ongeacht hoe robuust de rest van je infrastructuur is.
Toch behandelen veel organisaties hun LLM-integratie anders dan andere infrastructuurcomponenten. Er is geen failover geconfigureerd, geen SLA geëist van de modelprovider, en vaak ontbreekt zelfs basale monitoring op de beschikbaarheid van het model. Dat is vergelijkbaar met het draaien van je productiedatabase zonder backups — het gaat goed totdat het fout gaat.
De uptime-realiteit van grote modelproviders
Laten we eerlijk zijn: geen enkele cloudprovider of AI-leverancier levert 100% uptime. Maar de verschillen zijn groot, en de transparantie verschilt enorm.
| Provider / Service | Gemeten uptime | Gepubliceerde SLA | Opmerking |
|---|---|---|---|
| Claude API (Anthropic) | 99,42% | Niet gepubliceerd | Geen formele SLA beschikbaar |
| Claude.ai | 99,32% | Niet gepubliceerd | Consumentenproduct |
| OpenAI API | ~99,5% | 99,9% (Enterprise) | SLA enkel voor Enterprise-tier |
| Azure OpenAI | ~99,9% | 99,9% | Microsoft SLA-framework |
| Google Vertex AI | ~99,9% | 99,9% | Google Cloud SLA |
| Amazon Bedrock | ~99,9% | 99,9% | AWS SLA-framework |
Wat opvalt: de gepubliceerde uptimecijfers van AI-modelproviders liggen consistent lager dan wat we gewend zijn van traditionele cloudinfrastructuur. Een SLA van 99,9% voor een Azure VM betekent maximaal 43 minuten downtime per maand. Een gemeten uptime van 99,3% voor een LLM-API betekent ruim 5 uur. Dat is een factor 7 verschil dat in veel organisaties niet wordt meegenomen in de risico-analyse.
Bovendien is de aard van de downtime anders. Traditionele infrastructuurproblemen zijn vaak lokaal en voorspelbaar — een regio heeft een storing, een specifieke service is tijdelijk onbereikbaar. AI-model downtime kan globaal zijn, zonder geografische failovermogelijkheden, en treft alle gebruikers tegelijk.
De strategische keuze: drie modellen
Bij Universal.cloud voeren we regelmatig gesprekken met klanten over de juiste strategie. De discussie concentreert zich rond drie fundamentele benaderingen, elk met eigen voor- en nadelen.
1. Multi-provider met automatische failover
Dit is de benadering die wij bij Universal.cloud het vaakst adviseren voor bedrijfskritische toepassingen. Het principe is eenvoudig: je integreert meerdere LLM-providers in je applicatie en configureert automatische failover wanneer de primaire provider niet beschikbaar is.
Concreet betekent dit dat je applicatie bij een storing op bijvoorbeeld de Claude API automatisch overschakelt naar OpenAI's GPT-4, Google's Gemini, of een ander model. De technische implementatie vereist een abstractielaag die modelspecifieke API-calls vertaalt, maar de investering betaalt zich terug in beschikbaarheid.
- Voordelen — Hoogste beschikbaarheid door eliminatie van single point of failure. Geen eigen hardware nodig. Toegang tot de nieuwste modellen van elke provider. Kosten alleen voor daadwerkelijk gebruik.
- Nadelen — Hogere complexiteit in de applicatielaag. Subtiele verschillen in modelgedrag kunnen de gebruikerservaring beïnvloeden. Je bent afhankelijk van meerdere externe partijen. Mogelijk hogere kosten door het onderhouden van meerdere integraties.
- Geschikt voor — Organisaties die maximale beschikbaarheid vereisen zonder de investering in eigen infrastructuur. Toepassingen waar lichte variaties in modeloutput acceptabel zijn.
2. Self-hosting bij een grote cloudprovider
Een groeiend aantal organisaties overweegt om open-source modellen zoals Llama, Mistral of Qwen zelf te draaien op GPU-infrastructuur bij Amazon (AWS), Google Cloud of Microsoft Azure. Dit geeft meer controle over beschikbaarheid, maar introduceert nieuwe uitdagingen.
De grote cloudproviders bieden inmiddels gespecialiseerde GPU-instances (Azure NC-serie, AWS P5, Google A3) en managed inference-platforms (Azure AI Model Catalog, Amazon Bedrock, Google Vertex AI). Je kunt kiezen tussen volledig zelf beheren op bare-metal GPU's of gebruikmaken van gemanagede platforms die een deel van de operationele last wegnemen.
- Voordelen — Volledige controle over beschikbaarheid en schaalbaarheid. Data verlaat je eigen cloudomgeving niet. Voorspelbare kosten bij consistent gebruik. Mogelijkheid tot fine-tuning op eigen data. SLA van de cloudprovider geldt voor de onderliggende infrastructuur.
- Nadelen — Hoge initiële kosten voor GPU-infrastructuur (vaak €10.000+ per maand). Operationele complexiteit van modeldeployment en -beheer. Je bent verantwoordelijk voor updates, patching en optimalisatie. Open-source modellen presteren niet altijd op het niveau van frontier-modellen zoals Claude of GPT-4o.
- Geschikt voor — Organisaties met strikte dataresidentie-eisen, hoog en voorspelbaar gebruik, en de technische capaciteit om AI-infrastructuur te beheren. Denk aan financiële instellingen, zorgorganisaties en overheidsinstanties.
3. Self-hosting in een eigen datacenter
De meest vergaande optie is het draaien van modellen op eigen hardware in een eigen of gehuurd datacenter. Dit zien we vooral bij organisaties met extreme compliance-eisen of bij partijen die AI beschouwen als strategisch differentiator.
- Voordelen — Maximale controle over data en privacy. Geen afhankelijkheid van externe partijen. Potentieel lagere kosten bij zeer hoog volume op lange termijn. Volledige vrijheid in configuratie en optimalisatie.
- Nadelen — Enorme kapitaalinvestering in GPU-hardware (NVIDIA H100/H200 kaarten kosten €25.000–40.000 per stuk). Stroomverbruik en koeling zijn aanzienlijk. Je hebt gespecialiseerd personeel nodig voor beheer. Hardware veroudert snel in het huidige tempo van AI-ontwikkeling. De beschikbaarheid is volledig je eigen verantwoordelijkheid.
- Geschikt voor — Grote enterprises met dedicated AI-teams, organisaties in gereguleerde sectoren met strikte air-gapped vereisten, en bedrijven waar AI het kernproduct is.
Onze aanbeveling: de gelaagde aanpak
Bij Universal.cloud hanteren we voor onze eigen applicaties en voor het advies aan onze klanten een gelaagde strategie die we de "AI Resilience Stack" noemen:
- Multi-provider integratie — Integreer minimaal twee LLM-providers in je applicatiearchitectuur. Definieer een primair model en een of meer fallback-modellen. Test regelmatig of de failover daadwerkelijk werkt.
- Abstractielaag — Bouw een abstractielaag die modelspecifieke details verbergt voor de rest van je applicatie. Dit maakt het wisselen tussen providers triviaal en beschermt je tegen vendor lock-in.
- Monitoring en alerting — Monitor de beschikbaarheid van je LLM-endpoints net zo serieus als je database of webserver. Implementeer health checks, meet latency, en stel alerts in op degradatie.
- SLA-berekening — Neem AI-beschikbaarheid op in je SLA-berekeningen. De totale beschikbaarheid van je applicatie is het product van alle componenten. Een LLM-endpoint met 99,3% uptime drukt de beschikbaarheid van je hele keten.
- Graceful degradation — Ontwerp graceful degradation. Wat doet je applicatie als geen enkel AI-model beschikbaar is? De beste applicaties vallen terug op basisfunctionaliteit in plaats van volledig te stoppen.
De SLA-puzzel: reken het na
Een veelgemaakte fout is het negeren van de cumulatieve impact van meerdere afhankelijkheden op je totale SLA. De wiskunde is eenvoudig maar onverbiddelijk:
| Component | Uptime | Downtime/maand |
|---|---|---|
| Azure App Service | 99,95% | ~22 min |
| Azure SQL Database | 99,99% | ~4 min |
| Azure Networking | 99,99% | ~4 min |
| LLM API (enkel provider) | 99,30% | ~5 uur 6 min |
| Totaal (zonder AI) | 99,93% | ~30 min |
| Totaal (met AI) | 99,25% | ~5 uur 28 min |
Door een LLM-provider toe te voegen aan je keten zonder de beschikbaarheid mee te nemen, beloof je klanten een SLA die je niet kunt waarmaken. In het voorbeeld hierboven verlaagt de toevoeging van een enkel AI-model je beschikbaarheid van 99,95% naar 99,25% — een verviervoudiging van de verwachte downtime.
Met een multi-provider failover-strategie verbeter je dit drastisch. Als je twee onafhankelijke LLM-providers hebt met elk 99,3% uptime, is de kans dat beide tegelijk down zijn slechts 0,0049%, waardoor je effectieve AI-uptime stijgt naar 99,995%.
Conclusie: AI-uptime is geen bijzaak meer
We staan aan het begin van een tijdperk waarin AI een essentieel onderdeel wordt van het applicatielandschap. Net zoals we twintig jaar geleden leerden omgaan met de beschikbaarheid van cloudinfrastructuur, moeten we nu dezelfde discipline toepassen op AI-modellen.
De vraag is niet *óf* AI-modellen onbereikbaar zullen zijn — maar *wanneer*, en hoe goed je erop voorbereid bent. Organisaties die nu investeren in een robuuste AI-architectuur met multi-provider failover, adequate monitoring en realistische SLA-berekeningen, zullen een significant concurrentievoordeel hebben ten opzichte van partijen die AI behandelen als een simpele API-call die "wel altijd werkt".
Bij Universal.cloud helpen we organisaties met het ontwerpen en implementeren van AI-resilient architecturen. Of je nu een bestaande applicatie wilt versterken of een nieuw AI-gedreven platform bouwt — de beschikbaarheid van je AI-componenten verdient dezelfde aandacht als elke andere bedrijfskritische infrastructuur.
---
Wil je sparren over jouw AI-strategie? Neem contact op met Universal.cloud voor een vrijblijvend gesprek over hoe je AI-beschikbaarheid kunt integreren in je bestaande SLA-beleid en architectuur. Neem contact op.
