1. Introdução

Em hospitais digitais, tecnologia não é apenas suporte administrativo, estando presente na monitorização:
•	do diagnóstico, 

•	da priorização, 

•	da prescrição, 

•	da administração 

•	de medicamentos, 

•	da documentação,

•	da comunicação entre profissionais. 

Consequentemente, uma falha tecnológica pode modificar o cuidado mesmo quando nenhum
invasor está presente e nenhum equipamento está fisicamente quebrado.

A linguagem tradicional de risco costuma separar domínios para facilitar responsabilidade e
controle. Essa separação é útil, mas se torna perigosa quando cria silos. Uma indisponibilidade 
de rede pode:

•	começar como risco de TI, 

•	tornar-se risco operacional ao bloquear o prontuário, 

•	converter-se em risco clínico ao atrasar uma conduta,

•	culminar em evento adverso. 

A mesma cadeia pode ser iniciada por:

•	um erro de integração,

•	derivação algorítmica,

•	atualização inadequada,

•	dependência de fornecedor,

•	ataque cibernético.

Tese central

Na Medicina Assistida por IA, o risco tecnológico deve ser medido pela capacidade de alterar 
o cuidado, e não apenas pela capacidade de interromper sistemas ou gerar perdas financeiras.

2. Objetivos e método

O objetivo é propor uma estrutura didática e operacional que conecte gestão de riscos tecnológicos
à segurança assistencial. Fizemos análise crítica e reestruturação de material formativo sobre FAIR, 
risco tecnológico, cibersegurança e governança, e ainda complementação com a legislação, normas, 
guias regulatórios e referenciais oficiais vigentes consultados até setembro de 2026 [1–16].

•	Definir os principais domínios de risco sem impor uma hierarquia universal artificial.

•	Adaptar a quantificação de risco à natureza clínica e ética da saúde.

•	Integrar frameworks corporativos, técnicos, algorítmicos, sanitários e assistenciais.

•	Demonstrar a aplicação em três cenários clínico-computacionais fictícios.

•	Delimitar responsabilidades, evidências mínimas e critérios de escalonamento.

3. Taxonomia

Risco operacional, tecnológico, de TI e cibernético não formam obrigatoriamente caixas 
perfeitamente encaixadas. Dependendo do modelo de governança, podem ser categorias 
parcialmente sobrepostas. Na saúde, acrescentam-se riscos algorítmicos, sanitários e clínicos. 

O ponto decisivo não é descobrir uma única árvore taxonômica, mas explicitar:
1.	a origem do risco, 

2.	o ativo afetado, 

3.	a função assistencial dependente, 

4.	os controles existentes,

5.	as consequências plausíveis.


# Legenda
1. Domínio	
2. Foco	
3. Exemplos hospitalares

A)
1. Operacional	
2. Falhas em pessoas, processos, sistemas ou eventos externos.	
3. Atraso de atendimento, quebra de fluxo, indisponibilidade de setor.

B) 
1. Tecnológico	
2. Uso, dependência, falha, inadequação ou obsolescência de tecnologia.	
3. DMIA incompatível, atualização defeituosa, dependência de fornecedor.

C)
1. TI	
2. Infraestrutura, redes, servidores, aplicações, bancos e continuidade digital.	
3. Prontuário indisponível, backup inválido, integração HL7/FHIR interrompida.

D) 
1. Cibernético	
2. Ameaças e vulnerabilidades que afetam confidencialidade, integridade ou 
disponibilidade.	
3. Ransomware, credencial comprometida, ataque à cadeia de suprimentos.

E)
1. Algorítmico/IA	
2. Dados, modelo, uso, contexto, viés, deriva, opacidade ou automação inadequada.	
3. Alerta falso, omissão de deterioração, recomendação fora da população validada.

F)
1. Clínico-assistencial	
2. Possibilidade de dano ao paciente ou de degradação do cuidado.	
3. Atraso terapêutico, dose incorreta, perda de monitorização, decisão enviesada.

G)
1. Sanitário/regulatório	
2. Não conformidade do produto, uso ou vigilância ao longo do ciclo de vida.	
3. Uso fora da finalidade, falha de notificação, alteração não controlada.


# Regra de modelagem
 
• Um mesmo evento deve receber múltiplas etiquetas quando atravessa domínios. 
• Classificar como “cibernético” não elimina seu caráter operacional, sanitário ou clínico.

4. Da falha tecnológica à consequência clínica

