Owner’s Engineering em Data Centers: responsabilidades, matriz RACI e limites de atuação

Entenda como aplicar Owner’s Engineering em Data Centers, com responsabilidades, matriz RACI, limites, interfaces, entregáveis, comissionamento e aceite.

Confira!

O Owner’s Engineering em Data Centers é a aplicação da Engenharia do Proprietário à governança de empreendimentos nos quais energia crítica, climatização, telecomunicações, automação, segurança, incêndio, arquitetura, operação e tecnologia precisam funcionar como um único sistema. Sua função é representar tecnicamente o proprietário, preservar os requisitos aprovados, controlar interfaces, qualificar decisões e consolidar evidências para implantação, comissionamento e aceite.

Este artigo não pretende substituir a explicação geral sobre o que é Owner’s Engineering. O foco aqui é outro: como a função deve ser estruturada especificamente em projetos, expansões e modernizações de Data Centers, quais responsabilidades pode assumir, quais decisões permanecem com o proprietário e quais atividades pertencem aos projetistas, fornecedores, gerenciadora, fiscalização e autoridade de comissionamento.

Em um Data Center, o OE não deve ser entendido como uma fiscalização ampliada nem como um projetista paralelo. Ele organiza a governança técnica entre requisitos, projetos, contratos, submittals, execução, testes e operação. A responsabilidade técnica pelas soluções e pelos fornecimentos continua com seus respectivos autores e executores; o proprietário permanece responsável pelas decisões de investimento, risco e operação.

Síntese técnica

Questão	Resposta objetiva
Qual é a função do OE?	Representar tecnicamente o proprietário e preservar requisitos, interfaces, riscos e critérios de aceite.
O OE projeta?	Pode desenvolver estudos ou projetos quando isso estiver contratado, mas deve separar autoria, revisão independente e aprovação.
O OE executa a obra?	Normalmente não. A execução permanece com construtoras, EPCistas, integradores e fornecedores.
O OE aprova sozinho?	Não necessariamente. Ele analisa e recomenda; a autoridade de aprovação deve ser definida na governança.
O OE substitui o gerenciamento?	Não. Pode integrar a estrutura de gerenciamento, mas prazo, custo, contratos e comunicação possuem responsabilidades próprias.
O OE substitui o comissionamento?	Não. Governa requisitos e aceite do proprietário; a autoridade de comissionamento conduz o processo de verificação conforme o escopo contratado.
Quando gera mais valor?	Quando participa desde requisitos, projeto e contratação, antes que decisões sejam incorporadas aos contratos e equipamentos.
Qual é o principal entregável?	Não existe um único. O valor está no conjunto rastreável de pareceres, matrizes, registros, decisões, evidências e recomendações.

Por que Data Centers exigem uma aplicação específica de Owner’s Engineering?

A infraestrutura de um Data Center é composta por cadeias funcionais interdependentes. A carga de TIC depende de alimentação elétrica, rejeição de calor, conectividade, controle ambiental, proteção física, automação, detecção de incêndio, procedimentos operacionais e equipes preparadas. Um componente pode atender isoladamente à sua especificação e, ainda assim, o sistema integrado falhar em uma condição de manutenção, transferência ou emergência.

Esse risco aumenta porque cada cadeia costuma envolver diferentes projetistas, fabricantes, instaladores e contratos. A concessionária entrega energia em determinado ponto; a subestação transforma e distribui; geradores e UPS sustentam cargas; sistemas de climatização rejeitam calor; automação supervisiona estados; redes transportam dados e alarmes; sistemas de incêndio e segurança aplicam lógicas próprias. Entre esses pacotes existem dezenas de fronteiras físicas, funcionais, documentais e contratuais.

A série ISO/IEC 22237 organiza princípios de infraestrutura de Data Centers considerando disponibilidade, segurança e eficiência ao longo do ciclo de vida. A ANSI/TIA-942-C abrange instalações de diferentes portes e modelos, incluindo arquitetura, telecomunicações, energia, climatização, incêndio, segurança e monitoramento. Essas referências ajudam a estruturar requisitos, mas não substituem a governança específica do proprietário.

O OE cria essa camada de governança ao conectar:

• objetivos do investimento e requisitos do proprietário;
• critérios de projeto e decisões de arquitetura;
• responsabilidades dos contratos;
• interfaces entre disciplinas e fornecedores;
• mudanças, desvios e riscos;
• evidências de fabricação, instalação e testes;
• condições de aceite e prontidão operacional.

O artigo geral e a cauda longa de Data Centers

A palavra-chave ampla Owner’s Engineering pertence ao artigo geral da A3A Engenharia. O novo conteúdo deve funcionar como especialização semântica e metodológica.

Conteúdo	Intenção proprietária
Owner’s Engineering: governança técnica para obras e sistemas críticos	explicar o conceito geral, aplicações, modelos e diferenças para funções próximas
Este artigo	explicar responsabilidades, RACI, entregáveis e limites do OE em Data Centers
Owner’s Engineering para Data Centers	apresentar o serviço contratável, escopo comercial e atuação da A3A Engenharia

Por isso, a definição geral será curta. O restante do artigo tratará de situações próprias de Data Centers: carga de TIC, distribuição A/B, redundância, manutenção concorrente, climatização crítica, telecomunicações, BMS, EPMS, DCIM, fases energizadas, testes integrados e handover operacional.

O que o Owner’s Engineering representa no empreendimento?

O OE atua como extensão técnica do proprietário, mas não recebe automaticamente autoridade irrestrita. Sua autoridade precisa ser estabelecida em contrato, plano de governança, matriz RACI, fluxos de aprovação e delegações formais.

