Cómo gobernar Kiro a escala empresarial

Por Gonzalo Vásquez, Senior Solutions Architect en AWS Chile y Franco Abregu, Sr. Delivery Consultant — DevOps en AWS Professional Services.

La gobernanza empresarial de Kiro a escala se pone a prueba con una pregunta incómoda, y casi siempre llega desde la mesa del CTO. ¿Puedes decir, hoy, qué modelos y qué herramientas MCP usan tus desarrolladores? Rara vez es curiosidad: suele ser una exigencia de auditoría. Sin gobernanza empresarial de Kiro, esa respuesta es pura especulación.

Kiro es una plataforma de desarrollo con IA que, además de acelerar la escritura de código, opera bajo controles de nivel empresarial. Documentamos su costo-eficiencia en un análisis previo sobre benchmarking de Kiro.

Para responder esa pregunta, Franco y yo levantamos un entorno lab controlado y probamos cada control. En este post recorremos los cuatro planos que te permiten responderla con datos: identidad y suscripciones, gobernanza de modelos y del Model Context Protocol (MCP), monitoreo, e ingeniería de contexto.

Un desafío honesto: si la ingeniería de contexto sobre Kiro realmente escala, deberíamos poder producir este mismo post aplicándola. Lo hicimos, y volvemos sobre eso en el Plano 4.

Los cuatro planos de la gobernanza empresarial

Antes de tocar la consola, conviene ver el mapa completo. La gobernanza empresarial de Kiro se organiza en cuatro planos que se apoyan uno sobre otro. Cada uno deja evidencia mecánica que puedes auditar.

El primer plano es identidad y suscripciones. Conectas Kiro a tu proveedor de identidad y asignas las suscripciones por grupo, de modo que cada acción quede atribuida a una persona real y no a una cuenta anónima. Es la base: sin identidad, ningún otro plano es auditable.

El segundo plano es gobernanza de modelos y del registro MCP. Un perfil empresarial define qué modelos y qué servidores MCP están permitidos. En nuestro lab, el catálogo permitía solo tres servidores de los 19 declarados localmente; los otros 16 quedaron fuera. Al activarse el perfil, el cliente los apaga solo, antes de que salga una sola petición de la máquina.

El tercer plano es monitoreo. Con el registro de prompts y los reportes de actividad activados, Kiro escribe cada interacción en Amazon S3 y la atribuye a la identidad que la generó. Aquí es donde la pregunta del CTO deja de ser especulación.

El cuarto plano es ingeniería de contexto. Sobre esa base gobernada apilas capas: el steering fija los estándares que Kiro sigue siempre. Encima defines Powers, Skills y Custom Agents para que trabaje con el conocimiento de tu organización, no con supuestos genéricos. A esas capas las respaldan los hooks, que aplican las reglas de forma automática al guardar un archivo o abrir una PR.

Figura 1: los cuatro planos de la gobernanza empresarial de Kiro, desde identidad hasta ingeniería de contexto, sobre un perfil empresarial.

Prerrequisitos

Antes de replicar este patrón en tu propia cuenta, necesitas lo siguiente:

• Una cuenta de AWS con permisos para administrar AWS IAM Identity Center y Amazon S3.
• Un proveedor de identidad (AWS IAM Identity Center en este post) con al menos un grupo de desarrolladores creado.
• Un plan empresarial de Kiro con acceso a la consola de administración para definir el perfil de gobernanza.
• La guía de primeros pasos de Kiro empresarial a mano para los detalles de configuración.
• Familiaridad básica con la consola de AWS y la línea de comandos.

Plano 1: identidad y suscripciones con IAM Identity Center

Todo empieza por la identidad, porque sin ella ninguna de las métricas posteriores es atribuible a una persona. En el lab conectamos Kiro a una instancia de AWS IAM Identity Center, creamos un grupo developers y asignamos a los usuarios de prueba a ese grupo.

