Separaciones de servicios públicos del Reino Unido: separación de gemelos digitales, datos operativos y activos regulados

1. Definir la decisión de la transacción.

La decisión de la junta es si un negocio de servicios públicos específico puede transferirse a un comprador con un perímetro completo y operable de forma independiente a un valor, asignación de riesgos y cronograma acordados. La respuesta requiere evidencia sobre el servicio regulado, los activos que lo prestan y los sistemas que controlan esos activos. Un límite de entidad legal o un registro de activos fijos es un punto de partida incompleto cuando los datos operativos, las aplicaciones y los equipos de especialistas se comparten en un grupo.

La decisión debería permitir cuatro resultados: proceder con el perímetro propuesto, ampliar el perímetro, rediseñar la arquitectura de transición o posponer la firma hasta que se resuelva una dependencia material. Cada dependencia no resuelta necesita un propietario, una consecuencia de cierre y un efecto de valor cuantificado. Un compromiso genérico de brindar asistencia razonable una vez finalizado brinda poca protección al comprador cuando un modelo, una licencia o una ciberdependencia son esenciales para la continuidad del servicio.

La CMA establece que un paquete de exclusión utilizado como solución de fusión debe contener los activos, funciones y capacidades necesarios para que el comprador opere con éxito y compita eficazmente [1,2]. La misma lógica operativa se aplica a una exclusión voluntaria de servicios públicos. El equipo de transacciones debe comprobar si el comprador recibe un negocio que funcione en lugar de un conjunto de activos.

Marco original. Los requisitos varían según el sector, la licencia, la estructura de la transacción y la dirección regulatoria.

2. Empieza por el servicio regulado

El perímetro debe comenzar con el servicio que debe prestar la entidad autorizada o designada. Las redes de electricidad y gas operan bajo licencias sectoriales y controles de precios. Las empresas de agua operan mediante instrumentos de nombramiento. Esos marcos asignan obligaciones, deberes de información, protecciones financieras y resultados del cliente a entidades definidas [14-18]. Un plan de separación debe asignar cada obligación a los activos, personas, datos y decisiones necesarios para cumplirla.

Este enfoque de dar prioridad al servicio evita dos errores comunes. El vendedor puede asumir que una aplicación es un servicio grupal porque el contrato se encuentra a nivel de matriz, aunque la entidad regulada no pueda operar sin él. El comprador podrá asumir que la propiedad de una subestación, obra de tratamiento o red incluye automáticamente la telemetría, el modelo de ingeniería y los registros históricos necesarios para su gestión. Ninguno de los supuestos establece un perímetro operable.

La sala de pruebas deberá contener un registro de obligaciones reglamentarias. Cada entrada debe identificar la fuente de la obligación, la entidad responsable, el proceso operativo, la tecnología de apoyo, las entradas de datos, los resultados de los informes y el tratamiento propuesto al finalizar. Un regulador puede exigir notificación, consentimiento, modificación de licencia o garantía. El asesoramiento legal debe confirmar el proceso aplicable a la transacción real.

3. Mapear el perímetro legal y regulatorio

El perímetro legal identifica acciones, activos, contratos, licencias, permisos, derechos sobre la tierra, propiedad intelectual y empleados propuestos para su transferencia. El perímetro regulatorio identifica las obligaciones y protecciones que deben seguir siendo efectivas. El perímetro operativo identifica lo que realmente necesita la empresa. Una exclusión sólida reconcilia los tres en lugar de tratar el cronograma legal como la respuesta completa.

Las vallas circulares de servicios públicos añaden restricciones. Las condiciones de la licencia de Ofwat pueden restringir las transacciones con propietarios y asociados, requerir información y proteger la resiliencia financiera [15,16]. El marco de protección de la red de Ofgem busca independencia legal, financiera y operativa para los licenciatarios regulados y restringe los subsidios cruzados y las transferencias de activos que podrían comprometer las obligaciones de licencia. ^[17]. Los equipos de transacciones deben probar los acuerdos entre empresas, los activos compartidos, la mancomunación de efectivo, las garantías, los cargos por servicios y el acceso a los datos frente a las condiciones pertinentes.

También podrá aplicarse el régimen de Seguridad Nacional e Inversiones. La orientación gubernamental explica cómo interactúa el régimen con la regulación del sector e identifica la energía, la infraestructura de datos y otras actividades sensibles [19-23]. La evaluación del perímetro debe considerar el objetivo, el adquirente y el control que se transfiere. El análisis de notificaciones pertenece a la ruta crítica de la transacción y no a una lista de verificación de cierre tardío.

4. Definir activos regulados y derechos asociados

El valor de los activos regulados es una construcción financiera regulatoria más que una lista completa de activos operativos. El informe de Ofgem explica que el RAV refleja la inversión acumulada bajo el marco de control de precios y respalda el cálculo de los rendimientos permitidos. ^[18]. Un perímetro de transacción también debe capturar activos que tienen poco valor contable pero que siguen siendo operativamente esenciales, incluida la lógica de control, los modelos de red, los registros de configuración, las claves cibernéticas, los historiales de mantenimiento y las herramientas especializadas.

El mapa de activos regulados debe conectar cada activo físico con la propiedad, el tratamiento de la licencia, la ubicación, la condición, el valor regulatorio, el valor contable, el deber de mantenimiento, la telemetría, la representación del modelo y la autoridad operativa. Debe registrar los activos propiedad de terceros o compartidos con empresas retenidas. Un derecho de uso puede importar más que un título cuando una interfaz, un circuito de comunicaciones o una licencia de software respaldan un servicio continuo.

