Riesgos de la IA en las empresas: cuáles son reales y cómo se gobiernan

Los riesgos de la IA en las empresas que importan no son los de la ciencia ficción. Son cinco cosas mundanas: un agente que se equivoca sin que nadie lo note, una dependencia de proveedor que no se ve hasta que duele, datos que salen por donde no deben, un incumplimiento que aparece en una inspección, y un sistema que se degrada porque nadie lo mantiene. Ninguno se resuelve confiando en que el modelo “es muy bueno”. Cada uno tiene un mecanismo y un control que lo gobierna.

He puesto agentes a trabajar en operaciones reales, y mi punto de partida con cualquier comité es siempre el mismo. El riesgo no se elimina, se acota y se hace visible. Una operación con personas también tiene riesgo, y no la paras por eso, le pones controles. Con agentes es igual, con una ventaja y una trampa. La ventaja es que buena parte de esos controles se puede codificar y aplicar en cada ejecución. La trampa es que, si no los diseñas, el sistema parece funcionar durante meses y falla en silencio.

El error silencioso

Una persona que duda pregunta. Un agente mal gobernado, no: aplica la regla que tiene y sigue. Si esa regla está mal, o el caso se sale de lo previsto, produce un resultado plausible y equivocado, y lo hace a la velocidad y el volumen de una máquina. Ese es el riesgo más caro que veo, porque no da la cara: no hay una alarma, hay una desviación que se acumula.

Se gobierna de tres maneras. Con evaluaciones antes de dar trabajo real: casos de prueba con respuesta conocida y umbrales de calidad, para saber en qué se equivoca antes de que lo haga con un cliente. Con escalado a una persona en los casos que exceden su mandato, en vez de forzar una respuesta. Y con trazabilidad, para que una desviación se pueda detectar y reconstruir. Un agente que ejecuta sin que puedas medir su tasa de acierto no es un agente productivo: es un pasivo que todavía no ha vencido.

La dependencia de proveedor

Aquí conviene separar dos cosas que se mezclan. Depender del proveedor de un modelo es tolerable: los modelos de Anthropic, OpenAI o Google son cada vez más una utility, se contratan por API y se sustituyen si otro rinde mejor en tu tarea. El riesgo real es más sutil: que tu operación quede codificada dentro de las primitivas de un fabricante o de un producto concreto, de forma que cambiar de proveedor signifique rehacer el sistema.

Ese riesgo se gobierna con arquitectura. Las reglas, los permisos, las trazas y las integraciones que definen tu operación deben poder vivir con independencia del modelo que haya debajo. Es la diferencia entre alquilar capacidad y quedar atado a ella, y es una de las razones por las que separo desde el inicio lo que es plataforma de lo que es tu arquitectura operativa. Lo he desarrollado en comprar o construir IA, donde la pregunta no es solo quién lo hace, sino qué te llevas si te vas.

La fuga de datos

Un agente trabaja con información: la lee de tus sistemas, la mete en un prompt, la manda a un modelo, la registra en una traza. Cada uno de esos pasos es una puerta por la que un dato puede terminar donde no debe. El riesgo no es teórico: un permiso demasiado amplio, un log sin control de acceso o un dato personal enviado a un servicio sin base jurídica bastan para convertir una mejora de productividad en un problema legal.

Se gobierna con el principio del menor privilegio y con higiene de datos. El agente accede solo a lo que su función necesita, con credenciales propias y acotadas, según he detallado en permisos y controles de agentes. Las trazas y los prompts se tratan como lo que son, datos que hay que proteger, minimizar y retener con criterio. La cara defensiva —ataques, inyección de instrucciones, exfiltración— pertenece a la seguridad de los agentes, y la cara legal, a la protección de datos y el RGPD.

El incumplimiento normativo

Poner un agente a decidir sobre pedidos, personas o dinero te mete, quieras o no, en un terreno regulado. El marco europeo de IA introduce obligaciones según el nivel de riesgo del uso, la normativa de protección de datos aplica desde el primer prompt que contiene un dato personal y tu propio sector puede añadir requisitos. El riesgo aquí es doble: incumplir sin saberlo, y no poder demostrar que cumples aunque cumplas.

