La IA ya puede investigar vulnerabilidades de software, comprobar si son explotables y ayudar a desarrollar correcciones. La oportunidad para las empresas es importante, pero también lo son las dudas sobre fiabilidad, seguridad y control.
Las empresas tienen herramientas de seguridad. ¿Por qué corregir vulnerabilidades sigue dando tanto trabajo?
Imagina una empresa de software con decenas de aplicaciones, lanzamientos de código frecuentes y un equipo pequeño de seguridad de aplicaciones.
Cada día, los desarrolladores modifican código, actualizan dependencias y conectan las aplicaciones con nuevos servicios. Las herramientas de seguridad existentes analizan esos cambios e identifican posibles debilidades.
Algunos hallazgos son sencillos. Una dependencia vulnerable puede necesitar una actualización, o una credencial incrustada en el código puede tener que eliminarse.
Otros exigen una investigación más profunda.
Un escáner puede señalar código sospechoso, pero determinar si se trata de una vulnerabilidad real puede implicar varios servicios, reglas de autenticación, flujos de datos y configuraciones de despliegue.
Un ingeniero de seguridad investiga el hallazgo. Un desarrollador explica el comportamiento de la aplicación. Alguien reproduce el problema, propone una corrección y prueba el resultado.
Mientras tanto, llega más código.
A la empresa no necesariamente le faltan herramientas de seguridad. Su desafío es convertir los hallazgos de seguridad en problemas confirmados y resueltos.
Ese es el problema de negocio que intenta abordar una nueva generación de sistemas de seguridad con IA.
Los avances recientes de Anthropic, OpenAI, Google, GitHub y empresas especializadas en seguridad sugieren que la IA puede asumir una parte mayor de la investigación que rodea a una vulnerabilidad.
Pero ¿qué pueden hacer realmente estos sistemas? ¿Y cómo debe decidir una empresa si vale la pena adoptarlos?
De encontrar código sospechoso a investigar debilidades de seguridad
La detección automatizada de vulnerabilidades no es nueva.
Las organizaciones ya utilizan pruebas estáticas de seguridad de aplicaciones (SAST), pruebas dinámicas de seguridad de aplicaciones (DAST), análisis de composición de software (SCA), detección de secretos y pruebas de penetración.
Cada método responde a preguntas distintas. El análisis estático examina el código o su representación. Las pruebas dinámicas examinan aplicaciones en ejecución. El análisis de dependencias identifica problemas conocidos en software de terceros. Las pruebas de penetración investigan si las debilidades pueden explotarse dentro de un alcance autorizado.
Estas capacidades siguen siendo importantes.
La dificultad es que identificar un comportamiento sospechoso no siempre equivale a comprender sus consecuencias para la seguridad.
Un agente basado en razonamiento puede investigar cómo interactúan varios archivos, servicios y permisos. Puede formular una hipótesis, examinar las pruebas que la respaldan y proponer pruebas adicionales.
Eso hace posible un tipo distinto de investigación de seguridad.
Alternativa de texto accesible para esta figura
Flujo convencional: Análisis, Hallazgos, Priorización, Corrección del desarrollador, Revisión y nueva prueba.
Flujo asistido por agentes: Entender el contexto, Investigar, Validar, Proponer corrección probada, Revisión independiente.
Los dos flujos son conceptuales. Los escáneres existentes ya automatizan el análisis, y no se afirma que ningún agente concreto realice todas las etapas.
El cambio importante no es que el análisis de seguridad se automatice. Eso ya ocurría.
El cambio es que el software puede ayudar cada vez más en el trabajo que va entre la detección, la validación y la corrección.
Lo que representan realmente Claude Security y GPT-6 Cyber
Dos anuncios recientes ilustran partes distintas de esta evolución.
Claude Security: investigación continua de seguridad de aplicaciones
Claude Security, de Anthropic, se conecta a repositorios de software, examina las relaciones dentro del código y construye un contexto de modelo de amenazas.
Ese contexto parte del código. Los equipos pueden editar el modelo de amenazas y añadir contexto de despliegue y documentos de arquitectura, que según Anthropic Claude podría pasar por alto de otro modo.
El servicio alojado admite el análisis de referencia, el análisis recurrente de los cambios de código, la validación de hallazgos, la ayuda con las correcciones y el seguimiento de los problemas sin resolver.
Estaba disponible en beta para los usuarios del plan Enterprise en la fecha de cierre de la investigación, y requiere un puesto premium por cada usuario y créditos de uso. Un proyecto puede conectar hasta ocho repositorios.
Lo que lo distingue de una conversación puntual con un asistente de programación es el flujo de trabajo que lo rodea. Mantiene el contexto del proyecto y realiza el seguimiento de los hallazgos a medida que cambia el código.
Esto podría reducir el esfuerzo necesario para reconstruir la arquitectura de una aplicación cada vez que aparece un problema de seguridad.
Pero Anthropic también documenta una limitación importante: dos análisis del mismo código pueden producir hallazgos distintos porque la investigación del agente es estocástica, es decir, no sigue siempre el mismo camino.
Eso plantea la pregunta de cómo deben establecer las organizaciones una garantía de seguridad repetible.
GPT-6 Cyber: investigación más profunda de vulnerabilidades y exploits
GPT-6 Cyber, de OpenAI, aborda el problema de otra manera.
Es un modelo especializado en ciberseguridad, diseñado para la investigación avanzada de vulnerabilidades, incluida la validación de si las debilidades pueden explotarse.
OpenAI informa de una tasa de éxito del 48.5 % en su benchmark ExploitGym, frente al 32.1 % de GPT-5.6 Cyber, en su propia evaluación.
La empresa también informa de que sus investigadores usaron el modelo para desarrollar exploits funcionales para 948 vulnerabilidades del kernel de Linux y para encontrar 81 vulnerabilidades desconocidas hasta entonces en Firefox que Mozilla clasificó como de gravedad alta.
Estos resultados indican avances en tareas concretas de investigación en ciberseguridad. No significan que el modelo vaya a identificar el 48.5 % de las vulnerabilidades de una empresa ni a reducir su riesgo de seguridad en una proporción equivalente.
OpenAI clasifica la capacidad de ciberseguridad del modelo como Critical en su Preparedness Framework. OpenAI dice que el modelo está disponible inicialmente a través de su API y de Codex para un grupo selecto de clientes aprobados de su programa Daybreak Red.
No es la misma categoría de producto que un servicio de análisis de seguridad conectado a repositorios.
Claude Security es sobre todo un flujo de trabajo empaquetado de seguridad de aplicaciones. GPT-6 Cyber aporta una capacidad de modelo especializada que puede respaldar investigaciones avanzadas de seguridad y otras herramientas autorizadas.
La comparación importa porque las empresas no deben confundir un modelo capaz con un servicio de seguridad completo.
¿Quién más está desarrollando capacidades similares?
Anthropic y OpenAI no son las únicas. Varias empresas abordan distintas partes del mismo desafío de seguridad.
| Proveedor o servicio | Enfoque principal | Diferencia importante |
|---|---|---|
| Claude Security | Investigación de seguridad de repositorios | Análisis continuo, contexto y seguimiento de correcciones. Beta para usuarios del plan Enterprise |
| Google CodeMender | Descubrimiento de vulnerabilidades, verificación y generación de parches | Pruebas locales y verificación de exploits. Preview para un grupo limitado de clientes a través de ventas de Google Cloud, no apto para producción |
| GitHub Agentic Autofix | Corrección de alertas de code scanning | Valida los cambios con CodeQL y prepara pull requests. Disponibilidad general desde el 15 de octubre de 2026 para Code Security y Advanced Security en GitHub Enterprise Cloud, solo alertas de la rama predeterminada |
| Semgrep Agentic AppSec | Análisis de seguridad asistido por agentes | Combina herramientas de análisis de programas, contexto persistente y flujos de trabajo con agentes. Disponible para clientes de Semgrep, con la capa de contexto en beta privada |
| Snyk Agent Fix | Corrección de seguridad para desarrolladores | Amplía los flujos de gestión de vulnerabilidades y de corrección ya existentes. Snyk informa de sus propios resultados de benchmark |
| XBOW | Pruebas de penetración autónomas | Prueba dentro de un alcance definido por el cliente. XBOW dice que comprobaciones deterministas validan los hallazgos antes de informar de ellos |
| Palo Alto Networks Unit 42 | Evaluación continua de la exposición empresarial | Servicio gestionado dirigido por expertos y con varios modelos |
La comparación refleja propósitos principales distintos, no un ranking. La disponibilidad y las capacidades admitidas deben revisarse para la suscripción o el despliegue concretos.
Estas ofertas revelan algo importante.
Google CodeMender combina razonamiento de IA, pruebas de seguridad y parches generados. Agentic Autofix de GitHub parte de las alertas de code scanning existentes, trabaja sobre los archivos relevantes, vuelve a ejecutar CodeQL y abre un pull request en borrador. Semgrep combina flujos de trabajo con agentes y análisis de programas especializado, en lugar de depender solo del razonamiento del modelo.
XBOW y Palo Alto Networks llegan más lejos, hacia las pruebas de penetración y la validación de rutas de ataque. Palo Alto Networks también usa varios modelos y supervisión de expertos, en lugar de confiar en un solo modelo para realizar todas las tareas de seguridad.
Varias de estas herramientas ejecutan comandos o abren pull requests en tu nombre, así que el acceso que necesitan forma parte de la decisión.
Por tanto, el mercado no es una categoría simple de productos de seguridad con IA.
Una empresa debe establecer primero si necesita mejor análisis de código, validación de vulnerabilidades, ayuda con las correcciones, pruebas de penetración o investigación en operaciones de seguridad.
Solo entonces tiene sentido comparar proveedores.
¿Qué ocurre cuando un agente de IA investiga un problema real de una aplicación?
Consideremos una aplicación financiera ficticia.
Un cliente inicia sesión y solicita información de su cuenta mediante una API. La aplicación verifica que el cliente esté autenticado, pero un endpoint no comprueba si la cuenta solicitada pertenece realmente a ese cliente.
Esta es una debilidad de autorización.
Un escáner convencional podría detectar algunas formas de este problema, pero la causa de fondo puede ser difícil de ver porque cada función, por separado, puede parecer razonable.
Para entender la vulnerabilidad hay que seguir la relación entre el usuario autenticado, el identificador de la cuenta y las reglas de negocio que controlan el acceso.
| Etapa | Qué debe ocurrir | Dónde puede ayudar un agente |
|---|---|---|
| Descubrimiento | Identificar un endpoint con comprobaciones de acceso sospechosas | Rastrear la identidad y los datos de la cuenta a través de las funciones |
| Investigación | Determinar si se exige que la cuenta pertenezca al cliente | Examinar los servicios conectados y la lógica de autorización |
| Validación | Establecer si es posible un acceso no autorizado | Proponer pruebas en un entorno aislado y autorizado |
| Corrección | Corregir la comprobación de propiedad que falta | Generar un cambio de código dirigido |
| Verificación | Demostrar que el acceso legítimo funciona y que el no autorizado falla | Ejecutar pruebas de regresión funcionales y de seguridad |
| Publicación | Desplegar la corrección aprobada | Aportar evidencia para la revisión independiente |
Escenario ilustrativo, no un incidente real ni una demostración del rendimiento de ningún proveedor en particular.
La posible ventaja del agente es su capacidad de conectar información de varias etapas, en lugar de obligar a los ingenieros a reconstruir manualmente cada relación.
Pero un resultado de seguridad satisfactorio exige más que un agente que diga que la vulnerabilidad está corregida.
La aplicación corregida debe aplicar las reglas de acceso previstas. Las operaciones legítimas existentes deben seguir funcionando. Las pruebas deben ser pertinentes, y la corrección debe llegar al entorno donde existía la debilidad.
Un agente de seguridad puede reducir el esfuerzo necesario para llegar a ese resultado.
No debe tratarse como la autoridad final sobre si el resultado se ha logrado.
¿Dónde podrían ver valor de negocio las empresas?
La mayor oportunidad podría estar en reducir el tiempo entre el descubrimiento de una vulnerabilidad y la aplicación de una corrección verificada.
Investigación más rápida
Los hallazgos de seguridad complejos pueden consumir mucho tiempo de ingeniería. Un agente con el contexto adecuado de la aplicación puede ayudar a los ingenieros a entender las rutas de ataque e identificar los componentes afectados.
Orientación de corrección más útil
Un hallazgo que identifica la causa de una debilidad y propone una corrección comprobable puede ser más útil que una alerta que solo indica una ubicación y una gravedad.
Evaluación más frecuente
La investigación continua o repetida puede identificar algunos problemas antes que las evaluaciones ocasionales, sobre todo cuando las aplicaciones cambian con frecuencia.
Mejor aprovechamiento de una experiencia de seguridad limitada
Los desarrolladores y los ingenieros de seguridad pueden dedicar menos tiempo a reunir contexto rutinario y más a examinar los hallazgos importantes, diseñar controles y aprobar correcciones.
Estos son beneficios potenciales, no mejoras garantizadas.
| Lo que quieren las empresas | Lo que deberían medir |
|---|---|
| Menos riesgos de seguridad sin resolver | Tiempo hasta la corrección verificada y exposición restante |
| Menos esfuerzo de investigación | Tiempo de revisión humana y de investigación por problema confirmado |
| Mejores hallazgos | Verdaderos positivos validados, falsos positivos y vulnerabilidades no detectadas |
| Correcciones más seguras | Regresiones funcionales y de seguridad tras una corrección propuesta |
| Mejor economía | Costo total por corrección verificada, incluido el uso de la herramienta y el trabajo repetido |
Un proveedor podría informar de que descubre muchas más vulnerabilidades o de que completa las investigaciones mucho más rápido.
Esos resultados merecen atención, pero las organizaciones deben preguntar qué se midió, qué línea base se usó y si los resultados se aplican a sus propios entornos.
Un benchmark que muestra un mejor rendimiento en el desarrollo de exploits no demuestra un retorno de la inversión empresarial. Incluso la auditoría de un proveedor puede cambiar un resultado destacado: AWS redujo sus 35 flags capturadas a 33 exploits verificados una vez que examinó cómo se había obtenido cada flag.
Del mismo modo, una herramienta que produce más hallazgos puede no reducir el riesgo si esos hallazgos siguen sin resolverse.
El objetivo de negocio no es generar el informe de seguridad más extenso.
Es reducir la exposición significativa con un costo y una interrupción aceptables.
Por qué una mayor capacidad de seguridad también crea una mayor responsabilidad
Un agente de seguridad necesita acceso para hacer un trabajo útil.
Puede necesitar leer código fuente, inspeccionar la configuración, ejecutar pruebas, comunicarse con herramientas o proponer cambios en varios repositorios.
Las pruebas de seguridad avanzadas pueden requerir una explotación controlada contra objetivos autorizados de forma específica.
Esas capacidades crean un nuevo límite de seguridad.
Supón que un agente lee documentación con instrucciones maliciosas. Si el agente trata ese material no confiable como una instrucción en lugar de como evidencia, podría intentar una acción no autorizada.
Esta es una forma de inyección de prompts.
Un agente muy capaz también podría producir parches inseguros, exponer información sensible, consumir recursos inesperados o intentar acciones fuera de su alcance aprobado.
Por eso, la arquitectura de seguridad que lo rodea debe controlar al agente con independencia de su razonamiento.
| Actividad del agente | Límite adecuado |
|---|---|
| Leer el código fuente pertinente | Alcance explícito de repositorios y datos |
| Analizar hallazgos | Evidencia registrada sobre versiones identificables |
| Ejecutar pruebas o demostraciones de exploits | Objetivos aislados y autorizados, y herramientas controladas |
| Proponer modificaciones de código | Permisos de escritura restringidos y cambios revisables |
| Fusionar o desplegar correcciones | Aprobación independiente y controles de publicación existentes |
| Manejar información sensible | Políticas definidas de retención, acceso y procesamiento |
La guía de OWASP sobre seguridad de agentes de IA hace hincapié en el mínimo privilegio, la autorización de herramientas, la protección contra la inyección de prompts, la ejecución controlada y la aprobación humana para las operaciones importantes.
Los acuerdos de manejo de datos también difieren entre productos. Por ejemplo, Anthropic afirma que el servicio alojado Claude Security no admite Zero Data Retention (retención cero de datos). Documenta por separado un plugin de seguridad de Claude Code para las organizaciones que necesitan otras modalidades de despliegue.
Esa diferencia ilustra por qué una empresa debe revisar el servicio real y las condiciones de despliegue, en lugar de fiarse solo del nombre de un producto.
Los agentes de seguridad pueden ser herramientas potentes, pero no se debe permitir que creen nuevas vías de acceso sin gestionar hacia los sistemas que se supone que deben proteger.
¿Pueden las empresas confiar en agentes de seguridad que no siempre producen los mismos resultados?
La documentación de Anthropic afirma de forma explícita que los análisis de Claude Security son estocásticos.
Un agente de razonamiento puede investigar caminos distintos en ejecuciones distintas, incluso sobre el mismo código.
Eso puede ser valioso. Una investigación flexible puede descubrir una falla de lógica de negocio que una regla fija no reconoce.
Pero también limita lo que puede establecer un resultado limpio.
Si un agente no encuentra ninguna vulnerabilidad crítica en un análisis, la organización no puede suponer que se examinaron todas las rutas de ataque relevantes.
Las herramientas de seguridad tradicionales también tienen limitaciones. Un escáner determinista puede repetir sus comprobaciones de forma fiable y aun así no detectar vulnerabilidades que quedan fuera de sus reglas o de sus capacidades de análisis.
Por tanto, una arquitectura más sólida puede combinar distintos tipos de evidencia:
- Las comprobaciones de seguridad repetibles establecen la cobertura conocida.
- Los agentes de razonamiento investigan debilidades complejas y dependientes del contexto.
- Las pruebas controladas validan los hallazgos importantes.
- Los revisores humanos evalúan el impacto de negocio y las decisiones importantes.
- Las pruebas posteriores comprueban si las correcciones siguen siendo eficaces.
Esta es una recomendación de arquitectura, no una afirmación de que un proveedor concreto haya resuelto el problema.
El objetivo debe ser lograr resultados de seguridad fiables, no depender exclusivamente de los escáneres tradicionales ni del razonamiento de la IA.
¿Serán menos importantes los ingenieros de seguridad?
La IA puede automatizar partes del descubrimiento, la investigación y la corrección de vulnerabilidades.
Pero la seguridad de aplicaciones no consiste solo en saber reconocer código inseguro.
Alguien sigue teniendo que entender los procesos de negocio, identificar los activos críticos, definir el riesgo aceptable, diseñar políticas de acceso y determinar si una corrección es adecuada.
La IA puede ayudar a reunir evidencia para esas decisiones. No adquiere automáticamente autoridad ni responsabilidad dentro de la organización, una brecha que se analiza en La IA hace cada vez mejor el trabajo. Pero ¿está lista para hacerse cargo del resultado?
Lo más realista a corto plazo es que los ingenieros de seguridad dediquen menos tiempo a ciertas tareas repetitivas y más a evaluar riesgos complejos, supervisar investigaciones automatizadas y asegurarse de que los agentes operen con seguridad.
Algunas organizaciones podrían mejorar su cobertura sin hacer crecer los equipos al mismo ritmo que sus carteras de software.
Otras podrían necesitar nueva experiencia en seguridad de agentes, permisos de herramientas, comportamiento de los modelos y evaluación.
La evidencia aún no justifica una predicción general de que los agentes de seguridad con IA reemplazarán a los ingenieros de seguridad.
Respalda una conclusión más acotada: es probable que las actividades y las habilidades de la ingeniería de seguridad cambien a medida que estas herramientas maduren.
¿Deberían las empresas adoptar estas tecnologías ahora?
No todas las organizaciones necesitan otra plataforma de seguridad.
Una empresa con muchos repositorios, revisores de seguridad con experiencia y un gran volumen de vulnerabilidades pendientes puede tener una buena razón para evaluar la investigación asistida por agentes.
Un equipo de desarrollo más pequeño puede encontrar que ampliar un flujo de trabajo ya existente con GitHub, Semgrep o Snyk es más práctico que contratar un servicio aparte.
Una organización que trabaja con código muy sensible o con sistemas fuertemente regulados puede tener que establecer requisitos de manejo de datos, aislamiento y autorización antes de realizar siquiera una evaluación limitada.
| Situación de la organización | Siguiente paso sensato |
|---|---|
| Programa de AppSec maduro y muchos hallazgos sin resolver | Hacer una comparación controlada con el flujo de trabajo existente |
| Equipo pequeño que ya usa herramientas de seguridad con funciones de IA | Evaluar las capacidades ya incluidas en sus plataformas actuales |
| Aplicaciones o infraestructura muy sensibles | Establecer primero las salvaguardas de acceso, procesamiento de datos y ejecución |
| Sin un proceso fiable de análisis, responsabilidad o corrección | Resolver esos fundamentos antes de esperar que la IA los compense |
| Interés en la investigación avanzada de exploits | Usar servicios especializados debidamente autorizados y entornos controlados |
Empieza con un problema de negocio representativo y decide qué significa el éxito antes de probar.
Por ejemplo: ¿puede un flujo de trabajo asistido por agentes ayudar a resolver un conjunto de vulnerabilidades confirmadas con más precisión o menos costo que el proceso actual?
Una prueba práctica: toma un conjunto de vulnerabilidades que tu equipo ya haya confirmado y corregido, ejecuta tanto tu flujo de trabajo actual como el asistido por agentes sobre ese mismo conjunto, y compara el tiempo hasta la corrección verificada, los hallazgos no detectados y las regresiones.
Mide los resultados reales, incluidas las vulnerabilidades no detectadas y los cambios inseguros. Evalúa el costo total y no solo el precio de la herramienta de IA.
Y mantén las acciones importantes, en particular la ejecución de exploits, la fusión de correcciones de seguridad y los cambios en producción, dentro de controles de autorización aplicados de forma independiente.
Una evaluación que concluya que la tecnología aún no es útil para una organización concreta sigue siendo valiosa. Puede evitar una inversión mayor sin evidencia que la respalde.
El cambio más amplio no consiste en reemplazar a los escáneres
El desarrollo de software asistido por IA ha facilitado generar y modificar código. Eso aumenta la importancia de las prácticas de seguridad capaces de seguir el ritmo de unas aplicaciones cambiantes.
Los sistemas de seguridad con agentes son una posible respuesta.
Pueden conectar la comprensión del código, la investigación de vulnerabilidades, la validación y la corrección de maneras que antes resultaba difícil automatizar.
El mercado emergente ya incluye plataformas de seguridad de repositorios, corrección asistida por IA, pruebas de penetración autónomas y servicios de varios modelos dirigidos por expertos.
Estas tecnologías no son equivalentes, y la evidencia que respalda sus afirmaciones de rendimiento varía.
Las empresas deben evaluarlas según el trabajo de seguridad que necesitan completar, no por la sofisticación del modelo ni por el entusiasmo que rodea a un lanzamiento.
El objetivo fundamental de la ciberseguridad no ha cambiado.
Las empresas siguen necesitando identificar las debilidades, entender sus consecuencias y corregirlas antes de que causen daño.
Lo que cambia es cuánto de ese trabajo puede llegar a hacer el software, y con cuánto cuidado deben controlar las empresas al software que lo hace.
Profundiza
Estas fuentes ofrecen detalles técnicos, límites de los productos y orientación de seguridad pertinente.
- Anthropic: Use Claude Security: Análisis de repositorios, escaneo continuo, modelos de amenazas, hallazgos, correcciones y limitaciones documentadas.
- OpenAI: GPT-6 Cyber, November 5, 2026: Capacidades del modelo de ciberseguridad especializado, benchmarks, investigación autorizada y controles de seguridad.
- Google Cloud: CodeMender overview: Descubrimiento de vulnerabilidades, verificación y generación de parches, incluidas las limitaciones de la preview.
- GitHub: Agentic Autofix general availability, October 15, 2026: Corrección de alertas de code scanning e integración con pull requests revisables.
- Semgrep: Agentic AppSec Platform, November 12, 2026: Flujos de seguridad con agentes respaldados por análisis de programas y contexto de código persistente.
- Palo Alto Networks: Unit 42 Continuous Frontier AI Defense: Descubrimiento continuo de la exposición, validación y servicios de seguridad gestionados por expertos con varios modelos.
- OWASP: AI Agent Security Cheat Sheet: Controles prácticos para los permisos de los agentes, el uso de herramientas, la inyección de prompts, la ejecución y la revisión humana.
- Snyk: Agent Fix agentic architecture, April 27, 2026: Cómo describe Snyk la corrección automatizada de código y sus propios resultados de benchmark.
- XBOW: We ran 1,060 autonomous attacks, March 2, 2026: La descripción de XBOW de las pruebas de penetración autónomas, el control del alcance y la validación.
Las fuentes se leyeron el 13 de noviembre de 2026. La disponibilidad de los productos y las cifras de los proveedores son las de los propios proveedores y pueden cambiar.