IA Privada por Menos de lo que Crees: Enmascarado con un Modelo Pequeño en Vez de $100k en GPUs

Últimamente me pasa seguido. Alguien se me acerca —un dueño de empresa, un gerente de operaciones, un colega— y me hace la misma pregunta: "¿cómo corro IA local en mi empresa sin gastar más de dos mil dólares?".

Y tengo que dar la respuesta incómoda: así, como lo imaginas, es imposible. Te lo digo con números propios: nosotros llevamos más de cien mil dólares en infraestructura de IA —GPUs de gama alta, servidores, energía, redundancia— y aún así nos quedamos cortos para correr local lo que un modelo comercial hace por centavos. Dos mil dólares no te alcanzan ni para empezar a competir con eso.

Pero después de oír la pregunta veinte veces entendí algo: casi nadie quiere "IA local" de verdad. Quieren otra cosa, y la están pidiendo mal. Este post es sobre cuál es esa otra cosa, y sobre la arquitectura barata —de verdad barata— que la resuelve.

La Pregunta Equivocada

Cuando alguien insiste en correr el modelo localmente, casi nunca es porque le emocione administrar GPUs. Es por una sola razón de fondo: miedo a que sus datos sensibles salgan de la empresa. Los datos de sus clientes, sus números, sus contratos, sus expedientes. No quieren que eso viaje a un servidor de OpenAI o de quien sea.

Es un miedo legítimo. Pero la conclusión —"entonces todo el modelo tiene que ser local"— es un salto que cuesta una fortuna y casi nunca hace falta. Están atando dos cosas que pueden separarse: privacidad (que lo sensible no salga) y capacidad (que el modelo sea bueno). La pregunta correcta no es "¿cómo corro el modelo grande en mi sótano?". Es: "¿cómo evito que mis datos sensibles salgan, sin renunciar a un modelo potente?".

La Cuenta Real de la IA Local

Vale la pena entender por qué los dos mil dólares no alcanzan, para no engañarse. Para correr local un modelo que se acerque —solo se acerque— a la calidad de un GPT o un Claude actuales, necesitas un modelo grande. Eso significa mucha VRAM: hablamos de GPUs que cuestan miles cada una, y normalmente varias. Súmale el servidor que las aloja, la energía (que no es trivial), el enfriamiento, y el tiempo de alguien que lo mantenga.

Y aun pagando todo eso, un modelo abierto corriendo en tu hardware todavía suele quedar por debajo del modelo comercial de punta, que tiene detrás centros de datos que ni tú ni yo vamos a igualar. Nosotros lo vivimos: la inversión fuerte en GPUs propias se justifica para nuestro caso —volumen, control, experimentación—, pero recomendársela a una PyME que solo quiere automatizar unos procesos sería una irresponsabilidad. Para ese caso hay un camino mil veces más barato.

El Replanteo: Que lo Sensible Nunca Salga

Aquí está el giro. Si el objetivo real es que los datos sensibles no salgan de la empresa, no necesito que el modelo grande sea local. Necesito que el modelo grande nunca vea los datos sensibles. Y eso es un problema mucho más chico —y mucho más barato— de resolver.

¿Y si, antes de mandar nada a la nube, le quito a mi texto todo lo identificable y lo reemplazo por etiquetas? El modelo comercial razonaría sobre un texto anonimizado, devolvería su respuesta con esas mismas etiquetas, y yo —ya de vuelta en casa— volvería a poner los datos reales. El modelo potente hace el trabajo pesado; los datos reales nunca cruzan la puerta.

La Arquitectura: Enmascarar con un Modelo Pequeño

El pipeline tiene tres pasos, y solo el primero necesita correr local —y para eso sí basta hardware barato—:

1. Enmascarar (local). Un modelo pequeño —un SLM que corre en una GPU modesta o hasta en CPU, dentro de tu presupuesto de dos mil dólares— recorre el texto, detecta los datos sensibles (nombres, RFC, correos, montos, direcciones) y los reemplaza por variables. De paso genera un mapa de enmascarado: qué etiqueta corresponde a qué valor real.
2. Procesar (nube). Mandas el texto ya enmascarado al modelo comercial potente. Como nunca ve un dato real, no hay nada sensible que filtrar. Pagas por uso, centavos, sin infraestructura.
3. Desenmascarar (local, por código). La respuesta vuelve con las mismas etiquetas. Un simple reemplazo por código —no hace falta IA aquí— restituye los valores reales usando el mapa. Resultado final con datos reales, generado por un modelo de punta que nunca los tocó.

# 1) Enmascarar con el modelo pequeño local (NER -> mapa)
texto = "Cobrar a Juan Pérez (RFC GODE561231GR8) $48,500 por la póliza."
mascara = {
  "[PERSONA_1]": "Juan Pérez",
  "[RFC_1]": "GODE561231GR8",
  "[MONTO_1]": "$48,500"
}
texto_enmascarado = "Cobrar a [PERSONA_1] (RFC [RFC_1]) [MONTO_1] por la póliza."

