IA local para empresa: modelos, privacidad, coste y viabilidad · Módulo 1: Requisitos y encaje
Clasificar requisitos de privacidad, latencia y control
Método para traducir razones genéricas para usar IA local en requisitos medibles de datos, conectividad, latencia, continuidad, seguridad y control.
Objetivo de aprendizaje
Convertir privacidad, conectividad, latencia, control y continuidad en requisitos MUST/SHOULD y pruebas verificables antes de comparar arquitecturas.
La decisión de ejecutar un modelo localmente suele empezar con una frase demasiado general: «no queremos que los datos salgan» o «necesitamos más control». Son motivos legítimos para investigar, pero todavía no son requisitos técnicos.
La primera lección consiste en convertirlos en condiciones verificables. Solo después podrás comparar una API externa con un servidor propio, una workstation, un dispositivo de borde o una arquitectura híbrida.
Empieza por la tarea
Delimita una única carga:
- qué entrada recibe;
- qué salida produce;
- cuántas veces se ejecuta;
- cuánto contexto necesita;
- qué usuarios la utilizan;
- qué datos atraviesan el sistema;
- qué ocurre si falla;
- qué alternativas existen.
«Usar IA local en la empresa» es demasiado amplio. «Clasificar 15.000 documentos mensuales con 12 categorías y devolver evidencia» es evaluable.
Privacidad no significa únicamente ubicación
Ejecutar la inferencia en un servidor propio cambia el flujo de datos: puede evitar enviar prompts o documentos a un proveedor externo para esa inferencia concreta. Pero privacidad depende del sistema completo.
Debes revisar:
entrada → aplicación → almacenamiento → inferencia → logs → backups → herramientas → salida
Un servicio local puede seguir filtrando información si:
- los logs contienen prompts;
- la administración está expuesta;
- los backups no están protegidos;
- una tool llama a Internet;
- el host está comprometido;
- varios tenants comparten datos sin aislamiento;
- el sistema descarga artefactos o telemetría sin control.
Por tanto, formula requisitos específicos:
«Los documentos de producción no podrán salir de la red X durante inferencia.»
«Los logs no almacenarán contenido completo.»
«El servidor no tendrá acceso saliente salvo a repositorios aprobados durante mantenimiento.»
Esas condiciones pueden probarse.
Cuando se traten datos personales sujetos al RGPD, la ejecución local no elimina por sí sola principios como finalidad, minimización, seguridad o conservación. El diseño técnico debe integrarse con la revisión de privacidad correspondiente; este minicurso no sustituye esa revisión.
Conectividad y continuidad
La operación local puede ser útil cuando existe:
- conectividad intermitente;
- requisito offline;
- fábrica o sucursal aislada;
- procesamiento en dispositivo;
- necesidad de seguir funcionando aunque falle Internet o un proveedor.
Pero local también crea dependencias:
- electricidad;
- refrigeración;
- hardware;
- drivers;
- almacenamiento;
- personal;
- repuestos.
Define la continuidad como un objetivo.
Ejemplo:
«El sistema debe seguir clasificando durante una interrupción WAN de cuatro horas.»
Eso permite diseñar una prueba.
Latencia
«Local será más rápido» no es una regla.
La latencia depende de:
- hardware;
- tamaño del modelo;
- longitud del prompt;
- tokens generados;
- concurrencia;
- batching;
- cuantización;
- software de serving;
- red de la API externa.
Una workstation puede responder muy rápido para un usuario y degradarse con 20 solicitudes concurrentes. Una API remota puede añadir red y aun así ofrecer mayor throughput.
Define métricas:
- tiempo hasta primer token;
- tiempo total;
- p50/p95;
- máximo tolerable;
- tokens/s cuando sea relevante.
MLPerf y otros benchmarks distinguen escenarios precisamente porque una cifra aislada no describe todas las cargas.
Control operativo
«Queremos control» puede significar varias cosas:
- fijar versión del modelo;
- controlar cuándo se actualiza;
- impedir tráfico externo;
- inspeccionar logs;
- adaptar el runtime;
- operar offline;
- elegir hardware;
- limitar costes variables.
Cada una debe escribirse por separado.
También existe el coste del control: si tú decides la versión, tú eres responsable de actualizar, probar, parchear, monitorizar y retirar.
Dependencia y soberanía técnica
La ejecución local puede reducir dependencia de una API concreta, pero puede aumentar dependencia de:
- una familia de hardware;
- un runtime;
- un formato;
- una licencia;
- un ecosistema de drivers.
No evalúes «lock-in» como sí/no. Identifica qué componente sería difícil de sustituir.
Seguridad
Incluye:
- autenticación;
- autorización;
- segmentación de red;
- administración;
- secretos;
- cifrado;
- parches;
- dependencias;
- imágenes;
- acceso físico;
- backups.
Un servidor dentro de la oficina no es seguro por definición.
Construye una matriz de requisitos
Ejemplo:
| Requisito | Tipo | Objetivo | Cómo medir |
|---|---|---|---|
| Datos no salen de red | privacidad | obligatorio | captura de tráfico |
| p95 < 3 s | rendimiento | objetivo | benchmark |
| 10 usuarios concurrentes | capacidad | obligatorio | load test |
| servicio offline | continuidad | deseable | simulación |
| actualización mensual | operación | objetivo | runbook |
Separa:
MUST / SHOULD / NICE TO HAVE
Una opción que incumple un MUST se descarta aunque gane en otras métricas.
NIST como estructura
NIST AI RMF puede ayudarte a formular riesgo, medición y gestión de controles, pero NIST lo presenta como un marco voluntario. Úsalo como referencia metodológica, no como certificado.
Ejercicio
Elige una carga real y redacta:
- finalidad;
- usuarios;
- volumen;
- datos;
- privacidad;
- conectividad;
- latencia;
- throughput;
- disponibilidad;
- control;
- seguridad;
- dependencia;
- coste;
- MUST/SHOULD.
Después escribe una prueba para cada MUST.
Resultado de la lección
Debes terminar con un conjunto de requisitos medibles. En la siguiente lección comprobarás si algún modelo y hardware concretos pueden satisfacerlos y si su licencia permite el uso previsto.