España roza los 1.841 ciberataques semanales: el dato impresiona, pero lo serio es lo que revela sobre la fatiga defensiva

Los 1.841 ciberataques semanales que sufrió España en mayo suenan a cifra de portada. Lo son. Pero si te quedas solo con el titular, te pierdes la parte incómoda: el volumen ya no es la noticia. La noticia es que nos estamos acostumbrando a operar bajo fuego constante y a gestionar esa presión como si fuera ruido de fondo.

Check Point Research sitúa la media global en 2.055 ataques semanales por organización en mayo de 2026. España, con 1.841, queda por debajo de esa media mundial. Eso podría invitar a un optimismo algo perezoso. Error. Una frecuencia de ese calibre no describe un problema episódico; describe una condición operativa permanente. Y cuando una amenaza pasa de ser excepcional a convertirse en entorno, cambian las reglas para el CISO, para el consejo y también para compliance.

No estamos ante una simple estadística de threat intelligence. Estamos ante una pista clara de tres fallos estructurales: exposición crónica, dependencia excesiva de terceros y una brecha persistente entre lo que las normas exigen y lo que las organizaciones pueden demostrar de verdad. Si una empresa española recibe, de media, miles de intentos hostiles al mes, la pregunta ya no es si sufrirá presión. La pregunta útil es otra: cuánto tiempo aguanta antes de que un error humano, una mala configuración o un proveedor comprometido conviertan esa presión en incidente material.

La cifra impresiona menos cuando entiendes lo que mide

Conviene poner orden. Cuando los proveedores de ciberseguridad hablan de “ataques semanales”, normalmente agregan actividad maliciosa observada contra organizaciones: explotación de vulnerabilidades, intentos de acceso, campañas automatizadas, malware, phishing, movimientos asociados a botnets o escaneos con capacidad ofensiva. No equivale a “brechas confirmadas”. Tampoco equivale a “incidentes notificables”. Y, aun así, importa mucho.

Importa porque esa presión continua consume recursos defensivos incluso cuando no culmina en compromiso. Cada oleada obliga a filtrar, priorizar, parchear, cerrar exposición externa, revisar logs y decidir si aquello fue mero ruido o el principio de algo peor. En castellano llano: el enemigo no necesita entrar cada semana para desgastarte; le basta con obligarte a vivir en modo fatiga.

Ahí está el ángulo que a menudo se pierde en las notas comerciales de threat intel. El número no solo habla de agresores. Habla de la economía interna de la defensa. Si tu SOC revisa cientos de alertas derivadas de actividad masiva, si tu equipo de IT arrastra una deuda de parcheo de 45 o 60 días, si tu proveedor de MDR tarda horas en escalar señales de alta criticidad, la frecuencia se convierte en multiplicador de riesgo. No necesitas un “gran ataque sofisticado” cada semana. Te basta un flujo constante de intentos para aumentar la probabilidad de que un control falle por puro agotamiento.

Hay otra cuestión menos vistosa pero más relevante: estas métricas suelen contar por organización, no por tamaño ni criticidad del activo. Un gran banco, una pyme industrial y un hospital pueden aparecer dentro del mismo marco estadístico, aunque sus superficies de ataque y sus capacidades defensivas sean radicalmente distintas. Por eso el dato de 1.841 no debe leerse como ranking patriótico, sino como indicador de entorno hostil. Ni consolida que España esté “mejor” que otros países ni permite concluir que el riesgo es moderado. Con esa intensidad, moderado no es exactamente la palabra.

España no tiene un problema de ruido: tiene un problema de exposición acumulada

La pregunta útil es por qué una economía como la española sigue mostrando una presión tan alta de actividad maliciosa. La respuesta no cabe en un eslogan, pero sí en varios factores bastante reconocibles.

Primero, la superficie expuesta sigue creciendo más deprisa que la capacidad de controlarla. Más servicios en la nube, más APIs, más accesos remotos, más identidades privilegiadas, más integraciones con terceros. El negocio pide velocidad y conectividad; la seguridad intenta poner orden después. A veces lo consigue. A veces documenta el riesgo y cruza los dedos, que no es un control reconocido por ninguna norma seria.

