Guía de adopción empresarial de ADLC

Esta guía lleva a la práctica el manifiesto, el ciclo de vida y las skills compartidas. Es un modelo de adopción ilustrativo, no una certificación, garantía de conformidad ni conjunto universal de umbrales. Adaptar los controles al impacto empresarial y al modelo de riesgo de la organización. La versión inglesa es la fuente de referencia.

La gobernanza del conocimiento abarca documentos, prompts, skills compartidas, políticas, memoria y contexto runtime, independientemente de cómo se proporcionen. La generación aumentada por recuperación (RAG) es una técnica opcional, no un requisito previo de ADLC. Cuando se utilice, gobernar la calidad del retrieval, la actualización de fuentes, los permisos de acceso y las citas, junto con pruebas de regresión del comportamiento. El context engineering compone el contexto operativo del agente; no sustituye estos controles de gobernanza.

1. Aprobar el siguiente incremento

Ninguna implementación comienza sin haber superado el quality gate de requisitos.

Aprobar el alcance del siguiente incremento, en lugar de intentar fijar todos los requisitos futuros. Registrar responsables de negocio, ingeniería y riesgo; resultado esperado; criterios de aceptación medibles; datos autorizados; incertidumbres conocidas; condiciones que exigen una nueva aprobación.

Comparar automatización determinista, workflow LLM, agente único y orquestación multiagente. Utilizar la mínima autonomía y complejidad necesarias para lograr el resultado validado. Más agentes no demuestran mayor madurez.

Para un experimento, el incremento aprobado debe especificar hipótesis, sandbox, datos permitidos, presupuesto y criterios de salida. La aprobación experimental no concede acceso a producción. Un agente de quality gate puede preparar evidencias, pero no sustituir la decisión humana responsable.

2. Definir un contrato de autonomía

Versionar el contrato junto con la implementación y las evidencias de release:

Probar las acciones denegadas además de las permitidas. Los documentos recuperados, respuestas de herramientas y otros contenidos no fiables no pueden prevalecer sobre el contrato. Registrar decisiones y resultados sin incluir secretos o datos personales innecesarios.

Hacer efectiva la supervisión humana

Supervisión competente, no aprobación de trámite. Asignar revisores formados en el dominio, las limitaciones de los agentes y los riesgos de decisión. Antes de asignar tareas de aprobación, realizar ejercicios proporcionales al riesgo con recomendaciones incorrectas, evidencias ausentes e incidentes, para comprobar que reconocen la incertidumbre y pueden intervenir. Actualizar la formación tras cambios sustanciales o incidentes relevantes.

• Proporcionar fuentes, evidencias, limitaciones conocidas, incertidumbres y consecuencias de la acción propuesta, no solo la recomendación del agente.
• Dar tiempo suficiente y una carga de trabajo manejable. Si no es posible una revisión sustantiva, pausar la acción o dirigirla a una alternativa autorizada; no aprobarla implícitamente.
• Conceder autoridad efectiva para cuestionar, rechazar, pausar, solicitar revisión y escalar, sin depender de la cooperación del agente.
• Registrar revisor, evidencias examinadas, decisión y justificación proporcional al riesgo. Muestrear periódicamente la calidad de las decisiones e investigar señales de aprobación habitual; contar aprobaciones no demuestra supervisión.

Una aprobación formal sin verificación sustantiva no es un control de gobernanza.

3. Gobernar conocimiento, contexto y memoria

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.

Mantener documentación humana y contexto del agente conectados pero separados. La documentación humana facilita lectura, revisión y auditoría. Los endpoints para agentes exponen contexto aprobado y pertinente para la tarea, con URL estables, acceso autenticado cuando proceda, responsables de fuentes, versiones, estado de aprobación y reglas de retrieval.

Las instantáneas versionadas de las fuentes y la configuración del retrieval forman parte de las evidencias de release. La memoria mutable requiere un historial de eventos gobernado: origen, escritor autorizado, ámbito, marcas temporales, retención, corrección y eliminación. Aislar usuarios y tenants; definir cómo resolver hechos contradictorios u obsoletos. No convertir automáticamente una inferencia del agente en conocimiento autorizado.

La compresión del contexto debe ahorrar tokens sin eliminar permisos, restricciones, procedencia de fuentes ni evidencias necesarias para decidir correctamente. Evaluar el contexto comprimido frente a los mismos requisitos de comportamiento. Una URL, conexión MCP o archivo llms.txt no establece por sí solo confianza ni autorización.

4. Evaluar el comportamiento antes de la promoción

Verificar el software producido por agentes

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.

