Latet
Próximamente

Latet Enterprise

Latet sustituye los secretos y los datos personales de las peticiones de tus agentes de IA por valores ficticios realistas antes de que salgan. Con Latet Enterprise, el control lo tiene tu equipo de seguridad: fija reglas que nadie puede relajar, aprueba o rechaza cualquier cambio que las debilite y recibe eventos e informes para su SIEM y sus auditorías. Todo funciona en un servidor dentro de tu red.

Apuntarme a la lista de espera Escribe a info@latet.ai

Dónde funciona

Latet Enterprise funciona en tu propio servidor, dentro de tu red. No hay una nube de Latet, y el servidor nunca contacta con Latet.

Tu red
Ordenadores Claude Code, Codex, OpenCode y otros agentes
CI y programas cada uno con su propia clave de API
Servidor de Latet enmascara cada petición y restaura los valores reales en cada respuesta
Proveedores de IA los que tus agentes ya usan
Conexión directa: bloqueada
Cortafuegos
Con la regla del cortafuegos activa, solo el servidor de Latet llega a los proveedores de IA.
  • El servidor es quien enmascara. Ordenadores y programas envían sus peticiones de IA al servidor de Latet por HTTPS, y el servidor enmascara cada una por sí mismo. Nunca confía esa tarea a un ordenador.
  • Ninguna llamada a Latet. El servidor se conecta a los proveedores de IA y a los sistemas con los que lo integres, como tu proveedor de identidad y tu SIEM. La licencia es un archivo firmado que se verifica sin conexión.
  • Tu punto de control, junto con el cortafuegos. El servidor se convierte en tu punto de control cuando tu cortafuegos solo le permite a él acceder a los proveedores de IA; un ordenador que acceda a ellos directamente lo elude. La documentación muestra un ejemplo de la regla. Latet no comprueba que esté activa.
Detalles técnicos
  • Despliegue. Latet funciona en instancias sin estado detrás de tu balanceador de carga, con PostgreSQL y Valkey, en un contenedor o como servicio de systemd o de Windows.
  • Cifrado. En PostgreSQL, los valores, textos e imágenes de cada persona y de cada clave de API se sellan con una clave propia, y esas claves con una clave maestra. Los nombres de cuenta y las direcciones de correo se guardan sin cifrar.
  • La clave maestra. El servidor la lee de un archivo o de una variable de entorno. Guarda una copia de ella, separada de las copias de seguridad de la base de datos.
  • Compilaciones. Cada versión se genera con un flujo de trabajo que añade atestaciones de procedencia de la compilación y un SBOM en formato CycloneDX.

Control

Tu equipo de seguridad fija las reglas para todos en un solo lugar, con un mínimo del que nadie puede bajar, y decide sobre los cambios que reduzcan la protección.

Reglas para todos

  • Una sola vez, para todos. Los términos, las listas, los reconocedores, las reglas de campo y los niveles de protección se fijan en el servidor y se aplican a cada persona y a cada clave de API; cada persona añade los suyos.
  • Un mínimo, no un techo. Los ajustes de cada persona se suman a tu política. Un cambio que baje de ella se rechaza, venga del panel, de la línea de comandos o de una importación, y el rechazo indica qué ajuste ha bloqueado tu empresa.
  • Visibles para todos. En el panel, cada persona ve los ajustes bloqueados con un candado.
  • En el servidor, al momento. La política se guarda en la base de datos del servidor y se aplica enseguida a cada persona y a cada clave de API.
Detalles técnicos
  • Formato. La política usa el formato del archivo de reglas de Latet: puedes partir de una exportación de las reglas que ya usas.
  • Sin servidor. Tu herramienta de gestión de dispositivos instala un archivo de política donde solo los administradores pueden escribir: C:\ProgramData\Latet\policy.yaml, /Library/Application Support/Latet/policy.yaml o /etc/latet/policy.yaml.
  • El límite de un archivo. Quien es administrador de su propio ordenador puede borrarlo. Un mínimo que nadie pueda saltarse se fija en el servidor, junto con la regla del cortafuegos.

