IA en producción (5/6): «ni una sola línea de código»

«No he escrito ni una sola línea de código.»

Lo dijo el fundador de Moltbook, una red social donde agentes autónomos se relacionan entre sí, y lo dijo con orgullo, como quien enseña un truco. Era, además, verdad.

A los pocos días del lanzamiento, unos investigadores de seguridad dieron con ello y publicaron poco después lo que habían encontrado: la base de datos entera abierta a lectura y escritura para cualquiera. 1,5 millones de tokens de autenticación de API, unas 35.000 direcciones de correo, varios miles de mensajes privados.

Vamos con la quinta entrega de la serie, que es la que más me duele profesionalmente. Van los desastres, los permisos, las copias y la respuesta plausible.

La postura correcta de las manos. La parte que se ve nunca fue la difícil. Foto: Queensland State Archives, dominio público, vía Wikimedia Commons.

Lo que falló en Moltbook no fue un fallo

Y esto hay que entenderlo bien, porque es todo el asunto.

La clave de la base de datos iba en el JavaScript del navegador. Eso, por sí solo, no es un error: en esa arquitectura, esa clave está diseñada para ser pública. Va en el cliente a propósito. Lo que impide que sirva para llevárselo todo es una segunda cosa, que se configura aparte: las reglas de seguridad a nivel de fila, que definen qué filas puede ver o tocar cada quién.

Moltbook tenía la primera parte y no tenía la segunda.

Ahora, la pregunta del millón: ¿qué habría fallado si lo hubieras probado?

Nada. Absolutamente nada.

La aplicación funcionaba. Los usuarios se registraban, publicaban, se enviaban mensajes. Todos los flujos, correctos. La demo, impecable. De hecho —y aquí está el veneno— sin esas reglas la aplicación funciona mejor: no hay permisos que ajustar, no hay consultas que fallen por falta de acceso, no hay ese rato incómodo depurando por qué un usuario legítimo no ve sus propios datos.

Quitar la seguridad no rompe nada. Quitar la seguridad arregla cosas, a corto plazo.

Ese es el sesgo. Y no es un sesgo del modelo: es un sesgo de la realidad, que el modelo se limita a heredar.

Lo que dicen los números

No es una impresión mía. Está medido, y bastante bien.

Veracode publicó en 2025 un informe sobre seguridad del código generado: 80 tareas de programación seleccionadas, pasadas por más de 100 modelos distintos. El resultado: cuando existía una forma segura y una insegura de resolver la tarea, los modelos eligieron la insegura el 45 % de las veces.

Y el dato que de verdad importa, que es la evolución:

• Corrección sintáctica: por encima del 95 %. El código compila, se ejecuta y hace lo que le pides.
• Tasa de aprobado en seguridad: en torno al 55 %. Prácticamente idéntica a la de dos años antes.

Léelo otra vez, porque es la frase más importante de esta entrega: la parte funcional ha mejorado muchísimo y la parte de seguridad no se ha movido.

Por lenguajes, Java salía como el peor parado, con un 72 % de fallo en las tareas de seguridad de aquella edición. Y no fue cosa de un año suelto: las ediciones posteriores del mismo estudio siguen situando la tasa media de aprobado en seguridad en torno al 56 %.

Y sobre lo que se despliega, un escaneo de Escape.tech sobre 5.600 aplicaciones construidas con herramientas de generación encontró más de 2.000 vulnerabilidades de alto impacto, más de 400 secretos expuestos —claves de API, credenciales, tokens— y 175 casos de datos personales accesibles, incluidos datos bancarios. No hallazgos teóricos de un analizador estático quisquilloso: aplicaciones en producción, con usuarios dentro.

Por qué pasa esto (que no es porque el modelo sea tonto)

Hay al menos dos mecanismos que ayudan a explicarlo, y un modelo más capaz no los elimina automáticamente.

1. Aprendió de tutoriales

El material de entrenamiento es, en buena parte, código público. ¿Y qué es la mayor parte del código público? Ejemplos. Tutoriales. Respuestas de foro. Repositorios de demostración.

Y todo ese corpus tiene una característica común: omite la seguridad a propósito, para que se entienda el concepto. El tutorial de cómo conectar con la base de datos no valida la entrada, porque el tutorial va de conectar con la base de datos. La respuesta del foro pone la clave en línea, porque el que preguntaba tenía un problema de conexión, no de gestión de secretos. En el mejor de los casos hay un comentario que dice «no hagas esto en producción», que es exactamente el tipo de matiz que se pierde al aprender un patrón.

Hemos entrenado a la herramienta con la mayor colección de ejemplos didácticos de la historia. Y los ejemplos didácticos están hechos para funcionar, no para aguantar.

2. Optimiza hacia «funciona»

