Seguridad y privacidad

Son las diez y cuarto de la mañana. Un analista de una aseguradora abre su consola de evaluación de riesgo. Tiene delante la solicitud de un seguro de vida. La solicitante es Vega, la misma paciente que en el primer capítulo llegó de madrugada a urgencias con una historia clínica que nadie logró reunir a tiempo. El analista quiere saber una sola cosa: si Vega tiene antecedentes que encarezcan la prima. Su sistema es moderno y, como todo en este libro, habla en preguntas. Así que formula una consulta perfectamente legible: ¿qué situaciones de clase diagnostico_medico tienen a esta persona como paciente?

El grafo responde sin titubear: una arritmia, vigilada desde hace dos años, con un episodio de descompensación documentado. La prima se dispara. En el peor caso, la aseguradora niega la cobertura. Y aquí está lo inquietante: nadie hackeó nada. No hubo una brecha, ni una contraseña filtrada, ni un empleado vendiendo registros. El sistema funcionó exactamente como se diseñó: alguien preguntó y obtuvo una respuesta precisa y confiable. El mismo grafo que ante un médico de guardia reúne en segundos una historia clínica dispersa y salva una vida, ante un analista a media mañana le niega el seguro.

Esta es la objeción más seria que se le puede hacer al modelo, y no la voy a esquivar. Un grafo compartido en el que cada persona tiene una identidad estable es, por defecto, una infraestructura de vigilancia. No es un efecto colateral: es la cara opuesta de su mayor virtud. Las leyes de protección de datos del mundo (el RGPD europeo, la HIPAA estadounidense, la Ley 29733 peruana) existen justamente para impedir lo que WQuestions vuelve fácil: cruzar, sin esfuerzo, datos que vivían separados. Si la fuerza del modelo es que el paciente, el cliente y el lugar son los mismos en todos los dominios, esa misma fuerza permite que el banco vea el diagnóstico y la clínica vea la deuda.

Lo que sigue defiende dos cosas. Primero, que el problema no solo tiene solución: bien entendido, el modelo ofrece mejores herramientas para resolverlo que la arquitectura relacional a la que reemplaza. Segundo, que queda un frente que ningún modelo enlazable resuelve todavía. Pero antes de la ingeniería hay que deshacer un malentendido, porque la primera respuesta no es técnica.

Un idioma, no una base de datos central

La imagen que produce pánico, y con razón, es la de un gran depósito central: un único servidor donde el historial completo de cada persona cuelga de un identificador, y donde cualquiera con credenciales puede consultarlo. Si WQuestions fuera eso, sería indefendible y este capítulo no tendría nada que defender.

No lo es. El grafo compartido es semántico, no físico: lo que se comparte es un significado común, no un disco común. El banco, la clínica, la endocrinóloga y el cardiólogo no comparten una base de datos. Comparten un idioma de preguntas: los siete ejes y el lexicon que traduce hacia ellos. Cada uno sigue guardando sus propios hechos en su propio almacén, bajo su propio control y su propia llave. La clínica no lee el grafo del banco. Lo que ocurre es que, cuando hace falta interoperar, y solo con autorización, los dos grafos hablan la misma lengua. Y la fusión que antes era un proyecto de integración de seis meses se vuelve sencilla.

Lo que se comparte es el idioma de las preguntas, no la memoria de los hechos. La interoperabilidad vive en el borde, bajo consentimiento; no en un cerebro central que todo lo sabe.La distinción que lo cambia todo

Releída así, la escena del médico de guardia cambia de sentido. No fue que el médico «entrara al expediente global de Vega». Fue que cada parte (los dos hospitales, la endocrinóloga, el cardiólogo) publicó hacia un espacio que la paciente había autorizado de antemano para emergencias. Y como todos esos hechos hablaban el mismo idioma, se ensamblaron solos. La interoperabilidad no exige un cerebro central; le bastan un idioma compartido y un permiso. Eso disuelve el susto inicial, pero abre la pregunta de ingeniería de verdad: si cada parte controla su propio acceso, ¿con qué lo controla? Aquí el modelo deja de defenderse y empieza a atacar.

