Infraestructura preparada para inteligencia artificial privada

Introducción

Preparar una infraestructura para inteligencia artificial privada no consiste simplemente en comprar una tarjeta gráfica potente y descargar un modelo. Consiste en diseñar un entorno donde la empresa pueda utilizar modelos de IA con control suficiente sobre los datos, los accesos, la capacidad de cálculo, los costes, las actualizaciones y la continuidad del servicio.

La IA privada puede ejecutarse en un ordenador profesional, una estación de trabajo, un servidor propio, una máquina dedicada en un centro de datos o una arquitectura híbrida. Lo decisivo no es que todo esté físicamente dentro de la oficina, sino que la organización conozca dónde se procesan los datos, qué modelo utiliza, quién puede acceder, qué información se conserva y cómo se sustituye el sistema si deja de ser adecuado.

Para una microempresa, la privacidad no debe confundirse con aislamiento. Puede ser razonable utilizar componentes externos para determinadas tareas y reservar la infraestructura privada para información sensible, documentos internos, propiedad intelectual, atención al cliente o procesos que no conviene enviar a servicios de terceros.

También es importante distinguir entre ejecutar un modelo, ajustarlo y entrenarlo desde cero. Son cargas muy diferentes. Muchas empresas necesitan inferencia privada y recuperación de información sobre documentos propios, pero no necesitan construir un gran centro de cálculo ni entrenar modelos fundacionales.

Este artículo presenta los requisitos generales para construir una infraestructura de inteligencia artificial privada proporcionada, segura, mantenible y capaz de evolucionar. El enfoque está pensado para profesionales, microempresas y PYMES de distintos sectores que desean aprovechar modelos locales o dedicados sin perder el control tecnológico ni asumir una complejidad innecesaria.

Índice

• Qué es una infraestructura de inteligencia artificial privada
• IA privada, IA local e IA híbrida: diferencias
• Qué casos de uso justifican una infraestructura privada
• Inferencia, ajuste y entrenamiento: tres cargas distintas
• Arquitectura general de una plataforma de IA privada
• 1. Modelos, formatos, licencias y ciclo de vida
• 2. Capacidad de cálculo: CPU, GPU y aceleradores
• 3. Memoria RAM, VRAM y contexto
• 4. Almacenamiento para modelos, datos y resultados
• 5. Red, acceso y separación de entornos
• 6. Sistema operativo, runtimes y servidor de inferencia
• 7. Datos privados, documentos y preparación de información
• 8. RAG y búsqueda sobre información empresarial
• 9. Seguridad, identidades y protección de secretos
• 10. Monitorización, registros y evaluación
• 11. Copias, recuperación y continuidad
• 12. Gobierno, riesgos y responsabilidad humana
• Modelos de arquitectura para distintos tamaños
• Método práctico para dimensionar la infraestructura
• Hoja de ruta de implantación
• Aplicaciones en empresas de distintos sectores
• Costes que deben calcularse
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué es una infraestructura de inteligencia artificial privada

Una infraestructura de inteligencia artificial privada es el conjunto de equipos, software, modelos, datos, redes, identidades, procedimientos y controles que permite utilizar IA bajo un nivel de gobierno definido por la organización.

El concepto no exige necesariamente que la empresa sea propietaria de todos los componentes físicos. Puede utilizar un servidor dedicado alojado externamente o una nube privada siempre que conserve control suficiente sobre:

• los datos enviados al modelo;
• la ubicación y conservación de esos datos;
• las personas y aplicaciones autorizadas;
• el modelo y la versión utilizada;
• la configuración de inferencia;
• los registros generados;
• las copias y procedimientos de recuperación;
• la capacidad de migrar o sustituir la plataforma;
• los costes y límites de operación;
• la revisión humana de los resultados.

La privacidad, por tanto, no depende únicamente de que el modelo se ejecute sin conexión a Internet. Un sistema local puede ser poco privado si guarda conversaciones sin control, comparte carpetas indiscriminadamente o utiliza cuentas comunes. Del mismo modo, un servidor externo dedicado puede ofrecer un nivel alto de control si está correctamente aislado, cifrado, administrado y documentado.

La infraestructura privada debe formar parte de la arquitectura digital general. No es una caja separada. Se conecta con almacenamiento, bases de datos, aplicaciones, usuarios, copias, monitorización y procesos empresariales. Para comprender esa relación resulta útil revisar qué componentes forman una infraestructura digital moderna.

La IA privada no consiste en poseer un modelo, sino en gobernar de forma efectiva el recorrido completo de los datos, la ejecución y los resultados.

IA privada, IA local e IA híbrida: diferencias

IA local

La IA local se ejecuta en un dispositivo o servidor controlado directamente por la organización: un portátil, una estación de trabajo, un servidor de oficina o un equipo dentro de su propia red.

Sus ventajas pueden incluir:

• procesamiento sin enviar datos a un servicio público;
• funcionamiento sin conexión externa para determinados usos;
• coste previsible cuando la carga es estable;
• control directo sobre modelos y versiones;
• latencia baja dentro de la red local.

También exige administrar hardware, energía, refrigeración, actualizaciones, seguridad y copias.

IA privada dedicada

La carga se ejecuta en infraestructura reservada para la empresa, aunque esté alojada en un centro de datos o proveedor externo. La organización conserva administración, aislamiento y políticas de datos.

Este modelo evita instalar equipos en la oficina y puede mejorar conectividad y disponibilidad, pero mantiene costes recurrentes y dependencia del proveedor de infraestructura.

IA privada gestionada

Un proveedor administra una plataforma dedicada o una instancia aislada. La empresa debe revisar cuidadosamente qué datos conserva el proveedor, quién puede acceder, cómo se realizan las copias y qué capacidad de exportación existe.

IA híbrida

Combina varios entornos. Por ejemplo:

• clasificación de documentos sensibles en local y tareas generales en un servicio externo;
• modelo pequeño local para uso diario y modelo mayor bajo demanda;
• datos privados en infraestructura propia y capacidad de cálculo temporal externa;
• RAG privado con un modelo remoto que recibe solo fragmentos minimizados;
• pruebas en una estación de trabajo y producción en un servidor dedicado.

