Un equipo de IT despliega un asistente de IA para resolver tickets de soporte de primer nivel, pensando que así liberará tiempo para incidencias más complejas. Semanas después descubren que el agente ha estado compartiendo fragmentos de configuración interna en respuestas a usuarios que no deberían verla, y que varios tickets críticos se quedaron "resueltos" por el bot cuando en realidad seguían abiertos. La tecnología funcionó exactamente como se le configuró: el problema es que nadie definió con suficiente cuidado qué podía tocar y cuándo debía ceder el control a una persona.
La mayoría de fracasos de IA en IT no vienen de un modelo que "alucina" una respuesta, sino de errores de proceso: desplegar agentes sin política de seguridad clara, sin criterios de escalado a humano y sin el mismo rigor de pruebas que se exige a cualquier cambio en producción. Son errores evitables, y detectarlos a tiempo es lo que diferencia un asistente que realmente reduce la carga del equipo de soporte de uno que multiplica los incidentes que antes no existían.
Además, estos errores suelen originarse en cómo se gobernó el proyecto desde el principio, no en un fallo técnico puntual. Corregirlos antes de dar acceso del agente a sistemas y datos reales cuesta una política de uso bien redactada; descubrirlos después de un incidente de seguridad o de un SLA incumplido puede costar la confianza de toda la organización en el propio departamento de IT.
Acceso a datos sin política de seguridad clara
El primer error habitual es desplegar copilots o asistentes de IA sin definir con precisión qué datos y sistemas pueden consultar, y sin segmentar ese acceso según quién hace la pregunta. Un agente conectado de forma genérica a la documentación interna, a repositorios de código o a configuraciones de infraestructura puede acabar exponiendo información sensible a usuarios que nunca deberían haber tenido acceso a ella, simplemente porque nadie limitó el alcance antes de ponerlo en marcha.
El segundo error es automatizar la resolución de tickets sin un criterio claro de cuándo escalar a un técnico humano. Cuando el agente intenta resolver por su cuenta incidencias que exceden su alcance —problemas de red complejos, fallos de seguridad, errores intermitentes difíciles de reproducir— y no lo hace bien, el ticket puede quedar marcado como resuelto sin estarlo, o el usuario pierde tiempo valioso siguiendo instrucciones genéricas que no aplican a su caso concreto, hasta que finalmente alguien humano tiene que retomarlo desde cero.
En la práctica, este segundo error es especialmente costoso porque erosiona la confianza de los propios usuarios internos en el soporte de IT: una vez que alguien ha tenido una mala experiencia con el bot, tiende a evitarlo por completo, incluso para incidencias donde sí funcionaría bien.
Cambios sin testear ni gobierno sobre qué herramientas se usan
El tercer error es permitir que un agente de IA modifique scripts, configuraciones o parámetros de sistemas sin someter esos cambios al mismo proceso de revisión y control de versiones que se aplicaría a un cambio hecho por una persona. Un ajuste automático que parece menor puede tener efectos en cascada sobre otros sistemas, y sin un registro claro de qué cambió, cuándo y por qué, diagnosticar un problema derivado se vuelve mucho más lento que si el cambio lo hubiera hecho un ingeniero siguiendo el proceso habitual.
El cuarto error es la falta de gobierno sobre qué herramientas de IA usa cada equipo dentro de la organización. Cuando distintos equipos adoptan asistentes o copilots por su cuenta, sin pasar por IT, se genera lo que en la práctica es shadow IT de IA: herramientas con acceso a datos corporativos que nadie ha auditado, que no siguen la misma política de seguridad y que multiplican la superficie de riesgo sin que el propio departamento de IT lo sepa.
Este tipo de error suele detectarse solo cuando ya se ha producido una fuga de información o un incidente de seguridad, porque hasta ese momento cada equipo considera que su herramienta "solo la usan ellos".
No medir el "antes" ni tener un responsable claro
Más transversal, pero igual de decisivo, es lanzar el proyecto sin establecer una línea base: tiempo medio de resolución de tickets, tasa de reapertura, número de incidentes de seguridad previos. Sin esos datos, es imposible demostrar después si la IA mejoró realmente el soporte o solo cambió dónde se generan los problemas. A esto se suma la falta de un responsable único dentro de IT: cuando "el equipo" en general es dueño del agente, en la práctica nadie revisa sus decisiones ni actualiza sus permisos con la disciplina que la seguridad exige.
Ese responsable no tiene que ser el CTO ni dedicar su jornada completa al proyecto; basta con que una persona concreta tenga la tarea explícita de auditar semanalmente los accesos del agente, revisar tickets reabiertos y decidir qué ajustar. Sin ese punto de control, los permisos excesivos y los criterios de escalado mal calibrados se quedan como están indefinidamente, hasta que un incidente obliga a revisarlos con urgencia.
Cómo detectar a tiempo que algo se está torciendo
La señal más temprana suele estar en los propios tickets reabiertos: si su número no baja, o si los usuarios empiezan a pedir explícitamente "hablar con una persona" en lugar de usar el asistente, el proyecto se está torciendo aunque las métricas generales de volumen atendido parezcan buenas. Conviene revisar cada dos semanas indicadores concretos —tickets reabiertos, tiempo hasta escalado, alertas de acceso a datos sensibles— y compararlos con la línea base. Este patrón de revisión se explica con más detalle en señales de que tu implementación de IA va por mal camino, y en qué hacer si tu primera implementación de IA no funcionó se plantea cómo corregir el rumbo sin desmontar todo el proyecto.
Para quien todavía está en fase de diseño, primeros pasos para implementar IA en tu empresa recoge cómo establecer desde el inicio los controles de acceso y gobierno que evitan buena parte de estos errores.
Conclusión
Los errores comunes al implementar IA en IT casi nunca son de tecnología: son de gobierno, de accesos mal delimitados y de procesos de escalado y control de cambios que se relajan justo cuando más falta hacen. Dar acceso sin política de seguridad, automatizar tickets sin criterio claro de escalado, saltarse el testeo de cambios y permitir shadow IT de herramientas no auditadas son, juntos, la combinación que más rápido convierte un proyecto de soporte en un riesgo de seguridad. Detectarlo a tiempo, con auditorías periódicas y un responsable claro, es lo que permite que la IA reduzca de verdad la carga del equipo sin abrir puertas que nadie debería haber dejado abiertas.
Si tu equipo de IT ya trabaja con IA y algo no cuadra, o estás valorando desplegar agentes y quieres evitar estos errores desde el diseño, pide un diagnóstico gratuito y lo revisamos juntos.