Qué hacemos con tus datos, sin adornos

Aquí no hay sellos. Hay lo que está construido, cómo funciona y qué lo comprueba. Y al final, la lista de lo que todavía no tenemos, que es la parte que suele faltar en estas páginas.

7
Capas que atraviesa cada petición
58
Ataques de manipulación en la suite
34
Acciones que esperan tu firma
15.000+
Casos de prueba en el repositorio
Capas

Siete capas independientes

Que falle una no compromete las siguientes. Cada petición las atraviesa todas antes de tocar tus datos.

  1. 1

    La entrada

    Todo el tráfico pasa antes por Cloudflare: cortafuegos, límite de peticiones, protección contra ataques de denegación y verificación anti-robot en los formularios públicos.

  2. 2

    La identidad

    Sesión firmada y verificada en cada petición, con el algoritmo de la firma fijado por el servidor. Tras cinco fallos, cada intento desde esa dirección se retrasa hasta 5 s; cinco códigos de 2FA erróneos bloquean ese factor diez minutos.

  3. 3

    La empresa

    En cada petición se vuelve a comprobar en la base de datos a qué empresa perteneces y con qué permisos. Si te retiran el acceso, deja de funcionar al instante, no en la siguiente sesión.

  4. 4

    El permiso

    Cada operación comprueba dos cosas por separado: que tu papel puede hacerla y que tu plan incluye ese agente. Fallar cualquiera de las dos la detiene.

  5. 5

    Los secretos

    Las credenciales de tus conectores se guardan cifradas con AES-256-GCM. Cada credencial lleva su propia clave, envuelta por una clave maestra, y va atada a tu empresa: copiada a otra, no se descifra. Si no hay clave, no se guardan.

  6. 6

    La salida

    Todo lo que sale hacia ti pasa por un filtro que borra credenciales y oculta qué modelo hay detrás de cada agente. Y detrás del filtro hay un vigilante que vuelve a mirar.

  7. 7

    El registro

    Cada acción queda escrita con quién, cuándo y cuánto costó, y los registros van encadenados entre sí. Los topes de gasto cortan la ejecución solos si algo se dispara.

Acceso

Qué pasa cuando alguien intenta entrar

Cada paso es una comprobación independiente. Si una falla, no hay siguiente.

  1. 1

    Se filtra el tráfico

    Cortafuegos y límite de peticiones antes de que nada llegue a nuestros servidores.

  2. 2

    Se confirma de dónde vienes

    La dirección de origen se toma de la red, no de una cabecera que el visitante pueda escribir a mano.

  3. 3

    Se frena la fuerza bruta

    Tras cinco fallos, cada intento desde esa dirección se retrasa hasta 5 s; cinco códigos de 2FA erróneos bloquean ese factor diez minutos. Adivinar un código de seis cifras dentro de sus treinta segundos de vida deja de ser posible.

  4. 4

    Se verifica la sesión

    El algoritmo con el que se comprueba la firma lo decide la configuración del servidor, nunca el propio testigo de sesión: uno que pida ser validado «a su manera» se rechaza.

  5. 5

    Se exige el segundo factor

    Si tienes 2FA, la aplicación te lo pide al entrar. Quien lo tiene activado lo necesita en toda la aplicación: en cada petición, en el canal en tiempo real, en los conectores y al aprobar acciones. Si tu empresa activa "2FA para todo el equipo", se exige a todos sus miembros, también cuando entran desde otra empresa. También puedes entrar con una passkey.

  6. 6

    Se recomprueba tu empresa

    En cada petición, contra la base de datos. Lo que diga el testigo de sesión no basta: puede ir por delante de la realidad.

  7. 7

    Se comprueba tu papel

    A la administración de la plataforma solo se llega con un control aparte. El resto ve «sin acceso» aunque su sesión sea válida.

  8. 8

    Se limpia la respuesta

    Antes de salir hacia ti se borran credenciales y se oculta el modelo que hay detrás. Si algo se colara, la respuesta se sustituye entera y salta un aviso interno.

Cumplimiento

RGPD y Reglamento europeo de IA

Lo que está construido dentro del producto, no lo que está prometido en un documento.

