La pregunta que todo cliente hace cuando descubre que la IA esta escribiendo codigo junto al equipo es siempre la misma. No va a tocar lo que no debia? No va a leer el secreto de mi base de datos? No va a tumbar mi produccion? Respuesta corta: aqui no puede. No porque confiemos mucho en ella. Es porque alguien escribio cuatro reglas antes de que ella empezara a teclear, y esas reglas estan versionadas en Git como cualquier otro pedazo de codigo.
Este texto explica las cuatro puertas que la IA encuentra cerradas cuando trabaja junto a nuestros desarrolladores, en lenguaje de negocio. Quien te esta vendiendo "IA con gobernanza" deberia poder mostrarte las puertas. Si no puede, estas pagando por una buena demo, no por gobernanza.
Por que existe este texto
Quien nunca trabajo con un desarrollador piensa que la IA escribe codigo sola, sin supervision. No es asi. Hay un humano leyendo cada cambio antes de que llegue cerca de la produccion. Pero el humano se cansa, el humano se descuida, el humano hace clic en "aceptar" a las 18h de un viernes. Por eso, ademas del humano, montamos una capa extra: bloqueos automaticos que se ejecutan cada vez que la IA intenta hacer algo. Esa es la capa que vamos a describir.
La logica es simple: defensa en capas. El humano revisa. La IA produce. El bloqueo automatico impide lo que ni siquiera deberia haberse intentado. Tres puntos de control, no uno.
Puerta 1: La IA no toca produccion. Punto.
Produccion es el entorno que usan tus clientes finales. Dev es la copia interna donde el equipo prueba antes. La regla aqui es dura: la IA opera solo en dev. Cualquier comando de la IA que intente tocar produccion se bloquea antes de ejecutarse.
Lo que se bloquea, en la practica:
- Subir codigo directo a la rama principal del proyecto sin revision.
- Aplicar un cambio de infraestructura en la nube (crear un servidor, tumbar un servidor, tocar un firewall).
- Publicar un paquete de software en el registro publico sin revision.
- Borrar datos, eliminar una tabla, borrar una instancia en la nube.
Quien aplica en produccion es un humano con responsabilidad de DevOps. La IA escribe, el humano aprueba y aplica. Dos pares de ojos siempre. El cliente paga por esa cautela: previsibilidad.
Puerta 2: La IA no crea ni lee un archivo de secreto
Los sistemas guardan credenciales (contrasena de la base de datos, clave de pago, token de integracion) en archivos llamados .env y parecidos. Esos archivos no van a Git, quedan fuera del control de versiones. La IA no puede leer ni crear esos archivos.
La regla es granular. Las plantillas de ejemplo, que muestran el formato del archivo sin traer un secreto real, estan liberadas. Los archivos con secreto real, certificados, claves privadas de servidor, cuentas de servicio de Firebase, de Google Cloud, todo bloqueado antes incluso de que la IA empiece a escribir.
Por que esto importa para tu proyecto: si la credencial de tu base de datos estuviera en un archivo de esta categoria, la IA ni siquiera tendria visibilidad de el. No se filtra lo que no se puede leer.
Puerta 3: La IA es auditada cada vez que guarda un archivo
Supongamos que la IA, en un momento de descuido, escribe una clave de API dentro de un archivo cualquiera. Puede pasar (es estadistica, no infalible). Para ese caso, todo archivo que la IA guarda pasa por un escaneo automatico justo despues.
Lo que el escaneo busca, en lenguaje de negocio:
- Credencial de servidor en la nube (AWS, Google, Anthropic, OpenAI).
- Token de integracion de pago (Mercado Pago, Stripe).
- Acceso a redes de codigo y comunicacion (GitHub, Slack).
- Enlace de base de datos que tenga una contrasena embebida en el.
- Contrasenas, tokens y cualquier texto que parezca un secreto.
Si se detecta algun patron, la IA recibe una alerta inmediata y se le instruye eliminarlo. Sucede en el mismo segundo. No es un escaneo nocturno. No es un proceso agendado para ejecutarse manana.
Puerta 4: Nada con secreto entra en el historial de Git
Git es el historial permanente del codigo. Lo que entra ahi queda registrado para siempre. Por eso la cuarta puerta: antes de cada confirmacion de un cambio en Git, un escaneo final es obligatorio. Si un secreto se escapo en las etapas anteriores, es interceptado aqui. La confirmacion no sucede.
Este es el ultimo punto de defensa. Despues de el, el secreto entraria al historial, y sacar un secreto del historial de Git es trabajoso y nunca queda totalmente limpio. Por eso la interceptacion es dura: bloquea, devuelve un mensaje de error, obliga a la correccion.
La prueba de que la puerta si traba
Paso mientras el equipo escribia este mismo texto. La persona estaba abriendo el pedido de revision en Git (una especie de acta de cambio) que documentaba las cuatro puertas. Para explicar lo que hace cada puerta, la descripcion del pedido mencionaba palabras como "produccion", "clave privada" y el nombre de comandos peligrosos.
Resultado: la propia puerta bloqueo al equipo tres veces. Rechazo el primer mensaje porque decia "produccion" cerca de "comando de infraestructura". Rechazo el segundo porque mencionaba "permiso inseguro". Rechazo el tercero porque el texto descriptivo contenia el patron tipico de una clave criptografica.
Puede parecer gracioso. No lo es. Es la prueba de que la puerta no revisa quien esta pasando, no tiene lista vip, no se relaja cuando es el propio equipo. Si ni nosotros pasamos cuando nos descuidamos, el secreto de un cliente tampoco pasa.
Politica versionada, no promesa verbal
Todo esto, las cuatro puertas, vive en un archivo de Git. Cualquier persona del equipo lo abre, lo lee, lo audita, propone un cambio. No es una promesa que hacemos en una reunion. Es un archivo que tiene historial de quien lo toco, cuando, y por que.
Para el cliente, esto significa tres cosas practicas:
- Auditabilidad real. Puedes pedir ver el archivo. Nosotros lo mostramos.
- Politica igual para todos. No hay cliente A y cliente B. La regla es una sola, para todo proyecto que pasa por Steply.
- Evolucion rastreada. Cuando endurecemos una regla (agregamos un nuevo patron de credencial para detectar, por ejemplo), queda registrado.
LGPD, contrato de procesamiento de datos, auditoria de proveedor: todo eso se vuelve mas simple cuando la regla esta en un archivo, no en la cabeza de alguien.
Que cambia para tu proyecto
Si estas evaluando trabajar con IA en la construccion de tu producto, y eres el decisor que tiene que responder ante el consejo sobre el riesgo, la pregunta correcta no es "usan IA?". La pregunta es: como impide el proveedor que la IA haga lo que no deberia? Si la respuesta incluye una frase tipo "confiamos en el equipo", sigue buscando.
Nuestra respuesta es diferente. Tratamos a la IA como un vendor con guard-rails versionados, igual que trataria a un pasante con acceso restringido. Quieres entender como aplicar esta logica en tu proyecto, una conversacion rapida lo resuelve: habla con nosotros, te mostramos las puertas funcionando en vivo.