El modelo híbrido puede equilibrar coste, privacidad y capacidad, pero necesita un mapa claro de qué información puede salir y qué procesos deben permanecer bajo control directo.

La decisión se parece a la comparación entre infraestructura propia y cloud público: no existe un ganador universal. Debe decidirse carga por carga.

Qué casos de uso justifican una infraestructura privada

No toda consulta a un modelo necesita una plataforma privada. La inversión se justifica cuando la combinación de privacidad, volumen, latencia, coste o control aporta un valor claro.

Documentación interna

La empresa puede utilizar IA para consultar procedimientos, contratos, documentación técnica, manuales, informes, históricos o contenidos propios sin enviar el repositorio completo a una plataforma pública.

Propiedad intelectual

Guiones, cursos, código, diseños, metodologías, investigaciones y materiales no publicados pueden requerir un entorno controlado.

Atención y soporte

Un asistente interno puede ayudar a clasificar consultas, recuperar respuestas o preparar borradores utilizando una base documental de la empresa. La respuesta final puede seguir bajo revisión humana.

Procesamiento de documentos

Extracción, resumen, clasificación y comparación de documentos pueden ejecutarse en un entorno privado cuando contienen datos personales, económicos o estratégicos.

Ayuda técnica y programación

Una empresa puede utilizar modelos locales para explicar código, generar pruebas, revisar configuraciones o consultar documentación sin exponer repositorios a servicios externos.

Operación sin conectividad estable

Determinados entornos pueden necesitar inferencia sin depender de Internet o de la disponibilidad de un proveedor.

Volumen repetitivo

Cuando la carga es estable y elevada, una infraestructura propia bien dimensionada puede ofrecer costes más previsibles que el pago por uso. Sin embargo, debe incluirse el coste total de hardware, energía, mantenimiento y renovación.

Experimentación controlada

La empresa puede comparar modelos, parámetros, cuantizaciones y flujos sin enviar datos reales a múltiples plataformas.

La existencia de un caso de uso no obliga a procesar todo con IA. Antes debe analizarse si una búsqueda tradicional, una regla, una base de datos o una automatización convencional resolverían el problema de forma más sencilla.

Inferencia, ajuste y entrenamiento: tres cargas distintas

Inferencia

La inferencia consiste en utilizar un modelo ya entrenado para generar una respuesta, clasificar información, crear una representación vectorial o analizar una entrada.

Es la necesidad más habitual de una empresa pequeña. Puede ejecutarse con modelos cuantizados y hardware moderado, especialmente cuando el número de usuarios simultáneos es reducido.

RAG

La generación aumentada por recuperación, conocida como RAG, añade información empresarial relevante al contexto del modelo. No modifica los pesos del modelo. Recupera fragmentos de documentos y los utiliza para responder.

Para muchas empresas, RAG aporta más valor y menos riesgo que entrenar o ajustar un modelo.

Ajuste ligero

El ajuste modifica parcialmente el comportamiento de un modelo mediante técnicas como adaptadores. Puede servir para adaptar estilo, formato o tareas específicas, pero requiere datos de entrenamiento, evaluación y mayor capacidad de cálculo.

Entrenamiento desde cero

Entrenar un modelo fundacional exige grandes conjuntos de datos, numerosas aceleradoras, almacenamiento rápido y una operación especializada. Rara vez es una opción razonable para una microempresa.

La primera decisión de infraestructura debe ser identificar cuál de estas cargas se necesita realmente. Comprar hardware para entrenamiento cuando solo se requiere inferencia puede multiplicar el coste sin aportar valor.

Arquitectura general de una plataforma de IA privada

Una plataforma funcional puede dividirse en varias capas:

1. Usuarios y aplicaciones: interfaz web, cliente de escritorio, API o integración empresarial.
2. Autenticación y permisos: determina quién puede utilizar cada modelo y documento.
3. Orquestación: prepara instrucciones, controla herramientas y coordina procesos.
4. Servidor de inferencia: carga el modelo y atiende solicitudes.
5. Modelos: archivos de pesos, tokenizadores, adaptadores y configuraciones.
6. Datos: documentos, bases de datos, vectores, historiales y resultados.
7. Capacidad de cálculo: CPU, GPU, memoria y almacenamiento.
8. Observabilidad: métricas, registros, trazas y evaluación.
9. Seguridad: cifrado, segmentación, secretos y actualización.
10. Continuidad: copias, restauración, inventario y alternativas.

Usuarios y aplicaciones
          │
          ▼
Autenticación y control de acceso
          │
          ▼
API u orquestador
      ┌───┴──────────┐
      ▼              ▼
Servidor de IA     Recuperación documental
      │              │
      ▼              ▼
Modelos         Índice y documentos
      └──────┬───────┘
             ▼
        Resultado
             │
             ▼
Registros, métricas y revisión

Seguridad, copias y gobierno atraviesan todas las capas.

No todas las empresas necesitan desplegar cada capa como un producto independiente. Un único equipo puede ejecutar varias funciones. La separación es conceptual: ayuda a saber qué debe protegerse, medirse y sustituirse.

1. Modelos, formatos, licencias y ciclo de vida

El modelo es un componente de software con requisitos, condiciones de uso y comportamiento propios. No debe tratarse como un archivo anónimo descargado una vez y olvidado.

Seleccionar por tarea

Un modelo grande no es automáticamente mejor para todos los usos. La selección debe considerar:

• idiomas;
• tipo de tarea;
• longitud de contexto;
• calidad de razonamiento necesaria;
• velocidad aceptable;
• memoria disponible;
• soporte de herramientas o imágenes;
• licencia;
• capacidad de actualización;
• resultados obtenidos con datos reales de prueba.

Cuantización

La cuantización reduce la precisión numérica de los pesos para disminuir tamaño y consumo de memoria. Puede permitir ejecutar modelos mayores en hardware más modesto y acelerar la inferencia, aunque puede introducir pérdida de calidad.

No existe un nivel universalmente correcto. Conviene probar varias configuraciones sobre tareas representativas y medir calidad, velocidad y memoria.