Segundo, España mantiene sectores con alta dependencia digital y alto atractivo para atacantes: banca, seguros, retail, turismo, energía, sanidad, administraciones públicas y una base industrial con automatización creciente. Muchos de estos entornos combinan sistemas modernos con legado. Ese matrimonio suele salir regular. Una parte de la organización está en SaaS con MFA, otra sigue dependiendo de aplicaciones antiguas, VPN mal segmentadas o activos OT que no admiten parcheo frecuente. Si un atacante busca asimetrías, aquí tiene buffet libre.

Tercero, el ecosistema de proveedores multiplica el riesgo. DORA puso negro sobre blanco algo que el mercado llevaba años intentando tratar como externalidad: la cadena de terceros ICT no es accesorio, es núcleo de riesgo operacional. El artículo 28 de DORA obliga a gestionar el riesgo derivado de terceros proveedores de servicios de TIC. El artículo 30 endurece las exigencias contractuales mínimas. Y el artículo 31 entra ya en el seguimiento de proveedores críticos. Traducido: si medio negocio descansa sobre cloud, software de nicho, MSSP, procesadores de pagos, herramientas de CRM, plataformas de firma o integradores con acceso remoto, tu perímetro real se ha mudado hace tiempo fuera de tu edificio.

Cuarto, la cultura de parcheo sigue siendo demasiado reactiva en muchas organizaciones. Los atacantes no necesitan descubrir una joya de día cero cada lunes. Les basta con explotar vulnerabilidades conocidas para las que ya existe parche, mitigación o guidance del fabricante. Cuando una empresa tarda semanas en inventariar, validar y desplegar remediación, el intervalo entre divulgación y explotación se vuelve criminalmente corto.

Aquí conviene recordar algo concreto. La directiva NIS2 exige en su artículo 21 medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos de seguridad de redes y sistemas de información, incluyendo gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en la adquisición y mantenimiento de sistemas, evaluación de la eficacia de medidas y prácticas básicas de ciberhigiene y formación. No es literatura decorativa. Es el regulador diciendo: “si operas servicios esenciales o importantes, quiero ver cómo reduces exposición, no escuchar que el panorama es complejo”.

La paradoja española: más presión, más normas, pero la ejecución sigue desigual

Europa no puede acusarse de falta de regulación. Entre DORA, NIS2, GDPR y, para producto digital, el Cyber Resilience Act, el mensaje normativo es diáfano: conocer activos, gestionar vulnerabilidades, gobernar terceros, detectar antes, responder mejor y documentarlo todo. El problema no es de falta de brújula. El problema es de ejecución desigual.

Tomemos DORA. Desde el 17 de enero de 2025, el reglamento es aplicable en la UE. Para las entidades financieras cubiertas, ya no basta con tener políticas bonitas en PDF. El artículo 5 exige que el órgano de dirección defina, apruebe, supervise y responda de la gestión del riesgo TIC. El artículo 6 baja a un marco interno sólido y documentado. El artículo 10 exige detección de actividades anómalas. El artículo 11 entra en respuesta y recuperación. El artículo 17 regula la notificación de incidentes graves relacionados con TIC. Y el capítulo sobre pruebas, incluidos los artículos 24 a 27, eleva el listón de testing, con pruebas avanzadas basadas en amenazas para determinadas entidades.

Sin embargo, muchas organizaciones siguen atrapadas en una fase adolescente del compliance: saben qué les aplica, han encargado gap assessments, han rehecho plantillas, pero no han convertido esas exigencias en evidencia operativa consistente. Una cosa es tener un registro de terceros. Otra, bastante más incómoda, es demostrar que clasificas servicios, mapeas dependencias críticas, revisas derechos de auditoría, conoces subencargados relevantes y puedes activar salidas ordenadas sin interrumpir procesos esenciales.

Con NIS2 ocurre algo parecido. La directiva entró en vigor el 16 de enero de 2023 y los Estados miembros debían transponerla antes del 17 de octubre de 2024. La transposición nacional ha avanzado a ritmos desiguales por Europa, y ese desfase ha generado la ilusión de que todavía había margen político. Margen jurídico, quizá. Margen operativo, no tanto. Los atacantes no esperan al boletín oficial.

