59 dominios EU escaneados. Los 11 estándares emergentes de AI Agent Readiness con adopción cero. El único control IA con tracción real (robots.txt) lo lidera el sector público (60%) y lo ignora el retail (11%). Análisis pasivo con datos propios de Hard2bit Scanner, 2026-06-06.
Resumen ejecutivo
Escaneamos 60 dominios públicos de grandes empresas y agencias europeas el 6 de junio de 2026 con Hard2bit Scanner. 59 análisis completados, 1 falló por timeout. Medimos 11 estándares emergentes de AI Agent Readiness, cabeceras HTTP de seguridad, autenticación de email, transporte SMTP, TLS y exposición a inteligencia de amenazas. Lo que encontramos sirve como fotografía honesta del estado del mercado EU a junio de 2026.
Seis hallazgos clave:
- 59 de 59 dominios puntúan cero estándares emergentes implementados: ninguno publica llms.txt, Content-Signal, MCP Server Card, Web Bot Auth, Agent Skills, OAuth Discovery, API Catalog ni el resto de los 11 indicadores evaluados. La adopción no es baja: es exactamente cero, sin un solo caso aislado en banca, farma, telcos, energía, retail ni sector público.
- Única señal con tracción: bloqueo de bots IA vía robots.txt. 47% publica alguna política, con sector público liderando (60%) y retail siendo el más expuesto (11%).
- 46% publica Content-Security-Policy, pero solo 20% lo configura sin
unsafe-inline— el resto es CSP de teatro. - 100% publica SPF, 98% DMARC, pero solo 15% MTA-STS — la seguridad del transporte SMTP entrante sigue siendo nicho.
- Banca tiene el DMARC más estricto (100% con
p=rejectop=quarantine) y la peor higiene CSP (0% sinunsafe-inline). - TLS está universalmente resuelto: 93% soporta TLS 1.3, 0% ofrece cifrados débiles.
Llamada al CISO: si tu organización está pensando en habilitar discoverability para agentes IA (publicar llms.txt, exponer un MCP Server Card, declarar APIs vía API Catalog), este informe muestra que aún no hay buenas prácticas consolidadas en grandes empresas EU. Mover ficha ahora significa definir el estándar de facto; hacerlo mal abre nuevos vectores de exposición.
Metodología
Qué medimos
Para cada dominio evaluamos cuatro bloques de controles:
- AI Agent Readiness — los 11 estándares emergentes 2025-2026:
llms.txt,llms-full.txt, Content-Signal (enrobots.txt), Markdown negotiation, API Catalog (RFC 9727), OAuth Discovery, OAuth Protected Resource (RFC 9728), MCP Server Card, Agent Skills, Web Bot Auth (RFC 9421) y Link Header AI. Adicionalmente, política de bots IA enrobots.txt(GPTBot, ClaudeBot, Google-Extended, PerplexityBot, etc.) — técnica defensiva pre-2024 pero contigua al ámbito. - Cabeceras HTTP de seguridad — HSTS, Content-Security-Policy (con detección de
unsafe-inline), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. - Autenticación y transporte de email — SPF (presencia y modo
~all/-all), DKIM visible en CT/DNS, DMARC (presencia y modop=), MTA-STS, BIMI. - TLS y exposición — soporte TLS 1.3, cifrados débiles, OCSP stapling, inteligencia de amenazas (Spamhaus, URLhaus, PhishTank, Google Safe Browsing).
Cómo medimos
Análisis completamente pasivo con Hard2bit Scanner. Solo consulta de información pública: DNS, certificados TLS, cabeceras HTTP, registros de Certificate Transparency, archivos robots.txt, security.txt, llms.txt, listas públicas de threat intel. Cero envío de tráfico anómalo, cero entradas en logs o WAF, equivalente a lo que cualquier navegador o resolver DNS público haría al visitar el dominio.
Cuándo y dónde
Escaneo el 2026-06-06, desde infraestructura europea (Hetzner, Helsinki). Tamaño muestral: 60 dominios (10 por sector × 6 sectores). 59 análisis exitosos y 1 timeout aislado.
Sectores y volumen
Distribución por sectores (10 dominios cada uno):
| Sector | Dominios analizados | Descripción |
|---|---|---|
| Banca | 10 | Bancos sistémicos EU y entidades de crédito relevantes |
| Healthcare / pharma | 10 | Multinacionales farmacéuticas y grandes proveedores sanitarios |
| Retail / e-commerce | 10 | Cadenas comerciales y marketplaces con presencia EU |
| Telcos | 10 | Operadores de telecomunicaciones e ISP de gran tamaño |
| Energía / utilities | 10 | Eléctricas, gas y operadores de red |
| Sector público | 10 | Agencias ciber nacionales y autoridades de protección de datos EU |
Limitaciones que conviene declarar
- Tamaño muestral por sector (10): suficiente para tendencias agregadas, insuficiente para inferencia estadística granular por sector.
- Punto de observación único (Europa): no detectamos configuraciones geo-específicas que solo se sirvan a otras regiones.
- Estándares emergentes en draft: ausencia ≠ rechazo. Para
llms-full.txto sub-checks de OAuth Discovery, la cifra cero puede reflejar simplemente que la organización todavía no los ha implementado, no que los descarte.
Anonimización por sector
Las cifras se publican agregadas por sector. No se atribuyen findings individuales a dominios concretos. Esta decisión es deliberada: el informe describe el estado del mercado, no señala empresas específicas. La lista completa de dominios escaneados queda disponible bajo solicitud razonada para investigadores académicos y auditores acreditados.
Ética
Dominios públicos de organizaciones notorias, análisis no intrusivo, equivalente a investigación periodística sobre transparencia digital pública. Sin acceso a sistemas internos, sin pruebas activas, sin generación de tráfico anómalo.
Hallazgo 1 — Once estándares emergentes, once cifras del 0%
El primer resultado es el más nítido: de los 12 indicadores AI Agent Readiness medidos, 11 tienen adopción exacta de cero en los 59 dominios analizados. El único con tracción real (bloqueo de bots IA en robots.txt) ni siquiera es un estándar emergente, sino una técnica defensiva consolidada antes de 2024.
| Indicador AI Agent Readiness | Presencia (n/59) | % |
|---|---|---|
| llms.txt | 0 | 0% |
| llms-full.txt | 0 | 0% |
| Content-Signal (robots.txt) | 0 | 0% |
| Markdown negotiation | 0 | 0% |
| API Catalog (RFC 9727) | 0 | 0% |
| OAuth Discovery | 0 | 0% |
| OAuth Protected Resource (RFC 9728) | 0 | 0% |
| MCP Server Card | 0 | 0% |
| Agent Skills | 0 | 0% |
| Web Bot Auth (RFC 9421) | 0 | 0% |
| Link Header AI | 0 | 0% |
| Política de bots IA en robots.txt | 28 | 47% |
Interpretación: aunque los estándares llevan en discusión IETF y propuestas comunitarias desde 2024-2025, la adopción a junio de 2026 entre 59 grandes organizaciones europeas es estadísticamente cero. El gap entre publicación de spec y adopción enterprise sigue siendo el cuello de botella habitual.
Qué es llms.txt y por qué su ausencia es reveladora
llms.txt es un archivo plano en la raíz del dominio que ofrece a los agentes IA un índice curado del contenido importante del sitio en formato Markdown. Lo propuso Jeremy Howard en septiembre de 2024 con respaldo de la comunidad LLM. Su ausencia total en 59 grandes orgs EU indica que el discoverability optimizado para agentes IA todavía no aparece en la agenda de los equipos web. Quien lo implemente primero define el formato de facto que sus competidores tendrán que seguir.
Qué es Content-Signal y qué dice esa ausencia sobre gobierno de IA
Content-Signal es una propuesta W3C/IETF que extiende robots.txt con metadatos sobre qué usos de contenido se permiten: indexación clásica, entrenamiento de modelos, búsqueda generativa, etc. Permite consentimiento granular. La ausencia total en el muestreo significa que las orgs que bloquean bots IA lo hacen en modo binario (sí/no), no diferenciando entre uso (training vs inference vs search). Es coherente con la inmadurez del propio estándar.
Qué es MCP Server Card y por qué su ausencia no sorprende
MCP Server Card es la declaración pública de un servidor compatible con Model Context Protocol, el estándar Anthropic para conectar agentes con herramientas. Exponer un MCP server al público es decisión deliberada y poco común en este momento; la cifra cero refleja sobre todo que la mayoría de orgs aún no opera infraestructura MCP pública. Esperable, pero confirma que el ecosistema enterprise está en fase muy temprana.
Web Bot Auth (RFC 9421) — la ausencia con mayor riesgo
RFC 9421 introduce firmas HTTP que permiten distinguir un agente legítimo (firmado por su operador) de un scraper malicioso que falsea su User-Agent. Sin Web Bot Auth, el robots.txt y las cabeceras X-Robots son señales puramente honoríficas: el atacante que ignora Disallow no puede ser identificado técnicamente. La ausencia total significa que el mercado depende todavía del fair-play de los operadores de IA, no de control criptográfico real.
Si quieres una baseline rápida de cómo se encuentra tu propio dominio frente a estos 11 estándares, escanea tu dominio con Hard2bit Scanner en menos de un minuto — escaneo anónimo gratuito, sin tarjeta.
Hallazgo 2 — El sector público bloquea más bots IA que la banca
La política de bloqueo de bots IA vía robots.txt es el único control AI-relacionado con adopción real. Donde está implementada, suele ser un bloqueo binario para todos los user-agents IA detectados. El sector público lidera (60% de dominios con política presente y bloqueo activo de los principales bots). El retail va el extremo opuesto (11% bloquea, frente a un 22% que publica política):
| Sector | Política presente | GPTBot | ClaudeBot | Google-Ext | Perplexity |
|---|---|---|---|---|---|
| Sector público | 60% | 60% | 60% | 60% | 60% |
| Energía | 60% | 50% | 50% | 50% | 50% |
| Telcos | 50% | 40% | 40% | 40% | 40% |
| Banca | 50% | 40% | 40% | 40% | 40% |
| Healthcare | 40% | 20% | 30% | 30% | 30% |
| Retail | 22% | 11% | 11% | 11% | 11% |
Sector público lidera con 60%. Hipótesis razonable: combinación de mandato regulatorio (AI Act, GDPR, guías ENISA), tradición conservadora respecto a transparencia algorítmica y baja presión comercial por aparecer en respuestas generativas.
Retail / e-commerce queda al fondo con 11%. Hipótesis: equipos web orientados a captación, voluntad explícita de aparecer en respuestas de Perplexity y ChatGPT, infravaloración del riesgo de uso del contenido en entrenamiento sin consentimiento.
Observación importante: las organizaciones que bloquean, bloquean todos los bots IA por igual. No vemos en el muestreo política diferencial entre, por ejemplo, bots de búsqueda generativa (deseable para SEO de respuestas) y bots de entrenamiento (no deseable para datasets sin permiso). Esto sugiere que en 2026 la política se aplica como bloqueo defensivo total, no como gobierno granular del consentimiento — coherente con la inmadurez del estándar Content-Signal, que sí permitiría esa granularidad si estuviera adoptado.
Hallazgo 3 — La Content-Security-Policy es teatro en el 80% de los casos
46% (27/59) publica una cabecera Content-Security-Policy. Pero solo 20% (12/59) la configura sin unsafe-inline — directiva que permite ejecutar JavaScript inline y neutraliza la mayor parte de la protección XSS que CSP debería ofrecer. 25% (15/59) publica CSP con unsafe-inline. El resto no publica.
| Sector | CSP presente | CSP sin unsafe-inline |
|---|---|---|
| Energía | 80% | 40% |
| Telcos | 50% | 30% |
| Sector público | 40% | 20% |
| Retail | 22% | 22% |
| Banca | 20% | 0% |
| Healthcare | 40% | 0% |
Energía lidera con 80% de presencia y 40% sin `unsafe-inline` — el sector que mejor combina cobertura y calidad. Banca tiene 20% de presencia y 0% sin `unsafe-inline`: cuando la pone, la pone mal. Healthcare repite el patrón (40% presente, 0% limpio). Retail es curioso: poca cobertura (22%) pero todo lo que tiene está bien configurado (22% sin unsafe-inline).
Implicación NIS2: el Artículo 21 exige medidas técnicas, operativas y organizativas para gestionar riesgos de ciberseguridad. Una cabecera CSP con unsafe-inline no cumple el espíritu de medida técnica efectiva — es señal de cumplimiento checklist más que de protección real. Auditores NIS2 y ENS deberían inspeccionar la calidad de las cabeceras, no únicamente su presencia.
Recomendación accionable para CISOs: si tu organización publica CSP, audítala con un evaluador serio (Mozilla Observatory o CSP Evaluator de Google son gratuitos). Si encuentras unsafe-inline, planifica migración a nonce o hash en máximo 6 meses. Esfuerzo medio-alto pero rendimiento defensivo real. Mientras tanto, una CSP con unsafe-inline desactivada hace casi tanto como no tenerla.
Hallazgo 4 — Email blindado, transporte vulnerable
La autenticación del email saliente (SPF, DKIM, DMARC) está universalmente adoptada en grandes orgs EU. La seguridad del transporte entrante (MTA-STS, exigir TLS al recibir) sigue siendo nicho:
- SPF: 100% (59/59). 97% (57/59) en modo estricto (
-allo~all). - DMARC: 98% (58/59). 83% (49/59) con
p=rejectop=quarantine. - DKIM visible en CT/DNS público: 73% (43/59).
- MTA-STS: 15% (9/59) — sigue siendo minoría.
- BIMI: 20% (12/59) — más adoptado de lo esperado, sobre todo en retail.
| Sector | SPF estricto | DMARC estricto | DKIM visible | MTA-STS | BIMI |
|---|---|---|---|---|---|
| Banca | 100% | 100% | 70% | 0% | 30% |
| Sector público | 100% | 90% | 70% | 20% | 10% |
| Healthcare | 100% | 90% | 100% | 20% | 20% |
| Telcos | 100% | 80% | 70% | 20% | 10% |
| Energía | 100% | 80% | 70% | 20% | 0% |
| Retail | 90% | 60% | 60% | 10% | 56% |
Lectura: el frontend del email security (autenticación del remitente) está maduro. El backend (transporte cifrado obligatorio entre servidores de correo) sigue siendo área de mejora. Banca es paradigmática: DMARC perfecto, cero MTA-STS.
Implicación supply-chain NIS2: varios incidentes EU 2025-2026 documentados (entre ellos la brecha en la Comisión Europea por terceros) involucran email comprometido en proveedores. Sin MTA-STS, el email entrante puede ser interceptado en tránsito por ataques on-path (downgrade STARTTLS). Para entidades con obligaciones NIS2 que reciben datos sensibles por email, MTA-STS deja de ser opcional.
Retail con 56% BIMI es el dato más llamativo: refleja sensibilidad de marca y madurez en marketing. BIMI requiere DMARC en modo p=reject o p=quarantine + certificado VMC, así que el sector que más BIMI tiene es también el que más invierte en DMARC estricto — coherente.
Hallazgo 5 — Banca: contraste interno entre perímetro email y perímetro web
Análisis específico del sector banca, donde el contraste entre madurez del perímetro de email y del perímetro web es el más marcado del muestreo:
- DMARC estricto: 100% (mejor del muestreo)
- SPF estricto: 100%
- CSP sin `unsafe-inline`: 0% (peor del muestreo)
- X-Frame-Options: 60% (medio)
- HSTS strong: 60% (medio)
Hipótesis interpretativa: equipos especializados defienden perímetros distintos. El equipo de email security en banca lleva 20 años integrado con anti-fraud y anti-phishing por regulación específica (PSD2, ECB cyber resilience, recomendaciones EBA). Madurez muy alta. El equipo de seguridad web suele estar integrado con desarrollo y AppSec, opera con prioridades distintas y arrastra más legacy en cabeceras HTTP.
Lectura para la profesión: cuando hay regulación específica que apunta a un riesgo concreto (phishing usando dominio bancario), el sector responde con DMARC blindado. Cuando la regulación es genérica (medidas técnicas razonables), las prácticas se relajan. La conclusión es que la regulación específica funciona y que DORA hace bien en pedir granularidad técnica más que invocaciones genéricas a buenas prácticas.
Insight para CISOs bancarios: si tu organización tiene DMARC perfecto y CSP con unsafe-inline, no es coincidencia ni descuido aislado. Es un patrón estructural. Asegúrate de que la AppSec recibe la misma atención sostenida que el anti-fraud de email. Una auditoría de seguridad web independiente señala estos desequilibrios sin política interna de por medio.
Hallazgo 6 — TLS y crypto: la batalla ganada
El único bloque del informe donde el resultado es mayoritariamente bueno:
- TLS 1.3 soportado: 93% (55/59)
- Cifrados débiles: 0% (0/59)
- OCSP stapling: 41% (24/59) — única mejora pendiente
- Exposición en threat intel (Spamhaus, URLhaus, PhishTank, Google Safe Browsing): 0% (0/59) — ningún dominio aparece listado
La criptografía HTTPS está hecha. Es una buena noticia que rompe el patrón mayoritariamente sombrío del informe. Los esfuerzos colectivos de la última década — Let's Encrypt democratizando certificados, listas HSTS preload, deprecación efectiva de TLS 1.0/1.1, presión coordinada de navegadores — han funcionado.
OCSP stapling al 41% es el único punto débil. Mejora privacidad (el navegador no consulta directamente al emisor de certificados) y latencia de revocación. Quick win incremental: activarlo en el reverse proxy / load balancer cuesta horas, no semanas. Recomendable para sectores que lideran (energía, telcos) como mejora siguiente.
Implicaciones para tu organización
Para CISOs
- Si tu organización está pensando en habilitar discoverability AI (publicar
llms.txt, exponer MCP server público, declarar APIs vía API Catalog), eres pionero. Significa responsabilidad de definir bien la configuración antes de exponerla — y oportunidad de establecer la práctica que tus competidores copiarán. - Prioriza auditar lo que ya tienes mal configurado (CSP con
unsafe-inline, MTA-STS ausente) antes de añadir nuevos vectores. Unallms.txtpublicada en un sitio con CSP rota suma exposición sin aportar protección. - Documenta la decisión de bloquear o permitir bots IA. La política importa cuando llegue la próxima auditoría supply-chain de NIS2 o ISO 27001.
Para auditores (NIS2, DORA, ENS, ISO 27001)
- CSP con
unsafe-inlinees señal clara de medida técnica meramente formal — pide evidencia de migración planificada con calendario. - Ausencia de MTA-STS en organizaciones que reciben datos sensibles por email es debilidad supply-chain documentable.
- Configuración AI Agent Readiness (presencia o ausencia, política aplicada) debería incluirse en los próximos frameworks como parte de la superficie expuesta auditable. Hoy nadie la pregunta; mañana sí.
Para consultores cyber
- El mercado tiene un gap real en assessment combinado de AI Agent Readiness y seguridad web tradicional. La oferta actual se reparte entre SEO/AEO (que cubre discoverability sin seguridad) y red-team / pentesting (que cubre vulnerabilidades clásicas sin AI). El medio queda libre.
- Los datos de este informe son material directo para conversaciones con clientes: «¿tienes
llms.txt? ¿lo has auditado por exposiciones? ¿tu CSP es real o de teatro? ¿estás recibiendo email vía MTA-STS?».
Para developers / SRE
- Si decides implementar
llms.txto MCP Server Card, hazlo con la misma disciplina que cualquier otro endpoint: revisión, auditoría, monitorización, rotación de credenciales si aplica. - Empieza por lo simple (
llms.txtbien curado,robots.txtcon política IA explícita). MCP Server público requiere infraestructura adicional (auth, rate-limit, logging) — trátalo como un servicio production-grade, no como un experimento.
Preguntas frecuentes
Estas preguntas y sus respuestas se publican también como FAQ schema (FAQPage JSON-LD) para facilitar su uso por motores de búsqueda y agentes IA.
Conclusión
Los 11 estándares emergentes de AI Agent Readiness son el nuevo perímetro de exposición de tu sitio web. En junio de 2026, las grandes empresas y agencias europeas no han empezado a configurarlo. Quien se mueva primero define las buenas prácticas que el resto copiará. Pero hacerlo mal abre vectores nuevos — exposición de contenido sin consentimiento, scraping no autorizado, infraestructura MCP pública sin auth robusta — sobre la superficie clásica que el mismo informe muestra plagada de configuración incompleta (CSP de teatro, MTA-STS ausente).
La recomendación honesta: audita lo que ya tienes antes de añadir más. La cripto está hecha, la autenticación del email también, pero la calidad de Content-Security-Policy y el transporte SMTP siguen siendo asignaturas pendientes en la mayoría de sectores. La capa AI Agent Readiness se construye sobre esos cimientos, no en paralelo.
Escanea tu dominio gratis en scan.hard2bit.com — análisis pasivo, 30-60 segundos, sin tarjeta. Si necesitas auditoría profesional con scope contractual definido, hablamos o conoce nuestro servicio de auditoría de seguridad informática.
Apéndice metodológico
Versión y fecha del escaneo
- Herramienta: Hard2bit Scanner (versión SaaS junio 2026)
- Fecha de escaneo: 2026-06-06 (todos los dominios en la misma ventana, mismo día)
- Origen del escaneo: infraestructura europea (Hetzner, datacenter Helsinki)
- Tamaño muestral: 60 dominios objetivo, 59 análisis exitosos, 1 timeout (mediamarkt.com)
- Volumen por sector: 10 dominios cada uno
Checks evaluados
Lista de los checks ejecutados por el scanner en cada dominio, agrupados por categoría interna del producto:
- Red: TLS / SSL, Salud DNS, Puertos expuestos
- Web: Cabeceras HTTP de seguridad (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), Tecnologías detectadas, Vulnerabilidades públicas conocidas (CVE), Configuración de cookies, Contenido mixto en páginas seguras
- Identidad: Seguridad del correo (SPF, DKIM, DMARC, MTA-STS, BIMI), Estado del dominio, Certificate Transparency
- Exposición de datos: Seguridad ante la era IA, Almacenamiento cloud expuesto, Filtración en pastes y repositorios, Riesgo de subdomain takeover, Exposición en datasets de IA, Bloqueo de bots IA, Subdominios en Certificate Transparency, Brechas de proveedores
- Reputación: Inteligencia de amenazas (URLhaus, Feodo, Spamhaus, PhishTank, Google Safe Browsing)
- Cumplimiento: Archivo security.txt, Señales de cumplimiento (cookies, privacidad, GDPR, accesibilidad), Archivo robots.txt
- AI Agent Readiness: 11 estándares emergentes — llms.txt, llms-full.txt, Content-Signal, Markdown negotiation, API Catalog (RFC 9727), OAuth Discovery, OAuth Protected Resource (RFC 9728), MCP Server Card, Agent Skills, Web Bot Auth (RFC 9421), Link Header AI
Cómo reproducir o verificar los datos
Cualquier dominio puede ser reescaneado individualmente en scan.hard2bit.com con la misma herramienta y obtener resultados directamente comparables a los publicados aquí. La lista completa de dominios escaneados está disponible bajo solicitud razonada para investigadores académicos, auditores acreditados y periodistas de tecnología en hard2bit.com/contacto/.
Bibliografía y referencias
- Especificación llms.txt (llmstxt.org)
- Model Context Protocol (modelcontextprotocol.io)
- RFC 9421 — HTTP Message Signatures (Web Bot Auth) (IETF)
- RFC 9727 — API Catalog (IETF)
- RFC 9728 — OAuth 2.0 Protected Resource Metadata (IETF)
- W3C Content-Signal — propuestas en curso (W3C)
- ENISA — agencia europea de ciberseguridad (enisa.europa.eu)
- NIS2 Directive (Comisión Europea)
- AI Act (texto consolidado)
- DORA Regulation (EU 2022/2554) (EUR-Lex)
Sobre los autores y la metodología editorial
Este informe ha sido elaborado por el equipo de I+D de Hard2bit S.L., empresa española de ciberseguridad con más de 10 años de experiencia. Hard2bit está certificada en ISO 27001, ISO 9001, ISO 14001, ISO 22301 e ISO 20000-1, y opera con categoría ENS ALTA. Miembros activos de ISMS Forum, ASLAN, CyberMadrid y UN Global Compact. La línea de investigación en el cruce IA-ciberseguridad es responsabilidad del equipo de Investigación & Desarrollo.
Hard2bit Scanner es la herramienta SaaS propia que ha generado los datos de este informe. Se publica en scan.hard2bit.com con plan gratuito de uso anónimo y planes de pago a partir de 19€/mes.
Aviso metodológico: este informe es investigación de datos propios con tamaño muestral declarado (n=59) y metodología pública. Las cifras y porcentajes reflejan exactamente el resultado del escaneo del 2026-06-06; no son extrapolables al universo completo de empresas europeas sin replicación con muestreos mayores. El informe no sustituye una auditoría profesional con scope contractual definido. Para evaluaciones formales con responsabilidad profesional, contacta con el equipo Hard2bit.