Formato y compatibilidad

El formato afecta a las herramientas capaces de cargar el modelo, las aceleraciones disponibles y la portabilidad. La empresa debe registrar:

• origen del modelo;
• versión;
• formato;
• nivel de cuantización;
• tokenizador;
• licencia;
• fecha de descarga;
• huella o suma de verificación;
• pruebas realizadas;
• configuración recomendada.

Licencias

“Abierto” no significa necesariamente que cualquier uso comercial esté permitido sin condiciones. Deben revisarse derechos de uso, redistribución, modificación, atribución y restricciones específicas.

Repositorio controlado

Los modelos aprobados deben almacenarse en una ubicación empresarial, no depender de descargas improvisadas por cada usuario. El repositorio debe evitar duplicidades y permitir recuperar una versión anterior.

Evaluación antes de sustituir

Actualizar al modelo más reciente sin pruebas puede modificar formatos de respuesta, consumo y comportamiento. Cada cambio debe compararse con un conjunto de casos conocido.

2. Capacidad de cálculo: CPU, GPU y aceleradores

CPU

La CPU puede ejecutar modelos pequeños o cuantizados, tareas de embeddings, preparación de documentos y procesos auxiliares. También puede asumir parte del modelo cuando la memoria de la GPU es insuficiente.

El rendimiento depende de arquitectura, número de núcleos, instrucciones disponibles, ancho de banda de memoria y optimización del runtime.

GPU

La GPU acelera operaciones matriciales y suele mejorar mucho la velocidad de inferencia. Para modelos generativos, la memoria de vídeo suele ser un criterio más limitante que la potencia teórica.

Conviene analizar:

• VRAM disponible;
• ancho de banda de memoria;
• compatibilidad con el software elegido;
• consumo eléctrico;
• refrigeración;
• espacio físico;
• fuente de alimentación;
• garantía y disponibilidad;
• capacidad de ampliar con otra GPU;
• carriles PCIe y distribución de ranuras.

Aceleradores integrados

Algunos procesadores incorporan GPU o NPU con memoria compartida. Pueden resultar útiles para inferencia local eficiente, aunque la compatibilidad y el rendimiento dependen del modelo y del runtime.

Una o varias GPU

Dividir un modelo entre varias GPU permite utilizar más memoria total, pero añade comunicación entre dispositivos. El rendimiento puede quedar limitado por PCIe o por la arquitectura de reparto.

Antes de comprar varias tarjetas conviene comprobar que el software soporta el modelo de distribución deseado y que la placa base ofrece las ranuras y carriles adecuados.

CPU más GPU

La inferencia híbrida puede cargar una parte del modelo en GPU y otra en memoria principal. Permite ejecutar modelos que no caben completamente en VRAM, aunque normalmente reduce la velocidad.

Dimensionar por servicio, no por demostración

Un modelo que responde correctamente a un usuario puede saturarse con varias solicitudes simultáneas. La capacidad debe medirse con el número real de usuarios, el contexto esperado y la latencia aceptable.

La elección debe integrarse en una visión más amplia sobre qué ordenador necesita realmente una PYME, evitando reducir toda la compra a la GPU.

3. Memoria RAM, VRAM y contexto

La memoria determina qué modelo puede cargarse, cuánto contexto puede procesarse y cuántas solicitudes simultáneas pueden mantenerse.

Memoria de los pesos

El tamaño del archivo del modelo ofrece una primera aproximación, pero no representa todo el consumo. También hay estructuras auxiliares, buffers y memoria del runtime.

Caché de contexto

Durante la inferencia, el sistema conserva información de los tokens procesados. El consumo crece con la longitud de contexto, el número de capas, la arquitectura y las solicitudes concurrentes.

Un modelo puede cargar correctamente y quedarse sin memoria al recibir documentos largos o varios usuarios.

RAM del sistema

La RAM debe cubrir:

• sistema operativo;
• modelo cuando se ejecuta total o parcialmente en CPU;
• cachés;
• base vectorial;
• procesamiento de documentos;
• servicios auxiliares;
• margen para picos.

VRAM

La VRAM debe alojar pesos, cachés y operaciones del modelo. Para una estación de trabajo, suele ser preferible priorizar memoria suficiente para la carga elegida antes que perseguir únicamente la GPU más rápida.

Memoria compartida

En arquitecturas unificadas, CPU y acelerador comparten memoria. Esto puede permitir modelos grandes sin copiar datos entre memorias separadas, aunque el rendimiento depende del ancho de banda y de la implementación.

Concurrencia

Cada sesión simultánea puede aumentar el consumo. El dimensionamiento debe incluir el número máximo de usuarios y no solo una prueba individual.

Margen operativo

No conviene diseñar para ocupar permanentemente el cien por cien de la memoria. Debe existir margen para variaciones, actualizaciones y tareas auxiliares.

Compatibilidad del hardware y rendimiento en entornos de IA exigentes

La compra de una GPU potente no garantiza un buen rendimiento. En inteligencia artificial intervienen la cantidad de VRAM, el ancho de banda de memoria, la velocidad del SSD, la RAM, la CPU, la placa base, la versión de los controladores y la compatibilidad del software de inferencia.

La VRAM suele ser el primer cuello de botella

Muchos modelos dejan de funcionar correctamente no por falta de potencia de cálculo, sino porque no caben completamente en la memoria de vídeo. Cuando esto ocurre el sistema descarga parte del modelo a la RAM principal y el rendimiento puede caer de forma muy significativa.

Compatibilidad entre hardware y software

No todos los aceleradores ofrecen el mismo nivel de soporte. Antes de invertir conviene verificar la compatibilidad entre GPU, controladores, bibliotecas de aceleración, runtime de inferencia y formato de los modelos que realmente utilizará la empresa.

El resto del equipo también importa

Una CPU lenta, poca RAM, un SSD saturado o una placa base con pocas líneas PCIe pueden limitar el rendimiento de una GPU muy potente. El dimensionamiento debe hacerse sobre el conjunto de la plataforma.

Preparar ampliaciones futuras

