El sistema puede funcionar y aun así estar equivocado

Esta mañana, durante mi jornada de trabajo habitual, mi jefe me llamó a una reunión para hablar sobre verificación y validación.

Es una de esas distinciones que conozco desde hace años. Cualquiera que haya pasado suficiente tiempo en ingeniería de software, ingeniería de sistemas o aseguramiento de calidad probablemente se ha encontrado con alguna versión de ella:

La verificación pregunta si construimos el sistema correctamente. La validación pregunta si construimos el sistema correcto.

Yo conocía la definición.

Lo que había olvidado era cuán consecuente se vuelve esa diferencia cuando el software ahora puede producirse a una velocidad que hace apenas unos años habría parecido absurda.

Durante la conversación, mi jefe nos contó dos historias. Una involucraba inteligencia artificial y al Ejército de Estados Unidos. La otra se remontaba mucho más atrás, a un trabajo que él había hecho en torno al programa del transbordador espacial después del desastre del Challenger.

Parecían ser historias completamente distintas.

En realidad trataban sobre el mismo problema.

Un sistema puede funcionar exactamente como fue diseñado y aun así estar equivocado.

Y la IA está a punto de hacer que ese problema sea mucho más importante.

01 El tipo peligroso de correcto

La primera historia involucraba un proceso de selección del Ejército.

Cada año, oficiales de alto rango debían evaluar a un gran número de candidatos para posiciones de liderazgo. El proceso incluía evaluaciones, entrevistas, reportes de pares y subordinados, evaluaciones cognitivas y otro material escrito.

Era costoso en la moneda que las organizaciones suelen subestimar más: la atención humana. Todo el proceso podía tomar de seis a ocho semanas.

La IA presentaba una oportunidad obvia. Entrenar un modelo usando el proceso existente, dejar que evaluara a los candidatos y comparar sus decisiones con el proceso humano histórico.

El resultado se veía notable. Lo que había tomado semanas ahora podía completarse en horas. Más importante aún, los resultados parecían coincidir con el proceso existente en aproximadamente un 96 por ciento.

Desde una perspectiva de ingeniería, eso suena a éxito. Las entradas se ingresaron. Las salidas esperadas se produjeron. El modelo reprodujo el comportamiento que había sido entrenado para reproducir. La verificación fue exitosa.

Y luego estaban los treinta oficiales.

Habían desaparecido efectivamente de la selección.

Al principio, uno podía imaginar todo tipo de explicaciones. Quizás eran candidatos límite. Quizás el proceso de apelación humana permitía que relaciones personales o políticas organizacionales anularan el algoritmo.

Eso no era lo que había pasado.

El modelo había aprendido algo que nadie tenía la intención de que aprendiera. Las evaluaciones escritas utilizadas para la selección contenían patrones de lenguaje organizacional. Los oficiales de la comunidad de inteligencia describían el desempeño de forma distinta a los oficiales de infantería. Sus reportes seguían convenciones narrativas diferentes porque esas comunidades habían desarrollado formas distintas de escribir sobre logros y liderazgo.

El modelo había aprendido, en gran medida, los patrones asociados con una de esas comunidades. No estaba rechazando a los otros oficiales porque no estuvieran calificados. Los estaba rechazando porque hablaban el dialecto organizacional equivocado.

Y aquí está la parte incómoda:

El modelo estaba funcionando.

Estaba haciendo lo que había sido entrenado para hacer. La falla no estaba necesariamente en la ejecución. La falla estaba en lo que se le había pedido a la ejecución que representara.

02 Construir el sistema correctamente

Aquí es donde una vieja distinción de ingeniería se vuelve de pronto mucho menos académica.

La verificación pregunta: ¿construimos el sistema correctamente? ¿La implementación se ajusta a la especificación? Dadas estas entradas, ¿produce las salidas que exige el diseño? ¿Se comporta el componente como se espera? ¿Los interfaces satisfacen sus contratos? ¿Pasan las pruebas?