El patrón que recomendamos es asignar las suscripciones de Kiro por grupo, no por usuario. Creas un grupo (por ejemplo developers) y le asignas el plan empresarial una sola vez. Cuando entra un desarrollador nuevo, lo agregas al grupo en tu proveedor de identidad y hereda el acceso; cuando sale, lo quitas del grupo y pierde el acceso. No hay asignaciones sueltas que auditar una por una.

La ventaja concreta aparece en el plano de monitoreo. Cada registro de actividad que Kiro escribe lleva un identificador que combina el ID de tu directorio y el ID del usuario. Así, un prompt registrado se resuelve directo a una identidad de IAM Identity Center, sin cruces manuales contra otra tabla.

Anclar la identidad de las herramientas de desarrollo en una fuente central no es exclusivo de Kiro. Es la misma filosofía con la que Moeve protege cargas externas con PKI privada y AWS IAM Roles Anywhere: una identidad verificable como base de todo control posterior. Con la identidad resuelta, pasamos a gobernar qué modelos y servidores MCP usa ese grupo.

Plano 2: gobernanza de modelos y del registro MCP

Aquí la gobernanza deja de ser una promesa y se vuelve un comportamiento observable del cliente. La gobernanza de Kiro permite al administrador definir un perfil empresarial con un allowlist: el registro central de servidores MCP aprobados. El bloqueo no es un rechazo por petición. En cuanto la sesión cambia al perfil empresarial, Kiro apaga los servidores que no están en el registro. Ocurre antes de que salga una sola petición de la máquina.

Lo capturamos en el lab. Al iniciar sesión con el perfil empresarial, el cliente cerró 16 servidores MCP en una ventana de 1,4 segundos. Sobrevivieron solo tres: filesystem, git y aws-ccapi, los del allowlist. Uno de los apagados, aws-documentation, era el que un Power de ejemplo referenciaba a propósito. Quedó fuera igual: el registro manda por sobre lo que declare cualquier Power o configuración local.

Esta es la respuesta mecánica a la pregunta del CTO sobre qué herramientas MCP corren tus desarrolladores. No dependes de que cada quien respete una política escrita: el cliente hace cumplir el registro por sí mismo.

El log del cliente lo registra servidor por servidor:

15:11:00.921 [info] [aws-documentation]   Connection closed successfully
15:11:00.921 [info] [fetch]               Connection closed successfully
15:11:00.921 [info] [chrome-devtools]     Connection closed successfully
15:11:01.277 [info] [playwright-mcp]      Connection closed successfully

Figura 2: fragmento del log donde el cliente Kiro apaga el servidor MCP aws-documentation al activarse el perfil empresarial que no lo permite.

Plano 3: registro de prompts y reportes de actividad

Con la identidad resuelta y el MCP gobernado, el tercer plano responde la parte de la pregunta del CTO sobre qué se usó realmente. El perfil empresarial habilita dos flujos de datos hacia un bucket de Amazon S3 de tu cuenta.

El primero es el registro de prompts: un JSON comprimido por interacción, tanto en el IDE como en la CLI. Cada archivo trae el modelId, la marca de tiempo y el userId.

El segundo es el reporte de actividad: un CSV periódico con profileId, nivel de suscripción y userId. Es el mismo userId del Plano 1, así que cada fila apunta a una persona real de tu directorio. Son los campos que necesitas para responder «quién usó qué, y bajo qué plan».

Juntos, estos dos flujos convierten la especulación en un conjunto de datos consultable. La pregunta de apertura (qué modelos y herramientas usan tus desarrolladores) deja de ser una conversación de pasillo y se vuelve una consulta. Más adelante construimos exactamente esa consulta.

Plano 4: ingeniería de contexto con Powers, Skills y Custom Agents

Con la gobernanza en su lugar, empieza el trabajo interesante: hacer que Kiro razone con el conocimiento de tu organización en lugar de supuestos genéricos. Lo construyes por capas. En el lab lo probamos con un caso concreto de estándares de Node.js.

