Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos la guía definitiva para sobrevivir
a la sopa de letras de la inteligencia
artificial, de proyectos a agentes autónomos.
Hola, ¿qué tal?
Encantado de estar aquí para, bueno, para intentar
desenredar todo esto un poco.
Porque tela, ¿eh?
Imaginemos por un segundo que en el tiempo
que tardamos en grabar este análisis a fondo,
un asistente invisible hubiera leído y clasificado nuestros
últimos 500 correos electrónicos y que además hubiera
leído y clasificado nuestros últimos 500 correos electrónicos.
Hubiera negociado un presupuesto con un proveedor.
Y hasta programado un pequeño videojuego para móviles,
¿eh?
Exacto, y todo eso sin que nadie haya
tocado un teclado.
O sea, no es ciencia ficción, es lo
que ocurre cuando dejamos de tratar a la
inteligencia artificial como un buscador glorificado y entendemos
cómo funcionan los agentes autónomos.
Claro, el problema es que la industria tecnológica
asume que todo el mundo comprende la diferencia
estructural entre darle una instrucción a un chat
genérico y, digamos, programar un entorno cerrado.
Totalmente.
Y claro, el problema central ahora mismo es
la sobrecarga absoluta de jerga técnica.
Cada semana abres las noticias.
Y hay un bombardeo.
Que si skills, agents, projects, gems, plugins… Madre
mía, parece que hace falta una ingeniería solo
para entender el menú de inicio.
Ya, y la paradoja reside en que toda
esta arquitectura de software se diseñó originalmente para
eliminar fricción, no para generar esta frustración.
Si entiendes las diferencias, dejas de pelearte con
la IA.
Y pasas a ser tu asistente.
Por eso la misión de hoy es traducir
todo este lenguaje alienígena a herramientas prácticas del
día a día.
Porque hay una diferencia abismal entre memorizar un
glosario y saber cómo ensamblar estas piezas.
Eso es.
Hay que saber ensamblarlas para que ejecuten trabajo
real.
Así que vamos a empezar por los cimientos.
A ver, el entorno de trabajo.
Si pensamos en nuestra relación actual con la
IA, se parece bastante… Se parece bastante a
un escritorio lleno de papeles desordenados.
Un caos absoluto.
Sí, sí.
Miras el historial de uso de una cuenta
promedio y hay un chat sobre la receta
de una tarta de mancena, seguido de otro
sobre física cuántica y luego, yo qué sé,
un borrador para un despido improcedente.
Todo mezclado en el mismo sitio, claro.
Exacto.
Según la documentación que manejamos, los famosos proyectos
o projects nacen para solucionar esto, como si
fueran archiveros con instrucciones estrictas.
Pero mi duda es, ¿qué cambia exactamente a
nivel técnico al meter un chat dentro de
un proyecto?
Pues, a ver, lo que cambia es la
gestión de lo que llamamos la ventana de
contexto.
En un chat normal, la IA arranca en
blanco.
No sabe quién habla ni qué se espera
de ella.
Vale, parte de cero.
Eso es.
Al crear un proyecto, estamos configurando una capa
de memoria a largo plazo que envuelve a
todos los chats que abras ahí dentro.
Si subes el manual de recursos humanos, o
los procesos de facturación… O el manual de
identidad visual… Claro, cualquier cosa.
El sistema inyecta esos documentos en el prompt
del sistema de forma invisible antes de cada
respuesta.
La IA restringe su conocimiento a ese universo
documental.
O sea que el proyecto precarga toda esa
información en milisegundos para que la IA actúe
como un empleado que ya se ha leído
los manuales de la empresa, ¿no?
Efectivamente.
Cualquier respuesta estará alineada con esas reglas, acabando
con la necesidad de recordarle constantemente el contexto.
Vale, vale.
Entonces, el proyecto nos… Nos da un entorno
ordenado y privado.
Pero luego la industria nos bombardea con otro
término, los GPTs personalizados, o GEMS, en el
ecosistema de Google.
Sí, los famosos GEMS.
A primera vista parece lo mismo.
O sea, ¿para qué hace falta crear un
GEM si el proyecto ya te organiza la
información?
Pues la división fundamental aquí es la protección
frente al usuario y la hiperespecialización.
Un proyecto es una mesa de trabajo dinámica
maleable.
Un GPT personalizado, por el contrario, es como
empaquetar a un becario hiperespecializado en una caja
sellada.
Ah, vale, en una caja sellada.
Sí, se utiliza cuando tenemos un proceso muy
afinado.
Por ejemplo, un humanizador de textos para redes
sociales.
Y queremos compartirlo con todo un departamento sin
que nadie rompa la configuración.
O sea que actúa como un guardián.
Exacto.
El GPT personalizado bloquea las instrucciones base para
que un compañero no modifique accidentalmente el comportamiento
del modelo.
Y menos mal que existen esos candados.
Porque repasando las fuentes, hay una anécdota reveladora
sobre los GEMS de Google que demuestra por
qué no podemos dejar a la IA operar
libremente en tareas repetitivas.
Sí, la de la generación de imágenes, ¿verdad?
Esa misma.
Resulta que, a la hora de generar imágenes,
al modelo a veces se le cruzan los
cables por la configuración de temperatura o creatividad
y decide añadir 200 palabras sin sentido flotando
en el cielo de la imagen.
Sí, o de repente...
Se renderiza todo en tonos verde cazador, porque
encontró un patrón estadístico irrelevante.
Madre mía.
¿Y por qué hace eso?
Ese fenómeno se conoce como alucinación inducida por
falta de restricciones.
Si dejamos el modelo abierto, la IA intenta,
digamos, sobrecomplacer, añadiendo elementos que cree que aportan
valor.
Claro, se viene arriba.
Se viene muy arriba.
El GPT personalizado soluciona esto mediante lo que
llamamos prompts negativos estructurados.
Le decimos a nivel de código, bajo ninguna
circunstancia, vas a incluir texto en los píxeles
generados.
Y cero verde.
Vale.
Y al empaquetarlo en un gem, ese problema
desaparece para cualquiera que pulse el botón de
generar.
Entendido.
Esto resuelve el caos dentro de una plataforma
concreta.
Pero aquí me surge un problema operativo bastante
gordo.
A ver, cuéntame.
Si hoy configuramos toda esta maravilla en el
ecosistema de OpenAI, pero mañana la empresa decide
migrar a Cloud o a Grok, ese entorno
ordenado se queda atrás.
¿Cómo evitamos perder meses?
¿Cómo evitamos perder meses de trabajo afinando instrucciones?
Ah, buena pregunta.
Y aquí es donde entra el concepto de
las skills o habilidades.
Ya.
Pero francamente, leyendo la documentación, tengo una teoría
que necesito poner a prueba contigo.
¿Acaso una skill no es simplemente un bloc
de notas donde hemos guardado un prompt muy
largo para copiarlo y pegarlo cuando nos haga
falta?
Fíjate, esa es la trampa mental en la
que cae la mayoría de la gente.
Pero mecánicamente son universos distintos.
Un prompt copiado es lenguaje natural estático.
Vale.
Una skill, sin embargo, es un flujo de
trabajo reutilizable empaquetado como código estructural.
Hablamos de archivos con extensiones como .md de
Markdown o .yml de Yamal.
Espera, espera.
O sea, si lo entiendo bien, ¿no le
estamos pasando un texto para que lo lea?
¿Le estamos pasando un engranaje de software para
que lo ejecute directamente?
Esa es la distinción crítica, exacto.
Un archivo YAML le dice a la IA,
mira, paso uno extrae estas variables.
Paso dos, aplica esta lógica condicional.
Paso tres, devuelve el resultado en formato JSON.
O sea, no depende de que la IA
interprete nuestra prosa.
Le da un carril de código por el
que circular.
Totalmente.
Y lo más revolucionario es la portabilidad.
Al ser un archivo físico que puedes tener
en tu disco duro, te lo llevas donde
quieras.
Nuestra lógica de trabajo ya no pertenece a
una empresa.
Esa tecnológica concreta nos pertenece a nosotros.
Eso democratiza por completo el conocimiento.
De hecho, hay una regla de productividad fantástica
en las fuentes que analizamos.
La regla de los dos.
Así, la regla de los dos es clave.
Si alguien se encuentra haciendo la misma petición
manual a una IA más de dos veces,
debería estructurarla y guardarla como una skill.
El ejemplo del creador de bocetos, el B
-Roll Sketch, lo ilustra perfectamente, creo yo.
¿Sí?
Es un gran ejemplo.
En lugar de escribir cada vez, oye, necesito
una imagen vertical en proporción 9 -16, con
estilo de dibujo a lápiz, fondo blanco roto
y trazo grueso.
Pues te creas el archivo de la skill.
Y a partir de ahí, solo dices, usa
el creador de bocetos para ilustrar un servidor
informático.
Y el archivo YAML inyecta todas las restricciones
técnicas de proporción y estilo de forma invisible.
Y fíjate, podemos llevar la complejidad mucho más
allá de generar simples imágenes.
Ah, sí.
¿Cómo en qué casos?
Pensemos en el caso del respondedor sarcástico de
redes sociales que vimos en la investigación.
Ah, el de Facebook.
Buenísimo.
Sí, esta skill no se limitaba a contestar
comentarios.
Ejecutaba un árbol de decisiones entero.
Primero, extraía el comentario del usuario.
Segundo, buscaba el contexto del producto en la
web para entender la queja.
Y tercero, redactaba una respuesta adoptando la voz
de la generación Z.
La anécdota era brillante.
¿Alguien se quejaba del precio exagerado de un
termo de moda?
Y la skill, de forma totalmente automatizada, respondía
a cosas como...
Ehm...
Pagar 45 dólares por un vaso de agua
es un trastorno de la personalidad con garantía.
LOL.
Pal cual, sin filtros.
E incluso, que esto me voló la cabeza,
inyectaba faltas de ortografía a propósito, para sonar
más real.
O sea, ¿cómo consigue una skill que la
máquina decida escribir mal?
Pues mediante parámetros de penalización.
En el código de la skill, se invierte
la lógica habitual del modelo.
En lugar de premiar la gramática perfecta.
Se le instruye para relajar las reglas de
sintaxis y usar diccionarios de jerga de Internet.
Es la demostración de que una skill no
es una petición.
Es una reconfiguración de la personalidad y el
proceso analítico del modelo.
Lo cual nos lleva a un salto cualitativo
brutal, claro.
Tenemos el manoral de instrucciones avanzado con las
skills.
Pero un manual, por muy detallado que sea,
no arregla el motor de un coche por
sí solo.
Alguien tiene que levantar el capó.
Alguien tiene que mancharse las manos, eso es.
Y aquí entramos en el territorio de los
agentes y los conectores.
Siguiendo con la analogía del taller, si la
skill es el manual de reparación, los conectores
serían las llaves inglesas.
Y el agente es el mecánico que toma
las decisiones, ¿no?
Es una excelente forma de visualizar cómo la
IA pasa de ser pasiva a ser activa.
Hasta ahora describíamos un sistema que espera a
que pulsemos la tecla intro para hacer algo.
Ya, ¿qué espera nuestra orden?
Exacto.
Los agentes destruyen esa barrera.
Son modelos de IA dotados de capacidad de
razonamiento secuencial y autonomía.
Pueden leer lo que hay en una pantalla
mediante APIs, mover el cursor, hacer clics en
botones invisibles, y navegar por internet sin supervisión
humana.
Vale, como concepto tecnológico, es fascinante.
Pero aquí tengo que pisar el freno y
admitir que genera un vértigo terrible.
Porque hablamos de un agente utilizando conectores, los
famosos MCPs, para salir de su burbuja y
tocar aplicaciones externas.
Sí, los puentes de software.
Claro, pero darle a un ente virtual acceso
a un Slack corporativo o a un correo
de Gmail suena a que, ante el mínimo
error de interpretación, el agente podría borrar toda
nuestra bandeja de entrada.
O enviar info confidencial a quien no debe.
Y ese vértigo está completamente justificado.
De hecho, es el mayor reto de seguridad
actual.
La magia y el peligro de las APIs,
que son las puertas traseras de nuestro sistema,
es que no tienen fricción.
O sea, que entran como Pedro por su
casa.
Tal cual.
Por eso la configuración de los conectores requiere
actuar con la precisión de un cirujano.
Existen permisos de solo lectura, donde el agente
actúa como un bibliotecario, que revisa facturas y
hace un resumen, sin poder alterar nada.
Vale, eso me tranquiliza un poco más.
¿Y los de escritura?
Pues luego están los permisos de escritura y
borrado, que son los delicados.
Es que la regla de oro en ciberseguridad
para esto, debería ser que los permisos de
escritura y borrado, que son los delicados.
Debería ser que el mecánico prepare el presupuesto
y el informe, pero que la firma final
para cambiar la pieza la ponga siempre un
humano.
Jamás otorgar autonomía total en entornos críticos.
Así es.
El humano se convierte en un supervisor, no
en un ejecutor.
Y para escalar esto, la industria ha creado
los plugins.
Si los conectores son llaves inglesas sueltas, un
plugin es la caja de herramientas premium ya
preconfigurada.
Ah, como el ejemplo del entorno de desarrollo
de Apple.
En los datos de las fuentes, se mencionaba
un plugin diseñado para crear aplicaciones de iOS.
Sí, una maravilla de la automatización.
Cuando se instala, no solo conecta con Xcode,
el programa para hacer apps, sino que trae
integradas nueve skills de programación distintas.
O sea, el usuario pide una app de
lista de tareas, y el plugin ya tiene
al mecánico, el manual y las herramientas soldadas
entre sí.
Y fíjate, el impacto macroeconómico de esto es
profundo.
Cuando se lanzaron plugins similares para el análisis
de riesgos legales, orientados a automatizar la revisión
de millones de documentos para juicios.
El famoso Discovery, ¿no?
Ese mismo.
Pues, las acciones de ciertas empresas tradicionales de
servicios legales cayeron en bolsa.
El mercado entendió inmediatamente que un plugin puede
cruzar referencias en millones de folios en segundos.
Aniquilando las horas facturables de ejércitos de analistas
junior, claro.
Destrucción creativa en estado puro.
Totalmente.
Pero claro, si le damos a este mecánico
las llaves del taller, la caja de herramientas,
y le damos la orden de, oye, no
pares hasta que termines el trabajo, ahí entramos
en la zona más salvaje de esta tecnología.
Los bucles y la autonomía profunda.
Uf, los bucles.
Aquí la cosa se pone interesante.
¿Cómo funciona exactamente un bucle en la mente
de un agente?
Pues un bucle, que frecuentemente se activa por
un comando en el código, como la barra
invertida GOL o META, es un ciclo de
retroalimentación.
¿Vale?
Errores, se corrige a sí mismo y vuelve
a intentarlo.
Es la diferencia entre delegar una tarea y
delegar un objetivo.
Pero, a ver, ¿cómo es capaz un modelo
de lenguaje de criticar su propio trabajo de
manera objetiva?
Si uno mismo escribe un texto, a la
tercera lectura ya no ve sus propias faltas
de ortografía.
Asumo que a la IA le pasa lo
mismo, que sufre de sesgo de confirmación.
Y asumes bien.
Para evitar ese punto ciego, se utilizan los
subagentes.
Cuando se lanza una tarea compleja, el sistema
no usa un solo cerebro.
Instancia múltiples inteligencias artificiales con roles enfrentados.
¿Roles enfrentados?
¿Se pelean entre ellos?
Básicamente sí.
Tenemos al agente creador, que escribe el código,
y al agente crítico, cuyo único parámetro de
existencia es encontrar vulnerabilidades y fallos lógicos en
lo que ha hecho el creador.
¡Qué pasada!
Ambos debaten y compiten internamente en milisegundos.
Si el crítico encuentra un fallo matemático, rechaza
el trabajo y obliga al creador a iterar
de nuevo.
Es como simular un departamento entero debatiendo en
la placa base de un ordenador.
Pero esto tiene que tener una trampa enorme.
¿Qué ocurre si se encuentran con un problema
irresoluble?
Y ninguno de los subagentes da su brazo
a torcer.
Ese es el famoso problema del bucle desbocado.
Si no se establecen criterios lógicos de salida,
el agente seguirá intentándolo hasta el infinito.
Y aquí la realidad económica golpea duro, porque
cada vez que el modelo procesa información consume
tokens.
Y para quienes nos escuchan y no estén
familiarizados con la factura técnica, un token es
básicamente como, no sé, como echarle una moneda
a una máquina recreativa cada vez que la
IA piensa o genera una palabra.
Exactamente.
Es una fracción microscópica de céntimo.
Pero en un bucle infinito que procesa miles
de líneas de código por segundo, la máquina
tragaperra se traga las monedas a velocidad de
vértigo.
¡Madre mía!
Un bucle desbocado puede vaciar el saldo de
una API, que es la interfaz de pago
con el servidor, en cuestión de horas.
Por eso, el código de cualquier agente debe
incluir un freno de emergencia.
Un intenta resolver este error, pero al tercer
intento fallido detente y mándame un aviso.
El clásico para el carro que nos arruinamos.
Eso es.
Vital para el bolsillo.
Aunque bueno, cuando el bucle funciona correctamente y
los subagentes logran su objetivo, los resultados son
de no creer.
Para ilustrar hasta dónde ha llegado ya esta
tecnología autónoma, tenemos que hablar del caso de
estudio de Fable 5.
Sí, el del videojuego de la ardilla.
Que cariñosamente podríamos llamar el RuneScape para ardillas.
Es uno de los hitos más impresionantes recientes
sobre la capacidad de razonamiento espacial de la
IA.
La historia, para nuestra audiencia, es que alguien
decidió crear un pequeño mundo virtual, estilo juego
de rol, donde controlas a una ardilla que
recoge bellotas y lucha contra arañas en un
sótano.
Pero ojo, no picó ni una línea de
código.
Nada.
Ni una sola línea.
Le dio un objetivo en bucle a un
agente autónomo.
Le dijo, por ejemplo, quiero que añadas una
cámara de 360 grados que pueda rotar alrededor
del personaje.
Y el agente, utilizando las APIs del ordenador,
analizó el entorno, diseñó las matemáticas necesarias y
escribió el código.
Y al probarlo, claro, la cámara atravesaba las
paredes.
Pero el subagente detectó el error, debatieron, reescribieron
la física de colisiones y lo inyectaron de
nuevo hasta que funcionó perfectamente.
Y lo fascinante de ese proceso es la
paciencia sobrehumana de la máquina.
Un programador humano se frustraría tras 10 intentos
fallidos calculando vectores.
El agente en bucle intentó cientos de iteraciones
en minutos.
De forma totalmente autónoma.
Y después construyeron los puentes de madera interactivos
e incluso programaron la inteligencia artificial de los
enemigos que perseguían a la ardilla.
Todo mientras el usuario humano estaba sentado con
los brazos cruzados, observando cómo su taller mecánico
virtual construía un software complejo desde cero.
Hemos pasado de picante, a buscar piedra en
la mina, a ser los directores de orquesta.
Es una locura.
Y es una dirección de orquesta que altera
el valor del trabajo.
Si unimos una skill, que es el conocimiento
empaquetado, un conector para el entorno, un agente
que ejecuta y un bucle de persistencia, democratizamos
la creación.
Totalmente.
La barrera de entrada para crear tecnología ya
no es saber programar, es saber qué problemas
merecen ser resueltos.
Es un horizonte fascinante.
Hemos visto el viaje completo hoy, ¿eh?
Sí, desde organizar el caos hasta la autonomía
total.
Desde los proyectos, pasando por destilar nuestro conocimiento
en skills, hasta darles las llaves a los
agentes en bucle.
Y todo esto culmina en un escenario que
pone los pelos de punta.
A ver, cuéntame esa reflexión final.
Pues que si todo el mundo empaqueta sus
rutinas, llegará el día en que un agente
de IA esté negociando presupuestos o agendando reuniones
directamente con el agente de IA de otra
empresa.
Sin que ningún humano haya intervenido.
Dejaremos de gestionar tareas para gobernar redes de
agentes.
Nos deja muchísimo que pensar sobre el rol
del trabajador en la próxima década.
Sin duda, es un cambio de paradigma brutal.
Y antes de irnos, os dejo con una
idea que no hemos tocado hoy en profundidad
para que le deis vueltas.
Si los agentes acaban haciendo el trabajo técnico
de forma autónoma, usando nuestras skills, ¿qué va
a pasar con la propiedad intelectual?
Uf, ese es otro temazo.
Claro, si un agente construye una aplicación millonaria,
mientras dormimos, solucionando sus propios errores de código,
¿de quién es el mérito legal?
¿Del humano que puso la tarjeta de crédito
o de la empresa tecnológica que entrenó al
modelo?
Ahí dejamos la semilla para el debate.
Una pregunta excelente para cerrar, desde luego.
Antes de despedirnos, hasta el próximo programa, os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
¡Nos escuchamos!