A cadeia causal pode ser representada em sete etapas. Intervir cedo reduz a probabilidade 
de propagação; intervir apenas no final significa depender do profissional à beira do leito 
para compensar falhas acumuladas.

1.	Fonte de perigo: defeito, ameaça, erro, mudança ou dependência.

2.	Exposição: ativo, interface, modelo, usuário ou processo alcançado.

3.	Falha técnica: perda de integridade, disponibilidade, confidencialidade ou desempenho.

4.	Degradação operacional: fluxo assistencial atrasado, indisponível ou inconsistente.

5.	Decisão clínica afetada: informação omitida, falsa, tardia ou fora de contexto.

6.	Consequência: dano real, incidente sem danos, near miss ou risco potencialmente grave.

7.	Aprendizagem: contenção, evidência, notificação, correção e prevenção.

5. FAIR na Saúde: quantificar sem reduzir a vida a dinheiro

O FAIR define risco como a frequência provável e a magnitude provável de perdas futuras [9]. 
Sua contribuição é decompor incertezas e substituir rótulos vagos por intervalos explícitos. 
Entretanto, a aplicação direta de uma única cifra financeira é insuficiente quando a consequência 
inclui morte, incapacidade, sofrimento, atraso diagnóstico, exposição de dados sensíveis ou perda 
de confiança no cuidado. Propõe-se, portanto, um vetor de perda em vez de uma única variável: 

L = 
(
1. Lclínica, 

2. Lassistencial, 

3. Ldados, 

4. Lregulatória, 

5. Lreputacional,

6. Leconômica. 
).

Os componentes podem ser monetizados quando houver base legítima, mas também podem 
ser expressos por:

•	escalas clínicas, 

•	tempo de indisponibilidade, 

•	número de pacientes expostos, 

•	gravidade potencial, 

•	extensão do comprometimento,

•	reversibilidade. 

A governança decide com transparência como cada dimensão será ponderada; 
não transforma vida humana em item contábil.

# Legenda

1. Componente	
2. Unidades possíveis	
3. Pergunta decisória

A)
Dano clínico	
gravidade; probabilidade; pacientes expostos; reversibilidade	
O evento pode causar morte, incapacidade ou atraso relevante?

B) 
Interrupção assistencial	
minutos/horas; leitos; procedimentos; filas	
Quanto cuidado seguro deixa de ser entregue?

C)
Dados e privacidade	
registros; sensibilidade; integridade; recuperabilidade	
A decisão clínica ou a confidencialidade foi comprometida?

E)
Regulatório/sanitário	
não conformidades; notificações; recolhimento; suspensão	
Há obrigação de vigilância, comunicação ou ação corretiva?

F)
Reputacional/social	
confiança; cobertura; impacto institucional	
O incidente reduz a confiança no serviço e na tecnologia?

G)
Econômico	
resposta; recuperação; paralisação; responsabilidade	
Qual é a exposição financeira e qual controle reduz mais risco?

6. Integração dos frameworks

•	 Nenhum framework isolado cobre todo o problema. 

1. ISO 31000 organiza o ciclo corporativo; 

2. ISO 14971 orienta risco de dispositivos médicos; 

3. NIST CSF 2.0 estrutura governança e resultados de cibersegurança; 

4. NIST AI RMF organiza riscos de IA por Governar, Mapear, Medir e Gerenciar; 

5. FAIR quantifica cenários; 

6. OMS fornece princípios éticos e de direitos humanos; regulação sanitária 
delimita produto, finalidade e ciclo de vida; e a segurança do paciente classifica
consequências assistenciais [1–9,13–16].

# Legenda

1. Referencial	
2. Contribuição	
3. Uso hospitalar sugerido

A) 
1. ISO 31000	
2. princípios e processo geral de risco	
3. política, apetite, comunicação, monitoramento e melhoria
4. 
B) 
1. ISO 14971	
2. gestão de riscos de dispositivos médicos	
3. perigos, situações perigosas, controles, risco residual e pós-mercado

C) 
1. NIST CSF 2.0	
2. Governar, Identificar, Proteger, Detectar, Responder, Recuperar	
3. programa de cibersegurança e resiliência hospitalar

D) 
1. NIST AI RMF	
2. Governar, Mapear, Medir, Gerenciar	
3. risco de modelo, dados, contexto, transparência e supervisão

