Qué debe entregar un proveedor de IA en los primeros 30 días

El error de tratar el primer mes como cortesía

El patrón se repite en distribuidoras, clínicas, estudios profesionales y empresas de servicios por igual: la empresa firma con un proveedor de IA después de una propuesta bien armada, con capturas de pantalla prometedoras y un roadmap a doce meses. El primer mes se gasta en “levantamiento de información”, reuniones de kickoff y accesos a sistemas que tardan semanas en aprobarse. Nadie exige un entregable concreto todavía porque “recién estamos empezando”. Ese es exactamente el momento donde el proyecto empieza a fallar, aunque nadie lo note hasta el mes cuatro.

El error de fondo no es contratar mal al proveedor. Es tratar los primeros 30 días como un periodo de cortesía en lugar de como la etapa de mayor riesgo del proyecto. En esas primeras semanas el proveedor todavía no ha probado nada: ni que entendió el proceso, ni que sabe traducir un problema de negocio en un sistema que funcione, ni que la promesa comercial resiste el contacto con la operación real. Cuanto más tiempo pasa sin un entregable verificable, más se acumula el riesgo sin que nadie lo mida.

La mayoría de los proyectos de IA que terminan mal no fallan por el modelo, ni por la tecnología elegida. Fallan porque un error de diagnóstico o de alcance quedó sin corregir durante meses, porque nadie exigió evidencia temprana de que el proveedor había entendido el problema. Cuando el primer entregable real llega en el mes tres o cuatro, cualquier corrección de rumbo ya implica repetir trabajo, renegociar presupuesto y, casi siempre, perder la paciencia del equipo que iba a usar el sistema.

Por eso los primeros 30 días importan más de lo que su nombre sugiere. No es la fase de “conocernos”, es el detector temprano del proyecto. Un proveedor serio construye evidencia desde la primera semana. Un proveedor que solo vende una promesa se esconde detrás de la complejidad técnica para ganar tiempo.

Qué es (y qué no) el hito de los primeros 30 días

Antes de exigir entregables hay que tener claro qué significa realmente “los primeros 30 días” en un proyecto de IA aplicado a un proceso de negocio. No es una fecha simbólica ni una reunión de seguimiento sin consecuencias. Es un hito contractual con productos verificables, tan real como un avance de obra en una construcción.

Confundir esta ventana con otra cosa es la puerta de entrada a los proyectos que se alargan sin control. Antes de seguir, vale la pena cortar la confusión con lo que NO es este primer mes.

• No es una etapa de cortesía donde solo se presentan personas y se firman actas de reunión sin ningún entregable de por medio.
• No es un mes de “entendimiento cultural” donde el proveedor solo hace preguntas sin dejar nada documentado por escrito.
• No es el momento de mostrar solo diapositivas y arquitecturas conceptuales, sin conexión verificable con el proceso real que se va a intervenir.
• No es el momento de pedir acceso a todo sin mostrar nada a cambio: acceso y entregable van juntos, uno no llega antes que el otro sin condición.
• No es una fase que se puede saltar “para ir más rápido”: saltarla es la manera más común de llegar tarde al problema real.

Los cinco entregables que deben existir al día 30

No hace falta un documento de cien páginas ni un panel de control sofisticado. Hace falta que, al cierre del día 30, existan estos cinco entregables. Si falta alguno, hay que preguntar por qué antes de aprobar el segundo desembolso.

1. Diagnóstico documentado del proceso

El primer entregable no es técnico, es de negocio: un documento (puede ser breve, no necesita ser extenso) que describa el proceso actual tal como es, con sus pasos, sus cuellos de botella, quién hace qué y dónde se pierde tiempo o dinero. Si el proveedor no puede mostrar que entendió el proceso en sus propias palabras, todavía no está listo para automatizarlo. Un diagnóstico serio nombra el dolor específico del negocio, no una versión genérica de “ineficiencia operativa”.

