Aigovia: un laboratorio personal de gobierno de IA, en directo

DevSecOps 360: el ciclo en 8 etapas y 24 capacidades

Salud explicable de 0 a 100, evaluación de entrega con cuatro veredictos y hallazgos con huella estable entre ejecuciones.

Quería saber con qué confianza llega un cambio a main, no solo si el CI está en verde.

Command Center, Insights y estándares

Una vista de todo en una pantalla, una bandeja de alertas que se resuelven solas y seis marcos (ISO 42001, EU AI Act, NIST…) medidos como evidencia, nunca como certificación.

App Intelligence: entender un código antes de opinar sobre él

Un grafo de conocimiento del proyecto, agentes que infieren su significado de negocio y mejoras con estado actual, estado objetivo y criterio de aceptación.

AgentScope pasa a llamarse Aigovia

El nombre provisional se quedaba corto: no se trataba solo de observar agentes, sino de gobernar cómo se construye software con ellos. Gobierno, ingeniería y ejecución en una sola palabra.

Un nombre que describe solo la mitad del problema acaba condicionando el diseño.

Primer commit: el esqueleto entra en el ciclo SDD

Todo lo prototipado se ordena como cambios de OpenSpec y se implementa en grupos: persistencia, proveedor de Claude Code, API y frontend. Desde aquí, cada cosa que construyo pasa por el mismo ciclo SDD que analiza la herramienta.

Walking skeleton: el esqueleto que conecta todo

Primeros desarrollos de extremo a extremo para validar la arquitectura antes de construir encima: leer una sesión real de Claude Code, calcular su coste por modelo, guardarla y verla en una primera pantalla. Feo, pero atravesando todas las capas.

Antes de pulir una pieza quería ver el camino completo funcionando, de la sesión en disco a la pantalla.

Del modelo en papel al diseño de la plataforma

Los cuatro pilares como navegación, el modelo de datos común (proyectos, sesiones, iniciativas, políticas, evidencias) y las primeras pantallas: qué pregunta responde cada una y qué dato necesita para hacerlo sin inventar nada.

Arquetipos SDD: SpecKit, BMAD, Kiro y OpenSpec

Estudio de los principales formatos de Spec-Driven Development para definir arquetipos: cómo organiza cada uno especificaciones, diseño y tareas, y qué huella deja en un repositorio. Base para detectar cómo se construye cada proyecto y para elegir OpenSpec como metodología del propio laboratorio.

Si la herramienta tiene que reconocer cómo trabaja un equipo, antes tengo que entender cada forma de trabajar.

Estudio de arquitecturas de referencia

Análisis de herramientas existentes que leen las sesiones de los agentes y de plataformas de observabilidad y FinOps. De ahí salen las decisiones de base: local-first, un solo binario, Rust con Axum y SQLite en el backend, React en el frontend y proveedores intercambiables para no depender de un único agente.

Antes de diseñar nada quería saber qué existía, qué resolvía bien y qué dejaba sin responder.

Arranca el laboratorio: ¿cómo se mide todo esto?

Después de publicar el Modelo de Gobierno IA y la guía SDD, la pregunta siguiente era inevitable. Primera investigación: qué dejan en disco los agentes de IA (sesiones, tokens, herramientas, ficheros tocados), qué preguntas no sabe responder hoy ningún equipo y qué haría falta para responderlas con evidencia.

Un modelo de gobierno que no se puede medir se queda en una presentación.