Proteger la IA en retail: riesgos, buenas prácticas y lecciones desde el sector automoción

30 de septiembre de 2026

La IA ya forma parte de distintos procesos de retail, desde la atención al cliente y los asistentes conversacionales hasta la personalización de ofertas, la automatización comercial o el soporte a operaciones internas.

Al mismo tiempo, conforme estas herramientas acceden a información corporativa, se conectan con otros sistemas o intervienen en procesos de negocio, su seguridad depende cada vez más de los datos, permisos, integraciones, procesos y personas que intervienen en su uso.

David Alonso, gerente en la Práctica de Ciberseguridad de Telefónica Tech, abordó este reto durante su participación en el II Observatorio de Innovación, IA y Transformación Tecnológica de Faconauto con su ponencia “Protege tu IA”. Su punto de partida fue que para utilizar la IA con mayor seguridad y confianza, primero hay que entender dónde se emplea, cómo se conecta con el negocio y qué hay que proteger.

David Alonso (Telefónica Tech) en la presentación de su ponencia 'Protege tu IA'

La ponencia seguía una secuencia práctica: partir de situaciones reconocibles, analizar qué puede ocurrir y terminar en medidas que las empresas y sus equipos pueden aplicar. Aunque los ejemplos proceden del retail automovilístico, buena parte de los riesgos son comunes a otros negocios que utilizan IA en su relación con clientes, empleados o proveedores.

La seguridad de la IA no depende solo del modelo: también de los datos, permisos, integraciones, procesos y personas que intervienen en su uso.

Cuando un chatbot deja de ser solo un canal de atención al cliente

Uno de los ejemplos utilizados por David para abrir la reflexión fue el conocido caso de un usuario que consiguió que el chatbot de un concesionario generara una respuesta aceptando la venta de un coche por un dólar. Aunque el episodio no derivó en una venta real por ese importe, mostró algo más interesante que la propia anécdota: un asistente de IA a disposición del público puede verse arrastrado fuera del comportamiento para el que fue diseñado.

Ese riesgo no se limita a un concesionario. Puede aparecer en un chatbot de ecommerce, un servicio de atención posventa o una herramienta interna utilizada por empleados. Su alcance aumenta cuando la IA deja de limitarse a generar una respuesta y empieza a consultar información, interactuar con otras aplicaciones o participar en un proceso comercial.

En ese punto es necesario evaluar a qué tiene acceso una IA, qué puede hacer y qué consecuencias tendría alterar su comportamiento.

Cuando un asistente puede consultar información o actuar sobre otros sistemas, el riesgo deja de estar solo en lo que responde.

Qué puede salir mal cuando incorporamos IA al retail

La presentación de David concentró el análisis en cuatro grandes ámbitos: fuga de información, estafa o daño reputacional, denegación de servicio y LLMJacking, a los que, en el contexto de la automoción, añadió una dimensión específica relacionada con la seguridad vial.

Dado que no todas las amenazas responden a la misma lógica ni requieren las mismas medidas, conviene evitar tratarlos como una única categoría de “ataques a la IA”.

Manipular un asistente y acceder a información que no debería revelar

Una de las amenazas más conocidas en los modelos de IA es el prompt injection: instrucciones diseñadas para alterar el comportamiento previsto del sistema, eludir determinados controles o conseguir que utilice de forma inadecuada la información o las herramientas que tiene disponibles.

Está relacionado con los jailbreaks, aunque no son exactamente lo mismo. Estos últimos buscan principalmente que el modelo ignore las restricciones con las que ha sido configurado y genere respuestas que deberían quedar bloqueadas. En nuestro paper Secure Journey to AI diferenciamos ambos tipos de manipulación y los situamos junto a otras técnicas dirigidas a extraer información o comprometer el comportamiento de los modelos.

En un entorno empresarial, lo importante no es únicamente que el chatbot produzca una respuesta inesperada. Si puede consultar información corporativa o utilizar otras herramientas, una manipulación también puede intentar aprovechar esos accesos.

■ La fuga de información puede producirse incluso sin un ataque sofisticado. Un empleado puede introducir datos sensibles en una herramienta no autorizada (uno de los riesgos asociados al Shadow AI) y una aplicación mal configurada puede devolver información a usuarios que no deberían verla. En retail, esto obliga a vigilar tanto lo que se introduce en una herramienta como lo que esa herramienta puede consultar o devolver.

Cuando la IA facilita una estafa o la suplantación de una marca

El riesgo también puede aparecer en torno a la marca, los canales y la confianza que el cliente deposita en ellos. En este sentido, la ponencia de David también puso el foco en la estafa y el daño reputacional. Entre los ejemplos utilizados en la diapositiva de análisis aparece la clonación de webs de concesionarios para ofrecer vehículos inexistentes: una página fraudulenta imita la apariencia de una empresa legítima y aprovecha esa confianza para engañar al usuario.

