Qué le falta a las herramientas de IA para ser tomadas en serio
Una entrada de blog sostiene que los asistentes basados en LLM no están construidos para verificar sus respuestas y propone poner la comprobación de errores en el centro del producto.

Las herramientas de IA que usamos a diario no están construidas para trabajar en serio con ellas. Esa es la tesis de una entrada de blog publicada el 28 de septiembre, que enumera lo que le falta a los asistentes basados en LLM para dejar de parecer un truco. Su autor no discute la ética de los grandes laboratorios ni la calidad de los modelos: se fija en cómo están armados como producto, y sostiene que esa composición transmite la sensación de estar ante una estafa más que ante una herramienta.
Avisar del error no es gestionarlo
Todos los chatbots admiten sus límites, siempre en letra pequeña gris. Gemini recuerda que puede equivocarse y que hay que verificar las respuestas; Claude dice lo mismo; ChatGPT pide comprobar la información importante. El texto señala lo obvio: nadie sabe qué información es "importante". Y esos avisos están ahí para devolver la responsabilidad al usuario, no para ayudarle.
La propuesta es poner la comprobación en el centro: cada afirmación de la salida llevaría una casilla al lado, en un formato de dos columnas, con el texto generado a la izquierda y las notas humanas a la derecha explicando qué trabajo costó verificarlo. En los asistentes de código, igual. Hoy esa tarea se delega en la revisión de pares, y eso anima a quien firma el cambio a no mirar nunca su propio diff. También tendría sentido poder revisar los cambios antes de lanzar la batería de pruebas, sobre todo cuando quemar el clúster de tests sale más caro que generar el código.
Citas que se puedan leer
Con las fuentes pasa algo parecido. Los bots citan cuando les apetece y, cuando lo hacen, meten anotaciones en línea con el dominio del resultado en un tipo de letra ilegible. Esas citas vienen de mecanismos reales de grounding, no de tokens alucinados, pero el problema no es la maquinaria interna sino cómo se enseña al usuario. Aunque una cita salga de una consulta RAG, el modelo puede deformarla como cualquier otro dato de entrenamiento, así que ninguna respuesta debería presentarse como autoritativa.
De ahí la alternativa: cada consulta de investigación se devuelve como una lista de citas, y cada cita es un objeto grande con metadatos claros (sitio, fecha de publicación y autor si se conoce) y el fragmento literal, extraído por un programa normal y no por un LLM, en primer plano y con más peso visual que el texto generado.
Quien escribe apunta que los grandes laboratorios son el caso más llamativo, pero que todo esto vale igual para Ollama, que además lo necesita más por la menor calidad de los modelos que sirve. Tampoco es un problema sin precedentes: en el ecosistema MCP ya han aparecido piezas como los gateways de aprobación, aunque vivan fuera de la interfaz del asistente.
Lo que plantea no es un producto concreto, sino una lista de requisitos para construir uno. Y ahí está lo útil para quien tiene que decidir si mete un modelo en su flujo de trabajo: mientras la verificación siga siendo opcional, cara de hacer y fácil de saltarse, la única defensa real es tratar la salida del modelo como un borrador sin firmar.