Este es un terreno familiar para la ingeniería de software. Llevamos décadas mejorando en esto. Las pruebas unitarias verifican piezas de comportamiento cada vez más pequeñas. Las pruebas de integración verifican interacciones. El análisis estático encuentra problemas estructurales. Las revisiones de arquitectura identifican desviaciones del diseño previsto. Los pipelines de CI determinan continuamente si los cambios violan expectativas conocidas.

El desarrollo dirigido por especificaciones lleva esto aún más lejos. Si podemos hacer la intención suficientemente explícita, la IA puede generar implementaciones y podemos evaluar esas implementaciones contra la especificación. Hay un valor enorme en eso.

Pero también hay un supuesto peligroso escondido dentro de esa idea:

Que la especificación merece ser satisfecha.

La verificación no puede responder esa pregunta. Una implementación perfectamente verificada de la especificación equivocada sigue siendo el sistema equivocado. De hecho, puede ser peor. Es el sistema equivocado implementado excepcionalmente bien.

03 Construir el sistema correcto

La validación hace una pregunta distinta: ¿construimos el sistema correcto? ¿Sirve a la necesidad para la cual existe? ¿Funciona en el mundo real, bajo condiciones reales?

Esto suena similar a la verificación hasta que algo pasa una y falla la otra. El sistema del Ejército hace visible la distinción.

Imaginemos que todas las pruebas automatizadas pasan. Imaginemos que el modelo se comporta de forma consistente. Imaginemos que sus resultados reproducen de cerca los resultados históricos. Imaginemos que la arquitectura es sólida, el pipeline confiable, y que el sistema realiza su tarea miles de veces más rápido que el proceso anterior.

Podríamos acumular una cantidad impresionante de evidencia que demuestre que el sistema funciona según su diseño. Y aun así estar excluyendo a las personas equivocadas.

Eso no es un defecto de software en el sentido convencional. Es algo más incómodo:

La implementación puede ser correcta mientras nuestra representación de la realidad está equivocada.

Por eso la validación no puede ser simplemente otra etapa de pruebas al final del desarrollo. La validación es la oportunidad de la realidad para estar en desacuerdo con la especificación.

04 Hacer más rápido lo equivocado

Hubo otra observación de la conversación que se quedó conmigo.

Cuando las organizaciones adoptan IA, el punto de referencia obvio suele ser lo que ya hacen. Eso tiene sentido. Si un proceso actualmente requiere ocho semanas y la IA lo completa en dos horas, comparamos ambos. Si los humanos producen un documento y la IA produce el mismo documento, los comparamos. Si los desarrolladores implementan una función en dos semanas y un agente la implementa en veinte minutos, comparamos el software resultante.

Necesitamos una línea base. El problema comienza cuando esa línea base se convierte silenciosamente en nuestra definición de lo correcto.

Un proceso histórico nos dice cómo una organización resolvió un problema antes de la IA. No prueba que esa fuera la mejor manera de resolverlo. Las organizaciones acumulan años de compromisos. Los procesos existen por viejas limitaciones técnicas, restricciones de personal, límites organizacionales, interpretaciones regulatorias, incidentes olvidados, y a veces simplemente porque nadie ha tenido suficiente razón para cambiarlos.

Los humanos aprendieron a trabajar alrededor de esas imperfecciones. Luego llega la IA. Y las automatizamos.

El resultado puede ser una eficiencia espectacular aplicada a algo que debería haberse reconsiderado primero. La IA puede hacer más rápido un buen proceso. También puede hacer más rápido un proceso mediocre. Puede hacer más rápido un proceso sesgado. Puede hacer más rápido un proceso innecesario. Puede hacer más rápida la decisión equivocada.

La velocidad no transforma un mal proceso en uno bueno.

A veces solo elimina la fricción que antes limitaba qué tan rápido podía propagarse el error.

