Planificación de sucesión de software para pequeños proveedores de IA

Un equipo de compras pasará tres reuniones preguntando a un proveedor de IA sobre residencia de datos y política de entrenamiento. Casi ninguno hace la pregunta que realmente determina si el proveedor seguirá existiendo el próximo año: qué pasa con este software si la persona que lo construyó desaparece.

Esa brecha se está ampliando, no reduciendo. Las herramientas de IA ahora permiten que una o dos personas entreguen software que antes necesitaba un equipo de diez. Eso es bueno para los compradores: entrega más rápida, coste más bajo, un sistema construido para su problema exacto en lugar de una porción configurada de algo genérico. También significa que una parte creciente del software B2B funciona hoy con un bus factor de uno. Nadie asegura ese riesgo, porque nadie pregunta por él.

El riesgo de concentración que nadie asegura

Hace diez años, un software suficientemente sólido para sostener la operación central de una empresa necesitaba una empresa detrás. Esa correlación se ha roto. Un solo desarrollador, con la generación actual de herramientas de código con IA, puede hoy construir y entregar un sistema que hace una década habría tomado dos trimestres a un equipo de cinco personas.

Este es precisamente el argumento a favor de trabajar con proveedores pequeños y especializados. Son más rápidos, cobran menos y construyen exactamente lo que el negocio necesita en lugar del módulo configurable más cercano de una plataforma diseñada para otros diez mil clientes. Para una operación B2B de nicho, ese ajuste suele valer más que la seguridad de un nombre conocido.

Lo que introduce, en silencio, es riesgo de concentración. Si el software sostiene la operación diaria de un cliente y una sola persona tiene todo el modelo mental de cómo funciona, esa operación tiene ahora una dependencia sin ningún respaldo institucional. No es un escenario hipotético. Si el proveedor deja de estar disponible, deja de querer continuar, o entra en insolvencia, el cliente se queda con software que funciona y ningún camino para mantenerlo funcionando.

Los compradores no preguntan por esto porque la categoría casi no tiene nombre todavía. Los cuestionarios de seguridad de proveedores son un género maduro. Los cuestionarios de continuidad de proveedores, para software de la era de la IA construido por equipos muy pequeños, prácticamente no existen todavía.

Las grandes plataformas venden continuidad, no solo software

Salesforce, HubSpot y Microsoft rara vez ganan una comparación funcionalidad por funcionalidad frente a un sistema construido específicamente para el flujo de trabajo de una empresa. Lo que sí ganan es la confianza de que el proveedor seguirá respondiendo tickets de soporte dentro de cinco años, porque la empresa detrás del software tiene miles de empleados y un balance financiero.

Esa confianza no es gratis. El comprador la paga de tres formas: un producto ajustado al cliente mediano en lugar de a su problema específico, trabajo de integración para doblar una herramienta genérica alrededor de su proceso, y un precio que refleja los costes de ventas y soporte empresarial en lugar del coste marginal de la función que realmente usa.

Un proveedor de IA boutique o a medida invierte ese intercambio. Mejor ajuste, entrega más rápida, precio más bajo. Lo que falta por defecto es el respaldo institucional, porque no hay institución detrás, solo una persona o un equipo pequeño.

Visto así, la decisión no es "plataforma segura contra proveedor arriesgado". Es un trade-off entre dos tipos distintos de coste: pagar por adelantado por una continuidad que quizás nunca necesites, incluida en cada función que compras, o pagar por el ajuste exacto y la velocidad, y comprar la continuidad por separado, deliberadamente, dimensionada a lo que el proyecto realmente necesita.

Qué significa la continuidad en concreto, en cinco piezas

"Nos aseguraremos de que estés cubierto" no es un compromiso. Es un sentimiento, y los sentimientos no sobreviven a una revisión de riesgo de un cliente. La continuidad, bien hecha, son cinco piezas concretas.

Documentación técnica. Arquitectura, pasos de despliegue, variables de entorno, esquema de base de datos, procedimientos de recuperación, mantenida actualizada en lugar de escrita una vez al arrancar el proyecto y luego abandonada. Todas las demás piezas de esta lista dependen de esta. Una custodia sin documentación actualizada es un volcado de código que nadie puede operar.

Un contrato de desarrollador de respaldo. Un desarrollador externo evaluado, bajo NDA, que revisa el código periódicamente, idealmente hace un despliegue de prueba contra staging para mantener su conocimiento vivo, y está contractualmente disponible para intervenir dentro de un plazo acordado si ocurre un evento desencadenante. Esta es la pieza que convierte "tenemos el código" en "alguien puede realmente hacerlo funcionar".

