Implantar IA en una empresa no consiste en comprar una herramienta, abrir cuentas para todos y esperar productividad automática. La parte difícil suele estar en otro lugar: que la IA acceda a los datos correctos, que sus respuestas entren en los sistemas que ya usa la organización, que alguien sea responsable de los indicadores y que los riesgos estén bajo control.
La brecha entre probar y escalar sigue siendo grande. Una recopilación de una encuesta global de McKinsey señala que el 88 % de las organizaciones ya usa IA en al menos una función de negocio, pero casi dos tercios no han pasado de la experimentación o de pilotos tempranos[5]. Es decir: muchas empresas ya están probando IA; muchas menos han logrado convertirla en una capacidad estable de operación.
Antes del modelo, el proceso
La primera pregunta no debería ser qué modelo elegir, sino qué proceso merece rehacerse. Los mejores primeros casos no siempre son los más vistosos. Suelen ser tareas frecuentes, repetibles, con datos disponibles, impacto medible y un margen razonable para revisión humana.
Un buen candidato inicial suele cumplir varias condiciones:
- El equipo repite la misma tarea todos los días o todas las semanas.
- Los datos ya existen en documentos, CRM, ERP, sistemas de tickets, almacenes de datos o bases internas de conocimiento.
- Hay un dolor claro: demasiado tiempo buscando información, mucho copiar y pegar, respuestas inconsistentes o retrabajo.
- La salida de la IA puede revisarse, corregirse o derivarse a una persona cuando haga falta.
- Existe un responsable de negocio con autoridad para cambiar el proceso y aceptar o rechazar los resultados.
Si esas condiciones no existen, el proyecto puede acabar siendo una demostración convincente en una reunión, pero no una mejora sostenible.
5 pasos para pasar del PoC a una capacidad real
1. Convertir la necesidad en un problema de negocio medible
Evite formular el proyecto como implantar IA. Es más útil describir qué usuarios hacen qué tarea, dónde se atascan y qué indicador debe mejorar.
Una plantilla sencilla:
En el proceso A, el rol B dedica cada semana demasiado tiempo a la tarea C; queremos usar IA para mejorar el indicador D desde la línea base actual hasta un objetivo definido, con el responsable de negocio E a cargo del cambio de proceso y de la validación del resultado.
Antes de empezar, conviene responder al menos estas preguntas:
- ¿Quién usará esta función de IA de forma habitual?
- ¿En qué paso del trabajo entra la IA?
- ¿Cuál es la línea base actual: tiempo de gestión, tasa de error, coste, conversión, reclamaciones o horas manuales?
- ¿El éxito se medirá por eficiencia, calidad, ingresos, coste, riesgo o experiencia del empleado?
- ¿Quién puede decidir que el proceso cambie y asumir el resultado?
Sin responsable de negocio y sin línea base, el PoC —prueba de concepto— queda sin criterio claro de éxito.
2. Elegir 1–3 casos de uso frecuentes, repetibles y con datos disponibles
El primer paquete de casos debe ser manejable. Mejor empezar con tareas de alto volumen y bajo riesgo que con procesos enormes, ambiguos o críticos.
| Caso candidato | Por qué sirve para empezar | Primeros KPI posibles |
|---|---|---|
| Búsqueda de conocimiento para atención al cliente | Las respuestas suelen venir de FAQ, manuales, historial de tickets o bases internas | Tiempo medio de gestión, resolución al primer contacto, precisión por muestreo, reclamaciones |
| Preguntas sobre documentación interna | Los empleados pierden tiempo localizando políticas, procesos, producto o documentación técnica | Tiempo de búsqueda, derivaciones a otros equipos, tasa de adopción de respuestas |
| Resúmenes de reuniones e informes | El formato suele ser repetitivo y la revisión humana es sencilla | Tiempo de elaboración, tasa de aceptación del resumen, número de revisiones |
| Extracción de campos en contratos o documentos | Los campos son identificables y puede diseñarse una revisión posterior | Precisión por campo, tiempo de revisión, retrabajo |
| Apoyo a ventas o compras | La IA puede ayudar a ordenar información, comparar opciones, redactar borradores o preparar recomendaciones iniciales | Tiempo de respuesta, ciclo de gestión, conversión, ahorro de trabajo manual |
No conviene empezar por el caso de mayor riesgo, con datos dispersos o con responsabilidades poco claras. Si la información está desordenada o el proceso no está estandarizado, primero hay que arreglar datos y flujo de trabajo.
3. Revisar datos, permisos e integración antes del PoC
La IA empresarial rara vez falla solo por el modelo. Falla cuando no puede usar datos fiables, cuando los permisos no están definidos o cuando el resultado no vuelve al sistema donde trabaja el usuario.
Una síntesis de Talyx sobre un estudio de RAND Corporation de 2024, basado en entrevistas a 65 científicos de datos e ingenieros experimentados, identifica varias causas recurrentes de fracaso en proyectos de IA: definición mal entendida del problema, datos insuficientes, mentalidad centrada en la tecnología y no en el problema, infraestructura insuficiente y problemas que superan lo viable[4].
Antes del PoC, revise:
- Dónde están los datos: repositorios documentales, CRM, ERP, tickets, data warehouse o archivos personales.
- Calidad de los datos: duplicados, versiones antiguas, campos incompletos o formatos inconsistentes.
- Permisos: qué puede ver cada departamento, rol, nivel jerárquico o región.
- Actualización: si la IA consulta información vigente o documentos de hace meses.
- Integración: si la salida puede volver al CRM, sistema de tickets, informes, aprobaciones o documentación.
- Trazabilidad: quién preguntó, qué respondió la IA, quién aceptó o corrigió la respuesta y dónde queda registrado.
Si los datos no están disponibles, la IA solo hará una demo. Si los permisos no están claros, el proyecto puede bloquearse en seguridad, privacidad, legal o auditoría.
4. Hacer un PoC pequeño, pero conectado al trabajo real
Un PoC no debería ser una maqueta aislada. Debe funcionar como una primera versión de producto: pocos usuarios, datos reales, flujo real y criterios de éxito, ampliación y parada definidos desde el principio.
Preguntas clave:
- ¿Dónde se activa la IA: CRM, Teams, Slack, portal interno, mesa de ayuda o una aplicación existente?
- ¿Quién revisa la salida?
- ¿Qué casos deben derivarse obligatoriamente a una persona?
- ¿Cómo se reportan errores y quién corrige datos, reglas o instrucciones?
- ¿Qué tareas solo pueden ser asistidas, no automatizadas?
- ¿Qué umbral de KPI permite escalar y qué umbral obliga a detener o rediseñar?
El objetivo no es demostrar que la IA puede generar texto. El objetivo es probar que mejora un indicador dentro de un proceso real.
5. Escalar solo después de gobernanza
Escalar IA no es repartir más licencias. Cada nuevo departamento añade fuentes de datos, reglas de acceso, diferencias operativas, obligaciones legales y métricas propias.
La prudencia es aún más importante cuando la IA pasa de buscar, resumir o redactar a actuar con mayor autonomía mediante agentes. El resumen de la encuesta 2025 de McKinsey muestra que, en cualquier función individual, no más del 10 % de los encuestados reporta haber escalado agentes de IA[2]. McKinsey también señala que la seguridad y el riesgo son la principal barrera para escalar IA agéntica, mientras que la inexactitud y la ciberseguridad siguen entre los riesgos de IA citados con más frecuencia[
8].
Una ruta razonable:
- Empezar con búsqueda, clasificación, resumen y borradores.
- Mantener revisión humana y registrar errores, excepciones y uso real.
- Automatizar pasos de bajo riesgo solo cuando precisión, permisos, trazabilidad y estabilidad estén maduros.
- Revisar datos, legal, privacidad, seguridad y auditoría antes de entrar en otro departamento.
Cómo definir KPI: no basta con medir precisión del modelo
La precisión técnica importa, pero no es suficiente. La empresa necesita saber si el proceso mejora. Por eso conviene medir la situación actual antes del piloto y usar varios tipos de indicadores.
| Tipo de KPI | Indicadores útiles | Casos donde aplica |
|---|---|---|
| Eficiencia | Tiempo medio de gestión, tiempo de ciclo, minutos manuales por caso, tiempo de elaboración de informes | Atención al cliente, documentación, informes, tickets |
| Calidad | Precisión por muestreo, tasa de adopción de respuestas, retrabajo, reclamaciones | Respuestas a clientes, extracción contractual, redacción asistida |
| Uso | Usuarios activos semanales, cobertura de tareas, repetición de uso, derivaciones a personas | Asistentes internos, búsqueda de conocimiento, herramientas departamentales |
| Resultado de negocio | Conversión, velocidad de respuesta, cierre de casos, coste por caso | Ventas, compras, operaciones, soporte |
| Riesgo y gobernanza | Escalados a revisión humana, incumplimientos de política, excepciones con datos sensibles, hallazgos de auditoría | Datos sensibles, respuestas externas, agentes de IA |
No hace falta medirlo todo desde el primer día. Sí hace falta que cada indicador esté unido a un proceso y a una decisión: ampliar, ajustar o detener.
Por qué tantos proyectos de IA no llegan a producción
1. Se compra la herramienta antes de encontrar el problema
Muchos proyectos nacen de una demo del proveedor o de la presión por usar IA. El resultado puede ser atractivo, pero irrelevante para el trabajo diario. La síntesis de Talyx sobre RAND incluye precisamente la mentalidad tecnología primero como una causa habitual de fracaso[4].
2. Cada área espera algo distinto
Negocio quiere reducir tiempos, tecnología quiere mejorar precisión, dirección espera ahorro y legal se centra en riesgo. Si no hay una definición compartida, el proyecto se descoordina. La definición mal entendida del problema también aparece entre las causas identificadas en esa síntesis[4].
3. Los datos y los sistemas no están conectados
Si la IA no accede a documentos, clientes, tickets o transacciones correctas, solo responderá de forma genérica. Si su salida no vuelve al CRM, ERP, gestor documental o sistema de tickets, el usuario seguirá copiando y pegando. La infraestructura insuficiente es otra causa recurrente señalada por la síntesis de Talyx sobre RAND[4].
4. El PoC no cambia la forma de trabajar
Que la adopción crezca no significa que haya escalado operativo. La recopilación de la encuesta de McKinsey citada antes indica que el 88 % de las organizaciones usa IA en al menos una función, pero casi dos tercios siguen en experimentación o pilotos tempranos[5]. Sin usuarios reales, responsable de negocio y KPI, el piloto se queda en presentación.
5. La gobernanza se deja para el final
Seguridad, privacidad, cumplimiento, auditoría y permisos no son un trámite final. Si se incorporan tarde, el proyecto puede tener que rehacerse. En IA agéntica, donde el sistema puede actuar con más autonomía, los límites de datos, permisos de acción, revisión humana y responsabilidad deben estar claros desde el diseño; McKinsey identifica seguridad y riesgo como la principal barrera para escalarla[8].
Matriz rápida: qué hacer primero y qué dejar para después
| Priorizar | Posponer hasta preparar mejor |
|---|---|
| Tareas repetidas cada semana o cada mes | Tareas excepcionales que ocurren pocas veces al año |
| Datos digitalizados y con fuente clara | Información dispersa en archivos personales o conocimiento oral |
| Reglas relativamente claras y respuestas trazables | Problemas ambiguos con expectativas distintas entre áreas |
| Errores revisables y corregibles por personas | Errores con impacto legal, financiero o de seguridad grave |
| Responsable de negocio dispuesto a cambiar el proceso | Proyecto impulsado solo por TI o consultores, sin usuarios comprometidos |
| KPI cuantificables: tiempo, precisión, coste, reclamaciones | Objetivos vagos como innovar o usar IA sin definición de valor |
Los casos de la segunda columna no están prohibidos. Simplemente requieren antes datos mejores, procesos más claros y una gobernanza más sólida.
Checklist de una página antes de iniciar
- ¿Qué problema de negocio concreto resuelve este caso?
- ¿Cuál es la línea base actual: tiempo, error, coste o reclamaciones?
- ¿Quién es el responsable de negocio y quién puede cambiar el proceso?
- ¿Los usuarios encuentran este problema con suficiente frecuencia?
- ¿Los datos existen, se pueden consultar y se mantienen actualizados?
- ¿Están claros permisos, privacidad, legal, seguridad y auditoría?
- ¿En qué sistema o flujo real entrará la salida de la IA?
- ¿Qué situaciones requieren revisión humana?
- ¿Qué KPI definen éxito, ampliación o parada?
- Si se escala a otro departamento, ¿siguen sirviendo los mismos datos, permisos y controles?
Conclusión: primero un proceso, luego la empresa entera
La IA empresarial debe empezar como rediseño de procesos, no como compra de modelos. El modelo es una capacidad necesaria, pero no garantiza adopción. Lo que decide si un PoC llega a operación es la combinación de datos utilizables, permisos claros, integración con sistemas, responsables de negocio, control de riesgos y KPI que demuestren valor.
