Acceso no es propiedad

Casi todo servicio afirma, en algún punto de su página de marketing, que los datos son tuyos. La frase suele ser sincera —más de lo que el cinismo supone— y aun así casi nunca significa lo que el lector entiende. Propiedad, en la tradición jurídica que heredamos, no es una relación con una cosa sino un haz de facultades sobre ella: usarla, excluir a otros, modificarla, transferirla, destruirla y, la que más importa aquí, seguir teniéndola aunque a un tercero le convenga que no. Cuando los bytes viven en la infraestructura de otro, ese haz se reparte, y el reparto rara vez es el que uno imagina. Esta lección no acusa a nadie: sustituye una palabra vaga por preguntas precisas. Qué facultades conservas exactamente, quién ejerce las que no conservas y qué queda en tus manos el día que la relación comercial termina, porque termina siempre, de un modo o de otro.

La propiedad es un haz, no un objeto

La intuición popular trata la propiedad como una relación binaria entre una persona y una cosa. La teoría jurídica lleva un siglo describiéndola de otro modo, y ese otro modo es el que sirve aquí: la propiedad es un conjunto de facultades separables que pueden repartirse entre varios titulares. El derecho romano ya distinguía usus, fructus y abusus; el análisis moderno de Honoré enumera once elementos, entre ellos el derecho a poseer, a usar, a gestionar, a excluir, a percibir el rendimiento, a transmitir, a consumir y —el más olvidado— la ausencia de término: que nadie pueda ponerle fecha de caducidad a tu titularidad.

Conviene tener la lista delante, porque el análisis posterior consiste en preguntar, facultad por facultad, quién la ejerce de verdad:

1. Usar. Leer el contenido y obtener de él la utilidad para la que existe.
2. Gestionar. Decidir cómo se organiza, dónde reside y bajo qué condiciones se accede.
3. Excluir. Impedir que otros lean, copien o deriven valor de ello.
4. Modificar y consumir. Alterarlo o destruirlo de forma definitiva y verificable.
5. Transmitir. Trasladarlo a otro sistema conservando su estructura y su significado.
6. Permanecer. Seguir siendo titular sin término y sin depender de la voluntad de un tercero.

Los datos complican el cuadro porque no son rivales: que yo lea un fichero no impide que tú lo leas. La posesión física, que en las cosas materiales hace casi todo el trabajo, aquí no hace ninguno. Lo que queda haciendo trabajo son dos facultades: la exclusión, es decir, poder impedir que otros lean o usen, y la permanencia, poder seguir teniendo sin permiso de nadie. Un dato sobre el que no puedes excluir ni puedes garantizar permanencia no es tuyo en ningún sentido operativo, por mucho que un contrato lo llame así.

Aplica el desglose a una aplicación de notas en la nube. Puedes usar y modificar; el proveedor también puede, y de hecho lo hace cada vez que reindexa, migra un esquema o entrena un clasificador de abuso. Puedes transmitir a otro sistema, pero solo por el conducto y en el formato que él ofrezca. No puedes excluirlo a él, porque para servirte una página necesita leer el contenido en claro. Y no tienes permanencia, porque el contrato tiene término y el término lo fija la otra parte.

flowchart TD
H[Haz de facultades sobre un dato]
H --> U[Usar y leer]
H --> E[Excluir a terceros]
H --> M[Modificar y borrar]
H --> T[Transferir a otro sistema]
H --> P[Permanencia sin termino]
U --> A[Compartida con el proveedor]
M --> A
E --> B[Del proveedor en la practica]
T --> C[Limitada al conducto que el ofrezca]
P --> D[Del proveedor por contrato]
style A fill:#f9e2af,color:#11111b
style B fill:#f38ba8,color:#11111b
style C fill:#f9e2af,color:#11111b
style D fill:#f38ba8,color:#11111b

Custodia, licencia y la analogía bancaria

La confusión entre custodia y propiedad no es exclusiva del software, y hay una analogía madura que sirve para pensarla con más finura que la indignación.

Cuando ingresas dinero en un banco no eres dueño de unos billetes concretos: eres acreedor de la entidad. Es custodia, no depósito de cosa cierta, y sin embargo casi nadie lo vive como una pérdida. La razón es que alrededor de esa custodia se construyó, a lo largo de un siglo y a golpe de crisis, un andamiaje enorme: garantía de depósitos, supervisión prudencial, requisitos de capital, autoridades de resolución que mantienen las cuentas operativas incluso cuando la entidad quiebra. La custodia bancaria es tolerable no porque sea inocua, sino porque está domesticada.

