La topología de despliegue es la primera decisión arquitectónica y la más difícil de revertir. Determina qué datos puede tocar legalmente el sistema, y toda decisión posterior hereda esa restricción.
Habitualmente se trata como un detalle de infraestructura a resolver después del diseño funcional — así es como los equipos descubren en el cuarto mes que el sistema que construyeron no puede procesar los datos para los que fue construido.
Del estándar
“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
Las tres topologías
SaaS alojado por el proveedor
Sus datos se procesan en la infraestructura del proveedor. Es el camino más rápido a producción y la respuesta correcta más a menudo de lo que a las organizaciones cautelosas les gusta admitir — para datos públicos, contenido interno sin exposición regulatoria y cualquier caso donde el costo de una brecha sea vergüenza y no una notificación formal.
Falla en una condición específica: cuando un contrato, un regulador o una cláusula de residencia dice que los datos no salen. Ningún acuerdo de tratamiento cambia a dónde van los paquetes, y ninguna certificación lo sustituye.
Nube propia (BYOC)
El sistema se divide en una frontera dura. Un plano de control orquesta sesiones, evalúa políticas y recolecta trazas — y no retiene datos del cliente. Un plano de ejecución corre dentro de su propia cuenta de nube, bajo su gestión de identidad y accesos, su política de red y sus reglas de salida. Es el único componente que conecta con sus sistemas.
Esta es la topología que resuelve la mayoría de las objeciones empresariales, porque hace que la pregunta de residencia se responda con un diagrama de red y no con una garantía legal. Cuesta más operativamente: usted opera infraestructura, la parchea y es dueño de los modos de falla dentro de su perímetro.
Totalmente on-premises
Ambos planos corren en su entorno. Apropiado para redes aisladas, trabajo clasificado y entornos de tecnología operativa donde la conectividad saliente está directamente prohibida y no solo restringida.
Dos dependencias suelen forzar el acceso saliente y deben resolverse explícitamente: la inferencia del modelo, que debe enrutarse por un gateway que usted ya opera, y los embeddings de recuperación, que deben correr residentes y localmente en lugar de llamar a un servicio alojado. Resuelva ambas y el resto de la pila no tiene razón para salir a internet.
La pregunta que lo decide
No "qué tan sensibles son estos datos" — todos responden "mucho". Pregunte en cambio: ¿existe un compromiso escrito, ante un regulador o un cliente, que restrinja dónde pueden procesarse estos datos? Si la respuesta es sí, la topología ya está elegida y la discusión terminó. Si es no, está optimizando costo operativo, y lo alojado suele ser lo correcto.
Qué significa realmente el aislamiento dentro del plano de ejecución
Elegir BYOC define dónde corre el código. No define con qué seguridad corre allí, y esa distinción importa porque un agente que escribe y ejecuta código es una vía de ejecución remota que usted construyó a propósito.
El aislamiento a nivel de contenedor es insuficiente para esa carga. Los contenedores comparten kernel, y los escapes de kernel son una categoría conocida, no una hipótesis. El código generado por el agente pertenece a un sandbox aislado por hardware — una MicroVM con su propio kernel — para que un escape exitoso deje al atacante en una máquina virtual vacía.
El aislamiento por sí solo aún deja una vía de exfiltración. Combínelo con salida denegada por defecto: un filtro de red y un sumidero DNS que restrinjan el tráfico saliente a una lista que usted define. Un agente totalmente comprometido no tiene entonces a dónde enviar nada, porque la exfiltración requiere un destino y no lo hay.
La pregunta que hay que hacerle a un proveedor
Pregunte si la versión on-premises es el mismo código que la alojada. Muchos proveedores mantienen dos, y la rama auto-alojada inevitablemente se rezaga — usted recibe el sistema del año pasado al precio de este año, y cada conversación de soporte empieza por establecer qué versión está ejecutando.
Luego pregunte qué cambia entre topologías. En un sistema bien construido la respuesta es la configuración de despliegue y nada más: los mismos contenedores, el mismo motor de políticas, la misma tubería de auditoría, con el plano de control reubicado. Si la respuesta implica una matriz de funciones distinta, la opción restrictiva es un producto de segunda y debería cotizarse como tal.
Decida esto en la semana uno
La topología no puede cambiarse tarde sin reescribir el sistema, porque todo lo posterior — dónde viven los secretos, cómo se federa la identidad, qué puede ver la tubería de auditoría — se deriva de ella. Corresponde a la primera sesión de arquitectura junto al proveedor de identidad y la política de salida, no a un sprint de endurecimiento al final.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.