Hay una asimetría en casi todas las empresas de software y casi nadie la mira de frente.

Una función que devuelve el dato equivocado rompe una prueba. Un manifiesto que se desvía de lo desplegado enciende una alerta de deriva. Una dependencia con un CVE conocido para el pipeline. Todo lo que ejecutas está vigilado por algo.

Y luego está la frase de tu página de privacidad que promete en qué región viven los datos de tu cliente. Esa frase la escribió alguien que tenía el contexto entero en la cabeza, hace catorce meses. Desde entonces la infraestructura cambió tres veces. La frase no. Y no hay nada, en ningún sitio, que se ponga rojo cuando deja de ser verdad.

Nosotros hicimos ese ejercicio con nuestro propio sitio: coger cada afirmación publicada y buscar, en nuestro código y en nuestras decisiones de arquitectura, el archivo que la respalda. No salió indemne. Corregimos lo que había que corregir en la misma pasada, y lo que aprendimos vale más que el inventario de nuestros fallos.

Lo que sacamos, en cinco líneas:

Toda afirmación pública necesita una fuente citable en el repositorio, no alguien que se acuerde.
La auditoría tiene tres resultados, no dos: confirmada, contradicha y sin fuente.
El peligroso es el tercero, porque no se parece a un fallo.
Tus documentos internos no son autoridad. Lo que se ejecuta lo es.
Lo que puede comprobar un script debe comprobarlo un script, y un 200 no es una comprobación.

Las afirmaciones se escriben una vez y se leen para siempre

El problema no es que la gente mienta en su marketing. Es que las afirmaciones tienen un ciclo de vida rarísimo: se escriben una sola vez, en el momento de máximo conocimiento, y a partir de ahí solo se leen.

El código, en cambio, se toca. Cada vez que alguien lo abre tiene ocasión de notar que algo ya no cuadra. Una página de producto puede pasar dos años sin que nadie con contexto técnico vuelva a leerla línea por línea, mientras debajo se mueven la infraestructura, los planes, los límites y los proveedores.

Un ejemplo pequeño y sin ninguna gravedad, de los nuestros. En la documentación de instalación de nuestro agente, el comando de ejemplo apuntaba al Service equivocado: el nombre y el puerto genéricos que trae el chart de referencia, en vez del servicio de ingesta real. Quien copiara ese comando se quedaba con un agente que arrancaba y no reportaba nada. Sin error visible, sin log rojo.

Nadie lo detectó durante meses por un motivo muy simple: la documentación no se ejecuta. Nada la prueba. Es texto, y el texto no falla, solo envejece.

Tres resultados, no dos

La trampa de este ejercicio es plantearlo como un examen de verdadero o falso. Si lo haces así, terminas con una lista de correcciones y la sensación tranquilizadora de que el resto está bien. No lo está.

Cada afirmación cae en una de tres casillas:

Resultado	Qué parece	Qué es en realidad	Qué haces
Confirmada	Correcta	Correcta, y vuelve a ser comprobable mañana	Anotar la fuente junto a la afirmación
Contradicha	Un fallo	Un fallo con arreglo evidente	Corregir el texto, nunca la fuente
Sin fuente	Correcta	Desconocida	Buscar quién decide. Si no hay nadie, retirarla

La tercera casilla es la interesante, y es la que se pierde si solo buscas contradicciones. Una afirmación sin fuente no está mal: está sin comprobar. Nadie puede confirmarla y nadie puede desmentirla, tú incluido. Puede llevar dos años siendo cierta por casualidad, y dejar de serlo el martes que viene sin que nada lo registre.

Una afirmación sin fuente no es una afirmación correcta: es una afirmación que nadie puede desmentir, tú incluido.

Cuando encuentras una de esas, la pregunta útil no es “¿es verdad?”. Es “¿quién decide si es verdad, y dónde vive esa decisión?”. Si la respuesta es un archivo, ya tienes fuente. Si la respuesta es una persona, tienes un problema de otro tipo. Y si no hay respuesta, la afirmación no debería estar publicada.

Tus documentos internos no son autoridad

Este es el error que más veces vimos, y el más fácil de cometer con buena fe.

Cuando auditas, necesitas una fuente contra la que cotejar. La tentación es usar la documentación interna: el fichero de contexto del repositorio, la especificación, el wiki. Es cómodo, está escrito en prosa y responde rápido.

