Los errores de un consultor de IA en su primer año

La reunión donde dijiste que sí demasiado rápido

Esta escena se repite con variaciones en casi todos los consultores que conozco en su primer año. Cambia el sector, cambia el nombre del cliente, pero la estructura es idéntica: alguien con presupuesto dice que quiere “automatizar con IA”, tú necesitas el primer contrato grande para justificar haber dejado un sueldo fijo, y firmas antes de haber hecho las preguntas incómodas. El error no aparece en la reunión de cierre. Aparece semanas antes, en la reunión donde el cliente habló del problema en términos vagos (“queremos ser más eficientes”, “queremos usar IA como la competencia”) y tú, en lugar de frenar ahí, avanzaste directo a la propuesta.

La formación técnica de un consultor de IA (los cursos de modelos, de agentes, de arquitectura) no enseña nada de esto. Enseña a construir. No enseña a decir que no, a cotizar un diagnóstico antes que una solución, ni a leer las señales de que el proyecto que tienes enfrente está mal planteado desde el origen. Por eso el primer año se paga con cicatrices que ningún tutorial cubre: proyectos que se extienden sin límite, clientes que dejan de responder cuando llega la factura, y la sensación repetida de que el problema no fue técnico, fue haber aceptado algo que nunca debiste aceptar.

Los errores que de verdad cuestan no están en el modelo, están en lo que aceptaste antes de tocarlo

Cuando un proyecto de consultoría de IA fracasa en el primer año, la explicación que se da hacia afuera casi siempre es técnica: “el modelo no era lo bastante bueno”, “faltó tiempo de entrenamiento”, “la integración fue más compleja de lo esperado”. La explicación real, la que el consultor se dice a sí mismo en privado, suele ser otra.

Los tres errores del callout no son independientes: se encadenan. Aceptas a un cliente sin dolor real porque necesitas el ingreso. Cotizas rápido porque no quieres perder al cliente que sí conseguiste. Prometes un número porque el cliente lo pidió, y decir “todavía no lo sé” se siente como perder la venta. Cada error individual parece razonable en el momento; juntos arman un proyecto condenado antes de la primera línea de código. El resto de esta página desarrolla cada uno, más los errores de ejecución que se derivan de partir mal: no cobrar el diagnóstico, construir de más, no documentar y terminar vendiendo una herramienta en lugar de un resultado.

El error de origen: aceptar al cliente que no tiene un dolor real

El primer error, y el que arrastra a todos los demás, es firmar con un cliente que no tiene un dolor concreto, medible y molesto hoy. Tiene curiosidad. Tiene presión de un directorio que leyó sobre IA en la prensa. Tiene ganas de decir en una reunión que “ya estamos trabajando con inteligencia artificial”. Ninguna de esas tres cosas es un dolor. Un dolor real suena distinto: “perdemos ocho horas a la semana clasificando reclamos a mano”, “se nos escapan leads porque tardamos tres días en responder”, “tenemos un proceso que depende de una sola persona y si se enferma, se detiene todo”. Si en la primera reunión no puedes escribir una frase así, con un verbo y un número, todavía no hay proyecto: hay entusiasmo.

Reconocer esta diferencia es la primera habilidad que separa a un consultor de un vendedor de tecnología, y es también el tema central de cómo conseguir clientes de consultoría de IA cuando empiezas: no se trata de conseguir cualquier cliente que diga que sí, se trata de encontrar al que ya sufre el problema que tú sabes resolver. Aceptar al cliente sin dolor tiene un costo específico: como no hay una molestia real que resolver, el alcance se vuelve líquido. Cada semana aparece una idea nueva (“¿y si también hace esto?”, “¿y si lo conecta con aquello?”) porque nadie está resolviendo un dolor puntual, están explorando posibilidades sin límite. El consultor de IA que confunde interés con dolor termina construyendo un proyecto sin borde, porque nunca hubo un borde que defender.

