Qué preguntar antes de contratar un consultor o agencia de IA

Por qué nadie pregunta lo que de verdad importa

La reunión de cierre con un consultor o una agencia de IA suele girar alrededor de tres cosas: el precio, el cronograma y quién va a ser el punto de contacto durante el proyecto. Son preguntas legítimas, pero no son las que determinan si ese proyecto termina siendo un activo de la empresa o un dolor de cabeza de dieciocho meses. Esas preguntas casi nunca se hacen, y no porque sean complicadas de formular, sino porque nadie las trae a la mesa.

El problema no es que los consultores mientan en esa reunión. El problema es que un proveedor no va a ofrecer voluntariamente la respuesta que lo deja mal parado. Si nunca preguntas quién es dueño del código al terminar el contrato, es perfectamente legal que la respuesta implícita sea “ellos”, y te enteras seis meses después, cuando quieres cambiar de proveedor y descubres que no puedes tocar nada del sistema sin volver a pagarles.

Esta guía no explica cómo comparar propuestas ni cómo elegir entre varios consultores, eso ya está cubierto con otro criterio en otra guía de este Playbook. Esta es, literalmente, el guion de preguntas para la reunión de cierre: las que hay que hacer antes de firmar, agrupadas por tema, con la respuesta que indica que el proveedor es serio y la que debería encender una alerta.

Qué es este guion (y qué no)

No es una lista de criterios para comparar propuestas ni un checklist de qué debe tener una buena agencia en general, eso ya se cubre en la guía sobre cómo elegir un consultor o agencia de IA para tu empresa, que evalúa experiencia, especialización y encaje antes de siquiera llegar a la mesa de cierre. Esta guía asume que ya elegiste con quién probablemente vas a trabajar, y es la última verificación antes de poner la firma.

• Un cuestionario general de referencias: para eso existe una guía específica sobre cómo saber si un consultor de IA es bueno antes de contratarlo.
• Una negociación de precio: el precio se negocia con el criterio de la guía sobre cómo se cobra un proyecto de IA, no con estas preguntas.
• Una lista para incomodar al proveedor porque sí: cada pregunta busca información concreta que necesitas para decidir, no ganar una discusión.
• Un trámite que reemplaza al contrato o al acuerdo de servicio firmado: las respuestas de esta reunión deben terminar escritas ahí, no quedar solo en la memoria de quien preguntó.

Las preguntas sobre cómo van a trabajar y quién es dueño de qué

Proceso de trabajo y metodología

Antes de hablar de entregables finales, pregunta cómo van a trabajar semana a semana. La respuesta te dice si el proveedor tiene un método repetible o si improvisa proyecto por proyecto.

• ¿Cómo se ve una semana típica de trabajo en este proyecto? Sana: puede describir reuniones, entregables intermedios y quién revisa qué. Alerta: responde en abstracto (“vamos iterando”) sin poder nombrar un ritmo concreto.
• ¿Cuál es el primer entregable y en cuánto tiempo lo tengo? Sana: un plazo corto, de semanas, con algo tangible que se pueda probar. Alerta: el primer entregable “real” aparece recién a los tres o cuatro meses.
• ¿Quién de mi equipo necesita dedicar tiempo, y cuánto? Sana: un número concreto de horas por semana y de qué rol. Alerta: “no se preocupen, nosotros nos encargamos de todo”, frase que casi siempre esconde que después van a pedir información que nadie preparó.
• ¿Qué pasa si a mitad de camino el alcance cambia? Sana: un proceso definido de control de cambios, con impacto en tiempo y costo explicado antes de ejecutar el cambio. Alerta: “eso lo vemos en su momento”, que en la práctica significa que el cambio se cobra después, sin acuerdo previo.

Acceso y propiedad de los datos

Esta es la parte que casi ninguna empresa pregunta con suficiente detalle, y la que más problemas causa cuando el proyecto involucra datos de clientes.

