Summary

  • La eliminación de un diálogo protege el dato sensible, pero puede llevarse también la reclamación, desplazar índices y romper referencias. Una carcasa conserva tiempo y participantes, no necesariamente el sentido.
  • VCON ya puede enlazar el derivado con un antecesor, exigir el hash de contenido referenciado y firmar el resultado. Eso acredita bytes y autor, no la exhaustividad del borrado ni la verdad de un sustituto.
  • Esta nota propone un recibo de transformación con localizadores, operaciones y límites de uso. Es análisis operativo, no un requisito ya normalizado por draft-rosenberg-vcon-redaction-00.

La unidad de privacidad no coincide con la unidad de sentido

Una persona explica que un cargo fue duplicado y, en la misma intervención, dicta su número de cuenta. Si el sistema retira todo el objeto de diálogo, el identificador deja de estar expuesto. También desaparecen la acusación de duplicidad, el momento en que se formuló y quizá la prueba de que el agente la oyó.

Este desacoplamiento es el problema más útil que plantea draft-rosenberg-vcon-redaction-00. Se publicó el 29 de septiembre de 2026 como Internet-Draft individual con intención Informational. Es material de discusión sobre casos y requisitos: no es RFC, no ha sido adoptado por el grupo de trabajo VCON, no expresa consenso del IETF y no demuestra que exista un despliegue.

El texto separa dimensiones que una etiqueta genérica de “redactado” oculta. ¿Se avisa a la máquina de que hubo modificación? ¿Permanece la posición temporal o textual? ¿Se identifica al participante afectado? ¿La intervención resulta detectable para una persona o un modelo? ¿Se quitó el dato o se mantuvo etiquetado para que otro control decidiera quién puede verlo?

La respuesta cambia el valor probatorio. Un hueco puede revelar que el testigo habló. La ausencia total puede ocultar que existió una reclamación. Un reemplazo natural puede hacer que un dato inventado parezca observado.

La línea de procedencia que ofrece el núcleo

La revisión 04 del núcleo VCON define un objeto redacted que debería señalar por UUID una versión no redactada o menos redactada. Puede añadir una URL restringida y su hash; la URL obliga a incluir ese compromiso. La entidad que crea el derivado debería firmarlo. Si se elimina por completo un elemento de un array, se recomienda dejar un elemento vacío para que los índices posteriores no cambien.

Cada mecanismo sirve para algo. El UUID permite localizar la relación entre versiones. El hash detecta una variación en el contenido externo. La firma identifica al emisor de la afirmación. El hueco conserva direcciones internas.

Pero el núcleo deja fuera de alcance los métodos para texto, audio y vídeo. No declara qué fragmento se encontró, con qué detector, qué semántica tenía o qué puede hacer un receptor con la versión resultante. Una firma JWS válida vincula al firmante con unos bytes; no convierte un falso número de cuenta en palabras del cliente. Tampoco prueba que el sistema descubrió todas las instancias del dato sensible.

En términos de Lu Heng, el original, la vista de privacidad y la acción posterior pertenecen a capas de realidad distintas. El vínculo entre ellas debe ser explícito. La autoridad de una observación no debe pasar por ósmosis a una representación transformada.

Lo que conserva cada operación

La eliminación total ofrece una frontera clara de divulgación, pero el precio puede ser desproporcionado: desaparece todo el turno, se alteran posiciones y una referencia puede apuntar al objeto equivocado si no se repara. Para un auditor, una conversación más corta no explica qué falta.

La carcasa de diálogo retiene metadatos como participantes, inicio y duración, y mantiene el índice. Da fe de que hubo actividad. Sin embargo, no distingue si se eliminó una sola cifra o toda una explicación, y puede revelar precisamente la posición o el participante que había que proteger.

La sustitución visible con XXX o REDACTED comunica intención a muchos lectores, pero sigue siendo texto corriente. Quizá el interlocutor dijo esas letras. El convenio cambia de idioma. Ningún consumidor debería deducir de ese token la ubicación exacta ni la clase del dato.

La sustitución plausible protege mejor contra la detección casual. También inventa una afirmación con aspecto normal. El ejemplo del borrador es un número de cuenta dentro de una conversación de reembolso: el siguiente agente podría devolver dinero a la cuenta falsa. Lo que se ganó en discreción se perdió en seguridad operativa.

El etiquetado conserva el original y delega su ocultación en el destinatario. Es útil cuando receptores autorizados necesitan el dato, pero falla en cuanto un visor, una exportación o un modelo ignora la etiqueta. No hay una técnica universal; hay consecuencias diferentes que deben viajar con el derivado.

Del historial de versiones al recibo de transformación

Una referencia al antecesor no basta para un uso con consecuencias. Esta nota propone—sin atribuirlo como texto normativo a la revisión 00—un recibo firmado que comprometa la identidad y el hash de la fuente y del derivado; la versión y finalidad de la política; los localizadores exactos; la clase semántica previa; y la operación aplicada en cada lugar.

El recibo debe declarar si preserva o suprime posición y participante, quién realizó el proceso, cuándo y bajo qué alcance de clave. Debe incluir el resultado de validar cada localizador y contar como fallo cerrado cualquiera que no resuelva. Finalmente, debe imponer límites al consumidor: un valor plausiblemente sustituido no autoriza pagos, cambios de credenciales, atribuciones jurídicas ni entrenamiento sin distinción de procedencia.

JSON Pointer de RFC 6901 puede nombrar una posición, pero deja al programa la respuesta ante errores. Una ruta que dejó de apuntar por un cambio de índice rompe el recibo. JWS de RFC 7515 aporta integridad y autoría criptográfica. RFC 8785 hace repetible la canonicalización de JSON. Ninguna de esas piezas demuestra cobertura semántica; esa prueba exige evaluación del detector, muestras controladas y coherencia entre modalidades.

La conversación verificable de agentes aumenta la urgencia. Los registros pueden incluir prompts, entradas y salidas de herramientas, credenciales, ficheros y órdenes ejecutables. Su borrador compañero advierte que una firma identifica al firmante, no garantiza la veracidad. También separa los límites de confianza del runtime, el registrador, el almacén, el verificador y quien decide.

Por eso una acción posterior merece su propio recibo. El responsable del reembolso debe registrar el compromiso del derivado, el recibo de transformación, la política local y el efecto. Sólo así se puede reconstruir si el error vino de la fuente, del transformador, del consumidor o de la ejecución.

Fuentes y límites

La revisión 00 es una propuesta temprana e incompleta; no define todavía un perfil interoperable acabado. Esta investigación no evalúa proveedores, centros de contacto ni implementaciones concretas. Tampoco afirma que una técnica cumpla por sí sola la legislación. El artículo 5 del RGPD y NIST SP 800-122 ayudan a relacionar minimización, exactitud y salvaguardas, pero no homologan el recibo aquí propuesto.