AI na Diligência de Engenharia: Detectando Riscos de Cronograma, Custo e Confiabilidade antes da Assinatura

1. Use AI para ampliar o campo de evidências preservando a autoridade decisória

A diligência de engenharia é um exercício de conversão de evidências. O comprador recebe desenhos, cronogramas, relatórios de custos, históricos de manutenção, registros de inspeção, contratos, dados operacionais e explicações da administração. Cada fonte descreve uma parte diferente do ativo ou do projeto. A equipe da transação deve determinar quais registros estão atualizados, se são conciliáveis e como as condições identificadas afetam valor, caixa, conclusão e continuidade.

AI pode ampliar a quantidade de material revisado dentro do prazo da transação. Modelos de documentos podem classificar arquivos, extrair identificadores e conectar revisões. Modelos analíticos podem examinar redes de cronogramas, movimentações de custos e históricos de manutenção. Métodos estatísticos podem revelar agrupamentos incomuns de falhas, sobreposições repetidas ou progresso inconsistente. Essas capacidades melhoram a cobertura quando as evidências são controladas. Elas criam risco quando um resumo gerado perde a proveniência ou uma pontuação de anomalia é tratada como conclusão de engenharia.

O princípio operacional é a ampliação controlada. O sistema deve mostrar a fonte, a transformação, a versão do modelo, o resultado e o parecer do revisor para cada sinal material. O revisor de engenharia mantém a responsabilidade pela causalidade e pelo julgamento técnico. A equipe da transação mantém a responsabilidade pela avaliação, pela estrutura e pela negociação. O conselho ou o comitê de investimentos mantém seus direitos de decisão.

A Estrutura de Gestão de Riscos de AI do NIST organiza o risco de AI por meio das funções governar, mapear, medir e gerenciar.[3] Seu Perfil Generativo de AI acrescenta ações para riscos específicos de sistemas generativos.[4] A ISO/IEC 42001 fornece uma estrutura de sistema de gestão de AI que abrange políticas, objetivos, processos e melhoria contínua.[6] Essas estruturas sustentam um ambiente de diligência no qual velocidade, rastreabilidade, segurança e responsabilização são concebidos em conjunto.

O primeiro produto prático deve ser um registro de análises. Ele registra a pergunta, a população de evidências, o método, as limitações, o revisor, o limite de materialidade e o uso permitido na transação. Um modelo capaz de agrupar narrativas de manutenção pode apoiar a descoberta. Ele não deve determinar de forma independente a vida útil remanescente, a conformidade de segurança ou o preço de compra. O uso aprovado deve ser explícito antes que o modelo acesse dados confidenciais da empresa-alvo.

2. Definir a tese da transação e o perímetro de engenharia

O escopo da diligência deve partir da tese de valor. Um comprador que adquire uma empreiteira de engenharia pode se preocupar com a qualidade da carteira de pedidos, o custo para conclusão, os pleitos, a capacidade dos equipamentos e a dependência de pessoas-chave. Um comprador que adquire um ativo industrial pode se preocupar com integridade, confiabilidade, capex de manutenção, licenças e continuidade operacional. Um investidor de projeto pode se concentrar na conclusão, nos testes de desempenho, no risco de interface e nas indenizações pré-fixadas.

O perímetro de engenharia registra as entidades jurídicas, os locais, os projetos, as linhas de produção, as utilidades, os sistemas, os contratos e os períodos incluídos na análise. Ele também identifica exclusões. Um grupo pode compartilhar recursos de manutenção, software de engenharia, laboratórios, peças sobressalentes, salas de controle e propriedade intelectual entre locais. A equipe de diligência deve distinguir ativos transferidos na conclusão de serviços que exigem um acordo de transição.

O perímetro temporal é importante. Um extrato de manutenção de doze meses pode não captar um ciclo plurianual de parada geral. Um cronograma atual pode ocultar redefinições anteriores da linha de base. Uma melhoria recente de confiabilidade pode suceder um período anormal de parada. O plano de evidências deve abranger um período longo o suficiente para observar estados representativos de operação, construção e manutenção.

O perímetro decisório traduz a tese da transação em perguntas testáveis. O programa atual pode alcançar a conclusão mecânica dentro da previsão do vendedor? A contingência remanescente é adequada para o escopo conhecido e latente? O ativo instalado pode alcançar a produção e a disponibilidade assumidas na avaliação? Quais constatações exigem preço, depósito em garantia, retenção, uma condição de fechamento ou uma ação do proprietário com recursos provisionados?

O controle de escopo evita o desvio analítico. A equipe deve aprovar inclusões quando as evidências apontarem para um novo risco material. Também deve registrar perguntas adiadas para diligência confirmatória, assessoria especializada ou verificação pós-conclusão. Um registro de escopo visível preserva a distinção entre evidência incompleta e conclusão adversa.

3. Construir um mapa de dados do projeto antes de executar os modelos

O mapa de dados do projeto é a base da análise. Ele inventaria cada fonte, proprietário, sistema, data de extração, período, unidade, identificador, revisão, restrição de acesso e finalidade na transação. Ele abrange registros estruturados, como atividades do cronograma e ordens de serviço; registros semiestruturados, como folhas de inspeção; e registros não estruturados, como narrativas de progresso, correspondência e fotografias.

