Enterprise
Een append-only audit trail voor AI-assisted development
Elke prompt, merge, deploy en admin-actie, append-only vastgelegd — zodat 'wie deed wat, en wie keurde het goed' een antwoord heeft dat je auditors kunnen lezen.
Ciao onderhoudt een append-only audit trail over prompts, merges, deploys en admin-acties. In tegenstelling tot ontwikkeltools die alleen commits loggen, legt de trail de nieuwe vraag van het AI-tijdperk vast — wat aan de AI werd gevraagd, wat daardoor veranderde, en welke mens het beoordeelde — met Guardrails die menselijke review vastlegt bij elke merge. De trail kan worden geëxporteerd voor auditreview en live worden gedemonstreerd tijdens evaluatie.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
'Wie deed wat' omvat nu ook de AI
Traditioneel wijzigingsbeheer audit drie artefacten: het ticket, de commit en de goedkeuring. AI-assisted development voegt een vierde toe die de meeste tooling negeert — de prompt. Wanneer een verzoek in gewone taal een productiewijziging kan opleveren, maakt het verzoek zelf deel uit van het wijzigingsrecord, en een audit trail die bij de commit begint, heeft het begin van het verhaal al gemist.
Ciao legt de hele reeks vast. Prompts zijn eersteklas gebeurtenissen; merges dragen het Guardrails-reviewrecord — welk beleid gold, welke mens beoordeelde, wat werd goedgekeurd; deploys en admin-acties maken het beeld compleet. De trail is append-only: items stapelen zich op, en de geschiedenis die je auditors lezen, is de geschiedenis die is gebeurd. Niets aan de reeks hoeft achteraf te worden gereconstrueerd uit chatexports of screenshots.
Voor een CISO zet dit een ongemakkelijke vraag — 'hoe beheersen jullie wat de AI verandert?' — om in een beoordeelbare: haal de trail op en lees precies wat werd gevraagd, wat veranderde, wie het goedkeurde en wanneer het live ging. Die ene mogelijkheid verschuift een AI-ontwikkelplatform vaak van de kolom 'uitzonderingen om uit te leggen' naar de kolom 'controls om naar te verwijzen' in een risicoreview, omdat weinig wijzigingsbeheerverhalen elders in het landschap zo vroeg beginnen als bij het verzoek zelf.
Wat wordt vastgelegd
Vier gebeurtenisklassen, één trail — in volgorde vastgelegd, niet achteraf samengesteld:
- Prompts — De verzoeken in gewone taal aan het platform — het echte begin van elke wijziging, vastgelegd in plaats van verloren in een chatvenster.
- Merges met reviewcontext — Guardrails koppelt code aan bedrijfsdomeinen, detecteert risicovolle wijzigingen, past plain-English-beleid toe en legt menselijke review vast — met een audit trail achter elke merge.
- Deploys — Wat live ging en wanneer, wat goedgekeurde wijzigingen verbindt met wat daadwerkelijk voor gebruikers draait.
- Admin-acties — Identiteits-, toegangs- en configuratiewijzigingen — inclusief provisioninggebeurtenissen van SSO en SCIM — zodat toegangsreviews en wijzigingsreviews op hetzelfde record putten.
- Append-only by design — De trail stapelt zich op; items worden niet ter plekke bewerkt. Wat reviewers lezen, is de reeks zoals die is gebeurd.
Exporteren en beoordelen
Bewijs dat je niet kunt extraheren, is bewijs dat je niet hebt. De trail kan worden geëxporteerd voor auditreview, zodat je team records naar zijn eigen werkdossiers en bewaarproces kan brengen in plaats van een leveranciers-UI te screenshotten. Vraag tijdens de evaluatie om twee dingen: een live doorloop waarbij je een echte wijziging kiest en end-to-end traceert, en een export van diezelfde reeks zodat je auditors het formaat zien waarmee ze daadwerkelijk zouden werken. Vraag ook wie exports mag uitvoeren en hoe exportgebeurtenissen zelf worden vastgelegd — een goed loggingverhaal omvat ook het toegangsverhaal van het log zelf.
Voor incidentrespons dient dezelfde trail een andere meester. Wanneer iets kapot gaat of er verkeerd uitziet, reconstrueren responders de reeks van prompt tot deploy zonder te wachten op iemands geheugen van wat er is gevraagd en goedgekeurd. Het bewijs dat een auditor tevreden stelt in de kwartaalreview, is het bewijs dat de incidenttijdlijn verkort in de slechte week.
Hoe een auditverzoek verloopt
Een concrete doorloop, waarbij de trail wordt gebruikt zoals je auditors dat zouden doen:
1. Bepaal de vraag
Een auditor vraagt naar een wijziging: wie initieerde het, wat raakte het, wie keurde het goed, wanneer bereikte het productie.
2. Haal de trail op
Lokaliseer de reeks — prompt, resulterende wijziging, Guardrails-beleid en reviewrecord, deploygebeurtenis.
3. Toon de review
Het mergerecord toont het plain-English-beleid dat gold en de menselijke review die Guardrails vastlegde, wat de goedkeuringsvraag direct beantwoordt.
4. Exporteer het bewijs
Exporteer de relevante records naar de werkdossiers van de audit, zodat de bevinding rust op records in plaats van herinnering.
5. Sluit de lus
Omdat admin-acties in dezelfde trail staan, worden vervolgvragen over wie op dat moment toegang had, beantwoord vanuit dezelfde bron.
Gebeurtenistypen en waarom reviewers erom geven
| Gebeurtenistype | Wat wordt vastgelegd | Waarom reviewers erom geven |
|---|---|---|
| Prompt | Het verzoek in gewone taal aan het platform | De echte oorsprong van een AI-assisted wijziging |
| Merge | Detectie van risicovolle wijzigingen, toegepast beleid, vastgelegde menselijke review | Goedkeuringsbewijs achter elke merge |
| Deploy | Wat live ging en wanneer | Verbindt goedkeuringen met productierealiteit |
| Admin-actie | Identiteits-, toegangs- en configuratiewijzigingen | Toegangsreviews en bewijs voor bevoegde wijzigingen |
Verificatienotities
De trail is een control die je kunt zien draaien: maak tijdens de evaluatie een wijziging via het platform en vind jezelf daarna terug in het log. Voor schriftelijk bewijs zijn SOC 2 Type II-rapporten beschikbaar onder NDA, en het security pack — op aanvraag via de contactpagina — dekt logging-architectuur en bewaarspecifieke details. Als je auditframework specifieke bewaar- of formaateisen heeft, leg die schriftelijk voor aan het enterprise-team tijdens inkoop.
Eén gewoonte die het waard is over te nemen van teams die goed auditen: kies elke maand één echte wijziging en traceer die end-to-end als oefening. Het houdt de auditspier warm, brengt hiaten aan het licht terwijl ze nog goedkoop te verhelpen zijn, en maakt van de jaarlijkse audit een herhaling van iets routinematigs in plaats van een haastklus.
Veelgestelde vragen
Kunnen auditlogitems worden bewerkt of verwijderd door een beheerder?
De trail is by design append-only — items stapelen zich op in plaats van ter plekke te worden bewerkt. Vraag voor het architecturale detail achter die eigenschap het security pack aan en, onder NDA, het SOC 2 Type II-rapport dat de relevante controls dekt.
Zijn AI-prompts echt onderdeel van het auditrecord?
Ja. De trail overspant prompts, merges, deploys en admin-acties, zodat het record van een wijziging begint bij het verzoek in plaats van bij de commit. Tijdens evaluatie kun je een prompt traceren tot aan de deploy.
Hoe lang worden auditrecords bewaard?
Bewaarspecifieke details horen schriftelijk vastgelegd, niet op een marketingpagina — ze staan in het security pack en kunnen in je overeenkomst worden opgenomen. Vermeld de bewaartermijn-eis van je framework tijdens inkoop en laat het antwoord documenteren.
Kunnen we de trail in onze SIEM- of GRC-tooling trekken?
De trail kan worden geëxporteerd voor auditreview. Opname in jouw specifieke SIEM- of GRC-stack is een integratievraag — beschrijf je pipeline aan het enterprise-team en bevestig de workflow tijdens evaluatie in plaats van het aan te nemen.
Wie kan de audit trail lezen?
Toegang tot de trail wordt geregeld door rolgebaseerde toegangscontrole, zodat auditzichtbaarheid een rol is die je workspace bewust toewijst. Toegangswijzigingen zijn zelf admin-acties — vastgelegd in dezelfde trail waartoe ze toegang verlenen.