Piloto de IA: cómo decidir si merece pasar a producción
Un piloto de IA no se aprueba porque una demostración resulte convincente. Se aprueba cuando resuelve un caso acotado mejor que la forma actual, con errores conocidos, datos permitidos, supervisión asumible y una operación que puede mantenerse. Antes de construir, define la decisión final: escalar, corregir y repetir, o parar. Después diseña la prueba para producir la evidencia que esa decisión necesita.
Lo esencial, antes de empezar
- Define el problema, la línea base y los criterios de éxito antes de elegir modelo o proveedor; una demo posterior no debe fijar la regla de aprobación.
- Evalúa casos normales, difíciles, prohibidos y de abstención, y pondera los errores por su impacto en lugar de esconderlos en un promedio.
- Incluye el tiempo de revisión y corrección humana, la exposición de datos, el coste por caso aceptado y la capacidad de volver al proceso anterior.
- Escalar exige propietario, monitorización, reevaluación y límites de uso; un piloto aislado no es todavía un servicio de producción.
La respuesta corta: escribe la ficha de decisión primero
Un piloto útil cabe en una ficha: proceso, usuario, decisión que apoya, entrada permitida, salida esperada, baseline, conjunto de prueba, riesgos, criterios de éxito, responsable y tres posibles decisiones. Si esos campos no pueden cerrarse, aún no hay un piloto evaluable.
| Campo | Pregunta concreta |
|---|---|
| Problema | ¿Qué paso consume tiempo, crea error o limita capacidad? |
| Unidad de evaluación | ¿Un email, documento, respuesta, expediente o decisión? |
| Baseline | ¿Cómo funciona hoy y con qué calidad, tiempo y coste? |
| Uso de la salida | ¿Informa, prepara, recomienda o ejecuta una acción? |
| Fallo inaceptable | ¿Qué error obliga a bloquear o detener? |
| Decisión final | ¿Qué evidencia permite escalar, repetir o parar? |
La guía para priorizar qué proceso automatizar primero ayuda a elegir un caso por frecuencia, estabilidad, riesgo y posibilidad de medición. El piloto empieza después: comprueba si una solución concreta alcanza el resultado con límites aceptables.
Aplica cuatro gates antes de construir
- 01
Gate de proceso
El paso tiene dueño, entrada y salida; las excepciones actuales se conocen y el equipo puede describir qué es una respuesta correcta.
- 02
Gate de datos
Existe base legítima y autorización interna para usar los datos, con minimización, acceso y proveedor revisados por los responsables adecuados.
- 03
Gate de riesgo
Se ha evaluado a quién afecta la salida, qué daño puede causar y si el caso requiere análisis jurídico, sectorial o de seguridad adicional.
- 04
Gate de operación
Hay una persona que revisará excepciones, un entorno de prueba, presupuesto acotado, fechas y una ruta para detener o volver atrás.
La Comisión Europea explica el enfoque por riesgo del Reglamento de IA, incluidos actores, prácticas y casos de alto riesgo. Un artículo no puede clasificar jurídicamente el sistema de una empresa. El gate sirve para detectar cuándo hace falta revisión especializada antes de experimentar o desplegar.
Si el piloto conversa con personas, la AEPD recomienda informar, minimizar datos y advertir de posibles errores. Esas medidas se concretan con privacidad, legal y seguridad según el caso; no se añaden como una nota al final.
Construye la línea base y el conjunto de prueba
La línea base registra el proceso actual sobre la misma unidad que evaluará el piloto: tiempo activo y de espera, porcentaje que requiere corrección, resultado correcto según el responsable, coste de herramienta y trabajo de revisión. No necesita ser perfecta, pero debe medirse con una definición repetible.
- Casos frecuentes: representan el volumen real y evitan aprobar sobre una selección llamativa.
- Casos difíciles: documentos pobres, instrucciones incompletas, lenguaje ambiguo o datos contradictorios.
- Casos críticos: errores con impacto alto aunque sean infrecuentes; se evalúan por separado.
- Casos fuera de alcance: la salida correcta es rechazar, abstenerse o derivar, no improvisar.
- Casos de cambio: nuevas plantillas, políticas o fuentes que el sistema deberá encontrar en producción.
Separa un conjunto de desarrollo para iterar y otro de evaluación que no se usa para ajustar cada fallo. Conserva procedencia, permiso, versión y respuesta esperada. Si evalúas un asistente de IA con documentos y permisos, incluye perfiles distintos, documento retirado, contradicción y pregunta sin respuesta.
Mide calidad, operación y resultado de negocio por separado
| Capa | Ejemplos | Pregunta |
|---|---|---|
| Salida | Exactitud por campo, cobertura, citas válidas, abstención | ¿La respuesta cumple el criterio? |
| Riesgo | Error crítico, dato expuesto, acción prohibida, sesgo observado | ¿Qué daño podría producir? |
| Humana | Tiempo de revisión, correcciones, desacuerdos, casos escalados | ¿Cuánto trabajo real queda? |
| Operación | Latencia, disponibilidad, coste por caso, fallos de proveedor | ¿Puede mantenerse con el volumen esperado? |
| Proceso | Tiempo de ciclo, cola, retrabajo, resultado aceptado | ¿Mejora el proceso frente al baseline? |
Pondera por gravedad. Confundir dos categorías internas quizá se corrige; enviar información de otro cliente o ejecutar una acción no autorizada puede ser un criterio de parada. Publica el denominador: «18 correcciones de 200 casos evaluables» informa más que «91 %» cuando existen casos excluidos.
El NIST AI Risk Management Framework organiza el trabajo en gobernar, mapear, medir y gestionar. Es un marco voluntario útil para no reducir la evaluación a una puntuación de modelo. Adapta el rigor al impacto y documenta quién acepta el riesgo residual.
Calcula coste por caso aceptado, incluida la supervisión
Suma uso del proveedor, infraestructura, integración, observabilidad, revisión, corrección y mantenimiento. Divide por casos que alcanzan el criterio de aceptación, no por llamadas al modelo. Una salida barata que necesita rehacerse puede costar más que el proceso actual.
| Tiempo humano | Cómo registrarlo |
|---|---|
| Preparar entrada | Limpieza o contexto adicional que no existía antes |
| Revisar | Lectura necesaria para aprobar o abstenerse |
| Corregir | Edición hasta alcanzar la calidad esperada |
| Resolver excepción | Investigación, consulta a otra persona o retorno al proceso manual |
| Mantener | Cambios de prompt, fuente, modelo, evaluación y permisos |
Ejemplo hipotético: clasificar solicitudes y preparar un borrador
Ejemplo hipotético: un equipo prueba IA para clasificar solicitudes entrantes y preparar un resumen, sin enviar respuestas ni modificar el CRM. Mide el proceso manual durante dos semanas, crea casos frecuentes, ambiguos, sensibles y fuera de alcance, y exige que estos últimos se deriven. Una persona revisa categoría, evidencia y resumen desde la fuente original.
El piloto reduce tiempo en casos normales, pero confunde dos categorías con impacto de enrutado y expone demasiado texto en el log. La decisión no es escalar ni desechar automáticamente: se corrigen permisos y logging, se añade una regla determinista para el caso crítico y se repite el conjunto de evaluación sin cambiar el criterio. Este ejemplo es ilustrativo; no representa un proyecto o resultado de NAS.
El perfil de IA generativa NIST AI 600-1 recoge riesgos y acciones a lo largo del ciclo de vida. Úsalo como catálogo para revisar huecos, no como sello automático de seguridad o conformidad.
Cierra con una decisión go, corregir o no-go
- 01
Go limitado
Los criterios se cumplen en el alcance probado, los fallos críticos están controlados y existen propietario, monitorización, fallback y revisión periódica.
- 02
Corregir y repetir
Existe valor, pero una causa concreta impide aceptar: datos, regla, interfaz, coste, permisos o carga humana. Cambia una versión y vuelve a evaluar.
- 03
No-go
El caso no supera la línea base, el riesgo no puede contenerse, los datos no deben usarse o la operación cuesta más de lo que resuelve. Documentar el aprendizaje también es éxito del piloto.
- Versión de modelo, prompt, herramientas, fuentes y configuración evaluadas.
- Resultados por segmento y lista de fallos críticos, no solo promedio.
- Coste y tiempo humano por caso aceptado al volumen esperado.
- Datos, accesos, retención, proveedor y controles aprobados por sus responsables.
- Fallback, rollback, alertas, límites de autonomía y señales para pausar.
- Fecha de reevaluación ante cambio de modelo, fuente, proceso o riesgo.
Añade un presupuesto operativo al piloto
Además de calidad y tiempo, registra documentos, tokens, llamadas, reintentos y coste por caso útil. La guía para presupuestar consumo de IA propone escenarios bajo, esperado y alto, límites y alertas sin fijar precios que puedan quedar desactualizados.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
