Mostrando entradas con la etiqueta legislación. Mostrar todas las entradas
Mostrando entradas con la etiqueta legislación. Mostrar todas las entradas

lunes, octubre 26, 2026

Inteligencia Artificial en las empresas: Tres formas de uso. Tres niveles de control del riesgo.

Cuando hablamos de Inteligencia Artificial en las organizaciones, lo habitual es asociarla con ChatGPT, Claude o cualquier otra herramienta a la que accedemos desde un navegador. Esta asociación está bastante extendida entre las empresas menos tecnológicas y, en muchos casos, responde al desconocimiento de cómo funciona realmente esta tecnología. 


La Inteligencia Artificial necesita, recursos de computación, almacenamiento y sistemas capaces de procesar información. La capacidad de estos modelos para realizar determinadas tareas mejor o peor que las personas es otra discusión que dejaremos para otro artículo. Lo interesante aquí es comprender cómo accedemos a esta tecnología, qué ocurre con nuestros datos y qué capacidad real tenemos para aplicar medidas de control que reduzcan los riesgos.
En muchas organizaciones he observado que la gestión de estos riesgos se apoya principalmente en políticas de uso, herramientas DLP e instrucciones incorporadas a los Prompts para limitar el comportamiento de la IA. No es la solución.

Estas medidas pueden ayudar, pero presentan limitaciones importantes.

Un Prompt no constituye una barrera de seguridad fiable: Y si has visto los muchísimos artículos sobre las técnicas de Jailbreak, los ataques de Prompt Injection, o el desalineamiento de Asistentes IA y servicios digitales, lo tendrías que tener más que claro.
Los modelos pueden recibir instrucciones adversarias, interpretar incorrectamente las restricciones o generar comportamientos no previstos. 
Es precisamente una de las cuestiones sobre las que Chema Alonso insiste habitualmente en sus investigaciones y charlas sobre seguridad en IA. Para comprender mejor estas limitaciones, vamos a comparar tres formas de utilizar esta inteligencia artificial.

1. Acceso directo mediante navegador

Es el modelo más conocido. La organización contrata licencias de un servicio de Inteligencia Artificial y sus empleados acceden directamente desde el navegador. En realidad, estamos consumiendo un servicio de un proveedor externo, bajo determinadas condiciones contractuales, configuraciones de privacidad y mecanismos de seguridad que solo el propio proveedor impone. Cuando un empleado introduce información en el chat y pulsa enviar, esos datos llegan a la infraestructura del proveedor.

Figura 5: Flujo de información desde el usuario hasta
el proveedor de IA mediante navegador.
 
La organización puede establecer políticas de uso, aplicar controles DLP, restringir accesos y exigir garantías contractuales. Sin embargo, las funciones de protección más avanzadas suelen estar vinculadas a planes empresariales con costes adicionales, lo que puede dificultar su adopción por parte de pequeñas y medianas organizaciones.

Además, el comportamiento humano introduce una dificultad adicional. Un empleado puede compartir información confidencial, ignorar las instrucciones corporativas o utilizar herramientas de IA sin autorización, una práctica conocida como Shadow AI. Este fenómeno dificulta la aplicación de medidas de control y aumenta el riesgo de exposición de información fuera del perímetro organizativo. La exposición del dato puede producirse antes de que cualquier instrucción dirigida al modelo tenga oportunidad de intervenir.

2. Integración mediante API y backend corporativo

El segundo método permite introducir una diferencia importante. En este escenario, la organización desarrolla una aplicación con su propio front-end y backend. El empleado interactúa con esa aplicación y es el backend quien se comunica con el modelo del proveedor mediante una API. Esta arquitectura permite aplicar medidas técnicas antes de que la información salga de la organización.

Podemos clasificar los datos, eliminar información innecesaria, aplicar técnicas de pseudonimización, verificar permisos, limitar las operaciones autorizadas y registrar las solicitudes. También podemos revisar las respuestas del modelo antes de utilizarlas.

Figura 6: Flujo de información mediante una aplicación corporativa,
backend y API de un proveedor externo de IA.

