Identificar las responsabilidades, los riesgos, los antipatrones y las necesidades de rastreabilidad
A medida que los agentes se vuelven más capaces, puede ser tentador imaginar el cambio de responsabilidad al sistema. No es así. Los sistemas agenteicos pueden ejecutar el trabajo, pero los seres humanos siguen siendo responsables de los resultados y de los controles que rigen la ejecución.
En esta unidad, aprenderá
Quién es responsable de las acciones y los resultados del agente
Qué riesgos comunes y antipatrones aparecen en los sistemas de agentes
Cómo GitHub controles mitigan estos riesgos
¿Por qué se requieren seguimientos y observabilidad para sistemas de confianza?
La responsabilidad no se mueve con la ejecución
Cuando un agente crea una solicitud de incorporación de cambios, revisa el código o responde a los comentarios, participa en el flujo de trabajo, pero no asume la propiedad de los resultados. Las partes responsables siguen siendo las personas y los equipos que:
Se definió la tarea
Establecimiento de permisos
Elegir y configurar controles
Aprobación del cambio resultante
Un modelo de revisión de solicitudes de incorporación de cambios hace esto explícito: el sistema puede proponer, pero los seres humanos deciden lo que se acepta.
Riesgos comunes y antipatrones
Los sistemas de agentes de fase temprana suelen producir errores de maneras predecibles:
Ejecución sin plan El agente comienza a cambiar el código sin un enfoque inspeccionable claro.
Agentes con permisos excesivos El agente (o sus credenciales de token o herramientas de flujo de trabajo) tiene acceso más amplio de lo necesario.
Razonamiento oculto El flujo de trabajo expone solo salidas (la diferencia) sin artefactos intermedios (plan, suposiciones, puntos de decisión, contexto de ejecución).
Confiar ciegamente en la automatización importa que CI pase, pero las comprobaciones solo validan lo que están diseñadas para detectar. Una compilación exitosa no significa automáticamente que el cambio sea completo, adecuado o de bajo riesgo.
Mapeo de implementación: riesgo → mitigación en GitHub
| Riesgo/antipatrón | Cómo se ve en GitHub | Mitigación mediante controles de GitHub |
|---|---|---|
| Ejecución sin plan | El PR tiene diferencias pero no tiene ningún plan o justificación | Requerir una sección de plan a través de una plantilla de SOLICITUD de incorporación de cambios; requerir revisión antes de la combinación |
| Agentes con permisos excesivos | Los flujos de trabajo pueden escribir en el repositorio y acceder a secretos ampliamente | GITHUB_TOKEN con privilegios mínimos; entornos con revisores necesarios; restringir quién puede desencadenar flujos de trabajo |
| Razonamiento oculto | Sin supuestos, ámbito o pista de decisión | Requerir ejecuciones de flujo de trabajo de plan y vínculo y tomar decisiones de registro en los comentarios de solicitud de incorporación de cambios |
| Confianza ciega en la automatización | "CI pasada, enviarla" mentalidad | Combina comprobaciones con CODEOWNERS, revisiones requeridas y aprobaciones basadas en riesgos |
Rastreabilidad y observabilidad
Para supervisar bien un agente, necesita más que una diferencia final, necesita una pista. En GitHub, ese rastro puede incluir:
Solicitudes de incorporación de cambios y historial de confirmaciones
Revisión de comentarios y aprobaciones
Flujos de trabajo se ejecutan y artefactos cargados (informes de prueba, registros)
Subidas y alertas de análisis de código
Alertas de exploración de secretos y eventos de protección al enviar
Eventos de registro de auditoría de la organización (la disponibilidad y el acceso dependen de la configuración de la organización o de la empresa)
El objetivo no es solo el cumplimiento. Es la comprensión operativa: cuando se produce un error en algo, debe saber qué ha cambiado, quién la aprobó, qué evidencia existía y qué pasó a continuación.
Seguimiento mínimo de auditoría para las contribuciones del agente
Un objetivo indicado (vínculo de problema o descripción de la solicitud de incorporación de cambios)
Un plan inspeccionable (sección o archivo del plan de solicitud de incorporación de cambios)
Un conjunto de cambios delimitado (rama y confirmaciones)
Evidencia automatizada (ejecución del flujo de trabajo y artefactos)
Juicio humano (revisión y aprobación)
Resultado claro (combinación, reversión o escalación)
Supongamos que la solución de vulnerabilidad del agente pasa CI pero más adelante provoca una regresión. La pregunta clave no es solo si el agente ha cometido un error, es si el sistema ha cometido el error comprensible y evitable:
¿Había un plan y un ámbito visibles?
¿Se solicitó a los revisores adecuados (y aprobaron)?
¿Las verificaciones se corresponden con el riesgo del cambio?
¿Es suficiente el registro de auditoría para reconstruir lo que ha ocurrido?
Los sistemas agenteicos cambian quién realiza el trabajo, pero no quién es el propietario de los resultados. Los equipos humanos siguen siendo responsables, por lo que deben diseñar en contra de antipatrones comunes y requieren una alta rastreabilidad a través de artefactos y registros nativos de GitHub.
Una vez que comprenda cómo funciona la responsabilidad, el último paso es decidir cómo se debe juzgar el trabajo del agente. En la próxima unidad, aplicará el modelo de contribuidor a la salida generada por el agente.