Se gobierna con documentación y trazabilidad desde el diseño, no como parche tras una inspección. Qué hace el agente, con qué datos, bajo qué controles y con qué supervisión humana. Si eso está escrito y registrado, respondes a un auditor con hechos. He resumido qué implica el marco europeo para quien despliega agentes en AI Act y agentes de IA, y cómo se demuestra el cumplimiento caso a caso en auditar decisiones de agentes.

La degradación sin mantenimiento

El error más común que veo en los comités es tratar el despliegue como un proyecto con final. Un sistema de agentes no es una obra que se entrega: es una operación que hay que mantener. Los modelos cambian, tu proceso cambia, tus datos cambian, y las evaluaciones que ayer daban verde hoy pueden dar rojo sin que nadie mire. Un agente sin mantenimiento se degrada igual que una máquina sin él, solo que la avería no hace ruido.

Se gobierna con un ciclo, no con un proyecto: medir de forma continua, reevaluar cada vez que cambia un componente y tener a alguien responsable de que eso ocurra. Es el mismo patrón por el que tantos pilotos mueren al pasar a producción, que analicé en por qué fracasan los pilotos de IA. La demo es la parte fácil. La fiabilidad sostenida es la obra, y la obra no termina.

Cómo se ordenan estos riesgos

Ninguno de estos riesgos es motivo para no usar agentes, igual que el riesgo operativo no es motivo para no tener una operación. Son motivo para gobernarla. La tabla resume el mapa:

Riesgo	Mecanismo	Cómo se gobierna
Error silencioso	Aplica una regla mala a velocidad de máquina	Evaluaciones, escalado a humano, trazas
Dependencia de proveedor	La operación queda atada a primitivas de un fabricante	Arquitectura independiente del modelo, salida limpia
Fuga de datos	Permisos amplios, prompts y trazas sin control	Menor privilegio, higiene de datos, seguridad
Incumplimiento	Uso regulado sin documentación ni prueba	Documentación y trazabilidad desde el diseño
Degradación	Sistema sin mantenimiento tras el despliegue	Ciclo de medición y reevaluación continua

El marco completo con el que ordeno estos controles está en gobernanza de agentes, con el marco de gestión de riesgos de IA del NIST como referencia pública para contrastarlo, y la revisión que hago antes de aceptar un despliegue, en preparar tu empresa para agentes. Si quieres el terreno donde estos riesgos se materializan, están en una operación real con agentes; y si quieres el punto de partida, en agentes de IA para empresas.

Preguntas frecuentes

¿Cuál es el mayor riesgo de la IA en las empresas?

El error silencioso: un agente que aplica una regla equivocada de forma plausible, a velocidad y volumen de máquina, sin que nadie lo note hasta que la desviación es grande. Se gobierna con evaluaciones que midan su tasa de acierto, escalado a una persona en los casos límite y trazabilidad para detectar y corregir. No confiar en la calidad del modelo, sino medirla.

¿Es peligroso depender de un proveedor de IA?

Depender del modelo es tolerable, porque los modelos se sustituyen por API. El riesgo está en que tu operación quede codificada dentro de las primitivas de un fabricante o producto, de modo que cambiar cueste rehacer el sistema. Se acota manteniendo tus reglas, trazas e integraciones independientes del modelo, y pactando una salida limpia desde el contrato.

¿Puede una empresa mediana asumir estos riesgos sin un equipo técnico grande?

Sí, si los gobierna en lugar de ignorarlos. La cuestión no es el tamaño del equipo, sino quién se responsabiliza de las evaluaciones, los permisos, las trazas y el mantenimiento. Ese trabajo se puede construir dentro o contratar como operación gestionada, pero no se puede saltar: un despliegue sin él parece funcionar hasta que deja de hacerlo.

¿Cómo sé si mis agentes se están degradando?

Si no puedes responder, ya tienes la respuesta: te falta medición continua. Un sistema sano reevalúa cada vez que cambia el modelo, el proceso o los datos, y guarda el historial de esa medición. Sin ese ciclo, la degradación no se ve, y se descubre cuando un cliente o un auditor la señala.