Modelo de riesgo y clases de protección

La plena capacidad agentiva no significa que un agente pueda hacer cualquier cosa. Significa que el sistema puede describir de forma estructurada cada uno de sus estados y cada una de sus capacidades, incluidas las capacidades que permanecen vedadas a un agente de forma fundamental. El modelo de riesgo es la herramienta que traza este límite: preciso, legible por máquina y sin excepciones.

Áreas sensibles

Algunas partes de un sistema requieren una mayor protección, no solo frente a atacantes externos, sino también frente a agentes internos. Un error frecuente es:

El usuario puede verlo, por tanto la IA también puede verlo.

Eso no es correcto. El acceso efectivo de la IA resulta de la intersección de: permiso del usuario, permiso del agente, nivel de confianza del cliente, sensibilidad del recurso, propósito y estado de confirmación. Cada uno de estos elementos es una barrera propia, no solo el rol del usuario.

Entre las áreas sensibles que deben estar especialmente protegidas se incluyen:

• Datos financieros, datos bancarios, datos de pago, detalles de facturación
• Datos de salud, documentos médicos, historiales clínicos, certificados
• Datos salariales, salarios, bonos, historial salarial, ciclos de nómina
• Expedientes de personal, contratos, documentos de candidatura, evaluaciones internas
• Credenciales y claves API, contraseñas, claves privadas, tokens de acceso
• Funciones de eliminación masiva, eliminar usuarios, eliminar tenant, exportación masiva
• Gestión de permisos, otorgar y revocar permisos, cambiar roles
• Logs de seguridad, Audit Trails, eventos de seguridad, sesiones activas
• Comunicación privada, notas confidenciales, evaluaciones internas
• Datos fiscales y contratos, documentos fiscales relevantes, contratos con efectos legales
• Datos personales según RGPD, todos los datos que identifican a una persona física

Seis clases de protección

Cada recurso y cada herramienta se asigna a una de las seis clases de protección. La clase determina quién obtiene acceso, si un agente ve la herramienta en el Discovery y qué aprobación se requiere antes de la ejecución.

Public

Contenido de acceso público sin restricciones. No se requiere autenticación, ni rol especial, ni confirmación. Adecuado para artículos de ayuda, información de productos y capacidades documentadas del sistema.

help.article.read
public.product_info.read

Internal

Solo para usuarios autenticados. La autenticación es suficiente; no se necesitan derechos especiales. Típico para consultas de listas, búsquedas y vistas de trabajo generales del contexto propio.

project.list
contact.search

Confidential

Solo accesible con rol explícito y scope asignado. Un simple inicio de sesión no es suficiente. Los datos son internos, pero no están destinados a todos los empleados.

contract.read
customer_private_note.read

Sensitive

Solo con aprobación adicional o transferencia de contexto restringida. Un agente no puede cargar estos datos sin revisión en su contexto. Al transferirlos a una IA, el alcance debe estar estrictamente limitado y el propósito documentado.

salary.read
bank_account.read
health_document.read

Critical

La IA no puede actuar de forma autónoma en esta clase. Cada ejecución requiere una aprobación explícita del usuario, frecuentemente Step-up Authentication. Las acciones generan efecto externo, son difíciles de deshacer o afectan directamente a terceros.

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI

Esta clase es un límite estricto, no una decisión de política. Las herramientas y recursos de esta clase están completamente ocultos en el Tool Discovery para los agentes. Un agente no puede leerlos, invocarlos ni usarlos como referencia.

password.read
private_key.read
full_database_export
raw_access_token.read

El modelo de riesgo

El modelo de riesgo traduce las clases de protección en reglas operativas para cada caso de ejecución. Establece si se permite la autonomía, si se necesita confirmación y qué tipo de aprobación se exige.

Low

Operaciones puramente de lectura o acciones sin efecto externo permanente. Los agentes pueden invocar estas herramientas de forma autónoma.

Medium

Se crean o modifican datos o estados, pero dentro de un scope estrictamente definido sin efecto externo. La ejecución autónoma está permitida cuando el scope y el contexto se derivan inequívocamente del workflow.

High

Acciones que modifican estados relevantes del sistema o afectan a otros usuarios y recursos externos. Generalmente se requiere una confirmación explícita.

Critical

Comunicación externa, pagos, eliminaciones, cambios de permisos. Siempre confirmación, frecuentemente Step-up Auth. La ejecución autónoma no está permitida.

Forbidden

Completamente bloqueado para agentes de IA, ni en lectura ni en escritura. No visible en Discovery, no invocable, no utilizable como referencia.

UX de aprobación

El modelo de riesgo técnico solo funciona completamente cuando la interfaz de usuario cumple también su papel. Una confirmación es tan buena como la información sobre la que se otorga.

Antes de que un humano confirme una acción crítica de un agente, debe poder reconocer claramente siete cosas:

1. ¿Qué quiere hacer el agente?, La acción concreta, no la intención del agente en sus propias palabras.
2. ¿Por qué quiere hacer eso el agente?, Qué intent o encargo desencadenó esta acción.
3. ¿Qué datos se utilizan?, Destinatarios, adjuntos, entidades referenciadas.
4. ¿Qué efectos externos se producen?, Qué cambia fuera del sistema: se envía un correo, se activa un pago, se transmite un documento.
5. ¿Quién está afectado?, Personas, empresas, tenants, partes externas.
6. ¿Puede deshacerse la acción?, Declaración clara: reversible o irreversible.
7. ¿Qué ocurre al confirmar?, Descripción completa de los próximos estados del sistema.

El siguiente ejemplo muestra cómo es una tarjeta de aprobación completa para la herramienta emails.send_external:

El agente espera la decisión del usuario. No puede anticipar la confirmación, no puede establecer una acción predeterminada ni basar la ejecución en el timestamp de una aprobación anterior.