Dejar que la IA toque producción: dónde pongo el límite

Le doy permisos bastante amplios. Que lea, que escriba, que ejecute cosas, que instale lo que necesite. Trabajar con la mano levantada aprobando cada paso mata todo el valor de la herramienta y acabas dándole a "sí" sin mirar, que es peor que no preguntar.

Y aun así hay tres cosas que no toca nunca sin que yo esté delante. Te las cuento con el criterio que hay detrás, que es lo que se puede aplicar a tu caso aunque tu montaje sea distinto.

¿Qué permisos le doy a un agente de IA?

El criterio no es "qué es peligroso". Es otro y es mucho más útil: ¿puedo deshacer esto en cinco minutos?

Si la respuesta es sí, permiso amplio y a correr. Que toque, que pruebe, que se equivoque. Los errores reversibles son gratis y frenarlos cuesta más de lo que ahorra.

Si la respuesta es no, freno obligatorio. Y da igual lo rutinaria que parezca la operación.

Con ese filtro, la mayoría del trabajo diario pasa sin fricción. Escribir código, crear archivos, reorganizar cosas, instalar dependencias, ejecutar pruebas: todo eso está bajo control de versiones y se revierte en un comando. Adelante.

Las tres cosas que no toca solo

Uno: la base de datos de producción.

Aquí no hay marcha atrás. Un borrado mal filtrado, una migración que va en la dirección equivocada, una actualización masiva con la condición mal puesta. El código lo revierto en segundos porque está en el historial. Los datos borrados no están en ningún historial.

Lo que hago: la herramienta puede escribir la migración, puede explicarme qué hace, puede probarla contra una copia. Ejecutarla contra producción lo hago yo, mirando, y con una copia de seguridad hecha justo antes. No es desconfianza en el modelo: yo tampoco me dejaría a mí mismo hacer eso a las once de la noche sin copia.

Dos: todo lo que sale hacia fuera.

Enviar correos a una lista. Publicar algo. Mandar un mensaje a alguien. Cualquier operación de pago.

El motivo es que esto no es irreversible en el sentido técnico, es irreversible en el sentido social. Un correo enviado a mil personas no se puede "deshacer" aunque mandes otro pidiendo perdón. La gente ya lo leyó.

Y aquí la probabilidad de error no es teórica. Basta un filtro mal entendido para que lo que iba a veinte personas se vaya a la lista entera. Así que el envío siempre lo dispara un humano después de mirar a quién va y qué dice.

Tres: las credenciales y quién puede entrar dónde.

Claves de acceso, tokens, permisos de usuarios, configuración del cortafuegos. Todo lo que decide quién puede tocar qué.

Este lo tengo bloqueado por una razón concreta: un error aquí no se nota. Si rompes el código, se cae y te enteras. Si abres un acceso que no debías, todo sigue funcionando perfectamente y no hay ninguna señal. Los errores silenciosos son los que más miedo me dan, porque el tiempo juega en contra en vez de a favor.

La red que hay debajo

Los límites solos no valen de nada si no tienes por dónde recuperarte. Cuatro cosas, todas aburridas.

Control de versiones en todo. No solo en código. Mi documentación, mis notas, mis configuraciones. Todo tiene historial. Eso es lo que convierte casi cualquier error en algo reversible, y es la razón por la que puedo dar permisos amplios con tranquilidad. Sobre cómo volver atrás cuando algo sale mal escribí aquí: checkpoints y deshacer en Claude Code.

Copias de seguridad automáticas de lo que no está versionado. Básicamente la base de datos. Diarias, a otro sitio distinto del que está la original.

Separar donde se prueba de donde vive lo bueno. Que exista un sitio donde romper cosas sin consecuencias cambia por completo lo que puedes delegar. La mayoría del miedo a dar permisos viene de no tener ese sitio.

Pruebas automáticas, aunque sean cuatro. No hace falta ser exhaustivo. Con que comprueben que las cosas críticas siguen funcionando, ya te avisan cuando algo se rompió por un lado que no mirabas. Y no hace falta saber escribirlas: se las puedes pedir, como conté en pruebas sin saber testear.

La vez que sí la lié

Sin dramatizar, porque no fue para tanto y precisamente por eso es útil contarlo.

Estaba reorganizando una estructura de carpetas. Trabajo aburrido, mucho movimiento de archivos, permisos amplios porque era exactamente el tipo de tarea reversible donde no quiero estar aprobando cada paso.

Y en medio del proceso acabaron borrados unos archivos que yo no quería borrar. La instrucción que di era ambigua y se ejecutó una interpretación razonable de lo que dije. El fallo era mío, en la instrucción, no en la ejecución.

Lo recuperé en un minuto porque estaba todo versionado. Fin de la historia. Y esa es justo la moraleja: no fue un desastre porque la red estaba puesta. Si esos archivos hubieran estado fuera del control de versiones, hoy no existirían.

Desde entonces tengo una costumbre nueva: antes de una tarea que toca muchos archivos, guardo el estado. Cuesta cinco segundos.

Lo que no me funcionó

Dos cosas que probé y descarté, por si te ahorro el intento.

Aprobar cada acción. Insostenible. A la media hora estás dando a "sí" en piloto automático y ya no estás revisando nada, solo añadiendo fricción. Peor que no tener nada, porque encima te da la falsa sensación de estar supervisando.

Permisos totales sin límites. Va bien hasta que va mal. Y como el trabajo diario es sobre todo reversible, la mayoría de los días no pasa nada, así que te confías. El problema aparece el día raro, que es el día en que estás cansado y hay algo importante de por medio.

Lo que funciona es la asimetría: casi todo abierto, tres cosas cerradas a cal y canto. Poca fricción en el 95% del trabajo y freno duro donde importa.

¿En qué me estaría equivocando?

En dos direcciones opuestas, según con quién hable.

Si vienes del mundo de la empresa con procesos serios, mis límites te van a parecer un chiste. Y tienes razón para tu contexto: con un equipo, clientes y responsabilidad legal, esto se gestiona con revisiones, entornos separados de verdad y aprobaciones formales. Yo trabajo prácticamente solo y me puedo permitir ser más ligero. No copies mi montaje si tu situación no es la mía.

Y si estás empezando, es al revés: probablemente mis tres límites te sobren, porque no tienes producción, ni lista de correo, ni servidor. Tu único límite útil es tener control de versiones desde el minuto uno, que es lo que convierte los errores en anécdotas. Si no sabes por dónde empezar con la herramienta, lo tengo en Claude Code para no programadores.

Donde creo que no me equivoco es en el criterio de fondo. No preguntes si la IA es de fiar. Pregunta si puedes deshacerlo. Es la misma pregunta que te harías antes de dejar que una persona nueva toque algo, y ahí nadie discute que sea razonable.

El resumen

Permisos amplios donde el error se deshace. Freno humano donde no.

Con esa regla he podido delegar muchísimo más de lo que delegaba al principio, cuando revisaba todo por miedo y avanzaba a paso de tortuga. La confianza no viene de fiarte más. Viene de tener la red puesta.

Si quieres montarte un sistema donde todo tu trabajo esté ordenado, versionado y recuperable, sin ser técnico, eso es exactamente lo que enseño en Yo SA.

Ver Yo SA