> Bron: https://neuralex.nl/blog/backups-voor-ai-systemen > Een bruikbare back-up van een AI-systeem bevat meer dan documenten en databases. Ook modellen, prompts, indexconfiguratie, agentrechten, evaluaties en herstelprocedures bepalen of je het systeem werkelijk kunt terugbrengen. [Terug naar kennisbank](/blog) Infrastructuur ·6 oktober 2026 ·6 min lezen # Backups voor AI-systemen: wat bewaar je behalve de data? Een bruikbare back-up van een AI-systeem bevat meer dan documenten en databases. Ook modellen, prompts, indexconfiguratie, agentrechten, evaluaties en herstelprocedures bepalen of je het systeem werkelijk kunt terugbrengen. Voor een AI-systeem moet je behalve de oorspronkelijke data ook alles bewaren wat nodig is om van die data weer hetzelfde werkende systeem te maken. Denk aan configuraties voor chunking en indexering, gebruikte embeddingmodellen, prompts en systeeminstructies, modelversies, toolconfiguraties, agentrechten, evaluatiesets en relevante auditinformatie. Een back-up van alleen documenten en databases beschermt de inhoud, maar niet noodzakelijk de werking van het AI-systeem. Het belangrijkste criterium is daarom niet: wat staat er op de server? De betere vraag is: welke onderdelen heb je nodig om het systeem na verlies, corruptie of een foutieve wijziging opnieuw betrouwbaar op te bouwen? Sommige onderdelen wil je letterlijk kunnen terugzetten. Andere, zoals een vectorindex, kun je soms beter opnieuw genereren uit gecontroleerde brondata en vastgelegde configuratie. ## Bewaar de onderdelen die het gedrag bepalen Bij klassieke applicaties ligt de nadruk van back-ups vaak op bestanden, databases en applicatieconfiguratie. Bij AI-systemen komen daar componenten bij die direct invloed hebben op wat het systeem terugvindt, genereert of uitvoert. Bij een RAG-systeem zijn bijvoorbeeld niet alleen de brondocumenten belangrijk. Je moet ook weten met welk embeddingmodel de vectorrepresentaties zijn gemaakt, welke versie daarvan is gebruikt, hoe documenten zijn opgesplitst en welke metadata of filters tijdens het indexeren zijn toegepast. Zonder die informatie kun je dezelfde kennisbank mogelijk niet reproduceerbaar herstellen. Bewaar daarom minimaal de gebruikte embeddingmodel- en versiegegevens, de chunkingconfiguratie, indexeerregels en relevante instellingen voor retrieval. Gebruik je een extern embeddingmodel dat niet zelf wordt opgeslagen, leg dan ten minste de exacte modelreferentie en configuratie vast. Bij lokale modellen kunnen modelgewichten onderdeel zijn van je herstelstrategie, zeker wanneer je niet kunt garanderen dat dezelfde versie later nog beschikbaar is. De hardware waarop lokale modellen moeten draaien kan eveneens invloed hebben op je herstelplan; zie ook [hardware voor lokale AI](/blog/hardware-voor-lokale-ai). ## Een vectorindex is niet altijd iets dat je wilt terugzetten Een vectorindex kan groot zijn en bevat doorgaans afgeleide informatie uit je brondata. Daardoor is het niet vanzelfsprekend dat iedere index als volledige back-up moet worden bewaard. Als je de originele documenten, het embeddingmodel, de chunkingregels en de indexeerconfiguratie hebt, kun je de index in veel gevallen opnieuw opbouwen. Herbouwen kan zelfs wenselijker zijn dan een oude index terugzetten. Een index kan beschadigd zijn, gedeeltelijk bijgewerkt zijn of gegevens bevatten die inmiddels uit de bron zijn verwijderd. Door opnieuw te indexeren vanuit een gecontroleerde dataset voorkom je dat zulke inconsistenties automatisch terugkomen. Daar staat tegenover dat opnieuw indexeren tijd, rekenkracht en eventueel API-kosten vraagt. Voor grote systemen kan het daarom zinvol zijn om zowel herstel vanuit een bestaande index als volledige herbouw te ondersteunen. Zulke herstelkosten horen bij de bredere operationele kosten van AI; zie [wat AI echt kost](/blog/wat-kost-ai-echt). ## Versiebeheer prompts, instructies en configuratie Prompts zijn onderdeel van de softwareconfiguratie van een AI-systeem. Een kleine verandering in een systeemprompt, toolbeschrijving of retrieval-instructie kan het gedrag merkbaar veranderen. Bewaar prompts daarom niet alleen als losse tekstbestanden, maar zet ze onder versiebeheer samen met de configuratie waarmee ze worden gebruikt. Hetzelfde geldt voor modelinstellingen, routeringsregels, fallback-logica, outputschema's en parameters die bepalen welke tools een model mag aanroepen. Bij agents moet je daarnaast vastleggen welke rechten de agent had, welke systemen bereikbaar waren en onder welke voorwaarden menselijke goedkeuring nodig was. Een herstel waarbij de documenten correct zijn teruggezet maar de agent ineens andere rechten krijgt, is geen betrouwbaar herstel. Dit geldt ook voor ketens waarin meerdere modellen of diensten elkaar kunnen vervangen. Meer daarover staat bij [fallback-ketens voor AI-systemen](/blog/fallback-ketens). ## Bewaar evaluaties, logs en goedkeuringsregistraties bewust Een hersteld AI-systeem moet niet alleen starten; je wilt ook kunnen controleren of het zich nog gedraagt zoals vóór het incident. Daarom zijn evaluatiesets waardevol in een back-up- en herstelstrategie. Met een vaste verzameling vragen, documenten en verwachte eigenschappen kun je na herstel controleren of retrieval, antwoorden en agentgedrag nog binnen de afgesproken grenzen vallen. Logs zijn eveneens belangrijk, maar niet iedere log hoeft onbeperkt te worden bewaard. Operationele logs, foutmeldingen, model- en toolcalls en goedkeuringsregistraties kunnen nodig zijn voor analyse, audit en incidentonderzoek. Welke logs noodzakelijk zijn en hoelang je ze bewaart, hangt af van je systeem en organisatie. Zie ook [AI-monitoring](/blog/ai-monitoring) voor de rol van logging en observability in productie. Geheimen zoals API-sleutels, wachtwoorden en tokens horen niet als gewone configuratiebestanden in een back-up. Bewaar ze in een daarvoor bedoelde secrets-kluis of sleutelbeheeromgeving en zorg dat ook het herstelproces daarvan is geregeld. De back-up moet duidelijk maken welke geheimen nodig zijn, zonder die geheimen onnodig te kopiëren naar meerdere opslaglocaties. ## Een back-up is pas bruikbaar als je hem kunt herstellen De bekende 3-2-1-gedachte blijft ook bij AI-systemen bruikbaar: houd meerdere kopieën, gebruik meer dan één opslagvorm of opslagomgeving en zorg dat minstens één kopie voldoende geïsoleerd is van het primaire systeem. Het exacte ontwerp hangt af van je infrastructuur en risicoprofiel; de gedachte is vooral dat één back-upbestand op hetzelfde platform geen robuuste herstelstrategie vormt. Belangrijker nog is het verschil tussen een gemaakte back-up en een herstelbare back-up. Je weet pas of een back-up bruikbaar is wanneer je het herstel daadwerkelijk test. Dat betekent bijvoorbeeld een schone omgeving opbouwen, data terugzetten of opnieuw indexeren, configuraties laden, secrets opnieuw verbinden en daarna functionele evaluaties uitvoeren. Neem ook externe afhankelijkheden mee. Een modelnaam in een configuratiebestand helpt weinig wanneer die modelversie bij herstel niet meer beschikbaar is. Controleer daarom periodiek of de verwijzingen en installatiebronnen waarop je herstelproces steunt nog bestaan. ## Bewaartermijnen gelden ook voor back-ups Back-ups zijn geen vrijplaats voor onbeperkte opslag. Als er persoonsgegevens in documenten, databases, logs of evaluatiesets staan, blijven privacyverplichtingen relevant. Onder de AVG moet je onder meer kunnen uitleggen waarom persoonsgegevens worden bewaard en hoe lang dat nodig is. Meer hierover staat in [AI en de AVG](/blog/ai-en-de-avg). Dat betekent niet dat ieder verwijderd persoonsgegeven onmiddellijk uit iedere historische back-up technisch gewist moet kunnen worden. De inrichting hangt af van de gekozen back-upstrategie, bewaartermijnen en toegangsmaatregelen. Wel moet duidelijk zijn wat er in back-ups staat, hoe lang kopieën blijven bestaan en wat er gebeurt wanneer een oude back-up wordt teruggezet. Laat privacygevoelige herstelprocessen waar nodig juridisch toetsen. ## Korte checklist voor AI-back-ups - **Brondata:** documenten, databases, metadata en andere primaire gegevens. - **Vectorlaag:** vectorindex of een aantoonbaar reproduceerbare methode om die opnieuw op te bouwen. - **Embeddings:** embeddingmodel, versie en relevante instellingen. - **Indexering:** chunkingregels, parsers, metadataregels, filters en indexeerconfiguratie. - **Modellen:** lokale modelgewichten of exacte verwijzingen naar gebruikte modelversies. - **Prompts:** systeemprompts, templates, toolinstructies en andere gedragsbepalende configuratie onder versiebeheer. - **Agents:** toolconfiguraties, rechten, goedkeuringsregels en toegangsbeleid. - **Evaluatie:** testsets en evaluatieconfiguraties waarmee je na herstel controleert of het systeem nog correct werkt. - **Auditinformatie:** noodzakelijke logs, foutinformatie en registraties van menselijke goedkeuringen. - **Geheimen:** API-sleutels en wachtwoorden via een afzonderlijke secrets-kluis, inclusief een getest herstelproces. - **Hersteltest:** voer regelmatig een volledige herstelprocedure uit in plaats van alleen te controleren of back-upbestanden bestaan. Betrouwbare AI-infrastructuur ## Kun je jouw AI-systeem morgen volledig herstellen? Wij ontwerpen back-ups die meer omvatten dan data: index, configuratie, prompts en rechten — en we testen het herstel. Benieuwd wat dat voor jouw situatie betekent? [Stel je vraag](/contact) [Lees wat AI echt kost](/blog/wat-kost-ai-echt) --- Volledige (opgemaakte) versie: https://neuralex.nl/blog/backups-voor-ai-systemen