La ficha de aprobación para proyectos de IA

1. Empieza por la tarea, no por el modelo

La primera pregunta de la ficha debe ser: ¿qué decisión o actividad ejecutará la IA? Describe la tarea como una operación observable, con entrada, salida esperada y límites de actuación. “Ayudar al servicio de atención” es demasiado amplio. “Clasificar mensajes como una segunda copia de una factura, cancelación, duda técnica u otro” permite verificar el resultado. “Redactar una respuesta basándose en artículos aprobados” también es más comprobable que “responder a los clientes”.

No mezcles tareas diferentes en la misma aprobación. La clasificación, la extracción de campos, la generación de texto y la ejecución de acciones tienen fallos distintos. Si el flujo combina varias etapas, evalúa cada una por separado y después prueba la cadena completa. Esta separación ayuda a descubrir si el problema está en la interpretación de la solicitud, la recuperación de datos, la elección de una herramienta o la respuesta final.

• Define quién proporciona la entrada y en qué formato.
• Declara qué cuenta como salida correcta, incompleta o prohibida.
• Registra lo que la IA puede sugerir y lo que no puede ejecutar.
• Elige a la persona responsable de liberar, pausar o retirar el flujo.

Fuentes y referencias: [1][2]

2. Construye una muestra que represente el trabajo real

La muestra debe contener casos comunes, casos difíciles y entradas que suelen confundir a las personas o a los sistemas. Usa ejemplos históricos permitidos, datos creados específicamente para las pruebas y situaciones construidas por especialistas. No selecciones únicamente los ejemplos fáciles ni los casos que confirman la idea inicial. La distribución de la muestra debe aproximarse al uso previsto, sin ocultar excepciones importantes.

Reserva una parte de la muestra para la decisión final. Si todos los casos se utilizan para ajustar instrucciones, reglas o herramientas, la ficha pierde fuerza como prueba independiente. Como ilustración hipotética, un equipo podría reservar 120 solicitudes para la evaluación final, distribuidas entre situaciones frecuentes, ambiguas y adversariales. Esa cantidad es solo un ejemplo de planificación, no un estándar de calidad.

• Incluye variaciones de idioma, ortografía, formato y extensión cuando sean plausibles.
• Añade solicitudes con varias intenciones y contexto incompleto.
• Prueba datos ausentes, contradictorios y campos con nombres ambiguos.
• Identifica los ejemplos que contienen información sensible y controla su acceso.

Fuentes y referencias: [1]

3. Registra los errores críticos antes de calcular promedios

Un promedio puede ocultar un fallo que vuelva inviable el proyecto. Por eso, la ficha debe separar los errores según su gravedad. Un texto ligeramente más largo quizá sea aceptable en un borrador. En cambio, inventar una condición contractual, enviar información privada o llamar a una herramienta con el identificador equivocado puede exigir un bloqueo inmediato.

Describe cada error en términos observables. En lugar de “respuesta deficiente”, registra “atribuye al cliente un plazo que no aparece en la fuente” o “clasifica una cancelación como duda general”. Para cada categoría, indica la consecuencia, la frecuencia tolerable y la reacción esperada. La tolerancia puede ser cero para algunas clases, especialmente cuando la salida activa una acción externa o expone datos.

• Distingue los errores de contenido, formato, enrutamiento y acción.
• Marca los fallos que exigen bloqueo, corrección automática, derivación o solo registro.
• Prueba intentos de modificar las instrucciones mediante el contenido recibido.
• En los agentes, verifica la herramienta elegida, los argumentos enviados y los límites de ejecución.

Fuentes y referencias: [3]

4. Compara con una referencia sin IA y utiliza evaluación humana

La pregunta correcta no es solo si la IA funciona. Es si mejora, acelera o simplifica el proceso frente a una alternativa concreta. La referencia puede ser una regla existente, un clasificador tradicional, una búsqueda estructurada o el procedimiento manual actual. Documenta el costo operativo, el tiempo, la tasa de derivación y los tipos de error de esa alternativa, sin suponer que sea perfecta.

