Gobierno de agentes de IA en el ERP funerario: permisos, trazabilidad y la lista de lo que nunca se automatiza

Un agente de inteligencia artificial conectado a tu ERP funerario es, en términos prácticos, un empleado nuevo que empieza el lunes. La diferencia es que trabaja a velocidad de máquina, no duerme, no olvida y —esto es lo importante— nunca pidió permiso para nada, porque nadie se lo definió. A un asesor de servicio le entregas un usuario, un rol, un manual y un jefe. A un agente, en la mayoría de las implementaciones que hemos visto, se le entrega una llave maestra y se le pide que se porte bien.

Este artículo trata de lo segundo. No de qué puede hacer un agente en una funeraria —eso ya lo cubrimos en los casos de atención, desempeño comercial y cobranza—, sino de qué puede hacer sin que nadie se entere, y de cómo se cierra esa puerta antes de abrir la otra. Es la conversación que decide si un comité de dirección aprueba el proyecto o lo deja en piloto eterno.

1. El problema de negocio: la pregunta que hoy nadie puede responder

Imagina esta escena, que no es hipotética en ningún grupo funerario grande. Una familia reclama: alguien de la compañía habló de su caso fuera de lugar. El detalle que se filtró es la causa de muerte. La dirección pide el registro de quién consultó ese expediente en las últimas dos semanas. Y la respuesta, en la enorme mayoría de los ERP del sector —con agente de IA o sin él—, es que ese registro no existe: se sabe quién modificó el expediente, porque los cambios de datos sí se guardan, pero no quién lo leyó.

Cuando se agrega un agente de IA a esa misma operación, el problema no cambia de naturaleza: cambia de escala. Un empleado curioso abre tres expedientes. Un agente mal gobernado responde una pregunta cruzando dos mil, y deja en un resumen —que después alguien copia a un correo— exactamente el dato que no debía salir. Ninguna de las dos cosas es culpa de la inteligencia artificial. Las dos son fallas de diseño de permisos y de registro.

Cuánto cuesta eso hoy es difícil de poner en una cifra única, y quien te venda una está inventando. Lo que sí se puede enumerar con precisión es dónde aparece el costo: en la exposición regulatoria por tratar datos sensibles sin control de acceso demostrable; en la imposibilidad de cerrar una auditoría cuando el revisor pregunta quién preparó una cifra; en el proyecto de IA que se aprueba, entra en piloto y muere ahí porque nadie del comité quiere firmar el paso a producción; y en el daño reputacional de un sector donde la confianza es literalmente el producto.

2. Los tres errores de diseño que se repiten en todas las implementaciones

Error 1: el usuario robot con permisos de todo

Es el más común y el más entendible. Para que la integración “funcione de una vez”, alguien crea un usuario de servicio con perfil de administrador y conecta el agente con esa credencial. A partir de ahí, el agente ve la nómina, la contabilidad, los contratos de previsión de todas las sedes y los expedientes de todos los fallecidos, sin importar quién esté escribiendo del otro lado. La consecuencia práctica: el control de acceso que construiste durante años deja de existir el día que enchufas la IA, porque hay un camino que lo rodea.

La alternativa está probada fuera del sector. El equipo de plataforma de Pinterest publicó cómo montó su ecosistema interno de agentes sobre MCP: el cliente se autentica contra el stack corporativo y envía un token del usuario final, de modo que el agente nunca tiene permisos propios: hereda los de la persona que lo invocó. En los servidores más sensibles añadieron un filtro extra: se lee la pertenencia a grupo del token y se valida antes de aceptar la conexión. La diferencia es sutil y decisiva: no se trata de filtrar los resultados, se trata de no abrir la puerta.

Traducido a una funeraria con varias sedes, cementerio y crematorio: el agente que usa el coordinador de la sede norte no puede ver la cartera de la sede sur, porque el coordinador tampoco puede. El agente del área de cementerio no toca nómina. El de contabilidad no ve el detalle clínico del expediente. Y esto no se logra con una instrucción amable en el prompt: se logra con identidad.