E) 
1. FAIR / FAIR-CAM	
2. frequência, magnitude e análise de controles	
3. cenários “e se”, priorização e custo-benefício

F) 
1. OMS – IA para a saúde	
2. autonomia, bem-estar, transparência, responsabilidade, equidade e sustentabilidade	
3. governança ética e participação de profissionais e pacientes

G) 
1. ANVISA / SaMD / tecnovigilância	
2. regularização, finalidade, vigilância e notificação	
3. gestão do produto, queixa técnica e evento adverso

H) 
1. Segurança do paciente	
2. dano, incidente, near miss e barreiras
3. análise assistencial e aprendizagem institucional

7. Programa hospitalar integrado de gestão do risco tecnológico

•	 Um programa efetivo precisa ter dono, linguagem comum, gatilhos de escalonamento 
e evidência reprodutível. 

•	 O objetivo não é acumular checklists, mas demonstrar que os controles reduzem cenários
relevantes.

•	Governança: comitê multiprofissional com assistência, tecnovigilância, segurança do paciente,
engenharia clínica, TI, cibersegurança, proteção de dados, qualidade, jurídico e direção.

•	Inventário: DMIA, SaMD, modelos, versões, integrações, fornecedores, dados, dependências, 
usuários e finalidade pretendida.

•	Cenários: ator ou fonte de perigo, ativo, método, efeito técnico, fluxo clínico, pacientes expostos 
e consequências.

•	Controles: prevenção, detecção, resposta, recuperação e fallback clínico independente.

•	Métricas: disponibilidade, latência, falsos positivos/negativos, calibração, drift, overrides, incidentes, 
tempo de contenção e recuperação.

•	Evidências: logs imutáveis, versão do modelo, proveniência de dados, configuração, validação, decisão
humana, comunicação e notificação.

•	Ciclo de vida: aquisição, validação local, implantação, mudança, monitoramento, revalidação,
descontinuação e aprendizado pós-incidente.

8. Matriz de decisão clínica e tecnológica

# Legenda
1.  Sinal
2.  Classificação operacional	
3.  Resposta mínima

A)
1. Saída incompatível com fisiologia	
2. emergência assistencial e suspeita técnica	
3. avaliar paciente; medida independente; suspender confiança na saída; preservar evidências

B)
1. Queda abrupta de desempenho	
2. possíveldrift, mudança de dados ou integração	
3. ativar fallback; comparar baseline; segmentar por unidade/população; revalidar

C)
1. Indisponibilidade crítica	
2. incidente de continuidade	
3. plano de contingência; priorização clínica; comunicação; restauração validada

D) 
1. Integridade ou autoria duvidosa	
2. possível incidente cibernético	
3. isolar; não executar recomendação; verificar assinatura/proveniência; investigar

E) 
1. Mudança de versão/configuração	
2. risco de alteração controlada	
3. aprovação; teste; rollback; documentação; monitoramento intensificado

F)
1. Dano ou potencial grave	
2. evento assistencial e possível tecnovigilância	
3. cuidado imediato; notificação institucional; análise multiprofissional; ação corretiva

9. Cenário derivação silenciosa após atualização do prontuário

# 9.1 Descrição
•	Um modelo de alerta precoce para sepse foi validado com determinadas unidades, códigos 
e padrões de preenchimento. 

•	Após atualização do prontuário eletrônico, a unidade de temperatura muda em parte dos 
registros e campos ausentes passam a ser preenchidos com zero. 


•	O serviço permanece disponível, mas a sensibilidade cai progressivamente. 

•	Nenhum ataque ocorreu: a origem é tecnológica e operacional; a consequência potencial é clínica.

# 9.2 Risco e impacto
•	Fonte: alteração de schema e transformação de dados sem contrato de interface validado.

•	Efeito técnico: mudança de distribuição, dados impossíveis e perda de desempenho.

•	Efeito assistencial: atraso na identificação de deterioração e falsa sensação de segurança.

•	Evidência: versão do modelo, schema, métricas estratificadas, alertas, overrides e desfechos.

# 9.3 Mitigação
•	Validação automática de schema antes da inferência.

•	Monitoramento de dados e desempenho por unidade, população e tempo.

•	Gatilho de fallback quando a qualidade cai abaixo do limite aprovado.

•	Revalidação clínica após mudanças de prontuário, interface ou modelo.

•	Comunicação explícita de limitação ao usuário e auditoria de alertas omitidos.

