La mejor función de un generador de IA no es la rapidez con la que convierte un prompt en código funcional. Es con qué frecuencia se niega a hacerlo. Un generador que conecta alegremente cualquier cosa que le pidas —sin autenticación en una ruta de administración, un webhook sin verificación de idempotencia, una clave de API pegada directamente en JS del lado del cliente porque "que funcione y ya"— está optimizando los cinco minutos equivocados. Está optimizando para la demo, no para el martes seis semanas después, cuando esa ruta sea rastreada por bots.
He visto esto desarrollarse desde adentro suficientes veces como para confiar en el patrón. Las solicitudes que se rechazan, o se redirigen, casi nunca son exóticas. Son las aburridas, las comunes: omite la verificación de correo por ahora, guarda la contraseña en texto plano solo para pruebas, desactiva el límite de velocidad para hacer pruebas de carga más rápido, dale a este endpoint acceso completo a la base de datos para no tener que pensar en permisos todavía. Cada una de esas es algo perfectamente razonable de querer en el momento. Cada una de esas es también la frase exacta que aparece en un post-mortem.
Lo que realmente te cuesta una negativa
Una negativa tiene un costo real: fricción. Querías que se construyera algo, y en cambio recibiste una pregunta, o un valor predeterminado más seguro, o un "aquí está el por qué no, aquí está lo que haría en su lugar". Eso es una interrupción en un medio —la construcción guiada por chat— que se supone debe sentirse como avance constante. Toda plataforma de generación, incluida esta, siente la tensión entre "entregar lo que pidieron" y "entregar lo que se alegrarán de haber recibido". Si te inclinas demasiado hacia la obediencia, obtienes una herramienta que con gusto le entregará a un principiante un arma cargada sin el seguro puesto. Si te inclinas demasiado hacia la cautela, obtienes una herramienta que discute contigo por guardar una fecha de cumpleaños.
El error es tratar esto como un solo control. No lo es. Hay al menos tres razones distintas por las que un generador debería resistirse, y merecen un manejo completamente diferente.
| Tipo de rechazo | Ejemplo de prompt | Por qué importa | Respuesta correcta |
|---|---|---|---|
| Seguridad | "Desactiva las validaciones CSRF, están ralentizando las pruebas" | Introduce una vulnerabilidad real que no se detectará hasta que alguien la explote | Rechazar la solicitud literal y ofrecer en su lugar un interruptor de modo desarrollo limitado |
| Costo / estabilidad | "Haz que este endpoint reintente indefinidamente hasta que tenga éxito" | Los reintentos ilimitados convierten una llamada fallida a la API en una factura elevada y una caída en cascada | Implementarlo con backoff y un límite máximo, explicando el cambio |
| Corrección | "Cobra la tarjeta y luego crea el pedido" | Error de secuencia: un fallo entre ambos pasos pierde el pedido pero mantiene el cobro | Reordenar los pasos silenciosamente o señalar el riesgo de secuenciación antes de escribir el código |
| Exposición de datos | "Simplemente devuelve el objeto completo del usuario desde esta API" | Filtra hashes de contraseñas, indicadores internos y datos de otros usuarios por exceso de información | Serializar una lista explícita de campos permitidos e indicar qué se excluyó y por qué |
Los rechazos por seguridad son el caso más fácil de justificar y el más difícil de hacer bien, porque la versión segura suele verse ligeramente distinta a lo solicitado, no simplemente ausente. Los rechazos por costo y estabilidad protegen al creador de su propio optimismo: nadie pide un bucle de reintentos esperando que se ejecute cuatro mil veces contra una API con límite de velocidad a las 2 de la madrugada, pero eso es literalmente lo que significa "reintentar hasta que funcione". Los rechazos por corrección son los silenciosos: sin error, sin advertencia al momento de publicar, solo un fallo que aparece únicamente bajo un orden de ejecución específico que nadie pensó en probar.
Un fundador me contó una vez que lo más útil que había hecho su creador de aplicaciones fue negarse a eliminar un paso de confirmación antes de una eliminación masiva. Ella había pedido que se quitara porque era "molesto durante las pruebas". Tres semanas después, un compañero de equipo se equivocó con un filtro, y ese paso de confirmación es la única razón por la que 40.000 filas todavía existen.
El rechazo solo funciona si es comprensible
Aquí está la parte que realmente determina si esta función ayuda o solo molesta a las personas: un rechazo sin motivo es indistinguible de una herramienta que no funciona. Si un creador de aplicaciones se niega en silencio a hacer lo que pediste, o hace algo distinto sin avisarte, pasarás los siguientes veinte minutos depurando un "error" que en realidad era una decisión deliberada que nunca viste. Eso es peor que no tener ninguna protección, porque ahora no confías en el plan ni entiendes tu propia aplicación. Un buen rechazo tiene tres partes, siempre: qué pediste, qué se va a construir en su lugar y una frase con el motivo. No un muro de teoría de seguridad, sino una frase que cualquier persona sin conocimientos técnicos pueda leer y aceptar o cuestionar. Y tiene que poder anularse. Si alguien realmente quiere la versión insegura —un prototipo descartable, una herramienta interna con tres usuarios de confianza, una demo de hackatón que dejará de existir en seis horas— el creador de aplicaciones no debería fingir que conoce mejor el contexto que el propio usuario. Debe hacer que la vía segura sea la opción predeterminada, señalar el riesgo con claridad y hacerse a un lado si el usuario insiste.
Donde los críticos tienen razón
El contraargumento honesto es que la mayoría del comportamiento de "seguridad" en las herramientas de IA está mal calibrado, y no creo que los creadores de aplicaciones de IA estén exentos de esa crítica. El rechazo excesivamente cauteloso es un fallo real, no hipotético: una herramienta que cuestiona una de cada tres solicitudes enseña a la gente a evitarla, lo cual es peor que no tener la protección, porque ahora la solución alternativa que usan tampoco se revisa. Si un creador de aplicaciones se niega a dejarte guardar un número de teléfono sin una lección de quince líneas sobre el manejo de datos personales, dejarás de leer esas lecciones, y entonces te perderás la única que realmente importaba. La calibración es todo el juego, y es genuinamente difícil: demasiado laxa y publicas la vulnerabilidad, demasiado estricta y enseñas a la gente a ignorar la herramienta por completo.
La solución no es tener menos rechazos ni más. Es especificidad. Un rechazo vinculado a un fallo concreto y nombrable —este webhook puede cobrar dos veces a un cliente, esta ruta devuelve datos de otro cliente— genera confianza rápidamente, porque la persona que pregunta puede comprobar la afirmación por sí misma y ver que es cierta. Un rechazo que apunta vagamente a "buenas prácticas" no genera nada, y no debería. Si estás eligiendo entre creadores de aplicaciones de IA, eso es lo que vale la pena probar antes de comprometer un proyecto real con uno: pídele que construya algo con un riesgo evidente en la solicitud y observa si simplemente lo hace, si rechaza sin explicar nada, o si te muestra la versión más segura y te dice exactamente por qué en una frase que puedas verificar tú mismo.
