Saltar al contenido
Implementa.

Crear un agente IA · Guía 14 de 14

Qué hace un agente de IA cuando no sabe la respuesta: la duda se diseña, no se espera

Nadie compra un agente pensando en cómo se va a portar el día que no sepa algo, y ese día llega la primera semana. Qué hace un agente de IA cuando no sabe la respuesta no es un detalle de implementación: es lo que decide si el sistema se puede usar. El que se calla a tiempo cuesta una derivación; el que contesta igual, con aplomo y sin avisar, cuesta el error más el tiempo de encontrarlo. Aquí va cómo se fabrica la duda —señales que no dependen de que el modelo sea sincero, verificación obligatoria antes de tocar nada, umbral atado a la capacidad real del equipo— y qué tiene que viajar en el traspaso.

Qué hace un agente de IA cuando no sabe la respuesta (y qué hace el tuyo hoy)

Un agente bien diseñado hace tres cosas y en este orden: detecta que no sabe por una señal medible, se abstiene de responder o de actuar, y traspasa el caso a una persona con el contexto ya recogido. Un agente mal diseñado hace una sola: contesta igual. Y contesta rápido, bien escrito y con aplomo, que es justo lo que convierte el fallo en caro, porque así nadie lo mira dos veces.

De ahí la tesis de esta guía, que suena a exageración y no lo es: un agente que nunca duda es el más peligroso que puedes tener. Una duda que se ve —«esto no lo sé, te paso con quien sí»— cuesta una derivación. Una duda que no se ve —una respuesta plausible y falsa, un campo rellenado a ojo, un reembolso aprobado sin base— cuesta el error más el tiempo de encontrarlo, y el segundo sumando casi siempre es mayor que el primero. Por eso un agente no se juzga por lo que hace en su mejor caso: se juzga por lo que hace en el peor.

Lo que viene no va de ajustar el modelo. Bajar la invención a nivel de respuesta —grounding, citas, una recuperación decente— es otro trabajo y hay que hacerlo: está en reducir alucinaciones de IA en producción. Esta guía va de lo que rodea al momento de la duda, que se diseña en tu sistema y vale igual para un agente de soporte, uno que lee facturas y uno que prepara un informe. Los criterios concretos de paso a humano de un chatbot están en crear un chatbot de IA; aquí va la pieza general.

Tu agente está entrenado para no callarse nunca

Antes de diseñar nada hay que aceptar el punto de partida, y es incómodo: el modelo que llevas debajo viene con un sesgo de fábrica contra el silencio. No es una opinión de consultor contrario. El trabajo de Kalai, Nachum, Vempala y Zhang lo formula sin adornos: los modelos de lenguaje alucinan porque los procedimientos de entrenamiento y evaluación premian adivinar por encima de reconocer la incertidumbre, y el problema persiste por cómo se corrigen la mayoría de evaluaciones, que optimizan al modelo para ser un buen examinando —y un buen examinando, cuando no sabe, contesta igual—. Fuente: Why Language Models Hallucinate, Kalai, Nachum, Vempala y Zhang (OpenAI), 4 de septiembre de 2025, consultado el 13 de septiembre de 2026.

El corolario operativo es el que importa: la abstención no es un comportamiento latente que puedas despertar con una frase en el prompt. «Si no lo sabes, dilo» ayuda en el margen y falla justo donde duele, porque le estás pidiendo prudencia a un sistema entrenado para lo contrario. La duda hay que fabricarla fuera del modelo: señales que calcula el sistema, comprobaciones que se ejecutan antes de actuar y una salida a una persona que existe de verdad.

Hay una segunda trampa, más popular todavía: preguntarle al modelo cuánta confianza tiene. No funciona, y está medido. La evaluación de Xiong y colegas sobre elicitación de confianza encontró que los modelos son muy sobreconfiados al verbalizar su confianza, con valores que se concentran de forma abrumadora entre el 80 % y el 100 %. Fuente: Can LLMs Express Their Uncertainty?, Xiong et al., ICLR 2024, consultado el 13 de septiembre de 2026. Un número que casi siempre dice noventa no es una señal: es un adorno.

Las señales de duda que sirven, y la que usa todo el mundo

La duda útil no sale del modelo: sale del sistema que lo rodea. Son señales calculables, cada una con su disparador, y ninguna necesita que el modelo sea sincero.

