Presentamos el lenguaje de diseño de agentes (ABL): Porque los agentes de IA empresariales necesitan más que simples indicaciones
¿Cómo Agent Blueprint Language transforma los agentes de IA empresariales?
¿Cómo pueden las empresas gobernar, escalar y llevar agentes de IA a producción de forma segura?
Cada generación de software empresarial ha terminado necesitando su propio lenguaje. El desarrollo web obtuvo HTML. La lógica de las aplicaciones obtuvo Java. Y la IA empresarial adoptó los prompts.
Los prompts se han convertido en el recurso predeterminado para prácticamente todo: definir un agente, establecer su gobernanza o gestionar su escalamiento. Gran parte de la infraestructura actual de IA empresarial se basa en instrucciones proporcionadas a un modelo, confiando en que este las interprete y ejecute correctamente.
Sin embargo, esto no es suficiente. Durante los últimos 24 meses, hemos observado dos desafíos recurrentes en las conversaciones con organizaciones que implementan agentes de IA.
El primero es la gobernanza. Las políticas existen, pero con frecuencia se encuentran en el lugar equivocado: dentro de instrucciones que el modelo puede interpretar erróneamente, omitir o de las que puede desviarse. El Índice de Productividad de Agentes de Kore.ai 2026, basado en una encuesta realizada a más de 400 líderes de TI e ingeniería que utilizan activamente agentes de IA en producción, refleja la magnitud del desafío: el 72 % considera que sus agentes generan riesgos financieros o de cumplimiento no controlados, a pesar de contar con medidas de seguridad implementadas.
El segundo desafío está relacionado con cómo se construyen los agentes de IA. A medida que esta tecnología se democratiza, cada vez más personas pueden crear sus propios agentes. Sin estándares, políticas ni buenas prácticas comunes, el resultado puede convertirse en un ecosistema fragmentado de agentes difícil de auditar para los equipos de cumplimiento y complejo de mantener para los equipos de ingeniería.
La gobernanza que depende de que un modelo interprete correctamente una instrucción no ofrece un control determinista.
Por primera vez en la historia del software, contamos con una tecnología capaz de razonar, planificar y actuar con cierto grado de autonomía. Sin embargo, los métodos tradicionales del ciclo de vida del desarrollo de software (SDLC) no fueron diseñados originalmente para gestionar este tipo de sistemas. Era necesario un enfoque diferente.
Aquí surge Agent Blueprint Language (ABL), un lenguaje declarativo compilado diseñado específicamente para definir agentes de IA empresariales y que constituye una de las bases de Artemis, la plataforma de agentes empresariales nativa de IA de Kore.ai.
ABL no es un framework ni una simple colección de prompts. Es un lenguaje con un proceso de compilación propio, diseñado para aportar estructura, gobernanza y previsibilidad al desarrollo y operación de agentes de IA empresariales.
Con ABL, la gobernanza se incorpora a la arquitectura del agente, se integra en el entorno de ejecución y se aplica independientemente del razonamiento del modelo. El comportamiento del agente se define mediante un artefacto único y versionado, lo que permite detectar determinados problemas antes de llegar a producción, en lugar de descubrirlos durante una interacción real con el cliente.
ALCANZA LA EVOLUCIÓN DIGITAL DE TU EMPRESA,
MÁS ALLÁ DE LAS PLATAFORMAS
¿Por qué cada enfoque para crear agentes de IA tiene un límite?
La mayoría de las empresas ya ha probado al menos uno de estos enfoques y, probablemente, también ha identificado sus principales limitaciones.
Las plataformas basadas en prompts permiten crear agentes con rapidez. Sin embargo, cuando la gobernanza depende de instrucciones proporcionadas al modelo, estas pueden interpretarse incorrectamente, eludirse o comportarse de manera diferente entre versiones. Para sectores regulados, como la banca o los seguros, una medida de seguridad que funciona solo la mayor parte del tiempo no ofrece el nivel de control y previsibilidad que requiere un entorno empresarial.
El desarrollo mediante código personalizado ofrece un alto nivel de flexibilidad, pero obliga a cada equipo a construir gran parte de la infraestructura necesaria desde cero. Según el enfoque planteado, aproximadamente el 80 % del esfuerzo de ingeniería puede destinarse a la infraestructura de la plataforma y solo el 20 % a la lógica de negocio que realmente genera valor. Además, la gobernanza suele incorporarse en etapas posteriores, en lugar de formar parte de la arquitectura desde el inicio.
Las plataformas visuales low-code y no-code facilitan la creación de soluciones, pero pueden presentar limitaciones a medida que aumenta la complejidad de los sistemas de IA. Conforme las organizaciones utilizan cada vez más la propia IA para crear y optimizar agentes, los entornos tradicionales de arrastrar y soltar pueden resultar insuficientes para gestionar arquitecturas más avanzadas.
El desafío consiste en conseguir lo que la IA empresarial realmente necesita: agentes capaces de razonar de forma inteligente y, al mismo tiempo, operar dentro de límites claramente definidos, gobernados y auditables.
El problema fundamental es estructural. En muchos enfoques de IA empresarial, la gobernanza se incorpora como una instrucción dirigida al modelo. En consecuencia, el propio modelo debe interpretar esa instrucción y determinar cómo aplicarla. Este enfoque puede funcionar en una demostración, pero plantea mayores desafíos en producción, donde las políticas de cumplimiento, los controles de acceso y otras restricciones deben mantenerse independientemente del razonamiento que realice el modelo.
El software empresarial abordó un desafío similar al separar la política de la ejecución. Las reglas son aplicadas por el propio sistema, reduciendo la dependencia de interpretaciones. La IA empresarial necesitaba un cambio arquitectónico similar. Ese es el enfoque que propone ABL.
¿Qué es realmente Agent Blueprint Language (ABL)?
Agent Blueprint Language (ABL) no es simplemente un archivo de configuración ni una colección de prompts. Es un artefacto de software compilado diseñado para definir el comportamiento de un agente de IA empresarial, de manera similar a cómo el código de una aplicación determina el funcionamiento de un sistema empresarial.
Escrito en YAML, puede ser leído por ingenieros, arquitectos, responsables de cumplimiento normativo y sistemas de IA. Sin embargo, el formato es solo una parte de su propuesta.
Podemos compararlo con el cambio que React introdujo en el desarrollo web. Antes de su aparición, los desarrolladores debían trabajar directamente con JavaScript o recurrir a herramientas que podían encontrar limitaciones al aumentar la complejidad. React introdujo una abstracción estructurada y predecible para construir interfaces complejas. ABL busca aportar un cambio similar al desarrollo y la gobernanza de agentes de IA empresariales.
Un único archivo ABL puede reunir los principales componentes necesarios para definir un agente:
- Identidad y ejecución: establece qué es el agente, qué puede hacer y cómo debe funcionar.
- Gobernanza: define restricciones y límites que pueden incorporarse al entorno de ejecución, en lugar de depender únicamente de instrucciones proporcionadas al modelo.
- Flujos de trabajo: establece una separación explícita entre los pasos que requieren razonamiento y aquellos que necesitan una ejecución determinista.
- Coordinación multiagente: incorpora mecanismos de delegación, transferencia y escalamiento como capacidades propias del lenguaje, reduciendo la necesidad de desarrollar estas funciones mediante código personalizado.
Todo queda centralizado en un artefacto único y versionado que los equipos de ingeniería, seguridad y cumplimiento pueden leer, revisar y auditar.
De esta manera, la definición del agente que se prueba y aprueba puede mantenerse de forma consistente durante su paso hacia producción, reduciendo desviaciones entre entornos y aportando mayor trazabilidad, gobernanza y previsibilidad al ciclo de vida de los agentes de IA empresariales.
¿Cómo elimina ABL los riesgos antes de llegar a producción?
La mayoría de las plataformas de IA toman la definición de un agente y la ejecutan directamente. Agent Blueprint Language (ABL), en cambio, incorpora primero un proceso de compilación. Esta diferencia permite garantizar que la definición del agente que se prueba, revisa y aprueba sea la misma que posteriormente se ejecuta en producción.
Antes de que se produzca cualquier interacción con un cliente, el compilador valida las referencias a herramientas, los destinos de transferencia y las definiciones de los controles de seguridad. De esta manera, las infracciones de esquema, las referencias inexistentes, las transferencias incorrectas y las incompatibilidades de tipos pueden detectarse antes de la implementación, en lugar de aparecer durante una interacción real con el cliente.
El resultado de este proceso es una Representación Intermedia (IR) inmutable, versionada, compatible con Git y preparada para avanzar de forma controlada a través de los entornos de desarrollo, pruebas, piloto y producción. La misma IR puede ejecutarse en cada uno de estos entornos, reduciendo posibles desviaciones entre lo que se prueba y lo que finalmente llega a producción.
Las conversaciones que ya están en curso también permanecen protegidas. Cuando se implementa una versión actualizada del agente, las sesiones existentes continúan utilizando la versión original con la que comenzaron hasta finalizar, mientras que las nuevas conversaciones utilizan la versión actualizada. De esta manera, los usuarios no experimentan cambios inesperados en el comportamiento del agente durante una interacción activa.
Además, el artefacto compilado puede integrarse con los procesos existentes de CI/CD y revisarse mediante solicitudes de extracción (Pull Requests), al igual que cualquier otro cambio de software. Cada modificación en las medidas de seguridad genera una diferencia visible y auditable, mientras que los agentes que no cumplen con las validaciones definidas pueden ser detenidos por el compilador antes de avanzar hacia los siguientes entornos.
¿Cómo aplica ABL la gobernanza de la IA empresarial en el entorno de ejecución?
En ABL, las restricciones y las medidas de seguridad se incorporan al artefacto de tiempo de ejecución y se aplican fuera de la capa de razonamiento del modelo. Esto reduce la dependencia de instrucciones que el modelo pueda interpretar incorrectamente y permite que determinadas restricciones se ejecuten de manera estructural.
Aunque esta diferencia pueda parecer sutil, transforma el modelo de confianza y gobernanza de los agentes de IA.
En los sistemas donde las políticas dependen principalmente de prompts o instrucciones, la gobernanza está condicionada a que el modelo interprete y aplique correctamente esas indicaciones. Con ABL, las políticas pueden existir y ejecutarse independientemente del razonamiento del modelo.
De esta forma, es el propio entorno de ejecución el que aplica las restricciones definidas, permitiendo que los agentes mantengan capacidades de razonamiento mientras operan dentro de límites empresariales, de seguridad y de cumplimiento previamente establecidos.
Cuando se activa una restricción, el entorno de ejecución bloquea automáticamente la acción y genera un evento de seguimiento con marca de tiempo vinculado a la política específica que se ha activado. Este evento forma parte directa de cada interacción y proporciona evidencia estructurada de lo ocurrido, en lugar de depender únicamente de registros que deban consultarse de forma retroactiva.
“La pregunta que se hacen todas las empresas es cómo llevar la IA de la fase piloto a la producción sin generar riesgos de cumplimiento normativo. Lo que destacó de Kore.ai es que la gobernanza es arquitectónica, no un añadido posterior. Eso es lo que se necesita para obtener la aprobación de la IA para el trabajo que realmente importa”.
— Arunkumar Ramakrishnan, Director de Tecnología Empresarial, Blue Cross Blue Shield of Massachusetts.
¿Cómo combina ABL el razonamiento autónomo con el control determinista?
Una de las ideas más extendidas sobre la IA empresarial es que las organizaciones deben elegir entre dos enfoques: permitir que los agentes razonen con libertad, aceptando cierto grado de imprevisibilidad, o restringir su comportamiento mediante reglas estrictas, reduciendo parte de la flexibilidad que hace valiosa a la inteligencia artificial.
ABL fue diseñado para superar esta disyuntiva, permitiendo combinar razonamiento autónomo y control determinista dentro de una misma definición de agente.
Este enfoque es posible gracias a la denominada arquitectura de doble cerebro de Artemis. Un componente se encarga del razonamiento, mientras que otro aplica las reglas y restricciones definidas. ABL proporciona las estructuras necesarias para establecer con precisión cuándo debe intervenir cada uno dentro del flujo de ejecución de un agente.
La estructura FLOW permite definir rutas de ejecución paso a paso, indicando explícitamente cuáles requieren razonamiento y cuáles deben seguir una lógica determinista. De esta manera, un mismo agente puede razonar de forma conversacional en una etapa y aplicar una regla de negocio compilada en la siguiente, todo dentro de una única definición.
Por su parte, la estructura GATHER gestiona aquellos momentos en los que es necesario recopilar información con precisión, como números de cuenta, identificadores de pólizas o importes de transacciones. Los campos pueden validarse antes de que el flujo de trabajo continúe, evitando que la integridad de estos datos dependa exclusivamente de la interpretación del modelo.
Así, el límite entre “permitir que la IA razone” y “ejecutar una regla de forma determinista” queda definido explícitamente en la arquitectura del agente, en lugar de ser inferido por el modelo durante la ejecución. ABL permite establecer y mantener esa separación de manera estructurada.
“Planos predefinidos, gobernanza en una capa determinista independiente y un lenguaje único para cada agente son las opciones de diseño que le faltaban a la IA empresarial”.
— Keyur Parikh, Director de Estrategias y Servicios de Tecnología para el Entorno Laboral, Vanguard.
¿Cómo convierte ABL la orquestación multiagente en una capacidad integrada?
Los flujos de trabajo empresariales reales suelen requerir la participación coordinada de múltiples agentes. Por ejemplo, un proceso de clasificación de reclamaciones puede necesitar la intervención de un especialista; una verificación de fraude puede requerir procesamiento paralelo; y una transacción de alto valor puede necesitar una revisión humana antes de ejecutarse.
En muchos frameworks, esta coordinación debe diseñarse específicamente para cada proyecto, lo que puede generar arquitecturas diferentes y dificultar la aplicación de una gobernanza uniforme. En Agent Blueprint Language (ABL), cuatro primitivas de orquestación forman parte del propio lenguaje:
DELEGATE: asigna una subtarea a un agente especializado y devuelve el resultado al proceso principal, que mantiene el control de la conversación.
HANDOFF: transfiere la conversación completa a otro agente, preservando el contexto e incorporando mecanismos de detección de ciclos.
FAN-OUT: distribuye tareas entre varios agentes de forma simultánea, reduciendo la ejecución secuencial y optimizando el consumo de tokens en flujos de trabajo multiagente complejos.
ESCALATE: establece una política compilada y determinista que deriva la interacción a una persona cuando se cumplen determinadas condiciones. Al formar parte de las reglas de ejecución, el escalamiento no depende únicamente de que el modelo decida aplicarlo.
Estas capacidades forman parte de la arquitectura de ABL y pueden reutilizarse de manera consistente entre implementaciones, evitando tener que reconstruir los mismos patrones de orquestación para cada proyecto.
¿Cómo hace ABL que las decisiones de los agentes de IA sean rastreables y auditables?
Implementar agentes de IA empresariales sin mecanismos sistemáticos de evaluación puede introducir riesgos difíciles de detectar antes de llegar a producción. ABL busca sustituir esa incertidumbre por un modelo basado en pruebas, trazabilidad y evidencia operativa.
Su marco de evaluación utiliza una matriz de Persona × Escenario × Evaluador, que permite validar el comportamiento del agente frente a una línea base previamente establecida. La detección de regresiones puede identificar degradaciones específicas, señalando el evaluador, la persona, el escenario y la diferencia de puntuación correspondiente. Además, su integración con procesos de CI/CD permite impedir automáticamente un despliegue cuando se detectan regresiones que incumplen los criterios definidos.
Spatial Trace Intelligence, una funcionalidad de Kore.ai, crea representaciones vectoriales de las diferentes rutas de ejecución y genera puntuaciones de confianza entre versiones. De esta manera, preguntas como “¿se comportará igual el agente después de una actualización?” pueden evaluarse mediante datos comparables entre versiones.
El entorno de ejecución puede capturar más de 200 eventos de rastreo por sesión, incluyendo:
- Rastros de razonamiento: registran las llamadas a los LLM y los resultados obtenidos mediante herramientas.
- Registros de decisiones: documentan las verificaciones de restricciones y la evaluación de las medidas de seguridad.
- Registros de auditoría de contexto: permiten conocer qué información estaba utilizando cada componente del sistema en los diferentes puntos de decisión.
Este nivel de observabilidad permite reconstruir con mayor precisión cómo y por qué se produjo una determinada decisión, facilitando los procesos de auditoría, cumplimiento y análisis operativo.
¿Cuáles son las tres formas de crear y compilar agentes con ABL?
ABL está diseñado para permitir que diferentes perfiles puedan trabajar con el lenguaje sin modificar el resultado final. Existen tres rutas principales, y todas conducen a un artefacto ABL compilado, versionado y gobernado.
Arch AI, el arquitecto de IA de Kore.ai: permite que un analista de negocio describa en lenguaje natural lo que necesita que haga el agente. Arch AI genera la definición, selecciona los patrones de orquestación adecuados y determina qué procesos deben ejecutarse de forma determinista y cuáles requieren razonamiento. De esta manera, es posible generar la arquitectura sin necesidad de escribir directamente la sintaxis de ABL.
Studio IDE: ofrece un entorno de desarrollo diseñado para equipos de ingeniería que prefieren trabajar directamente con código. Incluye resaltado de sintaxis, autocompletado y validación durante el proceso de compilación, permitiendo detectar posibles errores antes de avanzar en el ciclo de desarrollo.
Asistentes de codificación externos: los equipos que trabajan con entornos de desarrollo asistidos por IA pueden generar ABL mediante herramientas como Claude Code, Cursor y Codex a través de integraciones compatibles con MCP. Independientemente del origen del código, se mantienen las mismas reglas de compilación y gobernanza.
El método utilizado para construir el agente puede variar, pero el objetivo es el mismo: obtener un artefacto compilado, versionado y controlado que mantenga un comportamiento consistente a medida que avanza entre los diferentes entornos.
¿Qué resultados puede ofrecer ABL en implementaciones empresariales de IA?
Mientras muchas plataformas de IA se concentran principalmente en optimizar el rendimiento del modelo, ABL busca optimizar el rendimiento integral del sistema. Esta diferencia puede reflejarse en el consumo de tokens, los costes asociados a los LLM, la infraestructura necesaria, la latencia y la confiabilidad operativa.
Dos decisiones arquitectónicas son especialmente relevantes.
En primer lugar, la Representación Intermedia (IR) compilada busca reducir la sobrecarga asociada a las arquitecturas tradicionales. Al disponer de un artefacto previamente compilado, se reduce la necesidad de interpretar o reconstruir determinadas estructuras durante cada implementación.
En segundo lugar, el enrutamiento de modelos por operación permite utilizar diferentes modelos según las necesidades de cada etapa del flujo de trabajo. Las tareas sencillas pueden ejecutarse mediante modelos más rápidos y económicos, mientras que los procesos que requieren razonamiento avanzado pueden asignarse a modelos con mayores capacidades. Arch AI puede ayudar a determinar qué tipo de modelo resulta apropiado para cada operación.
En arquitecturas multiagente, FAN-OUT permite enviar solicitudes a varios agentes simultáneamente, en lugar de procesarlas de manera estrictamente secuencial. Este enfoque busca reducir la latencia acumulada y optimizar el consumo de recursos en flujos de trabajo complejos.
Entre los resultados reportados para las primeras implementaciones empresariales se encuentran:
- Entre un 40% y un 80% de reducción en el consumo de tokens en implementaciones multiagente complejas mediante la ejecución paralela asociada a FAN-OUT.
- Entre un 40% y un 65% de reducción en el gasto asociado a LLM, mediante el enrutamiento de modelos por operación y la selección de modelos según la complejidad de cada tarea.
- Una reducción del 80% o más en la huella de infraestructura, en comparación con determinadas arquitecturas convencionales, mediante el uso de la IR compilada de ABL.
- Hasta un 60% de reducción de la latencia y un 80% de reducción de costes en determinadas operaciones, cuando modelos más rápidos pueden sustituir a modelos de razonamiento más complejos sin comprometer la calidad requerida.
- Continuidad de las sesiones durante nuevas implementaciones: las conversaciones que ya están en curso permanecen vinculadas a la versión compilada con la que comenzaron, mientras que las nuevas sesiones utilizan la versión actualizada.
Estos resultados corresponden a implementaciones empresariales reportadas con ABL y muestran cómo una arquitectura basada en compilación, orquestación multiagente, selección inteligente de modelos y gobernanza integrada puede generar mejoras medibles en eficiencia y operación.
¿Por qué ABL puede convertirse en una base para escalar la IA empresarial?
Durante demasiado tiempo, la IA empresarial se ha construido a partir de componentes y enfoques fragmentados. Agent Blueprint Language (ABL) propone una base estructurada para abordar algunos de los desafíos que aparecen cuando los agentes de IA pasan de la experimentación a implementaciones empresariales a gran escala.
Los enfoques anteriores presentan un desafío estructural recurrente: cuando la gobernanza depende de instrucciones que el propio modelo debe interpretar, su aplicación puede quedar condicionada por el comportamiento de ese modelo. Al mismo tiempo, la orquestación suele reconstruirse de manera diferente para cada proyecto, aumentando la complejidad a medida que crece el ecosistema de agentes.
ABL cambia este punto de partida mediante restricciones compiladas que operan independientemente del razonamiento del modelo, primitivas de orquestación integradas en el lenguaje y una definición unificada que describe qué es un agente, qué puede hacer y bajo qué límites debe operar.
La pregunta para las organizaciones ya no es únicamente si su arquitectura actual funciona para los casos de uso que han desarrollado hasta ahora, sino si está preparada para lo que viene: flujos de trabajo regulados, mayores exigencias de cumplimiento y ecosistemas donde múltiples agentes deberán operar de forma coordinada, segura y auditable.
Cada generación de software termina desarrollando las abstracciones necesarias para poder escalar. La IA empresarial se aproxima a un punto de inflexión similar.
Agent Blueprint Language parte de la idea de que los agentes de IA deben definirse, gobernarse y operarse como sistemas de software, en lugar de funcionar únicamente como conjuntos de prompts o instrucciones. A medida que las organizaciones avanzan desde la experimentación hacia la producción, esta distinción puede adquirir una importancia creciente para garantizar la gobernanza, trazabilidad, seguridad y escalabilidad de sus ecosistemas de IA.
ABL surge, precisamente, como una propuesta para proporcionar una base más estructurada sobre la cual construir esta nueva generación de agentes de IA empresariales.
Preguntas frecuentes sobre Agent Blueprint Language (ABL)
¿Los ingenieros necesitan aprender la sintaxis de ABL para utilizarlo?
No necesariamente. Existen tres formas principales de trabajar y compilar con ABL, y solo una requiere escribir directamente su sintaxis.
Arch AI puede generar definiciones ABL completas y validadas a partir de descripciones del caso de uso realizadas en lenguaje natural. Studio IDE proporciona un entorno de desarrollo con resaltado de sintaxis, autocompletado y herramientas orientadas a los ingenieros que prefieren trabajar directamente con el lenguaje.
Además, asistentes de codificación como Claude Code, Cursor y Codex pueden utilizarse para generar ABL mediante integraciones compatibles con MCP.
Independientemente del método utilizado, el objetivo es producir el mismo tipo de artefacto compilado, versionado y gobernado, permitiendo que distintos perfiles participen en la construcción de agentes sin depender necesariamente del conocimiento directo de la sintaxis de ABL.
¿En qué se diferencia ABL de crear agentes con Python o LangChain?
Es posible desarrollar agentes de IA utilizando Python y diferentes frameworks, y muchas organizaciones ya trabajan de esta manera. El desafío aparece cuando cada equipo implementa sus agentes con arquitecturas diferentes, incorpora la gobernanza posteriormente y utiliza mecanismos distintos para validar, versionar y auditar su comportamiento.
ABL no pretende sustituir a Python como lenguaje de programación general. Su propósito es proporcionar una abstracción especializada para definir, gobernar y operar agentes de IA a escala empresarial.
La comparación puede entenderse de forma similar a la relación entre React y JavaScript: React no sustituyó a JavaScript, sino que introdujo una estructura específica para facilitar la creación, mantenimiento y escalabilidad de interfaces complejas. ABL busca desempeñar un papel comparable en la arquitectura de agentes de IA empresariales.
¿Qué ocurre cuando un agente infringe una medida de seguridad o una restricción?
Cuando se activa una restricción definida en ABL, el entorno de ejecución puede bloquear la acción y generar un evento de seguimiento estructurado.
Este evento incorpora una marca de tiempo y queda vinculado a la política específica que provocó su activación, proporcionando información disponible para los procesos de seguimiento y auditoría.
De esta manera, la aplicación de determinadas políticas no depende exclusivamente de revisar posteriormente archivos de registro. Los equipos de cumplimiento pueden disponer de evidencia estructurada sobre qué restricción se activó, cuándo ocurrió y qué acción fue bloqueada, mejorando la trazabilidad de las decisiones tomadas durante cada interacción.
¿Puede ABL funcionar con los modelos y la infraestructura de IA existentes?
Sí. ABL está diseñado para funcionar de manera independiente del modelo y de la infraestructura utilizada.
Según las capacidades descritas para la plataforma, esta admite 178 modelos de IA de 15 proveedores, incluyendo modelos de OpenAI, Anthropic, NVIDIA, Cohere y la familia Llama, con posibilidades de seleccionar diferentes modelos según el agente o la operación que se necesite ejecutar.
Las opciones de implementación incluyen entornos SaaS sobre AWS, Azure o Google Cloud Platform (GCP), infraestructuras de nube privada dentro de una VPC y despliegues mediante Kubernetes para organizaciones con mayores requisitos de soberanía, seguridad o regulación.
Los agentes también pueden conectarse con sistemas empresariales existentes mediante tecnologías y protocolos como HTTP, MCP, AWS Lambda, A2A, especificaciones OpenAPI y webhooks, facilitando su integración con diferentes arquitecturas tecnológicas.
¿Cómo se integra ABL con los procesos de CI/CD y DevOps?
El artefacto ABL compilado puede almacenarse y gestionarse mediante Git, permitiendo mantener un control de versiones y promover los cambios de manera estructurada entre los entornos de desarrollo, pruebas, piloto y producción mediante pipelines de CI/CD.
Las modificaciones pueden revisarse mediante solicitudes de extracción (Pull Requests), de forma similar a otros cambios realizados sobre código.
Además, los cambios en las políticas y medidas de control pueden generar diferencias visibles y auditables entre versiones. La integración con CI/CD también permite establecer controles que bloqueen automáticamente un despliegue cuando las evaluaciones detecten regresiones o incumplimientos de los criterios de calidad previamente establecidos.
Esto permite incorporar el ciclo de vida de los agentes de IA dentro de prácticas de DevOps y gobierno de software ya conocidas por los equipos empresariales.
¿Cómo pueden los equipos de cumplimiento trabajar con ABL?
Una de las características de ABL es que las restricciones, los límites de seguridad y las condiciones de escalamiento pueden declararse explícitamente dentro de una definición estructurada en YAML.
Esto permite que los responsables de cumplimiento, seguridad y gobernanza puedan revisar de manera más clara las reglas bajo las cuales debe operar un agente, sin depender exclusivamente de instrucciones ocultas dentro de prompts o de lógica distribuida en diferentes componentes de código.
Durante la ejecución, las decisiones relacionadas con políticas pueden generar eventos de seguimiento estructurados y con marcas de tiempo, proporcionando un registro que permita reconstruir lo ocurrido durante una interacción.
De esta manera, los equipos de cumplimiento pueden disponer de dos elementos fundamentales: una definición explícita de cómo debería comportarse el agente y una trazabilidad operativa de cómo se comportó realmente, facilitando los procesos de auditoría y gobernanza de la IA empresarial.