Es un patrón fácilmente trasladable al conjunto del retail. Puede adoptar la forma de una tienda falsa, una promoción inexistente, un supuesto canal de atención al cliente, un anuncio fraudulento o incluso un código QR que dirige al usuario a una página diseñada para robar información o realizar un pago.

La IA puede facilitar la creación y adaptación de esos contenidos, y el riesgo para la empresa no siempre depende de que hayan comprometido sus propios sistemas. Un cliente puede asociar la experiencia fraudulenta a la marca que ha sido suplantada, generando reclamaciones, pérdida de confianza y daño reputacional.

■ La protección no debería limitarse a las aplicaciones propias. También conviene prestar atención al uso fraudulento de la marca, los canales y las comunicaciones con clientes o empleados.

Disponibilidad y LLMJacking: dos formas distintas de abusar de los recursos

La denegación de servicio también aparece expresamente entre los riesgos de la presentación. Un volumen abusivo de peticiones o un consumo intensivo de recursos puede degradar una aplicación y afectar a un canal de atención al cliente, una tienda online, una plataforma comercial o un proceso interno que dependa de ella.

El LLMJacking o “robo de tokens” parte de una situación distinta. En este caso, un tercero consigue utilizar credenciales, claves o mecanismos de acceso legítimos para consumir servicios de modelos de IA sin autorización.

El impacto puede reflejarse en un aumento inesperado del consumo y de los costes e, incluso, en una reducción de los recursos disponibles para los usuarios legítimos.

■ Ambos problemas pueden terminar afectando a la continuidad del servicio y al negocio, pero requieren una lectura diferente: uno se centra en degradar o agotar una capacidad, y el otro en apropiarse de ella.

El riesgo digital puede trasladarse al entorno físico

El sector automovilístico añade una dimensión particular. Por el contexto de la presentación David señaló expresamente los riesgos para la seguridad vial junto al resto de amenazas.

Este riesgo se ilustra con los denominados adversarial attacks sobre señales de tráfico: modificaciones concebidas para intentar alterar la forma en que el sistema de visión artificial de un vehículo interpreta una señal.

El ejemplo ayuda a entender una diferencia relevante. En determinados usos de la IA una manipulación no termina necesariamente en una respuesta incorrecta o una fuga de información: puede afectar a la percepción que un sistema tiene de su entorno físico.

Esto no significa que cualquier alteración vaya a comprometer cualquier sistema de conducción. La robustez depende del modelo, del diseño de la solución y de las medidas de seguridad aplicadas. Pero sí muestra por qué, cuando la IA interviene en funciones relacionadas con vehículos, maquinaria u otros sistemas físicos, la evaluación del riesgo debe contemplar también las posibles consecuencias fuera del entorno digital.

¿Qué es un 'adversarial attack'? Del automóvil al retail

El ejemplo de las señales de tráfico alteradas ayuda a explicar cómo una modificación visual puede intentar cambiar la interpretación de un sistema de visión artificial. Este tipo de escenarios se ha analizado en pruebas experimentales con señales de tráfico, donde determinados patrones, adhesivos o modificaciones físicas pueden afectar a la detección de algunas señales.

El principio puede extenderse a otros sistemas que dependen de visión artificial, también en retail; por ejemplo, pueden existir aplicaciones orientadas al reconocimiento y valoración de productos, control de inventario, prevención de pérdidas o experiencias interactivas como los probadores virtuales. En estos casos, conviene evaluar si determinadas entradas visuales (imágenes, patrones, etiquetas o modificaciones del entorno) pueden alterar el comportamiento esperado del sistema.

Sin embargo, no toda manipulación visual es un ataque adversarial. Sustituir un código QR legítimo por otro que dirige a una página fraudulenta es un ataque diferente, aunque ilustra un problema relacionado: cuando una experiencia comercial conecta el entorno físico con sistemas digitales también conviene proteger aquello que personas y máquinas utilizan como punto de entrada.

Principales riesgos de la A en retail y un mismo reto: proteger la información, la operación y la confianza del cliente.

Fuga de información, fraude, denegación de servicio y LLMJacking no responden a la misma lógica; cada riesgo exige una lectura y una respuesta propias.

Proteger la IA combina tecnología, procesos y personas

La respuesta pasa por combinar medidas técnicas con hábitos y procesos claros. David destacó la doble verificación, la concienciación, la higiene digital, la detección de ingeniería social, la verificación de identidad y el reporte inmediato de anomalías, además de la importancia de trabajar con proveedores tecnológicos y partners de confianza.

Son recomendaciones aparentemente sencillas, pero responden a una idea importante ya mencionada: muchos incidentes no empiezan con una vulnerabilidad extraordinariamente sofisticada. Pueden comenzar con una credencial expuesta, una identidad mal verificada, una operación que nadie cuestiona o un empleado que introduce información en una herramienta que no debería utilizar.

