Resumen

El Registro Sannvit es un registro de auditoría de solo anexado y encadenado por hashes para la actividad de agentes de IA. Cada llamada a un LLM, invocación de herramienta y consulta que realiza un agente se sella en una cadena de hashes SHA-256 por organización — verificable de forma independiente por cualquiera, no solo por el sistema que la escribió. Se ejecuta enteramente dentro de su propia infraestructura: autoalojado mediante Docker Compose o Kubernetes, sin que ningún dato salga de sus paredes.

El problema que resuelve

Los registros de aplicación son una afirmación, no una prueba — un administrador puede editar una fila, la retención se mide en días y no hay distinción entre lo que una IA afirmó y lo que se registró de forma independiente. Un regulador, auditor o la parte contraria que pregunte «¿qué hizo su IA y en qué se basó?» necesita algo más: registros sellados que nadie puede reescribir en silencio, años de retención y una cadena de custodia desde la decisión hasta la entrada de la que dependía.

Cómo funciona

• Capturar — un SDK ligero observa las acciones de su agente dentro del propio proceso, sin intermediarlas. Nada se interpone entre su código y su proveedor de modelos, y el SDK no puede tumbar su aplicación: la captura es una escritura síncrona y no bloqueante en un búfer, y la entrega al ledger API ocurre de forma asíncrona. Vea SDKs.
• Sellar — el encadenamiento de hashes ocurre en el servidor, en el ledger API, no en el SDK — los escritores concurrentes no pueden conocer «el registro anterior», así que el invariante de escritor único vive en una sola función de base de datos. Cada registro se sella sobre el anterior en una cadena por organización.
• Verificar — la cadena es verificable de forma independiente: recalcule el hash de cada registro y recorra los enlaces, fuera del servicio en ejecución, sin tener que confiar en el operador.
• Revisar — un panel reconstruye la cadena de custodia de cualquier decisión, gestiona las alertas y exporta paquetes de evidencia para un examinador.

Propiedades de la arquitectura

• Observador, no pasarela. El SDK nunca se sitúa en la ruta de la solicitud — si el ledger quedara inalcanzable, su agente no lo notaría. Los fallos se reportan a un callback on_error en lugar de propagarse.
• Sellado del lado del servidor. Los registros se serializan como entradas canónicas RFC 8785, encadenadas por hash con SHA-256 (un par record_hash / prev_hash por registro). El SDK solo reporta lo ocurrido; el servidor calcula cada hash.
• Nunca pierde datos en silencio. Si el búfer de ingesta se desborda, los eventos descartados se cuentan y se sellan como un registro lifecycle — el propio hueco pasa a formar parte de la cadena de auditoría, no un vacío silencioso en ella.
• Autoalojado. Postgres simple, Keycloak para la autenticación y un almacén de blobs compatible con S3 para el contenido de los payloads (solo puntero + hash, direccionado por contenido) — todo ejecutándose en su propia VPC o en local, sin un backend gestionado en el que confiar.

Qué contiene la pila

Hacia dónde ir a continuación

• Primeros pasos — despliegue la pila con Docker Compose o Kubernetes.
• SDKs — instrumente un agente para empezar a sellar su actividad en el ledger.