Escalamiento humano desde chatbot

1. Objetivo

Garantizar que cuando Nim no pueda resolver una consulta — por su complejidad, por ser de naturaleza clínica, o por requerir una acción que sólo una persona puede ejecutar — la consulta llega a una persona de la organización con el contexto suficiente para darle seguimiento.

2. Alcance

Cubre el traspaso desde el canal de chat (Nim autenticado o público) hacia el canal de atención humana de la organización, y el registro del caso para su seguimiento.

No cubre:

• La atención por parte de Nim antes del escalamiento — eso es [[wiki/entities/dispensai/protocolos/ATN-002]] (autenticado) o ATN-001 (público).
• La resolución del caso ya escalado — eso corresponde al flujo de tickets (CAL-002) y al proceso de atención de soporte de la organización.
• El seguimiento de casos observados en el proceso de admisión — eso es ATN-006.
• Las consultas que Nim puede resolver directamente.

3. Definiciones

Escalamiento. La derivación de una consulta desde Nim hacia una persona de la organización, cuando Nim reconoce que el caso supera su alcance o cuando el socio lo solicita explícitamente.

Caso abandonado. Una consulta en que el socio agotó el canal de Nim sin resolución y sin recibir instrucciones claras sobre cómo continuar. Es el riesgo central de este protocolo.

Canal de soporte humano. El sistema de tickets de la organización, accesible desde el panel del socio y del administrador. Para el escalamiento desde chat, el mecanismo actual es la apertura manual de un ticket por CAL-002.

4. Roles y responsables

Rol	Responsabilidad
Nim (sistema)	Reconocer cuándo el caso supera su límite y comunicarlo al socio con claridad
Socio	Abrir un ticket de soporte si Nim no resuelve su consulta
Soporte / admin	Recibir y dar seguimiento al ticket abierto por el socio
Responsable de datos	Asegurar que el contexto traspasado al canal de soporte no incluya más datos de los necesarios

5. Disparador de inicio

Nim reconoce que la consulta supera su límite (clínica, operacional, o de información no disponible), o el socio solicita explícitamente hablar con una persona.

6. Requisitos previos

• El socio ha interactuado con Nim y la consulta no ha sido resuelta.
• El sistema de tickets está operativo y accesible desde el panel del socio.

7. Entradas

• Mensaje del socio que supera el límite de Nim, o solicitud explícita de atención humana.
• Historial de la conversación en chat_messages.

8. Procedimiento paso a paso

1. Detección del límite. Nim reconoce que la consulta requiere criterio clínico individual, acceso a información que no tiene, o una acción que solo una persona puede ejecutar.
2. Comunicación al socio. Nim informa al socio con claridad que no puede resolver la consulta dentro de su rol, sin dejar al socio sin instrucción de qué hacer a continuación.
3. Orientación al canal de soporte. Nim indica al socio el paso siguiente concreto: abrir un ticket de soporte desde el panel, con una descripción de su consulta, para que el equipo de la organización le dé seguimiento. El socio puede hacerlo desde el mismo panel del sistema (flujo CAL-002).
4. Apertura del ticket por el socio. El socio abre el ticket desde /dashboard o desde el canal habilitado para ello, conforme a [[wiki/entities/dispensai/protocolos/CAL-002]]. Este paso lo ejecuta el socio, no el sistema de chat.
5. Seguimiento por soporte. El equipo de la organización recibe el ticket y da respuesta dentro del plazo definido.

9. Puntos de control

#	Control	Qué impide
C1	Nim comunica su límite antes de cerrar la respuesta	Dejar al socio sin instrucción
C2	Nim indica el paso concreto hacia el canal humano	Caso abandonado por falta de orientación
C3	El ticket queda registrado en el sistema de la organización	Caso sin trazabilidad para soporte

Solo C3 tiene evidencia de implementación hoy (el sistema de tickets existe). C1 y C2 dependen del comportamiento del modelo. Ver §17.

10. Criterios de decisión

Situación	Resultado
Nim reconoce que la pregunta requiere criterio clínico	Escala e indica al socio abrir ticket
Nim no tiene la información que el socio necesita	Escala e indica al socio abrir ticket
El socio solicita explícitamente hablar con alguien	Nim orienta hacia el canal de soporte
El socio abre el ticket	El caso entra al flujo CAL-002 con el equipo de soporte

11. Excepciones y escalamiento

• Socio que no abre el ticket: El caso no tiene seguimiento. La organización no tiene mecanismo automático que detecte este escenario hoy. Ver §17.
• Ticket de alta urgencia: La organización puede definir categorías de urgencia dentro del flujo CAL-002 para priorizar la atención.
• Escalamiento desde el chat público (ATN-001): El mismo mecanismo aplica. El socio no autenticado recibe instrucciones para registrarse o contactar por los canales de la organización.