En protección de datos, el déjà vu es total. El GDPR obliga a notificar violaciones de seguridad de los datos personales a la autoridad competente en un plazo de 72 horas cuando sea probable que entrañen riesgo para los derechos y libertades de las personas físicas, según su artículo 33. El artículo 34 regula la comunicación al interesado cuando el riesgo sea alto. Cada organización cree tener esto “bastante trabajado” hasta que descubre, en mitad de un incidente, que no sabe con seguridad qué datos estaban en el sistema afectado, qué logs son fiables o quién decide si la brecha es notifiable. La gobernanza real siempre aparece el día peor.

Lo que revela el dato de mayo no es una carencia regulatoria. Revela que la presión ofensiva está creciendo más rápido que la madurez defensiva media. Y esa distancia, si se cronifica, convierte el cumplimiento en un ejercicio de fe reputacional.

Lo que significa 1.841 ataques semanales para un CISO que no vive en las presentaciones

Bajemos del plano macro al operativo. ¿Qué implica una cifra así para una empresa española media o grande? Varias cosas, todas bastante terrenales.

La primera: el inventario ya no es un proyecto, es una función vital. Si no sabes qué activos están expuestos a internet, qué versiones corren, qué credenciales de servicio existen, qué APIs hablan con terceros o qué buzones tienen privilegios elevados, no puedes priorizar remediación. Esto parece obvio y, sin embargo, sigue siendo una de las principales grietas. Las organizaciones tienen CMDB, escáneres, herramientas EDR, inventarios de cloud y hojas de cálculo heroicas. El problema es la reconciliación entre fuentes. Si cuatro sistemas te dan cuatro verdades distintas sobre el mismo activo, el atacante agradece la confusión.

La segunda: el tiempo de parcheo importa más que el volumen de políticas. La mayoría de consejos de administración entienden bien la idea de “estar cumpliendo”. Entienden bastante peor la idea de “tenemos 137 vulnerabilidades explotables expuestas y 19 llevan más de 30 días sin remediar por dependencia de negocio”. Pues deberían. Porque el riesgo raramente entra por la calidad estética del policy framework.

La tercera: identity is the new perimeter, aunque el eslogan ya esté algo sobado. Si la actividad maliciosa es persistente, el compromiso de credenciales, el abuso de sesiones, el MFA fatigue, el secuestro de cuentas privilegiadas y la mala gestión de secretos se vuelven rutas preferentes. Aquí la pregunta práctica es brutalmente simple: ¿cuántas cuentas con privilegios elevados existen hoy, quién las usa, desde dónde, con qué controles de acceso condicional y con qué trazabilidad? Si no puedes responder sin abrir cinco tickets, tienes trabajo.

La cuarta: el SOC necesita menos fuegos artificiales y más ingeniería de decisión. Un flujo tan intenso de intentos hostiles no se resuelve solo comprando más feeds, más paneles o más licencias de IA generativa metidas con calzador en la consola. Se resuelve afinando casos de uso, eliminando alertas inútiles, automatizando contención de bajo riesgo, validando cobertura MITRE ATT&CK y ligando detección a procesos de negocio reales. Un centro de operaciones saturado de alertas que nadie cierra bien no es resiliencia; es teatro con presupuesto.

La quinta: la preparación de crisis debe asumir compromiso parcial, no solo catástrofe total. Muchas empresas tienen playbooks para ransomware, exfiltración o caída de servicios. Menos tienen procedimientos afinados para escenarios mucho más comunes: compromiso de una cuenta de proveedor, manipulación de reglas de correo, uso de credenciales en VPN, malware en un endpoint de alta sensibilidad o explotación de una API periférica. La mayor parte del daño serio empieza de forma bastante prosaica.

El ángulo regulatorio que no deberías ignorar si operas en España

No toda oleada de ciberataques tiene traducción regulatoria directa. Esta sí la tiene, aunque de forma indirecta y muy material. Cuanto más persistente es la presión de amenaza, menos margen tienen las organizaciones para defender evaluaciones de riesgo complacientes o controles “proporcionados” solo sobre el papel.

Para entidades financieras, DORA cambia el listón de lo defendible. Si una entidad sufre incidentes recurrentes por fallos básicos de visibilidad, segmentación, gestión de vulnerabilidades o supervisión de terceros, el problema ya no será solo técnico. Será de gobernanza. El artículo 5 atribuye responsabilidad al órgano de dirección. El artículo 13 obliga a contar con capacidades y personal adecuados. El artículo 17 empuja a una notificación estructurada de incidentes graves. Si la presión externa es alta y conocida, sostener internamente que ciertos controles podían esperar empieza a sonar menos a prudencia presupuestaria y más a ficción de comité.

