Privacidad por arquitectura: 12 features por segundo como decisión legal

La diferencia entre un producto de inteligencia emocional que tu equipo legal aprueba en seis semanas y uno que aprueba en seis meses cabe en una sola decisión técnica:

¿Qué cruza la red?

Si la respuesta es "video y audio crudos", el producto entra en el régimen completo de tratamiento de datos biométricos sensibles — GDPR Art. 9, Ley 1581 colombiana ampliada, LFPDPPP mexicana, HIPAA si hay caso clínico, CCPA si hay residentes californianos. Cada régimen exige consentimiento granular, retención auditable, DSR completos, brecha-notification y, en algunos casos, registro ante la autoridad.

Si la respuesta es "12 features densos por segundo", el régimen cambia. No por privilegios legales — por la naturaleza del dato.

Este post explica por qué.

Qué es un feature denso de 12 dimensiones

Cada ventana de 1 segundo se resume, en el dispositivo del usuario, en un vector de 12 números reales. Esos números son estadísticas agregadas:

• 4 features faciales (movimiento de cejas, apertura ocular, microexpresión orbicular, tensión de mandíbula)
• 4 features vocales (energía RMS, jitter, MFCC reducidos a 4 componentes, ritmo de turno)
• 4 features fusionadas / de interacción (sincronía facial-vocal, latencia de respuesta, contexto temporal de turno)

El vector resultante es suficiente para que un clasificador distinga entre estados VEXKIO-5 con la precisión que reportamos. Pero no es suficiente para reconstruir identidad. Un atacante que intercepte el stream de features densos no puede:

• Recrear el video del usuario
• Reconocer la cara del usuario en otro video
• Identificar al usuario en una base de datos biométrica
• Reconstruir el audio o transcripción

Eso es por construcción, no por encriptación. La encriptación puede ser quebrada; la pérdida de información, no.

Por qué cambia el régimen legal

Los marcos regulatorios europeos y latinoamericanos definen "dato biométrico" como un dato que permite identificar. La definición varía pero gira alrededor del eje de identificabilidad:

• GDPR Art. 4(14): "datos personales obtenidos a partir de un tratamiento técnico específico, relativos a las características físicas, fisiológicas o conductuales de una persona física que permitan o confirmen la identificación única"
• Ley 1581 + Decreto 1377 (Colombia): similar, con énfasis en el tratamiento que individualiza
• AI Act EU (2024): distingue entre "remote biometric identification" (alto riesgo) y "emotion recognition" (riesgo específico, prohibido en algunos contextos como aula y trabajo sin consentimiento)

Un vector de 12 features densos no permite identificación única — no es un embedding facial, no contiene huella biométrica reconocible. Es señal estadística agregada.

Esto no significa que VEXKIO esté fuera de la regulación. Sí significa que VEXKIO opera en un sub-régimen distinto al de las plataformas que envían video crudo:

• Consentimiento sigue siendo obligatorio (lo capturamos explícitamente en el SDK)
• Retención sigue siendo limitada (default: 0 días para payload crudo, 30 días para agregados anonimizados)
• DSR sigue aplicando (derecho a acceso, rectificación, supresión sobre los agregados)
• Pero el alcance del análisis de impacto (DPIA / EIPD) es significativamente más manejable

El argumento práctico para el equipo legal

Cuando una empresa cliente nos pregunta "¿cuánto va a tardar nuestro legal en aprobar VEXKIO?", la respuesta promedio del último año ha sido 3-6 semanas. Para plataformas adyacentes que mandan video crudo, es 4-9 meses (con casos no aprobados).

La diferencia no es nuestro DPA mejor escrito (es estándar). La diferencia es que el equipo legal no tiene que reconciliar:

1. La promesa funcional ("queremos análisis de emoción en tiempo real")
2. El régimen biométrico estricto que aplica si hay video crudo
3. La incertidumbre sobre cómo va a regular el AI Act "biometría categorial"

Con VEXKIO, el legal mira el contrato y ve: edge first, vector denso, sin embedding identificable, consentimiento granular, retención mínima, anonymizado por construcción. Aprueba.

Las preguntas que sí siguen vigentes

La privacidad por arquitectura no resuelve todo. Quedan:

• Consentimiento del usuario observado. VEXKIO no captura consentimiento de terceros automáticamente — el cliente que despliega el SDK debe configurarlo (banner por sesión, política por jurisdicción).
• Bias del modelo. Aunque el output sea agregado, el modelo puede tener bias por demografía. Documentamos métricas por subgrupo cuando los datasets de validación lo permiten.
• Uso secundario por el operador. El cliente puede usar las salidas VEXKIO de formas que el legal no anticipó. Tenemos cláusulas contractuales que limitan uso secundario, pero la responsabilidad operativa es del cliente.

La privacidad por arquitectura es condición necesaria para producto enterprise serio. No es suficiente. La parte ética no delegable sigue viviendo en el operador.

Lo que VEXKIO firma con cada cliente

• DPA en español e inglés, revisable por tu legal
• Cláusulas de prohibición de uso secundario para detección de mentiras, hiring autónomo, vigilancia encubierta
• SLA de retención y borrado
• Cláusula de auditoría: el cliente puede pedir verificación externa del flujo de datos
• Certificación SOC 2 Type I (en auditoría) y compromiso de Type II en 12 meses

---

¿Tu equipo legal está mirando inteligencia emocional?

→ Página /ethics con la postura completa → Diagnóstico técnico de 20 min → Pillar de la categoría Behavioral Signal Intelligence