framework
Calidad en sistemas con IA: QA debe diseñarse desde la arquitectura
En sistemas con IA, QA no puede quedar al final. La calidad debe diseñarse desde la arquitectura: datos, prompts, contexto, evaluaciones y monitoreo.
Durante mucho tiempo, muchas organizaciones trataron QA como una etapa del ciclo de desarrollo: se construye, se prueba, se corrige y se libera.
Ese enfoque ya era limitado en sistemas tradicionales. En sistemas con inteligencia artificial, se queda corto muy rápido.
La IA cambia la naturaleza de la calidad. Introduce comportamiento probabilístico, dependencia fuerte del contexto, sensibilidad a datos de entrada, cambios frecuentes en modelos y nuevas formas de interacción con herramientas externas.
Un sistema con IA puede fallar aunque el código esté correcto. Puede fallar aunque la API responda. Puede fallar aunque la demo se vea impecable.
Puede fallar porque recuperó mal el contexto. Porque el prompt induce una respuesta ambigua. Porque el modelo cambió su comportamiento. Porque la fuente de datos está desactualizada. Porque no existe un criterio claro para evaluar la salida. O porque una acción automática no tenía límites suficientes.
Por eso, en sistemas con IA, QA no puede quedar al final. Debe diseñarse desde la arquitectura.
Probar al final llega tarde
Cuando QA entra solo al final, llega tarde a las decisiones que más afectan la calidad.
Para ese momento ya se eligieron modelos, se conectaron datos, se definieron prompts, se establecieron permisos, se diseñó el flujo de aprobación y se asumió cómo debería comportarse el sistema.
Si esas decisiones no incorporaron criterios de calidad, QA queda detectando síntomas en vez de prevenir causas.
En sistemas con IA, muchos problemas no se corrigen con un bug fix puntual. Requieren revisar fuentes, rediseñar instrucciones, ajustar evaluaciones, limitar acciones, mejorar observabilidad o cambiar el flujo de revisión humana.
La calidad debe participar antes: cuando se define qué hará el sistema, qué no hará, cómo se medirá éxito, qué errores son aceptables, qué errores son críticos y qué evidencia debe quedar disponible.
Nuevas superficies de fallo
Los sistemas con IA amplían la superficie de calidad.
La primera superficie son los datos. Un sistema que usa información incompleta, duplicada o mal estructurada puede producir respuestas convincentes pero equivocadas.
La segunda son los prompts. En muchos sistemas, el prompt funciona como una pieza de comportamiento: define tono, límites, formato, criterios y prioridades. Si cambia sin control, cambia el sistema.
La tercera es el contexto. En arquitecturas con recuperación de información, agentes o herramientas conectadas, el resultado depende de qué contexto se entrega al modelo. Recuperar el documento equivocado puede ser tan grave como un error de lógica.
La cuarta son los modelos. Distintos modelos tienen fortalezas, costos, límites y comportamientos diferentes. Incluso el mismo modelo puede evolucionar. Eso exige evaluación continua, no una prueba única.
La quinta son las herramientas. Cuando la IA puede llamar APIs o modificar registros, QA debe considerar no solo la respuesta generada, sino el efecto operacional de esa respuesta.
La sexta es la interacción humana. Un sistema puede ser técnicamente correcto y aun así inducir exceso de confianza, confusión o dependencia. La calidad también incluye cómo una persona entiende límites, revisa resultados y decide cuándo intervenir.
QA como diseño arquitectónico
Diseñar QA desde la arquitectura implica incorporar controles en varias capas.
En la capa de datos, se necesitan criterios de frescura, completitud, permisos y fuente confiable. No basta con conectar documentos; hay que saber cuáles se usan, para qué y con qué nivel de confianza.
En la capa de instrucciones, se requiere versionado, revisión y pruebas. Los prompts importantes no deberían modificarse como texto informal sin registro. Deben tratarse como componentes del sistema.
En la capa de evaluación, hay que definir casos representativos, casos límite y casos de riesgo. No todos los outputs se pueden validar con tests deterministas, pero sí se pueden establecer rúbricas, comparaciones, evaluaciones humanas y métricas de desempeño.
En la capa de ejecución, se necesitan permisos y límites. Si el sistema puede actuar, debe estar claro qué acciones requieren aprobación y cuáles pueden ejecutarse automáticamente.
En la capa de observabilidad, se requiere trazabilidad. Cuando algo falla, el equipo debe poder revisar entrada, contexto, salida, herramientas utilizadas y decisión humana asociada.
En la capa de operación, se necesita monitoreo posterior al despliegue. La calidad no termina cuando el sistema sale a producción; empieza una nueva etapa de aprendizaje con uso real.
Prácticas mínimas
Una práctica básica es construir datasets de evaluación con casos reales o representativos. No tienen que ser enormes al inicio, pero deben cubrir escenarios frecuentes, excepciones y riesgos conocidos.
Otra práctica es definir criterios de aceptación para respuestas de IA: exactitud, completitud, tono, formato, uso correcto de fuentes, reconocimiento de incertidumbre y respeto de límites.
También es importante registrar cambios en prompts, modelos, fuentes y herramientas. Si el comportamiento empeora, el equipo necesita saber qué cambió.
Para flujos sensibles, conviene incorporar revisión humana obligatoria. No como freno genérico, sino como control diseñado donde el riesgo lo justifica.
Finalmente, se debe monitorear producción: qué errores aparecen, qué casos escalan, qué respuestas se corrigen, qué usuarios reportan problemas y qué patrones indican degradación.
El rol estratégico de QA
QA puede tener un rol mucho más estratégico en la era de la IA.
No solo como equipo que encuentra defectos, sino como disciplina que ayuda a diseñar sistemas confiables.
Eso requiere cambiar la conversación. QA no debería entrar solo a validar pantallas o flujos felices. Debería participar en preguntas como: qué significa que este sistema responda bien, qué evidencia necesita mostrar, qué límites no debe cruzar, cómo se comporta ante incertidumbre y cómo sabremos si está mejorando o empeorando.
En productos con IA, la calidad es una combinación de ingeniería, datos, diseño de interacción, operación y criterio de negocio. Reducirla a testing final es quedarse corto.
Cierre
La IA no elimina la necesidad de calidad. La vuelve más importante.
Cuando un sistema genera, interpreta o actúa con apoyo de IA, sus fallas pueden ser menos evidentes que un error tradicional. Pueden sonar correctas, parecer útiles y aun así estar equivocadas.
Por eso QA debe estar incorporado desde la arquitectura, no pegado al final como una revisión tardía.
La calidad no es una fase. Es una forma de diseñar sistemas que puedan operar en el mundo real.