Seguridad y cumplimiento

Principio de SHARA: tus datos son tuyos y están protegidos por defecto, no por configuración. La seguridad se organiza en capas, desde el aislamiento entre clientes hasta el control humano de cada acción relevante. Nada de lo que hace un agente escapa al registro, y nada con impacto real se ejecuta sin que una persona lo apruebe.

1. Aislamiento multi-tenant: doble capa (base de datos + aplicación): cada consulta queda acotada a tu organización; sin ese contexto no se devuelve ninguna fila.
2. Autenticación y acceso: JWT firmado de expiración corta, control por rol y departamento, doble verificación obligatoria para el CEO y los administradores, y exigible a toda la plantilla si la empresa lo activa.
3. Cifrado: en tránsito (TLS) y en reposo, con un vault por tenant (AES-256-GCM) y cabeceras estrictas (HSTS, CSP, X-Frame-Options).
4. Anti-prompt-injection: cada release se testea contra ≥ 50 casos adversariales (OWASP LLM Top 10 + propios); si el % neutralizado baja del 95 %, la release se bloquea.
5. Redactor de salida: revisa cada respuesta antes de devolverla para evitar filtraciones (por ejemplo, el proveedor real detrás de un alias).
6. Control humano (approvals): ninguna acción con efectos relevantes se ejecuta sin aprobación humana.
7. Audit logs inmutables: cada llamada a un agente queda registrada de forma append-only y verificable.

Cada capa es independiente: si una falla, las demás siguen en pie. Un atacante que superara la autenticación se toparía con el aislamiento de tenant; si esquivara el aislamiento, el redactor seguiría filtrando la salida; y pase lo que pase, la acción quedaría en el registro de auditoría. Es defensa en profundidad, no un único muro.

Cada cliente es un tenant con su propio espacio lógico. En cuanto tu petición entra por la API, el middleware de contexto fija tu organización como filtro obligatorio de toda consulta posterior. No es una comprobación opcional que el código pueda olvidar: sin contexto de tenant, la consulta no devuelve filas. A esto se suma una segunda capa a nivel de base de datos (RLS, seguridad a nivel de fila) que actúa como red de seguridad.

La consecuencia práctica es sencilla: los datos de una organización nunca son visibles para otra, ni siquiera por error de programación. Un agente de tu empresa no puede leer el CRM, los correos ni los documentos de ningún otro cliente de SHARA. Y cuando Amadeus delega en un especialista, solo le pasa el contexto que esa tarea necesita, sin abrir el resto de tus datos.

En Concerto Local el aislamiento es físico además de lógico: la plataforma corre sobre tu propia infraestructura, y en modo solo local no sale ninguna llamada de inferencia. Lee Concerto Local.

El acceso se gobierna por seis roles canónicos. Cada persona de tu organización tiene uno, y ese rol decide a qué superficies llega y qué puede hacer. Es el mismo modelo en la app de escritorio, en el panel web y en el backend, de modo que no hay puertas traseras: si un rol no tiene un permiso, no lo tiene en ninguna parte.

Rol	Alcance	Qué puede hacer
CEO (owner)	Control absoluto	Único por organización. Llega a toda la aplicación: equipo, ajustes, Amadeus, sistema y dirección. Se asigna al activar la cuenta y no se puede modificar desde el panel.
Administrador	Mano derecha del CEO	Gestiona el equipo (salvo al propio CEO), ajustes y superficies de sistema. Acceso a Amadeus y a las aprobaciones.
Director	Su departamento	Recibe las decisiones cruciales que el agente delega, con aviso al empleado. Ve a su equipo en lectura y resuelve su bandeja de decisiones. Solo app de escritorio.
Operador	Su puesto	Trabaja con su agente departamental y sus herramientas. Es el trabajador de a pie. Solo app de escritorio.
IT	Salud técnica	Se asegura de que todo funcione e interconecte: integraciones, daemons y claves. Sin permisos de negocio (no toca dinero ni RRHH).
Visualizador	Solo lectura	Dashboards y reportes, sin ninguna capacidad de escritura. Ideal para perfiles que solo consultan.

