Una prueba de IA suele empezar con energía. Alguien descubre un asistente, prepara una demo convincente y consigue que una dirección diga: "Tenemos que hacer algo con esto". A partir de ahí se compran licencias, se anuncia un piloto y se espera que el uso aparezca solo.
Entonces llega la parte menos vistosa: los usuarios no saben qué tareas delegar, los documentos están duplicados, nadie ha decidido quién revisa las respuestas y el equipo técnico recibe peticiones que no tienen prioridad. Tres meses después, el proyecto se describe como "interesante", pero no como útil.
La inteligencia artificial puede fallar por motivos técnicos. En la empresa, sin embargo, los bloqueos más caros suelen estar en otro sitio: decisiones mal planteadas, procesos poco definidos y una distancia enorme entre probar una herramienta y cambiar una forma de trabajar.
La idea principal
Un proyecto de IA no empieza al activar el modelo. Empieza al elegir un problema concreto, definir quién responde por él y preparar el entorno donde la solución tendrá que funcionar.
1. Empezar por la herramienta
"Queremos poner Copilot", "necesitamos un chatbot" o "hay que crear un agente" son decisiones de producto, no objetivos de negocio. La herramienta puede ser adecuada, pero todavía no explica qué cambiará el lunes por la mañana.
El primer paso debería ser describir una tarea con suficiente detalle:
- Quién la realiza y con qué frecuencia.
- Qué información necesita consultar.
- Cuánto tiempo consume hoy.
- Qué errores o retrasos produce.
- Qué parte puede asistir la IA y cuál debe seguir bajo revisión humana.
La diferencia parece pequeña, pero cambia el proyecto entero. "Aplicar IA al departamento comercial" es demasiado amplio. "Preparar el resumen de una oportunidad a partir de reuniones y correos autorizados, para que el responsable lo revise antes de la siguiente llamada" ya permite elegir datos, permisos, herramienta y métrica.
2. Confundir una demo con un caso de uso
Una demo está diseñada para sorprender. Un caso de uso tiene que sobrevivir a las excepciones, a los datos incompletos y a la rutina de una persona que tiene prisa.
En una demostración todo suele estar preparado: el documento correcto, el prompt adecuado y una respuesta que se puede enseñar. En producción aparecen preguntas más incómodas:
- ¿Qué sucede cuando falta un dato?
- ¿Cómo se distingue una respuesta fiable de una respuesta bien redactada?
- ¿Qué pasa si dos documentos contienen instrucciones contradictorias?
- ¿Quién corrige la fuente cuando cambia una política?
- ¿Qué debe hacer el sistema cuando no tiene suficiente contexto?
Un caso de uso está listo para un piloto cuando tiene una entrada reconocible, una salida que alguien puede revisar y un criterio para decidir si mejora el proceso. Si solo tiene una demo atractiva, todavía está en fase de exploración.
3. Ignorar la calidad de los datos y los permisos
La IA no convierte automáticamente un repositorio desordenado en una base de conocimiento fiable. Si hay versiones duplicadas, nombres ambiguos, carpetas abandonadas y permisos heredados sin revisar, el asistente trabajará con el contexto disponible, no con el contexto que la empresa tenía en mente.
En entornos Microsoft 365 este punto tiene una doble cara. Las soluciones respetan los permisos que ya tiene cada usuario, pero eso no corrige permisos excesivos. Si una persona puede acceder a más documentos de los que necesita, una herramienta capaz de buscar y resumir información puede hacer visible ese exceso con mucha más rapidez.
Antes de conectar IA a un área conviene revisar:
- Propietarios de los sitios, equipos y bibliotecas.
- Grupos con acceso amplio y enlaces compartidos.
- Documentos obsoletos, duplicados o sin clasificación.
- Información personal, contractual o confidencial.
- Fuentes que el agente puede consultar y fuentes que debe ignorar.
La preparación del tenant y el gobierno de Copilot no son tareas que se hacen después de la IA. Son parte del producto que se está construyendo.
4. No asignar un responsable después del lanzamiento
Muchos proyectos tienen patrocinador, proveedor y equipo técnico, pero nadie que responda por la solución una vez publicada. El agente se queda sin dueño; el catálogo de prompts se abandona; las fuentes cambian y las respuestas empeoran sin que exista un circuito de revisión.
Todo caso de uso debería tener, como mínimo:
- Una persona responsable del resultado del proceso.
- Un propietario técnico o funcional de la configuración.
- Un procedimiento para actualizar las fuentes.
- Un canal para reportar respuestas incorrectas.
- Un criterio de retirada si deja de aportar valor.
No hace falta crear un comité para cada automatización. Sí hace falta que alguien pueda contestar a una pregunta sencilla: "¿Quién decide qué debe cambiar cuando esta solución se equivoca?"
5. Lanzar formación sin cambiar hábitos
Una sesión de dos horas puede enseñar dónde está un botón. No garantiza que una persona incorpore una nueva forma de trabajar.
La formación genérica suele fallar porque explica capacidades sin conectarlas con el trabajo real. El usuario sale sabiendo que puede resumir, redactar o generar una presentación, pero no cuándo debe hacerlo, cómo comprobar el resultado ni qué información no debe introducir.
La adopción mejora cuando la formación parte de situaciones reconocibles:
- Una reunión que termina con acuerdos difíciles de seguir.
- Un expediente que requiere consultar varias fuentes.
- Un informe que se prepara cada semana con los mismos pasos.
- Una bandeja de entrada que obliga a reconstruir contexto.
También hay que explicar los límites. Una respuesta fluida puede contener errores. Un resumen puede omitir una excepción. Un agente puede utilizar una fuente que ya no está vigente. La formación útil no promete que la IA acierta; enseña a trabajar con ella sin apagar el criterio profesional.
6. Medir actividad en lugar de resultado
Contar prompts, usuarios activos o sesiones puede ayudar a conocer el uso, pero no demuestra que el proyecto esté mejorando el negocio. Una plantilla puede generar miles de consultas y seguir tardando lo mismo en cerrar una tarea.
Antes del piloto conviene fijar una línea de referencia. Por ejemplo:
| Si el objetivo es... | No basta con medir... | Conviene observar... |
|---|---|---|
| Reducir tiempo de preparación | Número de prompts | Minutos hasta obtener un borrador revisable |
| Mejorar soporte interno | Consultas realizadas | Tiempo de resolución y escalados evitables |
| Aumentar consistencia | Documentos generados | Correcciones, excepciones y cumplimiento del formato |
| Reutilizar conocimiento | Visitas al agente | Respuestas resueltas y calidad de las fuentes |
La métrica no tiene que ser perfecta. Tiene que ayudar a decidir. Si el equipo no puede explicar qué evidencia justificaría mantener, ampliar o retirar el proyecto, todavía no tiene un sistema de medición.
7. Dar por terminado el proyecto al activar la solución
La activación es el comienzo de la operación. Los modelos cambian, las fuentes se actualizan, los permisos evolucionan y los usuarios descubren casos que no estaban en el diseño inicial.
Una solución empresarial necesita una revisión periódica que incluya:
- Uso real por área, perfil y caso de uso.
- Coste de licencias, consumo o infraestructura.
- Errores reportados y tiempo de respuesta.
- Calidad y vigencia de las fuentes.
- Cambios normativos, contractuales o de seguridad.
- Casos que deben ampliarse, rediseñarse o retirarse.
El marco de gestión de riesgos de IA de NIST organiza este trabajo en gobernar, mapear, medir y gestionar. No es una lista exclusiva para grandes laboratorios. Es una forma útil de evitar que una prueba se convierta en una dependencia sin responsable.
Qué hacer en lugar de cometer los siete errores
Un proyecto de IA razonable puede avanzar con un proceso sencillo:
- Elegir un proceso. No una tecnología. Describe quién trabaja, con qué información y qué fricción quieres eliminar.
- Definir el riesgo aceptable. Decide qué puede automatizarse, qué necesita revisión y qué queda fuera.
- Preparar el entorno. Revisa permisos, fuentes, clasificación, conectores y condiciones de uso.
- Diseñar una prueba pequeña. Incluye usuarios representativos, un responsable y una duración limitada.
- Medir antes y después. Combina uso, calidad, tiempo, coste y satisfacción del equipo.
- Tomar una decisión explícita. Escalar, corregir, cambiar de enfoque o cerrar. Las cuatro opciones son válidas.
Microsoft resume su orientación de implantación de Copilot en preparación técnica, habilitación de usuarios, escenarios y medición. La Comisión Europea, por su parte, plantea un marco basado en riesgos para los usos de IA. Las dos perspectivas apuntan a lo mismo: una solución útil necesita tecnología, contexto, personas responsables y reglas de operación.
La IA no necesita otro experimento: necesita un dueño y un caso útil
Cuando un proyecto de IA no funciona, la reacción habitual es cambiar de modelo o buscar una herramienta con más capacidades. A veces hace falta. Muchas veces no.
Antes de comprar otra licencia, revisa si existe un problema concreto, si los datos están preparados, si los usuarios saben cómo incorporar la solución y si alguien medirá el resultado dentro de tres meses. Si la respuesta es no, añadir tecnología solo hará más grande la confusión.
Recomendación de IntegroIA
Empieza con un diagnóstico breve: identifica los procesos con más fricción, revisa el estado de Microsoft 365 y prioriza un piloto que puedas medir. La pregunta no es qué puede hacer la IA, sino qué trabajo merece la pena cambiar primero.
Fuentes y fecha de revisión
Artículo revisado el 19 de agosto de 2026. Las fuentes se consultaron ese mismo día; sus contenidos y condiciones pueden cambiar.
- Microsoft Copilot Success Kit: implementación, preparación técnica y adopción
- NIST AI Risk Management Framework
- Comisión Europea: marco regulatorio de inteligencia artificial
La aplicación de obligaciones legales depende del caso de uso, el sector, el país y la función que desempeñe la organización. Este artículo es informativo y no sustituye una revisión jurídica.