Uso del AST en código de flujos de trabajo y seguridad

Informatec Digital » Recursos » Uso del AST en código de flujos de trabajo y seguridad

Cuando hablamos de AST en código de flujos de trabajo, en realidad estamos mezclando varios mundos que, aunque parezcan lejanos, están cada vez más conectados: la ingeniería de software clásica, la seguridad de aplicaciones, la automatización de procesos con RPA, la generación de código con IA y, curiosamente, hasta la prevención de riesgos laborales. Todo gira en torno a cómo modelamos, analizamos, automatizamos y protegemos los flujos de trabajo que gobiernan sistemas complejos.

Los Árboles de Sintaxis Abstracta (AST) se han convertido en una pieza clave para entender y transformar código, automatizar auditorías, generar pruebas, reforzar la seguridad y hasta representar gráficamente workflows de negocio. A la vez, bajo las mismas siglas AST encontramos conceptos como Application Security Testing o Análisis de Seguridad en el Trabajo, que apuntan a otra idea de fondo: tomar los flujos de trabajo (de software o de personas) y someterlos a un análisis sistemático para detectar fallos, riesgos y oportunidades de mejora.

AST como Árbol de Sintaxis Abstracta en flujos de trabajo y generación de código

En desarrollo de software a medida, el uso de Árboles de Sintaxis Abstracta permite pasar de código opaco a estructuras visuales y comprensibles que describen con precisión la lógica de un flujo de trabajo. Un AST descompone el programa en nodos que representan operaciones, estructuras de control, llamadas a funciones, datos y relaciones entre ellos, de forma que la lógica deja de ser “líneas de código sueltas” para convertirse en un grafo navegable.

Esta representación es especialmente útil cuando se gestionan agentes de inteligencia artificial o arquitecturas distribuidas, donde los flujos son intrincados y difíciles de seguir mentalmente. Al transformar el código de un workflow en un AST, es posible generar diagramas que muestran de forma intuitiva ramas de decisión, dependencias entre componentes, orden de ejecución y puntos críticos del proceso, facilitando tanto el desarrollo como la revisión y la toma de decisiones técnicas.

Empresas especializadas en software a medida, como Q2BSTUDIO, aprovechan estos árboles sintácticos para convertir flujos de trabajo complejos en diagramas accesibles, visualmente claros y, sobre todo, útiles a nivel funcional. No se trata solo de “dibujar cajitas”, sino de tener un modelo estructurado que sirva para refinar algoritmos, identificar cuellos de botella, localizar errores lógicos y preparar el terreno para optimizaciones posteriores.

La gran ventaja del AST en este contexto es que es independiente del lenguaje de programación final. A partir de un mismo árbol se puede compilar o transformar el flujo hacia distintos lenguajes o plataformas (por ejemplo, distintos runtimes en la nube como AWS o Azure), manteniendo una lógica de negocio coherente. Esto habilita arquitecturas más flexibles, portables y mantenibles, donde el core del proceso está definido de forma abstracta y el código ejecutable es una derivación controlada.

Otro punto clave es la reutilización de nodos dentro del AST. Es posible definir bloques lógicos (por ejemplo, validaciones de entrada, patrones de acceso a datos o mecanismos de auditoría) que se reutilizan como piezas seguras y ya validadas. Si estos nodos son además conocidos por la IA generadora de código, puede referenciarlos en lugar de inventar desde cero, incrementando enormemente la seguridad y la consistencia del software generado.

AST y generación de funciones con IA: seguridad, validez y confianza

La irrupción de modelos de IA generando código ha abierto un nuevo frente: ¿cómo confiar en funciones escritas por una IA sin revisar cada línea a mano? Una solución sólida es no pedir directamente “código ejecutable”, sino una representación estructurada de la lógica mediante un AST, que luego se valida y transforma en código por una herramienta de confianza.

Al trabajar con AST en lugar de código plano, la IA genera nodos, operaciones, estructuras de control y flujos de datos que pueden analizarse de forma automática: se comprueban tipos, rutas de ejecución, coherencia de parámetros, manejo de errores, condiciones límites y otras propiedades antes de llegar al compilador o al intérprete. Este filtro reduce de manera drástica el riesgo de ejecutar código malicioso o simplemente incorrecto.