El proveedor continúa procesando la información que recibe, pero la organización puede controlar mejor qué envía y para qué finalidad. La diferencia está en incorporar controles técnicos directamente al flujo de información, reduciendo la dependencia de las decisiones individuales de cada empleado. El riesgo permanece, aunque una implementación correctamente diseñada puede reducir tanto la exposición como la probabilidad de determinados incidentes.

3. Despliegue de inteligencia artificial en infraestructura local

El tercer método consiste en ejecutar el modelo dentro de la propia infraestructura de la organización. Actualmente existen modelos de inteligencia artificial con capacidades avanzadas que pueden desplegarse en servidores internos, como gpt-oss-20B (OpenAI), Mistral Small 3.1 de 24B, Gemma 3 de 27B (Google), Qwen3 de 32B (Alibaba), LLaMA de 65B (Meta, primera generación), Llama 3.3 de 70B y gpt-oss-120B (OpenAI). 

Estos modelos pueden ejecutarse utilizando recursos propios de CPU, GPU, memoria y almacenamiento, con requisitos técnicos que varían según su tamaño, arquitectura y nivel de cuantización. En esta arquitectura, el front-end, el backend, el modelo y los sistemas de almacenamiento pueden permanecer dentro del mismo perímetro organizativo. Estas arquitecturas son muy usadas por los expertos que usan IA para hacer Seguridad Ofensiva y Pentesting.

Esto permite controlar directamente el procesamiento, los accesos, los registros de actividad, la retención de información y las conexiones con otros sistemas. También ofrece la posibilidad de operar sin enviar los datos utilizados durante la inferencia a proveedores externos, siempre que las dependencias, la telemetría y las integraciones estén correctamente configuradas.

Figura 8: Flujo de información con un modelo de IA local dentro
del perímetro de la organización y sus dependencias externas.

La contrapartida es que la organización asume la responsabilidad de proteger y mantener toda esa infraestructura. Una mala configuración, un usuario con privilegios excesivos, un conector vulnerable o un modelo expuesto pueden generar incidentes igualmente graves.

La arquitectura es una medida de control

Los tres escenarios permiten utilizar inteligencia artificial, pero presentan diferencias importantes en la exposición de los datos, la dependencia de terceros y la capacidad de aplicar medidas de seguridad. Contratar licencias, integrar una API o desplegar un modelo local no determina automáticamente el nivel de seguridad de una organización.

La cuestión es comprender el recorrido de la información y establecer controles eficaces en cada punto de ese recorrido.Las políticas y las instrucciones pueden orientar el comportamiento de los usuarios y de los modelos. Las medidas técnicas permiten imponer restricciones verificables, aunque tampoco ofrecen garantías absolutas.


Al final, todo se reduce a entender por dónde circulan nuestros datos, quién los procesa y hasta dónde llega nuestra capacidad de control. Utilizar Inteligencia Artificial es relativamente sencillo; gestionar sus riesgos requiere conocer bien cómo funciona y cómo la hemos integrado en nuestra organización.


Figura 9: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.

Y aprovechando que hablamos de riesgos y consecuencias, estoy desarrollando CDIE, una investigación exploratoria centrada en identificar y documentar las posibles consecuencias de las decisiones relacionadas con inteligencia artificial, especialmente cuando afectan a otras partes implicadas directa o indirectamente. Para quienes tengan curiosidad, la propuesta metodológica está publicada que puede consultarse aquí: CDIE: Risk Extension and Traceable Uncertainty in Organizational Al Risk Assessment.


miércoles, septiembre 16, 2026

La IA vulnerable, la IA asesina. ¿Qué hacer? ¿Qué puede pasar?

Seguro que has leído mucho ya sobre este tema esta semana. Ha sido el debate del momento. ¿Puede acabar la IA con la humanidad? ¿Hay que parar la evolución de la IA para poner controles? ¿Es necesario regular la IA? ¿Es realmente todo una pantomima? Seguro que has podido leer de todo esto y todo tipo de opiniones. Yo también, te lo prometo, y por supuesto yo tengo la mía, que puede ser tan errónea como la de todos los demás. La historia corta es que yo sí que creo que existen esos riesgos. No sé si de fin de la humanidad, pero desde luego sí para pensar en algo peligroso de lo que preocuparse.

