La chat riutilizza l'ID del documento già emesso

Un file di compliance non è finito quando la prosa è corretta. È finito quando, la settimana successiva, è lo stesso record: stesso ID, stessa posizione nel registro, solo un incremento di versione invece di una nuova identità. ISO/IEC 27001:2022 (pubblicato nell'ottobre 2022) si basa su informazioni documentate che possono essere identificate, revisionate e sostituite in modo intenzionale. Ecco perché una policy reca un numero di riferimento, non solo un titolo.

In passato, la chat di ISMS Copilot non rispettava questo principio. Generavi una policy di controllo degli accessi, che lasciava il workspace come POL-005, e la volta successiva che chiedevi una revisione in un altro thread, ne creava una nuova con ID POL-006. Le parole erano una riscrittura. L'identità era un nuovo documento. Il tuo registro, la tua SoA e il file che avevi già inviato per la revisione continuavano a puntare al vecchio ID. L'assistente aveva scritto un doppione.

Questo non è un fallimento di formulazione, ma di controllo dei documenti.

Cosa abbiamo rilasciato

In un workspace, la chat standard può ora riutilizzare un ID di documento già esistente invece di inventare il numero successivo nella sequenza.

Quando un file generato include un ID di documento (ad esempio POL-005, oppure una riga Document ID: / Dokument-ID:), le chat successive nello stesso workspace possono mantenerlo. L'elenco proviene dai documenti che hai già esportato nel workspace, incluse altre conversazioni. Non devi attivare nulla. Non esiste una modalità extra.

Questa funzionalità è attiva in Fast e Think. Non si applica a Beyond, a Agent Tasks o alla generazione tramite API / MCP. Se una bozza successiva dovesse comunque inventare un nuovo ID, specifica l'ID esistente nella richiesta. La pagina di aiuto riporta gli stessi limiti.

Questa novità si affianca a una correzione silenziosa di luglio: una volta generato un documento, le righe degli identificatori (ID documento, versione, classificazione, proprietario, approvatore, date) rimangono nel file Word, PDF e Markdown scaricato, invece di essere rimosse come se fossero metadati della pipeline. Mantenere l'ID durante l'esportazione era il primo passo. Far sì che la bozza successiva veda quell'ID è il secondo.

Prima e dopo

Prima, la chat poteva perdere traccia degli ID emessi in altre conversazioni e poteva inventare o continuare una sequenza diversa. POL-005 diventava POL-006, oppure ISMS-POL-004 se la richiesta utilizzava uno stile diverso. Dovevi accettare un crescente cumulo di doppioni, oppure incollare ogni volta l'ID corretto nella richiesta, o modificare manualmente l'intestazione dopo il download. Nessuna di queste opzioni è controllo dei documenti. Sono attività di pulizia.

Dopo, la chat nello stesso workspace può vedere gli ID che sono già stati esportati come file. Chiedi una revisione della policy di controllo degli accessi e la bozza può mantenere POL-005. La riga della versione può cambiare. L'identità no.

Non verrà inventato uno schema di numerazione per te, né verranno assegnati ID come policy. Se il file precedente non conteneva un ID di documento, non c'è nulla da riutilizzare. Se vuoi un nuovo record, chiedilo esplicitamente. Il cambiamento è che il comportamento predefinito non deve più essere "emetti il codice successivo".

Perché l'ID è il prodotto

I modelli di frontiera sono bravi a redigere una policy. Non sono bravi a ricordare che il file Word di martedì scorso è lo stesso record controllato della riscrittura di questa mattina. Quella memoria non è nel modello. È nel workspace: i file che hai già esportato, gli ID che quei file già contengono.

La scommessa è la stessa alla base dei citation a livello di punto e del trovare conversazioni passate. Per un lavoro di compliance serio, la mossa preziosa non è una risposta più lunga. È una risposta che rimane ancorata alla decisione che hai già preso. Una citazione che nomina il paragrafo. Un thread che puoi ritrovare. Un documento che mantiene il suo ID.

Senza questo, la chat produce file. Con questo, la chat può produrre la versione successiva di un documento.

A chi si rivolge

• Professionisti che mantengono un set di documenti ISMS, che già hanno ID in un registro e non possono permettersi una riscrittura che diventa silenziosamente una seconda policy.
• Consulenti che gestiscono un workspace per cliente, che generano un pacchetto in più conversazioni e hanno bisogno che la policy di controllo degli accessi rimanga POL-005 martedì dopo essere stata POL-005 lunedì.
• Chiunque revisioni un pacchetto generato rispetto a una Statement of Applicability o a un registro dei documenti, dove un ID cambiato sembra un nuovo documento controllato anche quando l'intento era una versione.

Se generi note usa e getta e non metti mai un ID su di esse, nulla di quanto sopra ti riguarderà. La pagina dimostra il suo valore quando l'intestazione è un elemento critico.

Provalo

Apri un workspace che contiene già documenti generati esportati con ID di documento. In modalità Fast o Think, chiedi una revisione di uno di quei documenti. La nuova bozza dovrebbe mantenere l'ID esistente. Se non lo fa, inserisci l'ID nella richiesta e genera nuovamente.

Una riscrittura che cambia l'identità non è una versione. È un nuovo documento che ora devi spiegare. La chat non dovrebbe farlo di default.