El permiso es un hecho

En una arquitectura relacional, el control de acceso es una capa aparte, escrita en un lenguaje distinto del de los datos: tablas de permisos, jerarquías de roles, sentencias GRANT y REVOKE, reglas sueltas por todo el código. Es un sistema que corre en paralelo a los datos. Y los sistemas paralelos terminan igual: se desincronizan. La política dice una cosa, el código hace otra y nadie sabe cuál de las dos manda de verdad.

En WQuestions no hay capa aparte, por una razón que a estas alturas del libro debería sonar inevitable: el permiso es, él mismo, un hecho del grafo. Es una situación reificada, es decir, un hecho descrito con las mismas siete preguntas que cualquier otro. «Que el cardiólogo Rosales pueda ver el diagnóstico de arritmia de Vega» no es una fila en una tabla de permisos: es una afirmación del grafo, con su quién, su qué, su agente y su cuándo. El control de acceso habla el mismo idioma que aquello que controla.

Visto como tripletas, el consentimiento se descompone en cables hacia cada eje, igual que cualquier otro hecho del libro:

(consentimiento_4471, instancia_de, consentimiento)        ∈ M(O, K)
(consentimiento_4471, quien,        paciente_vega)         ∈ M(O, Q)   # titular
(consentimiento_4471, a_quien,      cardiologo_rosales)    ∈ M(O, Q)   # beneficiario
(consentimiento_4471, permite,      puede_ver)             ∈ M(O, K)   # acción
(consentimiento_4471, sobre,        arritmia_dx_2026)      ∈ M(O, O)   # alcance
(consentimiento_4471, desde,        2026-03-12)            ∈ M(O, T)   # vigencia
(consentimiento_4471, caracter,     revocable)             ∈ M(O, K)

Y ese mismo consentimiento, escrito para viajar entre sistemas, no usa un formato especial de seguridad: es un hecho más del grafo, con la misma forma que un diagnóstico o una transferencia.

{
  "id": "consentimiento_4471",
  "instancia_de": "consentimiento",
  "quien": "paciente_vega",
  "permite": "puede_ver",
  "sobre": "arritmia_dx_2026",
  "a_quien": "cardiologo_rosales",
  "desde": "2026-03-12",
  "caracter": "revocable"
}

Que el permiso sea un hecho, y no un sistema aparte, trae tres regalos. Conviene verlos uno por uno, porque cada uno cura un dolor clásico del control de acceso relacional.

El segundo punto merece una palabra más, porque es donde el modelo y la ley se cruzan con elegancia. «Revocar es publicar» funciona gracias a la vigencia temporal que ya conoces: ante dos hechos que se contradicen, gana el último que sigue vigente. Retirar un permiso no borra nada; añade un hecho nuevo, con su propia marca de tiempo, que cancela al anterior. Así el grafo conserva la historia completa del consentimiento, imprescindible para auditar, y a la vez sabe sin dudas qué vale ahora.

# ¿Quién accedió a la situación arritmia_dx_2026, y cuándo?
?acceso  instancia_de  acceso_a_dato
?acceso  sobre         arritmia_dx_2026
?acceso  quien         ?solicitante      # Q  → quién preguntó
?acceso  cuando        ?momento          # T  → cuándo

Redacción por eje

Hay una diferencia de grano fino que juega a favor del modelo, y es quizá su ventaja más subestimada en privacidad. Una base relacional da acceso por tabla o, con bastante esfuerzo, por fila: o ves el registro entero de la transacción, o no ves nada. WQuestions da acceso por hecho, e incluso por eje.

Como cada situación parte la realidad en coordenadas separadas y de tipo conocido, se pueden mostrar unas y tapar otras sin romper nada. Un auditor financiero puede recibir la prueba de que una transacción ocurrió (su O qué y su T cuándo) sin ver nunca el N cuánto ni la Q contraparte. Un investigador epidemiológico puede saber que hubo un diagnóstico de cierta clase, en cierta fecha y cierto lugar (K, T y L), con el Q quién guardado bajo llave.

