Aceptar una advertencia en pantalla puede ser suficiente para empezar a utilizar un programa. El clic, sin embargo, deja intactos los fallos que ese software pueda contener. Chema Alonso sitúa ahí una de sus críticas al desarrollo de la inteligencia artificial: el usuario acaba asumiendo riesgos que el fabricante debería haber tratado antes de ofrecer el producto.La preocupación aumenta cuando el sistema puede actuar sobre otros servicios. Una respuesta equivocada puede quedarse en un texto que alguien descarta; una orden ejecutada puede modificar información o enviar un mensaje. La diferencia está en los permisos y herramientas disponibles, además de en la calidad de las respuestas del modelo.El informático reclama controles de calidad y correcciones para las vulnerabilidades conocidas. Su advertencia se dirige a cómo se construyen y despliegan los productos, en una etapa en la que algunos asistentes reciben capacidad para elegir pasos y realizar tareas con menos intervención de la persona que los utiliza.Un aviso no corrige un falloAlonso expuso esta posición en su blog personal, Un informático en el lado del mal, el 16 de septiembre de 2026. Allí expresa su temor a que el sector reaccione después de un incidente. Lo vincula a la responsabilidad de los fabricantes de subsanar fallos conocidos y aplicar medidas de seguridad razonables antes de dejar al cliente frente a ellos.Su planteamiento admite un límite: no es posible garantizar que nunca aparecerá una vulnerabilidad nueva. La exigencia está en disponer de un proceso de calidad y corregir lo que ya se conoce. Ese criterio permite examinar los errores de los modelos sin confundir un resultado convincente con uno fiable, ni el rendimiento de una demostración con la seguridad del producto completo.El Instituto Nacional de Estándares y Tecnología de Estados Unidos, NIST, dedica su perfil de riesgos de IA generativa a problemas concretos, entre ellos las respuestas falsas formuladas con seguridad y la privacidad de los datos. El documento propone pruebas antes del despliegue y seguimiento de incidentes. Su utilidad reside en evaluar riesgos durante todo el uso, más allá de una advertencia inicial.El organismo también describe las limitaciones de las pruebas en laboratorio: pueden no representar las condiciones reales en las que se utilizará el sistema. Esa distancia afecta a la confianza en la IA. Superar una batería de ejercicios aporta información, pero no garantiza el mismo comportamiento en cualquier tarea, con otros datos o conectado a nuevas herramientas.Cuando el asistente puede actuarLa organización OWASP identifica un riesgo relacionado con dar a los agentes más funciones, permisos o autonomía de los necesarios. En su documentación plantea un ejemplo sencillo: un asistente pensado para leer documentos puede tener también capacidad para modificarlos o borrarlos. El fallo adquiere otra dimensión cuando la aplicación puede cambiar el original.Las medidas que propone incluyen limitar las herramientas disponibles y los permisos concedidos, además de introducir revisión humana en las acciones que lo requieran. Son controles sobre lo que el programa puede hacer. La discusión sobre IA privada también exige conocer a qué información accede el sistema y hasta dónde llegan sus autorizaciones.Para una empresa, esa diferencia aparece al conectar un asistente con documentos, correo o bases de datos. El rendimiento incluye la utilidad del resultado y el coste de comprobarlo, una preocupación presente en los debates sobre contenido generado por IA. Antes de delegar una tarea, debe quedar definido quién puede autorizar una acción y qué operaciones quedan fuera del alcance del programa.La petición de Alonso devuelve la atención al fabricante y al diseño. Corregir una vulnerabilidad, reducir un permiso o impedir una operación innecesaria cambia el funcionamiento del producto. Marcar una casilla solo acredita que alguien ha aceptado un aviso; el defecto técnico seguirá ahí hasta que se resuelva.