flowchart TD
A[Solicitud inicial incompleta] --> B[Identificar información faltante]
B --> C[Formular pregunta]
C --> D[Recibir respuesta]
D --> E[Actualizar estado]
E --> F{¿Hay información suficiente?}
F -- No --> B
F -- Sí --> G[Continuar con la tarea]
Agente conversacional
Cuando pensamos en inteligencia artificial generativa, la experiencia más familiar es una conversación.
Escribimos una pregunta.
Recibimos una respuesta.
Escribimos otra.
El sistema utiliza lo ocurrido anteriormente para continuar el diálogo.
Ese comportamiento puede parecer trivial después de haber hablado de herramientas, workflows y planificación. Sin embargo, mantener una conversación útil durante varios turnos ya plantea un problema de estado y coordinación.
Un agente conversacional convierte esa interacción en una función deliberada.
Su objetivo principal no es todavía investigar exhaustivamente ni actuar sobre otros sistemas.
Es conducir una conversación, aclarar el encargo y mantener suficiente continuidad para que el intercambio progrese.
Un agente conversacional organiza una interacción a través de varios turnos.
Su capacidad central es:
conversar + aclarar + mantener estado básico.
Puede ser muy útil para intake, orientación y levantamiento de antecedentes.
Pero si no tiene documentos, recuperación ni herramientas, sólo puede trabajar con aquello que la conversación le proporciona.
Del chat reactivo a la conversación guiada
Un chat reactivo puede limitarse a responder cada pregunta.
Por ejemplo:
Usuario: ¿Qué contrato necesito?
Sistema: Depende del tipo de servicio.
Un agente conversacional puede adoptar una conducta más estructurada:
Usuario: Necesito contratar un proveedor nuevo.
Sistema: Para identificar qué documentación necesitas, primero debo entender el servicio. ¿El proveedor entregará software, servicios profesionales o ambos?
Usuario: Software SaaS.
Sistema: ¿El servicio recibirá datos personales o documentos confidenciales de clientes?
La diferencia no consiste solamente en que haga preguntas.
El sistema está utilizando las respuestas para reducir incertidumbre respecto del objetivo.
1. Conversación: preguntar es una acción de trabajo
En un agente conversacional, una pregunta no es un fracaso por falta de respuesta.
Puede ser el próximo paso correcto.
Esto resulta especialmente importante en tareas jurídicas, donde una instrucción inicial suele llegar incompleta.
Por ejemplo:
“Necesito revisar un contrato.”
Antes de producir un análisis útil pueden importar preguntas como:
- ¿qué tipo de contrato es?;
- ¿a quién representamos?;
- ¿qué decisión debe apoyarse?;
- ¿qué documentos existen?;
- ¿hay una fecha límite?;
- ¿qué áreas deben intervenir?;
- ¿se espera diagnóstico o redacción?
El agente puede conducir el intake de manera progresiva.
Una conversación no debe preguntar todo
Existe un equilibrio.
Un sistema podría convertir el intake en un interrogatorio de cincuenta preguntas antes de aportar valor.
Eso también sería un mal diseño.
La conversación debería preguntar aquello que:
- cambia materialmente la tarea;
- no puede deducirse con suficiente seguridad del contexto;
- es razonable que el usuario pueda responder;
- permite desbloquear el siguiente paso.
Esto conecta con lo aprendido sobre ambigüedad en prompts: no necesitamos eliminar toda incertidumbre, sino hacer explícita la que cambia el trabajo.
La conversación como proceso de reducción de incertidumbre
Podemos visualizar el diálogo así:
El sistema no pregunta por conversar.
Pregunta para modificar el estado del problema.
2. Estado básico: qué sabemos hasta ahora
Para mantener una conversación útil, la aplicación necesita alguna forma de representar lo que ya se estableció.
Podemos llamarlo estado básico de la sesión.
Supongamos un intake contractual.
Después de varios turnos, el estado podría ser:
Tipo de servicio: SaaS
Parte representada: cliente
Datos personales: sí
Datos sensibles: no confirmado
Criticidad: alta
DPA recibido: no
Fecha objetivo de firma: 20 de octubre
No estamos diciendo que el modelo posea una memoria humana.
Estamos diciendo que la aplicación mantiene información relevante para no recomenzar desde cero.
Estado no es transcripción
El historial completo de conversación y el estado no son exactamente lo mismo.
El historial podría contener:
“Creo que probablemente van a usar algunos datos, pero no sé bien cuáles…”
El estado puede convertir esa conversación en una variable más útil:
Datos personales: por confirmar
Esta representación permite al sistema saber que todavía falta una respuesta.
Estado también puede contener pendientes
Un buen estado no registra solamente hechos confirmados.
Puede registrar:
Punto abierto: identificar categorías de datos
Responsable: usuario
Próximo paso: solicitar DPA
La conversación pasa a ser una forma de gestión del encargo.
Mantener el hilo no significa recordar todo
En una conversación larga puede resultar imposible o inconveniente colocar todo el historial frente al modelo en cada turno.
La aplicación puede resumir, seleccionar o estructurar información.
No profundizaremos aquí en ingeniería de contexto ni memoria persistente, porque tienen páginas propias.
Basta una idea:
la continuidad conversacional depende de cómo el sistema representa y vuelve a proporcionar el estado relevante.
Si esa representación falla, el agente puede:
- repetir preguntas;
- olvidar restricciones;
- mezclar asuntos;
- asumir como confirmado algo que estaba pendiente.
Un caso completo: intake para contratación tecnológica
Imaginemos un cliente interno que abre una solicitud:
“Necesitamos contratar una herramienta de IA para recursos humanos.”
Un agente conversacional podría seguir esta trayectoria.
Paso 1: identificar la naturaleza del servicio
¿La herramienta se utilizará solamente para redactar o también analizará información de candidatos o trabajadores?
Respuesta:
Analizará CV y ayudará a priorizar candidatos.
Estado:
Uso: análisis y priorización de candidatos
Datos personales: sí
Impacto sobre personas: potencialmente relevante
Paso 2: identificar documentos disponibles
¿Tienes propuesta comercial, términos de servicio, DPA y documentación de seguridad?
Respuesta:
Sólo propuesta y términos.
Estado:
Propuesta: sí
Términos: sí
DPA: no
Seguridad: no
Paso 3: identificar decisión requerida
¿Quieres una revisión preliminar para decidir si avanzar con el proveedor o ya están negociando condiciones?
Respuesta:
Estamos evaluando si vale la pena avanzar.
Estado:
Fase: evaluación preliminar
Producto esperado: mapa de temas y documentos faltantes
Resultado conversacional
El sistema puede cerrar el intake diciendo:
“Con los antecedentes disponibles puedo preparar un mapa preliminar. Quedan pendientes el DPA y la documentación de seguridad, por lo que no conviene tratar privacidad y seguridad como materias cerradas.”
El valor no provino de una respuesta enciclopédica.
Provino de conducir la conversación hasta obtener un estado operativo útil.
Conversación y formularios: no son opuestos
Podríamos obtener los mismos datos mediante un formulario tradicional.
Entonces, ¿para qué usar un agente conversacional?
La conversación aporta flexibilidad cuando:
- el usuario no conoce la terminología;
- las preguntas dependen de respuestas anteriores;
- existen múltiples maneras de describir el mismo hecho;
- la aplicación necesita explicar por qué pregunta algo;
- algunas respuestas requieren aclaración.
Pero un formulario puede ser superior cuando:
- las preguntas son fijas;
- las opciones están bien definidas;
- necesitamos validación estricta;
- importa máxima consistencia.
La arquitectura no debe usar conversación por moda.
Puede combinar ambos mecanismos:
conversación para comprender
↓
campos estructurados para registrar
3. Límites: el agente conversacional no ve lo que no tiene
Éste es el límite central de la página.
Un agente conversacional puede parecer competente porque mantiene contexto y formula buenas preguntas.
Pero si no tiene fuentes ni herramientas, su universo factual está restringido a aquello que aparece en la conversación y al conocimiento general del modelo.
No puede verificar documentos que no recibió
Si el usuario dice:
“El proveedor asegura que no conserva nuestros datos.”
el agente puede registrar esa afirmación como antecedente.
No puede convertirla en hecho verificado si no dispone de evidencia.
Una respuesta cuidadosa debería distinguir:
Afirmación del usuario/proveedor
≠
hecho documentado
No puede consultar silenciosamente sistemas inexistentes
Si no tiene una herramienta para buscar el DPA, no debería actuar como si lo hubiese revisado.
Ésta parece una regla obvia, pero la fluidez de los modelos puede ocultar el límite.
No basta para trabajo jurídico verificable
Las clases lo formulan directamente:
es útil para conversación guiada; no basta para trabajo jurídico verificable.
La razón es estructural.
Verificabilidad exige poder relacionar afirmaciones relevantes con fuentes o evidencia.
La conversación puede reunir antecedentes, pero no sustituye el acceso a esas fuentes.
Límite adicional: estado equivocado
Un agente conversacional también puede fallar aunque tenga todas las respuestas del usuario.
Puede representar mal el estado.
Ejemplo:
Usuario:
“No sabemos todavía si habrá datos sensibles.”
Estado incorrecto:
Datos sensibles: no
Estado correcto:
Datos sensibles: pendiente de confirmación
La diferencia puede modificar todo el workflow posterior.
Por eso conviene distinguir valores como:
- sí;
- no;
- desconocido;
- no aplicable;
- pendiente.
Ausencia de confirmación no equivale a respuesta negativa.
Preguntar, inferir o detenerse
Ante información incompleta, el agente conversacional tiene tres opciones generales.
Preguntar
Cuando el usuario puede resolver la incertidumbre.
“¿La herramienta tomará decisiones automáticamente o sólo hará recomendaciones?”
Inferir provisionalmente
Cuando la inferencia es de bajo riesgo y se marca como provisional.
“Por lo descrito, parece tratarse de un servicio SaaS, pero conviene confirmarlo con la documentación.”
Detenerse
Cuando no existe base suficiente para avanzar con una conclusión importante.
“No puedo evaluar retención de datos sin el DPA o términos equivalentes.”
La capacidad de no inventar continuidad es parte de una conversación profesionalmente útil.
Diseño de una conversación gobernable
Sin entrar todavía en páginas posteriores, un agente conversacional debería permitir responder algunas preguntas básicas:
- ¿qué objetivo tiene la conversación?;
- ¿qué datos intenta obtener?;
- ¿qué estados registra?;
- ¿qué respuestas considera suficientes?;
- ¿qué debe tratar como pendiente?;
- ¿cuándo deja de preguntar?;
- ¿cuándo deriva a otra función?;
Estas preguntas convierten un chatbot genérico en una herramienta de proceso.
Por qué importa para abogados
Muchos errores de trabajo no se producen porque alguien desconocía la norma, sino porque el problema llegó mal definido.
Faltaba saber:
- qué se quería contratar;
- qué documento era vinculante;
- quién decidía;
- qué hechos estaban confirmados;
- qué antecedente faltaba.
Un agente conversacional puede aportar valor precisamente antes del análisis sustantivo, estabilizando el intake.
Eso también puede mejorar trazabilidad: en vez de que los antecedentes queden dispersos en mensajes, el sistema puede convertir la conversación en un estado explícito para el siguiente proceso.
Qué debes recordar
El agente conversacional es el tipo más cercano al chat, pero su función puede ser más precisa que “hablar con el usuario”.
Su valor está en:
- mantener diálogo;
- aclarar el encargo;
- registrar estado básico;
- identificar información faltante;
- decidir cuándo preguntar nuevamente o derivar.
Su límite principal también es claro:
sin acceso a documentos o herramientas, sólo trabaja con lo que se le entrega.
Por eso conversación guiada no equivale a investigación verificable.
El problema que todavía queda abierto
Una vez que la conversación identifica qué información necesitamos, aparece el siguiente problema:
¿cómo obtiene el sistema esa información desde fuentes externas y cómo evita confundir lo recuperado con sus propias inferencias?
La siguiente página desarrolla el agente de recuperación: buscar, filtrar, recuperar, citar y separar evidencia de inferencia.