Na prática, a função pode assumir quatro níveis de atuação:

Nível	Atuação	Exemplo
Informar	organizar dados, riscos e evidências	consolidar relatório de desvio de capacidade
Analisar	avaliar aderência e impacto	revisar alteração de UPS ou chiller
Recomendar	emitir parecer para decisão	recomendar aprovação condicionada de submittal
Aprovar por delegação	decidir dentro de limites autorizados	aprovar documento de baixa criticidade conforme matriz

O fato de o OE revisar um documento não transfere automaticamente a responsabilidade de projeto. Um desenho elaborado pelo projetista continua sob responsabilidade de seu autor. Um equipamento selecionado e fornecido por fabricante permanece sob responsabilidade do fornecedor. Uma instalação executada por construtora permanece sob responsabilidade da executora.

A revisão do OE verifica aderência aos requisitos do proprietário e identifica riscos, inconsistências e interfaces. Ela não deve ser usada como mecanismo para deslocar ao proprietário a responsabilidade que pertence à cadeia de fornecimento.

O que o OE não deve substituir?

O proprietário

Decisões sobre investimento, tolerância a risco, prioridade de prazo, capacidade, modelo operacional, aceitação de risco residual e estratégia de expansão pertencem ao proprietário. O OE fornece análise e recomendação, mas não deve assumir silenciosamente decisões empresariais.

O projetista

O projetista desenvolve e responde tecnicamente pelas soluções sob seu escopo. O OE pode revisar critérios, cálculos, diagramas, layouts e interfaces, mas não deve corrigir informalmente documentos e permitir que a autoria fique indefinida.

O executor ou EPCista

Construtoras, integradores e EPCistas respondem pela execução, qualidade, segurança, planejamento de seus serviços e atendimento contratual. O acompanhamento do OE não elimina inspeções próprias, controle de qualidade ou responsabilidade por correções.

A gerenciadora ou o PMO

Gerenciamento de escopo, prazo, custo, contratos, comunicação e riscos do projeto pode ser exercido por uma gerenciadora, PMO ou equipe interna. O OE fornece conteúdo técnico para essas decisões, mas não deve deixar sem responsável o controle integrado do empreendimento.

A autoridade de comissionamento

O comissionamento possui processo, documentação e responsabilidades próprias. A ASHRAE/IES Standard 202-2024 descreve o processo e os papéis dos principais agentes. O OE protege os interesses do proprietário, participa da definição de requisitos e avalia evidências; a autoridade de comissionamento coordena a verificação conforme o plano aprovado.

A operação

A equipe operacional precisa participar de requisitos, revisão, procedimentos, testes e treinamento. O OE não deve decidir sozinho como a instalação será operada, mantida e recuperada após falhas.

Diferenças entre OE, gerenciamento, fiscalização, EPCM e comissionamento

Função	Responsabilidade dominante	Entregáveis típicos	Limite principal
Owner’s Engineering	governança técnica e representação do proprietário	pareceres, matrizes, revisões, decisões, evidências e recomendações	não substitui autoria técnica nem decisão empresarial
Gerenciamento	coordenação de prazo, custo, escopo, comunicação e contratos	cronogramas, relatórios, controles, atas e dashboards	pode não possuir profundidade multidisciplinar de engenharia
Fiscalização	verificação da execução em campo	relatórios, registros, medições e não conformidades	frequentemente concentrada na construção
EPCM	engenharia, procurement e construction management	projetos, pacotes, aquisições e gestão da implantação	pode assumir papel executivo mais amplo que o OE
EPC ou design-build	entrega integrada da solução	engenharia, fornecimentos, construção e testes	representa a contratada, não o proprietário
Comissionamento	verificação documentada de requisitos e desempenho	planos, checklists, testes, issues logs e relatórios	não substitui governança global do investimento
Operação	exploração segura e confiável do ativo	SOPs, MOPs, EOPs, registros e manutenção	não deve receber um sistema sem baseline e treinamento

Essas funções podem coexistir. Em um contrato EPC, por exemplo, o EPCista desenvolve e entrega a solução; uma gerenciadora controla prazo e custo; a autoridade de comissionamento estrutura os testes; e o OE verifica se requisitos, interfaces, mudanças e evidências permanecem alinhados aos interesses do proprietário.

Modelo de governança para um Data Center

A governança deve ser desenhada antes da emissão das principais RFPs. Depois que responsabilidades, preços, prazos e exclusões entram nos contratos, corrigir lacunas se torna mais difícil e caro.

Uma estrutura mínima inclui:

1. definição das autoridades do proprietário; 2. identificação dos responsáveis técnicos por disciplina; 3. matriz RACI por processo e entregável; 4. hierarquia documental e baselines; 5. fluxo de submittals, RFIs e mudanças; 6. matriz de interfaces entre pacotes; 7. registro de riscos e decisões; 8. plano de inspeção, testes e comissionamento; 9. critérios de aceite e transferência para operação; 10. regras para pendências, exceções e risco residual.

A governança não deve existir apenas como organograma. Cada fluxo precisa indicar entradas, prazo, autoridade, evidência de decisão e condição de encerramento.

Como utilizar a matriz RACI?

A matriz RACI identifica quem é responsável por executar uma atividade, quem possui autoridade final, quem deve ser consultado e quem precisa ser informado.

• R — Responsible: executa ou produz o trabalho.
• A — Accountable: responde pela decisão ou aprovação final.
• C — Consulted: participa tecnicamente antes da decisão.
• I — Informed: recebe a informação após o marco ou decisão.

