Contexto
Una demostración prueba que un recorrido puede ejecutarse. Un piloto permite observarlo en condiciones acotadas de uso. Para afirmar que se ha mejorado un servicio hace falta además un diseño de evaluación capaz de distinguir el efecto de la intervención de otros cambios. La duración del proyecto, por sí sola, no resuelve esa diferencia.
Una oficina con registros completos y otra con horas sin cobertura no son comparables por el número bruto de incidencias. Deben mostrarse tiempo observado, tiempo utilizable, entradas descartadas y revisión pendiente. La ausencia de alertas no demuestra ausencia de problemas.
En un piloto GovTech, formular el problema y aceptar la solución también requiere participación del equipo del organismo. Qué error se tolera, qué caso exige intervención y qué colectivos deben evaluarse no son decisiones que deba tomar el desarrollador a partir de una métrica agregada.
Ejemplo didáctico · situación inventada
Menos alertas después de perder cobertura
Un piloto detecta incidencias en varios equipamientos. En la segunda ronda aparecen menos alertas, pero dos fuentes dejaron de funcionar parte de la jornada y el personal no pudo revisar todas las entradas pendientes.
Qué decisión cambia. No se comunica una reducción de incidencias. Primero se separan horas observadas y utilizables, omisiones conocidas y revisión pendiente. La comparación se limita a condiciones comparables; lo que no pudo observarse queda como falta de evidencia, no como resultado favorable.
Qué comprobar antes de empezar
- Pregunta del piloto, población de uso y situaciones que quedan fuera.
- Referencia actual y muestra reservada, con cobertura de casos difíciles.
- Responsable de aceptar, rechazar o detener el uso de una salida.
- Método independiente para encontrar casos que el sistema no detecta.
- Datos, permisos, accesibilidad y condiciones operativas necesarios para la prueba.
- Qué evidencia permitiría ampliar el piloto y qué afirmaciones no podrá sostener su muestra.
Método de trabajo
Separar las preguntas de evaluación
La evaluación técnica mide error, cobertura o latencia. La operativa comprueba tiempo de revisión, carga de trabajo y tareas completadas. La de impacto estudia el cambio en el servicio. Redacta cada pregunta y su medida antes de empezar. Evita sustituir una por otra: una precisión alta no demuestra ahorro de tiempo y una encuesta de satisfacción no demuestra mejor calidad de las decisiones.
Medir lo que el sistema no ve
Revisar únicamente las alertas generadas permite estimar cuántas son correctas, pero deja fuera las omisiones. Diseña observaciones paralelas, muestras auditadas u otra referencia independiente adecuada al problema. Registra cuándo no ha sido posible observar. Si la referencia también es incompleta, explica qué error puede medirse y cuál sigue sin conocerse.
Congelar la versión durante cada comparación
Documenta modelo, umbral, fuentes y reglas utilizados en cada periodo. Si cambia un sensor o se corrige el modelo entre mediciones, separa ese cambio de una posible mejora del servicio. En una revisión humana, comprueba también desacuerdos y casos pendientes; una cola que crece puede hacer inviable un detector técnicamente bueno.
No atribuir impacto con un simple antes y después
Un cambio posterior puede coincidir con vacaciones, otra dotación de personal o una población distinta. La guía metodológica Magenta Book distingue observar un resultado de atribuirlo a la intervención. Según el problema y la viabilidad, la evaluación puede requerir comparación controlada, despliegue escalonado u otro diseño justificado. Esa guía es una referencia metodológica, no una norma de contratación española. Si el piloto solo permite una señal preliminar, así debe describirse.
Entregar una decisión de continuidad
El cierre reúne resultados por condición de uso, cobertura no conseguida, errores que siguen abiertos y coste de operación. Incluye una prueba en la que el equipo receptor ejecute tareas sin ayuda del desarrollador. Ampliar exige revisar qué cambia en nuevas sedes, fuentes y usuarios. Repetir una prueba, restringir el uso o cerrar la línea son opciones que deben quedar justificadas, igual que la integración.
Señales para detener la prueba
- Los indicadores mejoran porque se descartan periodos sin cobertura o casos difíciles sin declararlo.
- No existe una forma de observar omisiones y se afirma exhaustividad del sistema.
- Se atribuye un cambio del servicio a la IA sin un diseño que permita sostenerlo.
- El personal no puede revisar las alertas a tiempo, corregir errores o detener el uso.
Fuentes
- HM Treasury — Quality in policy impact evaluation — Diferencia observación y atribución; límites de comparaciones antes-después sin un contrafactual sólido.
- HM Treasury — Test and Learn — Evaluación progresiva para decidir si ampliar, adaptar o reconsiderar una intervención.
Para seguir con esta decisión
- ¿Cuándo necesita un problema un modelo temporal o un grafo?
- ¿Cuándo ayuda Edge AI a la privacidad por diseño?
- ¿Cómo saber si una modalidad adicional mejora un modelo multimodal?
Servicio de I+D en inteligencia artificial: alcance y entregables
Publicado por Ordantis el .