Comprar IA, construirla o contratar el resultado: cómo decidir

«Comprar o construir» deja fuera una tercera opción que la IA ha hecho viable: contratar el trabajo realizado. La elección ya no se limita a una licencia frente a una base de código propia. Un comité puede comprar una herramienta, construir una capacidad interna o contratar una operación ejecutada con software que mantiene el proveedor.

La diferencia no está en cuánta IA contiene cada propuesta. Está en quién hace el trabajo, quién mantiene la tecnología y por qué resultado responde cada parte.

Tres contratos distintos

Al comprar SaaS, la empresa obtiene acceso a una herramienta. El proveedor mantiene el producto común. El cliente aporta usuarios, configura el flujo, integra sus sistemas y sigue siendo responsable de ejecutar la operación. El contrato suele medir licencias o consumo.

Al construir, la empresa financia el software, decide su arquitectura y crea un equipo para operarlo. Obtiene control técnico a cambio de asumir contratación, mantenimiento, evaluaciones, seguridad e integraciones. La inversión tiene sentido cuando esa capacidad forma parte del producto de la empresa o existe una cartera permanente que justifica el equipo.

En service as software, el proveedor conserva la plataforma y vende la capacidad operativa. Sus agentes hacen una parte del trabajo y su equipo mantiene el sistema. El cliente aporta reglas, datos, acceso y un responsable del proceso. El contrato se acerca al resultado: expedientes preparados, casos resueltos, oportunidades detectadas o una operación ejecutada con niveles de servicio acordados.

Las tres opciones pueden usar los mismos modelos. Lo que cambia es la distribución de responsabilidad.

Los componentes comunes se contratan

Los modelos de IA ya se consumen por API. También se compran cómputo, almacenamiento y buena parte de la orquestación. Una empresa que no vende modelos no gana posición competitiva entrenando uno fundacional.

Esto no elimina las decisiones técnicas. Hay que separar el modelo del proceso, medir su comportamiento y poder cambiar de proveedor cuando coste, calidad o política de datos lo justifiquen. Pero ese trabajo no tiene por qué ocurrir dentro del cliente. En un servicio gestionado, el operador absorbe el cambio de modelo y protege la continuidad de la operación.

La empresa debería exigir visibilidad del coste y las reglas de uso de datos. No necesita, por ello, crear un equipo que pruebe cada nueva versión del mercado.

Comprar producto cuando el proceso puede ser estándar

Correo, nómina, contabilidad, gastos o firma electrónica suelen admitir un proceso común. Si la forma de ejecutar la función no diferencia a la empresa, adaptar algunas variantes al producto puede reducir complejidad.

La pregunta es qué trabajo queda después de instalarlo. Una plataforma de agentes puede resolver el flujo previsto y dejar al cliente la identificación de excepciones, la creación de evaluaciones, la integración con sistemas y el seguimiento diario. En ese caso se ha comprado una herramienta, aunque el marketing la presente como un trabajador digital.

Antes de firmar, pediría una lista concreta: quién configura cada regla, quién revisa los fallos, quién cambia de modelo, quién mantiene los conectores y quién responde cuando el proceso cambia. Si todas las respuestas apuntan al cliente, la plataforma requiere una función de producto y tecnología.

Construir cuando poseer la capacidad es la estrategia

Construir tiene sentido cuando el software es parte del producto vendido, la empresa ya dispone de dirección técnica y existe trabajo para un equipo durante varios años. Como Chief Product & Technology Officer, desarrollo esa capacidad internamente porque producto y tecnología ya son funciones del negocio.

No aplicaría la misma decisión a una distribuidora o una firma de servicios que quiere mejorar dos operaciones y no tiene un departamento de producto. Contratar ingenieros sin poder evaluar su arquitectura crea una dependencia distinta: la del primer equipo que llegue. Además, los agentes cambian lo bastante rápido como para convertir el mantenimiento en una línea de trabajo continua.

Poseer el repositorio no equivale a poder operar el sistema. Si nadie puede revisar una evaluación, recuperar un fallo o sustituir un modelo, la propiedad formal del código aporta poca autonomía.

Contratar el resultado cuando no quieres operar la tecnología

El service as software encaja cuando el proceso tiene volumen, un resultado observable y reglas que pueden concretarse, pero el cliente no quiere construir la plantilla técnica que lo automatice.

La capa específica sigue existiendo. Cada empresa tiene fuentes, permisos, excepciones y criterios propios. La diferencia es dónde vive ese trabajo. Un forward-deployed engineer lo incorpora a una plataforma que sigue manteniendo el proveedor. No entrega una solución paralela ni ocupa una vacante del cliente. Conecta el sistema común con la operación real.

En Arkatai, mapeamos el proceso, conectamos la plataforma con los sistemas y operamos los agentes bajo controles definidos con el cliente. La firma conserva y mantiene el software. Los FDE incorporan la lógica específica sin crear una base de código que el cliente deba operar. El modelo se explica en la fase custom.

Dependencia no es lo mismo que falta de control

Un servicio crea dependencia del operador. Conviene reconocerla y contratarla bien. En Arkatai separamos la propiedad: la plataforma, su código y sus componentes reutilizables siguen siendo nuestros; la arquitectura operativa específica es del cliente y su entrega actualizada forma parte de la salida contractual.

Esa arquitectura reúne el proceso, las reglas, las excepciones, los controles, los contratos de datos, las especificaciones de integración y los criterios de evaluación. Al finalizar el contrato, se entrega junto con la exportación acordada de datos, resultados y trazas. El cliente puede llevarla a otro implementador o construir su propio software. Tendrá que reimplementar la capa técnica, pero no volver a descubrir cómo funciona su operación.

Para comparar las tres opciones usaría el coste completo: licencias, equipo interno, integración, revisión humana, mantenimiento, excepciones y coste de salida. Después mediría el proceso, no la actividad tecnológica. El marco de ROI de la IA en operaciones parte de esa misma unidad.

Preguntas que me hacen los comités

No tenemos ingenieros para mantener agentes. ¿Descarta eso la IA?

Descarta construir y operar una plataforma internamente, no usar agentes. Puedes comprar una herramienta sencilla para tareas individuales o contratar una operación gestionada. En el segundo caso necesitas un responsable del proceso, no un departamento de IA.

¿Service as software no es una consultora con otro nombre?

No si el proveedor conserva y mantiene una plataforma común, responde por un servicio recurrente y convierte los patrones de cada despliegue en mejoras del núcleo. Si cada cliente recibe un proyecto aislado y toda mejora exige reconstruirlo, sigue siendo consultoría.

¿Cómo evitamos quedar atrapados en el proveedor?

Acordándolo antes de empezar. La arquitectura operativa específica debe figurar como propiedad del cliente, y el contrato debe definir cómo se actualiza y se entrega al terminar junto con los datos, resultados y trazas acordados. La portabilidad relevante es la del conocimiento operativo: permite cambiar de implementador sin convertir un repositorio sin equipo en una falsa garantía de autonomía.

¿Por dónde empezar?

Elige un proceso con volumen, impacto económico y un responsable con autoridad. Documenta el baseline y sus excepciones. Con esa información puedes comparar una licencia, un equipo interno y un servicio gestionado sobre el mismo resultado, en vez de comparar demostraciones.