IA generativa: madurez tecnológica al servicio del impacto
Estadísticas de AWS para 2025 sobre la adopción de la IA en Francia (el 90 % de las empresas declara un aumento de la facturación, el 68 % de las startups utiliza la IA generativa).
Ya desde la sesión plenaria de apertura quedó claro: la IA generativa ya ha sido ampliamente adoptada por las empresas francesas. Un estudio presentado durante la ponencia inaugural indica que el 90 % de las empresas que han implementado la IA generativa observan un aumento en su facturación, mientras que el 68 % de las startups francesas ya utilizan la GenAI en sus productos o servicios. Estas cifras, en fuerte crecimiento (+26 % en un año), dan testimonio del auge de la GenAI en todos los sectores de actividad.
En concreto, AWS ha destacado varios testimonios de clientes que ilustran esta madurez. Por ejemplo, Safran, gigante de la aeronáutica, ha dado a conocer su uso de Amazon Bedrock para el análisis de documentos técnicos y el mantenimiento predictivo, lo que le ha permitido ahorrar un millón de euros en 18 meses. Safran ha anunciado, además, una colaboración reforzada con AWS para implementar la IA generativa a gran escala, con objetivos ambiciosos como la descarbonización de la aviación y la optimización de la cadena de suministro. Otro ejemplo revelador: Veolia, en colaboración con la startup francesa Mistral AI, ha mostrado cómo la IA ayuda a detectar averías industriales y a clasificar documentos, además de preparar futuros asistentes de voz especializados. Ya sea Owkin (salud), Qonto (fintech) o Poolside (herramienta para desarrolladores), todos estos actores han demostrado casos de uso reales en producción, muy lejos de simples POC: la GenAI se ha convertido en una ventaja operativa concreta, desde el apoyo a los técnicos de mantenimiento hasta la lucha contra el fraude bancario. La IA les permite mejorar la experiencia del cliente, optimizar sus operaciones internas o generar nuevos ingresos. Tras la era de los simples chatbots de 2024, se ve claramente que 2025 es el año de los agentes de IA y de las soluciones generativas de alto valor añadido en producción, con un retorno de la inversión concreto y una integración profunda en los sistemas de información existentes.
Por último, es imposible no mencionar a Mistral AI —el buque insignia de la French Tech en el ámbito de los LLM—, que aprovechó la cumbre para anunciar la disponibilidad de su modelo propio, Pixtral Large, en Amazon Bedrock. Se trata del primer modelo europeo de este tipo que se ofrece en modo sin servidor y totalmente gestionado en AWS. Para la comunidad tecnológica francesa, esto supone una señal clara: nuestras innovaciones locales encuentran su lugar en el ecosistema global de la nube. Como experto, me complace ver que AWS acoge esta diversidad de modelos y enfoques: esto abre la puerta a más opciones estratégicas para nuestros propios proyectos (según el caso, podremos optar por un modelo de AWS, de código abierto, local u otro, sin problemas de integración).
El auge de los sistemas multiagente: hacia una IA colaborativa
Mesa redonda «De la IA asistencial a la IA creativa» con Dust, Anthropic y Balderton sobre los agentes de IA y el MAS.
Si la IA generativa alcanza cierta madurez, ya se abre una nueva frontera: la de los sistemas multiagente (MAS). En lugar de basarse en un único agente conversacional, la idea es coordinar varios agentes inteligentes que colaboren para realizar tareas complejas. Este tema, que se hace eco de los experimentos recientes de AutoGPT y similares, ha tenido un gran protagonismo en la Cumbre.
En una mesa redonda titulada «De la IA asistente a la IA creativa: la revolución de los agentes», varios expertos debatieron sobre esta revolución que se avecina. Junto a AWS, participaron figuras destacadas del sector como Guillaume Princen (director para EMEA de Anthropic), Gabriel Hubert (director ejecutivo de Dust) y Zoé Mohl (socia principal de Balderton Capital). Esta mesa redonda exploró la evolución de las IA conversacionales hacia agentes más autónomos y proactivos, capaces no solo de responder a preguntas, sino también de tomar iniciativas, recurrir a otros servicios e incluso colaborar entre sí. Los ponentes destacaron que, para abordar tareas complejas, un solo agente de IA ya no es suficiente: a menudo es preferible coordinar varios agentes especializados (lo que se conoce como sistemas multiagente o MAS), cada uno experto en un ámbito, y hacer que interactúen para alcanzar un objetivo común. Todos comparten la visión de un futuro próximo en el que enjambres de agentes especializados cooperan para resolver problemas, un poco al estilo de los equipos humanos o los microservicios de software. Al hablar con mis compañeros, observo que esta idea resulta especialmente atractiva para los perfiles de I+D, incluso en Squad, donde nuestro trabajo ya explora las arquitecturas multiagente. Es emocionante ver cómo nuestras intuiciones se ven confirmadas por las tendencias del mercado.
Un ejemplo concreto de este enfoque multiagente lo ha aportado Qonto, el neobanco francés, que ha causado sensación al revelar que ha desplegado nada menos que 200 agentes de IA en producción para detectar el fraude y automatizar tareas financieras del servicio PayLater (pago aplazado) para sus clientes profesionales, lo que ha permitido evitar un fraude de 3 millones de euros. Esta cifra es vertiginosa y demuestra que ya no estamos en la fase de experimentación de laboratorio: al coordinar cientos de agentes (algunos supervisando transacciones, otros gestionando controles de cumplimiento normativo, etc.), Qonto ha alcanzado un nivel de automatización y vigilancia sin precedentes en su sistema de información.
En lugar de basarse en un único modelo monolítico, Qonto ha creado tres tipos de agentes complementarios para gestionar cada solicitud:
- Agentes «Vision»: utilizan el modelo de lenguaje grande (LLM) Claude 3.7 de Anthropic (a través de Amazon Bedrock) para leer y extraer la información de las facturas facilitadas por los clientes (importe, fecha, proveedor, etc.).
- Agentes de «Investigación»: consultan fuentes externas y API públicas (Google a través de Serper, el registro mercantil del INPI, etc.) para verificar la información sobre el comprador y el vendedor (existencia de la empresa, solvencia, posibles riesgos), basándose en los datos extraídos por el Agente Vision.
- Agentes de «Análisis»: ejecutan código de validación de negocios y cruzan datos (por ejemplo, verifican los historiales de pago o el cumplimiento normativo en materia de AML/KYC) para decidir si la transacción puede aprobarse o no.
Arquitectura técnica de CrewAI en Qonto para el procesamiento de PayLater con Kafka, PostgreSQL, EKS y Amazon Bedrock.
La arquitectura presentada por Qonto (ilustrada arriba) se basa en el marco de código abierto CrewAI para coordinar estos agentes dentro de contenedores en Amazon EKS. Los eventos de solicitud de financiación («Transferencia PayLater») se publican en Kafka, son procesados por el servicio CrewAI que controla a los agentes, los cuales pueden almacenar y leer datos en una base de datos PostgreSQL y utilizar los modelos de Amazon Bedrock. Una vez finalizado el análisis por parte de los agentes, el resultado (aprobación o denegación de la financiación) se genera en Kafka y luego se aplica en el sistema de transacciones. Este sistema multiagente ha permitido a Qonto reducir el tiempo de tramitación de una solicitud de 6 horas a menos de 5 minutos, automatizar el 25 % de los casos desde el momento de la implementación (con un objetivo del 80 % en breve) y, de este modo, escalar sin necesidad de contratar personal de forma masiva para las verificaciones manuales. Para los equipos de DevOps, este ejemplo demuestra que, con la arquitectura adecuada, la GenAI puede integrarse de forma fiable en flujos de trabajo críticos del negocio sin dejar de ser escalable y mantenible.
Por su parte, el gigante cementero Holcim ha demostrado cómo los agentes equipados con IA generativa pueden automatizar procesos empresariales que hasta ahora eran manuales: por ejemplo, la tramitación de facturas se ha acelerado de forma espectacular (una reducción del 90 % en las tareas manuales gracias a la IA). Incluso en la agricultura, una empresa como Syngenta utiliza la colaboración de agentes a través de Bedrock para optimizar los rendimientos agrícolas, con un aumento del 5 % en la productividad de algunos cultivos, lo que supone una ganancia enorme a escala de este sector.
El problema del «superagente» de IA: cuando un único agente gestiona demasiados casos de uso, se vuelve lento, costoso e impreciso. De ahí el interés de los MAS.
En términos más generales, los debates de la cumbre advirtieron contra el mito del «superagente» capaz de hacerlo todo. Una diapositiva muy elocuente mostraba que, al querer confiar demasiadas responsabilidades a un solo agente (por ejemplo, gestionar por sí solo la totalidad de un proceso de comercio electrónico, desde la recepción del pedido hasta el servicio posventa), se obtiene un agente lento, que consume muchos recursos y, a menudo, impreciso. Por el contrario, al adoptar un enfoque modular con múltiples agentes, se puede descomponer el problema en subtareas, optimizar cada agente para su tarea específica y, de este modo, obtener una solución global más eficaz. Este principio de arquitectura, que recuerda a la división en microservicios, se está imponiendo como una buena práctica para las aplicaciones avanzadas de IA.
Sin embargo, esto también plantea nuevos retos de ingeniería: ¿cómo supervisar y depurar una constelación de agentes? ¿Cómo evitar que un agente se vuelva malicioso o ineficaz? Seguiremos de cerca las experiencias, como la de Qonto, para extraer las buenas prácticas.
Seguridad y gobernanza de los modelos de lenguaje grande (LLM): medidas de protección indispensables
Resultados del estudio de Gartner de 2024: el 59 % de los directores de sistemas de información (CIO) considera que las alucinaciones de los modelos de lenguaje grande (LLM) son el principal riesgo, por delante de la desinformación y la confidencialidad.
Con la adopción masiva de la IA generativa, la seguridad y la fiabilidad de estos sistemas se han convertido en preocupaciones fundamentales. Según un estudio de Gartner citado durante la Cumbre, el principal temor de los directores de sistemas de información (DSI) en relación con los modelos de lenguaje grande (LLM) es el problema de las alucinaciones (el 59 % de ellos lo cita como el riesgo n.º 1), es decir, aquellas respuestas inventadas por el modelo que pueden provocar errores en la toma de decisiones. A continuación, se sitúan los riesgos de desinformación intencionada (48 %) y de confidencialidad de los datos (44 %). Consciente de estos retos, AWS ha dedicado varias sesiones a las buenas prácticas para la seguridad de las aplicaciones de IA generativa.
Los tres pilares de la seguridad de la IA generativa según AWS: la protección de las aplicaciones de IA, el uso de agentes de ciberseguridad y la protección frente a las nuevas amenazas de la IA.
En particular, una presentación informativa presentó los «tres pilares de la seguridad de la IA generativa» según AWS, representados por un taburete de tres patas (véase más arriba). Estos tres pilares son:
- Proteger las aplicaciones de IA generativa: garantizar que nuestros chatbots, agentes y otras aplicaciones basadas en modelos de lenguaje grande (LLM) no se conviertan en vectores de ataque.
- Utilizar la IA generativa para proteger el entorno: emplear los modelos de IA como herramientas defensivas en materia de ciberseguridad.
- Protegerse contra las amenazas emergentes relacionadas con la IA generativa: anticiparse y contrarrestar los nuevos tipos de ataques que la IA hace posibles (deepfakes, suplantación mediante voz sintética, etc.).
El primer pilar se refiere a la protección de nuestras aplicaciones frente a las vulnerabilidades propias de los LLM. Nos referimos, por ejemplo, a la inyección de prompts (un usuario malintencionado que manipula las instrucciones del modelo), a la filtración de información sensible en las respuestas de la IA o al robo de modelos (exfiltración de los pesos de un modelo entrenado). A este respecto, los ponentes mencionaron que OWASP está trabajando en un Top 10 de riesgos específicos de las aplicaciones LLM, a semejanza del Top 10 clásico para aplicaciones web.
OWASP Top 10 para aplicaciones LLM, con advertencias sobre la inyección de comandos, la fuga de datos, el robo de modelos, etc.
Entre los riesgos de los LLM enumerados (véase la ilustración anterior), destacan: LLM01: Inyección de prompts, LLM02: Gestión inadecuada de las salidas del modelo, LLM03: Envenenamiento de los datos de entrenamiento, LLM06: Fugas de información sensible, LLM09: Confianza excesiva en el modelo, o incluso LLM10: Robo del modelo. Como DevSecOps, es crucial integrar desde el diseño medidas de protección (GuardRails) contra estas vulnerabilidades: validación y filtrado de las entradas/salidas del LLM, gestión del ciclo de vida de los secretos y claves API utilizados por el LLM, supervisión de las llamadas para detectar posibles abusos, etc. El mensaje es claro: una aplicación GenAI debe protegerse con el mismo rigor que una aplicación web crítica, adaptando nuestras herramientas y hábitos a las particularidades de los modelos de lenguaje.
El segundo pilar pone de relieve cómo la IA puede ser un aliado en materia de ciberseguridad. Un caso de uso destacado que se presentó fue el de un agente de seguridad basado en IA capaz de responder a preguntas sobre vulnerabilidades conocidas y de ayudar a los analistas del SOC. Al combinar un LLM con bases de conocimiento de seguridad, se puede acelerar el análisis de incidentes o la respuesta a los desarrolladores sobre las vulnerabilidades. De hecho, AWS mostró cómo crear rápidamente un asistente de este tipo a través de Amazon Bedrock.
Fragmento de código Python que muestra la implementación de un agente de seguridad basado en IA que consulta las vulnerabilidades CVE del OWASP Top 10 a través de Amazon Bedrock.
El código anterior ilustra la sencillez con la que se puede implementar un agente LLM equipado con herramientas. En Python, se define una función equipada con herramientas (get_top10_cves) para recuperar la lista de las 10 principales vulnerabilidades (en este caso, el Top 10 de OWASP). A continuación, se configura el cliente Bedrock para que utilice esta función «tools», una herramienta a la que el modelo podrá recurrir cuando se le consulte. Resultado: en unas treinta líneas, disponemos de un asistente capaz de proporcionar la lista de CVE críticas o de detallar las vulnerabilidades más comunes, basándose en un modelo alojado por Bedrock. Este tipo de agente podría integrarse en un chatbot interno, una herramienta de análisis de código o cualquier otro sistema de seguridad para aumentar la productividad de los equipos técnicos.
Por último, el tercer pilar aborda las nuevas amenazas generadas por la propia IA. Se trata aquí de protegerse contra los usos maliciosos de la IA generativa: desde piratas informáticos que utilizan modelos de lenguaje grande (LLM) para automatizar el phishing o generar malware sofisticado, hasta la difusión masiva de desinformación mediante bots de IA, pasando por ataques indirectos como el envenenamiento de modelos (introducir datos erróneos para falsear un modelo). En este frente, AWS recomienda una vigilancia tecnológica activa y la implementación de defensas específicas. Por ejemplo, están surgiendo soluciones para detectar contenidos sintéticos (deepfakes) o para poner a prueba los modelos mediante equipos de simulación de ataques (Red Teams) de IA. El objetivo es no quedarse atrás: al igual que los atacantes innovan con la IA, los defensores deben integrar la IA en su arsenal y adaptar sus estrategias de seguridad. En definitiva, la seguridad y la IA deben avanzar de la mano en la era de la GenAI.
Ingeniería de plataformas: cada vez más eficiencia a gran escala
Además de la IA, la cumbre también dedicó un espacio especial a la ingeniería de plataformas y a las novedades que facilitan el trabajo de los equipos de infraestructura y DevOps. Un tema llamó especialmente la atención: la implementación de EKS en modo «Auto».
Arquitectura de clúster EKS en modo automático con gestión automatizada del escalado, la red y el almacenamiento por parte de AWS.
El modo EKS Auto (anunciado recientemente por AWS) permite crear clústeres de Kubernetes gestionados aún más autónomos. En la práctica, al activar este modo, es AWS quien se encarga automáticamente del aprovisionamiento de los nodos (a través de Karpenter), del escalado de los trabajadores en función de los pods, así como de parte de la configuración de red y del almacenamiento. El esquema anterior muestra la arquitectura simplificada de un clúster EKS Auto: el plano de control sigue siendo gestionado por AWS como de costumbre, pero ahora las instancias de cómputo (EC2), así como componentes como los equilibradores de carga, los volúmenes EBS o los buckets S3, pueden aprovisionarse de forma dinámica y ser controlados por la propia plataforma. Para los equipos, esto significa menos gestión manual de las infraestructuras de Kubernetes y más tiempo para centrarse en las cargas de trabajo de las aplicaciones. Durante la sesión sobre este tema, pudimos ver demostraciones de la creación de clústeres con unos pocos comandos, sin tener que preocuparse por el tipo de instancia o los ajustes de capacidad, lo cual es ideal para entornos de desarrollo y pruebas, pruebas de concepto rápidas o incluso para la producción, siempre que se hayan definido bien las necesidades básicas.
Desde el punto de vista de la ingeniería de plataformas, el modo automático de EKS supone un gran avance, ya que democratiza el acceso a un K8s bien gestionado, incluso para equipos que no cuentan con expertos en K8s a tiempo completo. Por supuesto, los puristas o aquellos con necesidades específicas siempre podrán personalizarlo (el modo automático permite ajustes de red, elección de tipos de nodos, etc.). Pero para muchas organizaciones, esta oferta gestionada acelerará el tiempo de comercialización al reducir la carga operativa. Se puede ver en ello la culminación de tendencias iniciadas anteriormente: el software de código abierto Karpenter (el autoescalador de instancias spot desarrollado por AWS) ha marcado el camino para optimizar los costes y la flexibilidad de los clústeres. De hecho, Anthropic declaró el año pasado haber reducido su factura de AWS en un 40 % gracias a Karpenter. Hoy en día, AWS integra estos mecanismos de forma nativa en EKS Auto: ya no es necesario instalar ni configurar Karpenter por separado, ya que el autoaprovisionamiento está integrado. Se gana en simplicidad lo que se pierde (un poco) en control preciso.
El equipo de SRE de Qonto gestiona 15 clústeres EKS (aprox. 20 000 pods) con más de 150 implementaciones al día, gracias a GitOps/ArgoCD y al autoescalado de Karpenter. En su sesión en la Summit, mostraron cómo las actualizaciones de la plataforma, que antes tardaban varios días, se han reducido a solo una hora gracias a estas optimizaciones.
Por otra parte, GitOps se ha consolidado como una práctica imprescindible en la ingeniería de plataformas. Ya sea para implementar aplicaciones o gestionar la configuración de los clústeres EKS, numerosos ponentes mencionaron el uso de herramientas GitOps (Argo CD, FluxCD) con el fin de garantizar la trazabilidad y la reproducibilidad de los cambios. En combinación con soluciones como EKS Auto Mode, GitOps permite alcanzar un alto nivel de automatización sin perder el control a través del código. Así, se vislumbran plataformas internas de «autoservicio» en las que los desarrolladores y los científicos de datos pueden implementar sus aplicaciones (incluidos los pipelines de ML o los modelos de IA) con unos pocos clics, mientras que la infraestructura se gestiona como código en segundo plano.
Por último, el movimiento de la ingeniería de plataformas en su conjunto se consolida. AWS ha hablado mucho sobre las formas de industrializar el uso de la nube: plantillas de Terraform o CDK para implementar rápidamente plataformas completas (que integran CI/CD, observabilidad, etc.), la creciente adopción de GitOps para todo (varias sesiones mostraron ArgoCD en acción) y la importancia de la automatización de extremo a extremo. El mensaje subyacente era claro: para sacar el máximo partido a la GenAI y a las nuevas tecnologías, se necesitan cimientos sólidos y automatizados. Como Tech Lead, esto me reafirma en la idea de que invertir en una plataforma interna robusta (Infraestructura como Código, pipelines, monitorización, seguridad integrada) no es un lujo, sino un requisito previo para innovar rápido y bien.
AWS Graviton4: un 30 % más de rendimiento en comparación con Graviton3, un 40 % más en bases de datos y un 45 % más en aplicaciones Java.
En cuanto a infraestructura y optimización, AWS también ha presentado sus últimos avances en materia de hardware. Se ha dado a conocer la nueva generación de procesadores propios Graviton4, que promete mejoras significativas: un 30 % más de rendimiento en comparación con Graviton3 en general, e incluso un 40 % más en cargas de trabajo de bases de datos y un 45 % más en aplicaciones Java. Estas mejoras de hardware se traducirán para los equipos de operaciones en menores costes (ya que se obtiene más rendimiento por cada dólar gastado) y en la posibilidad de ejecutar cargas de trabajo intensivas (big data, entrenamiento de modelos de ML, etc.) con mayor eficiencia. Para la comunidad DevOps, esto supone un recordatorio de que la optimización pasa también por una elección acertada de la infraestructura: aprovechar las últimas ofertas de AWS (instancias Graviton, GPU optimizadas, almacenamiento optimizado para E/S, etc.) forma parte integrante del enfoque de excelencia operativa.
De la concepción a la producción: buenas prácticas para la IA generativa
Concluyamos este resumen de experiencias con un aspecto transversal que me ha llamado la atención: ¿cómo pasar de la fase experimental a la de producción en los proyectos de IA generativa? Muchos ponentes han hecho hincapié en las buenas prácticas para llevar a cabo con éxito esta transición.
El ciclo de vida de un proyecto de GenAI se analizó en profundidad desde la ponencia inaugural a través del concepto de «AI Foundations». En la fase inicial, todo comienza con la preparación de los datos (data readiness). No hay modelo eficaz sin datos de calidad: varios ponentes (entre ellos Safran y Owkin) destacaron la importancia de modernizar y centralizar los datos de la empresa antes de adentrarse en el deep learning. En este sentido, servicios como AWS Glue, Lake Formation o la integración de Apache Iceberg con S3 (anunciada durante la cumbre) ayudan a crear lagos de datos gobernados, versionados y listos para alimentar los modelos. He observado, por ejemplo, que Owkin ha creado pipelines MLOps en AWS para agregar datos médicos de múltiples fuentes garantizando al mismo tiempo el anonimato, lo que demuestra que es posible conciliar la riqueza de los datos con el cumplimiento normativo.
Una vez elegido el modelo, se ha debatido ampliamente la cuestión del ajuste fino. La tendencia es a la moderación: solo se realiza el ajuste fino si es necesario. Muchos casos de uso ya pueden cubrirse mediante una ingeniería de prompts cuidadosa aplicada a un modelo genérico, o mediante técnicas de embedding + RAG (Retrieval Augmented Generation) para aportar los conocimientos específicos del sector sin alterar el modelo. El ajuste fino se utiliza para aportar un verdadero valor añadido (tono específico, jerga del sector, rendimiento en una tarea especializada) y debe realizarse respetando las normas de seguridad (sin fugas de datos en el conjunto de entrenamiento, uso de almacenes de características para rastrear lo que se ha utilizado para el entrenamiento, etc.). También he retenido que AWS ofrece herramientas para facilitar este ajuste fino, vigilando la deriva del modelo (model drift) y permitiendo destilar el modelo ajustado si es necesario (para crear una versión más ligera que se pueda utilizar en producción en hardware estándar).
En resumen, las mejores prácticas de producción para la IA generativa presentadas en la Cumbre se resumen en unos pocos puntos: datos bien preparados y gestionados, una selección acertada de los modelos (y su coordinación), una arquitectura integrada en el resto del ecosistema de aplicaciones y una seguridad «por diseño» (medidas de protección, supervisión y control de acceso) a lo largo de todo el proceso. Puede parecer que son muchos requisitos, pero ese es el precio que hay que pagar para que la IA generativa aporte valor en la práctica. Como responsable técnico, estos consejos coinciden plenamente con mi propia experiencia: el diablo está en los detalles (un modelo brillante en la demostración puede fallar en producción por falta de datos actualizados o de operaciones adecuadas), de ahí la importancia de un enfoque full-stack que abarque tanto el modelo como la infraestructura.
¡Por último, pero no menos importante! No olvidemos el aspecto de la formación y la cultura. La cumbre ha demostrado que la tecnología está lista (o se está preparando activamente) para la GenAI, pero el éxito de su adopción también pasa por la aculturación de los equipos. Es importante formar a los desarrolladores en las nuevas prácticas (prompt engineering, uso de API de IA, MLOps), sensibilizar a los equipos de seguridad sobre las particularidades de los LLM e implicar a los distintos departamentos para identificar los casos de uso adecuados.
Un futuro prometedor, unos fundamentos que se mantienen sin cambios
Esta AWS Summit Paris 2025 ha sabido satisfacer mis expectativas como entusiasta de la tecnología. Salgo de ella sintiéndome a la vez estimulado por las novedades y reafirmado en mis convicciones. Sí, la IA generativa ya está lo suficientemente madura para usos concretos a gran escala, y AWS ofrece un ecosistema sólido (chips dedicados, modelos variados, herramientas de implementación) para sacarle partido. Sí, el enfoque multiagente se perfila como el siguiente paso, abriendo perspectivas inéditas que exploraremos con pasión, pero sin perder de vista los retos de coordinación y seguridad que esto plantea. Y precisamente, en materia de seguridad, aplaudo la lucidez de recordar que sin confianza y gobernanza, ninguna innovación perdura: nos corresponde a nosotros implementar estas medidas de protección en nuestros proyectos desde ahora mismo.
En el fondo, esta cumbre nos recuerda que los principios fundamentales de DevOps/DevSecOps siguen siendo más relevantes que nunca. Ya se trate de implementar un chatbot impulsado por un modelo de lenguaje grande (LLM) o una aplicación en la nube más convencional, las fórmulas que funcionan son las mismas: una plataforma automatizada, escalable y observable, flujos de CI/CD fluidos, y una cultura de mejora continua y de intercambio de conocimientos. Las herramientas evolucionan (Kubernetes pasa a ser autónomo, la IA se cuela en todas partes), pero nuestra misión como ingenieros sigue siendo mantener el control —técnico, operativo y ético— de estas potentes tecnologías.
Para Squad y nuestra comunidad tecnológica, la aventura continúa, pues, con un rumbo claro. Este resumen de la AWS Summit 2025 no es un fin en sí mismo, sino un hito inspirador. Ahora nos toca a nosotros aprovechar esta oportunidad aplicando estos conocimientos en nuestros próximos proyectos de DevSecOps y MLSecOps, compartiendo a nuestra vez nuestros descubrimientos y manteniendo siempre ese equilibrio entre el entusiasmo por la innovación y la exigencia de fiabilidad. Como me gusta decir: «Innovar está bien… ¡innovar de forma segura y sólida está mejor!».
