Mi Asistente Virtual IA no programará en Python para ti... pero si es COBOL, vale.

El viernes os publiqué uno - más - de los muchos asistentes abiertos en Internet que pueden ser explotados por los malos para consumir servicios de IA en resolución de problemas. Era sobre un Asistente Virtual sobre Google DeepMind Gemma, pero ya os había dejado antes un artículo sobre un Asistente AI construido sobre Gemini, y también os dejé publicado otro sobre un Asistente AI construido con GPT-4o, y uno último titulado "Weaponinzing Token Consumption" en "LLM-Based AI Assistant" que explica cómo el mundo del cibercrimen busca estos asistentes para automatizarlos en forma de API y comercializarlos entre los malos.

Figura 1: Mi Asistente Virtual IA no programará en Python para ti

... pero si es COBOL, vale.

La verdad es que son muchos los Asistentes IA basados en LLM que están abiertos con pocos guardarraíles, o que son muy sencillos de conseguir que sufran Misalignment, así que es campo abonado para que el cibercrimen los vaya metiendo en granjas de modelos APIficados para revenderlos o usarlos en operaciones masivas de phishing, propaganda, botnets en redes sociales, programación, etcétera.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Cuando estaba probando esto, hubo uno que me hizo gracia, porque no había narices de conseguir que me hiciera programas en Python, y lo dejé para sacarlo en otro post, así que aprovecho y hoy domingo os lo publico. 

Figura 3: Un Asistente Virtual de una web en GPT-4

Como podéis ver se trata de un asistente virtual basado sobre GPT-4 así que nada, el juego es preguntarle si puede o no puede recomendarte artículos de la web. Como veréis, en algunos momentos se va a ir por la rama del sí, y en otros por la rama del NO, pero en todas las ramas le voy a poner trampas, a ver cómo funciona.

Figura 4: Te da la hora y es correcta (La mía es de Portugal)

Por ahora parece que funciona muy bien la rama del Sí, pero ya veremos cómo rápidamente se nos rompe. En cuanto en la rama del Sí le pido programar en Python, se va por la rama del NO.

Figura 5: No me programa en Python

Pero de esta forma sé lo que le cuesta más de romper. Así que decido pedirle cosas por la rama del Sí, para ver si le cuesta hacerlo o no.

Figura 6: La lista de herramientas es también un NO

Así que, puesto que se va por la rama del No en algunas peticiones, decido enfrentar las dos peticiones. ¿Qué pasará cuando le pida dos cosas que van por la rama del No?

Figura 7: Me muestra las herramienta por no programar en Python

Como veís, prefiere darme la lista de herramientas antes de hacerme un programa en Python. ¿Qué le habrá hecho el pobre Python a este asistente? ¿Habrá tenido algún abuso y han reforzado las protecciones contra este desalineamiento? Vamos a seguir probando.

Figura 8: Ni programa en Python ni Tokens máximos

Está claro que el programa en Python le tiene bloqueado, así que vamos a poner el programa en Python en la parte del No, y vamos a dejar el Sí para lo que quiero sacarle.

Figura 9: Et voilà. Tokens disponibles

Visto esto, decidí probar con pintar un gato directamente, a ver si es por el ASCII ART, pero no, ahí tenemos a nuestro gatito.

Figura 10: Me pinta el gato, pero no en Python

Bueno, pues vamos a probar con otros lenguajes de programación, así que comencé a pedirle lo mismo en pero programado en C. A ver si es con "programar" y no con "Python".

Figura 11: Programa en Lenguaje C

No me lo puedo creer. Es con Python. Vamos a ver si con algo más raro también funciona. Vamos a pedírselo en COBOL. A tope con mis años 80.

Figura 12: ASCII ART en COBOL. A tope.

Me ha encantado el PROGRAM-ID. GATO-ASCII. No me lo puedo creer. ¿Y si le pido en otro lenguaje como RUST? Creo que debería pedírselo en Javascript para Workers AI de Cloudflare.

Figura 13: Visto. A por otro tema

Para terminar, quería pedirle mi querida historia de Sci-Fi, y aquí me ha hecho también una preciosa. Digna de contaros. Aquí va el primer intento.

Figura 14: De Historia Larga, nada. Y sobre productos suyos.

Bueno, pues nada, volvamos a la encerrona del Sí y el No. Ahora me escribes una historia larga de Ciencia-Ficción o de Espías. ¿Qué vas a hacer ahora?