Uma atividade deve possuir responsáveis definidos e, preferencialmente, uma única autoridade final. Quando vários agentes acreditam ser o aprovador, surgem decisões paralelas. Quando nenhum agente assume a autoridade, documentos permanecem indefinidos ou são liberados por decurso de prazo.

Exemplo de matriz RACI por fase

A matriz abaixo é conceitual. A configuração real depende do modelo contratual, das delegações e da estrutura do proprietário.

Atividade	Proprietário	OE	Projetista	Gerenciadora	EPC/Executor	CxA	Operação
aprovar objetivos e OPR	A	R/C	C	I	I	C	C
desenvolver Basis of Design	C	C	R/A	I	C	C	C
aprovar arquitetura conceitual	A	R/C	R	C	I	C	C
elaborar projeto executivo	I	C	R/A	C	C	C	C
revisar projeto contra requisitos	A	R	C	I	I	C	C
elaborar RFP técnica	A	R	C	C	I	C	C
responder proposta e desvios	I	C	C	I	R/A	I	I
equalizar propostas	A	R	C	C	I	C	C
aprovar submittal	A ou delegado	R/C	C	I	R	C	C
executar construção	I	C	C	C	R/A	I	I
fiscalizar execução	A	R ou C	C	C/R	R	I	I
elaborar procedimentos de teste	I	C	C	I	R	A/R	C
aprovar critérios de aceite	A	R/C	C	I	C	R/C	C
executar FAT e SAT	I	C	C	I	R	A/R	C
decidir sobre risco residual	A	R/C	C	C	I	C	C
aceitar tecnicamente o sistema	A	R/C	C	I	I	C	C
assumir operação	A	C	I	I	C	C	R

A matriz não deve ser copiada mecanicamente. Em alguns empreendimentos, o projetista principal aprova submittals; em outros, essa autoridade permanece com o proprietário. A autoridade de comissionamento pode ser contratada pelo proprietário ou integrar outra estrutura, desde que sua independência e seus limites estejam claros.

Matriz de autoridade decisória

A RACI explica participação, mas decisões críticas exigem também limites de autoridade.

Decisão	Recomendação do OE	Autoridade final típica
alterar capacidade de TIC	análise de impacto e cenários	proprietário
aceitar redução de redundância	parecer de risco e operação	proprietário
aprovar equivalência técnica	análise de conformidade	proprietário ou delegado
aceitar desvio sem impacto funcional	recomendação documentada	OE, se formalmente delegado
alterar cronograma de energização	análise técnica e interfaces	direção do projeto
utilizar contingência temporária	análise de risco e controles	proprietário e operação
aceitar pendência menor	classificação e recomendação	autoridade definida no plano
aceitar risco residual crítico	parecer e condicionantes	proprietário
rejeitar entrega sem evidência	recomendação técnica	autoridade contratual

A delegação precisa estabelecer limites por valor, criticidade, disciplina, tipo de documento e impacto. Sem isso, o OE pode ser cobrado por decisões que não possuía autoridade para tomar ou, no sentido oposto, pode aprovar alterações que deveriam permanecer com o proprietário.

Responsabilidades na viabilidade e na seleção do site

Na fase de estudo de viabilidade de Data Center, o OE ajuda a estruturar critérios, evidências e condicionantes. Sua atuação pode incluir revisão de capacidade elétrica, conectividade, expansão, riscos do terreno, licenciamento, água, climatização, cronograma e alternativas de implantação.

O papel não é apenas produzir uma pontuação de sites. O OE deve identificar quais informações ainda são hipóteses, quais dependem de compromisso de concessionárias ou operadoras e quais condições precisam ser resolvidas antes da aquisição ou do investimento.

Entregáveis possíveis:

Entregável	Função
matriz de critérios e pesos	comparar alternativas de forma rastreável
registro de evidências	separar dados confirmados, declarações e premissas
matriz de riscos	registrar impacto, responsável e tratamento
parecer de alternativas	recomendar avanço, condicionamento ou descarte
condições precedentes	estabelecer o que precisa ser comprovado antes do compromisso
gate de decisão	apoiar decisão Go, Hold ou No-Go

O artigo Como escolher a localização de um Data Center aprofunda a seleção geográfica e imobiliária. Neste artigo, a seleção aparece apenas como uma fase da governança do OE.

Responsabilidades sobre OPR, URS e Basis of Design

O proprietário deve possuir requisitos claros antes que a equipe de projeto consolide a solução. O artigo sobre Basis of Design, OPR e URS explica a função de cada documento.

O OE pode facilitar workshops, estruturar requisitos, organizar conflitos e manter a rastreabilidade. Entretanto:

• o proprietário aprova objetivos, prioridades e riscos;
• os usuários e operadores fornecem necessidades funcionais;
• os projetistas documentam a resposta técnica no BoD;
• o OE verifica consistência, completude, rastreabilidade e impacto;
• a autoridade de comissionamento utiliza os requisitos para planejar verificações.

Uma das responsabilidades mais importantes é impedir que requisitos sejam alterados informalmente para acomodar uma solução já adquirida. Quando uma decisão de projeto exige mudança no OPR, a alteração precisa passar por análise de impacto e aprovação do proprietário.

Responsabilidades na fase de projeto

O artigo Como projetar um Data Center apresenta as fases, disciplinas e entregáveis do projeto. O OE não precisa reproduzir o trabalho do projetista; precisa verificar se a evolução documental preserva os requisitos do empreendimento.

Revisão de projeto

A revisão deve considerar:

• capacidade nominal, disponível e utilizável;
• arquitetura elétrica e caminhos A/B;
• redundância e modos comuns de falha;
• estados normal, manutenção, falha, emergência e retorno;
• manutenibilidade e substituição de ativos;
• segregação física e funcional;
• instrumentação e testabilidade;
• expansão e estados temporários;
• integração entre elétrica, HVAC, automação, incêndio e segurança;
• condições para operação e recuperação.

Uma revisão de OE não deve se limitar a marcar comentários em desenhos. Ela precisa relacionar cada observação ao requisito, risco, interface ou critério de verificação correspondente.

Construtibilidade

O projeto pode estar correto em cálculo e inviável em campo. A revisão de construtibilidade considera acessos, transporte, içamento, sequência, áreas de montagem, rotas temporárias, interferências, drenagem, conexões, substituição futura e coexistência com áreas ativas.

Operabilidade

O OE deve envolver a operação para verificar se manobras, isolamentos, bypasses, alarmes, intertravamentos e procedimentos podem ser executados com clareza e segurança.

Testabilidade

Pontos de medição, conexões temporárias, cargas de teste, simulações, controles, registros e segurança dos ensaios precisam ser previstos antes da construção. Um sistema impossível de testar tende a produzir aceite baseado em presunção.

Interfaces técnicas que o OE precisa governar

Energia e climatização

A carga elétrica de TIC converte-se quase integralmente em carga térmica. Alterações em densidade, UPS, distribuição ou expansão afetam climatização, espaço, peso, autonomia, cabos, proteções e controles. O OE verifica se as premissas são comuns entre disciplinas.

Energia e automação

Transferências, estados de UPS, geradores, disjuntores, medição e alarmes precisam chegar ao EPMS ou BMS com prioridades, timestamps, permissões e lógica coerentes. A fronteira entre fabricante, integrador e operador deve ser explícita.

Climatização e controles

Setpoints, sensores, estágios, falhas, redundância, válvulas, bombas, ventiladores e estratégias de contenção precisam funcionar em conjunto. A simples disponibilidade dos equipamentos não demonstra controle térmico adequado.

Telecomunicações e energia

Caminhos de fibra, MMRs, racks, alimentação A/B, aterramento, identificação e segregação precisam manter diversidade real. Rotas diferentes em desenho podem compartilhar um mesmo shaft, sala ou ponto de entrada.

Incêndio, HVAC e energia

Detecção, alarme, desligamentos, dampers, pressurização, ventilação, liberação de agentes e procedimentos de emergência possuem interações críticas. A matriz de causa e efeito deve ser compatível com sequências elétricas e mecânicas.

Segurança física e operação

Controle de acesso, CFTV, credenciais, intertravamentos, visitantes e emergência precisam permitir operação, manutenção e evacuação sem eliminar a proteção por camadas.

DCIM, BMS e EPMS

A governança deve definir qual plataforma é fonte de cada dado, como os sistemas trocam informações, quais alarmes são operacionais, como ocorre sincronismo de tempo e como os dados serão entregues ao proprietário.

Matriz de interfaces entre pacotes

Interface	Pacote A	Pacote B	Pergunta que precisa ser respondida
alimentação do chiller	elétrica	HVAC	quem fornece cabos, proteção, partida e sinais?
comunicação da UPS	UPS	EPMS/DCIM	protocolo, gateway, pontos, teste e responsabilidade?
desligamento por incêndio	incêndio	elétrica/HVAC	quais cargas desligam, em qual sequência e sob qual autoridade?
alimentação A/B dos racks	elétrica	racks/TI	conectores, balanceamento, identificação e limite de carga?
entrada de operadoras	telecom	civil/segurança	rotas, selagem, acesso e diversidade física?
contenção de corredor	arquitetura	HVAC/TI	responsabilidade por geometria, portas, sensores e desempenho?
combustível	geradores	civil/operação	armazenamento, transferência, autonomia, acesso e testes?
dados de medição	elétrica/HVAC	DCIM	precisão, protocolo, cadastro, retenção e ownership?

O OE deve manter a matriz viva. Uma interface “resolvida” em reunião só pode ser encerrada quando estiver incorporada aos documentos, contratos, instalação e testes aplicáveis.

Responsabilidades na RFP e no procurement

A RFP para Data Center transforma requisitos em uma base comparável para o mercado. O OE pode coordenar ou revisar:

• objeto e limites do pacote;
• requisitos funcionais e técnicos;
• documentos de entrada;
• matriz de responsabilidades;
• matriz de conformidade e desvios;
• entregáveis de projeto e fabricação;
• critérios de qualificação;
• estrutura de preços e opcionais;
• cronograma e long lead items;
• FAT, SAT, testes integrados e aceite;
• documentação, treinamento, garantia e suporte.

Equalização de propostas

O OE deve separar atendimento integral, atendimento condicionado, alternativa e desvio. A análise precisa considerar escopo, capacidade, arquitetura, ciclo de vida, riscos, cronograma, testes, documentação e custo total — não apenas o valor apresentado.

Alternativas técnicas

A RFP pode permitir alternativas, mas o fornecedor deve apresentar também uma proposta-base aderente. A alternativa precisa demonstrar impacto sobre capacidade, disponibilidade, manutenção, expansão, operação, prazo, custo e comissionamento.

Conflito de interesse

Quando a mesma empresa elabora a especificação, fornece o equipamento e valida sua conformidade sem revisão independente, surge risco de conflito de interesse. O modelo contratual deve separar adequadamente autoria, recomendação, decisão e verificação.

Submittals, shop drawings e documentos de fornecedores

O OE deve participar do fluxo de documentos de acordo com sua autoridade. Um submittal típico pode passar por:

1. verificação formal de completude; 2. análise do projetista responsável; 3. revisão do OE contra requisitos e interfaces; 4. consulta à operação ou comissionamento quando aplicável; 5. decisão pela autoridade definida; 6. registro de condicionantes e desvios; 7. incorporação ao projeto, fabricação e as built; 8. encerramento após evidência de atendimento.

Status genéricos como “aprovado com comentários” precisam possuir significado contratual. Deve estar claro se o fornecedor pode fabricar, quais comentários são obrigatórios, quem verifica sua incorporação e quando o documento é considerado encerrado.

O OE não deve alterar diretamente o documento do fornecedor e assumir sua autoria. Comentários, respostas e revisões precisam preservar rastreabilidade.

RFIs e esclarecimentos técnicos

RFIs são instrumentos para resolver dúvidas ou inconsistências. Elas não devem se transformar em canal informal de mudança de escopo.

Cada RFI relevante deve identificar:

• documento e requisito afetado;
• dúvida ou conflito;
• proposta do solicitante;
• impacto em outras disciplinas;
• efeito sobre prazo, custo e testes;
• decisão e autoridade;
• documentos que precisam ser atualizados.

Uma resposta rápida, mas incompleta, pode gerar consequências em várias interfaces. O OE avalia o efeito sistêmico antes de recomendar a decisão.

Gestão de mudanças e desvios

Alterações em Data Centers podem afetar disponibilidade, capacidade, eficiência, manutenção e segurança. Uma mudança aparentemente simples — substituir um disjuntor, alterar uma válvula, mover um rack ou trocar um gateway — pode modificar seletividade, sequência, acesso, medição ou testes.

O processo recomendado é:

1. registrar a origem e a justificativa; 2. identificar requisitos, documentos e contratos afetados; 3. analisar alternativas; 4. avaliar impacto técnico multidisciplinar; 5. avaliar prazo, custo, risco e operação; 6. definir testes e evidências adicionais; 7. submeter à autoridade correspondente; 8. atualizar baselines e comunicar as partes; 9. verificar implantação e encerrar a mudança.

O OE deve distinguir mudança aprovada, desvio temporário, não conformidade e concessão. Esses termos possuem efeitos diferentes sobre correção, prazo, aceite e risco residual.

Responsabilidades durante a construção

O acompanhamento de campo do OE deve ser planejado por risco. Não é necessário observar cada atividade continuamente; é necessário definir pontos de inspeção, hold points, witness points, amostragem e evidências adequadas à criticidade.

Planos de inspeção e teste

Os ITPs precisam indicar atividade, requisito, método, responsável, critério, registro e ponto de intervenção. O OE revisa se a sequência de inspeção é suficiente para impedir que serviços críticos sejam ocultados antes da verificação.

Não conformidades

Uma NCR deve registrar condição observada, requisito violado, evidência, criticidade, ação proposta, responsável, prazo, verificação da correção e impacto residual. Fechar a NCR apenas porque o serviço foi retrabalhado não basta; é necessário verificar a eficácia.

Medição e marcos de pagamento

O OE pode fornecer evidência técnica para medição, retenção ou liberação de marcos, mas a autoridade financeira e contratual permanece com o proprietário. O critério deve estar definido antes da execução.

Segurança e método executivo

O OE pode revisar impactos técnicos e interfaces de métodos executivos, mas a responsabilidade por segurança do trabalho e planejamento da execução permanece com a contratada, conforme legislação e contrato.

Expansão em Data Center operacional

Em ambientes ativos, o risco não está somente no resultado final. Estados temporários durante a obra podem reduzir redundância, eliminar caminhos, alterar alarmes ou expor cargas a uma falha única.

O OE deve governar:

• segregação entre áreas ativas e construção;
• capacidade disponível durante cada fase;
• estados temporários e risco residual;
• MOPs, SOPs e EOPs aplicáveis;
• janelas e critérios de autorização;
• contingências e rollback;
• monitoramento reforçado;
• prontidão de equipe e fornecedores;
• testes antes, durante e depois da intervenção;
• atualização imediata da documentação.

O artigo futuro sobre modernização sem interromper a operação aprofundará o método de intervenção. Aqui, o tema é tratado como responsabilidade específica de governança do OE.

Relação com o comissionamento

O OE e a autoridade de comissionamento trabalham sobre a mesma cadeia de requisitos, mas possuem perspectivas diferentes.

Aspecto	Owner’s Engineering	Autoridade de comissionamento
interesse representado	proprietário e investimento	processo independente de verificação
foco	governança, decisões, interfaces, riscos e aceite	planejamento e execução das verificações
início ideal	viabilidade e requisitos	pré-projeto, junto ao OPR
projeto	revisa aderência e riscos	revisa com foco em comissionabilidade
construção	acompanha conformidade e mudanças	verifica prontidão e documentação
testes	avalia evidências e impacto no aceite	coordena procedimentos, execução e issues
decisão final	recomenda ao proprietário	reporta resultados e pendências

A separação não significa isolamento. O OE deve assegurar que requisitos de comissionamento estejam nas RFPs, contratos, submittals, cronogramas e métodos executivos.

FAT, SAT e testes integrados

FAT

O Factory Acceptance Test verifica funções, fabricação, lógica, comunicação e desempenho que podem ser demonstrados antes do envio. O OE participa da definição de escopo, testemunho, tratamento de pendências e autorização de embarque conforme a governança.

SAT

O Site Acceptance Test confirma instalação, configuração, conexões, proteções, comunicação e funções no ambiente real. O fato de o equipamento ter passado no FAT não elimina verificações de campo.

Testes funcionais

