Pentesting de productos con IA: pruebas de seguridad para robots, dispositivos AIoT y Edge AI

El pentesting de productos con IA es una prueba de seguridad para dispositivos con IA integrada – por ejemplo, robots, cámaras con IA, asistentes de voz o Edge AI en máquinas. Se evalúan el hardware, el firmware, la radio, la API cloud, la app, el modelo en el dispositivo y la integración del LLM. La cuestión central es si un atacante puede tomar el control del producto o inducirlo a realizar acciones en el mundo físico.

Una prueba de penetración IoT evalúa hardware, firmware, radio y cloud. En un producto con IA se suman los ataques al modelo y a la integración del LLM – prompt injection, jailbreaks, extracción de modelos, ejemplos adversarios – y la cuestión de qué consecuencias físicas puede tener un ataque a través de actuadores y sensores. Para dispositivos sin función de IA, recomendamos nuestro servicio de pentesting IoT.

Sí. Están documentados, entre otros, accesos root por Bluetooth a robots Unitree (UniPwn, 2025), jailbreaks de robots controlados por LLM con tasas de éxito de hasta el 100 % en ensayos de investigación (RoboPAIR, 2024) y una vulnerabilidad crítica en el software de cobots de Universal Robots (CVE-2026-8153, CVSS 9,8). Los puntos de entrada típicos son las interfaces de radio, los servicios de red, las API cloud y el propio planificador de IA.

Sí, si las salidas del modelo se convierten en comandos sin validación o el modelo tiene permisos demasiado amplios – en la edición 2026 de OWASP, esto corresponde a Improper Output Handling (LLM10) y Excessive Agency (LLM03). Los investigadores han demostrado que comandos de voz, textos en la imagen de la cámara o invitaciones de calendario pueden controlar robots, drones y dispositivos del hogar inteligente. Por eso comprobamos específicamente si entre la planificación por IA y los actuadores actúa una capa de seguridad determinista.

Para la capa de IA, el OWASP Top 10 for LLM Applications 2026, el OWASP Top 10 for Agentic Applications 2026, el OWASP AISVS 1.01, la OWASP AI Testing Guide, la OWASP GenAI Red Teaming Guide y MITRE ATLAS. Para el dispositivo y la radio, la OWASP ISTG, el OWASP ISVS, el OWASP IoT Top 10, la metodología de firmware OWASP FSTM y, para robots, DDS Security con SROS 2. Como normas, ETSI EN 303 645, EN 18031, ETSI EN 304 223 e IEC 62443-4-1/-4-2.

MAESTRO es un framework de Threat Modeling de la Cloud Security Alliance para IA agéntica con siete capas de arquitectura, de Foundation Models a Agent Ecosystem. STRIDE responde a qué tipo de amenaza existe; MAESTRO, a en qué punto de la arquitectura de IA surge. Para productos con sensores y actuadores, añadimos una capa para el mundo físico – Microsoft ya recoge los ejemplos adversarios en el dominio físico como una clase de amenaza propia en su Threat Modeling para sistemas de IA/ML.

El CRA no prescribe ningún procedimiento denominado pentest, pero sí exige en el anexo I, parte II, pruebas y revisiones eficaces y periódicas de la seguridad del producto. Un pentest es la vía habitual para demostrarlo. Las obligaciones de notificación se aplican desde el 11 de septiembre de 2026; todos los demás requisitos, a partir del 11 de diciembre de 2027.

Sí: el anexo III del CRA incluye en la clase I los asistentes virtuales de uso general para el hogar inteligente (n.º 16), los productos para el hogar inteligente con funciones de seguridad, como cámaras de seguridad, vigilabebés y sistemas de alarma (n.º 17), los juguetes conectados con funciones de interacción social o de localización (n.º 18), así como determinados wearables (n.º 19). El Reglamento de Ejecución (UE) 2025/2392 menciona expresamente los altavoces inteligentes con asistente de voz. Para la clase I, la autoevaluación (módulo A) solo es posible si se aplican íntegramente normas armonizadas, especificaciones comunes o un esquema europeo de certificación de la ciberseguridad de nivel «sustancial» como mínimo (art. 32, apartado 2, del CRA) – mientras no se haya publicado ninguna norma en el Diario Oficial, el camino pasa, por lo general, por un organismo notificado.

Depende de la legislación de producto aplicable. Para la IA como componente de seguridad en productos del anexo I, sección A – por ejemplo, juguetes, equipos radioeléctricos o productos sanitarios –, las obligaciones de alto riesgo, incluido el art. 15, se aplican tras el ómnibus digital a partir del 2 de agosto de 2028, cuando esté prevista una evaluación de la conformidad por terceros. El ómnibus ha trasladado las máquinas a la sección B: para la IA en robots y máquinas, los requisitos llegarán mediante actos delegados del Reglamento de Máquinas, que a su vez se aplica a partir del 20 de enero de 2027. Las obligaciones de transparencia del art. 50 se aplican ya desde el 2 de agosto de 2026.

Con un concepto de seguridad funcional acordado: zona de pruebas definida, parada de emergencia al alcance, velocidades reducidas y autorización de los responsables de seguridad funcional del fabricante. Los escenarios críticos los probamos primero en simulación o en el gemelo digital, antes de reproducirlos en el sistema real.

Sí. Comprobamos si los archivos del modelo están sin protección en el dispositivo o en la app, si el proceso de carga y la firma son seguros y cuán robusto es el modelo frente a ejemplos adversarios, datos de sensores manipulados y envenenamiento. Cuando procede, evaluamos también los riesgos de canal lateral en los aceleradores (ISTG-PROC-SIDEC).

Sí. Analizamos el firmware, los servicios y el tráfico de red en busca de conexiones no documentadas, túneles de mantenimiento remoto y funciones ocultas. Ejemplos de la investigación son la telemetría encubierta del Unitree G1 y el túnel de acceso remoto del Unitree Go1 (CVE-2025-2894).

Lo más eficaz es un enfoque grey box o white box: dos o tres dispositivos de prueba, acceso a la app y al entorno de pruebas cloud, documentación de arquitectura y – si es posible – imágenes de firmware y extractos del código fuente. Una prueba black box es posible, pero en el mismo tiempo cubre menos superficie de ataque.

Depende de la clase de producto, el número de interfaces, la profundidad de la prueba y los módulos deseados. Tras una reunión de scoping gratuita, recibirá una oferta a precio fijo. Una prueba focalizada de un único dispositivo, incluido el informe, suele durar pocas semanas.

Como mínimo, antes de cada lanzamiento importante del producto y tras cambios sustanciales en el firmware, el modelo o las funciones cloud. Como los modelos y las técnicas de ataque evolucionan rápidamente, recomendamos además un retest anual – el CRA exige pruebas periódicas durante todo el periodo de soporte.