Enterprise
Un registro di controllo append-only per lo sviluppo assistito da AI
Ogni prompt, merge, deploy e azione amministrativa, registrati in modo append-only — così 'chi ha fatto cosa, e chi lo ha approvato' ha una risposta che i tuoi auditor possono leggere.
Ciao mantiene un registro di controllo append-only su prompt, merge, deploy e azioni amministrative. A differenza degli strumenti di sviluppo che registrano solo i commit, il registro cattura la nuova domanda dell'era AI — cosa è stato chiesto all'AI, cosa è cambiato di conseguenza, e quale umano l'ha revisionato — con Guardrails che registra la revisione umana dietro ogni merge. Il registro può essere esportato per la revisione di audit e dimostrato dal vivo durante la valutazione.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
'Chi ha fatto cosa' ora include l'AI
La gestione tradizionale dei cambiamenti verifica tre artefatti: il ticket, il commit e l'approvazione. Lo sviluppo assistito da AI ne aggiunge un quarto che la maggior parte degli strumenti ignora — il prompt. Quando una richiesta in linguaggio semplice può produrre una modifica di produzione, la richiesta stessa fa parte del registro della modifica, e un registro di controllo che inizia al commit ha già perso l'inizio della storia.
Ciao registra l'intera sequenza. I prompt sono eventi di prima classe; i merge portano il registro di revisione Guardrails — quale policy si è applicata, quale umano ha revisionato, cosa è stato approvato; i deploy e le azioni amministrative completano il quadro. Il registro è append-only: le voci si accumulano, e la storia che i tuoi auditor leggono è la storia che è successa. Niente della sequenza deve essere ricostruito da esportazioni di chat o screenshot a posteriori.
Per un CISO, questo converte una domanda scomoda — 'come controllate cosa cambia l'AI?' — in una revisionabile: estrai il registro e leggi esattamente cosa è stato richiesto, cosa è cambiato, chi lo ha approvato e quando è stato rilasciato. Questa singola capacità tende a spostare una piattaforma di sviluppo AI dalla colonna 'eccezioni da spiegare' di una revisione del rischio alla colonna 'controlli da citare', perché poche storie di gestione dei cambiamenti nel resto del patrimonio iniziano presto quanto la richiesta stessa.
Cosa viene registrato
Quattro classi di eventi, un unico registro — registrati in sequenza, non assemblati a posteriori:
- Prompt — Le richieste in linguaggio semplice fatte alla piattaforma — il vero inizio di ogni modifica, catturato invece di perso in una finestra di chat.
- Merge con contesto di revisione — Guardrails mappa il codice in aree di business, rileva le modifiche rischiose, applica policy in linguaggio semplice e registra la revisione umana — lasciando un registro di controllo dietro ogni merge.
- Deploy — Cosa è stato rilasciato e quando, collegando le modifiche approvate a ciò che gira realmente davanti agli utenti.
- Azioni amministrative — Modifiche a identità, accesso e configurazione — inclusi eventi di provisioning da SSO e SCIM — così le revisioni degli accessi e delle modifiche attingono allo stesso registro.
- Append-only per progettazione — Il registro si accumula; le voci non vengono modificate sul posto. Ciò che i revisori leggono è la sequenza così com'è avvenuta.
Esportazione e revisione
Le prove che non puoi estrarre sono prove che non hai. Il registro può essere esportato per la revisione di audit, così il tuo team può portare i record nelle proprie carte di lavoro e nel processo di conservazione invece di fare screenshot di un'interfaccia del fornitore. Durante la valutazione, chiedi due cose: una dimostrazione dal vivo dove scegli una modifica reale e la tracci end-to-end, e un'esportazione di quella stessa sequenza così i tuoi auditor vedono il formato con cui lavorerebbero realmente. Chiedi anche chi può eseguire le esportazioni e come vengono registrati gli eventi di esportazione stessi — una buona storia di logging include la storia dell'accesso al log stesso.
Per la risposta agli incidenti, lo stesso registro serve un padrone diverso. Quando qualcosa si rompe o sembra sbagliato, i responder ricostruiscono la sequenza dal prompt al deploy senza aspettare la memoria di nessuno su cosa è stato chiesto e approvato. Le prove che soddisfano un auditor nella revisione trimestrale sono le prove che accorciano la tempistica di un incidente nella brutta settimana.
Come si svolge una richiesta di audit
Una dimostrazione concreta, usando il registro nel modo in cui lo userebbero i tuoi auditor:
1. Delimita la domanda
Un auditor chiede di una modifica: chi l'ha avviata, cosa ha toccato, chi l'ha approvata, quando ha raggiunto la produzione.
2. Estrai il registro
Individua la sequenza — prompt, modifica risultante, policy Guardrails e registro di revisione, evento di deploy.
3. Mostra la revisione
Il registro del merge mostra la policy in linguaggio semplice che si è applicata e la revisione umana che Guardrails ha registrato, rispondendo direttamente alla domanda sull'approvazione.
4. Esporta le prove
Esporta i registri rilevanti nelle carte di lavoro dell'audit, così il rilievo poggia su registri piuttosto che su ricordi.
5. Chiudi il cerchio
Poiché le azioni amministrative sono nello stesso registro, le domande di follow-up su chi aveva accesso in quel momento vengono risposte dalla stessa fonte.
Tipi di eventi e perché contano ai revisori
| Tipo di evento | Cosa viene registrato | Perché conta ai revisori |
|---|---|---|
| Prompt | La richiesta in linguaggio semplice fatta alla piattaforma | La vera origine di una modifica assistita da AI |
| Merge | Rilevamento delle modifiche rischiose, policy applicata, revisione umana registrata | Prove di approvazione dietro ogni merge |
| Deploy | Cosa è stato rilasciato e quando | Collega le approvazioni alla realtà della produzione |
| Azione amministrativa | Modifiche a identità, accesso e configurazione | Revisioni degli accessi e prove di modifiche privilegiate |
Note di verifica
Il registro è un controllo che puoi vedere operare: durante la valutazione, fai una modifica tramite la piattaforma e poi trovati nel log. Per le prove scritte, i report SOC 2 Type II sono disponibili sotto NDA, e il security pack — su richiesta tramite la pagina dei contatti — copre l'architettura di logging e le specifiche di conservazione. Se il tuo framework di audit ha requisiti particolari di conservazione o formato, mettili per iscritto al team enterprise durante il procurement.
Un'abitudine che vale la pena adottare dai team che fanno audit bene: scegli una modifica reale al mese e tracciala end-to-end come esercitazione. Mantiene allenato il muscolo dell'audit, fa emergere le lacune mentre sono economiche da correggere, e trasforma l'audit annuale nella ripetizione di qualcosa di routine piuttosto che una corsa contro il tempo.
Domande frequenti
Le voci del registro di audit possono essere modificate o eliminate da un amministratore?
Il registro è append-only per progettazione — le voci si accumulano invece di essere modificate sul posto. Per il dettaglio architetturale dietro quella proprietà, richiedi il security pack e, sotto NDA, il report SOC 2 Type II che copre i controlli rilevanti.
I prompt AI fanno davvero parte del registro di audit?
Sì. Il registro copre prompt, merge, deploy e azioni amministrative, così il registro di una modifica inizia alla richiesta piuttosto che al commit. Durante la valutazione puoi tracciare un prompt fino al suo deploy.
Per quanto tempo vengono conservati i registri di audit?
Le specifiche di conservazione appartengono per iscritto, non a una pagina di marketing — sono coperte nel security pack e possono essere affrontate nel tuo accordo. Dichiara il requisito di conservazione del tuo framework durante il procurement e ottieni la risposta documentata.
Possiamo estrarre il registro nel nostro SIEM o strumento GRC?
Il registro può essere esportato per la revisione di audit. L'ingestione nel tuo specifico stack SIEM o GRC è una domanda di integrazione — descrivi la tua pipeline al team enterprise e conferma il workflow durante la valutazione invece di presumerlo.
Chi può leggere il registro di controllo?
L'accesso al registro è governato dal controllo degli accessi basato sui ruoli, così la visibilità dell'audit è un ruolo che il tuo workspace assegna deliberatamente. Le modifiche di accesso sono esse stesse azioni amministrative — registrate nello stesso registro a cui concedono l'accesso.