El mapa también debe identificar los activos que no pueden transferirse sin consentimiento, novación, modificación de licencia o reconfiguración técnica. El equipo de separación debe evitar una clasificación binaria de transferencia versus retención. Algunos artículos requieren duplicación, acceso transitorio, custodia, sustitución o un nuevo acuerdo operativo. Esos tratamientos necesitan costos, fechas y consecuencias del fracaso.

5. Trate al gemelo digital como una capacidad operativa.

La definición del gobierno del Reino Unido para 2025 requiere que un gemelo digital permanezca vinculado a una contraparte del mundo real, utilice un flujo de datos bidireccional, opere dentro de un sobre de validación establecido y lleve un conjunto de suposiciones. ^[5]. Un modelo tridimensional estático, un panel de control o un registro de activos pueden respaldar el negocio, pero no cumplen esa definición por sí solos. La distinción es importante porque un verdadero gemelo depende de las interfaces en vivo, la calibración, la calidad de los datos y la gobernanza una vez finalizado.

El inventario de separación debe describir la contraparte física, el propósito, el propietario, los usuarios, los datos de origen, las decisiones de salida, la frecuencia de actualización, el sobre de validación, los supuestos, la versión del modelo, la pila de software y el proceso de respaldo para cada gemelo. Debe identificar si el modelo solo avisa a los operadores o envía instrucciones al sistema físico. Un modelo que influye en la configuración de control, los intervalos de mantenimiento o las decisiones de seguridad requiere mayores garantías que una herramienta de planificación visual.

Los principios del Programa Nacional de Gemelos Digitales enfatizan la seguridad, la confiabilidad, la adaptabilidad y la interoperabilidad [6,7]. Por lo tanto, los documentos de transacción deben abordar la procedencia, la validación, el control de cambios y el soporte del ciclo de vida. La entrega del código fuente sin derechos de telemetría, documentación de modelo u operadores calificados puede dejar al comprador con un artefacto inutilizable.

6. Construya el mapa de linaje de datos

Los datos operativos deben rastrearse desde el sensor o el registro de origen hasta cada sistema, transformación, modelo, decisión, informe regulatorio y archivo. El mapa debe mostrar propietario, controlador, procesador, licencia, período de retención, clasificación de seguridad, regla de calidad y uso permitido. También debe identificar lagos de datos grupales, datos maestros compartidos, hojas de cálculo manuales y fuentes de terceros que se encuentran fuera del perímetro legal propuesto.

La guía de mejores prácticas de datos de Ofgem trata los datos como un activo que debe ser detectable, interoperable y regido por obligaciones de licencia [3,4]. Ofwat describe los datos, junto con las personas, los procesos y la tecnología que los respaldan, como un activo importante para el sector del agua. ^[14]. Estas políticas respaldan un diseño de separación en el que los productos de datos tengan propiedad, estándares y responsabilidad claros.

El linaje debe llegar a la capa de decisión. Si un modelo de fuga, pronóstico de interrupción o simulación de red utiliza una característica derivada, el comprador necesita la lógica de transformación y la versión histórica. Si una declaración regulatoria proviene de un mercado de datos, el plan de separación debe preservar la conciliación con la fuente. Una simple exportación de base de datos rara vez satisface estas necesidades.

7. Asignar derechos y responsabilidades sobre los datos

El vendedor puede poseer una base de datos y carecer de derechos irrestrictos para transferir todos los registros. La información del cliente, los datos de los empleados, los datos geoespaciales con licencia, los feeds de proveedores y los registros de ingeniería creados conjuntamente pueden conllevar diferentes restricciones. El comprador necesita un análisis de derechos a nivel de registro o de conjunto de datos para productos de datos materiales. El análisis debe cubrir la propiedad, los derechos de la base de datos, la confidencialidad, la privacidad, las restricciones contractuales y el uso posterior a la finalización por ambas partes.

El código de intercambio de datos de la ICO establece que una fusión o adquisición que implique un cambio de controlador requiere la debida diligencia sobre el propósito original, la base legal, el uso modificado, la transparencia, la gobernanza y la seguridad. ^[8]. Una divulgación en la sala de datos de transacciones no establece permiso para la migración operativa. Las partes deben definir qué transferencias de datos personales se realizarán en el momento de la firma, finalización y salida de la TSA, y cómo se manejarán los derechos y obligaciones de retención de los interesados.

Los datos históricos compartidos pueden respaldar tanto los negocios vendidos como los retenidos. Las partes deben elegir entre transferencia, duplicación, acceso a sala limpia, agregación, anonimización o servicio continuo. El tratamiento elegido debe preservar la evidencia regulatoria y al mismo tiempo limitar su uso a los fines acordados.

8. Separe la tecnología operativa de forma segura

La tecnología operativa incluye el hardware y software que monitorea o controla los procesos físicos. En una empresa de servicios públicos, puede incluir control de supervisión y adquisición de datos, control distribuido, telemetría, protección, unidades terminales remotas, estaciones de trabajo de ingeniería y sistemas de seguridad. La separación cambia las identidades, las redes, el acceso de los proveedores y las responsabilidades en torno a los sistemas que respaldan los servicios esenciales.

El Marco de Evaluación Cibernética del NCSC proporciona una base estructurada para evaluar la seguridad y la resiliencia cibernéticas. ^[9]. Su guía de tecnología operativa reconoce las limitaciones distintivas de seguridad, disponibilidad y ciclo de vida de estos sistemas. ^[10]. La guía NIS 2026 de Ofgem requiere que los operadores identifiquen los sistemas, componentes, interfaces, personas y terceros de los que depende el servicio esencial y gestionen la seguridad durante todo el ciclo de vida de la ingeniería [11,12].

