En l’ecosistema actual d’intel·ligència artificial privada, és cada vegada més freqüent trobar arquitectures que combinen maquinari de Dell o HPE, virtualització amb VMware Cloud Foundation, orquestració amb Kubernetes, acceleració de NVIDIA i emmagatzematge empresarial. Cada un d’aquests components té el suport individual del seu fabricant, però quan el sistema complet falla, la pregunta clau no és 'què s’ha trencat?' sinó 'qui ha d’investigar primer?'. Aquest dilema, conegut com a 'ping-pong de proveïdors', pot paralitzar l’operació durant hores o dies. Per evitar-ho, no n’hi ha prou amb tenir contractes de suport; cal un model operatiu intern que defineixi amb claredat les responsabilitats de diagnòstic, escalat i resolució. Aquest model es plasma en una matriu RACI de suport específica per a plataformes d’IA privada multivendor.
La matriu RACI (Responsable, Accountable, Consultat i Informat) és una eina clàssica de gestió de projectes que, aplicada al suport tècnic, permet assignar de manera inequívoca qui assumeix la primera acció diagnòstica davant d’un símptoma determinat. En un entorn amb múltiples proveïdors, l’error més comú és esperar a conèixer la causa arrel per assignar responsabilitats. La realitat és que la causa arrel pot trigar hores a identificar-se, mentre que el primer diagnòstic ha de començar en segons. Per això, la RACI de suport no es basa en 'qui va causar la fallada', sinó en 'qui ha de mirar primer'.
Imaginem un node Kubernetes que deixa d’anunciar GPUs. L’equip d’infraestructura podria pensar que és un problema de Kubernetes; l’equip de Kubernetes podria pensar que és un problema del driver de NVIDIA; i l’equip de NVIDIA podria demanar evidències de l’hipervisor. Sense una RACI, cada equip obre un cas amb el seu proveïdor i el client acaba sent el missatger entre ells. La solució és designar un 'propietari del primer diagnòstic' per a cada símptoma. En aquest exemple, l’equip de Kubernetes i plataforma d’IA és el propietari del primer diagnòstic, perquè el símptoma es manifesta a la seva capa. La seva feina és recollir evidències i determinar si la GPU falta a nivell de sistema operatiu, del device plugin o del runtime. Només després d’aquesta anàlisi es decideix quin proveïdor ha d’obrir un cas.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, ajudem els nostres clients a dissenyar aquests models operatius per a les seves plataformes d’IA. No només desenvolupem aplicacions a mida que s’integren amb aquests entorns, sinó que també oferim serveis de consultoria per definir l’arquitectura de suport. Sabem que una plataforma d’IA privada no està operativament completa quan el maquinari està instal·lat i el primer endpoint respon; ho està quan l’organització sap qui realitza la primera acció diagnòstica davant qualsevol fallada. Per això, recomanem que el client retingui un únic propietari del servei i un director d’incidents, mentre que els equips de plataforma individuals assumeixen el diagnòstic de primera línia per a les seves capes respectives.
La matriu RACI també ha de distingir entre diferents tipus de responsabilitat: la responsabilitat del servei (accountability) recau sempre en el client; la responsabilitat del primer diagnòstic (first diagnostic ownership) recau en l’equip que millor pot aïllar la fallada a la capa on apareix el símptoma; la responsabilitat de la fallada (fault ownership) s’assigna només després que l’evidència determini la causa; la responsabilitat del cas (case ownership) identifica quina organització té obert un cas amb un proveïdor; i la responsabilitat de la remediació (remediation ownership) pertany a l’equip autoritzat per implementar la solució. Confondre aquests conceptes és una de les fonts principals d’ineficiència en el suport multivendor.
Un aspecte crucial és la recollida d’evidències abans d’obrir casos amb els proveïdors. Cada capa de la plataforma (maquinari, virtualització, Kubernetes, programari NVIDIA, emmagatzematge, xarxa) ha de tenir un runbook de diagnòstic que especifiqui quins logs, mètriques i ordres recollir abans d’escalar. Per exemple, per a un problema amb un endpoint NIM de NVIDIA, l’equip de plataforma ha d’inspeccionar la cadena completa d’inici: planificació del workload, assignació de GPU, accés al registre de contenidors, estat del model cache, connectivitat de xarxa, etc. No serveix de res obrir un cas dient 'NIM va fallar'; cal identificar si la fallada es produeix durant la descàrrega de la imatge, la inicialització del model o l’exposició del servei. De la mateixa manera, en un problema de rendiment d’entrenament distribuït, l’evidència ha d’incloure mètriques de GPU, xarxa RDMA, latència d’emmagatzematge i utilització de CPU. Només així s’eviten les derivacions circulars entre proveïdors.
Per a plataformes que utilitzen núvol públic com AWS o Azure, la complexitat augmenta. Q2BSTUDIO ofereix serveis de cloud AWS/Azure que inclouen el disseny d’arquitectures híbrides on la IA privada es combina amb recursos elàstics al núvol. En aquests entorns, la RACI de suport ha d’incloure el proveïdor de núvol com un actor més, amb les seves pròpies responsabilitats de diagnòstic. Per exemple, si un node d’Azure Local no veu una GPU, l’equip d’Azure Local (o el client amb suport de Microsoft) ha de ser el primer diagnosticador, no el fabricant del maquinari. L’evidència ha d’incloure la recollida de logs diagnòstics d’Azure Local abans d’escalar a Dell o NVIDIA.
La ciberseguretat també hi té un paper fonamental. Una plataforma d’IA privada gestiona dades sensibles que no s’han de filtrar en logs ni en prompts d’intel·ligència artificial. Per això, els runbooks de diagnòstic han d’incloure procediments per sanititzar la informació abans de compartir-la amb proveïdors. Q2BSTUDIO integra serveis de ciberseguretat i pentesting en els seus projectes d’IA, assegurant que les evidències no exposin secrets empresarials. A més, l’ús d’agents IA i solucions de Business Intelligence amb Power BI pot automatitzar part del monitoratge i la correlació d’esdeveniments, reduint el temps de diagnòstic.
En definitiva, implementar una RACI de suport per a IA privada multivendor no és un exercici teòric. És una necessitat operativa que evita pèrdues de productivitat i redueix el temps de resolució d’incidències. Els passos pràctics inclouen: definir el límit del servei (què inclou la plataforma d’IA), nomenar un propietari del servei accountable, assignar propietaris de primer diagnòstic per a cada classe de símptoma, crear un registre de versions i compatibilitats, establir una línia base de configuració coneguda, elaborar runbooks d’evidències per capa, i provar la RACI mitjançant exercicis de taula. A Q2BSTUDIO acompanyem les organitzacions en aquest procés, combinant la nostra experiència en desenvolupament de programari a mida, integració al núvol, ciberseguretat, BI i agents d’IA perquè la tecnologia funcioni no només quan tot va bé, sinó també quan alguna cosa falla.
