Envía el mismo código a un revisor de IA dos veces. No cambies nada. Espera los resultados.
Lo más probable es que no coincidan. No de forma dramática —no obtendrás un dictamen opuesto—, pero sí con suficiente varianza como para que un ingeniero no sepa cuál de los dos veredictos tomar en serio. Si necesitaras esa consistencia para tomar una decisión de producción, acabas de descubrir que tu "herramienta de calidad" tiene un problema de calidad propio.
Este es el patrón que más aparece esta semana en conversaciones técnicas: sistemas de IA que funcionan, que pasan los tests, que no generan errores en los logs, pero que producen resultados que varían de forma impredecible según la sesión, el orden de los tokens o el estado interno del modelo. No es un bug en el sentido clásico. Es algo más difícil de detectar y, por eso mismo, más peligroso de ignorar.
La consistencia no es lo mismo que la precisión: un modelo puede acertar el 80% de las veces y aun así ser inutilizable si no sabes cuándo falla.
Los sistemas de verificación basados en IA heredan la misma varianza que intentan controlar, creando bucles de falsa seguridad.
La solución no está en mejores modelos, sino en arquitecturas que traten la inconsistencia como una condición de partida, no como una excepción.
Deriva: Cuando el Sistema Funciona pero no se Puede Confiar en Él
En ingeniería clásica, un sistema que falla lo hace de manera reconocible: lanza una excepción, devuelve un código de error, deja un rastro en el log. Puedes escribir un test que lo reproduzca. Puedes abrir un ticket. Puedes arreglarlo.
Los sistemas de IA introducen una categoría de fallo distinta: la deriva silenciosa. El sistema responde. El sistema parece correcto. Pero la respuesta varía de una ejecución a otra para el mismo input. En un contexto de revisión de código, esto significa que el mismo pull request puede recibir diez observaciones en la primera pasada y seis en la segunda, con solapamiento parcial pero no total. ¿Cuál es la verdad? ¿Cuál implementas?
Este problema no es nuevo en términos teóricos —la temperatura y el muestreo estocástico son características conocidas de los LLMs—, pero la industria lleva dos años desplegando estos sistemas en flujos de trabajo donde la consistencia importa, sin haber resuelto cómo medir esa inconsistencia de forma sistemática. Se detecta cuando alguien hace la prueba manualmente y se lleva la sorpresa. En la mayoría de los casos, no se detecta.
El problema se agrava cuando el sistema de IA no solo genera contenido, sino que toma decisiones de flujo: aprobar o rechazar un cambio, escalar o no una alerta, marcar o no un documento para revisión. Aquí la inconsistencia deja de ser molesta y se convierte en un riesgo operativo real. La superficie de ataque más peligrosa en arquitecturas de IA no son los prompts maliciosos, sino los comportamientos que nadie ha auditado porque el sistema "parecía funcionar".
La trampa del silencio: alertas que dejan de importar
Hay un patrón relacionado que merece su propia mención. Cuando un sistema de IA se despliega para filtrar alertas —reducir el ruido, priorizar lo crítico—, el equipo técnico adopta rápidamente la confianza en ese filtro. Es lógico: si la IA te ha ahorrado cincuenta alertas falsas esta semana, empiezas a asumir que las que llegan son las que importan.
El riesgo es exactamente ese. Si el modelo empieza a silenciar alertas que debería escalar —por deriva, por cambio en la distribución de los datos, por un contexto que el modelo nunca vio en training—, el equipo no lo sabrá hasta que el servidor caiga. El silencio del sistema no es prueba de que todo va bien; es el sonido de una capa de abstracción que ha absorbido un error sin comunicarlo.
Aquí la analogía no es la del portaaviones: es la del copiloto que asiente a todo. Un copiloto que nunca discrepa no es un buen copiloto; es un sistema de confirmación que da falsa sensación de control.
Verificación: El Coste que Nadie Presupuesta
Existe una idea intuitiva pero incorrecta que flota en muchos equipos de ingeniería: si usamos IA para revisar código, para verificar documentación, para validar patches, estamos reduciendo el trabajo humano. La IA hace la revisión; el humano solo aprueba.
El problema es que esta ecuación solo funciona si confías ciegamente en la IA. En cuanto introduces un mínimo de escepticismo profesional —que es exactamente lo que deberías introducir—, el tiempo de verificación no desaparece: se desplaza. Alguien tiene que comprobar que la revisión de la IA es correcta. Alguien tiene que decidir cuándo un resultado que parece extraño es un falso positivo del modelo o un problema real en el código.
Este coste oculto es especialmente visible en la documentación técnica. Si mandas un conjunto completo de documentos a un modelo para que los revise, el tiempo ahorrado en la generación del borrador puede perderse íntegramente en la verificación de las afirmaciones de alto riesgo. No todas las secciones tienen el mismo coste de revisión: una sección que documenta un endpoint de API interno puede verificarse en treinta segundos; una sección que describe un flujo de pagos o un procedimiento de compliance puede requerir diez minutos de revisión por un experto de dominio. Si no tienes un criterio explícito para decidir qué va al modelo y qué no, estás dejando esa decisión al azar.
La solución no es dejar de usar modelos. Es ser deliberado sobre qué delegar. La pregunta de qué delegarle a la IA es exactamente la misma que llevamos décadas haciendo sobre la delegación humana: ¿tiene el contexto necesario? ¿puedo verificar el resultado? ¿qué pasa si se equivoca?
El problema de usar IA para verificar IA
Hay una solución que parece obvia y que en realidad no resuelve nada: usar otro modelo para verificar el primero. Si el revisor de IA produce resultados inconsistentes, ¿por qué no poner un segundo modelo que evalúe al primero?
El problema es que el segundo modelo hereda las mismas propiedades estocásticas del primero. No estás añadiendo determinismo al sistema; estás añadiendo otra capa de varianza. En el mejor caso, tienes dos opiniones que a veces coinciden. En el peor, tienes dos opiniones que se contradicen y ningún criterio formal para decidir cuál prevalece.
Esto no significa que los sistemas de verificación multicapa sean inútiles. Significa que la verificación útil tiene que incorporar capas no estocásticas: compilación, análisis estático, tests de propiedad, bounds formales. Mecanismos que producen el mismo resultado para el mismo input, siempre. La IA puede ser una capa de ese stack; no puede ser todo el stack.
Arquitectura: Diseñar para la Inconsistencia, no Contra Ella
El error más frecuente que vemos en equipos que despliegan IA en flujos críticos es asumir que la consistencia llegará sola: con un modelo mejor, con más ejemplos en el contexto, con más fine-tuning. A veces mejora. Pero el problema de fondo —que los LLMs son sistemas probabilísticos que no garantizan determinismo— no desaparece con más parámetros. Es una característica estructural, no un bug que se parchea.
La implicación arquitectónica es directa: si tu sistema depende de que el modelo sea consistente para funcionar correctamente, tu sistema tiene un problema de diseño. La pregunta correcta no es "¿cómo hago que el modelo sea más consistente?" sino "¿cómo diseño el sistema para que funcione aunque el modelo no lo sea?".
Esto se traduce en decisiones concretas. Primero, separar las decisiones de flujo de las generaciones del modelo. El modelo puede analizar; el sistema determinístico decide. Un modelo puede señalar que un patch es potencialmente problemático; un rule engine con criterios explícitos decide si bloquea el merge. Segundo, definir umbrales de confianza explícitos y tratarlos como primera clase en la arquitectura: si el modelo no supera el umbral, la respuesta va a revisión humana, no a producción. Tercero, medir la varianza como métrica operativa, igual que se mide la latencia o la tasa de error. Si no estás midiendo cuánto varía tu modelo en el mismo input, no estás operando el sistema: lo estás tolerando.
Esto conecta directamente con algo que el software en producción exige y que los equipos suelen aprender tarde: los sistemas vivos requieren instrumentación continua, no solo en el momento del lanzamiento. Con IA en el loop, esa instrumentación necesita incluir dimensiones que no existían en los sistemas clásicos: drift de comportamiento, varianza entre ejecuciones, degradación silenciosa de la calidad de las respuestas.
Criterio: Lo que tu Stack de IA Debería Poder Responder
Hay un test de madurez simple para cualquier sistema que incorpore IA en un flujo técnico crítico. No es un test de código; es un test de criterio. Son cuatro preguntas que, si no tienen respuesta explícita en tu arquitectura, tienes un problema que no sabes que tienes.
Una: ¿sabes cuánto varían las respuestas de tu modelo para el mismo input? No intuitivamente —formalmente. ¿Tienes un proceso que lo mide, aunque sea de forma muestral? Si la respuesta es no, estás operando con confianza ciega.
Dos: ¿qué pasa cuando el modelo produce una respuesta de baja confianza o claramente inconsistente con una ejecución anterior? ¿Hay un mecanismo de escalado? ¿O simplemente se usa el resultado y nadie se entera?
Tres: ¿qué partes de tu flujo son recuperables si el modelo falla silenciosamente? Una arquitectura resiliente asume que el componente IA fallará de formas que no vas a detectar inmediatamente. ¿Qué has hecho para que ese fallo no se propague?
Cuatro: ¿tienes algún componente de verificación no estocástico en tu stack? Compilación, tests de regresión, análisis estático, validación de esquema. Si toda tu capa de calidad es probabilística, tu seguridad también lo es.
Un sistema de IA que nunca lanza errores pero produce resultados que nadie revisa no es un sistema fiable. Es un sistema que ha aprendido a fallar en silencio.
Estas preguntas no son sofisticadas. Son las preguntas que cualquier ingeniero senior haría de cualquier componente crítico. El problema es que la IA llega rodeada de suficiente novedad y promesa como para que muchos equipos suspendan momentáneamente el escepticismo profesional que aplicarían a cualquier otra pieza del sistema.
En Room 714 trabajamos con equipos que ya tienen IA en producción y quieren pasar de "parece que funciona" a "sabemos que funciona". Si tu sistema de IA lleva meses en producción y todavía no puedes responder estas cuatro preguntas, es el momento de hacer la revisión antes de que el sistema te la haga a ti. Hablamos.