Para sectores cubiertos por NIS2, la vara de medir también se endurece. El artículo 20 atribuye a los órganos de dirección la aprobación y supervisión de medidas de gestión de riesgos de ciberseguridad, además de exigir formación. El artículo 21 enumera medidas mínimas que ya no pueden tratarse como aspiracionales: políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición y mantenimiento, evaluación de eficacia, prácticas de ciberhigiene y criptografía cuando proceda. Si la actividad hostil es sistemática, la expectativa de diligencia también lo es.

En datos personales, el incremento de presión eleva otra obligación práctica: la trazabilidad para decidir rápido. GDPR artículo 33 no da 72 horas para “empezar a pensar”. Da 72 horas desde que el responsable tiene conocimiento de la violación, con matices interpretativos, para notificar si procede. Si la organización no tiene clasificación de datos, visibilidad de accesos y procedimientos de investigación mínimamente robustos, ese reloj corre demasiado deprisa.

Hay además una intersección poco glamourosa pero crucial con la gestión de terceros. En muchas investigaciones de brecha, el cuello de botella no es detectar el incidente interno, sino obtener información fiable del proveedor: qué sistema se vio afectado, qué logs existen, qué plazos manejan, qué subprocesadores estaban implicados, si hubo acceso a datos personales o interrupción de un servicio crítico. DORA art. 30 exige cláusulas contractuales detalladas, incluido acceso, auditoría, integridad, disponibilidad y asistencia en incidentes. Si tus contratos aún parecen redactados en la era pre-ransomware, tienes una deuda bastante concreta.

Por qué el verdadero riesgo está en los terceros, no solo en el perímetro visible

Si hubiera que elegir un punto ciego recurrente en el mercado español, yo apostaría por la cadena de suministro digital. No porque sea nuevo. Justo al contrario: porque todo el mundo sabe que es un problema y aun así sigue tratándose con una mezcla de checklists ligeras y resignación estructural.

La empresa moderna subcontrata infraestructura, soporte, desarrollo, autenticación, CRM, correo, nómina, pagos, monitorización, backup y hasta partes de la respuesta a incidentes. Eso mejora escala y, muchas veces, seguridad. Pero también pulveriza la idea clásica de perímetro. Cuando se produce un pico sostenido de ataques semanales, el agresor buscará el camino de menor resistencia. Y ese camino, a menudo, no es el frontalmente más visible, sino el acceso remoto del proveedor pequeño, la librería de software poco vigilada, la cuenta compartida que nunca debió existir o el panel expuesto de un entorno de staging que alguien olvidó despublicar.

El mercado se ha vuelto sorprendentemente tolerante con tres malas prácticas: evaluaciones de terceros basadas en cuestionarios autorreportados, contratos que prometen colaboración genérica en incidentes y ausencia de pruebas reales sobre capacidad de recuperación del proveedor. Todo eso queda bastante bonito en auditoría inicial hasta que hay un incidente. Luego llegan las sorpresas.

¿Tu proveedor te notificará un incidente relevante en horas o en días? ¿Conservará logs útiles? ¿Puede aislar entornos de clientes? ¿Permite auditoría o al menos evidencias independientes sólidas? ¿Ha mapeado sus propios subcontratistas críticos? ¿Sabe restaurar de forma verificada? Si no tienes respuestas concretas, el riesgo de terceros no está “gestionado”; está externalizado semánticamente, que no es lo mismo.

Aquí la lección de DORA merece atención más allá de finanzas. Aunque su alcance formal se limite a entidades concretas, su tratamiento del third-party ICT risk es probablemente el modelo de facto que otros sectores acabarán imitando. No por amor al reglamento, sino porque es difícil discutir la lógica: si un tercero soporta una función crítica o importante, no puedes gestionarlo como si fuera un proveedor de papelería.

La inflación del dato y el peligro de normalizar lo inaceptable