• Derivar los resultados esperados de requisitos aprobados, no de la implementación generada; someterlos a revisión humana competente independiente de la implementación.
• Proteger las pruebas de aceptación y las reglas CI. Eliminar pruebas, debilitar aserciones o cambiar umbrales de aceptación requiere revisión humana explícita.
• Para corregir un defecto, demostrar que la prueba falla antes y pasa después. Usar fallos controlados o pruebas de mutación cuando corresponda para comprobar que las aserciones detectan defectos pertinentes.
• Verificar efectos observables, datos persistidos y límites de autorización, no solo mensajes de éxito o mocks. Incluir pruebas de integración con servicios representativos.
• Cubrir comportamientos existentes, casos límite, acciones prohibidas y dependencias no disponibles. Mantener pruebas unitarias, de integración, end-to-end, de seguridad y no funcionales.
• Ejecutar controles en un entorno CI definido y conservar resultados reales vinculados a requisitos y al cambio revisado. El informe del agente no demuestra la ejecución.

Ejemplo: si un reembolso requiere aprobación, verificar que no se ejecute ningún pago sin ella, no solo que la interfaz muestre una solicitud de aprobación.

Crear un dataset representativo y versionado, vinculado a requisitos y casos de riesgo. Incluir resultados normales, solicitudes ambiguas, acciones no autorizadas, injection, conocimiento manipulado u obsoleto, fallos de retrieval, acceso entre tenants, timeouts de herramientas, solicitudes duplicadas, escalado y comportamiento de parada.

Repetir ensayos con estado aislado. Registrar dataset, configuración del modelo, prompts, herramientas, versiones de conocimiento y evaluadores, tamaño de muestra, variabilidad y lagunas de cobertura. Inspeccionar cambios reales de estado y cumplimiento de políticas, no solo una respuesta final plausible o una secuencia exacta de llamadas. Calibrar evaluadores basados en modelos con juicios de expertos del dominio y revisar desacuerdos.

Acordar umbrales de aceptación basados en riesgo antes de probar. El fallo de cualquier control obligatorio bloquea la promoción. Un conjunto finito de pruebas no demuestra la ausencia de fallos futuros. Repetir las pruebas de regresión pertinentes cuando cambie una entrada capaz de alterar el comportamiento, aunque no cambie el código.

5. Liberar, operar y recuperar

Las evidencias de release deben vincular requisito, fuente de conocimiento, comportamiento del agente, resultado de prueba, aprobación e identidad de release. Incluir todas las entradas que afectan al comportamiento, contrato de autonomía, limitaciones conocidas, plan de despliegue y ejercicios de recuperación.

Distinguir tres operaciones:

• Rollback de configuración: restaurar, cuando exista, una configuración anterior de código, prompt, conocimiento, herramienta o modelo.
• Restauración de estado: restaurar o reconciliar el estado interno sin repetir efectos externos.
• Compensación: aplicar una acción de negocio autorizada por separado para tratar un efecto externo que no puede simplemente deshacerse.

Usar despliegue gradual y controles preventivos para acciones irreversibles. Definir qué ocurre si falta un aprobador, una herramienta devuelve un resultado incierto o se agota el presupuesto. Los reintentos limitados no deben duplicar pagos ni otros efectos.

Monitorizar éxito, violaciones de políticas, deriva, calidad del retrieval, coste por tarea exitosa, latencia, intervención humana, retrabajo, escalado y valor empresarial frente a la referencia. Incluir intentos fallidos y gestión humana en el coste. Las evidencias pueden justificar un workflow más simple, menos autonomía o retirada. La retirada incluye revocar credenciales, desactivar endpoints y tareas programadas, y conservar o eliminar memoria y evidencias según la política aprobada.

Ejemplo completo: asistencia con reembolsos

Los números siguientes son umbrales ilustrativos para un piloto, no requisitos ADLC.

Registro de evidencias reutilizable

Mantener un registro vinculado por incremento aprobado y release:

• ID de requisito, responsable, resultado, decisión de idoneidad, referencia, riesgos y aprobación.
• Contrato de autonomía versionado, permisos, fuentes de conocimiento, política de memoria y controles runtime.
• Inventario de cambios de código, prompts, skills, conocimiento, herramientas, configuración del modelo y orquestación.
• Versiones del dataset y evaluadores, resultados de ensayos, umbrales, lagunas de cobertura y revisión humana.
• Autorización de release, alcance del despliegue, criterios de parada y resultados de ejercicios de recuperación.
• Resultados operativos, incidentes, decisiones correctivas y siguiente incremento aprobado o registro de retirada.

Referencias especializadas

Estas fuentes fundamentan las prácticas anteriores; la guía es una adaptación ADLC, no una declaración de respaldo o certificación.

• Anthropic: Building effective agents explica la simplicidad y las decisiones entre workflows y agentes.
• Anthropic: Demystifying evals for AI agents aborda evaluaciones repetidas, resultados y calibración de evaluadores.
• Anthropic: Effective context engineering for AI agents cubre gestión del contexto y memoria.
• OWASP: Top 10 for Agentic Applications aporta una perspectiva de controles agénticos basada en amenazas.
• Microsoft: AI agent orchestration patterns describe decisiones de orquestación y problemas de fiabilidad.
• NIST: AI Risk Management Framework core enmarca gobernanza y gestión del riesgo durante el ciclo de vida.