O diagrama mostra um caminho analítico controlado; os sistemas reais e os direitos de decisão dependem da transação.

Os identificadores criam o primeiro desafio de reconciliação. Uma bomba pode ter uma tag no registro de ativos, outra no sistema de manutenção e uma terceira no historiador de dados. Uma atividade de projeto pode usar um código de pacote diferente da conta de custo. O mapa de identidade deve preservar os identificadores originais e criar mapeamentos cruzados controlados em vez de sobrescrever os valores de origem.

A proveniência deve sobreviver a todas as transformações. Se um modelo converter ordens de serviço em texto livre em categorias de falha, o registro resultante deve vincular ao texto original e à regra de transformação. Se as datas forem padronizadas, o fuso horário e o carimbo de data/hora originais devem permanecer disponíveis. Se registros duplicados forem removidos, a regra de duplicidade e o registro retido devem ser documentados.

A ISO 55001:2024 reforça a ênfase na tomada de decisões, valor, risco, dados e ação preditiva na gestão de ativos.[7] A ISO 55013 aborda a gestão de ativos de dados em apoio aos objetivos de gestão de ativos.[8] Na diligência de transação, esses princípios se traduzem em um data room que pode apoiar tanto a análise antes da assinatura quanto a operação controlada após a conclusão.

Tabela 1. Registro de dados e controle da diligência de engenharia

Os controles exigidos dependem do tipo de ativo, do perímetro da transação e da materialidade.

4. Normalize as estruturas de trabalho, custo e equipamentos

A análise entre sistemas exige um grão analítico comum. Atividades de cronograma, contas de custo, contratos, tags de equipamentos e ordens de serviço de manutenção raramente compartilham uma única hierarquia. A equipe de diligência devida deve estabelecer um mapa controlado que conecte cada item a local, sistema, pacote de trabalho, parte responsável e questão da transação.

A estrutura analítica do trabalho deve representar entregáveis e escopo. A estrutura analítica organizacional mostra responsabilidade. A estrutura analítica de custos registra despesas. A hierarquia de equipamentos mostra relações físicas pai-filho. Seus propósitos diferem, portanto o modelo analítico deve conectá-las sem colapsá-las em uma única hierarquia artificial.

Unidades e calendários exigem a mesma disciplina. Dados de custo podem misturar moedas, valores nominais e reais e tratamentos tributários. Dados de cronograma podem usar semanas de trabalho, feriados e turnos diferentes. Dados de confiabilidade podem expressar tempo de operação em horas, ciclos, partidas ou toneladas de produção. A camada de normalização deve registrar cada conversão e reter os valores de origem.

O controle de versão é essencial porque as evidências da transação mudam durante a diligência devida. Uma previsão de conclusão revisada pode incorporar uma nova data do fornecedor. Um novo extrato de manutenção pode incluir ordens de serviço encerradas após a data de avaliação. Cada execução da análise deve identificar o snapshot da fonte e a data de vigência. Revisões relevantes devem ser comparadas com versões anteriores para mostrar quais premissas ou registros foram alterados.

A saída é uma tabela de reconciliação que mostra registros não conciliados, relacionamentos um-para-muitos e ambiguidades não resolvidas. Essas são constatações por si só. Uma conta de custo sem atividade no cronograma pode representar escopo não planejado. Uma atividade crítica do cronograma sem custo comprometido pode indicar uma previsão incompleta. Uma etiqueta de equipamento com falhas, mas sem registro no cadastro de ativos, pode indicar controle fraco sobre a base instalada.

5. Criar uma fila de anomalias em vez de um motor de conclusões

Uma anomalia é um sinal que merece investigação. Ela pode surgir de uma regra, modelo estatístico, teste de grafo, modelo de linguagem ou limite de engenharia. O sistema deve criar uma fila com o sinal, os registros de origem, o método, a confiança, a materialidade potencial e a decisão do revisor.

Falsos positivos são esperados. Um marco de duração zero pode ser válido. Um pico de custo pode refletir uma mobilização planejada. Alarmes repetidos de equipamento podem decorrer de uma falha de sensor, e não de degradação física. A revisão humana deve testar o contexto operacional e explicações alternativas antes que um sinal se torne um problema confirmado.

Falsos negativos também importam. Um modelo treinado em categorias históricas de manutenção pode não detectar um novo modo de falha. Dados esparsos de falhas podem fazer um ativo não confiável parecer estável. A administração pode ter alterado práticas de codificação após uma reorganização. O desenho da diligência devida deve combinar vários testes e manter amostragem manual para registros de altas consequências.

Volumes hipotéticos ilustram a disciplina do fluxo de trabalho; eles não descrevem uma transação.

Tabela 2. Classe de anomalia, validação e resposta permitida

Uma pontuação de modelo, por si só, não deve determinar uma conclusão de transação.

A fila deve registrar evidências de encerramento. Um sinal pode ser confirmado, rejeitado, mesclado, postergado ou deixado sem resolução. Sinais rejeitados devem permanecer na trilha de auditoria, porque falsos positivos repetidos podem revelar um modelo fraco ou um problema de dados. Sinais não resolvidos de alto impacto devem afetar a limitação de diligência devida, a proteção da transação ou o cronograma de decisão.

