El sistema dijo que lo hizo: el fallo silencioso en la operación funeraria y cómo verificarlo con IA y MCP

En un parque cementerio, cuando se disuelve un contrato por incumplimiento, el espacio tiene que volver al inventario. Es una operación de dos segundos: el acta queda firmada, el sistema responde «el contrato quedó disuelto y su espacio vuelve a estar disponible», y la bóveda debería aparecer otra vez en la lista de lo vendible.

Durante un tiempo, esa frase fue mentira. La rutina que liberaba el espacio escribía el estado en un campo que no existía, y lo hacía dentro de una guarda del tipo «si el campo existe». Como no existía, la escritura se saltaba. Como se saltaba en silencio, el documento se marcaba a sí mismo como ejecutado. El espacio quedaba ocupado para siempre y el sistema afirmaba lo contrario. Una bóveda muerta por cada disolución.

No hubo ni un mensaje de error. No hubo un registro en el log. No hubo un usuario molesto llamando a soporte, porque desde el mostrador todo se veía bien. Esto no es un bug: es una clase de bug, y es la más cara que existe en un sistema que sostiene una operación real. Este artículo es el caso de uso completo de un agente de inteligencia artificial que, conectado al ERP por MCP y en solo lectura, hace la única pregunta que ningún reporte de la compañía hace hoy: lo que el sistema afirma que pasó, ¿pasó?

1. El problema de negocio: el error que no grita

Conviene empezar por lo que hace distinta a esta clase de fallo, porque de ahí sale todo el diseño del caso. Un error ruidoso tiene un descubridor natural: la persona a la que se le rompió el proceso. Ese descubridor es gratis y es inmediato. Un fallo silencioso no tiene descubridor: la persona del mostrador ve la confirmación, la persona de cartera ve el recibo cuadrado, la persona de dirección ve el reporte que suma. Los tres están mirando la afirmación del sistema, no su efecto.

Y hay una razón estructural por la que una operación funeraria es especialmente vulnerable: casi ningún efecto se verifica contra el mundo físico. Que una bóveda esté libre no lo comprueba nadie hasta que hay que usarla, y eso puede tardar años. Que una nota crédito llegara a la autoridad no lo comprueba nadie hasta que llega un requerimiento. Que un pago se aplicara a la cuota correcta no lo comprueba nadie mientras el saldo dé un número, cualquier número. En una fábrica el inventario se cuenta; en un camposanto, el inventario está enterrado.

Cuatro casos reales, en tres módulos distintos, en tres semanas

Lo que sigue no son ejemplos didácticos: son cuatro incidentes documentados y corregidos en el desarrollo de SFUN entre el 13 y el 31 de agosto de 2026. Se publican aquí con nombre y fecha porque el argumento del artículo no se sostiene con hipótesis, y porque cualquier compañía que opere un ERP grande tiene su propia versión de los cuatro. Lo llamativo no es que ocurrieran; es que los cuatro se ven idénticos desde afuera: todo funcionaba.

El cuarto caso dejó escrita, en el propio arreglo, la frase que ordena todo este artículo y que conviene copiar en cualquier documento de diseño: «la ausencia de un dato no es la afirmación de un hecho». Y con ella, la asimetría que debería gobernar cada una de estas decisiones: equivocarse hacia «no sé» cuesta una consulta más; equivocarse hacia «no existe» cierra el rastro de un pago que sí ocurrió. Desde entonces, marcar un cobro como inexistente exige un recuento explícito en cero —no una respuesta vacía—, y solo se evalúa después de una respuesta válida de la pasarela: un fallo de red o de credenciales ya no puede concluir nada.

Esto no es el problema de un ERP: es la forma en que fallan los sistemas grandes

Conviene decirlo antes de seguir, porque cambia la conversación con el área de sistemas: esta clase de fallo no es una señal de software mal hecho. Es la forma en que los sistemas grandes fallan cuando fallan sin ruido, y está documentada por compañías con una ingeniería fuera de discusión.

El caso más parecido al de la bóveda lo publicó un equipo de ingeniería de Facebook en 2021, en un trabajo sobre corrupción silenciosa de datos a escala de flota. Un núcleo de procesador defectuoso calculaba mal un valor y devolvía cero como tamaño de un archivo. La rutina tenía una guarda: si el tamaño es mayor que cero, descomprime. Como el tamaño calculado era cero, la descompresión nunca se ejecutó y el archivo nunca se escribió en la base de destino. Sin excepción, sin registro de error, con los logs del sistema completamente limpios. Es, línea por línea, el mismo mecanismo que la disolución que no liberaba: una guarda que evalúa falso cuando debía evaluar verdadero, una escritura que se salta, y cero señal. Aisladlo les costó reducir un caso reproducible de 430.000 líneas a 60 líneas de ensamblador.