Q2BSTUDIO y otras organizaciones que exploran estas técnicas dan especial importancia a que la lógica generada por IA sea rastreable y verificable. El AST se convierte en la “verdad intermedia” sobre la que se aplican reglas de seguridad, estándares de calidad, políticas internas y análisis de impacto. Así, cada función generada encaja en una biblioteca de nodos seguros, aprovechando elementos previamente auditados.

Esta aproximación abre además la puerta a compilaciones multiobjetivo: a partir del mismo AST se puede obtener código en distintos lenguajes (por ejemplo, Python para microservicios, C# para servicios internos, o scripts especializados para orquestadores de la nube). Para empresas que trabajan en entornos híbridos o multicloud, esto resulta especialmente atractivo, porque asegura que el flujo de negocio es consistente sin importar el stack final.

Por último, el uso de nodos reutilizables dentro del AST permite construir “bibliotecas de lógica” certificadas. La IA, en lugar de inventar patrones de acceso a base de datos, validaciones de seguridad o trazas de logging, los compone a partir de estos bloques, lo que mejora tanto la seguridad como el rendimiento y favorece la analítica posterior en herramientas como Power BI u otras plataformas de inteligencia de negocio.

AST aplicado a testing inteligente en Python y máxima cobertura de código

El AST también es la base de soluciones avanzadas de testing automatizado, como ciertos kits de herramientas open source para Python que utilizan la estructura del código para generar baterías de pruebas con una cobertura muy superior a la que se suele conseguir escribiéndolas a mano.

En este tipo de herramientas se combinan tres capacidades principales: generación automática de pruebas unitarias para un fichero Python concreto, fuzzing guiado para someter funciones críticas a entradas extremas y mal formadas, y una generación de pruebas orientada por la cobertura, donde el AST se analiza a fondo para localizar todas las ramas, bucles, condiciones y rutas de excepción posibles.

La clave está en que la herramienta construye el AST del código Python y, a partir de él, identifica rutas de ejecución que aún no tienen pruebas que las cubran. Con esa información encarga a un modelo de IA (por ejemplo, Gemini) la creación de casos de prueba dirigidos específicamente a activar cada camino. Después ejecuta las pruebas y mide la cobertura con herramientas como coverage.py, cerrando así un ciclo automatizado de mejora continua.

Este enfoque no se limita a generar un lote inicial de tests, sino que permite iterar y mejorar: si después de una primera ronda siguen quedando rutas sin ejercicio, se vuelven a estudiar a partir del AST y se solicitan nuevos casos a la IA. Con esto, el proceso se adapta tanto a código nuevo como a bases de código heredadas con poca o ninguna cobertura previa.

El proyecto está montado como un servidor MCP (Model Context Protocol), de forma que funciona como un servicio local al que se puede llamar desde el editor o la línea de comandos. El uso de BAML facilita que el código de pruebas que se genera cumpla un formato preciso, sea fácil de analizar y no rompa las herramientas de integración continua que lo consumen.

AST como Análisis de Seguridad en el Trabajo: flujos seguros en el entorno laboral

Bajo las mismas siglas AST encontramos otro concepto muy extendido en prevención de riesgos laborales: el Análisis de Seguridad en el Trabajo. Aunque se mueve en un plano distinto al del código, comparte con los Árboles de Sintaxis Abstracta la idea de descomponer un flujo (en este caso, de tareas humanas) en etapas, identificar riesgos y definir controles antes de ejecutar.

El Análisis de Seguridad en el Trabajo es un proceso preventivo que se aplica sobre todo en actividades de alto riesgo, como trabajos en altura, manejo de maquinaria compleja o manipulación de sustancias peligrosas. El flujo de trabajo se trocea en pasos, y para cada uno se identifican peligros concretos, se evalúa el nivel de riesgo y se especifican medidas de control (EPP, señalización, instrucciones de emergencia, etc.).

Entre los beneficios principales del AST laboral destacan la reducción de accidentes, el cumplimiento de la normativa, la mejora de la eficiencia operativa y el fortalecimiento de la cultura de seguridad. Al tener un desglose claro de la tarea, se disminuye la improvisación, se evitan interrupciones por incidentes y se reducen costes asociados a lesiones, sanciones o paradas de producción.

El procedimiento típico para realizar un AST en el entorno de trabajo incluye: definir con precisión la tarea y su contexto (entorno, equipos, materiales), dividirla en etapas, identificar peligros y riesgos en cada etapa (caídas, exposición a químicos, atrapamientos, fallos en equipos), establecer medidas de control específicas, comunicar y formar a los trabajadores involucrados, y realizar una supervisión y seguimiento continuos para ajustar el análisis si cambian las condiciones.

Para que este análisis sea realmente efectivo conviene apoyarse en matrices de riesgo, listas de verificación y, cada vez más, herramientas digitales que facilitan la documentación, el seguimiento y la trazabilidad de las medidas adoptadas. Empresas de consultoría como GMS Consulting integran estos AST dentro de sistemas de gestión como ISO 45001, ayudando a las organizaciones a superar auditorías internas y externas y a mantener un ciclo de mejora continua en seguridad y salud laboral.

Application Security Testing (AST): SAST, DAST, IAST, MAST y más

En el ámbito de la ciberseguridad, AST se refiere habitualmente a Application Security Testing, es decir, al conjunto de técnicas y herramientas orientadas a detectar vulnerabilidades en aplicaciones modernas, ajustándose a metodologías ágiles y a la complejidad creciente del software.

Las soluciones de AST son un pilar de cualquier programa de AppSec sólido, porque las revisiones manuales de código y los planes de prueba tradicionales son lentos y no escalan bien frente a la aparición constante de nuevas vulnerabilidades. Además, múltiples normativas y marcos regulatorios (como PCI-DSS, entre otros) exigen explícitamente el uso de herramientas de este tipo.

Dentro de Application Security Testing hoy podemos distinguir varias categorías principales: el análisis estático (SAST), el análisis dinámico (DAST), las técnicas interactivas e híbridas (IAST), las pruebas específicas para aplicaciones móviles (MAST) y otros servicios complementarios como SCA, RASP, descubrimiento de aplicaciones, pruebas como servicio o herramientas de correlación y cobertura.

La tecnología Static AST o SAST analiza el código en reposo (código fuente, bytecode o binario) durante las fases de programación y prueba del ciclo de vida del software. Se considera una prueba “de caja blanca”, ya que el analista tiene acceso al código y al diseño de la aplicación. Estas herramientas buscan debilidades como errores numéricos, problemas de validación de entrada, condiciones de carrera, referencias no seguras, desbordamientos, etc.

Por su parte, la tecnología Dynamic AST o DAST se enfoca en la aplicación en ejecución, normalmente en entornos de prueba o producción controlada. Desde el exterior, se lanzan ataques simulados para descubrir problemas como inyecciones, fallos de autenticación, gestión deficiente de sesiones, errores en las interfaces o en el manejo de respuestas. Es una aproximación “de caja negra”, donde no se presume conocimiento del código interno.

Las tecnologías IAST combinan lo mejor de SAST y DAST. Se instrumenta la aplicación (por ejemplo, con un agente en la JVM o en .NET CLR) para observar desde dentro cómo se comporta mientras se lanzan pruebas dinámicas. Esto permite correlacionar flujos de datos y de ejecución, entender si una vulnerabilidad teórica es realmente explotable y reducir falsos positivos al validar los hallazgos sobre la marcha.

MAST, o Mobile Application Security Testing, aplica una mezcla de análisis estático, dinámico y forense específico para aplicaciones iOS y Android, incluyendo sus componentes de backend. Estas soluciones prestan especial atención a escenarios como dispositivos rooteados o desbloqueados, redes Wi‑Fi falsas, gestión incorrecta de certificados, filtrado de datos sensibles y otras particularidades del entorno móvil.

Servicios añadidos: SCA, RASP, descubrimiento, bases de datos y orquestación ASTO

Muchos proveedores de AST han ampliado su oferta con servicios complementarios clave para cubrir el ecosistema completo de seguridad de aplicaciones y la gestión de riesgos de ciberseguridad, desde la composición del software hasta la base de datos y la orquestación de todas las herramientas.

El Análisis de Composición de Software (SCA) se centra en identificar componentes de terceros y de código abierto incluidos en una aplicación, y cotejarlos con bases de datos de vulnerabilidades conocidas como la NVD del NIST, CVE y repositorios comerciales como VulnDB. Estas herramientas permiten detectar versiones obsoletas o con parches de seguridad pendientes, pero no suelen identificar vulnerabilidades en código propio.

RASP (Runtime Application Self-Protection) lleva la instrumentación un paso más allá, usando técnicas similares a IAST para monitorizar la aplicación en ejecución y bloquear ataques en tiempo real, compitiendo en cierto modo con los WAF tradicionales. Muchos equipos comienzan activando la instrumentación solo para diagnóstico (modo IAST) y, cuando confían en los resultados, pasan a modo RASP con bloqueo efectivo de ataques.

También es relevante la capacidad de descubrimiento de aplicaciones, que analiza el ecosistema web de una organización y localiza todos los sitios y servicios expuestos, incluyendo aquellos que han quedado olvidados pero siguen siendo una puerta de entrada potencial.

En el ámbito de la capa de datos, las herramientas de análisis de seguridad de bases de datos revisan versiones, parches, configuraciones, contraseñas, políticas de acceso y otros puntos débiles, tanto sobre datos en reposo como, en algunos productos, sobre datos en tránsito. Esto es crucial porque muchas vulnerabilidades explotables se deben a un mal gobierno de la base de datos, más que a fallos en el código de la aplicación.

El modelo ASTaaS (Application Security Testing as a Service) externaliza parte o todo el proceso de pruebas de seguridad a un proveedor especializado, que combina análisis estático y dinámico, pentesting, evaluación de APIs y análisis de riesgos. Es especialmente atractivo en entornos cloud, donde levantar y escalar entornos de test resulta más sencillo.

Para lidiar con el aluvión de hallazgos procedentes de múltiples herramientas surgen las soluciones de correlación de resultados y los analizadores de cobertura. Las primeras unifican y priorizan vulnerabilidades detectadas por distintas soluciones SAST, DAST, IAST, MAST, etc., mientras que las segundas miden qué porcentaje del código o de las ramas lógicas ha sido realmente sometido a pruebas, ayudando a fijar umbrales de calidad aceptables y detectar código inalcanzable.

Finalmente, Application Security Testing Orchestration (ASTO) propone integrar todas estas herramientas de forma coordinada dentro del ciclo de vida de desarrollo (SDLC) y de los pipelines de CI/CD, con una gestión centralizada de políticas, ejecuciones y reporting. Aunque todavía es un campo en evolución, responde a la necesidad de automatizar al máximo las pruebas de seguridad sin frenar el ritmo de entrega.

Análisis estático de código fuente orientado a seguridad: estándares, técnicas y retos

El análisis estático de código fuente con foco en seguridad es una exigencia creciente en organizaciones que quieren alinearse con estándares y buenas prácticas de desarrollo seguro. Modelos como CLASP, OpenSAMM, Touchpoints o Microsoft SDL integran explícitamente esta etapa dentro del ciclo de vida de desarrollo, reforzando la idea de “seguridad desde el diseño”.

Metodologías como OWASP y marcos SDLC seguros proporcionan guías concretas para ejecutar análisis estático, definir criterios de revisión, explotar resultados y mapear hallazgos contra referencias como OWASP Top 10 (XSS, SQL Injection, File Inclusion, etc.). Las herramientas SAST existentes —tanto comerciales como open source— se apoyan fuertemente en teoría de compiladores, AST y análisis de flujos de información para extraer conocimiento útil del código.

Entre las técnicas elementales podemos mencionar grep avanzado (búsqueda de patrones y posibles secretos en texto claro), verificación de indentación y estructura, análisis de flujo de datos para seguir la vida de una variable desde su definición hasta su uso, propagación de constantes para evaluar el impacto de valores inmutables y análisis de alias o punteros para entender referencias indirectas en lenguajes de bajo nivel.

A nivel de clasificación de hallazgos, conviene distinguir entre bugs (desviaciones entre lo que el programador pretendía y lo que hace realmente el software), violaciones de buenas prácticas o de las reglas del lenguaje (código “no ideal”) y vulnerabilidades, entendidas como el subconjunto de problemas con impacto en la seguridad. Una pieza de código puede ser, a la vez, un bug y una violación, y aun así no ser explotable debido a capas de seguridad adicionales.

Un reto importante es que muchas herramientas SAST populares (como PMD, SonarQube o FindBugs) están más enfocadas en calidad de código que en seguridad pura, y su máximo potencial se consigue si se integran desde el inicio del proyecto, algo que no siempre ocurre. En entornos donde se audita código ya existente —a menudo escrito por terceros— estas herramientas pueden quedarse cortas, y se hace necesario construir analizadores propios ajustados a las necesidades del equipo.

El proceso de construcción de un analizador estático suele organizarse como un pipeline: partiendo de las fuentes (código generado, binarios o código máquina no entran en esta categoría), se realiza una internalización que produce un modelo abstracto fiel al código original (generalmente un AST enriquecido), se derivan modelos de entidades y de ejecución, se aplican técnicas de análisis y finalmente se generan informes. La calidad de toda la cadena depende críticamente de la fase de internalización.

Internalización y generación de AST: frontends, gramáticas y ambigüedades

La etapa de internalización persigue traducir el código fuente a una estructura manejable por el analizador, normalmente un AST o un grafo similar. Para ello pueden usarse frontends de compiladores ya existentes (como GCC para C, Mono para .NET o Eclipse JDT para Java), que proporcionan estructuras probadas y eficientes.

Sin embargo, apoyarse en estos frontends tiene inconvenientes. Muchos están pensados para integrarse en un IDE, requieren crear proyectos y configuraciones adicionales, y generan modelos orientados a la interacción con el usuario más que al análisis masivo. Además, suelen operar sobre un código ya preprocesado (por ejemplo, C con macros resueltas), lo que puede introducir discrepancias con el código fuente original al reportar errores.

Cuando estas opciones no son suficientes, toca recurrir a técnicas clásicas de teoría de compiladores: construir gramáticas, definir analizadores sintácticos con herramientas como ANTLR, Bison o Flex, o incluso programar parser combinators o soluciones basadas en PEG. Esto exige un conocimiento profundo de la sintaxis y semántica del lenguaje que se está procesando.

Los problemas habituales en esta fase incluyen ambigüedades sintácticas (expresiones que la gramática puede interpretar de varias formas válidas), ambigüedades dependientes del contexto o la semántica (por ejemplo, distinguir si un fragmento representa una multiplicación o una declaración de puntero) y resolución de referencias (saber en cada uso a qué variable, tipo o miembro se está haciendo referencia realmente).

En lenguajes complejos como C++ o en entornos mixtos —por ejemplo, ASPX con C#, Android con Java/Dalvik— estas ambigüedades se multiplican. Incluso IDEs avanzados muestran errores de coloreado o reconocimiento de símbolos en fragmentos difíciles, lo que ilustra el nivel de dificultad para quienes construyen herramientas de análisis propias.

La conclusión es que no hay soluciones mágicas: hace falta dominar la gramática, la semántica, el modelo de memoria del lenguaje, las reglas de resolución de nombres y tener muy claro el objetivo del análisis, porque es fácil perderse en detalles de implementación que no aportan valor a la auditoría o al caso de uso que se persigue.

Técnicas de análisis avanzado: flujos de información y modelos de ejecución

Una vez que se dispone de modelos internos sólidos (AST, modelos de memoria y de ejecución), entra en juego la fase de análisis propiamente dicha. Aquí destaca el análisis de flujo de datos, que estudia cómo se propaga la información a través de la aplicación desde las fuentes no confiables (inputs del usuario, ficheros, sockets, etc.) hasta los sinks potencialmente peligrosos (consultas SQL, comandos del sistema, renderizado HTML sin escapar, etc.).

El análisis de flujo permite estudiar todas las rutas de ejecución posibles que conectan una entrada con un punto vulnerable, tanto en sentido directo (forward) como hacia atrás (backward), algo esencial para técnicas de taint analysis. Se requiere un conocimiento preciso del modelo de memoria del lenguaje y de los mecanismos implícitos de propagación (paso por valor o referencia, cierres, objetos inmutables, threads, etc.).

También es necesario modelar o incluir el comportamiento de librerías de terceros, ya que una gran parte de la lógica de negocio y de los puntos de entrada/salida reside en ellas. Si no se tienen en cuenta, los análisis pueden generar una gran cantidad de falsos positivos o, peor aún, falsos negativos que pasan desapercibidos.

Un ejemplo ilustrativo es el análisis de una aplicación vulnerable a SQL Injection: el código puede parecer sencillo, pero mediante taint analysis se observa cómo un parámetro controlado por el usuario se propaga a través de varias funciones hasta llegar a la construcción de la consulta, que se ejecuta sin parametrización adecuada. Sin un modelo detallado de flujo y memoria, estas dependencias resultan difíciles de descubrir automáticamente.

Otro caso más complejo implica variables estáticas compartidas, callbacks o eventos, donde el valor que llega a un sink depende de ejecuciones anteriores o de rutas poco evidentes. Aquí el modelo de ejecución —que representa estados, transiciones y contextos— combinado con el AST es lo que permite reconstruir el puzzle y extraer conclusiones fiables sobre la seguridad del código.

Aunque estas técnicas introducen desafíos adicionales, como el análisis entre lenguajes o la evaluación precisa de expresiones en entornos muy dinámicos, aportan una gran calidad al resultado: menos errores de interpretación, procesos más rápidos una vez construida la infraestructura y un marco de trabajo estandarizado que se puede adaptar a distintos proyectos y tecnologías.

Automatización de flujos con RPA en AST (Aragonesa de Servicios Telemáticos)

Más allá del análisis de código, los flujos de trabajo también se optimizan en la Administración Pública mediante tecnologías de robotización de procesos (RPA). Un caso ilustrativo es el de Aragonesa de Servicios Telemáticos (AST), entidad pública que proporciona servicios TIC al Gobierno de Aragón y actúa como operador de telecomunicaciones de la comunidad autónoma.

AST gestiona un amplio catálogo de servicios digitales —gestión documental, firma electrónica, pasarelas de pago, BI, infraestructuras de datos espaciales, alojamiento de aplicaciones, puesto de trabajo, conectividad y servicios de valor añadido— y se encontró con un cuello de botella crítico: el proceso manual de conformación de facturas, que consumía gran cantidad de tiempo y recursos en periodos muy concentrados.

Para abordar este reto se contó con Hiberus, que propuso una solución basada en RPA utilizando UiPath. El enfoque siguió una secuencia ordenada: creación de un Agile Center especializado (consultores RPA, arquitectos, desarrolladores, testers), consultoría de procesos para identificar datos, sistemas y flujos automatizables, elaboración de un documento PDD con la definición funcional y, a partir de ahí, construcción del entorno y desarrollo de la solución.

La automatización incluyó la integración con el Portafirmas corporativo, sistema clave para la firma de facturas, añadiendo incluso un sistema de avisos que la herramienta original no tenía. Se desplegaron entornos de desarrollo y producción, y se ejecutó un plan de pruebas específico apuntando a sistemas de preproducción, lo que permitió a AST validar el robot sin impactar su operación diaria.

Tras la validación se implantó la solución en producción, aprovechando las fortalezas de UiPath: capacidad para automatizar procesos complejos y de alto volumen, bajo requisito de programación, facilidad de escalado horizontal, rapidez de desarrollo, sistema de notificaciones incorporado y posibilidad de detener ejecuciones si se detecta alguna incidencia.

El proyecto se completó con formación detallada para el personal de AST, manuales de usuario confeccionados conjuntamente y sesiones prácticas para asegurar que los responsables pudieran manejar la herramienta con autonomía, ajustar configuraciones y entender los resultados sin depender continuamente del proveedor.

Los resultados cuantitativos fueron muy significativos: en un periodo de dos meses se estimó la conformación de más de 500 facturas, un 60 % más que el año anterior, y el tiempo por factura cayó de 10 minutos a aproximadamente 2, lo que supone una reducción del 80 % en el tiempo medio de gestión. A medio plazo se proyecta un ahorro de cientos de horas de trabajo manual, además de beneficios cualitativos como la eliminación de errores humanos, mayor agilidad para relanzar facturas, aumento de la productividad y mejor alineación con los objetivos de facturación.

Desde el punto de vista estratégico, este piloto de RPA encaja con el plan de AST para introducir procesos de robotización y actuación administrativa automatizada en la Administración aragonesa. Además, ha servido para revisar y aclarar reglas de negocio en el proceso de facturación, mejorar la información compartida entre los implicados y detectar nuevos procesos candidatos a ser automatizados en fases posteriores.

En conjunto, todo este panorama muestra cómo el concepto de AST, en sus distintas acepciones, se sitúa en el centro de la mejora de flujos de trabajo: modelando la lógica de programas mediante árboles de sintaxis abstracta para desarrollo y testing inteligente, examinando la seguridad de aplicaciones con baterías de herramientas especializadas, desgranando tareas laborales para eliminar riesgos, u orquestando robots que se encargan de tareas repetitivas para que las personas puedan concentrarse en actividades de mayor valor.