Cada dos CTOs se hace hoy la misma pregunta: «¿Por dónde empezar con IA para que no sea otra inversión inútil?» La respuesta no está en la tecnología. Está en la disciplina de los primeros tres meses — en lo que mapea, lo que descarta, a quién asigna responsabilidad y cómo mide el resultado. Este artículo es un marco de decisión para los primeros 90 días, no un manual técnico de instalación de modelos.
La mayoría de fuentes indica que entre el 75 y el 95 % de los proyectos de IA no alcanza el valor de negocio previsto. Las cifras quizás sufren de sesgos metodológicos en los estudios, pero la tendencia es consistente: los pilotos arrancan, se detienen a los 3–6 meses y el valor no llega. La causa suele ser la misma — no la tecnología, sino la falta de preparación antes del primer import openai.
Días 1–30: Mapee el terreno antes de excavar
Inventario de casos de uso, no lista de la compra
El primer mes no va de seleccionar tecnología. Va de entender dónde la empresa pierde tiempo y dinero en tareas cognitivas repetitivas — leer documentos, responder siempre las mismas preguntas, extraer datos de formularios, redactar informes estándar.
Método rápido: pida a 5–10 personas de distintos departamentos que anoten en papel qué hacen de forma repetitiva cada semana y qué les resulta tedioso. La mayoría de lo que escriban será cualitativamente diferente a «queremos un chatbot». Aparecerán cosas como: transcripción manual de correos de clientes al CRM, búsqueda de respuestas en documentación técnica, preparación de materiales para ofertas de precio, verificación de albaranes de entrega.
Evalúe cada caso de uso en dos ejes: frecuencia (con qué regularidad ocurre) y valor (cuánto cuesta una ejecución — tiempo × tarifa horaria × número de repeticiones mensuales). Esto no es un ejercicio académico — es la base de la conversación sobre ROI que tendrá con la dirección dentro de 60 días.
Distinción: chatbot, copilot o agente
Antes de elegir herramienta, distinga qué necesita realmente. Chatbot, copilot y agente son patrones arquitectónicos distintos con costes y complejidad diferentes.
Chatbot responde preguntas — adecuado para soporte al cliente o FAQ interno. El más sencillo de desplegar, las expectativas más bajas.
Copilot asiste al trabajador en su herramienta — en el sistema MES de producción, en el ERP, en la documentación. El trabajador toma decisiones, la IA sugiere y prepara. Primer paso habitual para empresas industriales.
Agente planifica, llama a herramientas y ejecuta acciones de múltiples pasos de forma autónoma. Más potente, pero exponencialmente más complejo — requiere error handling, observability y un pilotaje exhaustivo. No es para el primer proyecto.
Para el 80 % de las empresas en los primeros 90 días, la respuesta correcta es: copilot sobre documentación interna o RAG sobre la base de conocimiento corporativa.
Datos: abra la caja de Pandora desde el principio
Los proyectos de IA fallan por los datos, no por los modelos. En el primer mes averigüe:
- ¿Dónde están los documentos, manuales, especificaciones técnicas, registros de servicio — y en qué formato (PDF, Word, hojas de cálculo, bases de datos)?
- ¿Quién tiene acceso? ¿Está definida la sensibilidad de los datos (GDPR, secreto comercial)?
- ¿Cuál es la vigencia — están los documentos actualizados o son de 2018?
El Cisco AI Readiness Index indica que solo alrededor del 34 % de las empresas considera suficiente su preparación en datos. En la práctica esto significa: escaneos de archivos PDF en papel, tablas Excel codificadas a mano y documentación que solo existe en la memoria de empleados veteranos. Eso no es razón para no empezar — es razón para empezar con una auditoría de datos, no con un modelo.
Días 31–60: Un piloto que decida algo
Elección del primer caso de uso: ROI positivo, no el más atractivo
El error más frecuente: la empresa elige el caso de uso más ambicioso — «queremos IA para predecir fallos en la línea de producción» — y el piloto se para por falta de datos históricos suficientes, criterios de éxito difusos y ausencia de un experto en dominio en el equipo.
El primer caso de uso debe cumplir tres condiciones simultáneamente:
- 1.Baseline medible — sabe cuántas horas cuesta actualmente esa tarea. Sin baselines no puede evaluar el resultado.
- 2.Alcance acotado — el piloto cabe en 4–6 semanas, incluida la evaluación. Cuanto más largo es el piloto, menor la probabilidad de que llegue al final.
- 3.Base de datos real — tiene al menos 50–200 documentos o transacciones sobre los que probar el piloto. No una base de datos del futuro.
Un buen primer caso de uso para una empresa industrial: Q&A sobre documentación técnica (RAG sobre manuales de servicio, certificados, normas). Los técnicos buscan respuestas a las mismas preguntas diez veces al día, hay documentos suficientes y la medición es clara (tiempo de búsqueda antes vs. después).
Arquitectura del piloto: ¿local o cloud?
Para empresas con documentos técnicos sensibles o carga regulatoria (maquinaria, industria química, sanidad) la primera pregunta es: «¿Pueden nuestros datos salir de la red?»
Si no — modelo local (Ollama con Qwen 3 o Mistral, ejecutándose en un servidor o workstation corporativo) con base de datos vectorial local es la opción correcta. El rendimiento será inferior al de un modelo cloud de frontera, pero el riesgo de compliance es nulo.
Si sí — cloud API (Claude Sonnet, GPT, Gemini Flash) con Azure OpenAI o directamente vía API ofrece mejor rendimiento out-of-the-box con menor carga de IT en la fase piloto.
Una comparativa más detallada en el artículo LLM local vs. cloud y también en la discusión RAG vs. fine-tuning — cuándo usar cada uno.
Criterios de éxito antes de arrancar el piloto
Defina qué es el éxito antes del piloto. No después. Métricas habituales:
- Tiempo ahorrado por tarea — objetivo: -30 % o un número concreto de minutos
- Precisión de respuestas — objetivo: >85 % de respuestas correctas evaluadas por un experto en dominio (20–50 preguntas de test)
- Adopción por los usuarios — objetivo: >60 % de los miembros del equipo usa el sistema al menos 3 veces por semana tras 4 semanas
- Tasa de error — objetivo: <5 % de respuestas con información factualmente incorrecta
Sin estas cifras el piloto acabará en el debate «¿funciona?» en lugar de en datos que respondan sí o no.
Días 61–90: Resultados, decisión, plan
Evaluación del piloto: tres preguntas
Tras 4–6 semanas de piloto responda a tres preguntas:
1. ¿Funciona lo suficientemente bien? Compare con la baseline pre-piloto. Si ha alcanzado el objetivo — continúe. Si no — ¿por qué no? ¿Datos, prompt, integración, o fue una mala elección de caso de uso?
2. ¿Lo adopta la gente? Un sistema técnicamente funcional que nadie usa no tiene valor de negocio. La adopción en las primeras semanas predice el resultado a largo plazo. Si la adopción es baja, averigüe por qué — UI, confianza, formación, o simplemente el sistema no ahorra tiempo.
3. ¿Dónde está la mayor resistencia? Todo proyecto de IA tropieza con el «esto no va a funcionar». Identifique de dónde viene la resistencia — seguridad de IT (datos), mandos intermedios (control), trabajadores (miedo a perder el empleo). Cada caso tiene una respuesta diferente.
Cálculo del ROI: sencillo, pero honesto
Para los decisores que deben justificar la continuación necesita cifras. Medir el ROI de proyectos de IA es un tema en sí mismo, pero el marco básico:
- Ahorro de tiempo: (horas/mes ahorradas) × (tarifa horaria del trabajador) × 12 = valor anual
- Costes del proyecto: infraestructura + costes de API + tiempo de ingeniería (piloto + producción)
- Período de retorno: costes / valor mensual = número de meses hasta la amortización
Para un RAG copilot típico con 5–10 técnicos, ahorrando 30–60 minutos/día: el valor anual es medible en decenas de miles de euros con tarifas centroeuropeas. Los costes del piloto son del orden de 10–30 veces inferiores si dispone de infraestructura existente y unos pocos días de trabajo de ingeniería.
Build vs. buy: la decisión del día 90
Tras el piloto tiene suficientes datos para la decisión build vs. buy. La regla de la práctica:
Compre (herramienta SaaS, plugin integrado) si: el caso de uso es genérico (soporte al cliente, resumen de correos), no es una diferenciación crítica y el equipo no tiene capacidad de AI engineering.
Construya (pipeline RAG propio, agente propio) si: los datos son sensibles y no pueden ir a la nube, el caso de uso es específico de dominio (normas de maquinaria, procesos internos), o planea escalar a más casos de uso donde los componentes compartidos (embedding, base de datos vectorial, orquestación) rentabilizan compartirse.
Combine — la respuesta correcta más habitual en 2026: compre para las capas commodity (API de modelos, vector DB), construya para «la última milla» (prompts, lógica de retrieval, integraciones, eval harness).
Qué evitar: cinco trampas de los primeros 90 días
1. Caso de uso hype sin baselines
«Queremos mantenimiento predictivo» o «queremos un analista estratégico con IA» — ambicioso, visualmente atractivo, y a la luz del análisis sin baseline medible, sin datos históricos y sin un experto en dominio en el equipo. Estos proyectos mueren en el tercer mes.
Regla: si no tiene baseline, tiene una aspiración, no un proyecto.
2. Vendor lock-in en la fase piloto
Algunos proveedores ofrecen un «piloto gratuito» a cambio de un compromiso. Antes de firmar, pruebe una alternativa — el stack open-source (LangChain/LlamaIndex + Qdrant + modelo local) puede ejecutar la mayoría de pilotos sin compromisos. El vendor lock-in es razonable después de validar el caso de uso, no antes.
3. Equipo de IA sin experto en dominio
Un ingeniero de IA sabe construir el pipeline. No sabe juzgar si la respuesta sobre un circuito hidráulico es correcta. Sin un técnico o tecnólogo que valide los resultados durante el piloto no tiene base para medir la precisión. El experto en dominio no es un «nice to have» — es un bloqueante.
4. Un piloto = estrategia de producción
Los pilotos demuestran el principio, no la preparación para producción. Del piloto a producción se necesita: auditoría de seguridad (prompt injection, data egress), MLOps (monitorización, versionado de prompts, eval regression) y change management (formación de usuarios, SLA, ruta de escalado cuando la IA responda incorrectamente).
5. Ignorar el EU AI Act
Si su caso de uso entra en la cadena de decisión con impacto sobre personas (contratación, evaluación, clasificación de riesgo), desde el 2 de agosto de 2026 son de aplicación los requisitos del EU AI Act sobre transparencia y clasificación de riesgo. El compliance no es solo un ejercicio legal — afecta a la arquitectura del sistema (audit log, explainability, supervisión humana). Cuanto antes lo tenga en cuenta en el diseño, más barato es el cambio.
Equipo: quién necesita y quién no
Un proyecto de IA no es una disciplina en solitario. Un sistema en producción (no solo un piloto) requiere habitualmente una combinación de:
- Ingeniero AI/ML — pipeline RAG, fine-tuning, orquestación de agentes, eval
- Ingeniero de datos — pipeline de datos, limpieza, base de datos vectorial
- Experto en dominio — validación de resultados, creación del conjunto de eval
- Product owner — métricas de éxito, priorización de casos de uso, gestión de stakeholders
- IT/seguridad — data egress, accesos, compliance
Para la fase piloto no es necesaria la tripulación completa. Un ingeniero AI + experto en dominio + product owner son suficientes para el piloto. MLOps e ingeniero de datos entran en producción.
Aviso: un equipo de menos de 3 personas responsables del proyecto de IA es arriesgado incluso para el piloto. La baja de una persona clave paraliza todo.
El equipo interno frente a un socio externo depende de la estrategia: si la IA es una competencia a largo plazo de la empresa, construya internamente. Si necesita validar rápidamente 2–3 casos de uso y no dispone de capacidad de IA, un socio externo con un marco de proyecto fijo es más ágil. La combinación — socio externo pilota, equipo interno asume la producción — es un modelo híbrido sensato.
Medición tras los 90 días: cuatro preguntas para la retrospectiva
Al final de los primeros 90 días responda con honestidad:
- 1.¿Alcanzó el piloto los criterios de éxito que definimos antes de empezarlo? (Si no los definió — eso es ya en sí mismo una lección.)
- 2.¿Podemos identificar otros 2–3 casos de uso donde la misma infraestructura aporte más valor? (Si no — existe el riesgo de estar pilotando sin estrategia.)
- 3.¿Tiene el proyecto un sponsor a nivel de dirección capaz de articular el valor de negocio? (Los proyectos sin sponsor CEO/COO fracasan estadísticamente con mucha más frecuencia que los que sí lo tienen.)
- 4.¿Sabemos cómo será el sistema en producción — monitorización, eval, ciclo de actualización? (Si no — el piloto es un proof-of-concept, no una base para escalar.)
Estas cuatro preguntas no evalúan la tecnología. Evalúan la madurez organizativa — y esa decide el resultado más que cualquier modelo.
Preguntas frecuentes
¿Cuánto cuesta todo esto — los primeros 90 días?
Depende del alcance, pero a modo orientativo: un piloto de RAG copilot sobre documentación interna, con cloud API y socio externo — del orden de unos pocos miles de euros en tiempo de ingeniería más bajos costes mensuales de API (para una PYME típicamente decenas o pocos cientos de euros con volúmenes normales). El despliegue local (servidor propio, modelo open-weight) tiene una inversión inicial más alta, pero menores costes operativos.
¿Necesitamos nuestra propia GPU?
Para la fase piloto normalmente no. Cloud API (Claude, Gemini Flash, GPT) u Ollama en un servidor corporativo existente con CPU convencional es suficiente para el piloto. La GPU propia tiene sentido cuando: los datos no pueden salir a la nube, el volumen de inferencia es alto (miles de peticiones diarias) o se planifica fine-tuning.
¿Y si nuestros datos no están preparados?
La falta de preparación de datos no es un bloqueo para el piloto — es un parámetro de entrada. Un piloto con 50 documentos bien preparados es mejor que uno con 5.000 de baja calidad. Empiece con un conjunto de referencia de 50–100 documentos revisados manualmente. El escalado en producción se aborda tras validar el caso de uso.
¿Cómo explicamos a los empleados que estamos implantando IA?
De forma directa y concreta — no «la IA va a ocupar su puesto», sino «la IA se encargará de buscar en los manuales para que usted tenga más tiempo de resolver problemas». Incorpore a los trabajadores al piloto como «evaluadores de IA» — su función es probar y reportar fallos. El ownership del piloto reduce la resistencia a la producción.
¿Es mejor empezar con un gran proyecto o con varios pilotos pequeños?
Desde la práctica: un piloto bien elegido con ROI claro es mejor que tres experimentos en paralelo. Los pilotos simultáneos dispersan la atención, degradan la calidad de datos en cada uno de ellos y dificultan la evaluación. Escale a más casos de uso después del primer éxito — no antes.
*MP Industrial Solutions ayuda a las empresas a afrontar los primeros 90 días de forma estructurada — desde el inventario de casos de uso hasta la elección de arquitectura y la definición de criterios de éxito medibles. Si está valorando por dónde empezar y quiere evitar pilotos de los que no resulta nada, estaremos encantados de mantener una consulta inicial gratuita.*