Y es exactamente el mismo tipo de artefacto que estás auditando. Un documento interno también se escribió una vez y se leyó muchas. También envejece. Si lo tomas como autoridad, no encuentras el error: lo blanqueas, porque ahora tienes dos textos de acuerdo entre sí y ninguno comprobado.

Nos pasó literalmente. Una afirmación del sitio no cuadraba con el fichero de contexto del producto, y la conclusión cómoda era corregir el sitio. Al bajar al código, el que estaba desactualizado era el fichero de contexto. El sitio decía la verdad.

La regla que sacamos es incómoda pero corta: la autoridad es lo que se ejecuta. La migración, no la especificación. El fichero de configuración, no el diagrama. La línea del manejador, no el comentario que la precede. Todo lo demás es una opinión bien intencionada sobre el sistema.

El fallo silencioso: datos con confianza equivocada

El segundo ejemplo que nos gusta contar no rompió nada, y por eso es el mejor.

Habíamos tenido un experimento A/B en la portada: dos versiones distintas, un reparto por cookie, atribución de las altas a cada rama. Un montaje normal. En agosto retiramos el experimento y publicamos una portada nueva.

Retiramos el experimento. No retiramos el reparto.

Durante un mes largo, el middleware siguió sorteando una cohorte para cada visitante nuevo y guardándola noventa días, mientras la página servía siempre la misma portada. El resultado no fue un error: fueron dos sistemas de analítica describiendo distinto a la misma persona. Uno reportaba la portada real. El otro reportaba la rama del sorteo, que ya no correspondía a nada que nadie hubiera visto. Y las altas quedaban etiquetadas con una cohorte imaginaria.

Ninguna alerta se disparó, porque desde fuera todo funcionaba. Los paneles se llenaban de números. Los números tenían la forma correcta. Simplemente no medían lo que decían medir.

Esa es la firma de la tercera casilla: no un fallo, sino confianza injustificada. Y solo aparece si alguien se sienta a preguntar de dónde sale cada dato.

Lo que puede comprobar un script, que lo compruebe un script

Buena parte de este trabajo es leer con cuidado, y esa parte no se automatiza. Pero hay un subconjunto que sí, y conviene sacarlo del terreno del criterio humano cuanto antes:

Paridad entre idiomas. Si publicas en dos lenguas, el número de claves debe coincidir y ninguna debe estar huérfana en un lado. Es una comprobación de tres líneas que atrapa secciones que solo existen en un idioma.
Comandos que resuelven. Si tu documentación cita un servicio, un puerto o una ruta, comprueba que existan en los manifiestos que publicas.
Consultas que ejecutan. Si un informe imprime SQL para que otros lo peguen, ejecútalo contra la base antes de publicarlo. Un SELECT con una columna mal escrita se lee estupendamente.

Y una lección que nos costó un rato, porque es contraintuitiva. Queríamos enlazar una lista filtrada de versiones en GitHub, y la URL con el parámetro de filtro devolvía 200 OK. Parecía correcta. Al contar los elementos de la respuesta, resultó que devolvía la lista entera, sin filtrar: el parámetro se ignoraba en silencio.

Un 200 no es una comprobación. Es la confirmación de que el servidor te contestó. Si quieres saber si algo filtra, ordena o excluye, tienes que comparar el resultado con uno que sepas distinto. Vale para las URLs que enlazas y vale, exactamente igual, para la afirmación que escribiste sobre ellas.

Lo que queda

Encontramos más de lo que cuenta este artículo, y lo arreglamos en la misma pasada. Pero el inventario de nuestros tropiezos envejece igual de rápido que la página que los contenía, y no es lo que te sirve.

Lo que cambia de verdad no es la lista de correcciones: es que ahora cada afirmación pública lleva anotada, en el propio código, la fuente que la sostiene. Cuando esa fuente cambie, el cambio aparece como una diferencia en una revisión de código, delante de alguien, en vez de quedarse quieto en una página que nadie relee.

Es la misma idea que sostiene el producto que vendemos, aplicada a nuestra propia casa: detectar sirve de poco si nada recuerda. Una afirmación con su fuente al lado tiene memoria. Una afirmación suelta solo tiene la de quien la escribió.

Si quieres ver cómo queda, nuestra página de confianza fue la que salió peor parada de esta auditoría y la que más cambió. Está publicada, con sus fuentes, en /trust.