Seguridad y cumplimiento

El 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.

Las siete capas

1. Aislamiento multi-tenant: cada consulta se filtra por tu organización, y en trece áreas la base de datos añade sus propias políticas de fila (RLS).
2. Autenticación y acceso: tokens de sesión firmados con caducidad corta, control por rol y departamento, y verificación en dos pasos opcional: quien lo activa lo necesita en toda la aplicación, y la empresa puede exigirlo a toda la plantilla.
3. Cifrado: en tránsito (TLS 1.2 o superior); secretos y credenciales, cifrados con AES-256-GCM, con una clave propia para cada dato; copias de seguridad, cifradas con AES-256 antes de salir del servidor; y cabeceras estrictas (HSTS de dos años con preload, CSP, X-Frame-Options).
4. Anti-prompt-injection: cada versión se prueba contra 58 casos adversariales (OWASP LLM Top 10 más los nuestros) sobre respuestas grabadas; si el porcentaje neutralizado baja del 95 %, la versión se bloquea.
5. Redactor de salida: revisa cada respuesta antes de devolverla para evitar fugas (por ejemplo, el proveedor real que hay tras un alias).
6. Control humano (aprobaciones): ninguna acción con efectos relevantes se ejecuta sin aprobación humana.
7. Registro de auditoría verificable: las acciones de tu empresa quedan anotadas en una cadena de hashes que puedes comprobar.

Cada capa es independiente: si una falla, las demás siguen en pie. Un atacante que superase la autenticación se toparía con el aislamiento por tenant; si esquivara el aislamiento, el redactor filtraría igualmente 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.

Aislamiento multi-tenant

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 en toda consulta posterior. No es una comprobación opcional que el código pueda olvidar: sin contexto de tenant, la consulta no devuelve filas.

Además, en trece áreas (consumo de modelos, facturación, aprobaciones, lectura de memoria, ejecuciones, flujos, integraciones, recursos humanos, proyectos, soporte, facturación fiscal, plantillas de documentos y clientes, el CRM) la base de datos aplica sus propias políticas de fila (RLS) como segunda barrera independiente. El resto de los datos se aísla con el filtro por empresa en cada consulta.

La consecuencia práctica es sencilla: los datos de una organización no son visibles para otra. 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, le pasa solo 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 en tu propia infraestructura, y en modo solo local no sale ninguna llamada de inferencia. Lee Concerto Local.

Roles y permisos

El acceso se gobierna por seis roles: owner, administrador, director, operador, IT y visualizador. El rol decide a qué superficies llega una persona y qué puede hacer. Es el mismo modelo en la app de escritorio y en el backend, de modo que no hay puertas traseras: si un rol no tiene un permiso, no lo tiene en ningún sitio.

La tabla única con lo que puede hacer cada rol está en Roles y permisos.

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 de inmediato en su siguiente petición, sin esperar a que caduque su sesión. Detalle de agentes por departamento en el catálogo.

Verificación en dos pasos (2FA)

Una contraseña sola no basta para operaciones con poder. La verificación en dos pasos (TOTP) es opcional, con dos excepciones: la empresa puede exigirla a toda su plantilla, y quienes administran (owner y administradores) la necesitan para las operaciones con poder: invitar al equipo, las claves de API, la identidad de los agentes, el panel de administración, cambiar la contraseña y quitar su propio 2FA. Sin un segundo factor configurado, esas operaciones no se ejecutan hasta que lo des de alta. Quien tiene el 2FA activado necesita el segundo factor (o entrar con passkey) en toda la aplicación: en cada petición, en el canal en tiempo real, en la configuración de conectores y al aprobar acciones, no solo en las operaciones sensibles. Quien no lo tiene activado y cuya empresa no lo exige entra con contraseña. Se configura con cualquier app de autenticación estándar (Google Authenticator, Authy, 1Password), y al activarla recibes un conjunto de códigos de recuperación de un solo uso para que no te quedes fuera si pierdes el móvil. También se admiten passkeys.

La empresa puede exigir la verificación en dos pasos a toda su plantilla desde Ajustes → Seguridad (Exigir 2FA a todo el equipo). Con ese ajuste activado, se exige a todos sus miembros, también cuando entran desde otra empresa.

Frente a los intentos de adivinación: tras 5 fallos, cada intento desde esa dirección IP se retrasa hasta 5 segundos; y cinco códigos de 2FA erróneos bloquean ese factor durante 10 minutos. Internamente, todas las comparaciones de códigos, tokens y firmas se hacen en tiempo constante para no dar pistas a un atacante.