Os testes funcionais demonstram comportamento de sistemas em modos normais, manutenção, falha e emergência. Procedimentos devem citar requisitos, pré-condições, instrumentos, passos, critérios e evidências.

IST

Os testes integrados simulam interações entre sistemas: perda de concessionária, partida de geradores, transferência de UPS, falha de climatização, perda de comunicação, incêndio, estados degradados e retorno à condição normal.

O OE avalia se os resultados sustentam a recomendação de aceite e se pendências ou exceções foram corretamente classificadas.

Aceite técnico e risco residual

Aceite não significa ausência absoluta de pendências. Significa que a autoridade competente avaliou evidências, pendências, restrições e riscos e decidiu conforme critérios previamente estabelecidos.

Uma classificação prática pode considerar:

Classe	Condição	Efeito típico
crítica	compromete segurança, função essencial ou disponibilidade	impede energização, operação ou aceite
maior	afeta desempenho, redundância, manutenção ou documentação essencial	exige correção ou decisão formal antes do marco
menor	não compromete função principal e possui tratamento controlado	pode permanecer em punch list com prazo
documental	evidência ou registro incompleto	aceite condicionado conforme impacto

O OE deve recomendar a decisão, mas riscos relevantes precisam ser aceitos pelo proprietário. Nenhum parecer técnico deve esconder que determinado requisito não foi demonstrado.

Handover e prontidão operacional

A entrega física não representa prontidão operacional. O handover precisa reunir:

• requisitos vigentes e Basis of Design final;
• as built, diagramas e listas de ativos;
• configurações, backups e licenças;
• relatórios de testes e pendências;
• manuais e planos de manutenção;
• peças, ferramentas e contratos de suporte;
• SOPs, MOPs e EOPs;
• matriz de alarmes e escalonamento;
• treinamento e registros de competência;
• limites, riscos residuais e recomendações.

O OE verifica completude e consistência, mas a operação deve confirmar que consegue assumir o ativo. A aceitação precisa incluir pessoas, processos, dados e suporte, não apenas equipamentos.

Principais entregáveis do OE em Data Centers

Fase	Entregáveis possíveis
viabilidade	matriz de critérios, riscos, condicionantes e parecer de alternativas
requisitos	OPR/URS estruturados, matriz de rastreabilidade e decisões
projeto	pareceres, design review, matriz de interfaces e construtibilidade
contratação	RFP, matriz de conformidade, equalização e recomendação técnica
fabricação	revisão de submittals, plano de inspeção, FAT e diligenciamento
construção	relatórios, NCRs, RFIs, mudanças, hold points e evidências
comissionamento	requisitos, revisão de procedimentos, issues log e pareceres
aceite	matriz de pendências, risco residual e recomendação de aceite
handover	checklist de prontidão, documentação consolidada e baseline operacional

O contrato não deve listar apenas nomes genéricos de relatórios. Cada entregável precisa possuir finalidade, conteúdo mínimo, periodicidade, responsável, prazo e critério de aceite.

Registros e controles mínimos

Uma estrutura de OE precisa manter, conforme aplicabilidade:

• registro de requisitos;
• matriz de rastreabilidade;
• registro de decisões;
• registro de riscos;
• matriz de interfaces;
• matriz RACI;
• lista mestra de documentos;
• log de submittals;
• log de RFIs;
• log de mudanças;
• registro de não conformidades;
• issues log de comissionamento;
• matriz de pendências;
• registro de risco residual;
• dashboard de prontidão.

Esses controles podem estar integrados em plataforma digital. O objetivo não é multiplicar planilhas, mas preservar uma fonte confiável de status, decisão e evidência.

Indicadores para medir a atuação do OE

A quantidade de comentários emitidos não mede qualidade. Um OE pode gerar milhares de observações superficiais e não identificar uma interface crítica.

Indicadores mais úteis incluem:

Indicador	Interpretação
requisitos sem resposta	lacunas entre OPR e projeto
interfaces abertas por fase	risco de integração ainda não resolvido
submittals vencidos	pressão sobre fabricação e cronograma
mudanças com impacto não avaliado	fragilidade de governança
NCRs críticas abertas	risco para energização ou aceite
testes aprovados na primeira execução	maturidade de projeto e instalação
pendências por criticidade	prontidão real do sistema
documentos de handover aceitos	preparação para operação
decisões aguardando proprietário	gargalo de autoridade
riscos residuais sem aceite	impedimento de encerramento responsável

Indicadores precisam ser analisados em contexto. Redução rápida de pendências pode representar correção efetiva ou simples reclassificação inadequada.

Como dimensionar a equipe de Owner’s Engineering?

O dimensionamento depende de porte, fases, modelo contratual, criticidade, dispersão geográfica, quantidade de pacotes e capacidade interna do proprietário.

Núcleo permanente

Pode incluir gerente de OE, coordenador técnico, controle documental e interfaces com planejamento, contratos e operação.

Especialistas por disciplina

Elétrica, mecânica, telecomunicações, automação, segurança, incêndio, civil, arquitetura, comissionamento e operação podem atuar conforme marcos e riscos.

Presença de campo

A cobertura pode variar entre visitas por hold point, equipe residente ou modelo híbrido. Presença contínua sem método não substitui especialistas nos momentos críticos.

Independência

A equipe deve declarar conflitos de interesse e separar revisão independente de atividades em que participou como autora. Quando a A3A Engenharia desenvolve também projetos ou estudos, a governança deve definir revisores distintos ou mecanismos de verificação adequados.

Quando contratar o OE?

O momento ideal é antes da consolidação dos requisitos e das principais contratações. A entrada tardia reduz a capacidade de prevenir problemas e concentra a atuação em identificar desvios já incorporados.

