Local-first es una decisión de producto, no de arquitectura

Cuando alguien propone procesar datos en el dispositivo en vez de en la nube, la conversación suele derivar rápido a lo técnico: modelos cuantizados, WebAssembly, límites de memoria. Es la conversación equivocada para empezar.

La pregunta anterior es de producto: ¿en qué momento está la persona cuando usa esto, y qué necesita que sea cierto en ese momento?

Tres momentos que cambian la respuesta

Cuando el dato es sensible y la persona lo sabe. Un profesional grabando una conversación con un cliente no está evaluando arquitectura; está evaluando si confía. Que el procesamiento ocurra en su equipo no es una optimización, es la razón por la que acepta usar la herramienta.

Cuando la conexión no es un supuesto. En buena parte de Colombia, y de LATAM en general, la conectividad es intermitente antes que mala. Un producto que asume conexión permanente no falla catastróficamente: falla de forma intermitente, que es peor, porque enseña a desconfiar.

Cuando el costo por uso mata la adopción. Si cada acción del usuario cuesta dinero en una API, el producto empieza a limitar el uso. Y un producto que desalienta su propio uso tiene un problema de negocio, no de infraestructura.

Qué se gana y qué se paga

Del lado de lo que se gana: privacidad demostrable, funcionamiento sin conexión, costo marginal cercano a cero, y latencia predecible porque no depende de la red.

Del lado de lo que se paga: modelos más pequeños y por lo tanto menos capaces, distribución más compleja, y una superficie de soporte mayor porque el hardware del usuario ahora es parte del sistema.

Ninguna de las dos listas gana sola. Ganan según el momento.

El patrón que solemos recomendar

Rara vez es todo local o todo en la nube. El patrón que más nos ha funcionado es dividir por sensibilidad y por tamaño:

Lo que es sensible o frecuente, en el dispositivo. Transcripción, clasificación simple, filtrado, primer pase de extracción. Son tareas donde un modelo pequeño alcanza y donde el volumen haría caro el procesamiento remoto.

Lo que requiere razonamiento amplio, en la nube, pero sobre datos ya reducidos. Si el paso local ya extrajo lo relevante, lo que viaja es menos y menos identificable.

Y una regla que sostenemos: la persona debería poder saber qué salió de su equipo. No en un documento legal: en la interfaz.

Cuándo no hacerlo

Si el producto necesita el modelo más capaz disponible para funcionar, local-first todavía no es la respuesta. La brecha entre lo que corre en un portátil y lo que corre en un centro de datos es real.

La decisión honesta ahí es reconocer que el producto depende de la nube y diseñar la confianza por otro lado: siendo explícito sobre qué se envía, por cuánto tiempo se guarda y quién puede verlo.