05 Las cosas que no podemos medir

La segunda historia venía de una era completamente distinta de la computación.

Después del desastre del Challenger, mi jefe trabajó como desarrollador de software en un sistema relacionado con la detección de condiciones asociadas a fugas en los anillos O-ring. Había un problema de ingeniería inmediato. No se podía simplemente conectar un monitor útil al O-ring y preguntarle al software si estaba fugando. Lo que necesitaban saber no era directamente observable de la manera que necesitaban.

Así que los ingenieros se hicieron una pregunta distinta. Si un O-ring estuviera fugando, ¿qué más sucedería? El combustible y los gases se comportarían de manera diferente. Las relaciones de presión cambiarían. Las tasas de agotamiento químico y las mezclas en otras partes del sistema se desviarían de lo que normalmente debía ocurrir a medida que aumentaba la velocidad y se quemaba el combustible.

Esas cosas sí podían medirse. El software, por lo tanto, no necesitaba observar el O-ring directamente. Podía observar las consecuencias de que un O-ring se comportara de forma incorrecta.

Esa idea se quedó conmigo desde que terminó la conversación. Porque describe algo mucho más grande que la instrumentación de una nave espacial.

Siempre habrá cosas en los sistemas complejos que no podemos medir directamente.

La pregunta es si podemos identificar la evidencia que esas cosas deberían dejar a su paso.

06 La evidencia es parte del diseño

Los ingenieros de software a menudo tratan la observabilidad como algo que se añade después de que se han tomado las decisiones de diseño importantes. Logs. Métricas. Trazas. Dashboards. Maquinaria operativa útil.

Pero la historia del Challenger sugiere una interpretación más fundamental. La evidencia en sí misma puede diseñarse. Si afirmamos que un sistema posee cierta propiedad, deberíamos preguntar: si esta afirmación es verdadera, ¿qué más deberíamos poder observar?

Esa pregunta cambia cómo pensamos sobre la verificación. También cambia cómo pensamos sobre la validación. La verificación requiere evidencia de que la implementación corresponde a la especificación. La validación requiere evidencia de que la especificación corresponde a la realidad.

Esas no son necesariamente la misma evidencia. Y no deberían serlo.

Si validamos un sistema nuevo usando exclusivamente los mismos supuestos que produjeron su especificación, hemos creado un bucle epistemológico cerrado. El sistema nos dice que es correcto porque se comporta según la definición de corrección que le dimos.

Eso demuestra conformidad. No demuestra verdad.

07 La vieja V tiene algo que enseñarnos

La ingeniería de sistemas ha representado esta distinción durante décadas a través del Modelo en V.

Del lado izquierdo, descomponemos progresivamente el problema: requisitos, análisis del sistema, diseño de software, diseño de módulos, y eventualmente código. Del otro lado, volvemos a subir hacia la intención original: pruebas unitarias, pruebas de integración, pruebas del sistema, pruebas de aceptación.

Los niveles inferiores hacen preguntas cada vez más técnicas. ¿Este módulo se comporta correctamente? ¿Estos componentes interactúan correctamente? ¿El sistema integrado se comporta según su diseño?

A medida que subimos hacia la cima, sin embargo, la pregunta cambia. Eventualmente regresamos a donde todo comenzó.

¿Esto realmente resuelve el problema?

Esa simetría es más importante en un entorno de ingeniería impulsado por IA de lo que parece a primera vista. La IA está haciendo que el descenso sea cada vez más fácil. Los requisitos pueden convertirse en especificaciones. Las especificaciones pueden convertirse en diseños. Los diseños pueden convertirse en código. El código puede convertirse en pruebas. Los agentes pueden avanzar a través de enormes cantidades de ese trabajo más rápido que cualquier organización de ingeniería compuesta enteramente por humanos.

