Cuando la IA se convierte en una identidad de máquina

La primera ola de seguridad para la IA empresarial se construyó alrededor de una advertencia conocida: no pegues información confidencial en un chatbot público.

La advertencia sigue siendo válida. Ya no es suficiente.

El cambio más importante es que los sistemas de IA están pasando de responder preguntas a recuperar datos, invocar herramientas y modificar otros sistemas. Cuando eso ocurre, el modelo deja de ser únicamente una interfaz conversacional. Pasa a formar parte de una identidad de máquina.

El modelo no determina el riesgo. Lo determinan la arquitectura y el caso de uso.

Un asistente público que resume un comunicado y un agente que puede modificar registros de producción podrían usar el mismo modelo subyacente. Sus perfiles de riesgo, sin embargo, son completamente distintos.

Empieza con cuatro preguntas

Antes de hablar de proveedores o de comparar modelos, responde estas preguntas para cada implementación de IA.

1. ¿Qué puede ver?

Mapea los datos que pueden entrar en los prompts, sistemas de recuperación, registros, conjuntos de evaluación y APIs externas. La lista puede incluir datos de clientes, información de empleados, contratos, código fuente, correo, bases de datos o historial de transacciones.

Este es el límite de confidencialidad. Debe estar clasificado, ser explícito y poder comprobarse; no debe depender de lo que “entienda” un prompt de sistema.

2. ¿Qué puede hacer?

Un chatbot quizá solo produzca texto. Un agente puede enviar correos, crear tickets, modificar registros, ejecutar scripts, consultar una base de datos o cambiar recursos en la nube.

Cuantas más cosas pueda hacer un sistema de IA, menos debe permitírsele decidir sin un control independiente, fuera del modelo.

3. ¿Bajo qué identidad opera?

Una carga de trabajo de IA puede utilizar la sesión de un usuario, un token OAuth, una cuenta de servicio, una clave API, una identidad administrada o una identidad dedicada de agente. Cada opción tiene consecuencias distintas para la autorización, la auditoría y la respuesta ante incidentes.

Trata las identidades de los agentes como identidades privilegiadas de máquina. Necesitan un propietario, un propósito, un conjunto acotado de permisos y un ciclo de vida.

4. ¿Podemos reconstruir lo ocurrido?

Para una acción de alto impacto, la organización debería poder seguir esta cadena:

usuario → aplicación de IA → prompt → datos recuperados → respuesta del modelo → herramienta → acción → resultado

Si no puedes reconstruirla, la detección y la respuesta serán una colección de suposiciones.

El plano de control importa más que el prompt

Los filtros de prompts pueden ayudar, pero no son un sistema de autorización. El modelo nunca debería ser la autoridad final para decidir si una acción está permitida.

Una arquitectura más segura coloca controles alrededor del modelo:

Usuario
  ↓
Política de identidad y acceso
  ↓
Aplicación de IA / gateway
  ↓
Autorización de datos y DLP
  ↓
Modelo
  ↓
Autorización de herramientas
  ↓
Sistemas empresariales aprobados

El modelo puede recomendar una acción. Una capa determinista de políticas debe decidir si la acción está permitida, si requiere aprobación humana y qué identidad la ejecuta.

Esta separación es especialmente importante para agentes, generación aumentada por recuperación (RAG) y protocolos de herramientas como MCP.

Cinco límites que merecen atención especial

Límite de datos: autoriza antes de recuperar

Un sistema RAG no debería recuperar todos los documentos y pedirle al modelo que decida cuáles puede ver el usuario. La autorización debe ocurrir antes de la recuperación.

identidad del usuario → autorización → documentos permitidos → recuperación → modelo

Aplica la misma regla a bases vectoriales, índices de búsqueda, contexto almacenado y citas generadas. Una respuesta limpia no demuestra que la ruta de los datos haya sido segura.

Límite de identidad: usa permisos específicos para cada tarea

Evita dar a un agente “todo lo que el usuario puede hacer”, salvo que ese comportamiento haya sido diseñado y revisado de forma deliberada. Es preferible una identidad de tarea con un rol estrecho.

Por ejemplo, un agente de facturas podría leer facturas, consultar datos de proveedores y preparar una propuesta de pago. No debería poder aprobar ese pago. La aprobación es una responsabilidad separada.

Límite de herramientas: trata el contenido externo como no confiable

La inyección de prompts no se limita a que un usuario escriba “ignora las instrucciones anteriores”. También puede llegar a través de una página web, un documento, un correo, un ticket o la descripción de una herramienta que el agente consuma.

La respuesta práctica es una defensa por capas:

• mantén el contenido externo dentro de un límite de confianza explícito
• valida la salida del modelo antes de pasarla a otro sistema
• autoriza las herramientas fuera del modelo
• limita las herramientas a una lista aprobada
• exige confirmación para las acciones sensibles
• reduce el contexto expuesto a cada tarea

Límite de la cadena de suministro: inventaría toda la ruta

Una aplicación de IA puede depender de un SDK, un framework de agentes, un proveedor de modelos, un modelo de embeddings, una base vectorial, un plugin y uno o más servidores de herramientas. El propio archivo del modelo también es un artefacto que puede necesitar procedencia, validación de integridad, revisión de licencia y análisis de seguridad.