• ¿Dónde van a vivir mis datos durante el proyecto? Sana: en infraestructura tuya o en un ambiente claramente delimitado, con acceso que tú controlas. Alerta: “los subimos a nuestra plataforma” sin especificar dónde, por cuánto tiempo ni bajo qué condiciones de borrado.
• ¿Quién más dentro de tu equipo va a tener acceso a esta información? Sana: una lista acotada de personas, con un acuerdo de confidencialidad nombrado. Alerta: no lo saben o lo minimizan (“solo el equipo del proyecto”, sin poder decir cuántas personas son en realidad).
• Si terminamos el contrato mañana, ¿qué pasa con mis datos? Sana: un plazo y un método concretos de devolución o borrado, por escrito. Alerta: silencio, o una respuesta vaga tipo “normalmente los mantenemos por si acaso”.
• ¿Van a usar mis datos para entrenar o mejorar productos que después venden a otros clientes? Sana: una negación clara y por escrito, o una explicación técnica de qué datos anonimizados sí se reutilizan y cuáles nunca. Alerta: evasivas, o un “eso está en los términos generales” sin señalar dónde exactamente.

Propiedad del sistema cuando termine el contrato

Esta es, en la práctica, la pregunta que más dinero le cuesta a las empresas que nunca la hicieron.

• Cuando termine el contrato, ¿de quién es el código, los prompts y la configuración del sistema? Sana: tuyo, con entrega documentada del repositorio y las credenciales correspondientes. Alerta: “eso corre sobre nuestra plataforma propietaria”, que en la práctica significa que sin ellos el sistema no existe.
• ¿Puedo llevarme el sistema a otro proveedor si decido cambiar? Sana: sí, con una descripción de qué se entrega (código, documentación, accesos) para que otro equipo pueda continuar sin empezar de cero. Alerta: “nadie más va a poder mantenerlo igual de bien”, un argumento de retención, no una respuesta técnica.
• ¿El sistema depende de una licencia, API o infraestructura que solo ellos controlan? Sana: lo explican con transparencia y, si existe una dependencia real, es de un proveedor externo (no de ellos mismos) y queda documentada. Alerta: la dependencia clave es de su propia infraestructura interna, sin alternativa mencionada.

Las preguntas sobre qué pasa si algo sale mal y a quién le puedes creer

Qué pasa si el proyecto no cumple lo prometido

Esta conversación tiene que pasar antes de firmar, no después de que el proyecto ya se atrasó o no entregó el número esperado.

• ¿Qué pasa si el resultado no llega al número que estamos definiendo hoy? Sana: una cláusula concreta, ya sea de ajuste, de horas adicionales sin costo o de salida del contrato. Alerta: “eso no va a pasar”, una promesa sin mecanismo de respaldo detrás.
• ¿Cómo se define y quién audita si el proyecto “funcionó”? Sana: un número acordado antes de empezar, con una fuente de medición que ambas partes aceptan de antemano. Alerta: el criterio de éxito queda abierto a interpretación recién después de entregado.
• ¿Existe una cláusula de salida si esto no está funcionando en dos o tres meses? Sana: sí, con condiciones claras y sin penalidad desproporcionada. Alerta: el contrato ata a la empresa por doce o veinticuatro meses sin ningún punto de salida intermedio.

Referencias verificables de clientes reales

Un testimonio escrito no es una referencia, es material de marketing. Esto se verifica hablando con alguien real.

• ¿Puedo hablar directamente con un cliente actual, no solo leer un testimonio escrito? Sana: sí, y te agenda la llamada sin fricción. Alerta: “los podemos poner en contacto”, seguido de silencio, o solo ofrecen testimonios en PDF sin ningún contacto real.
• ¿Ese cliente de referencia tiene un proyecto parecido en tamaño y sector al mío? Sana: coincide razonablemente, o el proveedor es honesto en que no. Alerta: todas las referencias son de proyectos mucho más pequeños o de industrias sin ninguna relación con la tuya.
• ¿Qué pasó con algún proyecto que no salió bien? Sana: puede nombrar uno, en términos generales, y explicar qué aprendió de eso. Alerta: “todos nuestros proyectos han sido un éxito”, una frase que en cualquier proveedor con historial real es estadísticamente poco creíble.