6. Teste a lógica do cronograma antes de aceitar datas de conclusão

Um cronograma é um modelo de trabalho, dependências, calendários e restrições. Sua data de término só é crível quando a rede subjacente é abrangente, logicamente conectada, sensível a recursos e atualizada com progresso confiável. O GAO Schedule Assessment Guide estabelece dez práticas para um cronograma confiável e de alta qualidade e relaciona o risco de cronograma ao custo do ciclo de vida.[1]

Testes automatizados podem identificar predecessores ou sucessores ausentes, defasagens excessivas, atividades longas, restrições rígidas, folga negativa, datas reais inválidas e caminhos críticos rompidos. A análise de grafos pode revelar agrupamentos desconectados e atividades cuja flexibilidade aparente depende de lógica incompleta. Esses testes devem ser calibrados ao padrão de planejamento e à fase do projeto.

A evidência de progresso exige revisão separada. O percentual concluído relatado pode ser subjetivo quando a atividade não tem uma regra mensurável. A equipe de diligência devida deve comparar o progresso com quantidades, marcos certificados, equipamentos instalados, desenhos aprovados, registros de testes, faturas e evidências de campo. Uma atividade não deve se tornar concluída apenas porque sua data de término planejada passou.

A redefinição da linha de base pode ocultar o histórico de desempenho. A equipe deve comparar as linhas de base atual e anterior, identificar marcos movidos, atividades adicionadas, escopo excluído, calendários alterados e lógica revisada. A análise deve distinguir mudança de escopo aprovada de premissas de recuperação e otimismo de cronograma.

Restrições de recursos podem invalidar uma rede logicamente sólida. Equipes críticas de engenharia, comissionamento ou especialistas podem estar programadas em atividades simultâneas. Datas de fornecedores e de licenças podem estar fora do arquivo nativo. A revisão do cronograma deve conectar a rede a evidências de compras, alocação de pessoal, acesso e interfaces.

7. Quantifique o risco de cronograma como uma distribuição e um mapa causal

Uma única data de previsão oculta a incerteza. A análise de risco de cronograma deve modelar a incerteza em durações, correlações, eventos discretos e ramificações condicionais. O resultado é uma distribuição de resultados de conclusão e um mapa dos fatores que os movem.

O modelo deve distinguir incerteza de contingência de gestão. Uma faixa de duração pode representar variabilidade ordinária. Um risco discreto pode representar atraso de licença, falha de equipamento durante testes ou inadimplência de fornecedor. Um plano de recuperação deve ser modelado como uma intervenção com premissas de custo, recursos e execução.

Pontuações hipotéticas ilustram apenas a priorização; avaliações reais exigem evidências de cronograma específicas do projeto.

O modelo da transação deve traduzir tempo em economia. O atraso pode ampliar custos do proprietário, juros durante a construção, aluguéis, garantias e capital de giro. Pode adiar receita, acionar indenizações pré-fixadas ou encurtar um período operacional contratado. Alguns impactos são não lineares porque uma janela sazonal perdida ou um marco de licença perdido pode causar uma mudança de patamar maior.

O questionamento da gestão deve se concentrar na cadeia causal. Se o comissionamento impulsiona a cauda, a equipe deve examinar procedimentos de teste, conclusão de sistemas, presença de fornecedores, peças de reposição e fechamento da lista de pendências. Se as compras impulsionam a cauda, deve examinar progresso de fabricação, transporte, alfândega, prontidão do local e fornecimento substituto. A distribuição do cronograma torna-se útil para a decisão quando cada fator tem evidências e um responsável pela mitigação.

8. Reconstruir o custo para conclusão a partir do escopo, compromissos e custos reais

O Guia de Estimativa e Avaliação de Custos do GAO enfatiza linhas de base técnicas, estruturas de decomposição do trabalho, premissas, dados, métodos de estimativa, sensibilidade, análise de riscos, documentação e atualizações com custos reais.[2] Essas práticas fornecem uma estrutura de controle útil para a diligência devida de transações, mesmo quando o projeto é financiado com capital privado.

O custo para conclusão deve começar pelo escopo remanescente, não pelo total previsto pelo vendedor. A equipe deve conciliar orçamento, custo real, compromissos, provisões, mudanças aprovadas, mudanças pendentes, pleitos, contingência e previsão. Ela deve identificar custos omitidos porque estão em outra entidade, contrato ou conta.

AI pode acelerar a classificação de faturas, o mapeamento de contratos para custos e a comparação de previsões narrativas com movimentações do razão. Pode sinalizar contas de custo cuja previsão restante está abaixo dos compromissos em aberto, pacotes de trabalho com progresso mas sem provisão, e compromissos sem atividades no cronograma. Cada sinal exige revisão contábil e de engenharia.

A contingência deve ser analisada por titularidade e risco. Contingência geral, provisão de projeto, escalonamento, variação cambial, crescimento de quantidades e reserva de cronograma respondem a perguntas diferentes. A contingência utilizada deve ser conciliada com riscos materializados. A contingência remanescente deve ser testada em relação ao registro de riscos atual e à maturidade do escopo.

