1. Introdução

Os termos “Human in the Loop” e “Man-in-the-Middle” descrevem fenômenos completamente 
distintos. HITL diz respeito a um mecanismo de governança e segurança sociotécnica e MitM se
constitui em forma de ameaça de segurança da informação (ameaça cibernética). Na Medicina IA
ambas podem atuar sobre a mesma cadeia de dados e decisões.

O Profissional Médico dentro do contexto do fluxo clínico digital, recebe a informação por diversas
maneiras, tais como:
1.	sensores, 
2.	prontuários eletrônicos, 
3.	modelos de IA, 
4.	sistemas de apoio à decisão, 
5.	plataformas em nuvem, 
6.	dispositivos médicos conectados (DMIA)

A segurança do paciente depende simultaneamente de governança decisória e de segurança 
da comunicação. Para tanto:
•	O HITL procura assegurar que decisões relevantes não sejam simplesmente delegadas ao
algoritmo. 
•	A defesa contra MitM procura assegurar que aquilo que o humano e o algoritmo recebem 
seja autêntico, confidencial e íntegro. 
•	A Organização Mundial da Saúde enfatiza a preservação da autonomia humana e a 
responsabilidade na utilização de IA em saúde;
•	O NIST estrutura o gerenciamento de risco de IA ao longo do ciclo de vida e identifica a 
configuração de equipes humano-IA como tema de gestão de risco;
•	Autoridades regulatórias de DMIA, como FDA e Anvisa, tratam a cibersegurança, a 
interoperabilidade, a validação e o gerenciamento de risco como componentes relevantes 
de sistemas médicos digitais [1-7]. 

2. Entendendo o significado de cada conceito

# 2.1 Human in the Loop (HITL): 

O humano como parte deliberada do sistema
HTIL é um padrão de arquitetura e governança no qual a intervenção humana é inserida
intencionalmente em um ponto do fluxo automatizado para que ele possa:
1.	validar dados, 
2.	contextualizar uma recomendação, 
3.	rejeitar uma saída, 
4.	aprovar uma ação, 
5.	solicitar informação adicional, 
6.	escalonar um caso,
7.	interromper o processo.

Na saúde, HITL não deve ser reduzido a um “clique de confirmação”. Para assegurar 
que o controle humano tenha valor clínico validado cientificamente, uma característica
obrigatória de um Ato Médico, o médico deverá:
•	ter acesso e receber informação suficiente,
•	dispor de tempo adequado,
•	possuir autoridade institucional para divergir do sistema, 
•	possuir qualificação real e competência técnica. 

Na Medicina, o mesmo princípio precisa ser elevado a outro patamar porque a consequência 
da validação pode envolver diagnóstico, tratamento, monitoramento ou segurança do paciente,
do tipo:
•	Decisões de alto impacto ou potencialmente irreversíveis.
•	Resultados com baixa confiança, dados incompletos ou possível distribuição fora do treinamento.
•	Conflito entre recomendação algorítmica, sinais clínicos e julgamento profissional.
•	Necessidade de incorporar preferências, valores, contexto social e consentimento do 
paciente.
•	Eventos que exigem atribuição explícita de responsabilidade e trilha de auditoria.

# 2.2	Man-in-the-Middle (MitM): 

O adversário como parte não autorizada da comunicação
MitM descreve uma classe de ataque na qual um agente malicioso consegue se posicionar 
logicamente entre duas partes que acreditam estar se comunicando diretamente, tendo
como objetivo: 
1.	Espionagem, 
2.	alteração de conteúdo, 
3.	injeção de mensagens, 
4.	captura de credenciais,
5.	redirecionamento da comunicação. 

São exemplos de tipos de ações presentes em um Ciberataque:
•	acesso a informações que deveriam permanecer confidenciais.
•	alteração de dados clínicos ou metadados em trânsito.
•	injeção de comandos ou informações falsas em uma sessão aparentemente legítima.
•	redirecionar o tráfego para uma infraestrutura controlada pelo invasor.

Em saúde, o risco não é apenas informacional: a adulteração de telemetria, ordens, 
parâmetros  ou resultados pode produzir consequência clínica. 

