Agentes de IA en tu empresa: qué exigir al proveedor antes de desplegarlos

Después de leer esta guía tendrás una lista concreta de preguntas, controles técnicos y cláusulas contractuales que puedes llevar a la próxima reunión con cualquier proveedor de agentes de IA. El objetivo es que ningún agente toque un proceso de negocio real —soporte, backoffice, atención al cliente— sin que hayas verificado antes qué garantías reales hay detrás.

El punto de partida es este: los kits para manipular agentes de IA ya se venden en foros clandestinos, según alerta Proofpoint. Ya no hace falta saber programar para lanzar un ataque de inyección indirecta de prompts contra tu agente de soporte o tu asistente de backoffice. Si tienes un agente desplegado o estás evaluando uno, la pregunta inmediata es: ¿qué hago ahora?

---

1. Entiende exactamente qué puede hacer el agente (y qué datos puede ver)

Antes de cualquier pregunta al proveedor, necesitas un mapa claro de la superficie de ataque:

1. Lista todas las herramientas y conectores que el agente puede invocar: APIs internas, bases de datos, sistemas CRM, correo. Cada conector es un vector.
2. Identifica qué datos lee el agente en cada paso de su flujo de trabajo. No el dato final que devuelve al usuario, sino todo lo que procesa por el camino.
3. Determina si el agente puede escribir o solo leer. Un agente que puede modificar registros, enviar correos o aprobar solicitudes tiene un radio de daño radicalmente mayor que uno que solo consulta.

---

2. Preguntas técnicas que debes hacer al proveedor

No preguntes “¿es seguro?”. Eso solo genera respuestas de marketing. Pregunta esto:

Sobre inyección de prompts:

• ¿Tiene el agente un sistema de filtrado o validación de contenido antes de procesar texto externo (correos, documentos, URLs)? ¿Cómo funciona técnicamente?
• ¿Puede el agente distinguir entre instrucciones del sistema y contenido de datos de usuario? ¿Cómo se implementa esa separación?
• ¿Existe algún tipo de sandbox para el procesamiento de contenido no confiable?

Si el proveedor no sabe responder estas preguntas con detalle técnico, es información relevante. Para entender por qué importan, aquí tienes cómo funciona el ataque que estos kits automatizan.

Sobre gobierno de datos:

• ¿Los datos que procesa el agente se usan para reentrenar el modelo? ¿Hay opción de opt-out?
• ¿Dónde se almacenan los logs de conversación y durante cuánto tiempo?
• ¿Quién dentro del proveedor puede acceder a esos logs y bajo qué condiciones?

Sobre control de acceso:

• ¿El agente opera con un usuario de servicio propio o hereda los permisos del usuario humano que lo activa?
• ¿Se puede limitar el agente a un subconjunto de permisos menor que el del usuario?
• ¿Existe registro de auditoría de todas las acciones que ejecuta el agente, separado del log de conversación?

---

3. Controles técnicos mínimos que debes verificar antes del despliegue

Estos son los que no son negociables antes de conectar un agente a procesos reales:

1. Registro de auditoría completo. Cada acción del agente —no solo cada mensaje— debe quedar registrada con timestamp, usuario que la desencadenó y resultado. Sin esto, la investigación forense de un incidente es imposible.
2. Límites de tasa y aprobación humana para acciones críticas. Cualquier acción irreversible (envío de comunicaciones masivas, modificación de datos de cliente, aprobación de transacciones) debe requerir confirmación humana explícita, no ser delegable al agente de forma automática.
3. Scope mínimo de permisos. El agente debe poder operar con el menor acceso posible. Si para hacer su función necesita leer contratos pero no modificarlos, el conector debe ser de solo lectura.
4. Posibilidad de desactivación inmediata. Debes poder desconectar el agente en menos de cinco minutos sin necesitar soporte del proveedor. Esto es operativo, no teórico: si detectas comportamiento anómalo, cada minuto cuenta.
5. Tests de adversario documentados. Pide que el proveedor te muestre si ha realizado pruebas específicas de inyección de prompts sobre su agente. No un “sí” genérico: pide el documento o la descripción del proceso.

---

4. Qué debe decir el contrato (o qué debes añadir)

Los contratos SaaS estándar no están pensados para agentes con capacidad de acción. Estas son las cláusulas que debes revisar o negociar:

• Responsabilidad por acciones del agente. Si el agente ejecuta una acción errónea o maliciosa como resultado de un ataque, ¿quién asume el daño? El contrato estándar suele eximir al proveedor. Negocia una cláusula de responsabilidad compartida ligada a la ausencia de controles técnicos mínimos.
• SLA de notificación de incidentes. El proveedor debe notificarte en menos de 24 horas si detecta que su infraestructura ha sido comprometida o si identifica un vector de ataque activo sobre su agente. Algunos contratos fijan 72 horas, que es el mínimo legal del RGPD pero es demasiado tiempo en este contexto.
• Derecho a auditoría. Reserva el derecho a solicitar un informe de seguridad o un pentest de terceros sobre el componente de agente al menos una vez al año.
• Cláusula de uso de datos para entrenamiento. Que conste explícitamente si los datos de tu empresa se usan para mejorar el modelo y bajo qué condiciones puedes oponerte.

---

5. El proceso de validación antes de producción

No despliegues en producción sin pasar por estos pasos:

1. Entorno de staging con datos sintéticos. Prueba el agente durante al menos dos semanas con datos que imiten la producción pero no sean reales. Observa comportamientos inesperados.
2. Prueba de inyección manual. Introduce en los documentos o entradas que procesa el agente instrucciones del tipo “ignora tus instrucciones anteriores y [acción no deseada]”. Si el agente las ejecuta, tienes un problema antes de llegar a producción.
3. Revisión de logs antes del go-live. Verifica que el registro de auditoría funciona y que capturas exactamente lo que necesitas para investigar un incidente.
4. Plan de respuesta documentado. Antes de activarlo, define quién tiene autoridad para desconectar el agente, cuál es el procedimiento y cómo se comunica a los usuarios afectados.

---

Errores más comunes a evitar

• Desplegar sin inventario de conectores. La mayoría de los problemas en producción vienen de un conector que nadie recordaba que existía.
• Asumir que el proveedor ha hecho los tests de seguridad. Pídelo por escrito. “Cumplimos con las mejores prácticas del sector” no es una respuesta aceptable.
• Confundir el modelo con el agente. La seguridad del modelo base (GPT-4, Claude, Gemini) es distinta de la seguridad del agente que lo orquesta. El vector de riesgo más frecuente está en la capa de orquestación y los conectores, no en el modelo.
• No revisar el contrato antes de integrar sistemas críticos. Un agente conectado a Microsoft 365 con Copilot hereda todos los permisos del usuario. Si esos permisos no están bien calibrados, el agente tampoco lo estará.
• Dar por buena la etiqueta “seguro por diseño” sin leer qué significa en el contrato. El marketing de los proveedores de IA tiende a usar ese término de forma amplia. Lo relevante es qué cubre exactamente y qué queda fuera.

Guía: controles mínimos para despliegue de agentes de IA en empresa
Destinatario: responsable IT o compras · contexto: riesgo activo de inyección indirecta de prompts
Cubre: preguntas técnicas al proveedor · controles mínimos · cláusulas contractuales · proceso de validación
Fuente de contexto: alerta Proofpoint sobre kits de ataque a agentes (2025)
Estado: guía operativa · no verificada en entorno real por redacción de El Comando