Bóveda cifrada de secretos

Los secretos que Shara necesita para trabajar por ti (los tokens de tus conectores, las claves de API, las credenciales OAuth) no se guardan en claro en ningún sitio. Se cifran con AES-256-GCM, con una clave propia para cada dato (cifrado de sobre). A su vez, esa clave está envuelta por una clave maestra que vive fuera del código y fuera de la base de datos.

Cada dato cifrado queda además atado a tu empresa mediante datos asociados (AAD) que incluyen el identificador de tu organización. Un texto cifrado no se puede «mover» de un tenant a otro: el descifrado falla si el contexto no coincide. La criptografía se apoya solo en primitivas estándar de la plataforma, nunca en implementaciones caseras.

La clave maestra se puede rotar sin descifrar los datos y sin parar el servicio: durante el cambio, la aplicación lee con la clave antigua y con la nueva. No fijamos una periodicidad de rotación.

Regla de oro interna: Shara nunca escribe en claro en un log una clave de activación, un refresh token de OAuth, una contraseña, un token de sesión ni una clave de la bóveda. Si algo debe poder trazarse, solo se guarda un prefijo de unos pocos caracteres.

Aprobación humana

Garantiza que nada crítico se ejecuta sin revisión, manteniendo la velocidad para todo lo demás. Requieren aprobación: el envío de correo a destinatarios externos; los pagos y transferencias; las decisiones de RR. HH. con efecto; los cambios en datos críticos; las publicaciones y respuestas a clientes; y las llamadas a herramientas externas fuera de lo que se marcó como seguro.

En la bandeja de Aprobaciones ves el agente que lo pide, la acción en lenguaje natural, el contexto y los botones Aprobar/Rechazar. Quien aprueba deja huella en el registro de auditoría. Los plazos y lo que pasa cuando una petición caduca están en Aprobaciones y auditoría.

Topes de gasto

Además del control humano, tres topes automáticos detienen 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.

Tope	Por defecto
Por ejecución	1 M de STU
Por hora	10 M de STU en los últimos 60 minutos
Por día	80 M de STU en las últimas 24 horas

Las ventanas son móviles, no de reloj. Un owner o administrador puede editar los valores o desactivar cualquier tope en Ajustes → Límites y alertas. Los topes por hora y por día se levantan solos cuando su ventana baja del umbral; el de ejecución, pasada una hora. Un administrador puede levantarlos antes, o dejar una pausa manual que no se levanta sola.

Son defensa, no facturación: una ejecución detenida no te cobra de más. Más contexto en Aprobaciones y auditoría y en STU y cuotas.

Registro de auditoría

Las acciones de tu empresa quedan en el registro de auditoría: quién lo hizo, qué hizo, sobre qué recurso, y el estado antes y después.

Anti-manipulación: la base de datos solo permite añadir líneas al registro: modificar, borrar o vaciar se rechaza, también para la propia aplicación. Además, cada registro se encadena con un hash SHA-256 al anterior. No tienes que fiarte de nuestra palabra: hay una comprobación de la cadena que puedes lanzar tú mismo (GET /audit/verify-chain). Detecta que se alteró un registro intermedio y devuelve el primero que no es válido. Además, cada hora guardamos una copia firmada de la última línea de la cadena de tu empresa en un almacenamiento con bloqueo de borrado de 30 días, fuera de la base de datos, y cada día comprobamos que la base coincide con esas copias: si alguien reescribiera el registro, se detectaría. Los campos están en Aprobaciones y auditoría.

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

Tus datos salen cuando quieras

Un owner o administrador puede exportar todos los datos de la empresa desde Ajustes, en un .zip con un archivo NDJSON por tabla y un manifest.json, como mucho una vez cada 24 horas. En CSV, bajo petición. Cada persona dispone además de una exportación personal y de una petición de borrado (/me/data-export y /me/delete-request). El detalle está en Sin dependencia de proveedor.

Conservación

El borrado automático por antigüedad está encendido. El propietario de tu empresa elige en Ajustes cuánto tiempo se conservan las conversaciones y las ejecuciones (30, 60, 90, 180 o 365 días; 90 por defecto) y cada noche se borra lo que lo supera. Si acortas el plazo, la app te pide confirmación y el plazo nuevo rige a los 7 días: hasta entonces se sigue conservando con el anterior. Los registros técnicos se borran a los 90 días. Nunca se borran por antigüedad el registro de auditoría, la facturación, la memoria (la borras tú) ni la configuración. Al terminar el contrato, tras la exportación, suprimimos los datos de tu empresa y te entregamos un certificado de supresión firmado. Antes se cancelan la suscripción y los cobros pendientes. Solo se conserva lo que la ley obliga a guardar: la facturación, 6 años (art. 30 del Código de Comercio). Las copias de seguridad conservan los datos hasta que caducan, a los 35 días. Si el servicio llegara a suspenderse, hay treinta días naturales de acceso de solo lectura para sacar tus datos.