La analogía ilumina justamente por contraste. El alojamiento de tus datos en un servicio también es custodia, pero sin ninguna de esas piezas. No hay garantía de continuidad, no hay supervisor que obligue a mantener el servicio, no hay régimen de resolución que preserve tu acceso si la empresa cierra o la compra otra, y no hay más obligación de conservación que la que el propio contrato se imponga. El vocabulario de la propiedad se aplica a una relación que jurídicamente es una licencia de acceso: revocable, sujeta a unas condiciones que la otra parte puede modificar de forma unilateral con un preaviso que llega por correo y nadie lee.

La comparación sugiere además por dónde iría una solución no técnica, que conviene mencionar para no dar la impresión de que la arquitectura es el único instrumento disponible. Nada impide, en principio, construir para el alojamiento de datos el equivalente de lo que existe para los depósitos: obligaciones de conservación mínima tras la terminación, depósito de código fuente en custodia para el caso de cierre, exigencias de exportación verificable o mecanismos de continuidad supervisados. Algunos sectores regulados ya tienen piezas de eso. Que la vía regulatoria sea posible no resta fuerza al argumento arquitectónico, pero sí lo pone en su sitio: la arquitectura es el instrumento que un equipo pequeño puede usar por su cuenta y sin esperar a nadie.

Conviene nombrar la asimetría con precisión, porque es la raíz de todo lo demás. El proveedor puede terminar la relación y retener la operación del sistema; tú puedes terminarla pero no llevarte el sistema en funcionamiento, solo, con suerte, una copia de los contenidos. Esa asimetría no depende de la buena fe: sobrevive intacta a un proveedor impecable, porque no es una cuestión de conducta sino de dónde está la palanca.

Hay un tercer estado, intermedio y muy frecuente, que merece nombre propio: la cotitularidad opaca. Muchos servicios se reservan en sus condiciones una licencia amplia sobre el contenido que alojas, no necesariamente para explotarlo comercialmente sino porque operar el servicio la exige: para indexar hace falta copiar, para mostrar una vista previa hace falta transformar, para entrenar un clasificador de abuso hace falta procesar. Esas facultades son técnicamente necesarias y suelen estar redactadas de buena fe, pero su efecto acumulado es que el proveedor ejerce sobre tu material un conjunto de derechos que tú no puedes revocar sin abandonar el servicio.

Lo que se pierde no son los bytes

El error de encuadre más común es imaginar el final de una suscripción como la pérdida de un fichero. Casi nunca es eso. Los bytes suelen poder descargarse; lo que desaparece es el resto del sistema que los volvía útiles, y ese resto son tres cosas distintas.

Vale la pena detenerse en la asimetría de valor que hay detrás. En una hoja de cálculo el contenido bruto son números y cadenas, pero el valor está en las fórmulas, las referencias entre celdas, los formatos condicionales y las tablas dinámicas, es decir, en la estructura que un exportador tabular aplana sin remedio. En un espacio de trabajo colaborativo el contenido bruto son bloques de texto, y el valor está en la red de enlaces bidireccionales, las bases de datos con vistas y los permisos por sección. La proporción varía por producto, pero la regla general se sostiene: cuanto más útil es una herramienta, mayor es la fracción de su valor que reside en la estructura y no en el texto, y por tanto mayor es la fracción que no sobrevive a una descarga.

1. El intérprete. El programa que da sentido a la estructura. Una exportación en ficheros de texto conserva las palabras y pierde las vistas, los filtros, los permisos, los enlaces entre elementos y las fórmulas que producían los valores.
2. La identidad. Lo que se rompe antes que nada no es el dato, es el inicio de sesión, y un dato inaccesible es indistinguible de un dato inexistente. La cuenta es el cuello de botella de todo el haz, y por eso una suspensión automatizada sin recurso humano efectivo cancela de golpe todas las facultades a la vez.
3. La red de referencias. Los enlaces que otros guardan hacia tu material, las integraciones que lo consumen, los documentos ajenos que lo incrustan. Ese tejido es un activo colectivo y no viaja en ninguna exportación individual.