La capa base es el steering: archivos que Kiro carga siempre y que fijan tus reglas — cómo tipar, cómo manejar errores, qué está prohibido en una dependencia. En nuestro ejemplo, dos archivos de steering codificaron los estándares de código y las reglas de seguridad de Node.js.

Encima va un Power, que empaqueta ese steering junto con los servidores MCP permitidos y una Skill, todo bajo un nombre reutilizable. El Power nodejs-standards agrupó esos estándares y expuso solo los servidores MCP del allowlist empresarial — un recordatorio de que los planos se apoyan uno en otro.

La Skill automatiza una tarea repetible. nodejs-pr-check corre un chequeo de cumplimiento sobre el diff de una PR: tipos any, promesas sin await, versiones no fijadas, secretos. Emite un reporte JSON con código de salida para que lo conectes a tu CI.

El Custom Agent cierra el stack. nodejs-reviewer es un revisor de solo lectura, con MCP limitado a git y filesystem, que camina el diff regla por regla y produce un veredicto estructurado. No puede escribir ni desplegar; solo revisar.

Este patrón no es teórico. Es la misma disciplina de codificar el conocimiento del equipo que le permitió a Frávega reducir ~52% el costo operativo de sus bases de datos en AWS.

Figura 3: capas del stack de ingeniería de contexto en Kiro — steering, MCP allowlisted, Power, Skill y Custom Agent.

Los hooks son la capa de cumplimiento que empareja con este stack: no son contexto, sino automatización. En el peldaño mecánico, un command hook corre un script determinista al guardar un archivo. Nuestro hook de chequeo de PR dispara la verificación en cada edición de un .ts o de package.json, rápido y sin costo de LLM. En el peldaño de razonamiento, un steering de inclusión manual delega una revisión cualitativa a un agente cuando tú lo invocas: más profundo, con costo por invocación.

Este post es la demostración práctica de ese stack. Lo escribimos con un harness: el conjunto de Power, Skills, agentes y hooks que guía el proceso. Aplica esta arquitectura sobre las convenciones de aws-spanish y la Content Design System de AWS:

• Un Power con diez archivos de steering codifica las reglas de estilo y estructura.
• Seis Skills producen el outline, las secciones y las revisiones.
• Dos Custom Agents completan el flujo: un editor que escribe en los borradores y un reviewer de solo lectura para la revisión pre-publicación.
• Cinco hooks de cumplimiento, tres mecánicos y dos de razonamiento, validan estilo, outline y evidencia.

Los cinco pilares de contexto y los dos peldaños de cumplimiento, aplicados sobre nuestro propio proceso.

Adopción medible: del dato al tablero

Los datos de actividad solo sirven si alguien los mira, así que el plano de monitoreo se completa con un tablero que un CTO puede leer en cinco minutos. La arquitectura es directa: los CSV de actividad en Amazon S3, un crawler de AWS Glue que descubre el esquema, y Amazon Athena para consultarlos con SQL.

Ese pipeline no lo escribimos. El repositorio sample-kiro-user-analytics-dashboard lo despliega con Terraform y trae su propia app Streamlit; puedes levantarlo tal cual sobre tu bucket de reportes. Conservamos su arquitectura y cambiamos la capa de presentación por una página HTML autocontenida.

Sobre ese esquema escribimos ocho consultas. La más importante arma un CTO scorecard: usuarios activos en siete días, créditos por usuario activo, y el porcentaje de uso por modelo. Ninguna de las dos cosas viene en el repositorio; son la capa que agregamos sobre el esquema que crea su Terraform.

Con un usuario y cuatro días de datos, el lab produce un tablero de una sola fila. Con 50 desarrolladores y 90 días, las mismas consultas revelan tendencias por equipo, modelo y semana. Aquí la pregunta del CTO tiene una respuesta consultable, no una suposición.

Figura 4a: el CTO scorecard — usuarios activos, créditos consumidos y porcentaje de uso por modelo sobre los datos de actividad del lab.

Figura 4b: la distribución de modelos — la mayor parte del uso corre sobre el modelo «auto», que elige la opción capaz más económica.

