El primer proyecto tiene que demostrar que sirve.
Elegimos un trabajo con un resultado visible, acordamos cómo se va a medir y nos quedamos hasta que el resultado sea real. La primera IA no debería ser un piloto. Debería ser una pieza en producción con un criterio de cierre.
El problema del piloto
La mayoría de los pilotos de IA no fracasan porque el modelo sea malo, sino porque el piloto nunca se diseñó para que alguien tomara una decisión.
Los estudios del sector han detectado que la mayoría de las organizaciones que implantan IA generativa no ven un impacto medible en su cuenta de resultados. Las previsiones de los analistas apuntan a que más del 40 % de los proyectos de IA agéntica se habrán cancelado a finales de 2027, por los costes, la falta de un valor claro y unos controles de riesgo débiles. El patrón se repite: el trabajo no se acotó para demostrar nada concreto.
La primera IA no debería ser un piloto. Debería ser una pieza en producción con un criterio de cierre.
Para qué sirve un primer proyecto
Un primer proyecto tiene tres cometidos. Demostrar un resultado. Construir el modelo operativo. Dejar pruebas suficientes para tomar una decisión.
El resultado es lo que se ve. El modelo operativo es el responsable, las restricciones, la evaluación, la derivación y el ritmo. El dosier de pruebas permite al cliente decidir qué viene después.
Si el primer proyecto solo demuestra que la tecnología funciona, no ha cumplido su cometido. Que la tecnología funcione es el punto de partida. El resultado de negocio es lo que importa.
Los criterios de selección
Elige un trabajo que reúna seis cualidades: gran volumen, un responsable claro, un resultado medible, datos accesibles, un riesgo asumible y un ciclo de retroalimentación corto.
El volumen genera retorno. Un responsable claro fija quién responde. Un resultado medible genera pruebas. Unos datos accesibles dan velocidad. Un riesgo asumible mantiene seguro el primer proyecto. Un ciclo de retroalimentación corto permite al equipo aprender antes de que se acabe el presupuesto.
Basta con una tabla de puntuación sencilla. Puntúa cada candidato de uno a cinco en los seis criterios. Elige la puntuación más alta entre los trabajos que el negocio esté dispuesto a cambiar de verdad.
- Gran volumen: el trabajo ocurre con la frecuencia suficiente para importar.
- Un responsable claro: una persona responde del resultado.
- Un resultado medible: el negocio puede ver el cambio.
- Datos accesibles: el sistema puede llegar a los registros que necesita.
- Riesgo asumible: un error se puede detectar y corregir.
- Un ciclo de retroalimentación corto: el equipo aprende en semanas, no en trimestres.
El alcance
Un proceso, un resultado visible, una medida, un equipo. Lo bastante concreto para terminarlo, lo bastante importante para que cuente.
Un primer proyecto debe medirse en semanas, no en trimestres. Cuatro o seis semanas bastan para mapear el trabajo, construir la pieza, evaluarla y ponerla en producción. Un programa de doce meses no es un primer proyecto. Es una apuesta.
El alcance debe decir con la misma claridad qué entra y qué queda fuera. El límite es lo que mantiene seguro el primer proyecto y centrado al equipo.
Las medidas
Un primer proyecto necesita cuatro medidas: una de negocio, una operativa, una de calidad y una de riesgo.
La medida de negocio es el resultado que le importa al cliente: reuniones concertadas, ingresos recuperados, tiempo ahorrado, coste por contacto o conversión. La medida operativa describe cómo funciona el sistema: volumen, tiempo de ciclo, tasa de derivación e integridad de los registros. La de calidad mide qué tal hace su trabajo: éxito en la tarea, resolución en el primer contacto y puntuación según el método. La de riesgo recoge lo que puede ir mal: tasa de error, incumplimiento de las restricciones, reclamaciones y derivaciones que no llegan.
Fija la línea base de cada medida antes de construir. Un resultado sin línea base es una anécdota.
El modelo operativo
Un primer proyecto debe dejar un modelo operativo, no solo un modelo. Ese modelo concreta el responsable, el ritmo de revisión, la vía de derivación, el proceso de cambio y el modelo de costes.
¿Quién revisa el sistema cada semana? ¿Quién se ocupa cuando hay que derivar un caso? ¿Quién aprueba un cambio en las restricciones? ¿Quién paga los tokens, la telefonía y el mantenimiento? ¿Qué pasa cuando se marcha el proveedor?
No son detalles de compra. Son la diferencia entre un sistema que sobrevive al primer mes y una demostración que no.
El dosier de pruebas
Al terminar el primer proyecto, el cliente debe recibir un dosier. El sistema en funcionamiento. Los resultados de la evaluación. El registro de auditoría. El manual de operación. El proceso de derivación. El modelo de costes. La nota de decisión.
La nota de decisión ocupa una página. Qué nos propusimos demostrar. Qué medimos. Qué pasó. Cuánto costó. Qué recomendamos. Repetir, ampliar o parar.
Ese dosier es lo que permite ganarse la segunda IA. También protege al cliente si la respuesta es parar.
La decisión
Repetir, ampliar o parar. Las tres son salidas válidas. Un primer proyecto que termina en un no claro es un éxito, porque evita un error mayor.
La decisión debería caer por su peso con las pruebas en la mano. Si la medida de negocio se movió, la calidad se mantuvo y el riesgo no se salió del límite, repite. Si el resultado es prometedor pero el alcance era demasiado estrecho, amplía. Si no hay pruebas, para.
El peor resultado es un piloto que no termina nunca, se come el presupuesto y no produce ninguna decisión.
Qué viene después
La segunda IA es más fácil cuando la primera dejó pruebas, no una demostración. El equipo sabe cómo se comporta el sistema, cuándo pasa el caso a una persona y quién responde de él.
El segundo desarrollo reutiliza el circuito de datos, las restricciones, el hábito de evaluar y el ritmo de trabajo. La plataforma no es el proveedor. La plataforma es la forma en que ahora trabaja el negocio.
Por eso preferimos construir una implantación de IA que forme parte del negocio antes que diez que nunca salgan de la demostración.
El plan de 90 días
Un primer proyecto práctico puede durar doce semanas. Las semanas uno y dos sirven para mapear el trabajo, fijar la línea base de las medidas y nombrar al responsable. De la tres a la seis se construye la pieza y se conectan los sistemas. Las semanas siete y ocho se dedican a evaluar con casos reales y a corregir la derivación. Las nueve y diez, a funcionar en producción con una revisión diaria. Las once y doce, a revisar las pruebas, escribir la nota de decisión y acordar qué viene después.
El plan no es una cascada. El desarrollo y la evaluación se solapan. Lo que importa es el ritmo, no la secuencia.
Un plan de 90 días da al negocio una meta y al equipo una razón para priorizar.
La lista de comprobación de quien compra
Antes de comprometerte, pregunta cuál es el primer trabajo. Pregunta quién responde de él. Pregunta cuál es el criterio de cierre. Pregunta cuál es la línea base. Pregunta cómo se evaluará el sistema. Pregunta qué pasa después del lanzamiento. Pregunta cuál es el plan de salida.
Un proveedor que no sabe responder a estas preguntas vende una demostración. Uno que las responde vende un primer proyecto.
- ¿Cuál es el primer trabajo, en una frase?
- ¿Quién responde del resultado después del lanzamiento?
- ¿Cuál es el criterio de cierre y qué pruebas lo demuestran?
- ¿Cuál es la línea base de cada medida?
- ¿Cómo se evaluará el sistema?
- ¿Qué pasa después del lanzamiento?
- ¿Cuál es el plan de salida?
La primera IA es una decisión
La primera IA debe ganarse la segunda. No es un eslogan sobre escala. Es un estándar para el primer proyecto.
Un primer proyecto que produce pruebas, un modelo operativo y una decisión clara vale más que una cartera de pilotos. Da al negocio la confianza para seguir o la disciplina para parar.
En cualquiera de los dos casos, la primera IA ha hecho su trabajo.
Sigue leyendo