Atención de consultas por Nim autenticado

1. Objetivo

Garantizar que el socio autenticado reciba respuestas informativas útiles a través de Nim, dentro de los límites del rol de asistente — sin reemplazar la indicación médica, sin divulgar datos de terceros y con escalamiento claro cuando la consulta supera ese límite.

2. Alcance

Cubre las consultas que el socio autenticado dirige a Nim desde el área privada (/asistencia): consultas sobre su dispensación, estado de cuenta, información legal, información general sobre la organización y sobre el cannabis medicinal en el contexto regulatorio chileno.

No cubre:

• Consultas del público no registrado — eso es ATN-001.
• Consultas de carácter clínico que impliquen indicación, ajuste o modificación del tratamiento. Nim informa; el médico trata.
• El escalamiento a una persona de soporte cuando Nim no puede resolver — eso es [[wiki/entities/dispensai/protocolos/ATN-003]].
• La actualización de datos del perfil o de la receta — eso es ATN-004.
• El bloqueo cuando la receta está vencida — eso es [[wiki/entities/dispensai/protocolos/ATN-005]].

3. Definiciones

Nim. El asistente de inteligencia artificial de la organización. Responde desde la base de conocimiento aprobada y desde los datos del socio en el sistema. No es un médico, no diagnostica, no prescribe y no modifica indicaciones.

Agente autenticado. Configuración de Nim que requiere sesión activa (agentType = "patient") y tiene acceso a datos propios del socio (dispensaciones, estado de cuenta, estado de documentos, tickets). Distinto del agente público, que opera sin sesión y sin acceso a datos.

Enrutamiento de intención. El sistema clasifica la consulta entrante y la dirige al sub-agente especializado más adecuado: legal, médico-informativo, dispensación o general.

Límite de Nim. Nim no responde preguntas que requieran criterio clínico individual — diagnóstico, ajuste de dosis, interacciones no documentadas en la base de conocimiento, efectos adversos que requieran evaluación médica. Ante esas preguntas, dirige al socio a su médico.

4. Roles y responsables

Rol	Responsabilidad
Socio	Plantear su consulta dentro del canal designado
Nim (sistema)	Responder dentro de su base de conocimiento y de los datos del socio; derivar cuando la consulta excede su límite
Admin del sistema	Mantener actualizada la base de conocimiento que alimenta a Nim
Responsable de datos	Velar por que el canal no filtre datos de terceros

5. Disparador de inicio

El socio autenticado envía un mensaje en la interfaz de chat de /asistencia.

6. Requisitos previos

• El socio tiene una sesión activa en el sistema.
• El sistema dispone de la base de conocimiento categorizada actualizada.
• El sistema tiene acceso a los datos del socio (dispensaciones, estado de documentos, estado de cuenta).

7. Entradas

• Mensaje del socio.
• Sesión autenticada (identidad verificada por Supabase Auth).
• Datos del socio desde la base de datos (contexto del agente patient).
• Base de conocimiento filtrada por categoría del agente.
• Historial de la conversación (si existe conversationId).

8. Procedimiento paso a paso

1. Verificación de autenticación. El sistema verifica que existe una sesión activa. Si no, retorna requiresAuth: true sin procesar el mensaje.
2. Enrutamiento de intención. El sistema clasifica la consulta y selecciona el sub-agente correspondiente: legal, médico-informativo, dispensación o general. La clasificación usa un modelo ligero (GPT-4o-mini) para minimizar latencia.
3. Construcción del contexto. El sistema arma el contexto del agente: sistema prompt del sub-agente seleccionado, contexto específico del socio (estado de documentos, dispensaciones recientes, estado de cuenta), fragmentos de la base de conocimiento relevantes para la consulta (RAG file-direct, filtrado por las categorías permitidas para el sub-agente).
4. Generación de la respuesta. Nim responde usando el contexto construido, con las herramientas disponibles para el sub-agente. Las herramientas acceden a datos propios del socio; nunca a datos de terceros.
5. Aplicación del límite. Si la consulta requiere criterio clínico individual (diagnóstico, prescripción, ajuste de dosis), Nim informa que esa pregunta corresponde al médico tratante y, si el socio lo necesita, lo orienta hacia el canal de escalamiento (CAL-002 / ATN-003).
6. Persistencia de la conversación. El mensaje del socio y la respuesta de Nim quedan guardados en chat_messages, asociados a la conversación del socio. El socio solo puede acceder a sus propias conversaciones.
7. Cierre del turno. El sistema retorna la respuesta al socio. El encabezado X-Conversation-ID permite que el cliente mantenga la continuidad de la conversación.

9. Puntos de control

#	Control	Momento
C1	Sesión verificada antes de procesar el mensaje	Paso 1
C2	Aislamiento de categorías RAG por sub-agente — un agente no accede a categorías de otro	Paso 3
C3	El contexto del socio se construye desde su sesión, no desde un parámetro del cliente	Paso 3
C4	La conversación pertenece al socio — se verifica user_id antes de leer o escribir	Pasos 6 y 7
C5	Nim no afirma eficacia terapéutica ni da indicaciones clínicas	Paso 5

10. Criterios de decisión

Situación	Resultado
Consulta informativa dentro del conocimiento de Nim	Respuesta directa con herramientas o RAG
Consulta sobre datos propios del socio	Nim accede con su tool y responde
Consulta clínica (diagnóstico, ajuste de dosis)	Nim informa que corresponde al médico y orienta al canal de soporte
Sin sesión activa	Retorna requiresAuth: true, no procesa el mensaje
Consulta sobre datos de otro socio	Nim no tiene herramientas que crucen socios; el contexto está acotado al user_id de la sesión