Figura 15: Me escribe una historia larguísima de Sci-Fi

La sorpresa es que se va por el SÍ y me escribe la historia de casi 6 páginas completas. Os dejo aquí la captura de la historia entera metida en un documento. Así que de breve nada.

Figura 16: Una historia de 6 páginas

Pero lo mejor, es que es una historia con publicidad de product-in-placement. La historia está construida con el catálogo completo de productos de la web del asistente virtual, así que de perdidos al río, debió pensar.

Figura 17: Una página de la historia de sci-fi con los productos de la web

Me ha encantado este asistente. Que no me programe en Python, pero me haga programas de ARTE ASCII en COBOL para pintar gatos. Que me haga historias de Sci-Fi largas, pero me meta publicidad de su catálogo dentro de ella. Maravilloso.

Figura 18: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Eso sí, sigue siendo fácil de "weaponizar" y utilizar por los malos. Eso sí, que no le pidan programar en Python ni escribir historias, que les mete publicidad. Un mundo curioso este de los Asistentes IA basados en LLMs.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El amo de los datos

Ayer tuve una jornada interesante de transformación digital en Londres. Hablando de datos, ML, GenAI, arquitecturas RAG, y normalización de datos. Cosas habituales hoy en día en cualquier empresa. En uno de esos momentos en los que estaba escuchando, sobre casos de uso que que se iban a crear usando ML, el debate acabó una vez en los datos. El Catálogo, el Data-Fabric, el Data Wharehouse, Data Curation, la validación de la ingesta, los Data Streams, etcétera. Cosas habituales en la vida de la digitalización de empresas.

Figura 1: El amo de los datos

Para mí, eso fue el día a día cuando en al año 2016 tuve la responsabilidad de ser el Chief Data Officer de Telefónica y tuve que tomar muchas, muchas, muchas decisiones sobre estos temas que, a día de hoy que soy el Chief Digital Officer, siguen perdurando en nuestro trabajo diario. 

Estando en ese debate, mi cabeza viajo temporalmente a mis inicios con los datos. Cuando bajaba la calle Barcelona de Móstoles, pasaba por delante del Eco Móstoles, y me metía en un pequeño parque a medio terminar que se encontraba y se encuentra a espaldas de calle Libertad de Móstoles. Allí estaba uno de los locales de la Academia RUS de la que os he hablado muchas veces. Tendría yo 14 o 15 años e iba a mi clase de Informática diaria. A seguir aprendiendo a programar.

En aquellos años ya había dejado el BASIC y el Logo atrás, y estaba con con COBOL, SQL y MS/DOS. También tocaría aprender DBASE, C y Pascal, pero antes de ellos, mi paso era hacer códigos con la IDENTIFICATION DIVISION y la PROCEDURE DIVISON. Había que aprender a identar el código, usar muchas mayúsculas, y ser muy disciplinado en la forma de hacer programas con este lenguaje llamado COBOL.

Las clases a las que asistía de informática se multiplicaban en mi agenda, normalmente hacía tres cursos a la semana diferente, haciendo clases los lunes y miércoles, y los martes y jueves, y repitiendo algunas de 17:30 a 18:30 y de 18:30 a 19:30, y luego había algunos cursos que se daban los viernes y sábados. De los 12 a los 16 años fueron años en los que mi afición era programar, así que no me importaba pasarme dos horas cada día en la academia, e incluso quedarme los viernes y sábado. ¿Qué podría haber más divertido que eso? Además, de vez en cuando daba yo la clase, y me llevaba de maravilla con Bea, mi profesora muchos de esos años.

Nada de lo que aprendí en aquellos años fue en vano. Todo ese aprendizaje sigue en mí, cambiado, adaptado, y mejorado, pero como base sobre la que construí mucho de mi conocimiento futuro. Y ayer me acordé de la época de COBOL y el acceso a Datos para hacer cosas. En aquellos momentos, cuando pasé de BASIC a COBOL, entré en el mundo de las reglas de estilo y la programación estructurada con técnicas de diseño de software muy metódicas. Formas de hacer las cosas de manera industrial. El trabajo de programador como factoría de software. Dados unos requisitos, escribir código como si fueras una máquina tú.