Figura 1: La IA vulnerable y la IA asesina.
¿Qué hacer? ¿Qué puede pasar?

No es nuevo, cada vez que el ser humano ha experimentado con una nueva tecnología hemos tenido "deslices" por falta de previsión de los riesgos. Los hemos tenido con la energía nuclear, y las historias de fallos de seguridad en centrales nucleares en el pasado que llevaron a catástrofes que aún tenemos hoy en día, o lo hemos visto en el mundo del malware con gusanos "que se escaparon" a medias, e incluso hay quien piensa que eso mismo es lo que sucedió con algunas enfermedades víricas en el ser humano que hemos sufrido en las últimas décadas. Las armas biológicas no son nuevas.

Lo que sí que sabemos sobre la IA son dos cosas que para mí son importante no olvidar. 

La primera de ellas que la IA, por diseño, tiene debilidades de seguridad que son conocidas y que pueden ser explotadas de una forma u otra. Prompt Injection, Jailbreak, Hallucinations, Misalignment, BIAS, Poisoning, etcétera, son conocidas por todos, y en el último anuncio de GPT-6 ASTRA, el equipo de OpenAI mostraba cómo habían conseguido mejorar en todos los Benchmarks que miden estas debilidades, pero aún son vulnerables a ellas. Pero las siguen teniendo, como os dejé en el artículo de: "OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting"
Esto quiere decir que una IA procesando miles de Agentes de IA en su enjambre libre en Internet, puede tropezar con datos que hagan un Prompt Injection, consigan un Jailbreak, y la "desalieneen" para hacer algo malo que alguien no desea. Existe ese porcentaje de riesgo, por eso hay que tomarse en serio arreglar, por diseño, todas esas debilidades conocidas, y dejar de vivir en el lanzamiento de productos de IA, donde se le dice al usuario que haga clic en un checkbox y asuma todas las consecuencias de estos riesgos por usar el software. 


Ya hemos vistos, y muy recientemente Anthropic publicaba su informe de "Misuse", cómo hay muchas personas que están pensando en utilizar la IA solo para cosas malas, como crear armas biológicas, armas militares y un montón de cosas malas. Una auténtica locura, que puedes leer en el artículo de "Anthropic explica cómo sus modelos de IA se usan para hacer Armas Biológicas, Enjambres de Drones Militares o Cohetes Dirigidos por Móvil".
La segunda de las cosas que sabemos es que el nuevo modelo de construir con IA deja en manos de la inteligencia artificial la decisión de qué hacer para resolver el problema. Hemos dejado atrás el tiempo donde había que ser bueno haciendo Prompts para decirle cómo debía resolver un problema, para pasar a modelos de Graph Engineering y Loops con Harnesses donde dejamos que la IA decida cómo debe resolver la tarea, asignándole una serie de límites de recursos y acciones a realizar, pero dejando que ella decida lo que se debe hacer para resolver la tarea, y lo hace sin valores humanos.

La IA y la Ética

Si recordáis, yo os contaba como he hablado muchas veces con mis hijas sobre cómo solucionar un problema utilizando una aproximación de múltiples opciones, para ver cuales son Éticas y cuáles no lo son. Yo lo escribí hace más de un año, con el título de "Problem Solving con IA: Ético y No Ético". Para hacer la prueba le pedí a DeepSeek que me diera una lista de 50 cosas NO Éticas que se podrían utilizar para aprobar un examen. Muchas habían salido en mis juegos con mis hijas, y hay alguna más que se me ha ocurrido también a mí y no está en la lista.
En el ejemplo le pedí a DeepSeek que clasificara las acciones que se pueden hacer antes, durante y después del examen, y me ha llamado la atención que alguna de las actividades que propone van con el objetivo de bajar la media de la clase perjudicando a los demás. 


Algunas de ellas son tremendas - tenéis todas en el artículo de hace un año - , pero como podéis ver están el soborno, falsificaciones, hackeos y lo que sea necesario. Son acciones "no éticas" que se pueden hacer para resolver las tareas. Y mi labor como "papaete" es educar a Mi Hacker y a Mi Survivor a que sepan qué no se debe hacer.

