Cómo leer: la escalera aumenta la autonomía, pero cada peldaño solo se alcanza con el control del peldaño anterior instalado. La cima aparece en rojo a propósito: el nivel 5 no es la meta del curso, es el límite que la mayoría de las organizaciones no debería cruzar.
Mapa de la ruta
Contenido detallado
📘 Playbooks y procesos reutilizables
Procedimientos para tareas recurrentes: nueva funcionalidad, corrección de errores, modernización de código heredado, revisión de PR, refactorización, dependencias, migración de bases de datos, incidentes y validación antes del deploy.
Un procedimiento reutilizable para una tarea recurrente, escrito como una secuencia de pasos con entradas, salidas y criterio de finalización.
El playbook es lo que hace que el resultado se pueda repetir entre personas y agentes, y es donde el conocimiento del equipo deja de depender de quien está de guardia.
Pasos ordenados > principios genéricos · Un playbook por tarea recurrente · Evoluciona con la retroalimentación de la práctica.
Leer la especificación → confirmar el alcance → mapear el impacto → crear un plan → implementar el cambio mínimo → crear pruebas → ejecutar quality gates → revisar → documentar → preparar el pull request.
Es el camino estándar para el trabajo nuevo. Dejarlo por escrito elimina la variación de calidad entre el lunes y el viernes.
Confirma el alcance antes de programar · Mapear el impacto revela qué se rompe · Documentar forma parte de estar listo.
Reproducir el error → registrar evidencia → identificar la causa → crear una prueba que falle → implementar la corrección → ejecutar la regresión → revisar el impacto → documentar.
El orden importa: sin reproducir el problema, corriges lo que imaginas; sin una prueba que falle antes, no hay evidencia de que el error haya desaparecido.
La reproducción es el primer paso · Una prueba que falla antes = evidencia · La regresión cierra el ciclo.
Mapear dependencias → crear pruebas de caracterización → definir límite → crear adaptador → migrar un módulo pequeño → ejecutar en paralelo → comparar resultados → habilitar gradualmente.
Es la ruta 4 condensada en un procedimiento: el formato en que realmente se usa en el día a día.
Un módulo a la vez · Comparación antes del cambio · La liberación gradual mantiene disponible la posibilidad de volver atrás.
Recopilar logs → clasificar la gravedad → preservar las evidencias → identificar la causa probable → crear una mitigación → validar → aplicar la corrección → registrar el aprendizaje.
Bajo presión nadie improvisa bien. El playbook es lo que impide que la primera reacción borre la evidencia de lo ocurrido.
Preservar antes de actuar · Mitigar ≠ corregir · El aprendizaje registrado se convierte en regla o gate.
La práctica de revisar el playbook cada vez que falla en la realidad y guardarlo en el repositorio, con control de versiones como código.
Un playbook que no se usa se deteriora y empieza a estorbar: el agente sigue un procedimiento que ya no describe el sistema.
¿Falló en la práctica? Actualízalo · Versionado en el repositorio · Pocos y buenos > muchos y olvidados.
🧩 Skills y Rules
Skills como capacidades reutilizables (analizar un repositorio, generar una spec, crear un plan, implementar, revisar, probar) y rules como límites permanentes de comportamiento.
Una capacidad reutilizable que guía al agente en una tarea específica: analizar el repositorio, generar una especificación, crear un plan, reproducir un bug, generar pruebas, revisar la arquitectura o la seguridad, o preparar un PR.
Una skill es el playbook en un formato que el agente consume directamente: ya no tienes que volver a pegar el mismo prompt cada semana.
Skill ≈ playbook ejecutable · Una tarea por skill · La reutilización reduce la variación en la calidad.
Objetivo, cuándo usarlo, entradas, herramientas, pasos, criterios de aceptación, acciones prohibidas, gestión de errores, formato de salida y verificaciones obligatorias.
"Cuándo usar" y "acciones prohibidas" son los campos que distinguen una skill útil de un prompt guardado: el primero hace que el agente elija correctamente, el segundo evita el daño.
Cuándo usar > qué hace · El formato de salida hace que la skill sea componible · La verificación obligatoria cierra el ciclo.
El criterio de priorización: empieza por las tareas que repites mucho y que hoy obtienen resultados de calidad inconsistente.
Una skill para una tarea poco frecuente es mantenimiento sin retorno. Una skill para una tarea semanal se amortiza en la primera semana.
La repetición justifica empaquetar · Alta variación = gran beneficio · Empieza con 3 a 5 skills, no 30.
Reglas permanentes o condicionales que limitan el comportamiento de los agentes: nunca modificar pruebas para ocultar fallas, nunca insertar secretos, no hacer deploy sin aprobación, no refactorizar fuera del alcance.
Las Rules reducen las decisiones arbitrarias. No dependen de que recuerdes escribir la misma prohibición en cada tarea.
Skill = capacidad, rule = límite · La regla se aplica a todas las tareas · Pocas y claras > muchas e ignoradas.
El núcleo esencial: no exponer secretos, preservar las APIs públicas, no eliminar logs de seguridad, no modificar directamente la base de datos de producción y generar evidencia de las pruebas.
Son las reglas cuya violación cuesta caro y es difícil de revertir: merecen estar escritas y, cuando sea posible, convertirse en gate.
Una regla crítica también se convierte en una verificación · La API pública es un contrato · La evidencia es una obligación, no una cortesía.
Reglas que fijan el límite de intentos, el tope de costo, la exigencia de aprobación antes de acciones destructivas y la prohibición de refactorizar fuera del alcance.
Es donde la gobernanza se une al ciclo: la rule es la versión escrita y permanente de los límites que configuraste en la ruta 2.
El límite escrito se aplica a todo agente · Lo destructivo requiere intervención humana · Una regla sin verificación depende de la obediencia.
🛡️ Gobernanza y niveles de autonomía
Identidad del agente, permisos, auditoría, control de costos, datos accesibles, política de seguridad y los cinco niveles de autonomía, desde asistente hasta crítico.
El conjunto de controles que define cómo puede operar la IA dentro de la empresa: identidad, permisos, responsabilidades, auditoría, logs, costos, entornos, datos, acciones prohibidas y gestión de incidentes.
Sin gobernanza, la adopción ocurre de cualquier manera, y la organización descubre sus reglas después del primer incidente.
La gobernanza habilita, no solo prohíbe · Control escrito > norma implícita · Debe encajar en el flujo de trabajo.
Credencial propia, alcance mínimo de acceso, responsabilidades declaradas y una pista de auditoría por acción.
Si un agente se ejecuta con la credencial personal de alguien, es imposible auditarlo y exigir responsabilidades; además, concede un acceso que nadie revisó.
Identidad propia siempre · Privilegio mínimo · Toda acción se puede rastrear hasta quien la autorizó.
Límite de gasto por equipo y por tarea, entornos autorizados para la ejecución, qué datos pueden entrar en el contexto y política de retención.
Un dato personal o un secreto en el contexto de un tercero es un incidente de privacidad, no un detalle técnico; y un costo sin límite se convierte en una sorpresa al cierre del mes.
Los datos sensibles no entran en el contexto · El entorno autorizado es una lista corta · El costo por tarea es una métrica de gestión.
Nivel 1: asistencia (solo sugiere) · 2: ejecución supervisada (se aprueba cada acción importante) · 3: ejecución controlada (tareas delimitadas con quality gates) · 4: autonomía operativa limitada (flujos completos dentro de reglas y entornos) · 5: autonomía crítica.
El nivel 5 no debe adoptarse sin controles extremadamente rigurosos. Saber dónde estás evita conversaciones confusas sobre «usar IA o no».
El nivel depende del tipo de tarea, no de la empresa · Subir de nivel exige el control del anterior · El nivel 5 es un límite, no una meta.
El proceso de dar más autonomía a un tipo de tarea con base en cifras: tasa de aprobación sin correcciones, incidentes causados, costo por tarea y tiempo de revisión.
La autonomía concedida por entusiasmo se revierte ante el primer susto, y entonces el equipo también pierde lo que ya funcionaba.
Medir antes de promover · Piloto delimitado · Revertir también es una decisión válida.
Un documento breve que responde: quién es el agente, a qué puede acceder, qué puede hacer por su cuenta, qué requiere aprobación, cuánto puede gastar, qué se registra y quién responde.
Es el artefacto que permite ampliar el uso de la IA a otros equipos sin repetir toda la discusión cada vez.
Una página, no un manual · Revisión periódica · Sin responsable, no existe gobernanza.