Prácticas de datos

Borrador técnico público v0.2 — no vigente

Este inventario refleja código y esquema revisados el 22 de julio de 2026. No sustituye el RAT interno ni el mapa completo de datos. Los elementos marcados como pendientes impiden convertirlo en un compromiso vigente.

Resumen

Semantara trata dos grupos distintos:

1. datos de cuenta, facturación, soporte y seguridad necesarios para operar la relación;
2. contenido que el cliente envía para que Semantara lo procese hacia proveedores de IA.

Los registros de medición no guardan el prompt crudo, pero la tabla de caché sí puede guardar prompts y respuestas. Esta distinción es esencial para cualquier política de privacidad o retención.

Flujo principal

1. La aplicación del cliente envía una solicitud y una API key operativa a Semantara.
2. Semantara valida la key, registra metadatos de seguridad y determina la configuración aplicable.
3. En proxy/auto, un clasificador interno puede enviar contenido a OpenAI para estimar complejidad.
4. Si el caché no está deshabilitado, Semantara puede generar un embedding mediante OpenAI y escribir prompt, respuesta y vector en PostgreSQL, dentro del alcance público o privado configurado.
5. La solicitud se envía al proveedor principal o de respaldo configurado mediante BYOK.
6. Semantara devuelve la respuesta y registra tokens, modelo, proveedor, latencia, costo y resultado.

El serving por similitud coseno está apagado, pero los pasos de embedding y escritura de caché siguen activos. Apagar ese mecanismo no equivale a dejar de recolectar contenido ni deshabilita la configuración public.

Inventario técnico preliminar

Categoría	Datos observados	Uso	Protección actual	Conservación conocida
Perfil	Nombre, correo, país, idioma, plan y estado	Cuenta, comunicación y analítica	Acceso autenticado y separación por cliente	Sin política de eliminación formal
API keys de Semantara	Hash SHA-256, prefijo, rol, nombre, estado y fechas	Autenticación, autorización y medición	La clave completa no es recuperable desde BD	Revocación lógica permanente
Credenciales BYOK	Proveedor, alias, sufijo y secreto	Llamar al proveedor elegido	AES-256-GCM en reposo; descifrado en memoria	Revocación lógica; borrado al cierre pendiente
Tokens de auth	Token de verificación o reset, estado y vencimiento	Alta y recuperación	Token aleatorio, uso único	Vencimiento 24 h; purga física pendiente
Metering	IP, endpoint, tokens, modelo, proveedor, estado, latencia, costos y cache metadata	Cobro, analítica, ahorro y soporte	Sin prompt crudo en request_logs	Sin plazo formal
Caché	Prompt, respuesta, embedding, modelo, proveedor y conteos	Reutilización y calibración	Scope por key: pool compartido en public y separación en alcances privados; cifrado de infraestructura por verificar	TTL por defecto 30 días; purga física automática pendiente
Costos internos	Etapa, modelo, tokens, costo, latencia, intento y features	Medir COGS	Diseño sin prompt crudo; metadata JSON controlada	Sin plazo formal
Auditoría	IP, servicio, método, endpoint, actor, resultado y error	Seguridad e investigación	Acceso administrativo	Sin plazo formal
Alertas	IP, patrón, ventana, conteo y endpoint de muestra	Detección de amenazas	Acceso administrativo	Sin plazo formal
Billing	IDs de Stripe, suscripción, estado, periodo, plan y moneda	Cobros y cancelación	Pago alojado por Stripe; sin tarjeta completa en Semantara	Pendiente de regla fiscal y contractual
Navegador	API key administrativa y guards de verify/reset en sessionStorage	Mantener sesión y evitar doble envío	Almacenamiento por sesión, no localStorage para la key	Normalmente hasta cerrar la sesión de la pestaña
Contacto y soporte	Nombre, correo y mensaje	Responder solicitudes	Envío por el proveedor de correo	Pendiente de inventario del buzón

Caché: alcances y comportamiento

Los alcances definidos son:

• disabled: no buscar ni guardar para esa key;
• public: utilizar un pool compartido entre clientes;
• private-client: aislar el pool por cliente;
• private-key: aislar el pool por API key.

El esquema contiene prompt_text, response y prompt_embedding. Un embedding es una representación numérica del contenido, no una forma de anonimización, y puede almacenarse junto con el prompt y la respuesta originales.