El inventario de activos de IA debería registrar propietario, proveedor, modelo y versión, ubicación de despliegue, clasificación de datos, sistemas conectados, método de autenticación, nivel de riesgo y estado de aprobación.

Límite de observabilidad: registra lo necesario para investigar

En los sistemas de alto riesgo, registra al menos:

• identidad del usuario y del agente
• modelo y versión
• metadatos del prompt y de la respuesta
• documentos recuperados o sus identificadores
• herramientas invocadas
• aprobaciones y decisiones de política
• acciones realizadas
• violaciones de política
• consumo de tokens y actividad inusual

Los prompts pueden contener información sensible. Los registros de IA necesitan sus propios controles de acceso, reglas de retención y estrategia de redacción.

La autonomía debe reducirse cuando aumenta el impacto

Un principio operativo útil es sencillo:

La autonomía de la IA debe disminuir a medida que aumenta el impacto del negocio.

El comportamiento automático suele ser apropiado para resumir información pública o buscar en una base de conocimiento aprobada. Redactar un correo puede ser automático; enviarlo puede requerir condiciones. Modificar un registro, restablecer una cuenta, cambiar una regla de firewall o transferir dinero debería exigir un flujo de aprobación más fuerte.

Borrar una base de datos de producción no debería ser una capacidad disponible solo porque el agente técnicamente pueda llamar a la API.

Esto no es un argumento contra los agentes. Es un argumento a favor de una autonomía proporcional.

Una escala práctica de riesgo

Clasifica los sistemas según lo que pueden ver, lo que pueden hacer y las consecuencias de un fallo.

Riesgo mínimo: búsqueda de información pública, asistencia de escritura y lluvia de ideas de marketing sin datos sensibles.

Riesgo moderado: resumen de documentos internos, asistentes de programación y herramientas de conocimiento empresarial.

Riesgo alto: sistemas orientados a clientes, apoyo a decisiones con información sensible, análisis de fraude o flujos que influyen sobre personas o dinero.

Riesgo crítico: agentes con privilegios sobre infraestructura, administración de identidades, transacciones financieras autónomas y sistemas capaces de realizar cambios irreversibles.

Un nivel más alto debe activar requisitos más fuertes: modelado de amenazas, pruebas adversariales, monitoreo continuo, anulación humana y un interruptor de apagado probado.

Línea base para empezar hoy

• Mantén un inventario de los servicios de IA y herramientas conectadas que están aprobados.
• Publica una política de uso aceptable con clasificaciones de datos claras.
• Descubre y gestiona la Shadow AI; no asumas que no existe.
• Exige autenticación empresarial y MFA en los servicios administrados.
• Guarda las claves API y otros secretos en un vault, rótalos y asigna propietarios.
• Asigna a los agentes identidades específicas y permisos mínimos.
• Autoriza al usuario antes de recuperar documentos en RAG.
• Mantén un registro aprobado para MCP y otros servidores de herramientas.
• Envía la actividad de alto riesgo a la plataforma de monitoreo de la organización.
• Exige aprobación humana para acciones de alto impacto o irreversibles.
• Amplía la respuesta ante incidentes con desactivación del agente, revocación de credenciales y preservación del contexto.
• Prueba inyección de prompts, abuso de herramientas, filtración de datos y escalamiento de privilegios antes de pasar a producción.

Cómo organizar el programa

La seguridad de la IA funciona mejor como una capacidad de gobierno compartida, no como un proyecto aislado del equipo de seguridad. Privacidad, asuntos legales, riesgo, datos, arquitectura, tecnología y los responsables del negocio ven partes diferentes de la exposición.

Un flujo de aprobación liviano puede bastar para los casos de bajo riesgo:

caso de uso propuesto
  ↓
activo registrado
  ↓
nivel de riesgo asignado
  ↓
evaluación rápida o completa
  ↓
revisión de seguridad / privacidad / legal
  ↓
piloto y pruebas adversariales
  ↓
producción con monitoreo

Un conjunto útil de referencias es complementario, no competitivo:

• NIST AI RMF y el perfil para IA generativa para la gestión del riesgo.
• ISO/IEC 42001 para un sistema organizacional de gestión de IA.
• OWASP Top 10 para aplicaciones LLM para debilidades a nivel de aplicación.
• MITRE ATLAS para comportamiento adversario y modelado de amenazas.
• La CSA AI Controls Matrix para una implementación orientada a controles.
• La guía de Microsoft sobre identidades de agentes para consideraciones de diseño de identidad.

Ningún marco elimina la necesidad de criterio. Juntos ayudan a conectar gobierno, arquitectura, pruebas de aplicaciones y respuesta operativa.

La pregunta que debe acompañar cada revisión

No te detengas en “¿qué modelo vamos a utilizar?”. Pregunta:

¿Qué puede ver este sistema, qué puede hacer, qué identidad utiliza y cómo vamos a detenerlo cuando algo salga mal?

Esa es la diferencia entre adoptar la IA como una funcionalidad y gobernarla como una capacidad empresarial.