A equipe deve distinguir custo afundado de exposição econômica futura. Gastos excessivos históricos podem indicar controles fracos, mas a decisão da transação depende do custo remanescente e da recuperabilidade. Um pleito do vendedor contra um empreiteiro só pode reduzir a exposição quando o direito, as evidências, a capacidade da contraparte e o prazo de recebimento o sustentarem.

9. Ler ordens de mudança e pleitos como um sistema

As ordens de mudança conectam escopo, cronograma, custo, direitos contratuais e caixa. Sua análise deve ir além do valor aprovado. A equipe de diligência devida deve mapear cada mudança para instrução, revisão de projeto, notificação, cotação, aprovação, trabalho executado, custo incorrido, efeito no cronograma, fatura e recebimento.

Modelos de linguagem podem extrair partes, datas, cláusulas, valores solicitados e causas declaradas de correspondências. O registro controlado deve manter o documento original e distinguir o texto extraído da interpretação jurídica. Privilégio legal, confidencialidade e orientação específica por jurisdição exigem tratamento explícito.

Causas repetidas podem revelar risco estrutural. Informações de projeto tardias podem gerar retrabalho em vários pacotes. Restrições de acesso podem criar interrupção cumulativa. Um fornecedor pode apresentar pleitos fragmentados para um único evento subjacente. O agrupamento pode ajudar a identificar esses padrões, seguido de revisão de engenharia e jurídica.

O modelo financeiro deve separar mudanças aprovadas, prováveis, disputadas e não submetidas. Reconhecimento de receita, provisão de custos, recebimento de caixa e direito jurídico podem divergir. Um ativo de pleito otimista pode inflar margem e capital de giro, criando exposição futura de financiamento.

As respostas da transação incluem ajuste de preço, indenização específica, depósito em garantia, retenção, suporte à conclusão, ativo excluído, condição precedente ou plano operacional revisado. A resposta deve seguir as evidências, a materialidade, a recuperabilidade e o controle da causa subjacente.

10. Conectar evidências de aquisições ao cronograma e ao desempenho

O risco de aquisições abrange especificação, capacidade do fornecedor, fabricação, qualidade, logística, alfândega, armazenamento, instalação e garantia. Um pedido de compra marcado como emitido não prova que o equipamento chegará, será integrado ou terá desempenho no prazo.

O mapa de dados deve conectar atividades do cronograma a requisições, pedidos de compra, desenhos de fornecedores, pontos de inspeção, status de fabricação, documentos de embarque e recebimento no local. A correspondência assistida por AI pode identificar elos ausentes e datas contraditórias. A inspeção física e a confirmação do fornecedor continuam necessárias para itens relevantes.

Equipamentos com prazo de entrega longo exigem evidências de congelamento do projeto, submissões aprovadas, slots de produção, pagamentos por progresso, planos de qualidade, testes em fábrica e prontidão para embarque. A dificuldade financeira do fornecedor pode criar exposição oculta mesmo quando o progresso de fabricação reportado é alto.

O risco de substituição é relevante quando um projeto assume equipamentos alternativos. A equipe deve testar equivalência técnica, certificação, interface, garantia, prazo de entrega e aprovação contratual. Um substituto de menor custo pode criar atraso no comissionamento ou custo de ciclo de vida que excede a economia na aquisição.

Os documentos da transação podem alocar riscos de aquisição identificados por meio de suporte à conclusão, covenants específicos, contraprestação retida ou condições de fechamento. O plano de responsabilidades do proprietário deve nomear a pessoa responsável pelo relacionamento com fornecedores e pelo fechamento de interfaces desde a assinatura até a conclusão.

11. Validar o comissionamento como um marco de evidências

O comissionamento converte equipamentos instalados em um sistema em operação. Conclusão mecânica, energização, testes funcionais, testes integrados, testes de desempenho e aceitação final são estados distintos. A diligência devida deve identificar as evidências e a autoridade exigidas para cada um.

Os resultados dos testes devem ser comparados com o regime de projeto, as garantias contratuais e as condições reais de operação. Um teste aprovado em carga parcial pode não sustentar a confiabilidade em plena carga. Um teste curto pode não revelar instabilidade térmica, de vibração ou de controle. Renúncias e itens de lista de pendências devem ser vinculados a risco e medida corretiva.

AI pode comparar folhas de teste, registros de alarmes e curvas de desempenho entre populações de equipamentos. Pode identificar sequências incomuns de falhas ou intervenções manuais repetidas. O revisor deve verificar a calibração dos sensores, os limites dos testes, a completude dos dados e o efeito da intervenção do operador.

O risco de interface frequentemente aparece durante os testes integrados. Equipamentos que passam isoladamente podem falhar quando conectados à energia, ao controle, aos utilitários ou às condições do processo a montante. A abordagem de engenharia de sistemas descrita no manual da NASA enfatiza requisitos, interfaces, verificação, validação e gestão técnica ao longo do ciclo de vida.[11]

A prontidão para o fechamento deve distinguir evidências disponíveis antes da assinatura, evidências esperadas antes da conclusão e evidências que só podem surgir durante a titularidade. Testes relevantes após a assinatura podem exigir uma condição, retenção, garantia, seguro ou plano de remediação financiado.

