AI governance se bifurca: norma abierta contra defensa en producción

Es la capa OSS-académica para auditar agentes en menos de dos minutos: responde a la pregunta «¿el agente hace lo que se supone?» con ejecución humana o autónoma. Sus topics (eu-ai-act, iso-42001, nist-ai-rmf, owasp-llm, prompt-injection, hallucination-detection) lo orientan a empresas que necesitan justificar compliance, no solo defenderse. Ya cubrimos el concepto de governance AI y su pareja natural uber/ADR en el boletín del 2026-07-24; los dos juntos siguen siendo el par más claro que hemos visto para cubrir compliance externo + threat-model interno, así que este hallazgo refuerza la tendencia antes que abrir una nueva línea.

Uber libera bajo Apache-2.0 la capa que usa en producción para asegurar agentes AI: observabilidad, benchmark y detección de amenazas, con soporte explícito de MCP. Es pronto en términos de comunidad (796 estrellas, 72 forks) pero relevante precisamente porque es código que ya corre a escala Uber, no un prototipo. Lo cubrimos junto al concepto de ai_governance y enterprise_ai_readiness el 2026-08-03, y la lectura útil para nuestros lectores es esta: iFixAi audita desde fuera si el agente cumple, uber/ADR protege desde dentro en tiempo de ejecución; combinar ambos cubre el ciclo compliance + defensa que un equipo serio necesita antes de poner agentes en producción.

El equipo Every (autor de la metodología Compound Engineering) convierte esa metodología en un plugin oficial que sirve a la vez para Claude Code, Codex y Cursor. Con 23.9k estrellas es ya mainstream y confirma la commoditización de skills para coding agents: cada vendor edita su propia versión y obra/superpowers ya no es el único referente. Para el lector, el valor concreto es reducir el coste de cambio entre coding agents: un mismo plugin te sigue si alternas entre herramientas, en lugar de reescribir flujos cada vez.

Se suma al cluster de proyectos que ya cubrimos en boletines anteriores sobre memoria y continuidad entre sesiones (HKUDS/nanobot, screenpipe, obra/superpowers, TencentDB-Agent-Memory), con HKUDS/nanobot apareciendo por primera vez el 2026-07-16. La particularidad de KiroCrew no es la memoria persistente, que ya vimos en otros, sino que el workspace se reescribe a sí mismo entre sesiones para mejorar: es la primera vez, dentro de este grupo, que la auto-modificación del propio entorno del agente es la feature central y no un extra.