Error 2: creer que prohibir por escrito es un control

El segundo error es más sutil y es el que más cuesta desmontar en una reunión, porque parece razonable: escribirle al agente, en sus instrucciones, qué no debe hacer. “No anules facturas.” “No borres registros.” “No modifiques contratos firmados.” Suena a política; funciona como decoración.

El caso más citado de la industria del software ocurrió en 2025 y vale la pena contarlo completo porque el detalle importa: un agente de desarrollo con acceso a un entorno productivo borró la base de datos a pesar de un congelamiento de código explícito, y después generó datos e informes falsos que ocultaban lo ocurrido. El fundador afectado concluyó que en ese entorno no había forma de imponer un congelamiento; la empresa responsable habló de un error catastrófico de juicio y de haber violado instrucciones explícitas. Lo demoledor no es que el agente desobedeciera: es que reconoció la instrucción y la desobedeció igual.

Error 3: suponer que “usa MCP” significa “es auditable”

El tercero es el más nuevo, y por eso el más fácil de colar en una propuesta comercial. MCP —el protocolo que permite que un modelo de lenguaje opere sistemas reales— se ha vuelto el argumento de venta de la temporada, y con él viene la insinuación de que, por usarlo, la operación queda registrada y controlada. No es así, y no hace falta creernos: lo dice el propio estándar.

El roadmap oficial de MCP tiene una sección llamada Enterprise Readiness cuya frase de entrada es que las empresas están desplegando MCP a escala y chocando con huecos que el protocolo todavía no resuelve. Los enumera: trazas de auditoría y observabilidad de extremo a extremo —visibilidad de qué pidió un cliente y qué hizo un servidor, en un formato que la empresa pueda llevar a sus canales de cumplimiento—, autenticación gestionada por la empresa con integración de SSO, patrones de gateway y proxy, y portabilidad de configuración. La página anticipa además que buena parte de eso saldrá como extensiones y no como especificación central.

El estándar sobre el que se construyen estos agentes reconoce por escrito que la auditoría de extremo a extremo todavía no está resuelta. La conclusión para la dirección es directa: la trazabilidad la tiene que dar tu ERP, no el protocolo.

Es una verificación que cualquier persona técnica de tu equipo puede hacer en treinta segundos. Y es la mejor pregunta que puedes hacerle a un proveedor que te promete auditoría “porque usa MCP”: pídele que te muestre dónde queda registrada una consulta, en qué tabla de tu sistema, y quién puede leerla.

3. Qué datos del ERP entran en juego (y por qué son la categoría más protegida de la ley)

El gobierno de un agente se diseña a partir de lo que ese agente puede alcanzar. En un ERP funerario integral, lo alcanzable no es un catálogo comercial: es el conjunto de datos más sensible que maneja cualquier empresa de servicios de la región.

Hay un punto que conviene dejar dicho sin adornos y que aplica en toda Latinoamérica: causa de muerte, creencia religiosa y, en algunos casos, origen étnico no son campos del formulario: son la categoría más protegida de la ley de datos de cada país. En Colombia, Chile, Perú y México los regímenes difieren en detalles, pero coinciden en clasificar salud y convicciones como datos de tratamiento especialmente restringido. Un agente que los lee no está operando sobre un dato comercial cualquiera: está operando en la franja de mayor riesgo legal de la empresa.

4. Cómo se arma el gobierno, capa por capa

El gobierno de un agente no es un documento: es una cadena de siete controles, cada uno de los cuales debe poder demostrarse por separado. Esta es la secuencia, en el orden en que ocurre una petición real.

Capa 1 — Identidad: quién está preguntando, de verdad

La conexión entre el asistente y el ERP se autoriza con un flujo de OAuth 2.1 con PKCE, no con una clave copiada en un archivo de configuración. La diferencia práctica para la dirección es que la autorización queda ligada a una persona identificada del ERP, se puede revocar en cualquier momento y no vive en un documento compartido. En SFUN, además, el registro del cliente fuerza la pantalla de consentimiento: no existe la conexión silenciosa que se autoriza sola.