12. Construir análise de confiabilidade a partir de evidências de regime de operação, falhas e manutenção

Confiabilidade é a probabilidade de um item desempenhar sua função exigida sob condições declaradas por um período declarado. A diligência devida deve especificar a função, o contexto operacional, a demanda, a definição de falha e o período de observação antes de calcular uma taxa.

O histórico de falhas isoladamente pode enganar. Um número baixo de falhas pode refletir tempo de operação limitado, uso oculto em standby, ordens de serviço ausentes ou substituição recente. Um número alto pode refletir detecção agressiva e bom reporte. A análise deve conectar falhas à exposição, ao regime de operação, ao ambiente, à manutenção e à configuração.

Curvas hipotéticas demonstram sensibilidade; não são estimativas para um ativo identificado.

A população de equipamentos deve ser segmentada por projeto, idade, regime de operação e estado de modificação. Agrupar ativos não comparáveis pode ocultar uma coorte fraca. Observações censuradas e itens substituídos devem ser tratados explicitamente. Intervalos de confiança devem ser reportados quando a amostra for pequena.

A IEC 61508 trata da segurança funcional de sistemas elétricos, eletrônicos e eletrônicos programáveis relacionados à segurança.[10] Integridade de segurança, confiabilidade e disponibilidade são relacionadas, mas distintas. Uma revisão de transação deve preservar essas distinções e recorrer a especialização qualificada em segurança funcional quando relevante.

Tabela 3. Evidências de confiabilidade e interpretação da transação

A interpretação exige julgamento de engenharia específico do ativo e contexto operacional.

13. Converter o histórico de manutenção em necessidades futuras de caixa

A diligência de manutenção deve conciliar o trabalho planejado, o trabalho concluído, o trabalho em atraso, as avarias, as inspeções, os defeitos, as peças sobressalentes e a capacidade dos contratados. O objetivo é estimar o trabalho e o caixa necessários para preservar uma operação segura e confiável sob o plano do comprador.

Ordens de serviço em texto livre podem ser classificadas em modos de falha, causas e ações. O modelo deve preservar a incerteza quando a linguagem for ambígua. Códigos de sintoma repetidos podem representar uma única causa raiz não resolvida. Textos de encerramento como “testado, ok” podem não comprovar que um defeito foi eliminado.

O backlog deve ser segmentado por consequência de segurança, consequência de produção, requisito legal, criticidade do ativo, idade e janela de acesso. As estimativas monetárias devem incluir mão de obra, material, suporte especializado, parada e trabalhos decorrentes. O valor do backlog não é simplesmente a soma das estimativas de ordens de serviço, porque tarefas relacionadas podem se sobrepor ou exigir uma parada comum.

O trabalho de integridade de ativos do HSE destaca a necessidade de sistemas de manutenção que mantenham elementos críticos de segurança disponíveis e confiáveis quando necessário.[20] A diligência devida da transação deve testar se os regimes de inspeção e manutenção refletem os perigos atuais, os mecanismos de degradação e as condições operacionais.

O plano de propriedade deve distinguir manutenção de recuperação, manutenção recorrente e capital de melhoria. Trabalhos de recuperação podem afetar o preço ou a capacidade de endividamento. Trabalhos recorrentes pertencem ao fluxo de caixa em regime estável. O capital de melhoria exige um caso de negócio separado e não deve ser usado para ocultar o custo de restabelecer o controle básico.

14. Revisar tecnologia operacional e continuidade de dados

A análise de engenharia frequentemente depende de historiadores, controladores, sensores, plataformas de manutenção e acesso remoto de fornecedores. Esses sistemas afetam tanto a operação quanto as evidências usadas na diligência devida. Uma fragilidade cibernética ou de continuidade de dados pode, portanto, criar risco de segurança, produção e transação.

O NIST SP 800-82 Revisão 3 fornece orientação para proteger tecnologia operacional, reconhecendo requisitos de desempenho, confiabilidade e segurança.[9] O escopo da diligência devida deve mapear ativos, zonas, conduítes, acesso remoto, identidade, registro de logs, backups, aplicação de patches, sistemas sem suporte e resposta a incidentes.

Modelos AI devem receber o mínimo de dados necessários por meio de acesso controlado. A extração deve evitar interferir nos sistemas de produção. Coleta somente leitura, staging seguro, varredura de malware, criptografia e registros de acesso devem ser definidos. Dados sensíveis de processo e propriedade intelectual exigem controles contratuais e técnicos.

A equipe deve testar se os resultados analíticos podem ser reproduzidos após a conclusão. Software hospedado pelo vendedor, conectores proprietários ou mapeamentos de tags não documentados podem criar dependência. Os arranjos de transição devem abranger exportações da fonte, esquemas, configuração, credenciais, licenças e suporte especializado.

Achados cibernéticos devem ser vinculados à consequência operacional. Um caminho de acesso remoto vulnerável pode exigir fechamento antes da assinatura ou da conclusão. Um inventário de ativos fraco pode exigir um plano de remediação financiado. Um modelo não deve sondar ativamente sistemas de produção, a menos que o escopo, os controles de segurança e a autorização permitam expressamente.

15. Governar o risco de modelo e a revisão humana

