La situación del mercado en cifras claveLa situación del mercado en cifras clave
Presencia de AWS en Francia: cifras anunciadas en la inauguración por Amélie Clugnet Veron, directora de AWS en Francia.
AWS celebra su vigésimo aniversario e invierte 6000 millones de euros en Francia: centros de datos, ampliación de las regiones y formación. Un millar de empleados, más de trescientos socios, un ecosistema que configura una parte significativa de la oferta de servicios en la nube en Francia. Pero las cifras más reveladoras se refieren a los obstáculos para la adopción de la IA, y arrojan luz directamente sobre el tema de la gobernanza que recorre todo este artículo.
Los tres obstáculos para la transformación de la IA en Francia señalados por AWS.
El 41 % de las empresas francesas señala la falta de competencias en IA y digitales como principal obstáculo. De cada cien euros gastados en informática, cuarenta y dos se destinan al cumplimiento normativo. Además, un 32 % adicional menciona la incertidumbre normativa como obstáculo, mientras que el 70 % de esas mismas empresas afirma obtener beneficios tangibles de la IA. Esta última diferencia perfila con exactitud la forma que adoptará la demanda en el futuro. Las organizaciones ya no buscan herramientas: buscan marcos metodológicos seguros y conformes que les permitan industrializar sin perder el control. Se trata de una oportunidad estratégica para los profesionales de la ciberseguridad, siempre y cuando sepan posicionarse en ella.
Recordemos una cifra: 42 € en cumplimiento normativo por cada 100 € invertidos en TI. Esta proporción justifica por sí sola cualquier iniciativa de «compliance-as-code» (NIS2, CRA, DORA, Ley de IA de la UE) y cualquier enfoque que convierta el cumplimiento normativo en un acelerador en lugar de un freno. La Ley de IA de la UE y su posible sanción del 7 % de la facturación mundial cambian definitivamente la dinámica de las decisiones: ya no se pospone la gobernanza de la IA a la «fase 2» de un programa.
La ponencia principal: soberanía, productividad de los agentes y la cifra de los quince minutos
La ponencia inaugural, de dos horas de duración, se articuló en torno a una metáfora propuesta por Amélie Clugnet Veron: la de un cohete en el momento del despegue. Formación, navegación, estructura y soberanía: cuatro pilares que pretenden simbolizar lo que AWS quiere aportar a la transformación francesa. El recurso narrativo resulta un poco forzado, pero el resto de la mañana le confiere una densidad real. Hay tres señales estratégicas que merecen la atención de los responsables de seguridad de la información.
La nube soberana europea como argumento de infraestructura
La llegada de Stéphane Israël, antiguo presidente de Arianespace y ahora en AWS, es una señal política: AWS quiere operar en sectores de competencia estatal. Ariane 6, mencionado como primer cliente de la European Sovereign Cloud, completa el panorama. Los mismos servicios que la nube pública, no una oferta de menor calidad, sino operados en una región independiente por entidades jurídicas europeas, con la garantía de que no existe interdependencia con respecto a otras regiones del mundo y con mecanismos de auditoría específicos.
Para los responsables de seguridad de la información (RSSI) de organizaciones reguladas, esta propuesta resuelve la objeción histórica sobre la dependencia jurídica de EE. UU., al tiempo que mantiene el acceso al catálogo de AWSBedrock, AgentCore y doscientos cuarenta servicios. Evidentemente, esto no pone fin al debate sobre la soberanía (la cuestión de la Cloud Act sigue abierta, las garantías dependen de la estructura jurídica efectiva del operador local), pero se trata de una propuesta técnica y jurídica lo suficientemente estructurada como para merecer un examen serio en las trayectorias de arquitectura a tres o cinco años, en comparación con las ofertas de 3DS Outscale, OVHcloud o S3NS.
El cambio semántico: del «¿por qué?» al «¿por qué no?»
Stéphane Hadinger, director de Tecnología en Francia, ha señalado un cambio que merece nuestra atención. Durante diez años, el debate sobre la IA en las empresas ha girado en torno al «por qué»: ¿por qué este caso de uso? ¿por qué este modelo? ¿por qué ahora? En 2026, afirma, la pregunta pasará a ser «¿por qué no?», lo que supone que se ha demostrado el valor, que las herramientas existen y que la fricción se ha reducido hasta el punto de que la ausencia de automatización en un flujo de trabajo se convierte en una anomalía que hay que justificar. Para los CISO, este cambio significa que la presión para la adopción se intensificará enormemente por parte del negocio, y que la postura de «guardián que dice no» será cada vez más difícil de mantener. La única postura sostenible es la del socio que propone marcos de implementación seguros, no prohibiciones.
La cifra de los quince minutos y sus implicaciones
La cifra más llamativa de la mañana: un desarrollador sénior dedica, de media, solo quince minutos al día a escribir código. El resto del tiempo lo absorben las especificaciones, la arquitectura, las pruebas y la depuración. Este enfoque da sentido a toda la estrategia de agentes de AWS: los agentes no pretenden sustituir al desarrollador, sino industrializar las cuatro tareas que consumen más tiempo. Kiro, posicionado como competidor de Claude Code y Cursor, encarna esta visión.
Un caso práctico interno de AWS ilustra este punto. La remodelación de Amazon Bedrock, que inicialmente requirió treinta personas durante dieciocho meses, se repitió utilizando las herramientas de Agentic con seis personas en seis meses: dieciséis veces más barato y tres veces más rápido. La comparación invita a la cautela —hay que tener en cuenta los efectos del alcance, la deuda técnica previamente absorbida y el aprendizaje—, pero proporciona un punto de referencia que los equipos técnicos citarán en sus casos de negocio y que los responsables de seguridad de la información deberán saber argumentar.
Bureau Veritas y el auge de la auditoría estructurada basada en la inteligencia artificial
Radar de Bureau Veritas: ocho dimensiones de evaluación (explicabilidad, equidad, gobernanza, confidencialidad y seguridad, solidez, seguridad, transparencia y controlabilidad).
Marc Roussel, vicepresidente ejecutivo de Bureau Veritas, ofreció la ponencia más útil para quienes se interesan por la intersección entre la IA, el cumplimiento normativo y la auditoría. El 68 % de las empresas tiene dificultades para interpretar la Ley de IA de la UE: 113 artículos, múltiples funciones y una compleja matriz de riesgos. La oferta de Bureau Veritas combina una preauditoría documental, pruebas predictivas y una auditoría sobre el terreno. El radar de ocho ejes se superpone en gran medida a la norma ISO/IEC 42001 y a las dimensiones de IA del TRiSM de Gartner.
Para los profesionales de la ciberseguridad, la señal es doble. Por un lado, las metodologías de auditoría clásicas, que se dominan a la perfección en los sistemas de información tradicionales, resultan estructuralmente inadecuadas para auditar los sistemas de IA, tal y como ha reconocido la propia Bureau Veritas. Por otro lado, las nuevas matrices de evaluación que están surgiendo (Bureau Veritas, pero también el AI Risk Management Framework del NIST, la norma ISO/IEC 42001 y el marco AI TRiSM) convergen hacia un conjunto de dimensiones comunes. Esto supone una oportunidad para los RSSI y los responsables de auditoría: quien formalice la metodología de evaluación de la IA en su organización antes de que la normativa lo imponga obtendrá una ventaja estructural duradera.
AgentCore: las seis fronteras invisibles que la industrialización hace visibles
La sesión «Buenas prácticas avanzadas para implementar agentes con AgentCore», impartida por arquitectos de soluciones de AWS con la experiencia industrial del Grupo La Centrale, fue la sesión más densa del día para un perfil de seguridad. Merece un análisis en profundidad porque estructura el modelo operativo que AWS recomienda para industrializar los agentes en la empresa y porque cada componente de este modelo materializa una frontera que hasta ahora gestionábamos de forma implícita.
«La identidad es la arquitectura. La plataforma no es un conjunto de herramientas, sino un esquema de identidades y permisos al que se conectan las herramientas». — Frase repetida por La Centrale y Euronext durante la cumbre |
La arquitectura de referencia: Runtime y Gateway
Caso de uso «Asistente de análisis financiero»: un Finance Agent coordina un Prediction Agent y llama a cuatro herramientas de negocio a través de AgentCore Runtime.
El caso de uso presentado al principio, un asistente de análisis financiero, funciona como un modelo didáctico. Un agente financiero coordinador, un agente de predicción especializado, cuatro herramientas de negocio (calculate_profit_margin, get_exchange_rate, get_revenue_report, get_department_budget), dos tipos de servicios remotos —externos e internos— que se tratan de forma diferente en lo que respecta a la identidad y la red. Se pueden distinguir tres patrones.
En primer lugar, la clara separación entre el agente orquestador y los agentes especializados. Un agente no debe ser una navaja suiza: tiene una responsabilidad bien definida y sabe delegar. Este patrón reproduce en el ámbito de la IA lo que los microservicios han hecho en el ámbito de las aplicaciones. En segundo lugar, el aislamiento diferenciado de las llamadas externas. Los servicios internos y externos no tienen el mismo perfil de riesgo, no se autentican de la misma manera ni pasan por los mismos controles de red. AgentCore hace explícita esta distinción, mientras que las arquitecturas artesanales la confunden. Por último, la exposición uniforme desde el lado de la aplicación: independientemente de la complejidad interna, el consumidor ve un único entorno de ejecución.
AgentCore Gateway: punto de entrada unificado para MCP que redirige el tráfico hacia tres tipos de destinos (servidores MCP, API REST y funciones Lambda).
La Gateway es el componente más importante que debe comprender un RSSI. Expone un único punto de acceso /mcp que permite a cualquier agente cliente MCP enumerar, invocar y buscar herramientas. Detrás de ella, redirige el tráfico hacia tres tipos de destinos: servidores MCP existentes, API REST o funciones Lambda. La caché integrada evita llamadas downstream innecesarias, lo cual es fundamental para controlar los costes y la latencia. Pero, sobre todo, la Gateway crea un cuello de botella gestionable: todo el tráfico entre el agente y la herramienta pasa por un único punto, visible, filtrable y auditable. Este es el patrón que todo equipo de seguridad debería exigir antes de cualquier implementación de agentes a gran escala.
La seguridad de los agentes: tres planos de identidad que hay que gestionar
La seguridad de los agentes se articula en tres niveles, cada uno de los cuales debe gestionarse de forma explícita. Y es aquí donde el hilo conductor de este artículo se hace más patente: en las arquitecturas artesanales del pasado, estas tres relaciones solían confundirse; por lo general, el agente heredaba los derechos del usuario que lo invocaba, lo cual constituye un antipatrón de gran importancia.
Relación | Cuestión de control |
Empleado → Solicitud | Autenticación clásica: SSO, MFA resistente al phishing (claves de acceso, FIDO2). Una base indispensable, pero insuficiente cuando los agentes entran en juego. |
Agente → Aplicación | Identidad propia del agente, distinta de la del usuario. El agente no debe suplantar la identidad humana que lo invoca: esto rompe la trazabilidad y otorga derechos excesivos. AgentCore Identity materializa esta identidad específica. |
Agente → Recursos | Permisos granulares que combinan RBAC (rol del agente) y ABAC (atributos del contexto de la llamada) a través de AgentCore Policy. Un mismo agente, según el contexto, debe obtener decisiones de acceso diferentes. |
Este tríptico impone nuevas disciplinas operativas. Es necesario realizar un inventario de los agentes, al igual que se hace con los usuarios y las cuentas de servicio. Gestionar su ciclo de vida: creación, promoción, rotación de credenciales y revocación. Asignarlos a un propietario claramente designado, ya que un agente sin propietario es una bomba de relojería. Todo esto se corresponde con prácticas que los equipos de IAM conocen para las identidades humanas y de máquinas; se trata de ampliarlas a una tercera población. Las organizaciones que no lo hagan ahora mismo acumulan una deuda de seguridad invisible que solo se revelará ante el primer incidente, y dicho incidente será difícil de investigar, debido a la falta de trazabilidad de las identidades de los agentes.
Observabilidad y evaluación: la segunda línea de defensa
AgentCore Evaluations (versión preliminar): un modelo de lenguaje grande (LLM) actúa como juez y analiza los registros generados por AgentCore Observability.
AgentCore Observability proporciona un seguimiento de extremo a extremo: coste en tokens, latencia por herramienta y cadenas de invocación. La buena práctica que se insiste en recordar: incluir la observabilidad desde el principio, no añadirla a posteriori. Ya sabemos cómo va esto: la observabilidad añadida a posteriori siempre es incompleta y siempre resulta más costosa que la observabilidad nativa.
AgentCore Evaluations, aún en fase de vista previa, va más allá. Un LLM-juez analiza los registros, genera resultados y explicaciones, y alimenta paneles de control de evaluación continuos. Es el equivalente a un SonarQube para agentes, con la promesa de detectar de forma continua desviaciones en el comportamiento, regresiones en la calidad e interacciones anómalas con las herramientas. El patrón es el del LLM-as-a-judge, aplicado a la evaluación de agentes en producción en lugar de a la evaluación de conjuntos de datos de entrenamiento. Aquí hay toda una disciplina de ingeniería de calidad por construir.
Lo que un responsable de seguridad de la información debe saber sobre AgentCore AgentCore no es un producto que haya que comprar, sino un modelo operativo que hay que comprender. Aunque su organización implemente sus agentes en Azure, GCP o en las propias instalaciones, los seis componentes que AgentCore materializa (Runtime, Gateway, Identity, Policy, Observability, Evaluations) corresponden a seis requisitos arquitectónicos que toda implementación de agentes industriales deberá cumplir, independientemente del proveedor. El responsable de seguridad de la información (RSSI) que formalice estos seis requisitos en su repositorio de arquitectura antes de que los equipos de negocio implementen agentes no controlados tomará una ventaja decisiva. |
El informe de Euronext: cuando la gobernanza MCP se convierte en una disciplina operativa
La sesión «Secure MCP Platform for Generative AI with Bedrock AgentCore Gateway», moderada conjuntamente por Rubén Silva, ingeniero de nube en Euronext, y varios arquitectos de AWS, fue la parte más sólida de la jornada en materia de seguridad. En ella se abordó una cuestión muy concreta: ¿cómo pasar de cincuenta herramientas MCP desarrolladas de forma artesanal a varios miles en producción, sin que se dispare la deuda de seguridad?
El punto de ruptura y por qué llega antes de lo que pensamos
El caso inicial de Euronext —un servicio de atención al cliente basado en IA con unos pocos usuarios internos— funcionaba bien. Pero entonces se impuso la realidad industrial: miles de usuarios, múltiples dependencias, integraciones MCP heterogéneas, equipos de agentes distintos que desplegaban cada uno sus propios servidores MCP sin coordinación. La arquitectura ya no da la talla. Los autores establecen un paralelismo explícito con la transición del monolito a los microservicios: se recorre el mismo camino, pero con los agentes y sus herramientas. Surgen cuatro problemas simultáneamente: la necesidad de un punto único de comunicación, la necesidad de un control de acceso preciso y contextualizado, la exigencia de una observabilidad transversal y la gobernanza del ciclo de vida de las herramientas MCP (control de versiones, obsolescencia, reversión).
La arquitectura objetivo: MCP de nivel empresarial
Arquitectura de Euronext: desarrollador (VS Code + GitHub Copilot, SSO con Azure Entra ID) → AgentCore Gateway (SSO + autenticación por grupos de AD, medidas de protección de datos personales, ALB privada + VPC, enrutamiento de herramientas) → Servidores MCP integrados (GitLab, Atlassian, Coralogix; Figma pendiente).
La arquitectura cabe en una sola línea, pero concentra una cantidad impresionante de decisiones. El desarrollador solo se comunica con un punto final/MCP autenticado mediante SSO de Azure Entra ID y que pertenece a grupos de AD. La puerta de enlace encadena cuatro funciones: verificación de SSO y grupos de AD, PII Guardrails que filtran los datos sensibles tanto en la entrada como en la salida, conexión a una VPC privada a través de ALB y enrutamiento de herramientas hacia los destinos. Figma permanece en espera; el soporte para OAuth de tres partes aún no está disponible en el prototipo, lo que demuestra una honestidad técnica apreciable.
Conectividad privada: el VPC del cliente se conecta al plano de datos de AgentCore Gateway a través de AWS PrivateLink, sin exposición a Internet.
La topología de red es impecable para un entorno financiero regulado: AWS PrivateLink entre la VPC del cliente y el punto de acceso de la puerta de enlace gestionado por AWS. Sin salida a Internet, sin puerta de enlace NAT en el lado sensible. Este patrón es exactamente el que se recomienda para cualquier contexto regulado: banca, defensa, sanidad, energía, y responde de forma preventiva a tres objeciones clásicas: ¿nuestros datos transitan fuera de nuestro perímetro? ¿A quién pertenece el plan de control? ¿Y cómo aislar este tráfico de nuestras otras cargas de trabajo?
Control de acceso detallado: un ejemplo que cambia el rumbo del debate
Control de acceso detallado: un mismo agente de precios recibe decisiones de acceso diferentes dependiendo de si lo invoca un cliente externo o un administrador interno.
Este esquema vale más que cualquier discurso sobre la gobernanza MCP. Se invoca un mismo agente de precios en dos contextos. En el lado del cliente externo, AddPromotions se rechaza (Deny), mientras que SearchPromotions sigue estando autorizado. Por parte del administrador interno, ambas operaciones están permitidas. Mismas herramientas MCP, mismo agente, decisiones de acceso radicalmente diferentes: todo depende del contexto de la llamada y de la política. Este patrón descarta toda una generación de enfoques simplistas en los que el agente hereda un único rol asignado al inicio. Es necesario combinar quién llama y en qué contexto, y expresarlo en un lenguaje de políticas lo suficientemente expresivo.
Las tres fórmulas que hay que recordar del retex de Euronext «El MCP necesita una gobernanza». Sin una gobernanza explícita, el MCP se convierte en una nueva superficie de ataque sin control. Es exactamente lo mismo que nos pasó con las API REST hace diez años: mientras se trata de soluciones artesanales, funciona; pero a gran escala, se viene abajo. «La identidad es la arquitectura». La identidad del usuario, del agente o de la herramienta no es un mero complemento de seguridad. Es el pilar arquitectónico central en torno al cual se estructura todo lo demás. Se trata de un cambio de enfoque fundamental para los equipos de IAM. «Empieza poco a poco, empieza ahora». El coste de adaptar la gobernanza MCP es prohibitivo. Es mejor sentar las bases desde el principio con las primeras herramientas que tener que lidiar con mil herramientas sin gobernanza dentro de doce meses. |
La electrificación del ciclo de vida del desarrollo de software (SDLC): de GitLab DAP a la metodología AI-DLC
Las dos últimas sesiones técnicas deben leerse conjuntamente: la sesión patrocinada por GitLab sobre la plataforma Duo Agent y la sesión de clausura sobre el ciclo de vida del desarrollo impulsado por la IA. La primera propone una aplicación concreta: una plataforma de IA multiagente integrada en el ciclo DevSecOps. La segunda ofrece el marco metodológico que da sentido a estas aplicaciones. La herramienta sin método genera caos; el método sin herramienta queda en lo teórico.
La paradoja de GitLab: código más rápido ≠ entrega más rápida
El informe «State of AI 2026» de McKinsey indica que el uso de la IA en los equipos de desarrollo se ha duplicado en los últimos dos años. Sin embargo, el enfoque está más fragmentado que nunca: cada desarrollador elige su herramienta, cada equipo sus convenciones, y la cadena de entrega no se acelera tanto como se esperaba. De ahí la paradoja: «un código más rápido no equivale a una entrega más rápida». La lección estructural se alinea con nuestro hilo conductor: mientras el uso de la IA siga siendo individual y no esté regulado, las ganancias de productividad se esfuman en la integración, la depuración posterior y la deuda de inconsistencia. Para un RSSI, esta paradoja tiene una consecuencia directa: una IA de desarrollo no regulada no solo genera deuda técnica, sino también deuda de seguridad en el código generado sin revisión, sin convenciones y sin respeto por los estándares de codificación segura.
GitLab Duo Agent Platform ofrece una solución: una orquestación multiagente alineada con el ciclo completo de DevSecOps (planificación, código, compilación, pruebas, seguridad, implementación y operación), impulsada por Amazon Bedrock a través de una puerta de enlace de IA autohospedada. Esta topología proporciona un control preciso de los modelos utilizados en cada etapa, la residencia de los datos (ningún prompt ni código sale hacia servicios no controlados), el cumplimiento por diseño (registro centralizado, pista de auditoría) y la escalabilidad a través de los servicios gestionados de AWS. Para las organizaciones reguladas, este patrón «GitLab autogestionado + Bedrock a través de una puerta de enlace de IA privada» responde de frente a la objeción recurrente: «no podemos enviar nuestro código sin cifrar a un proveedor de IA». La respuesta técnica está ahora estandarizada y es reproducible.
AI-DLC: la analogía de la electrificación
El ciclo de vida de desarrollo de software (SDLC) tradicional: «todos esperan a todos». Cada «STOP» representa un cuello de botella entre los silos.
La analogía propuesta para reflexionar sobre cómo salir de este esquema es la de la electrificación de las fábricas. En los talleres preeléctricos, todas las máquinas estaban conectadas a un eje de transmisión central accionado por una única máquina de vapor. Si el eje fallaba, todo el taller se paralizaba. La electrificación dotó a cada máquina de su propio motor, lo que generó ganancias de un orden de magnitud superior, cambiando la topología de las fábricas y transformando la naturaleza del trabajo. La IA en el SDLC supone el mismo cambio: cada etapa puede funcionar a su propio ritmo, dirigida por un agente especializado. Pero, y este es el punto que se ha recalcado en las sesiones de seguridad: un motor individual sin control es más peligroso que un eje de transmisión centralizado. De ahí la necesidad de un marco metodológico.
AI-DLC se sitúa entre la programación intuitiva (máxima autonomía) y el desarrollo clásico asistido por IA (máximo control).
El AI-DLC se posiciona como un punto de equilibrio entre dos extremos. El «vibe coding», con máxima autonomía del agente, resulta arriesgado en producción. El desarrollo asistido clásico, con control total por parte del ser humano, ofrece pocas ventajas. El AI-DLC busca un tercer punto: la IA coordina (planificación, descomposición, propuestas de arquitectura, generación), los ingenieros arbitran (validación, decisiones estructurales, supervisión). No se trata de un compromiso a medias: es un reparto preciso de responsabilidades basado en las fortalezas relativas de cada uno.
Ciclo de vida del desarrollo impulsado por IA: Inicio → Construcción → Operaciones. Cada etapa aporta información al contexto de la siguiente.
El AI-DLC se estructura en tres fases. La fase de inicio (Inception) agrupa el establecimiento del contexto (estándares, código existente, dependencias, restricciones normativas), la elaboración de la intención a través de historias de usuario y la planificación en unidades de trabajo. Es aquí donde se pone en práctica el «shift-left compliance»: los requisitos de la Ley de IA de la UE, NIS2, CRA y DORA se incorporan desde la fase de definición, en lugar de descubrirse en la auditoría final. La fase de construcción distribuye la generación de código, las pruebas, la incorporación de componentes de arquitectura (secretos, observabilidad, seguridad) y el despliegue IaC. Las operaciones abarcan el despliegue en producción y la gestión de incidencias con la asistencia de un agente de DevOps que realiza el análisis de la causa raíz, la medición del impacto y la propuesta de soluciones, mientras que el ser humano conserva el poder de decisión.
La metodología AI-DLC se aplica en nueve disciplinas, todas ellas asistidas por IA, repartidas en las tres fases.
El caso práctico de Amazon Payments completa el panorama: se llevaron a cabo cuatrocientos proyectos piloto antes de la industrialización a través del AI-DLC. De ellos surgieron cinco principios operativos. Empezar por integrar la IA en el flujo de trabajo existente antes de transformarlo. Dar a la IA acceso al código, a la documentación y a las herramientas, no solo a una indicación aislada. Utilizar archivos de contextualización para alinear los resultados con la intención. Gestionar con precisión el contexto, ya que es este, y no el modelo, lo que determina la calidad del resultado. Y fomentar la innovación de forma responsable, con salvaguardias explícitas y la participación humana en las decisiones de gran impacto.
Qué cambia el AI-DLC para un RSSI El AI-DLC no es solo un marco de productividad, sino también un marco de gobernanza para el desarrollo asistido por IA. Su fase de inicio, si se cuenta con las herramientas adecuadas, se convierte en el punto natural de incorporación de todos los requisitos de seguridad y cumplimiento normativo. Los RSSI deberían verlo como una oportunidad estratégica: es el momento del ciclo en el que los desarrolladores quieren que se les proporcione un marco, porque sin él la IA genera código incoherente con los estándares de la organización. El «shift-left compliance» ya no es un discurso abstracto: es una acción concreta que se puede llevar a cabo desde la primera user story. La otra dimensión, más sutil: el AI-DLC obliga a explicitar lo que los equipos maduros hacían gracias a la proximidad. Las convenciones de nomenclatura, las decisiones de arquitectura y las medidas de seguridad se transmitían oralmente, en la cafetería o durante las revisiones. Los agentes no tienen esa intuición; solo saben lo que se les dice. Por lo tanto, el AI-DLC obliga a crear un registro documental, lo que supone una ventaja clara para la gobernanza y la auditoría. |
Ciberseguridad en Francia: la resiliencia colectiva ante la proliferación de superficies
La mesa redonda, en la que participaron Éric Bothorel, diputado; Laurent Verdier, director de sensibilización de Cybermalveillance.gouv.fr; y los responsables de seguridad de AWS Francia aportó las cifras más llamativas de la jornada. En ella se articula un discurso que prolonga directamente el hilo conductor: cuando la amenaza se vuelve contextual y se industrializa mediante la IA, la defensa ya no puede basarse únicamente en la proximidad humana. También debe volverse explícita y replicable.
La explosión cuantitativa y lo que esconde
220 K Asistencia en 2024 (de los cuales 150 000 son profesionales) | 500 K Asistencia en 2025 (de los cuales 30 000 profesionales) | 1.000 millones de dólares Inversión en ciberseguridad de Amazon / año | 7 % Facturación mundial (sin tener en cuenta la Ley de IA de la UE) |
El cambio de tendencia entre 2024 y 2025 es espectacular. Las solicitudes de asistencia gestionadas por Cybermalveillance.gouv.fr pasan de 220 000 a 500 000, lo que supone un aumento de 2,3 veces en un año. La proporción de solicitudes profesionales disminuye (del 68 % al 6 %), no porque las empresas se hayan librado, sino porque la amenaza al público general se dispara a un ritmo sin precedentes y los atacantes disponen de una sobreabundancia de datos personales para contextualizar sus escenarios. Esta contextualización es el punto de inflexión: una IA de atacante alimentada con datos personales genera escenarios creíbles, específicos y difíciles de detectar mediante los filtros tradicionales.
Tendencias para 2025: el phishing pierde protagonismo
La sorpresa del año: el phishing ya no es la amenaza número uno. Ha sido desbancado por el hackeo de cuentas en línea de microempresas, pymes y asociaciones, debido al uso de contraseñas sencillas o reutilizadas. Le siguen la ingeniería social contextualizada, el fraude en las transferencias bancarias (BEC) y las filtraciones de datos, que convierten a las empresas en objetivos prioritarios al albergar datos de empleados, clientes y socios.
Laurent Verdier insistió: los datos filtrados se convierten en munición para futuros ataques. Efecto de acumulación temporal: cuanto más tiempo pasa, más crece el stock de datos aprovechables y más precisos se vuelven los ataques. Éric Bothorel añade: «Cuantos más datos tengan los atacantes, más eficaz es la IA. Por lo tanto, el consumo de datos también se dispara. » Consecuencia directa para las arquitecturas: el principio de minimización de datos ya no es solo un requisito del RGPD, sino un requisito de seguridad operativa. Cada dato almacenado es un arma potencial.
«La seguridad solo existe si es colectiva». — Laurent Verdier, Cybermalveillance.gouv.fr |
Las medidas mencionadas convergen: la colaboración entre actores privados y el sector público (un caso de redada conjunta de AWS y Microsoft con el Gobierno indio para desmantelar una red de estafas), la certificación «Expert Cyber» de AFNOR, la evolución legislativa europea (NIS2 como base, complementada por CRA, DORA, AI Act) y, sobre todo, la constatación de la hibridación de las amenazas: el espionaje, la injerencia y los ataques digitales convergen, lo que impone defensas distribuidas y replicables. Éric Bothorel lo expresó sin ambigüedades: ante una amenaza híbrida y distribuida, solo una defensa también distribuida y replicada puede resistir a largo plazo.
¿Qué supone todo esto para un profesional de la ciberseguridad?
Es hora de llevar todo esto a nuestro terreno. La Cumbre 2026 lanza cinco señales fundamentales, cada una de las cuales exige una respuesta operativa por parte de los responsables de seguridad de la información, los arquitectos de seguridad y los consultores expertos.
Primera señal: la identidad del agente es el nuevo ámbito de IAM
AgentCore Identity, el tríptico empleado/agente/recurso, el retex de Euronext: todo apunta a la misma conclusión. Las identidades de los agentes constituyen una tercera población de IAM que se suma a las identidades humanas y a las identidades de las máquinas. Requiere sus propias herramientas de gestión, sus propias políticas de rotación y sus propios mecanismos de auditoría. Las organizaciones que no la integren en su estrategia de IAM desde ahora mismo acumulan una deuda invisible cuyo coste de corrección crece exponencialmente con el número de agentes desplegados.
Segunda señal: la gobernanza MCP es la próxima gobernanza API
El protocolo MCP (Model Context Protocol) se está convirtiendo para los agentes en lo que REST es para las aplicaciones. Y, al igual que REST en su momento, primero se extenderá de forma descontrolada antes de que las organizaciones se den cuenta de que hay que regularlo. El caso de Euronext ilustra perfectamente el punto de ruptura y las soluciones arquitectónicas (puerta de enlace única, medidas de protección de datos personales, enrutamiento de herramientas, VPC privada). Las organizaciones que implementen esta gobernanza desde las primeras herramientas MCP se ahorrarán una costosa adaptación; las demás sufrirán la misma curva de aprendizaje que la de las API no reguladas de los años 2015-2018.
Tercera señal: el AI-DLC es el marco de cumplimiento «shift-left» que faltaba
Cuarenta y dos euros destinados al cumplimiento normativo por cada cien euros invertidos en TI. Esta cifra refleja un fallo estructural: el cumplimiento normativo llega demasiado tarde en el ciclo, resulta demasiado costoso y genera demasiadas fricciones. El AI-DLC, con su fase «Inception», que define el contexto, los estándares y los requisitos normativos antes de escribir la primera línea de código, ofrece un marco concreto para resolver este problema. Ya no se trata de un «shift-left» de cumplimiento declarativo, sino de un «shift-left» operativo, instrumentado por agentes que verifican el cumplimiento de forma continua.
Cuarta señal: la cadena de suministro se extiende a los modelos, los agentes y los contextos
Las disciplinas de SBOM, SCA, firma (Sigstore), certificación (SLSA) y programación segura, todas ellas desarrolladas con gran esfuerzo durante la última década, cobran nueva vida al ampliarse al ámbito de la IA. Es necesario inventariar los modelos utilizados, del mismo modo que se inventarían las bibliotecas de código abierto. Rastrear la procedencia de los conjuntos de datos, tal y como se rastrea la procedencia del código. Firmar las cadenas de agentes como se firman los artefactos de compilación. Certificar la conformidad de las indicaciones y los contextos como se certifica la de las configuraciones de infraestructura. El radar de Bureau Veritas de ocho ejes (explicabilidad, equidad, gobernanza, confidencialidad, solidez, seguridad, transparencia y controlabilidad) ofrece un marco de referencia para estructurar esta ampliación.
Quinta señal: la resiliencia requiere medidas de protección explícitas y replicables
Las cifras sobre ciberdelincuencia (de 220 000 a 500 000 solicitudes, contextualización de los ataques mediante IA, hibridación de las amenazas) nos recuerdan una verdad arquitectónica fundamental: una defensa basada en la proximidad humana, los conocimientos tácitos y los procesos no formalizados no resiste el aumento de escala de la amenaza. La defensa debe estar explícita, documentada, ser verificable, auditable y replicable, automatizable, versionable y desplegable de manera homogénea en toda la organización. Este principio, que DevSecOps ha defendido desde sus orígenes, nunca ha sido tan relevante como en la era de la amenaza agencial.
De la gobernanza del código a la gobernanza del contexto
La AWS Summit París 2026 no es una cumbre como las demás. Es aquella en la que, tras dos años de promesas y pruebas de concepto, el ecosistema da el paso definitivo hacia la industrialización basada en agentes. Al concluir este análisis, se refuerzan tres convicciones y se perfila un horizonte más amplio.
Tres convicciones
La gobernanza ha vuelto a convertirse en el tema fundamental. Tras la carrera por las pruebas de concepto (POC), las organizaciones maduras invierten en lo que yo denomino la «infraestructura de control»: identidad, políticas, observabilidad y evaluación. Este es precisamente el terreno de juego de los profesionales de DevSecOps, siempre y cuando den un paso más allá de la gobernanza del código para pasar a la gobernanza de la cadena de agentes. Las competencias en la cadena de suministro de aplicaciones se trasladan de forma natural; lo contrario no es cierto.
El AI-DLC no es una simple moda. Se trata de una metodología coherente que integra el cumplimiento normativo en su fase inicial y que reabre el ámbito de la consultoría en la definición del alcance de los proyectos. Quien sea el primero en formalizarla como un marco operativo en el ecosistema francés obtendrá una ventaja de imagen duradera.
La diferencia radica en la capacidad de transmitir tranquilidad, no en las herramientas. Cuarenta y dos euros en cumplimiento normativo por cada cien euros invertidos en TI. Un 7 % de la facturación mundial en sanciones por la Ley de IA. Quinientas mil solicitudes de asistencia por ciberataques en 2025. Son las organizaciones las que soportan el estrés, y es ese estrés el que hay que absorber, estructurar y transformar en una trayectoria controlada. No vendemos tecnología. Vendemos tranquilidad ante una complejidad que crece más rápido de lo que los equipos pueden asimilar.
La próxima batalla será la del contexto
Si bien esta cumbre marca el giro hacia la industrialización basada en agentes, deja entrever la batalla que vendrá después. Una frase, pronunciada de pasada por los equipos de Amazon Payments y retomada por La Centrale, merece ser meditada: «la ingeniería rápida ya no basta, hay que avanzar hacia la ingeniería contextual». Bajo su apariencia modesta, anuncia un cambio estratégico de una magnitud comparable a la que estamos viviendo actualmente.
La era del «prompt engineering», entre 2023 y 2025, fue aquella en la que se buscaba la fórmula mágica, el «prompt» perfecto que desbloqueara las capacidades del modelo. Un oficio de manitas refinado. La era que se abre ahora es diferente: lo que importa a partir de ahora es la arquitectura del contexto en el que opera el agente. ¿De qué herramientas dispone? ¿Con qué derechos? ¿Sobre qué datos? ¿Con qué memoria? ¿Qué documentación? ¿Qué estándares? ¿Qué ejemplos? ¿En qué cadena de agentes se inscribe? Todas estas son cuestiones que ya no se abordan a nivel del prompt, sino a nivel de la plataforma, la gobernanza y la arquitectura de la aplicación.
Este cambio tiene profundas repercusiones en nuestra profesión. El profesional de la ciberseguridad de 2028-2030 ya no se limitará a gestionar la cadena de producción de software. Gestionará la producción de contextos: los repositorios de código visibles para los agentes, las herramientas de gestión de contenidos y proyectos (MCP) disponibles, los documentos de marco de referencia, las memorias compartidas y las reglas de evaluación. La disciplina emergente que se está empezando a denominar «ingeniería de contextos» agrupará todo esto. Tomará prestados elementos de la arquitectura de la información, la gestión del conocimiento, la seguridad de los datos, la gestión de identidades y accesos (IAM), la observabilidad y la gobernanza documental. Se trata de una disciplina compuesta que aún no tiene un nombre definitivo ni profesionales reconocidos.
Hay tres preguntas concretas que permiten abordar este tema desde ya. ¿Quién controla el contexto en su organización? Si la respuesta es «nadie» o «cada uno va a lo suyo», el riesgo es enorme: desviaciones de los agentes, incoherencia en las decisiones y fuga de datos sensibles introducidos como contexto por negligencia. ¿Cómo gestiona las versiones del contexto? Si este guía las decisiones de los agentes, tiene los mismos requisitos que un código fuente: debe tener versiones, revisarse, probarse e implementarse de forma controlada. ¿Cómo evalúa la calidad de un contexto? Un mal contexto produce malos agentes, por muy sofisticado que sea el modelo subyacente.
Termino este artículo con una convicción. Nuestra profesión nunca ha sido tan apasionante. No somos meros observadores de la revolución de la inteligencia artificial, sino sus artífices. Lo que construyamos en los próximos meses determinará la forma en que las organizaciones utilizarán la inteligencia artificial durante la próxima década. Es una responsabilidad, es una oportunidad y, sobre todo, es un momento excepcional en el que nuestra disciplina se encuentra exactamente en el centro de la ecuación.
Anexo: Glosario de anuncios y conceptos clave
Concepto | Descripción |
Amazon Bedrock AgentCore | Entorno de ejecución gestionado para agentes de IA: seis componentes (Runtime, Gateway, Identity, Policy, Observability, Evaluations). Eje central de la estrategia de agentes de AWS para 2026. |
AgentCore Gateway | Punto de entrada unificado /mcp que convierte las API, las funciones Lambda y los servidores MCP en recursos gestionables. Caché, protecciones de datos personales (PII) y enrutamiento de herramientas. |
AgentCore Identity | Identidad propia del agente (distinta de la del usuario), gestión de la autenticación en tres niveles. |
Política de AgentCore | Permisos granulares RBAC + ABAC por herramienta, operación y contexto. |
AgentCore Observability | Trazabilidad de extremo a extremo: tokens, latencia, cadenas de invocación. |
Valoraciones de AgentCore | LLM-as-a-judge integrado con Observability para la evaluación continua de los agentes. |
MCP (Protocolo de contexto de modelo) | Protocolo estandarizado de comunicación entre agentes de IA y herramientas o servicios. |
AI-DLC | Ciclo de vida del desarrollo impulsado por la IA: tres fases (Concepción, Construcción, Operaciones) y nueve disciplinas asistidas por IA. |
Ingeniería de contexto | Disciplina emergente: ingeniería post-prompt. Arquitectura del contexto puesto a disposición de los agentes: herramientas, derechos, datos, memoria, estándares. |
Kiro | IDE de AWS, competidor de Claude Code y Cursor. |
AWS Transform | Agente de migración de código y arquitecturas (ejemplo de Air Canada: reducción del tiempo a una quinta parte). |
Funciones duraderas de Lambda | Patrón: ejecutar/punto de control/suspender/reanudar/reproducir. Fin del límite de 15 minutos de Lambda. |
Nube soberana europea de AWS | Región autónoma, entidades jurídicas europeas, Brandeburgo. Primer cliente: Ariane 6. |
Bureau Veritas: radar de IA | Evaluación de la IA en ocho aspectos: explicabilidad, equidad, gobernanza, confidencialidad y seguridad, solidez, fiabilidad, transparencia y controlabilidad. |
Ley de IA de la UE | Reglamento europeo sobre la IA: 113 artículos, sanciones de hasta el 7 % de la facturación mundial. |