# 9.4 Código — Barreira determinística de qualidade antes da inferência

from dataclasses import dataclass
from math import isnan

@dataclass
class VitalSigns:
    temperature_c: float
    heart_rate: int
    systolic_bp: int

def validate(v: VitalSigns) -> list[str]:
    errors = []
    if not 30.0 <= v.temperature_c <= 45.0:
        errors.append("temperatura fora do domínio clínico esperado")
    if not 20 <= v.heart_rate <= 250:
        errors.append("frequência cardíaca inválida")
    if not 40 <= v.systolic_bp <= 300:
        errors.append("pressão sistólica inválida")
    return errors

def safe_predict(model, v: VitalSigns):
    errors = validate(v)
    if errors:
        return {"status": "FALLBACK_CLINICO", "errors": errors}
    score = float(model.predict([[v.temperature_c, v.heart_rate, v.systolic_bp]])[0])
    return {"status": "OK", "risk_score": score}

•  Nota:
Código educacional: simplificado, sem dados reais e não destinado ao uso assistencial direto.

# 9.5 Leitura FAIR adaptada
•  (Frequência: mudanças de interface × probabilidade de escaparem dos testes 
× chance de alcançar pacientes)  

•  Magnitude: 
1. pacientes expostos, 
2. tempo até detecção, 
3. gravidade clínica potencial, 
4. retrabalho documental, 
5. investigação,
6. custo de resposta.

10. Cenário — adulteração da configuração em bomba de infusão inteligente

# 10.1 Descrição

•	Uma bomba de infusão conectada recebe bibliotecas de medicamentos por servidor central.

•	Uma credencial comprometida permite publicar configuração não autorizada que eleva limites de dose. 

•	O dispositivo continua operacional e a alteração pode parecer legítima ao usuário. 

•	O evento combina risco de:
1.	cibernético de integridade, 

2.	fornecedor/configuração,

3.	sanitário do dispositivo,

4.	clínico de sobredose.

# 10.2 Contenção e Mitigação
•	Interromper a propagação da biblioteca e identificar dispositivos afetados.

•	Confirmar dose e concentração por fonte clínica independente.

•	Verificar assinatura digital, hash, autor, horário, versão e aprovação da
configuração.

•	Restaurar versão conhecida e validada; manter alternativa manual segura.

•	Preservar logs; acionar engenharia clínica, farmácia, cibersegurança, tecnovigilância 
e segurança do paciente.

•	Notificar conforme natureza do evento, gravidade e exigências aplicáveis.

# 10.3 Código — Verificação de integridade e limites clínicos

import hashlib
import json

APPROVED_HASH = "hash_publicado_em_repositorio_imutavel"
LIMITS = {"heparina_ui_h": (0, 5000), "insulina_ui_h": (0, 30)}

def canonical_hash(payload: dict) -> str:
    raw = json.dumps(payload, sort_keys=True, separators=(",", ":")).encode()
    return hashlib.sha256(raw).hexdigest()

def validate_library(payload: dict) -> dict:
    if canonical_hash(payload) != APPROVED_HASH:
        return {"allow": False, "reason": "integridade não comprovada"}
    for drug, value in payload["max_rates"].items():
        low, high = LIMITS[drug]
        if not low <= value <= high:
            return {"allow": False, "reason": f"limite inválido: {drug}"}
    return {"allow": True, "version": payload["version"]}

•  Nota: 
Código educacional: simplificado, sem dados reais e não destinado ao uso assistencial direto.

# 10.4 Princípio de segurança
•	Disponibilidade sem integridade não é cuidado seguro. 

•	Dispositivo que permanece ligado, mas opera com configuração adulterada, pode 
representar risco maior do que um dispositivo corretamente indisponível.

11. Cenário — Injeção de prompt em agente clínico com RAG

# 11.1 Descrição
• 	Um agente hospitalar recupera protocolos institucionais para responder 
dúvidas sobre anticoagulação. 

•	Um documento malicioso é inserido na base e contém instrução oculta 
para ignorar  contraindicações e recomendar dose padronizada. 

•	O modelo segue o texto recuperado, apresenta resposta convincente e cita
o documento comprometido. 

•	O risco:

1.	nasce na cadeia de conhecimento, 


2.	atravessa RAG e automação,

3.	alcança uma decisão clínica de alto impacto.

# 11.2 Barreiras necessárias
•	Repositório autorizado, controle de versão, assinatura e proveniência dos documentos.