Siempre que sea posible conviene elegir una plataforma que permita ampliar memoria, almacenamiento o GPU sin sustituir completamente el servidor.

4. Almacenamiento para modelos, datos y resultados

Una plataforma de IA privada puede consumir almacenamiento con rapidez. No solo por los modelos, sino por documentos, índices, versiones, registros y resultados.

Modelos

Varias cuantizaciones y versiones pueden ocupar decenas o cientos de gigabytes. Conviene evitar que cada usuario mantenga copias separadas.

Datos fuente

Documentos, imágenes, audio, vídeo, bases de datos y contenidos internos necesitan una ubicación oficial con permisos y copias.

Índices y embeddings

Los sistemas RAG generan representaciones y metadatos que deben reconstruirse cuando cambia el modelo de embeddings, la segmentación o el documento original.

Registros

Guardar todas las instrucciones y respuestas de forma indefinida puede crear un repositorio sensible y costoso. Debe definirse qué se registra, durante cuánto tiempo y con qué finalidad.

Rendimiento

Los modelos se benefician de almacenamiento rápido durante la carga. El procesamiento masivo de documentos también puede requerir buen rendimiento de lectura y escritura.

Separar datos activos, archivo y copia

• activo: modelos y datos utilizados regularmente;
• archivo: versiones retiradas, pruebas e históricos;
• copia: información necesaria para recuperar el servicio.

RAID o redundancia no sustituyen a las copias. Para diseñar la capacidad puede utilizarse el enfoque de cómo dimensionar almacenamiento empresarial.

5. Red, acceso y separación de entornos

La IA privada debe integrarse en la red sin exponer innecesariamente el servidor de inferencia.

Acceso local

En una oficina, los usuarios pueden acceder mediante una interfaz interna o API protegida. El servidor no necesita publicarse directamente en Internet.

Acceso remoto

El teletrabajo puede resolverse con VPN, acceso de confianza cero o una pasarela autenticada. No conviene abrir el puerto del servidor de IA sin controles adicionales.

Segmentación

Puede ser útil separar:

• usuarios;
• servidores;
• almacenamiento documental;
• entorno de pruebas;
• administración;
• servicios expuestos.

Ancho de banda interno

Si los modelos y datos residen en almacenamiento de red, la velocidad y latencia pueden afectar a cargas y procesamiento. Los archivos de modelo utilizados en producción suelen funcionar mejor en almacenamiento local rápido o caché controlada.

Salida a Internet

Un entorno privado puede necesitar Internet para descargar modelos y actualizaciones. La salida debe estar controlada y no implicar que el servidor envíe automáticamente conversaciones o telemetría.

Entorno aislado

Para datos especialmente sensibles puede utilizarse una red restringida. Sin embargo, el aislamiento aumenta la carga de actualizaciones, transferencia de modelos y soporte. Debe justificarse por riesgo real.

6. Sistema operativo, runtimes y servidor de inferencia

Sistema operativo

Debe tener soporte, controladores compatibles, actualizaciones y una base conocida por quien administrará el equipo. Linux es habitual en servidores, pero una estación de trabajo puede utilizar otros sistemas si el runtime elegido ofrece soporte estable.

Controladores y bibliotecas

GPU, aceleradores y runtimes dependen de versiones concretas. Conviene documentar controladores, bibliotecas y compatibilidad para evitar que una actualización deje el servicio inoperativo.

Runtime de inferencia

El runtime carga el modelo y ejecuta las operaciones. La elección debe considerar:

• formatos soportados;
• CPU y GPU compatibles;
• cuantización;
• uso de varias GPU;
• servidor API;
• concurrencia;
• registros;
• actualizaciones;
• comunidad y documentación;
• facilidad de exportar la configuración.

Servidor de inferencia

Debe controlar colas, límites, autenticación, tiempo de espera y memoria. Una interfaz de chat de escritorio puede ser suficiente para una persona, pero no para varias aplicaciones o usuarios.

Contenedores

Los contenedores pueden facilitar despliegues reproducibles y separar dependencias, pero no resuelven por sí solos acceso a GPU, persistencia, seguridad ni copias. La decisión puede apoyarse en cómo usar contenedores en PYMES.

Virtualización

Una máquina virtual puede aislar servicios y facilitar recuperación. El acceso a GPU y el rendimiento deben probarse. No conviene añadir virtualización solo por moda si complica controladores y soporte.

Actualizaciones controladas

El sistema debe permitir probar una nueva versión y volver atrás. La configuración de producción no debería depender de comandos recordados por una sola persona.

7. Datos privados, documentos y preparación de información

La calidad de una IA privada depende tanto de los datos como del modelo.

Clasificar información

Antes de conectar repositorios conviene distinguir:

• información pública;
• información interna;
• datos personales;
• información contractual;
• datos financieros;
• secretos, credenciales y claves;
• propiedad intelectual;
• contenido que no debe procesarse mediante IA.

Minimizar

El modelo debe recibir únicamente la información necesaria para la tarea. Procesar una carpeta completa cuando bastan dos fragmentos aumenta exposición y ruido.

Normalizar documentos

Los archivos pueden contener duplicados, versiones antiguas, texto escaneado, tablas mal extraídas y metadatos incompletos. La preparación debe identificar:

• documento oficial;
• fecha y versión;
• autor o responsable;
• permisos;
• periodo de validez;
• relación con otros documentos.

Conservar el origen

Una respuesta debería poder relacionarse con la fuente utilizada. Esto permite verificar, corregir y actualizar.

No introducir secretos innecesarios

Las credenciales no deben incluirse en repositorios documentales ni en instrucciones. El sistema de IA no necesita conocer contraseñas para explicar un procedimiento.

Retención

Debe definirse si se guardan instrucciones, respuestas, archivos temporales y evaluaciones. La retención automática e indefinida puede contradecir el objetivo de privacidad.

La preparación se relaciona con cómo controlar los datos empresariales sin complicar la operativa.

8. RAG y búsqueda sobre información empresarial

RAG permite que el modelo responda utilizando fragmentos recuperados de una colección de documentos.

Componentes principales

