IA a medida o herramienta de mercado: cómo decidir y cómo medir el retorno

En casi todas las conversaciones con direcciones de ingenierías y estudios medianos aparece la misma pregunta: ¿desarrollamos nuestra propia solución de IA o contratamos una herramienta del mercado? Suele plantearse como una cuestión técnica. No lo es. Es una decisión de negocio con consecuencias técnicas, y se toma mal cuando se empieza por la tecnología.

Un dato de contexto ayuda a enmarcarla. Entre noviembre de 2025 y febrero de 2026 los principales proveedores han publicado varias generaciones de modelos: Gemini 3 y Claude Opus 4.5 en noviembre, Claude Opus 4.6 en febrero. Cualquier solución construida hoy tendrá que absorber cambios de modelo varias veces al año. Ese coste, que rara vez aparece en el presupuesto inicial, es central en la decisión.

Cinco criterios para decidir

1. Diferenciación

La primera pregunta es si el proceso que se quiere apoyar con IA diferencia a la empresa frente a sus competidores. La redacción de actas, la transcripción de reuniones o la consulta de normativa general son procesos necesarios pero no diferenciales: comprar suele ser lo sensato. En cambio, el método propio de una ingeniería para estimar costes de instalaciones a partir de su histórico de obras sí puede serlo.

2. Datos

Una solución a medida solo tiene sentido si hay datos propios, suficientes y en condiciones de uso: proyectos anteriores estructurados, presupuestos con partidas homogéneas, incidencias de obra documentadas. Si los datos están dispersos en carpetas sin criterio, el primer proyecto no es de IA, es de ordenación documental.

3. Mantenimiento

Desarrollar es la parte barata. Lo caro es mantener: actualizar el modelo cuando el proveedor lo retira, ajustar los prompts, reindexar documentos cuando cambia la normativa, gestionar la seguridad y responder a los usuarios. Una regla prudente es estimar el coste anual de mantenimiento como una fracción significativa del coste de desarrollo y validarla con quien vaya a asumirlo.

4. Coste de evaluación

Es el criterio que más se olvida. Para saber si una solución funciona hay que evaluarla de forma sistemática: un conjunto de casos de prueba representativos, con respuestas correctas conocidas, que se ejecuta cada vez que cambia el modelo o el sistema. En un sistema de consulta normativa, por ejemplo, implica un banco de preguntas con su artículo correcto del CTE o del RITE. Construir y mantener ese banco requiere tiempo de técnicos sénior. Si no está dispuesto a pagarlo, no construya.

5. Dependencia del proveedor

Comprar crea dependencia de un proveedor de herramientas; construir sobre una única API crea dependencia de un proveedor de modelos. La pregunta útil es: ¿qué ocurre si mañana este proveedor cambia precio, condiciones o desaparece? Exija exportación de sus datos, contratos con tratamiento de datos en la UE y, si construye, una arquitectura que permita cambiar de modelo.

Un esquema práctico

Compre lo que es común, construya lo que es suyo y no construya nada que no esté dispuesto a evaluar cada trimestre.

En la práctica, la mayoría de las organizaciones del sector acaban en un modelo mixto: herramientas de mercado para procesos generales y una capa propia, normalmente un sistema de recuperación aumentada (RAG) sobre su documentación interna, donde está su conocimiento diferencial.

Antes de decidir construir, merece la pena un paso intermedio: pilotar durante dos o tres meses una herramienta de mercado sobre el proceso candidato. Si no resuelve el problema, el piloto habrá servido para especificar con precisión qué debe hacer la solución propia; si lo resuelve, se habrá evitado un desarrollo innecesario.

Cómo medir el retorno para un consejo

Los consejos desconfían, con razón, de los cálculos de retorno basados en "horas ahorradas" multiplicadas por un coste hora teórico. Propongo un método en cuatro pasos:

1. Línea base medida. Antes de implantar, mida durante cuatro a seis semanas el tiempo y los errores del proceso actual. Sin línea base no hay retorno demostrable.
2. Indicadores de resultado, no de uso. No "número de consultas a la herramienta", sino plazo de entrega de la memoria, número de requerimientos del colegio en el visado o incidencias detectadas antes de licitación.
3. Coste total. Licencias o desarrollo, mantenimiento, evaluación, formación y tiempo de revisión humana. Este último suele omitirse y puede ser considerable.
4. Grupo de comparación. Siempre que sea posible, compare proyectos con y sin la herramienta en el mismo periodo.

Un ejemplo orientativo, con cifras estimadas y redondeadas para un escenario tipo de ingeniería de 40 personas: si la revisión documental previa al visado consume unas 15 horas por proyecto y la herramienta la reduce a 9, con 60 proyectos al año el ahorro bruto ronda las 360 horas. A eso hay que restar el tiempo de evaluación y revisión. El dato que convence al consejo, sin embargo, no suele ser ese, sino la reducción de requerimientos y reprocesos, que afectan al plazo y a la reputación.

Un apunte regulatorio

El Ómnibus Digital, que propone aplazar parte de las obligaciones del Reglamento europeo de IA, sigue en negociación entre Parlamento y Consejo al cierre de este artículo. Con independencia de su resultado, quien construye su propia solución asume más obligaciones de documentación y transparencia que quien la compra. Es un coste más a incluir en la decisión.

La pregunta correcta, por tanto, no es "¿construir o comprar?", sino "¿dónde está nuestro conocimiento diferencial y cuánto estamos dispuestos a invertir en mantenerlo y evaluarlo?"