Conoce las diferencias entre telemetría, SCADA e IoT, cómo viaja el dato industrial y qué arquitectura, protocolos, alarmas y controles de ciberseguridad necesita una operación energética.
La alarma llegó doce minutos después.
Para el tablero ejecutivo fue un retraso menor. Para la operación, fue suficiente para que una desviación de presión dejara de ser una anomalía y se convirtiera en un paro.
El sensor había medido. La RTU había recibido la señal. La red celular seguía activa y la plataforma mostraba gráficas. Sin embargo, la arquitectura no había definido qué equipo debía responder, cuánto retraso era aceptable, quién recibiría la alarma ni qué ocurriría cuando el enlace principal perdiera calidad.
La instalación tenía sensores, telemetría, una plataforma en la nube y un tablero moderno.
No tenía una cadena de control completa.
Esta diferencia explica muchos proyectos tecnológicos en energía: se compra un componente visible —un medidor, un gateway, una licencia, una pantalla o un servicio cloud— antes de definir la secuencia que realmente genera valor.
Una operación energética moderna no se controla porque produzca más datos. Se controla cuando cada medición puede convertirse en una señal válida, una acción segura, una alarma atendible, un histórico confiable y una evidencia recuperable.
La telemetría transporta datos; el SCADA organiza la supervisión y el control de alto nivel; el IoT conecta dispositivos y aplicaciones para intercambiar o analizar información.
Las tres tecnologías pueden coexistir, pero no son intercambiables.
El artículo matriz Medición energética en México: telemetría, control, software y cumplimiento para empresas presenta estos elementos como parte del ecosistema tecnológico. La pregunta que sigue es más difícil: ¿cómo deben integrarse para que una instalación siga operando, genere evidencia y no dependa de una conexión frágil?
| Componente | Función principal | No debe confundirse con |
|---|---|---|
| Sensor o transmisor | Mide una variable y la convierte en señal | Sistema completo de control |
| Actuador | Ejecuta una acción física | Sensor |
| PLC | Ejecuta control lógico local | SCADA |
| RTU | Adquiere señales y ejecuta control en activos remotos | Gateway genérico |
| IED | Protege, mide o controla sistemas eléctricos | Medidor común |
| DCS | Controla procesos continuos o complejos dentro de una planta | SCADA remoto |
| Telemetría | Transmite remotamente mediciones, estados o eventos | Control automático |
| SCADA | Supervisa, adquiere datos y ejecuta control de alto nivel | PLC o nube |
| HMI | Presenta información y controles al operador | Base histórica |
| Historian | Conserva series de tiempo operativas | Sistema transaccional |
| Gateway edge | Integra, filtra, normaliza o traduce protocolos | Controlador de seguridad certificado |
| IoT o IIoT | Conecta dispositivos y aplicaciones | SCADA por definición |
| EMS | Gestiona energía, demanda, consumo y desempeño | SCADA industrial general |
| BMS | Automatiza edificios e instalaciones | DCS de proceso |
| MES | Gestiona la ejecución productiva | ERP |
| ERP | Gestiona procesos empresariales y transaccionales | Control en tiempo real |
El recorrido básico puede representarse así:
Variable física → sensor → señal → PLC, RTU o IED → protocolo y red → SCADA o HMI → alarma, histórico o control → integración → decisión operativa → registro y evidencia.
Cada paso introduce una responsabilidad y una posibilidad de error.
| Etapa | Responsable principal | Error posible | Validación | Consecuencia | Respaldo | Evidencia |
|---|---|---|---|---|---|---|
| Variable física | Operación e ingeniería de proceso | Variable mal definida o punto no representativo | Revisión del proceso y análisis de riesgo | Se controla el indicador equivocado | Medición redundante cuando la criticidad lo justifique | Diagramas, bases de diseño y criterios operativos |
| Sensor o transmisor | Instrumentación | Rango incorrecto, deriva, saturación o instalación deficiente | Calibración, pruebas y comparación | Dato falso o pérdida de sensibilidad | Redundancia, diagnóstico o medición manual | Certificados, hojas de datos y registros de mantenimiento |
| Señal | Instrumentación y control | Ruido, cableado, escalamiento o polaridad incorrecta | Prueba de lazo | Lectura inestable o invertida | Diagnóstico local y canales alternos | Loop check y planos de conexión |
| PLC, RTU o IED | Automatización y protecciones | Lógica defectuosa, configuración incorrecta o reloj desajustado | FAT, SAT, simulación y revisión de lógica | Acción equivocada o ausencia de respuesta | Backups, redundancia y modo manual | Versiones, lógica, matriz causa-efecto y bitácora de cambios |
| Red y protocolo | Telecomunicaciones y OT | Pérdida, demora, duplicado, desconexión o ruta no segura | Monitoreo, pruebas de redundancia y diagnóstico | Información tardía o control no disponible | Segundo enlace, buffer local y store and forward | Logs, topología, eventos y disponibilidad |
| SCADA o HMI | Operaciones | Tag equivocado, pantalla ambigua o permiso excesivo | Pruebas de operación y revisión de usuarios | Interpretación o maniobra incorrecta | Estación redundante y procedimientos locales | Eventos, comandos, reconocimientos y sesiones |
| Alarma | Operación y dueño del proceso | Prioridad incorrecta, repetición o falta de responsable | Racionalización y revisión de desempeño | Respuesta tardía o fatiga del operador | Escalamiento y procedimientos | Evento, reconocimiento, acción y cierre |
| Historian | OT y gestión de datos | Pérdida de contexto, resolución insuficiente o retención corta | Comparación con fuente y auditoría de calidad | Análisis incompleto | Replicación, respaldo y almacenamiento local | Series de tiempo, banderas de calidad y metadatos |
| Integración | OT, IT y propietario de aplicación | Mapeo equivocado o actualización asíncrona | Conciliación y pruebas de interfaz | Reportes o transacciones incorrectas | Colas, reintentos y reconciliación | Logs de interfaz y versiones |
| Decisión | Operador, supervisor o responsable de negocio | No actuar o actuar fuera de procedimiento | Indicadores, revisión posterior y segregación de funciones | Pérdida, daño o incumplimiento | Escalamiento y contingencia | Bitácora, orden de trabajo o autorización |
La arquitectura empieza donde existen presión, temperatura, flujo, nivel, voltaje, corriente, vibración, posición, composición o calidad de energía.
La primera decisión no es qué sensor comprar, sino qué condición debe conocerse para controlar un riesgo o tomar una decisión.
Los sensores, transmisores, medidores, analizadores, actuadores y válvulas convierten el proceso en señales y las señales en acciones.
Un sistema de alta tecnología no puede corregir una mala selección de rango, una instalación incorrecta, una calibración vencida o un punto de medición que no representa el proceso.
El PLC, la RTU, el IED o el DCS ejecutan interlocks, secuencias, protecciones, control PID y lógica local.
Las funciones críticas no deberían depender de un servicio en la nube o de una comunicación remota. Cuando la red falla, el controlador debe mantener el proceso dentro de su diseño operativo o llevarlo a una condición segura.
La señal puede viajar por fibra, radio, celular, satélite, Ethernet o enlaces seriales. La selección depende de distancia, disponibilidad, entorno, ancho de banda, criticidad y capacidad de recuperación.
La comunicación primaria y secundaria no debe compartir inadvertidamente el mismo punto de falla: energía, torre, ducto, proveedor, equipo de borde o ruta física.
El SCADA y la HMI presentan estados, tendencias, alarmas y controles al operador. Una pantalla debe ayudar a comprender la situación, no llenar el monitor con valores sin jerarquía.
El historian conserva valores, sellos de tiempo, calidad y contexto. OPC UA, middleware, APIs, brokers y gateways edge permiten llevar información hacia otras aplicaciones sin conectar cada sistema directamente con cada controlador.
EMS, mantenimiento, calidad, inventarios, analítica, optimización y cumplimiento utilizan los datos de operación. Ninguna aplicación debe asumir que todos los datos tienen la misma resolución, disponibilidad o confiabilidad.
MES, ERP, facturación, contratos, auditoría y tableros ejecutivos necesitan información resumida y contextualizada. No requieren acceso directo irrestricto a PLC, RTU o IED.
La calidad del sistema completo está limitada por la calidad de su punto de medición.
Antes de seleccionar instrumentación deben definirse:
El PLC ejecuta ciclos de lógica en una instalación local. La RTU suele estar orientada a sitios remotos, adquisición distribuida y comunicaciones de campo. El IED combina funciones eléctricas especializadas como protección, medición, control y registro de eventos.
La diferencia no es únicamente de forma o fabricante. Es de función, entorno, criticidad y arquitectura.
| Protocolo | Ámbito típico | Fortalezas | Limitaciones | Seguridad | Interoperabilidad |
|---|---|---|---|---|---|
| Modbus | Instrumentos, variadores, PLC, medidores y equipos industriales | Simple, extendido y fácil de implementar | Modelo de datos básico y dependencia de mapas de registros | Las implementaciones tradicionales requieren controles complementarios | Amplia, pero debe comprobarse el mapeo específico de cada dispositivo |
| DNP3 | Electricidad, agua, petróleo, gas y activos remotos | Eventos, marcas de tiempo y comunicaciones remotas robustas | Mayor complejidad de ingeniería y configuración | Cuenta con extensiones de autenticación y seguridad; deben verificarse las capacidades implementadas | Alta cuando se aplican perfiles y pruebas de conformidad |
| IEC 60870-5-101/104 | Telecontrol eléctrico | Uso extendido en utilities y centros de control | Requiere perfiles, ingeniería y medidas de seguridad complementarias | Debe combinarse con arquitectura y estándares de seguridad aplicables | Depende de perfiles y pruebas entre equipos |
| IEC 61850 | Subestaciones y automatización de sistemas eléctricos | Modelos semánticos, ingeniería estructurada y comunicación entre IED | Mayor exigencia de ingeniería, configuración y pruebas | La familia IEC 62351 aporta mecanismos de seguridad para protocolos del sector eléctrico | Diseñada para interoperabilidad, pero ésta debe verificarse en cada proyecto |
| OPC UA | Integración entre control, aplicaciones y empresa | Modelos estructurados, independencia de plataforma y seguridad configurable | Una mala configuración puede eliminar las ventajas de seguridad | Incluye autenticación, autorización, integridad y confidencialidad | Alta cuando se utilizan perfiles y modelos compatibles |
| MQTT | IIoT, edge, activos remotos y aplicaciones de datos | Ligero, publish/subscribe y eficiente para redes restringidas | No reemplaza por sí solo funciones SCADA, control o semántica del activo | Depende de autenticación, cifrado, configuración del broker y arquitectura | Alta a nivel de mensajería; el modelo de datos debe diseñarse |
| HART | Instrumentación inteligente sobre señales de proceso | Diagnóstico y variables digitales sobre infraestructura de instrumentación | Ancho de banda limitado frente a redes modernas | Requiere protección en gateways, activos y redes superiores | Amplia en instrumentación compatible |
| Propietarios | Equipos y plataformas específicas | Pueden ofrecer funciones especializadas | Dependencia tecnológica y dificultad de migración | Variable y sujeta al fabricante | Limitada si no existen interfaces documentadas |
Modbus, DNP3, IEC 61850, OPC UA y MQTT no compiten necesariamente por la misma función. Una instalación puede utilizar un protocolo en campo, otro para telecontrol, OPC UA para integración y MQTT para distribución de datos hacia aplicaciones.
La pregunta no es cuál es el mejor protocolo. La pregunta es qué función debe cumplir, qué información debe conservar, qué seguridad soporta la implementación concreta y cómo se probará la interoperabilidad.
La HMI es la interfaz del operador. El SCADA agrega adquisición, supervisión, alarmas, eventos, permisos y control de alto nivel. El historian conserva las series de tiempo para análisis y reconstrucción.
Una operación necesita responder tres preguntas diferentes:
Un SCADA sin historian puede mostrar el presente, pero limita el análisis posterior. Un historian sin banderas de calidad puede conservar valores que parecen válidos aunque provengan de una comunicación perdida, una sustitución manual o un dato congelado.
El IIoT permite conectar sensores, gateways, brokers y aplicaciones para distribuir datos a mayor escala. El edge procesa o filtra información cerca del activo. La nube ofrece almacenamiento, analítica y acceso remoto a servicios.
Ninguno de estos componentes debe desplazar automáticamente el control local.
El edge puede:
La nube puede:
Pero una arquitectura moderna debe responder antes de conectarse:
La calidad del dato debe diseñarse, no suponerse.
Cada tag debería contar con:
También deben identificarse estados que suelen perderse en los tableros:
“Tiempo real” no significa latencia cero. Significa que la actualización es suficientemente oportuna para la función que debe cumplirse.
| Uso | Necesidad de actualización | Consecuencia del retraso | Disponibilidad requerida |
|---|---|---|---|
| Protección | Muy alta y definida por la función de protección | Daño a equipos o riesgo a personas | Crítica |
| Control local | Alta y dependiente de la dinámica del proceso | Inestabilidad o pérdida de control | Crítica |
| Supervisión | Según el activo y la respuesta esperada | Respuesta tardía | Alta |
| Mantenimiento | Media o alta según el diagnóstico | Análisis incompleto | Media o alta |
| Reporte ejecutivo | Baja | Decisión desactualizada | Media |
| Cumplimiento | Según la disposición aplicable | Evidencia insuficiente | Alta |
Una alarma debe indicar una condición anormal que requiere una respuesta del operador dentro de un tiempo determinado.
Debe contar con:
Las alarmas repetitivas, permanentes o sin acción definida erosionan la atención del operador. Por eso la gestión de alarmas debe tratarse como un ciclo de vida y no como una lista de umbrales.
| Alarma | Variable | Umbral o lógica | Consecuencia | Responsable | Acción | Evidencia |
|---|---|---|---|---|---|---|
| Desviación de proceso | Definida por la instalación | Debe derivarse del diseño y análisis de riesgo | Operativa, ambiental, económica o de seguridad | Operador o área asignada | Procedimiento aprobado | Evento, reconocimiento, acción y cierre |
| Pérdida de comunicación | Estado del enlace | Tiempo y condición definidos por criticidad | Pérdida de visibilidad o control remoto | Operación y telecomunicaciones | Activar respaldo o modo degradado | Logs, tiempos, ruta y recuperación |
| Dato congelado | Variación y sello temporal | Lógica contextual, no un umbral universal | Decisión basada en información obsoleta | Instrumentación u OT | Validar fuente y sustituir sólo bajo procedimiento | Bandera de calidad y corrección documentada |
| Instalación | Variables | Control local | Supervisión | Integración | Evidencia | Riesgo principal |
|---|---|---|---|---|---|---|
| Subestación | Voltaje, corriente, frecuencia, estados, protecciones y calidad | IED, relevadores y automatización local | SCADA eléctrico | Centro de control, historian y gestión de activos | Eventos, oscilografías, comandos y medición | Operación insegura o pérdida de coordinación |
| Central o parque renovable | Potencia, disponibilidad, meteorología y estado de equipos | PLC, controladores e inversores | SCADA de planta | Pronóstico, EMS, mantenimiento y centro de control | Producción, eventos y disponibilidad | Pérdida de generación o incumplimiento operativo |
| Ducto | Presión, flujo, temperatura, válvulas y estaciones | RTU, PLC, interlocks y control de válvulas | SCADA geográficamente distribuido | Balance, mantenimiento y gestión de integridad | Históricos, comandos, alarmas y bitácoras | Fuga, sobrepresión o pérdida de visibilidad |
| Refinería | Presión, temperatura, flujo, nivel, composición y vibración | DCS, PLC, SIS y control PID | HMI y supervisión de planta | Historian, mantenimiento, laboratorio y producción | Variables, alarmas, cambios y secuencias | Desviación de proceso o incidente |
| Terminal o estación de combustible | Recepción, volumen, inventario, temperatura y despacho | PLC, controladores y sistemas de medición | SCADA o plataforma operativa | Inventarios, conciliación, facturación y control volumétrico | Registros, movimientos y reportes | Diferencia de inventario o evidencia insuficiente |
| Data center | Demanda, calidad de energía, temperatura, humedad, UPS y respaldo | BMS, PLC, controladores de UPS y enfriamiento | BMS, EMS, DCIM o SCADA especializado | Mantenimiento, capacidad y tableros | Eventos, disponibilidad y consumo | Interrupción, sobretemperatura o pérdida de redundancia |
| Planta industrial | Energía, demanda, producción, aire, vapor, agua y proceso | PLC o DCS | SCADA y HMI | MES, EMS, mantenimiento y ERP | Producción, consumo, alarmas y cambios | Paro, sobrecosto o baja calidad |
En México, los requerimientos de telemetría, telecontrol y transferencia de información del sector eléctrico deben revisarse contra el marco vigente del SEN y del Mercado Eléctrico Mayorista. El Manual de Requerimientos de TIC publicado en 2017 incluye disposiciones sobre telemetría directa para SCADA y responsabilidades de infraestructura, pero su vigencia y modificaciones deben comprobarse nuevamente antes de utilizarlo como fundamento regulatorio en enero de 2027.
Un PLC, una RTU o un servidor SCADA no deberían conectarse directamente a internet.
La protección debe construirse por capas:
NIST SP 800-82 Rev. 3 enfatiza que los controles de seguridad deben adaptarse a los requisitos de desempeño, confiabilidad y seguridad física de la tecnología operacional. La serie ISA/IEC 62443 complementa este enfoque mediante requisitos para activos, sistemas, integradores, proveedores y operadores.
El acceso remoto de un proveedor debe ser:
En energía, una señal puede terminar convertida en evidencia comercial, operativa, fiscal o regulatoria.
El Manual de Medición para Liquidaciones del Mercado Eléctrico Mayorista establece requisitos para sistemas de medición que producen información utilizada en procesos de liquidación.
En hidrocarburos y petrolíferos, los controles volumétricos exigen revisar la Resolución Miscelánea Fiscal, sus anexos, las estructuras de archivos y las disposiciones vigentes en el periodo aplicable. No debe suponerse que una arquitectura técnica cumple sólo porque exporta un archivo XML o JSON.
La evidencia necesita:
El control local, las protecciones y los interlocks deberían continuar. Los datos pueden almacenarse temporalmente en RTU, PLC, gateway edge o historian local y reenviarse después.
Los controladores locales deben mantener las secuencias y funciones esenciales. La operación puede pasar a HMI local o modo manual, según el diseño y los procedimientos.
Sí, cuando la lógica, las entradas, las salidas y los servicios necesarios permanecen disponibles. No debe suponerse que todas las funciones externas seguirán operativas.
La arquitectura puede usar buffers locales, store and forward, historian redundante, replicación y respaldos. Debe definirse qué ocurre con duplicados, datos fuera de secuencia y sellos temporales después de la reconexión.
La organización debe definir roles, permisos, condiciones, segregación de funciones y registro de comandos.
Mediante respaldos probados, historización redundante, logs, sincronización, retención documentada y procedimientos de restauración.
| Criterio | Evidencia solicitada |
|---|---|
| Arquitectura | Diagrama, lista de componentes, flujos y límites de responsabilidad |
| Experiencia | Proyectos verificables y referencias comparables |
| Protocolos | Matriz de compatibilidad y alcance de pruebas |
| Disponibilidad | Diseño de redundancia y análisis de puntos únicos de falla |
| Seguridad | Diseño alineado con estándares y análisis de riesgos |
| Datos | Propiedad, exportación, formatos, calidad y retención |
| Alarmas | Filosofía, matriz, responsables y procedimiento de racionalización |
| Pruebas | Protocolos FAT, SAT y puesta en servicio |
| Capacitación | Plan, materiales, perfiles y evaluación |
| Soporte | SLA, horarios, escalamiento y tiempos contractuales |
| Ciclo de vida | Versiones, actualizaciones, obsolescencia y migración |
| Refacciones | Disponibilidad, tiempos y equivalencias |
| Acceso remoto | Procedimiento seguro, temporal y auditable |
| Documentación | Planos, respaldos, manuales, listas de tags y configuraciones |
| Integración | Interfaces, pruebas, propietarios y manejo de errores |
No debe elegirse un proveedor sólo por la cantidad de marcas que distribuye. El criterio central es si puede demostrar una arquitectura coherente, responsabilidades claras, interoperabilidad probada, seguridad, soporte y capacidad de entregar documentación recuperable.
| Componente de costo | Qué incluye | Riesgo de subestimarlo |
|---|---|---|
| Instrumentación | Sensores, transmisores, medidores y analizadores | Datos insuficientes o equipos inadecuados |
| Gabinetes y control | PLC, RTU, IED, fuentes, protección y acondicionamiento | Fallas, capacidad limitada o ampliación costosa |
| Comunicaciones | Fibra, radio, celular, satélite, switches y redundancia | Pérdida de disponibilidad |
| Licencias | SCADA, historian, drivers, clientes, servidores y módulos | Costos recurrentes y restricciones de crecimiento |
| Ingeniería | Diseño, listas de señales, lógica, alarmas, pantallas y documentación | Integración deficiente |
| Instalación | Cableado, montaje, energía, red y obra asociada | Retrasos y fallas de campo |
| Pruebas | FAT, SAT, loop checks, interoperabilidad y contingencia | Errores descubiertos durante la operación |
| Ciberseguridad | Segmentación, DMZ, acceso, monitoreo, respaldo y respuesta | Exposición del proceso |
| Capacitación | Operadores, mantenimiento, ingeniería y administradores | Dependencia del integrador |
| Mantenimiento | Calibración, refacciones, diagnóstico y actualizaciones | Degradación progresiva |
| Almacenamiento | Históricos, respaldos, replicación y retención | Pérdida de evidencia o crecimiento no previsto |
| Conectividad | Servicios de telecomunicaciones y enlaces alternos | OPEX recurrente y dependencia |
| Obsolescencia | Fin de soporte, sistemas operativos, hardware y protocolos | Migración urgente |
| Dependencia tecnológica | Formatos, interfaces y licenciamiento propietario | Costos de salida y baja competencia |
No existe un costo universal para implementar SCADA. Depende del número de señales, criticidad, dispersión geográfica, redundancia, comunicaciones, regulación, seguridad, disponibilidad y sistemas que deban integrarse.
Una gráfica puede demostrar que una variable cambió. Una arquitectura de control debe responder qué ocurrió después.
¿El controlador actuó? ¿La alarma llegó? ¿El operador entendió la consecuencia? ¿La comunicación falló? ¿El dato quedó almacenado? ¿La organización puede reconstruir la secuencia? ¿Existe evidencia suficiente para una auditoría?
Telemetría, SCADA e IoT generan valor cuando forman parte de una cadena operativa diseñada alrededor de una decisión.
El sensor mide.
El controlador responde.
La red transporta.
El SCADA supervisa.
El historian conserva.
Las aplicaciones contextualizan.
El operador decide.
La organización demuestra.
Una operación moderna no es la que conecta más dispositivos.
Es la que puede seguir funcionando, comprender lo que ocurre, responder a tiempo y conservar evidencia incluso cuando una parte de la arquitectura falla.
Es la adquisición y transmisión remota de mediciones, estados o eventos desde un activo hacia un sistema de supervisión o almacenamiento.
Es una arquitectura de supervisión, control de alto nivel y adquisición de datos que presenta estados, tendencias, alarmas y eventos de activos industriales o energéticos.
SCADA se orienta a la operación, supervisión, alarmas y control industrial. IoT conecta dispositivos y aplicaciones para intercambiar información. Un sistema IoT no incluye necesariamente funciones de control, seguridad operativa o gestión de alarmas.
Un PLC se utiliza principalmente para control lógico local. Una RTU suele concentrar adquisición y control en sitios remotos y está diseñada para operar con comunicaciones de campo y activos distribuidos.
No. Un SCADA puede operar sobre redes industriales privadas, fibra, radio u otras comunicaciones sin conexión a internet.
Sí. La nube es una opción de infraestructura o integración, no un requisito del SCADA.
Es un sistema especializado en conservar series de tiempo operativas con sellos temporales, calidad, compresión, consulta y contexto.
Es una arquitectura y estándar de interoperabilidad independiente de plataforma que permite intercambiar información estructurada entre dispositivos, sistemas de control y aplicaciones empresariales.
Los que requieran una respuesta o conocimiento oportuno según la criticidad del proceso. No todos los datos necesitan la misma frecuencia ni latencia.
Con inventario, segmentación, zonas y conductos, DMZ industrial, control de acceso, mínimo privilegio, acceso remoto seguro, respaldos, monitoreo, gestión de cambios y planes de recuperación.
Debe demostrar arquitectura, experiencia verificable, compatibilidad, pruebas, ciberseguridad, soporte, documentación, ciclo de vida y reglas claras sobre propiedad de los datos.
No existe un precio universal. Depende de señales, sitios, comunicaciones, redundancia, licencias, integración, seguridad, pruebas y soporte.
El control local debería continuar según el diseño. Los datos pueden almacenarse localmente y transmitirse después mediante mecanismos de store and forward.
El contrato debe establecerlo expresamente. La empresa operadora debería conservar capacidad de acceso, exportación, respaldo y migración de sus datos operativos.
Todos los campos son obligatorios *
Comentarios