El plan de separación debe clasificar cada conexión como transferencia, duplicación, aislamiento, reemplazo o retiro. Debe especificar la autoridad de identidad final, el modelo de acceso privilegiado, la ruta de soporte remoto, el monitoreo, la respuesta a incidentes y la responsabilidad de recuperación. La transición debe ensayarse en un entorno representativo. Un comprador no debe descubrir después de finalizar que una cuenta de vendedor retenida sigue siendo la única ruta hacia un controlador crítico.

9. Preservar la continuidad de los servicios esenciales

La continuidad es la principal restricción operativa. Los Reglamentos NIS se aplican a los servicios esenciales de energía y agua y requieren medidas adecuadas de seguridad y gestión de incidentes [11-13,24]. Una transacción no puede tratar una interrupción prolongada como un error de migración aceptable. Todo plan de transición necesita un respaldo seguro y una autoridad de decisión definida.

La empresa debe descomponer cada servicio esencial en capacidades operativas mínimas viables. Para cada capacidad, el equipo debe identificar la interrupción máxima tolerable, el respaldo manual, el punto de recuperación de datos, los controles cibernéticos, la dotación de personal, el soporte de proveedores y la ruta de notificación regulatoria. Estos requisitos se convierten en criterios de aceptación para las pruebas de separación.

La preparación del día 1 debe evidenciarse mediante pruebas de escenarios en lugar de informes de estado únicamente. Las pruebas deben cubrir la pérdida de conectividad del vendedor, fallas de las interfaces migradas, credenciales comprometidas, telemetría corrupta, indisponibilidad del proveedor y aprobación regulatoria retrasada. La junta debe recibir hallazgos críticos no resueltos y las mitigaciones específicas requeridas antes de la finalización.

10. Validar modelos antes y después de la transferencia.

Un modelo puede producir resultados técnicamente plausibles dependiendo de un preprocesamiento no documentado, una calibración obsoleta o datos no disponibles. El inventario del modelo debe registrar el propósito, el propietario de la decisión, las entradas, las salidas, el período de capacitación o calibración, el método de validación, los límites de desempeño, el historial de cambios, el proceso de anulación y el respaldo. Los gemelos digitales requieren evidencia adicional sobre la contraparte física y el sobre de validación ^[5].

El equipo de separación debería realizar tres pruebas. La reproducción confirma que el comprador puede generar el mismo producto a partir de los insumos acordados. La portabilidad confirma que el modelo opera en el entorno del comprador con datos y licencias permitidas. La validación operativa confirma que los usuarios calificados pueden interpretar el resultado y reconocer condiciones fuera de los límites del modelo. Pasar una prueba no prueba las demás.

Cuando se utiliza el aprendizaje automático, las partes deben preservar las definiciones de características, los datos de evaluación, los umbrales de seguimiento y la responsabilidad humana. Los principios AI de la OCDE enfatizan la transparencia, la solidez y la rendición de cuentas ^[26]. Los documentos de la transacción deben identificar quién asume el costo y el riesgo si un modelo transferido no puede validarse en el entorno del comprador.

11. Asignar propiedad intelectual y licencias de software.

El patrimonio digital puede incluir modelos propietarios, configuración, scripts, interfaces, software de proveedores, componentes de código abierto y plataformas desarrolladas en grupo. La propiedad y el derecho a operar son cuestiones separadas. Un vendedor puede poseer un código personalizado, mientras que una licencia de un tercero restringe la asignación. Un comprador puede recibir una licencia perpetua pero carecer de las herramientas o conocimientos necesarios para mantener el sistema.

El programa de propiedad intelectual debería vincular cada derecho con los sistemas y procesos que respalda. Debe identificar la disponibilidad del código fuente, los derechos del código objeto, la documentación, los derechos de trabajos derivados, los derechos de datos, las obligaciones de mantenimiento, el depósito en garantía y los límites territoriales. El cronograma también debe registrar las obligaciones de código abierto y cualquier componente cuyos términos requieran la divulgación de la fuente o restrinjan el uso comercial.

Los contratos de software deben revisarse para determinar su asignación, cambio de control, métricas de usuario, alojamiento, exportación de datos, derechos de auditoría, soporte y terminación. Una licencia de vendedor temporal puede respaldar el Día 1, pero la TSA debe contener una ruta de reemplazo financiada y una fecha de salida realista.

12. Diseñar la arquitectura del servicio de transición.

Una TSA gana tiempo para completar la separación. No debería ocultar un modelo operativo objetivo indefinido. Cada servicio necesita alcance, volúmenes, niveles de servicio, reglas de seguridad, cobro, control de cambios, responsabilidad, tratamiento de datos, asistencia de salida y un propietario designado en ambas partes. El catálogo de servicios debe separar las operaciones críticas de los servicios de conveniencia.

Las dependencias deben mapearse a nivel de aplicación y proceso. Un panel operativo puede depender de la gestión de identidades del grupo, un lago de datos compartido, soporte de proveedores, telecomunicaciones y un equipo de análisis retenido. La TSA debe especificar cómo se transferirá o reemplazará cada dependencia. Una fecha de finalización única para todo el catálogo puede generar costos excesivos o una salida prematura.

El comprador debe definir criterios objetivos de salida: conciliación de los datos migrados, pruebas de las interfaces, capacitación de los usuarios, contratación de proveedores, controles cibernéticos aprobados, informes regulatorios elaborados y demostración de la continuidad del servicio. La salida debe regirse a través de la evidencia y la aceptación, con escalada en caso de dependencias perdidas.