El panel web (/panel/*) está reservado a CEO y Administrador: es donde se gestiona el equipo, la facturación y la configuración de la empresa. Directores y operadores viven en la app de escritorio, cada uno en su superficie. El rol de IT entra por la vista de salud técnica y Visualizador solo lee. Nadie que no sea CEO o Administrador puede cambiar roles ni dar de baja a compañeros.

El rol es la fuente de verdad de los permisos, y se lee en el momento: si degradas a alguien de Administrador a Visualizador, pierde el acceso al panel de inmediato en su siguiente petición, sin esperar a que caduque su sesión. Detalle de agentes por departamento en el catálogo.

La contraseña sola no basta para las cuentas con poder. La doble verificación (TOTP) es obligatoria para el CEO y los administradores, sin excepción y sin poder saltársela: si el rol la exige y la cuenta no tiene segundo factor, el acceso se corta hasta que se enrole. Se configura con cualquier app de autenticación estándar (Google Authenticator, Authy, 1Password), y al activarla recibes un juego de códigos de recuperación de un solo uso para no quedarte fuera si pierdes el teléfono.

Además, la empresa puede exigir la doble verificación a toda su plantilla desde Ajustes → Seguridad, no solo a los cargos. Con ese ajuste puesto, las superficies sensibles (claves de API, administración, alta de la empresa, cambio de contraseña y retirada del propio 2FA) la piden a cualquier miembro.

Las operaciones más sensibles (aprobar pagos, cambiar la configuración de seguridad, gestionar el equipo) exigen que tu sesión tenga el segundo factor validado. Internamente, todas las comparaciones de códigos, tokens y firmas se hacen en tiempo constante para no dar pistas a un atacante que intente adivinarlas por fuerza bruta, y los endpoints sensibles aplican un ralentizado progresivo tras varios intentos fallidos.

Los secretos que SHARA necesita para trabajar por ti (tokens de tus conectores, claves de API, credenciales OAuth) no se guardan en claro en ninguna parte. Viven en un vault cifrado con AES-256-GCM, con una clave derivada por tenant (scrypt): cada organización tiene su propio material criptográfico, de modo que el secreto de una empresa es ilegible con la clave de otra.

Además, cada dato cifrado se ata a su contexto mediante datos asociados (AAD) que incluyen el identificador de tu organización. Esto significa que un ciphertext no se puede «mover» de un tenant a otro aunque alguien lo interceptara: el descifrado falla si el contexto no coincide. El maestro de cifrado exige un mínimo de 32 caracteres y la criptografía se apoya solo en primitivas estándar de la plataforma, nunca en implementaciones caseras.

Regla de oro interna: SHARA nunca registra en claro una clave de activación, un refresh token de OAuth, una contraseña, un JWT ni una clave del vault. Si algo necesita trazarse, se guarda solo un prefijo de unos pocos caracteres.

Garantiza que nada crítico se ejecuta sin revisión, manteniendo la velocidad para lo demás. Requieren aprobación: envío de correo a destinatarios externos; pagos y transferencias (sin excepción); decisiones de RRHH con efecto (vacaciones, fin de contrato, bonus, nómina); modificación de datos críticos (eliminar clientes, vaciar tablas, config global); acciones del desktop/server agent fuera de la allowlist; publicaciones y respuestas a clientes; y llamadas a herramientas o API externas irreversibles.

En la bandeja Aprobaciones → Pendientes ves el agente solicitante, la acción en lenguaje natural, el contexto y los botones Aprobar/Rechazar. Quien aprueba deja traza en el registro de auditoría. Los plazos por severidad y qué pasa cuando una tarjeta caduca están en Aprobaciones y auditoría.

Además del control humano, tres cortes automáticos frenan la ejecución sin intervención de nadie en cuanto se supera un umbral de gasto. Son un cinturón de seguridad frente a un bucle inesperado, un prompt malicioso o una tarea mal calibrada: cuando saltan, la actividad se detiene y el administrador recibe una alerta.

Corte	Umbral	En STU	Qué corta
Por ejecución	5 € en un run	1 M STU	Corta el run y pausa la inferencia de la empresa.
Por hora	50 € en los últimos 60 min	10 M STU	Pausa la inferencia mientras la ventana siga alta.
Por día	400 € en las últimas 24 h	80 M STU	Pausa la inferencia mientras la ventana siga alta.

Las ventanas son rodantes, no del reloj, y los umbrales son fijos: no se suben desde el panel. Los cortes de hora y día se levantan solos cuando su ventana baja del umbral; el de ejecución, al cabo de una hora. Un administrador puede levantarlos antes, o dejar una pausa manual que no se levanta sola.

Son defensa, no facturación: un run frenado no te cobra de más, queda en el registro con el umbral que se cruzó para que puedas revisar qué lo provocó. Más contexto en Aprobaciones y auditoría y en STU y cuotas.

Cada llamada a un agente queda en un registro inmutable. Por cada ejecución se guarda quién la lanzó y con qué agente, el nivel de modelo usado (siempre por alias), el consumo de STU y los tokens de entrada/salida, la latencia, el estado, el antes/después de los datos afectados y la aprobación asociada si la hubo. Del prompt se guarda solo una huella criptográfica, nunca el contenido en claro, de modo que puedes auditar y correlacionar sin exponer datos sensibles.

Anti-manipulación: los registros son append-only y cada uno encadena el hash del anterior; si alguien modifica o borra un registro, la cadena se rompe. Y no hay que fiarse de nuestra palabra: existe una verificación de la cadena que puedes lanzar tú, y devuelve el primer registro inválido si lo hay. Ni siquiera el equipo de SHARA puede editar ni borrar el registro de auditoría.

La identidad corporativa (IDENTITY.md) también es auditable: evoluciona por parches versionados, nunca por reemplazo, y cada cambio queda registrado con su antes/después. Lee Identidad corporativa.

Antes de que cualquier respuesta llegue a ti, a un log o a un cliente, pasa por un redactor. Su trabajo es evitar que se filtre información interna: el nombre del proveedor real que hay detrás de cada alias de modelo, mensajes de error crudos de SDKs externos, detalles del esquema de la base de datos o cualquier residuo técnico que no debería salir.

Trabajas con cuatro modelos por alias público (Prelude, Sonata, Symphony, Concerto), y esos aliases son lo único que verás tú, tu equipo o la API. El proveedor real es confidencial por acuerdo de confidencialidad. El redactor se aplica a todo: cada respuesta, cada plan de ejecución y cada línea de contexto. Si algún día un agente devolviera un error de un servicio externo, el redactor lo limpia antes de que se guarde o se muestre.

Los aliases públicos cumplen el requisito de transparencia del AI Act sin exponer al proveedor real. Si un cliente pregunta por el modelo concreto, el agente responde con el alias y redirige a soporte@aiginer.com para la divulgación bajo NDA. Lee Sin lock-in.

Marco	Qué cubrimos
RGPD / GDPR	Solo se procesan datos necesarios; registro de actividades; lista de subprocesadores con el DPA; derechos ARCO por endpoint; brechas notificadas en 72 h.
Datos en la UE	La plataforma cloud opera en la UE y la inferencia se sirve desde infraestructura soberana europea. Concerto Local corre en tu propia infraestructura.
Medidas técnicas del tipo que pide NIS2	Doble verificación para administradores, control por rol, cifrado en tránsito y en reposo, y gestión de incidentes con runbook. NIS2 obliga a determinados tipos de entidad: si te aplica a ti, estas medidas te ayudan, pero no te eximen de tus propias obligaciones.
EU AI Act (riesgo limitado)	Transparencia (sabes que hablas con un agente IA), trazabilidad (audit logs) y supervisión humana (approvals).

El RGPD no es un anexo, es parte del diseño. Solo se procesan los datos necesarios para cada tarea, tienes la lista de subprocesadores en el acuerdo de tratamiento (DPA) que aceptas al activar la cuenta, y los derechos de tus interesados (acceso, rectificación, supresión, portabilidad) se ejercen por endpoints concretos. Toda la documentación legal está en el centro legal.

SHARA pone la infraestructura de seguridad; tú la aprovechas con unos hábitos sencillos. Recomendaciones para que tu configuración sea tan sólida como la plataforma:

• Activa la doble verificación en todas las cuentas, no solo en las obligatorias, y guarda los códigos de recuperación en un gestor de contraseñas.
• Aplica el mínimo privilegio. Da a cada persona el rol más bajo que le permita trabajar: un perfil que solo consulta debe ser Visualizador, no Administrador.
• Revisa la bandeja de aprobaciones a diario. Es tu punto de control real; una aprobación desatendida es una acción que no ocurre, pero también una tarea que se atasca.
• Configura tu horario laboral. Fuera de él se aplica el modo ahorro y es más fácil detectar actividad anómala.
• Trata cualquier corte de gasto como una señal a investigar, no como ruido: los umbrales son fijos y no saltan con el uso normal.
• Da de baja a quien se va. Retira el acceso de exempleados el mismo día; el rol se revoca al instante. El paso a paso está en Cuenta, equipo y accesos.
• Revisa el registro de auditoría periódicamente. Filtra por acción sensible (pagos, borrados, comunicación externa) para confirmar que todo lo aprobado tenía sentido.
• Conecta solo las herramientas que uses y revisa los permisos OAuth concedidos; cuantos menos secretos guardes, menor es tu superficie de exposición.

Todo dato que llega de fuera (un correo entrante, el contenido de un ticket, un documento) se trata como potencialmente hostil. SHARA envuelve ese contenido con marcadores que lo separan de las instrucciones del sistema, para que un texto no pueda hacerse pasar por una orden legítima. Es la defensa frente a los ataques de inyección de prompts, donde alguien intenta secuestrar a un agente escondiendo instrucciones en los datos.

Cada release se somete a una batería de más de 50 casos adversariales (los del OWASP LLM Top 10 más los nuestros). Si el porcentaje de ataques neutralizados baja del 95 %, la publicación se bloquea automáticamente: no sale a producción código que empeore esta defensa.

Para necesidades reforzadas, el agente Schneier actúa como CISO virtual con auditoría continua, alertas de uso anómalo y revisión periódica del log por un humano experto. Viene incluido en Max y superiores, sin cargo aparte.

Dudas de seguridad o reporte responsable: seguridad@aiginer.com. Documentación legal completa en el centro legal. El detalle del flujo de aprobaciones y del registro está en Aprobaciones y auditoría.