O registro de modelos AI deve registrar finalidade, responsável, versão, dados, validação, limitações, acesso e uso aprovado. Ele deve distinguir regras determinísticas, modelos estatísticos e sistemas generativos, porque seus modos de falha diferem.

A validação deve testar acurácia, completude, robustez e reprodutibilidade com dados representativos da transação. Deve incluir positivos conhecidos, negativos conhecidos e casos limite difíceis. O desempenho deve ser avaliado na unidade relevante para a decisão, como atividade, ordem de serviço, tag de equipamento ou achado.

A revisão humana exige competência e independência adequadas à questão. Um engenheiro de planejamento deve revisar a lógica do cronograma. Um engenheiro de custos deve revisar a previsão e a contingência. Um especialista em confiabilidade deve revisar a análise de falhas. Conclusões jurídicas e contábeis devem permanecer com assessores qualificados.

O modelo deve expor a incerteza. A extração por modelo de linguagem pode incluir o trecho de origem e a confiança. Modelos de anomalia podem mostrar variáveis que contribuem para a pontuação. Testes de cronograma podem mostrar as atividades e os caminhos afetados. Resultados de caixa-preta sem evidências devem permanecer como auxílios à investigação.

A iniciativa de perfil de infraestrutura crítica do NIST AI RMF reconhece que o uso de AI em tecnologia da informação, tecnologia operacional e sistemas de controle industrial exige uma abordagem repetível de ciclo de vida para a confiabilidade.[5] A regulamentação e as obrigações contratuais dependem da jurisdição e do uso. A Lei AI da UE estabelece um marco legal para o desenvolvimento e uso de sistemas AI dentro de seu escopo.[16] Portanto, uma transação transfronteiriça deve mapear onde o modelo é desenvolvido, operado e usado.

16. Converter constatações confirmadas em avaliação e financiamento

Uma constatação de engenharia confirmada afeta o valor por meio de caixa, prazo, risco ou opcionalidade. O modelo deve mostrar o caminho causal. Um atraso no comissionamento pode prolongar os custos do proprietário e postergar a receita. A manutenção diferida pode exigir capital imediato e reduzir a disponibilidade. Uma fragilidade de confiabilidade pode aumentar os custos de peças de reposição, paradas e seguros.

A ponte de avaliação deve evitar a contagem dupla. Um aumento do custo para conclusão pode já reduzir o fluxo de caixa projetado. O mesmo risco não deve receber também um desconto de múltiplo separado, a menos que afete a incerteza residual ou a economia futura. Revisores de finanças e engenharia devem aprovar o tratamento em conjunto.

O caminho de decisão é ilustrativo; as medidas corretivas efetivas dependem de evidências, contrato e lei aplicável.

A capacidade de endividamento pode ser afetada por despesas de capital remanescentes, risco de conclusão, disponibilidade, caixa de manutenção, seguros e margem de covenant. O modelo de financiamento deve testar o momento da remediação e a parte que a financia. O suporte do vendedor só tem valor quando a obrigação, o montante, a duração e o crédito são críveis.

A IFRS 3 rege o reconhecimento e a mensuração de ativos e passivos em uma combinação de negócios e o goodwill resultante ou a compra vantajosa.[13] A IFRS 13 fornece uma estrutura para a mensuração pelo valor justo.[15] As constatações de engenharia devem ser comunicadas aos especialistas em contabilidade e avaliação com evidências suficientes para avaliar o reconhecimento, a mensuração e a divulgação.

Tabela 4. Constatação de engenharia para resposta econômica e de transação

O tratamento depende de materialidade, controle, contabilidade, contrato e evidências de recuperação.

17. Redigir proteções da transação a partir de evidências causais

A proteção da transação deve acompanhar o risco identificado e a parte mais capaz de controlá-lo ou absorvê-lo. Garantias genéricas podem ser frágeis quando a constatação diz respeito a um projeto, ativo ou limitação de dados específicos. O registro de diligência devida deve subsidiar a redação precisa por assessores jurídicos qualificados.

Uma condição de fechamento pode exigir a conclusão de um teste, a entrega de evidências, consentimento, licença ou remediação. Um ajuste de preço pode reconhecer uma lacuna de financiamento mensurável. Um depósito em garantia ou retenção pode garantir uma exposição definida. Uma garantia ou indenização pode alocar risco que sobrevive à conclusão. Um covenant pode reger o trabalho após a assinatura.

As medidas de reparação exigem gatilhos e mensuração. Se a proteção depender de confiabilidade, o documento deve definir o equipamento, a função, o período, as condições operacionais, o evento de falha, as evidências e o cálculo. Se depender da conclusão do projeto, deve definir marcos, aceitação, exclusões e consequências de prazo limite.

O IAS 37 trata de provisões, passivos contingentes e ativos contingentes.[14] Direitos legais e reconhecimento contábil são questões separadas. A equipe da transação deve preservar essa distinção ao converter uma constatação de engenharia em modelo ou divulgação.

O pacote de evidências deve ser utilizável em negociação. Deve conter a constatação confirmada, documentos de origem, análise, resposta da administração, conclusão do especialista, efeito econômico e ação proposta. A saída do modelo isoladamente é insuficiente.

18. Elaborar o plano de titularidade antes da assinatura