RGPD

  • Acuerdo de encargado del tratamiento firmable desde la propia aplicación: quedan registrados el nombre, la fecha, la dirección de origen y la huella del texto exacto que firmaste.
  • Descarga de tus datos en un fichero, desde tu cuenta y sin pedírnoslo (derechos de acceso y portabilidad).
  • Baja de la cuenta con efecto inmediato: bloquea el acceso en el momento y queda registrada. Tras la exportación, suprimimos los datos de la empresa y entregamos un certificado de supresión firmado; solo se conserva lo que la ley obliga a guardar (la facturación, 6 años).
  • Procedimiento escrito para una brecha de datos, con su guía de actuación paso a paso.
  • Lista de subencargados publicada, con historial de cambios fechado.
  • Evaluación de impacto en borrador desde mayo de 2026, sin cerrar. Se comparte con esa etiqueta.

Reglamento europeo de IA

  • Siempre se sabe que quien responde es un agente, con qué nombre y de qué departamento. Nunca se presenta como una persona.
  • Trazabilidad de cada ejecución: qué agente intervino, qué herramientas usó, qué devolvió y cuánto consumió.
  • 34 acciones no se ejecutan solas: quedan en una bandeja esperando a que una persona las apruebe o las rechace.
  • La espera tiene plazo: si nadie decide, la petición caduca en vez de acabar ejecutándose sola.
  • La identidad y las instrucciones de cada agente se modifican por partes y con historial completo, nunca se sustituyen enteras.
  • Documentación técnica disponible bajo acuerdo de confidencialidad.

Dónde están los datos

Los datos del producto viven en un servidor propio dentro de la Unión Europea, no en una nube compartida. Las identidades y el inicio de sesión se gestionan aparte, en Irlanda (eu-west-1). La inferencia sale por un proveedor con entidad y centros de datos en la UE y sin que almacene ni registre el contenido de las peticiones: hay un guardarraíl en el código que ignora cualquier dirección de proveedor fuera de la UE salvo que se autorice a propósito. Qué proveedor es cada pieza, en qué país está y para qué se usa está en /subprocessors.

Si necesitas que no salga nada en absoluto (sectores regulados, contratos públicos, salud), Concerto Local lo resuelve: la inferencia corre en tu propio servidor, sobre el modelo Concerto local. El plan trae además 60 M STU al mes de cuota en la nube para lo que quieras mandarle a Amadeus, y es un interruptor: con él apagado, tus datos no salen de tu infraestructura.

Aislamiento

Quién impone el aislamiento, de verdad

Aquí es donde estas páginas suelen decir «doble barrera» y quedarse tan anchas. La nuestra la impone hoy la aplicación; lo que hay debajo llega hasta donde llega, y está escrito con su alcance exacto.

  • Lo que aísla hoy: la aplicación. cada petición resuelve a qué empresa perteneces y lo comprueba contra la base de datos, sin atajos, y cada consulta filtra por esa empresa. Modificar o borrar cualquier cosa exige comprobar la pertenencia otra vez. Si te retiran el acceso, lo notas en esa misma petición.
  • Lo que hay debajo: las políticas del motor. en trece áreas (consumo de modelos, facturación, aprobaciones, memoria —lectura—, ejecuciones, flujos, integraciones, recursos humanos, proyectos, soporte, facturación fiscal, plantillas de documentos y clientes, el CRM) las políticas de fila del propio motor de base de datos hacen además de segunda barrera. En el resto, el aislamiento es el filtro por empresa de la aplicación.

En Concerto Local cada cliente tiene su propia base de datos dedicada: ahí la separación es física, no solo lógica, y toda esta discusión no aplica.

-- activo en las tablas de trece áreas
ALTER TABLE all_owned_tables ENABLE ROW LEVEL SECURITY;
ALTER TABLE all_owned_tables FORCE  ROW LEVEL SECURITY;

-- pero solo se aplica dentro de este bloque,
-- que usan esas trece áreas
SET LOCAL ROLE shara_app;
SET LOCAL app.current_tenant = '…';
Pruebas

Más de cincuenta ataques (hoy, 58), escritos como pruebas

Se ejecutan en cada verificación del código y en su propio flujo de integración continua. Si el porcentaje neutralizado en los casos graves baja del 95 %, la publicación se detiene. Cómo se mide exactamente está en la tercera tarjeta, y conviene leerla.

