Checklist: 20 preguntas antes de arrancar un proyecto de IA

La pregunta útil no es si una idea de IA parece prometedora. Es si existe evidencia suficiente para invertir en la siguiente prueba sin esconder dependencias, riesgos o trabajo previo.

Esta checklist convierte una conversación imprecisa en una recomendación concreta: probar ahora, validar primero, secuenciar para más adelante o reformular el caso. No sustituye un diagnóstico, pero evita aprobar un proyecto solo porque la demo resulta convincente.

Cómo utilizar la checklist

Reúne al propietario del proceso, uno o dos usuarios reales y las personas responsables de datos, tecnología y riesgo. Para cada pregunta registra una de estas respuestas:

La puntuación es una heurística de trabajo de INSTINTIA, no una certificación de viabilidad. Anota la evidencia y el propietario de cada pendiente; marcar casillas sin ese registro produce una seguridad ficticia.

1. Problema y valor

1. ¿El problema está descrito sin mencionar la solución? Debe nombrar el proceso, el usuario, la fricción observable y el resultado afectado. «Queremos un agente» no es un problema; «las incidencias urgentes esperan dos días por una clasificación manual» sí se puede investigar.
2. ¿La fricción está respaldada por evidencia? Aporta registros, observación, una muestra de expedientes o comentarios estructurados de usuarios. Evita convertir una impresión aislada en una demanda empresarial.
3. ¿Existe una línea base con unidad, periodo y método de medida? Por ejemplo: tiempo de ciclo mediano durante ocho semanas, porcentaje de expedientes devueltos o número de traspasos por caso.
4. ¿Sabemos qué resultado justificaría continuar? Define un cambio mínimo relevante y la condición que no debe empeorar: reducir espera sin aumentar errores, aumentar capacidad sin trasladar trabajo a revisión o mejorar consistencia sin perder trazabilidad.

Para profundizar en esta fase, consulta cómo convertir una fricción operativa en un caso de uso y cómo priorizar oportunidades por valor y viabilidad.

2. Proceso, usuarios y propiedad

5. ¿El flujo tiene un inicio, un final y excepciones delimitados? «Gestionar contratos» es demasiado amplio. Una primera versión podría limitarse a comparar contratos recibidos con plantillas aprobadas y derivar cláusulas no estándar.
6. ¿Un propietario operativo puede cambiar el proceso y aceptar el resultado? El responsable técnico no sustituye a quien decide qué significa «bien», resuelve excepciones y responde por el funcionamiento diario.
7. ¿Los usuarios reales participarán en la definición y la prueba? Identifica quién hará el trabajo, quién recibirá la salida y quién tendrá que revisarla. Una prueba aislada del equipo de innovación no demuestra adopción.

3. Datos, conocimiento e integración

8. ¿Están identificadas las fuentes que necesita el sistema? Registra sistema, propietario, formato, frecuencia de actualización y sensibilidad. «Está en SharePoint» no explica qué documentos son vigentes ni quién puede verlos.
9. ¿Existe acceso legítimo y técnicamente viable? Confirma permisos, base jurídica o contractual, API o mecanismo de extracción, residencia y restricciones de reutilización. El acceso manual de una persona no implica que el sistema pueda utilizar esos datos.
10. ¿La calidad es suficiente para la primera prueba? Comprueba cobertura, duplicados, campos ausentes, versiones y ejemplos representativos. No hace falta limpiar toda la organización, pero sí el ámbito que se va a evaluar.
11. ¿Las integraciones necesarias caben en el alcance inicial? Distingue lectura, escritura y acciones externas. Consultar un pedido no tiene el mismo riesgo ni esfuerzo que modificarlo, aprobarlo o enviar una comunicación al cliente.

4. Riesgo, seguridad y cumplimiento

12. ¿Sabemos qué ocurre cuando el sistema se equivoca? Describe el daño posible, su reversibilidad y cómo se detectaría. Un resumen incorrecto y una orden de pago incorrecta requieren niveles de autonomía distintos.
13. ¿Están definidos los límites, permisos y puntos de supervisión? El sistema debe saber qué puede leer, proponer o ejecutar, con qué identidad y cuándo necesita aprobación humana.
14. ¿Se han revisado privacidad, seguridad y obligaciones aplicables? Clasifica datos y uso, identifica a proveedor y desplegador cuando corresponda, y documenta las revisiones necesarias. Desde el 2 de agosto de 2026, el artículo 50 del AI Act aplica obligaciones de transparencia a determinados sistemas interactivos y contenidos sintéticos; no todas afectan a todos los casos.

5. Evaluación y evidencia

15. ¿Existe un conjunto de pruebas representativo antes de construir? Incluye casos normales, difíciles, excepciones y ejemplos que el sistema debe rechazar o escalar. Reservar parte de la muestra evita ajustar el piloto a respuestas ya conocidas.
16. ¿Las métricas cubren calidad y resultado operativo? Precisión técnica, utilidad, correcciones, tiempo de revisión, tasa de resolución, coste por caso y experiencia pueden ser relevantes. Elige solo las que respondan a la decisión.
17. ¿Hay umbrales para avanzar, corregir o detenerse? Define por adelantado qué evidencia permite ampliar, qué obliga a otra iteración y qué resultado invalida el enfoque. Sin criterio de parada, cualquier piloto puede declararse prometedor.

La evidencia útil debe conservar fuente, línea base, periodo y limitaciones. La guía de OpenAI Academy sobre evidencia de valor distingue adopción, eficiencia, calidad, operación segura y resultado del equipo; no exige medirlo todo, sino medir lo que corresponde a la decisión.

6. Entrega, adopción y operación

18. ¿La primera prueba está acotada a usuarios, casos y duración? Define quién participa, qué parte del flujo entra, durante cuánto tiempo y qué queda explícitamente fuera.
19. ¿Hay capacidad para integrar, formar, soportar y corregir? Un prototipo puede construirlo un equipo pequeño; una solución operativa necesita atención a incidencias, cambios en fuentes, permisos, adopción y mantenimiento.
20. ¿Está acordada la decisión posterior? Nombra quién revisará la evidencia, en qué fecha y qué opciones tendrá: escalar, repetir con cambios, secuenciar después de una dependencia o cerrar el proyecto.

Cinco bloqueos que la puntuación no compensa

No recomendamos empezar el piloto si ocurre cualquiera de estas situaciones:

• Nadie es propietario del resultado operativo.
• No existe acceso legítimo a los datos o sistemas necesarios.
• Un error relevante sería difícil de detectar o revertir y no hay control humano adecuado.
• No existe una línea base mínima con la que comparar.
• El equipo no ha acordado qué evidencia detendrá el proyecto.

Resolver un bloqueo puede ser el siguiente proyecto. A veces consistirá en observar el proceso, ordenar documentos, aclarar permisos o rediseñar una aprobación; ese trabajo tiene valor aunque todavía no produzca una demo.

Cómo interpretar el resultado

No uses diferencias de uno o dos puntos para ordenar una cartera. Compara también valor potencial, complejidad, riesgo y dependencias. La evaluación de preparación de flujos de OpenAI Academy utiliza las categorías test now, validate further, sequence later y avoid for now, y recomienda no inventar impacto, demanda, viabilidad o retorno cuando la evidencia no existe.

Preguntas frecuentes