1. Ingesta de documentos.
2. Extracción y limpieza de texto.
3. Segmentación en fragmentos.
4. Creación de embeddings.
5. Almacenamiento del índice.
6. Búsqueda de fragmentos relevantes.
7. Construcción del contexto.
8. Generación de la respuesta.
9. Presentación de fuentes.

Permisos

El índice no debe permitir que un usuario recupere documentos a los que no tendría acceso fuera de la IA. Los permisos deben aplicarse antes de entregar fragmentos al modelo.

Segmentación

Fragmentos demasiado pequeños pierden contexto. Fragmentos demasiado grandes introducen ruido y consumen memoria. La estrategia debe probarse con documentos reales.

Actualización

Cuando cambia un documento, el índice debe actualizarse. De lo contrario, la IA seguirá utilizando información obsoleta.

Fuentes y citas

Mostrar el documento y la sección utilizada mejora la verificación. Una respuesta sin fuente puede sonar convincente y ser incorrecta.

Evaluación

Debe comprobarse si el sistema recupera el documento correcto antes de culpar al modelo por una respuesta deficiente. Muchos errores de RAG son errores de búsqueda, permisos o preparación documental.

RAG no sustituye a una buena gestión documental

Una colección desordenada seguirá produciendo respuestas contradictorias. Antes de indexar conviene definir la fuente oficial y retirar versiones inválidas.

9. Seguridad, identidades y protección de secretos

Cuentas individuales

Cada usuario debe identificarse. Una interfaz compartida sin autenticación impide aplicar permisos y atribuir acciones.

Roles

Pueden distinguirse:

• usuarios;
• responsables de documentos;
• evaluadores;
• administradores de modelos;
• administradores de infraestructura;
• aplicaciones o cuentas técnicas.

Protección del servidor

El equipo debe aplicar actualizaciones, cifrado, firewall, acceso administrativo restringido y protección física proporcionada.

Modelos y archivos descargados

Conviene utilizar fuentes conocidas, verificar archivos y evitar ejecutar código asociado sin revisión. Un modelo puede acompañarse de scripts o configuraciones que no deben tratarse como contenido pasivo.

Inyección de instrucciones

Un documento o entrada puede incluir instrucciones destinadas a alterar el comportamiento del sistema. Las aplicaciones deben separar instrucciones de datos y limitar las acciones que el modelo puede ejecutar.

Herramientas y agentes

Cuando el modelo puede enviar correos, modificar archivos, consultar bases o ejecutar comandos, el riesgo aumenta. Deben aplicarse:

• permisos mínimos;
• listas de acciones permitidas;
• aprobación humana;
• límites de volumen;
• registros;
• entornos de prueba;
• mecanismos de parada.

Secretos

Claves de API, contraseñas y certificados deben almacenarse fuera de instrucciones, modelos y repositorios de documentos.

Privacidad de registros

Los logs pueden contener exactamente la información que se pretendía proteger. Deben minimizarse, cifrarse y conservarse durante un periodo definido.

La seguridad debe integrarse en el diseño, aplicando los principios de seguridad empresarial práctica.

10. Monitorización, registros y evaluación

Una plataforma de IA puede estar disponible y ofrecer respuestas deficientes. La observabilidad debe cubrir infraestructura y calidad.

Métricas de infraestructura

• uso de CPU y GPU;
• RAM y VRAM;
• temperatura;
• espacio disponible;
• latencia;
• tokens procesados;
• solicitudes simultáneas;
• errores;
• tiempo de carga del modelo;
• consumo eléctrico cuando resulte relevante.

Métricas de servicio

• tiempo hasta la primera respuesta;
• velocidad de generación;
• porcentaje de solicitudes completadas;
• colas;
• tiempos de espera;
• disponibilidad;
• número de usuarios activos.

Métricas de calidad

• respuestas correctas;
• fuentes recuperadas;
• alucinaciones detectadas;
• formato válido;
• rechazos apropiados;
• casos que necesitan corrección humana;
• comparación entre versiones.

Conjunto de evaluación

La empresa debería mantener preguntas y tareas representativas con resultados esperados. Cada cambio de modelo, configuración o índice se prueba contra ese conjunto.

Registro proporcional

No es necesario guardar el contenido completo de todas las conversaciones. Puede registrarse identificador, modelo, latencia, estado y evaluación, reservando el contenido para casos justificados.

Alertas

Las alertas deben señalar saturación, temperatura, falta de espacio, caída del servicio, error de carga, copia fallida o degradación significativa.

11. Copias, recuperación y continuidad

La plataforma debe poder reconstruirse aunque falle el equipo principal.

Qué debe copiarse

• documentos fuente;
• configuración;
• índices o procedimiento para regenerarlos;
• metadatos;
• adaptadores propios;
• conjuntos de evaluación;
• inventario de modelos;
• scripts y contenedores;
• documentación;
• registros necesarios.

Los modelos descargables pueden no necesitar la misma prioridad que los datos propios, pero conviene registrar origen y versión para recuperarlos.

Restauración

Debe existir una secuencia:

1. recuperar sistema y controladores;
2. instalar runtime;
3. restaurar configuración;
4. recuperar modelos;
5. restaurar documentos e índices;
6. aplicar secretos;
7. ejecutar pruebas;
8. abrir el servicio.

Equipo alternativo

Una microempresa puede mantener un modo degradado en CPU, un modelo más pequeño o un servicio externo temporal. No necesita duplicar todo el hardware, pero sí saber cómo continuará.

Copias aisladas

Los datos y configuraciones deben disponer de copias separadas del servidor. La estrategia puede seguir los criterios de copias 3-2-1.

Pruebas

La restauración debe probarse. Un repositorio sin instrucciones, controladores o versiones puede ser insuficiente.

12. Gobierno, riesgos y responsabilidad humana

La infraestructura privada reduce algunas dependencias, pero no elimina los riesgos de la IA.

Definir usos permitidos

La empresa debe indicar qué tareas pueden realizarse y qué información no debe introducirse.

Responsable del sistema

Debe existir una persona responsable de:

• aprobar modelos;
• revisar cambios;
• gestionar datos;
• supervisar accesos;
• evaluar resultados;
• coordinar incidencias;
• retirar versiones.