SeñalDe dónde saleQué la dispara
Cobertura de la fuenteEl paso de recuperación, no el modeloNo hay pasaje por encima del umbral, o el que hay no contiene el dato que se pide
Desacuerdo consigo mismoDos pasadas sobre la misma entradaLas dos respuestas no coinciden en el dato que importa
Contrato de salida rotoLa validación, antes de que nada se escribaFalta un campo obligatorio, un importe no es número, una fecha no existe
Regla dura de negocioTu política, no el modeloImporte por encima del límite, cliente sin histórico, dato regulado, país fuera de cobertura
Contador de fracasoEl orquestadorN reintentos o N turnos sin avanzar
Petición explícitaLa persona del otro lado«quiero hablar con alguien»

Las tres primeras se montan el mismo día y son las que más cazan. La de cobertura es la que más rinde por euro invertido: si el agente responde sobre tus documentos y el recuperador no ha traído nada relevante, ya sabes que lo que venga después es invención, sin necesidad de leerlo. Es binaria, barata y anterior a la respuesta.

Un matiz que evita el error de diseño más común: estas señales no se suman en un número mágico. Cada una pide un tratamiento distinto. La cobertura vacía se resuelve diciendo «no tengo esto documentado» y traspasando. El contrato roto se resuelve con un reintento acotado y, si vuelve a romper, cola. La regla dura no negocia con ninguna otra señal: si el importe pasa el límite, pasa a una persona aunque el agente esté segurísimo. Un marcador global de confianza mezcla cosas que no se parecen y acaba escondiendo las tres.

Antes de actuar, verificar: dudar al responder no es dudar al ejecutar

La abstención tiene dos versiones y confundirlas sale caro. Abstenerse de responder es barato: si te callas de más, alguien contesta después. Abstenerse de actuar es otra liga, porque una acción mal hecha deja rastro en un sistema y deshacerla cuesta más que hacerla. El listón no puede ser el mismo en los dos sitios.

La guía de OpenAI para construir agentes lo ordena por herramienta, no por conversación: recomienda evaluar el riesgo de cada herramienta del agente y darle una calificación —bajo, medio o alto— según si es de solo lectura o de escritura, si la acción es reversible, qué permisos exige y qué impacto económico tiene; y usar esa calificación para disparar acciones automáticas, como parar a comprobar antes de ejecutar funciones de alto riesgo o escalar a una persona. Sobre la intervención humana es igual de concreta: los dos disparadores habituales son superar umbrales de fallo —límites de reintentos, o no entender la intención del usuario tras varios intentos— y las acciones de alto riesgo, sensibles, irreversibles o con mucho en juego, como cancelar pedidos, autorizar reembolsos grandes o hacer pagos. Fuente: A practical guide to building agents, OpenAI, consultado el 13 de septiembre de 2026.

  1. Comprobar antes de escribir. Si el agente va a tocar un sistema, el dato se verifica contra la fuente que manda —el maestro, el ERP, el contrato— y no contra lo que el modelo recuerda. En las acciones la verificación no es una mejora: es el paso.
  2. Si no es reversible, no hay umbral que valga. Ninguna medida de confianza autoriza una acción que no se puede deshacer. Esa se confirma siempre, aunque el agente lleve seis meses sin fallar.
  3. Si la comprobación no se puede hacer, eso ya es la duda. El sistema que tenía que confirmar está caído, el documento no se abre, el identificador no existe. No es un caso raro que se resuelve por analogía: es un caso que se para.

Esto engancha con dos decisiones que se toman aparte y conviene no mezclar: qué puede tocar el agente está en qué permisos dar a un agente de IA, y cuánto puede hacer solo, en los niveles de autonomía de un agente. El comportamiento de la duda es la tercera pata: qué pasa cuando, con esos permisos y en ese peldaño, el caso concreto no da la talla.

Dónde poner el umbral sin colapsar al equipo

El umbral no es un número que se elige leyendo un artículo: es la consecuencia de dos cosas tuyas, el coste del error y la capacidad de la cola. Si el error es barato y visible, el umbral puede ser laxo. Si es caro y silencioso, se aprieta. Y si el número de casos que manda a revisión no cabe en las horas que tiene tu equipo, ese umbral no es prudente: en tres semanas se estará aprobando en bloque sin leer, que es peor que no tenerlo, porque además genera un registro que dice que alguien lo miró.

  1. Agrupa las tareas del agente en tres cubos por coste del error: barato y visible, caro y visible, caro e invisible. El tercero manda: ahí el umbral se pone donde haga falta aunque duela.
  2. Arranca deliberadamente pesimista. Es más fácil defender un umbral que se relaja con datos que uno que se aprieta después de un incidente.
  3. Mide dos semanas y mira las abstenciones, no los aciertos. De cada caso que fue a la cola, marca si la persona lo resolvió distinto —la abstención era correcta— o igual que habría hecho el agente —era ruido—. Ese reparto es lo que mueve el umbral, no la sensación.
  4. Ajusta por segmento, nunca en global: cliente nuevo frente a cliente de diez años, importe pequeño frente a importe grande, idioma en el que tienes documentación frente a idioma en el que no.
  5. Pon la capacidad como techo duro. Si con el umbral correcto la cola no cabe, la conclusión no es bajar el umbral: es que esa tarea todavía no debería estar en producción sin más manos.