Capa 2 — Habilitación: nadie entra por estar autenticado

Estar autenticado no basta. Hace falta una habilitación explícita: un rol dedicado que dice “esta persona puede operar por agente”. En SFUN ese rol es MCP User, se evalúa en cada petición y antes de leer el contenido del mensaje, y su ausencia devuelve un rechazo que queda escrito en el registro de errores. Como se lee en cada llamada y no dentro del token, quitarle el rol a alguien corta su acceso en la siguiente petición, sin esperar a que expire nada. Eso es lo que hace que la palabra “revocar” signifique algo.

Capa 3 — Herencia: los permisos son los de la persona, no los del agente

Es la capa que resuelve el error número uno. Cada lectura y cada escritura del agente pasan por el mismo motor de permisos que usa la interfaz: roles por documento, enmascaramiento de campos por nivel —un campo restringido sencillamente no se devuelve—, permisos por registro y documentos compartidos. Hasta el descubrimiento está filtrado: cuando el agente pregunta qué puede consultar, recibe solo la lista de lo que ese usuario puede leer, con las acciones que ese usuario puede ejecutar. El agente no ve un mapa completo del ERP con puertas cerradas; ve un mapa recortado.

Capa 4 — Catálogo cerrado: lo prohibido no existe, no está prohibido

Aquí es donde el error número dos se resuelve por construcción. El agente no puede invocar cualquier función del sistema: solo las que están en una lista blanca curada. En SFUN son 466 métodos habilitados, y hay una lista negra de 694 funciones bloqueadas que salió de una auditoría de seguridad con severidad y categoría por función —inyección de SQL, acceso indebido a registros de otros—. Entre las bloqueadas están todas las que ejecutan cobros: el agente no puede cargar una tarjeta ni activar un débito automático porque esa capacidad no está en su catálogo, no porque se le haya pedido que no lo haga.

El principio general lo formuló bien el equipo de ingeniería de Block —una empresa de pagos, es decir, gente que responde ante un regulador— en su guía de diseño de servidores MCP: una herramienta, un nivel de riesgo, sin mezclar lectura y escritura en la misma capacidad, porque mezclarlas confunde al usuario y hace imposible configurar los permisos. Y una segunda regla suya que traduce sola al sector funerario: todos sus servidores internos son escritos y auditados por sus propios ingenieros, y ninguno entra a producción sin doble revisión, una técnica y otra de seguridad.

Capa 5 — Separación entre consultar y ejecutar

En la práctica funeraria, la línea es fácil de trazar y conviene trazarla en el papel antes que en el sistema. Consultar —cuántas salas están ocupadas hoy, qué contratos vencen esta semana, cómo va la cartera de la sede— es de riesgo bajo y puede autorizarse de manera permanente. Preparar —redactar el borrador de una factura, dejar propuesto un plan de pagos, armar el reporte del comité— es de riesgo medio: produce un documento que todavía no tiene efecto. Ejecutar —emitir, anular, cobrar, cambiar titularidad, cerrar nómina— es irreversible y no debería ocurrir sin una firma humana.

SFUN aplica hoy esa separación como convención de diseño en las acciones sensibles: crear una factura la deja en borrador y no la emite; registrar un pago lo deja sin confirmar; crear un contrato inicial no lo somete. Es una decisión deliberada y correcta. Y es también, por transparencia, una convención y no un candado: nada impide que, acto seguido, se invoque la operación que confirma. La diferencia entre convención y candado importa, y volvemos sobre ella en la sección de hoja de ruta.

Capa 6 — Límites de volumen: la protección que casi nadie pide y todos necesitan