Momento de contratação	Capacidade de atuação
viabilidade	influencia critérios, riscos, site e estratégia
requisitos	organiza OPR, URS, BoD e governança
projeto conceitual	compara arquiteturas e define interfaces
projeto básico	qualifica RFPs e critérios de contratação
projeto executivo	revisa detalhes, construtibilidade e testabilidade
construção	controla conformidade, mudanças e interfaces
comissionamento	avalia evidências e pendências, mas corrige menos causas
pós-obra	realiza auditoria, diagnóstico e recomissionamento

Contratar durante a construção ainda pode gerar valor, especialmente em projetos com dificuldades. Entretanto, o escopo deve reconhecer que várias decisões já estarão contratualizadas.

Como estruturar o contrato do OE?

O escopo deve definir:

1. objetivos da atuação; 2. fases e pacotes abrangidos; 3. responsabilidades e exclusões; 4. autoridade e delegações; 5. disciplinas e disponibilidade da equipe; 6. entregáveis e periodicidade; 7. fluxos de documentos e prazos de resposta; 8. participação em reuniões, inspeções e testes; 9. critérios de medição e aceite; 10. tratamento de conflitos de interesse; 11. propriedade e retenção dos registros; 12. limites de responsabilidade profissional.

O contrato deve evitar expressões como “garantir o desempenho do Data Center” quando o OE não controla projeto, fabricação, instalação e operação. A obrigação deve ser definida em termos de diligência técnica, revisão, verificação, recomendação e evidência, conforme o escopo.

Erros comuns

Erro	Consequência
contratar o OE apenas para visitar a obra	requisitos e contratos permanecem sem governança
não definir autoridade	decisões ficam paralisadas ou contraditórias
confundir revisão com autoria	responsabilidade técnica torna-se ambígua
usar matriz RACI genérica	atividades críticas permanecem sem responsável real
não envolver operação	solução é entregue sem procedimentos e competência
deixar comissionamento para o fim	sistemas não são projetados para teste
aprovar submittals sem analisar interfaces	equipamentos incompatíveis avançam para fabricação
permitir mudanças por e-mail informal	baseline e contratos perdem coerência
medir o OE por quantidade de relatórios	incentivo à burocracia sem valor técnico
não registrar risco residual	aceite ocorre sem decisão consciente do proprietário
manter o OE subordinado ao executor	independência e representação do proprietário são comprometidas
não atualizar as built e BoD	operação recebe documentação histórica e inconsistente

Checklist executivo

1. O artigo geral de Owner’s Engineering continua sendo a referência conceitual do cluster? 2. O novo escopo está explicitamente limitado a Data Centers? 3. O proprietário definiu objetivos, capacidade, disponibilidade e risco? 4. Existe autoridade formal para aprovar requisitos e mudanças? 5. A matriz RACI possui um accountable claro por atividade? 6. Projetistas, fornecedores e executores mantêm suas responsabilidades técnicas? 7. O OE possui independência suficiente para emitir pareceres? 8. OPR, URS e BoD possuem baselines e rastreabilidade? 9. As interfaces entre energia, HVAC, telecom, automação, incêndio e segurança estão registradas? 10. RFPs exigem matriz de conformidade e declaração de desvios? 11. Submittals possuem fluxo, prazo, status e condição de encerramento? 12. RFIs não estão sendo usadas como mudanças informais? 13. Mudanças possuem análise multidisciplinar de impacto? 14. ITPs, hold points e witness points foram definidos por risco? 15. Estados temporários de expansão em ambiente ativo foram avaliados? 16. FAT, SAT, testes funcionais e IST citam requisitos verificáveis? 17. Pendências possuem criticidade, responsável, prazo e impacto no aceite? 18. Riscos residuais serão decididos pelo proprietário? 19. Documentação, procedimentos e treinamento fazem parte do handover? 20. A operação confirmou prontidão para assumir o ativo?

Escopo de engenharia consultiva da A3A Engenharia

A A3A Engenharia atua em Owner’s Engineering para Data Centers desde a estruturação de requisitos e governança até implantação, comissionamento e aceite. O escopo pode ser adaptado a Data Centers corporativos, colocation, Edge, Micro Data Centers, instalações modulares, expansões, modernizações e ambientes de alta criticidade.

A atuação pode incluir matriz RACI, OPR e URS, revisão do Basis of Design, design reviews, RFPs, equalização técnica, matriz de interfaces, análise de submittals, fiscalização orientada por risco, controle de mudanças, acompanhamento de FAT e SAT, governança de testes integrados, prontidão operacional e recomendação de aceite.

O serviço especializado está apresentado em Owner’s Engineering para Data Centers. Ele pode ser integrado ao Projeto de Data Center, ao Estudo de Viabilidade e ao Comissionamento e Aceite.

Resumo técnico

O Owner’s Engineering em Data Centers é uma função de governança técnica aplicada a um empreendimento multidisciplinar e crítico. Ele representa o proprietário, organiza requisitos, revisa decisões, controla interfaces, avalia mudanças e consolida evidências para aceite.

Seu valor não está em substituir projetistas, executores, gerenciadoras, comissionamento ou operação. Está em manter esses agentes alinhados a uma baseline comum, com responsabilidades, autoridades e limites explícitos.

A matriz RACI ajuda a identificar participação, mas precisa ser complementada por delegações, fluxos de aprovação e critérios de decisão. O OE recomenda e, quando formalmente autorizado, pode aprovar dentro de limites; riscos relevantes, mudanças estratégicas e aceite final permanecem sob autoridade do proprietário.

