Aún no hemos tenido que rescatar a ningún cliente de un proyecto de IA mal entregado. Hemos visto sistemas mal documentados en otros contextos, sabemos el coste real que tiene heredarlos, y por eso tratamos cada entrega como si el cliente fuera a continuar con otro proveedor mañana, aunque no sea así.
Esta forma de pensar cambia cómo se diseña el proyecto desde el principio. No se escribe código pensando "ya documentaremos al final", no se dejan credenciales en archivos personales, no se utilizan servicios que solo una persona de nuestro equipo sabe configurar. Cada decisión técnica pasa por un filtro sencillo: si mañana el cliente quisiera llevarse este sistema a casa, ¿podría hacerlo?
Este artículo explica por qué los handovers en proyectos de IA son más complejos que en otros sistemas, qué debería incluir una entrega bien hecha, y cuáles son las señales de alerta antes de firmar con cualquier proveedor que prometa "sistemas inteligentes".
Por qué un handover de IA es más complejo que otro
En un proyecto web tradicional, un handover bien hecho implica código documentado, accesos y un README claro. La gran mayoría del conocimiento está en el código: si una persona nueva lo lee, puede deducir qué hace el sistema y cómo mantenerlo.
En un proyecto de IA, eso no es suficiente. El comportamiento del sistema no está solo en el código: está en los prompts, en las configuraciones del modelo, en las herramientas conectadas, en los flujos de orquestación, en los evals que definen qué es una respuesta correcta y en las decisiones arquitectónicas que a menudo solo se justifican con el contexto del caso concreto. Un nuevo equipo puede leer el código y entender qué hace cada función, pero sin documentación adicional no entenderá por qué se decidió aquel prompt, aquel modelo o aquella secuencia de acciones.
A esto se le suma otro factor: los sistemas de IA son sistemas vivos, no estáticos. Hacen falta evals periódicos, ajustes cuando el comportamiento deriva, decisiones sobre cuándo actualizar modelos. Sin traspaso adecuado de esta capa operativa, el sistema funcionará el primer mes y empezará a degradarse lentamente el segundo o tercero, sin que el cliente sepa por qué.
Un handover de calidad debe cubrir todas estas capas, no solo el código.
Los seis elementos de un handover bien hecho
A partir de nuestra experiencia construyendo sistemas de IA y de la práctica de tratar cada proyecto como si fuera entregable mañana, estos son los seis elementos que consideramos imprescindibles en una entrega técnica seria:
1. Documentación técnica completa. No es un README de tres líneas. Es un conjunto estructurado que incluye: arquitectura del sistema (qué hay, qué hace cada parte, cómo se comunican), decisiones técnicas relevantes (por qué este modelo, por qué esta base de datos, por qué esta orquestación), runbooks operativos (qué hacer cuando falla X, cómo diagnosticar Y), y diagramas cuando son útiles. Si un ingeniero senior puede leerlo y entender el sistema en una tarde, está bien hecho.
2. Acceso total a credenciales y cuentas. Todas las cuentas, APIs, tokens, repositorios y servicios deben estar en propiedad del cliente, no del proveedor. Parece obvio pero es el primer punto donde muchos handovers fallan: la cuenta de la API está a nombre del proveedor, el repositorio está en su GitHub personal, el monitor está en un servicio que el proveedor paga. Cuando el cliente quiere marcharse, tiene un sistema pero no tiene control sobre él. Un handover bien hecho invierte esta situación: el cliente lo tiene todo, el proveedor solo tiene acceso mientras dura la relación.
3. Tests automatizados y sistema de evals. En IA, los evals son tan importantes como los tests unitarios en software tradicional. Permiten validar que el sistema sigue tomando decisiones correctas cuando alguien toca el código, cambia un modelo o ajusta un prompt. Sin evals, cualquier modificación al sistema es un acto de fe. Un handover bien hecho incluye una batería de evals ejecutable con un solo comando, datasets de test propios del caso y criterios claros de éxito.
4. Sesión de transferencia presencial o por videoconferencia. La documentación es necesaria pero no suficiente. Una sesión de 2-3 horas con el equipo técnico del cliente, donde se explica el sistema, se hacen demostraciones reales y se resuelven dudas, vale por cincuenta páginas de documentación. Es donde se transfiere el conocimiento tácito: aquellas cosas que nadie escribe pero que todo el mundo necesita saber para operar el sistema.
5. Periodo de acompañamiento posterior. Un sistema nunca se entrega "cerrado". Siempre aparecen dudas, comportamientos inesperados o necesidades nuevas en los primeros meses. Un handover bien hecho incluye un periodo de soporte posterior —típicamente entre 1 y 3 meses— donde el equipo que construyó el sistema queda disponible para consultas. No es un servicio premium escondido: es parte de la responsabilidad del proveedor que construyó el sistema.
6. Plan de mantenimiento documentado. Qué hay que hacer cada semana, cada mes, cada trimestre para mantener el sistema saludable: revisar evals, mirar logs de errores, comprobar costes, actualizar dependencias críticas. Un plan de mantenimiento claro permite al cliente decidir si quiere llevarlo internamente o contratar mantenimiento a alguien —al mismo proveedor o a otro—. La clave es que pueda escoger con información, no con desconocimiento.
Señales de alerta antes de firmar con un proveedor
Si estás evaluando proveedores para un proyecto de IA, aquí van cuatro señales de alerta que indican que probablemente no recibirás un handover decente:
Señal 1: el proveedor habla solo de la demo y no de cómo se mantiene en producción. Si en las reuniones comerciales se dedican 90% del tiempo a enseñar lo bonito que queda el sistema funcionando y 10% (o menos) a explicar cómo se opera, cómo se mide y cómo se mantiene, es señal de que su mentalidad es "entregar y marcharse", no construir algo que dure.
Señal 2: en el presupuesto no hay ninguna partida de documentación, transferencia o periodo de acompañamiento. Si el presupuesto incluye solo desarrollo y nada más, significa que el proveedor está pensando en mínimo viable para cobrar y marcharse. Un proveedor serio considera la documentación y la transferencia como parte integral del proyecto, no como un servicio adicional.
Señal 3: te piden firmar un contrato donde solo ellos tienen acceso al código o a la infraestructura. Si la propiedad intelectual no queda claramente en el cliente, o si las cuentas principales quedan a nombre del proveedor, te están creando dependencia estructural desde el minuto cero. Un proveedor serio insiste en que todo quede a nombre del cliente desde el inicio.
Señal 4: te ofrecen un mantenimiento mensual obligatorio sin opción de salir o cambiar de manos. Hay proveedores que estructuran los contratos para que el cliente quede atrapado: solo ellos pueden mantener el sistema, solo ellos tienen acceso, solo ellos conocen cómo funciona. Esto no es una relación comercial, es una hipoteca técnica. Un proveedor serio ofrece mantenimiento como una opción más, no como una necesidad impuesta por diseño.
Por qué escribimos sobre esto sin haber tenido que rescatar a nadie
Reconocemos que este artículo no se basa en la experiencia de haber rescatado clientes de proveedores anteriores. Se basa en el criterio técnico acumulado construyendo sistemas que queremos que sobrevivan a nuestra relación con el cliente. Cada decisión que tomamos en un proyecto pasa por la pregunta: si mañana este cliente quisiera llevarse el sistema, ¿podría? La respuesta siempre debe ser sí.
Este enfoque tiene un coste. Significa más tiempo en documentación, más tiempo en sesiones de transferencia, más rigor en cómo se gestionan accesos y cuentas. Pero el coste vale la pena: es lo que diferencia a un proveedor que trata cada proyecto como una venta de alguien que lo trata como una relación profesional.
Si estás evaluando proveedores para un proyecto de IA, hazles estas preguntas antes de firmar: ¿cómo sería un handover si mañana decidiéramos cambiar de proveedor? ¿Qué documentación recibiríamos? ¿Qué accesos? ¿Hay periodo de acompañamiento incluido? Si las respuestas son vagas o defensivas, ya sabes lo que necesitas saber.
Si quieres hablar con nosotros de un proyecto concreto —el tuyo o uno que estás evaluando—, escríbenos. Tengas o no tengas intención de acabar trabajando con MindRise, una valoración honesta del planteamiento puede ahorrarte problemas importantes más adelante.