Infraestructura multi-cliente para agencias de IA: qué estandarizar y qué aislar

Una agencia de IA rara vez tiene un único producto y un único entorno. Entrega agentes, sistemas RAG, automatizaciones, APIs y workers para clientes diferentes. Cada proyecto puede necesitar su propia cuenta cloud, secretos, base de datos, almacenamiento, modelo y política de acceso.

El problema aparece cuando aislar clientes significa inventar una operación distinta para cada uno.

El primer proyecto se puede operar manualmente. Con cinco o diez proyectos activos, los despliegues, accesos y alertas empiezan a competir con el desarrollo funcional.

El patrón que deja de escalar

La secuencia suele ser reconocible:

1. Se crea un VPS o una cuenta cloud para el cliente.
2. Una persona configura variables, redes y permisos.
3. El despliegue se documenta parcialmente o queda en su memoria.
4. Las alertas llegan a canales diferentes.
5. Una incidencia vuelve a la persona que montó el entorno.

No es necesariamente mala ingeniería. Es una forma rápida de iniciar un proyecto. El riesgo está en repetir esa excepción hasta convertirla en el modelo operativo de la agencia.

Qué debe permanecer aislado

Una base común no significa compartirlo todo. Hay elementos que deben tener límites explícitos por cliente:

• secretos y credenciales;
• datos y almacenamiento;
• recursos y límites de consumo;
• redes y políticas de acceso;
• logs con información sensible;
• costes y etiquetado;
• backups y recuperación;
• trazabilidad de cambios.

El nivel de aislamiento depende del contrato, la sensibilidad de los datos y los requisitos regulatorios. Un proyecto experimental no necesita la misma arquitectura que una solución que procesa documentación confidencial.

Qué conviene estandarizar

La agencia gana capacidad cuando reutiliza el proceso sin mezclar los contextos:

• una plantilla de repositorio;
• una forma común de definir infraestructura;
• pipelines con las mismas fases;
• convenciones para staging y producción;
• gestión centralizada de secretos;
• observabilidad mínima obligatoria;
• runbooks para incidencias frecuentes;
• checklist de onboarding y offboarding;
• etiquetas para atribuir costes.

La estandarización útil crea un camino conocido. No obliga a que todos los proyectos usen el mismo proveedor ni introduce Kubernetes por defecto.

Arquitectura de referencia: plano común, límites por cliente

Una arquitectura inicial puede separar el plano de operación de los recursos de cada cliente:

                    PLANO DE OPERACIÓN DE LA AGENCIA
        repositorios · plantillas · CI/CD · inventario · alertas
                                  │
                 ┌────────────────┼────────────────┐
                 │                │                │
          CLIENTE A        CLIENTE B        CLIENTE C
        cuenta/proyecto   cuenta/proyecto   cuenta/proyecto
        app · datos       app · datos       app · datos
        secretos · logs   secretos · logs   secretos · logs

El plano común conoce cómo desplegar y verificar. No necesita concentrar todos los datos ni conceder acceso transversal permanente. Cada frontera debe poder revocarse sin afectar a los demás clientes.

Namespace, clúster o cuenta: elegir la frontera

No hay una única respuesta. La frontera depende del daño que produciría un fallo de aislamiento:

Frontera	Cuándo puede encajar	Principal riesgo
Namespace	Cargas homogéneas, mismo propietario y requisitos moderados	Configuración incorrecta comparte clúster y plano de control
Clúster separado	Equipos, ciclos o criticidad diferentes	Más coste y mantenimiento
Cuenta o proyecto cloud	Clientes jurídicamente separados, facturación o acceso independiente	Mayor complejidad de gobierno y despliegue
Proveedor separado	Requisito contractual, regional o técnico	Variación operativa y menor reutilización

La decisión debe registrar datos tratados, identidad, red, facturación, recuperación y quién administra el plano de control. Kubernetes ofrece mecanismos de aislamiento, pero su documentación sobre multi-tenancy distingue precisamente entre compartir clústeres y usar clústeres dedicados según el nivel de confianza.

Una definición mínima por cliente

La incorporación no debería depender de copiar una carpeta y recordar qué valores cambiar. Incluso una definición pequeña puede hacer explícitas las diferencias:

client: acme
owner: delivery-acme
environment:
  region: eu-west
  isolation: cloud-account
  data_classification: confidential
delivery:
  repository: acme-platform
  production_approval: client-and-agency
operations:
  alerts: acme-operations
  recovery_target: documented-in-contract
  cost_tags: [client, environment, service]

Este archivo no contiene secretos ni sustituye Terraform. Funciona como contrato legible entre onboarding, automatización y operación. El pipeline puede validar campos obligatorios antes de crear recursos.

Guardrails antes que una plataforma enorme

Los primeros controles deberían impedir errores caros:

• no desplegar sin etiqueta de cliente y entorno;
• no permitir secretos en variables o repositorios sin cifrado adecuado;
• bloquear recursos públicos salvo excepción aprobada;
• requerir propietario y canal de alerta;
• comprobar que existe política de backup antes de producción;
• registrar quién aprobó el cambio y qué versión se desplegó;
• ejecutar una comprobación posterior al despliegue y conservar el resultado.

Estos guardrails pueden comenzar como validaciones de CI/CD. No es necesario construir un portal interno para obtener valor.

Pruebas que revelan si el modelo es realmente operable

Una revisión trimestral puede seleccionar un cliente y comprobar:

1. Acceso: retirar temporalmente a la persona que creó el entorno y desplegar con el procedimiento documentado.
2. Aislamiento: verificar que identidades, red y consultas no cruzan la frontera del cliente.
3. Recuperación: restaurar un componente o conjunto de datos en un entorno aislado.
4. Coste: explicar la factura del periodo usando etiquetas y recursos reales.
5. Salida: generar el inventario de recursos, accesos y datos necesarios para transferir el servicio.

Un checklist marcado sin ejecutar estas pruebas solo confirma intención. La evidencia debe incluir logs del pipeline, resultado de recuperación, cambios de permisos y excepciones aceptadas.

Un runtime operativo, no otro producto interno

Es tentador construir una plataforma completa. Para una agencia de 10 a 60 personas, normalmente conviene empezar con menos:

1. Identificar los tres trabajos operativos más repetidos.
2. Crear una plantilla para el tipo de proyecto más frecuente.
3. Automatizar el despliegue y la creación de entornos.
4. Definir quién responde de aplicación, datos e infraestructura.
5. Medir tiempo de onboarding, intervención manual e incidencias.

Si una capacidad no reduce una espera, un riesgo o un trabajo repetido, probablemente todavía no hace falta.

Cómo saber si está funcionando

La mejora debe observarse en el trabajo diario:

• un desarrollador puede crear un entorno sin esperar a una persona concreta;
• un nuevo proyecto sigue un checklist verificable;
• los despliegues tienen rollback y trazabilidad;
• una alerta llega al responsable correcto;
• el coste se puede relacionar con un cliente;
• la ausencia de una persona no bloquea producción.

La agencia no necesita convertirse en una empresa de infraestructura. Necesita una base operativa suficientemente consistente para incorporar clientes sin multiplicar su carga interna.

Una prueba sencilla: elige el último cliente incorporado y enumera cada paso manual, cada permiso concedido y cada decisión que solo conoce una persona. Ahí está el primer mapa de lo que conviene estandarizar.