Los asistentes y agentes de IA pueden leer, modificar y ejecutar código dentro del entorno de desarrollo. Este Informe USERS propone construir una política propia en cuatro pasos: definir qué información puede conocer la IA, qué acciones puede realizar y qué controles debe superar su trabajo antes de integrarse.
Autor: Elisa Belmar
Clasificar por capacidad, no por marca
El punto de partida no es prohibir sino mirar. Antes de escribir una sola regla, conviene clasificar cada herramienta por las capacidades que tiene habilitadas, no por su nombre ni por su fabricante.
Esas capacidades van desde recibir una función pegada a mano hasta ejecutar comandos en la terminal o tocar bases de datos. Una misma herramienta puede resultar inofensiva o peligrosa según lo que tenga activado.
Lo que hay que proteger tampoco se reduce al código fuente. Un archivo .env guarda credenciales que un agente podría encontrar aunque la tarea no lo pida, y las bases de prueba suelen ser copias de producción con datos reales.
Los datos personales piden un cuidado aparte: una vez enviados a un servicio externo, se pierde el control sobre dónde quedan y quién los procesa. El resultado de este paso es un inventario de lo que hay que cuidar y por qué.
Un agente puede recibir el objetivo “corrige este error” y necesitar inspeccionar archivos, modificar código, ejecutar pruebas y usar la terminal. Si además tiene acceso a Internet, Git o bases de datos, deja de ser un generador de código: puede realizar acciones dentro de nuestro entorno.
Mínimo privilegio: qué puede conocer y hacer
Con el inventario a la vista, el segundo paso lo convierte en reglas y separa dos preguntas distintas: qué puede conocer la IA y qué puede hacer.
La información se ordena en tres niveles: permitido, requiere autorización y prohibido. En el último quedan las credenciales, los secretos y los datos personales reales, que no deberían llegar nunca a una IA para desarrollar o probar código.
Acá aparece el principio que atraviesa toda la política: el mínimo privilegio. Que un agente pueda recorrer todo un repositorio no significa que deba hacerlo. Si la tarea es tocar la interfaz, no necesita acceder a datos de usuarios reales.
Los permisos de acción también se separan en lugar de habilitarse en bloque: no es lo mismo leer archivos que modificarlos, correr comandos o desplegar en un entorno publicado.
El cruce de esos permisos con cada recurso arma una matriz. Algunas operaciones pueden autorizarse pero no correrse en automático: instalar una dependencia o hacer un push piden intervención humana cuando son difíciles de revertir.
El mínimo privilegio consiste en dar solo los accesos necesarios para una tarea y dejar el resto fuera de alcance. Tener acceso no es lo mismo que necesitar acceso: que un agente pueda recorrer todo un repositorio no significa que deba hacerlo. Si la tarea es modificar la interfaz, probablemente no necesite consultar copias de bases de datos con información de usuarios reales.
Controlar el resultado y mantener viva la política
Limitar los permisos reduce el riesgo mientras se trabaja, pero falta controlar lo que queda. El código que genera una IA no debería tener un camino especial hacia el proyecto: tiene que superar los mismos controles que cualquier otro cambio.
Ese circuito encadena la revisión del diff, las pruebas, los controles de seguridad y la aprobación final. Que las pruebas pasen dice que el código funciona, no que sea seguro: son dos preguntas distintas.
La revisión del diff (la comparación entre el estado anterior y el nuevo) verifica que no aparezcan secretos ni datos personales incrustados. La seguridad suma el análisis estático y la revisión de dependencias, además de mantener la red cerrada por defecto.
Producción merece una frontera aparte, porque ahí están los sistemas y los datos de las personas reales. El acceso a esos entornos no debe heredarse de los permisos de desarrollo.
El último paso escribe todo en una política breve. Sirve una prueba simple: si alguien que recién entra al equipo puede decidir qué está permitido sin interpretar la intención de quien la redactó, la regla cumple su función.
La política no se revisa solo por calendario. Si una herramienta incorpora nuevos accesos o permisos, cambia el riesgo que se había aceptado, así que conviene que viva junto al proyecto y se actualice cuando cambian sus capacidades.
Una política bien construida no queda vieja cada vez que aparece un producto nuevo. Una buena política no busca impedir que la IA programe: define el espacio dentro del cual puede ayudarnos, qué puede conocer, qué puede hacer y qué controles debe superar su trabajo antes de convertirse en parte de nuestro software.
Encuentra la versión completa de la publicación en la que se basa este resumen, con todos los detalles técnicos en RedUSERS PREMIUM
También te puede interesar:
REFACTORIZAR CON IA
El código que crece termina perdiendo claridad y volviéndose difícil de mantener. Este Informe USERS explica cómo refactorizarlo con agentes de inteligencia artificial como Claude Code y Codex, siguiendo todo el proceso sobre un mismo ejemplo: una aplicación PHP para administrar una biblioteca.
Lee todo lo que quieras, donde vayas, contenidos exclusivos por una mínima cuota mensual. Solo en RedUSERS PREMIUM: SUSCRIBETE!
