Una válvula es física. Pero la orden que la abre puede pasar por un PLC, una red industrial, una estación de ingeniería y un sistema de control antes de convertirse en movimiento. La misma digitalización que permite medir mejor, automatizar, anticipar fallas y operar remotamente acerca cada vez más las decisiones informáticas al proceso físico.
La pregunta deja entonces de ser solamente si una computadora puede ser comprometida. La pregunta importante para una planta es otra: ¿en qué momento un problema digital puede degradar la visibilidad, el control, la producción, la seguridad o la capacidad de recuperarse?
Información verificada al 7 de septiembre de 2026.La respuesta rápida: la ciberseguridad OT es riesgo operativo
La tecnología operacional —OT, por sus siglas en inglés— supervisa o controla procesos físicos. Por eso su ciberseguridad no puede administrarse únicamente como protección de información. Un evento digital puede quedarse en una cuenta comprometida o un servidor indisponible, pero también puede propagarse a una dependencia operativa y terminar provocando pérdida de visibilidad, incapacidad para operar remotamente, una parada o una recuperación prolongada.
Eso no significa que toda vulnerabilidad produzca un incidente ni que todo incidente termine afectando físicamente una planta. La cadena es más larga: activo → conectividad → acceso → evento → pérdida de capacidad → consecuencia operacional → recuperación. La gestión correcta consiste en reducir la probabilidad de que esa cadena avance y preparar a la organización para detenerla o recuperarse de forma segura.
El cambio de perspectiva
En infraestructura energética, proteger OT significa preservar cuatro cosas al mismo tiempo: operación segura, disponibilidad, control y recuperación. La confidencialidad sigue importando, pero la prioridad puede cambiar cuando el sistema administra bombas, compresores, motores, interruptores, hornos, válvulas o servicios auxiliares.
Por eso la ciberseguridad OT no pertenece exclusivamente al departamento de TI. Requiere operaciones, automatización, mantenimiento, seguridad de procesos, ingeniería, TI, ciberseguridad, compras, proveedores y dirección.
OT no es simplemente “la computadora de la planta”
NIST define Operational Technology como sistemas y dispositivos programables que interactúan con el entorno físico o administran equipos que lo hacen. Esto incluye sistemas de control industrial, pero también otros sistemas capaces de detectar o provocar cambios directos en dispositivos, procesos y eventos.
OT
Tecnología que supervisa o controla procesos, activos y condiciones físicas.
ICS
Industrial Control Systems: familia que incluye arquitecturas como SCADA, DCS y control basado en PLC.
PLC
Controlador lógico programable que ejecuta lógica local y secuencias de proceso.
DCS
Sistema distribuido utilizado para controlar procesos continuos o complejos dentro de una planta.
SCADA
Supervisa activos, adquiere datos, gestiona eventos y permite control supervisorio.
HMI
Interfaz mediante la cual un operador observa estados y ejecuta acciones autorizadas.
Historian
Conserva series de tiempo y contexto histórico del proceso para análisis y reconstrucción.
Engineering workstation
Estación utilizada para configurar, programar, diagnosticar o mantener sistemas de automatización.
Convergencia IT/OT
Integración creciente entre sistemas empresariales, analítica y tecnología de operación.
AI Regula Solutions ya explicó la arquitectura que une sensores, PLC, RTU, redes, SCADA, historiadores y aplicaciones en su análisis sobre telemetría, SCADA e IoT . La pregunta ahora no es cómo conectarlos, sino qué riesgos aparecen cuando esas conexiones crecen.
IT y OT: por qué las prioridades cambian
TI y OT comparten tecnologías —servidores, redes, sistemas operativos, usuarios, comunicaciones—, pero existen para misiones diferentes. Una aplicación administrativa procesa información; un sistema OT puede participar directamente en una secuencia de producción o en la operación de infraestructura física.
| Variable | IT | OT | Por qué importa |
|---|---|---|---|
| Objetivo | Procesar información y soportar servicios empresariales. | Supervisar o controlar un proceso físico. | La consecuencia puede alcanzar producción y equipos. |
| Disponibilidad | Alta según la aplicación. | Puede ser crítica para continuidad o safety. | Un reinicio puede no ser operacionalmente aceptable. |
| Actualización | Suele existir mayor flexibilidad para desplegar cambios. | Puede requerir pruebas, fabricante y ventana operativa. | Un parche correcto desde seguridad puede causar incompatibilidad operacional. |
| Ciclo de vida | Generalmente más corto. | Puede extenderse durante muchos años. | Conviven equipos modernos con plataformas legacy. |
| Consecuencia de falla | Pérdida de servicio, información o productividad. | Puede incluir pérdida de control, parada o daño físico. | El análisis debe incorporar ingeniería y proceso. |
| Mantenimiento | Frecuentemente programable con mayor flexibilidad. | Puede depender de producción, paros mayores o disponibilidad de redundancia. | La ventana técnica se convierte en decisión de negocio. |
| Safety | No suele controlar directamente funciones de seguridad de proceso. | Puede coexistir o interactuar con sistemas relevantes para seguridad. | Ciberseguridad y seguridad funcional deben coordinarse. |
De sensor a negocio: cómo se conectó la operación
Esta arquitectura crea valor porque evita capturas manuales, permite analítica, concentra operaciones remotas y conecta producción con mantenimiento, energía, inventarios y decisiones empresariales. El artículo sobre medición energética en México muestra precisamente cómo una señal física puede convertirse en evidencia y decisión.
El riesgo aparece cuando las interfaces se incorporan sin conocer para qué existen, qué sistemas pueden comunicarse, quién puede utilizarlas y qué ocurriría si la dependencia deja de estar disponible. La conectividad no es por sí misma insegura; necesita arquitectura, necesidad de negocio y controles proporcionales a su criticidad.
Vulnerabilidad, incidente y consecuencia no son lo mismo
Una vulnerabilidad no equivale automáticamente a un incidente; un incidente tampoco implica necesariamente una consecuencia física.
Esta separación evita dos errores: minimizar cualquier hallazgo porque “nunca ha pasado nada” y convertir toda vulnerabilidad en una predicción catastrófica. La dirección necesita comprender la trayectoria plausible desde el activo hasta una consecuencia y conocer qué barreras impiden que esa trayectoria avance.
No puedes proteger lo que no sabes que existe
El inventario OT no debe ser una hoja estática creada para una auditoría y olvidada. CISA y socios internacionales publicaron en agosto de 2025 una guía específica para que propietarios y operadores mantengan una lista organizada y actualizada de hardware, software y sistemas. La información permite priorizar riesgo, gestionar obsolescencia y entender dependencias.
Para gobierno interno, una organización debería poder asociar cada activo relevante con su función, responsable, versión, criticidad, conectividad, dependencias, proveedor, soporte y estado de ciclo de vida. No se trata de publicar esa información ni convertirla en un mapa ofensivo: se trata de que la propia empresa conozca lo que opera.
Pregunta para dirección
Si mañana un fabricante anuncia el fin de soporte de un componente crítico, ¿la organización puede identificar dónde está instalado, qué función cumple y qué otros sistemas dependen de él? Si la respuesta tarda semanas, el problema comienza antes de cualquier ataque.
Una red industrial no debería comportarse como una gran red plana
IEC 62443-3-2 utiliza el concepto de zonas y conductos: los activos se agrupan de acuerdo con función y riesgo, y las comunicaciones entre esas zonas se tratan de forma explícita. El objetivo conceptual es sencillo: no todo sistema necesita hablar con todos los demás.
Una arquitectura puede separar control, supervisión, servicios OT, una DMZ industrial y sistemas empresariales, con rutas autorizadas según una necesidad concreta. Esto no significa que toda instalación deba desconectarse completamente de internet o de IT. Significa que las conexiones necesarias deben ser conocidas, limitadas y controladas, mientras las innecesarias se eliminan.
Acceso remoto: el proveedor también forma parte de la superficie
Integradores, fabricantes, técnicos de mantenimiento y especialistas pueden necesitar acceso remoto para diagnosticar o mantener un sistema. El problema no es que exista el acceso: el problema aparece cuando permanece abierto sin necesidad, utiliza identidades compartidas, concede privilegios excesivos o deja poca evidencia de lo ocurrido.
Las guías actuales de CISA y NIST recomiendan tratar el acceso remoto como una capacidad gobernada: necesidad justificada, identidad individual, autenticación reforzada cuando sea compatible, privilegio mínimo, aprobación, duración limitada, registro y cierre posterior. NIST publicó en junio de 2026 SP 1800-45, una arquitectura de referencia de acceso remoto OT para agua y aguas residuales. Su sector de origen no la convierte en obligación universal, pero sus principios son útiles para evaluar diseños remotos.
Si todos usan la misma cuenta, nadie sabe quién cambió qué
Las cuentas compartidas, credenciales predeterminadas, usuarios que permanecen activos después de que una persona cambia de puesto y cuentas permanentes de proveedores destruyen trazabilidad. En un entorno industrial, saber quién cambió una lógica, una configuración o un parámetro puede ser tan importante para una investigación operacional como saber qué valor cambió.
El gobierno de identidades debe considerar limitaciones reales de productos antiguos. Cuando un equipo no soporta controles modernos, la respuesta no es fingir que el requisito no existe: deben evaluarse medidas compensatorias en la arquitectura, el procedimiento y el acceso.
Legacy: viejo no significa automáticamente inseguro, pero sí exige estrategia
IEC 62443-2-1:2024 reconoce una realidad industrial: la vida de un sistema IACS puede superar veinte años y algunos componentes quedan sin soporte mucho antes de que termine la vida útil de la planta. Eso puede limitar parches, herramientas de respaldo, autenticación y otras capacidades que hoy se consideran normales.
Un activo antiguo no es automáticamente vulnerable de manera crítica ni debe reemplazarse sólo por edad. La empresa necesita entender soporte, exposición, función, dependencias y consecuencias, y aplicar controles compensatorios cuando actualizar o reemplazar inmediatamente no sea viable.
Patching no funciona igual que en una laptop
En OT una actualización puede requerir validación con el fabricante, pruebas de compatibilidad, una ventana de mantenimiento, plan de reversión y aprobación de operaciones. Demorar todo parche indefinidamente aumenta exposición; instalarlo sin pruebas puede generar indisponibilidad. La disciplina correcta combina riesgo de ciberseguridad con confiabilidad operacional.
Backup: tener una copia no significa poder recuperarse
NIST publicó en junio de 2026 su OT Backup Quick Start Guide, SP 1339. Su mensaje central es operativo: los respaldos deben formar parte de la gestión de cambios, realizarse con regularidad, probarse y revisarse durante ejercicios de recuperación. Una copia que nunca se ha restaurado es una hipótesis, no una capacidad demostrada.
Según la instalación, la recuperación puede depender de lógica de control, configuraciones de PLC y DCS, HMI, SCADA, estaciones de ingeniería, servidores, historiadores, parámetros, configuraciones de comunicaciones y otros elementos necesarios para reconstruir la función. La lista concreta debe definirse internamente de acuerdo con criticidad.
Backup y recovery son dos cosas diferentes
Backup es la copia recuperable. Recovery es la capacidad real de restablecer la función. En OT, restaurar un archivo no necesariamente significa volver a producir: después pueden requerirse validaciones, comprobación de estados, secuencias de arranque, condiciones seguras y autorización operacional.
Dos conceptos ayudan a dirección. El RTO expresa cuánto tiempo puede tolerarse la indisponibilidad de una función. El RPO expresa cuánto estado o información puede perderse. En OT estas métricas deben conectarse con seguridad física, procedimientos de arranque y capacidad de operar de manera manual o degradada.
Incidentes reales: cuando lo digital llega a la operación
Los casos públicos muestran trayectorias diferentes. Algunos alcanzaron directamente sistemas industriales; otros afectaron TI y obligaron a detener o degradar la operación por dependencia empresarial. Esa distinción es importante: no todos los incidentes OT comienzan en un PLC.
| Caso | Sector | Qué ocurrió | Impacto comprobado | Control relevante |
|---|---|---|---|---|
| Ukraine Power Grid, 2015 | Electricidad | Un ciberataque afectó a tres empresas de distribución y alcanzó funciones de control. | Aproximadamente 225,000 clientes sufrieron interrupciones de 1 a 6 horas. | Segmentación, control de acceso, recuperación operacional y capacidad manual. |
| TRITON, 2017 | Refinación | Actores manipularon dispositivos de un sistema instrumentado de seguridad en una refinería extranjera. | La instalación se detuvo durante varios días. | Independencia SIS, gobierno de estaciones de ingeniería y monitoreo de cambios. |
| Norsk Hydro, 2019 | Manufactura y energía | Un ciberataque afectó sistemas de TI de la organización. | Varias instalaciones operaron manualmente y algunas sufrieron paros temporales. | Procedimientos degradados, respaldos, aislamiento y recuperación. |
| Colonial Pipeline, 2021 | Ductos | La empresa detuvo preventivamente su sistema de ductos tras un ataque de ransomware sobre TI. | El sistema completo permaneció detenido hasta el reinicio anunciado el 13 de mayo. | Dependencias IT/OT, continuidad, segmentación y restauración coordinada. |
Colonial Pipeline: una lección sobre dependencias
El Departamento de Energía de Estados Unidos documentó que Colonial detuvo de manera preventiva sus ductos el 7 de mayo de 2021 después de un ataque de ransomware y anunció el reinicio completo el 13 de mayo. El caso es especialmente útil porque demuestra que una interrupción operacional puede surgir por dependencia de sistemas empresariales aunque no se demuestre que el atacante haya tomado control de PLC del ducto.
Norsk Hydro: el valor de poder trabajar degradado
Hydro aisló plantas y recurrió a operaciones y procedimientos manuales después del ataque de marzo de 2019. Algunas unidades continuaron produciendo cerca de la normalidad; otras enfrentaron paros y menor capacidad. Posteriormente la empresa reconstruyó sistemas cifrados a partir de respaldos. La lección es resiliencia: el modo manual no es obsoleto si forma parte de una estrategia de continuidad.
El ransomware en OT no necesita cifrar un PLC para detener producción
Una planta puede depender de sistemas empresariales para programación, calidad, logística, identidades, mantenimiento, recetas, documentación o comunicación con terceros. Si esas funciones dejan de estar disponibles, operaciones puede decidir reducir o detener producción aun cuando el controlador local continúe funcionando.
Por eso ransomware debe analizarse como problema de continuidad y dependencias, no sólo como malware. NIST actualizó en junio de 2026 su perfil de ransomware basado en CSF 2.0, reforzando el ciclo de gobernar, identificar, proteger, detectar, responder y recuperar.
Seguridad funcional y ciberseguridad: relacionadas, pero diferentes
Un SIS —Sistema Instrumentado de Seguridad— busca reducir riesgos de proceso mediante funciones diseñadas para llevar la instalación a una condición segura cuando se cumplen determinadas condiciones. Ciberseguridad busca evitar que eventos digitales comprometan funciones, integridad, disponibilidad o control. Una disciplina no sustituye la otra.
TRITON mostró por qué deben coordinarse: CISA documentó que en 2017 actores manipularon dispositivos de seguridad de una refinería y el evento provocó una parada de varios días. La lección no es transformar al ingeniero de procesos en analista de malware; es reconocer que cambios digitales sobre una barrera de safety pueden convertirse en riesgo de proceso.
La misma lógica aplica a sistemas de detección de gas. En el artículo sobre sensores, alarmas y detección industrial de gas , una alarma sólo es útil cuando forma parte de una cadena de decisión y respuesta. La ciberseguridad debe proteger también la integridad y disponibilidad de esa cadena.
México: obligación sectorial no es lo mismo que buena práctica internacional
No existe una única “NOM general de ciberseguridad OT” aplicable a toda la industria mexicana
Al corte de esta investigación, el marco debe analizarse por sector, instalación y sujeto obligado. NIST, CISA e IEC 62443 son referencias técnicas internacionales; no deben presentarse automáticamente como obligación legal mexicana.
En electricidad sí existen obligaciones específicas. El Código de Red expedido mediante RES/550/2021 contempla criterios de seguridad de la información para infraestructura TIC del Sistema Eléctrico Nacional: identificación de infraestructura crítica y activos clave, administración de riesgos, respuesta a incidentes, mejora continua y mecanismos de recuperación. Documentos actuales de la Comisión Nacional de Energía siguen identificando esa resolución como parte del marco de confiabilidad.
CENACE también mantiene entre sus disposiciones el Manual de Requerimientos de Tecnologías de Información y Comunicaciones para el SEN y el MEM, con requerimientos específicos para comunicaciones y seguridad del sector eléctrico. Estas reglas no deben extrapolarse automáticamente a una refinería, una fábrica o una estación de servicio fuera de su campo de aplicación.
A escala nacional, CERT-MX opera un Protocolo Nacional Homologado de Gestión de Incidentes Cibernéticos para coordinación de incidentes de alta criticidad, y la Agencia de Transformación Digital y Telecomunicaciones desarrolla la agenda nacional de ciberseguridad e infraestructura crítica. Parte de esa agenda 2026-2027 continúa en construcción. Una iniciativa legislativa o un proyecto de política pública no debe citarse como ley vigente hasta completar su proceso jurídico.
Qué debe ver un director: no vulnerabilidades, sino capacidad operacional
Dirección no necesita recibir un listado interminable de puertos, versiones o alertas técnicas. Necesita saber qué funciones críticas dependen de sistemas digitales, qué tan preparada está la organización para perderlas y cuánto tiempo requiere para recuperarlas.
| Área | Pregunta de dirección | Evidencia que debería existir |
|---|---|---|
| Inventario | ¿Sabemos qué activos soportan funciones críticas? | Inventario actualizado, responsables y criticidad. |
| Segmentación | ¿Qué conexiones existen entre OT, IT y terceros y por qué? | Arquitectura y flujos autorizados documentados. |
| Accesos | ¿Quién puede cambiar una función operacional? | Roles, identidades, autorizaciones y registros. |
| Terceros | ¿Qué proveedor puede acceder y bajo qué condiciones? | Contrato, aprobación, acceso temporal y bitácora. |
| Backups | ¿Podemos reconstruir las funciones críticas? | Alcance de respaldos y pruebas de restauración. |
| Recovery | ¿Cuánto podemos estar detenidos y cómo arrancamos de manera segura? | Procedimientos, RTO/RPO donde apliquen y ejercicios. |
| Monitoreo | ¿Podemos identificar cambios y fallas relevantes? | Eventos, alarmas, registros y responsables. |
| Incidentes | ¿Quién toma decisiones cuando IT y OT están afectados? | Plan, roles, contactos y ejercicios conjuntos. |
| Ciclo de vida | ¿Qué sistemas se acercan a fin de soporte? | Roadmap de obsolescencia y medidas compensatorias. |
El proveedor OT también debe diseñarse dentro del modelo de riesgo
CISA y socios publicaron en enero de 2025 Secure by Demand, una guía dirigida precisamente a compradores de productos OT. Cambia la conversación desde “qué funciones tiene” hacia “qué control conserva el propietario, cómo se actualiza, cómo genera registros, cómo se recupera y qué dependencia crea con el fabricante”.
| Pregunta | Por qué importa | Evidencia |
|---|---|---|
| ¿Quién administra el producto? | Evita dependencia no prevista del fabricante. | Matriz de responsabilidades. |
| ¿Cómo funciona el acceso remoto? | Un canal de soporte es también una ruta hacia OT. | Arquitectura y procedimiento de acceso. |
| ¿Puede utilizar identidades individuales? | Permite trazabilidad. | Funciones de usuarios y roles. |
| ¿Qué registra? | Sin logs es difícil reconstruir cambios. | Ejemplos de registros y retención. |
| ¿Cómo recibe actualizaciones? | El ciclo de seguridad continúa después de la compra. | Política de actualizaciones y avisos. |
| ¿Cómo comunica vulnerabilidades? | Permite reaccionar antes del fin de vida. | Proceso de divulgación y advisories. |
| ¿Cómo se respalda y recupera? | Reduce dependencia del proveedor durante una crisis. | Procedimiento y prueba de restauración. |
| ¿Qué estándares e interfaces utiliza? | Reduce bloqueo tecnológico innecesario. | Protocolos e interfaces documentados. |
| ¿Cuál es su ciclo de vida? | Permite planear obsolescencia. | Fechas de soporte y transición. |
| ¿Qué parte de IEC 62443 afirma aplicar? | “Cumple IEC 62443” es demasiado ambiguo. | Parte, edición, alcance y evidencia de conformidad. |
De “tenemos firewall” a “podemos seguir operando”
Una estrategia madura deja de medir seguridad únicamente por herramientas instaladas. La pregunta evoluciona hacia capacidad: conocer activos, controlar conexiones, detectar cambios, responder y recuperar funciones sin crear un riesgo adicional durante el arranque.
Esta escala no es una certificación oficial. Es una herramienta editorial de AI Regula Solutions para ayudar a dirección a visualizar el cambio entre reacción y resiliencia.
Qué distingue una operación digitalizada de una operación digitalizada y resiliente
La primera puede tener sensores conectados, PLC, SCADA, historiadores, acceso remoto y analítica. La segunda sabe qué activos son críticos, limita las comunicaciones necesarias, controla a los terceros, conoce sus dependencias, conserva configuraciones recuperables y ha probado cómo volver a operar.
La ciberseguridad OT madura no promete que nunca ocurrirá un incidente. Busca que un evento digital no avance sin control hacia una consecuencia física y que, si una función se pierde, la organización tenga una forma conocida, probada y segura de recuperarla.
En esa perspectiva, ciberseguridad deja de ser solamente informática. Se convierte en continuidad, disponibilidad, safety, control y capacidad de recuperación de una operación física.
Preguntas frecuentes
¿Qué es ciberseguridad OT?
¿Cuál es la diferencia entre IT y OT?
¿Qué significa OT en una planta industrial?
¿Cómo se protege una red SCADA?
¿Qué es segmentación IT/OT?
¿Por qué son importantes los backups OT?
¿Qué riesgos crea el acceso remoto?
¿Qué debe exigir una empresa a un proveedor OT?
Fuentes esenciales
- NIST — SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security. Final, septiembre de 2023. Guía principal para seguridad OT con consideración de desempeño, confiabilidad y safety. Fuente oficial.
- NIST — SP 800-82 Rev. 4. Initial Preliminary Draft, 22 de enero de 2026. Se cita únicamente para señalar que la nueva revisión está en desarrollo y no sustituye todavía a Rev. 3. Fuente oficial.
- NIST — Cybersecurity Framework 2.0. Final, 26 de febrero de 2024. Marco de gestión y comunicación de riesgo de ciberseguridad. Fuente oficial.
- NIST — SP 1339, OT Backup Quick Start Guide. Final, 17 de junio de 2026. Respaldo, pruebas, cambio y recuperación OT. Fuente oficial.
- NIST — SP 1800-45, Operational Technology Remote Access. Final, 24 de junio de 2026. Arquitectura de referencia para acceso remoto OT en agua y aguas residuales. Fuente oficial.
- CISA y socios internacionales — Principles of Operational Technology Cybersecurity. Guía, octubre de 2024. Seguridad, negocio, segmentación, supply chain y personas. CISA.
- CISA y socios — Foundations for OT Cybersecurity: Asset Inventory Guidance. Guía, 13 de agosto de 2025. Inventario y taxonomía de activos OT. CISA.
- CISA y socios — Secure by Demand. Guía para compradores OT, 13 de enero de 2025. Propiedad, dependencia de fabricantes, logging, recuperación y selección de productos. CISA.
- IEC — IEC 62443-2-1:2024. Estándar internacional para programas de seguridad de propietarios de IACS. IEC.
- IEC — IEC 62443-3-2:2020. Estándar internacional para análisis de riesgo de diseño, zonas y conductos. IEC.
- DOF — Código de Red, RES/550/2021. Publicado el 31 de diciembre de 2021. Contiene criterios de seguridad de información, administración de riesgos y recuperación para infraestructura TIC del SEN. Fuente oficial.
- Guardia Nacional CERT-MX — Protocolo Nacional Homologado de Gestión de Incidentes Cibernéticos. 2023. Referencia mexicana de coordinación para incidentes cibernéticos de alta criticidad. Gobierno de México.
- U.S. Department of Energy — Colonial Pipeline Cyber Incident. Caso de mayo de 2021. Respalda el análisis de dependencia entre sistemas digitales y continuidad del ducto. DOE.
- CISA — Ukraine Critical Infrastructure / Electricity Sector. Caso de diciembre de 2015. Respalda consecuencias comprobadas sobre distribución eléctrica. CISA.
- CISA — TRITON, Energy Sector. Caso de 2017. Respalda la relación entre ciberseguridad y sistemas instrumentados de seguridad. CISA.
- Norsk Hydro — Cyber-attack on Hydro. Caso de marzo de 2019, actualizado por la empresa en 2024. Respalda operación manual, recuperación y reconstrucción desde backups. Hydro.
Comentarios