En el panorama actual de la transformación digital, las empresas están descubriendo que la inteligencia artificial deja de ser un experimento aislado para convertirse en un pilar operativo. Sin embargo, contar con una plataforma como VMware Cloud Foundation 9.1 no garantiza por sí sola que la IA opere de forma segura, repetible y gobernada. La diferencia entre tener una capacidad técnica y poseer un modelo operativo real es el factor que separa a las organizaciones que escalan la IA de aquellas que se quedan estancadas en pruebas piloto. Este artículo propone una visión práctica para diseñar ese modelo operativo, integrando conceptos de infraestructura, gobernanza y automatización, todo ello enmarcado en la experiencia de Q2BSTUDIO como empresa de desarrollo de software y tecnología.
Para empezar, es esencial entender que la IA privada no es simplemente un cluster de GPUs con algunos endpoints de modelos. Un entorno productivo de IA requiere límites de consumo claros, aislamiento de red, propiedad definida sobre los planos de Kubernetes, controles de ejecución de modelos, patrones de servicios de datos, observabilidad, gestión de costes y automatización. VCF 9.1 incorpora capacidades como Private AI Services, despliegues basados en Supervisor, opciones de red VPC, métricas específicas de IA, visibilidad operativa en tiempo real, APIs programables e integración con servicios de datos. Pero la pregunta clave para los equipos de plataforma no es '¿VCF soporta IA?' sino '¿Cómo diseñamos VCF para que la IA se consume de forma segura, repetible y sostenible?'. Esa es la conversación del modelo operativo.
El modelo operativo comienza con los límites. La IA expande el radio de impacto de un diseño deficiente. Una aplicación tradicional puede necesitar acceso de red a una base de datos, unas pocas APIs y una plataforma de logs. En cambio, una aplicación de IA generativa o un sistema de agentes puede requerir acceso a un runtime de modelo, una base de datos vectorial, repositorios internos de documentos, un servicio de embeddings, una puerta de enlace de prompts, servicios de identidad, herramientas internas o externas, sistemas de flujo de trabajo y APIs de negocio. Esto crea una superficie de seguridad y gobernanza mucho mayor. Por tanto, la plataforma debe definir límites antes de que los equipos comiencen a desplegar servicios de IA. El concepto de 'zona de aterrizaje' gobernada es fundamental: una plantilla repetible para la ubicación de namespaces, segmentación VPC, acceso a datos, despliegue de modelos, monitorización y propiedad del soporte. Sin ese patrón, cada proyecto de IA se convierte en una construcción personalizada, y las construcciones personalizadas no escalan bien.
El diseño del Supervisor se convierte en una decisión de plataforma. VCF Private AI Services se apoya en vSphere Supervisor como núcleo. Broadcom describe el Supervisor como el plano de control de Kubernetes y la capa de gestión de recursos necesaria para instalar y ejecutar Private AI Services. Además, las organizaciones deben elegir una pila de red del Supervisor al habilitar cargas de trabajo de IA. Esto hace que el diseño del Supervisor sea una decisión estratégica, no solo un paso técnico. Las preguntas que deben responderse incluyen: ¿Qué clusters alojarán cargas de trabajo de IA? (determina ubicación de GPU, capacidad y aislamiento), ¿Qué tamaño de Supervisor es adecuado? (afecta la capacidad del plano de control y las opciones de escalado futuro), ¿Qué pila de red se usará? (determina autoservicio, segmentación y flexibilidad futura), ¿Qué equipos son propietarios de las operaciones de Kubernetes? (aclara límites de soporte entre VMware e ingeniería de plataforma), y ¿Qué namespaces corresponden a qué proyectos? (controla tenencia, cuotas y límites de acceso). El Supervisor actúa como puente entre la infraestructura VMware tradicional y el consumo de IA nativo de Kubernetes, y ese puente debe diseñarse deliberadamente.
La red VPC debe tratarse como una capa de gobernanza. La conectividad en IA no es solo conectividad, es gobernanza. Las opciones de red del Supervisor en VCF 9.1 incluyen VCF Networking con VPC y redes Supervisadas por VDS con balanceador de carga externo. El modelo VPC se posiciona como la topología más rica para redes de autoservicio y seguridad, mientras que el modelo VDS puede ser más simple para entornos de prueba o proof of concept. La elección importa porque las plataformas de IA suelen pasar de la experimentación al consumo multiinquilino más rápido de lo esperado. Un proof of concept puede necesitar solo un pequeño endpoint de modelo, pero una plataforma productiva puede requerir múltiples VPCs de proyecto, servicios compartidos, zonas de datos restringidas, políticas de red, NAT, balanceo de carga y límites de enrutamiento claros. VCF 9.1 introduce también un control más fuerte de las VPC mediante Connectivity Policy, que permite definir cómo se comunican las VPCs sin depender únicamente de reglas de firewall. Esto se alinea bien con la IA privada: el objetivo no es firewallear manualmente cada flujo, sino crear patrones de red repetibles donde la comunicación sea intencional. Los proyectos de IA no deberían ver automáticamente todas las fuentes de datos, herramientas o proyectos adyacentes.
El VPC Network Span ayuda a alinear las cargas de trabajo con los límites físicos. Las cargas de trabajo de IA no se distribuyen uniformemente: algunas necesitan clusters GPU, otras zonas reguladas, otras rutas de alta velocidad este-oeste, y otras deben mantenerse alejadas de clusters generales compartidos. VCF 9.1 permite definir qué clusters de vCenter pueden ver y alojar las subredes asociadas a una VPC específica. Esto permite que los límites de red virtual se correspondan más precisamente con los límites físicos de los clusters. Para la IA, esto tiene valor práctico: redes de modelo-serving solo en clusters GPU, redes RAG restringidas solo en zonas reguladas, aplicaciones de IA orientadas al exterior solo en clusters alineados con DMZ, servicios compartidos accesibles desde múltiples proyectos, y cargas de trabajo de desarrollo separadas de las de producción. Esto evita que la plataforma extienda cada red a todas partes, lo que mejora la seguridad, la claridad operativa y la simplicidad física de la red.
El runtime del modelo es solo una parte del stack. Un endpoint de modelo no es una plataforma de IA completa. Las dependencias circundantes importan igualmente: artefactos de modelo aprobados, configuración de ejecución, asignación de GPU, puerta de enlace de prompts o inferencia, indexación RAG, base de datos vectorial, ingesta de documentos, integración de identidad, políticas de red, logs y métricas, respaldo y recuperación, y gestión del ciclo de vida. Broadcom enumera capacidades como Model Gallery, Model Runtime, Agent Builder, Data Indexing for RAG, API Gateway y MCP Tools Registry. Esto es importante porque la IA empresarial necesita más que alojamiento de modelos; también debe controlar cómo los modelos se conectan a datos y herramientas. Esto es especialmente crítico para cargas de trabajo de agentes. Un agente que puede llamar herramientas o consultar sistemas internos necesita una gobernanza más fuerte que un prototipo de chatbot simple. La plataforma debe definir qué herramientas están aprobadas, qué equipos pueden usarlas, cómo se registran las llamadas y cómo se revoca el acceso.
Los servicios de datos deben diseñarse dentro de la plataforma desde el inicio. Los flujos de trabajo RAG y de IA empresarial suelen depender de una capa de servicios de datos que incluye PostgreSQL, pgvector, almacenamiento de objetos, repositorios de documentos, flujos de ingesta y políticas de respaldo. Data Services Manager 9.1 ofrece soporte para PostgreSQL con pgvector para cargas de trabajo de IA como RAG, búsqueda semántica y embeddings dentro de un entorno VCF. Esto es relevante porque muchos proyectos de IA fracasan entre el prototipo y la producción. El modelo puede funcionar, la demo puede ser impresionante y el negocio puede estar interesado, pero luego el equipo descubre que la producción requiere gestión del ciclo de vida de la base de datos, respaldo y restauración, cifrado, parcheado, visibilidad de rendimiento, control de acceso, políticas de retención, flujos de actualización de datos, procedimientos de recuperación y claridad de propiedad. Un modelo operativo de IA en VCF debe incluir los servicios de datos desde el principio, no añadirlos después del primer incidente en producción.
La observabilidad debe incluir señales de modelo e infraestructura. La monitorización tradicional de infraestructura no es suficiente para la IA. Una VM puede estar sana, un host puede estar sano, un cluster puede estar sano, pero el servicio de IA puede estar fallando para los usuarios. El problema puede ser latencia de tokens, memoria GPU agotada, rendimiento de recuperación deficiente, endpoints de modelo sobrecargados, generación de embeddings lenta o un conector de datos roto. VCF 9.1 empieza a abordar esto con métricas específicas de IA como utilización de caché, tokens generados por solicitud, rendimiento de tokens, tiempo hasta el primer token y latencia de extremo a extremo. VCF Operations 9.1 añade visibilidad operativa más profunda, incluyendo observabilidad en tiempo real con recolección configurable en intervalos cortos para hosts ESX, gestión centralizada de logs, diagnósticos, integración con Prometheus y APIs que pueden soportar pipelines RAG y frameworks MCP. Un dashboard práctico de IA debe conectar múltiples capas: experiencia de usuario (latencia, errores, tiempo hasta el primer token), runtime del modelo (rendimiento de tokens, volumen de solicitudes, utilización de caché), capa de GPU (utilización de GPU, presión de memoria, ubicación), capa de Kubernetes (salud de pods, cuota de namespace, estado del servicio), capa de infraestructura (métricas ESXi, latencia de vSAN, flujos de red, salud del host) y capa de costes (asignación de GPU, consumo por proyecto, showback o chargeback). Sin esta vista completa, los equipos solucionan problemas de IA en silos: el equipo de ciencia de datos ve latencia del modelo, el equipo de VMware ve métricas del host, el equipo de red ve flujos, el equipo de seguridad ve acceso a herramientas, y nadie ve el servicio completo. El modelo operativo debe cerrar esa brecha.
La automatización se convierte en el modelo de consumo. La demanda de IA no escala bien mediante tickets. Si cada endpoint de modelo, namespace, VPC, reserva de GPU, dependencia de base de datos y conector de datos requiere una solicitud manual personalizada, la plataforma se convertirá en un cuello de botella o, peor aún, los equipos la evitarán. La dirección API-first de VCF 9.1 es relevante aquí. Broadcom describe VCF 9.1 como una plataforma cloud privada unificada y API-first con consumo consistente basado en OpenAPI a través de herramientas como Python, Java, PowerCLI y Terraform. Esto es importante porque el consumo de la plataforma de IA debe ser repetible. Un equipo no debería tener que inventar una nueva ruta de despliegue para cada caso de uso. Un modelo mejor es exponer zonas de aterrizaje de IA aprobadas a través de la automatización. Esto podría incluir: un sandbox de desarrollo de IA, un patrón de endpoint de modelo en producción, un patrón de aplicación RAG, un patrón de cluster VKS con GPU, un patrón de acceso restringido a datos, un patrón de integración de servicios compartidos, y un patrón de IA en producción monitorizado y con seguimiento de costes. El objetivo no es eliminar la gobernanza, sino codificarla en la ruta de aprovisionamiento. Por ejemplo, una política de proyecto de IA podría definir el propietario, el entorno, el supervisor, el namespace, la VPC, la política de conectividad, los grupos de herramientas permitidos, la cuota de recursos, los modelos permitidos, las fuentes de conocimiento aprobadas y los requisitos de observabilidad. De esta forma, el equipo de plataforma puede mapear la política a proyectos, namespaces, cuotas, políticas VPC, fuentes de datos aprobadas, patrones de runtime de modelo y requisitos de monitorización. Seguridad puede revisar el acceso a herramientas, gobernanza de datos puede revisar las fuentes de conocimiento, y operaciones puede definir alertas antes de que llegue el tráfico de producción. Así es como la IA privada se convierte en una plataforma, no en otro stack de TI paralelo.
La implementación práctica debe ser por fases. Comience con un caso de uso estrecho pero realista. Evite una construcción genérica de plataforma de IA sin una carga de trabajo ancla. Un caso de uso RAG contra una fuente de conocimiento interna curada suele ser un punto de partida práctico porque fuerza las conversaciones correctas sobre acceso a datos, runtime de modelo, recuperación, logs y experiencia de usuario. Luego defina la primera zona de aterrizaje de IA, incluyendo Supervisor, namespace, VPC, runtime de modelo, servicio de datos, observabilidad y modelo de soporte. Mantenga el primer patrón controlado. El objetivo no es soportar a todos los equipos de inmediato. A continuación, defina los servicios de plataforma alrededor de esa zona de aterrizaje: decida qué modelos están aprobados, qué clases de GPU están disponibles, qué bases de datos están soportadas, qué políticas VPC son estándar y qué dashboards de observabilidad son obligatorios. Después, automatice las partes repetibles usando VCF Automation, APIs, Terraform, PowerCLI u otras herramientas estándar para reducir el aprovisionamiento manual y evitar la desviación de configuración. Finalmente, cree la transferencia operativa: defina quién es propietario de incidencias, actualizaciones, cambios en fuentes de datos, problemas de runtime de modelo, capacidad de GPU, políticas de red y reporting de costes. Esta es la parte que muchos equipos omiten y también la que determina si la plataforma sobrevive al uso en producción.
Existen varias advertencias importantes. Privado no significa automáticamente gobernado: si cada repositorio, base de datos y herramienta se conecta sin revisión, la plataforma puede generar una exposición grave. El diseño del Supervisor importa desde el principio: las decisiones de tamaño, red y propiedad se vuelven más difíciles de cambiar después de que los equipos dependen de la plataforma. La elección entre VPC y VDS no es solo una preferencia técnica: afecta el modelo futuro de autoservicio y multiinquilino. El acceso a GPU necesita política: la asignación exclusiva puede ser apropiada para algunas cargas de trabajo, pero puede reducir la flexibilidad si todos los proyectos reciben hardware dedicado por defecto. Los servicios de datos necesitan propiedad en producción: una base de datos vectorial no es solo una dependencia de desarrollo una vez que la IA en producción depende de ella. La observabilidad debe incluir métricas a nivel de modelo: la salud de la infraestructura por sí sola no demuestra que el servicio de IA esté sano. Las notas de versión y las matrices de compatibilidad siguen siendo importantes: el soporte de GPU, versiones de drivers, licencias, complementos y disponibilidad de funciones deben verificarse con la documentación actual de Broadcom antes de aprobar el diseño de producción.
En conclusión, VCF 9.1 ofrece a los equipos de VMware una base más sólida para la IA privada, pero el trabajo real está en el diseño del modelo operativo. La plataforma necesita definir cómo se consume la IA, dónde se ejecuta, a qué datos puede acceder, qué herramientas puede llamar, cómo se monitoriza y cómo se gobiernan los costes. Eso requiere más que un cluster de GPU. Requiere un patrón de plataforma repetible. Los equipos que tengan éxito con VCF 9.1 y la IA no construirán cada carga de trabajo de IA como una excepción personalizada. Crearán zonas de aterrizaje, políticas, patrones de red, estándares de servicios de datos, líneas base de observabilidad y rutas de automatización. Así es como la IA privada se vuelve operativamente útil. Y ahí es donde VCF 9.1 puede convertirse en una base práctica, no solo en otra versión de plataforma.
En Q2BSTUDIO entendemos que la implementación exitosa de IA privada requiere no solo tecnología puntera, sino también un enfoque estratégico que integre inteligencia artificial con aplicaciones a medida, ciberseguridad, cloud AWS/Azure, BI/Power BI y agentes de IA. Nuestra experiencia como empresa de desarrollo de software nos permite diseñar modelos operativos que convierten la capacidad técnica en realidad operativa. Si buscas una hoja de ruta práctica para tu plataforma de IA privada, estamos aquí para ayudarte.