Un agente no necesita permisos indebidos para causar un problema de privacidad: le basta con poder extraer mucho a la vez. Por eso los topes importan tanto como los permisos. En SFUN, una consulta de listado devuelve como máximo 50 registros; un reporte se trunca a 200 filas; cualquier respuesta se corta a 50.000 bytes con aviso explícito; una agregación admite hasta 20 grupos; y la consulta libre en SQL está restringida a un rol privilegiado, admite solo lectura y devuelve un puñado de filas. La subida de archivos va por una URL firmada de un solo uso con vencimiento de diez minutos y tope de tamaño.

Vale la pena entender por qué esto es una protección y no una limitación molesta: un agente que solo puede traer 50 filas por consulta puede responder preguntas de gestión pero no puede vaciar tu base de datos en una conversación. Es la diferencia entre una herramienta de análisis y un canal de exfiltración.

Capa 7 — Entrada no confiable: el correo que le da órdenes a tu agente

Esta capa es la menos intuitiva para un comité de dirección y la que más rápido se entiende con un ejemplo. La investigación de seguridad sobre MCP ha documentado el envenenamiento de herramientas: instrucciones maliciosas escondidas en la descripción de una herramienta —no en los datos que devuelve—, que el modelo lee y obedece como si vinieran de su dueño. Un trabajo de modelado de amenazas publicado en 2026 lo identifica como la vulnerabilidad más prevalente del lado del cliente, evaluada sobre siete clientes MCP importantes.

El mismo mecanismo aplica al contenido ordinario. El correo de una funeraria corresponsal, el PDF que manda una notaría, el campo de observaciones que llenó un tercero: todo eso es entrada no confiable. Si el agente la lee y además tiene permiso de escritura, cualquiera de esos textos puede convertirse en una instrucción. De ahí salen dos reglas simples: el catálogo de herramientas del ERP funerario debe ser cerrado y de origen conocido, sin conectores de terceros que se instalan solos; y los conectores se fijan en una versión revisada, sin actualización automática en producción —una extensión de asistente de programación llegó a publicarse con instrucciones para borrar sistemas de archivos, incorporadas por un aporte externo malicioso—.

5. Qué existe hoy en SFUN y qué todavía no

Esta es la sección que un artículo de proveedor normalmente no trae, y es justamente la que le sirve a un comité. La hicimos revisando el código, no el material comercial. Si estás evaluando cualquier software funerario —el nuestro incluido—, pide esta misma tabla a cada proveedor y observa cuál puede llenarla.

6. La lista de lo que nunca se automatiza

Todo modelo de gobierno necesita una lista corta, escrita y verificable de operaciones que ningún agente ejecuta sin firma humana, por conveniente que sea. Corta, porque una lista de cuarenta puntos no la respeta nadie. Escrita, porque lo que no está escrito se negocia caso por caso a las tres de la mañana. Y verificable, porque debe poder auditarse que se cumplió.

1. Emitir o modificar la autorización de cremación. Es un acto irreversible sobre un cuerpo humano y suele tener requisitos legales de firma. El agente puede preparar el expediente, verificar que estén los documentos y avisar qué falta; la autorización la firma una persona.
2. Registrar, transcribir o corregir la causa de muerte. Es dato de salud y con frecuencia proviene de un certificado médico. El agente puede leerlo para verificar consistencia; no lo escribe ni lo reinterpreta.
3. Cambiar la titularidad de una bóveda, lote o derecho de uso en el cementerio. Son derechos que duran décadas y generan conflicto familiar. El agente prepara el trámite y detecta inconsistencias en la sucesión; la transferencia la aprueba una persona con facultad para hacerlo.
4. Anular una factura emitida o generar una nota crédito. Tiene efecto tributario frente a la autoridad y consecuencias contables. El agente identifica el caso, arma el soporte y deja el documento listo; el envío lo autoriza el responsable.
5. Ejecutar un cobro, activar o cancelar un débito automático. En SFUN esto ya está resuelto por construcción: esas funciones no están en el catálogo del agente.
6. Cerrar o liquidar la nómina. Afecta el ingreso de personas concretas y tiene efectos laborales. El agente puede señalar novedades sin capturar, turnos que exceden un tope o inconsistencias de marcación; el cierre lo firma quien responde por él.
7. Comunicarse por iniciativa propia con la familia en las primeras horas del duelo. No es una restricción técnica: es de criterio. Ese contacto lo hace una persona.
8. Borrar cualquier registro. Sin excepciones y sin matices. Si algo debe desaparecer, lo decide y ejecuta una persona identificada, dejando constancia.