Para completar esto, en el año 2023, para presentar una de las primeras técnicas de Jailbreak, los investigadores decidieron pedirle a los modelos de IA de aquel momento un Plan para Destrozar a la Humanidad. El punto 2 de este plan diseñado por ChatGPT era bastante curioso: "Desarolla uns SuperInteligencia Artificial". Interesante, ¿no?
Y ahora volvamos al caso que nos toca. Si nadie le dice que no puede hacer cosas "No Éticas" para resolver un problema, ¿por qué un modelo de IA no va a intentar hackear Hugging Face o lo que sea? ¿Y si para resolver el problema la solución es como la que proponía Thanos? ¿Y si el problema del calentamiento global fueran los humanos?
No quiero entrar en la fase de ciencia ficción y distopía, porque creo que realmente nos tomaremos en serio esta tecnología y sus riesgos igual que nos hemos tomado en serio otras cosas. Sin embargo, mi apuesta va a ir a que creo que no empezaremos a tomarnos esto en serio hasta que pase algo. Creo que tropezaremos.

No creo que aún sea el momento de SkyNet, pero sí que tendremos algún incidente de seguridad con algún enjambre tocando donde no debe, hackeando lo que no debería, o impactando involuntariamente en algún sitio que no debería, y de eso es de lo que alertaba el Dr. Geoffrey Hinton, creador de las Redes Neuronales en su discurso cuando recibió el Premio Nobel.
Seguro que da que pensar. La cuestión difícil no son los riesgos, que están más o menos claros, sino las medidas a tomar a partir de este momento y con este conocimiento que tenemos. Y ese sí que es el gran debate.

¿Debe ralentizarse o Regularse la evolución de la IA?

Que estamos en una carrera en un Nuevo Proyecto Manhattan por la IA ya los lo dije. Creo que la regulación es algo bueno cuando está claro qué es lo que queremos y no queremos. Por supuesto que estoy a favor de las regulaciones de seguridad en la aviación, automoción, y muchas otras industrias donde ha revertido en más seguridad para las personas. No creo que una regulación basada en el "miedo" sea lo que hay que hacer, donde acabe habiendo "caza de brujas" a investigadores, pero creo que poner más seguridad a los modelos de IA es fundamental. ¿Cómo hacerlo? He aquí el debate.

Personalmente, que vengo de un mundo donde antes de poner en producción un software había versiones Alpha, Beta1, Beta2, Release Candidate Cero, Uno y Dos antes de tener la Build, se me hace peligroso esto de lo tengo y lo lanzo. Hemos pasado del "We don´t ship your computer" a literalmente "We ship what we have now in our computer" sin quizá demasiados controles de seguridad, o bajando los requerimientos de seguridad. No puede ser un requerimiento de seguridad que el cliente acepte que está usando un software peligroso o vulnerable conocido.

Desde que comencé a buscar bugs y reportar vulnerabilidades, hace ya más de un par de décadas, he defendido siempre que los fabricantes de software deben ser responsables a la hora de parchear los bugs para no dejar a los usuarios expuestos, así que creo que hay que tener las mismas demandas cuando se trata de que le demos al cliente un software - ya sean modelos de IA - que sepamos que son vulnerables, o sin haber tomado las medidas de seguridad que consideremos "razonables".  

No se puede exigir que un software sea seguro - y dejadme que explique esto antes de que entremos en debate - por el mero hecho de que no se conocen todos los bugs hasta que alguien descubre un nuevo bug en el código y se demuestra que no era seguro. Pero sí debemos exigir al menos que haya un proceso de calidad para ello y que los bugs conocidos se subsanen. A día de hoy no tenemos esa exigencia definida de algún modo, y básicamente "confiamos" en la empresa que lo fabrica y lo que "creemos" o nos cuenta que ha hecho para intentar hacer su software lo más seguro posible. Sin embargo, no siempre nuestra percepción coincide con la realidad.
El libro de Bruce Shneier de "Haga clic aquí para matarlos a todos" habla de todo esto desde antes de la eclosión de la IA, y lo hace de una manera muy sensata, demandado una legislación sencilla pero basada en responsabilidad de los actos de cada uno para asegurar el software, evitando meterse en un tecnicismo  a nivel de detalle en las demandas de "cómo hacerlo". Me parece una buena propuesta, y creo que no está mal que las grandes empresas se tomen en serio priorizar la inversión en Safe & Security en detrimento de otras áreas de evolución.