O MitM pode explorar:
1.	redes sem autenticação robusta, 
2.	certificados inválidos ou não verificados, 
3.	endpoints comprometidos, 
4.	configuração fraca de TLS, 
5.	redes Wi-Fi mal protegidas, 
6.	DNS ou roteamento manipulados, 
7.	credenciais expostas,
8.	interfaces legadas de DMIA.
A mitigação exige defesa em profundidade: 
1.	autenticação mútua quando apropriada, 
2.	TLS corretamente configurado, 
3.	gestão de certificados e chaves, 
4.	proteção contra replay, 
5.	segmentação, 
6.	monitoramento, 
7.	atualização segura,
8.	validação de integridade, 
9.	política institucional de consolidada
10.	corpo clínico cientificamente qualificada em cibersegurança. 

3. O ponto de encontro entre HITL e MitM na Medicina Inteligente

A presença de um humano no ciclo não protege automaticamente a cadeia de comunicação. 
•	um radiologista pode revisar uma imagem, 
•	um intensivista pode validar um alerta de deterioração,
•	um enfermeiro pode confirmar um parâmetro de bomba de infusão.

Porém, se o dado apresentado foi alterado em trânsito, a supervisão humana começa a partir
de uma premissa corrompida. Por isso, um fluxo confiável deve responder a duas perguntas
independentes:
1.	“quem tem autoridade para tomar ou autorizar esta decisão?”;
2.	“como sabemos que a informação que chegou até essa autoridade é autêntica, íntegra e atual?”. 
HITL responde principalmente à primeira da seguinte maneira:
1.	criptografia, 
2.	autenticação, 
3.	controle de sessão, 
MitM responde principalmente por:
1.	proteção contra replay,
2.	monitoramento.

4. Descrição Comparativa: HITL x MitM

- Legenda

1. Critério

2. Human in the Loop

3. Man-in-the-Middle


A) 
1. Natureza	
2. Mecanismo planejado de governança e supervisão.	
3. Classe de ataque cibernético não autorizado.

B) 
1. Objetivo
2. Adicionar julgamento, contexto, responsabilidade e capacidade de interrupção.
3. Observar, adulterar, injetar ou redirecionar comunicações.

C) 
1. Posição no fluxo	
2. Humano é inserido deliberadamente no ponto decisório.	
3. Adversário tenta ocupar clandestinamente o caminho entre endpoints.

D)
1. Relação com a segurança	
2. Pode reduzir risco decisório e automação indevida.	
3. Cria risco de confidencialidade, integridade, autenticidade e segurança clínica.

E) 
1. Falha típica	
2. Rubber-stamping, viés de automação, revisão insuficiente ou sem autoridade real.	
3. Certificados inválidos, sessão comprometida, rede insegura, credenciais ou chaves
expostas.

F) 
1. Evidência necessária	
2. Registro de quem revisou, o que viu, decisão, justificativa e horário.	
3. Logs de sessão, certificados, assinaturas/MACs, alertas, telemetria e evidências de 
rede.

G) 
1. Mitigação principal	
2. Desenho de workflow, critérios de escalonamento, treinamento e auditoria.	
3. TLS/mTLS, PKI, validação de certificados, integridade, anti-replay, segmentação e
monitoramento.

H)
1. Impacto clínico	
2. Pode evitar que uma recomendação algorítmica inadequada vire conduta.	
3. Pode fazer uma decisão correta ser tomada sobre dados falsificados.

5. Human in the Loop aplicado à Medicina Assistida por IA

•	na prática clínica, a utilidade do HITL depende de o ponto de intervenção humana
ser escolhido de acordo com o risco. 
•	colocar um profissional para revisar absolutamente tudo pode gerar gargalo, fadiga
e revisões superficiais; 
•	não colocar revisão em decisões críticas pode transferir poder excessivo ao sistema
automatizado.
•	o desenho adequado é baseado em risco e contexto.

# 5.1 Situações obrigatórias á revisão humana dedicada 
•	recomendações para iniciar, interromper ou alterar tratamento de alto risco,

•	discordância entre resultados e dados clínicos 

•	Saída do modelo fora das condições previstas de uso, desempenho ou população
validada.