Esto no es un parche encima del modelo: es la propia forma del hecho atómico haciendo trabajo de privacidad. La minimización de datos (el principio legal de no entregar más de lo necesario para cada fin) deja de ser una promesa de buena conducta y pasa a ser algo que la estructura del dato expresa con precisión de bisturí. En una tabla, «mostrar el hecho pero ocultar el monto» exige una vista a medida, todo un proyecto. Aquí basta con decir qué ejes se revelan.

Esa distinción se vuelve crítica en un caso concreto: cuando la pregunta es por el agregado. A veces quieres que alguien sepa cuántos pacientes tienen cierta condición sin permitirle llegar a ninguno en particular; el control de acceso, entonces, tiene que separar contar de ver.

Las tensiones que quedan crudas

No todo está resuelto. Quedan tres tensiones reales, y la última no la resuelve nadie todavía, para ningún modelo de datos enlazable. Las pongo sobre la mesa sin maquillaje, porque el modelo se defiende mejor cuando no finge.

El sistema que nunca olvida frente al derecho al olvido

La vigencia temporal cancela un hecho, pero no lo borra; el RGPD, en cambio, da derecho a la eliminación de verdad. Son dos exigencias que parecen compatibles y no lo son del todo. La salida pasa por separar dos cosas que el lenguaje confunde: que un hecho deje de ser verdad y que su contenido se destruya. La técnica concreta se llama crypto-shredding, «triturado por cifrado»: el contenido de los ejes de valor se guarda cifrado, y «borrar» consiste en destruir la llave. Sin la llave, lo que queda es ruido imposible de recuperar, aunque el nodo de la situación siga ahí para no romper las referencias y poder auditar.

La identidad estable es a la vez el arma y la herramienta

El poder del modelo viene de que la persona es la misma en todos los dominios; y eso es, justamente, lo que abre la puerta a los ataques de re-identificación, los que vuelven a poner nombre a un dato anónimo. La defensa se llama seudónimos pareados: la persona sigue siendo una sola por dentro, pero cada relación la ve con un identificador propio, válido solo en ese dominio. Es como usar un nombre distinto en cada ventanilla, donde solo un árbitro autorizado sabe que detrás de todos está la misma persona. Así, cruzar dos identificadores deja de ser gratis: pasa a exigir un permiso explícito.

El frente genuinamente abierto: inferencia y agregación

Aun con permisos por hecho y con la redacción por eje, un modelo que unifica las preguntas vuelve más fácil el ataque por combinación: varios hechos inofensivos por separado, al cruzarse, reconstruyen lo que ninguno mostraba solo. Dónde vives, a qué hora sales de casa, qué farmacia frecuentas: ninguno es secreto, pero juntos te identifican y hasta dicen qué enfermedad tienes.

Esto no lo resuelve bien nadie, y WQuestions, justo por facilitar el enlace desde el diseño, está obligado a tomárselo más en serio, no menos. Existen defensas serias en el momento de responder una consulta: el k-anonimato (no contestar si la respuesta señala a menos de k personas) y la privacidad diferencial (añadir un poco de ruido a las cifras agregadas para que nadie quede al descubierto). Pero son eso, defensas, no soluciones. Por eso este problema pertenece, con todas las letras, al capítulo siguiente: es parte de lo que falta.

El veredicto

En limpio, esto es lo que el grafo compartido sí ofrece, y lo que todavía no:

La conclusión práctica es incómoda y conviene decirla en voz alta: una arquitectura de información que no piensa la privacidad desde el primer día no merece adoptarse. Un modelo que vuelve fácil preguntar cualquier cosa sobre cualquiera sirve tanto para la mejor medicina como para el peor abuso, y la diferencia no está en la potencia del grafo, sino en quién puede preguntar qué.

Que esa pregunta —quién puede preguntar qué— se responda con el mismo modelo, y no con un sistema aparte pegado con cinta, es la mejor noticia de este capítulo. Que la inferencia por agregación siga abierta es la peor. Las dos cosas son verdad a la vez, y la página siguiente empieza, justamente, por admitir todo lo que falta.

La diferencia entre la mejor medicina y el peor abuso no está en la potencia del grafo, sino en quién puede preguntar qué.El veredicto