Cómo se factura

El modelo de cobro importa menos que la claridad y la ausencia de sorpresas después de firmado.

• ¿Se cobra por hora, por alcance fijo o por resultado? Sana: una respuesta clara con el modelo elegido y por qué lo aplican a este proyecto en particular. Alerta: la respuesta cambia dependiendo de a quién le preguntes dentro de su propio equipo.
• ¿Qué pasa si el proyecto toma más horas de las estimadas? Sana: un tope acordado o un proceso de aprobación antes de que las horas extra se facturen. Alerta: “se factura lo que tome”, sin techo ni aviso previo a la empresa.
• ¿Hay costos que no están en esta propuesta pero que van a aparecer después? Sana: licencias de terceros, infraestructura o soporte posterior al lanzamiento, nombrados explícitamente desde ahora. Alerta: aparecen después de firmado, como un “eso no estaba incluido”.

Errores comunes al llegar a esta reunión

• Firmar sin pedir que las respuestas de esta reunión queden escritas en el contrato o en un anexo, confiando en la palabra verbal de la conversación.
• Preguntar solo por precio y plazo, y tratar las preguntas sobre datos y propiedad del sistema como un detalle legal que “ve el abogado después”.
• Aceptar “corre sobre nuestra plataforma propietaria” como respuesta suficiente a quién es dueño del sistema, sin pedir que lo expliquen en términos concretos de qué se puede llevar y qué no.
• Pedir referencias y conformarse con un testimonio escrito, sin insistir en hablar directamente con un cliente real de tamaño y sector parecido.
• No preguntar qué pasa si el proyecto no cumple, asumiendo que “eso no nos va a pasar a nosotros” porque el proveedor se ve confiable en la reunión.

Cómo se ve esto en la práctica

Una distribuidora mediana de productos de consumo, en Perú, con unos ochenta trabajadores, contrató una agencia para automatizar la atención al cliente por WhatsApp con IA. En la reunión de cierre, el comité preguntó precio, plazo de entrega y quién sería el contacto durante el proyecto. Nadie preguntó de quién sería el sistema al terminar el contrato ni qué pasaba con la información de los clientes que la agencia iba a manejar en el proceso.

El proyecto funcionó razonablemente bien los primeros ocho meses. El problema apareció cuando la empresa quiso cambiar de proveedor por un tema de costo: todo el sistema (los flujos de conversación, la configuración del modelo, la integración con su CRM) corría sobre una plataforma propietaria de la agencia. Migrarlo no era una opción técnica simple, era empezar de cero con otro proveedor, porque nada de lo construido era exportable fuera de esa plataforma.

La empresa terminó renegociando un contrato de salida más caro de lo que hubiera costado simplemente preguntar, en la reunión original, quién era dueño del código y si el sistema podía migrarse. La lección no fue que esa agencia fuera mala, entregó lo que prometió durante ocho meses. La lección fue que nadie preguntó lo que hubiera cambiado la negociación completa desde el primer día.

Mi criterio

Cómo saber si hiciste bien esta reunión

No hace falta esperar meses para saber si la reunión de cierre estuvo bien hecha. Se puede verificar el mismo día, antes de firmar nada.

• Todas las respuestas de la reunión quedaron por escrito en el contrato o en un anexo, no solo en la memoria de quien preguntó.
• Sabes, con plazo concreto, qué pasa con tus datos si terminas el contrato mañana mismo.
• Puedes explicar en una frase de quién es el código, los prompts y la configuración del sistema una vez termine el contrato.
• Hablaste directamente con al menos un cliente real de un proyecto de tamaño y sector parecido al tuyo, no solo leíste un testimonio.
• El contrato define qué pasa si el resultado no llega al número acordado, con una cláusula concreta y no una promesa verbal.

Si alguna de estas preguntas no tiene respuesta clara, o el proveedor se pone visiblemente incómodo al escucharla, todavía estás a tiempo, antes de firmar, de decidir si ese es el proveedor correcto para tu empresa.