Marco original. Los plazos y los controles son hipotéticos y requieren confirmación específica de la transacción.

13. Construir una cibergobernanza independiente

La separación cibernética es un cambio de gobernanza, así como una migración técnica. El comprador se hace responsable de la aceptación de riesgos, las decisiones sobre incidentes, la participación de los reguladores y la supervisión de los proveedores. Las políticas copiadas del vendedor pueden hacer referencia a equipos, herramientas o rutas de derivación no disponibles. El comprador necesita un sistema de control que funcione y que se ajuste a su organización real.

El diseño de gobernanza debe identificar al ejecutivo responsable, las operaciones de seguridad, el liderazgo de seguridad de OT, la función de protección de datos, el comandante del incidente y la presentación de informes a la junta directiva. Debe asignar controles a los sistemas dentro de su alcance y registrar los riesgos residuales. Las cuentas privilegiadas, los certificados, las claves, las herramientas de acceso remoto y los dominios compartidos requieren un tratamiento de transferencia explícito.

El plan de aseguramiento debe combinar revisión del diseño, evidencia de configuración, gestión de vulnerabilidades, pruebas de acceso, ejercicios de recuperación y desafío independiente. Una prueba de penetración por sí sola no puede establecer la resiliencia. Cuando se aplica la regulación de servicios esenciales, el equipo debe alinear la evidencia con el marco actual de la autoridad competente [9,11,24].

14. Cree finanzas excluyentes confiables

Las cuentas de gestión históricas suelen reflejar asignaciones grupales, adquisiciones compartidas, financiación central y servicios que cambian después de la separación. El comprador necesita estados financieros que se concilien con el perímetro propuesto y un modelo de costos independiente que identifique servicios de reemplazo, funciones duplicadas, dessinergias y remediación. Las cuentas regulatorias, las cuentas estatutarias y las cuentas de exclusión de transacciones tienen diferentes propósitos y deben ser unidas.

El modelo debería separar los costos recurrentes independientes de los gastos únicos de separación. Debe identificar el costo inmovilizado del vendedor sin asumir que el comprador lo reembolsará. También debería distinguir los costos ya financiados mediante un control de precios de los costos que pueden requerir un tratamiento regulatorio futuro. El valor regulatorio y el valor empresarial no deben considerarse intercambiables.

Cada ajuste material necesita una fuente, una base, un dueño y una sensibilidad. Los costos de las plataformas de datos, las licencias de software, las operaciones cibernéticas, el soporte de modelos y las telecomunicaciones a menudo están dispersos entre los presupuestos del grupo. El flujo de trabajo del perímetro digital debería alimentar el modelo financiero en lugar de funcionar como un apéndice técnico.

15. Unir el valor regulatorio al valor de transacción

El valor de los activos regulatorios puede anclar el análisis en las transacciones de red porque refleja el tratamiento que el regulador da a las inversiones calificadas. El valor empresarial también refleja los rendimientos permitidos, el rendimiento, los requisitos de capital, la financiación, la calidad del servicio, el crecimiento, el riesgo y las suposiciones del comprador. Una prima o descuento sobre RAV necesita una explicación clara basada en los riesgos y flujos de efectivo esperados.

El puente de valor de separación debería mostrar el efecto del costo independiente, los gastos de separación, los cargos de la TSA, las negociaciones de costos abandonados, el capital requerido, las obligaciones ambientales o de pensiones, la remediación del modelo y el riesgo cibernético. Debería evitar tratar todo gasto digital como creación de valor. Algunos gastos restablecen una capacidad operativa mínima y deben evaluarse como un costo necesario.

El comprador debe probar si los datos y la capacidad digital mejoran los resultados operativos que recompensa el marco regulatorio. El vendedor debe proporcionar evidencia que vincule un modelo o plataforma con decisiones de servicio, costo o inversión. Una narrativa tecnológica sin evidencia operativa medida no debería respaldar una prima de valoración.

Todos los montos son supuestos hipotéticos de gestión en GBP millones. No representan una empresa ni una valoración real.

16. Cuantificar los gastos de separación

Los gastos de separación deben estimarse a partir del mapa de dependencia. Las categorías pueden incluir extracción y limpieza de datos, desarrollo de interfaces, migración a la nube, aislamiento de OT, telecomunicaciones, rediseño de identidad, licencias, portabilidad de gemelos digitales, garantía cibernética, entornos de prueba, ejecución paralela y retención de especialistas. Cada categoría debe tener cantidades, tarifas, contingencias y plazos.

La correlación importa. Una plataforma de identidad retrasada puede retrasar varias aplicaciones. Un derecho de datos en disputa puede impedir la validación del modelo y la presentación de informes regulatorios. Un proveedor crítico puede controlar tanto el soporte de software como la capacidad de integración. El modelo de costos debería preservar estas dependencias en lugar de aplicar contingencias independientes a cada línea.

La gobernanza debe distinguir el crecimiento del alcance del refinamiento de las estimaciones. Cuando la diligencia revela un sistema omitido, el perímetro ha cambiado. Cuando una tarea de migración conocida recibe una cotización más firme, la estimación ha mejorado. Ambos afectan el valor, pero requieren diferentes decisiones del directorio y protección contractual.

17. Llevar a cabo diligencia del comprador en torno a las decisiones.

