Separações de serviços públicos do Reino Unido: separando gêmeos digitais, dados operacionais e ativos regulamentados

1. Defina a decisão da transação

A decisão do conselho é se uma determinada empresa de serviços públicos pode transferir para um comprador um perímetro completo e operável de forma independente, com um valor, alocação de risco e cronograma acordados. A resposta requer provas sobre o serviço regulamentado, os activos que o prestam e os sistemas que controlam esses activos. Um limite de entidade jurídica ou registo de activos fixos é um ponto de partida incompleto quando dados operacionais, aplicações e equipas especializadas são partilhados entre um grupo.

A decisão deverá permitir quatro resultados: prosseguir com o perímetro proposto, alargar o perímetro, redesenhar a arquitectura de transição ou adiar a assinatura até que uma dependência material seja resolvida. Cada dependência não resolvida precisa de um proprietário, uma consequência final e um efeito de valor quantificado. Um compromisso genérico de fornecer assistência razoável após a conclusão dá pouca proteção ao comprador quando um modelo, licença ou dependência cibernética é essencial para a continuidade do serviço.

A CMA afirma que um pacote de exclusão utilizado como solução para uma fusão deve conter os ativos, funções e capacidades necessárias para que o comprador opere com sucesso e concorra de forma eficaz [1,2]. A mesma lógica operacional se aplica a uma separação voluntária de serviços públicos. A equipe de transação deve testar se o comprador recebe um negócio funcional em vez de um conjunto de ativos.

Estrutura original. Os requisitos variam de acordo com o setor, licença, estrutura de transação e direção regulatória.

2. Comece com o serviço regulamentado

O perímetro deve começar pelo serviço que a entidade licenciada ou designada deve prestar. As redes de electricidade e de gás operam sob licenças sectoriais e controlos de preços. As empresas de água operam sob instrumentos de nomeação. Essas estruturas atribuem obrigações, deveres de informação, proteções financeiras e resultados do cliente a entidades definidas [14-18]. Um plano de separação deve mapear cada obrigação em relação aos ativos, pessoas, dados e decisões necessárias para cumpri-la.

Essa abordagem que prioriza o serviço evita dois erros comuns. O vendedor pode presumir que uma aplicação é um serviço de grupo porque o contrato fica a nível da empresa-mãe, mesmo que a entidade regulada não possa operar sem ele. O comprador pode assumir que a propriedade de uma subestação, estação de tratamento ou rede inclui automaticamente a telemetria, o modelo de engenharia e os registros históricos necessários para gerenciá-la. Nenhuma das suposições estabelece um perímetro operável.

A sala de provas deve conter um registo de obrigações regulamentares. Cada entrada deve identificar a obrigação de origem, a entidade responsável, o processo operacional, a tecnologia de apoio, as entradas de dados, os resultados do relatório e o tratamento proposto na conclusão. Um regulador pode exigir notificação, consentimento, modificação de licença ou garantia. A assessoria jurídica deverá confirmar o processo aplicável à transação real.

3. Mapear o perímetro legal e regulatório

O perímetro legal identifica ações, ativos, contratos, licenças, alvarás, direitos fundiários, propriedade intelectual e funcionários propostos para transferência. O perímetro regulatório identifica as obrigações e proteções que devem permanecer eficazes. O perímetro operacional identifica o que o negócio realmente precisa. Uma exclusão robusta reconcilia todos os três, em vez de tratar o calendário legal como a resposta completa.

As barreiras de utilidade adicionam restrições. As condições de licença do Ofwat podem restringir transações com proprietários e associados, exigir informações e proteger a resiliência financeira [15,16]. A estrutura de proteção da rede da Ofgem busca independência jurídica, financeira e operacional para licenciados regulamentados e restringe subsídios cruzados e transferências de ativos que poderiam comprometer as obrigações de licença ^[17]. As equipes de transação devem testar acordos entre empresas, ativos compartilhados, pooling de caixa, garantias, taxas de serviço e acesso a dados em relação às condições relevantes.

O regime de Segurança Nacional e Investimento também pode ser aplicado. As orientações do governo explicam como o regime interage com a regulamentação do setor e identifica energia, infraestrutura de dados e outras atividades sensíveis [19-23]. A avaliação do perímetro deve considerar o alvo, o adquirente e o controle a ser transferido. A análise de notificação pertence ao caminho crítico da transação, e não a uma lista de verificação de fechamento tardio.

4. Definir ativos regulamentados e direitos associados

O valor dos ativos regulamentados é uma construção financeira regulatória e não uma lista completa de ativos operacionais. O relatório da Ofgem explica que o RAV reflete o investimento acumulado sob a estrutura de controle de preços e apoia o cálculo dos retornos permitidos ^[18]. Um perímetro de transação também deve capturar ativos que tenham pouco valor contábil, mas que permaneçam operacionalmente essenciais, incluindo lógica de controle, modelos de rede, registros de configuração, chaves cibernéticas, históricos de manutenção e ferramentas especializadas.

O mapa de activos regulamentados deve ligar cada activo físico à propriedade, tratamento da licença, localização, condição, valor regulamentar, valor contabilístico, dever de manutenção, telemetria, representação do modelo e autoridade operacional. Deve registar os activos pertencentes a terceiros ou partilhados com empresas retidas. O direito de uso pode ser mais importante do que o título quando uma interface, circuito de comunicação ou licença de software suporta serviço contínuo.