Cuando pides una aplicación, el criterio de éxito implícito —y explícito, y el que tú vas a comprobar— es que funcione. Lo probarás abriéndola. Si hace lo que querías, aprobado.

La seguridad no aparece en esa prueba. Ni en ninguna otra que vayas a hacer, salvo que la hagas a propósito. Es un requisito no funcional, y los requisitos no funcionales tienen todos el mismo problema: nadie los echa de menos hasta el día del incidente.

La lista es siempre la misma, por cierto:

• Control de acceso a nivel de dato.
• Validación de entrada en el servidor, no solo en el formulario.
• Límites de peticiones.
• Gestión de secretos.
• Registro de actividad suficiente para investigar después.
• Cifrado de lo que hay que cifrar.

Ninguna de esas seis cosas se nota en una demo. Las seis se notan mucho en un juzgado.

Un apunte de justicia, que ya sabes que me gusta ponerlo: si le pides seguridad explícitamente, el resultado mejora. Le dices «revisa este endpoint buscando problemas de autorización» y encuentra cosas que a mí se me habrían pasado. Ojo con lo que eso significa y con lo que no: pedirlo sirve y saca problemas reales, pero no garantiza que el código quede seguro ni sustituye a una auditoría o a una revisión profesional. El problema, en todo caso, no es solo de capacidad. Un asistente puede sacar el tema por su cuenta, según el producto, el contexto y las instrucciones que lleve detrás; lo que no se puede es contar con que lo haga de forma consistente si la seguridad no forma parte explícita del encargo y del proceso. Y quien no sabe que existe la pregunta, no la hace.

Que es, exactamente, el perfil de la persona que presume de no haber escrito ni una línea de código.

El problema de fondo: lo que el generador no te dice

Cuando un desarrollador con oficio recibe una aplicación terminada, tiene una lista mental de cosas que va a comprobar antes de enseñársela a nadie. Esa lista no está escrita en ninguna parte. Se forma con los años, normalmente a base de sustos, y es literalmente lo que le pagan.

El generador entrega el mismo artefacto sin esa lista. Y como el artefacto funciona, la ausencia de la lista es invisible.

Lo conté hablando de por qué «aquí no hay nada que robar» es una frase peligrosa: la falsa sensación de seguridad no viene de ser optimista, viene de no saber qué es lo que hay que mirar. Antes, para llegar a producción, tenías que atravesar a alguien que sí lo sabía. Ahora puedes llegar el mismo día, tú solo, y el camino está despejado.

No hemos eliminado la barrera de entrada al desarrollo. Hemos eliminado la barrera de salida a producción. Que era la que servía para algo.

En pequeño, eso es parte de por qué el horizonte se ha quedado en «mañana»: si algo llega a producción antes de que haya dado tiempo a preguntarse qué puede fallar, la velocidad ya ha decidido por ti.

Lo mínimo antes de publicar algo generado

Si has construido algo así —y no pasa nada, yo también genero código todos los días—, esto es el suelo, no el techo:

1. Pregunta explícitamente por la seguridad. «Revisa este código buscando problemas de autorización, validación de entrada y secretos expuestos.» Cuesta un minuto y encuentra cosas. No sustituye a una auditoría; sustituye a no hacer nada, que es lo que hay ahora.
2. Abre las herramientas de desarrollo del navegador y mira qué se envía. Si ves una clave, entérate de si esa clave debe ser pública y qué la protege. Esa única comprobación habría salvado a Moltbook.
3. Intenta ver los datos de otro usuario. Cambia un identificador en la URL. Es la prueba de seguridad más barata que existe y sigue funcionando en 2026 con una frecuencia deprimente.
4. Busca secretos en el repositorio antes del primer despliegue. Hay herramientas gratuitas que lo hacen en segundos. Y recuerda lo que vimos sobre permisos: si el secreto se filtró, la pregunta ya no es cómo, sino qué alcance tenía.
5. Pon un límite de peticiones antes de abrir al público. Contra el abuso, contra el error, y contra la factura del proveedor.
6. Si maneja datos de personas, que lo mire alguien. Una hora de un profesional. Una. Es la compra con mejor relación coste/beneficio de todo tu proyecto, y lo digo sabiendo perfectamente que cobro por eso.

El taladro, quinta parte

Esta entrega es la que mejor encaja con la metáfora, así que la cierro aquí.

El mejor taladro del mundo hace un agujero perfecto en el sitio que le señales. Lo que no hace es decirte que ese tabique es de carga.

No porque sea mal taladro. Porque no es su trabajo, no tiene forma de saberlo, y la casa se aguanta igual el primer día.

Se aguanta el primer día, el segundo y el mes siguiente. El problema con las estructuras es que avisan tarde y avisan una sola vez.