Un asesor le pide al agente de inteligencia artificial que emita la factura del servicio. El agente contesta: «Listo, la factura del servicio quedó emitida.» Nueve palabras, ningún dato personal, nada que un revisor pudiera objetar. Si mañana el oficial de cumplimiento audita las conversaciones del agente, encontrará miles de frases exactamente así de limpias y concluirá, con toda lógica aparente, que el sistema no expone datos sensibles.
Se estará equivocando, y no por poco. Para producir esas nueve palabras, el agente tuvo que llamar a una herramienta del ERP y pasarle argumentos: el número de documento del contratante, el parentesco con el fallecido, el nombre del difunto y, según cómo esté modelado el expediente, la causa de muerte. Ese contenido nunca apareció en la respuesta. Viajó dentro de la llamada, se escribió en el registro de invocaciones tal como se envió, y probablemente sigue ahí.
Este artículo trata la capa que casi nadie está mirando cuando conecta un agente de IA a su ERP: no lo que el agente dice, sino lo que el agente escribe en los argumentos. Es el complemento directo de nuestra guía de gobierno de agentes de IA en el ERP funerario, que resuelve quién puede hacer qué; aquí resolvemos algo distinto y menos discutido: qué viaja dentro de cada llamada, y dónde queda.
1. El problema de negocio: la auditoría mira donde no pasa nada
Cuando una compañía funeraria conecta un agente de IA a su ERP, el comité que aprueba el proyecto suele pedir tres cosas: que el agente no vea más de lo que ve la persona, que quede constancia de lo que hizo y que se pueda revisar. Las tres son razonables. El problema es que la revisión, en la práctica, se implementa sobre el historial de conversaciones — porque es lo legible, lo que se puede leer en una tarde y lo que el proveedor entrega de fábrica.
El resultado es una auditoría que produce tranquilidad sin producir cobertura. Y en el sector funerario eso no es un tecnicismo: el expediente de un servicio concentra, en un mismo documento, la categoría de datos más protegida por cualquier régimen de la región — datos de salud y causa de muerte, identificación del fallecido y de los deudos, relaciones familiares, y con frecuencia información económica del contrato de previsión. No es un CRM con correos y teléfonos. Es un archivo sensible por diseño.
Lo que cuesta hoy no es una multa hipotética. Es algo más inmediato y más medible: la compañía no puede responder una pregunta básica. Si el regulador, un auditor externo o la propia familia pregunta «¿qué datos de este fallecido procesó su sistema de inteligencia artificial, cuándo y para qué?», la respuesta honesta en la mayoría de las implantaciones que hemos visto es que no se sabe: hay un historial de lo que el agente contestó, no un registro de lo que el agente movió.
2. La evidencia: dónde ocurre de verdad la fuga
Esto dejó de ser una intuición de arquitectura. En febrero de 2026 se publicó AgentLeak, un banco de pruebas diseñado específicamente para medir la fuga de información privada por los canales internos de un sistema multiagente, y no solo por su salida. Instrumentó siete canales distintos, sobre mil escenarios de salud, finanzas, legal y corporativo, con cinco modelos de producción, y validó 4.979 trazas de ejecución.
| Dónde se midió la fuga | Tasa | Qué significa para tu auditoría |
|---|---|---|
| Mensajes entre agentes (canal interno) | 68,8 % | Es el canal con más fuga, y es el que ninguna revisión de conversaciones alcanza a ver. |
| Respuesta final al usuario | 27,2 % | Es lo único que audita hoy la mayoría de las compañías. |
| Agregado de todos los canales instrumentados | 68,9 % | La exposición real del sistema, no la de su vitrina. |
| Violaciones que pierde una auditoría de solo salida | 41,7 % | Cuatro de cada diez incidentes no aparecen en el informe que hoy se firma. |
Conviene leer bien el dato: el estudio encontró que una configuración multiagente reduce la fuga en la salida final frente a un agente único — es decir, la vitrina mejora — mientras abre exposición nueva por la vía interna. Es el peor patrón posible para un comité: los indicadores que mira mejoran mientras el riesgo real se desplaza a donde no mira.
El diseño arquitectónico de un sistema multiagente —y en particular la mensajería entre agentes— determina la exposición de datos privados más allá de lo que cualquier salvaguarda aplicada sobre la salida puede detectar.— AgentLeak: A Benchmark for Internal-Channel Privacy Leakage in Multi-Agent LLM Systems, arXiv:2602.11510 (12 de febrero de 2026)
El control que crees tener: qué dice la letra chica del fabricante
La objeción natural del área de tecnología es que esto ya está resuelto: «activamos el filtro de datos sensibles de la plataforma». Vale la pena leer lo que el propio fabricante documenta. En la documentación de los guardrails de Amazon Bedrock, la nota sobre el filtro de información sensible advierte que, en cargas de trabajo con uso de herramientas, el filtro no evalúa determinados campos — y que, por lo tanto, la información personal que esté en ellos «no se bloquea ni se enmascara».
- Los argumentos de la llamada. La PII que el modelo genera dentro de
toolUse.input(o los parámetros detool_use). El ejemplo que da la propia documentación es exactamente nuestro caso: si el modelo le pasa el correo de un cliente a una herramienta que escribe un archivo, ese correo no se enmascara. - Los resultados que devuelve la herramienta. La PII contenida en
toolResult, es decir, lo que tu ERP le responde al modelo. - Las definiciones de las herramientas. La PII que haya en
toolSpec.descriptionytoolSpec.inputSchema— el catálogo mismo.
Y hay una segunda nota, sobre los registros, que es la que convierte el problema en permanente: el enmascaramiento no aplica a los logs de invocación. Si tienes activado el registro de invocaciones del modelo, el campo de entrada en el log «siempre contiene la petición original, sin modificar, con independencia de la intervención del guardrail». Dicho de otro modo: el filtro puede haber hecho bien su trabajo de cara al usuario y, aun así, el dato en crudo quedó escrito en tu log.
3. Qué datos del ERP intervienen (y por qué el caso funerario es el peor)
En un ERP funerario, la superficie no es abstracta. Cuando un agente resuelve una tarea corriente de mostrador o de call center, los argumentos que compone salen de estos sitios:
| Origen del dato | Qué viaja en los argumentos | Por qué es crítico |
|---|---|---|
| Expediente del servicio | Nombre del fallecido, fecha y lugar del deceso, y en muchos modelos la causa de muerte | Es dato de salud. Es la categoría con el estándar de protección más alto en toda la región. |
| Contratante y deudos | Documento de identidad, parentesco, teléfono, dirección | Identifica a personas vivas y las vincula a un hecho sensible: no es un contacto comercial cualquiera. |
| Contrato de previsión y cartera | Número de contrato, saldo, mora, medio de pago | Información económica; en varios regímenes tiene protección reforzada propia. |
| Conversaciones de WhatsApp y del call center | Fragmentos textuales que el agente cita o resume dentro de la llamada | El texto libre es el peor: no está tipado, así que ningún filtro por campo lo encuentra. |
| Parque cementerio | Ubicación de la bóveda, titularidad, historial de inhumaciones | La ubicación de una sepultura es, en la práctica, un dato de localización asociado a una familia. |
El detalle que agrava el caso funerario frente a otros sectores es la combinación. Un banco maneja identificación y dinero; un hospital maneja identificación y salud. Una funeraria maneja las dos cosas en el mismo registro y sobre una misma familia, y además la conserva durante décadas por los plazos del contrato de previsión. Cualquier fuga que ocurra en esa capa no es parcial: es el expediente entero.
El marco regulatorio ya se está moviendo
No hace falta esperar una norma específica sobre agentes de IA: la que existe ya alcanza. En Colombia, la Superintendencia de Industria y Comercio expidió la Circular Externa 002 del 21 de agosto de 2024, con lineamientos sobre el tratamiento de datos personales en sistemas de inteligencia artificial, que sigue siendo el instrumento vigente de la autoridad en la materia. En Chile, la Ley 21.719 entra en plena vigencia el 1 de diciembre de 2026 y crea una agencia con potestad sancionatoria propia — lo tratamos en detalle en el artículo sobre la Ley 21.719 y las funerarias en Chile.
El punto no es el catálogo de normas, sino la pregunta que todas comparten y que este punto ciego deja sin responder: ¿puedes demostrar qué datos personales trató tu sistema, cuándo y con qué finalidad? Un historial de respuestas no lo demuestra. Un registro de llamadas con sus argumentos, sí.
4. Cómo se arma el caso con MCP, paso a paso
La buena noticia es que MCP hace este trabajo posible, porque convierte la conversación en algo estructurado: cada acción del agente es una llamada con nombre y con argumentos tipados. Eso es justamente lo que se puede inventariar, clasificar, enmascarar y registrar. En una integración por texto libre no habría por dónde empezar.
Paso 1 — Inventaría la superficie de argumentos (una tarde de trabajo)
Lista las herramientas que tu agente ve y, para cada una, los campos que puede recibir. No es una investigación: el catálogo es finito y está declarado. El entregable es una tabla de tres columnas — herramienta, argumento, categoría del dato — y el hallazgo típico es incómodo y útil: la mayoría de las herramientas no necesitan la mitad de los datos personales que pueden recibir.
Paso 2 — Clasifica por sensibilidad y decide qué NO debe viajar nunca
- Nunca debe viajar en un argumento: causa de muerte y cualquier dato de salud, salvo que la herramienta exista precisamente para eso y esté autorizada por rol para ese uso concreto.
- Debe viajar por referencia, no por valor: identificación del contratante y de los deudos. El agente pasa el identificador interno del registro, no el número de documento. El ERP resuelve la referencia del lado seguro.
- Puede viajar, con registro: número de contrato, importes, fechas. Son operativos y trazables, y sin ellos no hay trabajo posible.
- Requiere revisión caso a caso: el texto libre — resúmenes de conversaciones, notas del asesor. Es donde se cuela lo que ninguna regla por campo atrapa.
Paso 3 — Enmascara en la capa de los argumentos, no solo en la de la respuesta
Este es el paso que la documentación del fabricante deja explícitamente en tu tejado. Si el filtro de la plataforma no evalúa toolUse.input, el enmascaramiento tiene que ocurrir en tu capa: en el servidor MCP, en el punto donde la llamada entra, antes de ejecutarla y antes de escribirla en cualquier registro. La ventaja de hacerlo ahí es que es un solo sitio, y que ese sitio ya existe: es el mismo por el que hoy pasa la autorización.
Paso 4 — Sanea la bitácora, y trátala como lo que es
Un log de invocaciones con argumentos en crudo es una base de datos personales, con todas las consecuencias: tiene responsable, finalidad, plazo de conservación y derechos de los titulares ejerciéndose sobre ella. Casi ninguna compañía la inventaría como tal, y ese es el hallazgo que más incomoda en una auditoría. Las decisiones a tomar son tres, y son de dirección, no de infraestructura: cuánto se guarda, quién puede leerlo y cuándo se destruye.
Paso 5 — Construye la traza que sí responde la pregunta
El objetivo final no es tener más logs: es poder contestar, en minutos y con evidencia, qué tocó el agente. Un registro de invocaciones útil tiene seis campos y ni uno más:
| Campo | Para qué sirve |
|---|---|
| Persona real que originó la acción | No el usuario técnico del agente: la persona cuyos permisos se ejercieron. |
| Herramienta invocada y resultado | Qué se intentó y si se ejecutó o fue rechazada. |
| Argumentos, ya saneados | Referencias en lugar de valores; el resto, enmascarado. |
| Registros del ERP alcanzados | Los identificadores concretos que se leyeron o modificaron. Es lo que permite responder «¿qué datos de esta familia se trataron?». |
| Marca de tiempo y finalidad | La finalidad es un campo de negocio, no técnico: cobranza, atención, cierre contable. |
| Volumen devuelto | Cuántos registros salieron. Una consulta que devuelve 4.000 filas no es la misma acción que una que devuelve 3. |
5. El bucle de mejora continua
Esto no es un proyecto que se entrega: es un control que se corre. La cadencia que recomendamos es deliberadamente modesta, porque un control que exige demasiado se abandona en el segundo mes.
- Cada día, automático: revisión de las llamadas cuyos argumentos activaron una regla de dato sensible. No es una lista para leer entera: es una lista que debería estar vacía, y cuya cifra distinta de cero es la señal.
- Cada semana, 30 minutos: las herramientas más invocadas y los argumentos que más se repiten. Aquí aparecen los datos que viajan por costumbre y ya no hacen falta.
- Cada mes, una hora: ¿alguna herramienta nueva entró al catálogo sin pasar por la clasificación del paso 2? Es la vía por la que la superficie vuelve a crecer sin que nadie lo decida.
- Cada trimestre: una prueba real — se toma un expediente concreto y se reconstruye, solo con el registro, todo lo que el agente hizo con él. Si no se puede, el control no está funcionando, por buenos que se vean los indicadores.
6. Gobierno y límites: qué existe hoy en SFUN y qué todavía no
Esta sección es la que más nos importa que se lea con exactitud, porque separa lo verificable de lo deseable. Todo lo que sigue en la primera tabla está comprobado en el código del producto; lo que sigue en la segunda es hoja de ruta, y lo decimos con esa palabra.
Lo que ya existe y funciona
| Control | Cómo está implementado |
|---|---|
| Doble portón de acceso | No basta con estar autenticado: además del token Bearer, el usuario debe tener el rol MCP User. Sin ese rol, el servidor responde 403 aunque las credenciales sean válidas. |
| Revocación efectiva en el request siguiente | El rol se lee de la base de datos en cada petición y no se memoiza en el token. Si a alguien se le retira el acceso, queda bloqueado en la llamada siguiente, sin esperar a que expire nada. |
| Herencia de permisos, no permisos propios del agente | La analítica en modo agregado consulta a través de la capa de permisos de Frappe, de modo que se aplican los permisos del usuario y las condiciones de consulta por rol. El agente no ve más que la persona. |
| Tope duro contra la extracción masiva | El modo SQL está limitado a 20 filas, y el motivo está escrito en el propio código: impedir la extracción masiva de datos personales. Se puede analizar; no se puede vaciar la base. |
| Modo SQL restringido a rol privilegiado | Solo sentencias de lectura, una por llamada, y bloqueo explícito de acceso a la tabla de credenciales de Frappe, a los esquemas internos del motor, a la lectura y escritura de archivos y a las funciones de denegación de servicio. |
| Validación de campos contra el esquema | Los campos y agrupaciones que llegan como argumento se validan contra el esquema real del doctype antes de ejecutarse, lo que cierra la vía de inyección por argumento. |
| Autorización antes de procesar el cuerpo | La comprobación de acceso ocurre antes de interpretar el contenido de la petición, para no procesar payloads de actores no autorizados. |
| Registro de los rechazos | Los intentos de acceso de usuarios autenticados sin el rol requerido se registran con fines de auditoría — deliberadamente, esos y no cada rechazo anónimo, para que la señal de abuso interno no quede sepultada bajo el ruido. |
Lo que todavía no existe (hoja de ruta, dicho sin rodeos)
Lo mismo aplica al enmascaramiento en la capa de argumentos del paso 3: es la decisión de diseño correcta y es hacia donde va el producto, no una casilla que hoy puedas marcar. Preferimos decirlo así antes que dejar que un comité apruebe un proyecto creyendo que compra un control que aún no le podemos entregar.
Lo que nunca se automatiza
- Comunicar a una familia cualquier cosa relacionada con la causa de muerte. Sin excepciones y sin revisión humana que valga: no es una tarea de agente.
- Ejecutar la supresión de datos de un titular. El agente puede preparar el inventario de dónde está ese titular; la ejecución la firma una persona.
- Decidir sobre una reclamación o una negativa de cobertura. El agente reúne y cita; la decisión y su motivación son humanas, como ya tratamos en el artículo sobre la negativa motivada.
- Ampliar su propio alcance. Ninguna herramienta que agregue permisos, cree usuarios o modifique roles entra al catálogo del agente.
7. KPIs, con línea base y meta
La línea base honesta de casi toda compañía que empieza esto es cero: no es que los indicadores estén mal, es que no existen. Eso está bien como punto de partida, y conviene escribirlo tal cual en el acta del comité.
| Indicador | Línea base habitual | Meta a 90 días |
|---|---|---|
| Cobertura del inventario de argumentos | 0 % — no hay inventario | 100 % de las herramientas del catálogo clasificadas |
| Argumentos sensibles que viajan por valor | Sin medir | 0 para datos de salud; identificación solo por referencia |
| Tiempo en responder «¿qué datos de este titular trató la IA?» | No se puede responder | Menos de una hora, con evidencia exportable |
| Llamadas ejecutadas con registro completo de seis campos | 0 % | 100 % de las que escriben; muestreo en las de solo lectura |
| Herramientas nuevas que entraron sin clasificar | Sin control | 0 por trimestre |
| Antigüedad máxima de la bitácora con argumentos en crudo | Indefinida | Plazo definido, aprobado y ejecutándose de verdad |
8. Hoja de ruta de adopción
Semana 1 — Ver la superficie
Inventario de herramientas y argumentos (paso 1) y lectura, con el proveedor delante, de qué dice su documentación sobre las llamadas a herramientas y sobre los logs. El entregable de la semana es una tabla y una respuesta escrita a una sola pregunta: ¿dónde queda hoy el argumento en crudo, y quién puede leerlo?
Mes 1 — Cortar el flujo
Clasificación completa (paso 2) y conversión a referencias de los identificadores personales. Es el cambio de mayor retorno y el que menos discusión genera, porque no reduce ninguna capacidad del agente: solo cambia lo que viaja escrito. En paralelo, decisión de dirección sobre el plazo de conservación de la bitácora.
Trimestre 1 — Poder demostrarlo
Registro de invocaciones con los seis campos, y la prueba trimestral: se elige un expediente al azar y se reconstruye qué hizo el agente con él. El día que esa reconstrucción sale en veinte minutos y sin ayuda del área técnica, el control está instalado de verdad.
9. Cinco errores que hacen fracasar este caso
- Creer que el filtro de la plataforma cubre todo. Es el error de origen, y el fabricante lo desmiente por escrito en su propia documentación. Léela antes de firmar el acta.
- Auditar el historial de conversaciones y llamarlo auditoría. Es mirar el 27,2 % y perder el 41,7 %.
- Guardar todo «por si acaso». Una bitácora eterna con argumentos en crudo no es prudencia: es aumentar la superficie del problema y crear una base de datos personales que nadie inventarió.
- Resolverlo a punta de instrucciones al modelo. Pedirle al agente que «no incluya datos sensibles en las llamadas» es una preferencia, no un control. El control va en el servidor, donde no depende de que el modelo obedezca.
- Ponerlo en la lista de tareas del área técnica. Las tres decisiones difíciles —qué se guarda, quién lo lee y cuándo se destruye— son de dirección. Delegarlas garantiza que se tomen por omisión.
Preguntas frecuentes
¿Es seguro conectar un agente de IA al ERP de una funeraria?
Puede serlo, y depende menos del modelo que de la capa por la que pasa. Lo que hay que exigir es concreto: que el agente herede los permisos de la persona en lugar de tener los suyos, que exista un tope de volumen que impida vaciar la base, que el catálogo de herramientas sea cerrado y que quede registro de lo que se ejecutó. Los cuatro primeros existen hoy en SFUN; el registro completo de invocaciones está en la hoja de ruta. Si un proveedor te dice que todo está resuelto y no te muestra dónde, esa es la señal de alarma.
Si el agente solo consulta y no modifica nada, ¿también aplica?
Aplica igual, y es el malentendido más frecuente. El riesgo del que trata este artículo no es que el agente cambie algo, sino que el dato personal viaje y quede escrito donde nadie lo controla. Una consulta de solo lectura compone argumentos exactamente igual que una escritura, y su resultado —que puede traer decenas de registros de familias— vuelve al modelo por el mismo canal.
¿No basta con anonimizar los datos antes de que el agente los vea?
En la operación diaria, no: el asesor necesita saber de qué familia concreta está hablando, así que la anonimización total rompe el caso de uso. Lo que sí funciona es la vía intermedia del paso 2: que el agente trabaje con referencias y que el nombre y el documento se resuelvan del lado del ERP, en la presentación, y no dentro de los argumentos de la llamada.
¿Esto es lo mismo que el gobierno de agentes que ya publicaron?
Es la pieza que faltaba de aquel. El artículo de gobierno de agentes responde quién puede hacer qué: identidad, roles, catálogo cerrado, separación entre consultar y ejecutar. Este responde qué viaja dentro de cada llamada y dónde queda. Se puede tener un gobierno de permisos impecable y, aun así, estar escribiendo causas de muerte en texto claro en un log que nadie inventarió.
¿Cuánto cuesta implantar esto?
Los dos primeros pasos —el inventario y la conversión a referencias— son días de trabajo, no meses, y cubren la mayor parte de la exposición. El registro completo de invocaciones es un desarrollo de producto y por eso lo presentamos como hoja de ruta. Lo que no cuesta nada y casi nadie hace es el paso cero: abrir la documentación de tu plataforma y leer qué dice sobre las llamadas a herramientas.
¿Qué pasa si operamos en varios países?
El diseño técnico es el mismo en toda la región, porque el punto ciego es del sistema, no de la jurisdicción. Lo que cambia por país es el plazo de conservación, la autoridad ante la que se responde y el régimen sancionatorio. Por eso la decisión de cuánto tiempo se guarda la bitácora se toma por país, aunque el mecanismo que la produce sea único.
En resumen
La pregunta con la que conviene abrir el próximo comité no es si el agente de IA es seguro. Es más específica y más incómoda: «enséñame un ejemplo real de una llamada que hizo el agente, con sus argumentos, y dime dónde quedó guardada.» Si nadie en la sala puede mostrarlo en pantalla, no tienes un problema de inteligencia artificial: tienes un archivo de datos sensibles del que no llevas cuenta, y llevas meses alimentándolo.
Si quieres ver cómo se ordena esto sobre un ERP funerario real, el punto de partida es SFUN MCP, y la lectura complementaria obligada es el gobierno de agentes en el ERP funerario. Para el lado de la conversación con las familias, donde el texto libre es el que más se escapa, está el análisis de conversaciones de WhatsApp con IA.