La diligencia del comprador debe poner a prueba las decisiones que deben tomar la junta directiva y las partes financieras. Debe establecer si el perímetro funciona, qué se debe remediar, cuánto tiempo lleva la independencia y cómo los hallazgos afectan el valor y los documentos. Un cuestionario que produce miles de archivos sin un modelo de dependencia retrasa estas decisiones.

El comprador debe seleccionar recorridos de servicio de extremo a extremo para realizar pruebas. Un caso de red eléctrica podría rastrear una alarma a través de telemetría, control, despacho, gestión de incidentes, comunicación con el cliente e informes regulatorios. Un caso de agua podría rastrear un evento de calidad o fuga desde el sensor hasta la respuesta del operador, los datos de laboratorio, el impacto en el cliente y la evidencia regulatoria. Cada viaje expone dependencias multifuncionales.

Los hallazgos rojos deberían tener consecuencias cuantificadas. Los ejemplos incluyen una condición suspensiva, ajuste del precio de compra, depósito en garantía, indemnización específica, obligación de la TSA, convenio de remediación o derecho de retirada. La junta debería ver qué hallazgos siguen sujetos a confirmación legal, regulatoria o técnica.

18. Prepare el paquete de pruebas del vendedor.

La preparación del vendedor comienza con un modelo de perímetro controlado. Los flujos de trabajo legales, financieros, de operaciones, digitales, cibernéticos, inmobiliarios, fiscales y de personas deben utilizar los mismos identificadores de activos y dependencias. Las listas separadas crean un esfuerzo de reconciliación y permiten que las brechas materiales permanezcan ocultas entre los equipos.

El vendedor debe preparar un índice de pruebas que vincule cada afirmación con una fuente autorizada. Las afirmaciones sobre la independencia del sistema, la propiedad de los datos, la precisión del modelo, el costo del servicio y el tiempo de separación deben ser reproducibles. Las estimaciones de gestión deben etiquetarse con su base y rango. Los datos operativos confidenciales se pueden organizar a través de equipos limpios o entornos controlados.

La preparación temprana puede mejorar el apalancamiento de negociación porque reduce la incertidumbre en torno al activo que se vende. También puede exponer la necesidad de rediseñar el perímetro antes del lanzamiento. El vendedor debe tratar ese resultado como una preparación de la transacción y no como una falta de divulgación.

19. Traducir los hallazgos en documentos de transacción.

El acuerdo de venta debe describir el negocio que se transfiere en términos operativos. Los cronogramas de activos y contratos siguen siendo necesarios, pero las garantías y convenios deben abordar la integridad y usabilidad de los datos, la documentación, las interfaces, las licencias, los modelos y el acceso. Las divulgaciones deben identificar con precisión los límites conocidos.

Las condiciones suspensivas pueden incluir consentimiento regulatorio, autorización NSI, transferencia o modificación de licencia, novación de contrato material y pruebas de separación específicas. Los entregables de finalización pueden incluir extractos de datos conciliados, revocación de acceso, claves, runbooks, documentación de modelos y correspondencia con reguladores. Cuando una dependencia no pueda completarse antes del cierre, la TSA debe incluir los criterios de obligación y salida.

La asignación de riesgos debe seguir al control. Un vendedor que controle la migración antes de su finalización puede correr riesgos de demora y precisión. Un comprador que cambie la arquitectura de destino puede asumir el costo resultante. Las dependencias compartidas requieren mecanismos de gobernanza y disputa. El asesoramiento jurídico específico para cada transacción es esencial.

20. Preparación para el día 1 del gobierno

El día 1 es el primer estado operativo bajo control del comprador. El plan debe identificar qué sistemas, datos, personas y proveedores son propiedad del comprador, proporcionados por el vendedor o que operan bajo acceso temporal. Cada proceso crítico necesita un propietario designado y una ruta de escalada. La continuidad del servicio, la seguridad y el cumplimiento normativo tienen prioridad sobre una migración estéticamente completa.

El panel de preparación debe utilizar puertas basadas en evidencia. Un estatus verde requiere pruebas aprobadas, documentación aprobada y riesgo residual aceptado. El tiempo transcurrido o el porcentaje completado no establece que esté listo. Los defectos críticos deben permanecer visibles para la placa incluso cuando exista una solución alternativa.

La estructura del comando de transición debe definir quién puede detener, continuar o revertir cada migración. Las comunicaciones deben cubrir a los empleados, proveedores, reguladores y clientes cuando corresponda. El primer ciclo de presentación de informes y el ejercicio de incidentes deben planificarse antes de su finalización.

21. Controlar la salida de la TSA

La salida de la TSA transfiere responsabilidad y carga de trabajo. El comprador debe demostrar que posee los contratos relevantes, controla las identidades, recibe los datos requeridos, opera el monitoreo, gestiona incidentes y puede demostrar el cumplimiento normativo. El vendedor debe eliminar el acceso y conservar únicamente los registros que tiene derecho o está obligado a conservar.

La secuencia de salida debe seguir las dependencias. Las aplicaciones corporativas pueden desaparecer antes de tiempo, mientras que el monitoreo OT, las plataformas de datos y los servicios de gemelos digitales permanecen por más tiempo. Los términos comerciales pueden incluir un aumento de los precios para fomentar la salida, pero los precios no deberían forzar una reducción prematura. Los derechos de extensión deben ser limitados, documentados y vinculados a la remediación.

El certificado de salida debe enumerar los servicios aceptados, los defectos no resueltos, las pruebas archivadas, los registros transferidos, el acceso revocado y las obligaciones continuas. La supervisión de la junta debe continuar hasta que todos los servicios críticos hayan salido y hayan pasado las pruebas posteriores a la salida.