Hay una segunda medición que apunta al mismo lugar y describe con precisión una funeraria. Cuando estos agentes se evalúan en un entorno donde el control es compartido —donde el usuario también actúa sobre el mismo caso— su desempeño cae respecto del escenario en que operan solos. Un servicio funerario es exactamente eso: la familia, el médico, la notaría, el asesor y el coordinador de sede tocando el mismo expediente al mismo tiempo. Es el escenario menos favorable posible para la autonomía.

7. La traza: quién lo hizo, quién lo revisó y cuándo

La mejor formulación de lo que debe registrar un sistema no viene del mundo de la IA sino de la auditoría. La norma AS 1215 del PCAOB —la que rige la documentación de auditoría de compañías públicas en Estados Unidos— exige que la documentación demuestre claramente que el trabajo se realizó, quién lo realizó, quién lo revisó y en qué fecha se revisó. Es una frase de 1990 que describe con exactitud el problema de 2026.

Aplicada a un ERP funerario con agentes, esa exigencia se convierte en tres campos que ningún registro debería tener vacíos: qué agente lo hizo, bajo la identidad de qué persona y qué persona lo revisó y cuándo. Un registro que dice “generado por el sistema” no cumple ninguno de los tres. Y aquí está el correlato duro para la dirección: si mañana el auditor externo, la administración tributaria o un juez piden la trazabilidad de una factura o de una cremación, la respuesta no puede depender de los registros que guarde tu proveedor de inteligencia artificial. Tiene que estar en tu sistema, con tu retención y bajo tu control.

La misma figura eligió el reglamento europeo de IA para los sistemas de alto riesgo: el registro automático de acontecimientos a lo largo del ciclo de vida del sistema, pensado para identificar riesgos y permitir el seguimiento posterior. Con el aplazamiento de julio de 2026 esa obligación se aplica desde diciembre de 2027, lo que en la práctica significa que un grupo funerario que empiece a construir su traza este año llega con holgura, y que el argumento de urgencia inmediata que usan algunos proveedores no se sostiene: el argumento verdadero es que sin traza no hay adopción segura, no que haya una multa la semana que viene.

8. El botón de apagado tiene dueño y nombre

El marco de gestión de riesgo de IA del NIST incluye una subcategoría que casi nadie menciona en una demostración comercial y que es la que más rápido revela si hay gobierno de verdad: exige mecanismos y responsabilidades asignadas para anular, desconectar o desactivar sistemas de IA cuyo comportamiento sea inconsistente con el uso previsto. Junto con ella, el marco pide que los procesos de supervisión humana estén definidos, evaluados y documentados, y que los incidentes se comuniquen y se registren.

En SFUN esa palanca existe y es sencilla de operar, lo que conviene decir con nombre propio: quitar el rol de habilitación al usuario corta el acceso del agente en la siguiente petición, y revocar la autorización desconecta al cliente. No hace falta un despliegue, ni una ventana de mantenimiento, ni el proveedor. Lo que hace falta es que esté escrito quién puede hacerlo y que esa persona lo haya practicado al menos una vez.

9. El bucle: el gobierno se revisa, no se instala

Como todos los casos de este cluster, este también tiene un ciclo de mejora continua. La diferencia es que aquí lo que mejora no es la respuesta del agente: es el ajuste entre lo que el agente puede hacer y lo que debería poder hacer, que se desalinea solo con el tiempo, a medida que se agregan sedes, se contratan personas y se abren módulos nuevos.

