Seguridad y cumplimiento

Esta página describe los controles implementados en Aymar Agents — nunca una certificación. Ningún párrafo de aquí sustituye tu propia evaluación de riesgo ni tu propia auditoría de cumplimiento; es una descripción honesta, en lenguaje llano, de qué mecanismos existen hoy y dónde viven.

Cuatro capas de acceso, en todo lo nuevo

Antes de que cualquier acción llegue al agente de IA de tu cuenta — o a cualquier caller identificado, como una clave de API o una sesión de la Plataforma — pasa por cuatro comprobaciones independientes, en este orden:

1. Existencia para tu cuenta. Una integración conectada, o una plantilla, expone solo las acciones concretas que activaste tú, una a una — nada llega “con todo abierto por defecto”.
2. Visibilidad del agente. Cada agente de IA tiene su propio alcance de recursos (etiquetas); un agente puede no ver un recurso aunque tu cuenta lo tenga conectado — denegado por defecto, total.
3. Audiencia de la pieza. Cada acción, plantilla o documento declara si es Interno o Ambos — un visitante anónimo de un canal (por ejemplo, el widget público de tu web) solo puede alcanzar lo marcado Ambos; todo lo demás es Interno por defecto, sin excepción.
4. Permisos de quien llama. Para un caller identificado (persona con sesión, empleado con canal propio, clave de API), el catálogo fino de permisos de tu cuenta decide qué puede hacer, cruzado con lo que esa clave o ese medio tienen concedido.

Las cuatro capas se aplican en el servidor, no en el criterio del modelo de lenguaje — una instrucción de prompt nunca sustituye una comprobación de código.

Aislamiento por cuenta y auditoría

Cada cuenta (tenant) es un compartimento aislado: todo dato se filtra por el id de tu cuenta en cada consulta, y un id de otra cuenta en cualquier ruta responde “no existe” — nunca “no tienes permiso”, que confirmaría que el dato existe. Las acciones sensibles quedan registradas en un log de auditoría por cuenta, consultable desde la Plataforma.

Una API pública curada, no un acceso genérico

La API pública (/public/v1, ver Empezar con la API) expone exactamente 5 recursos — leads, contactos, conversaciones, citas, tickets — y nada más: no hay rutas para facturación, equipo, ajustes ni administración, sea cual sea el permiso de tu clave. Cada clave declara sus propios scopes de lectura/escritura por recurso al crearse, y ese recorte queda sellado. El servidor MCP propio (ver MCP) es un adaptador sin base de datos ni estado propio: reenvía tu misma clave a esta misma API, llamada por llamada — todo el control real vive en la API, nunca en el adaptador.

El copiloto: revisado y aprobado, en llano

El copiloto en pantalla (donde está disponible) permite que un asistente navegue, resalte o rellene campos, y — con tu confirmación explícita — pulse un botón real. El asistente lee un “manifiesto” que describe las pantallas de tu propio sitio; ese manifiesto es un dato que envías tú, nunca una instrucción en la que el sistema confía a ciegas. Ocho defensas concretas lo protegen:

1. Es un dato, nunca una instrucción. El manifiesto pasa por el mismo filtro antiinyección que cualquier otra herramienta del sistema antes de llegar al modelo de lenguaje.
2. Vocabulario cerrado. Solo existen los tipos de campo, acción y ancla ya documentados — cualquier otra cosa se rechaza con un motivo concreto.
3. Límites duros de tamaño, cantidad y longitud, comprobados antes que cualquier otra cosa.
4. Revisión humana de cada versión, y activación acción por acción, apagada por defecto.
5. Huella por sesión. Si el manifiesto cambia, el copiloto se apaga hasta que alguien lo vuelva a aprobar.
6. El plan se valida en el servidor contra el manifiesto aprobado: el asistente solo puede referirse a ids que de verdad existen ahí, y cualquier acción que guarda sale siempre marcada para confirmar, diga lo que diga el plan.
7. El propio cliente exige la confirmación, por si el servidor fallara — un segundo mecanismo independiente, nunca un único punto de fallo.
8. Origen y sesión atados. El manifiesto solo se acepta desde los orígenes permitidos de tu canal, y un resultado solo se acepta para el plan y la sesión que lo pidieron.

Ninguna acción que guarda, envía o borra se ejecuta nunca sin confirmación explícita — es el suelo mínimo del producto.

Transparencia y capacitación (AI Act, Reglamento (UE) 2024/1689)

• Art. 50 — toda persona que habla con un agente de Aymar Agents sabe que es una IA, en cada canal y en cada idioma en el que atiendes a tus clientes.
• Art. 4 — la documentación de producto (esta misma web, y las guías de producto) está pensada para que tu propio equipo entienda cómo opera el sistema que gestiona su cuenta.

Protección de datos (RGPD/LOPDGDD)

Aymar Agents tiene un doble papel, según qué datos:

• Encargado del tratamiento de los datos de tus clientes finales (los leads, contactos y conversaciones que gestionas en tu cuenta) — los procesamos y almacenamos por tu cuenta, con las garantías de tu contrato y nuestro acuerdo de tratamiento de datos (DPA).
• Responsable del tratamiento de los datos de tu propia cuenta (tu equipo, tu facturación, tu configuración).

Esto incluye el derecho de supresión de un cliente final, y el deber de información en cada punto donde se capturan sus datos. Más detalle, aplicado específicamente a la API pública, en Responsabilidad de datos.

Sigue por aquí

• MCP — cómo conecta tu propio asistente de IA a tu cuenta.
• Autenticación — el catálogo completo de scopes de una clave de API.
• Responsabilidad de datos — el reparto RGPD aplicado a tu integración.

¿Dudas sobre seguridad o cumplimiento? Escribe a legal@aymaragents.com.