Skip to content
Ingeniería

El LLM lee la solicitud. El código determinista decide la reserva.

Cómo construimos la reserva de citas con IA para una clínica dermatológica: el modelo de lenguaje extrae la intención, compuertas de funciones puras deciden qué está realmente permitido, y todo lo que queda fuera de las compuertas pasa a una persona. Un informe de campo sobre dónde trazar la línea entre comprensión y autoridad.

JT
JieGou Team
· · 5 min de lectura

El punto de partida

Uno de nuestros despliegues en clínicas gestiona la atención a pacientes por un canal de mensajería. Los pacientes escriben en lenguaje natural — solicitudes de cambio de cita, preguntas sobre tratamientos, «¿puedo ir mejor el jueves por la tarde?» — y un asistente de IA lleva la conversación. La agenda de la clínica vive donde la clínica siempre la ha tenido: una hoja de cálculo compartida que mantiene la recepción, con convenciones de horarios que el personal usa desde hace años.

La construcción obvia es dejar que el modelo lea la agenda y reserve cualquier hueco que parezca libre. No construimos eso, y las razones son la parte útil de este artículo.

Regla número uno: el modelo nunca decide qué es reservable

La agenda de la clínica codifica la política en convenciones: ciertos huecos están reservados solo para visitas de seguimiento y consultas, y están marcados visualmente, no etiquetados en una base de datos. Los tratamientos de pacientes nuevos no caben ahí, nunca. La recepción lo sabe. Un modelo de lenguaje que lee la cuadrícula no lo sabe — ve un hueco libre.

Así que lo primero que entregamos no fue la reserva. Fue una compuerta dura: los huecos reservados quedan estructuralmente fuera del alcance del asistente. No «instruido para evitarlos» — fuera del alcance, impuesto por código que se ejecuta después del modelo y antes de que nada toque la agenda. Con un prompt se puede discutir; con una función pura, no.

Esa es la arquitectura en una frase: el LLM extrae, el código determinista decide. El modelo es excelente leyendo «el jueves que viene después de las 3 me vendría genial, el mismo tratamiento que la última vez» y produciendo una intención estructurada: ventana solicitada, tipo de tratamiento, identidad del paciente. Todo lo que viene después es lógica simple y testeable — clasificación de huecos, reglas de elegibilidad, cálculo de duraciones — escrita como funciones puras sobre datos, con tests unitarios, revisada como cualquier otro código.

Los detalles aburridos sostienen la seguridad

La mayor parte del esfuerzo de ingeniería se fue en detalles que ninguna demo mostraría jamás:

  • Las duraciones de los tratamientos salen de la tabla de referencia de la propia clínica. Cada tratamiento reservable tiene un tiempo de preparación y un tiempo de tratamiento, conciliados línea por línea con la tabla impresa de la clínica — incluida la pasada en la que encontramos y corregimos diecinueve discrepancias. El asistente no puede ofrecer un hueco en el que la duración real no cabe.
  • La hora de llegada se deriva, no se adivina. El tiempo de preparación determina cuándo debe llegar el paciente; el mensaje de confirmación lo indica. Un juicio menos para el modelo, una sorpresa menos para la recepción.
  • Los números de teléfono se escriben como texto. Una hoja de cálculo se come sin pestañear el cero inicial de un número de teléfono almacenado como número. Bug pequeño, consecuencia real, arreglo determinista.
  • La ambigüedad se enruta a una persona. Cuando la solicitud no pasa limpiamente por las compuertas — una combinación de tratamientos inusual, un conflicto de horarios que las reglas no pueden resolver, un paciente que pide algo que la tabla de políticas no cubre — el asistente no improvisa. Entrega la conversación a una persona, con el contexto adjunto. La transferencia es una funcionalidad, no un modo de fallo.

Cada regla de decisión de esa lista existe porque el operador de la clínica tomó una decisión, nosotros la codificamos, y la codificación ahora es inspeccionable. Cuando el operador cambia una política, cambiamos una función y su test — no un prompt y una esperanza.

Por qué trabajamos así

Hay una versión de este proyecto que se entrega en un fin de semana: darle a un modelo capaz la agenda y un prompt de sistema, y dejarlo reservar. La demo sería preciosa y funcionaría la mayor parte del tiempo. «La mayor parte del tiempo» es el problema. La agenda de una clínica es una promesa a pacientes reales y a personal real; los casos de fallo son salas de tratamiento con doble reserva y una recepción que deja de confiar en la herramienta después del segundo desastre.

La separación que usamos — el modelo para la comprensión, compuertas deterministas para la autoridad, transferencia a humanos para todo lo que queda fuera de las compuertas — cuesta más ingeniería al principio y devuelve algo que un prompt no puede dar: la lógica de reserva es testeable antes de tocar a un paciente, auditable después, y corregible en exactamente un solo lugar cuando cambia la política.

El patrón no es específico de las clínicas. Allí donde un asistente de IA se encuentra con un recurso del que dependen otras personas — un calendario, un inventario, un libro contable — aplica la misma línea. Deja que el modelo lea. No dejes que mande.

AI booking deterministic gates human handoff clinics agent operations field report
Compartir este artículo

¿Le gustó este artículo?

Reciba consejos sobre flujos de trabajo, actualizaciones de producto y guías de automatización en su bandeja de entrada.

No spam. Unsubscribe anytime.