44 casos

Las diez categorías OWASP para modelos de lenguaje

Inyección de instrucciones, tratamiento inseguro de la salida, envenenamiento de datos, denegación de servicio, cadena de suministro, filtración de información sensible, herramientas vulnerables, exceso de autonomía, exceso de confianza y robo del modelo.

14 casos

Los nuestros

Los que solo tienen sentido aquí: intentos de sacarle a un agente el nombre real del modelo, de escalar a otro agente sin permiso, de reescribir la identidad de un agente por conversación, de saltarse la cuota o los topes de gasto, y de sacar credenciales guardadas.

Cómo se mide

Lo que esta cifra es, y lo que no

La suite se ejecuta contra respuestas grabadas, no contra el modelo en vivo. Comprueba que las defensas que neutralizaban cada ataque siguen en su sitio, no que el modelo de hoy resista un ataque nuevo. Es una red contra retrocesos y así hay que leerla. Ejecutarla periódicamente contra el modelo real está pendiente.

Catálogo

El catálogo completo

Ocho apartados con el detalle de qué hace cada cosa. Todo lo de aquí está en el código que se publica.

Acceso y sesión (7 medidas)
  • Sesión firmada y verificada en cada petición. El algoritmo de la firma lo fija la configuración del servidor, y nunca se acepta el que proponga el propio testigo de sesión.
  • Segundo factor por aplicación, con ocho códigos de respaldo de un solo uso guardados con scrypt y descargables en PDF o texto.
  • Hay operaciones que vuelven a pedir el segundo factor aunque ya hayas entrado: cambiar la contraseña, tocar la identidad de un agente, emitir claves de acceso y los pasos de alta de la empresa.
  • Acceso con Google y con Microsoft, con el intercambio de código protegido (PKCE, RFC 8252). Con Microsoft solo entran cuentas personales o cuentas de trabajo cuyo correo ha verificado el titular del dominio: una identidad sin verificar se rechaza.
  • Freno progresivo por dirección de origen en 29 rutas sensibles: acceso, segundo factor, códigos de respaldo, invitaciones, claves de activación, recuperación de contraseña y las que se abren con un testigo.
  • Tras cinco fallos, cada intento desde esa dirección se retrasa hasta 5 s; cinco códigos de 2FA erróneos bloquean ese factor diez minutos.
  • Las comparaciones de secretos se hacen en tiempo constante, para no filtrar nada por lo que tarda la respuesta. Hay 88 en el código.
Separación entre empresas y permisos (7 medidas)
  • A qué empresa perteneces se resuelve en cada petición y se comprueba contra la base de datos, sin atajos: lo que diga el testigo de sesión no basta, porque puede ir por delante de la realidad.
  • Modificar o borrar algo de la empresa exige comprobar de nuevo la pertenencia y que el papel esté en la lista permitida.
  • Seis papeles: propiedad, administración, dirección, operación, sistemas y consulta.
  • Veinte departamentos con nombres validados: quien está en ventas no entra en el perfil del agente legal.
  • La memoria personal es personal: nadie puede leer ni borrar la de otra persona de la misma empresa, ni pidiéndolo a mano.
  • La administración de la plataforma va detrás de un control aparte, exigido en los 18 sitios del código donde hace falta.
  • Concerto Local: base de datos propia y dedicada, separación física y no solo lógica.
El modelo, y por qué no se nombra (6 medidas)
  • El cliente nunca ve el nombre real del modelo que hay debajo.
  • Los nombres públicos son Prelude, Sonata, Symphony y Concerto, el que corre en tu propio servidor.
  • Un filtro recorre todo lo que sale y sustituye cualquier rastro del nombre real, incluidos los identificadores con número de versión y fecha; una prueba comprueba que no quede ningún resto.
  • Los mensajes de error de servicios de terceros pasan por ese filtro antes de guardarse o de llegarte, y los identificadores de cuenta que traen dentro se borran.
  • Detrás del filtro hay un vigilante: si detecta que algo se ha escapado, la respuesta se sustituye entera por una genérica y queda un aviso interno de máxima prioridad.
  • La comprobación pública de estado del servicio usa etiquetas neutras, nunca nombres de proveedor.