Hay un riesgo comunicativo en cifras como 1.841 ataques semanales. Cuanto más grandes son, más fácilmente se vuelven abstractas. La audiencia se acostumbra. El consejo asiente. El equipo técnico suspira. Y todos siguen adelante como si la exposición masiva fuese una especie de clima inevitable.

Esa normalización es peligrosa por dos razones. La primera es presupuestaria. Si el volumen constante se percibe como “lo normal”, cuesta más justificar inversiones en automatización, segmentación, hardening, identity security o resiliencia de proveedores. Total, siempre hay ataques. Sí, claro. Igual que siempre hay fraude; eso no significa que prescindas de controles financieros.

La segunda es cultural. Cuando la amenaza permanente se integra como paisaje, aumenta la tolerancia interna a desvíos que antes habrían sido escandalosos: sistemas sin MFA fuerte por “impacto de usuario”, excepciones de parcheo indefinidas, cuentas compartidas, logs incompletos, accesos de terceros mal gobernados, activos expuestos fuera de inventario. Nada de eso suele romper una organización en un día. La rompe lentamente, hasta que un atacante aprovecha la suma.

Si el dato de mayo tiene valor editorial, está aquí: obliga a dejar de hablar de ciberseguridad como proyecto de mejora continua y empezar a tratarla, de una vez, como disciplina de continuidad operativa. No es un matiz lingüístico. Cambia prioridades, responsables y métricas.

Qué deberían hacer ahora las empresas españolas, sin caer en el teatro del “tenemos una estrategia”

La reacción sensata ante un entorno de 1.841 ataques semanales no es lanzar un programa con nombre rimbombante ni convocar una sesión de inspiración con PowerPoint. Es revisar cinco decisiones muy concretas.

La primera es identificar qué activos y procesos no pueden fallar durante 24, 48 y 72 horas. Parece una pregunta de continuidad, y lo es. Pero también es la base de la seguridad proporcionada. Sin esa jerarquía, todo acaba siendo “crítico” en el papel y secundario en la práctica.

La segunda es medir exposición externa real, no la deseada. Internet-facing assets, servicios cloud, acceso remoto, APIs, certificados caducando, buckets, paneles, repositorios, cuentas de servicio y secretos expuestos. La foto debe salir de telemetría y validación, no de la presentación corporativa del trimestre.

La tercera es reducir ventana de explotación en vulnerabilidades conocidas. No hablo de perseguir obsesivamente todos los CVE, sino de ligar criticidad técnica con exposición y valor del activo. Una vulnerabilidad severa en un entorno aislado no pesa igual que una explotación conocida sobre un activo expuesto que da acceso a datos o a procesos esenciales. Esto ya lo entienden bien los atacantes. Algunas organizaciones aún no.

La cuarta es endurecer terceros de verdad. Menos cuestionario anual y más clasificación por criticidad, obligaciones de notificación, evidencias independientes, control de accesos, revisión de subproveedores relevantes y pruebas de salida. Si un proveedor toca autenticación, pagos, datos personales, procesos críticos o administración remota, debe tratarse como vector de riesgo material.

La quinta es entrenar la toma de decisiones bajo presión. No solo la parte técnica. También legal, negocio, comunicación y dirección. DORA, NIS2 y GDPR no castigan únicamente la falta de controles; exponen también la improvisación cuando el incidente ya está en marcha. Y la improvisación deja huella documental.

Si quieres una prueba simple de madurez, haz este ejercicio: toma un incidente plausible —por ejemplo, compromiso de cuenta de proveedor con acceso a un sistema financiero o a un repositorio con datos personales— y pregunta quién decide cada uno de estos puntos en las primeras seis horas: aislamiento, continuidad, preservación de evidencias, valoración de impacto, notificación regulatoria, comunicación interna, comunicación a clientes y activación contractual del proveedor. Si la respuesta tarda demasiado o depende de “ya lo veremos”, ya tienes el diagnóstico.

Para banca, seguros y fintech en España, la lectura es aún más severa

Aunque la noticia no se limita al sector financiero, en finanzas la cifra adquiere una gravedad adicional por una razón obvia: la tolerancia al fallo es mucho menor y el escrutinio regulatorio mucho mayor. Una entidad financiera no gestiona solo sistemas; gestiona confianza, liquidez operativa, pagos, autenticación, datos sensibles y, en algunos casos, funciones críticas para la estabilidad del mercado.