11. Excepciones y escalamiento

• Consulta compleja o sensible que Nim no puede resolver: Nim orienta al socio a abrir un ticket de soporte (CAL-002) o a contactar directamente al equipo de la organización, conforme a [[wiki/entities/dispensai/protocolos/ATN-003]].
• Base de conocimiento desactualizada: La respuesta puede ser incorrecta. El admin es responsable de mantener los documentos de conocimiento vigentes.
• Respuesta generada errónea: El socio puede reportarla mediante ticket (CAL-002). Nim no está libre de error y la organización no garantiza la exactitud de las respuestas generadas por el modelo.

12. Registros generados

Registro	Contenido	Tabla
Conversación	user_id, agent_type, title, updated_at	chat_conversations
Mensajes	conversation_id, role, content, created_at	chat_messages

No se emite evento ISO al abrir, responder o cerrar una conversación. Ver §17.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Tasa de resolución sin escalamiento	Consultas resueltas sin apertura de ticket ÷ total	Seguimiento, sin meta inicial	chat_conversations vs. tickets
Conversaciones con contenido clínico escalado	Conversaciones en que Nim derivó al médico ÷ total	Seguimiento	Manual / revisión de muestra

Los indicadores de este protocolo no son automáticos hoy. Ver §17.

14. Riesgos y controles

Riesgo	Control	Tipo
Sobrepromesa: Nim da indicación clínica	System prompt que delimita el rol; escalamiento explícito al médico (paso 5)	Preventivo
Acceso cruzado a datos de otros socios	Contexto construido desde user_id de la sesión; tools sin parámetro de user_id externo	Preventivo
Respuesta incorrecta de la base de conocimiento	Admin mantiene la base actualizada; Nim cita su fuente cuando puede	Detectivo
Conversación sin sesión	Guard de autenticación en el handler (C1)	Preventivo
Filtración del historial entre socios	Verificación de user_id antes de leer la conversación (C4)	Preventivo

15. Normativa y referencias

Norma	Referencia	Qué cubre en este protocolo
ISO 9001:2015	§8.2.1	Canal definido para la comunicación con el socio; el canal cubre el §8.5.5 de actividades posteriores al servicio
ISO 26000	6.7.3	Información veraz, sin sobrepromesa; acceso a servicios esenciales con contenido honesto
Ley 21.719	Art. 16	El canal maneja datos de salud del socio (estado de su receta, dispensaciones); el dato se trata con la protección del dato sensible

La cobertura normativa no implica certificación. El protocolo declara qué controles ejecuta la organización, no que esté auditado por un tercero.

16. Anexos y formularios vinculados

• Base de conocimiento de Nim: documentos categorizados en el panel de administración.
• [[wiki/entities/dispensai/protocolos/ATN-003]] — escalamiento humano desde el chat.
• [[wiki/entities/dispensai/protocolos/ATN-001]] — Nim público (sin sesión).

17. Implementación en el sistema

El protocolo está implementado en su flujo principal. Las brechas declaradas afectan la auditabilidad y el límite clínico.

Elemento del protocolo	Dónde vive
Guard de autenticación (C1)	app/api/chat/route.ts — if agentType === "patient" && !user → 401
Enrutamiento de intención (paso 2)	lib/ai/agents/router.ts — routeIntent() con GPT-4o-mini
Cuatro sub-agentes patient (paso 2)	lib/ai/agents/registry.ts — patientAgents
Aislamiento de categorías RAG (C2)	lib/ai/agent-prompts.ts + lib/ai/knowledge-retriever.ts — filtro estructural por ragCategories
Contexto del socio (paso 3)	lib/ai/agent-context.ts — buildPatientContext()
Herramientas patient (paso 4)	lib/ai/tools/patient-tools.ts — createPatientTools()
Persistencia de conversación (paso 6)	db:chat_conversations + db:chat_messages, con verificación de user_id
RLS chat_conversations (C4)	SELECT: auth.uid() = user_id; INSERT WITH CHECK: misma condición. Sin UPDATE/DELETE para el socio — solo admin. Migración 20240101000001_baseline_policies.sql.
RLS chat_messages (C4)	SELECT (socio): EXISTS subquery a chat_conversations filtrando user_id = auth.uid(); SELECT (admin): public.is_admin(); INSERT: misma EXISTS subquery. UPDATE/DELETE solo admin — mensajes IA inmutables para auditoría. Migración 20260520000000_rls_hardening_phase1.sql.

Brechas conocidas:

1. Sin eventos ISO en el canal de chat. Ninguna interacción de Nim autenticado (apertura de conversación, consulta respondida, escalamiento) genera un evento en iso_system_events. El historial existe en chat_messages, pero no hay trazabilidad del canal en la cadena de auditoría de la organización. Si el canal es auditado externamente, la única evidencia son los registros de la base de datos del tenant.
2. El límite clínico de Nim es promisorio, no ejecutable. El system prompt instruye al modelo a no prescribir, pero esa instrucción puede ser ignorada por el modelo o eludida por la formulación de la pregunta. No existe tool ni guard de código que interrumpa la respuesta cuando la pregunta es de naturaleza clínica prescriptiva. El control C5 depende del comportamiento del modelo en cada interacción.

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. Dos brechas declaradas.	Nim / admin
1.1	2026-08-29	Cierre de INFERIDO: RLS de chat_conversations y chat_messages leídas y confirmadas en migraciones 20240101000001 y 20260520000000. Límite clínico confirmado como brecha (promisorio, sin guard ejecutable).	Nim / admin