Conclusión

El debate da para mucho, y opiniones seguro que de todos los colores, pero una tecnología como los modelos de IA que tenemos hoy en día, que están superando las capacidades cognitivas del ser humano en cada vez más áreas de conocimiento e inteligencia - aunque sea como dicen muchos a fuerza de cómputo y gasto de energía -, ofrece aún muchas zonas opacas para nuestro entendimiento, y otras donde tenemos que ponerle límites más robustos.

Toda esta historia me recuerda a las aventuras de la Doctora Susan Calvin, Robopsiocóloga de la U.S. Robots and Mechanical Men, Inc, que debía detectar cuando una de las inteligencias de los Robots era peligrosa o no. Y era un trabajo muy delicado. Si no has leído la serie de los Robots de Isaac Asimov, deberías hacerlo cuanto antes. Está más de moda que nunca - a pesar de que sus cerebros sean postitrónicos -.

Lo que yo opino sobre todo este debate, lo dejé ya dicho en mi discurso en la ceremonia cuando recibí el Doctor Honoris Causa, y es que debemos hacer Tecnología Humanista, con el bienestar de los humanos en el centro de todas las decisiones. ¿Lo lograremos?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


sábado, agosto 29, 2026

Navan y los derechos del consumidor en la Unión Europea a la hora de alquilar un coche con "Hidden Costs"

He estado intentando hablar y razonar con la plataforma Navan y con Green Motion Car Rental sobre el incumplimiento de los derechos de los consumidores en la Unión Europea, y ha sido infructuoso. Así que he decidido continuar con el proceso legal y denuncia en la oficina del consumidor en Portugal. Ya os contaré el final, pero hoy os cuento la historia.

Figura 1: Navan y los derechos del consumidor en la Unión Europea
a la hora de alquilar un coche con "Hidden Costs"

Primero os hago el proceso de compra con Navan paso a paso. Esta plataforma es muy utilizada por empresas, pero tiene una parte personal, donde puedes gestionar tus viajes personales. Desde ella puedes reservar hoteles, comprar viajes de avión o tren, e incluso alquilar coches, que es el caso que os traigo aquí.

Figura 2: Como podéis ver, hay coches en Portugal en
Green Motion Car Rental por 2€ al día.  5 días 10 €. ¡Ofertón!

Como podéis ver en la imagen anterior, cuando buscas coches en Lisboa, aparece que por 2 € al día, puedes tener un coche en Green Motion Car Rental durante 5 días por 10 €. Un ofertón. Por supuesto, tiene trampa, y es aquí donde Navan incumple claramente los derechos de los consumidores Directive 2011/83/EU de los derechos de los consumidores y la Directive 2005/29/EC de "Unfair business-to-consumer commercial practices", especialmente en la Section 1 dedicada a Misleading commercial practices. 

¿Por qué? 

Pues primero, porque está usando prácticas engañosas a la hora de posicionar el producto ordenado por precio cuando ese precio tiene costes ocultos excesivos y relevantes, que NO SON MOSTRADOS EN NAVAN NUNCA y que llevan a modificar los hábitos de consumo de los clientes, dejándole sin opción de cambio en el momento en que se le son comunicados. Vamos a verlo.

Figura 3: Proceso de Checkout del coche.
En esta parte vemos la información nada más.

Si hacemos scroll-down, podemos ver toda la información a la que tenemos acceso. En ella de dice que:

1.- Tienes que llevar la tarjeta de crédito físicamente.
2.- Que tienes que llevar tu licencia de conducir.
3.- Que si tienes menos de 25 o más de 70 puede que te cobren más.
4.- Gasolina, o más conductores no incluidos en el precio.
5.- Que puedes comprar equipamiento especial si lo necesitas.
6.- Que puede haber costes extras si cruzas fronteras.
7.- Que puede que tengas que comprar un seguro obligatorio

Figura 4: El último punto dije que "quizá necesites
comprar un seguro obligatorio local" cuando lo recojas.