La pregunta que evita este error no es “¿tiene presupuesto?”. Es “¿qué le cuesta hoy, en horas o en dinero, no tener esto resuelto?”. Si el cliente no puede responder con algo concreto, el trabajo de la primera reunión no es cotizar, es ayudarlo a encontrar esa respuesta, y eso, casi siempre, todavía no se cobra en la primera cita.

Cotizar en la primera reunión: prometer un precio antes de entender el problema

El segundo error nace del mismo miedo que el primero: perder al cliente. El cliente pregunta “¿cuánto cuesta esto?” en la misma llamada donde explicó el problema por encima, y el consultor nuevo, temeroso de sonar inseguro, tira un número. Ese número no está basado en nada real: no sabe cuántos datos existen, no sabe si están limpios, no sabe cuántas áreas hay que coordinar para que el proyecto funcione. Es una adivinanza con formato de cotización.

El problema no es cobrar mal, aunque también pasa. El problema es que ese número se convierte en la vara con la que el cliente mide todo lo que sigue. Si el proyecto termina costando el doble porque los datos estaban mal (algo que se podía saber si se hubiera diagnosticado antes), el cliente no lo ve como un descubrimiento razonable del proceso: lo ve como que el consultor no sabía lo que estaba haciendo. Cotizar antes de diagnosticar no ahorra tiempo, lo cambia de lugar: el tiempo que no se invirtió en entender el problema se invierte después, discutiendo por qué el precio cambió.

Cómo se cotiza un proyecto que todavía no se entiende del todo es, de hecho, el problema central de cómo poner precio a un proyecto de IA: la respuesta corta es que no se cotiza el proyecto completo en la primera reunión, se cotiza el diagnóstico, y el proyecto se cotiza después, con datos reales encima de la mesa.

Prometer un resultado que dependía de datos que nunca viste

El tercer error del callout es el más caro de los tres porque se paga en público. El consultor promete, en la propuesta o en la llamada de cierre, un número específico: “vamos a reducir el tiempo de respuesta en 40%”, “vamos a bajar los reclamos a la mitad”. Suena bien en una presentación. El problema es que ese número dependía por completo de algo que el consultor nunca vio: la calidad del histórico del cliente, si los procesos internos realmente se siguen como el cliente dice que se siguen, si hay alguien saboteando el cambio sin decirlo en voz alta.

Un resultado prometido sin haber visto el dato real no es una meta ambiciosa, es una apuesta con el nombre del consultor puesto encima. Cuando el número no se cumple, y en un porcentaje alto de estos casos no se cumple precisamente porque nunca hubo base para calcularlo, el cliente no distingue entre “el consultor prometió mal” y “el resultado era imposible”. Para el cliente, el proyecto de IA simplemente no funcionó, y esa etiqueta queda pegada al consultor, no al dato que faltaba. Este es el mismo patrón que aparece cuando, con el proyecto ya entregado, alguien empieza a notar señales de que la automatización con IA no está funcionando: casi siempre la causa de fondo no es el modelo, es una promesa que se hizo sin haber visto el dato que la sostenía.

La alternativa no es dejar de prometer nada. Es prometer sobre lo que ya se vio, y ser explícito sobre lo que todavía no: “con los datos que revisé en el diagnóstico, esto es alcanzable; si el resto del histórico se parece a la muestra, el número se sostiene; si no, lo ajustamos juntos antes de construir”. Es una frase menos vendedora en la reunión y mucho más barata seis meses después.

Los errores de ejecución: no cobrar el diagnóstico y construir de más

Aceptar sin dolor, cotizar sin diagnosticar y prometer sin datos son errores de entrada. Pero hay dos errores de ejecución que aparecen incluso cuando el consultor ya evitó los tres anteriores, y ambos nacen de la misma inseguridad: regalar valor porque no se siente con derecho a cobrarlo o a limitarlo.