2. Acceso real a lo que se está construyendo

El segundo entregable es acceso, no una promesa de acceso. Si al día 30 la empresa no puede entrar a ver el sistema en construcción, aunque esté incompleto, lo que existe es una caja negra. Un proveedor que oculta el trabajo en progreso detrás de “todavía no está listo para mostrar” está comprando tiempo, no construyendo confianza. El criterio es simple: si no se puede ver, no se puede verificar.

3. Línea base medida del KPI

El tercer entregable es un número, no una intención. Antes de prometer mejora hay que medir el punto de partida: cuánto tiempo toma el proceso hoy, cuántos errores tiene, cuánto cuesta cada unidad procesada. Sin línea base, cualquier resultado futuro es imposible de verificar porque no hay contra qué compararlo. Un proveedor que llega al mes tres sin línea base está pidiendo que la empresa confíe en su palabra en lugar de en la evidencia.

4. Un primer avance tangible y probable

El cuarto entregable es algo que se pueda tocar: un prototipo, un flujo automatizado en su versión más simple, un primer caso de uso funcionando de punta a punta, aunque sea a escala reducida. No tiene que ser perfecto ni estar en producción. Tiene que ser real y probable por alguien del equipo de la empresa, no solo por el equipo del proveedor.

5. Plan claro de las siguientes semanas

El quinto entregable es un plan escrito con hitos concretos para los siguientes 30 a 60 días: qué se va a construir, qué se necesita del lado de la empresa (datos, accesos, decisiones) y qué resultado se espera medir. Un plan vago, del tipo “seguiremos avanzando en la integración”, es una señal de que todavía no hay control real del proyecto.

Señales tempranas de alarma en el primer mes

Además de revisar si los cinco entregables existen, hay señales que aparecen antes del día 30 y que ya anuncian un problema mayor más adelante. Ninguna por sí sola es una sentencia definitiva, pero dos o más juntas justifican una conversación dura con el proveedor.

• El proveedor evita hablar de números concretos y responde con “eso lo vemos más adelante” cuando se pregunta por la línea base.
• Las reuniones se llenan de jerga técnica sin traducción a negocio: mucho “agente”, “flujo” y “modelo”, poco “esto le ahorra tiempo a tu equipo de cobranzas”.
• No hay nadie del lado de la empresa validando lo que se construye: el proveedor avanza solo y presenta resultados terminados en lugar de avances parciales revisables.
• El cronograma se corre sin explicación clara y la única justificación disponible es “estas cosas toman tiempo”.
• El entregable del mes uno es una presentación en vez de un artefacto: diapositivas cuidadas, cero acceso a nada realmente construido.

Cómo dejar estos hitos escritos en el contrato

Ninguno de estos entregables funciona si vive solo en la conversación. La única manera de que el día 30 sea exigible es dejarlo escrito en el contrato o en el anexo de alcance, antes de firmar, no después de que algo empiece a fallar.

• Fecha exacta del hito de 30 días, no “al inicio del proyecto” sino una fecha calendario concreta.
• Lista explícita de los cinco entregables con su forma de verificación: quién los revisa y con qué criterio se aprueban.
• Cláusula de acceso continuo: la empresa puede ver el trabajo en construcción en cualquier momento, no solo en las demos programadas.
• Condición de pago ligada al hito, no solo al tiempo transcurrido: el segundo desembolso se libera cuando los cinco entregables están aprobados, no automáticamente al cumplirse el mes.
• Ruta de salida sin penalidad excesiva si el hito de 30 días no se cumple, para que la empresa no quede atrapada en un contrato que ya mostró señales de alarma.

Esto no es desconfianza gratuita hacia el proveedor. Es la misma lógica que se aplica en cualquier obra civil o desarrollo de software serio: hitos verificables, pagos ligados a evidencia y una ruta de salida razonable si algo no cuadra. Un proveedor que se resiste a poner esto por escrito ya está diciendo algo sobre cómo va a manejar el resto del proyecto.