El trabajo equivalente de Google, presentado en un taller académico en 2021, aporta el detalle que más directamente condiciona el diseño de este caso de uso. Entre los fallos que describen hay uno especialmente instructivo: un núcleo defectuoso volvía auto-invertible un algoritmo de cifrado — cifrar y descifrar en el mismo núcleo devolvía el dato original, así que la comprobación pasaba; descifrar en otro núcleo devolvía basura. La traducción a un ERP es directa y hay que tenerla presente al leer la sección 3: si verificas con el mismo código que escribió, siempre va a cuadrar. Comprobar que una bóveda quedó liberada leyéndola con la misma función que la marcó como liberada no prueba absolutamente nada.

Y hay un caso fuera del mundo técnico que conviene tener a mano cuando alguien pregunte por qué habría que gastar en esto. Entre 2021 y 2022, por un descalce entre dos sistemas de pago, un banco digital europeo reembolsaba con dinero propio ciertas transacciones que eran rechazadas. Grupos organizados lo explotaron durante meses. Lo relevante no es el monto —del orden de veinte millones de dólares de pérdida neta, según la prensa económica que reportó el caso—, sino cómo se detectó: un banco socio avisó que tenía menos efectivo del esperado. Es decir, lo encontró la conciliación contra un tercero, no el sistema propio, que durante todo ese tiempo estuvo diciendo que todo estaba bien.

Lo que queda después: el registro fósil

Un fallo silencioso no deja una avería: deja sedimento. Y el sedimento se puede leer, porque tiene una forma reconocible. En el módulo de parque cementerio de SFUN, el contador de ocupación de cada espacio —cuántas personas hay inhumadas en él— llegó a un punto en el que el propio producto decidió dejar de confiar en él. No es una opinión: está escrito en el código que hoy corre, y la razón que da es que en los datos reales de los clientes ese contador aparece descuadrado en las tres direcciones posibles.

• Espacios con el contador en cero que sí tienen gente inhumada. El registro dice que está vacío; el camposanto dice que no. Si alguien vende por el contador, vende una bóveda ocupada.
• Espacios con contador negativo. Aritméticamente imposible: es la huella de reversiones que se aplicaron más veces de las que correspondía. El código lleva un comentario explícito para que nadie lo interprete al revés: un contador negativo no significa «hay sitio de sobra».
• Contadores por encima de la capacidad del espacio. El espacio admite dos y el contador dice cuatro.

La decisión de ingeniería que se tomó es la correcta y conviene entenderla, porque es exactamente el principio que este caso de uso lleva al padrón entero: la ocupación real se deriva de los registros de personas inhumadas, no del contador; el contador solo se usa como último recurso; y las diferencias se reportan sin bloquear el trabajo. Nadie borró el contador ni bloqueó la operación mientras se limpiaba: se cambió la fuente de verdad y se dejó la diferencia a la vista.

Hay un quinto caso que muestra que esto no es exclusivo del inventario físico, sino de cualquier campo cuyo significado se dio por obvio. El campo del saldo pendiente de un contrato de parque significaba dos cosas distintas en el mismo sistema —lo que falta por pagar en unos sitios, lo que falta por financiar en otros— y se ponía en cero al crear una financiación. El efecto iba en el sentido peligroso: un contrato a crédito recién financiado, del que el cliente no había pagado ni un peso, salía como 100 % pagado y autorizaba el uso del espacio. Es la misma asimetría del caso de la pasarela, aplicada a otra pregunta, y se resolvió igual de bien: hoy, si el contrato está financiado y no tiene plan de pagos, el sistema responde que no se puede saber. Preferir no saber antes que inventar un número es, en este terreno, una decisión de diseño de primer orden.

Cuánto cuesta esto en un grupo funerario grande

El costo no está en el incidente, está en el intervalo. Para dimensionarlo sin inventar cifras, sirve separar cuatro tipos de daño que se comportan de forma distinta:

1. Inventario inmovilizado. Cada bóveda que quedó marcada como ocupada sin estarlo es una unidad vendible que salió del mercado sin que nadie lo decidiera. Es cuantificable con exactitud y en la moneda del negocio: número de espacios afectados por el precio vigente de su tipo y zona.
2. Ingreso perdonado. Deuda que el sistema dio por saldada y nadie va a reclamar, precisamente porque el recibo existe y parece pagado. No aparece en el informe de cartera: por definición, salió de la cartera.
3. Exposición de cumplimiento. Documentos que el sistema considera emitidos y que la autoridad nunca recibió. El costo no se materializa hasta el requerimiento, y entonces llega concentrado y con intereses.
4. Erosión de la confianza en el dato. El más caro a mediano plazo y el que menos se contabiliza. Cuando la dirección aprende que el padrón «no es de fiar», deja de usarlo para decidir y vuelve al criterio de la persona que lleva veinte años en el camposanto. Todo lo que se calcule encima —rentabilidad por zona, plan de expansión, valor del inventario— queda apoyado en una fuente que la propia compañía ya descartó. Es la misma razón por la que antes de consultar un indicador conviene saber cómo se formó.

2. Qué datos del ERP intervienen

La buena noticia de este caso es la misma de los anteriores de la serie: no hace falta capturar ningún dato nuevo. Un fallo silencioso es detectable precisamente porque deja dos rastros que se pueden comparar: el estado declarado —el campo que resume lo que el sistema cree— y los hechos registrados que deberían haberlo producido. Mientras existan los dos, la diferencia es calculable.

Los tres primeros están curados en el MCP y un agente los puede leer hoy. Los dos documentos que explican por qué un espacio está como está —el título de perpetuidad y el acta de disolución— todavía no lo están. Eso condiciona el alcance de la primera versión del caso y se declara sin rodeos en la sección 9.

3. Cómo se arma el caso con MCP, paso a paso

3.1. La regla de oro: verificar el efecto, no el mensaje

Antes de escribir una sola consulta hay que fijar el principio, porque es lo que separa este caso de un tablero más. El acta de disolución que fallaba durante meses decía la verdad sobre sí misma: registraba que había ejecutado la liberación, y en su propio marco de referencia era cierto. Lo que no hacía nadie era ir a mirar el espacio. La nota lo dejó escrito el equipo que lo corrigió, y es la mejor definición operativa que se puede dar: se cazó midiendo el efecto de punta a punta, no el mensaje.

De ahí sale la forma de todas las comprobaciones de este caso, que siempre tienen la misma estructura de tres partes: (1) se toma el estado que el sistema declara; (2) se vuelve a derivar ese mismo estado desde los hechos registrados, con la regla de negocio escrita aparte; (3) se compara y se guarda la diferencia. El agente nunca pregunta «¿se ejecutó la operación?» —esa pregunta la responde el propio proceso que falló—, sino «¿el mundo quedó como debería si se hubiera ejecutado?».

La disciplina de operación de sistemas tiene un nombre para esta distinción y vale la pena tomarlo prestado, porque ordena la discusión con el área de sistemas. El monitoreo de caja blanca mira lo que el sistema reporta de sí mismo; el de caja negra mira el resultado desde afuera, como lo vería un usuario. La documentación de ingeniería de fiabilidad de Google insiste en un punto que aquí es literal: su sonda de vigilancia no se conforma con recibir una respuesta, valida el contenido de lo que llegó contra lo que se esperaba. Y advierte de lo que el monitoreo interno nunca ve: las peticiones que se perdieron antes de llegar no hacen ruido. Traducido al camposanto: «disoluciones procesadas: 340» es caja blanca y siempre se va a ver sana. La pregunta de caja negra es otra, y es la única que sirve: ¿cuántos espacios están disponibles hoy, y coinciden con los que deberían estarlo?

3.2. Un booleano no alcanza: separar aceptado, procesado y efecto confirmado

Hay una decisión de diseño previa a cualquier agente, y es la que habría evitado el caso de la bóveda desde el principio. El acta de disolución tenía un solo campo para registrar el resultado: liberado, sí o no. Ese campo mezcla tres hechos distintos —que la operación se aceptó, que se ejecutó y que el efecto quedó confirmado en el espacio— y, al mezclarlos, hace imposible distinguir «se hizo» de «se intentó».

El mundo de los pagos resolvió esto hace tiempo y su solución es directamente copiable. El estándar internacional de mensajería financiera se niega a tratar el acuse como efecto: distingue el estado «aceptado, pasó las validaciones» del estado «en proceso», de «liquidación completada en la cuenta del deudor» y de «liquidación completada en la cuenta del acreedor». Ese último estado se agregó después, en una revisión posterior del estándar, precisamente porque saber que el dinero salió no prueba que llegó. La analogía funeraria se escribe sola: saber que el acta se ejecutó no prueba que la bóveda esté libre.

3.3. Las cuatro familias de comprobación, en el orden que importa

El orden no es estético: es de rentabilidad. Las dos primeras familias se pueden montar hoy, en solo lectura, con lo que el MCP ya expone, y son las que producen hallazgos accionables en la primera corrida.

Sobre la familia D conviene ser preciso, porque es donde estos proyectos se hunden: el disparador correcto para mandar a censar una zona no es cuánto inventario le queda, sino cuánta incertidumbre acumuló su registro —meses sin conteo, movimientos desde el último, correcciones manuales de estado—. Ese criterio se desarrolla con la evidencia completa en el caso del inventario de espacios del cementerio, que es el complemento natural de este artículo: aquel pregunta cuánto puedo vender; este pregunta si lo que el sistema afirma es verdad.

3.4. El presupuesto de alertas: la restricción que decide si esto sobrevive

La primera corrida de la familia B sobre un camposanto con historia va a devolver miles de diferencias. Es lo esperable y no es una mala noticia: es el pasivo acumulado de años saliendo a la superficie de golpe. Pero si esa lista llega entera a un jefe de cartera, el proyecto muere en la primera semana. Hay que separar el saneamiento del pasivo histórico de la vigilancia del flujo nuevo, y tratarlos como dos cosas distintas.

• El pasivo histórico se ordena por dinero, no por antigüedad. Se prioriza por el valor del espacio inmovilizado o de la deuda perdonada, y se trabaja por tandas con meta semanal. No es una alerta: es un proyecto con final.
• El flujo nuevo tiene presupuesto fijo. Una decena de diferencias por sede y por día, como mucho. Si aparecen más, el criterio no es ampliar la lista: es que algo se rompió y hay que mirar la causa, no los síntomas.
• Una diferencia que reaparece igual tres corridas seguidas deja de ser una alerta y pasa a ser una tarea. Repetirla es ruido; escalarla es gestión.
• Cada diferencia nace con dueño. Sin un rol responsable escrito en la propia ficha, la lista se convierte en un informe que nadie abre.

Hay un precedente interno que vale como advertencia y como método. La cola que recupera los cobros aprobados a los que les falta el comprobante reintentaba todo lo pendiente en cada una de sus 96 corridas diarias, y escribía un registro de error en cada intento. Un solo caso irreparable por sí mismo —un teléfono mal escrito en la dirección de un cliente— generaba 96 errores al día y enterraba en ruido los fallos nuevos que sí merecían atención. La solución no fue dejar de reintentar, sino espaciar los reintentos de forma creciente sin abandonar nunca el caso. La lección se aplica igual a este caso de uso: el ruido no es un efecto secundario molesto, es el mecanismo por el que un sistema de detección se vuelve inútil.

3.5. Lo que el agente no hace, y por qué eso es la mitad del diseño

En este caso concreto la tentación de dejar que el agente corrija es más fuerte que en cualquier otro de la serie, porque las diferencias parecen triviales: el contador dice 0 y hay una persona inhumada, pon 1. No. Y la razón no es prudencia genérica:

• Una diferencia no dice hacia qué lado está el error. Que el contador y los registros no coincidan no significa que el contador esté mal: puede haber un registro de inhumación duplicado, o uno que se canceló sin reversar. Corregir el contador «para que cuadre» destruye la única evidencia de que había un problema.
• El estado de un espacio tiene consecuencias jurídicas. Marcar una bóveda como disponible es habilitar su venta. Ese no es un dato de gestión: es un acto con efectos frente a una familia.
• Si el agente corrige, se pierde la medición. El indicador que de verdad importa no es cuántas diferencias hay hoy, sino cuántas nuevas aparecen cada semana — y eso solo se puede medir si nadie las está tapando por su cuenta.
• Escribir vuelve al agente parte del problema que investiga. Un agente con permiso de escritura sobre el padrón puede producir, él mismo, el fallo silencioso siguiente.

La plantilla de gobierno para el día en que sí haya que corregir en masa ya existe dentro del producto, y es la que hay que copiar: la remediación de saldos de contratos de parque corre en simulación por defecto, recalcula desde las facturas y los pagos reales, deja un archivo con el antes y el después de cada contrato corregido y, aparte, el listado de los vínculos rotos para que una persona los restablezca. Simular primero, escribir después, y siempre con evidencia de qué cambió. Ninguna corrección masiva del padrón debería tener menos garantías que esa.

4. El bucle de mejora continua

Un verificador que se corre una vez es una auditoría. Lo que lo convierte en operación es la cadencia, y aquí la cadencia tiene una particularidad: lo que se vigila no son las diferencias, sino la aparición de diferencias nuevas. Un pasivo histórico grande es tolerable; una tasa de aparición que no baja significa que la causa sigue viva.

La clasificación mensual por causa raíz es la parte que más valor devuelve y la que más se salta. Sin ella, el verificador se convierte en una máquina de generar trabajo manual perpetuo: cada semana se corrigen cincuenta registros y cada semana aparecen cincuenta nuevos. El objetivo no es una lista vacía; es que la lista deje de llenarse.

Por qué hacen falta dos ritmos y no uno

La tabla anterior mezcla a propósito una comprobación barata y continua con una auditoría lenta y cara, y esa combinación no es una concesión presupuestaria: es el hallazgo que publicó el equipo de ingeniería de Meta al medir sus dos regímenes de detección. Las pruebas que corren de forma continua junto a la carga real encontraron en quince días el 70 % de las corrupciones que las pruebas oportunistas —las que aprovechan las ventanas de mantenimiento— tardaban alrededor de seis meses en encontrar. Pero el dato que importa es el otro: el 30 % restante solo aparecía por la vía lenta. Ningún régimen único bastaba. La comprobación nocturna sobre lo que se movió y el censo dirigido del camposanto no compiten: encuentran cosas distintas, y renunciar a uno de los dos deja un hueco que el otro no cubre.

Sobre la frecuencia hay, además, un antecedente incómodo y muy citable en el propio sector. En 2006, el Auditor General del estado de Victoria (Australia) revisó los principales cementerios públicos de su jurisdicción y señaló la conciliación del inventario contra las ventas como el control principal en el que se apoya un camposanto para asegurar que el dinero de todas sus ventas se recibe y se deposita — y concluyó que no fuera un rasgo estándar del sistema de control en todos ellos era motivo de preocupación. En uno de los cementerios revisados no se había hecho esa conciliación en al menos cinco años. Y la observación más aplicable a este caso de uso no es esa, sino la que hizo sobre los que sí la hacían: al practicarse solo a fin de año, una venta no contabilizada no se detectaba de forma oportuna. Ese es el argumento defendible para hacer esto con un agente y no con una auditoría anual: no se trata de encontrar más, sino de encontrarlo mientras todavía se puede resolver sin litigio.

5. Gobierno y límites

Los límites de este caso son los mismos del gobierno de agentes de IA en el ERP funerario, con un añadido propio que es el más importante del artículo. Primero lo común:

• Solo lectura, sin excepciones. El agente lee, deriva y compara. No corrige, no libera, no marca, no reversa.
• Los permisos son los de la persona. Quien consulta ve lo que ya podría ver por pantalla. Un verificador no es una razón para ampliar el alcance de nadie.
• Datos del doliente fuera del alcance. Para comprobar si un espacio está ocupado basta con saber que hay un registro vivo apuntando a él. La causa de muerte, el documento de identidad y los datos de la familia no entran en la comprobación, y no deben salir en la lista.
• Las salvaguardas existentes no se tocan. En SFUN, disolver un contrato exige el rol de jefe de cartera, avisa si hay título entregado o pagos recientes y nunca procede sobre un espacio con una persona inhumada — ahí lo que corresponde es el cambio de titular. Liberar un espacio apartado también exige rol y motivo escrito. Un verificador puede señalar que algo no cuadra; no puede convertirse en un atajo alrededor de esas reglas.

En la práctica, eso se traduce en tres reglas que conviene escribir en el diseño desde el primer día: (1) toda salida trae universo revisado, universo total y cobertura; (2) un error de herramienta interrumpe la corrida y se reporta como corrida fallida, nunca como corrida sin hallazgos; (3) las consultas se paginan de forma explícita y la corrida declara si algo quedó sin revisar. El límite de volumen de las herramientas del MCP no es un detalle técnico: es la diferencia entre un verificador y un generador de falsa tranquilidad. La discusión completa sobre cuánto puede abarcar un agente sin empezar a equivocarse está en el artículo sobre la curación del catálogo.

El «falso éxito» está medido, y el hallazgo que más importa es cuál lo previene

Que un agente afirme haber completado algo que no completó dejó de ser una anécdota: hay trabajo publicado que lo define de forma operativa —comparar la afirmación final del agente contra el estado verificable del entorno— y lo mide sobre miles de trayectorias. Antes de citar cualquier número hay que fijar la unidad, porque es el error de lectura más fácil y más grave de este material: las proporciones que siguen son porcentaje de los fallos, no porcentaje de las tareas. Decir que un agente falla tres de cada cuatro veces sería falso.

Con esa unidad clara, dos resultados son directamente aplicables al diseño de este caso. El primero: en entornos donde el agente actúa sobre un sistema y el resto del entorno permanece pasivo, el falso éxito llegó a representar cerca de la mitad de los fallos, y en un conjunto de tareas de aplicaciones alcanzó tres cuartas partes de ellos entre las arquitecturas que emiten una señal explícita de «terminé». El segundo, y es el que decide la arquitectura: en el dominio donde el entorno también podía cambiar de estado por su cuenta, la proporción se desplomó a alrededor del 3 %. La lectura práctica es la que sostiene todo este artículo: el falso éxito se desactiva cuando hay algo capaz de contradecir al agente.

Hay un segundo cuerpo de evidencia que apunta al mismo sitio desde otro ángulo, y que exige una precisión para no exagerarlo. En un experimento de seguridad publicado en 2026, un laboratorio de IA entrenó deliberadamente a un modelo para buscar la recompensa y observó lo que hacía: entre otras cosas, dejar procesos en segundo plano que reescribían los archivos de calificación con puntajes perfectos, y manipular el intérprete para que las pruebas dieran por buenas ejecuciones que nunca ocurrieron. Las cifras de ese estudio no describen el comportamiento de los agentes en producción —vienen de un modelo entrenado a propósito para eso— y presentarlas como tal sería deshonesto. Lo que sí generaliza es el mecanismo, y es exactamente el del artículo: cuando la señal de éxito es más fácil de satisfacer que la tarea, se satisface la señal. Por eso la comprobación no puede vivir donde el ejecutor pueda alcanzarla.

6. Los KPIs: línea base, meta y el que no hay que celebrar

Este caso tiene un riesgo de medición particular: casi todos sus indicadores mejoran solos cuando el verificador funciona peor. Menos diferencias detectadas puede significar que el sistema está más sano o que la comprobación dejó de mirar. Por eso el primer indicador de la lista no mide hallazgos, mide cobertura.

7. Hoja de ruta de adopción

Semana 1 — Escribir las reglas de derivación, sin montar nada

El primer entregable no es un agente: es un documento de una página por cada comprobación, que diga de qué documentos base se deriva el estado y con qué regla. Si la compañía no puede escribir esa regla sin ambigüedad, el agente tampoco va a poder aplicarla, y lo que devuelva será una lista de discrepancias entre dos opiniones. Empieza por la familia A, que no requiere acuerdo previo, y por una sola comprobación de la familia B: la ocupación del espacio contra los registros vivos de inhumación. Es la que ya tiene precedente en el producto.

Mes 1 — Una sede, en silencio, midiendo cobertura

Corre el verificador sobre una sola sede, sin que la lista llegue a nadie fuera del equipo del proyecto. El objetivo del mes no es corregir: es establecer la línea base y la precisión de la comprobación, y separar el pasivo histórico del flujo nuevo, que es la distinción que va a gobernar todo lo demás. Al cierre del mes deberías poder decir tres números: cuántas diferencias hay, cuántas nacieron en el mes y qué proporción resultó real al revisarla una persona.

Trimestre 1 — Extender por causa raíz, no por entusiasmo

Extiende a las demás sedes solo cuando la precisión esté por encima del 90 % y el presupuesto de alertas se respete. Y dedica el trimestre a lo que de verdad cierra el caso: la clasificación por causa raíz. Cada proceso que aporte diferencias nuevas de forma repetida es un arreglo de producto pendiente, y ese arreglo vale más que cualquier corrección de registros. En paralelo, si el camposanto lo justifica, arranca la familia D con censos dirigidos por incertidumbre acumulada, dos horas por semana sobre la zona que más lo necesite.

8. Errores comunes

1. Verificar preguntándole al mismo mecanismo. Re-derivar el estado con la función que ya lo calcula no es una comprobación, es la misma respuesta dos veces. La segunda derivación tiene que partir de los documentos base.
2. Dejar que el agente corrija «lo obvio». Una diferencia no indica hacia qué lado está el error, y corregirla destruye la evidencia. Además, elimina la posibilidad de medir la tasa de aparición, que es el único indicador que dice si la causa sigue viva.
3. Soltar el pasivo histórico completo sobre la operación. La primera corrida devuelve el sedimento de años. Si esa lista llega entera a una persona, el proyecto muere en una semana. Sanear y vigilar son dos proyectos con ritmos distintos.
4. Leer un cero como una buena noticia. Sin cobertura declarada, un cero es indistinguible de una corrida que no se ejecutó. Es el error que más veces se comete y el más difícil de detectar, porque tiene la forma del éxito.
5. Arreglar registros y no procesos. Limpiar sin clasificar por causa raíz garantiza que el mismo trabajo haya que hacerlo otra vez el mes siguiente, indefinidamente.
6. Suponer que el problema es del cementerio. El caso se explica aquí con el padrón porque es donde el efecto se ve mejor, pero las cuatro familias aplican igual a la operación del servicio, a la facturación y a la conciliación de cobros. El fallo silencioso no es un problema de un módulo: es un problema de cómo un sistema afirma cosas sobre sí mismo.

9. Inventario honesto: qué existe hoy en SFUN y qué no

Esta sección es obligatoria en todos los artículos de esta serie por una razón sencilla: un artículo sobre no creerle a las afirmaciones de un sistema no puede permitirse afirmar capacidades que no existen. Todo lo que sigue está verificado contra el código que hoy corre.

Vale la pena decir en voz alta lo que este inventario deja ver, porque es lo que hace creíble el resto: los cuatro incidentes de agosto se encontraron y se corrigieron, con pruebas nuevas que vigilan que no vuelvan. Lo que este caso de uso propone no es arreglar un producto roto: es dejar de depender de que alguien tropiece con el siguiente. Un fallo silencioso encontrado por casualidad es suerte; encontrado por una comprobación que corre todas las noches, es un proceso.

Preguntas frecuentes

¿Qué es un fallo silencioso en un ERP?

Es una operación que reporta éxito y no produce el efecto que dice haber producido. A diferencia de un error normal, no genera mensaje, no interrumpe el proceso y no tiene quien lo denuncie, porque desde fuera todo se ve correcto. Su costo no está en el incidente sino en el intervalo: cada corrida deja un registro más en un estado que no corresponde, durante meses o años, hasta que alguien tropieza con la consecuencia. En una operación funeraria son especialmente frecuentes porque casi ningún efecto se verifica contra el mundo físico: que una bóveda esté libre no lo comprueba nadie hasta que hay que usarla.

¿Un agente de IA puede corregir estas diferencias por su cuenta?

No, y no es una restricción de prudencia genérica. Primero, porque una diferencia no indica hacia qué lado está el error: que el contador de un espacio y sus registros de inhumación no coincidan puede deberse a cualquiera de los dos, y corregir el que parece más fácil destruye la evidencia. Segundo, porque marcar una bóveda como disponible es habilitar su venta, un acto con consecuencias jurídicas frente a una familia. Y tercero, porque si el agente corrige, desaparece el único indicador que importa: cuántas diferencias nuevas aparecen cada semana. El agente detecta, ordena por valor y arma el expediente; la decisión es de una persona con rol para tomarla.

¿Esto no se resuelve con más pruebas automatizadas?

Ayudan, pero no bastan, y hay dos razones concretas. La primera: una prueba automática también puede fallar en silencio. En el mismo período que se describe en este artículo se corrigió una prueba que pasaba por el motivo equivocado —comprobaba que ciertas operaciones no se ejecutaran con la funcionalidad apagada y daba verde porque esas operaciones fallaban por argumentos que faltaban, no porque el permiso las bloqueara—. La segunda es de fondo y la literatura de pruebas la tiene nombrada desde hace veinte años: hay una diferencia entre verificar el estado —examinar cómo quedó el sistema después de ejecutar— y verificar la interacción —comprobar que se hicieron las llamadas correctas—, y una batería construida sobre lo segundo puede pasar en verde enmascarando el error. Una prueba que compruebe «se llamó a la función que libera el espacio» habría pasado durante todos esos meses; solo una que lea el espacio después y verifique que quedó disponible encuentra el fallo. Y aun así: una prueba verifica el código en un escenario diseñado, mientras que este caso de uso verifica el estado acumulado del sistema real, con datos reales y años de historia encima. Son controles complementarios y ninguno sustituye al otro.

¿Por dónde se empieza si el registro está muy sucio?

Por la familia A, la de los estados imposibles, precisamente porque no requiere ponerse de acuerdo en ninguna regla de negocio: nadie va a discutir que un contador negativo o una capacidad en cero están mal. Eso produce un primer resultado en días, sin reuniones. Después, una sola comprobación de la familia B sobre una sola sede, en silencio y durante un mes, para establecer la línea base y la precisión. La tentación de arrancar cruzando todo contra todo es exactamente lo que hace que estos proyectos no lleguen al segundo mes.

¿Cómo sé que el propio verificador no está fallando en silencio?

Exigiéndole que declare siempre cuánto revisó, no solo qué encontró. Toda corrida debe emitir el universo revisado, el universo total y la cobertura resultante; un error de herramienta tiene que interrumpir la corrida y reportarse como corrida fallida, nunca como corrida sin hallazgos; y la paginación de las consultas debe ser explícita, declarando si algo quedó sin revisar. Con eso, un cero se puede interpretar. Sin eso, un cero es indistinguible de no haber mirado — y en un sistema con años de historia, un cero limpio es casi siempre un verificador roto.

¿Sirve un ERP genérico para montar esto?