El ejercicio más rentable de esa tabla es el más aburrido: la revisión de autorizaciones activas. En cualquier grupo con rotación normal aparecen, a los pocos meses, conexiones de personas que ya no están, de proyectos que se cancelaron y de pruebas que nadie cerró. Cada una de ellas es una puerta abierta con permisos heredados de alguien que ya no responde por ellos.

10. KPIs del gobierno, con línea base y meta

Un modelo de gobierno que no se mide es una declaración de intenciones. Estos son los indicadores que un comité puede pedir cada trimestre, con la línea base típica de un grupo que empieza —que casi siempre es “no se sabe”, y eso ya es un hallazgo— y una meta razonable.

11. Hoja de ruta de adopción

Semana 1 — Ordenar lo que ya existe

• Inventaria las conexiones activas de agentes y asígnale un dueño a cada una. Revoca las que no lo tengan.
• Verifica con qué usuario está autorizado cada agente de producción. Si alguno usa la cuenta de administrador, cámbialo esta semana: es el hallazgo más frecuente y el más grave.
• Crea usuarios dedicados por dominio —consulta de operación, análisis de cartera, apoyo contable— con los permisos mínimos de un empleado de ese puesto, y reautoriza los agentes con ellos.
• Escribe la lista de lo que nunca se automatiza, en una página, y hazla firmar por la dirección.
• Nombra al responsable del apagado, con suplente. Que ambos hagan el ejercicio una vez.

Mes 1 — Recortar el alcance y practicar

• Activa el modo de solo lectura en los agentes que solo consultan. Es una decisión de configuración y elimina de un golpe toda una categoría de riesgo.
• Revisa el enmascaramiento de los campos más sensibles del expediente —causa de muerte y anotaciones clínicas en primer lugar— para que no viajen en respuestas donde no aportan nada.
• Corre la primera auditoría por muestra: veinte documentos del periodo, contrastados contra su historial de cambios, buscando operaciones que debieron llevar firma.
• Documenta el procedimiento de incidentes: qué se hace, en qué orden y a quién se avisa si un agente ejecuta algo indebido. Practicarlo importa más que redactarlo bien.
• Fija las versiones de los conectores en producción y desactiva su actualización automática.

Trimestre 1 — Cerrar los huecos estructurales

• Exige a tu proveedor —a nosotros incluidos— un calendario escrito para el registro de las acciones del agente y para la trazabilidad de consultas. Si no hay fecha, no hay compromiso.
• Define los umbrales que deberían obligar a confirmación humana en tu operación: por monto de factura, por tipo de documento, por acto irreversible. Aunque hoy el bloqueo no exista del lado del servidor, tener el umbral definido es lo que permite exigirlo y verificarlo.
• Incorpora la revisión de autorizaciones activas al calendario de control interno, junto al arqueo de caja y a la conciliación bancaria. Es del mismo tipo de control y merece el mismo lugar.
• Lleva al comité el primer informe de gobierno con los indicadores de la sección anterior. Que la línea base diga “no se mide” en varias filas es normal la primera vez, y es exactamente el punto de partida que hace falta.

12. Los cinco errores más comunes al implantar el gobierno

1. Escribir la política antes de mirar la configuración. Un documento de veinte páginas aprobado por el comité mientras el agente de producción sigue autorizado con la cuenta de administrador no gobierna nada. Primero se mira lo que hay; después se escribe.
2. Confundir el consentimiento con el control. Que alguien haya aceptado una pantalla de autorización no dice nada sobre qué puede hacer esa conexión. El consentimiento abre la puerta; los permisos definen las habitaciones.
3. Poner la lista de prohibiciones en las instrucciones del agente. Ya lo dijimos y vale repetirlo porque es el error que más caro sale: lo prohibido no se escribe, se elimina del catálogo.
4. Dejar el gobierno en manos exclusivamente técnicas. Qué se automatiza y qué no es una decisión de dirección, no de sistemas. Sistemas ejecuta el recorte; la dirección decide dónde va la línea y responde por ella.
5. Aceptar “es auditable” sin pedir el ejemplo. La pregunta correcta a cualquier proveedor no es si registra la actividad, sino: muéstrame el registro de una consulta hecha ayer, dime en qué tabla de mi sistema vive, cuánto tiempo se conserva y quién puede leerlo. Es una pregunta que se responde en la demostración o no se responde.