Alguns riscos de engenharia só podem ser resolvidos durante a propriedade. O comprador deve converter cada risco aceito em uma iniciativa com responsável, escopo, orçamento, dependência, marco, evidências e direito de decisão antes da assinatura.

Os primeiros cem dias podem incluir redefinição da linha de base do cronograma, validação do custo para conclusão, manutenção crítica, compra de sobressalentes, controle de acesso OT, limpeza de configuração e engajamento de fornecedores. O trabalho deve ser sequenciado em torno de segurança, continuidade e caixa, e não de um calendário genérico de integração.

A continuidade de dados é um requisito do primeiro dia. O comprador deve garantir acesso a arquivos nativos de cronograma, históricos de custos, registros de ativos, registros de manutenção, exportações do historian, documentação do modelo e configuração. Os serviços de transição devem incluir tempos de resposta, segurança e disposições de saída.

A capacidade de gestão faz parte do risco de engenharia. A equipe deve identificar planejadores, engenheiros de custos, especialistas em confiabilidade, engenheiros de controle e líderes de manutenção cujo conhecimento é necessário. Ações de retenção e sucessão devem decorrer da dependência de função verificada.

O comitê de investimentos deve ver o custo total de propriedade. Preço de compra, financiamento de conclusão, manutenção de recuperação, remediação de sistemas e contingência devem aparecer em uma única demonstração de fontes e usos e ponte de valor. Um múltiplo de destaque atraente pode ocultar um grande programa de restauração pós-conclusão.

19. Governar a diligência devida por meio de pontos de controle de evidências e registros de decisão

O escritório de diligência devida deve operar uma cadência semanal de evidências. Cada questão material tem um responsável, evidência exigida, status, conclusão, efeito econômico e decisão proposta. Os itens em aberto devem ser classificados por materialidade e tempo para resolução.

A equipe de modelagem deve publicar versões controladas. Cada versão registra snapshots das fontes, versão do código ou do modelo, parâmetros, testes e resultados alterados. Mudanças materiais devem ser explicadas aos líderes de engenharia e de transações antes de entrarem em um documento do conselho.

Tabela 5. Pontos de controle de governança para diligência devida de engenharia assistida por AI

O desenho dos marcos de aprovação deve ser calibrado ao cronograma da transação e à autoridade delegada.

O registro de decisões deve registrar por que uma constatação alterou ou não a transação. Isso protege contra a perda de memória em estágios avançados e ajuda a equipe de propriedade a entender os riscos aceitos. Também cria feedback para transações futuras.

Conflitos devem ser visíveis. Um vendedor pode controlar a extração de dados. Um fornecedor pode se beneficiar ao identificar trabalho de substituição. Um provedor de modelo pode promover sua própria precisão. A independência, o acesso e a remuneração dos revisores devem ser avaliados quando materiais.

O material do conselho deve separar constatações confirmadas, limitações não resolvidas e cenários da administração. Deve indicar quais conclusões dependem de inspeção física, confirmação por terceiros ou testes futuros. Essa estrutura apoia uma decisão sob incerteza sem disfarçar evidências ausentes.

20. Criar um sistema repetível de controle de diligência de engenharia

A diligência de engenharia assistida por AI torna-se repetível quando a organização preserva um método controlado, e não uma coleção de prompts e planilhas. O método conecta escopo, dados, análise, revisão, economia, proteção da transação e ação do proprietário.

Componentes reutilizáveis incluem dicionários de dados, tabelas de correspondência de identificadores, testes de cronograma, conciliações de custos, taxonomias de manutenção, notebooks de confiabilidade, modelos de evidências e registros de decisões. Eles devem ser adaptados ao tipo de ativo e à tese da transação. A padronização deve preservar o julgamento de engenharia e os requisitos regulatórios locais.

O sistema deve aprender com os resultados. Após a conclusão, o custo real, o cronograma, a confiabilidade e os resultados de remediação podem ser comparados com as constatações da diligência. Esse feedback pode revelar limiares otimistas, fontes de dados frágeis, modos de falha não identificados e indicadores iniciais valiosos. O aprimoramento do modelo deve usar dados controlados e legalmente permitidos.

O aprendizado de portfólio deve preservar o contexto da transação. Um sinal de cronograma de um projeto greenfield pode não ser transferível diretamente para a parada de uma instalação brownfield. Modos de falha em equipamentos rotativos podem ter pouca relevância para ativos logísticos controlados por software. A biblioteca deve, portanto, reter, ao lado de cada constatação, a classe do ativo, a fase do ciclo de vida, o regime operacional, a completude dos dados, a intervenção e o resultado. Esses atributos ajudam os revisores a selecionar evidências comparáveis e a evitar generalizações inadequadas.

A garantia de qualidade deve cobrir toda a cadeia analítica. As verificações da população de origem testam se todos os registros exigidos foram recebidos. As verificações de transformação testam identidade, unidades, datas e versões. As verificações de modelo testam o comportamento esperado e casos limite. As verificações de constatações testam o suporte da fonte, a aprovação do revisor e a tradução econômica. As verificações de liberação testam se o material do conselho, o modelo de avaliação e os documentos da transação usam o mesmo conjunto aprovado de constatações. As exceções devem permanecer visíveis até serem resolvidas ou aceitas pelo tomador de decisão autorizado.