Cuando el volumen crece, esto deja de ser una configuración y pasa a ser una función con turnos, cobertura y métricas propias: es supervisión humana de IA a escala, y conviene montarla antes de necesitarla.

Qué tiene que viajar en el traspaso para que la persona no empiece de cero

Un traspaso sin contexto es una duda bien detectada y mal resuelta. El agente hizo su parte —paró a tiempo— y aun así el cliente cuenta su problema por segunda vez, que es exactamente lo que enfada de un chatbot. En un traspaso interno pasa lo mismo sin que nadie proteste: la persona reconstruye a mano lo que el sistema ya tenía.

La mecánica está resuelta en las dos guías de referencia del sector. En el patrón descentralizado que describe OpenAI, el traspaso entre agentes transfiere el control y además el último estado de la conversación; y un agente, por definición, puede detener la ejecución y devolver el control al usuario cuando falla. Anthropic lo plantea como puntos de parada: los agentes pueden pausar para recibir intervención humana en puntos de control o cuando encuentran un bloqueo, y conviene fijar condiciones de parada —un máximo de iteraciones— para no perder el control. Fuentes: A practical guide to building agents, OpenAI, y Building effective agents, Anthropic, 19 de diciembre de 2024; ambas consultadas el 13 de septiembre de 2026.

Lo que la documentación no te da es el contenido del paquete. Estos son los seis campos que hacen que un traspaso ahorre tiempo en vez de costarlo:

  • Qué pedía el caso, en una línea y con las palabras del que lo pidió.
  • Qué hizo el agente hasta pararse: qué consultó, qué encontró, qué escribió si escribió algo.
  • Por qué paró: la señal concreta que se disparó, no «baja confianza». «Ningún documento cubre la pregunta» y «el importe supera el límite» piden dos cosas distintas de la persona.
  • Lo que ya tiene recogido: identificadores, adjuntos, datos verificados. Si la persona vuelve a pedirlos, el traspaso ha fallado.
  • Lo que NO ha hecho, cuando importa: «no se ha enviado nada al cliente», «no se ha tocado el pedido». Evita la acción duplicada, que es el accidente clásico del escalado.
  • Qué se espera de la persona: decidir, redactar, autorizar. Un caso que llega sin verbo se queda en la cola.

Y falta el tramo de vuelta, que casi nadie monta: la decisión de la persona tiene que volver al registro con su motivo. Sin eso, cada abstención es un caso perdido; con eso, la cola de revisión se convierte en la batería de casos con la que mides al agente el mes que viene. Es la diferencia entre un sistema que escala y uno que además aprende de lo que escala.

Cómo se mide un agente que duda bien (y por qué tu eval lo penaliza hoy)

Si tu única métrica es el porcentaje de acierto, estás reproduciendo en casa el problema que describen Kalai y compañía: cuando «no lo sé» puntúa igual que una respuesta equivocada, lo racional es adivinar. Ellos lo llaman una epidemia de penalizar las respuestas inciertas, y su propuesta no es añadir otra evaluación de alucinaciones, sino cambiar cómo puntúan las evaluaciones que ya se usan. En tu empresa es la misma operación y cabe en tres números.

  • Tasa de abstención. Qué porcentaje de casos para el agente. No tiene un valor bueno universal: tiene un valor esperado que fijas tú y una tendencia que vigilas. Si cae sola de un mes a otro sin que hayas tocado nada, algo se ha roto en la señal.
  • Precisión de la abstención. De lo que mandó a la cola, qué parte resolvió la persona de forma distinta a como lo habría hecho el agente. Es la métrica que distingue a un agente prudente de uno cobarde.
  • Error con aplomo. Casos que salieron mal sin que el agente marcara nada. Es la única de las tres con un objetivo claro, y es cero. Cada uno se abre y se convierte en señal nueva o en regla dura.

Con esos tres números la conversación cambia de sitio: deja de ser «¿es bueno el agente?» y pasa a ser «¿en qué se equivoca y lo sabe?». Que es la única versión de la pregunta que se puede contestar con datos.