22. Aplicar el caso hipotético resuelto.

El vendedor hipotético propone una plataforma regional que contiene redes reguladas, operaciones de campo, interfaces de servicio al cliente, una plataforma de datos operativos y varios modelos digitales. El primer perímetro contiene activos físicos y empleados, pero depende de identidades, datos, modelos y servicios cibernéticos alojados por el vendedor. El comprador identifica GBP 84 million de gastos de separación y aplica un ajuste de riesgo GBP 65 million.

Se prueban tres diseños. El Diseño A transfiere el perímetro físico y legal con una TSA de 18 meses. Tiene el trabajo previo a la finalización más bajo pero el mayor riesgo de dependencia y extensión. El Diseño B duplica las plataformas de identidad y datos centrales antes de su finalización, transfiere derechos de modelo y utiliza TSA específicas. Cuesta más antes de su finalización y alcanza la independencia antes. El Diseño C transfiere la plataforma digital compartida más amplia y los equipos seleccionados. Reduce la duplicación pero crea una separación más compleja de los negocios retenidos.

La junta selecciona el Diseño B como caso de planificación. Esta es una decisión hipotética. El ajuste de valor puede liberar GBP 42 million si el comprador recibe derechos de datos verificados, modelos reproducibles, arquitectura cibernética aprobada y salidas probadas de la TSA antes de los hitos acordados. El ajuste restante cubre la incertidumbre de ejecución que la evidencia hipotética no elimina.

23. Establecer puertas de tablero e informes

La junta debe aprobar el perímetro, el puente de valor, la ruta regulatoria, el modelo del Día 1 y el plan de salida de la TSA en las puertas definidas. Cada puerta debe presentar evidencia, riesgo residual y la decisión solicitada. Los informes deben distinguir entre hechos confirmados, suposiciones de la gestión y elementos pendientes de aprobación externa.

La junta necesita un pequeño conjunto de indicadores operativos: dependencias críticas sin tratamiento financiado, derechos no resueltos, pruebas de migración fallidas, altos riesgos cibernéticos, condiciones regulatorias, servicios de la TSA sin planes de salida, movimiento de costos de separación y valor en riesgo. Los datos detallados del flujo de trabajo deberían permanecer disponibles debajo de esos indicadores.

Los umbrales de escalada deben acordarse antes de firmar. Un cambio en el perímetro regulado, la pérdida de una licencia requerida, la imposibilidad de validar un modelo de control o el fracaso de una prueba de servicio esencial deben devolverse al organismo de aprobación correspondiente. La gobernanza debe permanecer activa una vez finalizado hasta que se verifique la independencia.

Marco original. Las pruebas y los organismos de aprobación deben adaptarse a los documentos reales de gobernanza y transacción.

24. Utilice un plan de acción de noventa días.

Durante los primeros treinta días, designe líderes de flujo de trabajo responsables, confirme el perímetro regulatorio y de servicio, cree identificadores comunes y lance el inventario de dependencia. Identifique asesoramiento regulatorio y NSI, proveedores críticos, conexiones OT compartidas y gemelos digitales. Establecer estándares de evidencia y acceso controlado a la sala de datos.

Durante los días treinta y uno a sesenta, complete mapas de servicios de extremo a extremo, linaje de datos, inventario de modelos, arquitectura objetivo y costos independientes preliminares. Probar el tratamiento propuesto de los sistemas de mayor riesgo. Redactar servicios de la TSA e identificar condiciones suspensivas. Introduzca los resultados cuantificados en los documentos de valoración y transacción.

Durante los días sesenta y uno a noventa, ensaye migraciones críticas, valide la capacidad del comprador, cierre las brechas de derechos materiales y acuerde las pruebas de salida. Presentar a la junta el perímetro completo, puente de valor, riesgos residuales y plan de ejecución cerrado. El cronograma es una secuencia de gestión ilustrativa y debe modificarse para la transacción real.

25. Apéndice A Registro de pruebas de diligencia

El registro de evidencia debe contener el mapa de obligaciones regulatorias, registros de licencias y nombramientos, correspondencia regulatoria, registro de activos, puente RAV, acuerdos entre compañías, catálogo de servicios, mapas de procesos, inventarios de aplicaciones y OT, linaje de datos, registro de modelos, arquitectura cibernética, contratos de proveedores, análisis de derechos, mapa de empleados, cuentas de exclusión, modelo de costos de separación, catálogo de TSA, plan del día 1, evidencia de pruebas y ruta crítica.

Cada elemento debe registrar el propietario, la fuente, la fecha, la versión, el alcance, la restricción de acceso, el estado de validación y la decisión respaldada. Un estado de completo debería requerir un revisor identificado y un criterio de aceptación. Las discrepancias materiales entre registros deben registrarse y resolverse.

El registro debe permanecer activo hasta su finalización y salida de la TSA. Se convierte en el rastro de auditoría de la transacción y reduce la dependencia del conocimiento personal. La información operativa sensible debe permanecer protegida mediante controles de acceso proporcionados.

26. Apéndice B registro de riesgos de separación

El registro de riesgos debe conectar cada dependencia con su probabilidad, impacto, método de detección, mitigación, propietario, fecha de vencimiento y consecuencia contractual. Los riesgos deben expresarse como causa, evento y consecuencia. Por ejemplo, una licencia de software intransferible puede impedir que el comprador opere el modelo de red una vez finalizado, lo que genera una dependencia prolongada de la TSA y costos adicionales.