12. Registros generados

Registro	Contenido
Ticket de soporte	Descripción del caso, estado, responsable, fechas
Historial de conversación en chat_messages	Contexto de la consulta que motivó el escalamiento

No existe hoy un registro automático que vincule la conversación de chat con el ticket de soporte abierto posteriormente. Ver §17.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Casos escalados resueltos	Tickets abiertos desde chat resueltos ÷ total de tickets marcados como escalados	100 % en ≤ 5 días hábiles	Sistema de tickets
Tiempo de primera respuesta humana	Fecha primera acción soporte − fecha apertura del ticket	≤ 2 días hábiles	Sistema de tickets

Los indicadores requieren que los tickets escalados desde el chat estén etiquetados manualmente. No hay automatización hoy.

14. Riesgos y controles

Riesgo	Control	Tipo
Caso abandonado: Nim no orienta al socio	System prompt instruye a Nim a comunicar el límite y el paso siguiente (C1 y C2)	Preventivo
Caso abandonado: el socio no abre el ticket	Nim reitera la instrucción; sin mecanismo automático de detección	Parcial
Ticket sin contexto suficiente	El socio describe su consulta al abrir el ticket; Nim puede sugerirle qué incluir	Preventivo
Falta de seguimiento por soporte	CAL-002 define el flujo de resolución; indicadores del §13 miden la respuesta	Detectivo

15. Normativa y referencias

Norma	Referencia	Qué cubre en este protocolo
ISO 9001:2015	§8.2.1	Canal definido de comunicación con el socio; el escalamiento es parte del canal
ISO 9001:2015	§8.5.5	Actividades posteriores al servicio: el seguimiento del caso escalado es una actividad posterior
ISO 26000	6.7.3	Acceso a servicios esenciales con información veraz; el socio debe saber cómo acceder a la atención humana

16. Anexos y formularios vinculados

• [[wiki/entities/dispensai/protocolos/CAL-002]] — Apertura de ticket o queja.
• [[wiki/entities/dispensai/protocolos/ATN-002]] — Atención de consultas por Nim autenticado.

17. Implementación en el sistema

El protocolo está parcialmente implementado. El sistema de tickets existe (CAL-002 vigente) y el canal de chat persiste las conversaciones. Lo que no existe es el puente automático entre ambos.

Elemento del protocolo	Dónde vive
Canal de chat autenticado (paso 1)	app/api/chat/route.ts + app/asistencia/page.tsx
getMyTickets — consulta de tickets existentes	lib/ai/tools/patient-tools.ts:362
Sistema de tickets (paso 4)	app/dashboard + flujo CAL-002

Brechas conocidas:

1. Sin herramienta de creación de ticket desde el chat. El agente patient dispone de getMyTickets (lectura de tickets existentes), pero no de ninguna tool que cree un ticket, que marque la conversación como “requiere atención humana”, o que dispare una notificación al equipo de soporte. El escalamiento del paso 3 consiste en que Nim le diga al socio lo que debe hacer; no en que el sistema lo haga. La ejecución del paso 4 depende enteramente del socio.
2. Sin flag de escalamiento en chat_conversations. La tabla no tiene columna escalated, needs_human ni equivalente. El administrador no tiene vista filtrada de conversaciones que requieran seguimiento. Si el socio no abre el ticket, el caso desaparece sin rastro en el sistema de soporte.
3. Sin vínculo entre la conversación y el ticket. Cuando el socio abre el ticket, no existe mecanismo que asocie ese ticket con la conversación que lo motivó. El equipo de soporte recibe el ticket sin el historial de Nim, a menos que el socio lo transcriba manualmente.
4. Sin evento ISO para el escalamiento. Ningún evento en iso_system_events registra que una conversación fue derivada a soporte humano.

Lo que ejecuta la organización fuera del sistema: la apertura de un ticket por el socio desde el panel (CAL-002) es el mecanismo actual de escalamiento humano. No es un defecto del software; es el canal oficial habilitado. La brecha es que Nim no puede activarlo directamente.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial. Redactada desde la corrida de evidencia 2026-08-28-ATN. Cuatro brechas declaradas.	Soporte
1.1	2026-08-29	Cierre de INFERIDO: confirmado que createPatientTools en lib/ai/tools/patient-tools.ts solo expone getMyTickets (línea 362) — no existe herramienta de creación de ticket ni de escalamiento directo. Confirmado que ninguna migración agrega columna escalated o needs_human a chat_conversations. Cuatro brechas vigentes y correctamente declaradas.	Soporte