En la atención médica y las ciencias biológicas, los agentes de IA ayudan a las organizaciones a procesar datos clínicos, presentar presentaciones regulatorias, automatizar la codificación médica y acelerar el desarrollo y la comercialización de medicamentos. Sin embargo, la naturaleza sensible de los datos de atención médica y los requisitos regulatorios como el cumplimiento de las Buenas Prácticas (GxP) requieren supervisión humana en los puntos de decisión clave. Aquí es donde las construcciones humanas en el circuito (HITL) se vuelven esenciales. En esta publicación, aprenderá cuatro enfoques prácticos para implementar construcciones humanas en el circuito utilizando los servicios de AWS.
Por qué es importante la participación humana en la atención sanitaria
Las organizaciones de atención médica y ciencias biológicas enfrentan desafíos únicos al implementar agentes de IA:
Cumplimiento normativo: las regulaciones GxP requieren supervisión humana para operaciones sensibles. Por ejemplo, la eliminación de registros de pacientes o la modificación de protocolos de ensayos clínicos no pueden realizarse sin una autorización documentada.
Seguridad del paciente: las decisiones médicas que afectan la atención del paciente deben tener una validación clínica antes de su ejecución.
Requisitos de auditoría: los sistemas sanitarios necesitan una trazabilidad completa de quién aprobó qué acciones y cuándo.
Sensibilidad de los datos: la información médica protegida (PHI) requiere autorización explícita antes del acceso o modificación.
Las construcciones HITL proporcionan los puntos de control necesarios al tiempo que mantienen las ganancias de eficiencia de la automatización agente para cumplir con estos requisitos.
Descripción general de la solución
Presentamos cuatro enfoques complementarios para implementar HITL en flujos de trabajo agentes. Cada flujo de trabajo es adecuado para diferentes escenarios y perfiles de riesgo, como se describe en nuestra guía para crear agentes de IA en entornos GxP. Creamos estos patrones utilizando el marco de Strands Agents, Amazon Bedrock AgentCore Runtime y Model Context Protocol (MCP), con ejemplos de código que puede adaptar a sus propios casos de uso.
Interrupción de bucle agente (sistema de gancho de marco de agente): utilizamos los ganchos de marco de agente de Strands para hacer cumplir la política de humanos en el bucle. Con los ganchos, podemos interceptar llamadas a herramientas antes de su ejecución. Interrupción del contexto de la herramienta: la lógica de aprobación humana en el circuito también se puede implementar dentro de la lógica de la herramienta directamente para lograr un control y flexibilidad detallados y específicos de la herramienta. El contexto de la sesión se puede utilizar para una lógica de aprobación personalizada. Interrupción de herramienta remota (funciones de pasos de AWS): en algunos casos, es posible que desee enviar una solicitud de aprobación a un sistema o persona de terceros de forma asincrónica. Demostramos este patrón enviando una notificación a un aprobador externo mediante Amazon Simple Notification Service (Amazon SNS). La sesión del agente continúa sin bloqueos mientras la aprobación se realiza en segundo plano. Obtención de MCP: el protocolo MCP introdujo recientemente la obtención, que los servidores utilizan para solicitar información adicional de los usuarios a través del cliente durante las interacciones. El protocolo de obtención nativo del MCP permite la aprobación interactiva en tiempo real utilizando eventos enviados por el servidor (SSE) para una comunicación bidireccional con estado.
Arquitectura
La arquitectura de la solución utiliza Strands Agents Framework para la gestión del ciclo de vida de los agentes y el manejo de interrupciones, implementado en Amazon Bedrock AgentCore Runtime para escalabilidad sin servidor y aislamiento de sesiones. AWS Step Functions organiza flujos de trabajo de aprobación asincrónicos con Amazon SNS, mientras que los servidores MCP exponen herramientas al agente a través del MCP, también implementado en AgentCore Runtime.
Detalles de implementación
Todo el código de estos patrones de arquitectura está disponible públicamente en el repositorio de GitHub.
Cada uno de los siguientes métodos demuestra un enfoque autónomo. El agente se implementa en Amazon Bedrock AgentCore Runtime con acceso a herramientas de atención médica en diferentes niveles de sensibilidad. Las operaciones de bajo riesgo, como buscar el nombre de un paciente, se ejecutan sin aprobación, mientras que las acciones de alto riesgo, como recuperar signos vitales o condiciones médicas, requieren autorización humana. Operaciones como el alta del paciente requieren la aprobación de un supervisor externo mediante notificación por correo electrónico.
Método 1: interrupción de la herramienta local del gancho de bucle agente
Strands Agent Framework proporciona un sistema de enlace que intercepta las llamadas a herramientas antes de su ejecución en el nivel del bucle del agente. Esto aplica una política HITL general en todas las herramientas confidenciales sin modificar las herramientas en sí.
Un HookProvider registra una devolución de llamada en BeforeToolCallEvent. Cuando se invoca una herramienta sensible, el gancho dispara una interrupción, pausando el ciclo del agente hasta que el humano responde. El usuario puede responder con “y” (aprobar una vez), “n” (rechazar) o “t” (confiar: aprobar esta herramienta por el resto de la sesión):
clase ApprovalHook (HookProvider): SENSITIVE_TOOLS = [“get_patient_condition”, “get_patient_vitals”]
def registrar_hooks(self, registro: HookRegistry, **kwargs: Cualquiera) -> Ninguno: registro.add_callback(BeforeToolCallEvent, self.approve) def aprobar(self, evento: BeforeToolCallEvent) -> Ninguno: nombre_herramienta = evento.tool_use[“name”]
si nombre_herramienta no está en self.SENSITIVE_TOOLS: return # Omitir si el usuario eligió previamente “confiar siempre” para esta herramienta clave_aprobación = f”{nombre_herramienta}-aprobación” if event.agent.state.get(clave_aprobación) == “t”: devolución aprobación = evento.interrupt( clave_aprobación, motivo={“razón”: f”Autorizar {nombre_herramienta} con argumentos: {event.tool_use.get(‘input’, {})}”}, ) si la aprobación.lower() no está en [“y”, “yes”, “t”]: event.cancel_tool = f”El usuario denegó el permiso para ejecutar {tool_name}” devuelve si aprobación.lower() == “t”: event.agent.state.set(approval_key, “t”) # herramienta de confianza para el resto de la sesión
El gancho está sujeto al agente durante la construcción; las herramientas permanecen completamente ajenas a la lógica de aprobación:
agente = Agente( ganchos =[ApprovalHook()]herramientas =[get_patient_name, get_patient_condition, get_patient_vitals])
Método 2: interrupción del contexto de la herramienta
En lugar de un enlace centralizado, la lógica de aprobación se integra directamente dentro de cada herramienta mediante tool_context.interrupt(). Esto proporciona un control detallado por herramienta: cada herramienta puede implementar sus propias reglas de acceso según el contexto de la sesión. En este ejemplo, la sesión del agente tiene un rol de usuario. Una función check_access compartida impone el acceso basado en roles: en nuestro ejemplo de código, a los no médicos se les niega directamente, mientras que a los médicos se les solicita la aprobación: al igual que el método 1, la opción de confianza almacena en caché la aprobación de la sesión:
def check_access(tool_context,patient_id: str, action: str): user_role = tool_context.agent.state.get(“user_role”) o “No médico” si user_role != “Médico”: return f”Acceso denegado: {acción} requiere rol de Médico (actual: {user_role})” aprobación_key = f”{action}-{patient_id}-approval” if tool_context.agent.state.get(approval_key) == “t”: return Ninguno # aprobación previamente confiable = tool_context.interrupt( Approval_key, Reason={“reason”: f”[{user_role}] Autorizar {acción} para el paciente {patient_id}”}, ) si aprobación.lower() no está en [“y”, “yes”, “t”]: devuelve f”El médico denegó el acceso a {acción} para el paciente {id_paciente}” si aprobación.lower() == “t”: tool_context.agent.state.set(approval_key, “t”) devuelve Ninguno # aprobado
Método 3: aprobación de herramientas asincrónicas mediante AWS Step Functions
En muchos escenarios empresariales, el flujo de aprobación requiere la autorización de un aprobador externo que no es la persona que invoca al agente. Esto requiere un flujo de trabajo de aprobación asincrónico que pueda funcionar independientemente de la sesión del agente. Un enfoque eficaz utiliza AWS Step Functions para organizar estos procesos de aprobación externos.
En este patrón, la herramienta del agente desencadena un flujo de trabajo de Step Functions que envía una solicitud de aprobación a un aprobador externo mediante una notificación por correo electrónico a través de Amazon SNS. La herramienta sondea el resultado de la aprobación y actualiza el estado de la sesión del agente en consecuencia. El usuario también puede verificar el estado de aprobación más adelante utilizando una herramienta check_discharge_status separada. La herramienta alta_paciente inicia la ejecución de Step Functions y sondea el resultado:
@tool(context=True) def alta_paciente(tool_context, id_paciente: str, motivo: str) -> str: # Omitir el flujo de trabajo si ya está aprobado en esta sesión if tool_context.agent.state.get(“external-approver-state”) == “aprobado”: return f”Paciente {id_paciente} dado de alta (preaprobado). Motivo: {razón}” respuesta = sfn_client.start_execution( stateMachineArn=state_machine_arn, input=json.dumps({“patient_id”:patient_id, “action”: “discharge”, “reason”: Reason}), ) return f”Esperando aprobación. ARN de ejecución: {respuesta[‘executionArn’]}”
Este enfoque asincrónico permite operaciones sin bloqueo en las que los usuarios no se ven obligados a esperar aprobaciones que pueden tardar horas o días, y la ejecución del agente puede continuar de forma independiente. Step Functions mantiene seguimientos de auditoría detallados con un historial de ejecución completo, gestión de estado persistente en los tiempos de espera de las sesiones e integración con los canales de comunicación empresarial existentes, como correo electrónico, Slack o Microsoft Teams. El usuario que inicia un flujo de trabajo confidencial activará una función de estado: el agente devuelve una confirmación al usuario de que se inició el flujo de trabajo. En todo momento, el usuario puede verificar si hay una actualización de estado para asegurarse de que el flujo de trabajo se haya completado.
Método 4: obtención de MCP
El protocolo MCP introdujo recientemente el protocolo de obtención que permite a los servidores MCP solicitar información adicional o aprobación de los usuarios durante la ejecución de la herramienta. Este enfoque sigue los estándares de protocolo y proporciona un mecanismo dinámico para avisar a los usuarios en tiempo de ejecución sin necesidad de configurar los parámetros por adelantado. Se puede utilizar para autorizar la llamada de una herramienta e incluir alguna justificación comercial.
Cuando se llama a una herramienta confidencial, el servidor MCP pausa la ejecución y envía un mensaje de aprobación a través del cliente MCP al usuario final. El usuario ve el mensaje, toma una decisión y el servidor continúa, ya sea procediendo con la operación o negando el acceso. Esta comunicación bidireccional está habilitada por el transporte HTTP transmitible de MCP, que mantiene una conexión con estado entre el cliente y el servidor.
En el servidor MCP, la lógica de aprobación es una única llamada ctx.elicit() dentro de cada herramienta confidencial:
@server.tool async def get_patient_condition(patient_id: str, ctx: Context) -> str: “””Obtener la condición del paciente. Sensible: requiere aprobación mediante obtención de MCP.””” result = await ctx.elicit( f”⚠️ ¿Aprobar el acceso a los datos de condición SENSIBLES para el paciente {patient_id}?”) if result.action != “accept”: return f”Acceso a los datos de condición para el paciente {patient_id} DENEGADO.” return f”Condición del paciente {patient_id}: hipertensión en etapa 2, diabetes tipo 2″
Del lado del agente, se registra una devolución de llamada de elicitación con el cliente MCP. Cuando el servidor llama a ctx.elicit(), esta devolución de llamada se activa, transmitiendo el mensaje de aprobación al usuario y devolviendo su decisión al servidor. Para los agentes locales, este es un mensaje de terminal. Para los agentes implementados en AgentCore Runtime, utilizamos una conexión WebSocket para transmitir la solicitud al usuario final remoto en tiempo real:
Este enfoque mantiene la lógica de aprobación completamente dentro de las definiciones de herramientas del servidor MCP. El propio agente no tiene conocimiento de qué herramientas requieren aprobación, por lo que puede agregar o modificar requisitos de aprobación de forma independiente.
Conclusión
Puede utilizar estas construcciones human-in-the-loop (HITL) para crear implementaciones de agentes de IA seguras y que cumplan con las normas en los sectores de la salud y las ciencias biológicas. Al implementar el patrón HITL adecuado para su caso de uso, puede implementar flujos de trabajo listos para producción que escalan desde proyectos piloto hasta implementaciones en toda la empresa. Empiece por identificar qué operaciones de su flujo de trabajo requieren supervisión humana. Luego, seleccione el patrón HITL que coincida con sus requisitos de aprobación: centralizado (Método 1), específico de la herramienta (Método 2), asíncrono (Método 3) o en tiempo real (Método 4).
Para obtener más información sobre Amazon Bedrock AgentCore, visite la documentación de Amazon Bedrock AgentCore.
Sobre el autor
Pierre de Mallard
Pierre de Malliard es arquitecto senior de soluciones de IA/ML en Amazon Web Services y brinda soporte a clientes en la industria de la salud y las ciencias biológicas. Pierre tiene más de 10 años de experiencia en la creación de aplicaciones y plataformas de aprendizaje automático. En su tiempo libre le gusta tocar el piano y disfrutar de la naturaleza.