Resolução das Atividades — Agentes de Inteligência Artificial na Medicina (Turma B)
Este arquivo destina-se exclusivamente ao uso do professor. Ele contém as resoluções comentadas das três atividades da Turma B, com orientações pedagógicas detalhadas, dicas de condução da discussão em laboratório e indicações sobre os pontos de maior dificuldade esperada pelos estudantes. Não distribua este documento aos estudantes antes ou durante a realização das atividades.
Resolução da Atividade 1 — Dissecando a arquitetura de um agente clínico
Resolução esperada
A atividade exige a identificação precisa de cada componente da arquitetura funcional de um agente — percepção, representação do conhecimento, raciocínio e planejamento, execução e feedback — aplicada ao PediGuard. O estudante deve usar o enunciado como fonte primária de evidência para cada componente.
Componente de percepção:
Os sensores do PediGuard são, no sentido funcional do material, as interfaces de integração que conectam o agente às fontes de dados do ambiente clínico. O enunciado identifica três sensores distintos. O primeiro é a interface de integração com o monitor multiparamétrico de cada leito, que captura frequência cardíaca, frequência respiratória, pressão arterial, saturação de oxigênio e temperatura a cada 15 minutos — dados fisiológicos contínuos de alta frequência. O segundo é o sistema de resultados laboratoriais, consultado a cada ciclo para verificar se há novos exames disponíveis desde a última consulta — dados laboratoriais discretos e assíncronos. O terceiro é o módulo de enfermagem do prontuário eletrônico, do qual o agente extrai registros de balanço hídrico, administração de medicamentos e evolução clínica das últimas duas horas — dados de enfermagem semiestruturados.
O estudante deve perceber que esses três sensores têm características diferentes: o monitor multiparamétrico produz dados contínuos em alta frequência, o sistema laboratorial produz dados discretos em momentos não previsíveis, e o módulo de enfermagem produz dados textuais semiestruturados que requerem processamento diferente dos dados numéricos. Essa heterogeneidade de fontes é um dado relevante sobre a complexidade do componente perceptivo do agente.
Componente de representação do conhecimento:
O modelo interno contínuo do estado de cada paciente é o componente de representação do conhecimento do PediGuard. A distinção entre dados brutos e modelo interno é o ponto central que o enunciado torna explícito ao dizer que o modelo “representa a estimativa do estado fisiológico atual e a tendência de evolução nas próximas horas”. Os dados brutos são as medidas brutas coletadas a cada ciclo — um valor numérico de frequência cardíaca, um resultado de hemograma, um registro de diurese. O modelo interno vai além: ele integra esses dados ao longo do tempo, calcula tendências, estima o estado fisiológico como uma variável latente que combina múltiplas medidas, e projeta uma trajetória de evolução futura. Em outras palavras, os dados brutos são o que o agente percebeu; o modelo interno é o que o agente sabe sobre o paciente — a representação elaborada que o agente constrói a partir das percepções acumuladas.
O estudante deve articular que o modelo interno é o que permite ao PediGuard detectar padrões de deterioração que não seriam visíveis em nenhuma medida isolada. A deterioração clínica progressiva em pediatria frequentemente se manifesta como uma mudança de tendência em múltiplos parâmetros simultaneamente — algo que só é detectável por um componente de representação que mantém o histórico integrado do paciente.
Componente de raciocínio e planejamento:
O raciocínio do PediGuard tem dois estágios descritos no enunciado. O primeiro estágio é o cálculo da probabilidade de deterioração nas próximas quatro horas com base no modelo interno — o agente compara essa probabilidade a um limiar pré-definido para decidir se deve ou não acionar a etapa seguinte. O segundo estágio, ativado quando o limiar é ultrapassado, é a classificação do padrão de deterioração identificado de forma específica o suficiente para guiar a busca na base de diretrizes. Esse segundo estágio implica raciocínio sobre qual tipo de deterioração foi detectada — respiratória, hemodinâmica, metabólica — para que a busca de diretrizes seja semanticamente adequada.
O critério de decisão é o limiar de probabilidade: abaixo do limiar, o agente continua monitorando sem agir; acima do limiar, ele passa à fase de execução. O estudante deve perceber que o próprio limiar é uma decisão de design com consequências clínicas diretas — um limiar muito baixo gera muitos falso-positivos e produz fadiga de alertas; um limiar muito alto pode deixar casos de deterioração real sem detecção. A calibração do limiar é parte da validação clínica do sistema.
Componente de execução:
O PediGuard realiza duas ações concretas no mundo quando o limiar é ultrapassado. A primeira é uma chamada ao repositório interno de diretrizes pediátricas da UTI, da qual o agente recupera as condutas recomendadas para o padrão de deterioração identificado — essa ação pode ser entendida como a chamada de uma ferramenta externa dentro da arquitetura de function calling. A segunda é o envio da notificação estruturada ao tablet do médico plantonista, contendo o resumo das alterações, a tendência do modelo, as condutas sugeridas e a classificação de urgência em três níveis. Essa segunda ação é o atuador que conecta o agente ao mundo clínico — o único ponto em que o agente produz uma intervenção observável por humanos.
O enunciado é explícito que essas são as únicas ações do agente: ele não altera prescrições, não aciona outros sistemas e não realiza nenhuma intervenção direta sobre o paciente. Toda ação clínica subsequente depende do médico responsável. Esse design posiciona o PediGuard no extremo de menor autonomia do espectro, o que é coerente com seu contexto de uso assistido ainda em avaliação.
Ausência de feedback e suas implicações:
A descrição do PediGuard não contém nenhum mecanismo de feedback. O agente emite notificações, mas não há qualquer referência a um processo pelo qual ele aprenda se as notificações levaram a intervenções clínicas, se os pacientes alertados realmente deterioraram, se os limiares geraram falso-positivos em excesso ou se detectaram casos que foram subidentificados. O modelo interno é atualizado com novos dados, mas o próprio modelo — incluindo seus parâmetros, pesos e limiares — permanece estático ao longo do tempo.
A implicação prática dessa ausência é que o PediGuard não consegue melhorar seu desempenho com a experiência acumulada. Ele não aprende que determinados padrões em pacientes pediátricos específicos da sua UTI têm maior ou menor valor preditivo do que os parâmetros assumidos no seu modelo. Ele não detecta se os médicos estão sistematicamente ignorando suas notificações — um sinal que poderia indicar alto índice de falso-positivos. Ele também não identifica casos em que a deterioração ocorreu sem ter sido prevista pelo sistema, o que poderia indicar que o modelo precisa ser recalibrado.
Para incorporar um ciclo de feedback real, o sistema precisaria de pelo menos três componentes adicionais: um módulo de registro de desfechos (que vinculasse cada notificação gerada ao desfecho clínico subsequente do paciente — deterioração confirmada, não deterioração, ou desfecho desconhecido); um módulo de avaliação do desempenho do modelo (que calculasse métricas como sensibilidade, especificidade e valor preditivo positivo das notificações ao longo do tempo); e um módulo de aprendizagem ou recalibração (que usasse esses dados de desempenho para ajustar os parâmetros do modelo interno e os limiares de acionamento). Sem esses componentes, o PediGuard permanece em um nível de sofisticação intermediário — capaz de manter estado e raciocinar sobre tendências, mas incapaz de evoluir com a experiência.
Dicas de resolução para o professor
O erro mais frequente nessa atividade é a confusão entre dados brutos e modelo interno. Muitos estudantes descrevem ambos como “o que o agente coleta”, sem perceber que o modelo interno é uma representação elaborada construída a partir dos dados brutos, com uma dimensão temporal e uma dimensão preditiva que os dados brutos individualmente não possuem. O professor pode materializar essa distinção com uma analogia: os dados brutos são como os valores individuais de glicemia em um diário; o modelo interno é como a curva de tendência que o endocrinologista traça ao observar esses valores ao longo de semanas, que incorpora não apenas os números mas o padrão deles.
O componente de raciocínio frequentemente é descrito de forma vaga como “o sistema analisa os dados e decide”. A resolução de alto nível especifica o que o raciocínio faz em dois estágios distintos e identifica o critério formal de decisão (o limiar de probabilidade). O professor pode estimular a precisão com a pergunta: “se o sistema precisasse ser auditado, qual seria o critério formal que um inspetor poderia verificar para determinar se o sistema agiu corretamente em um caso específico?”
A ausência de feedback é frequentemente identificada pelos estudantes, mas poucos articulam suas implicações com precisão. A imagem mais eficaz para tornar a implicação concreta é a seguinte: “imagine que o sistema tenha sido calibrado com dados de uma UTI pediátrica de outro estado, onde o perfil de pacientes é diferente. Como o sistema saberia que seus limiares estão gerando falso-positivos em excesso na sua UTI? Sem feedback, ele nunca saberia.”
Como explicar a resolução aos estudantes
A estratégia pedagógica mais eficaz para essa atividade é a construção coletiva de um diagrama do agente em tempo real. O professor projeta um quadro em branco com as quatro caixas da arquitetura funcional (percepção, representação, raciocínio, execução) e pede que a turma popule cada caixa com os elementos que identificou no enunciado. A divergência entre respostas de diferentes estudantes — especialmente na distinção entre dados brutos e modelo interno, e na identificação das ações de execução — é material pedagógico valioso que o professor pode usar para aprofundar a discussão.
Para a parte do feedback, o exercício mais produtivo é pedir que o estudante descreva o que aconteceria ao sistema se ele operasse por doze meses gerando sistematicamente 40% de falso-positivos. Com feedback, o sistema detectaria isso e se recalibraria. Sem feedback, ele continuaria gerando o mesmo percentual de falso-positivos indefinidamente, enquanto os médicos desenvolvem fadiga de alertas e passam a ignorar as notificações — um cenário clínicamente perigoso que é consequência direta da ausência do ciclo de feedback.
Resolução da Atividade 2 — Projetando um sistema multiagente para um problema clínico complexo
Resolução esperada
A atividade exige que o estudante projete uma arquitetura multiagente aplicando os conceitos do material ao contexto específico do stewardship de antimicrobianos. Não existe uma única resposta correta — o que se avalia é a coerência arquitetural, a justificativa dos agentes propostos e a profundidade da análise de propagação de erros e responsabilidade.
Agentes especialistas e seus papéis:
Uma arquitetura bem fundamentada deve incluir pelo menos quatro agentes especialistas distintos, cada um responsável por um domínio que o enunciado identifica como relevante para a decisão sobre antibioticoterapia.
O primeiro agente especialista poderia ser chamado de agente de microbiologia, responsável por acessar o sistema de resultados do laboratório de microbiologia, identificar o microorganismo isolado e seu perfil de sensibilidade e resistência no antibiograma do paciente, e devolver ao orquestrador uma representação estruturada do agente etiológico e dos antibióticos com sensibilidade demonstrada. Esse agente opera sobre dados específicos do paciente.
O segundo agente especialista é o agente de epidemiologia local, responsável por consultar o antibiograma local do hospital — um repositório periodicamente atualizado com as taxas de resistência de microorganismos isolados naquele hospital específico. Ele cruza o microorganismo identificado pelo agente de microbiologia com as taxas de resistência locais para estimar a probabilidade de que a sensibilidade in vitro se traduza em eficácia clínica no contexto daquele hospital. Esse agente responde diretamente ao problema identificado no enunciado de que o perfil de resistência local muda ao longo do tempo.
O terceiro agente especialista é o agente de perfil do paciente, que acessa o prontuário eletrônico do paciente para identificar fatores que condicionam a escolha do antibiótico de forma individual: função renal e hepática para ajuste de dose, histórico documentado de alergias e reações adversas, história de colonização por microorganismos multirresistentes em internações anteriores, uso de antibióticos nas últimas semanas (fator de risco para resistência adquirida), e status imunológico. Esse agente é o que garante que a recomendação seja individualizada e não apenas baseada no microorganismo e nas diretrizes.
O quarto agente especialista é o agente de diretrizes e protocolos, que usa RAG para consultar as diretrizes nacionais e internacionais de tratamento para o microorganismo e foco infeccioso identificados, cruzando com os protocolos internos do hospital aprovados pelo comitê de stewardship. Esse agente responde ao requisito de integrar diretrizes clínicas ao processo decisório de forma atualizada e contextualizável.
Um quinto agente opcional, mas pedagogicamente relevante de incluir, é o agente de interações medicamentosas, que verifica se os antibióticos candidatos apresentam interações clinicamente significativas com a medicação em uso pelo paciente — especialmente relevante em pacientes com múltiplas comorbidades e polimedicação.
O papel do agente orquestrador:
O orquestrador recebe o gatilho inicial — que pode ser uma prescrição de antibiótico registrada, um resultado de hemocultura positiva ou uma solicitação explícita do médico — e decompõe a tarefa em subtarefas paralelas ou sequenciais. Ele dispara o agente de microbiologia (para dados do paciente atual) e o agente de diretrizes (para conhecimento generalista) em paralelo, já que esses dois fluxos são independentes. O agente de epidemiologia local depende do resultado do agente de microbiologia (precisa saber o microorganismo antes de consultar as taxas locais de resistência), então é disparado sequencialmente. O agente de perfil do paciente pode rodar em paralelo com a microbiologia.
Após receber os resultados dos especialistas, o orquestrador realiza a integração: ele identifica os antibióticos com sensibilidade demonstrada pelo antibiograma que também têm boa cobertura local segundo a epidemiologia, que são adequados ao perfil renal e alérgico do paciente, que estão alinhados com as diretrizes para aquele foco infeccioso, e que não apresentam interações com os medicamentos em uso. Com esses critérios integrados, ele gera uma recomendação ranqueada — não apenas “use o antibiótico X”, mas “as opções em ordem de preferência são X, Y e Z, pelas seguintes razões”.
Propagação de erros:
O primeiro cenário de propagação de erros é o agente de epidemiologia local usando dados desatualizados. Imagine que o antibiograma local do hospital foi atualizado há seis meses e que, nesse período, uma cepa de Klebsiella pneumoniae produtora de carbapenemase (KPC) emergiu como relevante naquele hospital. O agente de epidemiologia local ainda mostra taxas de sensibilidade a carbapenens de 85%, quando o valor real atual pode ser de 60%. Esse erro se propaga para o orquestrador, que integra a “evidência” de boa cobertura local e recomenda um carbapenem como primeira linha. O médico segue a recomendação e o paciente não responde adequadamente. A prevenção desse cenário requer que o agente de epidemiologia local inclua explicitamente na resposta que entrega ao orquestrador a data da última atualização do antibiograma e sinalize quando essa data está acima de um threshold pré-definido.
O segundo cenário é o agente de perfil do paciente classificar incorretamente um registro de intolerância como alergia. O prontuário contém a anotação “penicilina — reação gastrointestinal leve em 2019”, que o agente processa como alergia a penicilinas. O orquestrador então exclui toda a classe dos betalactâmicos da recomendação e sugere um antibiótico de segunda linha com maior toxicidade ou menor eficácia para o microorganismo identificado. O paciente tem um desfecho pior do que teria com o betalactâmico. A prevenção requer que o agente de perfil do paciente não apenas classifique a alergia, mas retorne ao orquestrador o texto exato do registro, permitindo que o orquestrador (ou o médico) avalie se a natureza da reação contraindicaria o uso do fármaco no contexto atual.
Responsabilidade em sistemas multiagente vs agente único:
Em um sistema de agente único, quando ocorre um erro, é ao menos teoricamente possível rastrear qual passo do raciocínio levou à recomendação equivocada. A transparência do raciocínio — mesmo que seja um raciocínio Chain-of-Thought de um LLM — produz uma trilha auditável. Em um sistema multiagente, o erro pode emergir não de uma falha em nenhum agente individualmente, mas da interação entre agentes que cada um funcionou corretamente dentro de seu escopo. O agente de epidemiologia reportou o que sabia (dados desatualizados, mas corretamente recuperados). O orquestrador integrou os dados que recebeu (logicamente, dado o que tinha). O médico seguiu a recomendação do sistema. Nenhum componente individual “errou” — e ainda assim o resultado foi adverso.
Essa dificuldade de atribuição de responsabilidade em sistemas distribuídos é um problema qualitativo diferente do problema de responsabilidade em sistemas de agente único. Ela exige que o hospital adote um regime de responsabilidade de sistema — ou seja, que o sistema como um todo seja responsabilizado como uma unidade, independentemente de qual componente específico falhou — e que os desenvolvedores de cada agente especialista declarem explicitamente as condições em que seu agente pode falhar.
Dicas de resolução para o professor
O erro mais frequente nessa atividade é a proposta de agentes que são na verdade variações do mesmo agente com nomenclaturas diferentes. Por exemplo, um “agente de microbiologia” e um “agente de antibiograma” são frequentemente propostos como agentes distintos quando, na prática, descrevem o mesmo domínio de dados. O professor pode orientar com a pergunta: “esses dois agentes acessariam fontes de dados diferentes ou realizariam tipos de raciocínio diferentes?” Se a resposta for não, provavelmente são o mesmo agente descrito de forma redundante.
A propagação de erros é frequentemente abordada de forma superficial (“se um agente errar, o resultado será errado”). A análise de alto nível especifica o mecanismo: qual agente erra, como esse erro se manifesta na saída que entrega ao orquestrador, e por que o orquestrador não consegue detectar esse erro com os dados que tem disponíveis. O professor pode estimular com a pergunta: “o orquestrador saberia que o antibiograma local está desatualizado? Como ele poderia saber?”
Como explicar a resolução aos estudantes
A analogia da equipe multidisciplinar hospitalar, presente no próprio material, é o ponto de partida mais eficaz. O professor pode projetar o diagrama multiagente do material (o diagrama de sepse com orquestrador e cinco agentes especializados) e pedir que a turma adapte a estrutura para o contexto de stewardship de antimicrobianos, substituindo cada agente do diagrama original por um agente adequado ao novo contexto. Essa operação de transposição — usando uma estrutura que já entenderam para projetar uma nova — produz muito mais aprendizagem do que uma proposta de projeto do zero.
Para a discussão de responsabilidade, o exercício mais produtivo é o seguinte: apresente o cenário de propagação de erro do antibiograma desatualizado e pergunte à turma quem seria responsável por uma eventual ação judicial. Isso tipicamente gera discussão acalorada e revela as intuições dos estudantes sobre responsabilidade distribuída, que o professor pode então confrontar com os princípios do material.
Resolução da Atividade 3 — Avaliação crítica de um agente de IA para um comitê hospitalar
Resolução esperada
A atividade exige a aplicação sistemática do framework de cinco dimensões de avaliação crítica ao OncoPlan AI. A resolução de alto desempenho aplica cada dimensão ao dossiê com precisão, identifica tanto os pontos positivos quanto as limitações do produto, e formula uma recomendação fundamentada ao comitê.
Dimensão 1 — Validade:
O estudo de desempenho apresentado pelo fabricante tem limitações de generalização relevantes que o estudante deve identificar de forma específica, não genérica.
A primeira diferença é o escopo diagnóstico. O estudo foi realizado exclusivamente com pacientes com câncer de pulmão de células não pequenas (CPNPC) em estádios IIIb e IV. Um hospital de referência em oncologia trata tumores de múltiplas localizações — mama, cólon, próstata, hematológicos — para os quais os protocolos de quimioterapia são completamente distintos. O desempenho documentado em CPNPC avançado não é transferível para outras neoplasias sem estudos adicionais em cada tipo tumoral.
A segunda diferença é o contexto geográfico e de sistema de saúde. Os centros de validação são norte-americanos de excelência, com padrões de prática que diferem do Brasil em vários aspectos relevantes: acesso a medicamentos (alguns agentes aprovados pela FDA não são aprovados ou disponíveis no Brasil), cobertura por planos de saúde e SUS condicionando a escolha do protocolo, estadiamento influenciado por acesso a exames de imagem e biópsias moleculares.
A terceira diferença é o perfil dos pacientes. Populações em centros de excelência norte-americanos diferem sistematicamente da população brasileira descrita no enunciado — com maior prevalência de diagnóstico em estágios avançados, mais comorbidades não controladas e menor acesso prévio a cuidados preventivos. Os protocolos adequados para essa população podem diferir dos protocolos que o sistema foi treinado a recomendar.
Sobre o que a métrica de concordância de 87,3% mede e o que não mede: ela mede a sobreposição entre a sugestão do sistema e a decisão do oncologista. Ela não mede se as decisões dos oncologistas estavam corretas, se o sistema adicionou valor em relação ao que o oncologista teria decidido sem ele, se o sistema é mais ou menos consistente do que os oncologistas entre si, e se o sistema agiu adequadamente nos 12,7% dos casos em que não houve concordância. Em particular, os 8,1% dos casos em que o oncologista optou por abordagem diferente podem representar os casos clinicamente mais complexos e individualizados — exatamente aqueles em que o sistema é mais propenso a falhar.
Dimensão 2 — Impacto em desfechos:
O dossiê não apresenta dados de desfechos clínicos. A taxa de concordância é uma medida de processo — descreve o comportamento do sistema em relação a uma referência, não o impacto no que importa ao paciente. Para demonstrar impacto clínico, seriam necessários dados sobre sobrevida global, sobrevida livre de progressão, qualidade de vida, taxa de toxicidade grave e necessidade de hospitalização por eventos adversos, comparados entre pacientes gerenciados com e sem o sistema. O estudo ideal seria um ensaio clínico randomizado em que pacientes são alocados aleatoriamente para receber cuidado com ou sem suporte do OncoPlan AI, com acompanhamento de longo prazo para desfechos oncológicos.
O dado de que 4,6% dos oncologistas mudaram sua intenção inicial após ler o relatório do sistema é sugestivo mas ambíguo: essas mudanças foram para melhor ou para pior? Sem dados de desfechos, não é possível saber se essas influências do sistema sobre as decisões médicas foram benéficas ou prejudiciais.
Dimensão 3 — Explicabilidade:
O sistema como descrito oferece um nível razoável de transparência para o oncologista: o relatório inclui o protocolo sugerido, a fundamentação baseada nas diretrizes e os alertas de interação. Essa é uma forma de explicabilidade que permite ao oncologista verificar o raciocínio do sistema e identificar discordâncias. No entanto, há aspectos de explicabilidade que o dossiê não aborda.
Para o oncologista, o dossiê não descreve como o sistema trata casos em que o estadiamento documentado é ambíguo, como lida com neoplasias sem CID-10 específico mapeado aos seus protocolos, ou como explica sua recomendação quando ela difere das diretrizes mais recentes disponíveis. Para o paciente, o dossiê não menciona nenhum requisito de transparência. Sob a perspectiva ética e legal brasileira — considerando a LGPD e os princípios de consentimento informado — pacientes têm direito a saber que sistemas automatizados participam do planejamento do seu tratamento, e a hospital tem a obrigação de informar isso de forma compreensível.
Dimensão 4 — Gestão de falhas:
O primeiro cenário de falha identificável a partir do dossiê é o de tumor com perfil molecular que exige terapia-alvo, mas cujo resultado de biópsia molecular ainda não foi registrado no prontuário eletrônico no momento em que o agente gera sua recomendação. O sistema consulta o CID-10 e o estadiamento e sugere quimioterapia convencional, quando a conduta padrão para um tumor EGFR-mutado ou ALK-rearranjado seria terapia-alvo de primeira linha. O dossiê não descreve nenhum mecanismo pelo qual o sistema detectaria a ausência de informação molecular e sinalizaria que a recomendação está sendo gerada sem esse dado. Essa falha silenciosa é clinicamente perigosa porque a sugestão de quimioterapia convencional onde caberia terapia-alvo não seria identificada como um erro pelo oncologista apenas olhando o relatório do sistema.
O segundo cenário de falha é a base de protocolos desatualizada. Atualizada semestralmente e com a última atualização há quatro meses, a base pode não refletir resultados de ensaios clínicos relevantes publicados recentemente. Em oncologia, ensaios fase III podem mudar a conduta padrão de forma relativamente rápida — a aprovação de um novo regime de imunoterapia ou de uma nova combinação pode tornar o protocolo que o sistema sugere subótimo sem que o sistema saiba disso. O dossiê não descreve nenhum mecanismo de sinalização de desatualização potencial.
Dimensão 5 — Equidade:
O sistema foi treinado com dados de três centros norte-americanos de excelência. Essa origem de dados cria um risco sistemático de viés para a população descrita no enunciado — predominantemente afrodescendente, de baixa renda, com diagnósticos tardios e comorbidades não controladas.
O primeiro mecanismo de viés é o de representação: se a população de treinamento era predominantemente branca e de alta renda (o que é típico de centros de excelência norte-americanos), o sistema pode ter aprendido padrões de estadiamento e de resposta a tratamento que não se generalizam para a população descrita. Diferenças na biologia tumoral entre grupos populacionais podem fazer com que protocolos eficazes em uma população sejam subótimos em outra.
O segundo mecanismo é o de acesso: o sistema sugere protocolos que eram as melhores opções nos centros de treinamento, mas que podem exigir medicamentos de alto custo indisponíveis no contexto de financiamento do hospital. Um sistema que sugere consistentemente protocolos inacessíveis seria ineficaz no contexto de uso, mesmo que tecnicamente correto do ponto de vista oncológico.
Recomendação ao comitê:
A recomendação fundamentada deve ser a aquisição condicionada — não a aquisição imediata (há lacunas de validação e transparência que precisam ser preenchidas antes do uso clínico rotineiro) e não a não aquisição (o produto tem valor potencial real e merece avaliação mais aprofundada). As condições deveriam incluir: realização de um estudo de validação local com a população e o mix de diagnósticos do hospital antes da implantação rotineira; exigência de transparência ao paciente sobre o uso de sistemas automatizados no planejamento do tratamento; estabelecimento de um protocolo de vigilância pós-implantação para detectar divergências sistemáticas entre as recomendações do sistema e os protocolos adotados localmente; e um mecanismo de atualização da base de protocolos mais frequente do que o atual ciclo semestral, ou ao menos um mecanismo de sinalização de potencial desatualização.
Dicas de resolução para o professor
O erro mais frequente nessa atividade é a análise de validade que se limita a dizer que “o estudo foi feito nos EUA”. A resolução de alto nível especifica por que cada diferença entre o contexto de validação e o contexto de uso é clinicamente relevante — não como uma observação genérica, mas como um mecanismo concreto pelo qual o desempenho pode divergir. O professor pode estimular essa especificidade com a pergunta: “se o sistema tiver desempenho inferior nessa população, qual seria o mecanismo específico? A recomendação estaria errada por quê?”
A análise de gestão de falhas frequentemente se limita a cenários óbvios. O cenário do tumor com perfil molecular pendente é menos intuitivo e mais pedagogicamente rico porque envolve uma falha silenciosa — o sistema não sabe o que não sabe, e o médico não vê no relatório nenhuma indicação de que algo está faltando. Esse tipo de falha é mais perigoso do que erros que o sistema sinaliza explicitamente.
Para a análise de equidade, muitos estudantes mencionam viés sem articular o mecanismo. O professor pode conduzir com a seguinte pergunta concreta: “um paciente afrodescendente com câncer de mama triplo-negativo seria representado na base de treinamento desse sistema? Se não, o que isso significa para a qualidade das recomendações para essa paciente?” Isso torna o conceito abstrato de viés algorítmico em um problema clínico concreto e humano.
Como explicar a resolução aos estudantes
A estratégia mais eficaz é conduzir uma simulação real de reunião de comitê de tecnologia. O professor pode designar papéis: alguns estudantes representam o hospital (favoráveis à aquisição por motivos de eficiência), outros representam oncologistas céticos, outros representam uma associação de pacientes (questionando a transparência), e um grupo representa um consultor externo de avaliação de tecnologia (que deve dar o parecer final). A discussão estruturada nesse formato torna explícitas as diferentes perspectivas e interesses que uma avaliação de tecnologia em saúde envolve na prática.
Para conectar a atividade ao módulo de forma mais ampla, o professor pode fechar a discussão com a pergunta: “quais dos cinco critérios do framework você acha que são mais frequentemente ignorados quando hospitais adquirem sistemas de IA na vida real?” Isso estimula a reflexão sobre as dinâmicas institucionais que levam à adoção prematura de tecnologias e conecta o conhecimento técnico à realidade da gestão em saúde que os estudantes encontrarão na prática.