Gobernanza
La mayoría de empresas que adoptan agentes de código IA lo hacen sin una política escrita. Luego algo sale mal, un secreto se filtra en un prompt, un junior entrega código que nadie revisó, y la política se escribe bajo presión, y mal. Aquí tienes una política corta que puedes adaptar hoy, y una forma de que se cumpla de verdad.
"Usa el criterio" no es una política. Es lo que dices cuando no tienes una. Tus ingenieros van a usar agentes de código IA tengas o no una política, a menudo con cuentas personales y sin ninguna supervisión. Una política corta y escrita hace dos cosas: dice qué se espera antes de que la gente lo adivine, y te da algo a lo que apuntar cuando hay que justificar una decisión, ante un cliente, un auditor o un board.
Mantenla lo bastante corta como para que de verdad se lea. Estos seis puntos cubren las decisiones que importan:
Una política que solo vive en un documento se olvida en un mes. Las partes que importan deben aplicarse con herramientas, no con la memoria:
Una política que se lee como una lista de prohibiciones se acaba esquivando. Preséntala como quitar riesgo a algo que el equipo ya quiere hacer, no como bloquearlo. Involucra a dos o tres ingenieros senior en el primer borrador, pilótala en un equipo durante dos semanas y corrige lo poco práctico antes de desplegarla en toda la empresa. Publica el razonamiento, no solo las reglas: los ingenieros siguen una política que entienden.
Adáptala a tu contexto, mantén los seis puntos y ponla donde vive el manual de tu equipo de ingeniería:
Revisa la política cada trimestre, o cuando aparezca un tipo de herramienta nuevo. Nombra a un responsable, normalmente un ingeniero senior o el CTO, que la actualice y responda preguntas. Una política sin dueño queda obsoleta el mismo día que se publica.
Sí. El límite de datos y la obligación de revisión aplican a cualquier herramienta que vea tu código o sugiera cambios, autocomplete incluido. El punto de responsabilidad pesa menos para una sola línea sugerida, pero la regla de datos no cambia.
Trátala como una herramienta no aprobada según la política. El riesgo no es el modelo, es que código o datos de la empresa salgan por una cuenta que no controlas ni puedes auditar. Aprueba una cuenta de empresa para esa misma herramienta en lugar de intentar prohibir el comportamiento sin más.
Aplica el mismo escaneo de dependencias y licencias que ya usas para paquetes añadidos por personas, y asegúrate de que también corre sobre el código sugerido por IA antes del merge. Los agentes no comprueban la compatibilidad de licencias salvo que se lo pidas, y sugerirán lo que resuelva el problema más rápido.
Sí, una línea: los ingenieros junior deben poder explicar, con sus propias palabras, cualquier código generado por IA que entreguen, antes de que se revise. No cuesta nada exigirlo y es la mejor protección única contra la ilusión de competencia.
Gobernanza
Qué pregunta un auditor o un equipo de technology due diligence sobre código asistido por IA, qué evidencia ya tiene un equipo disciplinado y una checklist mínima para cerrar los huecos.
Fundamentos
El vibe coding y la ingeniería agéntica usan IA para escribir código, pero solo uno produce software que puedes llevar a producción. Aquí está la distinción y cómo llevar a un equipo al lado disciplinado.
Fundamentos
Un agente de código IA es más que un autocomplete y menos que un ingeniero senior. Aquí tienes una definición precisa, el bucle agéntico que lo hace 'agente' y lo que no es.
Una política vale lo que valen su despliegue y sus comprobaciones. Si quieres ayuda para adaptarla a tu contexto, integrarla en CI y conseguir que el equipo la adopte, es justo lo que hago en advisory.