SystemFlare
EN Hablar con un ingeniero

Gobierno de agentes de IA

Despliega agentes de IA para programar sin perder el control

Tus desarrolladores ya usan agentes de IA. Nosotros ponemos las reglas para que los agentes vayan rápido sin poder filtrar secretos, tocar producción ni hacer merge de código sin revisar.

El gobierno de agentes de IA para programar es la configuración de ingeniería que permite a un equipo usar Claude Code, Codex, Cursor y agentes similares con seguridad: políticas de permisos centralizadas, configuración gestionada, agentes que solo pueden abrir pull requests, controles de seguridad antes del merge, aislamiento de secretos, una lista aprobada de servidores MCP y trazabilidad. Es para responsables de ingeniería que despliegan agentes en un equipo, sobre todo en empresas reguladas. Parte de 4.000 € y lleva 2–3 semanas.

Para quién es

  • CTOs y responsables de ingeniería que despliegan Claude Code, Codex o Cursor en un equipo
  • Empresas reguladas (finanzas, pagos, proveedores TIC) que deben explicar a sus auditores cómo toca la IA su código
  • Equipos de seguridad a los que se pide aprobar agentes de IA sin una forma clara de controlarlos
  • Equipos en los que un agente ya ha hecho algo inesperado

Por qué ahora

  • Los desarrolladores usan agentes de IA en sus portátiles con su propia configuración, y nadie sabe a qué tienen acceso
  • Un agente ejecutó un comando, instaló un paquete o conectó un servidor MCP que nadie había aprobado
  • Tus evidencias de DORA o PCI DSS dicen que cada cambio en producción se revisa, y un agente con una clave de despliegue rompería eso
  • Las obligaciones de transparencia de la Ley de IA de la UE ya se aplican, y la dirección quiere una postura por escrito sobre cómo se usa la IA

Qué recibes

  • Política para agentes: qué pueden leer, ejecutar y cambiar, escrita para tus repositorios y revisada con tu equipo
  • Configuración gestionada desplegada de forma central: comandos, rutas y accesos de red permitidos y prohibidos, que los desarrolladores no pueden rebajar en local
  • Agentes que solo abren PRs: trabajan en ramas y abren pull requests; nunca hacen push a ramas protegidas ni despliegan
  • Controles antes del merge: búsqueda de secretos, archivos prohibidos, revisión de dependencias inventadas o con typosquatting, y aviso de cambios de riesgo
  • Aislamiento de secretos: los agentes no tienen credenciales de producción, ni acceso a servidores ni a bases de datos
  • Servidores MCP y herramientas aprobados: una lista permitida, con el motivo de cada uno, y una vía para pedir nuevos
  • Archivos de reglas por repositorio (como CLAUDE.md o AGENTS.md) que explican a los agentes vuestras convenciones y límites
  • Trazabilidad: qué agente propuso qué, quién lo aprobó y qué se desplegó, guardado en el historial de Git y de CI

Cómo funciona

  1. Inventario

    Qué agentes, herramientas, servidores MCP y credenciales se usan hoy, y en qué repositorios.

  2. Política

    Una política corta y práctica, acordada con ingeniería y seguridad: qué pueden hacer los agentes y qué necesita siempre a una persona.

  3. Aplicación

    Configuración gestionada, protección de ramas, controles antes del merge y aislamiento de secretos, desplegados mediante pull requests.

  4. Formación y entrega

    Una sesión con el equipo, archivos de reglas en cada repositorio y una revisión de las primeras semanas de trabajo de los agentes.

El principio: las reglas viven en el pipeline, no en el prompt

Un prompt o un archivo de reglas bien escrito hace que un agente se comporte mejor. No lo hace seguro. Los agentes malinterpretan, siguen instrucciones escondidas en archivos que leen o simplemente se equivocan. Por eso ponemos los límites importantes donde un agente no puede cambiarlos:

  • La protección de ramas decide qué se puede fusionar, no el agente.
  • Los controles en CI deciden si un cambio es aceptable: sintaxis para el runtime de destino, secretos, archivos prohibidos, revisión de dependencias y aviso de cambios de riesgo como configuración, CI, dependencias, SQL o código que borra datos.
  • La puerta de despliegue se ejecuta en el servidor y ninguna pull request puede debilitarla.
  • Las credenciales de producción sencillamente no existen en el entorno del agente.

Cómo lo aplicamos nosotros

Usamos agentes de IA en nuestro propio trabajo, y la configuración que montamos para los clientes es la que usamos. El agente trabaja solo mediante pull requests. No tiene acceso a servidores, bases de datos ni secretos. No puede hacer merge con comprobaciones en rojo. Cada petición, cambio y aprobación queda en el historial de Git. Así es como el propietario de una tienda en uno de nuestros proyectos pide cambios a Claude mientras la puerta de producción sigue en pie.

Lo que no hacemos

No elegimos tu proveedor de IA ni vendemos licencias, y no prohibimos herramientas. Hacemos que las herramientas que elijas sean seguras de usar y dejamos a tu equipo unas reglas que entiende.

Trabajo relacionado

Preguntas frecuentes

¿Cómo desplegamos Claude Code o Cursor en el equipo de forma segura?

Empieza con tres reglas que imponen las herramientas, no la confianza: los agentes solo abren pull requests, los agentes nunca tienen secretos de producción y nada se fusiona sin comprobaciones en verde y una revisión humana. Después añade configuración gestionada y una lista aprobada de herramientas. Eso es lo que monta este servicio.

¿Cuánto cuesta el gobierno de agentes de IA?

Desde 4.000 € sin IVA para un equipo y sus repositorios principales, normalmente en 2–3 semanas. Recibes un presupuesto cerrado tras una primera llamada.

¿Esto va a frenar a nuestros desarrolladores?

Muy poco. Los agentes pueden seguir leyendo código, ejecutando tests y proponiendo cambios libremente. Los límites están en los puntos que importan: secretos, producción y merge. La mayoría de los equipos ven que las revisiones son más fáciles, porque cada cambio del agente llega como una pull request limpia.

¿Vosotros usáis agentes de IA?

Sí. Usamos Claude en nuestro propio trabajo. El agente trabaja solo mediante pull requests, nunca tiene acceso a servidores, bases de datos ni secretos, y nunca hace merge con comprobaciones en rojo. Montamos las mismas reglas para nuestros clientes.

¿Qué son los servidores MCP y por qué hay que aprobarlos?

Los servidores MCP conectan un agente con otros sistemas: bases de datos, gestores de tickets, cuentas en la nube, navegadores. Cada uno amplía lo que el agente puede ver y hacer. Una lista permitida asegura que cada conexión sea una decisión, no un accidente.

¿Ayuda esto con los auditores?

Sí. Los auditores preguntan cómo se controlan los cambios. Con agentes que solo abren PRs, protección de ramas y comprobaciones, la respuesta es la misma para personas e IA: cada cambio se revisa, se prueba y queda registrado en Git.

¿Ya usáis agentes de IA? Pongámoslos bajo control

Cuéntanos qué herramientas usa tu equipo y cuántos repositorios hay. Te propondremos una política y un precio cerrado.

Hablar con un ingeniero