Aprobaciones centralizadas

  • Decide tu equipo de seguridad. Si tu política lo indica, un cambio que reduzca la protección, como dejar pasar un valor sin enmascarar o desactivar una regla, llega a las personas con el rol de seguridad.
  • Ningún valor en la solicitud. Una solicitud de aprobación indica el ajuste que cambiaría, nunca un valor.
  • Claro para quien espera. Quien lo ha pedido ve quién decide.
  • El Revisor en directo, si lo eliges. El Revisor en directo retiene cada texto nuevo hasta que alguien lo aprueba. Tu empresa puede hacer que sea el equipo de seguridad quien apruebe, en lugar de cada persona. Se informa de ello a las personas.

Evidencias

Latet Enterprise envía eventos a tu SIEM y genera informes para tus auditorías. Contienen recuentos y categorías, nunca un valor.

Eventos para tu SIEM

  • Splunk. Los eventos van al HTTP Event Collector (HEC) de Splunk.
  • Syslog. Latet envía mensajes RFC 5424 sobre TLS a rsyslog, a syslog-ng o a un recopilador delante de Microsoft Sentinel.
  • Webhook. Cada evento sale en JSON, por HTTPS, hacia la dirección que elijas, con las cabeceras que necesite el receptor. Funciona con Elastic, con Microsoft Sentinel a través de una Logic App y con recopiladores como Vector o Fluent Bit.
  • Nunca estorba. Enviar un evento nunca retiene la petición de un agente. Los eventos esperan en una cola y se vuelven a enviar si tu SIEM no responde.
Detalles técnicos
  • Tipos de evento. exchange, stopped, approval, change, policy, sync, sign-in, license, y admin para el registro de administración.
  • Entrega. Cada evento llega al menos una vez y en orden, en lotes de hasta 500 que envía una sola instancia cada vez. Si un envío falla a mitad de un lote, parte de él puede llegar dos veces: el id de cada evento permite reconocer los duplicados.
  • Reintentos. Si el receptor no responde, Latet vuelve a intentarlo a los 5 segundos, a los 10, a los 30 y al minuto, y después cada 5 minutos. Los eventos esperan en orden, también tras un reinicio.
  • Secretos. Los tokens y las claves se guardan sellados en la base de datos del servidor. Un webhook con secreto va firmado (x-latet-signature), y http:// se rechaza salvo hacia el propio servidor.
Un evento: recuentos, nunca un valor
{
  "v": 1,
  "id": "3f9a0c1d2e4b4c6f8a1b2c3d4e5f6071",
  "ts": "2026-11-03T09:12:44Z",
  "type": "exchange",
  "identity": null,
  "kind": "person",
  "group": "g_payments",
  "agent": "claude-code",
  "project": "billing-api",
  "masked": {"EMAIL": 3, "IBAN": 1},
  "stopped": 0,
  "reason": null,
  "outcome": null,
  "by": null,
  "rule": null
}

En este intercambio se enmascararon tres direcciones de correo y un IBAN. El evento dice cuántos y de qué tipo, nunca cuáles. Mientras los informes sean por grupo, la opción predeterminada, identity queda en null.

Informes

  • En el panel. Filtra por periodo, grupo, proyecto, agente o categoría, sigue la evolución en el tiempo y exporta en CSV o JSON.
  • Independientes del historial. Los informes salen de un registro de eventos propio, con su propia retención, así que funcionan aunque el historial esté desactivado.

Registro de administración

  • Quién hizo qué. Cada acción de administración queda registrada con quién, qué, sobre qué, cuándo y desde qué dirección, nunca con un valor. Se conserva 365 días, salvo que elijas otra cosa.
  • Los cambios se notan. Cada entrada lleva el hash de la anterior. latet server log verify, una comprobación cada hora y latet server status indican si la cadena está intacta.
  • También en tu SIEM. Una cadena de hashes revela un cambio, pero no lo impide: quien puede escribir en la base de datos puede reescribir toda la cadena. Por eso el registro también va a tu SIEM.
  • En cada servidor. El registro forma parte de todos los servidores de Latet, también en la Community Edition. Enterprise lo añade a los informes y al SIEM.

Los nombres de tu empresa

