La pregunta sobre si construir o comprar en IA es fácil de responder mal.
Un lado dice: «Solo compra la herramienta. Los proveedores ya han resuelto esto». El otro afirma: «Necesitamos una IA personalizada. Nuestro flujo de trabajo es especial». Ambos pueden tener razón. Ambos pueden resultar costosos cuando se aplican con descuido.
La decisión real no es construir frente a comprar. Suelen ser estas opciones:
- Comprar una herramienta.
- Configurar una herramienta.
- Extender una herramienta mediante automatización de flujos de trabajo.
- Construir un sistema personalizado en torno a las API del modelo.
- Alojarlo en infraestructura propia o realizar ajuste fino solo cuando el caso sea sólido.
Este artículo ofrece un marco práctico.
Evalúa todo el sistema: acceso a los datos, ajuste al flujo de trabajo, validación, permisos, integraciones, monitorización, supervisión humana, operaciones, términos contractuales y coste de salida. No tomes la decisión basándote en una demostración del modelo.
Comienza con el tipo de capacidad
| Capacidad | Hipótesis inicial | Por qué probarla |
|---|---|---|
| Redacción genérica, reuniones, investigación, asistencia de programación | Prueba compra/configuración primero | Varios candidatos pueden satisfacer un requisito acotado |
| Flujo de trabajo empresarial común | Prueba compra/configuración primero | Los sistemas empresariales existentes ya pueden ofrecer una capacidad gobernada adecuada |
| Automatización para flujos de trabajo específicos | Compara la extensión y la construcción | Las plataformas de flujos de trabajo pueden ser adecuadas, siempre que superen las pruebas de control, fiabilidad e integración |
| Asistente de conocimiento corporativo | Configurar o construir | Depende de los permisos y las fuentes |
| Agente orientado al cliente | Construir/extender con cuidado | Importan la marca, la seguridad, las integraciones y los registros |
| Soporte para decisiones reguladas | Revisión cualificada primero; compara las vías aprobadas del sector, de compra, de construcción o sin IA | La ley, la evidencia, la rendición de cuentas y la supervisión pueden vetar cualquier arquitectura |
| Diferenciación del producto principal | Compara las opciones de propiedad | Solo las pruebas obtenidas de clientes y operaciones demuestran si la propiedad crea una ventaja |
Si varios proveedores cumplen los requisitos, comprar puede reducir el nivel de propiedad. Si el flujo de trabajo es estratégicamente importante o las brechas del proveedor son significativas, extender o construir pueden estar justificados. Demuestra ambas afirmaciones.
Las cuatro dimensiones de decisión
1. Ajuste al flujo de trabajo
¿Puede la herramienta del proveedor adaptarse al proceso real?
Pregunta:
- ¿Puede acceder a los sistemas de registro?
- ¿Puede aplicar nuestras reglas de aprobación?
- ¿Puede gestionar excepciones?
- ¿Puede preservar los registros de auditoría?
- ¿Puede admitir nuestros idiomas y satisfacer las expectativas de los clientes?
- ¿Pueden los usuarios trabajar donde ya trabajan?
Si el equipo tiene que adaptar a diario su trabajo a las limitaciones de la herramienta, el precio de compra resulta engañoso.
2. Control de datos
¿Qué datos entran en el sistema y adónde van?
Comprar es más fácil cuando los datos son públicos, internos o ya aprobados para ese proveedor. Construir o desplegar en privado se vuelve más probable cuando los datos son confidenciales, regulados, específicos del cliente o están sujetos a estrictos requisitos de residencia y conservación de los datos.
No construyas por teatro de privacidad. Construye o despliega en privado cuando las normas sobre los datos realmente lo requieran.
3. Profundidad de integración
Algunos sistemas de IA generan valor a través de conexiones gobernadas con sistemas de registro o acción: CRM, correo electrónico, calendario, gestión de tickets, ERP, almacenes de documentos, bases de datos, pagos, identidad y registros. Otros casos de uso deben permanecer aislados o de solo lectura.
Como hipótesis inicial, las integraciones estándar pueden favorecer la compra, mientras que los flujos de trabajo personalizados con estado podrían favorecer extender o construir. Una prueba representativa debe verificar los permisos, la recuperación ante fallos, la observabilidad y el coste de salida.
Ejemplo:
- «Resumir tickets de soporte» -> comprar/configurar.
- «Clasificar tickets de soporte, verificar el SLA del contrato, inspeccionar la telemetría del producto, redactar respuesta, enrutar por nivel de cliente y registrar todas las decisiones» -> extender/construir.
4. Diferenciación estratégica
Si los competidores pueden obtener y configurar la misma capacidad con resultados comparables, la capacidad en sí puede no ser una ventaja duradera. Mide el valor para el cliente y la diferenciación operativa en lugar de inventar un cronograma para copiarla.
Construye allí donde el sistema codifique tu proceso, tus datos, tu distribución, tu experiencia en el dominio o la experiencia del cliente de una forma que un proveedor genérico no puede.
Coste total de propiedad (TCO)
Compara el coste completo, no solo la licencia frente al tiempo de desarrollo.
| Área de coste | Compra | Construcción |
|---|---|---|
| Licencia/API | Contratado pero potencialmente variable por puesto, uso, nivel o exceso de uso | API, inferencia, infraestructura y servicios de terceros |
| Implementación | Configuración, migración, integración y gestión del cambio | Trabajo de producto, integración, plataforma y migración |
| Mantenimiento | El proveedor asume algunas capas de la plataforma; el cliente sigue asumiendo la configuración y las integraciones | Tu equipo asume las capas definidas del sistema y sus dependencias |
| Revisión de seguridad | Debida diligencia del proveedor | Revisión de arquitectura y código |
| Integración | Limitada por el proveedor | Flexible pero costosa |
| Control de cambios | Riesgo en la hoja de ruta del proveedor | Carga de la hoja de ruta interna |
| Soporte | Soporte del proveedor | Soporte interno |
| Coste de salida | Limitaciones de datos/exportación | Deuda técnica y propiedad |
Ambas vías pueden implicar costes materiales y duraderos. Compara cotizaciones actuales, costes laborales totales, migración, soporte, incidentes y escenarios de salida durante el mismo período.
La hoja de puntuación
Puntúa cada dimensión de 1 a 5, define el significado de cada puntuación y pondera las dimensiones antes de evaluar a los proveedores. No permitas que una puntuación total alta anule un veto de seguridad de la información, legal, de privacidad, de protección frente a daños (safety), de accesibilidad o de residencia de datos.
| Dimensión | La compra se favorece cuando es baja | La construcción se favorece cuando es alta |
|---|---|---|
| Especificidad del flujo de trabajo | Flujo genérico | Flujo único |
| Sensibilidad de los datos | Público/interno | Confidencial/restringido |
| Profundidad de integración | Integraciones estándar | Flujo personalizado multi-sistema |
| Diferenciación | Producto básico (commodity) | Ventaja estratégica |
| Tasa de cambio | Hoja de ruta del proveedor aceptable | Necesita iteración interna rápida |
| Capacidad operativa | Poca o ninguna capacidad de ingeniería | El equipo puede asumir el sistema en producción |
La hoja de puntuación complementaria enlazada desde este artículo ofrece una plantilla reutilizable. Adjunta pruebas a cada puntuación: el resultado de la prueba, una cláusula contractual, una revisión de arquitectura, una cotización, una prueba comparativa o una investigación con clientes.
Para las opciones finalistas, implementa el mismo segmento representativo y registra el éxito de la tarea, la recuperación ante fallos, el esfuerzo humano, la latencia, el coste, las limitaciones de integración, el comportamiento de los permisos, la observabilidad y la vía de exportación o salida. Vuelve a calcular la puntuación después de la prueba.
Un árbol de decisiones práctico
- ¿Una herramienta del proveedor cumple los requisitos obligatorios de forma segura? Prueba candidatos para comprar/configurar.
- ¿La brecha restante importa operativamente? Extiende con automatización antes de construir a medida.
- ¿El flujo de trabajo requiere datos privados, permisos personalizados o integración profunda? Compara la configuración empresarial, una extensión, una capa personalizada ligera y controles sin IA o manuales frente a los requisitos obligatorios.
- ¿Es necesario personalizar el comportamiento del propio modelo? Considera el ajuste fino solo después de evaluar enfoques aplicables más sencillos, como el diseño de prompts, la lógica determinista, la recuperación o las salidas restringidas, con evaluaciones para cada opción.
- ¿El despliegue requiere control privado? Considera VPC o alojamiento en infraestructura propia después de medir la calidad, el coste y las operaciones.
Comienza por arriba. No saltes a una infraestructura personalizada porque la demostración parezca estratégica.
Cuándo comprar es la decisión correcta
Compra cuando:
- El flujo de trabajo sea común.
- El proveedor ya se integre con tu pila tecnológica.
- La sensibilidad de los datos sea manejable.
- El coste se ajuste al uso.
- Sea importante obtener valor con rapidez.
- La capacidad no sea un diferenciador.
- No tengas capacidad para operar un sistema personalizado.
Ejemplos: resúmenes de reuniones, asistentes de escritura, macros básicas de soporte, autocompletado de código, redacción de correos electrónicos de ventas, búsqueda interna sobre documentos aprobados.
Cuándo construir es la decisión correcta
Construye cuando:
- El flujo de trabajo sea central para el negocio.
- Las herramientas del proveedor no puedan aplicar los controles requeridos.
- Necesites integración profunda con sistemas internos.
- Los datos no puedan enviarse a SaaS genéricos.
- Necesites observabilidad detallada y evaluaciones (evals).
- La experiencia de usuario sea parte de tu producto.
- Puedas mantenerlo.
Ejemplos: producto de IA orientado al cliente, flujo de trabajo regulado de documentos, RAG corporativo que respeta los permisos, agente específico del sector, canalización privada de extracción de datos.
No hagas esto aún
No construyas una plataforma antes de demostrar un solo flujo de trabajo.
No compres una herramienta sin una revisión del tratamiento de datos.
No aceptes funciones de IA del proveedor sin probar casos extremos reales.
No realices un ajuste fino antes de probar el diseño de prompts, RAG y las evaluaciones.
No alojes en infraestructura propia solo porque suene privado. Demuestra el requisito de privacidad y la capacidad operativa.
Deja que decida la prueba representativa
La decisión correcta entre construir o comprar un sistema de IA depende de pruebas concretas. La actual evaluación de idoneidad de la IA del Gobierno del Reino Unido también comienza por determinar si la IA es siquiera adecuada, teniendo en cuenta los datos, los usuarios, los posibles daños, las alternativas y el coste del ciclo de vida.
Usa las vías de compra, configuración, extensión, construcción y sin IA/manual como hipótesis. Selecciona el candidato con menor nivel de propiedad que cumpla los requisitos obligatorios de flujo de trabajo, datos, seguridad, integración, coste, accesibilidad y salida. El modelo y el sistema circundante pueden ser cada uno el factor limitante; la prueba representativa debe mostrar cuál es.