Cómo empezar

No necesitas los cuatro planos operativos el primer día. El patrón se construye en capas, y cada una entrega valor por sí sola.

Esta semana: conecta Kiro a tu proveedor de identidad y asigna las suscripciones por grupo. Es el paso que hace auditable todo lo demás, y el más rápido de completar.

Este mes: define el perfil empresarial con tu registro de servidores MCP permitidos y activa el registro de prompts y los reportes de actividad. Al terminar, ya puedes responder qué modelos y herramientas usa tu equipo — con datos, no con suposiciones.

Este trimestre: invierte en ingeniería de contexto. Empaqueta los estándares de tu organización en un Power, automatiza tus revisiones con una Skill y un Custom Agent, y respalda las reglas con hooks. Es la capa que más tiempo toma, pero también la que convierte a Kiro en una extensión del criterio de tu equipo.

Empieza por la identidad; el resto se apoya sobre ella.

Limpieza

Si replicaste este patrón en un entorno de prueba, elimina los recursos que no vayas a conservar para no incurrir en costos. Vacía y borra el bucket de Amazon S3 con los registros de prompts, los reportes de actividad y los resultados de consultas. Elimina el crawler y la base de datos de AWS Glue, y el grupo de trabajo de Amazon Athena. Si creaste una instancia de AWS IAM Identity Center solo para la prueba, desactívala. Deja intacto lo que uses en producción.

Conclusión

En este post, mostramos cómo llevar Kiro a escala empresarial sin perder visibilidad ni control. Recorrimos los cuatro planos de la gobernanza: identidad y suscripciones, gobernanza de modelos y del registro MCP, monitoreo, e ingeniería de contexto. Cada plano deja evidencia mecánica: desde el apagado automático de servidores MCP no permitidos hasta un tablero que responde en cinco minutos qué modelos y herramientas usa tu equipo.

Aquella pregunta del CTO que abrió el post ya no se responde con una suposición, sino con un dato consultable. Ese es el punto: la gobernanza no frena la adopción, la hace auditable. Si estás evaluando Kiro para tu organización, empieza por la identidad y construye hacia arriba: cada capa entrega valor por sí sola y prepara la siguiente.

Recursos

• Documentación de Skills, Custom Agents y steering para la capa de ingeniería de contexto.
• Implementación de referencia del tablero: aws-samples/sample-kiro-user-analytics-dashboard.
• El mismo patrón aplica a cualquier proceso con reglas de cumplimiento denso: mapea las reglas suaves a steering, las mecánicas a command hooks, las cualitativas a Custom Agents. Kiro provee las primitivas; el trabajo es mapear tu dominio.

¿Ya gobiernas Kiro a escala en tu organización? Cuéntanos en los comentarios qué plano te resultó más difícil de implementar.

Sobre los autores

Gonzalo Vásquez es Senior Solutions Architect en AWS Chile, donde trabaja con las principales empresas SaaS del mercado regional. Ingeniero Electrónico con más de 25 años en la industria de tecnología y 4 en AWS, antes se desempeñó como desarrollador, arquitecto de sistemas y CTO en compañías chilenas. Es Area of Depth (AoD) de las Technical Field Communities de Next Generation Developer Experience y Sustentabilidad Ambiental en AWS, actuando como especialista (SME) en esos dominios. LinkedIn: https://www.linkedin.com/in/gvasquez/

Franco Abregu es Senior Delivery Consultant — DevOps en AWS Professional Services, y miembro de la Technical Field Community de Next Generation Developer Experience. Ingeniero en Sistemas de Información por la Universidad Tecnológica Nacional (FRBA), tiene experiencia en desarrollo de software, analítica digital y computación en la nube. Disfruta diseñar soluciones en la nube de alta disponibilidad, distribuidas y seguras, y ayudar a otros equipos a automatizar tareas manuales para simplificar su trabajo diario. LinkedIn: https://www.linkedin.com/in/francoabregu/