•	Alerta de dispositivo conectado que implique ação imediata no paciente.

•	Casos nos quais uma decisão automatizada produza impacto ético, jurídico ou de
consentimento.

# 5.2 Riscos de um HITL mal desenhado
•	Viés de automação: tendência de aceitar a saída da IA porque “o sistema calculou”.

•	Fadiga de alerta: excesso de revisões reduz atenção justamente nos eventos críticos.

•	Ambiguidade de responsabilidade: ninguém sabe se a decisão é “da IA”, do operador 
ou da instituição.

•	Interface deficiente: o humano vê a recomendação, mas não os dados ou incertezas 
relevantes.

•	Ausência de trilha de auditoria: revisão ocorreu, porém sem registro de motivo, 
versão do modelo ou contexto.

6. Man-in-the-Middle no ecossistema clínico conectado

Hospitais conectados operam como sistemas distribuídos:
1.	monitores, 
2.	bombas, 
3.	estações de trabalho, 
4.	gateways, 
5.	PACS,
6.	prontuários, 
7.	APIs,
8.	dispositivos móveis, 
9.	serviços em nuvem,
10.	plataformas de manutenção remota. 

Essas conectividade trocam mensagens continuamente e ampliam capacidade assistencial, 
mas também aumentam a superfície de ataque. 

O risco de MitM é particularmente relevante quando uma decisão depende de um dado 
transmitido. 

Uma alteração pequena pode ser clinicamente significativa: frequência, saturação, pressão, 
dose, identificação do paciente, prioridade de alerta, timestamp, status de um dispositivo 
ou resultado de exame. O problema deixa de ser apenas “roubo de dados” e passa a incluir 
integridade do cuidado.

# 6.1 Controles defensivos recomendáveis

•	Criptografia de transporte atual e corretamente configurada, com validação 
rigorosa de certificados.

•	Autenticação mútua entre componentes quando o perfil de risco justificar.

•	Assinatura digital ou MAC para mensagens críticas, além da proteção do canal.

•	Proteção contra replay com timestamp, nonce, número de sequência ou janela de
validade.

•	Segmentação de rede e princípio do menor privilégio para limitar movimento lateral.

•	Gestão segura de chaves e certificados, incluindo rotação, revogação e inventário.

•	Monitoramento de anomalias, mudanças de rota, certificados inesperados e falhas 
repetidas de autenticação.

•	Atualização, hardening e eliminação de protocolos inseguros ou legados sempre 
que tecnicamente possível.

7. Cenários clínico-computacionais e códigos didáticos

Nota de segurança: os exemplos de MitM abaixo são exclusivamente defensivos. 

Eles não ensinam interceptação, spoofing, captura de credenciais ou bypass de
autenticação. 

O foco é demonstrar como detectar adulteração e impedir que dados não confiáveis
avancem no fluxo clínico.

7.1 Cenário 1 - HITL: IA de priorização sugere urgência, mas o médico mantém a autoridade final

1. Cenário fictício: 
•	um sistema de apoio à decisão analisa dados sintéticos de um paciente com
suspeita vascular e classifica a prioridade de avaliação. 

•	o caso será obrigatoriamente escalonado para revisão:
o fluxo automatizado pode liberar automaticamente apenas casos de baixo risco 
e alta confiança. perante risco alto, confiança insuficiente, sinal de “fora de distribuição”,
o caso é obrigatoriamente escalonado para revisão humana.

2. Código. Gate de supervisão humana baseado em risco.

from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass
class RecomendacaoIA:
    prioridade: str      # "baixa", "moderada" ou "alta"
    confianca: float     # 0.0 a 1.0
    fora_distribuicao: bool
    justificativa: str


def exige_revisao_humana(rec: RecomendacaoIA) -> bool:
    return (
        rec.prioridade == "alta"
        or rec.confianca < 0.90
        or rec.fora_distribuicao
    )


def registrar_evento(acao: str, detalhe: str):
    agora = datetime.now(timezone.utc).isoformat()
    print({"timestamp": agora, "acao": acao, "detalhe": detalhe})