O mapa também deve identificar os ativos que não podem ser transferidos sem consentimento, novação, modificação de licença ou reconfiguração técnica. A equipe de separação deve evitar uma classificação binária de transferência versus retenção. Alguns itens exigem duplicação, acesso transitório, garantia, substituição ou um novo acordo operacional. Esses tratamentos precisam de custos, datas e consequências do fracasso.

5. Trate o gêmeo digital como uma capacidade operacional

A definição do governo do Reino Unido para 2025 exige que um gêmeo digital permaneça vinculado a uma contraparte do mundo real, use um fluxo de dados bidirecional, opere dentro de um envelope de validação declarado e carregue um conjunto de suposições ^[5]. Um modelo tridimensional estático, um painel de controle ou um registro de ativos podem dar suporte ao negócio, mas não atendem a essa definição por si só. A distinção é importante porque um verdadeiro gêmeo depende de interfaces ativas, calibração, qualidade de dados e governança após a conclusão.

O inventário de separação deve descrever a contraparte física, finalidade, proprietário, usuários, dados de origem, decisões de saída, frequência de atualização, envelope de validação, suposições, versão do modelo, pilha de software e processo de fallback para cada gêmeo. Deve identificar se o modelo apenas avisa os operadores ou envia instruções de volta ao sistema físico. Um modelo que influencia as configurações de controle, os intervalos de manutenção ou as decisões de segurança requer uma garantia mais forte do que uma ferramenta de planejamento visual.

Os princípios do Programa Nacional de Gêmeos Digitais enfatizam segurança, confiabilidade, adaptabilidade e interoperabilidade [6,7]. Os documentos de transação devem, portanto, abordar a proveniência, a validação, o controle de alterações e o suporte ao ciclo de vida. A entrega do código-fonte sem direitos de telemetria, documentação de modelo ou operadores qualificados pode deixar o comprador com um artefato inutilizável.

6. Construa o mapa de linhagem de dados

Os dados operacionais devem ser rastreados desde o sensor ou registro de origem até cada sistema, transformação, modelo, decisão, relatório regulatório e arquivo. O mapa deve mostrar proprietário, controlador, processador, licença, período de retenção, classificação de segurança, regra de qualidade e uso permitido. Deve também identificar data lakes de grupo, dados mestres compartilhados, planilhas manuais e feeds de terceiros que estejam fora do perímetro legal proposto.

A orientação de melhores práticas de dados do Ofgem trata os dados como um ativo que deve ser detectável, interoperável e regido por obrigações de licença [3,4]. Ofwat descreve os dados, juntamente com as pessoas, processos e tecnologia que os suportam, como um ativo importante para o setor da água ^[14]. Estas políticas apoiam um design de separação em que os produtos de dados têm propriedade, padrões e responsabilidade claros.

A linhagem deve atingir a camada de decisão. Se um modelo de vazamento, previsão de interrupção ou simulação de rede usar um recurso derivado, o comprador precisará da lógica de transformação e da versão histórica. Se um retorno regulatório for proveniente de um data mart, o plano de separação deverá preservar a reconciliação com a fonte. Uma simples exportação de banco de dados raramente atende a essas necessidades.

7. Atribuir direitos e responsabilidades de dados

O vendedor pode possuir um banco de dados e não ter direitos irrestritos para transferir todos os registros. Informações de clientes, dados de funcionários, dados geoespaciais licenciados, feeds de fornecedores e registros de engenharia criados em conjunto podem conter diferentes restrições. O comprador precisa de uma análise de direitos em nível de registro ou de conjunto de dados para produtos de dados de materiais. A análise deve abranger a propriedade, os direitos da base de dados, a confidencialidade, a privacidade, as restrições contratuais e a utilização pós-conclusão por ambas as partes.

O código de compartilhamento de dados da ICO afirma que uma fusão ou aquisição que envolva uma mudança de controlador requer a devida diligência quanto à finalidade original, base legal, mudança de uso, transparência, governança e segurança ^[8]. Uma divulgação no data room de transações não estabelece permissão para migração operacional. As partes devem definir quais transferências de dados pessoais na assinatura, conclusão e saída do TSA, e como serão tratados os direitos dos titulares dos dados e as obrigações de retenção.

Os dados históricos partilhados podem apoiar tanto os negócios vendidos como os retidos. As partes devem escolher entre transferência, duplicação, acesso a salas limpas, agregação, anonimização ou serviço continuado. O tratamento escolhido deve preservar as evidências regulamentares, limitando ao mesmo tempo a utilização aos fins acordados.

8. Separe a tecnologia operacional com segurança

A tecnologia operacional inclui o hardware e software que monitora ou controla processos físicos. Em uma concessionária, pode incluir controle de supervisão e aquisição de dados, controle distribuído, telemetria, proteção, unidades terminais remotas, estações de trabalho de engenharia e sistemas de segurança. A separação altera identidades, redes, acesso a fornecedores e responsabilidades em torno dos sistemas que suportam serviços essenciais.

O Quadro de Avaliação Cibernética do NCSC fornece uma base estruturada para avaliar a segurança e a resiliência cibernética ^[9]. Sua orientação de tecnologia operacional reconhece as restrições distintas de segurança, disponibilidade e ciclo de vida desses sistemas ^[10]. A orientação NIS 2026 do Ofgem exige que os operadores identifiquem os sistemas, componentes, interfaces, pessoas e terceiros dos quais o serviço essencial depende e gerenciem a segurança durante todo o ciclo de vida da engenharia [11,12].

