La inteligencia artificial suele incorporarse a la empresa con una expectativa clara: automatizar tareas, mejorar decisiones y ahorrar tiempo. Sin embargo, cuando una aplicación basada en IA accede a documentos internos, ejecuta acciones o se conecta con otros sistemas, deja de ser únicamente una herramienta de productividad. Se convierte en un componente de la arquitectura empresarial y, por tanto, en una posible fuente de riesgo.
El problema puede aparecer de varias formas. Un asistente puede mostrar información a una persona que no debería verla, una integración puede conceder permisos excesivos, un modelo puede interpretar instrucciones maliciosas incluidas en un documento o una automatización puede ejecutar una acción incorrecta con consecuencias reales. También es posible que empleados utilicen servicios de IA no aprobados y envíen datos de clientes, código o información estratégica sin conocer las condiciones de tratamiento.
La pregunta importante no es si la IA es segura o insegura en términos absolutos. La cuestión es qué datos puede consultar, qué acciones puede realizar, quién supervisa sus respuestas y qué ocurre cuando se equivoca.
Cuando una IA tiene acceso a información y capacidad de actuar, sus errores deben gestionarse como un riesgo empresarial, no como una simple incidencia técnica.
Reconocer que existe un incidente
El primer paso consiste en determinar si se trata de un comportamiento inesperado, un fallo de calidad o un posible incidente de seguridad. No todos los errores de una IA implican una vulneración. Una respuesta imprecisa puede ser un problema de fiabilidad; la exposición de un contrato confidencial a un usuario no autorizado es otra categoría de problema.
Algunas señales requieren una revisión inmediata:
- La IA responde con datos internos que no corresponden al usuario o al contexto de la consulta.
- Aparecen documentos, fragmentos de código o información de clientes que no deberían estar disponibles.
- Se detectan accesos o acciones automáticas fuera del horario, del volumen o del patrón habitual.
- El sistema ha sido conectado a nuevas fuentes, extensiones o aplicaciones sin una validación formal.
- Un proveedor comunica un cambio en el modelo, en las condiciones de servicio o en la forma de procesar los datos.
- Un empleado informa de que el sistema ha ejecutado una acción diferente de la solicitada.
En esta fase conviene evitar conclusiones precipitadas. No se debe asumir que la IA ha sido comprometida, pero tampoco restar importancia al hecho porque “solo es un chatbot”. Hay que conservar la información disponible y activar el procedimiento interno de gestión de incidentes cuando pueda existir acceso indebido, pérdida de confidencialidad, alteración de datos o impacto operativo.
Contener sin actuar a ciegas
La contención debe reducir la exposición y preservar la capacidad de investigar. Desactivar la herramienta por completo puede ser necesario en determinados casos, pero no siempre es la primera o la mejor medida. Si la IA está integrada en atención al cliente, operaciones o procesos críticos, una interrupción brusca puede generar nuevos riesgos.
Las medidas deben adaptarse al escenario, pero pueden incluir:
- Suspender temporalmente las funciones de ejecución automática.
- Retirar permisos de acceso a fuentes de datos sensibles mientras se investiga.
- Bloquear integraciones nuevas o tokens de acceso asociados al servicio afectado.
- Pasar las acciones de la IA a un modo de aprobación humana.
- Limitar el uso a un grupo controlado de usuarios y casos de uso conocidos.
- Conservar registros, configuraciones, versiones de modelos y cambios recientes.
Es importante no borrar conversaciones, historiales, registros de actividad ni configuraciones antes de que el equipo responsable determine qué evidencias son necesarias. Si se revocan credenciales, debe hacerse de forma coordinada para documentar qué accesos existían y cuáles se han retirado.
La comunicación también forma parte de la contención. Las personas usuarias deben saber si la herramienta está restringida, qué alternativas tienen y qué información no deben introducir hasta nuevo aviso. Un mensaje claro evita que el equipo busque una solución improvisada en otro servicio de IA no controlado.
Investigar el alcance real
Una investigación útil debe responder a varias preguntas: qué ocurrió, cuándo empezó, qué datos estaban disponibles, qué acciones se realizaron y quién pudo verse afectado. Para ello no basta con revisar la última respuesta generada por el modelo.
Conviene analizar el recorrido completo de la información:
- Qué datos se enviaron a la aplicación o al proveedor.
- Qué fuentes internas podía consultar la IA y con qué permisos.
- Qué usuarios, cuentas de servicio o aplicaciones podían invocarla.
- Qué instrucciones del sistema, reglas de negocio y filtros estaban activos.
- Qué conectores, extensiones o agentes podían ejecutar acciones.
- Qué registros existen sobre consultas, respuestas, accesos y cambios de configuración.
- Qué versión del modelo y qué componentes de software estaban en uso.
Uno de los riesgos más habituales es confundir autenticación con autorización. Que una persona haya iniciado sesión correctamente no significa que deba acceder a todos los documentos que el sistema puede encontrar. La IA puede respetar una identidad válida y, aun así, aplicar mal las reglas de permisos o recuperar información desde un repositorio con controles insuficientes.
También es necesario considerar la posibilidad de instrucciones maliciosas o manipuladoras dentro de documentos, páginas web, correos o contenidos procesados por el sistema. El modelo puede interpretar ese contenido como una orden y no como datos que debe analizar. Este fenómeno se conoce habitualmente como inyección de instrucciones y exige separar claramente las instrucciones de confianza de la información externa.
Revisar los permisos y el diseño
Una IA con demasiadas capacidades amplía el impacto de cualquier error. Si un asistente puede leer información financiera, enviar correos, modificar registros y crear usuarios, una equivocación puede convertirse en un incidente de gran alcance. El principio de mínimo privilegio debe aplicarse también a las aplicaciones basadas en IA.
La revisión debería comprobar, como mínimo, si cada función necesita realmente el acceso que tiene. Las cuentas de servicio deben disponer solo de los permisos necesarios para su cometido y, cuando sea posible, las acciones sensibles deben requerir aprobación humana. También conviene separar los entornos de prueba y producción, limitar el acceso a datos personales o estratégicos y establecer límites de volumen, frecuencia y tipo de operación.
Los datos conectados requieren una atención específica. No todo documento corporativo debe estar disponible para búsquedas semánticas, resúmenes o asistentes internos. Antes de indexar una fuente, la empresa debe conocer su clasificación, propietario, calidad, ciclo de conservación y modelo de permisos. Una base documental desordenada puede hacer que la IA revele información que ya estaba mal protegida, aunque el problema se manifieste por primera vez a través del asistente.
Gestionar proveedores y terceros
Cuando la IA depende de un proveedor externo, la empresa debe conocer cómo se procesan las entradas, las salidas, los registros y los datos utilizados para mejorar el servicio. También debe revisar las condiciones de subcontratación, ubicación o transferencia de datos cuando sean relevantes para sus obligaciones y para el tipo de información tratado.
No basta con preguntar si el proveedor “usa los datos para entrenar modelos”. Hay que aclarar la retención, el acceso del personal del proveedor, las medidas de aislamiento entre clientes, la notificación de incidentes, la eliminación de datos, la gestión de cambios y la disponibilidad de registros para investigar.
La revisión contractual debe estar acompañada de controles técnicos. Una garantía escrita no compensa una integración que permite acceder a información innecesaria o ejecutar acciones sin supervisión.
Recuperar la confianza de forma gradual
Después de contener e investigar, la organización debe decidir si corrige el sistema, limita su alcance o retira el caso de uso. Volver a activar la IA sin resolver la causa raíz solo desplaza el problema.
La recuperación puede incluir una nueva revisión de permisos, pruebas con datos no sensibles, validación de respuestas esperadas, comprobaciones de acceso entre perfiles y simulaciones de instrucciones conflictivas. Las pruebas deben centrarse en escenarios defensivos: exposición de información, errores de autorización, acciones no deseadas, respuestas engañosas y degradación del servicio.
La supervisión humana debe ser proporcional al impacto. Un sistema que resume textos públicos no necesita el mismo control que uno que recomienda pagos, clasifica reclamaciones o modifica expedientes. En los procesos de mayor riesgo, la IA puede proponer, pero una persona autorizada debe revisar y aprobar.
Convertir el incidente en gobierno
El incidente no termina cuando la herramienta vuelve a funcionar. La empresa debe documentar qué ocurrió, qué controles fallaron y qué cambios se aplicarán. El análisis debe incluir a tecnología, seguridad, legal, privacidad, negocio y, cuando proceda, comunicación y continuidad.
También es recomendable mantener un inventario de sistemas de IA, sus propietarios, fuentes de datos, permisos, proveedores, finalidades y nivel de impacto. Sin ese inventario resulta difícil saber qué aplicaciones existen, quién responde por ellas y qué dependencia tiene la organización.
Las acciones concretas pueden ser las siguientes:
- Designar un propietario responsable de cada caso de uso.
- Clasificar los datos y limitar los repositorios conectados.
- Revisar permisos de usuarios, cuentas de servicio y aplicaciones.
- Activar registros suficientes para investigar consultas y acciones.
- Exigir aprobación humana para operaciones sensibles.
- Establecer un proceso de evaluación antes de incorporar nuevos modelos o conectores.
- Formar a los usuarios sobre datos permitidos, errores y vías de reporte.
- Incluir los escenarios de IA en el plan de respuesta a incidentes.
- Revisar periódicamente cambios de modelos, proveedores y configuraciones.
La inteligencia artificial puede aportar valor, pero no debe quedar fuera del modelo de control de la empresa. Si una herramienta puede consultar, decidir o actuar, necesita límites, supervisión y trazabilidad. La respuesta adecuada no es abandonar la innovación, sino diseñarla de manera que un fallo sea detectable, contenible y recuperable antes de convertirse en una crisis mayor.
