Reglas de negocio con agentes de IA — Álvaro González-Iglesias González

Vídeo em Espanhol, publicado pelo canal Orbitant.

Sobre este contenido: El resumen, los puntos principales y los temas que aparecen a continuación se generan automáticamente a partir de la transcripción del vídeo. Reflejan el contenido, las opiniones, afirmaciones y predicciones presentadas en el vídeo y no representan una posición, validación o verificación de hechos por parte de IA Dots.

Resumen del vídeo

El video explica la arquitectura de un modelo de datos y cómo conviven diferentes agentes de inteligencia artificial para explotarlo de manera genérica. Se contrasta el enfoque tradicional de ataques directos a bases de datos con una arquitectura en la nube basada en capas, almacenamiento estructurado y repositorios separados para reglas de negocio y código.

Puntos principales

• Se describe el origen de los proyectos de datos mediante consultas directas a bases de datos y informes alimentados en vivo, destacando la falta de trazabilidad y de histórico como principales desventajas.
• Se introduce la arquitectura implementada utilizando Azure Data Factory para la orquestación y una capa Medallion dividida en bronce, silver y gold para estructurar y validar la información.
• Se explica el uso de Databricks como motor de procesamiento para aplicar las reglas de negocio y preparar los datos destinados a herramientas de visualización como Power BI.
• Se detalla la separación entre el repositorio de reglas lógicas en Notion y el control de versiones del código en GitHub, lo que permite un versionado independiente y mayor seguridad.
• Se expone la integración de agentes de IA utilizando un enfoque full cloud, donde un agente director llamado Overwatch custodia el conocimiento y coordina a agentes de código independientes mediante tareas específicas.

Temas

Modelo de datosArquitectura de datosAzure Data FactoryCapa MedallionDatabricksReglas de negocioAgentes de IAControl de versiones

Transcripción del vídeo

Texto de los subtítulos disponibles; puede contener errores.

