En el ecosistema actual de inteligencia artificial privada, es cada vez más frecuente encontrar arquitecturas que combinan hardware de Dell o HPE, virtualización con VMware Cloud Foundation, orquestación con Kubernetes, aceleración de NVIDIA y almacenamiento empresarial. Cada uno de estos componentes está soportado individualmente por su respectivo fabricante, pero cuando el sistema completo falla, la pregunta clave no es '¿qué se rompió?' sino '¿quién debe investigar primero?'. Este dilema, conocido como 'ping-pong de proveedores', puede paralizar la operación durante horas o días. Para evitarlo, no basta con tener contratos de soporte; se necesita un modelo operativo interno que defina con claridad las responsabilidades de diagnóstico, escalado y resolución. Ese modelo se plasma en una matriz RACI de soporte específica para plataformas de IA privada multivendor.
La matriz RACI (Responsable, Accountable, Consultado e Informado) es una herramienta clásica de gestión de proyectos que, aplicada al soporte técnico, permite asignar de forma inequívoca quién asume la primera acción diagnóstica ante un síntoma determinado. En un entorno con múltiples proveedores, el error más común es esperar a conocer la causa raíz para asignar responsabilidades. La realidad es que la causa raíz puede tardar horas en identificarse, mientras que el primer diagnóstico debe comenzar en segundos. Por eso, la RACI de soporte no se basa en 'quién causó el fallo', sino en 'quién debe mirar primero'.
Imaginemos un nodo Kubernetes que deja de anunciar GPUs. El equipo de infraestructura podría pensar que es un problema de Kubernetes; el equipo de Kubernetes podría pensar que es un problema del driver de NVIDIA; y el equipo de NVIDIA podría pedir evidencias del hipervisor. Sin una RACI, cada equipo abre un caso con su proveedor y el cliente termina siendo el mensajero entre ellos. La solución es designar un 'propietario del primer diagnóstico' para cada síntoma. En este ejemplo, el equipo de Kubernetes y plataforma de IA es el dueño del primer diagnóstico, porque el síntoma se manifiesta en su capa. Su trabajo es recopilar evidencias y determinar si la GPU falta a nivel de sistema operativo, del device plugin o del runtime. Solo después de ese análisis se decide qué proveedor debe abrir un caso.
En Q2BSTUDIO, como empresa de desarrollo de software y tecnología, ayudamos a nuestros clientes a diseñar estos modelos operativos para sus plataformas de IA. No solo desarrollamos aplicaciones a medida que se integran con estos entornos, sino que también ofrecemos servicios de consultoría para definir la arquitectura de soporte. Sabemos que una plataforma de IA privada no está operativamente completa cuando el hardware está instalado y el primer endpoint responde; lo está cuando la organización sabe quién realiza la primera acción diagnóstica ante cualquier fallo. Por eso, recomendamos que el cliente retenga un único propietario del servicio y un director de incidentes, mientras que los equipos de plataforma individuales asumen el diagnóstico de primera línea para sus capas respectivas.
La matriz RACI también debe distinguir entre distintos tipos de responsabilidad: la responsabilidad del servicio (accountability) recae siempre en el cliente; la responsabilidad del primer diagnóstico (first diagnostic ownership) recae en el equipo que mejor puede aislar el fallo en la capa donde aparece el síntoma; la responsabilidad del fallo (fault ownership) se asigna solo después de que la evidencia determine la causa; la responsabilidad del caso (case ownership) identifica qué organización tiene abierto un caso con un proveedor; y la responsabilidad de la remediación (remediation ownership) pertenece al equipo autorizado para implementar la solución. Confundir estos conceptos es una de las fuentes principales de ineficiencia en el soporte multivendor.
Un aspecto crucial es la recogida de evidencias antes de abrir casos con los proveedores. Cada capa de la plataforma (hardware, virtualización, Kubernetes, software NVIDIA, almacenamiento, red) debe tener un runbook de diagnóstico que especifique qué logs, métricas y comandos recopilar antes de escalar. Por ejemplo, para un problema con un endpoint NIM de NVIDIA, el equipo de plataforma debe inspeccionar la cadena completa de inicio: planificación del workload, asignación de GPU, acceso al registro de contenedores, estado del modelo cache, conectividad de red, etc. No sirve de nada abrir un caso diciendo 'NIM falló'; hay que identificar si el fallo ocurre durante la descarga de la imagen, la inicialización del modelo o la exposición del servicio. De igual forma, en un problema de rendimiento de entrenamiento distribuido, la evidencia debe incluir métricas de GPU, red RDMA, latencia de almacenamiento y utilización de CPU. Solo así se evitan las derivaciones circulares entre proveedores.
Para plataformas que utilizan cloud público como AWS o Azure, la complejidad aumenta. Q2BSTUDIO ofrece servicios de cloud AWS/Azure que incluyen el diseño de arquitecturas híbridas donde la IA privada se combina con recursos elásticos en la nube. En estos entornos, la RACI de soporte debe incluir al proveedor cloud como un actor más, con sus propias responsabilidades de diagnóstico. Por ejemplo, si un nodo de Azure Local no ve una GPU, el equipo de Azure Local (o el cliente con soporte de Microsoft) debe ser el primer diagnosticador, no el fabricante del hardware. La evidencia debe incluir la recogida de logs diagnósticos de Azure Local antes de escalar a Dell o NVIDIA.
La ciberseguridad también juega un papel fundamental. Una plataforma de IA privada maneja datos sensibles que no deben filtrarse en logs ni en prompts de inteligencia artificial. Por eso, los runbooks de diagnóstico deben incluir procedimientos para sanitizar la información antes de compartirla con proveedores. Q2BSTUDIO integra servicios de ciberseguridad y pentesting en sus proyectos de IA, asegurando que las evidencias no expongan secretos empresariales. Además, el uso de agentes IA y soluciones de Business Intelligence con Power BI puede automatizar parte del monitoreo y la correlación de eventos, reduciendo el tiempo de diagnóstico.
En definitiva, implementar una RACI de soporte para IA privada multivendor no es un ejercicio teórico. Es una necesidad operativa que evita pérdidas de productividad y reduce el tiempo de resolución de incidentes. Los pasos prácticos incluyen: definir el límite del servicio (qué incluye la plataforma de IA), nombrar un propietario del servicio accountable, asignar dueños de primer diagnóstico para cada clase de síntoma, crear un registro de versiones y compatibilidades, establecer una línea base de configuración conocida, elaborar runbooks de evidencias por capa, y probar la RACI mediante ejercicios de mesa. En Q2BSTUDIO acompañamos a las organizaciones en este proceso, combinando nuestra experiencia en desarrollo de software a medida, integración cloud, ciberseguridad, BI y agentes de IA para que la tecnología funcione no solo cuando todo está bien, sino también cuando algo falla.
