PROGEN
Tienes un proceso que consume horas de tu equipo, has visto que la IA podría ayudar y no tienes a nadie en plantilla capaz de montarlo. La opción realista es contratar a alguien de fuera. La duda que aparece justo después es la que casi nadie plantea en voz alta: si lo construye un tercero, ¿qué pasa cuando el tercero se va?
Esa pregunta es la buena. Y tiene respuesta, pero requiere decidir desde el principio dónde pones la frontera entre lo que subcontratas y lo que se queda dentro de tu empresa.
Por qué contratar a un ingeniero interno rara vez es la primera jugada
La alternativa teórica a externalizar es fichar un perfil técnico. En una pyme suele fallar por tres motivos prácticos.
El primero es que un solo perfil no cubre el abanico necesario. Un proyecto de automatización con IA toca integración con tus sistemas, tratamiento de datos, diseño de prompts o modelos, despliegue, seguridad y cumplimiento normativo. Encontrar a una persona sola que haga todo eso bien y que además quiera trabajar sin equipo técnico alrededor es difícil.
El segundo es el volumen de trabajo. La implantación es intensa durante unas semanas o meses; el mantenimiento posterior es mucho más ligero. Contratas a jornada completa para una curva que no es plana.
El tercero es que sin nadie que sepa evaluar el trabajo, la contratación es una apuesta a ciegas. Si no puedes juzgar técnicamente a un candidato, externalizar con un contrato bien escrito es menos arriesgado que fichar.
Esto no significa que nunca haya que internalizar. Cuando la automatización se convierte en parte del producto que vendes, o cuando el volumen de proyectos justifica un equipo, tiene sentido. Pero normalmente eso llega después, no antes.
Qué se subcontrata de verdad
Cuando decides externalizar implementación de IA en empresas sin equipo técnico propio, lo que compras no es «inteligencia artificial». Es una lista bastante concreta de trabajos.
Diagnóstico y elección de qué automatizar
La parte más rentable del proyecto ocurre antes de escribir código: decidir qué proceso se toca y cuál se deja en paz. Un proveedor con experiencia debería decirte que dos de tus cinco ideas no merecen la pena, y explicarte por qué. Si te dice que sí a todo, mala señal.
Construcción e integración
Aquí entra el trabajo técnico visible: conectar con tu ERP, tu CRM, tu gestor documental o tu correo; montar los flujos; elegir y ajustar el modelo; construir la interfaz que use tu equipo. Es la parte que claramente no vas a hacer internamente.
Pruebas y ajuste con datos reales
Un sistema que clasifica documentos o redacta respuestas funciona distinto con tus datos que con datos de demostración. Esta fase, que consiste en medir errores y corregir, suele ser la que separa un proyecto que se usa de uno que se abandona a los dos meses.
Documentación y traspaso
Esto se subcontrata también, y es donde más proyectos cojean. Si no está en el contrato como entregable con nombre y apellidos, no lo esperes.
Mantenimiento evolutivo
Los modelos cambian, las API cambian, tus procesos cambian. Alguien tiene que ocuparse. Puede ser el mismo proveedor con un acuerdo de horas mensuales, otro proveedor, o tu equipo si el sistema es sencillo.
Qué no puedes externalizar aunque quieras
Hay cuatro cosas que se quedan dentro por definición, y conviene asignarlas a personas concretas antes de empezar.
El conocimiento del proceso. Nadie de fuera sabe por qué tu departamento de compras rechaza determinadas facturas o qué excepciones tolera un cliente antiguo. Ese saber tiene que salir de tu gente y hay que reservarles tiempo para contarlo. Un proyecto en el que el responsable de operaciones no puede dedicar horas a explicar el proceso es un proyecto que va a salir mal.
La decisión sobre los datos. Qué información sale de tu empresa, hacia dónde, con qué base legal y durante cuánto tiempo. El proveedor te propone opciones y firma un contrato de encargado del tratamiento; la responsabilidad de decidir sigue siendo tuya, y también la de cumplir con el Reglamento General de Protección de Datos. Si el sistema toma decisiones que afectan a personas, el Reglamento de IA europeo añade obligaciones según el nivel de riesgo, y el titular de esas obligaciones es la empresa que usa el sistema, no quien lo programó.
La propiedad de las credenciales y las cuentas. Las claves de API, las cuentas en el proveedor de nube, los repositorios de código: a nombre de tu empresa, siempre. Es la diferencia entre cambiar de proveedor en dos semanas o reconstruirlo todo.
Un responsable interno del sistema. No tiene que ser técnico. Tiene que ser alguien que sepa qué hace el sistema, qué debería hacer, y que detecte cuando se desvía. Sin esa figura, el proyecto no tiene dueño y nadie se entera cuando deja de funcionar bien.
Cómo no acabar atado al proveedor
La dependencia no es un accidente: es el resultado de no haber pedido ciertas cosas. Estas son las que importan.
Que la propiedad intelectual sea tuya, por escrito
El contrato debe decir que el código, las configuraciones, los prompts y la documentación desarrollados para ti son de tu propiedad. Es habitual que el proveedor mantenga la titularidad de componentes genéricos que reutiliza entre clientes; eso es legítimo, pero pide una licencia perpetua e irrevocable de uso sobre ellos, y que estén identificados.
Nada de tecnología cerrada del proveedor
Desconfía de la plataforma propia y no documentada. Si el sistema se construye sobre herramientas estándar y ampliamente utilizadas, cualquier otro equipo técnico puede retomarlo. Si se construye sobre algo que solo entiende quien lo hizo, la salida cuesta dinero.
Documentación como entregable, no como favor
Pide por contrato: arquitectura del sistema, inventario de integraciones y credenciales, decisiones de diseño con su justificación, procedimiento de despliegue, y qué hacer cuando algo falla. En castellano, legible por alguien que no participó en el proyecto.
Cláusula de salida
Define qué ocurre si terminas la relación: plazo de entrega de todo el material, horas de acompañamiento incluidas para el traspaso, y compromiso de responder dudas durante un periodo posterior. Se negocia al principio, cuando el proveedor quiere firmar, no al final.
Formación real de tu equipo
No una sesión de demostración. Sesiones de trabajo en las que tu gente opera el sistema, provoca errores a propósito y aprende a interpretarlos. Es la mejor póliza contra la dependencia, y la más barata.
En los proyectos de integración de IA en empresas que llevamos, este punto es el que marca la diferencia entre un cliente que a los seis meses nos pide mejoras concretas y bien argumentadas, y uno que nos llama para preguntar qué está pasando. El primero paga menos y obtiene más.
Señales de que el proveedor te está construyendo una jaula
Algunas conductas son bastante fiables como aviso:
- Evita hablar de propiedad del código o lo deja para «cuando avancemos».
- Registra las cuentas de nube y las claves de API a su nombre.
- Propone su plataforma propia para todo, sin documentación pública.
- No cuantifica el mantenimiento posterior ni lo que incluye.
- No pregunta apenas por tu proceso y va directo a la solución.
- Presenta el proyecto como algo que tu equipo «no necesita entender».
Ninguna es descalificatoria por sí sola, pero tres juntas sí lo son.
Un orden razonable para empezar
Si vas a externalizar por primera vez, empieza pequeño y con criterio de salida claro.
Elige un proceso con volumen suficiente para que el ahorro se note, con reglas relativamente estables y donde un error no sea catastrófico. Clasificación y extracción de datos de documentos entrantes, preparación de respuestas que luego revisa una persona, o consolidación de información dispersa entre sistemas son territorios habituales.
Define antes de firmar cómo vas a medir si ha funcionado: tiempo por operación, tasa de error, número de casos que requieren intervención manual. Sin métrica acordada, la discusión al final del proyecto es de opiniones.
Y reserva presupuesto para los meses siguientes al arranque. Un sistema recién implantado necesita ajustes; el error clásico es gastarlo todo en la construcción y quedarse sin margen justo cuando el sistema empieza a dar datos reales sobre lo que hay que corregir.
Preguntas frecuentes
¿Cuánto tiene que implicarse mi equipo si lo hace un proveedor externo?
Más de lo que la mayoría espera. Cuenta con que las personas que conocen el proceso dediquen varias horas semanales durante la fase de diagnóstico y diseño, y que participen en las pruebas con casos reales. No es tiempo perdido: es lo que evita construir algo que técnicamente funciona pero no encaja con cómo trabajáis. Si nadie de tu empresa puede reservar ese tiempo, es mejor retrasar el proyecto.
¿Es peligroso que un proveedor externo acceda a nuestros datos?
Es gestionable, no automáticamente peligroso. Necesitas un contrato de encargado del tratamiento conforme al RGPD, saber en qué servicios y ubicaciones se procesan los datos, limitar el acceso a lo estrictamente necesario y usar datos anonimizados o de prueba siempre que sea posible durante el desarrollo. Lo que sí es peligroso es no preguntar nada de esto.
¿Qué presupuesto de mantenimiento hay que prever?
Depende de la complejidad y del número de integraciones, pero conviene pensarlo como un porcentaje anual del coste de implantación en lugar de asumir que es cero. Pide al proveedor que cuantifique el mantenimiento en la propuesta inicial, con lo que incluye y lo que no. Si no sabe estimarlo, probablemente tampoco ha mantenido muchos sistemas.
¿Cuándo tiene sentido dejar de externalizar y montar equipo propio?
Cuando tienes varios sistemas en producción a la vez, cuando los cambios que necesitas son continuos en lugar de puntuales, o cuando la automatización pasa a formar parte de lo que vendes a tus clientes. Antes de eso, un modelo mixto suele funcionar mejor: proveedor externo para construir, responsable interno para operar y decidir.