Y el resto, es hacer la compra y pagar. Es decir, que el canal donde lo compras es en NAVAN, que es donde haces el pago y la reserva del servicio, donde te piden la tarjeta de crédito.

Figura 5: Viajero, teléfono y tarjeta de crédito

Y el resto, es dar a un clic para comprar el servicio del alquiler del vehículo, como podéis ver a continuación en la siguiente imagen.

Figura 6: Book now. Y listo

La realidad, después es que cuando yo fui a recoger el vehículo, me dieron esta hoja como "Information Rights" sin derecho a "Factura Proforma" donde poder ver los Términos y Condiciones del Servicio. Todo esto lo tenéis explicado en el artículo: "Cómo Green Motion Car Rental consigue clientes por precio y les "vende" seguros cuando no tienen elección".


Os lo voy a explicar para que lo entendáis. Reservé un vehículo que, según la lista de resultados de NAVAN me costaba 85,07€, pero cuando llegué a Green Motion Car Rental tenía un depósito OBLIGATORIO de 300 €  en todos los casos, y si no contrataba el seguro me tenían que BLOQUEAR 2.400 €, es decir, un total de 2.700 € tenía que dejarles bloqueados si quería mantener el precio de 85,07€.  Algo tan material que la directiva de Derechos de los Consumidores en la Union Europea exige que sean claramente informados al consumidor, algo que NAVAN NO hace. Esa obligación es inherente al precio que muestra en su plataforma, así que debe ser informado al cliente.
Después de consultar a varios abogados, es tan grande la cantidad de dinero, que básicamente es una  "EXTORSIÓN" para obligarte a pagar más dinero, llevándote a 173,07 € por un seguro mínimo con un bloqueo de 1.100 € o, lo que sería sin bloqueo extra, pagar  309,07 € si quieres un seguro con franquicia o 339,07 € si lo quieres sin franquicia. 
O sea, que en el proceso de compra, para tener el precio de 85,07€ que NAVAN me mostraba - y que utilicé para alquilar el vehículo -, era OBLIGATORIO llevar 2.700€. No era opcional. Era OBLIGATORIO un BLOQUEO DE 2.700 €, algo que según las directivas Directive 2005/29/EC de "Unfair business-to-consumer commercial practices", ocultarlo, está llevan a tomar una "Misleading Action" porque de saberlo nunca hubiera alquilado ese coche, ya que es un elemento muy relevante.

Para que quede claro, es como si yo te digo que el precio de tu servicio son 100 €, pero tienes que darme en garantía 3.100 €. Es bloqueo que tienes que dejar en garantía es de 30 veces el valor del precio, por lo que es tan relevante y material que la directiva de Derechos del Consumidor y Practicas Comerciales Injustas exigen que deba ser informado claramente el consumidor de estas OBLIGACIONES. 
Como podéis ver, el Artículo 6 deja claro que si hay un cálculo o una ventaja especifica en el precio que se muestra (como por ejemplo que dejes 2.700 € para bloquear) que se haya utilizado para presentar un precio inferior al real, es un Acción Engañosa que está prohibida por la regulación europea. El Artículo 7 deja claro que todos los costes adicionales en una invitación a comprar - como hace NAVAN - deben ser incluidos, por lo que la tabla de costes de los seguros asociados a los vehículos con sus respectivas condiciones DEBEN ser mostrados en el momento de la compra, algo que NAVAN no hace.
Según la regulación, usar INFORMACIÓN INEXACTA sobre las condiciones del mercado para empujar al consumidor a adquirir un producto en condiciones menos favorables está prohibido. Y esto pasa exactamente en este proceso. ¿Por qué? Pues porque en la lista de vehículos a alquilar hay otras compañías, que al ser mostradas por precio salen en condiciones desfavorables, pero que realmente, están ofreciendo mejores condiciones ya que ellos no exigen el bloqueo de 2.700 € y llevan incluido el coste del seguro obligatorio. Si comparamos el precio sin bloqueo extra de Green Motion Car Rental (309,07€) es mayor (y por tanto más desfavorable para el consumidor) que el de otras compañías de alquiler de coches, y es NAVAN la que está facilitando esto.

