Código generado por IA: ¿es seguro y quién responde?
Por Alessandro Massoni 4 min de lectura
El código generado por IA rara vez falla donde uno lo espera. Compila, pasa la demo y se ve ordenado; el riesgo está en lo que no se ve en pantalla, como un permiso mal configurado o una librería que la IA inventó con un nombre convincente. Y cuando algo sale mal, la herramienta no firma nada: alguien tiene que responder.
En este artículo verás dónde están los riesgos reales, qué controles debe tener cualquier proyecto que use IA para programar, qué cambia si tu sistema además usa IA por dentro y quién responde cuando algo falla.
Dónde están los riesgos reales del código generado por IA
Un modelo de lenguaje produce el código más probable para lo que le pediste, no el más seguro para tu empresa. Si la petición no menciona la seguridad, la IA no tiene por qué priorizarla. Estos son los puntos que revisamos siempre:
- Permisos de datos: reglas de acceso ausentes o demasiado amplias, que dejan a un usuario ver información de otros.
- Librerías inexistentes o desactualizadas: la IA puede sugerir paquetes que no existen, y alguien puede publicarlos después con código malicioso.
- Validación de datos: formularios que aceptan cualquier cosa porque nadie pidió validarlos.
- Claves expuestas: credenciales escritas directamente en el código en vez de guardarse aparte.
- Lógica sin revisar: reglas de negocio que se ven bien pero no hacen lo que el negocio necesita.
Ninguno de estos riesgos es nuevo; existían antes de la IA. Lo nuevo es la velocidad: se puede producir en una tarde más código del que una persona alcanza a revisar en una semana. Por eso, cuando construimos aplicaciones a medida para empresas, la revisión es una etapa del proyecto y no un paso opcional al final.
Qué controles debe tener un proyecto con código generado por IA
La seguridad no depende de qué herramienta usa tu proveedor, sino del proceso que la rodea. Estos son los controles mínimos que deberías exigir:
- Reglas del proyecto escritas: qué tecnología se usa, qué está prohibido y qué requiere aprobación.
- Permisos mínimos para la IA: la herramienta solo accede a lo que necesita para cada tarea.
- Pruebas antes de aceptar un cambio: si no pasa la comprobación, no entra.
- Revisión humana contra la especificación, con foco en permisos y datos sensibles.
- Respaldos y exportación de datos que no dependan del proveedor.
En sistemas sobre Supabase, como los que construimos, el primer punto incluye definir políticas de acceso por fila: reglas en la base de datos que deciden qué registros puede ver cada usuario, aunque haya un error en la pantalla. Es el tipo de decisión que la IA no toma bien sola y que explicamos dentro del método completo de desarrollo de software con IA.
Si tu sistema usa IA por dentro, los riesgos son otros
Una cosa es usar IA para escribir el código y otra es que el sistema terminado use IA para operar, por ejemplo un asistente que responde a clientes o un agente que ejecuta acciones. En ese caso aparecen riesgos propios: instrucciones maliciosas escondidas en un texto que el sistema lee, o un agente con más permisos de los que necesita.
La referencia más usada para este tipo de sistemas es el proyecto de seguridad para IA generativa de OWASP, que mantiene un listado de los riesgos más críticos en aplicaciones con modelos de lenguaje. Si tu proyecto incluye IA dentro del producto, pídele a tu proveedor que te explique cómo aborda esos riesgos.
Quién responde cuando algo falla
La responsabilidad no se delega a la herramienta. Quien construyó el sistema responde por él, lo haya escrito a mano o con IA, y eso debería quedar claro antes de empezar. Si tu proveedor no puede explicarte cómo revisa lo que la IA genera, ese es el riesgo principal.
En nuestro caso, usamos Claude Code y revisamos cada entrega antes de que llegue a tu equipo. Tus datos se pueden exportar en CSV o SQL en cualquier momento, el código fuente se entrega si lo pides y la mantención la hace el mismo equipo que conoce el sistema. Los detalles están en nuestras preguntas frecuentes sobre desarrollo de aplicaciones.
Si el código lo generó alguien sin revisión, por ejemplo un prototipo armado por tu cuenta, conviene leer por qué el vibe coding no llega a producción y repasar los errores comunes en el desarrollo de sistemas empresariales.
¿Sabes hoy quién revisa el código de los sistemas que usa tu empresa? Conversemos sobre tu proyecto y te contamos qué revisaríamos primero.
Preguntas frecuentes
Puede serlo si hay proceso alrededor: reglas del proyecto, pruebas y revisión humana. Sin eso, los riesgos habituales son permisos de datos mal configurados, librerías inexistentes o desactualizadas, validaciones ausentes y claves expuestas.
Reglas escritas, permisos mínimos para la herramienta, pruebas antes de aceptar cada cambio, revisión humana contra la especificación y respaldos de datos que no dependan del proveedor.
Quien construyó el sistema, lo haya escrito a mano o con IA. La responsabilidad no se traspasa a la herramienta, y conviene dejarla clara antes de empezar el proyecto.