Pero acelerar el descenso por el lado izquierdo de la V no resuelve automáticamente el ascenso de regreso. Si acaso, lo hace más importante. Porque cuanto más rápido podamos transformar la intención en implementación, más rápido un supuesto incorrecto puede convertirse en un sistema funcional.

08 Vi una versión pequeña de esto ayer

La conversación también me hizo pensar en algo en lo que había estado trabajando el día anterior.

Estaba revisando una de nuestras habilidades de análisis de código asistidas por IA. Su trabajo era inspeccionar una base de código y producir un conjunto de prioridades de mejora.

Técnicamente, el trabajo era bueno. La información estaba ahí. El análisis era detallado. La salida estaba estructurada. Y cuando intenté usar el documento resultante, me di cuenta de que apenas podía tomar una decisión a partir de él.

La IA había tenido éxito en producir el artefacto. Había fallado en producir un artefacto para un ser humano.

Así que cambié la forma en que la información estaba organizada. No porque el análisis subyacente fuera necesariamente incorrecto, sino porque la corrección era insuficiente. El documento necesitaba ayudar a alguien a clasificar evidencia, entender la prioridad, comparar alternativas y decidir qué debía suceder a continuación.

Esa experiencia parece trivial comparada con seleccionar oficiales del Ejército o detectar fallas en naves espaciales. Pero estructuralmente es el mismo problema.

Una salida correcta no es necesariamente una salida útil.

Si un humano sigue siendo responsable del juicio, entonces la comprensibilidad humana no es un formato cosmético. Es parte del requisito del sistema.

09 El propósito de un artefacto no es existir

Esto importa cada vez más a medida que la IA comienza a producir artefactos de ingeniería a escala. Requisitos. Especificaciones. Documentos de arquitectura. Análisis de riesgo. Planes de prueba. Matrices de trazabilidad. Revisiones de código. Candidatos de mejora.

Un sistema de IA puede generar todos ellos. Pronto el problema difícil no será generarlos. El problema difícil será decidir qué merece la atención humana.

Un análisis de 900 líneas que contiene cada hecho relevante puede ser técnicamente superior a un análisis de 50 líneas. Pero si la persona responsable de tomar la decisión no puede identificar la evidencia importante dentro de él, el documento más grande puede ser operativamente peor.

Esto lleva a un principio que creo que tendremos que tomar mucho más en serio:

El propósito de un artefacto generado por IA no es existir. Su propósito es habilitar la próxima decisión.

Eso cambia lo que significa calidad. La completitud importa. La corrección importa. La trazabilidad importa. Pero también importan la comprensibilidad, la priorización, la incertidumbre y la capacidad de exponer desacuerdos. La IA no debería simplemente producir más información para que los humanos revisen. Debería ayudar a los humanos a entender dónde importa su juicio.

10 El humano en el bucle no es suficiente

Solemos responder a la incertidumbre de la IA con una frase tranquilizadora: humano en el bucle.

Pero esa descripción está incompleta. ¿En qué parte del bucle? ¿Haciendo qué? ¿Revisando todo? ¿Aprobando todo? ¿Repitiendo el análisis que la máquina acaba de realizar?

Si la IA produce diez veces más trabajo y los humanos deben revisar manualmente diez veces más salida, no hemos creado un sistema de ingeniería inteligente. Hemos creado un productor más rápido que alimenta el mismo cuello de botella humano.

La pregunta más útil es:

¿Dónde crea el juicio humano información que la máquina no puede obtener simplemente ejecutando la especificación?

Eso tiende a ocurrir alrededor de la incertidumbre. Excepciones. Evidencia contradictoria. Consecuencias inesperadas. Supuestos débiles. Condiciones novedosas. Y lugares donde la realidad discrepa de lo que creíamos que haría la realidad.

Los treinta oficiales importan precisamente porque representan desacuerdo. Las relaciones inusuales de los sensores alrededor de un O-ring con fuga importan porque revelan algo que no puede observarse directamente. El reporte de ingeniería difícil de leer importa porque un humano no puede tomar la decisión que el artefacto supuestamente existe para respaldar.

