Tu empresa quiere implantar IA: ¿necesita una consultora, un integrador tecnológico, software o dirección externa?
Una consultora, un integrador tecnológico, un proveedor de software y una dirección externa no resuelven el mismo problema. Antes de elegir quién te ayudará a implantar IA, necesitas identificar qué capacidad le falta realmente a tu empresa: criterio, tecnología, integración o dirección.
Tu empresa ha decidido implantar inteligencia artificial. La decisión parece importante, pero bastante clara: identificar una oportunidad, elegir tecnología y empezar.
Entonces llegan las alternativas.
Una consultora propone identificar casos de uso y construir un roadmap. Un integrador tecnológico plantea conectar modelos, datos y sistemas. Un proveedor asegura que su software ya resuelve gran parte del problema. Alguien propone desarrollar agentes a medida. Y quizá otra opción sea incorporar capacidad de dirección para decidir qué merece hacerse, coordinar a los distintos actores y convertir la tecnología en una nueva forma de trabajar.
Todos pueden tener razón.
Y precisamente por eso elegir es difícil.
Una empresa puede contratar a un proveedor excelente y seguir tomando una mala decisión si ese proveedor resuelve una capacidad distinta de la que realmente le falta.
Una empresa suele necesitar una consultora cuando todavía debe definir qué problema resolver, qué casos priorizar o cómo plantear la transformación; un integrador cuando la solución está suficientemente clara pero exige conectar tecnología, datos y sistemas; software cuando el problema ya está suficientemente estandarizado; y dirección externa cuando el principal déficit está en gobernar prioridades, responsables, proveedores, procesos, adopción y resultados. Muchas implantaciones necesitan varias de estas capacidades a la vez. Y si la empresa ya dispone internamente de criterio, ownership y capacidad técnica suficientes, puede no necesitar ninguna de ellas.
- Consultoría, integración, software y dirección externa no son formas distintas de vender lo mismo. Resuelven carencias diferentes y pueden coexistir en una misma implantación.
- Elegir proveedor antes de diagnosticar la capacidad que falta puede llevar a resolver el problema equivocado. Una empresa puede comprar software cuando necesita dirección o contratar consultoría cuando lo que falta es integración.
- Software es frecuentemente la mejor respuesta cuando el problema ya está suficientemente estandarizado. Poder construir una solución específica no significa que exista una razón empresarial para hacerlo.
- Un integrador es especialmente valioso cuando el reto está en hacer funcionar conjuntamente modelos, datos, sistemas, permisos e infraestructura. Eso no le convierte automáticamente en responsable de decidir las prioridades del negocio.
- La dirección externa tiene sentido cuando falta ownership y capacidad directiva para convertir tecnología, procesos y proveedores en una implantación gobernada. Si esa capacidad existe internamente, puede ser innecesaria.
- Un piloto funcional no demuestra todavía una capacidad empresarial. Producción exige fiabilidad, gobierno, integración, costes sostenibles, mantenimiento y medición del resultado.
- La empresa puede externalizar capacidades, pero no su responsabilidad empresarial final. Debe conservar criterio sobre objetivos, riesgo, datos, autonomía y retorno.
- Respuesta rápida: qué necesitas según el problema que tienes
- Antes de elegir proveedor, identifica qué capacidad te falta
- Cuándo necesitas una consultora de IA
- Cuándo necesitas un integrador tecnológico
- Cuándo comprar software es mejor que construir
- Cuándo el problema no es tecnológico: necesitas dirección
- El error es pensar que tienes que elegir solo uno
- Qué dependencia debes evaluar antes de elegir un proveedor de IA
- Cuando cambiar de modelo o proveedor no resolverá el problema: los datos
- Qué debe ser capaz de llevar a producción un proveedor de IA
- Qué decisiones no debería delegar la empresa al proveedor ni a la IA
- Cuándo sí necesitas dirección externa
- Matriz final: qué necesita realmente tu empresa
- Diez preguntas antes de pedir un presupuesto de IA
- Dónde encaja Rumbo & Resultados
- Antes de seleccionar proveedor, identifica la capacidad que falta
- Preguntas frecuentes sobre consultoría, integración, software y dirección para implantar IA
1. Respuesta rápida: qué necesitas según el problema que tienes
Consultora, integrador tecnológico, software y dirección externa suelen aparecer juntas cuando una empresa empieza a buscar ayuda para implantar inteligencia artificial.
Pero no son cuatro versiones de la misma solución.
Cada una cubre una carencia diferente. La dificultad consiste en que una empresa puede describir todas ellas con la misma frase —“queremos implantar IA”— aunque el problema que necesita resolver sea completamente distinto.
| Si tu problema principal es… | La capacidad que probablemente falta | Respuesta que gana peso |
|---|---|---|
| No sabemos dónde aplicar IA, qué priorizar ni cómo justificar la inversión | Criterio, diagnóstico, priorización y diseño de transformación. | Consultoría o dirección |
| Sabemos qué queremos conseguir, pero hay que conectar datos, sistemas, modelos o infraestructura | Arquitectura e integración tecnológica. | Integrador tecnológico |
| El problema está bien definido y ya existe una solución madura que lo resuelve suficientemente bien | Funcionalidad operativa estandarizada. | Software |
| Tenemos iniciativas, herramientas o proveedores, pero nadie gobierna prioridades, procesos y resultados | Ownership y capacidad directiva transversal. | Dirección externa |
| La empresa ya dispone de criterio, owner, capacidad técnica y recursos suficientes | Puede no faltar ninguna capacidad externa crítica. | Equipo interno |
| Faltan varias capacidades a la vez | Dirección, diseño, tecnología o ejecución en distintas proporciones. | Modelo combinado |
La tabla clasifica problemas, no proveedores por calidad
Una buena consultora puede participar en implantación y una buena empresa integradora puede ayudar a diseñar arquitectura y solución. Las fronteras no son absolutas. La comparación sirve para identificar cuál es la responsabilidad principal que necesitas cubrir, no para encerrar a cada empresa en una única actividad.
1.1. Una consultora ayuda principalmente cuando todavía hay que decidir qué hacer
Si la empresa sabe que quiere aprovechar IA pero todavía no tiene una respuesta suficientemente sólida sobre qué procesos transformar, qué casos de uso tienen sentido, qué retorno espera o cómo debería organizar la implantación, existe antes un problema de diagnóstico y decisión.
En ese escenario, empezar directamente por producto o desarrollo puede obligar a tomar decisiones técnicas sobre una necesidad empresarial que todavía no está suficientemente definida.
Gana peso cuando la empresa necesita entender qué debería hacer antes de decidir cómo hacerlo. Puede ayudar a identificar oportunidades, priorizar casos, construir business cases, diseñar un roadmap, definir gobierno y comparar alternativas.
1.2. Un integrador gana peso cuando el problema ya está definido pero la tecnología debe funcionar dentro de la empresa
Una solución de IA rara vez opera de forma aislada cuando entra en un proceso empresarial relevante.
Puede necesitar datos del ERP, escribir información en el CRM, recuperar documentación, respetar permisos, identificar usuarios, llamar a APIs, mantener contexto, registrar acciones o convivir con sistemas existentes.
Cuando ese es el reto principal, el problema se parece menos a “qué deberíamos hacer con IA” y más a cómo conseguir que una solución determinada funcione de forma fiable dentro de nuestra arquitectura real.
Gana peso cuando el resultado está suficientemente definido y el desafío principal consiste en hacer que modelos, datos, aplicaciones, permisos e infraestructura funcionen juntos.
1.3. Comprar software puede ser la decisión más sofisticada precisamente porque evita construir
La capacidad tecnológica para desarrollar algo no constituye por sí misma una razón para hacerlo.
Si el problema ya está suficientemente estandarizado y existe software capaz de resolverlo con una calidad razonable, desarrollar una solución específica puede añadir tiempo, mantenimiento, coste y riesgo sin crear una ventaja proporcional.
Esto es especialmente importante ahora que los modelos generativos reducen el coste aparente de construir prototipos. Que crear una primera versión sea más barato no significa que resulte más barato operar, mantener y evolucionar el sistema durante años.
Gana peso cuando el problema es suficientemente común, la solución existente cubre bien la necesidad y construir algo propio no crea una ventaja empresarial que justifique el coste adicional.
1.4. Dirección externa gana peso cuando el problema está entre todas las piezas
Una empresa puede tener buenas herramientas, un buen integrador y especialistas capaces de resolver problemas concretos y seguir sin conseguir una implantación coherente.
Puede no existir nadie con suficiente tiempo y autoridad para decidir qué iniciativa merece prioridad, qué proceso debe cambiar, qué resultado económico se espera, qué proveedor responde de cada parte, qué riesgo se acepta o cuándo un piloto debe detenerse.
En ese escenario no falta necesariamente conocimiento técnico. Puede faltar capacidad de dirección aplicada transversalmente a la implantación.
Gana peso cuando la empresa necesita ownership ejecutivo para priorizar, decidir, coordinar áreas y proveedores, transformar procesos, establecer métricas y responder por que la implantación se convierta en resultado empresarial.
1.5. Y existe una quinta respuesta que conviene no olvidar: quizá no necesitas contratar a nadie
Una empresa con una dirección clara, un responsable suficientemente dedicado, capacidad técnica interna, datos adecuados y un proceso bien definido puede desarrollar una implantación sin incorporar ninguna de estas capas externamente.
Externalizar no debería ser un requisito para utilizar IA.
La decisión debería ser similar a cualquier otra decisión sobre capacidad empresarial: qué necesitamos hacer, qué sabemos hacer suficientemente bien internamente y qué resulta más eficiente adquirir fuera.
No confundas complejidad con necesidad de externalización
Un proyecto complejo puede ser perfectamente gobernable internamente si la empresa dispone de las capacidades adecuadas. Y un proyecto técnicamente sencillo puede fracasar si nadie tiene ownership, el proceso no está definido o la organización no cambia su forma de trabajar.
1.6. La misma empresa puede necesitar respuestas distintas según el caso de uso
Tampoco existe una única respuesta para toda la organización.
Una empresa puede comprar software estándar para resumir reuniones, utilizar un integrador para conectar información comercial con su CRM, contratar consultoría para rediseñar un proceso financiero y necesitar dirección para gobernar un programa transversal que afecta a varias áreas.
Por eso la categoría del proveedor debería aparecer después de identificar la naturaleza del problema.
La unidad de decisión no debería ser “qué proveedor de IA elegir”. Debería ser “qué capacidad falta para resolver este problema concreto”.
Elegir bien un proveedor no compensa haber diagnosticado mal la capacidad que necesitas comprar.
2. Antes de elegir proveedor, identifica qué capacidad te falta
La expresión “implantar IA” mezcla demasiadas decisiones distintas.
Puede significar comprar una herramienta para una tarea muy concreta, automatizar parte de un proceso, construir una capacidad específica, integrar un modelo en los sistemas existentes o transformar la manera en que una función completa trabaja y toma decisiones.
La misma etiqueta contiene problemas con grados de riesgo, inversión, dependencia y cambio organizativo radicalmente diferentes.
Por eso antes de comparar proveedores conviene separar al menos cuatro dimensiones: claridad empresarial, estandarización, complejidad de integración y capacidad de gobierno.
Los datos recientes ayudan a entender por qué esta pregunta está ganando relevancia. El KPMG Global Tech Report 2026 · Edición España, basado en una encuesta internacional a 2.500 directivos tecnológicos y más de cien respuestas de organizaciones españolas, señala que el 65% de las organizaciones en España afirma obtener ya valor empresarial de sus casos de uso de IA. Sin embargo, solo el 23% declara conseguir ROI en múltiples casos de uso.
La distancia entre ambas cifras importa. Obtener valor de una aplicación concreta no significa haber convertido la IA en una capacidad repetible, gobernada y económicamente consistente en distintas partes de la empresa.
El mismo estudio encuentra además que el 67% de las organizaciones españolas reconoce no disponer todavía del talento necesario para ejecutar su transformación digital y que el 91% prevé ampliar alianzas y ecosistemas tecnológicos durante los próximos doce meses.
Eso significa que muchas empresas van a necesitar ayuda externa. Lo que todavía no responde es qué clase de ayuda.
Adoptar IA y escalar IA no son la misma cosa
Estas cifras no demuestran que el 77% de las empresas esté fracasando ni que externalizar sea mejor que desarrollar capacidad interna. Sí muestran una diferencia relevante entre obtener valor en casos concretos y conseguir retorno de forma repetida a escala.
La misma distancia aparece cuando observamos el paso de piloto a producción. El estudio global State of AI in the Enterprise 2026 de Deloitte, basado en más de 3.200 líderes empresariales y tecnológicos de 24 países, encontró que solo el 25% de las organizaciones había conseguido llevar al menos el 40% de sus pilotos de IA a producción.
El dato tampoco significa que tres de cada cuatro proyectos hayan fracasado. Una organización puede tener muchos pilotos simultáneos, encontrarse en fases tempranas o decidir correctamente no llevar algunos a producción. Su utilidad es otra: recuerda que demostrar que una tecnología puede hacer algo es solo una parte de conseguir que una empresa pueda utilizarla de forma sostenida.
Implantar IA es convertir una tecnología en una capacidad empresarial operativa, gobernada y medible. No basta con que un modelo genere una buena respuesta. La empresa debe saber qué problema resuelve, qué datos utiliza, quién responde del resultado, qué puede hacer el sistema, qué necesita autorización, cómo se integra en el trabajo y cómo se comprobará si merece mantenerse.
Esta diferencia la hemos comprobado también desarrollando capacidades propias en R&R. Conseguir que un modelo produzca una respuesta útil puede ser relativamente rápido. Después aparecen problemas menos visibles: qué información puede considerarse válida, qué sistema conserva la verdad, quién autoriza una acción, cómo se trazan las decisiones, qué ocurre ante un error, qué proveedor conviene utilizar, cuánto cuesta operar y cómo sabemos si la nueva capacidad ha creado valor.
En otras ocasiones, incluso hemos descubierto que el problema que parecía tecnológico no estaba realmente en el modelo. Estaba en los datos, el proceso, la cobertura de información o la forma de tomar la decisión.
Ese aprendizaje cambia la pregunta de partida.
La pregunta correcta no es “¿qué proveedor de IA necesitamos?”
Antes conviene responder otra:
¿Qué capacidad no tiene hoy nuestra empresa para conseguir que esta implantación produzca un resultado?
En R&R utilizamos el Marco R&R de capacidad para implantar IA, un marco de decisión basado en cuatro dimensiones: claridad empresarial, estandarización, complejidad de integración y capacidad de gobierno. No constituye una puntuación automática ni determina por sí solo qué proveedor contratar. Sirve para separar problemas que suelen mezclarse cuando una empresa empieza a hablar de IA.
El marco no elige proveedor por ti
Su función es identificar dónde está la carencia. Si falta claridad empresarial, el problema todavía no es principalmente tecnológico. Si la solución existe y está estandarizada, quizá basta con comprarla. Si hay mucha complejidad técnica, integración gana peso. Y si nadie puede gobernar transversalmente la implantación, aparece un problema de dirección.
El marco R&R separa cuatro dimensiones que suelen mezclarse cuando una empresa decide implantar IA: claridad sobre el resultado empresarial, grado de estandarización del problema, complejidad técnica de la integración y capacidad interna para gobernar la implantación.
Marco de gestión de R&R. No asigna automáticamente un tipo de proveedor ni presupone que una empresa necesite apoyo externo. Su función es identificar qué capacidad está limitando la implantación antes de decidir cómo cubrirla.
El resto del artículo utilizará este marco para distinguir qué resuelve realmente cada alternativa. Veremos cuándo tiene sentido una consultora, cuándo el problema exige integración tecnológica, cuándo comprar software es mejor que construir, cuándo aparece una necesidad de dirección y por qué una implantación seria puede requerir varias de estas capacidades al mismo tiempo.
Después entraremos en una segunda capa menos visible pero igual de importante: dependencia de proveedores, datos, paso de piloto a producción, costes, autonomía, supervisión humana y responsabilidad sobre el resultado.
No necesitas encontrar primero quién sabe más de IA. Necesitas saber qué capacidad falta para convertirla en resultado empresarial.
2.1. Primera dimensión: claridad empresarial
“Queremos utilizar IA” no define un objetivo.
Tampoco lo define suficientemente “queremos automatizar administración”, “queremos vender más” o “queremos mejorar atención al cliente”.
Una implantación empieza a adquirir forma cuando la empresa puede describir qué resultado quiere modificar y qué proceso lo produce actualmente.
Por ejemplo:
- reducir el tiempo necesario para clasificar y revisar determinada documentación;
- aumentar el número de cuentas que un equipo comercial puede investigar con suficiente calidad;
- reducir el tiempo dedicado a preparar un cierre financiero;
- mejorar la velocidad con la que se detectan desviaciones relevantes;
- reducir tareas manuales de soporte sin deteriorar calidad;
- o aumentar la capacidad de una función sin incorporar proporcionalmente más estructura.
Cuanto menos claro esté este punto, menos útil resulta discutir todavía si necesitamos GPT, agentes, RAG, automatizaciones o una plataforma concreta.
Existe cuando la empresa puede explicar qué resultado quiere modificar, qué ocurre hoy, qué parte del proceso debería cambiar y qué evidencia permitiría concluir que la nueva capacidad merece mantenerse.
2.2. Un caso de uso no es todavía un business case
También conviene distinguir entre identificar algo que la IA puede hacer y justificar que merece implantarse.
Un modelo puede resumir documentos.
La cuestión empresarial es cuántos documentos existen, cuánto trabajo humano consume hoy esa actividad, qué errores importan, qué nivel de revisión seguirá siendo necesario, cuánto costará operar la solución y qué se hará con la capacidad liberada.
Sin estas preguntas podemos demostrar una capacidad técnica y seguir sin saber si existe una inversión razonable detrás.
“La IA puede hacerlo” no responde todavía “¿merece la pena hacerlo?”
La viabilidad técnica es una condición. El business case necesita incorporar volumen, impacto, coste, riesgo, intervención humana, mantenimiento y el valor real de modificar el proceso.
Este punto conecta con un problema que ya analizamos en nuestro artículo sobre por qué tantas empresas fallan al implantar IA: empezar desde la herramienta facilita producir pilotos, pero no necesariamente construir una secuencia clara entre problema, proceso, capacidad y resultado.
2.3. Segunda dimensión: estandarización
La siguiente pregunta es si el problema necesita realmente una solución específica.
Muchas necesidades empresariales son mucho menos singulares de lo que parecen.
Capturar notas de reuniones, transcribir conversaciones, recuperar documentos, clasificar determinados textos, redactar primeros borradores o asistir en ciertas tareas de productividad son problemas sobre los que ya existe una oferta considerable.
En esos casos, la decisión de construir debería demostrar qué diferencia relevante no puede cubrir razonablemente una solución disponible.
Mide hasta qué punto el problema que queremos resolver se parece a una necesidad ya resuelta de forma suficientemente madura por el mercado. Cuanto mayor sea, más fuerte debería ser la razón necesaria para justificar desarrollo específico.
2.4. Diferenciarse no significa construir todo
Una empresa puede tener procesos diferenciales y seguir utilizando componentes estándar para una parte importante de su arquitectura.
Un CRM estándar no hace que todas las empresas vendan igual. Un ERP estándar no hace que operen igual. Del mismo modo, utilizar modelos, bases de datos, herramientas o aplicaciones de terceros no elimina necesariamente aquello que diferencia a la empresa.
La ventaja puede estar en:
- los datos;
- las reglas;
- el proceso;
- la integración;
- el contexto acumulado;
- la experiencia del usuario;
- la velocidad de decisión;
- o la forma en que distintas piezas se combinan.
La ventaja competitiva puede estar en el sistema, no en cada componente
Utilizar tecnología estándar no obliga a estandarizar toda la forma de trabajar. La decisión es qué partes conviene comprar porque son commodities y cuáles merece diseñar porque contienen conocimiento, proceso o capacidad diferencial.
2.5. Tercera dimensión: complejidad de integración
Una solución puede parecer sencilla mientras vive en una demo y volverse mucho más compleja cuando debe utilizar información real y actuar dentro de un proceso empresarial.
La dificultad aumenta cuando debe responder preguntas como estas:
- ¿De dónde obtiene los datos y cuál es la fuente autoritativa?
- ¿Qué información puede ver cada usuario?
- ¿Puede escribir o modificar datos en otros sistemas?
- ¿Qué aplicaciones debe consultar o actualizar?
- ¿Cómo conserva contexto entre sesiones y procesos?
- ¿Qué ocurre si una API, modelo o proveedor no responde?
- ¿Qué debe registrarse para poder reconstruir después una decisión?
- ¿Cómo se separan empresas, usuarios, proyectos o permisos?
- ¿Qué parte puede resolverse mediante reglas y qué parte necesita realmente un modelo?
Estas preguntas explican por qué un prototipo aparentemente sencillo puede necesitar bastante arquitectura cuando entra en producción.
Y también por qué un buen integrador aporta valor incluso aunque la empresa ya haya elegido modelo o software.
No depende solo del número de aplicaciones conectadas. Aumenta con la cantidad de datos, permisos, reglas, estados, excepciones, acciones y responsabilidades que la nueva capacidad debe respetar para operar de forma fiable.
2.6. Cuarta dimensión: capacidad de gobierno
Esta es probablemente la dimensión que con más facilidad se confunde con tecnología.
Supongamos que la empresa ha identificado cinco casos de uso razonables. Dos afectan a ventas, uno a finanzas, otro a operaciones y otro a atención al cliente. Existen distintos proveedores y cada iniciativa tiene costes, datos, riesgos y dependencias diferentes.
La pregunta deja de ser únicamente quién puede construir cada solución.
Alguien debe decidir:
- qué se hace primero;
- qué se descarta;
- qué proceso debe cambiar;
- qué nivel de autonomía se acepta;
- quién responde del resultado;
- qué presupuesto merece cada iniciativa;
- qué proveedor debe resolver cada parte;
- qué métricas determinan si se continúa;
- y cuándo deja de tener sentido invertir.
Estas decisiones no desaparecen por contratar especialistas.
Al contrario: cuantos más actores participan, más importante puede volverse la capacidad para gobernar el conjunto.
Es la capacidad de la organización para asignar prioridad, autoridad, recursos, límites, métricas y responsabilidad a la implantación, coordinar las partes implicadas y cambiar o detener decisiones cuando la evidencia lo exige.
2.7. Tener un sponsor no significa tener ownership operativo
Una empresa puede tener un CEO convencido de que la IA es estratégica y seguir careciendo de alguien capaz de dirigir la implantación en el día a día.
Apoyar una iniciativa no equivale a disponer de capacidad para revisar procesos, resolver conflictos entre departamentos, negociar prioridades con tecnología, controlar proveedores, revisar métricas y tomar decisiones cuando aparecen excepciones.
Por eso conviene distinguir:
- Apoya la iniciativa.
- Facilita presupuesto o legitimidad.
- Desbloquea decisiones relevantes.
- Puede intervenir en momentos clave.
- Prioriza continuamente.
- Coordina áreas y proveedores.
- Resuelve trade-offs.
- Controla métricas y resultados.
- Toma decisiones sobre continuidad.
2.8. Las cuatro dimensiones cambian qué deberías contratar
El valor del marco aparece cuando cruzamos las variables.
Una empresa con baja claridad empresarial y buena capacidad interna de gobierno puede necesitar principalmente apoyo consultivo.
Otra puede tener perfectamente claro qué quiere conseguir y disponer de un owner sólido, pero enfrentarse a una integración técnicamente compleja. Ahí gana peso el integrador.
Una tercera puede descubrir que el problema está prácticamente resuelto por software existente y que no existe ninguna razón suficiente para desarrollar nada.
Y otra puede tener tecnología, especialistas y varios proyectos en marcha, pero seguir necesitando capacidad directiva para que todo ello forme un sistema coherente.
| Situación dominante | Qué falta principalmente | Capacidad que gana peso |
|---|---|---|
| Baja claridad sobre problema, prioridad o retorno | Diagnóstico y criterio empresarial. | Consultoría / dirección. |
| Problema claro y altamente estandarizado | Funcionalidad. | Software. |
| Problema claro pero fuerte dependencia de sistemas y datos propios | Arquitectura e integración. | Integrador. |
| Múltiples iniciativas, proveedores y áreas sin owner transversal | Gobierno y decisión. | Dirección externa o refuerzo directivo interno. |
| Todas las capacidades están suficientemente cubiertas internamente | No existe una carencia externa crítica. | Equipo interno. |
2.9. El diagnóstico también evita sobredimensionar la implantación
Identificar la capacidad que falta no sirve únicamente para evitar comprar demasiado poco.
También evita comprar demasiado.
No todo proyecto necesita una gran transformación, una arquitectura específica, un programa corporativo de IA o una nueva capa de dirección.
Puede ocurrir que la respuesta correcta sea simplemente adquirir una licencia, configurar una herramienta, conectarla con dos sistemas y asignar un responsable interno.
La sofisticación no debería medirse por la cantidad de componentes de la solución, sino por lo bien que responde al problema con el mínimo coste y complejidad necesarios.
La mejor arquitectura puede ser la que evita arquitectura innecesaria
Una implantación madura no intenta maximizar software, consultoría, integración o gobierno. Busca la combinación mínima de capacidades que permite alcanzar el resultado con suficiente calidad, control y sostenibilidad.
2.10. El orden correcto reduce buena parte de la confusión
En lugar de empezar comparando proveedores, podemos ordenar la decisión así:
¿Qué parte de esta implantación no puede resolver suficientemente bien nuestra organización con la capacidad que ya tiene?
Una vez contestada esa pregunta podemos empezar a evaluar cada alternativa con más precisión.
La primera es la consultoría: cuándo aporta una capacidad que realmente falta y cuándo otro diagnóstico o roadmap puede convertirse simplemente en una nueva capa entre la empresa y la ejecución.
Antes de comparar proveedores, compara tu problema con las capacidades que ya existen dentro de tu empresa.
3. Cuándo necesitas una consultora de IA
Una consultora de inteligencia artificial aporta especialmente valor cuando la empresa todavía necesita entender qué debería hacer antes de decidir cómo hacerlo.
Puede existir interés, presupuesto e incluso presión para avanzar, pero seguir abiertas preguntas fundamentales: qué procesos ofrecen una oportunidad real, qué casos deberían priorizarse, cuánto valor podrían generar, qué riesgos introducen o qué capacidades necesitará la organización para llevarlos a producción.
En ese contexto, empezar directamente por una herramienta o un desarrollo puede ser prematuro.
3.1. Consultoría tiene sentido cuando todavía existe demasiada incertidumbre empresarial
Hay empresas que llegan a una implantación con una necesidad concreta: quieren automatizar una fase determinada, integrar información de varios sistemas o resolver un problema operativo claramente identificado.
Otras empiezan bastante antes.
Saben que la IA puede modificar su sector o ampliar capacidad, pero todavía necesitan responder preguntas como:
- ¿En qué procesos existe realmente una oportunidad suficientemente relevante?
- ¿Qué casos de uso deberían ir primero y cuáles deberían esperar?
- ¿Qué problema empresarial intenta resolver cada iniciativa?
- ¿Qué impacto económico o de capacidad esperamos obtener?
- ¿Qué datos, personas y sistemas serán necesarios?
- ¿Qué riesgos, dependencias o cambios organizativos aparecerán?
- ¿Qué debería comprar la empresa y qué puede necesitar desarrollar?
- ¿Qué modelo de gobierno necesita la implantación?
Estas preguntas son previas a buena parte de la ejecución técnica.
Si no están suficientemente resueltas, construir más rápido puede significar simplemente llegar antes a una solución que la empresa todavía no sabe si debería querer.
Una consultora de IA ayuda principalmente a analizar, definir, priorizar y diseñar cómo debería utilizar una empresa la inteligencia artificial: qué problemas merece resolver, qué business case existe, qué capacidades necesita y cómo debería organizar la transformación.
3.2. Identificar casos de uso no debería convertirse en hacer una lista de posibilidades
Uno de los ejercicios más habituales consiste en identificar oportunidades de IA por departamentos.
Ventas puede tener diez. Marketing, ocho. Finanzas, seis. Operaciones, doce.
El resultado puede ser una lista extensa y aparentemente estratégica que, sin embargo, todavía no ayuda mucho a decidir.
Porque una empresa no tiene que saber únicamente qué podría automatizar o aumentar con IA. Necesita distinguir:
- qué problema es suficientemente importante;
- qué volumen de trabajo existe detrás;
- qué impacto podría producir;
- qué datos están disponibles;
- qué coste y dificultad implica;
- qué riesgo introduce;
- y qué capacidad de ejecución necesita después.
Un inventario de oportunidades no es todavía una estrategia de IA
Cuantos más casos de uso aparecen, más importante se vuelve priorizar. Una empresa puede identificar cincuenta posibilidades razonables y seguir sin saber en cuáles debería invertir primero sus recursos.
3.3. Un roadmap útil debería reducir incertidumbre, no aplazar decisiones
El roadmap es otro resultado típico de una intervención consultiva.
Puede ser muy valioso si transforma una ambición difusa en una secuencia clara de decisiones, dependencias, pilotos, métricas y capacidades necesarias.
Pero también puede convertirse en una capa intermedia que pospone la parte más difícil: ejecutar.
Un buen roadmap debería dejar suficientemente claras cuestiones como:
| Pregunta | Qué debería aclarar el roadmap |
|---|---|
| ¿Qué hacemos primero? | Prioridades y secuencia, no solo una lista de casos de uso. |
| ¿Por qué? | Hipótesis de valor, impacto esperado y relación con objetivos empresariales. |
| ¿Qué necesitamos? | Datos, procesos, personas, tecnología, proveedores y cambios organizativos. |
| ¿Quién responde? | Ownership y responsabilidades suficientemente explícitas. |
| ¿Cómo sabremos si funciona? | Métricas, baseline y evidencia necesaria para continuar o detenerse. |
| ¿Qué ocurre después? | Cómo pasa la iniciativa de prueba a operación, mantenimiento y evolución. |
Puede definir muy bien qué debería ocurrir. La implantación empieza cuando alguien transforma esa secuencia en procesos, decisiones, tecnología, responsabilidades y resultados que continúan funcionando después de terminar el análisis.
3.4. La consultoría puede aportar también operating model y gobierno
Sería incorrecto reducir una consultora a estrategia y presentaciones.
Las mejores intervenciones pueden ayudar a diseñar cómo debería operar la empresa con IA: qué roles necesita, dónde reside la autoridad, cómo se organizan los equipos, qué controles deben existir o cómo deberían coordinarse negocio y tecnología.
Esta dimensión está ganando importancia porque muchas organizaciones están descubriendo que desplegar herramientas sin modificar suficientemente workflows, responsabilidades y formas de decidir limita la capacidad de escalar la IA.
El problema aparece cuando esa capa de diseño no encuentra después una autoridad o capacidad ejecutiva capaz de convertirla en operación.
Consultoría y dirección pueden solaparse, pero no son necesariamente lo mismo
Una consultora puede diseñar el operating model, las prioridades y el gobierno. Dirección implica además asumir de forma continuada decisiones, trade-offs, coordinación y seguimiento del resultado durante la implantación.
3.5. Cuándo una consultora puede no ser suficiente
La consultoría empieza a quedarse corta cuando la incertidumbre principal ya no está en qué hacer.
Por ejemplo, si:
- el caso de uso está suficientemente definido pero hay que construirlo;
- la dificultad principal está en integrar datos y sistemas;
- el roadmap existe pero nadie lo está ejecutando;
- la organización necesita resolver decisiones cada semana, no diseñarlas una vez;
- el problema está en adopción, operación o mantenimiento;
- o la empresa necesita ownership ejecutivo continuado sobre distintos proveedores y áreas.
En esos escenarios puede seguir siendo útil apoyo consultivo, pero probablemente no cubre por sí solo toda la capacidad necesaria.
- No está suficientemente claro qué hacer.
- Existen demasiados casos posibles y poca prioridad.
- Falta business case o modelo de transformación.
- Hay que diseñar operating model o gobierno.
- Debe compararse build, buy o partner.
- Hay que construir o integrar.
- La prioridad ya está clara.
- Falta ownership continuado.
- El problema principal está en ejecución.
- Hay que operar y mantener la solución.
3.6. Qué deberías pedir antes de contratar una consultora de IA
La pregunta no debería ser únicamente qué experiencia tiene con modelos o herramientas.
Conviene entender qué tipo de incertidumbre ayudará a reducir y qué quedará preparado para actuar después.
- ¿Qué decisiones concretas podremos tomar al terminar la intervención?
- ¿Cómo se priorizarán los casos de uso?
- ¿Cómo se estimará valor, coste y riesgo?
- ¿Qué parte del trabajo llegará hasta diseño y qué parte hasta implantación?
- ¿Quién será responsable de ejecutar después las recomendaciones?
- ¿Cómo se transferirá el conocimiento generado?
- ¿Existe independencia suficiente respecto a fabricantes o soluciones concretas?
- ¿Qué evidencia tendría que hacernos abandonar una recomendación inicial?
Cuando el principal déficit está en entender, priorizar y diseñar la transformación antes de ejecutarla. Si ya sabes suficientemente bien qué necesitas y el verdadero reto es construirlo, conectarlo o gobernar su implantación diaria, probablemente necesitarás además otra capacidad.
Una consultora puede ayudarte a tomar una mejor decisión. No confundas esa mejora de decisión con haber ejecutado todavía la decisión.
4. Cuándo necesitas un integrador tecnológico
Hay un momento en el que la discusión sobre IA deja de ser principalmente estratégica y se convierte en una cuestión de arquitectura.
La empresa sabe qué quiere conseguir. El proceso está suficientemente definido. Incluso puede haber elegido software, modelos o proveedores.
Pero la solución tiene que funcionar con datos reales, usuarios reales, permisos reales y sistemas que no fueron diseñados pensando en ella.
Ahí aparece el trabajo de integración.
4.1. El integrador convierte una solución aislada en una capacidad conectada
Una herramienta de IA puede generar una respuesta excelente utilizando un documento cargado manualmente.
La implantación real puede exigir bastante más.
Quizá ese documento debe recuperarse automáticamente desde un repositorio, asociarse al cliente correcto, respetar permisos, cruzarse con información del ERP, guardar el resultado, registrar qué versión del modelo intervino y solicitar autorización humana antes de modificar ningún dato.
Ninguna de esas cuestiones mejora necesariamente la inteligencia del modelo.
Pero todas pueden determinar si la solución sirve para operar.
Un integrador convierte una solución suficientemente definida en una arquitectura capaz de funcionar dentro de los datos, aplicaciones, identidades, permisos, procesos e infraestructura reales de la empresa.
4.2. La integración no consiste únicamente en conectar APIs
Las APIs son una parte visible del problema, pero muchas de las decisiones difíciles aparecen alrededor.
| Dimensión | Pregunta que debe resolver |
|---|---|
| Datos | ¿Qué información puede utilizar el sistema, de dónde procede y cuál es la fuente que debe prevalecer? |
| Identidad | ¿Quién es el usuario y a qué información o acciones tiene derecho? |
| Permisos | ¿Qué puede consultar, preparar, modificar o ejecutar cada actor? |
| Estado | ¿Cómo conserva la solución contexto e información entre interacciones? |
| Integraciones | ¿Qué sistemas debe leer, actualizar o coordinar? |
| Trazabilidad | ¿Podemos reconstruir qué datos, reglas, modelos y decisiones produjeron un resultado? |
| Errores | ¿Qué ocurre cuando falla un modelo, una API, un dato o una dependencia? |
| Operación | ¿Quién mantiene, monitoriza, actualiza y corrige la capacidad una vez desplegada? |
Cuantas más de estas dimensiones intervienen, menos útil resulta evaluar una solución únicamente por la calidad de la respuesta que produce el modelo.
Una demo reduce deliberadamente gran parte de la complejidad
Eso es precisamente lo que la hace útil: permite comprobar rápidamente una hipótesis. El error aparece cuando interpretamos el éxito del camino feliz como evidencia de que también están resueltos permisos, excepciones, estado, seguridad, costes, mantenimiento y recuperación ante fallos.
4.3. En nuestros propios desarrollos, la respuesta del modelo suele ser solo el principio
Al desarrollar capacidades propias en R&R hemos encontrado repetidamente el mismo patrón.
Conseguir que un modelo interprete correctamente un texto, proponga una respuesta o extraiga determinada información puede resolverse relativamente pronto.
Después aparecen preguntas más difíciles:
- ¿esa información es un hecho o una inferencia?
- ¿qué fuente tiene autoridad si dos datos se contradicen?
- ¿puede la IA modificar el estado o únicamente preparar una propuesta?
- ¿qué acciones necesitan aprobación?
- ¿cómo se conserva el histórico sin depender de la memoria del modelo?
- ¿qué ocurre si cambia el proveedor?
- ¿qué parte puede validarse con lógica determinista?
- ¿cómo sabemos después qué ocurrió realmente?
La calidad del modelo importa, pero una capacidad empresarial necesita además memoria fiable, datos gobernados, reglas, permisos, trazabilidad, integración, control de costes y mecanismos para ejecutar y verificar acciones.
4.4. El LLM no debería convertirse por defecto en la base de datos
Una de las simplificaciones más peligrosas consiste en pedir al modelo que recuerde, interprete y decida sobre información que debería vivir en sistemas estructurados.
Los modelos generativos son especialmente útiles interpretando lenguaje, contexto, ambigüedad y problemas que no pueden resolverse bien con reglas rígidas.
Eso no significa que deban convertirse en:
- la base de datos de la empresa;
- la fuente autoritativa de estado;
- el repositorio de permisos;
- el motor de reglas críticas;
- o el único mecanismo para reconstruir por qué ocurrió una decisión.
El LLM puede interpretar lenguaje y ayudar a razonar. La verdad operativa, las reglas críticas y el estado deberían residir donde puedan gobernarse y verificarse.
Esto no es únicamente una cuestión de arquitectura elegante.
Afecta a fiabilidad, auditabilidad, capacidad de recuperación y dependencia de proveedores.
4.5. Tampoco todo necesita un LLM
Otra decisión de integración consiste en identificar qué parte del proceso necesita realmente inteligencia generativa.
Si una comprobación puede resolverse de forma segura mediante una regla, una consulta estructurada o un cálculo determinista, añadir un modelo puede introducir coste y variabilidad sin aportar suficiente valor.
Una arquitectura empresarial puede combinar:
- reglas;
- software convencional;
- consultas estructuradas;
- cálculos;
- búsqueda;
- automatización;
- modelos pequeños;
- modelos de mayor capacidad;
- y decisión humana.
El mérito no está en utilizar IA en el máximo número posible de pasos.
Está en utilizarla donde mejora suficientemente el sistema.
Determinista cuando sea suficiente; IA cuando añada valor
Una implantación robusta no necesita convertir cada decisión en una llamada a un modelo. Separar cálculo, reglas, recuperación de datos e interpretación generativa puede mejorar coste, control y fiabilidad.
4.6. Un buen integrador también puede aportar diseño y arquitectura
Del mismo modo que sería incorrecto reducir una consultora a presentaciones, sería injusto presentar un integrador como una empresa que simplemente conecta sistemas siguiendo instrucciones.
Un buen integrador puede detectar limitaciones del planteamiento inicial, recomendar arquitectura, cuestionar una tecnología, diseñar seguridad, proponer alternativas y ayudar a redefinir parte de la solución.
La diferencia que utilizamos en este artículo no está en si puede pensar estratégicamente.
Está en cuál es la responsabilidad principal que la empresa necesita cubrir.
La frontera útil no es “unos piensan y otros ejecutan”. Es identificar si la incertidumbre dominante está en qué debería hacerse o en cómo conseguir que la solución funcione técnicamente dentro de la organización.
4.7. Lo que un integrador no debería tener que decidir por la empresa
Incluso el mejor especialista tecnológico necesita recibir determinadas decisiones empresariales.
Puede recomendar alternativas, explicar riesgos y advertir de costes. Pero debería existir una autoridad de negocio capaz de determinar:
- qué problema merece inversión frente a otros;
- qué resultado se considera suficientemente bueno;
- qué proceso puede modificarse;
- qué riesgo acepta la organización;
- qué nivel de autonomía tendrá la IA;
- qué presupuesto sigue siendo razonable;
- y cuándo debe detenerse el proyecto aunque técnicamente pueda continuar.
No conviertas una decisión empresarial en una decisión del proveedor técnico
Un integrador puede explicar qué es posible, cuánto cuesta y qué riesgos técnicos existen. La empresa sigue necesitando decidir si esa posibilidad merece la inversión y qué resultado justifica asumirla.
4.8. Cuándo gana claramente peso un integrador
La integración se convierte en la capacidad dominante cuando la empresa ya puede describir suficientemente bien el resultado deseado y la mayor incertidumbre está en construir una solución fiable dentro de su entorno.
- El problema está suficientemente definido.
- Existe un business owner.
- Hay que conectar varios sistemas.
- Intervienen datos o permisos complejos.
- La solución necesita arquitectura específica.
- Debe desplegarse y mantenerse en producción.
- No está claro qué problema resolver.
- No existe criterio de éxito.
- Hay demasiados casos sin priorizar.
- Nadie tiene ownership empresarial.
- El mercado ya ofrece una solución estándar suficiente.
4.9. Qué deberías pedir antes de contratar un integrador de IA
Además de experiencia técnica, conviene entender cómo quedará la capacidad después de la implantación.
- ¿Qué arquitectura propone y por qué?
- ¿Qué sistemas y datos serán dependencias críticas?
- ¿Cómo se gestionarán identidad, permisos y trazabilidad?
- ¿Qué ocurre si falla un modelo, una API o un proveedor?
- ¿Qué parte queda basada en estándares y qué parte será específica?
- ¿Cómo podremos mantener y evolucionar la solución?
- ¿Qué conocimiento se transferirá al equipo interno?
- ¿Cuánto costará operar la solución, no únicamente construirla?
- ¿Qué dependencia tendremos del integrador una vez terminada la implantación?
Cuando la empresa sabe suficientemente bien qué quiere conseguir y el principal reto está en convertir ese objetivo en una solución técnica conectada, fiable, segura, mantenible y capaz de operar dentro de sus sistemas reales.
Pero existe todavía una posibilidad que puede evitar gran parte de este trabajo.
Que la capacidad que estamos intentando construir ya exista suficientemente bien resuelta en el mercado.
Antes de diseñar una arquitectura específica conviene responder, por tanto, una pregunta bastante menos tecnológica: ¿tenemos realmente una buena razón para construir?
Que una integración sea técnicamente posible no significa que construirla sea la mejor decisión empresarial.
5. Cuándo comprar software es mejor que construir
La IA generativa ha reducido drásticamente el coste de producir prototipos, automatizaciones y primeras versiones de software.
Eso tiene una consecuencia positiva: muchas empresas pueden probar capacidades que hace pocos años habrían exigido proyectos largos y costosos.
Pero también puede crear una ilusión peligrosa: si construir parece fácil, construir parece automáticamente mejor.
No lo es.
5.1. El software gana cuando el problema ya está suficientemente resuelto
Muchas necesidades empresariales no son únicas.
Gestión documental, transcripción, notas de reuniones, determinadas tareas de CRM, firma, productividad individual, recuperación de información, atención básica, generación de contenidos o clasificación de ciertos documentos son problemas sobre los que existe cada vez más software especializado.
Si una solución disponible cubre suficientemente la necesidad, comprar puede ofrecer ventajas difíciles de igualar con un desarrollo propio:
- menor tiempo hasta utilización;
- coste inicial más bajo;
- mantenimiento compartido entre muchos clientes;
- actualizaciones continuas;
- soporte especializado;
- menos dependencia de capacidad técnica propia;
- y una salida potencialmente más sencilla si el producto deja de encajar.
Cuando el problema es suficientemente estándar y una solución existente puede resolverlo con una calidad adecuada, menor coste total y menos complejidad que construir una capacidad específica.
5.2. El coste de construir empieza donde termina la demo
Un prototipo puede hacer parecer muy barata una solución propia.
Quizá basten unos días para conectar un modelo, diseñar una interfaz básica y demostrar que una función concreta es posible.
Pero el coste relevante no es únicamente crear esa primera versión.
Después aparecen:
- mantenimiento del código;
- actualización de integraciones;
- cambios de modelos y proveedores;
- seguridad y permisos;
- monitorización;
- resolución de errores;
- soporte a usuarios;
- evolución funcional;
- compatibilidad con nuevos sistemas;
- y tiempo de producto y dirección para decidir qué debe seguir cambiando.
Ese trabajo puede estar perfectamente justificado si la capacidad es estratégica.
Lo que no conviene es ignorarlo porque la primera versión resultó sencilla de construir.
El coste de desarrollo y el coste de propiedad no son lo mismo
Una solución puede ser barata de prototipar y costosa de mantener durante años. La decisión build vs buy debería considerar el coste total de propiedad y la capacidad que la empresa tendrá que conservar para seguir evolucionándola.
5.3. Construir tiene más sentido cuando la capacidad contiene algo realmente diferencial
Eso no significa que desarrollar sea una mala decisión.
Puede ser exactamente la correcta cuando la capacidad que queremos crear depende de conocimiento, datos, procesos o decisiones que forman parte de la ventaja de la empresa.
Por ejemplo, desarrollar gana sentido cuando:
- el proceso es suficientemente específico;
- las soluciones disponibles obligan a adaptar demasiado la operación;
- la capacidad depende de datos o contexto propio difícil de trasladar a un SaaS genérico;
- la integración con sistemas existentes es profunda;
- el workflow o la lógica de decisión constituyen una parte relevante de la ventaja competitiva;
- o la economía a escala justifica asumir propiedad y mantenimiento.
- Problema ampliamente estandarizado.
- Oferta madura disponible.
- Poca necesidad de diferenciación.
- Integración limitada o estándar.
- Mantenimiento propio aporta poco valor.
- Proceso claramente diferencial.
- Datos y contexto propios son fundamentales.
- La solución estándar exige demasiados compromisos.
- La integración forma parte central de la capacidad.
- La propiedad de la lógica crea valor estratégico.
5.4. Resolver una parte del problema no obliga a construir todo el sistema que la rodea
Este es un aprendizaje que aparece con frecuencia cuando desarrollamos capacidades propias en R&R.
Una función puede necesitar determinados datos de otro proceso sin que eso signifique que debamos construir también todo ese proceso.
ABACKIA, por ejemplo, necesita comprender determinadas evidencias relacionadas con nóminas para construir una visión financiera correcta: importes, retenciones, pagos, costes cuando están disponibles y su impacto sobre la caja.
Pero necesitar esa información no convierte a ABACKIA en un software laboral, un sistema de nóminas o una plataforma de recursos humanos.
Construir esas capacidades adicionales aumentaría alcance, mantenimiento, riesgo y complejidad sin mejorar necesariamente el problema financiero que queremos resolver.
Que una capacidad necesite información procedente de otro sistema no significa que deba sustituir ese sistema. Una arquitectura puede integrar, importar o interpretar únicamente lo necesario y preservar el resto como responsabilidad de herramientas especializadas.
5.5. Comprar software tampoco significa que la implantación esté resuelta
Aquí aparece el error contrario.
Una empresa selecciona una herramienta adecuada, compra licencias y considera que la capacidad ya está incorporada.
Puede no ser así.
Después siguen abiertas cuestiones como:
- quién debe utilizarla;
- en qué parte del proceso;
- qué trabajo anterior deja de hacerse;
- qué información debe conectarse;
- qué reglas de uso existen;
- cómo se mide adopción;
- qué resultado esperamos obtener;
- y cuándo debemos concluir que la herramienta no está creando suficiente valor.
Comprar software puede resolver la tecnología y dejar intacto el problema empresarial.
Una herramienta adecuada dentro de un proceso mal definido puede aumentar actividad, producir más información o trasladar trabajo de una persona a otra sin generar una mejora neta.
Por eso software e implantación no son sinónimos.
Comprar una herramienta resuelve el acceso a una capacidad tecnológica. Implantarla exige además integrarla en un proceso, asignar responsabilidad, modificar comportamientos cuando sea necesario y comprobar que produce un resultado empresarial suficiente.
5.6. A veces la mejor arquitectura es no construir ninguna arquitectura nueva
La sofisticación tecnológica puede convertirse fácilmente en un objetivo en sí mismo.
Agentes, RAG, orquestadores, modelos propios, automatizaciones y arquitecturas multiagente pueden ser necesarios en determinados problemas.
Pero si una herramienta existente resuelve el 90% de una necesidad no estratégica, construir un sistema específico para conseguir el 10% restante puede ser una mala asignación de recursos.
La decisión depende del valor de ese 10%.
Suficientemente bueno puede ser mejor que técnicamente perfecto
Una solución empresarial no necesita maximizar personalización. Necesita alcanzar el resultado con una relación razonable entre valor, coste, riesgo, velocidad y dependencia.
5.7. Qué deberías preguntar antes de desarrollar algo que podrías comprar
Cuando el problema está suficientemente estandarizado, existe software capaz de resolverlo con una calidad adecuada y la personalización adicional no crea una ventaja empresarial que justifique asumir más coste, mantenimiento y dependencia.
Pero incluso después de elegir correctamente software, integración o desarrollo sigue existiendo una pregunta que ninguna de esas decisiones resuelve por sí sola.
¿Quién dirige el conjunto?
Construir porque ahora es más fácil construir sigue siendo construir sin haber demostrado que deberías hacerlo.
6. Cuándo el problema no es tecnológico: necesitas dirección
Una empresa puede tener buenos proveedores, buenos especialistas y buena tecnología y seguir sin conseguir que su implantación de IA avance de forma coherente.
Puede haber pilotos en ventas, licencias en marketing, automatizaciones en operaciones, un proyecto de integración en finanzas y diferentes personas experimentando con herramientas generativas.
Cada iniciativa puede tener sentido por separado.
El problema aparece cuando nadie puede responder suficientemente bien qué debe ocurrir con el conjunto.
6.1. La tecnología puede estar disponible y seguir faltando una decisión
Imaginemos cinco proyectos de IA razonables compitiendo por el mismo presupuesto y por la atención de las mismas personas.
Uno puede ahorrar tiempo administrativo. Otro mejorar prospección. Un tercero reducir trabajo documental. Otro ayudar a atención al cliente. Y el último aumentar capacidad de análisis financiero.
Todos pueden superar un análisis técnico.
Eso no responde:
- qué iniciativa debería ir primero;
- qué impacto merece más inversión;
- qué dependencia acepta la empresa;
- qué procesos deberían cambiar;
- qué equipos pueden absorber la transformación;
- qué proyecto debería detenerse;
- o qué resultado justifica seguir invirtiendo.
Estas decisiones forman parte de la asignación de recursos y de la dirección de la empresa.
Es incorporar temporalmente capacidad directiva que la empresa necesita pero no tiene suficientemente disponible internamente para priorizar, decidir, coordinar funciones y proveedores, establecer criterios de éxito y conducir la implantación hasta resultados empresariales observables.
6.2. Dirección no significa project management
Un proyecto necesita seguimiento.
Tareas, responsables, fechas, dependencias, entregables y presupuesto deben gestionarse.
Pero controlar que se ejecuten las tareas no resuelve necesariamente qué tareas deberían existir.
- Controla tareas y hitos.
- Gestiona dependencias.
- Coordina calendarios.
- Hace seguimiento de entregables.
- Escala desviaciones.
- Decide qué merece hacerse.
- Asigna prioridades y recursos.
- Resuelve trade-offs.
- Define qué resultado es suficiente.
- Decide cuándo cambiar o detenerse.
Coordinar que se hagan las tareas no equivale a asumir la decisión de qué tareas deberían hacerse.
6.3. El verdadero problema puede estar en el operating model
La IA no solo añade una herramienta a un proceso existente.
En los casos más relevantes puede modificar:
- qué actividades realiza una persona;
- qué información recibe antes de decidir;
- qué tareas desaparecen;
- qué acciones pueden automatizarse;
- qué excepciones necesitan escalar;
- qué competencias debe conservar el equipo;
- y qué responsabilidad corresponde a cada actor.
Eso obliga a rediseñar una parte del sistema de trabajo.
Y explica por qué una organización puede desplegar herramientas y obtener mejoras individuales sin transformar todavía su capacidad empresarial.
Cuando una capacidad modifica quién hace una tarea, qué decisiones se automatizan, qué información se utiliza y dónde queda la responsabilidad, el cambio ya no es únicamente tecnológico. Afecta al operating model.
6.4. Cada proveedor puede estar haciendo bien su trabajo y faltar todavía alguien que optimice el conjunto
Este problema aparece especialmente cuando intervienen varios actores.
Una consultora puede estar optimizando la calidad del diagnóstico.
El integrador, la robustez técnica.
El fabricante de software, la adopción de su plataforma.
IT, seguridad y mantenibilidad.
El área funcional, su propio proceso.
Ninguno necesita estar actuando mal para que el sistema completo siga careciendo de una decisión común.
Optimizar cada pieza no garantiza optimizar el sistema
Cuando participan varios especialistas, alguien debe conservar la perspectiva empresarial: qué resultado se persigue, qué trade-offs se aceptan y cómo se decide entre soluciones técnicamente válidas pero económicamente diferentes.
6.5. La dirección externa cubre un vacío de ownership, no un vacío de desarrollo
Dirección externa no debería sustituir al integrador ni al especialista técnico. Su función está en otra capa: decidir prioridades, alcance, riesgo, inversión y criterios de continuidad.
- ¿Qué resultado estamos intentando conseguir y qué iniciativa tiene prioridad?
- ¿Qué proceso debe cambiar y qué parte debemos comprar, integrar o construir?
- ¿Qué decisiones puede tomar la IA y qué riesgo aceptamos?
- ¿Qué coste sigue siendo razonable y qué evidencia demuestra avance?
- ¿Cuándo debemos corregir, escalar o detener?
Dirección externa no sustituye al integrador. Resuelve un déficit de ownership y capacidad directiva, no un déficit de desarrollo tecnológico.
6.6. Cuándo NO necesitas dirección externa
No toda implantación necesita esta capa. Suele ser innecesaria cuando existe un owner interno con autoridad, disponibilidad y criterio, o cuando el proyecto es pequeño, principalmente técnico, está bien especificado o requiere poca transformación.
Dirección externa es una respuesta a una carencia concreta Si el ownership existe internamente y funciona, incorporar otra estructura directiva puede añadir coordinación sin aportar suficiente valor.
6.7. La elección deja de ser consultora o integrador o software o dirección
Una vez separadas las responsabilidades, la decisión deja de ser necesariamente excluyente: una implantación puede combinar software, integración, consultoría y dirección en proporciones distintas, o cubrir parte de esas capacidades con equipo interno.
El siguiente bloque muestra cómo se combinan sin duplicar responsabilidades.
Tener tecnología, especialistas y presupuesto no significa que alguien esté dirigiendo la transformación.
7. El error es pensar que tienes que elegir solo uno
Después de separar consultoría, integración, software y dirección resulta fácil caer en una nueva simplificación: pensar que la empresa debe escoger una de las cuatro.
En muchas implantaciones no funciona así.
Las cuatro categorías cubren responsabilidades distintas y pueden aparecer juntas, en momentos diferentes o ser asumidas parcialmente por equipos internos.
7.1. Las combinaciones más habituales
Las capas pueden combinarse de formas muy distintas. Lo importante es que cada una cubra una responsabilidad que realmente falta y que el ownership final siga siendo reconocible.
| Combinación | Cuándo encaja |
|---|---|
| Software + equipo interno | Problema y solución suficientemente estandarizados, integración limitada y ownership interno. |
| Consultoría + equipo interno | Falta diagnóstico o diseño, pero la empresa puede ejecutar y gobernar después con capacidad propia. |
| Integrador + equipo interno | El qué y el por qué están claros, pero falta resolver arquitectura, integración o despliegue. |
| Dirección externa + software | La tecnología existe, pero falta convertirla en prioridades, cambios operativos y resultados. |
| Dirección externa + integrador | Hace falta separar el gobierno empresarial de la ejecución técnica sin desconectarlos. |
| Consultoría + integrador + dirección interna | La empresa conserva ownership y compra fuera solo diagnóstico o capacidad técnica específica. |
Dirección decide qué resultado merece perseguirse y bajo qué condiciones. Integración convierte esa decisión en una capacidad técnica que pueda operar.
7.2. El equipo interno no es una quinta capa separada: puede asumir cualquiera de ellas
Esta precisión es importante.
Consultoría, integración, software y dirección describen tipos de capacidad, no necesariamente quién debe proporcionarlas.
Una organización puede tener internamente:
- estrategia y transformación;
- arquitectura e ingeniería;
- producto;
- datos;
- seguridad;
- gestión del cambio;
- y dirección del programa.
En ese caso puede necesitar únicamente tecnología de terceros.
Otra empresa puede tener exactamente el caso contrario: pocos recursos internos y necesidad de apoyarse temporalmente en varias capacidades externas.
La pregunta es qué capacidades necesita la implantación, cuáles existen ya con suficiente calidad dentro de la empresa y cuáles resulta más razonable incorporar temporal o permanentemente desde fuera.
Dirección, consultoría, integración y software cubren responsabilidades diferentes. El equipo interno puede asumir cualquiera de ellas si dispone de capacidad suficiente; los proveedores externos deberían completar las que falten, no duplicar las que ya existen.
Marco conceptual de R&R. Las capas no representan una jerarquía ni implican que toda implantación deba incluirlas todas. La combinación depende del problema, la capacidad interna y la complejidad de cada iniciativa.
7.3. Una empresa puede externalizar capacidades, pero no la responsabilidad final
Existe, sin embargo, un límite común a todas las combinaciones.
Una empresa puede contratar a especialistas para analizar, construir, operar o incluso asumir temporalmente parte de la dirección.
Pero sigue teniendo que conservar responsabilidad sobre cuestiones como:
- qué objetivo empresarial persigue;
- qué riesgos acepta;
- qué datos pueden utilizarse;
- qué decisiones está dispuesta a delegar;
- qué impacto considera suficiente;
- y qué capacidad quiere conservar una vez termine la relación externa.
Puedes externalizar capacidades. No puedes externalizar la responsabilidad empresarial final sobre lo que haces con la IA.
Esta distinción nos lleva a una cuestión que debería aparecer mucho antes de firmar con cualquier partner.
No solo qué puede hacer por nosotros.
También qué capacidad conservará la empresa cuando deje de hacerlo.
La mejor combinación de proveedores no es la que más capacidad externaliza, sino la que completa lo que falta sin vaciar a la empresa de aquello que necesita conservar.
8. Qué dependencia debes evaluar antes de elegir un proveedor de IA
Externalizar capacidad puede ser una de las formas más rápidas de avanzar.
Un partner especializado ya dispone de conocimiento, personas, herramientas y experiencia que una empresa tardaría meses o años en construir internamente.
Ese es precisamente su valor.
Pero la misma velocidad puede esconder una segunda variable: qué parte de la capacidad seguirá perteneciendo realmente a la empresa después de la implantación.
8.1. Dependencia no significa únicamente depender de un proveedor tecnológico
Cuando se habla de lock-in suele pensarse en tecnología: utilizar una nube, un modelo, una plataforma o una API que después resulta difícil sustituir.
Ese riesgo existe, pero es solo una de las formas de dependencia.
| Tipo de dependencia | Qué ocurre |
|---|---|
| Tecnológica | La capacidad depende de un modelo, plataforma, arquitectura o componente difícil de sustituir. |
| De datos | Contexto, histórico, configuraciones o conocimiento quedan almacenados de una forma poco portable. |
| Operativa | Solo el proveedor sabe desplegar, mantener, corregir o evolucionar la solución. |
| De conocimiento | Reglas, excepciones, criterios y decisiones importantes permanecen principalmente en las personas del partner. |
| De dirección | La empresa empieza a delegar también el criterio sobre qué hacer, no únicamente la capacidad para hacerlo. |
Las cinco pueden ser razonables durante determinadas fases.
El problema aparece cuando la empresa no sabe que las está asumiendo o descubre demasiado tarde cuánto costaría deshacerlas.
No significa únicamente utilizar tecnología externa. Existe cuando una parte relevante de la capacidad no puede mantenerse, evolucionarse, sustituirse o gobernarse sin continuar dependiendo del mismo tercero.
8.2. El problema no es depender. Es no saber de qué dependes
Buscar independencia absoluta sería poco realista.
Las empresas ya dependen de ERP, CRM, cloud, bancos, proveedores de comunicaciones, fabricantes de software, plataformas de pago y muchas otras infraestructuras externas.
Eliminar toda dependencia puede ser muchísimo más caro que gestionarla.
La pregunta útil es diferente:
No preguntes solo “¿dependemos de este proveedor?”. Pregunta “¿de qué dependemos exactamente, cuánto costaría cambiar y qué capacidad seguiríamos conservando si la relación terminara?”.
Eso transforma el lock-in en una decisión de gestión.
Puede haber dependencias aceptables porque el coste de evitarlas supera con claridad el riesgo.
Y otras que conviene reducir desde el principio porque afectan a conocimiento, datos, ownership o continuidad crítica.
8.3. Gartner está advirtiendo precisamente sobre este problema en determinados modelos de implantación
En septiembre de 2026, Gartner publicó una previsión específica sobre soluciones de IA agéntica construidas mediante equipos de ingeniería desplegados directamente por el proveedor —vendor forward-deployed engineering o FDE—.
Gartner prevé que, para 2028, el 70% de las empresas abandonará este tipo concreto de soluciones, señalando entre los riesgos el aumento de costes y la dificultad para evolucionarlas de manera independiente.
El alcance del dato es importante: no significa que el 70% de los proyectos de IA vaya a fracasar ni que externalizar desarrollo sea una mala decisión. Se refiere específicamente a ese modelo de entrega y a las condiciones que Gartner observa alrededor de él.
No es una predicción sobre el 70% de todos los proyectos de IA
La previsión de Gartner se limita a soluciones de IA agéntica construidas mediante vendor forward-deployed engineering. Su utilidad aquí no está en generalizar el porcentaje, sino en los factores que identifica: gobierno, ownership, transferencia de conocimiento, propiedad intelectual, valor empresarial y estrategia de salida.
La recomendación de Gartner resulta especialmente relevante porque desplaza la conversación desde “qué rápido puede construir el partner” hacia “qué estructura de relación estamos creando”.
Entre los elementos que propone definir desde el inicio aparecen:
- gobierno;
- responsabilidad sobre valor empresarial;
- propiedad intelectual;
- co-propiedad del proyecto;
- transferencia de conocimiento;
- y responsabilidades de transición o salida.
8.4. La estrategia de salida debería diseñarse antes de necesitarla
Antes de contratar un partner conviene saber qué conservaría la empresa si la relación terminara, especialmente cuando la capacidad puede volverse crítica.
- datos, histórico y reglas;
- código, configuraciones e integraciones;
- documentación y trazabilidad;
- conocimiento suficiente para operar;
- capacidad para sustituir modelo o plataforma;
- y una transición proporcionada a la criticidad de la solución.
No todas las respuestas tienen que ser “sí”, pero deberían ser conocidas antes de asumir la dependencia.
8.5. Transferir código no es lo mismo que transferir capacidad
Recibir repositorios, documentación e infraestructura no garantiza poder evolucionar una solución. Parte de la capacidad reside en entender por qué se tomaron determinadas decisiones, qué excepciones existen, cómo se evalúa el resultado y qué compromisos se aceptaron.
Transferir un sistema no significa transferir automáticamente la capacidad para entenderlo, gobernarlo y evolucionarlo.
8.6. Separar la capacidad empresarial del proveedor reduce parte del lock-in
En R&R intentamos separar, siempre que sea razonable, qué necesita hacer la capacidad de qué modelo o proveedor concreto la ejecuta. Así la identidad de la capacidad no queda unida innecesariamente a una única tecnología.
Este principio forma parte de una cuestión más amplia que desarrollamos en cómo ganar capacidad empresarial con IA sin aumentar estructura, coste ni dependencia.
La capacidad debería sobrevivir al proveedor siempre que sea razonable Diseñar contratos funcionales e interfaces más neutrales puede facilitar una transición futura. No elimina el coste de cambiar ni garantiza independencia completa.
8.7. Provider-neutral no significa provider-independent
Cambiar de modelo o proveedor puede seguir exigiendo revalidar comportamiento, formatos, seguridad, coste e integración. Una arquitectura más neutral hace la transición más gobernable; no convierte todos los proveedores en piezas intercambiables sin impacto.
8.8. La dependencia de dirección puede ser la más difícil de detectar
El lock-in no siempre es técnico. Si la empresa acaba necesitando al partner para priorizar, elegir proveedores, interpretar métricas o decidir cuándo detener una iniciativa, también ha externalizado parte de su criterio.
Un buen partner debería aumentar la capacidad de decidir de la empresa La relación puede seguir siendo valiosa sin que la organización pierda capacidad para entender y gobernar sus propias decisiones.
8.9. Qué deberías acordar antes de empezar
Cuanto más crítica y específica sea la capacidad, más importante resulta definir desde el comienzo qué ocurre durante y después de la relación.
Incluso una arquitectura con bajo lock-in puede fracasar si intentamos resolver con tecnología un problema que está en otro lugar. Y eso nos lleva a uno de los aprendizajes más útiles de nuestras propias herramientas: a veces el cuello de botella que parece estar en la IA está realmente en los datos que llegan hasta ella.
El mejor momento para diseñar una salida es cuando todavía quieres que la relación funcione durante muchos años.
9. Cuando cambiar de modelo o proveedor no resolverá el problema: los datos
Una de las decisiones más caras que puede tomar una empresa es mejorar la tecnología equivocada.
La respuesta de un modelo parece poco precisa y buscamos uno más potente. Una búsqueda devuelve pocas oportunidades y aumentamos consultas. Un agente no encuentra determinados casos y asumimos que necesita mejores instrucciones.
Puede ser cierto.
Pero también puede ocurrir que el problema esté antes.
9.1. Lo aprendimos construyendo una capacidad de descubrimiento de empresas
Durante el desarrollo de SELQIA, nuestra capacidad orientada a descubrir, investigar y priorizar empresas objetivo, una parte inicial del problema parecía bastante tecnológica.
Había que decidir cómo buscar, qué proveedores utilizar, qué modelos ofrecían suficiente calidad, cuánto costaba cada consulta y cómo evitar consumir recursos innecesariamente.
Todo eso era real.
Pero apareció una limitación más fundamental.
Si el conjunto inicial de empresas que el sistema puede considerar no contiene suficientes candidatas relevantes, mejorar el modelo que evalúa ese conjunto no resuelve la falta de cobertura.
La pregunta dejó de ser únicamente “¿qué modelo encuentra o evalúa mejor?” y pasó a ser “¿tenemos un universo suficientemente amplio, identificable y verificable para que la búsqueda pueda encontrar lo que realmente necesitamos?”.
9.2. Un sistema no puede recomendar aquello que nunca llegó a considerar
Esta limitación parece obvia cuando se formula de manera explícita.
Pero puede resultar difícil de detectar cuando la salida final la genera un modelo capaz de producir respuestas convincentes.
Imaginemos que queremos encontrar las mejores empresas para un determinado objetivo comercial.
El modelo recibe cien candidatas, las analiza correctamente y selecciona las diez mejores.
La respuesta puede ser excelente dentro de ese conjunto.
Pero si las compañías realmente más interesantes nunca estuvieron entre esas cien, la calidad del razonamiento no corrige la falta de cobertura.
Una IA puede razonar muy bien sobre un universo incompleto y seguir produciendo una mala decisión empresarial.
9.3. Calidad de modelo y calidad de información son problemas distintos
La diferencia importa porque cada problema exige una inversión diferente.
| Si el cuello de botella está en… | Mejorar el modelo puede… | Pero probablemente necesitas trabajar sobre… |
|---|---|---|
| Calidad de razonamiento | Mejorar interpretación, síntesis o capacidad de resolver el problema. | Modelo, prompts, contexto o herramientas. |
| Cobertura de datos | Analizar mejor lo que ya existe. | Fuentes, adquisición, identidad y cobertura. |
| Calidad de datos | Intentar compensar inconsistencias. | Normalización, validación, procedencia y autoridad. |
| Diseño del proceso | Optimizar una parte del workflow. | Secuencia, responsabilidades, excepciones y decisiones. |
| Gobierno | Producir mejores recomendaciones. | Ownership, permisos, métricas y autoridad. |
La misma confusión puede aparecer en muchas funciones.
Un asistente financiero puede fallar porque el documento no contiene la información necesaria.
Una herramienta comercial puede priorizar mal porque el CRM contiene oportunidades que deberían haberse cerrado hace meses.
Un sistema de atención puede responder de forma inconsistente porque distintas fuentes internas contienen versiones contradictorias de la misma política.
En estos casos, cambiar de modelo puede modificar la salida sin resolver la causa.
Cuando la restricción principal está en la cobertura o calidad de los datos, el diseño del proceso, la integración, el gobierno o la adopción. Un modelo mejor puede mejorar su parte del sistema sin corregir aquello que limita el resultado completo.
9.4. En SELQIA tuvimos que cambiar el orden de la arquitectura
El aprendizaje nos llevó a modificar la forma de plantear la capacidad.
En lugar de depender principalmente de búsquedas externas realizadas en cada consulta, empezamos a construir una base reutilizable de observaciones de mercado procedentes de distintas fuentes.
La lógica pasó a priorizar:
La consecuencia económica también es importante.
Buscar constantemente puede parecer barato si observamos únicamente el precio de cada llamada.
Pero una llamada barata que no descubre ninguna empresa útil sigue teniendo poco valor.
Por eso empezamos a observar el coste desde otra perspectiva: cuánto cuesta conseguir una candidata o un descubrimiento realmente útil, no únicamente cuánto cuesta utilizar una API.
Optimizar coste no significa minimizar llamadas
La unidad económica relevante debería acercarse al resultado útil. Un sistema puede realizar menos llamadas y producir peores resultados, o gastar más en una fase concreta y reducir el coste total porque mejora significativamente la calidad de las decisiones posteriores.
9.5. Este aprendizaje cambia también cómo deberías evaluar a un proveedor
Cuando una empresa pide una propuesta de IA suele preguntar qué modelos utiliza el proveedor, qué precisión consigue o qué automatizaciones puede construir.
Son preguntas razonables.
Pero deberían acompañarse de otras:
- ¿qué datos necesita la solución para funcionar?
- ¿de dónde procederán?
- ¿qué cobertura tienen?
- ¿cómo se resolverán duplicados o contradicciones?
- ¿qué información es suficientemente fiable y cuál es solo una inferencia?
- ¿qué ocurre cuando falta un dato crítico?
- ¿qué puede reutilizarse en lugar de volver a generarse?
- ¿y cómo sabremos si el problema de calidad está realmente en el modelo?
Cambiar de modelo no corrige un problema de datos. Comprar software no corrige un problema de proceso. Añadir integración no corrige un problema de dirección.
9.6. Los datos tampoco deberían convertirse en una excusa para no avanzar
Existe también el riesgo contrario.
Una empresa puede concluir que sus datos nunca estarán suficientemente limpios y aplazar indefinidamente cualquier implantación.
No hace falta disponer de información perfecta.
Hace falta saber qué calidad necesita cada decisión.
Una recomendación exploratoria puede tolerar más incertidumbre que una decisión financiera irreversible. Una clasificación preliminar puede trabajar con información incompleta si después existe una revisión. Una acción automática puede necesitar requisitos mucho más estrictos.
No todas las capacidades requieren datos perfectos. El nivel de evidencia debería ser proporcional al impacto de equivocarse y a la posibilidad de detectar, revisar o revertir el resultado.
9.7. La lección no es tecnológica
SELQIA nos obligó a cambiar arquitectura, pero el aprendizaje es más amplio.
Una empresa debería resistir la tentación de invertir inmediatamente en la parte más visible del problema.
Si una capacidad no produce el resultado esperado, primero conviene localizar la restricción.
- el modelo;
- los datos;
- la cobertura;
- la identidad;
- el proceso;
- la integración;
- los permisos;
- la adopción;
- la economía;
- o la forma en que la empresa toma decisiones.
Antes de comprar más inteligencia, comprueba que no estés intentando compensar con ella la falta de información, proceso o dirección.
10. Qué debe ser capaz de llevar a producción un proveedor de IA
Una demostración responde a una pregunta muy valiosa: ¿puede esta tecnología hacer algo suficientemente parecido a lo que necesitamos?
Una implantación empresarial tiene que responder muchas más.
¿Puede hacerlo repetidamente? ¿Con datos reales? ¿Para distintos usuarios? ¿Con permisos? ¿Cuando faltan datos? ¿Cuando el modelo se equivoca? ¿Cuando cae una integración? ¿A un coste sostenible? ¿Y produciendo un resultado que la empresa pueda medir?
Entre ambas situaciones existe buena parte del trabajo que explica por qué algunas pruebas prometedoras nunca llegan a convertirse en capacidad operativa.
10.1. Una demo reduce deliberadamente la realidad
Eso no es un defecto.
Es precisamente su función.
Una buena prueba elimina complejidad para comprobar rápidamente si una hipótesis merece seguir explorándose.
Puede trabajar con:
- un conjunto reducido de datos;
- usuarios conocidos;
- un camino feliz;
- revisión manual intensiva;
- pocas excepciones;
- una única integración;
- o costes que todavía no importan demasiado por el bajo volumen.
El error aparece cuando trasladamos automáticamente ese éxito al entorno productivo.
| Una demo puede demostrar… | Producción necesita además… |
|---|---|
| Una buena respuesta | Criterios de calidad, consistencia y tratamiento de respuestas incorrectas. |
| Acceso a información | Fuentes autoritativas, identidad, permisos y trazabilidad. |
| Una automatización | Excepciones, recuperación ante errores y continuidad operativa. |
| Una acción | Límites, autorización, registro y posibilidad de verificar qué ocurrió. |
| Un modelo | Coste, disponibilidad, routing, fallback y gestión de dependencia. |
| Una interacción puntual | Estado, contexto e histórico suficientemente fiables. |
| Uso inicial | Adopción sostenida y encaje real en el proceso. |
| Actividad | Evidencia de resultado empresarial. |
10.2. En nuestras capacidades propias, los problemas difíciles suelen aparecer alrededor del modelo
El desarrollo de ABACKIA, SELQIA, SELBASE y ORVETIA nos ha mostrado repetidamente que conseguir una buena interpretación del modelo es solo una parte del problema.
Después hay que resolver qué información es válida, qué necesita autorización, qué puede ejecutarse, qué debe quedar registrado, cómo se conserva contexto, cuánto cuesta cada operación y cómo se verifica el resultado.
Un modelo puede ser inteligente y el sistema seguir siendo ingenuo.
10.3. La verdad del sistema no debería depender de lo convincente que resulte una respuesta
Los modelos generativos pueden producir lenguaje muy plausible. Por eso una capacidad empresarial debería distinguir hechos, observaciones, inferencias e incertidumbre en lugar de presentarlos con el mismo nivel de certeza.
El modelo puede interpretar y proponer. Los hechos, estados, permisos y decisiones materiales necesitan mecanismos de validación y gobierno independientes de lo convincente que resulte el lenguaje generado.
10.4. El coste también forma parte de la arquitectura
En producción, volumen, criticidad y valor económico de cada operación condicionan qué arquitectura tiene sentido. No conviene utilizar siempre el modelo más capaz ni siempre el más barato.
Reglas, lógica local, caché, modelos más económicos y modelos de mayor capacidad pueden convivir. La cuestión es gastar inteligencia donde modifica suficientemente el resultado.
Más inteligencia no siempre significa mejor sistema
La arquitectura debería optimizar el resultado completo: calidad, coste, posibilidad de validación, riesgo y valor empresarial de cada tarea.
10.5. Observabilidad técnica y resultado empresarial tampoco son lo mismo
Logs, latencia, errores, disponibilidad, tokens o coste por llamada son necesarios para operar tecnología, pero no demuestran por sí solos que la empresa haya obtenido valor.
- Ejecuciones.
- Latencia.
- Errores.
- Tokens.
- Disponibilidad.
- Coste por llamada.
- Qué trabajo desapareció.
- Qué capacidad se liberó.
- Qué decisión mejoró.
- Qué coste total cambió.
- Qué resultado aumentó.
- Si el uso se mantiene.
10.6. Una métrica de uso no demuestra valor
En un piloto, entrar en la herramienta, generar un output, dar buen feedback o declarar intención de continuar son señales útiles, pero ninguna demuestra por sí sola que la capacidad se haya incorporado ni que exista disposición real a pagar.
Login ≠ activación. Output ≠ valor. Feedback ≠ disposición a pagar. Intención ≠ conversión.
Un piloto debería probar una hipótesis empresarial, no únicamente una capacidad técnica Conviene medir activación real, impacto sobre una decisión o proceso, intervención humana, coste operativo, recurrencia y evidencia suficiente para justificar continuidad.
Esta diferencia entre actividad individual y resultado empresarial la desarrollamos también en por qué ahorrar tiempo con IA no significa necesariamente aumentar la productividad de la empresa.
10.7. Tampoco todo piloto debe acabar en producción
Abandonar una prueba puede ser una buena decisión.
Puede descubrirse que:
- el problema era menos importante de lo esperado;
- la calidad necesaria resulta demasiado cara;
- la intervención humana elimina gran parte del ahorro;
- los datos disponibles no permiten una solución suficientemente fiable;
- la adopción no justifica el cambio;
- o existe software estándar que resuelve mejor la necesidad.
El objetivo del piloto no debería ser demostrar que la idea inicial era correcta.
Debería producir evidencia para decidir si continuar.
No llevar un piloto a producción no significa necesariamente que haya fracasado
Si la prueba permite descubrir pronto que la economía, calidad, riesgo o adopción no justifican la inversión, puede haber evitado un proyecto mucho más costoso. Un buen piloto también debe permitir decidir que no merece continuar.
10.8. Producción implica saber qué ocurre cuando las cosas no salen bien
Las demos enseñan sobre todo el camino feliz. Producción debe contemplar también datos ausentes o contradictorios, APIs caídas, usuarios sin permisos, formatos inesperados y acciones que no pueden completarse.
- ¿Qué ocurre si falta un dato o una fuente contradice a otra?
- ¿Qué ocurre si falla el proveedor?
- ¿Qué puede reintentarse y qué necesita intervención humana?
- ¿Qué estado debe conservarse y cómo sabemos después qué ocurrió?
10.9. El paso a producción cambia también qué proveedor necesitas
El proveedor adecuado para demostrar una idea puede no ser suficiente para llevarla a producción. A medida que aparecen integración, gobierno, mantenimiento, seguridad, economía y adopción, conviene volver a evaluar quién debe asumir cada responsabilidad.
Probar y producir pueden requerir capacidades distintas El éxito de una primera fase debería provocar una nueva decisión, no una continuación automática con la misma arquitectura y los mismos actores.
Y todavía falta una capa decisiva: definir qué puede proponer la IA y quién autoriza, qué se ejecuta y cómo se verifica después.
La demo demuestra posibilidad. Producción exige demostrar capacidad.
11. Qué decisiones no debería delegar la empresa al proveedor ni a la IA
Una de las preguntas más importantes al implantar inteligencia artificial no es qué puede hacer técnicamente el sistema.
Es qué autoridad estamos dispuestos a concederle.
Una IA puede ser capaz de interpretar una situación, recomendar una acción, preparar un documento o incluso ejecutar una operación. Pero capacidad técnica y autoridad empresarial son cosas distintas.
11.1. Preparar, autorizar, ejecutar y verificar son decisiones diferentes
Una parte importante de los errores de diseño aparece cuando se trata todo el proceso como una única acción.
Por ejemplo: “la IA aprueba una factura”, “la IA responde al cliente”, “la IA cambia una oportunidad” o “la IA decide una prioridad”.
En realidad, muchas de esas situaciones pueden separarse en cuatro capacidades distintas:
Separar estas fases permite diseñar autonomías mucho más precisas.
Una IA puede tener capacidad para preparar una recomendación sin poder autorizarla. Puede ejecutar una acción previamente autorizada sin tener autoridad para decidir cuándo debe realizarse. Y puede ser necesario que otra capa independiente verifique que la ejecución terminó correctamente.
Un sistema puede estar técnicamente preparado para ejecutar una acción y, aun así, estar diseñado para detenerse antes hasta que una persona, una política o una condición verificable conceda autorización.
Separar PREPARE, AUTHORIZE, EXECUTE y VERIFY permite definir qué parte del trabajo puede automatizarse, dónde debe existir una decisión humana o política y cómo comprobar después que la acción terminó correctamente.
Marco operativo de R&R. No todas las capacidades necesitan las cuatro fases de forma separada ni todas requieren autorización humana. El diseño depende del riesgo, impacto, reversibilidad y nivel de evidencia disponible.
11.2. La autonomía debería crecer de forma proporcional al riesgo
No todas las acciones necesitan el mismo nivel de control.
Una IA que propone un título para una reunión puede operar con mucha más autonomía que una que modifica datos financieros, envía una comunicación externa sensible o cambia una condición contractual.
Cuatro variables ayudan a pensar esta decisión:
| Variable | Pregunta | Cuanto mayor sea… |
|---|---|---|
| Materialidad | ¿Qué impacto tendría equivocarse? | Más sentido tiene aumentar controles. |
| Irreversibilidad | ¿Podemos deshacer fácilmente la acción? | Más importante resulta autorizar antes. |
| Incertidumbre | ¿Qué calidad y evidencia tiene la decisión? | Más útil resulta escalar o revisar. |
| Impacto externo | ¿La acción afecta a clientes, proveedores, administraciones o terceros? | Mayor necesidad suele existir de control y trazabilidad. |
La cuestión no consiste en introducir aprobación humana en cada paso.
Eso podría destruir buena parte de la capacidad que intentamos crear.
Consiste en reservar la intervención humana para los puntos donde el coste potencial del error, la incertidumbre o la irreversibilidad justifican utilizar criterio adicional.
Human-in-the-loop no debería significar humano-en-todo
El objetivo es diseñar una frontera inteligente entre automatización y decisión. Si cada acción necesita revisión manual, quizá no hemos creado suficiente capacidad; si ninguna la necesita, quizá hemos concedido más autonomía de la que el riesgo permite.
11.3. Un buen sistema debería saber cuándo no tiene suficiente evidencia
Una capacidad útil no solo responde; también reconoce cuándo la evidencia es insuficiente, contradictoria o demasiado incierta para continuar automáticamente.
Saber escalar también es una capacidad El sistema debería poder distinguir cuándo puede actuar, cuándo solo recomendar y cuándo necesita derivar la decisión a una persona u otro proceso.
11.4. La persona no debería revisar mecánicamente aquello que la IA ya hizo
La supervisión humana aporta más valor cuando se concentra en excepciones, ambigüedad, decisiones materiales y situaciones nuevas, no cuando convierte a una persona en aprobador mecánico de centenares de outputs.
El objetivo es reservar capacidad humana para aquello donde el juicio cambia el resultado.
11.5. Aprender tampoco concede autoridad para cambiar las reglas
Un sistema puede detectar patrones, aprender de feedback y proponer cambios. Pero identificar que una política merece reconsiderarse no equivale a tener autoridad para modificarla automáticamente.
Cuando una regla afecta a pricing, riesgo, fiscalidad, clientes, seguridad o asignación de recursos, el aprendizaje puede convertirse en evidencia para decidir un cambio, no necesariamente en política vigente.
Aprender ≠ gobernar Un sistema puede proponer una modificación sin tener autoridad implícita para redefinir por sí mismo las reglas con las que opera.
11.6. El nivel de autonomía también modifica qué proveedor necesitas
Una solución que solo asesora exige menos infraestructura de control que otra capaz de actuar sobre sistemas empresariales. Cuanta más autonomía exista, más peso adquieren identidad, permisos, autorización, trazabilidad, recuperación ante errores y verificación.
Más autonomía no es solo una mejora funcional Puede convertir un problema de software en uno de integración o de dirección. La arquitectura y el gobierno deben evolucionar al mismo tiempo que la capacidad para actuar.
11.7. La empresa debería conservar siempre una autoridad reconocible
Incluso en sistemas con mucha automatización debería poder responderse quién tiene autoridad sobre la capacidad: quién define qué puede hacer, qué riesgo se acepta, qué métricas importan y cuándo debe modificarse o detenerse.
Cuanto más autónomo sea un sistema, más explícita debería ser la autoridad humana que define sus límites.
Si la empresa no dispone internamente de alguien capaz de asumir esas decisiones, la cuestión deja de ser solo tecnológica y vuelve a aparecer el problema de capacidad directiva.
La autonomía útil no consiste en eliminar personas de la decisión. Consiste en decidir con precisión dónde dejan de ser necesarias.
12. Cuándo sí necesitas dirección externa
Hasta aquí hemos definido qué es dirección externa y en qué se diferencia de consultoría, integración o project management.
La cuestión práctica es otra.
¿Cómo saber si tu empresa realmente necesita incorporar esa capacidad?
No existe una puntuación universal. Pero hay patrones que indican que el problema ya no está en encontrar otra herramienta o especialista.
12.1. Primera señal: tienes demasiadas oportunidades de IA y ninguna prioridad defendible
Ventas quiere un agente. Marketing quiere automatizar contenidos. Finanzas quiere análisis documental. Operaciones quiere reducir tareas manuales. Dirección quiere mejorar productividad.
Todos pueden tener una necesidad legítima.
El problema aparece cuando la empresa responde a cada oportunidad por separado sin decidir qué capacidad merece realmente recursos primero.
Si la empresa acumula casos de uso pero no puede explicar por qué uno merece inversión antes que otro, falta una decisión de asignación de recursos, no otra herramienta.
12.2. Segunda señal: ya tienes herramientas y todavía no puedes explicar el retorno
Otra señal aparece cuando la organización ha avanzado tecnológicamente más rápido que en su capacidad para evaluar resultados.
Hay licencias.
Hay usuarios.
Hay automatizaciones.
Quizá incluso existen pilotos que reciben buen feedback.
Pero no está claro:
- qué trabajo ha desaparecido;
- qué capacidad se ha liberado;
- qué coste se ha reducido;
- qué decisión ha mejorado;
- qué ingreso se ha protegido o creado;
- o qué inversión debería detenerse.
Cuando la empresa puede medir uso pero no puede conectar ese uso con un resultado empresarial, suele faltar una capa de gobierno económico y operativo sobre la implantación.
12.3. Tercera señal: negocio y tecnología están resolviendo preguntas distintas
El área de negocio pregunta por velocidad, productividad o clientes.
Tecnología pregunta por arquitectura, seguridad, datos, permisos y mantenimiento.
Ambos tienen razón.
El problema aparece cuando nadie traduce suficientemente una conversación en la otra.
Entonces pueden aparecer situaciones como:
- soluciones técnicamente impecables que resuelven problemas poco relevantes;
- ideas de negocio imposibles de operar de forma segura;
- pilotos rápidos que después no pueden integrarse;
- o discusiones interminables sobre tecnología porque el resultado empresarial no está suficientemente definido.
Cuando ambas funciones necesitan continuamente a alguien que traduzca prioridades, límites y trade-offs, puede existir una carencia de dirección transversal más que una falta de conocimiento especializado.
12.4. Cuarta señal: cada proveedor está optimizando su parte
Una empresa puede disponer de una buena consultora, un integrador competente y software adecuado.
Y aun así faltar alguien que optimice el conjunto.
El fabricante quiere aprovechar su plataforma.
El integrador busca una arquitectura mantenible.
La consultora persigue el roadmap acordado.
Seguridad reduce exposición.
El área funcional quiere resultados rápidos.
La cuestión empresarial es decidir qué compromiso entre todos ellos crea más valor.
Cuando cada actor responde de una parte y no existe una persona con autoridad suficiente sobre el resultado transversal, la organización puede necesitar ownership directivo adicional.
12.5. Quinta señal: el proyecto exige cambiar procesos, no solo instalar tecnología
Cuanto más modifica una implantación la forma de trabajar, más probable es que la dificultad deje de ser exclusivamente técnica.
Si una solución implica decidir:
- qué tareas desaparecen;
- qué funciones cambian;
- qué información recibe cada rol;
- qué decisiones se automatizan;
- qué indicadores se modifican;
- o quién conserva determinadas responsabilidades;
la implantación está entrando en diseño organizativo.
Y eso necesita autoridad para intervenir sobre cómo funciona la empresa.
Cuando el valor depende de cambiar procesos, roles o decisiones, instalar correctamente la tecnología deja de ser suficiente. Alguien debe conducir también la transformación operativa.
12.6. Sexta señal: existe un sponsor, pero nadie puede dedicar suficiente capacidad
En pymes y empresas en crecimiento este escenario es especialmente habitual.
El CEO entiende la prioridad.
El director de operaciones participa.
IT ayuda.
Los responsables funcionales aportan conocimiento.
Pero todos tienen además una función principal que ya consume prácticamente toda su capacidad.
La implantación avanza entonces entre huecos, reuniones puntuales y decisiones retrasadas.
Saber qué debería hacerse no garantiza disponer de tiempo para hacerlo. Una transformación puede necesitar temporalmente más capacidad de dirección sin justificar todavía crear un nuevo puesto permanente.
12.7. Séptima señal: las decisiones importantes escalan continuamente al CEO
Existe otra forma de detectar el déficit.
Cada vez que aparece una excepción relevante, la decisión sube.
Qué proveedor.
Qué alcance.
Qué presupuesto.
Qué proceso cambia.
Qué riesgo se acepta.
Si el CEO tiene que reconstruir contexto continuamente para desbloquear la implantación, el proyecto puede estar consumiendo una capacidad que no escala.
Cuando las decisiones transversales solo pueden avanzar mediante intervención repetida de dirección general, puede ser necesario distribuir o incorporar capacidad directiva adicional antes de añadir más proyectos.
12.8. El test práctico: ¿qué ocurriría si mañana desapareciera el responsable informal?
En muchas implantaciones existe una persona que mantiene el proyecto unido sin que esa función aparezca formalmente.
Conoce:
- qué se decidió;
- por qué se eligió un proveedor;
- qué prometió cada área;
- qué limitaciones existen;
- qué piloto importa;
- qué incidencias siguen abiertas;
- y qué debería ocurrir después.
Si esa persona desapareciera durante un mes y el proyecto perdiera gran parte de su capacidad para decidir y continuar, existe una concentración de ownership que conviene hacer visible.
Cuando una transformación depende de una persona que “sabe cómo encaja todo”, esa persona ya está ejerciendo una función de dirección aunque el organigrama no la nombre así.
12.9. Cuándo probablemente NO necesitas incorporarla
Las señales anteriores no deberían utilizarse para justificar automáticamente otra capa externa.
Probablemente no necesitas dirección externa si:
- el caso de uso es concreto y limitado;
- existe un owner interno con autoridad y tiempo;
- las métricas están definidas;
- el proceso apenas cambia;
- la solución es principalmente técnica;
- la relación con proveedores puede gobernarse internamente;
- y la organización dispone de capacidad para tomar las decisiones que aparecerán durante la implantación.
No añadas dirección donde ya existe
Una capa directiva redundante puede aumentar reuniones, coordinación y coste sin resolver ninguna carencia. El diagnóstico debe demostrar qué responsabilidad no está suficientemente cubierta antes de externalizarla.
12.10. La decisión puede ser temporal
Necesitar capacidad directiva ahora tampoco implica necesitarla siempre.
Puede tener sentido durante una fase concreta:
- definir prioridades;
- poner en marcha un programa;
- seleccionar proveedores;
- llevar varios pilotos a producción;
- construir métricas;
- crear mecanismos de gobierno;
- y transferir después esa capacidad a alguien interno.
Eso permite incorporar seniority sin crear una estructura permanente antes de saber qué necesitará realmente la organización a largo plazo.
Puede utilizarse para atravesar una fase de alta incertidumbre o transformación y reducirse después a medida que ownership, criterios, procesos y conocimiento quedan internalizados.
12.11. El diagnóstico final no debería ser “necesitamos un director de IA”
El título del rol es secundario.
La cuestión es qué decisiones necesitan una autoridad que hoy no existe o no dispone de suficiente capacidad.
Puede asumirlas:
- el CEO;
- un COO;
- un CIO o CTO;
- un responsable de transformación;
- un director funcional;
- un equipo transversal;
- o capacidad directiva externa.
Lo importante es que alguien pueda responder por el conjunto.
Si ya tienes tecnología y especialistas pero sigue sin estar claro quién decide prioridades, integra negocio y tecnología, gobierna proveedores, mide valor y puede detener una iniciativa, probablemente te falta una capacidad directiva. La respuesta puede ser interna o externa; lo importante es cubrirla.
Con estas cuatro capacidades ya suficientemente diferenciadas —consultoría, integración, software y dirección— podemos construir finalmente una matriz de decisión que no empiece por categorías de proveedor.
Empieza por cuatro preguntas sobre la propia empresa.
Dirección externa no tiene sentido porque la IA sea compleja. Tiene sentido cuando la empresa carece temporalmente de suficiente capacidad para gobernar esa complejidad.
13. Matriz final: qué necesita realmente tu empresa
Después de recorrer consultoría, integración, software y dirección, podemos reducir buena parte de la decisión a cuatro preguntas.
No sustituyen un diagnóstico detallado.
Pero sí permiten evitar uno de los errores más frecuentes: empezar comparando proveedores antes de entender qué capacidad falta realmente.
13.1. Las cuatro preguntas que cambian la decisión
13.2. La matriz de decisión
Al cruzar estas cuatro dimensiones aparecen escenarios bastante diferentes.
| Situación | Capacidad que probablemente falta | Respuesta que gana peso |
|---|---|---|
| El problema todavía no está suficientemente definido, pero existe buen ownership interno | Diagnóstico, priorización y diseño. | Consultoría + dirección interna |
| El problema todavía no está suficientemente definido y tampoco existe suficiente ownership | Criterio y capacidad directiva. | Dirección externa, con apoyo consultivo si es necesario |
| El problema está claro, existe solución estándar y la integración es baja | Funcionalidad. | Software |
| El problema está claro, existe solución estándar, pero la integración es alta | Funcionalidad + integración. | Software + integrador |
| El problema está claro, no existe solución estándar suficiente y existe capacidad interna de gobierno | Construcción o integración específica. | Integrador / desarrollo + dirección interna |
| El problema está claro, no existe solución estándar suficiente y falta capacidad de gobierno | Construcción + ownership. | Dirección externa + integrador / desarrollo |
| Existen múltiples iniciativas, proveedores y áreas sin un owner transversal | Gobierno del conjunto. | Dirección interna reforzada o dirección externa |
| La empresa dispone internamente de criterio, ownership, capacidad técnica y recursos suficientes | No existe una carencia crítica externa. | Equipo interno |
La matriz indica capacidad dominante, no una receta contractual
Una misma empresa puede situarse en escenarios diferentes según el caso de uso. También puede combinar capacidades o cubrirlas internamente. El objetivo es evitar que la categoría del proveedor determine el diagnóstico.
El árbol parte de cuatro preguntas: claridad sobre el resultado, existencia de una solución estándar, necesidad de integración específica y capacidad interna para gobernar la implantación.
Marco de decisión de R&R. El resultado identifica la capacidad que gana peso, no impide combinar varias ni obliga a externalizarlas.
13.3. Primer caso: no sabes suficientemente bien qué quieres conseguir
Si la empresa todavía no puede definir con suficiente precisión el problema, el resultado esperado o la prioridad, discutir arquitectura es prematuro.
Antes conviene reducir incertidumbre sobre:
- qué problema merece resolverse;
- qué proceso está detrás;
- qué valor produciría cambiarlo;
- qué datos existen;
- y qué evidencia justificaría invertir.
Si existe buen ownership interno, una consultora puede completar ese diagnóstico.
Si además falta alguien capaz de convertirlo en decisiones y ejecución, la carencia puede ser directiva.
Evita empezar seleccionando tecnología. La prioridad es construir suficiente claridad empresarial antes de decidir software, arquitectura o proveedor.
13.4. Segundo caso: sabes qué necesitas y el mercado ya lo resuelve
Este escenario debería ser más sencillo de lo que a veces lo hacemos.
Si el problema está bien definido y existe una solución estándar suficientemente buena, software debería ser una de las primeras alternativas que evaluar.
La siguiente pregunta es únicamente cuánto trabajo hace falta para integrarlo.
Si la respuesta es poco, la empresa puede no necesitar prácticamente ninguna otra capacidad externa.
Si la integración es alta, software e integrador pueden formar una combinación natural.
Comprar suele ganar frente a construir, salvo que exista una diferencia empresarial concreta que justifique asumir más coste, mantenimiento y complejidad.
13.5. Tercer caso: sabes qué necesitas, pero no existe una solución suficientemente estándar
Aquí el problema cambia.
La empresa puede necesitar desarrollar una capacidad específica, combinar varios componentes o adaptar profundamente tecnología existente.
La pregunta principal ya no es estrategia de IA.
Es si existe capacidad técnica para construir y operar la solución.
Si el ownership empresarial está cubierto internamente, un integrador o equipo de desarrollo puede ser suficiente.
Si no lo está, construir sin resolver antes esa carencia puede trasladar demasiadas decisiones empresariales al proveedor técnico.
Separa dos responsabilidades: quién define y gobierna el resultado y quién construye la capacidad técnica. Pueden coincidir en un mismo proveedor, pero la empresa debería distinguirlas.
13.6. Cuarto caso: ya tienes piezas suficientes, pero nadie gobierna el conjunto
Este es el escenario en el que dirección gana más peso.
Existen:
- herramientas;
- proveedores;
- pilotos;
- presupuesto;
- y personas capaces.
Pero falta una autoridad capaz de ordenar todo ello alrededor de resultados empresariales.
Añadir otro software o especialista puede aumentar todavía más la fragmentación.
Antes de añadir otra capacidad técnica, identifica quién debe gobernar prioridades, inversión, proveedores, procesos, riesgo y criterios de continuidad.
13.7. Quinto caso: ya tienes todas las capacidades necesarias
También puede ocurrir.
Existe:
- un problema bien definido;
- un owner con autoridad;
- capacidad técnica;
- datos suficientes;
- criterios de éxito;
- y recursos para ejecutar.
En ese caso, contratar apoyo externo solo tiene sentido si aporta una ventaja concreta de velocidad, especialización o economía.
La respuesta correcta también puede ser no contratar a nadie.
13.8. El árbol debería terminar en una capacidad, no en una empresa concreta
Este principio es importante para mantener la decisión abierta.
Si el diagnóstico concluye que necesitas integración, todavía tendrás que decidir qué integrador.
Si concluye que necesitas software, tendrás que comparar productos.
Si concluye que falta dirección, deberás decidir si puede cubrirla alguien interno o si tiene sentido incorporarla externamente.
La matriz no pretende eliminar esas decisiones.
Pretende conseguir que ocurran en el orden correcto.
Identifica qué responsabilidad necesitas cubrir y solo entonces compara quién puede cubrirla mejor, con qué coste, qué dependencia y bajo qué condiciones.
Antes de pedir propuestas queda todavía una comprobación práctica.
Diez preguntas que obligan a convertir una intención genérica de implantar IA en una decisión suficientemente concreta como para poder presupuestarla.
No elijas primero el proveedor que más te convence. Asegúrate primero de que necesitas aquello que ese proveedor vende.
14. Diez preguntas antes de pedir un presupuesto de IA
Pedir propuestas demasiado pronto tiene un problema.
Cada proveedor tenderá a interpretar la necesidad desde aquello que sabe ofrecer.
El fabricante verá una oportunidad de software.
El integrador verá una arquitectura.
La consultora verá un diagnóstico o transformación.
Y una dirección externa verá un problema de gobierno.
Eso no significa que ninguno actúe de mala fe.
Significa que la empresa necesita llegar a la conversación con una definición suficientemente clara de su propio problema.
14.1. ¿Qué resultado empresarial queremos cambiar?
No empieces por la tecnología.
Define qué debería mejorar.
Puede ser:
- tiempo;
- coste;
- capacidad;
- calidad;
- velocidad de decisión;
- conversión;
- retención;
- riesgo;
- o cualquier otro resultado observable.
¿Qué debería ser materialmente distinto en el negocio si esta implantación funciona?
14.2. ¿Cuál es la situación actual?
Sin baseline es difícil saber si la solución mejora algo.
Si queremos reducir tiempo, necesitamos conocer aproximadamente cuánto consume hoy.
Si queremos mejorar calidad, necesitamos saber cómo se mide actualmente.
Si queremos aumentar capacidad, debemos saber qué volumen puede gestionar hoy el proceso.
¿Qué ocurre hoy y con qué métrica podremos comparar el resultado futuro?
14.3. ¿Existe ya software que resuelva suficientemente el problema?
Antes de financiar desarrollo específico conviene revisar si la necesidad está suficientemente estandarizada.
La pregunta no es si existe un producto perfecto.
Es si existe uno suficientemente bueno como para que construir algo propio deje de tener sentido económico.
¿Qué parte de la necesidad no puede cubrir razonablemente una solución existente y cuánto valor crea realmente esa diferencia?
14.4. ¿Qué datos necesita la solución?
Identifica qué información necesita para operar y dónde está.
Conviene conocer:
- fuentes;
- propietarios;
- calidad;
- frecuencia de actualización;
- permisos;
- procedencia;
- y contradicciones relevantes.
¿Disponemos realmente de la información que la solución necesita y con suficiente calidad para el nivel de decisión que esperamos automatizar?
14.5. ¿Con qué sistemas y procesos debe convivir?
Una capacidad rara vez llega a una empresa completamente aislada.
Puede necesitar consultar o modificar:
- CRM;
- ERP;
- correo;
- gestores documentales;
- bases de datos;
- herramientas internas;
- o aplicaciones externas.
También debe encajar en un proceso humano existente.
¿Qué sistemas, permisos, workflows y dependencias condicionan que la solución pueda operar de verdad?
14.6. ¿Qué puede preparar, qué puede decidir y qué puede ejecutar?
La autonomía debería definirse antes de construirla.
No es lo mismo:
- generar una recomendación;
- preparar una acción;
- autorizarla;
- ejecutarla;
- o verificarla.
Cuanto más material e irreversible sea la acción, más importante es diseñar claramente esa frontera.
¿Qué decisiones pueden delegarse, cuáles necesitan autorización y quién conserva la responsabilidad final?
14.7. ¿Quién será el owner?
Esta pregunta debería tener nombre y función, no únicamente un departamento.
El owner necesita poder responder por:
- prioridad;
- resultado;
- alcance;
- proveedores;
- adopción;
- métricas;
- y continuidad.
¿Quién tiene autoridad y tiempo suficiente para tomar decisiones durante la implantación y responder por el resultado?
14.8. ¿Cuál será el coste completo de operar la capacidad?
El presupuesto inicial suele mostrar únicamente una parte de la economía.
Conviene considerar:
- licencias;
- modelos;
- infraestructura;
- integraciones;
- mantenimiento;
- soporte;
- supervisión humana;
- formación;
- cambios de proceso;
- y evolución.
¿Cuánto costará mantener esta capacidad funcionando cuando deje de ser un piloto y empiece a utilizarse de forma recurrente?
14.9. ¿Qué ocurrirá si dentro de un año queremos cambiar de proveedor?
No necesitas independencia absoluta.
Necesitas saber qué estás aceptando.
Revisa:
- portabilidad de datos;
- propiedad del código;
- documentación;
- dependencia de modelos;
- conocimiento transferido;
- y coste de transición.
¿Qué conservará la empresa y qué coste tendrá continuar si el proveedor, modelo o plataforma cambia?
14.10. ¿Qué tendría que ocurrir para decidir que paramos?
Muchas implantaciones definen qué significa éxito.
Pocas definen con la misma precisión qué evidencia justificaría abandonar.
Sin criterios de salida, un proyecto puede continuar simplemente porque ya se ha invertido demasiado en él.
Una implantación gobernada necesita criterios de éxito y criterios de abandono.
¿Qué evidencia de coste, calidad, riesgo, adopción o falta de impacto debería llevarnos a corregir la iniciativa o dejar de invertir?
14.11. Si no puedes responder varias de estas preguntas, el presupuesto probablemente llegará demasiado pronto
No es necesario tener todo resuelto antes de hablar con proveedores.
Parte de su valor consiste precisamente en ayudarte a descubrir opciones, limitaciones y costes que todavía desconoces.
Pero existe una diferencia entre llegar con preguntas abiertas y llegar sin haber definido qué decisión empresarial intentas tomar.
Una propuesta muy precisa sobre un problema mal definido sigue siendo una mala propuesta
Si distintos proveedores presupuestan cosas radicalmente diferentes, puede que el problema no sea que las propuestas sean incomparables. Puede que la necesidad todavía no esté suficientemente especificada.
14.12. Estas preguntas también sirven para comparar propuestas
Una vez recibidas las ofertas, puedes volver a utilizar el mismo marco.
Compara si cada propuesta explica:
- qué resultado está intentando conseguir;
- qué parte resuelve el proveedor;
- qué capacidades deben seguir existiendo dentro de la empresa;
- qué datos necesita;
- qué integración presupone;
- qué autonomía tendrá la solución;
- qué coste operativo deja después;
- qué dependencia introduce;
- qué métricas propone;
- y qué ocurre si el proyecto no alcanza esas métricas.
Compara también qué responsabilidad asume cada proveedor, qué responsabilidad deja dentro de tu empresa y qué capacidad tendrás realmente cuando termine la implantación.
Con todo esto ya podemos situar mejor dónde encaja Rumbo & Resultados dentro de esta arquitectura.
Y, de la misma manera que hemos hecho con el resto de alternativas, también dónde no encaja.
Un presupuesto debería responder cuánto cuesta resolver un problema definido, no ayudarte a descubrir después qué problema acababas de comprar.
15. Dónde encaja Rumbo & Resultados
Después de separar consultoría, integración, software y dirección, también conviene ser precisos sobre dónde encaja Rumbo & Resultados.
R&R no parte de una herramienta concreta ni intenta convertir cualquier necesidad empresarial en un proyecto tecnológico.
Tampoco pretende asumir por defecto todas las capas de una implantación.
Trabajamos principalmente en la intersección entre dirección, diseño del sistema empresarial e implantación real.
Ese enfoque forma parte también de cómo planteamos nuestra consultoría para empresas: dirección, tecnología e implantación como capacidades que deben responder al mismo resultado empresarial.
15.1. El punto de partida no es “qué IA podemos instalar”
Una conversación puede empezar con una necesidad aparentemente tecnológica:
- automatizar un proceso;
- utilizar agentes;
- incorporar IA a ventas;
- analizar información financiera;
- mejorar productividad;
- o conectar determinadas herramientas.
Pero antes de decidir la solución intentamos identificar qué problema empresarial existe realmente detrás.
Eso puede llevar a conclusiones distintas.
Puede ser necesario implantar tecnología.
Puede bastar con comprar software.
Puede necesitarse un integrador especializado.
Puede ser mejor modificar primero el proceso.
O puede ocurrir que la inversión no esté suficientemente justificada.
R&R intenta empezar por resultado, proceso, capacidad y gobierno. Solo después decide qué papel debe jugar la tecnología y si esa tecnología debe comprarse, integrarse, desarrollarse o no incorporarse.
15.2. Nuestra función se parece más a construir capacidad que a recomendar herramientas
Una recomendación puede ser necesaria.
Pero el trabajo relevante empieza cuando esa recomendación debe convertirse en una forma nueva de operar.
Eso puede exigir:
- definir prioridades;
- rediseñar procesos;
- establecer métricas;
- seleccionar tecnología;
- decidir qué comprar y qué construir;
- coordinar especialistas;
- implantar capacidades;
- gobernar autonomía y riesgo;
- medir resultados;
- y corregir o detener aquello que no produce suficiente valor.
Una buena recomendación sigue sin ser una capacidad instalada.
15.3. A veces utilizamos tecnología propia y a veces no
R&R desarrolla capacidades propias basadas en IA.
Entre ellas estamos construyendo herramientas orientadas a inteligencia financiera, descubrimiento comercial, sistema comercial y visibilidad empresarial en entornos de IA.
Pero disponer de tecnología propia no significa que deba utilizarse en cualquier proyecto.
Una capacidad propia tiene sentido cuando:
- encaja con el problema;
- reduce tiempo o complejidad;
- aporta una capacidad que la empresa necesita;
- y resulta competitiva frente a las alternativas existentes.
Si una solución externa resuelve mejor la necesidad, la decisión debería poder ser utilizarla.
Las capacidades propias de R&R son herramientas disponibles dentro de una implantación, no el punto de partida obligatorio del diagnóstico. La elección debería depender del problema y de la alternativa que produzca mejor resultado empresarial.
15.4. Tampoco somos un integrador tecnológico generalista
Hay proyectos en los que la necesidad dominante es claramente técnica.
Por ejemplo:
- migraciones complejas;
- infraestructura cloud;
- arquitecturas empresariales de gran escala;
- integraciones profundas con sistemas legacy;
- ingeniería de datos especializada;
- o desarrollos que exigen equipos técnicos dedicados.
En esos casos, un integrador o especialista tecnológico puede ser la capacidad principal que necesita la empresa.
R&R puede participar en la definición empresarial, gobierno, coordinación o diseño de la capacidad si existe una necesidad real, pero eso no convierte a R&R en sustituto de especialistas técnicos que aportan una competencia que el proyecto requiere.
La implantación puede necesitar especialistas que no deben sustituirse
Si el problema necesita ingeniería específica, seguridad especializada, infraestructura o integraciones complejas, la respuesta correcta puede ser incorporar un proveedor especializado y gobernar correctamente esa relación.
15.5. Nuestra capa principal está entre la decisión y la ejecución
Ese espacio suele quedar mal cubierto.
Una empresa puede recibir una recomendación estratégica y seguir sin saber cómo transformarla en capacidad.
O puede contratar tecnología y seguir sin tener claro qué debe cambiar en el negocio para aprovecharla.
R&R intenta trabajar precisamente en esa transición.
| Función | Qué implica |
|---|---|
| Diagnosticar | Identificar dónde está realmente la restricción: dirección, proceso, datos, tecnología, integración o capacidad. |
| Priorizar | Decidir qué merece inversión primero y qué debería esperar o descartarse. |
| Diseñar | Definir proceso, responsabilidades, métricas, gobierno y arquitectura funcional necesaria. |
| Decidir build / buy / integrate | Determinar qué conviene comprar, integrar, construir o no hacer. |
| Coordinar | Alinear negocio, tecnología, proveedores y responsables alrededor del mismo resultado. |
| Implantar | Convertir decisiones en procesos, capacidades y formas de trabajo utilizables. |
| Medir | Conectar actividad y uso con evidencia de resultado empresarial. |
| Corregir o detener | Modificar la implantación cuando la evidencia no confirma la hipótesis inicial. |
15.6. El objetivo no debería ser que la empresa dependa permanentemente de R&R
El mismo criterio que hemos aplicado a otros proveedores debe aplicarse también a nosotros.
Si participamos en una implantación, la empresa debería conservar progresivamente:
- conocimiento;
- criterios de decisión;
- datos;
- documentación;
- capacidad para gobernar proveedores;
- y suficiente contexto para continuar sin reconstruir desde cero la transformación.
Puede seguir existiendo una relación porque continúa aportando valor.
Pero la relación no debería estar protegida artificialmente por oscuridad, falta de documentación o imposibilidad de continuar sin nosotros.
El objetivo de una implantación no debería ser hacer más imprescindible al proveedor. Debería ser hacer más capaz a la empresa.
15.7. Cuándo R&R probablemente NO es la respuesta que necesitas
Este límite también debe ser explícito.
- el caso de uso, el business owner, la arquitectura y las métricas ya están completamente definidos y solo falta ejecutar una integración técnica compleja;
- existe un producto estándar que resuelve suficientemente el problema y únicamente necesitas contratarlo o configurarlo;
- la organización ya dispone internamente de capacidad directiva suficiente para gobernar la implantación;
- o la necesidad principal pertenece a una especialidad técnica que exige un proveedor dedicado.
En esos escenarios, añadir R&R podría crear una capa que la implantación no necesita.
Y eso iría contra el mismo principio que hemos defendido durante todo el artículo.
Principalmente cuando la empresa necesita unir dirección, transformación empresarial, IA aplicada e implantación real: identificar qué debe cambiar, construir o incorporar las capacidades necesarias y gobernar la ejecución hasta poder evaluar el resultado.
15.8. El posicionamiento importa también para elegirnos correctamente
Por eso no creemos que describir R&R simplemente como una “consultora de IA” explique suficientemente nuestra función.
Tampoco como una agencia de automatización, un integrador tecnológico generalista o un proveedor SaaS.
Puede haber elementos de consultoría.
Puede haber tecnología propia.
Puede haber implantación.
Y puede haber coordinación con especialistas externos.
Pero la unidad que intentamos resolver es otra: capacidad empresarial.
La tecnología es parte de la respuesta cuando amplía la capacidad de la empresa. No es la definición completa del problema ni de R&R.
Si lo que necesitas es únicamente tecnología, contrata tecnología. Si lo que falta es capacidad para decidir, transformar e implantar, el problema es más amplio.
16. Antes de seleccionar proveedor, identifica la capacidad que falta
Una empresa puede equivocarse contratando un mal proveedor. Pero también puede equivocarse contratando a un excelente proveedor para resolver el problema equivocado.
Una consultora puede hacer un magnífico diagnóstico cuando lo que faltaba era ejecutar; un integrador puede construir una arquitectura impecable para una iniciativa sin suficiente valor; el software puede funcionar y no cambiar ningún proceso relevante; y una dirección externa puede añadir complejidad donde ya existía suficiente ownership interno.
La calidad del proveedor importa. Pero solo después de haber identificado con suficiente precisión qué capacidad necesita realmente la empresa.
- Consultoría gana peso cuando todavía debes entender y priorizar qué merece hacerse.
- Software gana peso cuando el problema ya está suficientemente estandarizado.
- Integración gana peso cuando la solución está clara pero debe funcionar con tus datos, sistemas y procesos.
- Dirección gana peso cuando faltan ownership, prioridad, coordinación y gobierno transversal.
- Las cuatro capacidades pueden combinarse y cualquiera de ellas puede estar cubierta internamente.
- El objetivo no es contratar más capacidad externa, sino cubrir exactamente la que falta.
Antes de preguntarte qué proveedor de IA contratar, identifica qué capacidad no tiene hoy tu empresa. La elección correcta empieza ahí.
Si ya existen herramientas, pilotos, proveedores o iniciativas pero no está claro qué debería comprarse, integrarse, desarrollarse o gobernarse internamente, podemos ayudarte a ordenar esa decisión antes de seguir invirtiendo.
El punto de partida no tiene que ser contratar tecnología. Puede ser simplemente determinar qué capacidad falta realmente y cuál es la forma más razonable de incorporarla.
Preguntas frecuentes sobre cómo implantar IA en una empresa
Respuestas directas para decidir cuándo necesitas consultoría, integración tecnológica, software, dirección externa o capacidad interna para implantar inteligencia artificial.
¿Qué diferencia hay entre una consultora de IA y un integrador tecnológico?
Una consultora gana peso cuando la empresa todavía necesita definir qué problema resolver, qué casos priorizar, qué retorno esperar o cómo organizar la transformación. Un integrador tecnológico gana peso cuando el resultado está suficientemente definido y el principal reto consiste en conectar modelos, datos, aplicaciones, permisos e infraestructura para que la solución funcione en producción. Pueden solaparse y una misma implantación puede necesitar ambas capacidades.
¿Cuándo es mejor comprar software de IA que desarrollar una solución propia?
Comprar suele ser mejor cuando el problema está suficientemente estandarizado, existe una solución madura que lo resuelve con calidad adecuada y la personalización adicional no crea una ventaja empresarial que compense su coste, mantenimiento y complejidad. Desarrollar gana sentido cuando datos, proceso, integración o lógica específica forman parte material de la capacidad que la empresa necesita diferenciar.
¿Quién debería liderar una implantación de inteligencia artificial?
Debe existir un owner con autoridad suficiente sobre el resultado empresarial, aunque la ejecución técnica recaiga en otras personas o proveedores. Ese responsable necesita poder priorizar, resolver trade-offs, coordinar negocio y tecnología, definir métricas, decidir niveles de autonomía y determinar cuándo continuar, corregir o detener la implantación. Puede ser una persona interna o, cuando esa capacidad no está disponible, incorporarse temporalmente como dirección externa.
¿Cómo elegir entre una consultora de IA, un integrador tecnológico, software o dirección externa?
Empieza identificando qué capacidad falta. Consultoría gana peso cuando todavía hay que definir el problema, las prioridades o el business case; integración cuando el reto está en conectar la solución con datos y sistemas; software cuando la necesidad está suficientemente estandarizada; y dirección externa cuando falta ownership para gobernar prioridades, proveedores, procesos y resultados. Pueden combinarse y cualquiera de estas capacidades puede existir internamente.
¿Cómo evitar depender demasiado de un proveedor de IA?
No es necesario eliminar toda dependencia. Conviene saber qué datos, conocimiento, código, configuraciones, integraciones y decisiones seguiría conservando la empresa si cambia de proveedor. La documentación, transferencia de conocimiento, propiedad de los activos, portabilidad y una estrategia de salida proporcionada a la criticidad de la solución ayudan a convertir la dependencia en una decisión gobernada.
¿Cuándo una empresa no necesita dirección externa para implantar IA?
Cuando el caso de uso está suficientemente definido y existe internamente una persona con autoridad, tiempo y criterio para gobernar prioridades, proveedores, integración, adopción y resultados. Tampoco suele ser necesaria en proyectos pequeños, puramente técnicos o basados en software estándar con poca transformación operativa. Dirección externa solo tiene sentido cuando cubre una carencia directiva real.
¿Te avisamos cuando publiquemos nuevos contenidos?
Nos tomamos en serio tu tiempo. Solo te enviaremos artículos, guías o herramientas que te ayuden a mejorar, decidir o actuar mejor.