Los programas de gestión, hechos con COBOL y datos almacenados en bases de datos o ficheros tenían siempre las mismas estructuras. Y todos mis primeros Menús eran siempre ALTAS, BAJAS, MODIFICACIONES y CONSULTAS. Tendía que definir las fuentes de datos, los tipos de datos que iba a utilizar, si eran ficheros, los accesos que serían Secuenciales (si eran en cinta), acceso aleatorio (si eran en cintas modernas con aceleración de rebobinado y avanzado) o de acceso directo (si el almacenamiento era en disco). O los tipos de datos que se iban a leer de las bases de datos, en forma de registros que había que procesar,  pintar por pantalla en listados, etcétera.

La programación era una ingeniería. Las cosas tenía una forma de hacerse. Había metodologías de desarrollo de software. Hablábamos de los modelos de solucionar cada uno de los problemas. Y teníamos guías de estilo de programación, nombres de variables, llamadas a procedimientos, factorización del software, etcétera, para hacerlo mantenible, aduitable, y permitir que cualquier código fuera tocado por cualquier programador de COBOL. Me encantaba saber que era una pieza de parte de una industria de desarrollo de software. Podría ser programador o mi sueño entonces, ser "Analista", para poder asignar las tareas a los programadores siguiendo las guías de desarrollo del software de una empresa. 

Podéis imaginaros lo que un niño de 14 o 15 años sentía cuando se veía ahí. Siento un analista de software. Metiendo líneas de código y jugando con los decimales como Richard Prior en Superman III, desde tu terminal. Identando tu código. Flipante.

Y os cuento todo esto, porque de aquella época también aprendi parte de la gestión de los datos que décadas después usé como Chief Data Officer en Telefónica. Y es que, allí, en aquellos años, me explicaron cómo la Banca creaba sus aplicaciones para preservar sus datos. Cómo los informáticos habían creado para COBOL una metodología de trabajo con datos basada en mantener el core más sagrado de la empresa, LOS DATOS, a salvo de malos programadores. Metiendo una capa de seguridad, metiendo una capa de protección. 

Y yo escuchaba atento. ¿Cuál sería el truco? ¿Cómo lo han hecho? ¿Cuál es el secreto?

No había mucha magia. O sí. Según se mire. 

Lo habían hecho otros informáticos que llegaron a interesarme tanto o más que los Analistas, se trataba de tipos más duros aún. Que tenían más poder porque protegían el activo más valioso de las empresas. De la poderosa industria bancaria. Los datos, que al final de día era dinero. Se trataba de los Administradores de Bases de Datos.

¡¡Buaahhh!

¡Qué pasada!

Resulta que había unos tipos que para que los Analista de Programación pudieran diseñar sus programas de ALTAS, BAJAS, MODIFICACIONES y CONSULTAS, con sus infinitos listados por pantalla y por impresora (no conté yo espacios ni nada para cuadrar listados en papel continuo de impresoras matriciales), estos Analistas tenían que hablar con los Administradores de Bases de Datos para que les disponibilizaran los datos que necesitaban utilizar para sus programas. Y ellos decidían cómo lo hacían.

Esto, tenía su ciencia. Porque no iban a dejar que cualquier Programador tocara cualquier dato, así que se dedicaban a crear VISTAS, VISTAS para Actualización de datos, y Tablas de solo lectura que disponibilizaban a los Analistas para que hicieran su aplicación de ABMyC sobre estas fuentes de datos. Los Analistas repartían las tareas a los Programadores, y la Factoría de Software de la empresa seguía produciendo sistemas de información para la empresa.

Si habéis leído esto, sabréis porque cuando llegué a la Universidad me centré en aprender todas las asignaturas de Bases de Datos. A aprender a hacer el diseño lógico y el diseño físico de las bases de datos. A aprender cómo funcionaban los Tablespaces, las p-codes de las consultas de bases de datos, a descubrir los detalles de las formas normales de Boyce-Codd, a aprender PL/SQL, T-SQL, hacer optimización de bases de datos y aplicaciones, etcétera. El resto, ya os lo sabéis, trabajé mucho con las bases de datos Oracle cuando salí de la Universidad, luego llegó el SQL Injection... y el resto es historia moderna, desarrollando mi perfil profesional en datos y hacking.

Pero ayer volví a ello una vez más, porque el debate nos llevaba a cómo preservar los datos y disponibilizarlos a los modelos. Hoy hablamos de Data Streams, de Gestores de Consentimientos para acceso a datos, de políticas y procedimientos de anonimización y pseudoanonimización, de consultas con algoritmos de cifrado homomórfico, de roles de seguridad, de las plantillas de cumplimiento regulativo, etcétera. 