O plano de separação deve classificar cada conexão como transferência, duplicação, isolamento, substituição ou retirada. Deve especificar a autoridade de identidade final, o modelo de acesso privilegiado, a rota de suporte remoto, o monitoramento, a resposta a incidentes e a responsabilidade de recuperação. A transição deve ser ensaiada em um ambiente representativo. Um comprador não deve descobrir, após a conclusão, que uma conta de vendedor retida continua sendo o único caminho para um controlador crítico.

9. Preservar a continuidade dos serviços essenciais

A continuidade é a principal restrição operacional. Os Regulamentos SRI aplicam-se a serviços essenciais de energia e água e exigem medidas adequadas de segurança e gestão de incidentes [11-13,24]. Uma transação não pode tratar uma interrupção prolongada como uma falha de migração aceitável. Todo plano de transição precisa de um substituto seguro e de uma autoridade de decisão definida.

A empresa deve decompor cada serviço essencial em capacidades operacionais mínimas viáveis. Para cada capacidade, a equipe deve identificar a interrupção máxima tolerável, o fallback manual, o ponto de recuperação de dados, os controles cibernéticos, a equipe, o suporte do fornecedor e o caminho de notificação regulatória. Esses requisitos tornam-se critérios de aceitação para testes de separação.

A prontidão no primeiro dia deve ser evidenciada através de testes de cenários, em vez de apenas relatórios de situação. Os testes devem abranger perda de conectividade do vendedor, falha nas interfaces migradas, credenciais comprometidas, telemetria corrompida, indisponibilidade do fornecedor e atraso na aprovação regulatória. O conselho deve receber as conclusões críticas não resolvidas e as mitigações específicas necessárias antes da conclusão.

10. Valide modelos antes e depois da transferência

Um modelo pode produzir resultados tecnicamente plausíveis enquanto depende de pré-processamento não documentado, calibração obsoleta ou dados indisponíveis. O inventário do modelo deve registrar a finalidade, o responsável pela decisão, as entradas, as saídas, o período de treinamento ou calibração, o método de validação, os limites de desempenho, o histórico de alterações, o processo de substituição e o substituto. Os gêmeos digitais exigem evidências adicionais sobre a contraparte física e o envelope de validação ^[5].

A equipe de separação deverá realizar três testes. A reprodução confirma que o comprador pode gerar o mesmo resultado a partir dos insumos acordados. A portabilidade confirma que o modelo opera no ambiente do comprador com dados e licenças permitidas. A validação operacional confirma que usuários qualificados podem interpretar o resultado e reconhecer condições fora dos limites do modelo. Passar em um teste não prova os outros.

Quando a aprendizagem automática é utilizada, as partes devem preservar as definições de características, os dados de avaliação, os limites de monitorização e a responsabilidade humana. Os princípios AI da OCDE enfatizam a transparência, a robustez e a responsabilização ^[26]. Os documentos de transação devem identificar quem arca com os custos e riscos se um modelo transferido não puder ser validado no ambiente do comprador.

11. Alocar propriedade intelectual e licenças de software

O patrimônio digital pode incluir modelos proprietários, configuração, scripts, interfaces, software de fornecedor, componentes de código aberto e plataformas desenvolvidas em grupo. A propriedade e o direito de operar são questões distintas. Um vendedor pode possuir um código personalizado, enquanto uma licença de terceiros restringe a atribuição. Um comprador pode receber uma licença perpétua, mas não possui as ferramentas ou o conhecimento necessários para manter o sistema.

A tabela de propriedade intelectual deve vincular cada direito aos sistemas e processos que ele suporta. Deve identificar a disponibilidade do código-fonte, os direitos do código-objeto, a documentação, os direitos sobre trabalhos derivados, os direitos sobre os dados, as obrigações de manutenção, o depósito e os limites territoriais. O cronograma também deve registrar obrigações de código aberto e quaisquer componentes cujos termos exijam divulgação da fonte ou restrinjam o uso comercial.

Os contratos de software devem ser revisados ​​quanto à atribuição, mudança de controle, métricas do usuário, hospedagem, exportação de dados, direitos de auditoria, suporte e rescisão. Uma licença temporária de vendedor pode suportar o Dia 1, mas o TSA deve conter um caminho de substituição financiado e uma data de saída realista.

12. Projete a arquitetura do serviço de transição

Um TSA ganha tempo para completar a separação. Não deve ocultar um modelo operacional de destino indefinido. Cada serviço precisa de escopo, volumes, níveis de serviço, regras de segurança, cobrança, controle de alterações, responsabilidade, tratamento de dados, assistência de saída e um proprietário nomeado de ambos os lados. O catálogo de serviços deve separar as operações críticas dos serviços de conveniência.

As dependências devem ser mapeadas no nível do aplicativo e do processo. Um painel operacional pode contar com gerenciamento de identidade de grupo, um data lake compartilhado, suporte de fornecedor, telecomunicações e uma equipe de análise retida. A TSA deve especificar como cada dependência será transferida ou substituída. Uma única data de término para todo o catálogo pode gerar custos excessivos ou saída prematura.

O comprador deve definir critérios objetivos de saída: dados migrados reconciliados, interfaces testadas, usuários treinados, fornecedores contratados, controles cibernéticos aprovados, relatórios regulatórios produzidos e continuidade do serviço demonstrada. A saída deve ser governada por meio de evidências e aceitação, com escalonamento para dependências perdidas.

