Resolução das Atividades — Agentes de Inteligência Artificial na Medicina (Turma A)
Este arquivo destina-se exclusivamente ao uso do professor. Ele contém as resoluções comentadas das três atividades da Turma A, 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 — Identificando e classificando agentes de IA em cenários clínicos
Resolução esperada
A atividade exige dois movimentos analíticos distintos: primeiro, a classificação de cada sistema como modelo passivo ou agente de IA; segundo, a identificação do tipo de agente dentro da taxonomia de Russell e Norvig para os sistemas classificados como agentes. O critério para o primeiro movimento é funcional, não tecnológico: a questão não é o que o sistema calcula internamente, mas se ele age de forma autônoma no ambiente sem precisar ser consultado.
O Sistema Alfa (emergência, alertas por limiares fixos) é um agente de IA, especificamente do tipo reativo simples. A evidência textual é clara: o sistema age de forma autônoma — ele aciona alertas sem precisar ser consultado pelo médico — e o faz por meio de regras condição-ação sem memória, sem modelo do mundo e sem objetivo explícito além de reagir imediatamente a cada percepção isolada. O enunciado explicita que o sistema não registra histórico de alertas e não considera o contexto clínico, o que confirma a ausência de estado interno. A regra “SE FC > 120 bpm ENTÃO emitir alerta” é o exemplo mais clássico de uma regra condição-ação de agente reativo simples. O estudante deve perceber que a simplicidade do algoritmo não impede que o sistema seja classificado como agente — o critério é o padrão de ação autônoma, não a sofisticação.
O Sistema Beta (UTI adulto, monitoramento de 28 variáveis com detecção de tendências) é um agente de IA do tipo reativo com estado interno (baseado em modelo). O elemento decisivo está na frase “mantém um modelo interno do estado de cada paciente desde a admissão” e no fato de que o sistema “rastreia tendências ao longo do tempo”. Essas duas características definem precisamente o agente baseado em modelo: ele não reage a percepções instantâneas isoladas (como o Alfa), mas mantém uma representação interna que captura como o mundo evoluiu ao longo do tempo, e raciocina sobre esse estado interno acumulado. O padrão de deterioração detectado — queda de pressão combinada a aumento de lactato e piora de diurese — só pode ser identificado por um sistema que mantém e integra informações ao longo de um período de 90 minutos, o que é tecnicamente impossível para um agente reativo simples sem memória. O envio autônomo de mensagem ao WhatsApp confirma que o sistema age sem ser consultado, o que o qualifica como agente.
O Sistema Gama (ambulatório de diabetes, exibe informações quando o médico abre o prontuário) é um modelo passivo. O critério definitivo está na frase “só exibe as informações quando o médico acessa o prontuário manualmente”. Um sistema que depende de ação humana prévia para produzir qualquer saída não age autonomamente no ambiente — ele responde a consultas. Não importa que seja integrado ao prontuário ou que exiba dados úteis; a passividade está no mecanismo de ativação. Para que o Sistema Gama se tornasse um agente reativo simples, seria necessário apenas que ele passasse a monitorar continuamente os dados e enviasse uma notificação automática ao médico responsável sempre que, por exemplo, um novo resultado de hemoglobina glicada acima de 8% fosse registrado no sistema, sem depender de o médico abrir o registro. Essa mudança simples — de exibição reativa para ação autônoma por condição — é o que separa um modelo passivo de um agente reativo simples.
O Sistema Delta (oncologia, verificação autônoma de interações ao detectar nova prescrição) é um agente de IA do tipo baseado em objetivos. A distinção em relação ao Sistema Beta é o elemento-chave que o estudante precisa dominar. O Sistema Beta mantém um modelo e alerta quando detecta deterioração — mas não tem um objetivo explícito além de reagir ao que percebe. O Sistema Delta, por contraste, tem uma meta declarada: impedir que uma combinação medicamentosa perigosa chegue ao paciente antes da liberação pela farmácia. Para atingir esse objetivo, ele planeja e executa múltiplos passos deliberados: consulta a base de interações, verifica o histórico individual do paciente, consulta as diretrizes, avalia o risco e, somente então, gera a notificação com alternativas. Esse encadeamento deliberado de ações orientado por uma meta explícita é o traço definidor do agente baseado em objetivos. Não se trata de uma reação imediata a um gatilho, mas de um processo de planejamento em múltiplos passos orientado ao cumprimento de um objetivo.
A resposta mais sofisticada, que diferencia desempenho satisfatório de desempenho excelente, articula de forma dissertativa a relação entre os quatro sistemas: eles representam pontos diferentes no espectro que vai do modelo passivo ao agente com raciocínio orientado por objetivos, e essa progressão tem implicações práticas concretas — especialmente no que diz respeito ao nível de supervisão que cada tipo de sistema exige e ao perfil de erros que pode cometer.
Dicas de resolução para o professor
O erro mais frequente esperado é classificar o Sistema Gama como agente por ele “monitorar” os dados de diabetes. Os estudantes confundem o fato de o sistema ter acesso a dados com o ato de agir autonomamente sobre eles. A pergunta-chave para corrigir esse equívoco é: “o sistema toma alguma iniciativa sem que o médico faça algo primeiro?” Se a resposta for não, o sistema é passivo.
Um segundo equívoco comum é classificar o Sistema Beta como agente baseado em objetivos porque ele tem o “objetivo” de identificar deterioração. Aqui o professor deve explorar a distinção sutil: ter um comportamento que parece orientado a um objetivo não é o mesmo que ter uma representação explícita do objetivo que guia o planejamento de ações. O Sistema Beta reage a padrões — o Sistema Delta planeja passos para atingir uma meta. A pergunta que ajuda a distinguir é: “o sistema escolhe entre múltiplos caminhos possíveis para atingir um resultado desejado, ou apenas detecta uma condição e dispara uma resposta pré-definida?”
O terceiro ponto de atenção é a discussão integradora solicitada no enunciado. Estudantes que respondem sistema por sistema, de forma isolada, perdem a oportunidade de articular os conceitos. O professor pode estimular a integração perguntando: “como a complexidade da gestão de incerteza aumenta ao longo dessa escala de sistemas?” O Sistema Alfa não tem incerteza — apenas aplica um limiar. O Sistema Beta trabalha com padrões probabilísticos. O Sistema Delta precisa raciocinar sobre múltiplas fontes de evidência para justificar sua conclusão. Essa progressão conecta a taxonomia a implicações práticas de segurança.
Como explicar a resolução aos estudantes
A estratégia mais eficaz é partir do caso do Sistema Gama. Pergunte à turma: “o Sistema Gama sabe que o paciente do Dr. Paulo está com HbA1c de 9,2%? Se sabe, por que não avisou o médico ontem à noite?” A resposta — porque ninguém abriu o prontuário — explicita o que significa ser passivo de forma mais memorável do que qualquer definição formal.
Em seguida, use a pergunta inversa para construir a noção de agente reativo simples: “o que seria necessário mudar para que o Sistema Gama soubesse que precisa avisar o médico sem que ele precise abrir o prontuário?” Essa pergunta quase sempre produz a resposta correta por inferência: o sistema precisaria verificar continuamente os dados e agir quando uma condição fosse satisfeita — ou seja, precisaria de um mecanismo de percepção ativa e de uma regra condição-ação, que são os dois ingredientes do agente reativo simples.
Para o Sistema Beta vs Delta, o exercício mais útil é pedir que o estudante descreva o que cada sistema faria diante de uma situação específica nova que não estava prevista nas regras: o Sistema Beta detectaria um padrão de deterioração não previsto (porque raciocina sobre o estado, não sobre regras rígidas), mas não saberia como agir — apenas alertaria. O Sistema Delta, com um objetivo explícito de segurança medicamentosa, procuraria ativamente as ferramentas disponíveis para verificar se uma combinação nova representa risco, mesmo sem uma regra específica para ela.
Resolução da Atividade 2 — Analisando um agente com function calling em contexto clínico
Resolução esperada
A atividade exige a aplicação de três conceitos técnicos do material — function calling, RAG e gestão de dados incompletos — a um agente clínico concreto, além de uma avaliação crítica da preocupação do cardiologista.
Identificação e análise das ferramentas (function calling):
O ciclo de avaliação do agente de insuficiência cardíaca utiliza quatro ferramentas distintas, identificáveis diretamente no enunciado. A primeira é uma ferramenta de consulta ao sistema de resultados laboratoriais do hospital, que o agente usa para buscar exames recentes como creatinina, eletrólitos e marcadores de função renal — essa é uma ferramenta de acesso a dados específicos do paciente, classificada como busca de dados individuais no framework do function calling. A segunda é uma ferramenta de acesso ao sistema de prescrições, pela qual o agente verifica os diuréticos prescritos na dose atual e o histórico de doses anteriores nessa internação — outra ferramenta de dados do paciente. A terceira é uma ferramenta de acesso ao módulo de registros de enfermagem, de onde o agente extrai os registros de balanço hídrico e os sinais clínicos documentados, como pressão venosa jugular — dados do paciente de origem semiestruturada. A quarta é uma ferramenta de acesso ao repositório de diretrizes da Sociedade Brasileira de Cardiologia sobre manejo da insuficiência cardíaca aguda — essa é uma ferramenta de conhecimento generalista, não de dados do paciente. A quinta é implicitamente uma ferramenta de cálculo, que o agente usa para computar a taxa de resposta diurética como a relação entre a diurese das últimas seis horas e a dose total de furosemida administrada no período.
A distinção entre as ferramentas de dados do paciente e a ferramenta de conhecimento generalista é o eixo central do conceito de function calling no material. As primeiras fornecem o contexto específico e individual; a última, que é tecnicamente uma implementação de RAG, fornece o conhecimento médico estruturado necessário para interpretar o contexto individual.
Aplicação do RAG e suas vantagens e riscos:
A consulta ao repositório de diretrizes é o componente de RAG do agente. A superioridade do RAG em relação ao conhecimento de treinamento do LLM é especialmente evidente neste contexto por três razões que o material deixa explícitas. Primeiro, as diretrizes da SBC são atualizadas periodicamente, e o treinamento de um LLM tem uma data de corte — o modelo pode ter sido treinado com uma versão anterior das diretrizes. Segundo, as diretrizes da SBC são específicas do contexto brasileiro, enquanto o treinamento de modelos de linguagem grandes é dominado por textos em inglês e por padrões de prática norte-americanos ou europeus. Terceiro, o hospital pode ter adaptações locais dos protocolos que jamais fariam parte de qualquer conjunto de treinamento público. O RAG permite que o agente fundamente sua recomendação na versão mais recente e mais contextualizada das diretrizes disponíveis.
Os riscos do RAG, que a resolução deve apontar, são dois principais. Se a base de diretrizes não for mantida atualizada, o agente pode retriever uma versão desatualizada com falsa segurança de que está usando a informação mais recente. E se o sistema de recuperação recuperar um trecho errado ou fora do contexto correto da consulta, o agente pode gerar uma recomendação baseada em uma seção da diretriz que não se aplica ao caso em questão.
Resposta à preocupação sobre dados incompletos:
A preocupação do cardiologista é tecnicamente fundamentada e o material a aborda diretamente ao discutir agentes que operam em ambientes com observabilidade parcial. O conceito de ambiente parcialmente observável implica que o agente nunca tem acesso perfeito a todos os dados relevantes para uma decisão. No contexto deste agente, dados incompletos podem ocorrer de múltiplas formas: um exame de creatinina que ainda não foi coletado, um registro de balanço hídrico que a enfermagem ainda não inseriu no prontuário eletrônico, ou um parâmetro como a pressão venosa jugular que o médico avaliou clinicamente mas não documentou formalmente.
O material estabelece que um agente bem projetado deve degradar de forma segura diante de dados ausentes — o que significa que, em vez de gerar uma recomendação aparentemente completa com base em dados incompletos, o agente deveria explicitamente comunicar ao cardiologista quais dados estão ausentes e que, por isso, a recomendação gerada tem um nível de confiança reduzido ou não pode ser gerada. A alternativa — gerar uma recomendação silenciando a incompletude dos dados — é arquiteturalmente perigosa porque o médico não tem como saber que o agente estava operando com informações parciais.
Avaliação da preocupação sobre o uso das diretrizes:
A preocupação do cardiologista é válida e aponta para uma limitação arquitetural real. As diretrizes clínicas são recomendações baseadas em populações estudadas em contextos específicos; elas não foram escritas para pacientes individuais com combinações únicas de comorbidades, preferências e contexto clínico. O agente como descrito consulta as diretrizes via RAG e as aplica ao contexto do paciente por meio de seu componente de raciocínio — mas a qualidade dessa aplicação depende do quanto o LLM consegue identificar quando o paciente individual diverge das premissas das diretrizes.
O risco mais concreto é o de um paciente cuja situação específica contraindica a recomendação padrão das diretrizes mas cuja contraindição não está registrada de forma estruturada no prontuário eletrônico — por exemplo, uma fragilidade severa documentada apenas em texto livre que o agente não processa adequadamente. O material aponta que essa é uma limitação inerente de qualquer sistema baseado em RAG e que ela justifica a manutenção de supervisão médica ativa sobre as recomendações geradas.
Dicas de resolução para o professor
O ponto mais comumente subestimado pelos estudantes é a distinção entre ferramentas de dados do paciente e ferramentas de conhecimento generalista. Muitos tratam todas as consultas como equivalentes, sem perceber que essa distinção é arquiteturalmente central — ela determina o tipo de dado que o agente recupera, o tipo de erro que pode cometer se uma ferramenta falhar e a forma como os dados recuperados são integrados no raciocínio. O professor pode estimular a reflexão com a seguinte questão: “o que acontece se a ferramenta de diretrizes retornar um erro e a ferramenta de dados do paciente retornar normalmente, e vice-versa? Os dois cenários têm o mesmo risco?”
A questão do RAG frequentemente gera respostas que apenas repetem que “o RAG usa dados atualizados”. A resolução de alto nível exige que o estudante articule por que a atualização é especialmente relevante neste caso específico (diretrizes cardiológicas têm ciclos de revisão, o contexto brasileiro é subrepresentado nos corpora de treinamento) e quais são os riscos concretos da abordagem.
Como explicar a resolução aos estudantes
O recurso pedagógico mais eficaz para essa atividade é o role-playing: peça que um estudante faça o papel do cardiologista e outro faça o papel do desenvolvedor do agente. O “cardiologista” faz perguntas sobre o funcionamento do sistema (“o que acontece se o resultado do potássio ainda não tiver saído?”, “como o sistema sabe qual versão das diretrizes está usando?”), e o “desenvolvedor” precisa responder com base nos conceitos do material. Essa dinâmica expõe rapidamente as lacunas de compreensão e força a aplicação dos conceitos ao caso concreto de forma muito mais eficaz do que uma revisão expositiva.
Para a questão das diretrizes vs contexto individual, o professor pode apresentar um caso hipotético simples: um paciente de 82 anos, frágil, com insuficiência cardíaca e creatinina de 2,1 mg/dL, para quem a diretriz recomenda aumento da dose de furosemida por ausência de resposta diurética. O que o agente recomendaria? O que um cardiologista experiente consideraria antes de seguir essa recomendação? Essa discussão torna concreta a tensão entre evidência populacional e julgamento clínico individualizado.
Resolução da Atividade 3 — Responsabilidade, autonomia e consequências: um caso para análise ética e jurídica
Resolução esperada
Esta atividade exige análise integrada em quatro dimensões. A resolução de alto desempenho não trata cada dimensão de forma isolada, mas constrói um argumento coeso que conecta a falha arquitetural ao padrão de uso, ao evento adverso e à distribuição de responsabilidades.
Primeira dimensão — Análise arquitetural:
A limitação estrutural que contribuiu diretamente para o evento adverso foi o escopo de percepção do agente: suas ferramentas de acesso ao prontuário cobriam apenas um módulo do sistema hospitalar e não tinham acesso ao módulo de prescrições intersetoriais. O material apresenta o conceito de percepção como o primeiro componente da arquitetura de um agente: é por meio dos sensores que o agente conhece o estado do mundo. No caso descrito, os sensores do agente eram funcionalmente cegos à prescrição de azitromicina porque ela estava em um módulo fora de seu escopo de integração.
O ponto que diferencia uma resposta satisfatória de uma resposta excelente é a compreensão de que isso não é simplesmente um bug corrigível com uma atualização de software. Trata-se de uma decisão arquitetural sobre quais sistemas o agente seria integrado — uma decisão que estava documentada implicitamente na especificação do produto. Em outras palavras, o agente funcionou exatamente como foi projetado para funcionar; o problema é que o projeto não contemplava o ambiente real de uso, onde prescrições relevantes poderiam vir de outros módulos.
O conceito de ambiente parcialmente observável formaliza esse problema. Um agente que opera em observabilidade parcial nunca tem acesso completo ao estado real do mundo. No contexto hospitalar, isso é quase inevitável — prontuários distribuídos por múltiplos sistemas, registros em papel, informações que o paciente forneceu verbalmente mas não foram documentadas. O agente bem projetado não age como se tivesse acesso completo às informações: ele aplica estratégias de gestão de incerteza, que incluem explicitamente sinalizar quando dados que deveriam estar disponíveis não estão, e reduzir sua confiança (ou se recusar a gerar uma recomendação) quando a completude dos dados não pode ser verificada. O agente descrito no caso não fez isso: gerou uma recomendação com aparência de completude a partir de dados que eram estruturalmente incompletos.
Segunda dimensão — Espectro de autonomia:
O material apresenta um espectro de autonomia que vai de sistemas puramente sugestivos, com revisão humana obrigatória em cada etapa, até sistemas completamente autônomos, que agem sem nenhuma intervenção humana. Como foi projetado, o agente do caso estava posicionado no nível de autonomia mais baixo do espectro: sua função era sugerir, e o protocolo exigia revisão médica obrigatória antes de qualquer alteração. Na prática, após três meses de uso, o agente operava em um nível de autonomia muito mais alto: suas recomendações eram aceitas sistematicamente sem revisão crítica, particularmente nos períodos noturnos.
Essa discrepância entre o nível de autonomia projetado e o nível de autonomia operacional é um fenômeno que o material identifica como um dos maiores riscos de implantação de agentes clínicos. Ele tende a ocorrer quando o sistema demonstra desempenho adequado ao longo do tempo e a equipe médica desenvolve um viés de automação — uma confiança excessiva no sistema que leva à redução da supervisão crítica. No caso descrito, a sobrecarga da equipe noturna com um plantonista para trinta e dois leitos foi o amplificador desse viés.
O perfil de risco das decisões apoiadas pelo agente — manejo de anticoagulação com varfarina, um fármaco de índice terapêutico estreito, com interações farmacológicas numerosas e potencialmente fatais — exigia, segundo os princípios do material, supervisão humana ativa e revisão crítica em cada recomendação. A combinação de alto risco clínico e nível de autonomia operacional elevado constituía uma configuração de risco que o protocolo de implantação não preveniu adequadamente.
Terceira dimensão — Responsabilidade jurídica e ética:
O material é explícito ao afirmar que a adoção de agentes de IA em saúde não elimina a responsabilidade médica — e pode amplificá-la, se o médico seguir uma recomendação sem o julgamento crítico que a situação exigia. No caso, a responsabilidade distribui-se em três direções distintas.
A responsabilidade do médico plantonista decorre de ter aceitado a recomendação sem revisar o prontuário completo, contrariando o protocolo de implantação que ele conhecia. O material aponta que, quando o médico usa um agente de IA como suporte à decisão e age sobre a recomendação sem revisão crítica, ele assume implicitamente a responsabilidade pelo julgamento final — incluindo a responsabilidade de verificar se as premissas sobre as quais o agente baseou sua recomendação eram corretas. A supervisão humana não é apenas uma salvaguarda ética; ela é a condição que preserva a integridade do processo decisório médico diante de um sistema que o material classifica como intrinsecamente limitado pela observabilidade parcial.
A responsabilidade do hospital é institucional e dupla. Primeiro, o hospital permitiu que a prática de aceitação acrítica se estabelecesse sem intervenção — o que configura falha de gestão do processo de implantação. Segundo, a configuração de um único plantonista para trinta e dois leitos em período noturno pode ter criado condições estruturais incompatíveis com a supervisão adequada que o protocolo exigia, o que transfere parte da responsabilidade do ato individual do médico para a decisão organizacional que gerou essa sobrecarga.
A responsabilidade da empresa desenvolvedora está na limitação arquitetural não declarada. O produto foi vendido com a promessa de verificar o perfil medicamentoso dos pacientes, mas com um escopo de acesso que estruturalmente excluía prescrições intersetoriais. O material discute que agentes clínicos têm o dever de declarar explicitamente o que não conseguem verificar, de modo que o médico saiba quando a recomendação está sendo gerada com informação incompleta. A ausência desse mecanismo de declaração de incerteza é uma falha de produto que o desenvolvedor deve responder.
Quarta dimensão — Prevenção:
A mudança arquitetural mais direta seria expandir o escopo de integração do agente para cobrir todos os módulos de prescrição do sistema hospitalar, incluindo as prescrições intersetoriais. Se isso não for tecnicamente viável de imediato, a alternativa arquitetural é implementar um mecanismo de detecção de incompletude: o agente deveria verificar se tem acesso a todos os módulos de prescrição antes de gerar uma recomendação e, caso não tenha, emitir explicitamente uma notificação de “dados de medicamentos possivelmente incompletos — revisão manual obrigatória do prontuário completo” como parte integrante da recomendação. A recomendação jamais deveria parecer mais completa do que os dados que a fundamentam.
A mudança de processo de implantação mais importante seria a instituição de um mecanismo de confirmação ativa: a interface do sistema não deveria permitir que o médico marcasse uma recomendação como “aceita” sem primeiro confirmar explicitamente ter revisado o prontuário completo, incluindo módulos fora do escopo padrão do agente. Esse mecanismo de fricção intencional — tornar a aceitação acrítica ligeiramente mais trabalhosa do que a revisão crítica — é uma estratégia de design de interação reconhecida no contexto de Human-in-the-Loop para reduzir o viés de automação.
A mudança de protocolo clínico seria a criação de uma lista de verificação específica para aceitação de recomendações do agente para fármacos de alto risco, especialmente anticoagulantes, que incluísse obrigatoriamente a revisão de prescrições de todos os módulos do sistema hospitalar e a verificação de antibióticos e antifúngicos de início recente com potencial interação com anticoagulantes. Essa lista seria parte do protocolo de anticoagulação do hospital, não apenas do protocolo do agente.
Dicas de resolução para o professor
Esta atividade é a mais complexa do conjunto e os erros de alto nível são diferentes dos erros de nível básico. Os estudantes mais avançados tendem a produzir análises que são tecnicamente corretas mas eticamente superficiais — identificam a falha arquitetural com precisão mas atribuem toda a responsabilidade ao médico, sem perceber a responsabilidade institucional e a do desenvolvedor. O professor deve provocar com a pergunta: “se o médico tivesse seguido o protocolo à risca, o evento teria sido evitado? E se o hospital não tivesse designado apenas um plantonista para trinta e dois leitos?”
Outro erro comum é propor como “mudança arquitetural” algo que é, na verdade, uma mudança de processo — como “exigir que o médico revise o prontuário completo”. Essa é uma mudança de protocolo clínico, não arquitetural. A mudança arquitetural é o que o sistema faz de forma diferente, não o que o médico faz de forma diferente. O professor pode ajudar a distinguir os dois tipos de intervenção perguntando: “quem executa essa mudança — o sistema ou o médico?”
O ponto sobre observabilidade parcial frequentemente é tratado de forma abstrata pelos estudantes sem conexão com o caso concreto. O professor pode materializar o conceito com a pergunta: “quais outras informações clinicamente relevantes sobre esse paciente provavelmente também estavam fora do alcance do agente?” Isso revela que a prescrição de azitromicina é apenas um exemplo de uma classe de dados estruturalmente inacessíveis, o que torna o problema mais sistemático do que uma falha pontual.
Como explicar a resolução aos estudantes
A estratégia mais eficaz para apresentar a resolução desta atividade é conduzir uma simulação de reunião de comitê de segurança hospitalar pós-evento. O professor pode dividir a turma em grupos representando o médico plantonista, a direção do hospital, o time jurídico, a empresa desenvolvedora e uma organização de defesa dos pacientes. Cada grupo deve defender sua perspectiva sobre o que ocorreu e o que deveria mudar. Esse exercício torna as tensões de responsabilidade visíveis e permite que a resolução emerja da discussão em vez de ser apresentada de forma expositiva.
Para conectar o caso ao tema do módulo de forma mais ampla, o professor pode fechar a discussão com a pergunta: “esse evento teria sido possível se o sistema fosse um modelo passivo em vez de um agente?” Isso força o estudante a articular por que a autonomia do agente — o traço que o torna útil — é também o traço que amplificou as consequências da falha de percepção.