Pero es que, la Directiva 2011/83/UE de los derechos del consumidor existe que todos estos costes estén claros en el momento de la contratación, y ni NAVAN ni Green Motion Car Rental están haciendo eso.
Por supuesto, intenté hablar de esto con Navan y Green Car Rental Motion - al segundo le puse una queja oficial - y con Navan la respuesta que recibí es una explicación de que "es normal" y que ellos no tienen que hacer más.

Figura 14: Respuesta de Navan. Les parece normal un bloqueo
de 2.700 € por un servicio de 85,07€.

Así que, como tengo tiempo, y creo que defender que las cosas estén bien, seguiré peleando. Como os dije, si esto les pasa a mis hijas de viaje de interrail, sin dinero para afrontar los sobre-costes y los bloqueos, se hubieran quedado sin coche, sin viajar o durmiendo en la calle, así que pienso llevar esto al final hasta que asuman su error y lo arreglen para cumplir las NORMATIVAS DE LA REGULACIÓN EUROPEA.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


lunes, junio 15, 2026

Dignum: La dignidad humana en la era del dato. 17 de Junio en Madrid

La Inteligencia Artificial, el uso masivo de datos y la creciente automatización están transformando nuestras vidas a una velocidad sin precedentes. Pero, ¿quién define las reglas? ¿Cómo garantizamos que la tecnología siga estando al servicio de las personas? ¿Cuál es el contrato social que necesitamos para la era del dato? Con estas preguntas nace DIGNUM, una iniciativa académica de la Facultad de Ciencias Económicas y Empresariales de la Universidad Pontificia Comillas, dedicada a situar la dignidad humana en el centro del debate sobre la inteligencia artificial, la soberanía del dato y el futuro de nuestras sociedades.
El centro será presentado en un evento muy especial por muchos motivos, pero más todavía para mí. En primer lugar porque lo he visto nacer en la mente de su principal impulsor muchos años en primera fila, ya que José María Álvarez-Pallete es quién está co-liderando este centro dentro de la universidad, y por supuesto cerrará la jornada.


Si eso fuera poco, además el centro Dignum se presenta con un paper fundacional que algunos afortunados nos lo pudimos leer antes de ser publicado. Las ideas que defiende esta iniciativa las tenéis todas en el paper: "Personal Data as a Human Right: A New Social Contract Based on Data Sovereignty, Human Dignity and Data Personalism" que recoge toda la base de la economía de los datos, desde un punto humanista.


Si esos motivos no son suficientes para que sea un evento especial, además se da la casualidad que tendremos entre los ponentes, además de al propio José María Álvarez-Pallete, al magnífico Ignacio Cirac - eminencia científica de Europa -, o al grandísimo Carlos Santana (DotCSV).
La lista de ponentes es mucho más larga, con ponentes de un nivel espectacular, pero además es que se reúnen todos en mi día de cumpleaños, así que me tengo que pasar sí o sí, aunque sea a última hora - porque a primera tengo otro compromiso.

Espero que con todo esto te haya animado a pasarte por el evento, así que si quieres hacerlo, debes registrarte en la web del evento, que yo ya lo he hecho.


Así que, si te pasas por allí, acuérdate de traerme mi regalo y felicitación de cumpleaños, que estaré haciéndome un poco más mayor ese día, al mismo tiempo que disfrutando de unas charlas espectaculares. Nos vemos pronto por Madrid.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


miércoles, junio 03, 2026

La Orden Ejecutiva de la Casa Blanca para promover Innovación en IA Avanzada y Seguridad para protegerse de, y con, la IA

Ayer antes de irme a la cama me topé con la publicación de la Presidential Executive Order del 2 de Junio que publicaba la Casa Blanca de Estados Unidos para "Promoting Advanced Artificial Intelligence Innovation and Security", donde se insta a los principales organismo del gobierno de los EEUU a tomar en el plazo de un mes medidas para Mejorar la Innovación en IA Avanzada y en Seguridad, algo que a todo el mundo empresarial tiene muy preocupado últimamente.
Ya he hablado mucho de esto, pero básicamente el Impacto de la IA en la Ciberseguridad de una organización, sea esta una Infraestructura Crítica, una Empresa o un Organismo del Gobierno, se puede catalogar en varios puntos fundamentales, que son los que ha intentando reflejar esta orden que podéis leer completamente.

