La pregunta correcta no es: “¿la IA funciona?”, sino: “¿funciona de forma confiable y segura, y el uso de esta total o parcialmente en TI hace parte del riesgo que el negocio estaría dispuesto a aceptar?”
La IA actualmente redacta documentos, resume expedientes, genera código, atiende clientes y recomienda acciones entre otras acciones y su adopción en las compañías es el resultado de una demostración ganadora: una respuesta en segundos donde antes tomaba horas o hasta semanas. Pero ahora el problema aparece cuando esa demostración se convierte en un proceso productivo sin una disciplina de Calidad “independiente” al desarrollo.
En el software tradicional esperamos resultados específicos: con la misma entrada, el sistema debería producir la misma salida, ahora cuando usamos GenAI las respuestas pueden variar y ser verdaderas y algunas otras podrían variar también sonando convincentes y aun así ser falsas.
Además, el modelo es solo una pieza donde intervienen datos, prompts, APIs, bases vectoriales, plugins, agentes, reglas de negocio y personas, entonces probar únicamente la interfaz es como revisar la pintura de un avión y asumir que los motores están funcionando de manera correcta, y aquí es donde Quality Engineering adquiere un rol estratégico dentro del ciclo de vida de la IA.
Desde el enfoque de calidad se amplía la mirada de “encontrar defectos” a prevenirlos y gestionar el riesgo durante todo el ciclo de vida. Se incluyen criterios de aceptación, calidad de datos, evaluación del modelo, seguridad, cumplimiento, observabilidad, supervisión humana y aprendizaje a partir de incidentes (Mejora continua).
1. Las respuestas convincentes que son incorrectas
En un modelo de IA este genera lenguaje probable para una solución, no una verdad garantizada. Ya que este modelo puede inventar cifras, políticas, referencias legales, causas de un incidente o fragmentos de código. El NIST (Instituto nacional de estándares y tecnología): denomina a este fenómeno “confabulación”: contenido falso presentado con seguridad. El riesgo oculto no es solo el error, sino la confianza que produce la forma de responder.
Ejemplo: Un agente o asistente interno resume un contrato y afirma que la renovación es automática y por un periodo de 24 meses. El documento real dice que es un periodo de 12 meses. Si el gerente aprueba una decisión basándose en ese resumen, el impacto trasciende el ámbito tecnológico y se convierte en un riesgo financiero, contractual y reputacional.
Qué se debe probar desde QA: Se debe crear un conjunto de evaluaciones con preguntas reales, que contenga respuestas esperadas y fuentes verificables; medir exactitud, fidelidad a la fuente, consistencia y tasa de respuestas no sustentadas. Para usos críticos se debería aplicar RAG con citación, umbrales de confianza, respuesta “no sé” y realizar hasta revisiones humanas también es válido.
2. Los datos que entran… y después no sabemos dónde terminan
Dentro del proceso de desarrollo y/o pruebas los usuarios y equipos pueden copiar en un prompt datos personales, secretos comerciales, código, credenciales o información de clientes. La exposición también puede ocurrir en logs, históricos, bases vectoriales, herramientas conectadas o respuestas del modelo.
Ejemplo: Un analista pega una base con nombres, documentos y reclamaciones para pedir un resumen. Aunque la respuesta sea correcta, la organización puede haber incumplido reglas de finalidad, minimización, consentimiento, retención o transferencia de datos.
Qué se debe probar desde QA: Se deben realizar clasificaciones de la información permitida y prohibida; anonimizar o enmascarar los datos; probar fuga de datos, aislamiento entre usuarios y borrado; verificar que los logs y la telemetría no almacenen contenido sensible. La privacidad debe ser un requisito comprobable y así mismo obligatorio.
3. El sesgo que toma decisiones injustas
Al usar la GenAI esta aprende de patrones de datos históricos, y si estos datos contienen subrepresentación, estereotipos o decisiones previas injustas, el sistema puede reproducirlos como información “correcta”.
Ejemplo: Una herramienta prioriza hojas de vida y describe como “más sólida” la experiencia de ciertos perfiles, aunque las competencias sean equivalentes. En atención al cliente, puede responder con menor precisión a variantes regionales del español o a personas con discapacidad.
Qué se debe probar desde QA: Segmentar métricas por población, idioma, escenario, etc; diseñar pruebas de pares equivalentes; evaluar lenguaje discriminatorio y resultados adversos; documentar límites y realizar evaluación de impacto.
4. La automatización con demasiada autonomía
El riesgo es mayor cuando la IA deja de recomendar (actuando como asistente) y empieza a actuar (tomar decisión y ejecutar acciones) (actuando como agente): enviar correos, modificar registros, ejecutar código, aprobar transacciones o llamar otros sistemas. Una inyección de prompt, una interpretación errónea o un permiso excesivo puede desencadenar acciones no autorizadas y errores de gran magnitud.
Ejemplo: Un agente de IA lee correos y crea órdenes de compra. Un mensaje externo contiene instrucciones ocultas para ignorar reglas previas y cambiar el proveedor. Si el agente tiene permisos amplios y no existe validación, la IA convierte texto no confiable en una acción real.
Qué se debe probar desde QA: Aplicar pruebas de privilegio, listas permitidas, validación de parámetros, separación entre sugerir y ejecutar, doble aprobación para acciones críticas (En este punto se deben contemplar validaciones humanas), pruebas adversariales y trazabilidad completa. La salida de un modelo siempre debe tratarse como entrada no confiable.
5. Cumplir hoy, fallar mañana: “falta de mantenimientos”
Un sistema puede funcionar muy bien hoy aprobando las pruebas iniciales y fallar después por cambios en el modelo, prompts, documentos, integraciones o comportamiento de usuarios. También puede depender de componentes de externos cuya versión o política cambie. Sin versionado y monitoreo, la organización no puede explicar qué ocurrió, ni reproducir un fallo o decisión de un agente.
Ejemplo: Un proveedor actualiza el modelo y el asistente comienza a rechazar más solicitudes legítimas o a citar documentos obsoletos. Desde el negocio se puede observar que “algo cambió”, pero no existe una línea base para demostrar qué, cuándo ni por qué.
Qué se debe probar desde QA: Mantener un inventario de sistemas y proveedores, versionado de modelos y prompts, pruebas de regresión antes de cada cambio, indicadores en producción, gestión de incidentes, rollback y evidencia auditable.
La diferencia entre una demo y una capacidad empresarial
El implementar GenAI con calidad no significa frenar la innovación. Significa darle frenos y cinturón de seguridad para poder acelerar, entonces una estrategia práctica comienza por clasificar el impacto del caso de uso, teniendo claro que el control de un asistente debe ser menor que el control del agente que decide, contrata, diagnostica o mueve dinero.