Cómo contratar e implantar data centers públicos: cloud-first, ETP, Ley 14.133, TIA-942-C, ISO 22237, redundancia, fiscalización, comisionamiento y aceptación.
¡Descúbrelo!
Contratar un data center público no es comprar racks, servidores, UPS, chillers o grupos electrógenos. Es decidir cómo una organización pública garantizará disponibilidad, seguridad, continuidad y capacidad para servicios digitales críticos durante años — y después transformar esa decisión en requisitos multidisciplinarios que puedan licitarse, fiscalizarse, probarse y aceptarse.
En el Poder Ejecutivo Federal brasileño integrante del SISP, esta decisión tiene un gate aún anterior: la Instrucción Normativa SGD/ME nº 94/2022 establece que los organismos y entidades que necesiten crear, ampliar o renovar infraestructura de centro de datos deben hacerlo mediante servicios de computación en la nube, salvo cuando la inviabilidad sea demostrada en el Estudio Técnico Preliminar. Por ello, para esos organismos, una nueva inversión en infraestructura física no debe comenzar por el BOM; comienza por la justificación técnica y estratégica de por qué es necesaria una alternativa física, híbrida o de modernización.
Cuando la infraestructura física está justificada, el problema cambia de naturaleza. Un data center reúne arquitectura, electricidad, energía ininterrumpida, generación, climatización, telecomunicaciones, automatización, seguridad física, detección y extinción de incendios, monitoreo, software de gestión, operación y procedimientos. La propia IN 94 diferencia varios de estos elementos — como cableado, infraestructura eléctrica, refrigeración y seguridad física — de la categoría estricta de recursos de TIC, incluso cuando forman parte de una sala de data center. Esta separación muestra por qué la contratación exige coordinación entre Ingeniería y Tecnología de la Información.
El error más peligroso es reducir una infraestructura de misión crítica a una lista de equipos. Dos proyectos pueden utilizar marcas similares y poseer niveles de resiliencia completamente diferentes. La disponibilidad nace de la arquitectura, de la eliminación de puntos únicos de falla, de la capacidad de mantenimiento, del comportamiento ante fallas, de los procedimientos operativos y de la validación integrada del sistema.
La primera pregunta es: ¿el organismo realmente necesita un nuevo data center físico?
En el sector público federal brasileño comprendido por el SISP, la elección de crear, ampliar o renovar infraestructura física de centro de datos debe superar primero el gate del Estudio Técnico Preliminar. La decisión correcta puede ser nube, híbrido, modernización o infraestructura propia — y debe demostrarse antes del proyecto.
Antes de discutir potencia, Tier, redundancia o área técnica, el Estudio Técnico Preliminar debe comparar alternativas.
En el contexto del SISP federal brasileño, la regla cloud-first de la IN SGD/ME nº 94/2022 exige una demostración cuando la solución elegida implica crear, ampliar o renovar infraestructura de centro de datos fuera de la estrategia principal de nube.
El análisis no debe ser superficial. “Necesitamos mantener los datos dentro del edificio” o “siempre tuvimos un CPD propio” no constituyen, por sí solos, justificaciones de ingeniería.
El estudio debe evaluar al menos:
- criticidad de las cargas;
- requisitos de latencia;
- soberanía y clasificación de la información;
- integraciones con sistemas locales;
- dependencia de conectividad externa;
- disponibilidad exigida;
- requisitos de recuperación ante desastres;
- capacidad de la infraestructura existente;
- costos de CAPEX y OPEX;
- ciclo de vida de los activos;
- competencias de operación;
- estrategia de nube y ambiente híbrido;
- riesgos de concentración;
- portabilidad;
- plazo de implantación;
- posibilidad de colocation o contratación de servicios especializados.
El Estudio de Viabilidad de Data Center debe transformar estas dimensiones en alternativas comparables, y no en una justificación escrita después de que la solución ya haya sido elegida.
Un data center público es un sistema de misión crítica, no un proyecto de TI aislado
La infraestructura soporta servicios que pueden incluir recaudación, salud, justicia, seguridad, educación, identidad, sistemas administrativos, datos institucionales y aplicaciones esenciales.
La indisponibilidad puede producir impactos que van más allá de la pérdida de productividad interna:
- interrupción de servicios al ciudadano;
- indisponibilidad de sistemas estructurantes;
- pérdida de acceso a información crítica;
- falla de comunicación entre unidades;
- riesgos de integridad y continuidad;
- impacto reputacional;
- necesidad de operación manual;
- exposición contractual y regulatoria.
Por ello, la arquitectura debe derivarse de requisitos de negocio y disponibilidad.
Comenzar con la pregunta “¿qué UPS debemos comprar?” invierte la lógica. Primero debe definirse qué falla debe soportar la instalación y qué nivel de mantenimiento debe ser posible sin interrumpir la carga crítica.
Cloud-first no elimina la Ingeniería de Data Centers
La prioridad por la nube no significa que las instalaciones físicas hayan desaparecido.
Los organismos pueden mantener ambientes propios existentes, arquitecturas híbridas, edge, infraestructura de conectividad, salas técnicas, sistemas locales o necesidades que justifiquen recursos físicos. Además, los servicios de nube dependen de data centers físicos operados por terceros.
La consecuencia es un cambio de enfoque:
- menos decisiones basadas en “poseer hardware por defecto”;
- más análisis de arquitectura de servicios;
- mayor importancia de la disponibilidad de extremo a extremo;
- integración entre infraestructura local y nube;
- planificación de migración y continuidad;
- gobernanza de dependencias externas.
Para instalaciones propias existentes, modernizar puede ser más complejo que construir un ambiente nuevo porque la operación no puede detenerse.
El artículo Modernización de Data Center sin interrumpir la operación aborda esta condición brownfield.
El ETP de un data center público debe comparar riesgo, no solo precio
El menor CAPEX inicial puede producir el mayor riesgo operativo.
Un análisis de alternativas debe considerar el costo del ciclo de vida y las consecuencias de la indisponibilidad.
| Alternativa | CAPEX | OPEX | Control | Escalabilidad | Dependencia externa | Complejidad operativa |
| data center propio | alto | alto | alto | moderada | menor en infraestructura local | alta |
| modernización del existente | variable | variable | alto | limitada por el sitio | moderada | muy alta durante la transición |
| colocation | menor CAPEX | recurrente | compartido | alta | alta | moderada |
| nube | bajo CAPEX físico | consumo recurrente | lógico/contractual | alta | alta | diferente de la operación del edificio |
| híbrido | distribuido | mixto | compartido | alta | múltiple | alta integración |
La tabla no determina una solución. Muestra que la comparación debe ir más allá del precio de adquisición.
El ETP también debe registrar premisas de crecimiento. Diseñar para la carga actual y descubrir dos años después que no existe capacidad eléctrica, térmica o física disponible es una falla de planificación.
Cómo definir requisitos de disponibilidad antes del proyecto
La disponibilidad debe traducirse en comportamientos esperados.
Preguntas útiles:
- ¿la carga crítica debe continuar durante el mantenimiento preventivo?
- ¿una falla de UPS puede interrumpir el servicio?
- ¿la pérdida de un chiller derriba toda la refrigeración?
- ¿existe un camino eléctrico alternativo hasta el rack?
- ¿los equipos de TI poseen doble alimentación?
- ¿el mantenimiento del cuadro principal exige shutdown?
- ¿una falla de automatización puede causar una parada?
- ¿existe autonomía suficiente para la transferencia y la operación con generación?
- ¿qué sistemas deben sobrevivir a un incendio localizado?
- ¿cómo se probará el retorno a la condición normal?
Estas preguntas producen requisitos de arquitectura.
La terminología N, N+1, 2N o distribución A/B es útil, pero no sustituye el análisis del sistema. El artículo Arquitectura eléctrica de Data Center: N, N+1, 2N y distribución A/B muestra por qué la redundancia local no garantiza resiliencia de extremo a extremo.
TIA-942-C e ISO/IEC 22237: cómo utilizar normas sin convertir la contratación en un sello
La ANSI/TIA-942-C, publicada en mayo de 2024, abarca requisitos de infraestructura de data centers y salas de computadoras, incluyendo telecomunicaciones, energía, refrigeración, arquitectura, protección contra incendios, seguridad y otras dimensiones.
La serie ISO/IEC 22237 estructura requisitos y recomendaciones para instalaciones e infraestructura de data centers. Las partes publicadas durante 2024 tratan, entre otros temas, construcción y sistemas de seguridad.
Estas referencias ayudan a establecer un lenguaje común y criterios técnicos, pero los documentos de licitación deben indicar claramente qué requisitos se aplicarán al objeto.
Escribir únicamente “el data center deberá cumplir la TIA-942” puede ser insuficiente. Es necesario definir:
- alcance de conformidad;
- clasificación pretendida;
- disciplinas incluidas;
- requisitos obligatorios;
- criterios de verificación;
- responsabilidad por la documentación;
- necesidad o no de certificación independiente;
- tratamiento de instalaciones existentes que no puedan cumplir integralmente el estándar.
La norma debe orientar un requisito verificable. No debe funcionar como sustituto del proyecto.
La contratación debe separar requisitos de desempeño de soluciones de fabricante
Una especificación pública debe evitar depender de una marca sin justificación legal y técnica.
En misión crítica, la salida consiste en especificar desempeño e interfaces con suficiente profundidad.
Para UPS, por ejemplo, pueden ser relevantes:
- potencia y margen;
- topología;
- eficiencia;
- redundancia;
- autonomía;
- bypass;
- coordinación de protección;
- mantenimiento;
- interfaces de monitoreo;
- comportamiento ante falla;
- compatibilidad con generador;
- requisitos ambientales.
Para climatización:
- carga térmica;
- densidad;
- condiciones de proyecto;
- redundancia;
- control;
- distribución de aire o líquido;
- contención;
- monitoreo;
- respuesta ante falla;
- mantenimiento concurrente.
La misma lógica vale para generadores, cuadros, PDU, cableado, seguridad, incendios y automatización.
El BOM debe ser consecuencia de la arquitectura
Listar equipos antes de cerrar la arquitectura crea dependencias artificiales.
La secuencia correcta es:
- requisitos de negocio;
- requisitos de disponibilidad;
- capacidad y crecimiento;
- arquitectura conceptual;
- criterios de redundancia;
- proyecto básico/ejecutivo;
- especificaciones de desempeño;
- cantidades;
- BOM de referencia o adquisición.
El BOM ayuda a cuantificar la solución. No debe definir por sí solo la solución.
En procurement público, esta distinción reduce el riesgo de adquirir componentes individualmente correctos que, una vez integrados, no entregan el desempeño requerido.
Disciplinas que deben coordinarse en un data center público
Arquitectura y construcción
Incluyen compartimentación, accesos, resistencia al fuego, cargas estructurales, piso, áreas técnicas, rutas, salas eléctricas, baterías, almacenamiento, muelles y circulación para mantenimiento.
Energía eléctrica
Abarca alimentación de la concesionaria, media y baja tensión, transformadores, cuadros, ATS, STS cuando corresponda, UPS, PDU, distribución A/B, puesta a tierra, protección contra sobretensiones, selectividad, calidad de energía y medición.
Generación de emergencia
El sistema debe considerar arranque, transferencia, paralelismo cuando corresponda, autonomía, combustible, reposición, ventilación, escape, mantenimiento y comportamiento con cargas no lineales.
Climatización
La carga térmica de TI no es la única variable. Es necesario evaluar densidad, expansión, flujo de aire, contención, redundancia, condición externa, agua helada o expansión directa, bombas, controles y fallas.
Telecomunicaciones
Topología, pathways, salas, racks, fibras, cobre, cross-connects y redundancia física deben coordinarse con energía y layout.
Seguridad física
Perímetro, zonas, control de acceso, autenticación, CFTV, intrusión y procedimientos deben reflejar la criticidad y el modelo operativo.
El contenido sobre Seguridad física en Data Centers profundiza esta arquitectura.
Protección contra incendios
Detección temprana, detección convencional, supresión, compartimentación, interfaces con HVAC y energía y procedimientos de emergencia deben estar integrados.
Supervisión y automatización
BMS, EPMS y DCIM poseen funciones distintas. La integración debe evitar que alarmas críticas se pierdan entre cientos de eventos sin prioridad.
El artículo DCIM, BMS y EPMS en Data Centers detalla las diferencias.
El mayor riesgo está en la interfaz entre disciplinas
Una UPS puede estar correctamente dimensionada y fallar como sistema porque no se validó la transferencia con el generador. Un chiller redundante puede no aumentar la disponibilidad si las bombas o la alimentación siguen siendo un punto único. Dos caminos de telecomunicaciones pueden entrar al edificio por la misma ruta física.
Por ello, la fiscalización no puede organizarse únicamente mediante checklists independientes de electricidad, HVAC y TI.
Debe verificar interfaces.
Ejemplos:
- generador x UPS;
- UPS x distribución A/B;
- HVAC x automatización;
- incendios x desconexiones;
- seguridad x rutas de emergencia;
- BMS x EPMS;
- alimentación x equipos dual-cord;
- cableado x compartimentación;
- modelo de operación x mantenimiento.
El valor del Owner’s Engineering aparece con fuerza en estas fronteras.
Cómo estructurar los Términos de Referencia de un data center
El documento debe traducir la arquitectura en obligaciones verificables.
Una estructura puede incluir:
- contexto y objetivo;
- requisitos de servicio y criticidad;
- alcance y límites de suministro;
- premisas de capacidad;
- requisitos de disponibilidad;
- normas aplicables;
- requisitos por disciplina;
- requisitos de integración;
- documentación de proyecto;
- submittals;
- calidad y fiscalización;
- FAT y pruebas de fábrica;
- instalación;
- precomisionamiento;
- comisionamiento funcional;
- pruebas integradas;
- capacitación;
- documentación As Built;
- procedimientos operativos;
- criterios de recepción.
El error consiste en dedicar decenas de páginas a fichas técnicas de equipos y pocas líneas a integración, pruebas y aceptación.
Régimen de contratación y asignación de riesgos
Los data centers pueden contratarse mediante diferentes estrategias, y cada una modifica la distribución de responsabilidades.
En una contratación tradicional con proyecto detallado del contratante, la Administración mantiene mayor responsabilidad por la definición. En una contratación integrada o semi-integrada, la matriz de riesgos, los requisitos de desempeño y los límites de libertad de la contratista adquieren aún más importancia.
Cuestiones críticas incluyen:
- responsabilidad por el dimensionamiento final;
- riesgos de la condición existente;
- interfaces con la operación;
- compatibilización;
- aprobación de equivalentes;
- desempeño energético;
- garantías;
- pruebas;
- certificaciones;
- disponibilidad durante la transición;
- consecuencias de una falla en el comisionamiento.
El régimen no corrige un requisito mal definido. Cuanta más libertad se otorga al contratista, más claros deben ser los resultados esperados.
Cómo tratar la frontera entre contratación de TIC e Ingeniería
La IN SGD/ME nº 94/2022 es particularmente útil para mostrar que un data center puede reunir objetos de naturalezas diferentes.
Su Anexo I excluye de la categoría de recursos de TIC, entre otros, servicios de ingeniería civil, control de acceso físico, cableado estructurado, infraestructura eléctrica, hidráulica/refrigeración y combate a incendios, incluso cuando forman parte de una sala de data center.
Esto exige atención en la estrategia de contratación.
El organismo debe decidir si realizará:
- una contratación integrada multidisciplinaria;
- lotes coordinados;
- contratos separados;
- obra con suministros especializados;
- contratación de TIC separada de la infraestructura del edificio.
Cualquier modelo puede funcionar. El riesgo aparece cuando las fronteras no están definidas.
Una interfaz sin responsable suele convertirse en retraso o disputa.
Data center existente: due diligence antes de especificar la modernización
La modernización brownfield debe comenzar por el diagnóstico.
El equipo debe levantar:
- diagramas unifilares reales;
- capacidades instaladas;
- cargas;
- estado de UPS y baterías;
- autonomía;
- generadores;
- calidad de energía;
- climatización;
- flujo de aire;
- capacidad de racks;
- rutas de cableado;
- seguridad;
- incendio;
- automatización;
- alarmas;
- mantenimiento;
- historial de fallas;
- documentación existente.
El servicio de Diagnóstico y Modernización de Data Centers y CPDs permite establecer una baseline técnica antes de decidir intervenciones.
Sin levantamiento, los documentos de licitación transfieren incógnitas al precio o a futuras adendas.
La capacidad debe proyectarse como vector, no como un único número
Decir que el data center tendrá “500 kW” es insuficiente.
La capacidad incluye:
- potencia total;
- potencia por rack;
- espacio;
- refrigeración;
- red;
- puertos;
- autonomía;
- capacidad de generación;
- caminos disponibles;
- reserva para expansión;
- capacidad operativa.
El cuello de botella real es el menor de estos límites.
Un sitio puede tener potencia disponible en la subestación y no disponer de refrigeración, espacio o distribución suficientes.
La Gestión de capacidad en Data Centers debe acompañar el activo después de la entrega.
La eficiencia no puede comprometer la resiliencia
PUE, WUE y otros indicadores son importantes, pero deben interpretarse junto con el perfil de carga y la arquitectura.
Un proyecto público puede buscar eficiencia mediante:
- equipos de alta eficiencia;
- contención;
- elevación controlada de temperatura;
- free cooling cuando corresponda;
- optimización de setpoints;
- mejor utilización de capacidad;
- reducción de pérdidas eléctricas;
- monitoreo.
Pero el ahorro no debe crear un punto único de falla ni eliminar el margen necesario.
La evaluación debe integrar costo de ciclo de vida, sostenibilidad y misión.
El comisionamiento debe especificarse antes de la obra
El comisionamiento no es una inspección final añadida cuando la instalación está lista.
Los criterios de prueba deben influir en proyecto, adquisición, documentación e interfaces.
Un programa puede incluir:
- revisión de requisitos;
- revisión de proyecto;
- submittals;
- inspecciones de fabricación;
- FAT;
- checklists de instalación;
- pruebas individuales;
- pruebas funcionales;
- pruebas bajo carga;
- escenarios de falla;
- pruebas integradas de sistemas;
- restauración;
- documentación de resultados;
- tratamiento de pendientes.
El artículo Comisionamiento de Data Center: pruebas, niveles y criterios de aceptación presenta la lógica progresiva de pruebas.
IST: en la prueba integrada la arquitectura deja de ser una promesa
Un diagrama puede mostrar una redundancia perfecta. El IST verifica cómo se comporta el conjunto cuando se provocan eventos reales.
Los escenarios pueden incluir:
- pérdida de alimentación normal;
- falla de UPS;
- falla de módulo redundante;
- transferencia a generador;
- pérdida de equipo de refrigeración;
- pérdida de bomba;
- falla de comunicación de automatización;
- actuación de la detección de incendios;
- pérdida del camino A o B;
- retorno a la condición normal.
El objetivo no es “derribar el data center”. Es demostrar que las fallas previstas se contienen y que los procedimientos de recuperación son ejecutables.
El contenido IST en Data Centers: pruebas integradas, escenarios y criterios de aceptación profundiza este punto.
La aceptación no puede depender de que el equipo esté energizado
“Encendió” no significa “aceptado”.
Una recepción técnica debe verificar:
- instalación;
- parametrización;
- pruebas;
- redundancia;
- alarmas;
- documentación;
- As Built;
- capacitación;
- procedimientos;
- lista de pendientes;
- garantías;
- repuestos;
- integración;
- desempeño bajo los escenarios previstos.
El servicio de Comisionamiento y Aceptación de Data Centers estructura esta verificación de forma independiente.
MOP, SOP y EOP deben existir antes de la operación
Las instalaciones resilientes pueden fallar por procedimientos inadecuados.
Los MOP describen operaciones de mantenimiento planificado; los SOP estructuran rutinas; los EOP orientan la respuesta a emergencias.
El contenido MOP, SOP y EOP en Data Centers muestra por qué los procedimientos forman parte de la confiabilidad.
El handover debe entregar no solo activos, sino capacidad operativa.
La seguridad física en un data center público exige zonificación y trazabilidad
Las instalaciones gubernamentales pueden concentrar información y servicios sensibles.
La seguridad debe combinar:
- perímetro;
- zonas;
- identidad;
- control de acceso;
- autenticación;
- segregación de áreas;
- CFTV;
- detección de intrusión;
- registro de visitantes;
- procedimientos;
- retención de logs;
- respuesta a incidentes.
La ISO/IEC 22237-6:2024 trata requisitos y recomendaciones para sistemas de seguridad de data centers en relación con acceso no autorizado, intrusión y eventos internos y externos.
El requisito público debe evitar una simple lista de cámaras y lectores. Debe definir objetivos de protección, cobertura, retención, integración y operación.
Cómo fiscalizar la implantación de un data center
La fiscalización debe acompañar la cadena completa, y no solo la etapa civil.
Una matriz puede utilizar fases:
| Fase | Evidencias principales |
| proyecto | cálculos, diagramas, estudios, coordinación |
| procurement | submittals, equivalencia, FAT, certificados |
| instalación | inspecciones, checklists, fotos, torque, identificación |
| precomisionamiento | pruebas individuales, calibración, continuidad |
| comisionamiento | pruebas funcionales e interbloqueos |
| IST | escenarios integrados y fallas simuladas |
| handover | As Built, Data Book, procedimientos, capacitación |
El fiscal debe tener acceso a las evidencias antes de la medición de los hitos correspondientes.
La medición debe acompañar entregables verificables
Los data centers poseen equipos costosos. Esto crea el riesgo de que la curva financiera avance mucho antes que la preparación operativa.
La medición puede vincularse a hitos como:
- proyecto aprobado;
- fabricación;
- FAT;
- entrega;
- instalación;
- energización;
- prueba funcional;
- IST;
- aceptación.
Los pesos deben equilibrarse para evitar front-loading.
Un equipo entregado en el sitio no representa el mismo valor que un sistema instalado, probado e integrado.
Owner’s Engineering: por qué el sector público necesita una visión independiente
En misión crítica, el integrador no debe ser la única fuente de confirmación de que su propia arquitectura atiende el interés del propietario. La capa independiente revisa proyecto, interfaces, propuestas, submittals, mediciones, pruebas y riesgos.
En una contratación compleja, el ejecutor posee un interés legítimo en cumplir su contrato y optimizar su solución. La Administración necesita una capa técnica que represente sus propios requisitos.
El Owner’s Engineering puede actuar en:
- definición de requisitos;
- revisión del ETP y TR;
- revisión de arquitectura;
- análisis de propuestas;
- equivalencia técnica;
- design review;
- fiscalización;
- análisis de submittals;
- inspecciones;
- validación de mediciones;
- control de interfaces;
- gestión de riesgos;
- comisionamiento;
- aceptación;
- handover.
El servicio de Owner’s Engineering para Data Centers fue estructurado exactamente para esta gobernanza entre requisitos, proyecto, implantación y aceptación.
Independencia en evaluación y fiscalización de TIC
La IN SGD/ME nº 94/2022 contiene un principio especialmente relevante: cuando se contrata la evaluación, medición o el apoyo a la fiscalización de la solución de TIC, la empresa que provee la solución no puede ser la misma que la evalúa, mide o apoya su fiscalización.
Incluso cuando parte de la infraestructura física sigue un encuadre de Ingeniería, la lógica de independencia es valiosa para misión crítica.
El integrador no debe ser la única fuente de confirmación de que su propia arquitectura cumple el requisito.
Ejemplo: modernización de un data center de un organismo público
Considere un organismo con un data center de 12 años, carga crítica creciente e historial de alarmas de climatización.
La demanda inicial podría ser “cambiar UPS y aire acondicionado”. Una due diligence revela:
- UPS próxima al límite;
- baterías al final de su vida útil;
- generador con autonomía insuficiente;
- distribución eléctrica con un punto único;
- refrigeración N+1 solo nominal, porque las unidades comparten alimentación;
- racks con densidad desigual;
- BMS sin integración con EPMS;
- rutas de fibra convergentes;
- documentación As Built desactualizada.
Comprar únicamente UPS y CRAC nuevos no resuelve el riesgo sistémico.
La estrategia pasa a ser:
- validar necesidad física frente a nube/híbrido;
- definir requisito de disponibilidad;
- crear arquitectura objetivo;
- planificar fases sin interrupción;
- proyectar caminos y redundancias;
- especificar equipos por desempeño;
- contratar con matriz de interfaces;
- ejecutar con fiscalización independiente;
- realizar comisionamiento progresivo;
- probar escenarios integrados;
- entregar procedimientos y As Built.
La diferencia entre compra de equipos e Ingeniería Consultiva está precisamente en esta transformación de la demanda en sistema.
Checklist antes de licitar un data center público
La Administración debe poder responder:
- ¿el ETP comparó nube, híbrido e infraestructura física cuando correspondía?
- ¿la necesidad del data center está técnicamente justificada?
- ¿se definieron requisitos de disponibilidad?
- ¿se estimó la capacidad actual y futura?
- ¿la arquitectura eléctrica está cerrada?
- ¿la climatización está coordinada con la densidad?
- ¿la seguridad física y los incendios poseen criterios definidos?
- ¿las telecomunicaciones poseen rutas y redundancia?
- ¿los sistemas de monitoreo están integrados?
- ¿las interfaces entre TIC e Ingeniería están definidas?
- ¿el régimen de contratación es coherente con la madurez del proyecto?
- ¿la matriz de riesgos cubre las condiciones existentes y la disponibilidad?
- ¿los requisitos de comisionamiento están en los documentos de licitación?
- ¿el IST posee escenarios y criterios?
- ¿la medición está vinculada a entregables verificables?
- ¿As Built y Data Book están especificados?
- ¿la capacitación y los procedimientos forman parte de la aceptación?
Si varias respuestas son negativas, los documentos de licitación probablemente están intentando contratar equipos antes de contratar una arquitectura de misión crítica.
Cuándo utilizar Estudio de Viabilidad, Proyecto, Owner’s Engineering y Comisionamiento
Estos servicios resuelven problemas diferentes.
Estudio de Viabilidad
Define la alternativa: mantener, modernizar, construir, colocation, nube o híbrido.
Proyecto de Data Center
Transforma requisitos en arquitectura, cálculos, planos, especificaciones y documentos de contratación.
Owner’s Engineering
Representa técnicamente al propietario durante procurement e implantación.
Comisionamiento
Verifica si el sistema instalado cumple los requisitos y funciona bajo escenarios de operación y falla.
En proyectos de mayor riesgo, los cuatro forman una secuencia lógica.
Los gates técnicos que deben preceder a la licitación y la aceptación
En infraestructura crítica, la contratación se vuelve más segura cuando las decisiones irreversibles están condicionadas a gates técnicos. El objetivo es impedir que el proyecto avance hacia adquisición, instalación o recepción con premisas todavía abiertas. Cada gate debe cerrar un conjunto de decisiones y producir evidencias suficientes para autorizar la fase siguiente.
| Gate | Decisión | Evidencias mínimas |
| G0 — estrategia | nube, híbrido, colocation, modernización o infraestructura propia | ETP, criticidad, requisitos de servicio, análisis de alternativas y TCO |
| G1 — requisitos | qué disponibilidad, capacidad y resiliencia serán contratadas | Owner’s Project Requirements, premisas de crecimiento, matriz de criticidad y criterios de continuidad |
| G2 — arquitectura | cómo se integran energía, refrigeración, telecomunicaciones, incendios, seguridad y automatización | diagramas, cálculos, matriz de interfaces, análisis de puntos únicos de falla y mantenimiento concurrente |
| G3 — procurement | si los equipos y sistemas propuestos cumplen el desempeño especificado | submittals, equivalencia técnica, data sheets, estudios, FAT y documentación del fabricante |
| G4 — preparación para energización | si la instalación puede iniciar pruebas funcionales con seguridad | checklists, inspecciones, calibración, torque, continuidad, parametrización y punch list controlada |
| G5 — preparación operativa | si el conjunto soporta escenarios de operación y falla | pruebas funcionales, interbloqueos, alarmas, pruebas bajo carga e IST |
| G6 — aceptación | si el propietario puede asumir el activo | As Built, Data Book, MOP/SOP/EOP, capacitación, garantías, pendientes residuales y evidencias de desempeño |
Este encadenamiento reduce el riesgo de aceptar un sistema técnicamente incompleto únicamente porque terminó la instalación física. En data centers, una parte relevante del valor está precisamente en lo que solo aparece durante una falla simulada, el mantenimiento planificado, la transferencia de fuente y la restauración.
La redundancia debe verificarse como una cadena, no como una etiqueta
Una de las trampas más comunes es tratar N+1 o 2N como un atributo aislado del equipo. La resiliencia real depende de la cadena completa entre la fuente y la carga. Un sistema puede poseer UPS redundantes y seguir vulnerable porque comparte un único cuadro, bus, ATS, ruta, controlador, alimentación de bomba o punto de distribución.
Por ello, para cada falla previsible, la revisión de arquitectura debe formular tres preguntas: qué componente se pierde, qué camino asume la carga y qué funciones permanecen disponibles durante la recuperación. La respuesta debe poder demostrarse en diagramas y después comprobarse mediante pruebas.
Esta lógica también vale para refrigeración y telecomunicaciones. Dos máquinas no representan redundancia efectiva si dependen de la misma alimentación o del mismo circuito hidráulico. Dos enlaces no representan diversidad si recorren la misma ruta física. La redundancia declarada por el proveedor debe convertirse en un análisis de puntos únicos de falla.
La aceptación debe vincularse a una matriz de desempeño
Un documento de licitación sólido no termina en la lista de equipos y servicios. Informa cómo la Administración reconocerá que el objeto fue efectivamente entregado. Para ello, cada requisito relevante debe poseer un método de verificación.
Los requisitos documentales pueden verificarse mediante revisión de submittals y Data Book. Los requisitos físicos pueden exigir inspección. Los requisitos de capacidad exigen mediciones. Los requisitos de redundancia exigen aislamiento de componentes y pérdida de caminos. Los requisitos de integración exigen pruebas de interbloqueo. Los requisitos de continuidad exigen escenarios integrados.
La matriz de desempeño debe nacer en el proyecto y trasladarse a los Términos de Referencia, al plan de comisionamiento y a los boletines de medición. Así, el criterio utilizado para especificar el sistema es el mismo utilizado para fiscalizarlo y aceptarlo. Esto reduce la subjetividad, evita una recepción prematura y mejora la posición técnica de la Administración ante divergencias.
Consideraciones finales
Los data centers públicos exigen una combinación poco común de Ingeniería, TIC, procurement, seguridad, operación y gobernanza. La criticidad del servicio no permite reducir la contratación a equipos de catálogo.
En el SISP federal brasileño, la propia planificación comienza por la estrategia cloud-first y exige justificación cuando se elige la solución física. Cuando esa infraestructura es necesaria, la Administración debe definir disponibilidad, capacidad, arquitectura, interfaces, criterios de desempeño, medición, comisionamiento y aceptación antes de la licitación.
Las referencias TIA-942-C e ISO/IEC 22237 ayudan a estructurar requisitos técnicos, pero no sustituyen la ingeniería del objeto. La redundancia debe analizarse de extremo a extremo y el comportamiento del sistema debe comprobarse mediante pruebas integradas.
El objetivo de la contratación no es recibir un conjunto de equipos energizados. Es recibir una infraestructura capaz de sostener los servicios públicos para los cuales fue concebida, con riesgos conocidos, documentación completa y desempeño demostrado.
La recepción de un data center debe basarse en desempeño demostrado. Las pruebas individuales, funcionales e integradas deben comprobar que la instalación responde correctamente a fallas, transferencias y condiciones de recuperación previstas en el proyecto.
Referencias técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. 2021. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] SECRETARIA DE GOVERNO DIGITAL. Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022 — processo de contratação de soluções de TIC. 2022. Disponible en: https://www.gov.br/governodigital/pt-br/contratacoes-de-tic/legislacao/processo-de-contratacao-de-solucoes-de-tic-regido-pela-lei-ndeg-14-133-de-2021.
[3] GOVERNO DIGITAL. Data Centers no Governo Federal. 2026. Disponible en: https://www.gov.br/governodigital/pt-br/infraestrutura-nacional-de-dados/ambiente-tecnologico/data-centers.
[4] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI/TIA-942-C — Telecommunications Infrastructure Standard for Data Centers. 2024. Disponible en: https://tiaonline.org/standard/tia-942/.
[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-2:2024 — Data centre facilities and infrastructures — Building construction. 2024. Disponible en: https://www.iso.org/standard/82248.html.
[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-6:2024 — Data centre facilities and infrastructures — Security systems. 2024. Disponible en: https://www.iso.org/standard/82250.html.
Preguntas frecuentes
Para los organismos y entidades integrantes del SISP, la IN SGD/ME 94/2022 establece que la creación, ampliación o renovación de infraestructura de centro de datos debe seguir la estrategia de contratación de servicios de computación en la nube, salvo cuando la inviabilidad sea demostrada en el Estudio Técnico Preliminar.
Puede involucrar ambas. La IN 94/2022 excluye de la categoría de recursos de TIC diversos elementos físicos, como ingeniería civil, cableado estructurado, infraestructura eléctrica, refrigeración, control de acceso físico y combate a incendios, incluso cuando forman parte de una sala de data center. La estrategia debe definir claramente las interfaces.
No existe una obligación general nacional de certificar todo data center público según TIA-942-C. La norma puede adoptarse como referencia técnica según el objeto, y los documentos de licitación deben definir qué requisitos, clasificaciones y verificaciones serán exigidos.
Deben definirse criticidad, requisitos de disponibilidad, capacidad, arquitectura eléctrica, redundancia, autonomía, mantenimiento y comportamiento esperado ante fallas. El equipo es consecuencia de estos requisitos.
Porque equipos aprobados individualmente pueden fallar cuando se integran. El comisionamiento verifica funciones, interbloqueos, alarmas, redundancia y escenarios de falla, culminando en pruebas integradas del sistema.
N+1 describe reserva de capacidad en determinado subsistema. La resiliencia exige analizar el camino completo y verificar si existen puntos únicos de falla, capacidad de mantenimiento y comportamiento adecuado cuando se pierden componentes o utilidades.
Representa técnicamente al propietario en la definición de requisitos, revisión de proyecto, procurement, análisis de propuestas, fiscalización, control de interfaces, validación de mediciones, comisionamiento, aceptación y handover.
Materiales técnicos complementarios
Soluciones relacionadas
- Data Centers: infraestructura crítica, disponibilidad, energía y conectividad
- Data Center Infrastructure Management — DCIM
Servicios relacionados
- Estudio de Viabilidad de Data Center
- Proyecto de Data Center
- Owner’s Engineering para Data Centers
- Comisionamiento y Aceptación de Data Centers
