El problema que nadie menciona en la propuesta comercial
Cuando una empresa mid-size contrata un proveedor de IA, la conversación suele girar en torno a casos de uso, plazos y precio. Lo que rara vez aparece en la propuesta es una pregunta más incómoda: ¿qué pasa si decidimos cambiar de proveedor en doce meses?
Si la respuesta es "tendríamos que empezar desde cero", hay un problema estructural que conviene identificar antes de firmar, no después.
La dependencia tecnológica no es nueva. Existe desde los primeros ERP. Pero con IA tiene una particularidad: los sistemas de agentes y workflows son más opacos, más difíciles de auditar y más fáciles de construir de forma que solo el proveedor los entienda. Eso no siempre es intencional. A veces es simplemente el resultado de trabajar rápido sin pensar en el largo plazo. Pero el efecto es el mismo.
A continuación, cinco preguntas que cualquier CFO o COO debería hacer antes de comprometerse con un proveedor de IA.
Pregunta 1: ¿Quién es el propietario del código y la documentación?
Esta es la más básica y, sorprendentemente, la que más se omite.
Algunos proveedores construyen sobre infraestructura propia, con herramientas propietarias y sin entregar el código fuente al cliente. Cuando el contrato termina, el sistema desaparece con ellos.
Lo que debe exigir: acceso completo al repositorio desde el primer sprint, documentación técnica legible por su equipo y claridad contractual sobre la propiedad intelectual de todo lo construido durante el proyecto.
Si el proveedor duda o pone condiciones, es una señal de alerta.
Pregunta 2: ¿Su equipo aprende a operar el sistema o solo a usarlo?
Hay una diferencia importante entre un equipo que sabe usar una herramienta y un equipo que sabe operarla, mantenerla y extenderla.
Un proveedor que construye dependencia entrega interfaces simples para el usuario final, pero mantiene el control de la lógica subyacente. Cuando algo falla o necesita ajustarse, el cliente debe llamar al proveedor.
Un proveedor orientado a la autonomía trabaja junto al equipo del cliente durante la implementación, explica las decisiones de diseño, forma a las personas que van a operar el sistema y documenta los flujos de forma que alguien interno pueda modificarlos sin asistencia externa.
La pregunta concreta que puede hacer: "¿Cuántas horas de formación práctica incluye el proyecto, y qué capacidad quedará instalada en mi equipo al finalizar?"
Pregunta 3: ¿Cómo se gobierna el sistema una vez en producción?
Un agente en producción no es un software estático. Los modelos de lenguaje se actualizan. Los datos cambian. Los procesos del negocio evolucionan. Sin gobierno activo, un sistema que funciona bien en el mes uno puede degradarse silenciosamente en el mes cuatro.
La pregunta relevante no es si el proveedor monitoriza el sistema, sino cómo y quién toma decisiones cuando algo cambia.
Un modelo de dependencia centraliza todo ese control en el proveedor. Un modelo de autonomía establece desde el inicio qué métricas se monitorean, quién en el equipo del cliente las revisa, y cuándo se escala al proveedor versus cuándo se resuelve internamente.
Pida ver el esquema de governance antes de firmar. Si no existe, es probable que tampoco exista un plan claro para cuando algo falle.
Pregunta 4: ¿Qué ocurre si decide cambiar de proveedor?
Esta pregunta incomoda a muchos proveedores, y eso ya es información útil.
Un proveedor que construye para la autonomía del cliente no debería tener problema en responder: "Si decide trabajar con otro equipo, le entregamos el repositorio completo, la documentación y una sesión de traspaso. El sistema seguirá funcionando."
Un proveedor que construye dependencia suele responder con ambigüedad: "Eso dependería del contrato", "habría que evaluar la situación", o simplemente desvía la conversación.
Para ilustrar el impacto financiero: una empresa de distribución con 80 empleados que contrata un sistema de automatización de reportes por 40.000 euros y luego descubre que no puede migrarlo sin rehacerlo desde cero, está asumiendo un costo oculto que no estaba en la propuesta original. Si el sistema tarda seis meses en construirse y otros seis en estabilizarse, el costo real de la dependencia puede superar el costo del proyecto inicial.
Pregunta 5: ¿El roadmap lo define usted o lo define el proveedor?
En un modelo de dependencia, el proveedor controla qué se construye a continuación, en qué orden y con qué criterio. El cliente recibe propuestas y las aprueba o rechaza, pero rara vez tiene visibilidad suficiente para cuestionar las prioridades.
En un modelo de autonomía, el cliente tiene un mapa claro de su ecosistema de agentes, entiende qué está construido, qué está pendiente y por qué, y puede tomar decisiones de priorización con criterio propio.
La señal práctica: si su equipo no puede explicar en quince minutos qué agentes tienen en producción, qué hacen y cuál es el siguiente paso, el proveedor no ha hecho bien su trabajo de transferencia.
Un ejemplo concreto
Una empresa de servicios profesionales con 120 empleados contrató un proveedor de IA para automatizar la consolidación de datos financieros entre tres sistemas. El proyecto duró cuatro meses y el resultado funcionaba correctamente.
Doce meses después, uno de los sistemas fuente cambió su estructura de datos. El proceso dejó de funcionar. El equipo interno no sabía cómo intervenir. El proveedor tardó tres semanas en liberar agenda para atender el problema y cobró horas adicionales por la corrección.
El costo directo de esas tres semanas —en horas de trabajo manual, retrasos en el cierre y honorarios del proveedor— se estimó entre 8.000 y 14.000 euros. El costo indirecto, en términos de confianza del equipo en los sistemas de IA, fue más difícil de cuantificar pero igualmente real.
El problema no era la tecnología. Era que el proveedor nunca transfirió el conocimiento necesario para que el equipo interno pudiera operar el sistema de forma autónoma.
Cómo usar estas preguntas en la práctica
No es necesario hacer las cinco preguntas en la primera reunión. Pero sí conviene tenerlas como criterio de evaluación antes de firmar cualquier contrato de implementación de IA.
Si un proveedor responde con claridad a las cinco, tiene un modelo orientado a la autonomía del cliente. Si esquiva alguna, pide más contexto antes de responder o responde con generalidades, conviene profundizar antes de comprometerse.
La IA bien implementada reduce costos, mejora la visibilidad operativa y libera capacidad del equipo. Pero esos beneficios solo se sostienen si el sistema es operable, auditable y extensible por el propio equipo del cliente. Sin eso, lo que parece una inversión en eficiencia puede convertirse en una nueva dependencia operativa.
Conclusión
La pregunta no es si su proveedor de IA es bueno. La pregunta es si el modelo de entrega que propone deja a su organización en mejor posición que antes, o simplemente sustituye una dependencia por otra.
Si tiene dudas sobre cómo evaluar su situación actual o está evaluando un nuevo proveedor, podemos revisar su caso en una llamada breve y darle una perspectiva independiente.