El registro debe incluir riesgos regulatorios, operativos, de seguridad, de datos, de privacidad, cibernéticos, de modelo, de proveedores, de personas, financieros y de calendario. Se deben identificar los riesgos correlacionados. Una migración de datos fallida puede afectar la validación del modelo, los informes regulatorios y la continuidad operativa al mismo tiempo.

El riesgo residual debe ser aceptado por la persona con autoridad sobre el servicio afectado. Un flujo de trabajo no puede cerrar un riesgo de continuidad del servicio a nivel de junta marcando una acción como completa. El cierre requiere evidencia de que el riesgo se elimina, transfiere o acepta dentro de la tolerancia aprobada.

Riesgos regulatorios y de licencia

El riesgo regulatorio debe identificar la obligación exacta, la autoridad competente, el cambio propuesto y la consecuencia de la transacción. Una entrada amplia, como la aprobación regulatoria, puede ocultar varias cuestiones distintas: análisis de cambio de control, modificación de licencias, compromisos de información, cumplimiento de la delimitación, tratamiento de control de precios y revisión de la seguridad nacional. Cada asunto puede tener un requisito de evidencia y un calendario diferentes. El registro debe mostrar si la acción es un requisito legal, un paso de participación prudente o una suposición de la gestión en espera de asesoramiento.

Los riesgos relacionados con la licencia deben conectarse con el modelo operativo. Una condición de licencia que requiere recursos, registros o independencia operativa puede afectar qué sistemas y personas deben transferirse. Por lo tanto, la mitigación debe indicar la capacidad requerida y cómo se demostrará. Una reunión celebrada con un regulador es una actividad; la confirmación escrita, una modificación aprobada o la finalización de una condición específica es evidencia. El cronograma de transacciones debe incluir tiempo suficiente para preguntas, presentaciones revisadas e implementación de condiciones.

Riesgos de datos y modelos

Los riesgos de los datos deben distinguir entre registros faltantes, mala calidad, derechos inciertos, formatos incompatibles y linaje no disponible. Cada categoría necesita una respuesta diferente. Los registros faltantes pueden requerir reconstrucción o una solución contractual. Los problemas de calidad pueden requerir limpieza y validación. Los problemas de derechos pueden requerir consentimiento, una nueva licencia, anonimización o uso restringido. Los problemas de formato pueden requerir transformación y pruebas paralelas. La falta de linaje puede limitar la capacidad del comprador de reproducir una declaración regulatoria o un resultado modelo.

Los riesgos del modelo deben indicar la decisión afectada. Un modelo de demanda utilizado para la planificación a largo plazo puede tolerar un ciclo de validación diferente al de un modelo de control que cambia la configuración operativa. El registro debe identificar el sobre de validación relevante, las dependencias de entrada, el umbral de rendimiento, los usuarios autorizados y el respaldo. La mitigación debe incluir una prueba de reproducibilidad y una prueba de aceptación operativa en el entorno del comprador. La confirmación del vendedor de que el modelo funcionó exitosamente antes de la separación no prueba que funcionará con los datos, licencias y controles del comprador.

Riesgos operativos y cibernéticos

Los riesgos operativos deben probarse a través de viajes de servicio. Una dependencia puede parecer menor en el inventario de una aplicación mientras se encuentra en el único camino entre una alarma y una respuesta del operador. El registro debe identificar la interrupción máxima tolerable y el retroceso manual. Si no existe un recurso seguro, la dependencia pertenece a la ruta crítica y puede requerir duplicación o soporte continuo del vendedor hasta que se demuestre la capacidad del comprador.

Los riesgos cibernéticos deben cubrir el acceso, la segmentación, el seguimiento, la recuperación, la conectividad de los proveedores, los certificados, las claves de cifrado y la responsabilidad por incidentes. Los dominios administrativos compartidos y las rutas de soporte remoto merecen entradas específicas porque pueden preservar el control no deseado una vez finalizados. La mitigación debe definir el estado objetivo, la secuencia de transición, la prueba, la evidencia y la reversión. El comprador deberá recibir un registro vigente de acceso privilegiado y confirmar la revocación o reasignación en el punto acordado.

Riesgos financieros y de valoración

Los riesgos financieros deben conciliar el perímetro con las cuentas históricas y el plan independiente. Una asignación de costes puede desaparecer de las cuentas de gestión del vendedor sin desaparecer del negocio. El registro debe identificar el servicio que se reemplaza, el volumen esperado, el proveedor o recurso interno, el costo de implementación y el costo estacionario. También debe registrar por separado los costos del vendedor varado porque esos costos no pertenecen automáticamente al comprador.

Los riesgos de valoración deben vincularse directamente al modelo. Si un derecho de datos sigue siendo incierto, el modelo debe mostrar el costo de reemplazo, el impacto operativo y el rango de cronograma. Si la salida de la TSA falla, el modelo debería mostrar cargos adicionales, costos duplicados y cualquier sinergia retrasada. Un ajuste de riesgo debe publicarse sólo cuando se entreguen pruebas acordadas. Este enfoque hace que el ajuste sea auditable y reduce las discusiones sobre si una acción está completa.

Riesgos de personas y proveedores

Los riesgos de las personas deben identificar roles, nombrar titulares cuando corresponda, tratamiento de transferencia, necesidades de retención, autorización de seguridad, responsabilidad de guardia y concentración de conocimientos. Un experto en la materia compartido puede respaldar a varias empresas y no poder transferirse. La mitigación puede requerir documentación, seguimiento, contratación, un acuerdo de servicios o un perímetro diferente. Los bonos de finalización por sí solos no crean capacidad de compra a menos que la persona y el conocimiento estén disponibles cuando sea necesario.