Revisión humana

Los resultados que afecten a clientes, alumnos, pagos, contratos, seguridad o decisiones relevantes deben contar con controles humanos proporcionados.

Limitaciones conocidas

El sistema debe documentar qué no hace bien: idiomas, cálculos, documentos concretos, contexto largo, tablas, imágenes o preguntas sin fuente.

Registro de decisiones

Conviene conservar por qué se eligió un modelo, qué pruebas superó y qué riesgos se aceptaron.

Dependencia tecnológica

Un modelo local puede depender de un runtime, una GPU, un formato y una comunidad. La soberanía no consiste en negar esas dependencias, sino en mantenerlas visibles y sustituibles.

Este criterio conecta con qué significa realmente tener soberanía tecnológica.

Modelos de arquitectura para distintos tamaños

Profesional individual

• ordenador con memoria suficiente;
• modelo pequeño o medio cuantizado;
• interfaz local;
• documentos seleccionados;
• disco cifrado;
• copias;
• sin acceso público;
• registro mínimo.

Es apropiado para consulta documental, redacción, programación o clasificación personal.

Microempresa

• estación de trabajo o servidor dedicado;
• servidor de inferencia accesible por red;
• cuentas individuales;
• RAG con permisos;
• almacenamiento empresarial;
• monitorización;
• copias externas;
• modelo alternativo;
• documentación y responsable.

PYME con varios equipos

• servidor o clúster dimensionado;
• varios modelos por tarea;
• colas y límites;
• integración con identidad;
• separación de pruebas y producción;
• repositorios documentales por área;
• evaluación continua;
• alta disponibilidad proporcional;
• soporte y ciclo de cambios.

Modelo híbrido

• modelo local para datos sensibles;
• modelo externo para picos o tareas no sensibles;
• política de enrutamiento;
• minimización de datos;
• registro del entorno utilizado;
• procedimiento de continuidad.

La arquitectura correcta es la más sencilla que cubre el caso de uso, el número de usuarios y el nivel de riesgo.

Método práctico para dimensionar la infraestructura

1. Definir la tarea

No se dimensiona “para IA” en abstracto. Debe definirse si se necesita resumir documentos, consultar un repositorio, generar código, clasificar mensajes o atender usuarios.

2. Elegir modelos candidatos

Seleccionar varios tamaños y cuantizaciones. Probar calidad antes de comprar hardware.

3. Medir memoria

Comprobar consumo al cargar, con el contexto máximo esperado y con varias solicitudes.

4. Definir latencia

Una tarea en lote puede esperar minutos. Un asistente interactivo necesita responder con fluidez.

5. Estimar concurrencia

Contar usuarios simultáneos, no usuarios totales.

6. Calcular volumen

Solicitudes diarias, documentos, tokens y horas de uso determinan capacidad y costes.

7. Añadir margen

Reservar capacidad para sistema, picos, actualizaciones y crecimiento.

8. Probar con hardware temporal

Cuando sea posible, utilizar un equipo alquilado o capacidad puntual para validar antes de invertir.

9. Calcular coste total

Incluir compra, energía, mantenimiento, tiempo, copias y renovación.

10. Diseñar salida

Definir cómo migrar modelos, datos, índices y aplicaciones.

Hoja de ruta de implantación

Fase 1. Caso de uso y datos

1. Seleccionar una tarea concreta.
2. Clasificar los datos.
3. Definir qué información no puede salir.
4. Crear un conjunto de pruebas.
5. Establecer un resultado esperado.

Fase 2. Laboratorio

1. Probar varios modelos.
2. Medir calidad, memoria y velocidad.
3. Comparar CPU, GPU y cuantizaciones.
4. Registrar versiones.
5. Descartar configuraciones inadecuadas.

Fase 3. Datos y RAG

1. Seleccionar documentos oficiales.
2. Limpiar y clasificar.
3. Definir permisos.
4. Crear índice.
5. Probar recuperación y fuentes.

Fase 4. Servicio interno

1. Instalar servidor de inferencia.
2. Crear autenticación.
3. Limitar usuarios.
4. Activar registros y métricas.
5. Definir retención.

Fase 5. Seguridad y continuidad

1. Segmentar red.
2. Proteger secretos.
3. Crear copias.
4. Documentar restauración.
5. Probar modelo alternativo.

Fase 6. Piloto

1. Incorporar pocos usuarios.
2. Recoger errores y correcciones.
3. Medir valor real.
4. Ajustar límites.
5. Revisar riesgos.

Fase 7. Producción

1. Formalizar responsabilidades.
2. Establecer actualizaciones.
3. Programar evaluaciones.
4. Controlar costes y capacidad.
5. Ampliar solo cuando el piloto sea estable.

La implantación gradual evita comprar una plataforma sobredimensionada antes de saber si el caso de uso aporta valor.

Aplicaciones en empresas de distintos sectores

La utilidad de una infraestructura de inteligencia artificial privada depende menos del sector que de la naturaleza de los datos, la repetición de las tareas y el nivel de control que necesita la empresa. Los siguientes ejemplos muestran cómo puede adaptarse a tres negocios muy diferentes sin convertir la IA en el centro obligatorio de toda la operación.

Empresa de comercialización por canal tradicional y venta online

Una empresa que vende mediante comerciales, teléfono, correo electrónico y una tienda online suele distribuir la información entre catálogos, tarifas, fichas de producto, condiciones comerciales, históricos de pedidos, documentación de proveedores y consultas de clientes. Una plataforma privada puede ayudar a consultar y relacionar esa información sin enviar indiscriminadamente datos comerciales a servicios externos.

Consulta de catálogo y documentación comercial

Un sistema RAG puede buscar características, compatibilidades, condiciones de suministro, instrucciones y restricciones dentro de fichas técnicas y documentos aprobados. La respuesta debe indicar la fuente y la versión utilizada para evitar que una tarifa antigua o una ficha retirada se presente como vigente.

Apoyo a presupuestos y preparación de ofertas