def human_in_the_loop(rec: RecomendacaoIA):
    if not exige_revisao_humana(rec):
        registrar_evento("auto_fluxo", "Critérios de baixo risco atendidos")
        return "seguir fluxo padrao"

    registrar_evento("escalonamento", rec.justificativa)
    print("Revisão médica obrigatória")
    print(f"Prioridade IA: {rec.prioridade} | confiança: {rec.confianca:.0%}")

    decisao = input("Médico: aprovar / rejeitar / pedir_dados? ").strip().lower()
    registrar_evento("decisao_humana", decisao)
    return decisao

3. Interpretação: 
•	o algoritmo não é proibido de sugerir; ele é proibido de substituir silenciosamente 
a autoridade humana quando o risco definido pelo sistema exige revisão,

•	o log registra escalonamento e decisão, reforçando auditabilidade. 

•	em ambiente real, a lógica precisaria estar integrada ao prontuário, à identidade 
do profissional, à versão do modelo e aos critérios institucionais de governança.

7.2 Cenário 2 - MitM: telemetria de DMIA adulterada é bloqueada por verificação de integridade

1. Cenário fictício: 
•	um DMIA envia telemetria para um gateway clínico. 
•	um atacante capaz de observar o tráfego tenta alterar o valor de um parâmetro no caminho. 
•	O exemplo não executa o ataque; ele demonstra que, se a mensagem original possuir um
código de autenticação baseado em chave (HMAC), a alteração torna a assinatura inválida e
o dado deve ser rejeitado.

2. Código. Detecção de adulteração de mensagem por HMAC e janela temporal.

import hashlib
import hmac
import json
import time

CHAVE_DEMO = b"chave-apenas-para-demonstracao"
JANELA_MAXIMA_S = 30


def serializar(payload: dict) -> bytes:
    # Forma canônica: importante para assinar e verificar o mesmo conteúdo
    return json.dumps(payload, sort_keys=True, separators=(",", ":")).encode()


def assinar(payload: dict) -> str:
    return hmac.new(
        CHAVE_DEMO,
        serializar(payload),
        hashlib.sha256
    ).hexdigest()


def verificar(payload: dict, assinatura: str) -> bool:
    # 1) Proteção simples contra replay
    if abs(time.time() - payload["timestamp"]) > JANELA_MAXIMA_S:
        return False

    # 2) Integridade + autenticidade da mensagem
    esperada = assinar(payload)
    return hmac.compare_digest(esperada, assinatura)


mensagem_original = {
    "device_id": "DMIA-UTI-07",
    "saturacao": 91,
    "timestamp": time.time()
}
assinatura = assinar(mensagem_original)

# Simula APENAS a consequência de uma adulteração em trânsito
mensagem_adulterada = dict(mensagem_original)
mensagem_adulterada["saturacao"] = 99

print("Original aceita?", verificar(mensagem_original, assinatura))   # True
print("Adulterada aceita?", verificar(mensagem_adulterada, assinatura)) # False

Interpretação: 
•	a mensagem adulterada falha porque o atacante não possui a chave necessária para 
gerar uma nova assinatura válida. 

•	em produção, a chave não deve ser embutida no código; deve haver gestão de segredos, 
rotação e proteção de hardware quando aplicável. HMAC também não substitui TLS.

•	o ideal é combinar canal seguro, autenticação dos endpoints e proteção de integridade 
da mensagem de acordo com o risco.

7.3 Cenário 3 - HITL + defesa contra MitM: o humano só revisa dados depois de a cadeia técnica ser considerada confiável

. Cenário fictício: 
•	um sistema recebe um alerta de deterioração enviado por um dispositivo conectado. 

•	antes de apresentar o alerta ao médico, o sistema verifica identidade do dispositivo,
integridade da mensagem e atualidade temporal.

•	somente mensagens válidas chegam ao gate clínico. 

•	se o alerta for crítico, o médico deve confirmar, rejeitar ou solicitar nova aquisição.

2. Código. Defesa em camadas: confiança técnica antes da decisão humana.

# Continuação didática do Código 2: reutiliza assinar(), verificar() e time
from dataclasses import dataclass

DISPOSITIVOS_AUTORIZADOS = {"DMIA-UTI-07", "DMIA-UTI-08"}

@dataclass
class EnvelopeClinico:
    payload: dict
    assinatura: str