Estrutura original. O tempo e os controles são hipotéticos e exigem confirmação específica da transação.

13. Construir governança cibernética autônoma

A separação cibernética é uma mudança de governança e também uma migração técnica. O comprador torna-se responsável pela aceitação de riscos, decisões de incidentes, envolvimento do regulador e supervisão do fornecedor. As políticas copiadas do vendedor podem referir-se a equipes, ferramentas ou caminhos de escalonamento indisponíveis. O comprador necessita de um sistema de controlo funcional que corresponda à sua organização real.

O projeto de governança deve identificar o executivo responsável, as operações de segurança, a liderança de segurança da TO, a função de proteção de dados, o comandante do incidente e os relatórios do conselho. Deve mapear os controlos para os sistemas abrangidos e registar os riscos residuais. Contas privilegiadas, certificados, chaves, ferramentas de acesso remoto e domínios compartilhados exigem tratamento de transição explícito.

O plano de garantia deve combinar revisão de projeto, evidência de configuração, gerenciamento de vulnerabilidades, testes de acesso, exercícios de recuperação e desafio independente. Um teste de penetração por si só não pode estabelecer resiliência. Quando se aplica a regulamentação de serviços essenciais, a equipa deve alinhar as evidências com o quadro atual da autoridade competente [9,11,24].

14. Crie finanças separadas confiáveis

As contas de gestão históricas reflectem frequentemente alocações de grupo, aquisições partilhadas, financiamento central e serviços que mudam após a separação. O comprador precisa de demonstrações financeiras que se ajustem ao perímetro proposto e de um modelo de custos independente que identifique serviços de substituição, funções duplicadas, dessinergias e remediação. As contas regulamentares, as contas estatutárias e as contas de separação de transações têm finalidades diferentes e devem ser interligadas.

O modelo deve separar os custos isolados recorrentes das despesas pontuais de separação. Deve identificar o custo ocioso do vendedor sem presumir que o comprador o reembolsará. Deve também distinguir os custos já financiados através de um controlo de preços dos custos que podem exigir tratamento regulamentar futuro. O valor regulamentar e o valor empresarial não devem ser tratados como intercambiáveis.

Cada ajuste de material precisa de fonte, base, proprietário e sensibilidade. Os custos da plataforma de dados, licenças de software, operações cibernéticas, suporte de modelos e telecomunicações estão frequentemente dispersos pelos orçamentos do grupo. O fluxo de trabalho do perímetro digital deve alimentar o modelo financeiro em vez de funcionar como um apêndice técnico.

15. Unir o valor regulatório ao valor da transação

O valor dos activos regulamentares pode ancorar a análise nas transacções de rede porque reflecte o tratamento dado pelo regulador ao investimento qualificado. O valor da empresa também reflete os retornos permitidos, o desempenho, os requisitos de capital, o financiamento, a qualidade do serviço, o crescimento, o risco e as suposições do comprador. Um prémio ou desconto ao RAV necessita de uma explicação clara com base nos fluxos de caixa e riscos esperados.

A ponte de valor de exclusão deve mostrar o efeito dos custos autónomos, das despesas de separação, dos encargos da TSA, das negociações de custos ociosos, do capital necessário, das obrigações de pensões ou ambientais, da remediação do modelo e do risco cibernético. Deve evitar tratar todas as despesas digitais como criação de valor. Algumas despesas restauram uma capacidade operacional mínima e devem ser avaliadas como um custo necessário.

O comprador deve testar se os dados e a capacidade digital melhoram os resultados operacionais que o quadro regulamentar recompensa. O vendedor deve fornecer provas que liguem um modelo ou plataforma às decisões de serviço, custo ou investimento. Uma narrativa tecnológica sem provas operacionais medidas não deve apoiar um prémio de avaliação.

Todos os valores são premissas hipotéticas de gestão em GBP milhões. Eles não representam uma empresa ou avaliação real.

16. Quantificar despesas de separação

As despesas de separação devem ser estimadas a partir do mapa de dependências. As categorias podem incluir extração e limpeza de dados, desenvolvimento de interface, migração para nuvem, isolamento de OT, telecomunicações, redesenho de identidade, licenças, portabilidade de gêmeo digital, garantia cibernética, ambientes de teste, execução paralela e retenção de especialistas. Cada categoria deve ter quantidades, taxas, contingência e tempo.

A correlação é importante. Uma plataforma de identidade atrasada pode atrasar vários aplicativos. Um direito de dados contestado pode impedir a validação do modelo e os relatórios regulamentares. Um fornecedor crítico pode controlar tanto o suporte de software quanto a capacidade de integração. O modelo de custos deve preservar estas dependências em vez de aplicar contingências independentes a cada linha.

A governação deve distinguir o crescimento do âmbito do refinamento das estimativas. Quando a diligência revela um sistema omitido, o perímetro mudou. Quando uma tarefa de migração conhecida recebe uma cotação mais firme, a estimativa melhorou. Ambos afetam o valor, mas exigem decisões diferentes do conselho e proteção contratual.

17. Conduza a diligência do comprador em torno das decisões

A diligência do comprador deve testar as decisões que o conselho e as partes financeiras devem tomar. Deve estabelecer se o perímetro funciona, o que deve ser remediado, quanto tempo leva a independência e como as conclusões afectam o valor e os documentos. Um questionário que produz milhares de arquivos sem modelo de dependência atrasa essas decisões.

