Cuando el código se produce más rápido y parte del sistema deja de ser determinista, la verificación no sobra: se convierte en la única forma de saber si algo funciona. La intuición contraria —»si la IA escribe mejor código, hará falta menos QA»— confunde dos cosas distintas: la corrección sintáctica de lo que se escribe y la adecuación de lo que hace al negocio.
Un modelo produce código que compila y hace algo razonable. No sabe si ese algo es lo que tu empresa necesita, porque esa información no está en el código: está en el proceso, en la normativa y en las excepciones que nadie ha escrito.
Los sistemas actuales mezclan componentes deterministas y probabilísticos, y cada uno se verifica de forma distinta. Confundirlos es la causa de la mayoría de los sustos en producción.
|
Aspecto |
Componente determinista |
Componente probabilístico |
|---|---|---|
|
Qué se comprueba |
Que el resultado sea el esperado |
Que el resultado sea aceptable con suficiente frecuencia |
|
Resultado del test |
Pasa o falla |
Distribución de calidad sobre un conjunto |
|
Cuándo se ejecuta |
En cada cambio |
En cada cambio y periódicamente en producción |
|
Qué detecta |
Regresiones |
Regresiones y deriva de comportamiento |
|
Quién define el criterio |
El equipo técnico |
Negocio, con casos reales evaluados |
La fila más importante es la última. En la parte probabilística, el criterio de «correcto» no lo puede fijar el equipo técnico solo, porque depende de qué considera aceptable el negocio: un resumen que omite un dato secundario puede ser perfecto en un contexto e inaceptable en otro.
Por eso el activo más valioso de un proyecto de IA no es el modelo ni el prompt: es el conjunto de casos evaluados, con la respuesta que la organización considera correcta para cada uno. Ese conjunto sobrevive a los cambios de proveedor, permite comparar alternativas de forma objetiva y detecta si una versión nueva ha empeorado algo. Es la pieza que hace posible cambiar de modelo sin miedo.
Cuando el equipo escribía todo el código a mano, la revisión entre pares cubría buena parte de la verificación. Con más volumen, esa cobertura se diluye: no porque los revisores sean peores, sino porque hay más que revisar en el mismo tiempo.
El informe DORA de 2024 midió la consecuencia en la práctica: al aumentar la adopción de IA, la estabilidad de entrega caía un 7,2%, asociada al crecimiento del tamaño de los cambios. Y el 39,2% de los desarrolladores declaraba poca o ninguna confianza en el código generado, lo que introduce un coste que rara vez se contabiliza: el tiempo de verificar manualmente algo que se supone que iba a ahorrar tiempo.
La salida no es revisar más horas. Es sustituir revisión manual por verificación automática allí donde es posible, y reservar la atención humana para lo que solo una persona puede juzgar: si esto es lo que el negocio necesita.
Pruebas unitarias e integración. Lo de siempre, y ahora más necesario porque hay más código. Escritas o al menos revisadas por una persona: si el mismo sistema genera implementación y prueba, el circuito se cierra sobre sí mismo.
Conjunto de evaluación del componente de IA. Casos reales con respuesta esperada, ejecutados en cada cambio de modelo, de prompt o de configuración. Sin esto no se puede saber si una actualización ha mejorado o empeorado el sistema.
Pruebas de las excepciones. Los casos raros del proceso, convertidos en pruebas. Es la forma de asegurar que el sistema escala a una persona cuando debe, en lugar de improvisar.
Pruebas de seguridad específicas. Intentos de inyección de prompt, comprobación de que el componente no puede exceder sus permisos, verificación de que no expone información que no debería. OWASP recoge estos vectores en su Top 10 para aplicaciones LLM de 2025.
Verificación continua en producción. Muestreo periódico de casos reales, revisados por una persona. Es la única forma de detectar deriva: un sistema puede degradarse sin que cambie ninguna línea de código, porque cambió el modelo, los datos o el contexto de uso.
La quinta capa es la que casi nunca existe y la que más incidentes evita, por la razón que explicamos al hablar de observabilidad y automatización [enlace interno]: sin medición continua, la señal de que algo va mal llega por la vía del cliente.
Esto no es un alegato conservador. El perfil de QA cambia de forma sustancial, y hacia arriba:
Es un desplazamiento de «comprobar que funciona» a «definir qué significa que funcione». La segunda tarea es más difícil, más valiosa y no se automatiza.
Cuando alguien proponga reducir la inversión en calidad porque «la IA escribe mejor código», la pregunta que ordena la conversación es: ¿cómo sabremos que ha dejado de funcionar?
Si la respuesta es que alguien lo notará, la organización ha delegado su control de calidad en la paciencia de sus clientes. Si la respuesta incluye pruebas automatizadas, un conjunto de evaluación versionado y muestreo continuo en producción, entonces sí se puede hablar de eficiencia con fundamento.
No: la aumenta. Un modelo produce código que compila y hace algo razonable, pero no sabe si eso es lo que el negocio necesita, porque esa información está en el proceso y en las excepciones, no en el código. Además, el mayor volumen de cambio diluye la cobertura de la revisión entre pares.
Con un conjunto de casos reales evaluados y su respuesta esperada, ejecutado en cada cambio de modelo, prompt o configuración. El resultado no es «pasa o falla» sino una distribución de calidad, y el criterio de aceptación lo debe definir el negocio, no solo el equipo técnico.
Es el repertorio de casos reales con la respuesta que la organización considera correcta. Es el activo más duradero de un proyecto de IA: permite comparar proveedores objetivamente, detectar si una versión nueva ha empeorado el sistema y cambiar de modelo sin asumir riesgo ciego.
Cinco: pruebas unitarias y de integración, conjunto de evaluación del componente de IA, pruebas de las excepciones del proceso, pruebas de seguridad específicas (inyección de prompt, exceso de permisos, exposición de información) y verificación continua mediante muestreo en producción.
Sí. Puede empeorar porque cambió la versión del modelo, porque cambiaron los datos de entrada o porque cambió el contexto de uso. Es la razón por la que la verificación no puede terminar en el despliegue y debe continuar con muestreo periódico revisado por personas.
Se desplaza de la ejecución manual repetitiva hacia el diseño de casos, la construcción y el mantenimiento de conjuntos de evaluación y el análisis de resultados en producción. Pasa de comprobar que funciona a definir qué significa que funcione.
¿Cómo sabrías que tu sistema de IA ha dejado de funcionar bien? Diseñamos el conjunto de evaluación, las pruebas de las excepciones y la verificación continua para que la respuesta no dependa de que se queje un cliente. Hablemos →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