def processar_alerta(env: EnvelopeClinico):
    device_id = env.payload.get("device_id")

    # Camada 1: identidade mínima do endpoint
    if device_id not in DISPOSITIVOS_AUTORIZADOS:
        return {"status": "quarentena", "motivo": "dispositivo nao autorizado"}

    # Camada 2: integridade/autenticidade + anti-replay
    if not verificar(env.payload, env.assinatura):
        return {"status": "quarentena", "motivo": "integridade ou tempo invalidos"}

    # Camada 3: decisão clínica proporcional ao risco
    if env.payload.get("criticidade") == "alta":
        print("ALERTA CRÍTICO VALIDADO TECNICAMENTE")
        decisao = input("Médico: confirmar / rejeitar / repetir_medida? ").strip().lower()
        return {"status": "revisado_por_humano", "decisao": decisao}

    return {"status": "aceito", "acao": "fluxo automatizado de baixo risco"}


payload = {
    "device_id": "DMIA-UTI-07",
    "criticidade": "alta",
    "evento": "deterioracao_fisiologica",
    "timestamp": ti

3. Interpretação: 
•	este fluxo expressa a principal tese do artigo. 

•	o humano não deve ser usado como compensação para uma comunicação
insegura. 

•	primeiro o sistema avalia se a mensagem é tecnicamente confiável; depois, 
se o risco exigir, o profissional exerce julgamento clínico. 

• segurança cibernética e governança da IA tornam-se partes sequenciais do
mesmo mecanismo de segurança do paciente.

8. Arquitetura conceitual proposta

Um fluxo clínico inteligente pode ser estruturado em cinco camadas de confiança:

1.	Origem confiável: dispositivo, sistema ou modelo identificado e autorizado.

2.	Comunicação confiável: canal autenticado, criptografado e monitorado.

3.	Dado confiável: integridade, timestamp, origem e coerência validados.

4.	IA governada: versão, finalidade, limites, confiança e critérios de escalonamento 
conhecidos.

5.	Decisão humana proporcional ao risco: autoridade real, registro e possibilidade 
de interrupção.


DMIA / IoMT	->	TLS / mTLS	->	Integridade	->	IA	->	HITL

9. Brasil x Mundo: convergências regulatórias e de governança

Não existe uma norma única denominada “HITL na Medicina”. 
O conceito emerge de princípios de autonomia, supervisão, segurança, responsabilização e 
gerenciamento de risco. Da mesma forma, a proteção contra MitM aparece dentro de requisitos 
mais amplos de cibersegurança, autenticação, integridade, interoperabilidade e segurança 
de software.

# Legenda
Referencial	
Síntese	
Implicação para HITL x MitM

A)
1. Brasil 

2.
Anvisa	A RDC 657/2022 disciplina a regularização de SaMD. 
Material oficial da Anvisa destaca, para documentação técnica aplicável, arquitetura 
de software/hardware, interoperabilidade e comunicação, controles de cibersegurança, 
verificação e validação, gerenciamento de risco e mitigação de anomalias. 

O manual de regularização foi atualizado em 2025 no contexto das RDCs 
751/2022, 
657/2022
848/2024.	

3. Favorece a leitura integrada entre função médica, comunicação, risco 
e controles de cibersegurança.

B)
1. OMS / WHO	

2. A orientação ética para IA em saúde coloca autonomia humana, segurança, 
transparência, responsabilidade, inclusão e sustentabilidade como princípios centrais. 

3. A orientação sobre modelos multimodais amplia a discussão de governança de IA
 generativa em saúde.	
Fundamenta a necessidade de controle humano significativo, sobretudo em decisões 
de alto impacto.

C)
1. NIST	

2.
O AI RMF organiza risco nas funções Govern, Map, Measure e Manage e aborda confiança, 
segurança, resiliência, transparência e responsabilização. 
O roadmap reconhece a relevância de fatores humanos e human-AI teaming. 
O SP 800-52 Rev. 2 trata de seleção e configuração de TLS e certificados.	

3. Conecta governança de IA com práticas de segurança de comunicação e arquitetura de confiança.

D)
1. FDA	

