Introdução: Por que a Supervisão Humana é Essencial em Saúde
No setor de saúde e ciências da vida, agentes de IA desempenham papéis cada vez mais relevantes: processam dados clínicos, submetem registros regulatórios, automatizam codificação médica e aceleram o desenvolvimento e comercialização de medicamentos. No entanto, a natureza sensível dos dados médicos e requisitos regulatórios como conformidade com Boas Práticas (GxP) exigem supervisão humana em pontos críticos de decisão. É neste contexto que as construções de aprovação humana no fluxo de trabalho (conhecidas como human-in-the-loop ou HITL) se tornam fundamentais.
A AWS apresentou quatro abordagens práticas para implementar esses mecanismos de aprovação usando seus serviços de nuvem, permitindo que organizações de saúde mantenham tanto a segurança regulatória quanto os ganhos de eficiência que a automação inteligente proporciona.
Desafios Únicos da Implementação de Agentes em Saúde
As organizações de saúde e ciências da vida enfrentam desafios específicos ao implantar agentes de IA:
- Conformidade regulatória – As regulamentações GxP exigem supervisão humana para operações sensíveis. Por exemplo, exclusão de registros de pacientes ou modificações em protocolos de ensaios clínicos não podem prosseguir sem autorização documentada.
- Segurança do paciente – Decisões médicas que afetam o cuidado do paciente devem ter validação clínica antes da execução.
- Requisitos de auditoria – Os sistemas de saúde precisam de rastreabilidade completa: quem aprovou cada ação e quando.
- Sensibilidade dos dados – Informações Protegidas de Saúde (PHI) exigem autorização explícita antes de acesso ou modificação.
As construções HITL fornecem esses pontos de controle necessários mantendo os ganhos de eficiência da automação baseada em agentes, permitindo que as organizações atendam a todos esses requisitos simultaneamente.
Quatro Estratégias Complementares de Implementação
A AWS apresenta quatro padrões complementares, cada um adequado para diferentes cenários e perfis de risco. A implementação utiliza o framework Strands Agents, o Amazon Bedrock AgentCore Runtime e o Protocolo de Contexto do Modelo (Model Context Protocol – MCP), com exemplos de código que podem ser adaptados para casos de uso específicos.
Método 1: Interrupção no Loop do Agente (Sistema de Hooks)
O framework Strands Agents fornece um sistema de hooks que intercepta chamadas de ferramentas antes de sua execução no nível do loop do agente. Essa abordagem aplica uma política HITL uniforme a ferramentas sensíveis sem necessidade de modificar as ferramentas em si.
Um HookProvider registra um callback no evento BeforeToolCallEvent. Quando uma ferramenta sensível é invocada, o hook dispara uma interrupção, pausando o loop do agente até que o operador humano responda. O usuário pode responder com “y” (aprovar uma vez), “n” (negar) ou “t” (confiar – aprovar essa ferramenta pelo restante da sessão).
class ApprovalHook(HookProvider):
SENSITIVE_TOOLS = ["get_patient_condition", "get_patient_vitals"]
def register_hooks(self, registry: HookRegistry, **kwargs: Any) -> None:
registry.add_callback(BeforeToolCallEvent, self.approve)
def approve(self, event: BeforeToolCallEvent) -> None:
tool_name = event.tool_use["name"]
if tool_name not in self.SENSITIVE_TOOLS:
return
# Pular se o usuário já escolheu "confiar sempre" para esta ferramenta
approval_key = f"{tool_name}-approval"
if event.agent.state.get(approval_key) == "t":
return
approval = event.interrupt(
approval_key,
reason={"reason": f"Authorize {tool_name} with args: {event.tool_use.get('input', {})}"},
)
if approval.lower() not in ["y", "yes", "t"]:
event.cancel_tool = f"User denied permission to run {tool_name}"
return
if approval.lower() == "t":
event.agent.state.set(approval_key, "t")O hook é anexado ao agente no momento da construção — as ferramentas permanecem completamente desconhecidas da lógica de aprovação, mantendo a separação de responsabilidades:
agent = Agent(
hooks=[ApprovalHook()],
tools=[get_patient_name, get_patient_condition, get_patient_vitals],
)Método 2: Interrupção no Contexto da Ferramenta
Em vez de um hook centralizado, a lógica de aprovação é incorporada diretamente em cada ferramenta usando tool_context.interrupt(). Essa abordagem oferece controle granular por ferramenta: cada uma implementa suas próprias regras de acesso baseadas no contexto da sessão.
Neste exemplo, a sessão do agente carrega um user_role. Uma função check_access compartilhada implementa controle de acesso baseado em papéis. Usuários não-médicos recebem negação imediata, enquanto médicos recebem um prompt de aprovação:
def check_access(tool_context, patient_id: str, action: str):
user_role = tool_context.agent.state.get("user_role") or "Non-Physician"
if user_role != "Physician":
return f"Access denied: {action} requires Physician role (current: {user_role})"
approval_key = f"{action}-{patient_id}-approval"
if tool_context.agent.state.get(approval_key) == "t":
return None # previously trusted
approval = tool_context.interrupt(
approval_key,
reason={"reason": f"[{user_role}] Authorize {action} for patient {patient_id}"},
)
if approval.lower() not in ["y", "yes", "t"]:
return f"Physician denied access to {action} for patient {patient_id}"
if approval.lower() == "t":
tool_context.agent.state.set(approval_key, "t")
return None # approvedComo no Método 1, a opção de confiança armazena a aprovação para o restante da sessão, evitando prompts repetitivos para a mesma operação.
Método 3: Aprovação Assíncrona com AWS Step Functions
Em muitos cenários empresariais, o fluxo de aprovação requer autorização de um terceiro que não está invocando o agente. Isso necessita de um fluxo de trabalho assíncrono que funcione independentemente da sessão do agente.
Uma abordagem efetiva utiliza AWS Step Functions para orquestrar esses processos de aprovação externa. Neste padrão, a ferramenta do agente dispara uma execução do Step Functions que envia uma solicitação de aprovação a um aprovador externo através de notificação por email via Amazon SNS (Serviço de Notificação Simples).
A ferramenta consulta periodicamente o resultado da aprovação e atualiza o estado da sessão do agente. O usuário também pode verificar o status de aprovação depois usando uma ferramenta separada check_discharge_status:
@tool(context=True)
def discharge_patient(tool_context, patient_id: str, reason: str) -> str:
# Skip workflow if already approved in this session
if tool_context.agent.state.get("external-approver-state") == "approved":
return f"Patient {patient_id} discharged (pre-approved). Reason: {reason}"
response = sfn_client.start_execution(
stateMachineArn=state_machine_arn,
input=json.dumps({"patient_id": patient_id, "action": "discharge", "reason": reason}),
)
return f"Waiting for approval. Execution ARN: {response['executionArn']}"Essa abordagem assíncrona permite operações não-bloqueantes onde os usuários não são forçados a aguardar aprovações que podem levar horas ou dias. A execução do agente prossegue independentemente. O Step Functions mantém trilhas de auditoria detalhadas com histórico completo de execução, gerenciamento de estado persistente entre timeouts de sessão e integração com canais de comunicação empresariais como email, Slack ou Microsoft Teams.
Método 4: Elicitação via Protocolo de Contexto do Modelo (MCP)
O protocolo MCP (Model Context Protocol) introduziu recentemente o conceito de elicitação, que permite que servidores MCP solicitem informações ou aprovação adicionais do usuário durante a execução da ferramenta.
Quando uma ferramenta sensível é chamada, o servidor MCP pausa a execução e envia um prompt de aprovação de volta através do cliente MCP para o usuário final. O usuário vê o prompt, toma uma decisão e o servidor retoma — procedendo com a operação ou negando acesso. Essa comunicação bidirecional é habilitada pelo transporte HTTP contínuo do MCP, que mantém uma conexão com estado entre cliente e servidor.
No servidor MCP, a lógica de aprovação é uma única chamada ctx.elicit() dentro de cada ferramenta sensível:
@server.tool
async def get_patient_condition(patient_id: str, ctx: Context) -> str:
"""Get patient condition. Sensitive — requires approval via MCP elicitation."""
result = await ctx.elicit(
f"⚠️ Approve access to SENSITIVE condition data for patient {patient_id}?"
)
if result.action != "accept":
return f"Access to condition data for patient {patient_id} DENIED."
return f"Patient {patient_id} condition: Hypertension Stage 2, Type 2 Diabetes"No lado do agente, um callback de elicitação é registrado com o cliente MCP. Quando o servidor chama ctx.elicit(), esse callback dispara, transmitindo o prompt de aprovação ao usuário e retornando sua decisão de volta ao servidor. Para agentes locais, este é um prompt terminal. Para agentes implantados no AgentCore Runtime, uma conexão WebSocket retransmite a elicitação para o usuário remoto em tempo real.
Essa abordagem mantém a lógica de aprovação inteiramente dentro das definições de ferramentas do servidor MCP. O agente em si desconhece quais ferramentas exigem aprovação, permitindo adicionar ou modificar requisitos de aprovação de forma independente.
Visão Geral da Arquitetura
A arquitetura da solução utiliza o framework Strands Agents para gerenciamento do ciclo de vida do agente e tratamento de interrupções, implantado no Amazon Bedrock AgentCore Runtime para escalabilidade sem servidor e isolamento de sessão. AWS Step Functions orquestra fluxos de trabalho de aprovação assíncrona com Amazon SNS, enquanto servidores MCP expõem ferramentas ao agente através do MCP — também implantados no AgentCore Runtime.
Todos os códigos para esses padrões de arquitetura estão disponíveis publicamente no repositório GitHub. Cada um dos métodos demonstrados representa uma abordagem autocontida.
Detalhes de Implementação Prática
O agente é implantado no Amazon Bedrock AgentCore Runtime com acesso a ferramentas de saúde em diferentes níveis de sensibilidade. Operações de baixo risco, como buscar o nome de um paciente, executam sem aprovação. Ações de alto risco, como recuperação de sinais vitais ou condições médicas, exigem autorização humana. Operações como alta hospitalar requerem aprovação de supervisor externo através de notificação por email.
A seleção entre os quatro padrões depende do seu caso de uso específico: o Método 1 oferece controle centralizado e uniforme; o Método 2 oferece flexibilidade por ferramenta com controle granular; o Método 3 acomoda aprovações externas assíncronas em ambientes empresariais; e o Método 4 proporciona aprovação interativa em tempo real com protocolo padrão.
Conclusão: Segurança e Eficiência em Harmonia
Os padrões de aprovação humana apresentados permitem que organizações de saúde e ciências da vida construam implantações seguras e compatíveis de agentes de IA. Ao implementar o padrão HITL apropriado para seu caso de uso, é possível implantar fluxos de trabalho prontos para produção que escalem desde projetos piloto até implantações em toda a empresa.
O primeiro passo é identificar quais operações no seu fluxo de trabalho exigem supervisão humana. Em seguida, selecione o padrão HITL que melhor se adequa aos seus requisitos de aprovação — centralizado (Método 1), específico por ferramenta (Método 2), assíncrono (Método 3) ou em tempo real (Método 4).
Para informações adicionais sobre Amazon Bedrock AgentCore, visite a documentação do Amazon Bedrock AgentCore.
Fonte
Human-in-the-loop constructs for agentic workflows in healthcare and life sciences (https://aws.amazon.com/blogs/machine-learning/human-in-the-loop-constructs-for-agentic-workflows-in-healthcare-and-life-sciences/)
Leave a Reply