O comprador deve selecionar jornadas de serviço ponta a ponta para teste. Um caso de rede elétrica poderia rastrear um alarme através de telemetria, controle, despacho, gerenciamento de incidentes, comunicação com o cliente e relatórios regulatórios. Um caso de água poderia rastrear um evento de qualidade ou vazamento desde o sensor até a resposta do operador, dados laboratoriais, impacto no cliente e evidências regulatórias. Cada jornada expõe dependências multifuncionais.

As descobertas vermelhas devem ter consequências quantificadas. Os exemplos incluem uma condição precedente, ajuste de preço de compra, garantia, indenização específica, obrigação de TSA, acordo de remediação ou direito de afastamento. O conselho deve verificar quais conclusões permanecem sujeitas a confirmação legal, regulatória ou técnica.

18. Prepare o pacote de evidências do vendedor

A preparação do vendedor começa com um modelo de perímetro controlado. Os fluxos de trabalho jurídico, financeiro, operacional, digital, cibernético, patrimonial, fiscal e pessoal devem usar os mesmos identificadores de ativos e dependências. Listas separadas criam um esforço de reconciliação e permitem que lacunas materiais permaneçam ocultas entre as equipes.

O vendedor deve preparar um índice de evidências ligando cada reclamação a uma fonte confiável. As afirmações sobre independência do sistema, propriedade dos dados, precisão do modelo, custo do serviço e tempo de separação devem ser reproduzíveis. As estimativas de gestão devem ser rotuladas com a sua base e intervalo. Dados operacionais confidenciais podem ser preparados por meio de equipes limpas ou ambientes controlados.

A prontidão antecipada pode melhorar a alavancagem de negociação porque reduz a incerteza em torno do ativo que está sendo vendido. Também pode expor a necessidade de redesenhar o perímetro antes do lançamento. O vendedor deve tratar esse resultado como uma preparação para a transação e não como uma falha na divulgação.

19. Traduza as descobertas em documentos de transação

O acordo de venda deve descrever o negócio a ser transferido em termos operacionais. Os cronogramas de ativos e contratos continuam necessários, mas as garantias e os acordos devem abordar a integralidade e a usabilidade dos dados, documentação, interfaces, licenças, modelos e acesso. As divulgações devem identificar com precisão os limites conhecidos.

As condições precedentes podem incluir consentimento regulatório, autorização NSI, transferência ou modificação de licença, novação de contrato material e testes de separação especificados. Os resultados de conclusão podem incluir extrações de dados reconciliados, revogação de acesso, chaves, runbooks, documentação de modelo e correspondência reguladora. Quando uma dependência não puder ser concluída antes do encerramento, a TSA deverá incluir a obrigação e os critérios de saída.

A alocação de riscos deve seguir o controle. Um vendedor que controla a migração antes da conclusão pode assumir riscos de atraso e precisão. Um comprador que altere a arquitetura alvo poderá arcar com os custos resultantes. As dependências partilhadas requerem mecanismos de governação e de disputa. Aconselhamento jurídico específico para transações é essencial.

20. Preparação para governar no primeiro dia

O dia 1 é o primeiro estado operacional sob controle do comprador. O plano deve identificar quais sistemas, dados, pessoas e fornecedores são de propriedade do comprador, fornecidos pelo vendedor ou que operam sob acesso temporário. Cada processo crítico precisa de um proprietário nomeado e de uma rota de escalonamento. A continuidade do serviço, a segurança e a conformidade regulatória têm prioridade sobre uma migração esteticamente completa.

O painel de prontidão deve usar portas baseadas em evidências. Um status verde exige testes aprovados, documentação aprovada e risco residual aceito. O tempo decorrido ou a percentagem concluída não estabelece a prontidão. Os defeitos críticos devem permanecer visíveis para a placa mesmo quando existe uma solução alternativa.

A estrutura de comando de transferência deve definir quem pode interromper, continuar ou reverter cada migração. As comunicações devem abranger funcionários, fornecedores, reguladores e clientes, quando aplicável. O primeiro ciclo de relatórios e o exercício de incidentes devem ser planejados antes da conclusão.

21. Controle a saída do TSA

A saída da TSA transfere responsabilidade, bem como carga de trabalho. O comprador deve demonstrar que possui os contratos relevantes, controla as identidades, recebe os dados necessários, opera o monitoramento, gerencia os incidentes e pode comprovar a conformidade regulatória. O vendedor deve remover o acesso e reter apenas os registros que tem direito ou é obrigado a manter.

O sequenciamento de saída deve seguir as dependências. As aplicações corporativas podem sair mais cedo, enquanto o monitoramento de TO, as plataformas de dados e os serviços de gêmeos digitais permanecem por mais tempo. As condições comerciais podem incluir preços crescentes para encorajar a saída, mas os preços não devem forçar uma transição prematura. Os direitos de extensão devem ser restritos, documentados e vinculados à remediação.

O certificado de saída deve listar os serviços aceitos, os defeitos não resolvidos, as evidências arquivadas, os registros transferidos, o acesso revogado e as obrigações contínuas. A supervisão do conselho deve continuar até que todos os serviços críticos tenham sido encerrados e os testes pós-saída tenham sido aprovados.

22. Aplique o caso hipotético trabalhado