Quando contratado desde a viabilidade e os requisitos, o OE atua preventivamente. Quando contratado apenas durante a obra, ainda pode controlar desvios e evidências, mas encontra menor espaço para corrigir decisões já incorporadas aos contratos e equipamentos.

Referências técnicas

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 22237-1:2021 — Information technology — Data centre facilities and infrastructures — Part 1: General concepts. Geneva: ISO, 2021.

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC TS 22237-7:2018 — Information technology — Data centre facilities and infrastructures — Part 7: Management and operational information. Geneva: ISO, 2018.

[3] TELECOMMUNICATIONS INDUSTRY ASSOCIATION. ANSI/TIA-942-C — Telecommunications Infrastructure Standard for Data Centers. Arlington: TIA, 2024.

[4] ASHRAE; IES. ANSI/ASHRAE/IES Standard 202-2024 — The Commissioning Process Requirements for New Buildings and New Systems. Atlanta: ASHRAE, 2024.

[5] ASHRAE. Guideline 0-2019 — The Commissioning Process. Atlanta: ASHRAE, 2019.

[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020.

[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018.

[8] FIDIC. Conditions of Contract for EPC/Turnkey Projects. Silver Book. 2. ed. Geneva: International Federation of Consulting Engineers, 2017.

[9] INTERNATIONAL ATOMIC ENERGY AGENCY. Role of the Owner’s Engineer in Project Development and Management. Vienna: IAEA, 2014.

[10] A3A ENGENHARIA. Owner’s Engineering: governança técnica para obras de engenharia, sistemas críticos e integração multidisciplinar. Ponta Grossa: A3A Engenharia.

[11] A3A ENGENHARIA. Basis of Design, OPR e URS em projetos de Data Center. Ponta Grossa: A3A Engenharia.

[12] A3A ENGENHARIA. RFP para Data Center: o que é, como elaborar e quais requisitos incluir. Ponta Grossa: A3A Engenharia.

Perguntas frequentes

O que faz o Owner’s Engineering em um Data Center?

Representa tecnicamente o proprietário, preserva requisitos, revisa projetos e propostas, controla interfaces e mudanças, acompanha evidências e recomenda decisões de implantação, comissionamento e aceite.

O Owner’s Engineering substitui o projetista?

Não. O projetista continua responsável pelas soluções e documentos sob sua autoria. O OE revisa aderência aos requisitos, riscos e interfaces, sem assumir automaticamente a responsabilidade de projeto.

Qual é a diferença entre OE e fiscalização de obra?

A fiscalização concentra-se na execução e conformidade de campo. O OE possui escopo mais amplo de governança técnica, podendo atuar desde requisitos, projeto e contratação até testes, aceite e handover.

Qual é a diferença entre OE e autoridade de comissionamento?

O OE representa os interesses do proprietário e governa requisitos, riscos e decisões. A autoridade de comissionamento coordena o processo de verificação, procedimentos, testes, issues e relatórios.

O que é uma matriz RACI em projetos de Data Center?

É a matriz que identifica quem executa, quem possui autoridade final, quem deve ser consultado e quem precisa ser informado em cada atividade, documento ou decisão.

Quem aprova mudanças técnicas no Data Center?

Depende da delegação formal. O OE pode analisar e recomendar, ou aprovar dentro de limites autorizados. Mudanças estratégicas e riscos relevantes normalmente permanecem sob autoridade do proprietário.

Quando contratar Owner’s Engineering para Data Center?

Preferencialmente antes da consolidação dos requisitos e das principais RFPs. A contratação precoce permite atuação preventiva sobre arquitetura, interfaces, riscos, contratos e critérios de aceite.

O OE pode atuar em contratos EPC e EPCM?

Sim. Em EPC, protege os requisitos do proprietário perante a entrega integrada. Em EPCM ou pacotes separados, ajuda a governar múltiplas interfaces, responsabilidades e fornecedores.

Quais são os principais entregáveis do OE?

Matrizes de requisitos, riscos, RACI e interfaces; pareceres de projeto; RFPs e equalizações; revisões de submittals; relatórios de campo; controle de mudanças; evidências de testes; pendências e recomendação de aceite.

O OE garante que o Data Center não terá falhas?

Não. O OE reduz riscos por meio de governança, revisão e verificação, mas não controla sozinho projeto, fabricação, construção, operação e eventos externos. As responsabilidades devem ser definidas contratualmente.

Materiais técnicos complementares

• 1. Conceito geral e aplicação especializada
  • Owner’s Engineering: governança técnica para obras e sistemas críticos
  • Owner’s Engineering para Data Centers
  • Engenharia Integrada para Data Centers
• 2. Requisitos, viabilidade e decisões iniciais
  • Basis of Design, OPR e URS em projetos de Data Center
  • Estudo de viabilidade de Data Center
  • Como escolher a localização de um Data Center
• 3. Projeto, RFP e contratação
  • Como projetar um Data Center
  • RFP para Data Center
  • Projeto de Data Center
• 4. Comissionamento, testes e aceite
  • Comissionamento e Aceite de Data Centers
  • FAT, SAT e Testes Integrados em Sistemas Críticos
  • Critérios de Aceite em Engenharia
• 5. Arquiteturas e modelos de Data Center
  • Tier I, II, III e IV em Data Centers
  • Data Center modular
  • Edge Data Center
  • Micro Data Center
• 6. Infraestrutura crítica e interfaces
  • Energia para Infraestrutura Crítica
  • Climatização de Data Centers
  • Redes e Telecomunicações para Data Centers
  • DCIM
  • Segurança Física para Data Centers
  • Incêndio em Data Centers