La evaluación humana debe utilizar una rúbrica breve, ejemplos de niveles de calidad y criterios de aprobación. En tareas subjetivas, pide a los evaluadores que clasifiquen o comparen respuestas sin depender de una impresión general. Un evaluador automático puede ayudar a ampliar las pruebas, pero su coincidencia con los juicios humanos debe comprobarse en el contexto específico. Las calificaciones aisladas no sustituyen el análisis de los casos rechazados.

• Define los criterios antes de revisar los resultados de la nueva implementación.
• Usa una comparación lado a lado cuando la pregunta sea qué salida satisface mejor el objetivo.
• Registra las discrepancias entre evaluadores y ajusta la rúbrica cuando sea necesario.
• Exige una aprobación explícita para cada error crítico, aunque el promedio general sea bueno.

Fuentes y referencias: [1]

5. Toma una decisión de puesta en marcha con condiciones claras

La ficha debe terminar con una decisión que alguien pueda auditar: aprobar, aprobar con alcance limitado, devolver a desarrollo o rechazar. “Aprobado” no debe significar que la IA sea confiable en cualquier situación. Puede significar que se utilizará solo para borradores, con datos restringidos, sin ejecución automática y con un mecanismo de interrupción.

Una buena regla de decisión combina un resultado agregado con barreras por categoría. Como ejemplo hipotético, un equipo puede exigir al menos un 90 por ciento de clasificaciones correctas, ningún caso de filtración en el conjunto de prueba y derivación obligatoria para entradas ambiguas. Estos límites son ilustrativos. Cada organización debe definirlos según el impacto de la tarea, el costo del error y su capacidad de recuperación.

La complejidad de la arquitectura también debe estar justificada por la ficha. Si una llamada sencilla o un flujo fijo resuelve el problema, no añadas un agente autónomo solo para aumentar la flexibilidad. Los sistemas con más etapas, herramientas o transferencias ofrecen más puntos que evaluar y más caminos para fallar. La recomendación es aumentar la complejidad únicamente cuando las pruebas muestren un beneficio medible para la tarea.

• Delimita los usuarios, datos, herramientas y horarios del primer lanzamiento.
• Especifica las condiciones que suspenden automáticamente el flujo.
• Registra la versión de las instrucciones, los datos de referencia y los componentes utilizados.
• Define quién puede modificar el sistema y cuándo es obligatoria una nueva evaluación.

Fuentes y referencias: [2][3]

6. Supervisa el comportamiento después de la puesta en marcha

La aprobación es una fotografía; el monitoreo sigue la película. Registra las entradas relevantes, las salidas, las decisiones de enrutamiento, las llamadas a herramientas, las negativas, las derivaciones y las señales de error, respetando las reglas internas de acceso y conservación. Sin estos registros, será difícil distinguir un cambio en el modelo de un cambio en el perfil de los usuarios, los documentos disponibles o el sistema conectado.

Sigue métricas relacionadas con la tarea, no solo la latencia o el volumen. Observa la proporción de casos derivados, la frecuencia de correcciones, los errores críticos, la distribución de categorías y las reclamaciones relacionadas con la salida. Crea una cola de casos nuevos para ampliar la muestra de evaluación. Todo cambio relevante en las instrucciones, herramientas, fuentes o modelo debe pasar de nuevo por las pruebas que protegen contra regresiones.

En un flujo que utiliza herramientas, supervisa los argumentos inválidos, las llamadas inesperadas y los intentos de actuar fuera del alcance. El contenido externo o enviado por los usuarios no debe controlar directamente una instrucción privilegiada. Los campos estructurados, las validaciones y las confirmaciones para operaciones sensibles reducen las vías de propagación de comandos indebidos, aunque no eliminan la necesidad de realizar pruebas continuas.

• Define los umbrales que activan una investigación y una suspensión.
• Revisa periódicamente una muestra de casos reales y casos límite.
• Compara la versión actual con la última versión aprobada.
• Mantén una vía sencilla para volver al procedimiento sin IA.

Fuentes y referencias: [1][3]