O vendedor hipotético propõe uma plataforma regional contendo redes reguladas, operações de campo, interfaces de atendimento ao cliente, uma plataforma de dados operacionais e diversos modelos digitais. O primeiro perímetro contém ativos físicos e funcionários, mas depende de identidade, dados, modelo e serviços cibernéticos hospedados pelo vendedor. O comprador identifica GBP 84 million de despesas de separação e aplica um ajuste de risco GBP 65 million.

Três designs são testados. O Projeto A transfere o perímetro físico e legal com TSA de 18 meses. Tem o menor trabalho de pré-conclusão, mas o maior risco de dependência e extensão. O Projeto B duplica os dados principais e as plataformas de identidade antes da conclusão, transfere direitos de modelo e usa TSAs direcionados. Custa mais antes da conclusão e atinge a independência mais cedo. O Design C transfere a plataforma digital compartilhada mais ampla e equipes selecionadas. Reduz a duplicação, mas cria uma separação mais complexa entre negócios retidos.

O conselho seleciona o Projeto B como caso de planejamento. Esta é uma decisão hipotética. O ajuste de valor pode liberar GBP 42 million se o comprador receber direitos de dados verificados, modelos reproduzíveis, arquitetura cibernética aprovada e saídas TSA testadas antes dos marcos acordados. O ajustamento restante cobre a incerteza de execução que a evidência hipotética não elimina.

23. Definir portões e relatórios do conselho

O conselho deve aprovar o perímetro, a ponte de valor, o caminho regulatório, o modelo do Dia 1 e o plano de saída da TSA nos portões definidos. Cada portão deverá apresentar evidências, risco residual e a decisão solicitada. Os relatórios devem distinguir factos confirmados, pressupostos de gestão e itens que aguardam aprovação externa.

O conselho precisa de um pequeno conjunto de indicadores operacionais: dependências críticas sem tratamento financiado, direitos não resolvidos, testes de migração falhados, elevados riscos cibernéticos, condições regulamentares, serviços TSA sem planos de saída, movimento de custos de separação e valor em risco. Os dados detalhados do fluxo de trabalho devem permanecer disponíveis abaixo desses indicadores.

Os limites de escalonamento devem ser acordados antes da assinatura. Uma alteração ao perímetro regulamentado, a perda de uma licença exigida, a incapacidade de validar um modelo de controlo ou a falha num teste de serviço essencial devem ser devolvidas ao organismo de aprovação relevante. A governação deverá permanecer activa após a conclusão até que a independência seja verificada.

Estrutura original. Os órgãos de prova e aprovação devem ser adaptados aos documentos reais de governança e transação.

24. Use um plano de ação de noventa dias

Durante os primeiros trinta dias, nomeie líderes de fluxo de trabalho responsáveis, confirme o perímetro regulatório e de serviço, crie identificadores comuns e lance o inventário de dependências. Identifique conselhos regulatórios e NSI, fornecedores críticos, conexões de TO compartilhadas e gêmeos digitais. Estabeleça padrões de evidência e acesso controlado à sala de dados.

Durante o trigésimo primeiro ao sexagésimo dia, complete mapas de serviço ponta a ponta, linhagem de dados, inventário de modelos, arquitetura alvo e custos independentes preliminares. Testar o tratamento proposto para os sistemas de maior risco. Elabore os serviços da TSA e identifique as condições precedentes. Insira resultados quantificados em documentos de avaliação e transação.

Durante os dias sessenta e um a noventa, ensaie migrações críticas, valide a capacidade do comprador, elimine lacunas de direitos materiais e chegue a um acordo sobre evidências de saída. Apresente ao conselho o perímetro completo, ponte de valor, riscos residuais e plano de execução fechado. O cronograma é uma sequência de gerenciamento ilustrativa e deve ser alterado para a transação real.

25. Apêndice A Registro de evidências de diligência

O registro de evidências deve conter o mapa de obrigações regulatórias, registros de licença e nomeação, correspondência regulatória, registro de ativos, ponte RAV, acordos entre empresas, catálogo de serviços, mapas de processos, inventários de aplicação e OT, linhagem de dados, registro de modelo, arquitetura cibernética, contratos de fornecedores, análise de direitos, mapa de funcionários, contas separadas, modelo de custo de separação, catálogo TSA, plano do dia 1, evidências de teste e caminho crítico.

Cada item deve registrar proprietário, fonte, data, versão, escopo, restrição de acesso, status de validação e decisão suportada. Um status completo deve exigir um revisor identificado e um critério de aceitação. Discrepâncias materiais entre registros devem ser registradas e resolvidas.

O registro deve permanecer ativo até a conclusão e saída do TSA. Torna-se a trilha de auditoria da transação e reduz a dependência do conhecimento pessoal. As informações operacionais sensíveis devem permanecer protegidas através de controlos de acesso proporcionais.

26. Apêndice B registro de risco de separação

O registro de riscos deve conectar cada dependência à probabilidade, impacto, método de detecção, mitigação, proprietário, data de vencimento e consequência contratual. Os riscos devem ser declarados como causa, evento e consequência. Por exemplo, uma licença de software intransferível pode impedir o comprador de operar o modelo de rede após a conclusão, levando a uma dependência prolongada da TSA e a custos adicionais.