Estos no son inconvenientes alrededor del sistema. Son donde ocurre el aprendizaje.

11 De pipeline a bucle de aprendizaje

Durante años, el desarrollo de software se ha representado a menudo como alguna variación de un pipeline:

Requisitos → Diseño → Implementación → Pruebas → Lanzamiento

La IA hace que ese modelo sea cada vez más inadecuado. Una representación más útil podría verse algo así:

Intención → Especificación → Ejecución de IA → Evidencia → Verificación → Validación → Juicio Humano

Pero incluso eso está incompleto. Porque la validación puede decirnos que nuestra especificación estaba equivocada. El juicio humano puede exponer un supuesto que no sabíamos que teníamos. La evidencia operativa puede revelar una condición que nadie anticipó.

Esos descubrimientos tienen que viajar hacia atrás. Así que el proceso se cierra:

Intención → Especificación → Ejecución → Evidencia → Verificación → Validación → Juicio Humano → Aprendizaje → Especificación Refinada

Y luego vuelve a suceder. Esto no es simplemente humano en el bucle. Es un bucle de aprendizaje continuo entre la especificación y la realidad.

12 La IA cambia dónde vive el valor de la ingeniería

Durante la mayor parte de la historia del software, la implementación era costosa. Convertir una idea en software confiable requería enormes cantidades de esfuerzo humano. Así que las organizaciones de ingeniería optimizaron alrededor de la implementación. Los frameworks redujeron el trabajo repetitivo. Las plataformas en la nube redujeron el trabajo de infraestructura. DevOps redujo la fricción de despliegue. CI/CD redujo el costo de integración.

La IA es otro paso en esa progresión, pero potencialmente uno mucho más grande. Si la implementación se vuelve dramáticamente más barata, el cuello de botella se mueve. El recurso escaso ya no es simplemente la capacidad de producir código. Se convierte en la capacidad de decidir qué debe construirse, expresar esa intención con precisión, identificar evidencia significativa, reconocer cuándo la realidad contradice nuestros supuestos, y decidir qué cambiar cuando eso sucede.

La IA hace más barata la ejecución. No hace más barato el juicio.

Puede hacer que el juicio sea más valioso.

13 La realidad tiene la última palabra

Hay algo atractivo en las especificaciones. Crean certeza. Podemos inspeccionarlas. Versionarlas. Probarlas. Trazar los requisitos a través de la arquitectura hasta la implementación.

Para la ingeniería de software impulsada por IA, creo que las especificaciones se volverán aún más importantes porque las máquinas necesitan representaciones explícitas de la intención si esperamos que actúen de forma autónoma.

Pero las especificaciones tienen una propiedad peligrosa. Pueden estar equivocadas. Y ninguna cantidad de calidad en la implementación puede reparar una comprensión incorrecta del problema.

Por eso la verificación y la validación deben permanecer separadas. La verificación pregunta si la realidad dentro de la máquina se ajusta a nuestra especificación. La validación pregunta si nuestra especificación sobrevive al contacto con la realidad fuera de la máquina. La evidencia conecta ambas. El juicio humano decide qué hacer cuando están en desacuerdo.

La conversación de esta mañana me recordó algo que había sabido durante años, pero que había dejado convertirse en una definición de ingeniería en lugar de un principio de ingeniería.

Definitivamente deberíamos hacer que la IA sea mejor construyendo los sistemas correctamente. Deberíamos hacer que las especificaciones sean precisas, las implementaciones trazables, las pruebas ejecutables, la evidencia observable, y la verificación cada vez más automatizada.

Pero nada de eso elimina la pregunta que más importa.

¿Construimos el sistema correcto?

Porque el sistema de IA más peligroso puede no ser el que falla. Puede ser el que hace exactamente lo que le dijimos que hiciera.