Una empresa que desea utilizar un modelo generativo debe decidir por dónde circulan los datos, quién opera el modelo, qué registros se conservan y cómo cambiar de proveedor. La palabra «soberano» abarca varias expectativas: residencia, control jurídico, dominio técnico, independencia económica, software abierto o capacidad de funcionar sin un actor determinado.
Ninguna arquitectura maximiza simultáneamente calidad, simplicidad, elasticidad, costo y control. Una decisión sólida comienza por clasificar los usos y los datos, luego compara los escenarios con los mismos criterios.
Definir la soberanía buscada
Una organización puede buscar:
- la confidencialidad, para evitar un uso o almacenamiento no autorizado;
- la localización, para operar en una región o país dado;
- el control operativo, para gestionar accesos, registros y versiones ;
- la portabilidad, para cambiar de modelo o de proveedor de alojamiento ;
- la autonomía, para continuar funcionando sin dependencia externa ;
- la transparencia, gracias a pesos o componentes abiertos;
- el dominio económico, para evitar un coste variable incontrolado.
Estas dimensiones deben ser ponderadas. Una API puede ofrecer garantías contractuales excelentes sin dar el control del modelo. Un servidor local puede dar el control de la infraestructura mientras depende de una GPU, de un software o de una licencia extranjera.
Clasificar los datos y las acciones
El mismo proyecto puede manejar contenidos públicos, notas internas, datos personales y secretos. Tratarlos en un único entorno impone el nivel de control más alto a todos los usos, a menudo a un costo innecesario.
Una clasificación práctica distingue:
- pública ;
- interno;
- confidencial;
- regulado o limitado contractualmente;
- crítica secreta.
También especifica los datos derivados: indicaciones, incrustaciones, registros, cachés, evaluaciones y salidas. Una respuesta generada a partir de un dato sensible puede ser ella misma sensible.
Los cinco escenarios de arquitectura
1. API pública
El proveedor opera el modelo y la infraestructura. La integración es rápida, las capacidades son elásticas y los modelos más recientes son accesibles. Es necesario verificar retención, entrenamiento, subcontratistas, región, seguridad y condiciones de salida.
Esta opción es adecuada para los datos compatibles con las garantías obtenidas y para los usos donde la calidad o la velocidad de innovación priman.
2. API con entorno o región dedicada
Algunos servicios ofrecen un procesamiento regional, una capacidad dedicada o controles reforzados. Esto puede satisfacer requisitos de rendimiento y gobernanza, pero sigue siendo un servicio operado por un tercero. Los términos precisos del contrato prevalecen.
3. Nube privada gestionada
El modelo se despliega en un entorno aislado o en un servicio controlado, con una parte de la operación asegurada por un proveedor. El compromiso reduce la carga interna al tiempo que mejora el control. Deben evaluarse la portabilidad y el acceso del operador.
4. Infraestructura privada alojada
La organización o su administrador de TI opera los modelos en una infraestructura dedicada. Controla más la red, las versiones, los registros y el cifrado. Debe dimensionar las GPU, las actualizaciones, la resiliencia y la seguridad.
5. Local
El cálculo se realiza en las instalaciones o en un entorno totalmente controlado. Esta solución puede responder a fuertes restricciones de conectividad o de datos. Requiere una inversión, competencias y un plan de renovación. La calidad disponible depende de la capacidad del hardware y de los modelos desplegables.
Un enrutamiento híbrido dirige las solicitudes de IA a diferentes entornos según la sensibilidad de los datos.
Una arquitectura híbrida es a menudo la respuesta
Los usos públicos o poco sensibles pueden utilizar una API eficiente. Los contenidos confidenciales pueden ser enrutados hacia un modelo privado. Los secretos críticos pueden permanecer excluidos de cualquier procesamiento generativo o ser manejados por una capacidad local muy controlada.
El enrutamiento se basa en:
- clasificación de datos ;
- identidad y rol ;
- tarea;
- modelo autorizado;
- coste y latencia;
- nivel de registro;
- mecanismo de repliegue.
La política debe aplicarse del lado del servidor. El usuario no elige libremente un proveedor para eludir las reglas.
Comparar la calidad útil, no el prestigio del modelo
Un modelo más grande no siempre es mejor para una tarea. Hay que probar con los idiomas, formatos e instrucciones reales: extracción, clasificación, resumen, código, RAG o conversación.
El juego de evaluación mide exactitud, respeto del formato, rechazo, latencia y costo. Una arquitectura privada puede utilizar un modelo especializado más pequeño si la tarea está limitada. Una API externa puede seguir siendo necesaria para casos complejos.
Dimensionar la infraestructura privada
La inferencia depende del tamaño del modelo, de la cuantificación, del contexto, del número de consultas simultáneas y de la latencia. El rendimiento medio no es suficiente: hay que incluir los picos, las colas, los tiempos de carga y el mantenimiento.
El dimensionamiento prevé:
- GPU y memoria;
- redundancia ;
- almacenamiento de los pesos;
- red ;
- planificador;
- esconder;
- supervisión ;
- actualizaciones;
- capacidad de recuperación.
Una cola y prioridades pueden absorber ciertas tareas asincrónicas. Las interacciones en tiempo real exigen una capacidad reservada.
Costo completo
Una API generalmente factura el uso, al que se suman la integración, la observabilidad y la gobernanza. Una infraestructura privada transforma parte del costo en inversión o capacidad reservada, pero agrega operación, energía, soporte, amortización y subutilización.
El costo debe calcularse por tarea realizada y por nivel de servicio. Un modelo local barato pero que a menudo requiere correcciones manuales puede ser más costoso que una API de mejor calidad.
Licencias y modelos abiertos
Pesos disponibles no significan ausencia de condiciones. Hay que verificar la licencia del modelo, las restricciones de uso, los componentes, los datos de ajuste fino y la posibilidad de redistribución.
La apertura facilita la auditoría, la portabilidad y la personalización, pero la organización sigue siendo responsable de la seguridad, las actualizaciones y el comportamiento del sistema.
Controles contractuales para una API
La debida diligencia debe cubrir:
- uso de entradas y salidas para el entrenamiento;
- duración de conservación ;
- localización del tratamiento ;
- subcontratistas;
- cifrado ;
- acceso al soporte ;
- notificación de incidente ;
- disponibilidad;
- cambio de modelo;
- exportación y eliminación ;
- auditoría y pruebas.
Las promesas de marketing no reemplazan las condiciones aplicables al servicio y a la cuenta utilizada.
Seguridad de una infraestructura privada
El autoalojamiento no hace que el sistema sea seguro. Es necesario gestionar identidades, secretos, red, imágenes, dependencias, modelos, datos temporales y registros. Las interfaces de administración están aisladas y el acceso a las GPU controlado.
Los modelos y artefactos se verifican antes del despliegue. La cadena de suministro, las descargas y las actualizaciones siguen un proceso aprobado.
Portabilidad
Una capa de abstracción puede normalizar la llamada, los errores, la observabilidad y las políticas entre proveedores. No debe ocultar las diferencias de capacidad hasta el punto de reducir todos los modelos al denominador común más pequeño.
Indicaciones, evaluaciones y salidas estructuradas están versionadas. Los datos se almacenan en formatos exportables. Se prueba un escenario de cambio antes de que se vuelva urgente.
Explotación y habilidades
Una plataforma privada necesita MLOps, seguridad, infraestructura y soporte. Los modelos deben ser actualizados, evaluados, desplegados progresivamente y supervisados. Los incidentes pueden estar relacionados con la calidad, la deriva, la saturación o la fuga de datos.
La organización debe decidir lo que opera ella misma y lo que confía a un socio. La soberanía puede incluir la capacidad de cambiar de operador, no necesariamente de internalizar todo.
Una decisión por caso de uso
La buena elección combina datos, riesgo, calidad, volumen y capacidad. Una cartera de usos puede utilizar varios entornos con una política común. Este enfoque evita sobredimensionar las tareas simples o exponer las más sensibles.
Partitech diseña arquitecturas de IA abiertas e híbridas, integra API y despliega modelos privados. El acompañamiento puede cubrir clasificación, evaluación, dimensionamiento, seguridad, enrutamiento y reversibilidad para construir una soberanía verificable en lugar de un simple argumento comercial.
Hablemos de su proyecto
Comparar con Partitech las arquitecturas de alojamiento de su proyecto de IA. Contacte a Partitech.