Seguridad de las integraciones de IA: qué expones sin darte cuenta

Dónde está el riesgo de verdad

Ordenado por probabilidad de que te pase, no por lo interesante que suena.

• Permisos más amplios de lo necesario. El más común con diferencia.
• Datos que salen sin que nadie lo decidiera. Segundo en frecuencia y primero en consecuencias legales.
• Credenciales compartidas o embebidas. Tercero, y el que más tarda en descubrirse.
• Manipulación del modelo por la entrada. Real, y menos frecuente que los tres anteriores.

El cuarto es el que llena las presentaciones. Los tres primeros son los que producen los incidentes.

El orden de esa lista no es una opinión: sale de qué se encuentra al revisar integraciones ya montadas.

Los permisos amplios aparecen en casi todas. Los datos que salen sin decisión, en la mayoría. Las credenciales mal guardadas, en bastantes. La manipulación efectiva del modelo, en muy pocas, y casi siempre en sistemas que además tenían los otros tres problemas.

Que el cuarto sea el que más se discute y el primero el que más ocurre dice bastante sobre dónde se está poniendo la atención.

Permisos: el error del primer día

El patrón es siempre el mismo y no nace de un descuido: nace de la prisa por que la demo funcione.

Se necesita conectar el sistema, se usa la credencial que está a mano (la del administrador, la de la persona que lo montó), funciona, y ahí se queda. Nadie vuelve a revisarlo porque nada falló.

Datos que salen sin que nadie lo decidiera

Cada vez que una integración consulta a un modelo alojado por un tercero, algo de información de la empresa sale del perímetro.

Eso no es necesariamente malo y sí es una decisión que alguien tiene que tomar a propósito. El problema aparece cuando la toma el código sin que nadie la haya mirado.

Las tres preguntas que hay que responder antes de encender:

• Qué sale exactamente. No «datos del cliente», sino qué campos.
• Dónde queda. Retención del proveedor, en qué región y por cuánto tiempo.
• Si se usa para entrenar. Está desarrollado en si los datos de tu empresa entrenan la IA.

La primera es la que más sorprende. Es habitual que se mande el registro completo del cliente cuando la tarea sólo necesitaba dos campos, simplemente porque era más fácil mandarlo entero.

Hay una medida barata que resuelve buena parte de esto y casi nadie aplica: filtrar antes de mandar.

Si la tarea es clasificar un correo, el modelo no necesita el nombre del cliente ni su número de documento. Quitar esos campos antes de la llamada reduce la exposición sin cambiar el resultado.

Es la misma lógica de la anonimización de datos aplicada al punto donde el dato sale de la empresa.

Credenciales: el riesgo que tarda en verse

Tres formas de guardarlas mal, en orden de frecuencia:

• Dentro del código o de la configuración de una herramienta. Cualquiera con acceso al repositorio o al panel las ve.
• Compartidas por chat o correo durante el montaje, y ahí se quedan para siempre.
• Sin rotación. La misma clave desde el primer día, incluida la gente que ya no trabaja ahí.

La tercera es la más silenciosa. Una credencial que nunca caduca convierte cada salida de personal en un riesgo que nadie cierra.

El mínimo razonable: un gestor de secretos, una credencial por integración y rotación en el calendario. No es sofisticado y casi nadie lo tiene.

Manipulación por la entrada

Es el riesgo específico de la IA, y es real: un texto que llega desde fuera puede contener instrucciones que el modelo interprete como suyas.

El caso que importa en una empresa no es el usuario que intenta engañar al asistente. Es el contenido que entra solo: un correo, un documento adjunto, la descripción de un producto en un catálogo externo.

Si el modelo procesa ese contenido y además tiene permisos para actuar, la combinación es peligrosa aunque ningún usuario haga nada raro.

La contención no es del modelo: es de los permisos. Un sistema que sólo lee no puede hacer daño aunque lo manipulen. El detalle está en qué es un prompt injection.

El mínimo que hay que cerrar antes de encender

Seis puntos. Ninguno exige un equipo de seguridad y los seis se resuelven en días.

El tercero es el único que no es técnico y el que más protege legalmente, porque convierte una decisión implícita en una decisión tomada.

Cuándo dar permiso de escritura

La escritura es la línea donde una integración pasa de exponer información a poder cambiar el estado del negocio.

Tres condiciones antes de cruzarla, y las tres tienen que cumplirse a la vez:

• Alcance acotado a campos concretos, nunca a un objeto entero.
• Reversibilidad. Que se pueda deshacer lo que escribió, con registro de qué cambió y cuándo.
• Un límite de impacto. Monto máximo, número de registros por hora, o lo que aplique al caso.

Si alguna de las tres no se cumple, la integración se queda en lectura y la acción la ejecuta una persona a partir de lo que el sistema prepara.

Sobre la segunda condición, la reversibilidad: no significa que exista un botón de deshacer.

Significa que quede registrado qué había antes y qué quedó después, con fecha y con qué lo cambió. Con eso, revertir es trabajo manual pero es posible. Sin eso, no se puede ni saber qué habría que revertir.

Es la diferencia entre un incidente que se corrige en una tarde y uno que obliga a asumir que hay datos mal y no se sabe cuáles.

Qué preguntarle al proveedor

Cinco preguntas que separan a un proveedor que pensó esto de uno que lo va a improvisar contigo.

• ¿Con qué credencial se conecta y a nombre de quién está?
• ¿Qué campos exactamente salen hacia el proveedor del modelo?
• ¿Dónde queda el registro de llamadas y por cuánto tiempo?
• ¿Qué pasa si el sistema entra en bucle? ¿Hay tope?
• ¿Qué me entregas si terminamos el contrato?

La segunda es la que más cuesta responder con precisión, y por eso es la que más informa sobre con quién estás tratando.

La revisión trimestral que cierra el círculo

Todo lo anterior se degrada solo si nadie lo mira. Cuatro preguntas cada tres meses lo sostienen.

• ¿Siguen siendo mínimos los permisos, o alguien amplió alguno para resolver algo urgente?
• ¿Se rotaron las credenciales desde la última revisión?
• ¿Cambió qué datos salen, porque cambió el caso de uso?
• ¿Hay integraciones encendidas que ya nadie usa?

La última suele ser el hallazgo. Una integración olvidada sigue teniendo sus permisos, sigue consumiendo y no la vigila nadie, que es la peor combinación posible.

Sobre la primera pregunta, la de los permisos ampliados: conviene hacerla sin tono de reproche.

Cuando alguien amplía un permiso para resolver algo urgente, está haciendo su trabajo. El problema no es la ampliación, es que nadie la revierte después porque nadie recuerda que existió.

Un registro de cambios de permisos, aunque sea una hoja compartida, convierte esa revisión de una investigación en una lectura de dos minutos.