•	Separação entre conteúdo recuperado e instruções do sistema; conteúdo nunca recebe 
autoridade de comando.

•	Regras determinísticas para contraindicações, doses máximas e necessidade de validação
humana.

•	Exibição de fonte, versão, data e trecho utilizado.

•	Bloqueio de execução automática em decisões de alto risco.

•	Testes de prompt injection, red teaming e monitoramento de respostas.

# 11.3 Código  — RAG com proveniência, allowlist e veto clínico

TRUSTED_SOURCES = {"protocolo_anticoagulacao_v7.pdf"}
HIGH_RISK_TERMS = {"sangramento ativo", "plaquetas < 50000", "hemorragia intracraniana"}

def authorize_context(chunks: list[dict]) -> list[dict]:
    trusted = []
    for chunk in chunks:
        if chunk["source"] not in TRUSTED_SOURCES:
            continue
        if not chunk.get("signature_valid", False):
            continue
        trusted.append(chunk)
    return trusted

def clinical_gate(patient_summary: str, answer: str) -> dict:
    summary = patient_summary.lower()
    if any(term in summary for term in HIGH_RISK_TERMS):
        return {"release": False, "action": "REVISÃO MÉDICA OBRIGATÓRIA"}
    return {"release": True, "action": "APOIO À DECISÃO; NÃO EXECUTAR AUTOMATICAMENTE"}


•  Nota: 
Código educacional: simplificado, sem dados reais e não destinado ao uso assistencial direto.

11.4 Princípio de governança
•	RAG melhora acesso à informação, mas não converte documento em
verdade nem fonte em comando. 

•	Quanto maior o impacto clínico, maior deve ser a independência da validação.

12. Quadro comparativo dos três cenários

# Legenda

1. Cenário	
2. Risco dominante	
3. Primeira barreira	
4. Linha de defesa final

A) 
1. Drift após atualização	
2. tecnológico + algorítmico	
3. contrato de dados e monitoramento	
4. avaliação clínica independente

B) 
1. Configuração de bomba	
2. cibernético + sanitário	
3. assinatura, hash, controle de mudança	
4. checagem de dose e fallback


C) 
1. Prompt injection em RAG	
2. supply chain + IA	
3. proveniência e isolamento de instruções	
4. veto determinístico e revisão médica

13. Brasil e mundo: convergências e lacunas

O Brasil possui 
•	base sanitária para SaMD, 
•	estrutura de tecnovigilância,
•	regime geral de proteção de dados, 

Ainda assim, sua implantação hospitalar de IA tem esbarrado na exigência de maior 
integração entre:
1.	regulação do produto, 
2.	governança institucional, 
3.	cibersegurança, 
4.	validação local,
5.	monitoramento de desempenho [13–17]. 

Na esfera internacional OMS, NIST, FDA e IMDRF vêm reforçando:
1.	ciclo de vida, 
2.	transparência, 
3.	desempenho real, 
4.	controle de mudanças,
5.	participação das partes afetadas [1–5,10–12,20].

# Legenda
1. Dimensão	
2. Brasil	
3. Referências internacionais	
4. Prioridade prática

A) 
1. SaMD/DMIA	
2. RDC 657/2022 e RDC 751/2022; regularização e enquadramento	
3. FDA TPLC; IMDRF GMLP; ISO 14971	
4. inventário regulatório e uso conforme finalidade

B)
1. Pós-mercado
2. tecnovigilância, eventos adversos e queixas técnicas/Notivisa	
3. monitoramento real, drift e gestão de mudanças
4. vincular incidentes técnicos a consequências clínicas

C)
1. IA responsável	
2. LGPD, governança institucional e princípios éticos	
3. OMS; NIST AI RMF; perfis de IA generativa	
4. validação local, transparência e supervisão

D) 
1. Cibersegurança	
2. LGPD, requisitos setoriais e políticas institucionais	
3. NIST CSF 2.0; NIST SP 800-53; CIS Controls	
4. Governar + segmentar + detectar + recuperar

E)
1. Quantificação	
2. adoção ainda heterogênea	
3. FAIR e FAIR-CAM	
4. usar intervalos e vetor de perdas clínicas e empresariais

14. Indicadores para tecnovigilância e governança

# Legenda
1. Indicador	
2. Finalidade	
3. Gatilho de ação

A) 
1. Taxa de override clínico	
2. detectar baixa utilidade ou automação inadequada	
3. crescimento sustentado ou concentração por unidade

