IA dentro de casa: cuando los datos no pueden salir

Escrito por

en

Hay una conversación que se repite en empresas chilenas de servicios financieros, salud, legal y sector público. Alguien propone usar IA para una tarea concreta —revisar contratos, clasificar reclamos, apoyar control de calidad— y la respuesta es la misma: no podemos, esos datos no pueden salir.

No es resistencia al cambio. Suele ser una restricción real, y vale la pena entender de dónde viene antes de tratarla como un obstáculo.

De dónde viene la restricción

Rara vez es una sola norma. Normalmente son varias capas superpuestas:

  • Obligaciones contractuales con clientes. Es la más común y la que menos se menciona. Muchos contratos B2B incluyen cláusulas sobre dónde puede residir y procesarse la información del cliente, y sobre a qué terceros se le puede entregar. Un proveedor de IA en la nube es un tercero.
  • El sistema de gestión de seguridad de la información. Una organización con ISO/IEC 27001 tiene controles definidos sobre clasificación de la información, transferencia a terceros y relación con proveedores. Mandar datos clasificados a un servicio externo no es una decisión técnica: es un cambio que pasa por análisis de riesgo y por el control correspondiente.
  • Regulación sectorial y protección de datos personales. Según el rubro, hay exigencias específicas sobre tratamiento y sobre transferencia internacional de datos.
  • Criterio propio. A veces no hay norma que lo prohíba y la empresa simplemente decide que cierta información no sale. Es una razón perfectamente válida.

El punto es que ninguna de estas capas dice «no usen IA». Dicen «esos datos no salen». Son cosas distintas, y la diferencia es exactamente donde está la solución.

Qué cambia cuando el modelo corre adentro

Cuando la inferencia ocurre sobre hardware propio, dentro de la red de la organización, varias preguntas difíciles dejan de existir:

  • No hay transferencia a un tercero. El dato no cruza el perímetro. Eso simplifica el análisis contractual y el de proveedores.
  • No hay ambigüedad sobre entrenamiento. Desaparece la pregunta de si los prompts o los documentos alimentan el modelo de alguien más.
  • La trazabilidad es tuya. Los registros de quién consultó qué están en tus sistemas, con tu política de retención, disponibles para una auditoría sin depender de un tercero.
  • El costo es predecible. Es un activo, no un consumo variable por token. Para cargas sostenidas eso cambia bastante la conversación con finanzas.
  • Funciona sin internet. Relevante en operaciones donde la continuidad importa.

Lo que la IA local no resuelve sola

Conviene ser honesto: poner el equipo adentro no es, por sí solo, cumplimiento.

Un servidor de IA con acceso a información sensible es un activo de información más, y hereda todas las obligaciones que eso implica: control de acceso, segmentación de red, registro de actividad, gestión de vulnerabilidades, respaldo, y un dueño responsable identificado. Si el equipo queda en la red plana de la oficina, accesible desde cualquier notebook, el problema de seguridad no se resolvió: se movió de lugar y se hizo más difícil de ver.

Hay además una capa nueva que muchas organizaciones todavía no incorporan: el modelo mismo y sus datos de ajuste son activos que hay que proteger. Un modelo afinado sobre información propietaria contiene, de alguna forma, esa información. Quién puede copiarlo, dónde se guardan los checkpoints y qué pasa con ellos cuando el equipo se da de baja son preguntas que corresponde responder desde el diseño.

Por eso los equipos de esta categoría vienen con detalles que importan más de lo que parecen. El DGX Spark, por ejemplo, trae almacenamiento NVMe con autocifrado: un disco que sale del equipo no es un disco legible.

Cómo se ordena esto en la práctica

Una secuencia que funciona:

  1. Clasificar la información que va a tocar el sistema. No todo el dato de una empresa tiene la misma sensibilidad, y la arquitectura debería reflejar eso.
  2. Definir el caso de uso concreto y quién lo va a usar. «IA para la empresa» no es un alcance; «asistencia en revisión de contratos para el área legal» sí lo es.
  3. Dimensionar el equipo según el modelo que se va a correr y cuántas personas lo usarán en paralelo. Es lo que separa un DGX Spark de una DGX Station.
  4. Diseñar la red antes de instalar, no después. En la práctica esto significa un segmento aislado y reglas explícitas de quién llega al equipo.
  5. Documentar el control en el sistema de gestión: activo, responsable, riesgos, controles aplicados y evidencia. Si la organización tiene ISO 27001, esto no es trámite: es lo que hace que el proyecto sobreviva a la auditoría.

Los pasos 4 y 5 son los que más se saltan y los que más caro salen después.

Preguntas frecuentes

¿Tener el equipo adentro me hace cumplir con ISO 27001?

No. Elimina el análisis de transferencia a un tercero, que suele ser el punto más difícil, pero el equipo pasa a ser un activo de información sujeto a los mismos controles que el resto: acceso, red, registro, respaldo y responsable asignado.

¿Qué tamaño de modelo puedo correr con datos propios?

Sobre la plataforma GB10, NVIDIA declara inferencia de hasta 200 mil millones de parámetros y fine-tuning de hasta 70 mil millones. Para la mayoría de los casos de uso corporativos —clasificación, extracción, asistencia sobre documentos propios— eso da holgura de sobra.

¿Conviene un equipo por área o uno compartido?

Depende de si las áreas pueden ver los mismos datos. Si no pueden, la separación física es la respuesta más simple de auditar. Si sí pueden, una DGX Station con particionamiento MIG permite atender a varios equipos desde una sola unidad.

¿Y si igual quiero usar la nube para algunas cosas?

Es lo habitual y es razonable. El criterio es la clasificación del dato, no la tecnología: lo sensible se procesa adentro, lo que no lo es puede ir afuera. Tener capacidad propia es justamente lo que permite elegir en vez de renunciar.

Siguiente paso

La parte de red la desarrollamos en Cómo aislar en la red un equipo de IA con datos sensibles. Para la parte de gestión normativa, TECDEX opera TECDEX Compliance, una plataforma chilena para gestionar ISO 27001, 9001 y 42001 con la evidencia centralizada.

Y si quieres revisar tu caso —qué dato, qué uso, qué equipo— solicita una asesoría.