Latet detecta lo que tiene un formato reconocible: claves, direcciones de correo, IBAN, números de identificación. Los nombres de tus clientes y los nombres en clave de tus proyectos no lo tienen. Latet Enterprise los toma de tus propios sistemas y los enmascara como cualquier otro valor, sin que nadie tenga que escribirlos.

  • Desde un archivo o una URL. Latet lee a intervalos regulares una lista en CSV, JSON o YAML. Cualquier sistema puede generarla.
  • Desde Microsoft Entra ID. Latet obtiene mediante Microsoft Graph los nombres y direcciones de correo de las personas, y los nombres de los grupos.
  • Desde LDAP y Active Directory. Latet lee los nombres directamente de tu directorio.
  • Desde un CRM, a petición. HubSpot o Salesforce se añaden cuando una empresa lo pide.
Detalles técnicos
  • Tipos de término. Cada fuente asigna sus campos a tipos como CLIENT, PERSON y PROJECT.
  • Sellados. Los términos sincronizados se guardan sellados en PostgreSQL, no en un archivo de ajustes: una lista de clientes ya es sensible por sí misma.
  • Eliminados en la fuente. Un término que desaparece de su fuente sigue enmascarado, marcado como ausente, hasta que alguien con el rol de seguridad lo elimina.

Inicio de sesión y roles

Las personas inician sesión con tu proveedor de identidad, y sus cuentas se gestionan desde él.

  • Inicio de sesión único con OIDC. Funciona con Microsoft Entra ID, Google, Okta, Keycloak, Authentik, Auth0 y otros proveedores OIDC. SAML 2.0 está disponible a petición.
  • Cuentas mediante SCIM 2.0. Tu proveedor de identidad crea y desactiva las cuentas. Solo reciben una los miembros del grupo que elijas, por ejemplo latet-users.
  • Desactivar es cerrar la sesión. Al desactivar a alguien, sus sesiones se cierran y sus tokens se revocan al momento, en todas las instancias, y su plaza queda libre.
  • Grupos y roles. Los grupos llegan de tu proveedor de identidad o se crean a mano. Los roles se asignan a personas o a grupos.
Detalles técnicos
  • OIDC. Latet usa el flujo de código de autorización con PKCE. El secreto del cliente se sella con la clave maestra, y los grupos del token se asignan a los grupos de Latet.
  • SCIM. El servidor expone /scim/v2/Users y /scim/v2/Groups, la parte de SCIM 2.0 que usan Entra ID y Okta.
Roles
Rol Ve Decide
Usuario sus propios datos y las claves de API que controla sus propios ajustes, por encima del mínimo, y los de las claves de API que controla
Responsable de grupo los informes de sus grupos nada
Seguridad todos los informes la política, los términos, las aprobaciones, el SIEM
Auditor los informes, el historial de la política y el registro de administración, en solo lectura nada
Administrador personas, grupos y claves de API el inicio de sesión, los roles, la licencia, las claves de API y quién las controla

La privacidad dentro de la empresa

Latet mantiene los valores de las personas lejos de los proveedores de IA, y también de tus administradores.

  • Los datos de cada persona son suyos. Nadie ve los valores ni los textos de otra persona, tampoco los administradores. La caja fuerte, el historial y las aprobaciones de cada uno son solo suyos.
  • Informes sin contenido. Los informes y los eventos del SIEM llevan recuentos, categorías, identificadores de regla, el agente, el proyecto, el grupo y el resultado. Nunca llevan un valor, un texto ni un valor ficticio.
  • Una excepción, elegida de forma transparente. Si el equipo de seguridad aprueba los textos del Revisor en directo, quien aprueba ve cada texto, valores incluidos. Tu empresa lo decide y lo comunica a las personas.
  • Informes por grupo, de forma predeterminada. Los informes por persona, con seudónimo o con nombre, son una opción que activa tu empresa, tras un acuerdo con su plantilla cuando la ley lo exige.
Detalles técnicos
  • Cuando la ley exige un acuerdo. En Italia, el art. 4 del Statuto dei lavoratori (L. 300/1970); en Alemania, la cogestión del comité de empresa (BetrVG, § 87, apdo. 1, n.º 6).

Qué obtiene un auditor