Cómo aprovechar la reunión de cierre del mes uno

La reunión de cierre del día 30 no debería ser una demo pasiva donde el proveedor presenta y la empresa asiente. Es la oportunidad de hacer las preguntas que definen si el proyecto sigue como está, se ajusta o se corta a tiempo.

• ¿Qué aprendieron del proceso que no sabían al firmar el contrato? Una respuesta genérica revela que no hubo diagnóstico real.
• ¿Qué se puede ver hoy, sin preparar nada especial para la demo? Si la respuesta implica una demo armada de antemano, hay que sospechar.
• ¿Cuál es la línea base y cómo se midió? Si no hay número, no hay manera de evaluar el resultado después.
• ¿Qué decisión de la empresa está pendiente y está frenando el avance? Un buen proveedor sabe devolver la pelota cuando corresponde, no absorbe toda la responsabilidad en silencio.
• ¿Qué va a existir en 30 días más, y con qué criterio se va a medir? Si la respuesta es vaga, el patrón se va a repetir mes tras mes.

El objetivo de esta reunión no es incomodar al proveedor por incomodar. Es generar la evidencia que permite decidir con criterio, no con la esperanza de que “en algún momento” el proyecto arranque.

Cómo se ve en la práctica

Una distribuidora mediana, de unas setenta personas, en Perú, contrató a un proveedor de IA para automatizar la atención de primer nivel de su área de post venta: consultas de estado de pedido, cambios de dirección de entrega y reclamos simples. El contrato incluía un cronograma de tres meses y la promesa comercial de reducir el tiempo de respuesta al cliente.

Al cierre del día 30 el proveedor presentó una demo con capturas de pantalla de un flujo conversacional “casi listo”, pero no pudo mostrar acceso real al sistema en construcción, no entregó ninguna línea base del tiempo de respuesta actual y el diagnóstico del proceso se resumió en dos párrafos genéricos sobre “optimizar la experiencia del cliente”. Cuando el jefe de operaciones preguntó cuántas consultas se resolvían hoy sin escalar a una persona, nadie en la reunión tenía el número.

La empresa aplicó la cláusula de salida que había incluido en el contrato, con apoyo de su asesor legal, al no cumplirse el hito de 30 días, y cortó la relación antes del segundo desembolso. Perdió el pago inicial ya comprometido, pero evitó comprometer un presupuesto varias veces mayor en un proyecto sin diagnóstico ni línea base.

Seis semanas después contrató a otro proveedor que sí entregó, en su propio primer mes, el diagnóstico documentado, el acceso al sistema y la línea base del tiempo de respuesta. Con esa base de comparación, antes de llegar a los noventa días el proyecto ya mostraba una reducción medible en la proporción de consultas de post venta que necesitaban intervención humana, algo que el primer proveedor nunca llegó a demostrar.

Mi criterio

Cómo saber si lo hiciste bien

Cerrar bien el primer mes de un proyecto de IA no depende de la suerte ni de la buena voluntad del proveedor. Depende de haber definido antes qué se iba a exigir y de revisarlo con disciplina el día que corresponde.

• Existe un diagnóstico del proceso escrito en términos de negocio, no solo de tecnología.
• Alguien del equipo puede entrar a ver lo que se está construyendo, sin necesidad de agendar una demo especial.
• Hay una línea base medida del KPI que el proyecto promete mejorar.
• Existe un avance que se puede probar, aunque sea pequeño o incompleto.
• El plan de las siguientes semanas está escrito, con fechas y con lo que la empresa debe entregar de su lado.

Si los cinco puntos están cubiertos, hay base real para seguir con el proyecto y para seguir confiando en el proveedor. Si falta más de uno, la conversación honesta hay que tenerla ahora, con el contrato todavía fresco, no dentro de tres meses cuando el costo de corregir el rumbo ya se multiplicó.