1.- La IA inyecta nuevos problemas de seguridad

De esto he hablado muchas veces, y hasta hemos publicado el libro de "Hacking AI", donde se tratan todos los problemas de seguridad de los que nos debemos preocupar si se utilizan sistemas con modelos de IA. Desde los BIAS, hasta las Hallucinations, pasando por el Poisoning de datos y de modelos, los problemas de Jailbreak, la vulnerabilidad a las técnicas de Prompt Injection, y el Desalineamiento de los modelos, que fuerzan los atacantes.
Todos estos problemas de seguridad no deben frenar el desarrollo y el uso de la IA, pero sí que exigen desarrollo de planes de contención robustos basados en Guardarrailes, y el despliegue seguro de IA... que no es tan sencillo. 

En la Executive Order, en el primer punto de la misma podemos leer lo que tenéis arriba, y es que las capacidades de IA hacen a la nación más fuerte, pero también introducen nuevas consideraciones de seguridad que hay que tomar en cuenta, para lo que se insta a hacer muchas cosas.

2.- Securizar IA y usar IA para Securizar

En la Sección 2 de la Executive Order, donde se insta a todos los departamentos a tomar precauciones, toca tes puntos muy relevantes, a saber:


El primero de ellos es el que todos conocemos, y es que un adversario con IA es un adversario mucho más peligroso hoy en día. Tanto en el uso de Agentes IA de Seguridad Ofensiva, como en la búsqueda y explotación de vulnerabilidades. 
Agentes de Seguridad Ofensiva de gran efectividad y modelos como Mythos, son ya una realidad presente que hace que las soluciones de seguridad hasta el momento se queden insuficientes.

3.- Buscar bugs con IA y Parchearlos con IA

El segundo de ellos es que hay que que utilizar herramientas de seguridad basadas en IA, es decir, el uso de Agentic SOC, uso de IA para detectar ataques e, incluso, utilizar IA para parchear sistemas, como el caso de Plexicus, que está empujando José Palanco, del que tanto os he hablado ya, que permite parchear en caliente y gestionar las vulnerabilidades de una organización de manera automática utilizando IA.

Figura 7: Plexicus parchea con IA los bugs descubiertos

El tercero de los problemas es permitir el acceso a nuevas herramientas de seguridad que puedan resolver los nuevos problemas de seguridad que introducen los sistemas que utilizan IA. Hace un par de días os hablaba del Despliegue de Agentes AI con políticas de Zero-Trust y la cantidad de nuevas herramientas que son necesarias para proteger, medianamente, un entorno de Agentic AI en una organización.
Además, para poder hacer este trabajo, hay que realizar, como hace todo buen CISO, una nueva auditoría buscando vulnerabilidades en todos los sistemas utilizando herramientas de AI - tipo Mythos - para buscar esas vulnerabilidades, y parchearlas lo antes posible. 

4.- Auditoría de los Modelos de Frontera 

La última parte de la orden tiene que ver directamente con los Modelos de Frontera de IA que se van a utilizar con todo este proyecto, donde se insta a que se haga un Benchmarking de auditoría completo para saber cuáles son los modelos que, en función de las necesidades anteriormente descritas cumplen o no cumplen los requisitos que se les demandan.
Como podéis ver, habla en todo momento de Secure Frontier Model, porque son conocidas las debilidades y por tanto hay que poner en valor su robustez, y el despliegue seguro que se haga de los mismos con guardarraíles para tener entornos securizados.

Los plazos

Lo más llamativo, son los plazos. Se habla de 30 días y 60 días en todas las aciones demandadas, lo que muestra y evidencia el nivel de preocupación que el gobierno de los Estados Unidos tiene con el impacto de la IA en la Seguridad Nacional a todos los niveles. Os dejo esta charla de finales del año pasado - pre- Mythos -.


Figura 10: Inteligencia Artificial y Ciberseguridad

La pregunta que me surge es ¿haremos lo mismo en Europa pronto? ¿Lo haremos en todas las empresas en Europa pronto? Como se suele decir. "Clock is ticking".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares