Qué documentar en un proyecto de IA para no depender del proveedor

El día que el proveedor deja de contestar el teléfono

Esto no es un caso raro: es el resultado casi garantizado de cómo se contratan la mayoría de proyectos de IA en empresas medianas. Todo el foco se pone en que el sistema funcione el día de la entrega, y ninguno en qué pasa el día que deje de funcionar sin el proveedor al lado. Y aquí hay que ser directos con algo incómodo: el proveedor que entrega un sistema sin documentación no es descuidado ni está apurado por el siguiente cliente. Mientras menos entiendas de tu propio sistema, más caro te sale cada cambio, cada falla y cada renovación de contrato, y ese es justamente uno de los errores al implementar IA en una empresa que más se repite y menos se nombra en la reunión de cierre.

La documentación no se negocia después de la última factura, porque después ya no hay palanca. Se pide durante el proyecto, cuando el proveedor todavía necesita tu firma de conformidad para cobrar el siguiente hito. Esperar a pedirla al final es entregarle al proveedor el control total sobre qué tan bien vas a entender lo que compraste, y esa decisión, tomada por omisión, se paga durante años.

Los siete documentos que tienes que exigir, sin excepción

Documentar un proyecto de IA no es escribir un manual de usuario ni un README técnico que nadie va a abrir. Son siete piezas concretas, cada una con un dueño y un propósito distinto, y ninguna es opcional si de verdad quieres tener un sistema propio y no un servicio que rentas para siempre. Este es el inventario completo, el mismo que debería figurar como entregable en cualquier contrato serio dentro del framework Arquitectura IA, que separa lo que es implementar de lo que es depender.

• El mapa del proceso rediseñado: cómo se trabajaba antes, qué cambió con la IA y por qué. Sin este mapa, nadie nuevo puede entender el sistema sin preguntarle al proveedor.
• Las decisiones y los descartes: qué alternativas se evaluaron y por qué se eligió esta y no otra. Protege contra que un consultor nuevo proponga, sin saberlo, algo que ya se probó y se descartó.
• Las credenciales y los accesos: quién es dueño real de cada cuenta, cada llave de API y cada consola en la nube. Si el proveedor las creó a su nombre, la empresa no es dueña de su propio sistema.
• El runbook de fallas: qué hacer cuando el sistema se cae, en qué orden y a quién escalar si el primer paso no resuelve. Sin esto, cada falla se convierte en una llamada de emergencia al proveedor.
• La línea base de medición: cómo se medía el proceso antes de la IA y cómo se mide después, con los mismos criterios. Sin línea base no hay forma de probar que el proyecto mejoró algo.
• La configuración: los parámetros, umbrales y reglas que hacen que el sistema se comporte como se comporta hoy, no como venía por defecto.
• La custodia: quién dentro de la empresa guarda y actualiza todo lo anterior, y qué pasa con esos documentos si esa persona se va.

Las siguientes secciones desarrollan cada una de estas siete piezas por separado, con lo mínimo que tiene que contener cada documento para que sirva de algo el día que de verdad lo necesites.

El mapa del proceso rediseñado: qué cambió y por qué

El mapa del proceso rediseñado no es un diagrama técnico del sistema, es un antes y después del trabajo humano: quién hacía qué paso, con qué información, y qué de eso hace ahora la IA. Por ejemplo, si antes cinco personas revisaban a mano cada solicitud y ahora el sistema clasifica el noventa por ciento de los casos y una persona revisa solo las excepciones marcadas, ese cambio de roles tiene que quedar dibujado, no solo mencionado en una reunión que nadie grabó.

Este mapa debería estar listo desde el arranque del proyecto, no al final: es parte de lo que un proveedor serio tiene que entregar en los primeros 30 días de un proyecto de IA, junto con el resto de la documentación base. No hace falta que sea sofisticado: un diagrama de flujo simple, con las cajas de decisión y quién participa en cada una, alcanza para que alguien nuevo entienda en media hora lo que hoy solo entiende el proveedor.

Las decisiones que se tomaron y por qué se descartó todo lo demás

El documento de decisiones y descartes no es una bitácora técnica, es la memoria de las conversaciones que ya se tuvieron y que nadie quiere repetir dentro de seis meses. Ahí se registra, para cada decisión importante del proyecto, qué alternativas se pusieron sobre la mesa y por qué se descartaron: qué modelo se evaluó y se dejó de lado, por qué no se integró directamente con el sistema legado, por qué se automatizó un paso del proceso y no otro.

El valor de este documento aparece meses después, no el día que se firma. Cuando cambia el equipo interno, cuando entra un proveedor nuevo o cuando alguien de dirección pregunta “¿por qué no hicimos esto de otra forma?”, la respuesta ya está escrita, con el argumento y el contexto del momento, en vez de reconstruirse de memoria o, peor, repetirse desde cero con la misma discusión que ya se tuvo una vez.

Credenciales, accesos y configuración: lo que se queda cuando el proveedor se va

Cuando el proyecto termina, hay una pregunta simple que separa a la empresa dueña de su sistema de la que sigue rentándolo sin saberlo: ¿a nombre de quién están creadas las cuentas? Es común que el proveedor, por rapidez, cree las cuentas de la nube, las llaves de API y los accesos administrativos a su propio nombre, y se las “preste” a la empresa mientras dura el contrato. El día que la relación termina, esas llaves dejan de servir, y con ellas el sistema completo.

• Cuentas de administrador en la nube: creadas y facturadas a nombre de la empresa, nunca del proveedor, aunque él las administre durante el proyecto.
• Llaves de API y credenciales de los modelos: generadas bajo la cuenta de la empresa, con un registro de qué llave usa cada parte del sistema.
• Repositorio de código con la empresa como propietaria: aunque el proveedor mantenga permisos de trabajo, el dueño legal del repositorio es la empresa.
• El documento de configuración: los parámetros, umbrales y reglas de negocio que hacen que el sistema se comporte como se comporta hoy, explicados en lenguaje simple, no solo como líneas de código.

