La privacidad suele venderse como una promesa. Debería ser una propiedad. Una promesa es una frase en una página de política donde una empresa dice que no hará mal uso de tus datos. Una propiedad es un arreglo donde no hay nada que malusar en su lado, porque los datos nunca fueron allí. No son la misma garantía, y el hueco entre las dos es una decisión de arquitectura.
La mayoría de herramientas para developers tratan la privacidad del primer tipo. Tu código, la estructura de tu proyecto, tu trabajo viven en sus servidores, y se te pide confiar en la política que gobierna lo que hacen con ello. La política puede ser excelente. La gente puede tener buena intención. Pero estás confiando en una frase, y las frases cambian con una actualización de los términos de servicio que no vas a leer.
El desarrollo con IA local-first trata la privacidad del segundo tipo. Y la diferencia aparece justo cuando importa.
promesa
- una frase de política
- confiar en su intención
- cambia con los términos
propiedad
- nada en su lado
- no exige confianza
- aguanta el peor día
Qué proteges en realidad
Cuando la gente oye “mantén tu código privado” imagina algoritmos propietarios, y casi se encoge de hombros, porque casi ningún código es secreto. Ese encuadre lo infravalora mal.
El código es la capa menos sensible. La fábrica local de software que rodea al código guarda cosas que de verdad no querrías que se filtraran. La estrategia detrás de lo que construyes. Las apuestas que consideraste y mataste, que mapean tu pensamiento mejor que cualquier feature publicada. Las restricciones sensibles de seguridad —los sitios exactos donde está escrito “esto nunca puede pasar”, que es precisamente el mapa que querría un atacante—. Los criterios de aceptación que describen cómo se supone que se comportan las partes sensibles. Notas de discovery con cosas que un cliente te contó en confianza.
Eso no es código fuente. Es la forma del pensamiento de tu empresa. Cuando una herramienta sincroniza todo tu espacio de trabajo a sus servidores para poder ayudarte, eso es lo que entregas, y “no entrenamos con tus datos” no cubre la mayor parte.
Qué garantiza “local” de verdad
Supón que el almacenamiento está en tu disco: un archivo de base de datos, repositorios, evidencia, todo en formatos inspeccionables que puedes abrir tú mismo. Ahora traza qué podría ver un proveedor curioso, comprometido o requerido por un juez.
Nada, porque en su lado no hay nada. No porque prometieran contención, sino porque los datos no tienen copia en su infraestructura que examinar. La garantía es estructural. No depende de sus intenciones, de su postura de seguridad, de su adquisición ni del gobierno que puede obligarlos. Una promesa es tan fuerte como el más débil de esos. Una propiedad no tiene esa cadena de dependencias siquiera.
Eso es lo que significa que la privacidad sea una decisión de arquitectura. No eliges una empresa en la que confiar. Eliges un arreglo donde la confianza no es el elemento que carga el peso. Los datos son inspeccionables para ti y ausentes para todos los demás, y eso es cierto el peor día, no solo el día de marketing.
El límite real: qué sí sale
No voy a fingir que no sale nada, porque una fábrica que no llamara a ningún modelo sería inútil, y mentir aquí envenenaría todo el argumento.
Cuando invocas un modelo remoto, los tokens que le envías —el fragmento de código, el contexto, la instrucción— van a ese proveedor bajo sus términos. Eso es real. Local-first no lo hace desaparecer. Lo que cambia es la forma de la exposición, y la forma es justo la clave.
En vez de que todo tu espacio de trabajo se sincronice sin parar a un servidor como precio de entrada, solo sale el contexto concreto de una llamada concreta, cuando tú decides hacerla. Por defecto, todo se queda. Enviar es la excepción que tomas a propósito, acotada a lo que la tarea necesita. Puedes mirar un fragmento de contexto sensible y decidir que no va a un modelo en la nube en absoluto, y enrutar esa tarea a un motor local. La exposición se vuelve una serie de decisiones deliberadas y acotadas en vez de una rendición general que hiciste al registrarte.
Esa es la diferencia entre “¿qué elijo enviar ahora mismo?” y “¿qué acepté cuando creé la cuenta, y ha cambiado desde entonces?”. La primera es una decisión que conservas. La segunda es una promesa que esperas que aguante.
Qué te da el almacenamiento inspeccionable
Hay un beneficio de segundo orden en mantener los datos en local, y me costó valorarlo bien: puedes mirarlos de verdad.
Cuando tu grafo de producto, tus decisiones y tu evidencia viven en un archivo de base de datos y en repositorios normales en tu disco, puedes abrirlos. Consultarlos. Hacer copia de seguridad en tu propio calendario, a tu propio destino. Buscar con grep. Pasarlos a un script. Moverlos a la siguiente herramienta con un comando de copia. Los datos no están detrás de una API que expone solo lo que el proveedor decidió exponer, en la forma que decidió, al rate limit que fijó.
Esto importa más de lo que suena, porque “tus datos” en una herramienta en la nube suele significar “tus datos, vistos a través de su interfaz”. Los ves, pero no los sostienes. La exportación te da una foto, no la cosa viva, y las conexiones —la parte que lo hacía un sistema y no un montón de registros— a menudo no vienen contigo.
El almacenamiento local inspeccionable reduce a cero la distancia entre “la herramienta tiene mis datos” y “yo tengo mis datos”. No hay paso de exportación porque no hay de dónde exportar; los archivos ya son tuyos, en formatos que puedes leer sin permiso. Esa es la diferencia entre poseer la memoria de tu producto y que te concedan una vista de ella. La privacidad es el beneficio de titular del almacenamiento local. La propiedad sobre la que puedes actuar es el que notas cada vez que quieres hacer algo que el proveedor no anticipó.
Por qué merece diseñarse así ahora
Dos cosas lo vuelven más agudo que hace unos años.
El volumen que se mueve por estas herramientas explotó. Los agentes leen y escriben por todo tu código, arrastran contexto de forma agresiva, tocan mucho más de tu espacio de trabajo de lo que un humano editando un archivo hizo nunca. La superficie de lo que ve una herramienta sincronizada a la nube creció con la capacidad. Más potencia, más exposición, del mismo diseño.
Y el valor se concentró justo en las partes que una buena herramienta de IA más necesita. Para ser genuinamente útil, un agente quiere tus decisiones, tus restricciones, tus criterios de aceptación, tu historia de producto: la forma sensible, no solo el código. Así que las herramientas que más ayudan son las que tienen la mayor tentación de centralizar lo que menos querrías centralizar. Local-first es la salida de ese aprieto: la herramienta puede ver todo lo que necesita para ser útil, porque corre donde los datos ya están, y nada tiene que enviarse a un servidor para que la ayuda ocurra.
Dónde encaja PaellaDoc
PaellaDoc mantiene tu grafo de producto, tus repositorios, tus decisiones y tu evidencia en almacenamiento local en tu máquina macOS, en formatos que puedes inspeccionar. Llama a los modelos que elijas —proveedores en la nube con tus propias claves, o motores locales— y solo sale el contexto de una llamada dada, cuando la haces. No hay cuenta, así que no hay para empezar un perfil tuyo y de tu trabajo en ningún servidor. Gratis hasta tres proyectos.
La privacidad como banner te pide confiar en una empresa. La privacidad como arquitectura te pide confiar en un diseño que puedes inspeccionar. Que tu código, y el pensamiento a su alrededor, se queden en tu máquina no es una feature que atornillé encima. Es dónde guarda las cosas el sistema, que es la única versión de la privacidad que sigue en pie el día que cuenta.
Preguntas frecuentes
¿Se envía mi código a la nube al usar herramientas de IA?
Depende de la arquitectura de la herramienta. Muchas sincronizan todo tu espacio de trabajo a sus servidores como precio de ser útiles. Una herramienta local-first mantiene tu código, tu grafo de producto, tus decisiones y tu evidencia en tu disco, y solo envía fuera el contexto concreto de una llamada concreta al modelo, cuando la haces. Por defecto todo se queda; enviar se vuelve la excepción acotada que tomas a propósito, no una sincronización general.
¿Qué datos salen de verdad cuando un agente llama a un modelo?
Solo los tokens de esa llamada —el fragmento de código, el contexto y la instrucción que pasas— van al proveedor bajo sus términos. Eso es real y local-first no lo hace desaparecer. Lo que cambia es la forma: en vez de que todo tu espacio de trabajo viva en un servidor, sale el contexto de una llamada cuando tú eliges. Puedes mirar contexto sensible y enrutar esa tarea a un motor local para que no salga nada.
¿Qué diferencia hay entre la privacidad como política y como arquitectura?
Una política es una frase que promete que una empresa no hará mal uso de tus datos; cambia con una actualización de los términos que no vas a leer. La arquitectura es un arreglo donde no hay nada que malusar en su lado, porque los datos nunca fueron allí. La garantía es estructural: no depende de sus intenciones, su seguridad, su adquisición ni de un juez. Aguanta el peor día, no solo el día de marketing.
¿Solo estoy protegiendo el código fuente?
No, y ese encuadre lo infravalora. El código es la capa menos sensible. La fábrica que lo rodea guarda la estrategia detrás de lo que construyes, las apuestas que mataste, las restricciones sensibles de seguridad, los criterios de aceptación de las partes sensibles y notas de discovery contadas en confianza. Eso es la forma del pensamiento de tu empresa, y es justo lo que entrega una herramienta que sincroniza el espacio de trabajo. “No entrenamos con tus datos” no cubre la mayor parte.