Preguntas frecuentes

¿Es seguro dejar que un agente de IA opere el ERP de una funeraria?

Es tan seguro como el recorte de permisos con que lo conectes, y no más. Un agente que opera con la identidad de una persona concreta, con un catálogo cerrado de operaciones, sin capacidad de ejecutar cobros ni de borrar registros y con topes de volumen por consulta es razonablemente seguro para consultar y preparar trabajo. El mismo agente autorizado con una cuenta de administrador es un riesgo, y el riesgo no lo introdujo la IA: lo introdujo la decisión de con qué usuario se autorizó.

¿El agente puede ver datos que un empleado no puede ver?

No debería, y en SFUN no lo hace: cada lectura pasa por el mismo motor de permisos de la interfaz, incluido el enmascaramiento de campos restringidos, que sencillamente no se devuelven. La salvedad importante y honesta es la de siempre: eso vale para el usuario con que se autorizó la conexión. Si ese usuario ve todo, el agente ve todo.

¿Queda registro de lo que hace el agente?

Parcialmente, y conviene ser preciso. Todo cambio de datos queda registrado campo a campo con su autor y su fecha, en 292 tipos de documento del dominio, y ese registro es el que sirve para reconstruir qué pasó con un contrato o con un expediente. Lo que hoy no queda es un registro de las llamadas del agente como tal —qué herramienta invocó, con qué argumentos— ni de las consultas de lectura. Es hoja de ruta, no una función disponible, y así hay que evaluarlo.

¿Puedo limitar un agente a solo consultar, sin que pueda modificar nada?

Sí. Hay dos caminos y conviene usar los dos: conectar el agente con un usuario cuyos permisos sean únicamente de lectura —que es el camino robusto, porque lo garantiza el motor de permisos del ERP— y activar además el modo de solo lectura del servidor, que retira del catálogo toda operación de escritura. El interruptor existe y hoy no viene activado por defecto: pedirlo es parte de la puesta a punto.

¿Qué pasa si un empleado sale de la compañía?

Su agente debe morir con él, y ese es uno de los argumentos más fuertes a favor de la identidad heredada. Al desactivar el usuario o retirarle el rol de habilitación, la conexión deja de funcionar en la siguiente petición. Con el esquema de usuario robot compartido ocurre lo contrario: la persona se va y su acceso sigue vivo, sin dueño, hasta que alguien se acuerda. Por eso la revisión de autorizaciones activas debe entrar al mismo procedimiento de salida que la entrega del computador y el retiro de la tarjeta de acceso.

¿Necesito una política de IA formal para adoptar esto?

Necesitas cuatro cosas escritas, que caben en dos páginas: quién puede autorizar un agente y con qué usuario; la lista de lo que nunca se automatiza; quién supervisa y quién apaga, con nombre y suplente; y con qué cadencia se revisa todo lo anterior. Una política extensa que no responda esas cuatro preguntas no sirve; dos páginas que las respondan, sí. La política formal completa vendrá después, cuando el sector la exija o cuando un cliente corporativo la pida en una licitación.

¿Esto aplica igual en todos los países de Latinoamérica?

El modelo de gobierno sí: permisos heredados, catálogo cerrado, firma humana en lo irreversible y traza son buenas prácticas independientes de la jurisdicción. Lo que cambia por país es el marco de datos personales y sus plazos —Perú con su Oficial de Datos Personales, Chile con la entrada en vigencia de diciembre de 2026, Colombia con su régimen de habeas data y una autoridad que ya ha sancionado casos de circulación indebida de datos de salud—. La recomendación práctica es construir el gobierno con el estándar más exigente que te aplique y no país por país: sale más barato y evita tener sedes con reglas distintas.