O modelo operacional também precisa de uma política de retenção segura. Algumas evidências podem ser necessárias para negociação da transação, financiamento, seguro, administração de garantias ou disputas futuras. Outros dados-alvo podem precisar ser excluídos após um período definido. O escritório de diligência deve registrar regras de retenção, acesso, bloqueio legal e descarte por classe de dados. O uso para treinamento de modelo deve exigir autoridade separada e respeitar restrições contratuais, de privacidade, de concorrência e de propriedade intelectual.

A medida final é a qualidade da decisão. A análise deve revelar riscos materiais cedo o suficiente para alterar preço, estrutura, proteção, preparação ou execução pelo proprietário. Também deve descartar ruído imaterial com eficiência. Cobertura, rastreabilidade, tempo de revisão, conversão de constatações e precisão pós-transação fornecem um conjunto equilibrado de desempenho.

Para o comprador, o resultado é uma ponte defensável entre evidências de engenharia e valor e risco. Para os credores, é uma visão mais clara de conclusão, manutenção e exposição de caixa. Para a administração, é um plano de propriedade priorizado. Para o conselho, é uma base auditável para decidir se e como assinar.

Referências

1. U.S. Government Accountability Office, Guia de Avaliação de Cronogramas: Melhores Práticas para Cronogramas de Projetos, GAO-16-89G, 2015, https://www.gao.gov/products/gao-16-89g
2. Escritório de Responsabilidade Governamental dos EUA, Guia de estimativa e avaliação de custos: melhores práticas para desenvolver e gerenciar custos de programas, GAO-20-195G, 2020, https://www.gao.gov/products/gao-20-195g
3. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial 1.0, NIST AI 100-1, 2023, https://doi.org/10.6028/NIST.AI.100-1
4. Instituto Nacional de Padrões e Tecnologia, Estrutura de Gestão de Riscos de Inteligência Artificial: Perfil de Inteligência Artificial Generativa, NIST AI 600-1, 2024, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
5. Instituto Nacional de Padrões e Tecnologia, Nota conceitual: uso confiável de AI no perfil de infraestrutura crítica, 2026, https://www.nist.gov/system/files/documents/2026/04/08/Draft%20Concept%20Note_%20Development%20of%20the%20NIST%20AI%20RMF%20Trustworthy%20Use%20of%20AI%20in%20Critical%20Infrastructure%20Profile.pdf
6. Organização Internacional de Normalização, ISO/IEC 42001:2023 Sistema de gestão de inteligência artificial, https://www.iso.org/standard/42001
7. Organização Internacional de Normalização, ISO 55001:2024 Requisitos de sistema de gestão de ativos, https://committee.iso.org/sites/tc251/home/projects/published/iso-55001.html
8. Organização Internacional de Normalização, ISO 55013:2024 Orientações sobre a gestão de ativos de dados, https://www.iso.org/management-system-standards-list.html
9. Instituto Nacional de Padrões e Tecnologia, Guia de segurança de tecnologia operacional, NIST SP 800-82 Revisão 3, 2023, https://doi.org/10.6028/NIST.SP.800-82r3
10. Comissão Eletrotécnica Internacional, IEC 61508-2:2010 Requisitos de segurança funcional para sistemas elétricos, eletrônicos e eletrônicos programáveis relacionados à segurança, https://webstore.iec.ch/en/publication/5516
11. Administração Nacional de Aeronáutica e Espaço, Manual de engenharia de sistemas da NASA, NASA/SP-2016-6105 Revisão 2, https://www.nasa.gov/reference/systems-engineering-handbook/
12. Administração Nacional de Aeronáutica e Espaço, Orientações ampliadas para engenharia de sistemas da NASA, Volume 1, NASA/SP-2016-6105/SUPPL, 2016, https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170007238.pdf
13. Fundação IFRS, IFRS 3 Combinações de Negócios, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
14. Fundação IFRS, IAS 37 Provisões, Passivos Contingentes e Ativos Contingentes, https://www.ifrs.org/issued-standards/list-of-standards/ias-37-provisions-contingent-liabilities-and-contingent-assets/
15. Fundação IFRS, IFRS 13 Mensuração do Valor Justo, https://www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/
16. União Europeia, Regulamento (UE) 2024/1689, Regulamento de Inteligência Artificial, https://eur-lex.europa.eu/eli/reg/2024/1689/oj
17. Organização para a Cooperação e Desenvolvimento Econômico, Princípios AI da OCDE, https://oecd.ai/en/ai-principles
18. Agência de Segurança Cibernética e de Infraestrutura, Protegendo sistemas de controle industrial, https://www.cisa.gov/sites/default/files/publications/Securing_Industrial_Control_Systems_S508C.pdf
19. Administração Nacional de Aeronáutica e Espaço, Manual de engenharia de sistemas do MSFC, MSFC-HDBK-3173, https://standards.nasa.gov/standard/msfc/msfc-hdbk-3173
20. Health and Safety Executive do Reino Unido, Programa-Chave 3: Programa de Integridade de Ativos https://www.hse.gov.uk/offshore/assets/docs/kp3.pdf