Una hija escribe a la funeraria que atendió el servicio de su padre. Ya pagó todo, no quiere recibir más mensajes y pide que borren sus datos. Alguien de atención al cliente busca su ficha, la elimina y el sistema responde lo que se espera: eliminado. Se cierra la solicitud.
Tres meses después, la misma hija recibe un mensaje de cobranza de un plan de previsión que nunca contrató, generado desde un correo que seguía en el sistema. O pide acceso a sus datos y la respuesta trae sus conversaciones con el asistente de WhatsApp. En ninguno de los dos casos alguien mintió. El botón hizo lo que hace. El problema es que eliminar un registro y suprimir los datos de una persona son dos operaciones distintas, y casi ningún ERP del mercado las distingue en la pantalla.
Este artículo trata ese hueco en un grupo funerario, que maneja datos personales de los momentos más sensibles de una familia: causa de muerte, parentesco, situación económica, creencias. Complementa la guía de la Ley 21.719 para funerarias en Chile y la nota sobre datos sensibles y la LFPDPPP en México, que explican qué exige la ley. Aquí miramos lo que pasa dentro del sistema cuando alguien intenta cumplirla, y qué papel juega la inteligencia artificial: la que ayuda y la que complica.
1. El problema de negocio: todos creen que borrar es suprimir
La confusión no es una rareza del sector funerario. En 2025, las autoridades de protección de datos del Espacio Económico Europeo hicieron su revisión coordinada anual sobre un solo derecho: el de supresión. Participaron 32 autoridades y respondieron 764 organizaciones. El informe, adoptado por el Comité Europeo de Protección de Datos (EDPB) en febrero de 2026, describe fallos que cualquier director de un grupo funerario va a reconocer:
- No tener un procedimiento interno escrito, o tenerlo incompleto o sin revisar. Diecisiete autoridades lo señalaron, y el informe subraya que confirma lo encontrado el año anterior sobre el derecho de acceso.
- Excluir las copias de respaldo por defecto. Muchas organizaciones lo hacían, y la mitad de las autoridades que respondieron expresó preocupación por cómo se borra en los respaldos: confiar solo en que «algún día expiran» hace difícil demostrar que se borró sin demora.
- Llamar anonimización a lo que es seudonimización: aplicar un enmascaramiento parcial y dejar a la persona identificable por el resto de los datos.
- Confundir cerrar la cuenta con borrar el dato, un fallo que reportaron algunas autoridades: se desactiva al cliente y se da por cumplida la solicitud.
- Y un caso que vale la pena citar aunque fue aislado: una organización sostuvo que los datos contenidos en correos electrónicos quedaban fuera de la solicitud.
En Latinoamérica el derecho existe con distintos nombres: supresión en Chile, Colombia y Perú, cancelación dentro de los derechos ARCO en México. Y en todos los casos convive con la misma excepción: no procede borrar lo que hay que conservar por ley o por contrato. En México, la LFPDPPP de 2025 dice que la cancelación da lugar primero a un periodo de bloqueo y después a la supresión (art. 24) y enumera cuándo no procede (art. 25). En Colombia, la Ley 1581 de 2012 reconoce el derecho a pedir la supresión (art. 8, literal e) y el Decreto 1377 de 2013 lo limita cuando existe un deber legal o contractual de permanecer en la base de datos (art. 9). Y el calendario aprieta. En Chile, la Ley 21.719 entra en vigencia el 1 de diciembre de 2026, con 30 días corridos para responder una solicitud. El gobierno ingresó un proyecto para postergarla un año, pero mientras no se publique como ley la fecha vigente sigue siendo diciembre de 2026.
¿Por qué pega más fuerte en una funeraria? Por tres rasgos. Los datos son sensibles por naturaleza: causa de muerte, parentesco, creencias religiosas y, en muchos países, la situación socioeconómica. El titular muchas veces no es quien contrató: la ley chilena, por ejemplo, permite a los herederos pedir la supresión de los datos del fallecido. Y no todo se puede borrar: la factura, el contrato de previsión y los registros sanitarios del servicio tienen deberes de conservación. Por eso la respuesta correcta muchas veces no es borrar, sino bloquear el tratamiento y conservar solo lo que la ley obliga, como explicamos en la guía chilena.
2. Qué hace de verdad cada botón: borrar esconde, suprimir es otra cosa
Antes de hablar de IA conviene ver con precisión qué hace el sistema. Revisamos el código de SFUN, que se construye sobre el framework Frappe y ERPNext, y publicamos lo que encontramos. Es el comportamiento de fábrica del framework y es razonable: está diseñado para que un error de borrado se pueda deshacer. Justamente por eso no sirve, tal cual, para suprimir.
| Lo que hace el usuario | Lo que pasa en el sistema | Dónde sigue el dato |
|---|---|---|
| Borra el registro (una ficha, un contacto, un contrato en borrador) | El registro desaparece de las listas. Antes, el sistema guarda una copia completa en la papelera de documentos borrados para poder restaurarlo. También elimina el historial de versiones y los comentarios de ese registro | Primera copia: la papelera. El framework trae una rutina para vaciarla a los 180 días, pero no viene activada en la configuración de purga de registros: si nadie la agrega, la copia queda indefinidamente. Nuestras propias rutinas de depuración la usan a propósito como respaldo restaurable |
| Anonimiza campos (cambia el nombre y el teléfono de un contrato que hay que conservar) | El registro sigue, con los datos nuevos. En los documentos con seguimiento de cambios, el sistema guarda una versión con el valor anterior y el nuevo | Segunda copia: el historial de versiones, con el nombre y el teléfono originales, visible para quien tenga permiso sobre el documento |
| Borra el registro que tenía correos asociados | Los correos no se eliminan: el sistema solo les quita el enlace al registro borrado | Tercera copia: los correos completos, ahora más difíciles de encontrar porque ya no cuelgan de ninguna ficha |
| No hace nada con el canal de atención | Los mensajes de WhatsApp, las transcripciones de llamadas y el rastro de ejecución del asistente se guardan en registros propios del módulo de conversaciones, con su propio historial de cambios | También tercera copia: no hay purga automática de conversaciones ni borrado por contacto. Lo que la familia le contó al asistente sigue ahí |
| Usa la solicitud de supresión del framework | El framework trae un flujo de supresión y descarga de datos personales, pero cada aplicación debe declarar qué campos personales le corresponden | Las aplicaciones de negocio no lo han declarado, así que hoy ese flujo no alcanza a los datos funerarios. Lo contamos en la nota de México |
Queda un cuarto lugar que no depende del código sino de la instalación: las copias de respaldo de la base de datos. Cuántas hay, dónde y por cuánto tiempo se decide en cada infraestructura, y desde el código no se puede ver. Es la primera pregunta que hay que hacerle al área de tecnología o al proveedor, porque el procedimiento de supresión tiene que decir qué pasa con ellas, aunque la respuesta sea «se sobrescriben en N días y no se restauran datos suprimidos».
3. La copia que trae la IA: el índice vectorial
Hay un lugar más donde los datos personales sobreviven, y es nuevo: los índices vectoriales. Muchos asistentes de IA convierten documentos y conversaciones en vectores numéricos para encontrar después lo más parecido a una pregunta. Es la técnica detrás de la mayoría de los chatbots «entrenados con tus datos».
No es una suposición: la documentación de los propios fabricantes lo dice. Qdrant explica que un registro borrado «no se elimina de inmediato, sino que se marca como borrado» hasta que un proceso de limpieza lo retira. Weaviate aclara que, antes de esa limpieza, los objetos marcados siguen conectados al grafo del índice. Es un diseño razonable para que las búsquedas sean rápidas. Pero significa que entre el borrado y la limpieza, y en toda copia de respaldo tomada en ese intervalo, el vector sigue ahí.
Un trabajo publicado en junio de 2026, Ghost Vectors, midió qué se puede reconstruir de esos vectores borrados en índices organizados como grafo (HNSW), usando ChromaDB y FAISS. Con acceso directo al almacenamiento y conociendo el modelo que generó los vectores, los autores recuperaron 25,5 % de los nombres exactos y 46,4 % de las ubicaciones de un conjunto de biografías, y la edad y el género de todos los pacientes de un conjunto de historias clínicas sintéticas. Y comprobaron que una copia de respaldo tomada después del borrado permite la misma reconstrucción.
Aquí conviene ser concretos con SFUN. El único índice vectorial que usa SFUN MCP sirve para que el agente encuentre la herramienta correcta: contiene las descripciones de los módulos y funciones del ERP, no datos de personas. Cuando algo sale del catálogo, se borra físicamente en el siguiente despliegue. Los datos de negocio siguen en la base del ERP, con sus permisos. Es una decisión de diseño que resumimos así: no indexes lo que algún día vas a tener que borrar. Si tu proveedor de chatbot sí indexa conversaciones, pregúntale cómo borra de ese índice y en cuánto tiempo.
4. Qué datos del ERP intervienen
Este caso no necesita datos nuevos. Necesita encontrar a una persona en todos los lugares donde ya está:
| Dato | Dónde vive | Para qué sirve en el caso |
|---|---|---|
| Documento de identidad, teléfono y correo del titular | Clientes, contactos, afiliados y beneficiarios de previsión | Las llaves para buscar a la persona en el resto del sistema |
| Contratos, servicios y facturas donde aparece | Previsión, servicios funerarios y contabilidad | Separar lo que se puede borrar de lo que hay que conservar y bloquear |
| Correos enviados y recibidos | Comunicaciones del ERP | La copia que el borrado no toca |
| Mensajes, transcripciones de voz y ejecuciones del asistente | Módulo de conversaciones de Contacto AI | Lo que la familia le contó al canal de atención |
| Historial de versiones | Bitácora de cambios de los documentos con seguimiento | Dónde quedó el valor anterior de un campo anonimizado |
| Papelera de documentos borrados | Registro del framework | Qué se borró antes, a veces sin que nadie supiera que quedó una copia |
5. Cómo se arma con MCP, paso a paso
El diseño es deliberadamente modesto: un agente en solo lectura que, por cada solicitud, arma el mapa de dónde está la persona y, al final, prueba que ya no está. No borra, no anonimiza, no bloquea. Esas decisiones las toma una persona. Así se arma:
Paso 1. Identificar al titular y a quién pide
La solicitud entra por el canal que la empresa definió y alguien la registra con el documento, el teléfono y el correo del titular, y con la calidad de quien pide: el propio titular, un heredero, un apoderado. La verificación de identidad y de legitimación la hace una persona. El agente no decide si una hija es heredera; recibe una solicitud ya validada.
Paso 2. El mapa: dónde aparece la persona
Con esas tres llaves, el agente consulta a través de SFUN MCP cada tipo de registro donde puede aparecer la persona: clientes y contactos, afiliados y beneficiarios, contratos y servicios, facturas, correos por remitente y destinatario, conversaciones por número de teléfono. Las consultas respetan los permisos del usuario con el que corre el agente y devuelven como máximo 50 registros por página, así que el agente pagina hasta agotar cada tipo. La herramienta de análisis del MCP permite además contar cuántos registros hay por tipo antes de listarlos, que es lo que da el denominador.
Un detalle que se aprende rápido: buscar solo encuentra lo escrito igual. Un teléfono con prefijo de país y otro sin él, o una cédula con puntos y otra sin ellos, son búsquedas distintas. El agente debe probar las variantes razonables y reportar qué buscó, no solo qué encontró. Es la misma trampa que describimos en el caso del proveedor duplicado.
Paso 3. Clasificar: borrar, bloquear o conservar
El agente propone una clasificación de cada hallazgo con su razón, y la persona responsable la confirma o la corrige:
| Tipo de hallazgo | Propuesta habitual | Por qué la decide una persona |
|---|---|---|
| Contacto comercial, suscripciones y listas de difusión | Borrar | Suele no haber deber de conservación, pero hay que confirmar que no cuelga de un contrato vigente |
| Conversaciones de atención ya cerradas | Borrar o anonimizar el contenido | Pueden ser prueba en un reclamo abierto |
| Factura, contrato de previsión y soporte del servicio | Conservar y bloquear | Hay deberes contables, tributarios y sanitarios con plazos distintos en cada país |
| Datos del fallecido pedidos por un heredero | Según la ley del país y la voluntad del causante | La ley chilena, por ejemplo, lo permite salvo que el fallecido lo haya prohibido o una ley lo impida |
| Copias en la papelera y en el historial de versiones | Eliminar de forma definitiva lo ya suprimido | Es la parte que casi nadie hace, y requiere permisos de administrador |
Paso 4. Ejecutar, con las manos de una persona
La ejecución la hace un usuario con permisos, siguiendo el mapa aprobado. Hay una tentación que conviene nombrar: si el agente ya encontró todo, ¿por qué no deja que también borre? Porque en SFUN, como en la mayoría de los ERP construidos sobre el mismo framework, la acción de borrado del MCP pasa por la misma papelera que el botón de la pantalla. Un agente que borra deja la misma copia que dejaría una persona. Automatizar el borrado con IA no suprime mejor; suprime igual de mal, pero más rápido y a más registros.
Paso 5. La prueba de supresión
Terminada la ejecución, el agente vuelve a correr el mismo mapa, incluyendo la papelera y el historial de versiones. El resultado esperado es vacío en lo que se borró y bloqueado en lo que se conservó. Ese resultado, con la fecha, las búsquedas hechas y cuántos registros de cada tipo se revisaron, se guarda como respaldo de la respuesta al titular. Una prueba vacía sin denominador no prueba nada: puede significar que el agente no miró. Es la regla que desarrollamos en el artículo sobre el fallo silencioso.
6. El bucle de mejora continua
- Por cada solicitud: el mapa, la clasificación aprobada y la prueba de supresión quedan juntos. Si la prueba encuentra algo, se ejecuta de nuevo y se anota qué se había escapado.
- Cada semana: se revisa qué tipos de registro aparecieron en la prueba después de ejecutar. Si siempre son los correos, el procedimiento tiene un paso faltante, no un operador distraído.
- Cada mes: se revisan las búsquedas que no encontraron nada y se agregan variantes de formato. Cada teléfono con un formato nuevo mejora el mapa de todas las solicitudes siguientes.
- Cada trimestre: se mira dónde nace el problema. Si el historial de versiones siempre guarda datos que no debería, la corrección es desactivar el seguimiento de cambios en esos campos o documentos, no suprimir mejor cada vez.
Como en el resto del cluster, el agente no está para cumplir por la empresa. Está para mostrar dónde se queda el dato hasta que el proceso deje de dejarlo.
7. Gobierno y límites
| Acción | Quién la hace | Por qué |
|---|---|---|
| Verificar identidad y legitimación de quien pide | Una persona | Un falso heredero que obtiene una supresión borra la prueba que otra persona necesita |
| Buscar a la persona en todo el sistema y armar el mapa | El agente, en solo lectura | Es la parte que escala y donde el cansancio humano deja huecos |
| Clasificar cada hallazgo en borrar, bloquear o conservar | El agente propone, una persona decide | Los deberes de conservación cambian por país y por tipo de documento |
| Borrar, anonimizar o bloquear | Una persona con permisos | Es irreversible y, si lo hace el agente, deja la misma copia |
| Eliminar definitivamente de la papelera y del historial | Un administrador | Es la única acción que realmente suprime, y la más difícil de deshacer |
| Responder al titular | Una persona | La respuesta es un acto con plazo legal y debe quedar respaldada |
Cuatro límites más, que dependen de cómo se instale:
- Modo solo lectura en el servidor. SFUN MCP puede configurarse para que ninguna herramienta de escritura esté disponible. Para este caso es obligatorio: el agente no necesita escribir nada.
- Un usuario de consulta propio. Para armar el mapa, el agente necesita ver más que un usuario de sede, incluidos la papelera y el historial. Ese usuario es sensible por definición: se crea solo para este caso, se revisa su uso y no se reutiliza para otros agentes.
- El mapa también es un dato personal. Una lista de todos los lugares donde aparece una persona es exactamente lo que no debe circular. Se guarda dentro del sistema, con acceso restringido, y no se envía por chat ni por correo.
- El agente no ve lo que está bloqueado. Una vez bloqueado un dato, ningún agente de atención, cobranza o análisis debe poder leerlo. Es la otra mitad del bloqueo, y la que más se olvida.
Lo que nunca se automatiza: la verificación de quien pide, la decisión de borrar frente a conservar y la eliminación definitiva. Son acciones donde un error es caro y no tiene «deshacer», el criterio que tratamos en el artículo sobre acciones irreversibles.
8. KPIs: cómo saber si funcionó
| Indicador | Cómo se mide | Línea base | Meta a 90 días |
|---|---|---|---|
| Solicitudes respondidas dentro del plazo legal | Fecha de respuesta frente a fecha de ingreso, por país | Las últimas solicitudes atendidas | 100 % |
| Solicitudes con prueba de supresión guardada | Solicitudes cerradas con mapa posterior y denominador | Probablemente cero | 100 % de las cerradas en el trimestre |
| Hallazgos en la prueba posterior | Registros encontrados después de ejecutar, por tipo | Primeras cinco solicitudes | Cero en correos y conversaciones |
| Copias en la papelera de datos ya suprimidos | Registros de titulares suprimidos que siguen restaurables | Barrido inicial | Cero, con una retención definida y activada |
| Tiempo de armado del mapa | Minutos por solicitud | Proceso manual actual | Menos de 15 minutos de revisión humana |
| Tipos de registro cubiertos por el mapa | Tipos consultados frente a tipos con datos personales identificados | Inventario inicial | Todos los identificados, revisado cada trimestre |
Una advertencia sobre el tercer indicador: el primer mes va a mostrar hallazgos. No porque el proceso empeore, sino porque por primera vez alguien revisa después de ejecutar. Conviene decírselo al comité antes de mostrar el primer reporte.
9. Hoja de ruta de adopción
| Momento | Qué se hace | Entregable |
|---|---|---|
| Semana 1 | Preguntar a tecnología cuántos respaldos hay, dónde y por cuánto tiempo. Revisar si la purga de la papelera está activada y con qué plazo. Crear el usuario de consulta del agente en solo lectura | Respuesta escrita sobre respaldos y retención de la papelera |
| Semana 2 | Inventario de dónde aparecen datos personales: tipos de registro, campos y canales. Correr el mapa sobre una solicitud ya cerrada | Primer mapa real y lista de lo que se había escapado |
| Mes 1 | Procedimiento escrito de supresión con los cinco pasos, la tabla de borrar, bloquear y conservar por país, y la prueba posterior | Procedimiento aprobado por legal |
| Mes 2 | Todas las solicitudes nuevas pasan por el mapa y la prueba. Barrido de la papelera para eliminar copias de titulares ya suprimidos | Solicitudes con prueba guardada |
| Trimestre 1 | Revisar qué documentos guardan historial de campos personales que no lo necesitan, y la retención de conversaciones del canal de atención | Menos lugares donde el dato se queda |
Errores comunes
- Dar por cumplida la solicitud cuando la pantalla dice «eliminado». Es exactamente el fallo que encontraron las autoridades europeas.
- Borrar lo que había que conservar. Una factura suprimida para cumplir con un titular es un incumplimiento tributario. Lo que se conserva se bloquea.
- Olvidar el canal de atención. Lo que la familia escribió al asistente de WhatsApp es tan dato personal como su ficha.
- Dejar que el agente borre. Deja la misma copia en la papelera y multiplica el alcance de un error.
- Contratar un chatbot sin preguntar por su índice. Si indexa conversaciones, la supresión tiene que llegar hasta ahí, y el proveedor debe decir cómo.
- Guardar la prueba sin denominador. Una búsqueda vacía sin decir qué se buscó y cuántos registros se revisaron no demuestra nada ante una autoridad.
Qué existe hoy en SFUN y qué es hoja de ruta
| Pieza | Estado |
|---|---|
| Consulta de clientes, contratos, facturas, correos y conversaciones con SFUN MCP, respetando permisos | Existe |
| Conteo por tipo de registro y listados paginados (hasta 50 registros por página) | Existe |
| Modo solo lectura del servidor MCP | Existe |
| Índice vectorial del MCP limitado al catálogo de herramientas, sin datos de personas y con borrado físico | Existe |
| Papelera de documentos borrados con restauración, y rutina del framework para purgarla | Existe. La purga hay que activarla y definir su plazo |
| Flujo de supresión y descarga de datos personales del framework | Existe, sin conectar a los datos funerarios |
| Declaración de los campos personales de las aplicaciones de negocio para ese flujo | Hoja de ruta |
| Retención configurable y borrado por contacto en el módulo de conversaciones | Hoja de ruta |
| Registro de solicitudes de titulares con sus plazos legales | Hoja de ruta |
| Bloqueo de un titular que impida a los agentes leer sus datos | Hoja de ruta |
| Agente que arma el mapa y la prueba de supresión | Patrón de implementación sobre las piezas existentes, no función empaquetada |
Preguntas frecuentes
¿Borrar un registro en el ERP cumple con el derecho de supresión?
Casi nunca, por sí solo. En la mayoría de los ERP el borrado guarda una copia restaurable, no toca los correos asociados y no alcanza a otros registros donde aparece la persona, como las conversaciones del canal de atención. Cumplir exige encontrar todos esos lugares, decidir qué se borra y qué se conserva bloqueado, y comprobar después que el dato ya no está donde no debe.
¿Qué son los derechos ARCO y qué tiene que ver la supresión?
ARCO son las siglas de acceso, rectificación, cancelación y oposición, los derechos de los titulares de datos personales en México. La cancelación es el equivalente mexicano de la supresión. Chile, Colombia y Perú usan la palabra supresión, y la ley chilena agrega además portabilidad y bloqueo. El problema técnico es el mismo en todos: saber dónde está el dato para poder cancelarlo o suprimirlo de verdad.
¿Es lo mismo el derecho al olvido que el derecho de supresión?
Se usan como sinónimos, pero el «derecho al olvido» suele referirse a desindexar información de buscadores y medios. Para una funeraria, lo que llega es una solicitud de supresión o cancelación sobre los datos que la empresa trata en sus propios sistemas, y es la que este artículo describe.
Si la ley me obliga a conservar la factura, ¿puedo negar la supresión?
No conviene negarla sin más. Lo que se conserva por obligación legal se bloquea: se guarda, pero no se usa para nada más que para cumplir esa obligación, y ningún proceso comercial ni agente de IA debe verlo. Lo que no tiene deber de conservación se borra. La respuesta al titular explica qué se hizo con cada cosa. En Chile, la Ley 21.719 lo resuelve de forma expresa con el derecho de bloqueo, como explicamos en la guía chilena.
¿La IA puede atender las solicitudes de supresión sola?
Puede hacer la parte más pesada, que es encontrar a la persona en todo el sistema y comprobar después que ya no está. No debe verificar la identidad de quien pide, decidir qué se conserva ni ejecutar el borrado. En un ERP como SFUN, además, un agente que borra deja la misma copia en la papelera que dejaría una persona.
¿Qué pasa con las copias de respaldo?
Son uno de los puntos que más preocuparon a las autoridades europeas: la mitad de las que respondieron lo señaló. Rara vez es razonable restaurar y editar un respaldo por cada solicitud. Lo defendible es un procedimiento escrito con plazos publicados. Google Cloud, por ejemplo, documenta el suyo en tres etapas: marca el dato para borrado en un máximo de 24 horas, lo retira de los sistemas activos en unos dos meses y completa el borrado en unos seis meses, cuando expiran los respaldos. Tu procedimiento debe decir cuánto viven tus respaldos, que no se restauran datos ya suprimidos y que, si alguna vez se restaura uno, la supresión se vuelve a aplicar antes de usarlo.
¿Aplica igual en todos los países de Latinoamérica?
El problema técnico es idéntico en toda la región: dónde queda el dato no depende de ninguna ley. Lo que cambia por país es el nombre del derecho, el plazo para responder, quién puede pedirlo en nombre de un fallecido y qué documentos hay que conservar. Tenemos guías específicas para Chile, México y Costa Rica.
En resumen
Cuando el ERP dice «eliminado», el dato de la persona suele seguir en tres lugares: la papelera, el historial de versiones y los correos y conversaciones que el borrado no toca. Y si el asistente de IA indexó conversaciones en una base vectorial, puede haber un cuarto. Las autoridades europeas revisaron a 764 organizaciones y encontraron la misma raíz: nadie había escrito dónde vive el dato ni cómo se prueba que se fue.
El caso de IA que lo resuelve no es un agente que borra. Es un agente en solo lectura que encuentra a la persona en todo el sistema, propone qué borrar y qué bloquear, y al final prueba que ya no está, con el denominador a la vista. Las personas verifican quién pide, deciden y ejecutan. Y la dirección mira un solo número cada trimestre: cuántas solicitudes cerradas tienen su prueba guardada.
Fuentes de este artículo
- Coordinated Enforcement Framework 2025: right to erasure, Comité Europeo de Protección de Datos (EDPB), adoptado el 10 de febrero de 2026. edpb.europa.eu (PDF). De aquí salen las 32 autoridades y las 764 organizaciones (p. 2 y 9), las 17 autoridades que señalaron la falta de procedimiento (p. 13), la preocupación sobre los respaldos (p. 21-22) y los fallos citados (p. 14 y 23). El informe no trata inteligencia artificial ni índices vectoriales: esa conexión es nuestra.
- Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases, Chakraborttii, García Alvarado, Abdulofizova y Dwivedi, arXiv:2606.18497, 16 de junio de 2026. arxiv.org. Preprint no revisado por pares. De aquí salen el modelo de amenaza, las tasas de reconstrucción, el resultado con copias de respaldo, la mitigación por cifrado y los límites declarados por los autores.
- Documentación de Qdrant sobre el optimizador de limpieza (qdrant.tech) y de Weaviate sobre el índice vectorial (weaviate.io): borrado marcado hasta la limpieza.
- Data deletion on Google Cloud, Google Cloud. cloud.google.com. Etapas y plazos del borrado, incluida la expiración de respaldos.
- Ley 21.719, Chile (bcn.cl): supresión (art. 7 de la Ley 19.628 modificada), bloqueo (art. 8 ter) y herederos (art. 4); vigencia desde el 1 de diciembre de 2026. LFPDPPP, México, DOF del 20 de marzo de 2025 (diputados.gob.mx): arts. 24 y 25. Ley 1581 de 2012, art. 8 literal e) y art. 15, y Decreto 1377 de 2013, art. 9, Colombia (funcionpublica.gov.co).
- Código del producto SFUN, rama principal, consultado el 13 de septiembre de 2026: comportamiento del borrado del framework (copia en la papelera, eliminación del historial y de los comentarios del documento, desvinculación de correos), rutina de purga de la papelera y su configuración de fábrica, acción de borrado del servidor MCP, modo solo lectura, índice vectorial del catálogo de herramientas y módulo de conversaciones.