Vendor lock-in en IA: cómo evitar depender de quien te la implanta

Qué es (y qué no es) el vendor lock-in en IA

Cuando se habla de vendor lock-in, casi siempre se piensa en la herramienta: "si uso este software propietario, luego no puedo salir sin pagar una fortuna o rehacerlo todo". Ese lock-in existe y hay que vigilarlo, pero en proyectos de IA para pymes no suele ser el que más duele. El que de verdad para un negocio es el lock-in de conocimiento: la automatización funciona, pero solo la entiende quien la montó.

La diferencia se nota en un momento muy concreto: el día que hay que cambiar algo pequeño. Un cliente cambia de CRM, una plantilla de propuesta cambia de formato, una norma nueva obliga a añadir un campo. Si esa modificación menor exige llamar al proveedor, esperar factura y esperar cola, no es un problema técnico — es que el conocimiento de cómo funciona el sistema nunca llegó a tu empresa. Se quedó fuera.

Con herramientas open-source o estándar el riesgo es menor pero no desaparece: puedes tener el código y seguir sin poder tocarlo, porque nadie de dentro sabe leerlo. El lock-in no es de dónde vive el software. Es de quién sabe operarlo.

Por qué casi ninguna consultora lo evita por defecto

No es mala fe generalizada, es el incentivo del modelo de negocio más común: si el ingreso recurrente depende de que el cliente siga necesitando soporte para cualquier cosa, formar a su equipo para que deje de necesitarlo va en contra del propio negocio. Nadie lo dice así en una propuesta comercial, pero se nota en el resultado: documentación mínima, acceso a la configuración solo para el proveedor, y un "eso mejor lo tocamos nosotros" ante cualquier cambio, por pequeño que sea.

Nosotros tenemos el mismo incentivo económico que cualquier consultora — vivimos de que los clientes sigan trabajando con nosotros. La diferencia está en cómo se gana esa continuidad: no reteniendo el conocimiento, sino siendo lo bastante buenos como para que un cliente que ya podría prescindir de nosotros decida seguir contando con nosotros para lo siguiente. Por eso "autonomía, no dependencia" es uno de los tres principios que no negociamos, no un eslogan de la home.

Cómo lo evitamos: formar mientras se construye

La transferencia de conocimiento no es una fase que añadimos al final si sobra presupuesto. Está integrada en las tres etapas que seguimos con cada cliente, documentadas en nuestra metodología:

• Seahaven construye. Diseñamos y montamos los flujos y agentes funcionando sobre la operativa real del cliente, no sobre un caso de ejemplo.
• Seahaven forma. El equipo del cliente aprende a operar, supervisar y ajustar lo que se ha montado — no a nivel superficial de "botón que hay que pulsar", sino entendiendo qué hace cada pieza y por qué.
• Tu equipo vuela solo. Con supervisión y criterio propios. Nosotros pasamos a un rol de soporte, no de operación — seguimos disponibles, pero ya no somos el único que sabe tocar el sistema.

En la práctica esto significa cosas muy concretas: la documentación de cada flujo se entrega en español llano, no en jerga técnica; alguien del equipo del cliente participa en la construcción, no solo en la recepción del resultado; y los prompts, criterios y excepciones quedan escritos en un sitio que el cliente controla, no en la memoria de una persona externa.

Señales de que ya estás atrapado

No hace falta que sea con nosotros ni que sea IA — esto aplica a cualquier proveedor tecnológico. Algunas señales concretas:

• Nadie de dentro puede explicar en una frase qué hace el sistema. Si la respuesta a "¿cómo funciona esto?" siempre acaba en "eso pregúntaselo a [proveedor]", el conocimiento nunca cruzó la puerta.
• Cualquier cambio, por pequeño que sea, genera un presupuesto. Ajustar un texto o un criterio no debería requerir un proyecto nuevo.
• La documentación, si existe, la tiene el proveedor y no tú. Si mañana cambias de proveedor, ¿te llevas algo utilizable o empiezas de cero?
• El equipo interno nunca estuvo presente en la construcción. Si el sistema se montó sin que nadie del cliente participara, la formación posterior — si la hay — parte con desventaja.

Dónde NO conviene la autonomía total, al menos todavía

• Justo después de implantar algo nuevo. Nadie vuela solo el primer día. La fase de soporte no es un vestigio de dependencia, es parte razonable de cualquier curva de aprendizaje.
• Cuando el equipo no tiene ni el tiempo ni el interés de asumir la operación. Hay empresas donde la decisión correcta es delegar la operación de forma permanente y pagar por ello — no todo el mundo quiere ni necesita tener a alguien interno gestionando prompts. Eso es legítimo si es una decisión consciente, no la consecuencia de que nunca te ofrecieron otra opción.
• En sistemas muy regulados o de alto riesgo. Si un fallo tiene consecuencias legales o de seguridad serias, tiene sentido mantener un proveedor especializado con responsabilidad contractual clara, en vez de repartir esa responsabilidad entre alguien interno sin la misma cobertura.
• Cuando el volumen no justifica formar a nadie. Si un flujo se toca una vez al trimestre, invertir tiempo del equipo en dominarlo a fondo puede no compensar frente a llamar al proveedor esas pocas veces.

Por dónde empezar

Si ya tienes un proyecto de IA en marcha con un proveedor, la pregunta que lo revela todo es simple: pide la documentación completa de cómo funciona y mira quién de tu equipo la entendería sin ayuda. Si vas a empezar uno nuevo, pídelo por escrito antes de firmar: qué parte del conocimiento se queda contigo y en qué momento del proyecto se transfiere, no solo al final.

Cuéntanos vuestro caso y lo miramos. En el diagnóstico gratuito no solo hablamos de qué automatizar, también de quién debería acabar sabiendo operarlo.