La IA puede localizar productos adecuados, resumir requisitos recibidos y preparar un borrador de oferta a partir de plantillas. El precio final, los descuentos, los plazos y las condiciones contractuales deben proceder de los sistemas autorizados y quedar sujetos a validación humana.

Coordinación entre venta tradicional y comercio electrónico

La infraestructura puede ayudar a comparar información publicada en la web con catálogos internos, detectar descripciones inconsistentes o localizar productos que requieren actualización. No debería modificar directamente el catálogo, el stock o los precios sin un flujo de aprobación.

Atención posventa

Las consultas pueden clasificarse por producto, entrega, devolución, garantía o incidencia técnica. Para responder, conviene minimizar los datos personales y separar el conocimiento general del expediente concreto del cliente.

Separación de sistemas críticos

La tienda online, el ERP, el CRM y la plataforma de IA no deben compartir credenciales globales ni acceso completo a todas las bases de datos. Las integraciones deben limitarse a los campos y operaciones necesarios, con registros y permisos diferenciados.

En una empresa comercial, la IA privada debe mejorar la consulta y la coherencia de la información sin convertirse en una vía alternativa para alterar precios, pedidos o datos de clientes.

Empresa de transporte nacional

Una empresa de transporte nacional gestiona rutas, vehículos, conductores, clientes, albaranes, incidencias, mantenimiento, normativa, comunicaciones y documentación operativa. La IA privada puede aportar valor cuando ayuda a localizar información y priorizar trabajo, pero no debe asumir decisiones que afecten a la seguridad o al cumplimiento sin reglas y supervisión.

Consulta de procedimientos operativos

Conductores, tráfico y administración pueden consultar protocolos sobre carga, entrega, documentación, comunicación de incidencias, actuación ante averías o gestión de mercancía rechazada. Las respuestas deben basarse en procedimientos vigentes y distinguir claramente entre orientación interna y obligación normativa.

Clasificación de incidencias

Mensajes, partes y correos pueden agruparse por retraso, avería, ausencia del destinatario, daño, error documental o problema de ruta. La IA puede resumir y priorizar, mientras que la decisión operativa debe permanecer en manos del personal responsable.

Tratamiento de albaranes y documentos

El sistema puede extraer referencias, fechas, matrículas, números de expedición y observaciones para facilitar comprobaciones. Los documentos originales deben conservarse y cualquier dato extraído debe poder verificarse antes de incorporarse al sistema de gestión.

Mantenimiento y conocimiento técnico

Una base privada puede relacionar manuales, historial de averías, planes de mantenimiento y procedimientos del taller. No sustituye el diagnóstico profesional, pero puede acelerar la localización de antecedentes y documentación relevante.

Protección de la información de rutas

Las rutas, horarios, matrículas, ubicaciones y datos de clientes pueden ser sensibles. Los permisos deben limitar la información visible según la función, y los registros no deben conservar coordenadas o conversaciones durante más tiempo del necesario.

Continuidad de la operación

La planificación, la comunicación con conductores y la emisión de documentación deben seguir funcionando si el servicio de IA se detiene. La IA puede asistir, pero no debe convertirse en el único medio para despachar vehículos o resolver una incidencia urgente.

En transporte, la IA privada resulta útil cuando reduce tiempo de búsqueda y mejora la gestión documental, sin desplazar los controles de seguridad, tráfico y responsabilidad profesional.

Agencia de viajes

Una agencia de viajes combina información pública cambiante con datos personales, preferencias, presupuestos, reservas, contratos, seguros, proveedores y comunicaciones con clientes. Una infraestructura privada puede ayudar a organizar expedientes y reutilizar conocimiento interno, siempre que no confunda una propuesta generada con una disponibilidad o condición confirmada.

Preparación de propuestas

La IA puede resumir preferencias y construir borradores de itinerario a partir de productos, destinos y criterios previamente seleccionados. Precios, plazas, horarios, requisitos de entrada y condiciones de cancelación deben verificarse en fuentes actualizadas antes de enviarse al cliente.

Consulta de conocimiento interno

Los agentes pueden buscar procedimientos, fichas de proveedores, políticas de reserva, recomendaciones operativas y experiencias documentadas. El repositorio debe diferenciar claramente la información vigente de notas históricas o impresiones subjetivas.

Clasificación de solicitudes

Los mensajes pueden organizarse por presupuesto, cambio, cancelación, documentación, seguro, incidencia en destino o reclamación. Esto facilita priorizar casos sin permitir que el modelo resuelva automáticamente situaciones contractuales delicadas.

Protección de datos del viajero

Pasaportes, documentos de identidad, fechas de nacimiento, datos de contacto, necesidades especiales y detalles de pago requieren controles estrictos. La IA debe recibir únicamente la información imprescindible para cada tarea y evitar que documentos completos se incorporen a índices generales.

Separación entre recomendación y reserva

La infraestructura de IA puede sugerir, resumir o comparar, pero la reserva debe ejecutarse mediante los sistemas autorizados del proveedor o de la agencia. Las acciones que generen cargos, cancelaciones o cambios deben exigir confirmación explícita y quedar registradas.

Gestión de incidencias durante el viaje

Un asistente interno puede localizar teléfonos, condiciones, alternativas y procedimientos aplicables. La información crítica debe confirmarse y siempre debe existir un canal humano para emergencias, cambios complejos o viajeros vulnerables.

En una agencia de viajes, la IA privada debe acelerar la preparación y la consulta sin presentar como confirmados precios, plazas, requisitos o condiciones que todavía no se han verificado.

Costes que deben calcularse

Inversión inicial

• equipo o servidor;
• GPU o acelerador;
• memoria;
• almacenamiento;
• red;
• alimentación y refrigeración;
• implantación;
• pruebas.

Costes recurrentes

• electricidad;
• alojamiento;
• copias;
• soporte;
• monitorización;
• renovación de hardware;
• tiempo de administración;
• licencias cuando procedan.

Costes de datos

• limpieza;
• clasificación;
• digitalización;
• actualización;
• revisión de permisos;
• evaluación.

Coste de oportunidad

Un sistema lento, inestable o difícil de usar puede consumir más tiempo que el que ahorra.