Los riesgos de los proveedores deben cubrir la asignación, el cambio de control, la capacidad de soporte, el acceso a los datos, las obligaciones cibernéticas, los subcontratistas, la rescisión y la asistencia de salida. El equipo debe confirmar el papel del proveedor en la operación o restauración del servicio. Un proveedor puede poseer un conector, una clave de cifrado o un componente de modelo que ninguna de las partes puede reproducir. Los proveedores críticos deben participar en la planificación bajo confidencialidad controlada, con condiciones comerciales y capacidad de implementación confirmadas antes de que la transición se vuelva irreversible.

Disciplina de evidencia y escalada

Todo riesgo material debe señalar la evidencia que cambiaría su calificación. El registro debe evitar mitigaciones circulares, como continuar monitoreando o involucrar a las partes interesadas. Una mitigación útil establece el documento, prueba, consentimiento, contrato o capacidad operativa requerida, quién debe aceptarlo y cuándo cambia la decisión de la transacción si está ausente. La oficina del programa debe preservar el registro fuente y la aprobación en lugar de depender de una entrada del panel que pueda perder contexto.

La escalada debe seguir la consecuencia y la autoridad de decisión. Un líder del flujo de trabajo puede gestionar el riesgo de entrega de rutina dentro de un presupuesto aprobado. Un cambio que afecte el cumplimiento de la licencia, la continuidad del servicio esencial, el precio de compra, las condiciones de cierre o el apetito de riesgo acordado corresponde al comité o junta directiva de la transacción. El documento de escalada debe indicar el patrón de hechos, las rutas disponibles, los efectos financieros y operativos, el asesoramiento requerido y la fecha límite para tomar la decisión. Esta disciplina convierte el registro de riesgos de una lista administrativa en un instrumento de control de transacciones.

El registro final también debería distinguir entre riesgo transferido, retenido y compartido. Una indemnización contractual puede asignar una pérdida financiera y dejar al comprador expuesto a la interrupción del servicio. Los seguros pueden financiar ciertas pérdidas sin modificar la responsabilidad regulatoria y operativa. Por lo tanto, la junta debería revisar tanto la asignación económica como la capacidad práctica para prevenir, detectar y responder al evento una vez finalizado.

El registro aprobado debe basarse en el momento de la firma, actualizarse antes de completarse y conciliarse después de cada salida crítica de la TSA. Los elementos cerrados deben conservar su evidencia y su historial de aprobación.

Fuentes

1. Autoridad de Mercados y Competencia, Directrices para la evaluación de fusiones, actualizadas en septiembre de 2026. Lea la fuente principal
2. Autoridad de Competencia y Mercados, Orientación sobre soluciones para fusiones, 2025. Lea la fuente principal
3. Ofgem, Guía de mejores prácticas de datos. Lea la fuente principal
4. Ofgem, Dirección de orientación sobre mejores prácticas de datos y orientación sobre estrategias y planes de acción de digitalización, 2023. Lea la fuente principal
5. Gobierno del Reino Unido, definición de gemelo digital, 2025. Lea la fuente principal
6. Gobierno del Reino Unido, Principios del Programa Nacional de Gemelos Digitales, 2024. Lea la fuente principal
7. Gobierno del Reino Unido, Estrategia Nacional de Datos. Lea la fuente principal
8. Oficina del Comisionado de Información, Intercambio de datos: un código de práctica. Lea la fuente principal
9. Centro Nacional de Seguridad Cibernética, Marco de Evaluación Cibernética. Lea la fuente principal
10. Centro Nacional de Ciberseguridad, orientación de Tecnología Operativa. Lea la fuente principal
11. Ofgem, guía NIS para operadores de servicios esenciales, actualizada en enero de 2026. Lea la fuente principal
12. Departamento de Seguridad Energética y Net Zero, Implementación del Reglamento NIS para el sector energético. Lea la fuente principal
13. Gobierno del Reino Unido, colección de Reglamentos NIS de 2018. Lea la fuente principal
14. Ofwat, Datos abiertos en la industria del agua. Lea la fuente principal
15. Ofwat, Licencias y licenciatarios. Lea la fuente principal
16. Ofwat, Rentabilidades y dividendos y la barrera regulatoria. Lea la fuente principal
17. Ofgem, Decisión de revisión del Ring-fence de Energy Networks, 2026. Lea la fuente principal
18. Ofgem, datos de desempeño regulatorio RIIO-2 2025, publicados en febrero de 2026. Lea la fuente principal
19. Gobierno del Reino Unido, Ley de Inversión y Seguridad Nacional junto con los requisitos reglamentarios. Lea la fuente principal
20. Declaración de la Sección 3 de la Ley de Inversiones, Seguridad Nacional y Gobierno del Reino Unido. Lea la fuente principal
21. Gobierno del Reino Unido, orientación de la Ley NSI para activos downstream de gas y electricidad. Lea la fuente principal
22. Informe anual de la Ley de Inversión, Seguridad Nacional y Gobierno del Reino Unido de 2024 a 2025. Lea la fuente principal
23. Legislación del Reino Unido, Ley de Inversiones y Seguridad Nacional de 2021 Reglamento de adquisiciones notificables. Lea la fuente principal
24. Política de aplicación de la Inspección de Agua Potable, Redes y Sistemas de Información. Lea la fuente principal
25. Autoridad de Competencia y Mercados, Casos y proyectos de Utilities. Lea la fuente principal
26. OCDE, Principios OCDE AI. Lea la fuente principal