Custodia de software (escrow). Código fuente, documentación y scripts de despliegue depositados ante un tercero neutral, entregados al cliente bajo condiciones desencadenantes definidas como indisponibilidad prolongada o insolvencia. Es la pieza más formal y más cara, y la que la mayoría de compradores B2B asume que existe por defecto. Normalmente no es así, a menos que alguien la pida.

Seguro de persona clave. Una póliza que nombra al cliente, o al proyecto, como beneficiario, que paga si el fundador o el desarrollador principal fallece o queda permanentemente incapacitado para trabajar. No restaura la continuidad por sí sola. Financia la transición, cubriendo el coste de un desarrollador de reemplazo o un traspaso apresurado mientras el contrato de desarrollador de respaldo y la documentación hacen el trabajo operativo.

Una cláusula de continuidad en el contrato. La pieza que hace exigibles las otras cuatro en lugar de simplemente prometidas. Especifica qué desencadena un traspaso, a qué tiene derecho el cliente, y en qué plazo. Sin ella, todo lo anterior es buena voluntad.

Ninguna de estas cinco piezas requiere un proveedor grande para implementarse. Requieren un proveedor que haya decidido, antes de que se lo pidan, que esto forma parte de lo que vende junto con el software.

No todos los proyectos necesitan el paquete completo

El error en la dirección contraria es tratar las cinco piezas como obligatorias en todos los proyectos. Un pequeño panel interno que le ahorra a alguien dos horas a la semana no necesita custodia de software. El coste superaría al riesgo que cubre.

Ajusta el tamaño según dos preguntas: cuánto depende realmente la operación del cliente de que esto funcione, y qué tan grave es un fallo si se detiene. Un microsite de marketing o una herramienta interna de reportes necesita documentación y una cláusula, nada más. Un sistema que sostiene la operación diaria de un cliente, del tipo que pararía un almacén, un proceso de siniestros o un servicio de cara al cliente si se apaga, justifica el contrato de desarrollador de respaldo y, superado cierto tamaño de contrato o criticidad, también la custodia y el seguro.

Aquí es también donde el coste deja de ser la objeción esperada. La documentación es sobre todo disciplina, no presupuesto. Un contrato de desarrollador de respaldo cuesta unos pocos miles de euros al año por revisiones trimestrales, aproximadamente el mismo orden de magnitud que un test de penetración anual que la mayoría de compradores de software B2B ya presupuesta en otra parte. La custodia y el seguro de persona clave cuestan más, y precisamente por eso pertenecen a los sistemas donde el daño potencial realmente lo justifica, no a todo por defecto.

Por qué lo integramos desde el inicio, no lo añadimos después

Escribimos hace poco sobre tratar la confianza en la IA y la soberanía europea como decisiones de producto en lugar de comunicación, porque el comprador cambió y empezó a hacer preguntas concretas y verificables en lugar de aceptar un párrafo en la página de la empresa. La continuidad es la mitad operativa del mismo cambio. La soberanía trata de no depender estructuralmente de dónde corre el modelo de un proveedor o de qué pasa con tus datos. La continuidad trata de no depender estructuralmente de si el proveedor sigue existiendo.

Operamos varios sistemas de clientes que caen directamente en la categoría "pararía una operación", incluida una automatización en vivo 24/7 de la que un cliente depende cada día. En proyectos de ese nivel, la documentación y una cláusula de continuidad no son algo que el cliente tenga que negociar después de firmar el contrato. Son parte de lo que se define antes del primer sprint.

La versión honesta de este artículo no es "contrata a una gran plataforma para evitar este riesgo". Las grandes plataformas resuelven la continuidad incluyéndola en el precio de todo, lo necesite o no ese proyecto en concreto, y renunciando al ajuste que hace que valga la pena construir un sistema a medida en primer lugar. La mejor respuesta, para un problema B2B genuinamente de nicho o complejo, es preguntarle al pequeño proveedor que tienes delante cuál es su plan de continuidad antes de firmar, no después de que algo salga mal.

Qué hacer ahora

Si estás evaluando a un proveedor de IA boutique o a medida, pide su plan de continuidad antes de firmar, no después de que algo salga mal. Pregunta en concreto: hay documentación actualizada, hay un desarrollador de respaldo que podría intervenir, y qué garantiza realmente el contrato si el proveedor deja de estar disponible.

Si eres un desarrollador solo o un equipo pequeño construyendo software B2B, la versión más barata para empezar es mantener la documentación actualizada y añadir una cláusula en tu contrato estándar. Añade un contrato de desarrollador de respaldo en cuanto la operación de un cliente dependa genuinamente de que el sistema funcione. El resto se dimensiona según el tamaño de lo que estás protegiendo.