Nosotros montamos este comportamiento antes que el agente: señales calculadas, verificación obligatoria en todo lo que escribe, umbral atado a la capacidad real y un traspaso con los seis campos. Es lo que hay debajo de soporte con IA 24/7 y de cualquier agente que dejemos hablar con un cliente tuyo, y lo que se vigila a volumen en supervisión humana de IA a escala. El resto del montaje —permisos, autonomía, memoria, evals— está en crear un agente de IA que aguante producción.

Preguntas frecuentes

Uno bien diseñado hace tres cosas y en este orden: detecta que no sabe por una señal medible, se abstiene de responder o de actuar, y traspasa el caso a una persona con el contexto ya recogido. Uno mal diseñado hace una sola: contesta igual, rápido y con aplomo. La diferencia no está en el modelo, está en el sistema que lo rodea, y hay un motivo para que el comportamiento por defecto sea el malo: los procedimientos de entrenamiento y evaluación premian adivinar por encima de reconocer la incertidumbre, según Why Language Models Hallucinate (Kalai, Nachum, Vempala y Zhang, OpenAI, 4 de septiembre de 2025). Por eso la abstención se fabrica fuera del modelo: señales calculadas, verificación antes de actuar y una salida a un humano que existe de verdad.

Por señales que calcula el sistema, no por introspección del modelo. Las que más rinden son seis: cobertura de la fuente (el recuperador no ha traído ningún pasaje relevante, así que lo que venga después es invención); desacuerdo consigo mismo (dos pasadas sobre la misma entrada dan datos distintos); contrato de salida roto (falta un campo obligatorio, un importe no es un número); regla dura de negocio (importe por encima del límite, cliente sin histórico, dato regulado); contador de fracaso (N reintentos o N turnos sin avanzar); y petición explícita de la persona. Lo importante es que no se suman en un marcador único: cada señal pide un tratamiento distinto, y mezclarlas en un número global esconde las tres primeras.

Se puede, pero no sirve como señal de control. La evaluación de Xiong y colegas sobre elicitación de confianza encontró que los modelos son muy sobreconfiados cuando verbalizan su confianza, con valores que se concentran de forma abrumadora entre el 80 % y el 100 %, incluso cuando la precisión real no respalda ese número. Fuente: Can LLMs Express Their Uncertainty?, Xiong et al., ICLR 2024. La consecuencia práctica: usa señales externas y verificables —cobertura de la fuente, validación del contrato de salida, reglas duras, contadores de reintento— y deja el autoinforme de confianza como mucho para ordenar una cola, nunca para decidir si algo sale al cliente.

Lo decide el coste del error y la capacidad de tu cola, no un porcentaje de referencia. Agrupa las tareas en tres cubos —error barato y visible, caro y visible, caro e invisible— y deja que mande el tercero. Arranca pesimista, mide dos semanas mirando las abstenciones (de cada caso escalado, si la persona lo resolvió distinto la abstención era correcta; si lo resolvió igual, era ruido) y ajusta por segmento, nunca en global. Y pon la capacidad como techo duro: un umbral que genera más casos de los que tu equipo puede mirar acaba aprobándose en bloque sin leer, que es peor que no tenerlo porque genera un registro falso de revisión. Dos síntomas visibles en cinco minutos: la cola se aprueba en bloque (umbral bajo) o en un mes no ha escalado ni un caso (la señal no se dispara nunca).

Seis campos: qué pedía el caso en una línea; qué hizo el agente hasta pararse; por qué paró, con la señal concreta y no un genérico «baja confianza»; lo que ya tiene recogido (identificadores, adjuntos, datos verificados); lo que NO ha hecho cuando importa («no se ha enviado nada al cliente»), para evitar la acción duplicada; y qué se espera de la persona —decidir, redactar, autorizar—. La mecánica de fondo ya está en la documentación de referencia: en el patrón descentralizado de OpenAI el traspaso transfiere el control y además el último estado de la conversación, y Anthropic recomienda que el agente pueda pausar para intervención humana en puntos de control o cuando encuentra un bloqueo. Falta el tramo de vuelta, que casi nadie monta: la decisión de la persona tiene que volver al registro con su motivo, porque esa cola es la batería de casos con la que mides al agente el mes siguiente.

Plan de Impacto IA · gratis

La guía es genérica. Tu plan, no.

Cuéntanos tu empresa y te devolvemos un diagnóstico con prioridades, números y qué implementar primero. Sin reunión de venta y sin pagar un euro.

Qué hace un agente de IA cuando no sabe la respuesta: la duda se diseña, no se espera · Implementa