SLA de centro de datos para IA: las 5 cláusulas que faltan
Una noche de octubre, un clúster de GPU pierde su proceso de entrenamiento a las tres de la mañana. La sala no se apagó: la energía no se interrumpió, el enfriamiento no falló y el generador no arrancó. Tu contrato registra para ese horario una disponibilidad de 99.98 %. Y aun así, el trabajo de once horas se perdió. Cuando operaciones pregunta quién responde por esas once horas, el SLA que firmaste no lo dice: mide la sala, no la carga.
Esa diferencia es el problema central de las cargas de inteligencia artificial: la disponibilidad de la infraestructura dejó de garantizar el éxito del trabajo, y cerrarla por escrito es trabajo de contrato, no de arquitectura. Este artículo te da las cinco cláusulas que el SLA de un centro de datos no incluye hoy, la fuente legal mexicana que ya obliga a documentar esa responsabilidad, y el entregable que puedes exigir.
Qué mide tu SLA de centro de datos
Durante dos décadas el modelo de alojamiento se construyó sobre una proposición simple: el operador aporta el centro de datos, el cliente aporta sus sistemas y ambos acuerdan niveles de servicio. El cliente compraba espacio, energía, enfriamiento y conectividad y recibía infraestructura confiable, seguridad física y disponibilidad, con responsabilidades claramente definidas. Los SLA medían disponibilidad de la instalación, de energía y seguridad física.
Lo que cambió es la escala del problema. Un despliegue de IA abarca sistemas de potencia, enfriamiento líquido, redes de alto desempeño, GPU, almacenamiento, plataformas de software y equipos de operación: cuando falla un proceso de entrenamiento, la causa raíz puede estar en varias capas de infraestructura y de propiedad. Un centro de datos se declara preparado para IA cuando cumple cuatro requisitos de ingeniería: densidad de rack de hasta 227 kW, enfriamiento líquido directo al chip, preparación para el comportamiento transitorio de la potencia y resiliencia del clúster de GPU.
Esos cuatro requisitos son de ingeniería, no de contrato. El fabricante de la infraestructura eléctrica y de enfriamiento lo dice de otra forma: Vertiv proyecta que la densidad promedio de un módulo de IA pase de 40 a 100 kW a 100 a 250 kW en los próximos años, con consumos de GPU variables frente a los de CPU, que son mucho más estables. Un contrato escrito para cargas estables y una planta con consumos variables son dos problemas distintos. El contexto técnico ya está publicado aquí: qué infraestructura necesita tu clúster de GPU antes del primer H100.
Las cinco cláusulas que tu SLA de IA no tiene
El punto de partida es una frase del fabricante de la infraestructura: la disponibilidad de la instalación ya no garantiza el éxito de la carga de trabajo. La pregunta cambió de “¿estuvo disponible la instalación?” a “¿desempeñó la infraestructura como se esperaba para la carga?”. Si el contrato solo responde la primera, el trabajo de IA corre por cuenta del cliente.
Estas son las cinco cláusulas que cierran esa distancia, con la evidencia que hay que pedir por escrito en cada caso:
| Cláusula | Qué dice hoy el SLA | Qué debería decir | Evidencia que se pide |
|---|---|---|---|
| Visibilidad compartida | Disponibilidad del centro de datos | Métricas de potencia, enfriamiento, ambiente, incidentes y salud de activos | Reporte periódico con series, no capturas de pantalla |
| Desempeño de la carga | No existe | Variables definidas y método de medición | Línea base y umbral por variable |
| Remediación y escalamiento | Crédito por incumplimiento | Plazo por severidad, responsable y hora de escalamiento | Bitácora de incidentes con marcas de tiempo |
| Glosario de resiliencia | Términos sueltos | Anexo con definiciones y supuestos | Anexo firmado del contrato |
| Reparto de responsabilidad | “El operador da el centro de datos, el cliente da la computación” | Matriz por dominio y límites de responsabilidad | Matriz más acta de revisión del contrato |
El punto ciego: la resiliencia no significa lo mismo para los dos
El problema de fondo no es la redacción: es que las dos partes usan el mismo vocabulario y están diseñando para escenarios de falla distintos. El fabricante lo dice así: la confianza se erosiona en cuanto los supuestos no coinciden, y las suposiciones de cada lado rara vez están alineadas.
La clasificación por niveles lo hace visible. En el sistema del Uptime Institute, el nivel III es mantenible de forma concurrente, con componentes y rutas redundantes y sin paros por mantenimiento; el nivel IV agrega tolerancia a fallas y sistemas físicamente aislados. El propio estándar advierte que, con los componentes redundantes fuera de servicio por mantenimiento, el entorno tiene mayor riesgo de disrupción si ocurre una falla. Dos proveedores pueden vender el mismo nivel con ventanas de mantenimiento distintas, y esa diferencia no aparece en ninguna tabla de precios.
Peor: el vocabulario está en disputa. Uptime Institute y TIA publicaron un comunicado conjunto en el que TIA se compromete a modificar el estándar ANSI/TIA-942 para eliminar la palabra “Tier”, de modo que el sistema de niveles de Uptime y la escala de TIA queden separados. Cuando tu proveedor dice “Tier III” y la contraparte dice “Rated-3”, no se contradicen: usan dos sistemas de referencia que la industria decidió separar. El glosario con supuestos no es un adorno legal: es la cláusula que evita la discusión después del incidente. El contexto está en qué es un SLA de Tier I, II, III y IV.
En México el contrato de la instalación ya es un contrato de datos
Si tu carga de IA procesa datos personales —y en México casi siempre: registros de clientes, expedientes de empleados, telemetría con identificadores—, el contrato del centro de datos no es sólo de servicios: también es un contrato de tratamiento de datos.
La Ley Federal de Protección de Datos Personales en Posesión de los Particulares, en su texto vigente —publicada en el Diario Oficial de la Federación el 20 de marzo de 2025, con última reforma del 14 de noviembre de 2025, y cuya autoridad es ahora la Secretaría Anticorrupción y Buen Gobierno, no el INAI—, define en el artículo 2, fracción XII, a la “persona encargada” como la persona que trata datos personales por cuenta del responsable. El operador que aloja los datos del cliente entra, en términos prácticos, en esa figura. Y de ahí se derivan cuatro obligaciones:
Nada de esto es asesoría legal: la redacción final la revisa el área legal del cliente. El punto es otro: la ley mexicana ya exige documentar por escrito lo que tu SLA da por sentado, y esa es la cláusula con más recorrido en una negociación.
Qué puedes exigir por escrito
La auditoría que necesitas no es una lista de buenos deseos: es un documento con la tabla de las cinco cláusulas, la evidencia, el anexo de glosario y supuestos y la matriz de responsabilidad por dominio. Es el mismo ejercicio que la industria ya ejecuta del lado de la infraestructura: el Uptime Institute mantiene un servicio de análisis de brecha de niveles y acumula más de 4,300 certificaciones. Lo que no hace cualquiera es aplicarlo al contrato de una carga de IA en México.
El punto de Noxtel: cotizamos la auditoría de brecha de contrato y SLA para cargas de IA: las cinco cláusulas con su evidencia, el anexo de resiliencia y supuestos, la matriz de responsabilidad y el anexo de datos personales con los artículos 18, 19, 20, 35 y 36 verificados contra tu contrato vigente. Lo entregamos como documento que puedes enviar a tu proveedor. Si tu centro de datos todavía no tiene SLA, el punto de partida es el assessment de centro de datos.
Fuentes
¿Quieres dominar este tema?
Noxtel Academy →