Lo que os voy a contar un poco hoy viene a ser todo el la estructura, la arquitectura del modelo de datos que se está implementando. Y no solo eso, sino también cómo conviven los agentes de IA para poderlo explotar de una manera un poco genérica, ¿vale? Sin entrar en en datos ni en detalles concretos de de este modelo, pero sí viendo un poco cómo podría trabajar en distintos entornos levantándolo de una manera similar. También un poco de comparación entre por qué se ha levantado de esta manera, de dónde veníamos y cuál es la idea o cuál es la la dirección que se que se pretende alcanzar. Entonces, en en para empezar un poco contar eso, de dónde de dónde venimos o cómo surgen normalmente los los proyectos de datos en esas etapas iniciales, que al final no dejan de ser ataques directos a las bases de datos, en nuestro caso pues serían a los ERPs, a las distintas bases de datos disponibilizadas. Y a partir de ahí, eh como el negocio está vivo y siempre hace falta información y siempre se demanda información, directamente se alimentaban informes. Esto tiene una ventaja, es muchísimo más rápido, es decir, vas a demanda, según necesito un informe, levanto una conexión, levanto una query, ataco la base de datos, pim plas, en una en un momento he levantado he levantado un informe que está conectado a la a toda la información en vivo. ¿Cuáles son las desventajas que tenemos con este sistema directo? No tenemos ningún tipo de trazabilidad. Cualquier cambio eh que se realice en las bases de datos se refleja automáticamente en los informes sin saber quién, cuándo, cómo o por qué se ha realizado. También perdemos histórico, perdemos versiones, la capacidad de volver a estados válidos. Es en este punto en el que entra esa necesidad de gobernar la información. ¿Vale? En este caso un Data Warehouse, bien puede ser un Data Warehouse, un Data Lake, cualquier sistema, cualquier cualquier sentido de gestión de de la información que nos permite establecer esa capa de históricos, esa capa de versiones para volver a estados anteriores, para comparar, contrastar, validar, ver que los que las reglas de negocio que se están aplicando tienen un sentido, no solo a futuro, sino también sobre lo que hemos ido generando, porque reglas que solo valen a futuro sobre estados posibles eh no no nos responden a nada a día de hoy. En este caso, problemas que nos podemos encontrar. Tenemos una query que se alimenta directamente en un informe de Power BI en el que una métrica concreta se ve alterada y o bien rompemos ese informe o bien dejamos descolgados de un de un mismo sentido el resto de informes, es decir, todo lo que vaya por vía directa se tiene que replicar a mano en todas las demás alimentaciones. Con el sistema, teniendo un Data Warehouse, tenemos toda la información gobernada en un único centro y los informes, inferencias o analíticas que se realicen se hacen todas sobre una misma base, todos hablamos el mismo idioma. ¿Vale? Tiramos esa torre de Babel y pasamos a hablar todos un idioma común. Vamos entonces a ver un poco cuál es la arquitectura en nuestro caso que se ha planteado. En este caso, tenemos una entrada a través de Azure Data Factory que hace un la orquestación y la recogida de datos de esas fuentes principales. A partir de ahí, a través eh a través no, eh representado mediante una capa que se conoce como Medallion, se estructura la información a tres niveles. Tenemos la capa de recogida, lo que antiguamente se llamaba el el el landing, que es nuestra capa bronce. Cuando recibimos esa información está en bruto y debemos curarla, un un primer análisis, una primera validación de datos nulos, de información que pueda venir rota por el procesamiento. Eh, generamos una capa de silver, una capa de staging. Y por último, tenemos que aplicar las reglas de negocio, que es lo que va a permitir eh mmm toda, todo personal con conocimiento funcional pueda hacer inferencias, pueda hacer analíticas sobre la información, que es nuestra capa gold. Esto lo hacemos en un storage account que acaba vertiendo en databricks. Databricks va a ser nuestro motor de procesamiento, va a ser nuestra cocina, va a ser nuestros fogones, donde vamos a poder generar esa capa de oro que finalmente explotemos con power BI. A mayores de todo esto, debemos eh tener en cuenta mmm dos herramientas que van a vivir a la par que el resto de herramientas, pero a la vez por separado. Es decir, por un lado vamos a tener un repositorio de información, notion como pueda ser o pueda ser un obsidian, dependiendo de de la implementación que se haga, donde vivirá la capa lógica. Todas las reglas de negocio, todas las descripciones de conocimiento, todas las decisiones que se tomen, pero completamente separado de lo que es el código por otra parte, que vivirá en github, lo que nos va a permitir hacer también un versionado sobre dichas reglas de negocio aplicadas. ¿Quién tomó esta decisión? ¿Cuándo se tomó? ¿Cómo se tomó? ¿Debemos revertirla? Siempre vamos a poder llegar a todos los estados de la cadena. Con esto, pasamos a ver un poco más en detalle cómo es el uso de de las distintas herramientas en data factory, al final por un proceso ETL, como se vienen conociendo hasta ahora, vamos a poder orquestar toda esa recogida de información, toda esa validación principal. Como veis aquí, tenemos una estructuración en distintas capas, hablábamos esa capa bronce que es el resultado de eh las fases de orquestación de de Data Factory y ese histórico que hablábamos al principio. Ya empezamos a tener un primer punto de validación y de comprobación y de comparación con datos anteriores. Algo que con un ataque directo a las bases de datos, si no se contemplaban desde un inicio, perdíamos. Muchas veces, además, las bases de datos están lo suficientemente cargadas de información, con registros diarios o con transacciones del tipo de negocio que sea, que no se contempla que almacene toda esta información o no la almacene en bruto, ¿vale? Aquí ya empezamos a tener esa primera capa o esa o esa primera alimentación de datos que realmente teníamos de antes, pero que no estábamos explotando. ¿De acuerdo? Después de esto, vamos a pasar a lo que es el procesamiento, lo que hablábamos con Data Bricks. Vamos a poder ya empezar a aplicar esas reglas de negocio definidas en nuestro repositorio lógico, en Synapse, en en ese Obsidian y eh generar esa capa Gold. Además, Data Bricks también vamos a poder ir automatizando esos procesamientos para que la idea sea que todo lo que vayamos construyendo realmente nos podamos olvidar de ello. Si todo va bien, no hay que volver a tocarlo. Si todo va bien, no hay que volver a mirarlo, no hay que tenerlo en cuenta. Podemos seguir construyendo sobre una base muy estable y muy sólida, que al final es lo que nos interesa para poder ampliar eh ese conocimiento. Por último, llegamos a esa presentación de de en nuestras herramientas de BI, en este caso un Power BI, por ejemplo, que hm donde ya nos hemos hm desligado de la posibilidad de de de sincronizar los informes o de sincronizar los datos que se están mostrando, ya que no dependemos de una revisión manual uno a uno por cada uno de los informes cada vez que se realiza un cambio. Todos beben de la misma base, todos beben de un conocimiento que está validado, que está protegido, que está revisado y podemos empezar a generar insights, información mezclada y mucho más enriquecida de manera mucho más rápida y potente de lo que veníamos haciendo hasta ahora. Dos puntos de verdad. Por un lado, lo que comentábamos, tenemos las reglas de negocio. Viven en Notion. Toda decisión tomada por negocio, toda decisión explicada. Y por otro lado, ¿qué es lo que hemos implementado? GitHub. Nos va a permitir ese versionado, ese poder arreglar, ese poder ir ampliando los conocimientos sin pisar o romper, sin miedo a ello, mientras estamos desplegando. Eh, como veis, de nuevo la misma estructura y la parte importante también por qué por qué separamos, por qué tenemos por un lado Databricks y por otro lado Notion y por otro lado GitHub, por qué no unificarlos dentro de una misma plataforma. De esta manera vamos a poder garantizar que la gente que tiene conocimiento sobre nuestro negocio no tiene por qué acceder, podemos desplegarlo completamente de lo que es el negocio en sí mismo. No tiene acceso a los datos. Podemos emplear distintos agentes, podemos repartirlo entre distintos perfiles, entre distintas personas, hacer desarrollos simultáneos paralelos sin miedo a que nuestra información se vea publicada o se vea utilizada para reentrenar modelos de inteligencia. En este caso, o sea, con este caso, con esta metodología realmente podemos apostar por el modelo que mejor se adapte a nuestras necesidades, el que más nos guste, el que la empresa quiera implementar en cada momento, como decimos, con sin ese miedo de que nuestra información se vea publicada o mal utilizada. Eh, esperad un segundo. A mayores de esto, vamos a entrar ya un poco más en en cómo están implementados los distintos agentes de inteligencia en este en este contexto. El approach que se ha elegido en este caso es full cloud, ¿vale? Con los distintos modelos que tiene, haciendo uso en este caso de el modelo más complejo o el que mejor aguanta la memoria, que es el de Fable. Con Fable se genera un rol de Overwatch, un rol director, ¿vale? Este rol, este agente o esta implementación, lo que va a hacer va a ser cargar toda la información, toda la base de conocimientos sobre la estructuración del modelo de datos y empezar a orquestar y a dirigir. Este agente, el Overwatch, no va a tocar una línea de código. Overwatch simplemente se va a dedicar a ser el custodio del conocimiento. Va a tener todos los modelos de datos cargados y generará tareas para que ya no con sus agentes que le devuelvan ese ese contexto y lo va cargando, sino con agentes separados de código vayan generando a través de estas tareas. Estas tareas volverán a sí mismo, las revisará y seguiremos trabajando. De esta manera podemos separar no solo para que no se llene un contexto con información innecesaria de lo que es código y sino que siga manteniendo lo que es información solo de negocio, sino que además las tareas de código revisarán una segunda vez al generarlo posibles fallos en la lógica que se nos hayan pasado. Lógica que desde negocio tiene sentido, pero que desde implementación no. Esto se puede traducir, por ejemplo, al mundo de la arquitectura. El diseño que se hace de una casa que es espectacular y muy bonito y ya llega después el arquitecto o el ingeniero y dice, "Muy bien, pero no te puedo poner una habitación de pesa 2 toneladas sin ningún tipo de soporte." Hacemos lo mismo. Un diseño que por lógica de negocio tenga sentido, pero que por implementación se encuentran los fallos. Van a ir chequeándose unos a otros de manera que evitamos cualquier tipo de error que no hayamos que no que no hayamos tenido en cuenta. No solo esto, sino que además todo todo el aprendizaje que va haciendo este Overwatch, este director de orquesta, se va reintegrando, a su vez, en Notion para que se pueda aprender, se pueda lanzar en cualquier momento un un segundo perfil que levante esta misma estructura y desde el minuto cero tenga acceso a todo el conocimiento, o para ir validando y ir mejorando los modelos que vengan después. Aquí tenéis un ejemplo de las task files que genera este este director, ¿vale? Donde se cuenta cuál es el problema que queremos atacar, para que los agentes de código tengan un contexto mínimo y necesario de qué están resolviendo y así poder revisar esas reglas de lógica de las que hablábamos, y una serie de normas de cómo se espera que trabaje y cómo se espera que sea su vuelta. Es decir, aquí tienes todo el código necesario, no me preguntes, aquí tienes toda la información necesaria, y esto es cómo quiero que me des la información, tanto para mí como para la vuelta del director, pueda revisarla y pueda corregirla. Con esto que conseguimos, lo dicho, distintos agentes de código van a generar esas tareas, van a atacar sobre los repositorios que se subirán a GitHub, esos commits después se sincronizarán en Databricks y seremos nosotros los que en el entorno de procesamiento de datos ya lancemos esas ejecuciones. Todas estos commits, todas estas modificaciones, lo que van a llevar consigo también es una tarea de retorno. Es decir, las salidas que nos van a devolver estos notebooks, estas ejecuciones, van a venir con los datos estructurados sin eh sin mostrar información sensible en claro, para que nos llevemos de vuelta y podamos validar sobre lo esperado. Es decir, las reglas de negocio, teniendo en cuenta todo el contexto que muchas veces se escapa a lo que una sola persona puede puede estar manejando, lo mantiene Overwatch, y con las salidas de estas ejecuciones, las volvemos a pegar en pantalla y tenemos una validación para ver que por arreglar un problema puntual, no estamos rompiendo algo en el esquema general de la de la compañía. ¿Dónde entramos nosotros? En todas las interacciones, ¿vale? El perfil humano entra para gestionar y supervisar que todo lo que se está realizando tiene sentido, que todo lo que se está realizando tiene una cohesión y tiene una coherencia. Ya no nos dedicamos tanto a eh comprobar si cada línea de código está bien hecha, sino si la estructuración, la orquestación, la dirección, las salidas tienen el sentido o tienen los valores que estábamos esperando. De esta manera, ya no ya no estamos gestionando una única tarea manualmente, sino que vamos a poder pasar a gestionar distintas tareas de trabajo en paralelo. Eh en una de las cosas que por ejemplo me he dejado me he dejado sin comentar es que para el trabajo en para el trabajo con las tareas de code, para que no se solapen cuando muchas veces estamos atacando al mismo entorno de datos, lo vamos a hacer a través de work trees. Lo dicho, esto nos va a permitir que lo que antes haría un equipo de seis personas, cada uno con su tarea asignada individual, podamos atacarlo simultáneamente, simplemente teniendo que comprobar que los planes lógicos que se desarrollan cada una de las tareas de code son correctos, tienen la estructura necesaria y que las salidas después de las ejecuciones nos devuelven los datos esperados. Y o sea, ¿dónde entra todo esto lo que acabamos de hablar? En esos work trees, en esa configuración, en esa sincronización entre lo que es el entorno local de nuestros agentes y el entorno web de eh trabajo, para que no se publique ningún tipo de información privada o ningún tipo de información sensible, tenemos dos universos que conviven sobre la misma idea lógica, pero que cada uno trabaja de manera síncrona y desligada al otro. Eh las reglas sobreviven en la memoria general, ¿vale? Lo que comentábamos, el Overwatch mantiene toda la información, todas las reglas dentro de su contexto y comparten solo aquellas que son necesarias, permitiendo así que las tareas de code puedan acceder a pequeños archivos de contexto que contengan para cada caso concreto. No embarronamos la memoria, no sobrecargamos de contexto, reducimos el consumo de tokens, permitimos que las distintas tareas vayan sincronizándose hablando entre sí. Cada vez que acaba una tarea, volvemos a Overwatch y Overwatch informa a las tareas de code que considera que son necesarias o que puedan tener algún tipo de de sincronía a la hora del código. Queremos queremos habilitar toda la velocidad posible manteniendo una base estructurada y bien informada y eh sin pillarnos sin sin tropezarnos con nuestro propio pie. A mayores de esto, seguimos aprendiendo iteración a iteración, ¿vale? Cada vez que encontramos con un problema, añadimos a ese contexto general de Notion, ese contexto privado y podemos seguir trabajando. Para que nos hagamos una idea de qué es lo que de qué velocidad o qué sincronía podemos llegar a alcanzar, este este es el tablón de tareas que hago un segundo. Este sería el tablón de tareas que llevo actualmente, donde se puede ver que distintas no sé si veis toda la pantalla, sí se ve este cuadradito. ¿Sí? Vale. Donde se puede ver distintas tareas con eh que esto ya lo conté en un asteroide pasado, eh cada uno de los resúmenes de lo que se está llevando. De esta manera podemos llevar el contexto general de cinco o seis desarrollos simultáneos, ¿vale? Para saber de una forma rápida a qué se refiere cada uno de ellos, para tener un pequeño recuerdo, un pequeño resumen de qué es lo que estaba tocando esa tarea y permitir así que vayan avanzando paralelo. Si garantizamos que tenemos una base muy firme, muy estable y muy sólida, podemos ir construyendo cada vez a mayor velocidad. Y esto sería todo. La verdad es que como siempre tiendo a acelerarme, igual ha quedado un poco más más corta. Pero pero este es un poco el resumen de de cómo implementar los distintos agentes dentro de lo que es un desarrollo de datos teniendo en cuenta siempre esa sensibilidad especial que tiene el tener los datos ya claros y limpios para que no salgan o no se reentrenen en distintos modelos.

Assistir ao vídeo original no YouTube

Assuntos: Agentes de IA. Publicado no YouTube em 2026-10-22.

Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.