Casi ningún grupo funerario decide que una misma persona cobre, anule, condone y concilie. Ocurre por acumulación: alguien cubre unas vacaciones, una sede pequeña se queda con un solo administrativo, se abre una sucursal y se copia el usuario «que ya funciona». Este caso de uso muestra cómo un asistente de IA conectado al ERP por SFUN MCP ayuda a responder dos preguntas distintas: quién puede hacer dos cosas que no deberían estar juntas, y quién las hizo de verdad en el último trimestre. Retirar un permiso, y sobre todo sacar conclusiones sobre una persona, sigue siendo trabajo de la dirección.
Está escrito para la dirección financiera, la contraloría y la auditoría interna de un grupo funerario con varias sedes, cobradores en campo y cartera de previsión. Sigue el formato de los casos de este blog: problema, datos, pasos, bucle de mejora, límites, indicadores y hoja de ruta. Dice con claridad qué hace hoy el producto y qué no: SFUN no trae un informe de roles incompatibles; lo que sigue es una revisión armada con lecturas del ERP y criterio humano.
1. El problema de negocio: el permiso que nadie retiró
La segregación de funciones es la idea más vieja del control interno: quien custodia el dinero no lo registra, quien lo registra no autoriza los reversos y quien concilia no hizo ninguna de las tres cosas. La guía de segregación de funciones de la Oficina del Auditor del Estado de Washington lo resume, para una caja, en cuatro funciones que conviene repartir: custodia, registro, conciliación y autorización de anulaciones y devoluciones.
El costo de no hacerlo está medido. El informe Occupational Fraud 2024 de la ACFE, sobre 1.921 casos de 138 países, encontró que el factor que más contribuyó a los fraudes estudiados fue la falta de controles internos (32 %), seguido de la elusión de controles que sí existían (19 %): más de la mitad de los casos entre los dos. El mismo informe señala que las organizaciones de menos de 100 empleados tienen con menos frecuencia los controles antifraude habituales, entre ellos la segregación de funciones. Una sede funeraria con cuatro personas es, para estos efectos, una organización pequeña dentro de una grande.
En una funeraria el riesgo tiene forma conocida. Quien recibe una cuota en efectivo y además puede anular el recibo puede quedarse con el dinero y borrar el rastro. Quien cobra y además condona saldos puede hacer que una deuda desaparezca sin que entre un peso. Quien cuenta la caja y además revisa el arqueo se revisa a sí mismo. Nada de esto prueba que alguien lo esté haciendo: prueba que, si ocurriera, nadie más lo vería. Por eso la revisión no es una investigación; es mantenimiento.
Las combinaciones que importan en un grupo funerario
| Función A | Función B | Qué permite si coinciden en una persona |
|---|---|---|
| Registrar el cobro (crear y validar el recibo) | Anular o corregir el recibo | Recibir el dinero y borrar el registro |
| Registrar el cobro | Condonar saldos, ajustar el valor del contrato o reprogramar | Cerrar una deuda sin que el dinero entre |
| Custodiar la caja | Hacer o revisar el arqueo y el cierre de caja | Revisarse a sí mismo |
| Registrar cobros o pagos | Conciliar el banco | Ocultar una diferencia en la conciliación |
| Administrar usuarios y permisos | Cualquier función de dinero | Darse el permiso, usarlo y retirárselo |
Esta tabla es editorial: es el punto de partida que proponemos, no una regla del sistema. Cada grupo debe escribir la suya, y la escribe la dirección financiera con auditoría, no el área de sistemas.
2. Qué datos del ERP intervienen
SFUN está construido sobre un marco en el que cada documento tiene permisos por rol (leer, crear, validar, cancelar, corregir) y cada usuario tiene uno o varios roles. Para este caso importan tres familias de datos.
| Dato | Dónde vive | Para qué sirve | Límite que hay que conocer |
|---|---|---|---|
| Roles de cada usuario | Ficha del usuario | Saber quién puede qué | De fábrica solo lo lee quien administra el sistema |
| Permisos de cada rol sobre cada documento | Administrador de permisos de rol | Saber qué combinación de roles es peligrosa | Si el sitio personalizó los permisos de un documento, esos reemplazan por completo a los de fábrica |
| Quién creó cada recibo | Creador del recibo de caja de previsión y del recibo de caja del parque | La mitad «quién cobró» | En previsión el creador cambia si el recibo se reasigna a otro usuario; el anterior queda guardado en el propio recibo |
| Quién anuló | Campo «cancelado por», con motivo y fecha y hora, en el recibo de previsión y en la bitácora de recibos cancelados | La mitad «quién anuló» | Existe desde mediados de septiembre de 2026; las anulaciones anteriores no lo tienen. En el parque no existe: solo el último usuario que modificó y el historial de versiones |
| Condonaciones, ajustes al contrato y reprogramaciones | Documentos propios de previsión y cartera | Quién cerró o cambió una deuda | Guardan quién los creó; no tienen un campo de «aprobado por» |
| Arqueos y cierres de caja | Arqueo de caja del parque, arqueo de caja general, cierre de caja | Quién contó y quién revisó | El arqueo del parque tiene cajero y «revisado por» como campos; conviene comprobar que no coincidan |
Lo que viene de fábrica y por qué hay que mirarlo
Los permisos de fábrica son un punto de partida que cada compañía ajusta en la implantación. Dos de ellos merecen una mirada antes que cualquier otra cosa:
- Recibo de caja de previsión. De fábrica lo crea y lo valida el rol de cobrador, y solo el administrador del sistema puede anularlo o corregirlo. Es una separación fuerte, pero tan estricta que casi todos los sitios la abren para que caja o cartera puedan anular. La pregunta es a quién se le abrió.
- Recibo de caja y arqueo del parque cementerio. De fábrica, un mismo rol contable genérico puede crear, validar, anular y corregir el recibo, hacer el arqueo y usar las herramientas estándar de conciliación. Aquí la separación no viene dada: hay que construirla con roles propios.
El producto tiene hoy una sola regla de segregación integrada, y está en ventas, no en caja: en la aprobación del contrato inicial, el asesor que vendió no puede aprobar su propio contrato, si la compañía activa esa opción. No existe una regla equivalente que impida que quien creó un recibo lo anule, ni un flujo de aprobación de fábrica sobre anulaciones, condonaciones o ajustes. El marco sí permite configurar flujos de aprobación por documento; es trabajo de implantación, no algo que venga encendido.
3. Cómo se arma el caso con MCP, paso a paso
Con SFUN MCP cada persona se conecta con su propio usuario y el asistente hereda exactamente sus permisos: no hay un usuario de servicio que lo vea todo. Eso define quién hace cada paso.
Paso 0: escribir la matriz de incompatibilidades
Antes de consultar nada, la dirección financiera y auditoría escriben en una página qué pares de funciones no deben coincidir (la tabla de arriba, adaptada) y qué excepciones aceptan, con su control compensatorio: por ejemplo, «en sedes de menos de tres administrativos, caja puede anular, y contraloría revisa cada lunes todas las anulaciones de esa sede». Sin esta página, la revisión produce una lista de nombres y ninguna decisión.
Paso 1: traducir funciones a roles (lo hace el administrador)
«Anular recibos» no es un rol: es un permiso que tienen uno o varios roles sobre uno o varios documentos. Quien administra el sistema abre el administrador de permisos de rol y anota, para cada documento de dinero, qué roles pueden crear, validar, cancelar y corregir. Este paso no lo resuelve hoy el conector: al preguntar por un documento, SFUN MCP devuelve lo que puede hacer quien pregunta, no la matriz completa por rol. Son diez o quince documentos y se hace una vez; después solo se actualiza cuando cambia un permiso.
Paso 2: quién reúne roles que no deben coincidir
Con la traducción hecha, el administrador del sistema (o un auditor al que se le dio ese nivel de lectura) le pide al asistente la lista de usuarios activos con sus roles y la cruza con la matriz del paso 0. Una petición típica: «De los usuarios activos, dime cuáles tienen a la vez un rol que crea recibos de previsión y un rol que los cancela; sepáralos por sede». El resultado es una tabla corta: usuario, sede, roles que chocan, par incompatible.
Paso 3: quién lo hizo de verdad
Tener el permiso no es usarlo. La segunda mitad la puede consultar quien tenga lectura sobre recibos y bitácora, con su propio usuario:
- Anulaciones por usuario. Cuántos recibos de previsión anuló cada usuario en el trimestre, agrupando la bitácora de recibos cancelados por «cancelado por». El conector agrupa y devuelve hasta veinte grupos por consulta: se pide por sede para que quepa.
- Creó y anuló. De los recibos anulados, cuáles tienen el mismo usuario como creador y como «cancelado por». Antes de leer el resultado, hay que apartar los recibos reasignados (el recibo guarda el usuario anterior) y las anulaciones automáticas de cargues y reversos.
- Cobra y condona. Qué usuarios aparecen como creadores de recibos y también de condonaciones o ajustes al valor del contrato en el mismo período.
- Cuenta y revisa. En los arqueos de caja del parque, en cuántos coincide el cajero con quien revisó.
- Parque cementerio. Recibos del parque anulados en el trimestre y último usuario que los modificó, sabiendo que ese dato es más débil que el de previsión.
Las listas largas no caben en una respuesta: el conector devuelve hasta 50 documentos por página y 200 filas por informe. Para un grupo grande, lo práctico es que sistemas deje un informe guardado y que el asistente lo ejecute cada trimestre.
Paso 4: la ficha de cada hallazgo y la decisión
Por cada usuario con un par incompatible, el asistente arma una ficha de media página: roles, desde cuándo si se puede saber, cuántas veces usó cada lado del par en el trimestre y la explicación más probable (sede pequeña, reemplazo, usuario heredado). La dirección financiera elige una de tres salidas y la deja escrita: retirar el permiso, mantenerlo con un control compensatorio con responsable y frecuencia, o aceptar el riesgo con firma. El cambio de permiso lo hace una persona en el sistema.
4. El bucle de mejora continua
| Frecuencia | Qué se revisa | Quién |
|---|---|---|
| Cada semana | Anulaciones, condonaciones y ajustes de las sedes con excepción aceptada (el control compensatorio) | Contraloría, con su usuario |
| Cada mes | Altas, bajas y cambios de rol del mes; usuarios de personas que ya no están | Administrador del sistema y recursos humanos |
| Cada trimestre | La revisión completa: pasos 2 a 4, y firma de las excepciones | Dirección financiera y auditoría interna |
| Cada año o con cada módulo nuevo | La matriz de incompatibilidades del paso 0 y la traducción a roles del paso 1 | Dirección financiera, auditoría y sistemas |
Lo que mejora con cada vuelta es la matriz, no el asistente. Cada excepción que se repite tres trimestres es una señal de que falta un rol bien diseñado («caja de sede pequeña», por ejemplo) y de que conviene crearlo en vez de seguir firmando la misma excepción.
5. Gobierno y límites: lo que el asistente nunca hace
- No cambia permisos ni roles. La revisión se hace con el conector en modo de solo lectura para el sitio o con un usuario sin permisos de escritura sobre usuarios. Un asistente que pudiera asignar roles sería el rol incompatible más grave de todos.
- No señala culpables. «Creó y anuló el mismo recibo» describe un hecho con explicaciones inocentes frecuentes (un error de digitación corregido en el momento). La ficha lo dice así. Cualquier conversación con la persona la tiene su jefe o auditoría, con contexto.
- No ve más que quien pregunta. Cada consulta corre con los permisos del usuario conectado. Si alguien obtiene la lista de roles de toda la compañía, es porque ya tenía ese acceso.
- Los resultados son información sensible del personal. La tabla de usuarios con funciones incompatibles se guarda donde se guardan los papeles de auditoría, no en un chat de grupo.
- El asistente también es un acceso que se revisa. El principio de mínimo privilegio aplica a los agentes igual que a las personas: la guía de OWASP para aplicaciones con modelos de lenguaje llama «agencia excesiva» a darles más funciones, permisos o autonomía de los necesarios, y la especificación de MCP recomienda empezar con el alcance mínimo de lectura. En la revisión trimestral, la lista de usuarios con el rol que habilita el conector es una fila más.
6. KPIs para saber si funcionó
| Indicador | Cómo se calcula | Línea base | Meta razonable |
|---|---|---|---|
| Usuarios con al menos un par incompatible | Usuarios activos con roles que chocan según la matriz | La primera revisión | Reducción clara en dos trimestres; el resto, con excepción firmada |
| Excepciones sin control compensatorio | Pares incompatibles aceptados sin responsable ni frecuencia de revisión | La primera revisión | Cero |
| Recibos creados y anulados por el mismo usuario | Anulados del trimestre con creador igual a «cancelado por», sin reasignados ni automáticos, sobre el total de anulados | El trimestre anterior | A la baja, y todos con motivo registrado |
| Usuarios activos de personas que ya no trabajan en la compañía | Cruce mensual de usuarios activos con la nómina | El primer mes | Cero al cierre de cada mes |
| Usuarios con administración del sistema | Conteo de usuarios con ese nivel | Hoy | El mínimo que permita operar, con nombre y motivo |
| Días para ejecutar una decisión de retiro | Desde la firma de la decisión hasta el cambio del permiso | La primera revisión | Menos de cinco días hábiles |
No existe una cifra publicada de cuántos pares incompatibles son «normales» en una funeraria, y no la inventamos: la línea base es tu primera revisión.
7. Hoja de ruta de adopción y errores comunes
- Semana 1. Escribir la matriz de incompatibilidades y la lista de documentos de dinero. Activar, si no lo está, la opción que exige motivo al anular recibos de caja de previsión.
- Mes 1. Traducir funciones a roles, hacer la primera revisión de permisos y decidir quién, además de sistemas, puede leer usuarios y roles. Dar de baja los usuarios huérfanos.
- Trimestre 1. Primera revisión de hechos con un trimestre de datos, primeras excepciones firmadas con su control compensatorio y, donde se repitan, roles nuevos para sedes pequeñas. Revisar el parque cementerio como proyecto aparte.
Errores comunes. Revisar solo permisos y no hechos, o al revés. Copiar el usuario de un empleado para crear el de otro. Resolver la sede pequeña dándole a una persona el nivel de administrador. Prestar el usuario administrador a auditoría «solo para la revisión». Tratar la lista de hallazgos como una lista de sospechosos. Y olvidar que los permisos personalizados de un documento reemplazan a los de fábrica: la matriz se lee del sitio real, no del manual.
Lo que falta construir: la hoja de ruta de producto
Para que esta revisión deje de depender de pasos manuales harían falta piezas que hoy no existen en SFUN, y que presentamos como hoja de ruta, no como función disponible: un informe de roles por usuario que auditoría pueda ejecutar sin ser administrador del sistema; la matriz de permisos por rol consultable desde el conector; una regla opcional que impida anular un recibo a quien lo creó, como la que ya existe para el contrato inicial; «cancelado por» y bitácora en el recibo del parque; un campo de aprobación en condonaciones y ajustes, y un registro de las consultas hechas por el conector.
De dónde sale el patrón: la revisión de accesos en otros sectores
La banca, el sector público y las empresas de software llevan años haciendo lo que aquí se propone, con otros nombres:
- Sector público. La guía del Auditor del Estado de Washington recomienda, para las cajas, documentar cada anulación y devolución, revisarlas periódicamente, exigir aprobación de la gerencia por encima de un monto y conservar el rastro de los recibos anulados. Para oficinas de una a tres personas propone un revisor independiente como compensación. Es, casi literalmente, la excepción firmada del paso 0.
- Marco de control interno. COSO lo admite sin rodeos: «Where segregation of duties is not practical, management selects and develops alternative control activities». Separar es lo ideal; cuando no se puede, se compensa y se deja escrito.
- Seguridad de la información. El catálogo de controles NIST SP 800-53 pide documentar las funciones que requieren separación (AC-5) y revisar los privilegios con una frecuencia definida (AC-6). En las empresas de software esto es la «revisión de accesos de usuarios», habitualmente trimestral o anual.
- Gestión de identidades. Los proveedores de identidad ya tratan a los agentes de IA como una identidad más en sus campañas de certificación de accesos, y sus conectores MCP habilitan herramientas según el alcance concedido, con el de solo lectura como punto de partida. Lo que en una empresa de software es «certificar quién accede a producción», en una funeraria es «certificar quién puede anular un recibo».
Una advertencia honesta: no encontramos un caso publicado, con cifras medidas por un tercero, de una revisión de segregación de funciones ejecutada por un agente a través de MCP. El patrón existe por piezas. Lo que este artículo describe es una forma razonable de juntarlas sobre los datos que el ERP ya guarda.
Preguntas frecuentes
¿Qué es un rol incompatible en una funeraria?
Es la combinación, en una misma persona, de dos funciones que juntas permiten cometer un error o un desvío y ocultarlo: cobrar y anular recibos, cobrar y condonar saldos, custodiar la caja y revisar su arqueo, registrar pagos y conciliar el banco, o administrar permisos y operar dinero.
¿SFUN tiene un informe de segregación de funciones?
No. SFUN tiene permisos por rol sobre cada documento, registra quién creó y quién anuló cada recibo de caja de previsión, y trae una regla opcional para que el asesor no apruebe su propio contrato inicial. La revisión de roles incompatibles se arma con consultas sobre esos datos, como se describe aquí, o con un informe a la medida.
¿Puede el asistente de IA decirme qué permisos tiene cada rol?
Hoy no de forma directa. Al preguntar por un documento, el conector devuelve las acciones permitidas al usuario que consulta, y también te dice qué roles tiene tu propio usuario. La matriz completa de permisos por rol se lee en el administrador de permisos del sistema y la prepara quien lo administra.
¿Qué hago en una sede con una sola persona administrativa?
Aceptar que no puedes separar y compensar: que alguien de otra sede o de contraloría revise cada semana todas las anulaciones, condonaciones y ajustes de esa sede, que el arqueo lo revise un tercero y que la excepción quede firmada con responsable y frecuencia. Las vacaciones obligatorias y la rotación ayudan a que un problema salga a la luz.
¿Cada cuánto conviene revisar los accesos?
La revisión completa, cada trimestre; las altas, bajas y cambios de rol, cada mes; y los controles compensatorios de las excepciones, cada semana. La matriz de incompatibilidades se vuelve a escribir una vez al año o cuando se implanta un módulo nuevo.
¿Quién debe poder ver la lista de usuarios con roles incompatibles?
La dirección financiera, auditoría interna y quien administra el sistema. Es información sensible del personal: describe accesos, no conductas, y debe tratarse con la misma reserva que un papel de trabajo de auditoría.
En resumen
Los permisos se acumulan solos y nadie los retira si nadie los mira. Una revisión trimestral con dos mitades —quién puede y quién lo hizo— cabe en una tarde si la matriz de incompatibilidades está escrita y el ERP guarda quién creó y quién anuló. El asistente conectado por MCP acelera las lecturas y arma las fichas; la matriz, las excepciones y cada cambio de permiso son decisiones de personas. Si quieres ver el resto del ciclo, sigue con la analítica de anulaciones de recibos de caja, el control del efectivo del cobrador, la guía de control interno y prevención de pérdidas y el marco de gobierno de agentes de IA en el ERP funerario.
Fuentes de este artículo
- Association of Certified Fraud Examiners, Occupational Fraud 2024: A Report to the Nations: debilidades de control que contribuyeron al fraude (figura 37) y controles en organizaciones pequeñas. Leído en el PDF.
- Office of the Washington State Auditor, guía de segregación de funciones: funciones de caja, anulaciones y controles compensatorios. Lectura parcial.
- COSO, Internal Control — Integrated Framework, resumen ejecutivo (2013).
- NIST, SP 800-53 Rev. 5, controles AC-5 y AC-6.
- OWASP, LLM06:2025 Excessive Agency, y Model Context Protocol, Security Best Practices.
- Okta, certificación de accesos de agentes de IA (documentación del proveedor; se usa solo el patrón).
- Nashua Telegraph, 15 de septiembre de 2024 (prensa que cita a la fiscalía federal de New Hampshire).
- Producto: lo descrito de SFUN se verificó en el código de la versión principal el 10 de octubre de 2026. Los permisos «de fábrica» son los que trae el producto antes de la implantación; cada sitio puede tener otros. Las piezas que no existen figuran como hoja de ruta.