A partir de ahí, la protección técnica debe adaptarse al contexto de cada aplicación.

Saber dónde utilizamos IA y qué puede hacer

Antes de proteger una aplicación de IA hay que saber dónde está y qué papel cumple. Un retailer necesita conocer qué soluciones utiliza, qué información manejan, quién puede acceder a ellas y qué acciones pueden realizar.

Esto incluye tanto las herramientas aprobadas por la empresa como aquellas que pueden haberse incorporado al trabajo diario sin aprobación formal.

No todas requieren el mismo nivel de protección. Un asistente que únicamente trabaja sobre información pública no presenta el mismo riesgo que otro conectado a datos de clientes, sistemas internos o procesos capaces de ejecutar acciones.

■ Antes de desplegar una aplicación de IA conviene revisar sus puntos de integración y probar cómo responde ante usos maliciosos o no previstos. En ese análisis pueden entrar pruebas frente a prompt injection, revisión de APIs, evaluación de accesos y técnicas de adversarial testing.

Limitar accesos y verificar las acciones sensibles

Cuando una aplicación necesita acceder a información corporativa, los permisos deben limitarse a lo que realmente necesita para cumplir su función.

Esto implica aplicar principios como la verificación explícita y el mínimo privilegio, la protección de credenciales e identidades humanas y no humanas, la clasificación de la información sensible y el uso de controles que ayuden a reducir el riesgo de fuga de datos. En ese enfoque entran medidas como la autenticación multifactor, las políticas de acceso, la prevención de pérdida de datos y la revisión de registros de actividad.

Pero el control no tiene que ser únicamente tecnológico. La doble verificación que planteó David resulta especialmente relevante cuando una operación tiene consecuencias económicas, modifica datos sensibles o puede afectar directamente a un cliente.

■ Aunque la IA puede ayudar a automatizar decisiones y procesos, eso no significa que todas ellas deban ejecutarse automáticamente y sin supervisión humana.

Preparar a las personas para detectar el engaño

Las técnicas cambian, pero la ingeniería social sigue aprovechando mecanismos conocidos: urgencia, confianza, autoridad o suplantación de identidad.

La posibilidad de generar textos, imágenes y otros contenidos de forma rápida puede hacer más creíble un intento de fraude. Los equipos necesitan criterios claros para reconocer señales de alerta y saber cuándo escalar una duda.

■ Comprobar el origen de una solicitud, verificar una identidad por una segunda vía cuando la operación es sensible y reportar cuanto antes cualquier anomalía siguen siendo medidas muy eficaces.

Detectar y reaccionar cuando algo no encaja

Ningún control elimina por completo el riesgo. Además de prevenir, conviene disponer de señales que permitan detectar comportamientos anómalos y actuar antes de que el incidente escale.

Los registros y la monitorización permiten investigar un incidente y determinar qué usuarios, datos o sistemas pueden haberse visto afectados. Según el caso, puede ser necesario revocar una credencial o un token, limitar temporalmente una capacidad, bloquear una integración o corregir una configuración.

Este enfoque puede entenderse como un ciclo de mejora continua: identificar riesgos, ajustar controles y aprender de cada incidente o desviación detectada.

■ También conviene saber de antemano quién debe actuar. Si una aplicación depende de modelos, servicios cloud o proveedores externos, las responsabilidades y vías de respuesta deberían estar claras antes de que aparezca el incidente.

Buenas prácticas para proteger la IA con mayor seguridad: personas, procesos y tecnología

Proteger la IA requiere saber qué se usa, limitar lo que puede hacer, verificar las acciones sensibles y preparar a los equipos para detectar señales de alerta.

Conclusión

La IA puede mejorar la atención al cliente, automatizar tareas y optimizar procesos de retail. Esos beneficios conviven con riesgos concretos: asistentes manipulados, fugas de información, suplantaciones de marca, abuso de recursos y, en determinados ámbitos como la automoción o la industria, posibles consecuencias fuera del entorno digital.

Aplicar controles sin entender el uso concreto de cada herramienta solo añade fricción. El punto de partida es saber dónde utilizamos IA, qué papel desempeña y qué pasaría si alguien consigue usarla de una forma distinta a la prevista.

En retail, incorporar IA requiere algo más que elegir una herramienta o activar un nuevo canal. La diferencia está en desplegarla con límites claros, datos protegidos y capacidad real para actuar cuando el riesgo aparece.

■ En Telefónica acompañamos este proceso combinando análisis del riesgo, medidas de protección y capacidad de actuación durante todo el ciclo de vida de la IA. Nuestra propuesta Secure AI ayuda a ordenar la adopción segura de la IA en tres ámbitos complementarios: identificar riesgos, proteger frente a amenazas y responder cuando algo se desvía de lo previsto.

______