B) 
1. Falsos negativos/ positivos estratificados	
2. identificar degradação e desigualdade	
3. desvio do intervalo validado

C) 
1. Drift de entrada e saída	
2. detectar mudança de dados/modelo	
3. limite estatístico + revisão clínica

D) 
1. Tempo até contenção e recuperação	
2. medir resposta e resiliência	
3. acima do RTO assistencial aprovado

E)
1.  Incidentes por versão/configuração
2.  correlacionar mudanças e falhas	
3.  aumento após release ou fornecedor

F) 
1. Proporção de logs completos
2. garantir investigabilidade	
3. qualquer lacuna em sistema crítico

G)
1. Pacientes potencialmente expostos	
2. priorizar análise e comunicação	
3. gravidade × escala × reversibilidade

15. Responsabilidades multiprofissionais

•	A governança não deve atribuir ao médico a responsabilidade exclusiva por sistemas 
que ele não desenvolve nem controla. 

•	A governança não pode excluir o médico de decisões que alteram o cuidado. 

•	Responsabilidade segura é distribuída, explícita e compatível com autoridade real.


# Legenda

1. Ator	
2. Responsabilidade essencial

A)
1. Corpo clínico	
2. validar plausibilidade, reconhecer limitações, supervisionar decisões e comunicar risco

B)
1. Enfermagem e Farmacia	
2. identificar discrepâncias operacionais, barreiras de medicação e efeitos no fluxo

C)
1. Engenharia clínica/tecnovigilância	
2. ciclo de vida do dispositivo, manutenção, investigação, evidências e notificações

D)
1. TI e interoperabilidade	
2. disponibilidade, integrações, identidade, backup, configuração e continuidade

E)
1. Cibersegurança
2. ameaças, vulnerabilidades, detecção, contenção, resposta e recuperação

F)
1. Qualidade/segurança do paciente
2. classificação assistencial, análise de causa, barreiras e aprendizagem

G)
1. DPO/jurídico/regulatório	
2. proteção de dados, obrigações, contratos e comunicação

H)
1. Direção e conselho	
2. apetite de risco, recursos, accountability e decisão sobre risco residual

16. Benefícios, desafios e limitações

# 16.1 Benefícios
•	Linguagem comum entre assistência, tecnologia e governança.

•	Priorização baseada em cenários, não em medo ou checklist.

•	Decisões de investimento conectadas a redução mensurável de risco.

•	Maior capacidade de detectar propagação do risco até o paciente.

•	Evidência mais robusta para auditoria, tecnovigilância e aprendizagem.

# 16.2 Desafios
•	Escassez de dados confiáveis de frequência e impacto.

•	Dificuldade de mensurar dano potencial e efeitos distributivos.

•	Dependência de fornecedores e baixa transparência de modelos.

•	Fragmentação entre núcleos hospitalares e responsabilidades.

•	Risco de falsa precisão produzida por modelos quantitativos mal calibrados.

17. Perspectivas futuras

•	Gêmeos digitais de risco que simulem propagação de falhas entre infraestrutura, 
dispositivo, workflow e paciente.

•	Monitoramento contínuo de desempenho real de DMIA e SaMD com métricas 
clínicas estratificadas.

•	Registros institucionais de IA com model cards, data sheets, finalidade, risco, 
responsável e plano de retirada.

•	Quantificação multicritério que combine FAIR com gravidade clínica e equidade.

•	Red teaming clínico, testes de caos seguros e exercícios de contingência 
multiprofissionais.

•	Integração entre dados de tecnovigilância, segurança do paciente, cibersegurança 
e qualidade.

18. Considerações finais

• O avanço da Medicina Inteligente torna inadequado tratar risco tecnológico como 
assunto restrito à informática. 

• Sistemas digitais agora participam do cuidado e, portanto, suas falhas podem alterar 
diagnóstico, terapia, monitorização, documentação e continuidade assistencial. 

• A gestão madura começa ao reconhecer essa propagação.

• Frameworks e modelos quantitativos são úteis quando organizam perguntas melhores, tornam
incertezas visíveis e sustentam decisões proporcionais. 

• Tornam-se perigosos quando substituem julgamento, prometem precisão inexistente ou reduzem
dano humano a um número financeiro. 

• Na saúde, quantificar deve ampliar a responsabilidade, não empobrecer o significado da perda.