La jerarquía entre las tres importa más de lo que parece. La pérdida del intérprete es grave pero reparable con trabajo: alguien puede escribir un lector. La pérdida de la red de referencias es irreparable pero gradual, y se puede mitigar con identificadores estables. La pérdida de la identidad es instantánea y total, y ninguna cantidad de previsión técnica la compensa si el mecanismo de recurso no existe o no responde. Por eso el punto de fallo práctico de la propiedad de datos no suele ser el formato ni el contrato, sino un sistema automatizado de cumplimiento de normas que cierra una cuenta y no tiene a nadie al otro lado.

La prueba del proveedor hostil

Para no quedarse en la retórica hace falta un criterio que se pueda ejecutar. Propongo uno, y es deliberadamente incómodo: imagina que mañana el proveedor se vuelve hostil. No malvado ni negligente, simplemente alineado con sus intereses y no con los tuyos. La pregunta no es si eso ocurrirá, sino qué te quedaría si ocurriese, y hay que responderla en cuatro escenarios distintos porque cada uno ataca una facultad diferente:

• Sube el precio por diez. Ataca la permanencia por la vía económica. Si migrar cuesta más que pagar, la subida es efectivamente ilimitada.
• Cambia las condiciones. Ataca la gestión. Nuevos usos del contenido, nuevos límites de uso, nuevas restricciones sobre integraciones que hoy dependes.
• Discontinúa el producto. Ataca al intérprete. Los bytes pueden bajarse y el sistema que los volvía útiles deja de existir para todos a la vez.
• Suspende tu cuenta. Ataca la identidad, y por tanto todas las facultades de golpe. Es el escenario más raro y el más devastador.

La respuesta a los cuatro, medida en facultades concretas y no en sensaciones, es tu grado real de propiedad. Todo lo demás es una afirmación de marketing.

Merece señalarse por qué esta prueba es tan difícil de aplicar en la práctica: los cuatro escenarios son improbables individualmente, invisibles en cualquier demostración de producto y ausentes de todo proceso de evaluación técnica. Nadie compara herramientas por lo que pasa cuando fallan. El resultado es un sesgo sistemático de la industria hacia arquitecturas que se comportan bien en el caso medio y catastróficamente en la cola, que es exactamente el perfil de riesgo que uno no querría para el trabajo de una década.

flowchart LR
A[El proveedor se vuelve hostil]
A --> B[Sube el precio por diez]
A --> C[Cambia las condiciones]
A --> D[Discontinua el producto]
A --> E[Suspende la cuenta]
B --> F[Permanencia condicionada al coste de migrar]
C --> G[Gestion transferida a la otra parte]
D --> H[Quedan los bytes sin el interprete]
E --> I[Todas las facultades caen a la vez]
style I fill:#f38ba8,color:#11111b
style H fill:#f9e2af,color:#11111b

Ahora la posición contraria, que merece defenderse en serio. Para muchísimos datos el acceso es exactamente lo que quieres, y la propiedad sería un estorbo. Nadie desea ser dueño de un catálogo de películas ni de un índice de búsqueda. La custodia profesional es un servicio con valor genuino: replicación geográfica, copias de seguridad verificadas, recuperación de tus propios errores, disponibilidad en cualquier dispositivo, continuidad cuando se te moja el portátil. La evidencia empírica es dura con el bando soberanista: los usuarios pierden datos por fallo de disco, robo y descuido con mucha más frecuencia que los proveedores serios por cierre o corrupción. Una arquitectura local-first que termina en un fichero sin copia en un portátil que viaja en una mochila es, en esperanza matemática, peor que una nube bien operada. Trasladar la propiedad al usuario traslada también la carga de la durabilidad, y esa carga es real, es cara y casi nadie la asume bien.

La versión más incisiva de la objeción es que la propiedad, aplicada indiscriminadamente, es una forma de externalizar trabajo hacia quien menos preparado está para hacerlo. Delegar la custodia es una división del trabajo perfectamente racional, y la mayor parte de la civilización material funciona así: nadie genera su propia electricidad ni purifica su propia agua para reivindicar su soberanía. La respuesta local-first no puede ser negar esa racionalidad, porque es correcta. Tiene que ser más estrecha y más fuerte a la vez: la delegación es sensata cuando existe una salida practicable, y deja de serlo cuando la única alternativa a seguir pagando es perder el trabajo. Lo que se objeta no es la custodia, es la custodia sin salida, que convierte una relación de servicio en una posición de monopolio sobre lo que has creado.