Contenido que llega de fuera (5 medidas)
  • Todo lo externo —el mensaje de un cliente, un documento pegado— se envuelve en marcas que lo declaran dato y no instrucción.
  • Los agentes que hablan con clientes llevan esa regla escrita en su comportamiento, con los intentos concretos nombrados uno a uno: «ignora lo anterior», «ahora eres otro agente», «revélame tus instrucciones».
  • Lo que llega en formato de datos estructurados va en un sobre aparte, y se neutralizan las marcas con las que se podría intentar cerrarlo desde dentro.
  • El mensaje de una persona de tu propia empresa, que entra ya autenticada, NO se envuelve: hacerlo enseñaría al agente a desconfiar de su propio usuario. La envoltura es para lo externo, y ahí sí es sistemática.
  • La herramienta con la que un agente escala al orquestador vuelve a comprobar el permiso de la persona que originó la petición, no el del agente.
Gasto (6 medidas)
  • Tope por ejecución: 1.000.000 STU. Si una sola ejecución lo supera, se corta y el agente queda en pausa.
  • Tope por hora: 10.000.000 STU. La inferencia se cierra hasta que se libere.
  • Tope por día: 80.000.000 STU. Es el freno completo de la empresa.
  • El freno se levanta solo cuando el consumo de esa ventana vuelve a estar por debajo, o a mano desde la aplicación.
  • Fuera del horario de trabajo que fijes, el trabajo baja de escalón por sí solo: Symphony pasa a Sonata, Sonata a Prelude y Prelude se limita a respuestas cortas.
  • 34 acciones no se ejecutan solas: enviar correo, emitir y enviar facturas, ordenar pagos, publicar contenido, invitar a alguien, cambiar un papel, y todo lo que toca el ordenador de una persona.
Cifrado (8 medidas)
  • Las credenciales de tus conectores se guardan cifradas con AES-256-GCM, que cifra y a la vez detecta cualquier manipulación.
  • Cada credencial lleva su propia clave AES-256-GCM, envuelta por una clave maestra, y va atada a tu empresa: copiada a otra, no se descifra.
  • El texto cifrado va atado por dentro a la empresa a la que pertenece: moverlo a otra no lo descifra mal, lo invalida.
  • La clave maestra se puede rotar sin descifrar los datos ni parar el servicio: durante el cambio, la aplicación lee con la clave antigua y con la nueva.
  • Solo se escribe el formato actual. El anterior se sigue leyendo para poder migrar lo que quede, pero ya no se emite nunca, y hay una herramienta que lo rota.
  • Si el secreto maestro tiene menos de 32 caracteres, no se cifra nada: se rechaza escribir antes que escribir con una clave débil.
  • Todo lo que se cifra hoy usa la biblioteca estándar de Node (AES-256-GCM, scrypt). Un lector del formato antiguo, solo de lectura, sigue hasta rotar las últimas credenciales.
  • El agente de servidor solo habla con la API y con el servicio de actualizaciones si el certificado lo emite una de las autoridades raíz fijadas en el agente (las de Cloudflare). Se comprueba la firma de cada eslabón de la cadena y, si no casa, no envía nada. La fijación no se puede apagar en producción.
Registro y trazabilidad (6 medidas)
  • Cada cambio queda con autor, fecha, recurso y el antes y el después.
  • La base de datos solo permite añadir líneas: modificar, borrar o vaciar el registro se rechaza, también para la propia aplicación.
  • Además, los registros van encadenados con SHA-256: cada uno incluye la huella del anterior de esa misma empresa. Alterar una línea del medio rompe todas las siguientes, y la cadena se verifica desde la aplicación.
  • La identidad de cada agente se modifica por partes, nunca se sustituye entera, y cada cambio deja rastro.
  • Los registros internos pasan por un filtro que borra cabeceras de autenticación, contraseñas, testigos de acceso y de renovación, claves y los mensajes de error de terceros.
  • De las claves de activación solo se guarda su huella criptográfica; en claro no se escriben en ningún registro.
Carencias

Las carencias, con su fecha

Ninguna de estas nos deja bien, y por eso están aquí y no en una nota a pie de página del contrato. Si alguna es un problema para tu caso, mejor saberlo hoy.