Cuando una key utiliza public, su contenido elegible se incorpora al pool compartido y puede quedar disponible para reutilización entre clientes mediante los mecanismos habilitados. Cuando utiliza un alcance privado, el conjunto de candidatos se restringe al cliente o a la propia API key. La escritura y la generación de embeddings continúan aunque el serving por similitud semántica esté apagado durante su calibración. Éste es el comportamiento vigente que se documenta; no es una condición para deshabilitar el alcance público.

Controles y límites relevantes:

• el cliente puede elegir el alcance adecuado para cada API key;
• public no debe utilizarse con datos personales, confidenciales, secretos o contenido que el cliente no pueda autorizar legítimamente para tratamiento compartido;
• el TTL determina elegibilidad temporal, pero no demuestra el borrado físico inmediato de una fila;
• la aplicación permite purgar por cliente o por key;
• la trazabilidad, la purga física, el calendario formal de conservación y la validación del serving semántico continúan en desarrollo y deberán describirse conforme se implementen.

Proveedores que pueden recibir datos

La lista final de subprocesadores sigue pendiente. La arquitectura observada incluye:

Proveedor o categoría	Función	Datos potenciales	Pendiente
Railway	Aplicación y PostgreSQL	Cuenta, contenido, logs y configuración	Región, cifrado, backups y retención
Cloudflare	DNS, entrega web y capa de red	IP, cabeceras y solicitudes a superficies servidas	Productos activos y logs
Stripe	Checkout, suscripción y portal	Identidad de facturación, plan y pago	Entidad contratante, retención y avisos
Proveedor SMTP / Amazon SES	Correo transaccional	Nombre, correo, idioma y enlaces con token	Proveedor efectivo por ambiente y logs
OpenAI	Clasificación y embeddings internos; también BYOK si se elige	Prompts o texto derivado, además de datos técnicos	Contrato, retención y uso de datos
Anthropic	Proveedor final cuando el cliente lo configura	Prompts, parámetros y respuestas	Contrato BYOK y tratamiento aplicable

No se incluirá un proveedor en la lista pública basándonos sólo en una dependencia instalada: se verificará que reciba datos en cada ambiente.

Cookies y almacenamiento local

En el código inspeccionado no se identificaron píxeles de marketing ni una plataforma de analítica publicitaria. Las fuentes del sitio están autoalojadas.

Sí se usa sessionStorage para:

• la API key administrativa durante la sesión;
• impedir que los tokens de verificación y reset se procesen dos veces tras recargar.

Aún falta ejecutar un inventario sobre el sitio desplegado para detectar cookies o identificadores añadidos por Cloudflare, Stripe u otra infraestructura. No se instalará un banner de consentimiento sin saber primero qué tecnologías existen y cuáles son estrictamente necesarias.

Solicitudes de eliminación

La implementación permite purgar caché por cliente y por key. No existe todavía un flujo completo, verificado y documentado para cerrar una cuenta y propagar la eliminación a todas las tablas, proveedores y backups.

Hasta cerrar ese flujo, Semantara no debe prometer “eliminación total inmediata”. La política deberá distinguir:

• desactivación de acceso;
• revocación lógica;
• exclusión de uso;
• borrado en la base principal;
• expiración de backups;
• conservación obligatoria para facturación, seguridad o defensa jurídica.

Controles confirmados y límites

Controles observados:

• BYOK cifrado con AES-256-GCM;
• API keys hasheadas con SHA-256;
• autorización por roles;
• scopes de caché;
• revocación permanente;
• auditoría y detección de amenazas;
• pago alojado por Stripe;
• fuentes web autoalojadas.

Pendientes relevantes:

• calendario de retención;
• borrado de cuenta;
• inventario de backups;
• inventario contractual de subprocesadores;
• proceso de incidentes;
• DPA;
• registro versionado de aceptación;
• revisión del trust boundary usado para obtener la IP real;
• documentación, monitoreo y controles continuos del caché compartido.

Artefactos internos relacionados

Esta página será el resumen público. El expediente interno deberá contener por separado:

• RAT o registro de actividades de tratamiento;
• mapa de flujos de datos;
• matriz responsable–encargado–subprocesador;
• calendario de conservación y borrado;
• evaluación de impacto del caché;
• registro de proveedores y contratos;
• procedimiento de derechos ARCO;
• plan de respuesta a incidentes;
• matriz de afirmaciones públicas y evidencia técnica.