En cuestión de minutos, la bandeja de entrada comienza a llenarse de confirmaciones de registro, boletines informativos, mensajes de bienvenida, solicitudes de cambio de contraseña, promociones comerciales y notificaciones procedentes de servicios que el usuario no recuerda haber utilizado nunca. Los mensajes llegan en distintos idiomas, desde cientos de dominios y con asuntos diferentes. Muchos parecen perfectamente legítimos.
La reacción más intuitiva es pensar que se trata de una campaña de spam particularmente agresiva y comenzar a borrar mensajes. Sin embargo, esa puede ser precisamente la respuesta que busca el atacante.
El subscription bombing no siempre pretende únicamente saturar un buzón. La avalancha puede ser una cortina de humo diseñada para esconder una compra fraudulenta, un cambio de contraseña, una alerta de acceso o el comienzo de una operación de ingeniería social.Cuando aparecen miles de mensajes legítimos de repente, lo más peligroso puede no ser el ruido, sino aquello que alguien está intentando ocultar entre él.
Un ataque en el que los correos no son necesariamente maliciosos
El subscription bombing, también denominado subscription flooding o email spam bombing, consiste en inundar la dirección de correo de una víctima con una gran cantidad de mensajes no solicitados generados por servicios legítimos.
La diferencia respecto al email bombing tradicional es importante. En este último, el atacante envía directamente un volumen masivo de mensajes o controla la infraestructura desde la que se distribuyen. En el subscription bombing, en cambio, introduce una capa de intermediación: registra la dirección de la víctima en cientos o miles de servicios de terceros. Boletines, formularios de alta, solicitudes de soporte, plataformas comerciales, portales de empleo, reservas hoteleras, anuncios, redes sociales y mecanismos de recuperación de cuentas pueden convertirse así en amplificadores involuntarios.
Los servicios utilizados no tienen por qué haber sido comprometidos ni presentar una vulnerabilidad técnica convencional. En muchos casos se limitan a hacer exactamente aquello para lo que fueron diseñados: enviar una confirmación, una bienvenida o una notificación a la dirección que alguien ha introducido en su formulario. El abuso reside en que nadie ha comprobado previamente que el titular de esa dirección haya solicitado realmente el envío.
Los filtros de spam pueden dejar pasar la avalancha
El subscription bombing plantea un problema especialmente incómodo para los sistemas de filtrado: cada mensaje, analizado de manera aislada, puede ser completamente normal.
El remitente suele ser una empresa real. Su servidor puede tener buena reputación y no figurar en ninguna lista de bloqueo. Las verificaciones SPF, DKIM y DMARC pueden superarse correctamente porque nadie está falsificando necesariamente el dominio: el mensaje ha sido enviado por el verdadero proveedor.
Tampoco tiene por qué contener malware, enlaces fraudulentos o expresiones típicas de una campaña de phishing. Además, los asuntos, idiomas, plantillas y dominios de origen son muy distintos entre sí. Un mensaje dice «Confirme su suscripción»; otro, «Bienvenido»; otro solicita verificar una cuenta; otro comunica el alta en un comercio extranjero.
En campañas reales analizadas, más del 70 % de los mensajes recibió una puntuación que los clasificaba como correo no deseado muy improbable. Es decir, sin mecanismos adicionales, habrían llegado directamente a la bandeja de entrada. Las comprobaciones tradicionales de autenticidad tampoco resultaban eficaces porque, en gran medida, los mensajes eran auténticos.
Ahí se encuentra la paradoja: el carácter malicioso no está necesariamente en cada correo, sino en la coordinación, el volumen y la finalidad de todos ellos en conjunto.
Atacante vs Víctima
Para organizar una campaña no es necesario controlar una gran infraestructura de envío. El atacante necesita disponer de una base de datos de servicios capaces de generar mensajes y de algún mecanismo que automatice las altas, registros o solicitudes.
Las listas pueden recopilarse localizando formularios en la web y comprobando periódicamente cuáles continúan funcionando. A partir de ahí, la dirección de la víctima se introduce en un subconjunto de esos servicios durante un periodo determinado. Una campaña puede consistir en una única oleada o repetirse varias veces contra el mismo objetivo.
La dispersión dificulta la defensa. Cada solicitud se dirige a una entidad diferente, por lo que no existe un punto central desde el que identificar y detener todas las operaciones. Algunos atacantes rotan además las direcciones IP o distribuyen las peticiones para evitar bloqueos por frecuencia.
La automatización mediante navegadores y agentes de inteligencia artificial puede reducir todavía más el esfuerzo. Estos sistemas son capaces de interactuar con páginas web, completar formularios y adaptarse a procesos que antes exigían cierta intervención manual. No eliminan todas las dificultades, pero rebajan la barrera técnica y permiten ampliar con mayor rapidez las listas de servicios utilizables.
La asimetría es evidente. Iniciar la avalancha puede resultar barato (del orden de 5 euros 1000 emails, por hora) y relativamente sencillo. Identificar lo que sucede, recuperar la operatividad del buzón y cancelar cientos de registros puede consumir horas de trabajo.
Miles de mensajes en la primera hora
La escala convierte una simple molestia en un incidente de seguridad.
En un conjunto de 24 oleadas reales se recopilaron 46.970 mensajes no deseados. La campaña más intensa generó 4.847 correos en menos de dos horas, con un ritmo aproximado de 3.387 mensajes por hora. El promedio fue de 1.957 mensajes por ataque y 1.516 por hora, frente a un tráfico ordinario inferior a diez mensajes por hora en las cuentas afectadas.
No se trata, por tanto, de recibir unas cuantas decenas de suscripciones incómodas. En pocos minutos, cualquier mensaje nuevo desaparece entre cientos de notificaciones. El usuario pierde la capacidad de distinguir lo importante de lo irrelevante y puede dejar de confiar temporalmente en su principal canal de comunicación.
Los patrones temporales también sugieren planificación. La mitad de los ataques observados comenzó en viernes. El 80 % se inició durante la mañana y la franja más habitual fue entre las ocho y las diez, precisamente cuando muchas personas comienzan su jornada y consultan el correo. No se registraron ataques entre las diez de la noche y las siete de la mañana.
Esta distribución difícilmente parece casual. Un viernes puede ofrecer al atacante una ventana más amplia: algunos trabajadores terminan antes, los equipos técnicos pueden operar con menos personal durante el fin de semana y una incidencia iniciada al final de la semana tiene más posibilidades de permanecer sin investigar.
Las víctimas, además, eran frecuentemente directivos o personas con alta visibilidad externa. Sus direcciones estaban publicadas, podían localizarse en Internet o seguían esquemas empresariales fáciles de predecir.
Cortina de humo
En su forma más elemental, sirve como mecanismo de acoso, represalia o interrupción. Una persona descontenta, un antiguo empleado o alguien que mantiene un conflicto con la víctima puede buscar únicamente causarle frustración y obligarla a invertir tiempo en limpiar su bandeja.
También puede emplearse para sobrecargar un buzón o incluso provocar problemas en la infraestructura de correo. Si se alcanzan determinados límites de almacenamiento o procesamiento, algunos mensajes legítimos podrían retrasarse o rechazarse temporalmente.
Sin embargo, el objetivo más peligroso es la distracción.
Mientras la víctima intenta comprender por qué está recibiendo miles de mensajes, entre ellos puede aparecer:
La confirmación de una compra realizada con su tarjeta.
Un aviso de cambio de contraseña.
La notificación de un nuevo inicio de sesión.
La modificación de un método de recuperación.
Una transferencia o movimiento financiero.
Un mensaje relacionado con la toma de control de una cuenta.
Una alerta generada durante una intrusión.
El atacante no necesita impedir que ese correo llegue. Le basta con enterrarlo bajo otros mil.
En este escenario, la avalancha no constituye el ataque principal. Es el humo utilizado para reducir la visibilidad mientras se ejecuta el fraude, el robo de cuenta o la intrusión real.
La segunda fase: el técnico
Existe una variante todavía más elaborada.
Poco después de comenzar la inundación, la víctima recibe una llamada, un mensaje de WhatsApp o una comunicación mediante Microsoft Teams. El interlocutor afirma pertenecer al departamento de informática, al proveedor de correo o al soporte técnico de la organización.
Sabe que el usuario está sufriendo una avalancha de mensajes porque él mismo la ha provocado. Eso le permite resultar convincente:
—Hemos detectado el problema. —Estamos ayudando a los usuarios afectados. —Necesitamos instalar un filtro. —Abra este programa de asistencia remota. —Comparta el código que aparece en pantalla. Si, hay gente que todavía cae.
La víctima, agobiada y deseosa de recuperar la normalidad, puede aceptar una ayuda que en otras circunstancias habría considerado sospechosa.
El objetivo es conseguir acceso remoto al equipo, robar credenciales, desplegar malware o preparar una infección de ransomware. El subscription bombing crea el problema; el falso soporte aparece inmediatamente después ofreciendo la solución.
Este patrón convierte cualquier contacto técnico inesperado durante la incidencia en una señal de alarma. El usuario debe interrumpir la conversación y verificar la identidad del supuesto técnico a través de canales internos conocidos, nunca utilizando los datos facilitados por quien ha iniciado el contacto.
El ataque as a service
El subscription bombing también se comercializa en entornos clandestinos como un servicio listo para usar. Los proveedores ofrecen campañas con diferentes duraciones, velocidades y calidades de entrega. Algunos anuncian listas compuestas por decenas de miles de servicios y permiten programar ataques, distribuirlos durante varios días o automatizarlos mediante interfaces. El precio puede ser extraordinariamente bajo en comparación con el perjuicio causado. En determinadas ofertas, enviar miles de mensajes cuesta apenas unos pocos euros (como indiqué antes, entre 5 y 9 euros). Mientras el atacante realiza un gasto mínimo, la víctima o su organización deben dedicar tiempo a investigar, clasificar mensajes, revisar cuentas y restaurar la normalidad.
Un cálculo ilustrativo muestra que limpiar mil correos, suponiendo que una parte pueda borrarse rápidamente y otra exija cancelar manualmente la suscripción, puede requerir cerca de dos horas. El coste económico directo quizá no parezca enorme, pero se multiplica cuando intervienen directivos, personal técnico, responsables de seguridad y servicios externos.
A ello se añade el coste más importante: la posibilidad de que, durante esas horas, pase inadvertido un incidente mucho más grave.
Caíste. ¿Qué debes hacer?
La primera recomendación es no actuar de forma impulsiva. Borrar indiscriminadamente todos los mensajes puede eliminar precisamente la evidencia que se necesita encontrar.
Conviene seguir este orden:
Comunicar el incidente. En una organización, debe avisarse inmediatamente al equipo de seguridad, soporte o responsable informático mediante un canal conocido. Además, el aviso es obligado por Ley.
Identificar la hora de inicio. Registrar cuándo comenzó la avalancha, su intensidad aproximada y los tipos de mensajes recibidos ayuda a delimitar la ventana del posible ataque principal.
Buscar mensajes críticos. Hay que localizar avisos de compras, transferencias, cambios de contraseña, nuevos accesos, modificaciones de cuenta y alteraciones de los mecanismos de recuperación.
Revisar las cuentas sensibles. Banca, plataformas de pago, comercios electrónicos, correo principal, servicios en la nube y redes sociales deben comprobarse accediendo directamente desde sus aplicaciones o direcciones habituales, no desde enlaces recibidos por correo.
Examinar la propia cuenta de correo. Es necesario comprobar las sesiones abiertas, los dispositivos autorizados, las reglas de reenvío, los filtros creados recientemente y los métodos de recuperación.
Conservar evidencias. No deben eliminarse todos los mensajes antes de que el equipo técnico pueda analizar remitentes, horarios y patrones.
Desconfiar del soporte inesperado. No se instalarán herramientas de control remoto, no se compartirán códigos de autenticación y no se seguirán instrucciones recibidas mediante llamadas o mensajes no solicitados.
Aplicar filtros temporales con precaución. Agrupar confirmaciones, boletines o mensajes de remitentes desconocidos puede ayudar, pero una regla demasiado amplia podría ocultar también los avisos legítimos que se buscan.
Cancelar las suscripciones progresivamente. Debe hacerse después de la primera revisión y utilizando mecanismos confiables, preferiblemente las funciones de cancelación integradas en el proveedor de correo. Pulsar indiscriminadamente todos los enlaces durante una situación caótica no es recomendable.
Cambiar la contraseña y activar la autenticación multifactor son medidas necesarias cuando existe la sospecha de que una cuenta ha sido comprometida. Sin embargo, no detienen por sí solas el subscription bombing: para provocar la avalancha, al atacante puede bastarle con conocer la dirección de correo.
No caíste tú, cayó tu organización.
No existe una solución única capaz de bloquear todas estas campañas sin afectar al correo legítimo. La defensa debe combinar medidas técnicas, procedimientos de respuesta y formación.
Los sistemas de correo pueden detectar incrementos anómalos de mensajes procedentes de remitentes nunca vistos, aplicar límites adaptativos, agrupar correos similares y alertar al equipo de seguridad cuando un buzón pasa bruscamente de recibir unos pocos mensajes a recibir cientos por hora. La siguiente tabla recopila (a) los principales dominios (TLD) desde los que se ha registrado subscription bombing, (b) las cuentas desde las que se lanzan y (c) lo que puedes encontrar, comunmente -no es una regla de oro- en los asuntos de cada mensaje.
También resulta útil mantener información sobre remitentes y dominios habituales, de forma que durante una oleada puedan destacarse las comunicaciones conocidas y separar temporalmente el resto sin eliminarlas.
La organización debe disponer de un procedimiento específico. El usuario afectado necesita saber a quién avisar, qué cuentas revisar y cómo verificar cualquier llamada de soporte. No basta con formar frente al phishing tradicional: aquí los correos pueden ser legítimos y la ingeniería social puede llegar después, por teléfono o mensajería.
Los proveedores de boletines y servicios también tienen responsabilidad. El doble opt-in, la confirmación de la dirección antes de activar una suscripción, los mecanismos contra registros automatizados y la cancelación mediante un solo clic reducen el abuso.
Estas medidas introducen cierta fricción, pero impiden que un tercero pueda suscribir indefinidamente una dirección ajena. Aun así, no eliminan completamente el problema: el primer mensaje de confirmación continúa pudiendo utilizarse para contribuir a la inundación.
Colillas en el césped, una cubitera convertida en cenicero y un reglamento que parece redactado para no aplicarse: crónica de una estancia en el Parador de Antequera
Hay objetos que resumen por sí solos una forma de entender la convivencia. En el Parador de Antequera encontré uno: un elegante soporte metálico, colocado junto a una pared blanca y frente a un jardín cuidadosamente mantenido, cuyo recipiente superior estaba repleto de colillas, ceniza y restos de tabaco.
A primera vista podía parecer un cenicero. No lo era. Era un pie portacubos, el soporte sobre el que debe colocarse una cubitera para mantener frío el vino o el champán. Un objeto concebido para servir una botella había sido transformado, mediante una curiosa combinación de desconocimiento y desconsideración, en el pudridero colectivo de una docena de cigarrillos.
La escena resultaba tan absurda como reveladora. Al fondo, el césped, los setos y la vega antequerana. En primer plano, la liturgia del fumador incívico: consumir el placer en privado y dejar el humo, el olor y los residuos a cargo de los demás.
No pretendo convertir este episodio en una acusación indiscriminada contra todas las personas que fuman. La nicotina crea adicción y dejar el tabaco puede requerir ayuda profesional. La crítica se dirige a una conducta concreta: la de quien considera que su deseo inmediato de fumar lo exime de respetar las normas, el espacio compartido y la salud de quienes lo rodean.
El hedonismo de humo ajeno
Durante mi estancia observé a varios clientes fumando en la zona de piscina, los jardines y otros espacios comunes exteriores. También pude comprobar la presencia de colillas abandonadas sobre el césped y en recipientes que no estaban destinados a funcionar como ceniceros.
No se trataba simplemente de alguien que se apartaba discretamente para fumar. El humo llegaba a las zonas de descanso y obligaba a otros huéspedes a respirarlo. Es una peculiar forma de hedonismo: el placer lo disfruta uno; las consecuencias se socializan.
El Ministerio de Sanidad recuerda que el aire contaminado por humo de tabaco contiene sustancias nocivas y que su inhalación aumenta el riesgo de enfermedad cardiovascular y cáncer, además de agravar problemas como el asma, la enfermedad coronaria y la enfermedad pulmonar obstructiva crónica. La Organización Mundial de la Salud sostiene que no existe un nivel seguro de exposición al humo de segunda mano y que incluso una exposición breve puede causar daño. (Ministerio de Sanidad (sobre el tabaquismo pasivo))
Naturalmente, la concentración del humo en el exterior depende de la proximidad, el viento y la duración de la exposición. Pero «estar al aire libre» no convierte el humo en inocuo y, sobre todo, no lo convierte en voluntario. Quien ocupa una tumbona junto a una piscina no ha aceptado participar en el consumo de tabaco de la persona situada a su lado.
El espacio común deja de ser común cuando uno de sus usuarios impone a los demás un producto de combustión que estos no han elegido respirar. El fumador puede decidir encender el cigarrillo; quien está cerca no puede decidir dejar de respirar.
La sofisticación del cenicero imaginario
La conversión de los soportes para cubiteras en ceniceros improvisados añade a la escena un componente casi cómico, si no fuera porque expresa una considerable falta de respeto hacia las instalaciones.
La comparación entre la fotografía tomada en el establecimiento y la imagen comercial del producto elimina cualquier duda sobre su función original. No es un cenicero de gran tamaño ni un elemento colocado para invitar a fumar. Es un pie portacubos. Su recipiente está destinado a sostener una cubitera, no a recibir colillas, ceniza y filtros impregnados.
Podría hablarse de ignorancia funcional: la inclinación a considerar cenicero cualquier objeto cóncavo que no se defienda por sí mismo. Pero la ignorancia no explica todo. Aunque alguien desconociera la función del soporte, resulta difícil creer que también desconociera la existencia de papeleras o la elemental obligación de no abandonar residuos en el mobiliario.
Una colilla no es una minucia. Es el rastro material de una actitud: yo disfruto ahora; otro limpiará después. Yo fumo; tú respiras. Yo abandono el residuo; el jardín, el personal y el resto de los huéspedes asumirán el coste.
El Reglamento de Régimen Interior de Paradores establece, además, que los clientes deben depositar los desperdicios generados en el recinto de baño en las papeleras destinadas a ese fin. No parece una exigencia revolucionaria: se limita a trasladar al reglamento lo que normalmente se aprende antes de alcanzar la edad necesaria para comprar tabaco. (Paradores, reglamento de régimen interior)
Lo que dice la ley y lo que dice Paradores
La legislación estatal no prohíbe de manera automática fumar en todos los espacios exteriores de un hotel. La Ley 28/2005 (huelga decir que la Ley que reemplaza a esta es aún más proteccionista) prohíbe fumar en hoteles, hostales y establecimientos análogos, pero exceptúa con carácter general sus espacios al aire libre (el nuevo reglamente lo prohibe taxativamente). Por tanto, no sería correcto afirmar que cualquier cigarrillo fumado en cualquier jardín o piscina exterior de un hotel está prohibido directamente por esa disposición estatal, la de 2005; pero sí por la de 2026. (Boletín Oficial del Estado, 2005),pero me apoyaré en la vigente, para ser honestos. Aún así, esta misma ley incluye entre los lugares en los que se prohíbe fumar aquellos donde la prohibición haya sido establecida «por decisión de su titular«. Es decir: un hotel puede ampliar la protección y declarar libres de humo zonas exteriores en las que la ley estatal no impone por sí sola una prohibición general. (Boletín Oficial del Estado). Y es algo que, personalmente, tengo muy en cuenta a la hora de hospedarme. Es un contrato, al que me someto (especialmente por mi afección respiratoria) y que el personal no exige su cumplimiento.
Y en relación a que el titular del establecimiento pueda prohibir, eso es precisamente lo que ha hecho Paradores. Su Reglamento de Régimen Interior afirma sin ambigüedad:
«No está permitido fumar en todo el establecimiento salvo en las zonas que hubiera habilitado para ello».
La fórmula no dice «en el interior de los edificios» ni «en las habitaciones». Dice «en todo el establecimiento», con una única excepción: las zonas que Paradores haya habilitado expresamente para fumar. (Paradores). El Parador citado no define zona para fumadores. No hay. Pero sí expendedoras de tabaco.
La normativa turística andaluza refuerza el carácter vinculante de esa regla. Los establecimientos hoteleros deben disponer de un reglamento de régimen interior con normas de obligado cumplimiento; este debe encontrarse a disposición de los usuarios, exponerse en castellano e inglés y publicarse en la página web del establecimiento. Las personas usuarias, por su parte, tienen la obligación de respetar las normas de régimen interior, las reglas de convivencia e higiene, las instalaciones y el entorno medioambiental. (Boletín Oficial del Estado)
La página oficial del Parador de Antequera presenta la piscina, la terraza y los jardines como elementos propios de la experiencia y del descanso ofrecido por el establecimiento. Sin embargo, no he encontrado en esa página ni en el reglamento general publicado por Paradores una identificación pública de la zona concreta que, en su caso, haya sido habilitada para fumar en Antequera. Esto no permite afirmar que no exista físicamente, pero sí que no aparece claramente individualizada en la información pública consultada. (Parador de Antequera)
El reglamento no es decoración administrativa
También conviene precisar la relación entre la reserva, el contrato y el reglamento.
La confirmación de la reserva tiene la consideración de contrato de alojamiento turístico. Posteriormente, en la recepción se entrega el documento de admisión, que identifica el establecimiento, la habitación, las fechas, el régimen contratado y, cuando corresponda, el precio. En ese momento, el huésped debe ser informado de sus derechos, obligaciones y de la existencia del reglamento de régimen interior (bueno, esto no pasó). Por tanto, no es exacto decir que cada cláusula del reglamento figura necesariamente reproducida en el contrato inicial; sí lo es afirmar que el reglamento constituye una norma separada, obligatoria y que debe darse a conocer al cliente.
Tras comunicar al personal las molestias causadaspor la actividad incesante de los fumadores, no aprecié que se adoptaran medidas efectivas ni que cesara la conducta. Esta es una observación sobre lo sucedido durante mi estancia, no una afirmación sobre el funcionamiento habitual de todos los Paradores.
Pero: ¿para qué sirve una prohibición que la empresa publica y luego no hace respetar? Prohibición que supone un contrato al que se somete Paradores cuando el cliente hace una reserva.
La legislación turística andaluza obliga a las empresas a velar por la seguridad, intimidad, tranquilidad y comodidad de sus usuarios, así como a cuidar el buen funcionamiento de los servicios y el mantenimiento de las instalaciones. También permite impedir la permanencia de quienes incumplan sus deberes o las normas de régimen interior y, en casos graves, solicitar el auxilio de las Fuerzas y Cuerpos de Seguridad. No significa que deba llamarse a la policía ante el primer cigarrillo, pero sí demuestra que el establecimiento dispone de instrumentos para intervenir y que la pasividad no es la única respuesta posible. (Boletín Oficial del Estado)
La propia normativa hotelera permite denegar la permanencia por incumplir las condiciones del reglamento o por adoptar conductas que produzcan molestias a otras personas. La medida debe aplicarse con proporcionalidad, comenzando normalmente por informar, advertir y exigir el cese. Lo que resulta difícil de justificar es no hacer nada después de recibir una queja concreta. (Boletín Oficial del Estado)
La Ley 28/2005 considera infracción leve fumar en un lugar donde exista prohibición y califica como grave permitir fumar donde no está permitido. La conducta aislada de fumar puede sancionarse con hasta treinta euros; las restantes infracciones leves se sitúan entre treinta y seiscientos euros, mientras que las graves oscilan entre 601 y 10.000 euros. La responsabilidad concreta dependería de los hechos acreditados y de la valoración de la autoridad competente. (Boletín Oficial del Estado)
Se prohíbe fumar; el tabaco se vende al fondo
En el interior del Parador mantienen lo que aparenta ser una máquina expendedora de tabaco. La imagen produce una ironía difícil de ignorar: la empresa prohíbe fumar en todo el establecimiento, salvo zonas habilitadas, pero aparentemente facilita la adquisición del producto dentro de sus instalaciones.
La contradicción es comunicativa, no necesariamente jurídica. La legislación permite instalar máquinas de tabaco en hoteles, siempre que el establecimiento cuente con la autorización correspondiente y se cumplan las condiciones legales: ubicación interior, vigilancia directa y permanente, mecanismos que impidan el acceso de menores, advertencia sanitaria visible e inscripción de la máquina en el registro correspondiente. La ley contiene, además, una excepción expresa que permite estas máquinas en hoteles aunque no se pueda fumar en sus espacios interiores. (Boletín Oficial del Estado, caso excepcional) aún así, cabe señalar la paradoja: el establecimiento obtiene o facilita una actividad comercial vinculada al tabaco, pero durante mi estancia no pareció demostrar la misma diligencia al hacer cumplir las restricciones sobre su consumo.
Entiendo perfectamente que la máquina puede ser perfectamente legal. La indiferencia frente al humo no se vuelve razonable por ello.
El verdadero lujo es poder respirar
Un Parador no vende solamente una habitación. Vende descanso, paisaje, tranquilidad, gastronomía y cuidado. El propio Parador de Antequera invita en su publicidad a disfrutar de una tumbona junto a la piscina, de una copa en la terraza y del aroma de sus jardines. El aroma, si, pero no de los jardines. (Parador de Antequera)
No hacen falta castigos ejemplarizantes ni campañas de humillación contra quienes fuman. Hace falta gestión. Y compromiso con lo que se promete. Si se especifica que se puede fumar, pues no voy. Si se especifica que hay zona para fumadores, pues voy. Si se especifica que está terminantemente prohibido fumar, pues voy. Yo cumplo mi parte del contrato (de estancia) y el Parador debe hacer igual (que es exactamente lo que reclamo).
Existe señalización inequívoca en la piscina, los jardines y las terrazas; debe identificarse de manera clara cual es la única zona en la que, si existe, se permita fumar (no hay zona); información durante la reserva (no la hubo) y el registro de entrada; intervención del personal cuando se incumpla la regla (no la hubo); retirada de objetos que puedan ser confundidos «con una imaginación especialmente fértil» con ceniceros; limpieza inmediata de las colillas (si la hubo, una chica recogió todas las del cesped); formación del personal (la tienen, pero no actuaron) y disponibilidad visible de las hojas oficiales de reclamaciones (que lo informan en una pequeña pantalla que tienen en el mostrador de recepción), que la empresa está obligada a facilitar. (Boletín Oficial del Estado)
Sobre todo, se necesita que Paradores decida qué quiere que signifique su propio reglamento. Si «no está permitido fumar en todo el establecimiento» significa exactamente eso, debe hacerlo cumplir. Si existen excepciones, debe señalizarlas. Y si la prohibición solo vive en una página web, mientras en la piscina se fuma, en el césped se abandonan colillas y las cubiteras se convierten en ceniceros, entonces no estamos ante una norma.Estamos ante atrezo institucional.
Más información en:
Ley 28/2005, de 26 de diciembre, de medidas sanitarias frente al tabaquismo, texto consolidado: artículos 3, 4, 5, 6, 7, 8, 19, 20, 21 y 22. Agencia Estatal Boletín Oficial del Estado. Consulta: 2 de agosto de 2026. (Boletín Oficial del Estado)
Reglamento de Régimen Interior de Paradores, apartados relativos a la prohibición de fumar, convivencia y uso de la piscina. Paradores de Turismo de España. Consulta: 2 de agosto de 2026. (Paradores)
Decreto-ley 13/2020, de 18 de mayo, ordenación de los establecimientos hoteleros de Andalucía: artículos 4, 19, 20 y 25. Junta de Andalucía. Consulta: 2 de agosto de 2026.
Ley 13/2011, de 23 de diciembre, del Turismo de Andalucía: artículos 21, 22, 24 y 36. Consulta: 2 de agosto de 2026. (Boletín Oficial del Estado)
Tabaquismo pasivo, Ministerio de Sanidad. Consulta: 2 de agosto de 2026. (Ministerio de Sanidad)
Protecting people from tobacco smoke y Tobacco and nicotine, Organización Mundial de la Salud. Consulta: 2 de agosto de 2026. (Organización Mundial de la Salud)
El desarrollo de software podría estar desplazándose desde la escritura de instrucciones para una máquina hacia la formulación de intención, la definición de límites y la producción de evidencias de que el resultado es correcto. El cambio no elimina necesariamente el código ni al programador, pero sí obliga a preguntarnos cuál será el verdadero centro de trabajo de la ingeniería del software.
Del editor como taller de escritura al entorno como puesto de mando.
Imaginemos una escena no demasiado lejana. Una desarrolladora abre su ordenador y, en lugar de entrar directamente en un archivo, accede a un panel. En él trabajan tres agentes. El primero estudia el repositorio y propone una arquitectura. El segundo modifica varios componentes, compila y corrige dos errores. El tercero genera pruebas y rechaza la primera solución porque incumple una condición de rendimiento.
La desarrolladora no ha escrito una sola línea. Ha descrito qué quiere conseguir, delimitado lo que no debe ocurrir y examinado las pruebas que demuestran (o aparentan demostrar) que el trabajo está bien hecho.
El código sigue existiendo. También el compilador, el depurador y el repositorio. Lo que ha cambiado es quién conversa directamente con esas herramientas y dónde se concentra el esfuerzo intelectual humano.
La pregunta no es si la inteligencia artificial escribirá más código. Eso ya ocurre. La pregunta interesante es otra: si los agentes pueden leer, implementar, compilar, ejecutar, observar, corregir y volver a probar, ¿seguirá siendo el editor el lugar principal donde se construye el software?
Quizá estemos contemplando una transición desde la ingeniería del código hacia una ingeniería de la intención y de la evidencia.
El IDE como símbolo de una época (que algunos disfrutamos)
El entorno de desarrollo integrado reunió las herramientas que una persona necesitaba para escribir software: edición, navegación, compilación, depuración, control de versiones, terminales y pruebas. Todo quedó organizado alrededor del archivo que el programador tenía delante. Incluso las ayudas más avanzadas respetaban ese modelo. El autocompletado, la refactorización y los primeros asistentes de IA extendían las manos del desarrollador. Sugerían o explicaban, pero la unidad de trabajo continuaba siendo la línea de código y el sujeto principal seguía siendo quien la escribía.
Los agentes alteran esa relación. Las herramientas actuales pueden leer y buscar en un repositorio, modificar archivos, ejecutar órdenes, instalar dependencias y observar el resultado de sus acciones. Algunos agentes reciben una incidencia, trabajan en un entorno aislado y entregan una pull request para revisión. No producen únicamente texto que alguien debe copiar: operan dentro del proceso de ingeniería. [1][2]
Eso no significa que comprendan plenamente el sistema. Su rendimiento depende del tipo de tarea, el lenguaje, el repositorio y la calidad de las pruebas. Pueden destacar en evaluaciones controladas y caer ante trabajos largos, requisitos ambiguos o exigencias de seguridad. [3][4] Pero la dirección es clara: el modelo ya no está encerrado en una conversación. Tiene herramientas y capacidad de actuar. Cuando el agente habla directamente con el compilador, el IDE deja de ser necesariamente el intermediario entre la intención humana y la máquina.
De taller de escritura a puesto de mando
Probablemente los IDE no desaparezcan. Las tecnologías suelen cambiar de función mientras conservan el nombre. Seguimos hablando de teléfonos aunque llamar sea ya una actividad secundaria. Podríamos continuar hablando de IDE cuando el editor se haya convertido en una vista más dentro de una plataforma destinada a dirigir agentes. Ese entorno tendría menos aspecto de taller tipográfico y más de sala de control. Su superficie principal mostraría objetivos, riesgos, agentes activos, cambios propuestos, costes, decisiones pendientes y evidencias obtenidas. En lugar de preguntar «¿qué archivo quiero editar?», preguntaríamos:
¿Qué comportamiento debe producir el sistema?
¿Qué restricciones no puede vulnerar?
¿Qué dependencias y datos están autorizados?
¿Qué propiedades de seguridad, coste y rendimiento debe cumplir?
¿Qué evidencias exigiré antes de aceptar la implementación?
El futuro IDE podría ser un entorno integrado de especificación, coordinación y verificación. El código seguiría disponible, ocultarlo sería irresponsable, pero ya no ocuparía siempre el centro visual ni cognitivo.
La evolución de las plataformas apunta en esa dirección: sesiones paralelas, agentes especializados, instrucciones persistentes, revisión, entornos aislados y paneles desde los que delegar trabajos completos. [5] La interfaz empieza a organizar trabajo, no solo texto.
El agente ya puede recorrer directamente el bucle de implementación, compilación, prueba y corrección.
Escribir intención no consiste en escribir un «prompt»
Aquí aparece una trampa. Si el humano deja de escribir código, alguien podría concluir que bastará con describir en lenguaje natural lo que desea. Sería una sustitución demasiado cómoda: antes escribíamos Python; ahora escribiremos párrafos.
Pero el lenguaje natural es ambiguo e incompleto. Muchos defectos no nacen de una mala traducción al código, sino de que el requisito era contradictorio, omitía excepciones o significaba cosas distintas para usuarios y desarrolladores.
La alternativa al editor no puede ser únicamente una ventana de chat más grande. Necesitaremos herramientas para expresar la intención con distintos grados de formalidad: modelos de procesos y estados, arquitecturas, esquemas de datos, contratos de API, políticas de autorización, restricciones normativas, invariantes, criterios de aceptación y escenarios de fallo.
La instrucción «construye un sistema seguro para cambiar la cuenta bancaria de un proveedor» es insuficiente. Una especificación útil debería declarar que ningún cambio será efectivo sin verificación por un canal independiente; que el número utilizado no puede proceder del mismo correo que solicita la modificación; que debe conservarse una traza de auditoría; y que determinadas operaciones exigirán doble aprobación.
El trabajo de ingeniería no es redactar una petición elegante. Es convertir una intención empresarial en propiedades observables y restricciones ejecutables. La ingeniería dirigida por modelos, los lenguajes específicos de dominio, las máquinas de estados y las especificaciones formales no son ideas nuevas. Lo nuevo es que podrían dejar de ser actividades periféricas. Si un agente convierte esos artefactos en implementaciones, el modelo adquiere un valor operativo inmediato.
Tal vez el programa sea la especificación más sus pruebas
Durante décadas hemos tratado el código fuente como el principal producto intelectual del desarrollo. La documentación, los requisitos y las pruebas eran importantes, pero la verdad final era lo que el código hacía. Con agentes capaces de regenerar una implementación, esa jerarquía podría invertirse. El activo estable sería el conjunto formado por la intención, los modelos, las políticas, las pruebas y los criterios de aceptación. El código sería una de sus posibles materializaciones. Un agente podría producir una versión, medirla, descartarla y generar otra con un lenguaje o arquitectura diferente. El software se parecería menos a una catedral que debe conservarse piedra a piedra y más a un objeto compilado a partir de una descripción rica. Sin embargo, el código no se vuelve automáticamente desechable. Una implementación contiene conocimiento que no siempre aparece en la especificación: decisiones de rendimiento, compatibilidad heredada, correcciones tras incidentes y rarezas de una plataforma. Regenerar no garantiza recuperar ese conocimiento tácito.
Además, en sistemas regulados o críticos, el código es evidencia. Debe poder auditarse qué versión estuvo en producción, qué dependencia utilizó, qué vulnerabilidad corrigió y quién aprobó el cambio. La regeneración continua no elimina la trazabilidad; la hace más exigente. El código puede perder centralidad sin perder importancia: pasaría de ser el único lugar donde reside la verdad a convertirse en una realización verificable de una intención más amplia.
La especificación y las pruebas pueden convertirse en el activo estable; el código, en una materialización regenerable.
El testing como nueva frontera del control humano
Si el agente implementa, el poder humano se traslada hacia el criterio con el que esa implementación será aceptada. El testing deja de ser una fase final para convertirse en el núcleo del contrato entre persona y agente. El bucle parece sencillo: interpretar el objetivo, generar código, compilar, ejecutar pruebas, analizar fallos y repetir. Pero una batería de pruebas no demuestra automáticamente que el sistema hace lo que queríamos. Solo prueba su comportamiento en los casos que conseguimos imaginar y representar.
Un agente puede superar pruebas incompletas con una solución equivocada. Puede optimizar para el indicador visible o conservar el resultado mientras deteriora seguridad, mantenibilidad o rendimiento. Es el viejo problema de convertir una medida en objetivo, trasladado a un ejecutor capaz de iterar hasta satisfacerla.
Necesitaremos una verificación estratificada: pruebas unitarias y de sistema, pruebas basadas en propiedades, análisis estático y dinámico, fuzzing, regresión, análisis de dependencias, mediciones de recursos, simulación de fallos, verificación formal cuando proceda y revisión humana de arquitectura y amenazas.
NIST recomienda combinar modelado de amenazas, automatización, análisis estático, detección de secretos, pruebas de caja negra y estructurales, casos históricos y fuzzing. [6] La llegada de los agentes no vuelve obsoletas esas prácticas; multiplica su importancia. Si producir código se abarata, verificarlo se convierte en el cuello de botella.
Y surge una dificultad adicional: ¿quién prueba al probador? Si el mismo agente genera implementación y pruebas, puede compartir el mismo malentendido. Separar funciones (un agente construye, otro cuestiona, un tercero busca vulnerabilidades) ayuda, pero no garantiza independencia si todos utilizan el mismo modelo y los mismos patrones aprendidos.
La verificación futura necesitará diversidad de oráculos: herramientas deterministas y modelos distintos, pruebas humanas y automáticas, métodos estadísticos y formales, conocimiento del dominio y observación en ejecución.
El desarrollador cambia el lugar donde aporta criterio
De este desplazamiento no se deduce que programar deje de ser necesario. Para redactar una buena especificación hay que comprender qué puede especificarse; para revisar una arquitectura hay que conocer sus compromisos; para detectar una prueba engañosa hay que saber cómo podría satisfacerse de forma incorrecta.
La alfabetización de bajo nivel seguirá siendo especialmente valiosa en seguridad, concurrencia, sistemas operativos, firmware, criptografía e infraestructuras críticas. El agente puede producir una abstracción seductora mientras esconde una carrera de datos, una validación insuficiente o una dependencia inadecuada.
Lo que puede reducirse es el tiempo dedicado a tareas mecánicas: escribir estructuras repetitivas, migrar APIs, adaptar formatos o localizar errores triviales. Ese tiempo podría desplazarse hacia comprender el problema, discutir supuestos, modelar amenazas, comparar alternativas y diseñar evidencias.
Quizá «ingeniero de prompts» sea una etiqueta demasiado estrecha. Se perfila algo más cercano a un ingeniero de intención: alguien capaz de transformar necesidades imprecisas en contratos verificables, construir el contexto que limita al agente, decidir qué se delega, diseñar evaluaciones resistentes a atajos, auditar dependencias y preservar conocimiento organizativo.
El valor no residirá solo en decirle a la máquina qué debe hacer, sino en demostrar que no ha hecho otra cosa.
¿Quién enseñó a programar a los agentes?
Hasta aquí hemos hablado de cómo trabajan. Pero hay una cuestión previa y más incómoda: ¿de dónde procede su idea de lo que significa programar bien?
Los modelos de código aprenden de grandes colecciones de repositorios, documentación, incidencias, conversaciones técnicas, cuadernos, ejemplos y datos sintéticos. En algunos proyectos abiertos existe una trazabilidad considerable. The Stack, por ejemplo, se diseñó como un corpus con licencias identificadas, procedencia por elemento y un mecanismo de exclusión. [7] Sus versiones ampliaron el número de lenguajes y conservaron información de origen.
En los modelos propietarios, el detalle público suele ser menor. Conocemos categorías generales o declaraciones sobre el uso de código públicamente accesible, pero no necesariamente qué repositorios, versiones, filtros o pesos se utilizaron.
La diferencia entre código público y código libre de obligaciones es esencial. Que un repositorio pueda leerse no significa que pueda reutilizarse sin condiciones. Las licencias pueden exigir atribución, conservación de avisos o publicación de modificaciones. GitHub ofrece mecanismos para detectar coincidencias entre determinadas sugerencias y código público, mostrando fuente y licencia, precisamente porque la procedencia importa. [8]
La Unión Europea ha convertido esta discusión en una obligación para los proveedores de modelos de propósito general: deben mantener una política de cumplimiento de derechos de autor y publicar un resumen del contenido utilizado en el entrenamiento. [9] No resuelve todos los conflictos, pero reconoce que el corpus no es una materia prima neutra ni invisible.
También hay una cuestión de calidad. Un modelo aprende de lo que existe, no de un canon universal de buena ingeniería. En los repositorios hay soluciones correctas, pero también código obsoleto, parches provisionales, configuraciones inseguras y prácticas que funcionan por accidente.
La frecuencia tampoco equivale a excelencia. Si un patrón aparece millones de veces, el modelo aprende que es probable, no que sea óptimo. Puede confundir popularidad con corrección, familiaridad con seguridad y repetición con consenso técnico.
La monocultura de la implementación
Si distintos agentes se entrenan sobre repositorios parcialmente coincidentes, se evalúan con bancos de pruebas parecidos y se ajustan para maximizar indicadores similares, podrían converger hacia una forma dominante de implementar. No necesitarían generar exactamente el mismo código. Bastaría con que prefiriesen las mismas bibliotecas, arquitecturas, lenguajes, servicios en la nube y patrones de autenticación. La diversidad superficial ocultaría una profunda uniformidad estructural. Y esto, a mí, me preocupa enormemente.
La investigación muestra que el rendimiento de los modelos no se distribuye por igual entre lenguajes. Los que tienen mucha presencia en los datos (como Python, Java o JavaScript) suelen obtener mejores resultados que los de pocos recursos. Los corpus equilibrados mejoran notablemente el rendimiento en lenguajes minoritarios, aunque puedan sacrificar parte del desempeño en los dominantes. [10] La preferencia del agente no nace solo de las propiedades técnicas del lenguaje, sino de la distribución del material que ha visto.
Una monocultura tendría consecuencias culturales: soluciones minoritarias y paradigmas alternativos serían cada vez menos visibles. El agente recomendaría lo que conoce; los usuarios lo aceptarían; ese código aumentaría su presencia; y el siguiente modelo lo encontraría aún más representado.
También tendría consecuencias económicas. Si los agentes convergen hacia unas pocas plataformas, sus decisiones reforzarían concentraciones de mercado. Elegir automáticamente una dependencia arrastra costes, telemetría, jurisdicción y dependencia futura. Y tendría consecuencias de seguridad. La diversidad de software puede reducir fallos correlacionados. [11] Cuando millones de sistemas comparten componentes y decisiones, una vulnerabilidad puede propagarse a gran escala. Los agentes no inventan ese problema, pero pueden acelerarlo al replicar las mismas elecciones. La diversidad relevante no consiste en cambiar nombres de variables. Es diversidad algorítmica, arquitectónica, de dependencias, proveedores, modelos de seguridad y valores de diseño.
La diversidad superficial no basta: importan algoritmos, arquitecturas, dependencias, proveedores y criterios de diseño.
Cuando los agentes aprenden de otros agentes
El círculo se vuelve más delicado cuando el código generado entra en repositorios, documentación y conjuntos de entrenamiento futuros. Ya no tendríamos solo modelos aprendiendo de programadores, sino modelos aprendiendo de la interpretación que modelos anteriores hicieron del trabajo humano.
La literatura sobre entrenamiento recursivo con datos sintéticos describe el riesgo de model collapse: generaciones sucesivas que aprenden indiscriminadamente de contenido producido por modelos anteriores pueden perder las zonas menos frecuentes de la distribución y reducir su variedad. [12] Los comportamientos raros desaparecen primero; la distribución se concentra alrededor de lo probable. Trasladar ese resultado directamente al código exige prudencia. No está demostrado que todo ecosistema vaya a colapsar ni que cualquier dato sintético sea perjudicial. Los conjuntos sintéticos verificados mediante compilación, pruebas y filtrado pueden mejorar modelos y cubrir lenguajes con pocos datos. [13] El problema aparece cuando dejan de conocerse el origen, la calidad y la relación con datos humanos de referencia.
En código, la endogamia podría seguir este ciclo: un modelo favorece ciertos patrones; miles de usuarios los aceptan; el nuevo código se publica; futuros modelos lo incorporan como evidencia de uso generalizado; y las alternativas raras pierden representación. Errores, dependencias y convenciones de la primera generación se amplifican. El peligro no es solo producir código peor, sino reducir lentamente el espacio de soluciones que los modelos consideran plausible. La procedencia del corpus se convertirá en infraestructura crítica. Necesitaremos distinguir código humano, generado, revisado, verificado y de autoría o licencia incierta. Preservar repositorios históricos y fuentes originales puede ser tan importante como crear datos nuevos. Sin memoria de la diversidad anterior, cada generación corre el riesgo de aprender de un espejo.
Los agentes también podrían ampliar la diversidad
La conclusión no tiene por qué ser pesimista. Un agente puede explorar en minutos alternativas que un equipo no tendría tiempo de implementar. Puede generar varias arquitecturas, traducir una solución a lenguajes distintos, comparar dependencias y conservar la que mejor responda al contexto.
La automatización podría hacer viable desarrollar versiones diversas de un componente y contrastar sus resultados. También podría ayudar a comunidades pequeñas a crear ejemplos, pruebas y documentación para lenguajes minoritarios.
Pero esa diversidad no aparecerá por accidente. Si el objetivo único es entregar rápido una solución que supere pruebas visibles, el agente tenderá hacia el camino más probable. Para ampliar el espacio de soluciones habrá que pedirlo, medirlo y gobernarlo. Podríamos exigir alternativas con dependencias distintas, comparar implementaciones generadas por modelos diferentes, penalizar monocultivos en componentes críticos y evaluar no solo la corrección, sino la concentración tecnológica que cada decisión produce.
La diversidad tendrá que convertirse en un requisito no funcional, como hoy lo son la disponibilidad o el rendimiento.
Tres futuros que probablemente convivirán
No parece sensato pronosticar una única evolución para todo el software. Al menos tres escenarios pueden coexistir.
1. Evolución del IDE
El editor continúa siendo el centro. Los agentes realizan cambios amplios, ejecutan herramientas y explican decisiones, pero la persona sigue leyendo y modificando código. Será común en investigación, bajo nivel, seguridad y sistemas complejos.
2. Transformación del IDE
El entorno se convierte en una plataforma para especificar, coordinar y validar. El código comparte protagonismo con modelos, políticas, pruebas, trazas y sesiones de agentes. El profesional actúa como arquitecto y supervisor. Probablemente sea habitual en la ingeniería empresarial.
3. Sustitución parcial del código como objeto de trabajo
En aplicaciones rutinarias, integraciones y software de vida corta, las personas apenas manipulan código. Definen objetivos, datos, interfaces, restricciones y pruebas; los agentes generan implementaciones. El código funciona como un artefacto intermedio parecido al binario que hoy produce un compilador.
La frontera dependerá de la criticidad, regulación, longevidad y coste del fallo. No se desarrollará igual una aplicación promocional que un sistema bancario, un hipervisor o el firmware de una instalación industrial.
Los tres futuros probablemente convivirán según la criticidad y el coste del fallo.
El molino no era el editor
Quizá llevemos años mirando el lugar equivocado. El IDE parecía el gran molino de la programación porque allí ocurría la actividad visible: archivos, cursores y miles de líneas. Pero la esencia de la ingeniería nunca estuvo en pulsar teclas. Estaba en convertir una necesidad humana en un sistema comprensible, mantenible y defendible.
Los agentes pueden apropiarse de una parte creciente de la implementación y generar muchas más líneas de las que un equipo puede revisar con métodos tradicionales. Eso no vuelve innecesario el criterio humano. Lo desplaza hacia el punto más difícil: expresar con precisión qué queremos, anticipar cómo puede interpretarse mal, decidir qué pruebas cuentan como evidencia y asumir la responsabilidad por lo que se pone en funcionamiento.
Tal vez el IDE sobreviva, pero como algo distinto. El editor será una ventana de inspección. El centro será la especificación. El activo estratégico será el contexto. El control residirá en las pruebas, las políticas y la trazabilidad. Y la competencia decisiva no será producir más código, sino conservar la capacidad de entenderlo y rechazarlo.
Queda además una responsabilidad colectiva. Si unos pocos corpus, proveedores y criterios de optimización definen cómo se implementa el software mundial, podríamos ganar velocidad a costa de diversidad y resiliencia. Si utilizamos los agentes para explorar alternativas y sometemos sus elecciones a gobernanza explícita, la automatización podría ampliar el repertorio de la ingeniería.
El futuro no se decidirá solo por lo bien que un agente programe. Se decidirá por la calidad de las intenciones que sepamos formular, por la independencia de las pruebas que construyamos y por la diversidad técnica que estemos dispuestos a preservar.
¿Seguirá siendo el código fuente el principal producto intelectual del desarrollo?
¿Será más importante saber programar o saber especificar, probar y auditar?
¿Quién decidirá qué significa implementar correctamente una solución?
¿Cómo evitaremos que millones de aplicaciones reproduzcan las mismas decisiones, dependencias y vulnerabilidades?
¿Y necesitaremos proteger no solo la calidad del software, sino también la diversidad de las formas de construirlo?
Referencias
VS Code : Tools y agentes. Documentación oficial sobre lectura y escritura de archivos, terminal, búsqueda y servicios externos.
Hay una paradoja que conviene mirar de frente. El modelo productivo almeriense (más de 30.000 hectáreas de agricultura intensiva, una industria auxiliar que exporta tecnología a medio mundo, un sistema de comercialización hortofrutícola que abastece a Europa) se ha digitalizado a una velocidad admirable. Riego de precisión, climatización automatizada, trazabilidad desde el semillero hasta el lineal, contabilidad y logística integradas en plataformas conectadas. Pero esa digitalización avanza más rápido que su aseguramiento. Y ahora, sobre esa base ya frágil, se superpone una segunda capa de riesgo: la tentación de delegar en sistemas de inteligencia artificial generativa tareas de análisis, auditoría y peritaje que exigen algo que ningún modelo posee: criterio humano experto.
La IA actual ya no es un simple asistente conversacional. Se ha convertido en un ecosistema de agentes capaces de procesar en segundos volúmenes de información que antes exigían semanas de trabajo. En ese sentido, su uso en manos de un analista o de un perito puede compararse con la utilización de dinamita en un proyecto de ingeniería civil: una potencia descomunal, capaz de ejecutar en instantes tareas mecánicas de demolición que antes consumían recursos enormes. Pero la dinamita no decide por sí sola dónde se abre el túnel ni evalúa la estabilidad de la montaña. Esa responsabilidad (dónde, cuándo, cuánto y por qué) sigue siendo, y seguirá siendo, del ingeniero.
Trasladado a nuestro contexto: un modelo de lenguaje puede estructurar cientos de asientos contables de una comercializadora, identificar señales de alerta en los registros de una cooperativa o extraer patrones de los datos de sensores de un invernadero conectado. Todo ello con una eficiencia innegable. Lo que no puede hacer es asumir la responsabilidad del juicio.
El principio de complacencia
Aquí reside el riesgo más profundo, y el menos comprendido por quienes adoptan estas herramientas con entusiasmo acrítico. Los sistemas de IA generativa operan bajo lo que podríamos denominar un principio de complacencia: asumen por defecto que los datos de entrada son ciertos. Si se les alimenta con estados financieros manipulados, con lecturas de sensores comprometidos o con registros de trazabilidad falsificados, producirán un informe formalmente impecable, con gráficos limpios y una prosa persuasiva, construido íntegramente sobre una mentira. Si analizamos la relación con mi artículo anterior (Cuando el campo se apaga) se puede adivinar que, este, es otro posible vector de ataque.
El ojo humano entrenado hace exactamente lo contrario: no describe lo que los números muestran, sino que busca lo que los números ocultan. El auditor experimentado, el responsable de operaciones que conoce su instalación, el perito que ha declarado ante un tribunal saben que las anomalías, las apropiaciones indebidas y las estrategias de ocultación se detectan precisamente ejerciendo escepticismo profesional. Un escepticismo que es estructuralmente incompatible con el funcionamiento de estos modelos, que a las barreras anteriores suman el riesgo de alucinación: la generación de conclusiones plausibles pero falsas, indistinguibles a primera vista de las verídicas.
Un informe técnico que contenga una sola alucinación no revisada puede dinamitar la credibilidad profesional de quien lo firma en el momento de la ratificación, sea ante un tribunal, un árbitro o un consejo rector. Y en el plano operativo, un sistema de detección de anomalías que «confía» en datos envenenados por un atacante no es una defensa: es una falsa sensación de seguridad con sello de calidad algorítmico.
Blindar el sector
Para el tejido agroindustrial almeriense, la respuesta no es renunciar a la IA (sería tan absurdo como renunciar a la dinamita en la obra civil), sino gobernarla.
Primero, supervisión humana cualificada: toda conclusión generada por IA que sustente una decisión económica, técnica o legal debe ser verificada por un profesional que asuma su firma (human in the loop).
Segundo, cultura de escepticismo: formar a directivos y técnicos para tratar la salida de estos sistemas como hipótesis a contrastar, nunca como veredicto.
Tercero, segmentación rigurosa entre los entornos de operación (riego, clima, frío industrial) y los sistemas de gestión, de modo que un compromiso en la capa administrativa no alcance jamás al proceso productivo.
Cuarto, verificación independiente de los datos de origen (sensores, básculas, registros de subasta) porque la integridad del dato es la condición previa de cualquier análisis fiable, en este sentido puedes consultar mi publicación (https://peerj.com/articles/cs-1605/) sobre limpieza de datos IoT, te dejo el PDF (si no quieres leerlo online) al final del post.
Y quinto, formación específica: la provincia dispone de universidad, centros tecnológicos y organizaciones sectoriales capaces de articular programas conjuntos de capacitación en seguridad OT e IA responsable.
Aprovecho para poner al servicio de la sociedad el Seminario Permanente de la Universidad de Almería : Seguridad Nacional, Sociedad Digital y Ciberdelito, foro diseñado y creado para dar soporte a nuestra provincia y a quienes (fuera de ella) pudieran necesitarlo.
Una llamada al territorio
Almería ha demostrado durante décadas que sabe convertir la escasez en ventaja competitiva. El siguiente reto no es tecnológico, sino de gobernanza: incorporar la inteligencia artificial como acelerador del criterio experto, no como su sustituto. Empresas, cooperativas, administraciones y academia tenemos la responsabilidad compartida de blindar un modelo productivo que alimenta a Europa. La herramienta ya está en nuestras manos. El detonador, conviene no olvidarlo, debe seguir estando en las nuestras.
El Quijote Digital 