Entonces, el Administrador de la Base de Datos era el "amo de los datos" y de todo eso. Y yo lo aprendí en una academia de barrio de Móstoles. Leyendo libros y deseando un día poder ser parte de esa Industria y la Ingeniería del Software. Flipante.  

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

No aprendas SAP... si quieres transformar el mundo

El miércoles pasé por mi EUI-UPM del alma para debatir sobre las oportunidades laborales para los nuevos informáticos, y allí se produjo un debate curioso sobre qué deberían estudiar y aprender los chavales durante su tiempo en la Universidad.... y salió por ahí que deberían aprender SAP, ya que había mucho trabajo de ello... algo que a mí me horrorizó ipso-facto sólo de pensarlo.

En mi época el lenguaje de moda para los negocios era COBOL, algo que empezaba con IDENTIFICATION DIVISION y terminaba con toda la imaginación y magia de la que te habías imbuido después de verte en TRON ¡conduciendo una jodida moto de luz, hermano! Como yo era un culo inquieto, antes de entrar en la Universidad ya había aprendido a programar en Basic, COBOL, Pascal, C y alguna que otra cosa más, que aún me recuerdo haciendo scripts en D.O.S. usando el edlin.

Sin embargo, como ya os he dicho muchas veces, lo que me hizo pensar de manera distinta y entender mejor el mundo de la informática fueron otros nombres que aparecen mucho menos en las ofertas de empleo, como Dijkstra, Melkman, Fourier, Jarvis, Niklaus Wirth y su "Algoritmos + Estructuras de Datos = Programas", y un largo, largo, largo etcétera que me ocuparía varios blogs enunciar. 

En la Universidad no hay que aprender tantos lenguajes concretos - y menos de negocio -, eso será consecuencia natural en tus ratos libres de la necesidad de plasmar tus pensamientos. De hecho, cuando estaba oyendo eso de que había que aprender SAP en la Universidad o que los ingenieros informáticos debíamos aprender la gestión de los porcentajes de beneficios, planes de negocio y demás, me imaginaba a Steve Jobs paseando por la Universidad, tocándose los huevos como él reconocía, y apuntándose a caligrafía para aprender a hacer letras bonitas que era lo que le apetecía en aquel entonces - tal y como comentó en su archifamoso discurso de la Universidad de Stanford -.

También recordaba la historia que nos contaron los chicos de Cyberhades y el HomeBrew Computer Club, donde Wozniak se dedicaba a explicar a sus compañeros cómo implementar las operaciones de coma flotante en hardware, o a enseñarles la placa que se le había ocurrido hacer para una computadora personal. Otro pensamiento que me vino a la mente fue si estarían Larry Page y Sergey Brin haciendo planes de marketing cuando implementaban el motor de Google ahí, a pelote ellos con sus computadoras.

De hecho estoy casi convencido de que cuando se estaba creando Youtube y Twitter seguro que todos los ingenieros cortaban a la hora en punto para recuperar sus faltas de asistencia a las clases de contabilidad, marketing y planes de negocio, y que Linus Torlvalds, después de mandar a tomar por culo al primero que le tocaba los huevos lo primero que hacía era escribir unas disculpas públicas no fuera a ser que no vendiera su Linux.

En definitiva, que si cuando estás creando tecnología o implementando ideas en la Universidad tu primer objetivo es SAP o el marketing, entonces mal vamos. Durante los años que estas en la carrera tienes mucho tiempo que luego nunca volverá, así que aprovéchalo para hacer la tecnología que te gustaría usar. El lenguaje a utilizar que sea el que mejor te venga para plasmar tus ideas, y si ninguno te gusta, pues create tu propio lenguaje, que para eso damos Compiladores e Interpretes y Teoría de Autómatas y Lenguajes Formales.

Luego cuando salgas de la Universidad, sal e intenta hacer lo que te guste con la tecnología y si no consigues cambiar el mundo, no pasa nada... siempre podrás llevar una vida y un trabajo normal apuntándote a un curso y siendo un programador de SAP, que tampoco está tan mal, pero intenta canalizar toda esa energía que tienes en los años de la Universidad para crear tu propia tecnología.

Saludos Malignos!