El sistema aceptó el dato. La operación pagó el error

Una nave desapareció sobre Marte. Miles de resultados positivos quedaron fuera de los reportes que debían contarlos. Una empresa de software advirtió que un conjunto de problemas —entre ellos datos deficientes— podía afectar su negocio en aproximadamente USD 110 millones. Una firma financiera perdió más de USD 460 millones en unos 45 minutos.

A primera vista, son incidentes sin relación: exploración espacial, salud pública, software y mercados financieros. La conexión aparece en un lugar menos visible. En los cuatro, procesar información no bastó para representar la realidad sobre la que alguien debía actuar.

Esa es la trampa que recorre esta lectura. No el dato evidentemente corrupto que un sistema rechaza, sino el que entra en el flujo, parece utilizable y consigue que la operación siga avanzando sin una pieza crítica de contexto.

¿Qué puede faltarle a un dato para que un sistema aparentemente funcional contribuya a perder una nave o USD 460 millones? La respuesta cambia a medida que avanzan los casos. Primero falta el significado. Después, la cobertura. Luego, la procedencia. En el último incidente, la verdad sí existía dentro del sistema, pero no llegó a tiempo al componente que debía obedecerla.

El 23 de septiembre de 1999, la señal del Mars Climate Orbiter desapareció detrás de Marte 49 segundos antes de lo previsto. Debía volver después de 21 minutos. No volvió. NASA continuó intentando recuperarla hasta el 25 de septiembre.

La explicación apareció días después. El software de tierra debía entregar datos de impulso en Newton-segundo. Los entregó en libra-fuerza-segundo.

El modelo de navegación trató el valor como si estuviera expresado en la unidad esperada. Según la investigación de NASA, el efecto de las maniobras quedó subestimado por un factor de 4,45. La reconstrucción posterior situó el punto más bajo de la trayectoria en 57 kilómetros; la misión consideraba 80 kilómetros como el mínimo sobrevivible.

El archivo no llegó vacío ni con caracteres inválidos. Fue leído. Fue utilizado. El problema era que dos equipos no compartían el mismo contrato sobre lo que significaba el número.

Ese es el primer vacío: validar el valor sin validar su significado. En una integración ERP, la misma falla puede aparecer en una dimensión de producto, una moneda, una tasa, un peso o una definición como «disponible». La interfaz mueve el dato; la unidad determina la decisión.

El Mars Climate Orbiter deja la primera pregunta: ¿qué significa el valor? Pero incluso un dato bien definido puede fallar de otra manera. Puede no llegar.

Resolver el significado todavía no garantiza una imagen confiable. También hace falta saber si llegó todo lo esperado.

En octubre de 2020, Public Health England informó que 15.841 resultados positivos de COVID-19, correspondientes al periodo entre el 25 de septiembre y el 2 de octubre, no habían sido incluidos en los reportes diarios. Más del 75% —11.968 casos— correspondía a resultados que debieron aparecer entre el 30 de septiembre y el 2 de octubre.

Durante varios días coexistieron dos realidades. Cada persona recibió su resultado y fue instruida para aislarse. Pero esos mismos casos no aparecían en los reportes diarios ni habían llegado oportunamente al sistema de rastreo de contactos.

La explicación oficial fue concreta: el aumento del volumen hizo que algunos archivos Excel usados en la transferencia superaran su umbral de tamaño y no fueran cargados al sistema central. La mitigación inmediata consistió en dividir los archivos y revisar el proceso de punta a punta. Todos los casos pendientes fueron transferidos al sistema de rastreo antes de la 1:00 a. m. del 3 de octubre.

Aquí no bastaba con revisar si las filas recibidas eran correctas. Había que comparar archivos y registros esperados contra archivos y registros cargados. Un reporte puede ser coherente con todo lo que contiene y seguir ofreciendo una realidad incompleta por lo que nunca recibió.

El dato de NASA decía algo distinto de lo que el modelo entendió. Los registros de PHE decían lo correcto, pero faltaban en el conjunto que alimentaba los reportes y el rastreo. El problema pasó del significado a la cobertura.

Todavía quedaba otra pregunta: aunque llegue todo, ¿deberíamos confiar en la fuente?

Incluso un flujo completo puede fallar si los datos no son aptos para la decisión que van a alimentar.

Unity Software mostró otro riesgo en su Form 10-Q del primer trimestre de 2022. La compañía informó que sus productos Operate habían perdido eficacia por varios problemas, entre ellos las consecuencias de ingerir datos deficientes de un cliente grande. Unity estimó que el conjunto de esos problemas tendría un impacto aproximado de USD 110 millones en el negocio durante 2022.

El documento no permite atribuir los USD 110 millones únicamente a los datos del cliente, ni presenta la cifra como una pérdida ya realizada. Tampoco detalla qué hacía deficientes esos datos. Sí establece algo relevante: entraron al producto y redujeron su eficacia.

El formato, por tanto, era apenas el comienzo. Cuando una entrada alimenta segmentación, predicción, recomendación o monetización, también importa quién la produjo, bajo qué definición, qué periodo cubre y si su comportamiento es compatible con el uso previsto.

Aquí cambia la pregunta. Ya no es «¿podemos leer este dato?», sino «¿tenemos razones para confiar en él para esta decisión?».

El último caso amplía la idea de dato operacional. Una cantidad o una dimensión es un dato, pero también lo es el estado que debe iniciar o detener una acción.

El 1 de agosto de 2012, Knight Capital desplegó código nuevo en siete de los ocho servidores de su sistema automatizado de enrutamiento de órdenes. El octavo conservó código defectuoso.

A partir de las 8:01 a. m., antes de la apertura del mercado, un sistema interno generó 97 correos que identificaban un error. No habían sido diseñados como alertas y nadie actuó sobre ellos. Cuando comenzó la jornada, el octavo servidor siguió enviando órdenes secundarias sin considerar cuántas ejecuciones ya habían regresado desde el mercado.

Una parte del sistema sí sabía que las órdenes originales habían sido completadas. Ese estado no fue comunicado al componente que seguía ejecutando.

En unos 45 minutos, 212 órdenes de clientes produjeron más de 4 millones de ejecuciones en 154 acciones y más de 397 millones de títulos. Knight terminó con posiciones no deseadas de miles de millones de dólares y realizó una pérdida superior a USD 460 millones.

La orden era válida. La confirmación de ejecución también. Lo que faltó fue convertir el estado correcto en una condición capaz de gobernar el proceso: comunicarlo al componente adecuado y detener nuevas acciones.

En este caso, la verdad existía: una parte del sistema sabía que las órdenes estaban completadas. Pero una verdad atrapada en el componente equivocado no gobierna nada.

NASA obliga a preguntar qué significa el dato. PHE, si llegó completo. Unity, si su origen permite confiar en él. Knight, si el estado verdadero alcanzó a tiempo a quien debía actuar. No son cuatro categorías de una tabla. Son cuatro preguntas que una operación necesita responder antes de entregar una decisión al software.

En una operación cotidiana, el mismo patrón no necesita una nave perdida ni USD 460 millones consumidos en 45 minutos para causar daño. Puede avanzar lentamente y durar mucho más.

Supongamos que el ERP recibe 120. Es un número válido. Pero nadie confirma si son unidades, cajas, kilogramos o centímetros. Ese es el problema de NASA, trasladado a una dimensión de producto.

Después recibe disponible = 86. El valor puede ser correcto para una ubicación y aun así omitir unidades reservadas, dañadas, en tránsito o imposibles de entregar en la fecha prometida. Es la pregunta que deja PHE: ¿la imagen está completa?

El precio llega con el formato esperado, pero desde un archivo cuyo propietario, periodo o criterio de actualización nadie puede defender. La duda de Unity aparece en otra escala: ¿la fuente es apta para esta decisión?

Por último, completado = true existe en un sistema, mientras fulfillment y finanzas siguen actuando como si el pedido permaneciera abierto. Knight demuestra el extremo de esa falla: conocer el estado correcto sirve de poco si no llega al ejecutor.

Cada valor puede parecer razonable por separado. La consecuencia aparece al final del flujo: capacidad mal calculada, inventario prometido donde no existe, un precio que detiene el pedido o dos áreas actuando sobre estados diferentes.

La calidad del dato deja entonces de ser una propiedad aislada de una tabla. Se vuelve una cadena de evidencia que debe sobrevivir hasta la decisión.

Para un responsable de Operaciones, esta revisión puede empezar sin un programa abstracto de gobierno de datos. Basta con elegir un campo capaz de cambiar el flujo: cantidad disponible, dimensión, precio, dirección, fecha prometida o estado de cumplimiento.

Sobre ese campo conviene responder cinco preguntas antes de dejar que gobierne el proceso.

Las respuestas pertenecen al modelo operativo porque conectan trabajo, responsabilidad, información y tecnología. Solo después se traducen en contratos de interfaz, validaciones semánticas, conteos de control, observabilidad y límites automáticos.

1. ¿Qué representa exactamente? Definición, unidad y momento del proceso.
2. ¿Cómo sabemos que llegó completo? Registros, archivos, ubicaciones y periodos esperados frente a los recibidos.
3. ¿De dónde viene y quién tiene autoridad? Fuente, transformaciones y responsable de corregirlo.
4. ¿Sigue vigente cuando se utiliza? Fecha efectiva, caducidad y eventos que pueden cambiarlo.
5. ¿Qué pasa cuando deja de ser confiable? Evidencia de reconciliación, condición de parada y responsable de la excepción.

Antes de ampliar una integración o automatizar el siguiente paso, un diagnóstico operativo puede seguir un pedido real y un solo dato desde su creación hasta la consecuencia final.

¿Dónde nació? ¿Quién lo transformó? ¿Qué componentes lo recibieron? ¿Cómo se comprobó que llegó completo? ¿Qué hecho del mundo real lo confirma? ¿Quién puede detener el flujo si deja de coincidir?

Si las respuestas dependen de una persona que recuerda revisar una hoja, de un archivo que «normalmente llega» o de dos sistemas que usan la misma palabra para momentos distintos, el control ya existe. Solo que es implícito, frágil y difícil de observar.

Antes del próximo conector, hay una pregunta más importante: ¿qué evidencia demuestra que el dato merece gobernar una acción?

Si nadie puede responderla, la integración no está eliminando la incertidumbre. Está ayudando a distribuirla.

El dato más peligroso no siempre es el que el sistema rechaza. Es el que acepta, todos confían y nadie vuelve a comparar con la realidad.