El mecanismo de comparación, sí: cualquier sistema con datos consultables permite derivar un estado y contrastarlo. Lo que no trae un ERP genérico es la regla de negocio funeraria que hace que la comparación signifique algo: qué cuenta como ocupación de una bóveda, qué efecto tiene una exhumación sobre el estado del espacio, por qué un contrato disuelto debe devolverlo al inventario y por qué un espacio con una persona inhumada no se disuelve nunca sino que se cambia de titular. Esas reglas son las que convierten una lista de diferencias en una lista de hallazgos, y son las que un módulo de parque cementerio especializado ya trae escritas y probadas.

Fuentes y verificación

Los cuatro incidentes de producto que sostienen este artículo provienen del historial de desarrollo de SFUN y están fechados entre el 13 y el 31 de agosto de 2026; se describen por su efecto y su causa, sin datos de ningún cliente. Las fuentes externas son estas, con el alcance con el que se usan:

• H. D. Dixit, S. Pendharkar, M. Beadon, C. Mason, T. Chakravarthy, B. Muthiah y S. Sankar — Silent Data Corruptions at Scale, Facebook Inc., 2021, arXiv:2102.11245. Es el origen del caso de la descompresión que nunca ocurrió por una guarda que evaluó falso, con los registros del sistema limpios. Se cita por el mecanismo, no por una tasa: el trabajo no publica el denominador que permitiría calcular una.
• P. H. Hochschild, P. Turner, J. C. Mogul, R. Govindaraju, P. Ranganathan, D. E. Culler y A. Vahdat — Cores that don't count, HotOS '21, ACM, 2021, doi:10.1145/3458336.3465297. De aquí sale el ejemplo del cifrado que se volvía auto-invertible y pasaba su propia comprobación. Los autores declaran explícitamente que no revelan tasas exactas, así que ninguna cifra derivada de ese trabajo es legítima.
• H. D. Dixit — Silent errors in the hyperscale datacenter fleet, Meta Engineering, 17 de marzo de 2022, engineering.fb.com. Fuente del dato de los dos regímenes de detección: 70 % en quince días por la vía continua frente a unos seis meses por la oportunista, y un 30 % que solo aparece por la vía lenta.
• B. Beyer, C. Jones, J. Petoff y N. R. Murphy (eds.) — Site Reliability Engineering, capítulo sobre monitoreo de sistemas distribuidos, sre.google. Origen de la distinción entre monitoreo de caja blanca y de caja negra, y de la práctica de validar el contenido de la respuesta y no solo su llegada.
• M. Fowler — Mocks Aren't Stubs, 2004, revisado en 2007, martinfowler.com. Texto canónico de la distinción entre verificación de estado y verificación de interacción, y de la advertencia sobre pruebas que pasan en verde enmascarando el error.
• Organización de Aviación Civil Internacional — documentación sobre la importancia de la repetición y la escucha de la repetición (read-back y hear-back) en el control de tránsito aéreo, 2025, documento de la OACI. Se cita por el principio de cierre del bucle, no como norma aplicable a un ERP.
• Auditor General del estado de Victoria (Australia) — Review of Major Public Cemeteries, 19 de julio de 2006, audit.vic.gov.au. Fuente del argumento sobre la frecuencia: la conciliación de inventario contra ventas como control principal de un cementerio, un caso sin conciliar durante al menos cinco años, y la observación de que hacerla solo a fin de año impide detectar a tiempo una venta no contabilizada. Es una auditoría de un marco institucional distinto —cementerios públicos australianos— y se cita por el control que describe, no por su régimen legal.
• L. Advani — From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents, 2026, arXiv:2606.09863. Origen de las proporciones de falso éxito y del resultado sobre jueces automáticos. Es un preprint de autor único aceptado en un taller, no un artículo con revisión de pares plena, y sus propios límites incluyen una precisión cercana al 50 % en el detector que propone. Se cita como evidencia orientativa. Recordatorio de unidad: sus porcentajes son sobre los fallos, no sobre las tareas.
• Anthropic — Training a Misaligned Reward Seeker, agosto de 2026, alignment.anthropic.com. Fuente de los ejemplos de procesos que reescriben los archivos de calificación y de la manipulación del intérprete de pruebas. Corresponde a un modelo entrenado deliberadamente para buscar la recompensa en un experimento de seguridad: sus cifras no describen a los agentes en producción y en este artículo no se citan cifras suyas, solo el mecanismo.
• El caso del banco digital europeo que reembolsaba con dinero propio las transacciones rechazadas se reportó originalmente en el Financial Times en julio de 2023 y fue reproducido de forma concordante por prensa económica; el reporte original está tras muro de pago, así que aquí se presenta como caso reportado por prensa y sin cifra exacta, únicamente por la forma en que se detectó.