Manifiesto
Construir sistemas agénticos con método, gobierno y claridad.
El manifiesto ADLC (Agentic Development Lifecycle) define principios comunes para diseñar sistemas agénticos gobernados, agnósticos a las herramientas y guiados por un ciclo de vida explícito.
Manifiesto ADLC
El ADLC no sustituye al SDLC: conserva sus prácticas de ingeniería y las amplía para gobernar el software desarrollado con agentes y los sistemas agénticos en producción.
El ADLC se aplica tanto al software desarrollado con ayuda de agentes como a los sistemas que emplean agentes en producción.
En el primer caso, gobierna los cambios generados, la verificación frente a los requisitos y la responsabilidad humana en la aceptación. En el segundo, extiende estos controles al comportamiento en ejecución, al conocimiento, a las herramientas y a la autonomía de los agentes.
No equivale a programación autónoma ni únicamente a la seguridad del código generado por AI: exige evidencias verificables y responsabilidades explícitas durante todo el ciclo de vida.
El código fuente del Manifiesto ADLC, la licencia, las guías de contribución y los archivos del sitio están disponibles en el repositorio público.
Principios
Cada iniciativa parte de requisitos verificados, comprensibles y lo bastante maduros como para reducir ambigüedad y retrabajo.
Los componentes, agentes y capacidades deben diseñarse para ser reutilizados, conectados y orquestados a lo largo del tiempo.
Las herramientas ayudan, pero no deben dictar la arquitectura: el proceso y la gobernanza van antes que la herramienta.
No todos los problemas requieren un agente, ni más agentes producen necesariamente mejores resultados. Elegir la solución menos compleja que cumpla los requisitos aprobados, concediendo solo la autonomía necesaria. Justificar la complejidad adicional con beneficios medibles frente a una solución más simple.
Permisos, aprobaciones, presupuestos y controles de parada se aplican en runtime, no solo se describen en prompts.
Controles de gobernanza
La supervisión humana es una capa de control obligatoria en el ADLC, especialmente al aprobar requisitos, validar calidad, autorizar releases y gobernar el comportamiento en producción.
Los agentes aceleran y estructuran el trabajo, pero las decisiones críticas y responsables siguen siendo humanas.
Supervisión competente, no aprobación rutinaria.
Quienes aprueban deben recibir formación sobre el dominio, los límites de los agentes y los riesgos de las decisiones, con ejercicios sobre errores e incidentes proporcionales al riesgo. Necesitan acceso a evidencias, fuentes, incertidumbres y consecuencias de las acciones, además de tiempo suficiente y una carga de trabajo sostenible para evaluarlas.
Deben tener autoridad para cuestionar, rechazar, suspender, solicitar una revisión y escalar. Una aprobación formal sin verificación sustancial no constituye un control de gobernanza.
Ninguna implementación comienza sin superar el control de calidad de requisitos. El gate aprueba el siguiente incremento, no todos los requisitos futuros. Un agente puede ayudar a prepararlo; las personas responsables aprueban alcance, resultados medibles, riesgos e incertidumbres conocidas.
Este gate es fundamental porque determina si la implementación debe empezar o no.
El ADLC trata el conocimiento y el contexto como partes gobernadas del sistema. Documentos, prompts, skills compartidas, memoria, políticas, ejemplos, instrucciones de herramientas e información recuperada mediante RAG, cuando se utilice, pueden influir en el comportamiento del agente e introducir regresiones silenciosas incluso cuando el código de aplicación no cambia.
La gobernanza del conocimiento se aplica independientemente de cómo se proporcione el contexto. La generación aumentada por recuperación (RAG) es una técnica, no una arquitectura obligatoria ni un sinónimo de gobernanza del conocimiento. Cuando se utilice, requiere controles específicos de calidad del retrieval, actualización de fuentes, permisos de acceso y citas.
Por lo tanto, los cambios de conocimiento deben revisarse, versionarse, ser trazables y validarse frente al comportamiento esperado antes de usarse en producción.
El contexto runtime y la memoria requieren procedencia, permisos de escritura, retención, aislamiento entre usuarios y tenants, eliminación y gestión de contradicciones. El contenido recuperado no otorga autoridad. La compresión debe preservar permisos, restricciones y evidencia decisiva.
Contexto empresarial distribuido, acceso gobernado. Los agentes deben poder descubrir y utilizar información pertinente mediante interfaces interoperables, como API, MCP o mecanismos equivalentes. Las fuentes conservan responsables, versiones, procedencia y permisos de acceso. El contexto debe seleccionarse para la tarea y debe evaluarse su contribución a la calidad de los resultados.
FAIR · W3C DCAT 3 · W3C PROV-DM. Estas referencias respaldan descubribilidad, interoperabilidad y procedencia; no garantizan por sí solas mejores resultados de los agentes.
Definir responsable, acciones y datos permitidos, autoridad delegada, presupuestos, condiciones de parada y escalado. Aplicar permisos y aprobaciones fuera del prompt, con credenciales revocables y un mecanismo de parada probado.
Usar datasets representativos y versionados, ensayos repetidos, estado aislado y umbrales basados en el riesgo. Verificar resultados reales y cumplimiento de políticas; calibrar evaluadores basados en modelos con juicio humano y declarar incertidumbres y lagunas de cobertura.
Medir coste por tarea exitosa, latencia, intervención humana, retrabajo, escalado y valor de negocio frente a una referencia. La evidencia puede justificar reducir la autonomía o retirar el sistema.
Etapa 0
Ninguna implementación comienza sin superar el control de calidad de requisitos. El gate aprueba el siguiente incremento, no todos los requisitos futuros. Un agente puede ayudar a prepararlo; las personas responsables aprueban alcance, resultados medibles, riesgos e incertidumbres conocidas.
Usar el mínimo nivel de autonomía y complejidad necesario para lograr el resultado validado. Comparar automatización determinista, workflow LLM, agente único y orquestación multiagente frente a una referencia de negocio medible.
Los experimentos también requieren hipótesis aprobada, sandbox, datos permitidos, presupuesto y criterios de salida antes de la implementación.
La presencia humana es necesaria aquí para confirmar alcance, intención, significado de negocio y aprobación antes de iniciar el lifecycle.
Ciclo de vida ADLC
Ninguna implementación comienza sin superar el control de calidad de requisitos. El gate aprueba el siguiente incremento, no todos los requisitos futuros. Un agente puede ayudar a prepararlo; las personas responsables aprueban alcance, resultados medibles, riesgos e incertidumbres conocidas.
Human in the loop: aprobación obligatoria de la calidad y la intención de los requisitos.
Transformar los requisitos aprobados en capacidades concretas, servicios, prompts, flujos, integraciones y componentes reutilizables. Es la fase en la que la intención se convierte en una solución real, estructurada para poder ser revisada, probada, gobernada y evolucionada en el tiempo sin perder coherencia arquitectónica.
Implementar el contrato de autonomía con acceso de mínimo privilegio, políticas aplicadas en runtime, presupuestos y controles de parada. Las personas siguen diseñando e implementando, además de revisar.
Revisar la solución en términos de calidad, consistencia, seguridad, mantenibilidad y alineación con los principios del manifiesto antes de avanzar hacia la validación.
Human in the loop: revisión experta, juicio de riesgo y decisión de avanzar.
Revisar autoridad delegada, límites de confianza, gestión de memoria, calidad de evaluaciones y planes de recuperación, incluidos efectos irreversibles.
Validar comportamiento esperado, casos límite, modos de fallo, fiabilidad y readiness operativa mediante evidencia de pruebas estructurada y criterios de aceptación medibles.
Las pruebas también cubren la regresión de comportamiento causada por cambios en prompts, contenido RAG, shared skills, configuración del modelo, herramientas y reglas de orquestación.
Usar datasets representativos y versionados, ensayos repetidos, estado aislado y umbrales basados en el riesgo. Verificar resultados reales y cumplimiento de políticas; calibrar evaluadores basados en modelos con juicio humano y declarar incertidumbres y lagunas de cobertura.
La validación del software producido por agentes requiere supervisión humana competente. Las personas responsables aprueban los criterios de aceptación, revisan la adecuación de las pruebas y evalúan evidencias y riesgo residual para autorizar la release. Los agentes pueden generar y ejecutar pruebas, pero no aprobar su propio trabajo ni debilitar unilateralmente sus condiciones de aceptación. Un segundo agente no sustituye la responsabilidad humana; la profundidad de la revisión es proporcional al riesgo, sin exigir ejecutar manualmente cada prueba.
Liberar de forma controlada, observable y repetible, con opciones de rollback, release notes, ownership y evidencias de despliegue claramente definidas.
La evidencia de release debe identificar cambios de código, cambios de prompts, cambios de RAG o documentación, cambios de herramientas, cambios de configuración del modelo y cambios de orquestación.
Human in the loop: autorización de release y responsabilidad sobre el go-live.
Distinguir rollback de configuración, restauración del estado y compensación de efectos externos. Las acciones irreversibles requieren controles preventivos y aprobación explícita: un rollback no puede deshacer cada acción.
Operar la solución con monitorización, alertas, runbooks, flujos de soporte y checkpoints de gobernanza que mantengan el sistema fiable en condiciones reales.
Las operaciones deben monitorizar no solo la salud técnica, sino también drift de comportamiento, respuestas inesperadas, uso de conocimiento desactualizado, fallos de recuperación y regresiones introducidas por actualizaciones de conocimiento.
Human in the loop: gestión de incidentes, escalación y supervisión de gobernanza en producción.
Limitar reintentos y evitar efectos duplicados. Probar operación degradada, escalado, parada y revocación. Medir coste por tarea exitosa, latencia, intervención humana, retrabajo, escalado y valor de negocio frente a una referencia. La evidencia puede justificar reducir la autonomía o retirar el sistema.
Mejorar continuamente a partir del feedback de producción, incidentes, analítica, aprendizaje del usuario y experiencia de delivery que revelan qué refinar después.
Usar evidencia de producción para reducir autonomía o retirar sistemas con valor o fiabilidad insuficientes. Revocar credenciales, endpoints y tareas programadas; conservar o eliminar memoria según políticas aprobadas.
Coordinar agentes, flujos, políticas y capacidades reutilizables en un ecosistema componible que escala más allá de implementaciones aisladas.
Propagar identidad, límites de permisos, presupuestos, estado de aprobaciones y trazabilidad durante la delegación. Gobernar estado compartido y memoria sin ampliar implícitamente la autoridad.
ADLC Operating Model
Requisitos validados, intención de negocio explícita, ownership asignado y quality gate superado antes de iniciar cualquier build.
Usar esta checklist para validar evidencias, no para repetir actividades del ciclo de vida. Asignar responsables humanos identificados; la profundidad de revisión depende del riesgo y la ejecución puede automatizarse. Los controles obligatorios fallidos bloquean el avance. Operación y orquestación requieren controles continuos, no un único gate de salida.
Baseline de implementación
Los principios se vuelven operativos solo cuando se implementan como controles repetibles, verificaciones medibles y evidencia revisable.
Requirements quality gate superado, criterios de aceptación medibles y responsables de negocio, técnicos y de riesgo identificados.
Código, prompts, conocimiento, fuentes RAG, shared skills, configuración del modelo, descripciones de herramientas y reglas de orquestación son inputs controlados y versionados.
Pruebas, evaluaciones, controles de políticas y aprobaciones obligatorias se ejecutan en las pipelines y bloquean la promoción cuando falla un control requerido.
Datasets de evaluación versionados cubren comportamiento esperado, edge cases, acciones inseguras, calidad del retrieval, escalado y regresiones.
Cada release incluye evidencia aprobada, inventario completo de cambios, autorización responsable y planes de recuperación probados para configuración, estado y efectos externos.
Tracing, eventos de auditoría, señales de calidad, drift, fallos de retrieval, incidentes y feedback humano alimentan el ciclo de mejora gobernado.
Checklist de conformidad ADLC
SDLC y ADLC
| Característica | SDLC tradicional | ADLC |
|---|---|---|
| Ejecución principal | Delivery de software dirigida por personas | Delivery coordinada entre personas y agentes, con responsabilidad humana explícita |
| Comportamiento | Principalmente determinista y dirigido por código | También no determinista, adaptativo e influido por el contexto de runtime |
| Superficie de cambio controlada | Código fuente, configuración, infraestructura y datos | También prompts, conocimiento y RAG, skills, configuración del modelo, herramientas y orquestación |
| Validación | Pruebas de código, integración, sistema, seguridad y aceptación | Los mismos controles más evaluación continua de comportamiento, retrieval y regresión |
| Rol humano | Autor, reviewer, aprobador y operador | Diseñador, implementador, operador, reviewer, aprobador, responsable del escalado y de las decisiones |
| Evidencia | Registros de build, pruebas, aprobación y release | Trazabilidad end-to-end desde el requisito hasta el comportamiento, la evidencia, la release y las operaciones |
ADLC en práctica
En la práctica, el ADLC no funciona como una pipeline de una sola dirección. Los equipos entran por el quality gate de requisitos, atraviesan el delivery y vuelven al ciclo a través de operación, mejora y orquestación.
Skills compartidas
Las shared skills pueden partir de frameworks consolidados, pero deben adaptarse a la arquitectura, políticas, vocabulario, modelo de riesgo y cultura de delivery de la empresa.
Transforman know-how reutilizable en patrones de ejecución gobernados que agentes y equipos pueden aplicar con consistencia.
Define cómo la documentación humana y el agent context se producen como artefactos conectados pero separados.
La documentación humana vive en herramientas diseñadas para personas. La documentación para agentes se expone mediante Agent Context Endpoints gobernados, como servidores MCP (Model Context Protocol), archivos llms.txt, índices de retrieval o context packs versionados.
Las herramientas de contexto agentic pueden incluir Context7, GitMCP, MCPDoc, mcp-documentation-server, servidores MCP custom basados en SDKs MCP open source o sistemas equivalentes. Estos endpoints deben exponer URLs estables, ownership de fuentes, versionado, estado de aprobación y reglas de retrieval.
Recuperar solo el contexto aprobado necesario para la tarea. Reducir tokens sin eliminar permisos, restricciones, procedencia ni evidencia necesaria para una decisión correcta.
Publicar contexto reutilizable entre proyectos y equipos, evitando copias manuales divergentes y preservando vínculos con fuentes autorizadas.
Define cómo se seleccionan, asignan a un owner, aprueban, estructuran, versionan, publican, prueban, trazan y retiran las fuentes de conocimiento y el agent context.
Cubre fuentes RAG, context endpoints, conocimiento compartido, manejo de contradicciones, frescura, evaluación del retrieval, expectativas de cita, reglas de acceso y pruebas de regresión del comportamiento después de cambios de conocimiento.
El contexto runtime y la memoria requieren procedencia, permisos de escritura, retención, aislamiento entre usuarios y tenants, eliminación y gestión de contradicciones. El contenido recuperado no otorga autoridad. La compresión debe preservar permisos, restricciones y evidencia decisiva.
Define cómo generar, agrupar, revisar y adaptar release notes para audiencias técnicas, de negocio y operativas.
Incluye reglas para breaking changes, migraciones, known issues, rollback notes y resúmenes customer-facing.
Codifica principios arquitectónicos, criterios de decisión, reference patterns y expectativas de revisión de la empresa.
Ayuda a los agentes a razonar con estándares locales en lugar de recomendaciones genéricas.
Codifica convenciones de plataforma sobre entornos, despliegue, observabilidad, rollback, naming, ownership y readiness operativa.
Debe reflejar el modelo real de infraestructura de la empresa, no una checklist cloud abstracta.
Las skills de seguridad deberían ser definidas o validadas por el grupo CISO y alineadas con las políticas enterprise.
Ejemplos: manejo de datos, identidad, secretos, access control, threat modeling, uso seguro de prompts/tools y evidencia de auditoría.
Define datasets representativos, ensayos repetidos, umbrales de aceptación basados en riesgo, comprobación de resultados y políticas, evaluadores calibrados por personas y evidencia de regresión tras cambios de comportamiento. Vincula calidad, costes, latencia e intervención humana con decisiones de release.
Agentes compartidos
Produce y actualiza documentación para personas en la base de conocimiento humana oficial, como Confluence, SharePoint, Notion, GitBook, Backstage TechDocs, Read the Docs o plataformas equivalentes.
La documentación humana se optimiza para lectura, revisión, onboarding, gobernanza y auditabilidad. No es, por defecto, la interfaz de contexto para los AI agents.
Se encarga de ADR, runbooks, onboarding, notas de arquitectura, FAQ y documentación de proceso ligada a eventos reales de delivery.
Da soporte a las pull requests de punta a punta, resumiendo cambios, comprobando políticas, señalando riesgos y proponiendo reviewers.
Ayuda a mantener las revisiones consistentes, trazables y alineadas con los guardarraíles compartidos de ingeniería.
Genera release notes a partir del trabajo integrado, agrupando funcionalidades, fixes, breaking changes, migraciones y notas operativas.
Produce tanto resúmenes técnicos como versiones legibles para audiencias de negocio.
Detecta gaps entre código, tickets, releases y documentación, y luego propone o ejecuta las actualizaciones faltantes.
Mantiene alineadas en el tiempo la realidad del delivery y la base de conocimiento.
Revisa y gobierna las fuentes de conocimiento y agent context antes de que las usen los agentes. Comprueba frescura, ownership, estado de aprobación y versión, duplicación, contradicciones, validez de negocio, trazabilidad, calidad del retrieval e impacto de regresión.
Ayuda a asegurar que documentos, context endpoints, contenido RAG y conocimiento compartido mejoren el comportamiento de los agentes sin introducir cambios no controlados.
Conecta requisitos, implementaciones, pruebas, documentación y releases en una cadena auditable de evidencias.
Da soporte a quality gates, revisiones y checkpoints de gobernanza a lo largo del lifecycle.
Verifica que cada release tenga runbooks, ownership, guías de rollback, alertas y evidencias de readiness operativa.
Ayuda a que los equipos pasen del deploy a una operación estable con menos puntos ciegos.
Capacidades de tooling
Este mapa ADLC agrupa capacidades de tooling que apoyan sus controles, tomando como referencia estándares y prácticas técnicas consolidadas y emergentes. No es una taxonomía normativa ni un stack obligatorio: una herramienta puede cubrir varias capacidades y se pueden reutilizar servicios empresariales existentes. Seleccionar las implementaciones según el alcance aprobado, el riesgo y la arquitectura.
El retrieval solo es necesario cuando el sistema recupera conocimiento externo; los workflows persistentes son adecuados cuando la ejecución debe sobrevivir a interrupciones o coordinar acciones de larga duración. Un gateway multiproveedor es opcional cuando se necesita centralizar el acceso a modelos o el routing. Estos componentes no sustituyen el quality gate de requisitos ni la supervisión humana responsable.
Las referencias respaldan las capacidades subyacentes, no esta clasificación específica ni la conformidad ADLC. Los estándares y frameworks describen procesos o controles; la investigación estudia métodos específicos; la documentación técnica ilustra implementaciones.
| Capacidad | Qué utilizar | Control que demostrar |
|---|---|---|
| Requisitos y trazabilidad Estándar: ISO/IEC/IEEE 29148 | Un registro de requisitos vinculado a decisiones, pruebas y releases. | Alcance aprobado, criterios de aceptación medibles, responsables y quality gate superado. |
| Versionado y entrega Framework: NIST SSDF | Control de versiones, almacenamiento de artefactos y pipelines de entrega automatizados. | Cambios revisables en código, prompts, skills y configuración; promoción bloqueada si fallan controles obligatorios. |
| Conocimiento, contexto y documentación Documentación técnica: Context engineering | Documentación para personas y una interfaz separada de contexto para agentes, catálogo de fuentes, índice de retrieval y políticas de memoria cuando sean necesarios. | Responsables, aprobación, procedencia, actualización, acceso, retención y eliminación de fuentes; el contexto debe preservar las restricciones. |
| Identidad y acceso delegado Estándar: RFC 8693 | Proveedor de identidad, identidades de servicio, controles de autorización y gestor de secretos. | Quién actúa, en nombre de quién y con qué permisos; mínimo privilegio, delegación limitada, caducidad y revocación. |
| Políticas runtime y límites de consumo Documentación técnica: Policy enforcement Documentación técnica: Gateway budgets | Aplicación de políticas en los límites de las herramientas, contadores de uso, cuotas y controles de parada. | Límites de acciones, gasto, duración, llamadas y reintentos; las acciones prohibidas se bloquean, no solo se registran. |
| Orquestación y recuperación Documentación técnica: Durable execution | Controles de ejecución y procedimientos de recuperación; un motor de workflows persistente cuando se requiera reanudar o coordinar acciones de larga duración. | Ejecución reanudable, idempotencia, condiciones de parada, reconciliación del estado y compensación autorizada. |
| Revisión humana Framework: NIST AI 600-1 | Una cola de revisión con evidencias, asignación a revisores autorizados, caducidad y escalado. | Revisores formados pueden cuestionar o detener acciones; aprobación vinculada a la acción exacta, con evidencia de la decisión y sin aprobación implícita al vencer el plazo. |
| Evaluación del comportamiento Documentación técnica: Agent evaluations | Datasets de prueba versionados, motores de evaluación, pruebas adversariales y calibración humana. | Ensayos repetidos, resultados reales, cumplimiento de políticas, umbrales basados en riesgo y gates de regresión. |
| Observabilidad, costes y resultados Documentación técnica: OpenTelemetry GenAI | Trazas, métricas, alertas, contabilidad de costes y paneles operativos. | Deriva del comportamiento, fallos de retrieval, coste por tarea exitosa, latencia, intervención humana y resultados de negocio. La telemetría por sí sola no demuestra valor de negocio; evaluar los resultados frente a una referencia aprobada. |
| Auditoría e incidentes Documentación técnica: Decision logs Framework: NIST SP 800-61r3 | Almacenamiento protegido de evidencias, flujos de gestión de incidentes y runbooks operativos. | Reconstruir decisiones y cambios, gestionar incidentes, probar recuperación y retirar accesos y datos según políticas. |
| LLM Gateway y routing de modelos Investigación: RouteLLM Documentación técnica: LLM gateway | Cuando sea necesario, un gateway multiproveedor con routing evaluado, políticas de tokens de entrada/salida, caché y control de consumo. | Selección de modelos aprobados, evidencia separada del consumo de entrada/salida, gasto limitado y optimización que preserve la calidad. |
Verificar SSO (Single Sign-On) y roles, aislamiento entre tenants, retención y eliminación, evidencias de auditoría exportables, hosting y residencia de datos, soporte operativo e integración con controles existentes. La licencia open source por sí sola no garantiza la idoneidad.
Ejemplos de tooling empresarial
Estos ejemplos no son normativos. Usar un producto no hace por sí solo que un equipo esté alineado con ADLC: los controles, la evidencia, el ownership y las decisiones responsables siguen siendo obligatorios.
| Capacidad | Herramienta | Uso empresarial | Estado open source | URL |
|---|---|---|---|---|
| Requisitos y aprobaciones | Jira | Requisitos estructurados, workflows, aprobaciones, ownership y registros de trazabilidad. | No - comercial | https://www.atlassian.com/software/jira |
| Delivery y gates de evidencia | GitLab | Control de versiones, review, CI/CD, policy gates, controles de seguridad y evidencia de release. | Open core - CE es MIT; las funciones enterprise son propietarias | https://about.gitlab.com/ |
| Pruebas de comportamiento | promptfoo | Evaluaciones de prompts, RAG, agentes y red teaming ejecutables localmente o en pipelines CI. | Sí - proyecto MIT; oferta enterprise comercial | https://www.promptfoo.dev/ |
| Tracing y evaluación | Langfuse | Tracing, gestión de prompts, datasets de evaluación, experimentos y feedback de producción. | Open core - el core es MIT; los add-ons enterprise son comerciales | https://langfuse.com/ |
| Decisiones de políticas | Open Policy Agent | Policy-as-code para gates de entrega y autorización runtime. El servicio o gateway integrado debe aplicar las decisiones; los registros de decisiones apoyan la trazabilidad. | Sí - Apache-2.0 | https://www.openpolicyagent.org/ |
| Documentación humana | Backstage TechDocs | Catálogo de software y docs-as-code para personas, integrados con el ownership de ingeniería. | Sí - Apache-2.0 | https://backstage.io/docs/features/techdocs/ |
| Contexto técnico para agentes de programación | Context7 | Documentación de bibliotecas y ejemplos de código acordes con la versión mediante MCP y CLI. Un ejemplo de distribución de contexto técnico, no una plataforma completa de gobernanza de todo el conocimiento empresarial. | Parcial - el servidor MCP es MIT; el backend hosted es privado | https://context7.com/ |
| Ejecución persistente de workflows | Temporal | Workflows persistentes, recuperación ante fallos y coordinación de esperas y aprobaciones. La idempotencia y compensación de efectos externos deben diseñarse igualmente. | Sí - servidor MIT; servicio cloud comercial | https://github.com/temporalio/temporal |
| Secretos y credenciales temporales | OpenBao | Secretos centralizados, credenciales dinámicas para sistemas compatibles, caducidad y revocación. Apoya el acceso de mínimo privilegio sin introducir credenciales en prompts. | Sí - MPL-2.0 | https://github.com/openbao/openbao |
| Responsabilidad y procedencia de fuentes | OpenMetadata | Catálogo de metadatos, responsables, señales de calidad, linaje y análisis de impacto para un contexto de datos gobernado. Complementa, sin sustituir, la aprobación del conocimiento y las pruebas de comportamiento. | Sí - proyecto Apache-2.0 | https://github.com/open-metadata/OpenMetadata |
Arize Phoenix: Arize Phoenix es una alternativa para tracing, evaluación del retrieval, experimentos y diagnóstico del comportamiento. Es source-available bajo ELv2, no open source aprobado por OSI. Licencia.
LangGraph: LangGraph es un framework opcional con licencia MIT para agentes con estado, checkpoints y suspensión/reanudación para revisión humana. No es una plataforma completa de gobernanza: aún deben implementarse la interfaz de revisión, la competencia de los revisores, las autorizaciones y las políticas de aprobación.
Son ejemplos de capacidades, no un stack obligatorio ni una garantía de conformidad ADLC. Seleccionar solo los componentes necesarios para el alcance aprobado y verificar licencias y requisitos operativos de la edición concreta.
LLM Gateway
Un LLM Gateway debe gobernar el acceso a varios proveedores y dirigir cada tarea al modelo aprobado más adecuado, equilibrando calidad evaluada, riesgo, latencia, disponibilidad y coste. El balanceo de carga o elegir el modelo más barato no demuestra por sí solo su idoneidad.
| Gateway / fuentes oficiales | Licencia / oferta | Routing multiproveedor | Control de tokens y consumo |
|---|---|---|---|
| LiteLLM Documentación | Core open source: MIT; módulos enterprise con licencia separada. | Estrategias por coste/latencia y fallbacks entre proveedores. | Caché y límites de uso; configurar parámetros de tokens de salida y reducción de contexto cuando corresponda. |
| Portkey AI Gateway Documentación | Gateway open source: MIT; ofertas hosted/enterprise separadas. | Routing multiproveedor, balanceo y fallback. | Caché; optimización avanzada según edición. Validar límites de salida y políticas de contexto. |
| Kong AI Gateway Documentación | Funciones AI avanzadas comerciales; verificar edición y licencias de plugins. | Routing multiproveedor y semántico mediante plugins configurados. | Caché semántica, límites de tokens/coste; compresión con servicio adicional. Configurar límites de salida por separado. |
| Cloudflare AI Gateway Documentación | Servicio gestionado propietario; verificar límites del plan. | Rutas condicionales, selección de modelos, fallbacks y presupuestos. | Caché y cuotas de coste; límites de generación según parámetros del proveedor. Reducir contexto requiere integración. |
Primero los gateways open source, después los servicios comerciales. Son ejemplos, no un stack obligatorio ni un respaldo comercial. Ninguna fila implica soporte automático de todas las políticas de entrada/salida: verificar versión, compatibilidad y edición, incluidos streaming y presupuestos con solicitudes concurrentes.
Links útiles
Referencias duraderas para riesgo empresarial, responsabilidad, seguridad y gobernanza del ciclo de vida.
| Recurso | Descripción | Link |
|---|---|---|
| NIST AI Risk Management Framework | Framework vendor-neutral para gestionar los riesgos y la confiabilidad de la AI durante el diseño, desarrollo, despliegue, uso y evaluación. | nist.gov/ai-rmf |
| NIST Generative AI Profile | Perfil complementario que aplica el AI RMF a los riesgos y controles del ciclo de vida de la AI generativa. | nist.gov/genai-profile |
| ISO/IEC 42001 | Estándar internacional para sistemas de gestión de AI, con políticas, responsabilidad, controles de riesgo y mejora continua. El estándar completo es comercial. | iso.org/standard/42001 |
| MITRE ATLAS | Base de conocimiento evolutiva sobre tácticas y técnicas adversarias contra sistemas AI, incluidas amenazas agénticas y mitigaciones. | atlas.mitre.org |
| OWASP Agentic AI Threats and Mitigations | Taxonomía basada en threat modeling y guía de mitigación para sistemas AI autónomos y agénticos. | genai.owasp.org |
| OWASP State of Agentic AI Security and Governance | Reporte sobre el panorama actual de seguridad y gobernanza agéntica, útil como lectura contextual y no como estándar normativo. | genai.owasp.org/state-of-agentic-ai |
Especificaciones abiertas para integrar contexto, interoperar entre agentes y producir evidencia operativa portable.
| Recurso | Descripción | Link |
|---|---|---|
| Model Context Protocol | Protocolo abierto para conectar aplicaciones agénticas con herramientas, fuentes de datos y servicios de contexto gobernados. | modelcontextprotocol.io |
| Agent2Agent Protocol | Estándar abierto Apache-2.0 para discovery, interacción segura y colaboración entre sistemas agénticos independientes. | a2a-protocol.org |
| OpenTelemetry GenAI Semantic Conventions | Convenciones Apache-2.0 para trazas, métricas y eventos portables sobre retrieval, llamadas a herramientas, MCP y ejecución de agentes. | github.com/open-telemetry/semantic-conventions-genai |
Recursos de implementación que los equipos deben evaluar frente a sus controles, plataformas y modelos de riesgo.
| Recurso | Descripción | Link |
|---|---|---|
| Microsoft APM | Dependency manager con licencia MIT para distribuir instrucciones, skills, plugins y servidores MCP portables, versionados y gobernados por políticas. | github.com/microsoft/apm |
| Superpowers | Framework open source de skills y metodología de delivery para diseño, planificación, TDD, revisión y desarrollo asistido por agentes. | github.com/obra/superpowers |
| GitHub Copilot Token Optimization | Guía comunitaria específica del producto para reducir el contexto y el consumo de tokens sin comprometer la calidad del delivery. | github.com/olivomarco/github-copilot-token-optimization |
| Término | Nombre completo / concepto | Significado en ADLC |
|---|---|---|
| ADLC | Agentic Development Lifecycle | Ciclo de vida de sistemas agénticos que amplía SDLC con gobernanza del comportamiento, contexto y autonomía. |
| SDLC | Software Development Lifecycle | Disciplina del ciclo de vida del software, desde requisitos hasta entrega, operación y retirada. |
| AI | Artificial Intelligence | Capacidades de inteligencia artificial utilizadas en el sistema, sujetas a los mismos controles de gobernanza. |
| LLM | Large Language Model | Modelo de lenguaje utilizado por agentes; su versión y configuración afectan al comportamiento y requieren validación. |
| RAG | Retrieval-Augmented Generation | Recuperación de información externa para apoyar la generación; opcional, con fuentes gobernadas y pruebas de retrieval. |
| MCP | Model Context Protocol | Protocolo para conectar aplicaciones AI con herramientas y contexto; no sustituye autorización ni gobernanza. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Integración continua y entrega o despliegue continuo, con controles obligatorios antes de la promoción. |
| IAM | Identity and Access Management | Gestión de identidades y permisos, incluidas identidades de servicio y delegación limitada. |
| SSO | Single Sign-On | Autenticación única entre servicios; por sí sola no autoriza la ejecución de acciones. |
| Human in the Loop | HITL | Revisión humana competente y responsable en puntos críticos, con evidencias y autoridad para intervenir. |
| Quality gate | Quality gate | Control de entrada o promoción basado en evidencias; el gate de requisitos debe superarse antes de implementar. |
| Agent context | Agent context | Información disponible para un agente en una tarea, incluidas instrucciones, fuentes recuperadas, herramientas y memoria. |
| Guardrail | Guardrail | Control preventivo o de detección que limita comportamientos inseguros o no autorizados; los límites críticos requieren aplicación en runtime. |
| Orchestration | Orchestration | Coordinación de agentes, herramientas, estado y workflows dentro de permisos y presupuestos aprobados. |
| Context engineering | Context engineering | Selección y composición del contexto operativo; complementa, sin sustituirla, la gobernanza del conocimiento. |