DORA obliga a estas entidades a articular una resiliencia operativa digital demostrable, no aspiracional. Eso significa que la presión ofensiva observada en España debería reflejarse en varios frentes muy concretos: escenarios de pruebas más realistas, taxonomía de incidentes bien alineada, inventario vivo de dependencias con terceros ICT, revisiones de concentración de proveedores y una coordinación estrecha entre seguridad, riesgo operacional, compliance y negocio.

Hay una ironía regulatoria aquí. Durante años, parte del sector trató la resiliencia digital como una extensión técnica del riesgo tecnológico. DORA la ha elevado al corazón del riesgo operacional. Y cifras como la de mayo le dan la razón al legislador europeo, por una vez sin necesidad de retórica grandilocuente. Si recibes esta intensidad de ataques cada semana, la resiliencia digital no es un apéndice del CIO. Es una condición para seguir prestando servicio con una cara medianamente seria.

Para fintech y entidades más pequeñas, el desafío es doble. Tienen más dependencia relativa de terceros, menos capacidad interna y, a menudo, una presión comercial de crecimiento que compite directamente con hardening, gobierno de accesos y disciplina documental. El riesgo aquí no es solo sufrir un incidente. Es no poder demostrar, después, que las decisiones adoptadas eran razonables y proporcionadas.

Lo que este dato no demuestra, y conviene no exagerar

Un poco de higiene analítica no viene mal. La cifra de 1.841 ataques semanales no demuestra por sí sola que España sea uno de los países peor protegidos, ni que las organizaciones españolas sufran más brechas confirmadas que otras jurisdicciones, ni que cada empresa esté bajo el mismo nivel de riesgo. Tampoco permite deducir una tasa de éxito atacante ni el impacto económico asociado.

Los datos de threat intelligence dependen de la metodología del proveedor, de su base instalada, de sus sensores y de cómo categoriza “ataque”. Conviene leerlos como un indicador de presión y tendencia, no como censo perfecto del mal. Aun así, sería un error refugiarnos en ese matiz para restarle importancia. Cuando una métrica no es perfecta pero apunta siempre en la misma dirección, lo sensato es usarla como señal operativa, no como excusa académica.

La otra exageración frecuente consiste en convertir cualquier repunte estadístico en justificación para comprar tecnología a la carrera. Tampoco va por ahí. El problema central del mercado español no parece ser la ausencia absoluta de herramientas. Más bien lo contrario: muchas organizaciones tienen stacks razonables y procesos inmaduros, o productos excelentes mal integrados, o visibilidad parcial sin capacidad de decisión rápida. Más tecnología sin gobierno, sin limpieza de alertas y sin disciplina de activos suele producir una versión más cara del mismo desorden.

El mensaje de fondo: la ciberseguridad española ya no compite contra atacantes, compite contra el agotamiento

Eso es, probablemente, lo más inquietante del dato de mayo. No que haya muchos ataques. Eso, a estas alturas, apenas sorprende a nadie. Lo inquietante es que la intensidad sostenida favorece errores por fatiga: decisiones aplazadas, excepciones normalizadas, controles a medio desplegar, dependencias de terceros insuficientemente entendidas y una fe casi supersticiosa en que “ya lo detectará alguien”.

La ciberseguridad madura no consiste en prometer que nada ocurrirá. Consiste en reducir exposición, detectar antes, contener mejor y recuperarse sin convertir cada incidente en crisis existencial. DORA, NIS2 y GDPR no prometen inmunidad. Exigen disciplina. Y las cifras de mayo sugieren que esa disciplina tendrá que ser bastante menos cosmética de lo que algunas organizaciones desearían.

España puede permitirse debatir si 1.841 ataques semanales es una anomalía estadística, una foto parcial o una media que esconde diferencias sectoriales. Lo que no puede permitirse es tratar ese número como un dato curioso más de la economía digital. Porque cuando los intentos hostiles se cuentan por miles cada mes, la seguridad deja de ser una discusión técnica para convertirse en una pregunta bastante más simple: ¿tu organización está diseñada para resistir presión continua o solo para aparentar control hasta el próximo incidente?

Aquí está el quid. El volumen no es el escándalo. El escándalo sería seguir operando como si esa presión no obligara a cambiar nada.