2. A orientação final de 2025 para cibersegurança de DM reforça a gestão do risco 
cibernético no ciclo de vida e na documentação de submissão.	

3. Enquadra cibersegurança como componente de segurança e efetividade do DM, 
não como tema isolado de TI.

10. Discussão

A comparação entre HITL e MitM pode parecer inicialmente apenas linguística, mas 
ela expõe uma distinção fundamental entre dois tipos de “intermediário”. 

O HITL é um intermediário legítimo, identificado, treinado e responsável, inserido
para qualificar uma decisão. 

O MitM é um intermediário ilegítimo, oculto e adversarial,inserido para quebrar a 
confiança da comunicação.

Na assistência médica com IA, a segurança depende de não confundir supervisão 
com proteção. O profissional pode detectar inconsistências clínicas, mas não deve 
ser transformado em detector humano de falhas criptográficas ou de rede. 

Da mesma forma, uma infraestrutura tecnicamente segura não resolve problemas 
de julgamento clínico, vieses do modelo, contexto do paciente ou responsabilidade 
decisória. 

O sistema precisa das duas dimensões.

Essa leitura também desloca o conceito de segurança cibernética para mais perto 
da Tecnovigilância. 
1.	uma falha de integridade em comunicação de DMIA pode se manifestar como 
evento assistencial; 

2. uma anomalia clínica inexplicada pode ter causa técnica;

3. uma decisão humana aparentemente equivocada pode ter sido tomada 
sobre informação adulterada. 

A investigação madura de incidentes deve, portanto, reconstruir simultaneamente 
o caminho do dado, o estado do dispositivo, a versão do software/modelo, 
a decisão humana e a evidência de rede.

11. Perspectivas futuras

•	HITL adaptativo: intensidade de revisão variando conforme risco, confiança, novidade
do caso e histórico de desempenho.

•	Human-on-the-Loop e Human-in-Command: supervisão em níveis diferentes para 
sistemas mais autônomos, preservando capacidade de interrupção.

•	Criptografia e identidade por dispositivo: maior uso de autenticação mútua, credenciais 
de curta duração e hardware seguro em IoMT.

•	Observabilidade clínica-cibernética: correlação entre logs de rede, eventos de dispositivo, 
versão do modelo e decisões profissionais.

•	Tecnovigilância orientada por risco digital: investigação de eventos adversos que
considere  também integridade, autenticidade e cadeia de comunicação.

• Testes de resiliência: simulações controladas de falhas e adulterações em ambientes 
de laboratório para validar detecção, contingência e resposta.

12. Considerações finais

Human in the Loop e Man-in-the-Middle não são conceitos semelhantes; são quase 
opostos na lógica de confiança. 

O HITL insere deliberadamente uma pessoa legítima para melhorar a qualidade e a
responsabilidade de um processo automatizado. 

O MitM insere clandestinamente um agente ilegítimo para comprometer a comunicação. 

Na Medicina Inteligente, entretanto, ambos podem aparecer na mesma trajetória de dados 
e influenciar a mesma decisão clínica.
•	A supervisão humana não basta se os dados não forem confiáveis.
•	A segurança criptográfica não basta se decisões de alto risco forem delegadas sem governança. 

No que diz respeito a informação e a comunicação, um sistema clínico robusto precisa:
1.	conhecer a origem,
2.	assegurar a integridade, 
3.	controlar identidade, 
4.	definir os limites da IA, 
5.	estabelecer critérios de escalonamento,
6.	manter o profissional humano com autoridade real nos pontos em que julgamento, contexto 
7.	e responsabilidade são indispensáveis.
•	Em última análise, o objetivo comum não é proteger apenas o algoritmo, a rede ou o dispositivo. 
É proteger a continuidade, a qualidade e a segurança do cuidado oferecido ao paciente.

Referências