Lo que tus auditores pueden comprobar por sí mismos.

  • Un rol de solo lectura. Los auditores ven los informes, el historial de la política y el registro de administración, y no cambian nada.
  • Cifras por periodo. Los informes dicen cuántos valores se enmascararon y de qué tipos, cuántas peticiones se detuvieron y cuántos cambios se aprobaron, por grupo, proyecto y agente, nunca un valor.
  • Quién cambió qué. El historial de la política, el registro de administración y los eventos de aprobación muestran quién cambió cada regla y quién lo aprobó.
  • Un registro verificable. La cadena de hashes se comprueba con latet server log verify.
  • Material para una EIPD. La documentación indica qué guarda Latet, dónde, qué está sellado y qué no, y durante cuánto tiempo.
Qué respaldan estas evidencias
Marco Artículos y controles
RGPD Seudonimización (art. 4, punto 5), protección de datos desde el diseño (art. 25), seguridad del tratamiento (art. 32, apdo. 1, letra a)
ISO/IEC 27001:2022, anexo A 8.11 enmascaramiento de datos, 8.12 prevención de fugas de datos, 8.15 registro, 8.16 actividades de seguimiento

Latet reduce la exposición. Son tus propios controles los que determinan si cumples la normativa.

La licencia

El servidor forma parte de la Community Edition, gratis para cualquier empresa, e incluye un registro de administración. Latet Enterprise añade todo lo demás de esta página, incluidas las reglas para todos.

Quién la necesita. Una empresa que usa las funciones Enterprise en producción necesita una licencia de Latet Enterprise. Desarrollar y hacer pruebas con ellas es gratis, y la Community Edition, servidor incluido, sigue siendo gratis para cualquier empresa, sea cual sea su tamaño.

Solo la comprueban las funciones Enterprise. La Community Edition no tiene claves de licencia y nunca comprueba nada. Solo las funciones Enterprise leen el archivo de licencia, sin conexión.

Quién cuenta

Como en Jira: cada cuenta activa con acceso a Latet, se haya usado o no ese mes. Una persona cuenta una sola vez, tenga los ordenadores y grupos que tenga. Cada clave de API activa cuenta como un usuario. Desactivar una cuenta libera su plaza al momento.

El archivo de licencia

Firmado con Ed25519 y verificado sin conexión, sin activación. Indica tu empresa, los usuarios comprados, las funciones y la fecha de vencimiento, que latet license show y latet doctor muestran.

La prueba

Desarrollar y hacer pruebas con las funciones Enterprise no requiere licencia. Para probarlas primero en su trabajo real, una empresa puede pedir un archivo de licencia de prueba válido durante 32 días.

Si la renovación se retrasa

  1. 30 días antes del vencimiento Un aviso

    Los administradores ven un aviso en el panel y en latet doctor.

  2. La fecha de vencimiento Todavía no cambia nada

    Durante 30 días más, todo sigue funcionando como antes.

  3. 30 días después del vencimiento Lo nuevo se pausa

    Latet deja de generar cosas nuevas para ti: nuevos informes y exportaciones, eventos para el SIEM y sincronización de términos. Los términos ya sincronizados siguen enmascarados.

  • La protección nunca se detiene. Las reglas bloqueadas continúan bloqueadas, las aprobaciones siguen su curso y todo el mundo puede iniciar sesión como siempre.
  • Más usuarios de los comprados. El aviso llega enseguida, y después los mismos 30 días y la misma pausa.

Latet sigue protegiendo para que nadie quede expuesto, pero la licencia es igualmente necesaria. Una empresa que continúa usando Latet Enterprise tras el vencimiento la renueva, y una con más usuarios de los que compró adquiere los que le faltan.

Las condiciones completas

Contacto

Para hablar del caso de tu empresa, escribe a info@latet.ai. Indica cuántas personas usarían Latet, qué proveedor de identidad y qué SIEM tiene tu empresa, y qué agentes utiliza.

Recibe un aviso cuando Latet Enterprise esté disponible

Deja tu dirección de correo electrónico: recibirás un solo mensaje cuando Latet Enterprise esté disponible, y nada más.

Cómo se guarda la dirección

¿Preguntas sobre Latet Enterprise?

Escribe a esta dirección:

info@latet.ai

Escribir un correo