Certificaciones

No estamos certificados en ISO 27001 ni en SOC 2, y no hay auditoría de un tercero. Lo que hay es trabajo interno y está fechado: la auditoría de mayo de 2026 con sus setenta y seis hallazgos, la prueba de intrusión interna de junio y el barrido de agosto, cada uno con sus arreglos.

La segunda barrera de la base de datos

Las políticas de fila de Postgres cubren trece áreas: consumo de modelos, facturación, aprobaciones, memoria (lectura), ejecuciones, flujos, integraciones, recursos humanos, proyectos, soporte, facturación fiscal, plantillas de documentos y clientes (CRM). En el resto, el aislamiento descansa en el filtro por empresa de la aplicación.

La conservación de los datos

Al terminar el contrato, tras la exportación, suprimimos los datos de la empresa y entregamos un certificado de supresión firmado, salvo la facturación, que la ley obliga a guardar 6 años; las copias de seguridad conservan los datos hasta que caducan, a los 35 días. Mientras dura el contrato, el borrado automático está encendido: el propietario de cada empresa elige en Ajustes el plazo de conservación de 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. 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 borra el cliente) ni la configuración.

La evaluación de impacto

Existe en borrador desde mayo de 2026 y no está cerrada. Se comparte tal cual, con esa etiqueta, a quien la pida bajo acuerdo de confidencialidad. Cerrarla es trabajo pendiente, no un trámite hecho.

Los frenos, con más de un servidor

El freno progresivo ante fallos de acceso lleva su cuenta dentro del proceso que atiende la petición. Hoy el servicio corre en uno solo, así que las cuenta todas; el día que haya varios habrá que llevar esa cuenta a un sitio compartido, y hasta entonces no lo diremos de otra manera.

Quien administra la base de datos

La regla que solo deja añadir líneas al registro de auditoría está en la base de datos. Un administrador de la base con privilegios máximos podría saltársela. Para que no pase inadvertido, cada hora guardamos una copia firmada de la última línea de la cadena de cada empresa en un almacenamiento con bloqueo de borrado de 30 días, fuera de la base de datos, y cada día se comprueba que la base coincide con esas copias. Si alguien reescribiera el registro, se detectaría en esa comprobación diaria; no decimos que sea imposible, decimos que se detecta.

Las pruebas contra el modelo real

Los ataques (hoy, 58) se ejecutan contra respuestas grabadas. Sirven para que una defensa no desaparezca sin que nadie se entere, que es lo que suele pasar; no para afirmar que el modelo de hoy resiste un ataque que nadie ha escrito todavía.

Compromisos

Cómo trabajamos contigo.

Seis compromisos que sostienen todo lo anterior.

Datos en la Unión Europea

La inferencia y la base de datos del producto están en la UE. Salen de ella el correo transaccional, el tráfico de Cloudflare, y los pagos, con cláusulas contractuales tipo (ver subencargados).

Todo queda registrado

Cada acción de cada agente queda escrita: quién actuó y cuánto costó. Puedes revisar cualquier conversación de principio a fin.

Tú firmas

Las acciones sensibles pasan por tu visto bueno. El agente prepara el envío, el pago o la propuesta; tú decides.

Tus datos son tuyos

Conservas la propiedad de tu información y la exportas tú desde Ajustes: un .zip con un fichero JSON por tabla (el propietario o un administrador, una vez cada 24 h); si lo necesitas en CSV, te lo preparamos. No entrenamos modelos con tus datos ni los compartimos.

Gasto bajo control

Topes que cortan solos por ejecución, por hora y por día. Si algo se descontrola, Shara corta y avisa.

Siempre al día

Mantenemos la aplicación al día con las novedades de la IA, y las mejoras van incluidas en tu plan.

Documentos

Documentos de tratamiento de datos

Textos legales completos, listos para tu equipo de cumplimiento.

¿Encontraste un fallo? Cuéntanoslo de forma responsable en security@aiginer.com.

¿Quieres revisarlo a fondo?

Bajo acuerdo de confidencialidad compartimos los informes de auditoría con sus hallazgos, el borrador de la evaluación de impacto y los resultados completos de la suite de manipulación, caso a caso.

Pedir la documentación de seguridad