Agente de primera consulta laboral para Leal Abogados

En corto

Las consultas laborales llegan a Leal Abogados, una firma de Bogotá, por WhatsApp a cualquier hora. El agente hace la primera conversación, pide el aviso de tratamiento de datos antes que nada, marca lo urgente con reglas fijas además de la IA y le deja al abogado una ficha: resumen, fechas clave, documentos que debe traer y preguntas pendientes. Es una demo funcional con datos ficticios. La propuesta de piloto está en conversación con la firma.

Contexto

La firma ya tenía un chat en su página. Respondía desde el primer segundo, nunca pedía autorización de datos y, si la persona no daba clic al WhatsApp, la conversación se perdía: sin ficha, sin alerta, sin conteo. La firma no podía saber cuántas consultas llegaban ni cuántas eran urgentes.

La demo se construyó para mostrar cómo sería el piloto: la misma primera conversación, pero con consentimiento, reglas fijas, una guarda en cada respuesta y un panel para el abogado.

El problema

• Un despido en embarazo y una pregunta por horas extra llegan al mismo chat y se ven iguales.
• Alguien de la firma lee la conversación al otro día, vuelve a preguntar lo básico y solo entonces decide si es urgente.
• La gente escribe su cédula y su cuenta bancaria sin que se las pidan. Esos datos nunca deberían llegar al proveedor de IA.
• Un chatbot genérico calcula una indemnización o cita un artículo sin problema. Una firma de abogados no puede permitirlo.

El enfoque

Primero el consentimiento. El servidor rechaza cualquier mensaje antes de que la persona acepte el aviso de datos (Ley 1581). Se guardan fecha, hora y versión del aviso junto con la ficha.

Reglas fijas por encima del modelo. Embarazo, incapacidad, fuero, amenazas, una citación cercana o hechos cerca de los tres años se marcan urgentes siempre, diga lo que diga el modelo. Gana la urgencia más alta. La alerta llega al panel del abogado antes de que termine la conversación.

Una guarda en cada respuesta. Antes de mostrar una respuesta, la guarda revisa montos y fórmulas, promesas, plazos legales, citas de artículos, asesoría final, pedidos de cédula o archivos y cualquier frase que presente al asistente como abogado. Si algo se cuela, pide otra redacción al modelo; si persiste, quita la frase.

Datos mínimos. Cédulas, cuentas y tarjetas se ocultan antes de guardar o de enviar a la IA. El asistente nunca cita normas al cliente; la ficha agrega referencias verificadas solo para el abogado.

Qué construí

• Una pantalla del cliente, con estilo de WhatsApp, que presenta al asistente como automático, pide el consentimiento y después pregunta de a una.
• Un panel del abogado con indicadores del piloto (fichas, urgentes, fichas completas, tiempo hasta la ficha) y cada ficha con resumen, contacto, urgencia y por qué, preguntas pendientes, documentos que debe traer, normas verificadas y la conversación completa.
• Reglas fijas para urgencias y para temas fuera de alcance (el agente solo atiende lo laboral y manda el resto a una persona).
• Tres casos guiados pregrabados para que la demo corra sin internet ni clave de API.
• Un código de consulta al final de cada conversación, para que la persona pueda referirse a él.

Evaluación

Los 30 casos de aceptación cubren despidos, salarios sin pagar, acoso, un accidente de trabajo, un menor, una empleada doméstica, personas que exigen un monto exacto o un plazo legal, un intento de manipular al asistente para que actúe como abogado y dos casos donde la persona escribe su cédula y su cuenta.

Además, 78 pruebas sin red donde el SDK de Claude se reemplaza por un transporte falso, y 23 verificaciones en Edge en escritorio y celular. El evaluador usa un motor simulado adversarial que intenta dar asesoría, montos y pedir archivos, así que la guarda tiene que detenerlos. Lo que todavía no prueba: la calidad semántica, que necesita el modelo real y la revisión del abogado. El piloto solo sale si pasan 27 de 30 casos, se escalan todos los urgentes y hay cero respuestas prohibidas.

Qué se rompió y cómo lo encontré

• Una cuenta bancaria que parecía celular no se ocultaba. Caso CP-29: diez dígitos, sin palabras de banco cerca. La regla de ocultamiento la trató como teléfono y la dejó pasar. Corregido: un número identificado como cuenta se oculta aunque su longitud y prefijo parezcan de celular; los celulares sin contexto bancario se conservan.
• La tarjeta de otra área aparecía más de una vez. Cuando las reglas y el motor detectaban a la vez otra área legal, la sesión mostraba dos tarjetas de derivación. Corregido en el flujo: una sola tarjeta por sesión, diga lo que diga el historial.
• La guarda no detectaba pedidos de audio ni de datos bancarios. Atrapaba pedidos de documentos, pero no “mándeme el audio” ni “deme su cuenta”. Se amplió con patrones nuevos y una prueba de regresión por cada uno.
• La cifra honesta es 1 de 30, no 30 de 30. La corrida simulada aprueba todos los controles de reglas, pero solo un caso (rechazo de la autorización) se puede comprobar del todo sin el modelo real. Lo reporto así.

Qué aprendí

• Primero las reglas, después el modelo. Lo que protege a la firma no depende de que el modelo acierte ese día.
• Un evaluador que no puede fallar no sirve. Las regresiones incluyen expectativas alteradas a propósito: si se apaga la guarda o el ocultamiento, el evaluador tiene que fallar. Falla.
• Decir lo que falta. 29 casos todavía necesitan la corrida con IA real y la revisión del abogado de las 30 respuestas esperadas. Está escrito en la demo y en esta página.

¿El mismo dolor en tu firma?

Si las primeras conversaciones se comen el tiempo de tu equipo y lo urgente se mezcla con lo demás, hablemos. Te muestro la demo con casos ficticios antes de cotizar nada.

Escríbeme por LinkedIn