Coste de salida

Debe incluir migración de documentos, índices, configuraciones, integraciones y formación.

Coste total de propiedad (TCO)

El coste real de una infraestructura de IA no termina cuando se compra el hardware. Deben contemplarse la amortización, el consumo eléctrico, el mantenimiento, la sustitución de componentes, el tiempo de administración y la futura renovación tecnológica.

Escenarios económicos habituales

• Estación de trabajo reutilizada para pruebas.
• Equipo dedicado para una microempresa con pocos usuarios.
• Servidor de inferencia para varios departamentos.
• Infraestructura escalable cuando existen decenas de usuarios concurrentes.

Consumo energético y refrigeración

Las GPU de altas prestaciones pueden consumir varios cientos de vatios de forma continuada. Esto afecta al coste eléctrico, al dimensionamiento del SAI, al ruido y a la climatización de la sala donde se instala el equipo.

¿Cuándo compensa?

Una infraestructura propia suele resultar más interesante cuando el volumen de consultas es elevado, los datos son especialmente sensibles o la empresa necesita disponibilidad continua. Para cargas esporádicas puede resultar más económico utilizar servicios externos bajo demanda.

La comparación puede apoyarse en cómo calcular el coste real de una infraestructura tecnológica.

Errores frecuentes

Comprar hardware antes de probar modelos

La empresa puede descubrir que un modelo menor ofrece calidad suficiente o que la carga necesita más memoria de la prevista.

Confundir privado con desconectado

Desactivar Internet no resuelve permisos, registros, copias ni accesos internos.

Intentar entrenar desde cero

La mayoría de pequeñas empresas necesita inferencia o RAG, no entrenamiento fundacional.

Elegir por número de parámetros

El modelo mayor puede ser más lento, caro y difícil de mantener sin mejorar la tarea concreta.

Ignorar la licencia

Un modelo técnicamente adecuado puede no encajar con el uso comercial previsto.

No medir el contexto

La configuración funciona con una pregunta corta y se queda sin memoria con documentos reales.

Publicar el servidor directamente

Una API sin autenticación y límites puede exponer datos y consumir recursos.

Indexar todos los documentos

Versiones antiguas, borradores y contenido irrelevante producen respuestas contradictorias.

No aplicar permisos al RAG

La IA puede revelar documentos que el usuario no debería encontrar.

Guardar todas las conversaciones

Se crea un archivo sensible que contradice el objetivo de privacidad.

No evaluar respuestas

Una demostración convincente no demuestra fiabilidad en producción.

Depender de una sola persona

El sistema queda bloqueado si solo una persona conoce controladores, modelos y copias. Conviene aplicar los criterios de cómo evitar depender de una única persona para gestionar la tecnología.

Sobredimensionar

Varias GPU, clústeres y plataformas complejas pueden aumentar el mantenimiento sin aportar valor a pocos usuarios.

No preparar continuidad

La IA se integra en procesos críticos sin modelo alternativo ni procedimiento manual.

Lista de comprobación

• ¿Existe un caso de uso definido?
• ¿Se ha comprobado que la IA aporta más valor que una solución convencional?
• ¿Está claro qué datos pueden procesarse?
• ¿Se han clasificado datos personales, internos y secretos?
• ¿Se han probado varios modelos?
• ¿La licencia permite el uso previsto?
• ¿Se registran modelo, versión y cuantización?
• ¿El hardware se ha dimensionado con contexto y concurrencia reales?
• ¿Existe margen de RAM y VRAM?
• ¿El almacenamiento tiene capacidad y copias?
• ¿El servidor no está expuesto innecesariamente?
• ¿Cada usuario tiene identidad propia?
• ¿Los permisos del repositorio documental se respetan?
• ¿Los secretos están separados?
• ¿Pruebas y producción están diferenciadas?
• ¿Se monitorizan recursos y calidad?
• ¿Existe un conjunto de evaluación?
• ¿Las respuestas pueden mostrar fuentes?
• ¿Los registros aplican minimización y retención?
• ¿Se ha documentado el sistema?
• ¿Otra persona puede administrarlo?
• ¿Existen copias y restauración probada?
• ¿Hay un modelo o procedimiento alternativo?
• ¿Se conocen costes totales?
• ¿Existe una salida de proveedor, formato o hardware?
• ¿Los resultados sensibles reciben revisión humana?

Las respuestas negativas no significan que deba abandonarse el proyecto. Permiten ordenar las tareas previas y evitar que la privacidad dependa únicamente de dónde se ejecuta el modelo.

Preguntas frecuentes

Conclusión

Una infraestructura preparada para inteligencia artificial privada no se reduce a una GPU ni a un modelo descargado. Es un sistema compuesto por capacidad de cálculo, memoria, almacenamiento, red, software, datos, permisos, evaluación, copias y gobierno.

La primera decisión consiste en definir la carga: inferencia, RAG, ajuste o entrenamiento. Para la mayoría de pequeñas empresas, el valor se encuentra en ejecutar modelos existentes y conectarlos de forma controlada con documentación propia.

La privacidad real aparece cuando la empresa sabe qué información entra, dónde se procesa, qué modelo interviene, quién puede acceder y cómo se recupera o sustituye la plataforma.

El hardware debe elegirse después de probar modelos y medir contexto, concurrencia y latencia. La VRAM es importante, pero también lo son RAM, almacenamiento, compatibilidad, energía, red y capacidad de mantenimiento.

RAG puede convertir documentación interna en una fuente consultable, siempre que los documentos estén ordenados, los permisos se respeten y las respuestas muestren su origen.

La plataforma debe construirse de forma gradual: laboratorio, conjunto de evaluación, piloto limitado, seguridad, continuidad y ampliación. Esta secuencia reduce inversiones equivocadas y evita que la IA se convierta en una caja negra crítica.

Para una microempresa, la solución adecuada suele ser la mínima arquitectura capaz de proteger datos, ofrecer una calidad suficiente y ser mantenida por las personas disponibles.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para avanzar de forma estructurada en inteligencia artificial, infraestructura digital, sistemas, datos, seguridad y automatización.