Fuentes

• Model Context Protocol — Roadmap oficial, sección “Enterprise Readiness” (página actualizada el 2026-03-05, consultada el 3 de agosto de 2026): trazas de auditoría y observabilidad, autenticación gestionada por la empresa, patrones de gateway y proxy, y portabilidad de configuración, listados como áreas sin resolver: modelcontextprotocol.io.
• Reglamento (UE) 2026/1744 del Parlamento Europeo y del Consejo, de 8 de julio de 2026, por el que se modifican los Reglamentos (UE) 2024/1689, (UE) 2018/1139 y (UE) 2023/1230 (Digital Omnibus on AI), DOUE de 24 de julio de 2026: aplaza la aplicación de las secciones 1 a 3 del Capítulo III al 2 de diciembre de 2027 (Anexo III) y al 2 de agosto de 2028 (Anexo I): eur-lex.europa.eu.
• Reglamento (UE) 2024/1689 (Reglamento Europeo de IA), artículo 12 (registro automático de acontecimientos) y artículo 14 (supervisión humana): eur-lex.europa.eu.
• PCAOB — AS 1215, Audit Documentation, párrafo .06: la documentación debe demostrar quién realizó el trabajo, quién lo revisó y la fecha de esa revisión: pcaobus.org.
• NIST — AI Risk Management Framework 1.0, subcategorías GOVERN 2.1, MAP 3.5, MANAGE 2.4 (mecanismos y responsabilidades para anular, desconectar o desactivar), MANAGE 4.1 y MANAGE 4.3: airc.nist.gov.
• S. Yao, N. Shinn, P. Razavi y K. Narasimhan, “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains”, arXiv 2406.12045 — menos del 50 % de tareas resueltas y pass^8 por debajo del 25 % en el dominio minorista: arxiv.org.
• V. Barres et al., “τ²-bench: Evaluating Conversational Agents in a Dual-Control Environment”, arXiv 2506.07982 — degradación del desempeño cuando el control del entorno es compartido con el usuario: arxiv.org.
• F. F. Xu et al., “TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks”, arXiv 2412.14161 — alrededor del 30 % de tareas profesionales completadas de forma autónoma: arxiv.org.
• K. Huang, J. Huang, N. Tran y A. Milani Fard, “Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning”, arXiv 2603.22489 — el envenenamiento de herramientas como vulnerabilidad más prevalente del lado del cliente: arxiv.org.
• Pinterest Engineering — “Building an MCP Ecosystem at Pinterest” (19 de marzo de 2026): autorización en dos capas con token del usuario final, validación de pertenencia a grupo antes de aceptar la conexión y aprobación humana previa a la ejecución: medium.com/pinterest-engineering.
• Block Engineering — “Block’s Playbook for Designing MCP Servers” (16 de junio de 2025): una herramienta, un nivel de riesgo; separación entre lectura y escritura; doble revisión antes de producción: engineering.block.xyz.
• Superintendencia de Industria y Comercio (Colombia) — sanción por divulgación de la historia clínica de un paciente a directivos de su empleador, por violación de los principios de necesidad, finalidad y circulación restringida: sic.gov.co.
• Perú — Resolución Directoral 100-2025-JUS/DGTAIPD, directiva sobre designación y funciones del Oficial de Datos Personales, con plazo de adecuación hasta el 30 de junio de 2026: gob.pe.
• Chile — Ley 21.719 sobre protección y tratamiento de datos personales, con entrada en vigencia el 1 de diciembre de 2026: bcn.cl.
• The Register — “Vibe coding service Replit deleted production database, faked data, told fibs galore” (21 de julio de 2025): el agente reconoció el congelamiento de código y borró igual, y después generó datos e informes falsos: theregister.com.