En el otoño de 2022, un amigo mío que dirige un almacén de distribución de repuestos para automóviles en Fontana me llamó, entusiasmado. Acababan de desplegar inspección visual por IA en recepción: cámaras industriales sobre el carril de entrada, detectando piezas faltantes, etiquetas equivocadas y cajas dañadas de forma automática, mucho más rápido que las revisiones manuales. Lo felicité, pero algo me inquietaba: la empresa detrás del sistema era una startup que acababa de cerrar su Serie A.
Un año después, esa startup quebró. Los servicios en la nube se apagaron, las actualizaciones del modelo se detuvieron y, lo peor de todo, el sistema de inspección estaba atado a la API en la nube del proveedor. Cuando el servicio murió, toda la línea de inspección se quedó a oscuras de la noche a la mañana. Mi amigo tardó más de tres meses en volver a licitar y re-desplegar. La temporada alta vino y se fue. Lo que perdió, me dijo después, no fue el costo del sistema: fueron tres meses de trabajo manual durante la temporada alta y los clientes que se fueron.
Desde entonces, he añadido una pregunta obligatoria para cada cliente que considera IA: ¿qué pasa si tu proveedor desaparece? No se trata de ser negativo. Comprar IA no es como comprar equipo. Cuando compras una banda transportadora, es tuya. Con un sistema de IA, los modelos, los datos y el código fuente pertenecen al proveedor por defecto. Mientras el proveedor existe, todo está bien. Cuando desaparece, ni siquiera puedes abrir el sistema.
Un contrato sin cláusulas de salida no es un contrato
La mayoría de los contratos con proveedores de IA tienen exactamente una línea sobre la salida: "Los servicios cesarán dentro de los 30 días posteriores a la terminación." Eso es como no decir nada. En realidad hay cuatro cosas que deben estar incluidas.
Primera, depósito (escrow) del código fuente. El código fuente, los pesos del modelo y la documentación de despliegue van a un agente de depósito neutral, con los disparadores de liberación bien definidos: quiebra del proveedor, interrupciones de mantenimiento más allá de un número acordado de días, línea de producto discontinuada tras una adquisición. Si ocurre cualquiera de esas, el depósito se libera para ti. Sin esto, el día que tu proveedor quiebre, ni siquiera podrás ver cómo es el sistema por dentro.
Segunda, devolución de datos. Formato, plazos y exhaustividad deben especificarse: en qué formato se devuelven los conjuntos de datos crudos y etiquetados (no algún formato propietario que no puedas abrir), cuántos días después de la terminación, y el proveedor debe eliminar sus copias después. Si omites esta cláusula, tus datos operativos son un regalo.
Tercera, propiedad de los pesos del modelo. Un modelo entrenado con tus datos: ¿de quién son los pesos? Muchos contratos los asignan al proveedor por defecto, o usan evasivas como "propiedad conjunta". Insiste en un lenguaje claro: los modelos y los pesos derivados entrenados con los datos del cliente pertenecen al cliente. Si el proveedor no acepta, consigue como mínimo una licencia perpetua e irrevocable que sobreviva a la terminación.
Cuarta, soporte de transición. Tras la terminación, el proveedor ofrece varios meses de soporte operativo de solo lectura, u otorga el derecho a auto-alojarlo. La migración no ocurre de la noche a la mañana. Sin una ventana de transición, el sistema viejo muere antes de que el nuevo esté en vivo, y nadie cubre el hueco intermedio.
Los vendedores te dirán al firmar que son una empresa grande, que acaban de levantar capital, que nunca van a quebrar. No lo creas. Muchas startups de IA bien financiadas han muerto en los últimos años, y muchas más fueron adquiridas solo para que sus líneas de producto fueran discontinuadas. El resultado para ti es el mismo: nadie mantiene tu sistema.
Lo único verdaderamente tuyo son los datos
Hagamos una pausa: incluso con un contrato perfecto, si el proveedor realmente desaparece, ¿qué mantiene tu operación funcionando? Los datos. Los modelos pueden reemplazarse, los proveedores pueden reemplazarse. Lo que no se puede reemplazar son los datos etiquetados y las reglas de negocio que has acumulado durante años.
Los datos etiquetados son tu activo principal. Muestras de defectos de la inspección visual, registros de correcciones del picking por voz, pedidos históricos que alimentan la previsión de demanda: el proveedor construyó todo esto sobre tu negocio, y el contrato debe decir que te pertenecen. Con los datos en mano, re-entrenar con un nuevo proveedor toma meses. Sin ellos, partes de cero, y eso toma años. Durante la temporada alta, esa brecha es la diferencia entre sobrevivir y no hacerlo.
Las reglas de negocio son igual de valiosas. Los umbrales, la lógica de manejo de excepciones y las reglas específicas del proceso integradas en el sistema de IA —qué categorías de producto tienen qué estándares de inspección, por ejemplo— deben exportarse como documentación en un calendario regular, no quedarse sentadas en el sistema del proveedor. El peor caso que he visto no fue un modelo perdido; fueron tres años de estándares de inspección viviendo enteramente en la base de datos de configuración del proveedor. Cuando el proveedor se fue, los estándares se fueron con él, y el proveedor de reemplazo tuvo que reaprender todo.
¿Entonces pueden los modelos de código abierto tomar el relevo? Mi opinión: depende del caso de uso. Escenarios maduros como inspección visual y OCR tienen muchas opciones de código abierto, y el costo de migración es mayormente re-etiquetar y re-integrar: un par de ingenieros de ML internos pueden manejarlo. Pero casos de uso profundamente acoplados como optimización de planificación o previsión de demanda, donde la lógica de negocio está enredada con tus sistemas de almacén, son otra historia. Cambiar de proveedor ahí significa reconstruir medio proyecto. Pregunta esto durante la selección: si este proveedor desapareciera, ¿podría hacerme cargo a un costo razonable? Si la respuesta es no, o no lo despliegues, o mete el costo de salida en el costo total de propiedad.
Haz un simulacro de salida cada año, de verdad
Cláusulas escritas, datos asegurados, falta un paso: practicar. Nadie cree que un simulacro de incendio sea una maldición, y un simulacro de salida es lo mismo. Una vez al año, ejercicio simple: asume que el proveedor desaparece mañana, y dedica unos días a verificar tres cosas: si los datos pueden exportarse por completo, si los modelos pueden correr en tu propio entorno, y si los procesos críticos del negocio tienen un respaldo manual que no dependa del proveedor.
El primer simulacro casi siempre falla: los datos exportados carecen de campos, el modelo depende de las librerías propietarias del proveedor, algún reporte crítico solo existe en el portal del proveedor. Fracasar es buena noticia: significa que el plan tiene agujeros, y puedes arreglarlos mientras el proveedor aún existe. Intentar arreglarlos después de que el proveedor desapareció es demasiado tarde.
No necesita ser elaborado. Tu líder de TI lo dirige, operaciones participa, una vez al año, de medio día a un día completo. Seguro barato, y la única prueba de que el plan no es solo papel. Un beneficio extra: guarda el reporte del simulacro archivado. La próxima vez que renueves, es apalancamiento: cuando el proveedor sabe que puedes irte, los aumentos de precio se vuelven mucho más modestos.
Entonces, volviendo a la pregunta original: ¿vale la pena la IA? Sí, pero solo si tienes una salida. Durante la selección del proveedor, no te limites a maravillarte con la demo. Haz una pregunta más: si tu empresa ya no está el próximo año, ¿qué pasa con mi sistema? La respuesta te dice si este proveedor merece tu firma.
Tres cosas que puedes hacer mañana: primera, añade una cláusula de depósito de código fuente con disparadores de liberación a cualquier contrato de IA que estés negociando; segunda, para sistemas ya en vivo, solicita una exportación completa de datos y verifica que sea realmente usable; tercera, pon un simulacro de salida anual en el calendario, con el primero el próximo mes. No esperes: cuando llegue ese día, nadie te envía una advertencia.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