# 2) El modelo comercial razona sobre datos anonimizados
respuesta = openai_o_claude(prompt_con(texto_enmascarado))
# -> "Generar recibo a nombre de [PERSONA_1] por [MONTO_1]..."

# 3) Desenmascarar por código (determinista, sin IA)
for etiqueta, valor in mascara.items():
    respuesta = respuesta.replace(etiqueta, valor)
# -> "Generar recibo a nombre de Juan Pérez por $48,500..."

Por Qué Funciona

La clave es repartir el trabajo según lo que cada modelo hace bien:

• El modelo grande no necesita los valores reales para razonar. Para redactar el recibo, decidir el flujo o resumir el caso, le basta la estructura: que hay una persona, un monto, una póliza. Los dígitos exactos del RFC no aportan al razonamiento; solo al resultado final, que se rellena después.
• Enmascarar es una tarea fácil para un modelo pequeño. Detectar y etiquetar entidades (NER) no requiere un modelo de cientos de miles de millones de parámetros. Un SLM —o incluso reglas más un modelo chico— lo hace bien y rápido en hardware accesible. Estás usando IA local solo para lo que la IA local sí puede pagar.
• El desenmascarado es código, no IA. Un reemplazo de cadenas con el mapa es determinista: no alucina, no se equivoca, no cuesta tokens. Lo crítico —volver a unir el dato real con la respuesta— es la parte más confiable de todo el pipeline.
• Los datos sensibles nunca cruzan la red. El mapa de enmascarado vive en tu máquina y nunca se envía. Lo que viaja a la nube ya está anonimizado.

Lo que Nadie te Dice

No es magia, y prometer que lo es sería justo lo que critico de otros. Lo honesto:

• El enmascarado tiene que ser bueno. Si el modelo pequeño se salta una entidad, ese dato se filtra. Por eso conviene reforzarlo con reglas deterministas (regex para RFC, correos, teléfonos, tarjetas) además del modelo, y validar antes de enviar. La privacidad es tan fuerte como tu paso de enmascarado.
• Consistencia de etiquetas. La misma entidad debe recibir siempre la misma etiqueta dentro de un documento, o el modelo grande pierde el hilo de quién es quién. "Juan" y "el Sr. Pérez" deben mapear a [PERSONA_1].
• Hay tareas que sí necesitan el dato real. Si lo que pides depende del valor exacto (cálculos finos sobre el número, validar un RFC contra un padrón), eso se queda local o se resuelve por código. El híbrido es para razonamiento sobre lenguaje, que es el 80% de los casos.
• Full-local sigue teniendo su lugar. Para datos bajo regulación extrema —salud, ciertos esquemas de cumplimiento— donde ni siquiera el texto anonimizado puede salir, ahí sí se justifica la infraestructura local pesada. Pero es la excepción, no el default que todos piden.

Pruébalo: un Demo Visual

Para que esto no se quede en teoría, armé maskflow: un demo visual e interactivo de toda la arquitectura, en github.com/andyeswong/maskflow (Vue 3, client-only). Es un workflow de nodos donde ves en tiempo real cada paso: el resaltado de las entidades detectadas sobre tu texto real, el mapa de enmascarado ([PERSONA_1] → Juan Pérez) que se queda en tu máquina, un panel que verifica automáticamente que salieron cero datos reales en lo que se manda a la nube, y la respuesta del modelo público con etiquetas que el código restituye al final.

Y es configurable de verdad: el nodo enmascarador local habla Ollama nativo u OpenAI-compatible, con refuerzo de regex deterministas (RFC, CURP, email, teléfono, tarjeta, montos) para no depender solo del modelo; y el nodo de nube acepta DeepSeek, OpenRouter, OpenAI, Groq o cualquier endpoint OpenAI-compatible. Pruébalo y míralo por ti mismo: el dato sensible nunca cruza la frontera de privacidad.

Lo que Esto Cambia para una PyME

El presupuesto se vuelve realista. En vez de cien mil dólares en GPUs, necesitas: una máquina modesta para correr el modelo pequeño de enmascarado (un mini-PC con una GPU de entrada, o incluso buena CPU), y pago por uso del modelo comercial —que con datos enmascarados puedes usar sin culpa—. Cumples el requisito que de verdad importaba —que lo sensible no salga— a una fracción del costo, y con la calidad del mejor modelo del mercado.

Eso es lo que termino recomendándole a quien llega con la pregunta de los dos mil dólares: no inviertas en correr el modelo grande; invierte en el muro que mantiene tus datos adentro. El muro es barato. El modelo, réntalo.

Conclusión

La próxima vez que alguien te diga que para tener IA "privada" necesitas gastar una fortuna en GPUs, desconfía. La privacidad y la capacidad son problemas separables. Un modelo pequeño y local que enmascara, un modelo comercial potente que razona sobre datos anonimizados, y un desenmascarado por código: ese es el camino costo-efectivo que casi nadie te explica porque no vende servidores.

Nosotros gastamos los cien mil dólares porque nuestro caso lo pedía. El tuyo, probablemente, no. No preguntes cómo correr el modelo grande en tu empresa. Pregunta cómo evitar que lo sensible salga de ella —y resulta que eso cuesta mucho menos de dos mil dólares—.