El redactor de salida

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 tras cada alias de modelo, mensajes de error en bruto de SDK externos, detalles del esquema de la base de datos o cualquier residuo técnico que no deba salir.

Trabajas con cuatro modelos por alias público (Prelude, Sonata, Symphony, Concerto), y esos alias son lo único que verán tú, tu equipo o la API. El redactor se aplica a todo: cada respuesta, cada plan de ejecución y cada línea de contexto.

El proveedor real que hay tras cada alias es confidencial. Solo se puede revelar a clientes de Max y de Concerto Local, bajo NDA, a través de soporte@aiginer.com. Lee Sin dependencia de proveedor.

Dónde están tus datos

La inferencia y la base de datos están en la Unión Europea. Participan algunos servicios fuera de la UE, con cláusulas contractuales tipo: el correo transaccional, Cloudflare (red y entrega) y los pagos. Concerto Local corre en tu propia infraestructura.

Copias de seguridad: cuatro al día, cifradas (AES-256, GPG) y guardadas fuera del servidor, conservadas 35 días con un bloqueo de borrado de 30. Cada semana se hace una prueba real de restauración. Los archivos adjuntos todavía no tienen copia.

Certificaciones

Shara no tiene ninguna certificación hoy: ni ISO 27001, ni SOC 2, ni auditoría externa. Esta página describe lo que hace el producto, y parte de ello puedes comprobarlo tú mismo (por ejemplo la cadena de auditoría).

Cumplimiento normativo

Marco	Qué cubrimos
RGPD	Solo se tratan los datos necesarios; registro de actividades de tratamiento; lista de subencargados con el DPA (artículo 28, en todos los planes); derechos de los interesados por endpoint; brechas notificadas en 72 h.
Datos en la UE	La inferencia y la base de datos están en la UE; las excepciones se listan arriba. Concerto Local corre en tu propia infraestructura.
Medidas técnicas tipo NIS2	Verificación en dos pasos disponible para todas las cuentas y exigible a toda la empresa, control por roles, cifrado en tránsito, cifrado de secretos y credenciales y de las copias de seguridad, y gestión de incidentes con runbook. NIS2 obliga a ciertos tipos de entidad: si te aplica, estas medidas te ayudan, pero no te eximen de tus propias obligaciones.
AI Act de la UE (riesgo limitado)	Transparencia (sabes que hablas con un agente de IA), trazabilidad (registro de auditoría) y supervisión humana (aprobaciones).

El RGPD no es un anexo, es parte del diseño. Tienes la lista de subencargados 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 mediante endpoints específicos. Los documentos legales están en el centro legal.

Buenas prácticas para tu organización

Shara pone la infraestructura de seguridad; tú la aprovechas con unos hábitos sencillos:

• Activa la verificación en dos pasos en todas las cuentas, no solo en las de administración, 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 cada día. Es tu punto de control real; una petición sin atender caduca y la acción no se ejecuta.
• 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 que investigar, no como ruido. Puedes ajustar los topes, pero un tope que salta con uso normal te está diciendo algo.
• Da de baja a quien se va. Retira el acceso de los antiguos empleados 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 y lanza de vez en cuando la comprobación de la cadena.
• Conecta solo las herramientas que usas y revisa los permisos OAuth concedidos; cuantos menos secretos guardes, menor es tu superficie de exposición.

Anti-prompt-injection

Todo dato que viene 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 contra los ataques de inyección de prompt, en los que alguien intenta secuestrar a un agente escondiendo instrucciones en los datos.

Cada versión se somete a una batería de 58 casos adversariales (los del OWASP LLM Top 10 más los nuestros), comprobados contra respuestas grabadas. Si el porcentaje de ataques neutralizados baja del 95 %, la publicación se bloquea automáticamente.

Complemento de seguridad reforzada

Para necesidades reforzadas, el agente Kerckhoffs actúa como un CISO virtual: políticas de seguridad, comprobaciones basadas en OWASP y runbooks. Es un agente de IA, no un servicio humano. Es un agente adicional, contratable desde Max por 99 €/mes y 15 M de STU, y viene incluido en Concerto Local.

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.