• No cobrar el diagnóstico: tratarlo como un “entregable gratis para ganarse al cliente” en lugar de como el producto que resuelve la pregunta más cara del proyecto, que es si esto es viable con lo que el cliente ya tiene. Un diagnóstico no cobrado se percibe, exactamente, como algo sin valor: si el consultor no lo cobró, el cliente asume que tampoco costó producirlo, y lo trata como un trámite antes de “lo importante”.
• Construir de más: entregar un sistema con módulos, integraciones y capas de automatización que nadie pidió, porque “ya que estábamos” o porque se ve más impresionante en una demo. El resultado casi siempre es lo contrario a impresionante: más superficie para que algo falle, más tiempo de entrega, un costo de mantenimiento que nadie presupuestó, y un cliente que solo necesitaba resolver una cosa puntual y ahora tiene que operar cinco.

Los dos errores comparten una causa: el consultor nuevo confunde generosidad con profesionalismo. Cobrar el diagnóstico y construir exactamente lo que se acordó, ni más ni menos, no es tacañería, es la forma de que el cliente entienda desde el día uno qué está pagando y por qué. Definir con precisión dónde termina un proyecto y dónde empieza el siguiente es, de hecho, la disciplina que se explica en cómo definir el alcance de un proyecto de IA: un alcance escrito con claridad frena tanto el “constrúyeme esto también” del cliente como la tentación propia de sumar cosas que se ven bien en una demo.

No documentar, quedar amarrado al soporte gratis y vender la herramienta en lugar del resultado

El último grupo de errores no aparece en la entrega, aparece después, cuando el proyecto ya está “terminado” y el consultor cree que puede pasar al siguiente cliente. No documentar cómo funciona el sistema (qué hace cada parte, qué pasa si un dato llega distinto, cómo se reentrena o se ajusta) parece un ahorro de tiempo al cierre del proyecto. Es, en realidad, una deuda que se cobra sola: sin documentación, el único que entiende el sistema es el consultor, y eso lo convierte en soporte técnico permanente, casi siempre sin que nadie lo haya cotizado así.

De ahí sale el patrón que más desgasta a un consultor en su primer año: el cliente escribe cada semana con una duda o un ajuste menor, el consultor responde “rápido, ya que es poquito”, y sin darse cuenta el mantenimiento se volvió gratis e indefinido. El problema no es que el cliente sea abusivo, aunque a veces lo es: el problema es que nunca se definió, por escrito, dónde termina el proyecto entregado y dónde empieza un contrato de soporte aparte. Cómo ser consultor de IA implica sostener ese límite desde el contrato, no negociarlo mensaje por mensaje cuando ya se volvió costumbre.

El error que resume a todos los anteriores es este: vender la herramienta en lugar del resultado. El consultor que describe su trabajo como “te construyo un chatbot” o “te automatizo este proceso” está vendiendo un objeto. El que dice “vamos a reducir cuántas horas toma resolver un reclamo, con un sistema que se ajusta según lo que pase” está vendiendo un resultado, y ese resultado es lo único que le importa de verdad a una empresa que busca aplicar inteligencia artificial para empresas, no coleccionar herramientas nuevas. Cuando se vende la herramienta, el cliente compara precios contra cualquier otro que “también hace chatbots”. Cuando se vende el resultado, el cliente compara contra el costo de seguir sin resolver el problema, que casi siempre es mayor.

Mi criterio sobre el primer año

El criterio que separa el segundo año del primero

Nada de lo anterior se corrige con más técnica. Un consultor puede dominar el modelo más nuevo del mercado y seguir cometiendo estos siete errores, porque están antes del modelo: están en la reunión donde se acepta al cliente, en la llamada donde se cotiza, en el contrato donde no se escribió el límite del soporte. El segundo año no empieza cuando el consultor sabe más de IA. Empieza el día que aprende a decir “todavía no sé si esto se puede” en lugar de prometer un número para cerrar la reunión, y a cobrar por averiguarlo antes de construir nada.

El criterio que separa a quien sobrevive el primer año de quien no es simple de enunciar y difícil de sostener bajo presión: cada vez que sientas la tentación de aceptar, cotizar o prometer más rápido de lo que el proyecto merece, esa urgencia casi nunca viene del cliente. Viene del miedo a no tener el próximo contrato. Y un proyecto aceptado por miedo cuesta, casi siempre, más caro que el contrato que se perdió por decir que no a tiempo.