Empezamos por una tarea concreta, validamos la oportunidad, diseñamos datos e integración, probamos los fallos relevantes y sólo entonces ampliamos volumen o autonomía. Cada fase deja una decisión verificable.
Cada etapa existe porque responde una pregunta distinta: si merece la pena, si funciona, si puede integrarse y si puede operarse con control.
Reconstruimos cómo ocurre hoy la tarea: quién la inicia, qué información consulta, qué sistemas intervienen, dónde aparecen esperas y qué excepciones conoce el equipo. De ahí sale una unidad de trabajo concreta y una línea base contra la que medir.
Separamos lo que hará el modelo de lo que seguirá siendo regla, software e intervención humana. Fuentes, permisos, herramientas, condiciones de parada y coste del error definen cuánta autonomía tiene sentido.
No pedimos documentación perfecta antes de empezar. Necesitamos ejemplos reales y acceso a las personas que conocen el proceso. Cuando seguridad, legal, datos o sistemas internos cambian una decisión de arquitectura, los incorporamos antes de construirla.
Una fase termina con decisiones, entregables y pruebas acordados, además de dependencias pendientes. El siguiente paso tiene su alcance: validar una duda, resolver datos, integrar un flujo o ponerlo en operación. El registro identifica quién acepta y quién mantiene cada parte.
Antes de pedir propuesta, completa el brief de selección de una agencia de IA para 2027. Si necesitas valorar varios procesos, empieza por la auditoría de oportunidades. Si la tarea y los sistemas ya están claros, describe directamente ese encargo.
Alcance, piloto, desarrollo, revisión humana y relación con el equipo interno.
No. Si el proceso, los datos y el objetivo ya están claros podemos entrar directamente en arquitectura o desarrollo. Análisis inicial existe para reducir incertidumbre; no para añadir una fase comercial obligatoria.
Cuando existe una incertidumbre material sobre calidad del modelo, disponibilidad de datos, integración, adopción o coste. El piloto debe responder esa duda concreta. Si todo está suficientemente validado, puede tener más sentido construir directamente una primera versión de producción acotada.
Por reversibilidad, coste del error y evidencia. Una consulta puede automatizarse con un umbral distinto de una escritura en ERP. Podemos empezar en modo propuesta o con aprobación humana y ampliar autonomía después de observar suficientes casos.
Sí. Podemos asumir una parte de arquitectura, IA o integración y trabajar con desarrolladores, equipo técnico, datos, seguridad o producto internos. Dejamos contratos, decisiones y casos de prueba para que el sistema no dependa de conocimiento tribal.
Monitorizamos las señales que importan para el flujo y corregimos donde esté el problema: fuente, instrucción, modelo, herramienta, regla o integración. Producción proporciona evidencia nueva y la hoja de ruta debe responder a esa evidencia.
Envía proceso, responsables, sistemas y resultado esperado. Acordaremos qué decisión y prueba deben cerrar la primera fase y qué queda para el siguiente encargo.