IA self-hosted: usar inteligencia artificial sin filtrar datos (ni infringir la LGPD)

Un analista pega una planilla con nombres, números de identificación fiscal y montos en un asistente de IA público para "resumir rápido". La respuesta llega en segundos — y el dato acaba de salir de tu empresa, cruzó la frontera y terminó en un servidor que no controlas. Nadie lo vio. Ninguna alarma sonó. Y, técnicamente, puede que acabes de tratar datos personales sin base legal.

Este es el incidente de IA más común en las empresas hoy — y el más silencioso. No es un hacker; es gente competente intentando trabajar mejor. El problema no es la intención. Es la arquitectura: cuando la inteligencia vive en la nube de un tercero, todo dato que le envías sale de tu casa.

01La fuga que nadie ve

Cuando envías un prompt con datos sensibles a una IA pública, tres cosas escapan de tu control a la vez: adónde va el dato (servidores de terceros, muchas veces fuera del país), por cuánto tiempo queda retenido y para qué puede usarse después. Tú no firmaste eso — pero el dato de tu cliente, sí.

Y como no hay una "fuga" en el sentido dramático — nada es hackeado, nada sale en la prensa — el riesgo permanece invisible hasta el día en que hay que explicarlo. A un cliente. A una auditoría. A la ANPD, la autoridad brasileña de protección de datos.

02Por qué la LGPD entra en escena

La LGPD no prohíbe usar IA. Pero exige tres cosas que la IA pública, tal como suele usarse, atropella: base legal para tratar ese dato, minimización (enviar solo lo necesario — y un prompt crudo casi nunca lo es) y cuidado con la transferencia internacional. Pegar datos personales en un chatbot de terceros tiende a fallar en las tres a la vez.

El punto no es jerga jurídica para asustar. Es que estas tres exigencias, cuando las tomas en serio, apuntan todas a la misma solución técnica.

03La respuesta no es prohibir la IA — es cambiar dónde se ejecuta

La reacción instintiva de muchas empresas es bloquear las herramientas de IA. No funciona: la productividad es real, así que la gente encuentra la manera — y el uso se vuelve clandestino, todavía peor. La mejor salida es invertir la arquitectura.

Los modelos de lenguaje pueden ejecutarse en tu propia infraestructura — inferencia local, aislada por cliente (con herramientas como Ollama), on-premise o self-hosted. El dato se procesa en casa y no va a la nube de nadie. Mantienes la inteligencia y el control. Y, como el código y el entorno son tuyos, no hay lock-in: nada te ata a un proveedor.

04El candado que falta: detener lo sensible en la puerta

Ejecutar el modelo en casa resuelve el caso de uso interno. Pero a veces un servicio externo de IA es útil de verdad — y ahí necesitas un candado en la puerta de salida: algo que inspeccione lo que está por salir y detenga lo que sea sensible antes de que se convierta en una petición.

Ese es el papel de una capa de DLP para IA. En nuestro caso, es ZDZAIShield: se ubica en el camino de las llamadas a IAs públicas y bloquea (HTTP 403) el envío de datos sensibles — la petición ni siquiera llega al tercero. La IA pública sigue disponible para lo inofensivo; lo que es PII se detiene en la puerta. La diferencia entre una política que pide cuidado y un control que lo garantiza.

05Lo que ganas

No se trata solo de evitar multas. Es poder usar la IA de verdad — en los datos que importan, los internos — sin convertir cada uso en un riesgo. Es la LGPD cumplida por diseño, no por un documento que nadie lee. Y es la tranquilidad de responder, cuando alguien pregunte "¿adónde van nuestros datos?", con una frase corta: a ningún lugar que no controlemos.

IA y privacidad no son un trade-off que debas aceptar. Con la arquitectura correcta — inteligencia que se ejecuta en tu casa y un candado que retiene lo sensible en la puerta — puedes tener ambas. Esa es, de hecho, la vara honesta que aplicamos: donde hay IA, lo señalamos; y donde hay datos, quedan bajo tu control.