1. World Health Organization. Ethics and governance of artificial intelligence for health: WHO guidance. Geneva: WHO; 2021. https://www.who.int/publications/i/item/9789240029200
2. World Health Organization. Ethics and governance of artificial intelligence for health: guidance on large multi-modal models. WHO; 2025. https://www.who.int/publications/i/item/9789240084759
3. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1; 2023. https://doi.org/10.6028/NIST.AI.100-1
4. National Institute of Standards and Technology. Roadmap for the NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://www.nist.gov/itl/ai-risk-management-framework/roadmap-nist-artificial-intelligence-risk-management-framework-ai
5. McKay K, Cooper D. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. NIST SP 800-52 Rev. 2; 2019. Em revisão pelo NIST em 2026. https://doi.org/10.6028/NIST.SP.800-52r2
6. U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. Final Guidance; 27 Jun 2025. https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity
7. Agência Nacional de Vigilância Sanitária. RDC 657/2022 - Software como dispositivo médico: perguntas e respostas. Anvisa; 2022. https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2022/software-como-dispositivo-medico-perguntas-e-respostas
8. Agência Nacional de Vigilância Sanitária. Manual para Regularização de Equipamento Médico e Software como Dispositivo Médico na Anvisa. Versão atualizada divulgada em 22 out. 2025. https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2025/anvisa-publica-nova-versao-de-manual-para-regularizacao-de-equipamentos-medicos

Oii, Ricardo! Como vai?

Parabéns pelo trabalho.

Vi que você apresentou uma contraposição pouco explorada na literatura ao colocar lado a lado um mecanismo de governança e uma classe de ataque que compartilham apenas a posição de intermediário no fluxo.

A matriz comparativa entre HITL e MitM ficou clara e didática, e os três cenários com código em Python amarram bem a tese, sobretudo o segundo, no qual a verificação por HMAC com janela temporal demonstra a rejeição de telemetria adulterada sem ensinar nada ofensivo. Também merece destaque a arquitetura em cinco camadas de confiança, que ordena o raciocínio de forma prática: primeiro a cadeia técnica é validada, depois a decisão humana entra proporcional ao risco. Essa sequência é o que separa supervisão real de carimbo automático, e é uma distinção que faz diferença quando a consequência do erro chega ao paciente.

Se quiser aprofundar ainda mais:

• Registro de identidade do revisor: associar cada aprovação ao profissional, ao horário e à versão do modelo transforma o log em trilha de auditoria utilizável em investigação de evento adverso.
• Tratamento de timeout: definir o que acontece quando ninguém responde ao escalonamento evita que o fluxo fique suspenso indefinidamente em situação clínica sensível.
• Gestão de segredos: mover a chave do HMAC para um cofre com rotação e revogação aproxima os exemplos didáticos do que seria aceitável em ambiente regulado.

O que você considera mais difícil de resolver na prática hospitalar, calibrar o ponto de escalonamento para que a revisão humana não vire fadiga de alerta, ou convencer a instituição a tratar integridade de comunicação como tema de segurança do paciente e não apenas de TI?

Alguns materiais podem estar em inglês, mas é possível compreendê-los usando o recurso de tradução de páginas do próprio navegador.

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá, Lorena! Sempre aprecio muito suas análises e sua capacidade de enxergar o ponto estrutural da
discussão sem perder a sutileza das implicações práticas.

Política de Segurança Institucional Plena

Entendo que a segunda hipótese se mostra mais relevante. Em ambientes onde a comunicação médico‑
assistencial envolve múltiplos agentes, sistemas e camadas de decisão, calibrar o sistema passaria a ser
uma etapa natural quando existir uma política de segurança institucional que seja plena, ativa e eficiente.

Benefícios da Transformação Digital

Instituições que se adaptaram as necessidades de uma Transformação Digital são marcadas com:

1. protocolos sólidos,
2. auditoria contínua,
3. mecanismos claros de responsabilização,
4. ajuste do sistema regular

"Human-in-the-Loop not as a Option"

Como foi discutido no curso, é nesse ponto que o Human‑in‑the‑Loop deixa de ser apenas uma salvaguarda
e se torna um componente estratégico, ao garantir que a comunicação assistida por IA permaneça alinhada
aos critérios éticos, técnicos e operacionais definidos pela própria instituição.

Resumindo

Ou seja, antes de calibrar o sistema, é preciso que o sistema tenha um ambiente seguro para existir. Depois
disso, a calibragem não é mais uma etapa extraordinária — é simplesmente o próximo passo lógico.

Atenciosamente,
Ricardo