O registro deve incluir riscos regulatórios, operacionais, de segurança, de dados, de privacidade, cibernéticos, de modelo, de fornecedores, de pessoas, financeiros e de cronograma. Riscos correlacionados devem ser identificados. Uma migração de dados falhada pode afetar a validação do modelo, os relatórios regulamentares e a continuidade operacional ao mesmo tempo.

O risco residual deve ser aceito pela pessoa com autoridade sobre o serviço afetado. Um fluxo de trabalho não pode encerrar um risco de continuidade de serviço no nível da placa marcando uma ação como concluída. O encerramento exige evidência de que o risco foi removido, transferido ou aceito dentro da tolerância aprovada.

Riscos regulatórios e de licença

O risco regulatório deve identificar a obrigação exata, a autoridade competente, a alteração proposta e as consequências da transação. Uma entrada ampla, como a aprovação regulamentar, pode ocultar vários assuntos distintos: análise de mudança de controlo, modificação de licenças, compromissos de informação, conformidade com limites, tratamento de controlo de preços e revisão da segurança nacional. Cada assunto pode ter um requisito de evidência e um cronograma diferentes. O registo deve mostrar se a ação é um requisito legal, um passo de compromisso prudente ou um pressuposto de gestão que aguarda aconselhamento.

Os riscos relacionados com a licença devem estar ligados ao modelo operacional. Uma condição de licença que exija recursos, registros ou independência operacional pode afetar quais sistemas e pessoas devem ser transferidos. A mitigação deve, portanto, indicar a capacidade necessária e como ela será evidenciada. Uma reunião realizada com um regulador é uma atividade; confirmação por escrito, uma modificação aprovada ou conclusão de uma condição específica é evidência. O cronograma da transação deve conter tempo suficiente para perguntas, submissões revisadas e implementação de condições.

Riscos de dados e modelos

Os riscos dos dados devem distinguir registos em falta, má qualidade, direitos incertos, formatos incompatíveis e linhagem indisponível. Cada categoria precisa de uma resposta diferente. Registros ausentes podem exigir reconstrução ou solução contratual. Problemas de qualidade podem exigir limpeza e validação. Os problemas de direitos podem exigir consentimento, uma nova licença, anonimização ou utilização restrita. Problemas de formato podem exigir transformação e testes paralelos. A falta de linhagem pode limitar a capacidade do comprador de reproduzir um retorno regulatório ou um resultado de modelo.

Os riscos do modelo devem indicar a decisão afetada. Um modelo de demanda utilizado para planejamento de longo prazo pode tolerar um ciclo de validação diferente de um modelo de controle que altera as configurações operacionais. O registo deve identificar o envelope de validação relevante, as dependências de entrada, o limiar de desempenho, os utilizadores autorizados e o substituto. A mitigação deve incluir um teste de reprodutibilidade e um teste de aceitação operacional no ambiente do comprador. A confirmação do vendedor de que o modelo funcionou com sucesso antes da separação não prova que ele operará com os dados, licenças e controles do comprador.

Riscos operacionais e cibernéticos

Os riscos operacionais devem ser testados através de jornadas de serviço. Uma dependência pode parecer secundária em um inventário de aplicativos enquanto está no único caminho entre um alarme e uma resposta do operador. O registo deve identificar a perturbação máxima tolerável e o recurso manual. Se não existir um substituto seguro, a dependência pertence ao caminho crítico e pode exigir duplicação ou suporte contínuo do vendedor até que a capacidade do comprador seja demonstrada.

Os riscos cibernéticos devem abranger acesso, segmentação, monitorização, recuperação, conectividade de fornecedores, certificados, chaves de encriptação e responsabilidade por incidentes. Domínios administrativos compartilhados e rotas de suporte remoto merecem entradas específicas porque podem preservar o controle não intencional após a conclusão. A mitigação deve definir o estado alvo, sequência de transição, teste, evidência e reversão. O comprador deverá receber um registro atualizado de acesso privilegiado e confirmar a revogação ou reatribuição no ponto acordado.

Riscos financeiros e de avaliação

Os riscos financeiros devem conciliar o perímetro com as contas históricas e o plano autónomo. Uma alocação de custos pode desaparecer das contas gerenciais do vendedor sem desaparecer do negócio. O registo deve identificar o serviço que está a ser substituído, o volume esperado, o fornecedor ou recurso interno, o custo de implementação e o custo de estado estacionário. Deve também registar separadamente os custos do vendedor ocioso, porque esses custos não pertencem automaticamente ao comprador.

Os riscos de avaliação devem estar diretamente ligados ao modelo. Se um direito de dados permanecer incerto, o modelo deverá mostrar o custo de substituição, o impacto operacional e o intervalo de horários. Se a saída da TSA falhar, o modelo deverá mostrar encargos adicionais, custos duplicados e qualquer sinergia atrasada. Um ajuste de risco deve ser liberado somente quando a evidência acordada for entregue. Esta abordagem torna o ajustamento auditável e reduz os argumentos sobre se uma acção está concluída.

Riscos de pessoas e fornecedores

Os riscos pessoais devem identificar funções, nomear titulares quando apropriado, tratamento de transferência, necessidades de retenção, habilitação de segurança, responsabilidade de plantão e concentração de conhecimento. Um especialista no assunto compartilhado pode apoiar vários negócios e não conseguir transferir. A mitigação pode exigir documentação, acompanhamento, recrutamento, um contrato de serviços ou um perímetro diferente. Os bônus de conclusão por si só não criam capacidade de comprador, a menos que a pessoa e o conhecimento estejam disponíveis quando necessário.