Sin este bloque, cambiar de proveedor no es una decisión de negocio, es una migración forzada que empieza de cero. Por eso conviene revisar con detalle qué documentos exigirle a un proveedor de IA antes de firmar, antes de que el contrato esté firmado y esa palanca de negociación ya no exista.

El runbook: qué hacer cuando el sistema falla y el proveedor no está

El runbook es, en la práctica, el documento que más dinero ahorra y el que menos se pide, porque solo se necesita cuando algo ya salió mal. Un runbook útil no explica cómo funciona el sistema por dentro: explica qué hacer en los primeros quince minutos de una falla, antes de que alguien tenga tiempo de entrar en pánico o de llamar al proveedor a cualquier costo.

Qué tiene que responder el runbook, como mínimo

• Qué revisar primero: el diagnóstico rápido que cualquier persona del equipo interno puede correr sin depender del proveedor.
• A quién escalar y en qué plazo: nombres, roles y el tiempo máximo de espera antes de subir al siguiente nivel.
• Cómo volver al proceso manual: el camino de emergencia para apagar el sistema y seguir operando mientras se resuelve la falla.
• Un registro de fallas anteriores: qué pasó antes, cómo se resolvió y qué se cambió para que no vuelva a pasar.

Mantener este documento vivo, y no solo entregarlo una vez al cierre del proyecto, es parte de lo que separa un sistema que se sostiene en el tiempo de uno que se degrada en silencio hasta el día que colapsa, algo que desarrollo con más detalle en cómo mantener y actualizar un sistema de IA en producción.

La línea base de medición: sin esto no puedes probar que algo mejoró

La línea base de medición es el documento que menos brilla y el que más protege a la empresa, porque es la única prueba objetiva de que el proyecto sirvió para algo. Consiste en registrar cómo se medía el proceso antes de la IA, con la misma definición y la misma fuente de datos que se va a usar para medirlo después.

Por ejemplo, si el objetivo es reducir el tiempo de respuesta a un reclamo, la línea base es cuánto tardaba el proceso manual, medido con la misma definición de “tiempo de respuesta” que después va a reportar el sistema nuevo. Si esa medición nunca se hizo antes de encender el sistema, cualquier cifra de mejora que presente el proveedor más adelante es una afirmación suya, no una prueba tuya, y no hay forma de auditarla.

Esta línea base también es la que decide, con criterio y no con impresión, si conviene renovar el contrato con el mismo proveedor, renegociarlo o cortar la relación. Sin ella, la conversación de renovación se convierte en una discusión de percepciones: el proveedor dice que mejoró, el negocio siente que no tanto, y nadie tiene un número contra el cual comparar.

Qué hacer si el proveedor se niega a entregar esto

La forma más efectiva de conseguir estos siete documentos es no tener que exigirlos nunca: dejarlos como entregable explícito, ligado a un hito de pago, desde el primer contrato. Si el proyecto ya está en marcha y el proveedor no los ha mencionado, hay que pedirlos por escrito, con fecha, y con la aclaración de que forman parte del entregable, no un favor adicional.

El punto donde la mayoría de proveedores se resiste es cuando la empresa pide detalle sobre cómo se construyó el sistema, y ahí aparece la excusa del método propietario. Hay que separar dos cosas que un proveedor interesado suele mezclar a propósito: su forma de trabajo interna (cómo entrena o ajusta sus modelos en general) sí puede quedar protegida, y no vale la pena pelear por eso. Lo que documenta cómo ese sistema opera dentro de tu empresa (el proceso, las decisiones sobre tus datos, las credenciales, el runbook) no es su propiedad intelectual, es el registro de tu propia operación, y ningún argumento de confidencialidad general debería alcanzar para negarlo.

Si después de insistir por escrito el proveedor se niega de plano, la señal ya no es sobre documentación, es sobre el proveedor: alguien que se resiste tanto a explicar lo que hizo probablemente no quiere que se note cuánto de eso fue criterio real y cuánto improvisación. En ese punto, quien debe sostener la exigencia frente al proveedor no es cualquiera del equipo, es la misma persona que lidera un proyecto de IA en una empresa y tiene autoridad real para condicionar el siguiente pago o, si hace falta, terminar el contrato antes de que sea más caro seguir.

Quién custodia todo esto dentro de tu empresa

La documentación no sirve de nada si vive solo en la cabeza o en la carpeta personal de una persona, sea del lado del proveedor o del lado de la empresa. La pregunta de quién custodia todo esto necesita una respuesta institucional, no un nombre propio: un rol con continuidad, no un héroe que un día renuncia o cambia de área y se lleva el criterio con él.

Esto es, en el fondo, un ejercicio de memoria organizacional: la empresa no puede seguir dependiendo de que alguien recuerde por qué el sistema se comporta como se comporta. El repositorio de estos siete documentos debe vivir en una herramienta que la empresa controla, revisarse al menos una vez al año, y tener más de una persona que sepa dónde está y cómo leerlo, para que ese conocimiento sobreviva a cualquier salida, interna o externa.

Documentar un proyecto de IA no es un trámite del contrato ni una condición “bonita” de tener: es la línea que separa a una empresa que controla su propio proceso de una que renta, mes a mes, el criterio de otro. La pregunta que de verdad importa no es si el proveedor va a documentar bien. Es si tu empresa va a exigirlo mientras todavía tiene el poder real de exigirlo, antes de que llegue la última factura y ya no quede nada que negociar.