• A proteção efetiva do paciente depende de arquitetura sociotécnica: dispositivos e modelos seguros, 
dados íntegros, redes resilientes, profissionais capacitados, supervisão humana real, contingência
praticável, logs preservados e governança capaz de agir. 

• Quando essas camadas se integram, a instituição deixa de apenas reagir a falhas e passa a aprender 
com sinais precoces, conter riscos antes do dano e decidir com maior clareza, ética e responsabilidade.

Reflexão Final

Na Medicina Assistida por IA, a pergunta não é apenas 
•	“qual é a probabilidade de o sistema falhar?”, 
Ela passou a ser :
“
1.	como essa falha alcançaria o paciente? 
2.	quem a perceberia? 
3.	quais barreiras interromperiam a cadeia?
4.	como demonstrar que o risco foi realmente reduzido?
”.

19. Referências bibliográficas

1. WORLD HEALTH ORGANIZATION. Ethics and governance of artificial intelligence for health: WHO guidance. Geneva: WHO, 2021. Disponível em: https://www.who.int/publications/i/item/9789240029200. Acesso em: 2 set. 2026.
2. WORLD HEALTH ORGANIZATION. Ethics and governance of artificial intelligence for health: guidance on large multi-modal models. Geneva: WHO, 2025. Disponível em: https://www.who.int/publications/i/item/9789240084759. Acesso em: 2 set. 2026.
3. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg: NIST, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 2 set. 2026.
4. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). Gaithersburg: NIST, 2024. Disponível em: https://doi.org/10.6028/NIST.AI.600-1.
5. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Cybersecurity Framework 2.0. Gaithersburg: NIST, 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 2 set. 2026.
6. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Managing Information Security Risk: Organization, Mission, and Information System View. NIST SP 800-39. Gaithersburg: NIST, 2011. Disponível em: https://doi.org/10.6028/NIST.SP.800-39.
7. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management: guidelines. Geneva: ISO, 2018.
8. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14971:2019 — Medical devices: application of risk management to medical devices. Geneva: ISO, 2019.
9. OPEN GROUP. Open FAIR™ Risk Analysis Standard. The Open Group Standard, 2021. Disponível em: https://publications.opengroup.org/c20g. Acesso em: 2 set. 2026.
10. U.S. FOOD AND DRUG ADMINISTRATION. Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations. Draft Guidance. Silver Spring: FDA, 2025. Disponível em: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing. Acesso em: 2 set. 2026.
11. U.S. FOOD AND DRUG ADMINISTRATION. Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles. Silver Spring: FDA, 2024. Disponível em: https://www.fda.gov/medical-devices/software-medical-device-samd/transparency-machine-learning-enabled-medical-devices-guiding-principles. Acesso em: 2 set. 2026.
12. INTERNATIONAL MEDICAL DEVICE REGULATORS FORUM. Good Machine Learning Practice for Medical Device Development: Guiding Principles. IMDRF, 2025.
13. BRASIL. Agência Nacional de Vigilância Sanitária. Resolução RDC nº 657, de 24 de março de 2022. Dispõe sobre a regularização de software como dispositivo médico (Software as a Medical Device — SaMD). Brasília: ANVISA, 2022.
14. BRASIL. Agência Nacional de Vigilância Sanitária. Perguntas e respostas sobre a RDC 657/2022. Brasília: ANVISA, 2022. Disponível em: https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2022/software-como-dispositivo-medico-perguntas-e-respostas. Acesso em: 2 set. 2026.

Boa tarde, Ricardo! Tudo bom?

Gostei demais da sua pesquisa!

Mandou muito bem explorando a taxonomia dos riscos na saúde digital e apresentou com clareza a relação entre domínios sobrepostos como operacional, tecnológico e clínico. Ainda destacou a importância da governança integrada para evitar silos e falhas de comunicação. Esse raciocínio mostra profundidade acadêmica, visão sistêmica e preocupação em alinhar tecnologia com segurança assistencial.

Continue postando as suas soluções! Além de ganhar pontos de XP na plataforma, você pode ajudar outros estudantes no fórum.

Ah, uma pergunta: o que você considera mais relevante para fortalecer a resiliência digital em hospitais, investir primeiro em frameworks de risco adaptados à saúde ou em auditorias clínicas independentes que validem continuamente os sistemas de IA?

Fico à disposição! E se precisar, conte sempre com o apoio do fórum.

Abraço e bons estudos!

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