Os riscos do fornecedor devem abranger atribuição, mudança de controle, capacidade de suporte, acesso a dados, obrigações cibernéticas, subcontratados, rescisão e assistência à saída. A equipe deve confirmar o papel do fornecedor na operação ou restauração do serviço. Um fornecedor pode possuir um conector, uma chave de criptografia ou um componente de modelo que nenhuma das partes pode reproduzir. Os fornecedores críticos devem ser envolvidos no planeamento sob confidencialidade controlada, com termos comerciais e capacidade de implementação confirmados antes que a transição se torne irreversível.

Evidência e disciplina de escalonamento

Todo risco material deve apontar para a evidência que alteraria sua classificação. O registo deve evitar mitigações circulares, como continuar a monitorizar ou envolver as partes interessadas. Uma mitigação útil indica o documento, teste, consentimento, contrato ou capacidade operacional necessária, quem deve aceitá-lo e quando a decisão da transação muda se estiver ausente. O escritório do programa deve preservar o registro de origem e a aprovação, em vez de depender de uma entrada no painel que pode perder contexto.

A escalada deve seguir as consequências e a autoridade de decisão. Um líder de fluxo de trabalho pode gerenciar riscos de entrega de rotina dentro de um orçamento aprovado. Uma alteração que afete a conformidade da licença, a continuidade dos serviços essenciais, o preço de compra, as condições de fechamento ou o apetite ao risco acordado pertence ao comitê ou conselho diretor da transação. O documento de escalonamento deve indicar o padrão dos factos, as rotas disponíveis, os efeitos financeiros e operacionais, o aconselhamento necessário e o prazo de decisão. Esta disciplina converte o registro de riscos de uma lista administrativa em um instrumento de controle de transações.

O registo final deverá também distinguir entre riscos transferidos, retidos e partilhados. Uma indenização contratual pode alocar perdas financeiras, deixando o comprador exposto à interrupção do serviço. Os seguros podem financiar certas perdas, ao mesmo tempo que deixam inalterada a responsabilidade regulamentar e operacional. O conselho deve, portanto, rever tanto a alocação económica como a capacidade prática de prevenir, detectar e responder ao evento após a sua conclusão.

O registo aprovado deve ser definido na assinatura, atualizado antes da conclusão e reconciliado após cada saída crítica da TSA. Os itens fechados devem reter suas evidências e histórico de aprovação.

Fontes

1. Autoridade da Concorrência e dos Mercados, Orientações para avaliação de fusões, atualizadas em setembro de 2026. Leia a fonte primária
2. Autoridade da Concorrência e dos Mercados, Orientações sobre soluções para fusões, 2025. Leia a fonte primária
3. Ofgem, orientação de melhores práticas de dados. Leia a fonte primária
4. Ofgem, Direção para Orientação de Melhores Práticas de Dados e Estratégia de Digitalização e Orientação do Plano de Ação, 2023. Leia a fonte primária
5. Governo do Reino Unido, definição de Digital Twin, 2025. Leia a fonte primária
6. Governo do Reino Unido, princípios do Programa Nacional de Gémeos Digitais, 2024. Leia a fonte primária
7. Governo do Reino Unido, Estratégia Nacional de Dados. Leia a fonte primária
8. Gabinete do Comissário de Informação, Compartilhamento de dados: um código de prática. Leia a fonte primária
9. Centro Nacional de Segurança Cibernética, Estrutura de Avaliação Cibernética. Leia a fonte primária
10. Centro Nacional de Segurança Cibernética, orientação de Tecnologia Operacional. Leia a fonte primária
11. Ofgem, orientação NIS para Operadores de Serviços Essenciais, atualizada em janeiro de 2026. Leia a fonte primária
12. Departamento de Segurança Energética e Net Zero, Implementação do Regulamento NIS para o setor energético. Leia a fonte primária
13. Governo do Reino Unido, coleção NIS Regulations 2018. Leia a fonte primária
14. Ofwat, Dados abertos na indústria da água. Leia a fonte primária
15. Ofwat, licenças e licenciados. Leia a fonte primária
16. Ofwat, Retornos e dividendos e a barreira regulatória. Leia a fonte primária
17. Ofgem, decisão de revisão da cerca da Energy Networks, 2026. Leia a fonte primária
18. Ofgem, dados de desempenho regulatório RIIO-2 2025, publicados em fevereiro de 2026. Leia a fonte primária
19. Governo do Reino Unido, Lei de Segurança Nacional e Investimento juntamente com requisitos regulamentares. Leia a fonte primária
20. Declaração da Seção 3 da Lei do Governo, Segurança Nacional e Investimento do Reino Unido. Leia a fonte primária
21. Governo do Reino Unido, orientação da Lei NSI para ativos downstream de gás e eletricidade. Leia a fonte primária
22. Relatório Anual do Governo do Reino Unido, da Lei de Segurança Nacional e Investimento de 2024 a 2025. Leia a fonte primária
23. Legislação do Reino Unido, Lei de Segurança Nacional e Investimento de 2021 Regulamentos de Aquisição Notificável. Leia a fonte primária
24. Política de aplicação da Inspecção da Água Potável, Redes e Sistemas de Informação. Leia a fonte primária
25. Autoridade da Concorrência e dos Mercados, casos e projetos de Utilities. Leia a fonte primária
26. OCDE, Princípios OCDE AI. Leia a fonte primária