Tópico 8.4 — Governança de IA e de tecnologias emergentes

Em uma frase: A inteligência artificial na saúde e nos cuidados é uma tecnologia que aprende, depende de dados e é muitas vezes opaca, capaz de escalar tanto o benefício quanto o dano mais depressa do que qualquer sistema que vocês já governaram; vocês devem, portanto, governá-la como uma questão de segurança clínica, de equidade e de confiança pública ao longo de todo o seu ciclo de vida — e não tratá-la como um software comum que se compra uma vez e se esquece.

Por que isso importa na saúde e nos cuidados#

A maior parte do software que vocês implantaram se comporta amanhã como se comporta hoje: sua lógica está escrita, seu comportamento é testável e, quando erra, tende a errar de forma visível e repetível. A inteligência artificial quebra esses três confortos. Ela aprende padrões estatísticos a partir de dados em vez de seguir regras que uma pessoa escreveu; seu comportamento depende inteiramente dos dados com que foi treinada e dos dados que agora encontra; e seu raciocínio é frequentemente opaco até para quem a construiu. Essa combinação é a razão pela qual a IA precisa de sua própria disciplina de governança, em vez de ser dobrada numa lista de verificação genérica de software.

Na saúde e nos cuidados, as consequências não são abstratas. Um modelo que subdetecta doenças num grupo sub-representado em seus dados de treinamento não comete um erro isolado — comete o mesmo erro, em silêncio, milhares de vezes, entrincheirando e escalando as desigualdades em saúde. Um modelo generativo que fabrica um detalhe clínico de som plausível pode induzir em erro um clínico sobrecarregado exatamente no pior momento. Uma ferramenta que funciona de forma esplêndida na população em que foi validada pode decair em silêncio quando a população, a via de cuidado ou os dados a montante mudam. A IA pode escalar boas decisões e pode escalar o viés, o erro e o dano com igual eficiência.

Este tópico trata de governar esse risco sem engolir o exagero nem banir a tecnologia. Deliberadamente não repete os alicerces lançados em outros lugares: a segurança clínica (ver Tópico 1.6 — Segurança clínica e gestão de riscos), a governança da informação, a proteção de dados e a cibersegurança (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança) e a tomada de decisão baseada em evidências (ver Tópico 1.3 — Decisões baseadas em evidências). Ancora-se neles e acrescenta o que é específico dos sistemas que aprendem. Tratem-no como a extensão em forma de IA da sua garantia existente e como o irmão governado da implantação faseada da inovação (ver Tópico 8.0 — Implantação faseada da inovação).

Conceitos centrais#

Inteligência artificial e aprendizado de máquina. Para um líder, a distinção prática é esta: a maior parte da IA na saúde e nos cuidados hoje é aprendizado de máquina — sistemas que inferem padrões a partir de exemplos em vez de executar regras escritas à mão. É por isso que os dados são o produto tanto quanto o código: mudem os dados de treinamento e vocês mudam o comportamento. Significa também que um modelo não "sabe" nada; estima, e pode estar confiantemente errado. Entender isso em nível conceitual basta para fazer as perguntas certas de governança; vocês não precisam ler a matemática.

Software como Dispositivo Médico (SaMD) e a MHRA. Quando um software tem um propósito médico — diagnosticar, rastrear, triar, calcular uma dose, prever uma deterioração —, ele é muito frequentemente um dispositivo médico perante a lei, esteja rodando num celular ou num servidor. O software médico desse tipo, conhecido como Software como Dispositivo Médico (SaMD), é regulado no Reino Unido pela Medicines and Healthcare products Regulatory Agency (MHRA). Se vocês estão comissionando ou construindo uma ferramenta de IA com propósito clínico, a primeira pergunta de governança é se ela é um dispositivo regulado e, em caso afirmativo, se detém uma marcação válida de conformidade. Errar nisso não é tecnicalidade; implantar um dispositivo médico não registrado é ilícito e inseguro.

O AI Airlock. A MHRA estabeleceu um ambiente regulatório de testes (sandbox) chamado AI Airlock para trabalhar como a IA como dispositivo médico deve ser regulada num ambiente controlado e monitorado. Um sandbox regulatório permite que um regulador e um pequeno número de desenvolvedores examinem questões difíceis e novas — por exemplo, como validar um modelo que se atualiza ao longo do tempo — sob supervisão, antes de se fixarem regras gerais. Sejam sóbrios sobre o que isso é: o Airlock é um ambiente de aprendizado para o regulador e um punhado de participantes, e não uma rota de aprovação rápida, e estar associado a ele não significa que um produto esteja aprovado para uso clínico geral.

Viés algorítmico e justiça. O viés algorítmico é a tendência de um sistema a produzir resultados sistematicamente injustos para determinados grupos. Na saúde e nos cuidados, sua fonte mais comum são os dados de treinamento: se um grupo é sub-representado, mal rotulado ou medido com um instrumento enviesado, o modelo aprende a servir pior esse grupo. Como o modelo então aplica isso em escala e com ar de objetividade, uma IA enviesada pode ampliar as próprias desigualdades que a sua organização é estatutariamente obrigada a reduzir.

Explicabilidade e a caixa-preta. A inteligência artificial explicável trata de saber se um humano consegue entender por que um modelo produziu uma dada saída. Muitos modelos de alto desempenho são, na prática, "caixas-pretas": precisos no agregado, mas incapazes de dar a um clínico uma razão confiável para uma decisão individual. Num ambiente clínico isso importa para a responsabilização, o consentimento informado e o dever do clínico de exercer o julgamento — um médico não consegue assumir de forma significativa a responsabilidade por um conselho que não pode interrogar.

Deriva do modelo e vigilância pós-comercialização. A acurácia de um modelo não é fixa. A deriva de conceito (concept drift) — uma mudança ao longo do tempo na relação entre as entradas e aquilo que se prevê — significa que um modelo validado no ano passado pode se degradar em silêncio neste ano à medida que populações, vias ou dados a montante mudam. É por isso que a IA exige vigilância pós-comercialização e monitoramento contínuos, e não apenas uma validação pontual na entrada em produção.

MLOps e o ciclo de vida do modelo. O MLOps é a disciplina operacional de implantar, monitorar, versionar e retreinar modelos de forma confiável em produção. É a maquinaria que torna real a governança do ciclo de vida: saber qual versão do modelo está no ar, sobre quais dados, com que desempenho, e poder reverter.

Humano no circuito (human-in-the-loop). Um projeto de humano no circuito mantém uma pessoa — normalmente um clínico — de forma significativa na decisão, com a autoridade e a informação para sobrepor-se ao modelo. Bem feito, preserva a responsabilização; feito como carimbo, oferece apenas a ilusão de supervisão.

IA generativa e grandes modelos de linguagem. A inteligência artificial generativa, incluindo os grandes modelos de linguagem (LLMs), produz texto fluente e outros conteúdos. Seu valor realista de curto prazo na saúde e nos cuidados é em grande parte administrativo — redigir documentação, resumir, aliviar a papelada. Seu risco definidor é a alucinação: a geração confiante de conteúdo falso, mas plausível, agravada por riscos de confidencialidade quando dados de pacientes são inseridos em serviços de terceiros.

Terapêuticas digitais e aplicativos de saúde. As terapêuticas digitais (DTx) são intervenções baseadas em software e em evidências que previnem, gerem ou tratam uma condição — distintas dos aplicativos gerais de bem-estar precisamente porque fazem uma alegação clínica, o que significa que muitas são Software como Dispositivo Médico e exigem a mesma evidência e garantia que qualquer outra intervenção que vocês prescrevam ou recomendem.

Boas práticas#

1. Classifiquem a ferramenta antes de fazer qualquer outra coisa. Estabeleçam, por escrito e com contribuição clínica e regulatória, se a IA tem propósito médico e é, portanto, um dispositivo médico regulado, e se detém uma marcação válida de conformidade da MHRA. Essa determinação isolada governa tudo o que vem depois — a rota de garantia, as responsabilidades, a licitude da implantação. Na dúvida, busquem aconselhamento regulatório em vez de supor que uma ferramenta administrativa está fora do escopo.

2. Passem a IA pela maquinaria existente de segurança clínica e governança da informação, estendida e não contornada. Toda implantação de IA clínica precisa da gestão de risco clínico da DCB0129/DCB0160 (ver Tópico 1.6) e de uma Avaliação de Impacto sobre a Proteção de Dados (DPIA) sob o seu arcabouço de governança da informação (ver Tópico 1.7). Não deixem a novidade ou o entusiasmo do fornecedor criar um processo paralelo e mais leve. Os perigos específicos da IA — viés, deriva, opacidade, viés de automação — devem ser acrescentados ao registro de perigos, e não substituí-lo.

3. Interroguem os dados de treinamento quanto à representatividade e ao viés. Perguntem quem está nos dados e quem falta, como os desfechos foram rotulados e se os próprios instrumentos de medição eram enviesados entre grupos. Exijam que o fornecedor relate o desempenho desdobrado por subgrupos relevantes — idade, sexo, etnia, privação — e não apenas a acurácia principal. Uma ferramenta que não consegue demonstrar desempenho equitativo é um risco de desigualdade em saúde, por mais impressionante que seja sua média.

4. Exijam validação clínica apropriada ao risco e prefiram evidência prospectiva. A acurácia retrospectiva em dados curados é a forma mais fraca de evidência. Para qualquer coisa que influencie decisões clínicas, busquem validação numa população e num fluxo de trabalho como os de vocês, idealmente prospectiva, e encaminhem a alegação pelo arcabouço de garantia apropriado — o NICE Evidence Standards Framework para tecnologias de saúde digital e os Digital Technology Assessment Criteria (DTAC) como garantia de linha de base. Combinem a força da evidência com a magnitude do dano potencial.

5. Insistam num humano no circuito significativo e numa responsabilização clara. Definam quem responde por uma decisão que a IA informou e garantam que o humano tenha tanto a autoridade para se sobrepor quanto a informação para fazê-lo. Resguardem-se ativamente do viés de automação — a tendência a ceder à máquina — por meio de treinamento, projeto de interface e auditoria das taxas de sobreposição. Se as sobreposições nunca acontecem, o seu "humano no circuito" é decorativo.

6. Tratem a entrada em produção como o começo do monitoramento, e não o fim da garantia. Montem a vigilância pós-comercialização desde o primeiro dia: monitorem o desempenho no mundo real, observem a deriva de conceito e definam os limiares e o processo para retreinar, pausar ou retirar o modelo. Estabeleçam o versionamento e a reversão do modelo por meio de MLOps sólido para sempre saber o que está no ar e poder reverter com segurança. Um modelo que nunca é reverificado é um controle de segurança que falha lentamente.

7. Governem a IA generativa em função de seus usos realistas e de seus riscos reais. Permitam os LLMs onde o valor é genuíno e o risco é contido — redação administrativa, resumos, apoio à documentação com revisão humana — e proíbam a inserção não gerida de dados identificáveis de pacientes em serviços de terceiros. Presumam que toda saída generativa pode ser fabricada até que um humano a verifique e jamais deixem conteúdo gerado e não verificado entrar no prontuário clínico. Uma política clara e imposta vence tanto uma proibição geral, que empurra para o uso paralelo, quanto uma liberdade total, que vaza dados.

8. Apliquem a governança da informação a todo o ciclo de vida dos dados, incluindo o treinamento. Os dados usados para treinar, ajustar e avaliar um modelo estão sujeitos às mesmas obrigações de base legal, minimização e transparência que qualquer outro uso (ver Tópico 1.7). Sejam explícitos sobre a base para treinar com dados de pacientes, se estão adequadamente desidentificados e o que o fornecedor pode fazer com eles. Os contratos devem proibir a reutilização dos seus dados para treinar produtos para terceiros sem base legal e sem o seu acordo.

9. Mantenham um registro de modelos legível por humanos e exijam transparência dos fornecedores. Mantenham um inventário da IA em uso: propósito, situação regulatória, proveniência dos dados de treinamento, evidência de validação, plano de monitoramento e responsável. Exijam que os fornecedores sejam transparentes sobre como um modelo funciona, suas limitações e seus modos de falha; a opacidade de um fornecedor é, em si, um sinal de risco. Não se governa o que não se escreveu.

10. Façam a varredura de horizonte deliberadamente e faseiem por avaliação controlada. Além da IA de hoje, observem as tecnologias emergentes — documentação ambiente, modelos de fundação e, mais adiante, a quântica e a sensoriamento novo — com varredura de horizonte estruturada em vez de compras reativas. Introduzam qualquer coisa genuinamente nova pela abordagem controlada, reversível e avaliada da implantação faseada da inovação (ver Tópico 8.0), começando pequeno, medindo com honestidade e mantendo a capacidade de parar.

11. Tratem as terapêuticas digitais e os aplicativos de saúde como intervenções, e não como downloads de consumo. Quando um aplicativo faz uma alegação clínica — tratar, gerir ou prevenir uma condição —, é uma intervenção sobre a qual os pacientes agirão, e merece o mesmo escrutínio de um medicamento ou dispositivo antes que vocês o prescrevam ou recomendem. Estabeleçam se é Software como Dispositivo Médico com marcação válida de conformidade, exijam evidência proporcional à alegação e concluam uma avaliação de segurança clínica (ver Tópico 1.6) em vez de confiar numa nota de loja de aplicativos ou no entusiasmo de um fornecedor. Um aplicativo sem garantia que um clínico endossa carrega o nome da sua organização e a sua responsabilização se causar dano.

12. Encaminhem os aplicativos de saúde pela garantia existente e mantenham uma biblioteca curada e segura. Avaliem as terapêuticas digitais pela mesma maquinaria que vocês já operam — o DTAC como linha de base, o NICE Evidence Standards Framework combinado com a alegação clínica e a revisão de segurança clínica e de governança da informação — e construam ao longo do tempo a evidência de avaliação em mundo real (ver Tópico 8.6). Mantenham uma biblioteca curada de aplicativos que vocês avaliaram e apoiam, com a situação regulatória, a evidência e o responsável de cada um registrados, para que os clínicos recomendem a partir de uma lista curta segura e governada. A alternativa — uma proliferação descontrolada de aplicativos não avaliados, recomendados informalmente entre equipes — é ingerenciável e insegura.

Perguntas para discutir com a sua equipe#

1. Para cada ferramenta de IA que estamos considerando ou já usando, sabemos de fato se é um dispositivo médico regulado — e conseguimos produzir a evidência? Isto soa como formalidade de conformidade, mas é a pergunta de sustentação, porque a resposta determina o que é lícito, quem é responsável e que garantia devemos ao público. É fácil supor que uma ferramenta que "apenas ajuda na triagem" ou "apenas resume anotações" é um software administrativo inofensivo quando seu propósito médico, na verdade, a torna um dispositivo regulado que exige marcação de conformidade da MHRA. A discussão deve forçar vocês a nomear cada ferramenta de IA em uso ou no pipeline, declarar seu propósito pretendido em termos clínicos simples e identificar quem tomou a decisão de classificação do dispositivo e com que base. Deve trazer à tona os casos incômodos em que uma ferramenta foi adquirida por uma via comum de TI sem qualquer verificação regulatória. Sejam honestos sobre se vocês conseguiriam, hoje, produzir a documentação de conformidade e a evidência de validação se um regulador ou um legista pedisse. O valor da conversa é converter uma vaga sensação de que "alguém deve ter verificado" numa posição documentada e com dono — e revelar as ferramentas em que ninguém o fez.

2. Exigimos ver como este modelo se comporta para os grupos com maior probabilidade de serem prejudicados, ou aceitamos um número de acurácia principal? A acurácia média é o número com que os fornecedores abrem e o número que esconde o viés algorítmico, porque um modelo pode ser altamente acurado no geral e ter desempenho marcadamente pior para um grupo sub-representado. Na saúde e nos cuidados isso não é uma curiosidade estatística; é um mecanismo para ampliar as desigualdades que vocês têm obrigação legal e moral de reduzir, aplicado em silêncio e em escala. A equipe deve discutir que evidência de subgrupo vocês de fato viram — desempenho desdobrado por idade, sexo, etnia e privação — e se sabem quem estava nos dados de treinamento e quem faltava. Vale nomear o desconforto aqui: pressionar um fornecedor sobre justiça pode parecer obstruir uma inovação empolgante, e a pergunta honesta é se vocês estão dispostos a dizer não a uma ferramenta que não consegue demonstrar desempenho equitativo. Considerem também como vocês sequer detectariam resultados inequitativos após a implantação, já que o viés invisível na aquisição será invisível na produção, a menos que se monitore por ele. Uma boa discussão termina com um padrão evidencial concreto de justiça, aplicável antes de qualquer IA clínica entrar no ar, e um plano para continuar observando depois.

3. Quando este modelo errar — e errará — quem responde, um humano de fato pegará o erro e como sequer saberemos? Todo modelo falha às vezes, e os sistemas que aprendem podem derivar para falhar com mais frequência ao longo do tempo; a pergunta madura não é se os erros ocorrem, mas se as suas salvaguardas são reais. A equipe deve testar se o humano no circuito é significativo ou decorativo: o clínico tem a autoridade e a informação para se sobrepor e, se vocês olhassem as taxas de sobreposição, descobririam que alguma vez de fato se sobrepõem, ou o viés de automação se instalou? Discutam quem é nomeado responsável por uma decisão que a IA informou — o clínico, a organização, o fornecedor —, porque "o algoritmo fez" não é uma posição defensável perante um paciente ou um legista. Enfrentem o seu monitoramento com honestidade: vocês têm vigilância pós-comercialização que detectaria a deriva de conceito, limiares definidos para pausar ou retirar o modelo e a maquinaria de MLOps para saber qual versão está no ar e revertê-la? Para ferramentas generativas, acrescentem a pergunta da alucinação — o que impede que conteúdo fabricado entre no prontuário clínico e quem verifica a saída antes de ela ser confiável? A versão mais útil desta conversa expõe a lacuna entre o tranquilizador diagrama de "supervisão humana" e o que de fato aconteceria às 3 da manhã numa enfermaria movimentada.

4. O que acontece com os dados dos nossos pacientes quando treinamos, ajustamos e executamos estes modelos — e o que o fornecedor se reservou o direito de fazer com eles? A IA concentra o risco de governança de dados precisamente porque os dados são o produto: um modelo é tão confiável quanto a base legal, a minimização e a transparência por trás de cada conjunto de dados em que tocou, incluindo os dados de treinamento e de avaliação anteriores à entrada em produção. A equipe deve ser capaz de declarar, para cada ferramenta, a base legal de qualquer uso de dados de pacientes, se a desidentificação é adequada e não meramente afirmada e para onde os dados fisicamente fluem uma vez que saem do seu controle. Uma armadilha recorrente é o contrato que permite em silêncio ao fornecedor reutilizar os seus dados para melhorar produtos que venderá a outros; discutam se os seus acordos proíbem isso sem base legal e sem o seu consentimento explícito e se alguém de fato leu essas cláusulas. Isso se liga diretamente ao seu arcabouço de governança da informação (ver Tópico 1.7) e é onde o entusiasmo por uma ferramenta capaz mais frequentemente ultrapassa a devida diligência. Uma resposta honesta nomeia quem é dono da DPIA, o que o fornecedor pode e não pode fazer e onde vocês estão hoje expostos — em vez de supor que, porque a demonstração foi impressionante, a papelada deve estar sólida.

5. Como decidimos o que NÃO adotar, e conseguimos resistir à pressão de comprar a coisa por que todos estão empolgados? A disciplina de governança mais difícil com uma tecnologia que avança depressa é dizer "ainda não" ou "isto não", e uma equipe que não consegue articular seus critérios para recusar acabará adotando pela deriva e pelo exagero e não pela evidência. Discutam o que os faria abandonar uma ferramenta de resto atraente — evidência fraca de subgrupo, situação regulatória pouco clara, um caso de uso em que o benefício realista é magro frente ao risco — e se essas linhas vermelhas estão escritas ou meramente sentidas. Há uma tensão real aqui entre o custo de perder uma melhoria genuína e o custo de uma falha em escala que danifica a confiança pública, e pessoas razoáveis os pesarão de modo diferente. Vale nomear a realidade política de que a pressão para adotar muitas vezes vem de um conselho, de uma relação com fornecedor ou de um mandato nacional, e não da necessidade clínica em si. A posição do tópico é fazer a varredura de horizonte deliberadamente e faseiar por avaliação controlada e reversível (ver Tópico 8.0); assim, uma resposta honesta descreve como uma ferramenta promissora, mas não comprovada, entra como um piloto pequeno, medido e interrompível e não como uma implantação em atacado — e quem detém a autoridade para interrompê-lo.

6. Conseguimos explicar o que este modelo faz aos clínicos que precisam confiar nele e aos pacientes afetados por ele — e fomos honestos sobre seus limites? Um modelo que um clínico não consegue interrogar e um paciente não consegue entender corrói o julgamento informado e o consentimento informado de que o cuidado clínico depende, por mais acurado que seja no agregado. A equipe deve discutir quanta explicabilidade este uso em particular de fato exige: um auxílio de priorização de fila exige menos do que uma ferramenta que influencia um diagnóstico ou uma decisão de tratamento, e adequar a explicação ao que está em jogo é uma escolha de governança, e não uma reflexão técnica tardia. Considerem o que vocês dizem aos clínicos que devem usá-lo — seu propósito, seus modos de falha conhecidos, os grupos para os quais é menos confiável — e se essa orientação é franca ou um resumo de marketing. A honestidade voltada ao paciente também importa: as pessoas são informadas quando a IA está envolvida no cuidado delas, e em linguagem sobre a qual possam agir? Esta é também uma questão de força de trabalho, porque uma confiança baixa demais significa que uma ferramenta útil é ignorada, enquanto uma confiança alta demais produz o viés de automação que esvazia a supervisão. Uma resposta honesta enfrenta se o seu treinamento e a sua comunicação estão construindo uma confiança calibrada ou meramente vendendo a ferramenta.

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados recebe a oferta de uma ferramenta de IA que lê radiografias de tórax e sinaliza prováveis anormalidades para priorizar a fila de laudos de radiologia. O responsável pela segurança clínica e o diretor médico resistem à pressão para adquiri-la depressa e, em vez disso, a submetem a uma governança adequada.

Primeiro, a classificação: a ferramenta tem um propósito médico claro e é, portanto, confirmada como Software como Dispositivo Médico, e sua marcação de conformidade da MHRA e a declaração de uso pretendido são verificadas — o uso pretendido é apoio à triagem, e não diagnóstico autônomo, o que molda tudo o que se segue. Em seguida, a garantia: a ferramenta passa pelo DTAC como linha de base, suas alegações clínicas são conferidas com o NICE Evidence Standards Framework, uma avaliação de risco clínico DCB0160 é concluída e uma DPIA cobre os dados de imagem (ver Tópicos 1.6 e 1.7). A equipe pede o desempenho por subgrupo e descobre que a população de validação sub-representava um grupo demográfico local; exige validação local adicional antes de prosseguir, tratando o potencial viés como risco de desigualdade em saúde e não como nota de rodapé.

Na implantação, o projeto mantém um humano no circuito: toda imagem ainda é laudada por um radiologista, e a IA apenas reordena a fila, de modo que uma sinalização perdida não pode, por si só, causar um diagnóstico perdido. A vigilância pós-comercialização é montada desde o primeiro dia — monitorando as taxas de detecção, a discordância entre o modelo e os radiologistas que laudam e qualquer deriva à medida que o hardware dos aparelhos e o perfil dos casos mudam —, com limiares previamente acordados para pausar a ferramenta e um caminho de reversão por meio da implantação versionada do fornecedor. Separadamente, quando uma enfermaria pede para colar históricos de pacientes num LLM público para redigir sumários de alta, o mesmo fórum de governança diz não a essa via não gerida e encomenda em vez disso uma ferramenta aprovada e contida, com verificação humana. Um ano depois, a ferramenta de priorização de fila melhorou modestamente o tempo de laudo, seu monitoramento captou um episódio de deriva após uma atualização de aparelho e — de modo decisivo — a organização consegue mostrar exatamente como ela é governada.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital muitas vezes é a IA, de modo que sua maturidade de governança é o seu acesso ao mercado. Os fundadores devem tratar a classificação regulatória, a validação clínica e a evidência de viés como trabalho central do produto, e não como um imposto de conformidade acrescentado antes de uma venda, porque o responsável pela segurança clínica de um comprador pedirá exatamente isso e um "não" encerra o negócio. Engajar-se cedo com a MHRA — potencialmente por meio de mecanismos como o AI Airlock para questões genuinamente novas — e projetar para o DTAC e o NICE Evidence Standards Framework desde o início transforma a garantia em vantagem competitiva. O risco característico da startup é a alegação exagerada: marketing que ultrapassa a evidência ou uma demonstração de acurácia média que esconde o mau desempenho em subgrupos. O fundador disciplinado incorpora cedo ao produto o monitoramento e a vigilância pós-comercialização, porque uma única falha em escala num local de referência é um evento existencial para uma pequena empresa.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma clínica de unidade única — é geralmente comprador de IA e não construtor, mas carrega os mesmos deveres de um grande hospital sem nenhuma equipe dedicada de segurança clínica, governança da informação ou informática para cumpri-los. O risco prático é adotar uma ferramenta com base nas garantias de um fornecedor porque não há capacidade interna para exigir classificação de dispositivo, evidência de subgrupo ou uma DPIA, e ninguém para perceber quando um modelo deriva. Apoiem-se fortemente na garantia que outros já fizeram: prefiram ferramentas que claramente detêm marcação de conformidade da MHRA e passaram no DTAC, comprem de fornecedores que publicam sua evidência e recomendem aplicativos de saúde apenas de uma biblioteca curada que o seu ICS ou um órgão nacional tenha assegurado em vez de avaliar cada um por conta própria. Onde vocês não conseguem verificar pessoalmente a segurança de uma ferramenta, isso é razão para recorrer à garantia compartilhada do seu sistema, e não para pular a verificação. Manter até um registro leve de quais ferramentas de IA vocês usam, para quê e quem é dono delas transforma um dever ingerenciável em proporcional.

Grande organização#

Um grande hospital ou ICS tem o aparato para governar bem a IA e a escala que torna séria a falha. Seu trabalho é estender as funções existentes de segurança clínica, governança da informação e garantia para cobrir a IA — um registro de modelos, padrões de justiça por subgrupo, monitoramento pós-comercialização, MLOps para versionamento e reversão — em vez de deixar a IA chegar por vias de TI ou de pesquisa sem escrutínio. O perigo real da grande organização é a fragmentação: dezenas de pilotos, ensaios de escribas ambientes e experimentos departamentais com LLMs proliferando sem inventário central, sem DPIA consistente e sem ninguém responsável quando uma ferramenta deriva. A fadiga de mudança e a pressão dos fornecedores empurram para a adoção rápida; a liderança deve, portanto, sustentar que a novidade não dá direito a um processo mais leve. Bem feita, a grande organização também pode gerar a evidência prospectiva e local de validação que os atores menores não conseguem e compartilhá-la com todo o sistema.

Governo#

Os órgãos governamentais nacionais e locais — a MHRA, o NHS England, o DHSC, o NICE, as administrações descentralizadas e as autoridades locais — definem as condições sob as quais todos os demais implantam a IA. Seus instrumentos são a regulação, os padrões, os arcabouços de garantia (DTAC, o Evidence Standards Framework), mecanismos de porto seguro como o AI Airlock e o financiamento e a orientação que conduzem a adoção segura num sistema federado que não gerenciam diretamente. A responsabilização corre perante ministros, o Parlamento e o público; uma falha em escala da IA ou um viés demonstrável numa ferramenta nacional é, assim, um evento de confiança pública com uma sombra longa. O papel próprio do governo é tornar o caminho seguro o caminho fácil — regras claras, garantia reutilizável, comunicação pública honesta sobre o que a IA pode e não pode fazer — enquanto resiste tanto a mandatos movidos pelo exagero quanto à proibição reflexiva. Errar o equilíbrio em qualquer direção custa anos de confiança.

Modos de falha comuns#

• Pular a classificação regulatória. Implantar uma IA clínica como se fosse software comum. Evitem-no determinando primeiro a situação de dispositivo e a marcação de conformidade, com contribuição regulatória.
• Cegueira da acurácia principal. Aceitar um número médio que esconde o mau desempenho para grupos sub-representados. Evitem-na exigindo evidência de subgrupo antes da entrada em produção e monitorando a iniquidade depois.
• Validar uma vez e esquecer para sempre. Tratar a entrada em produção como o fim da garantia enquanto o modelo deriva em silêncio. Evitem-no montando a vigilância pós-comercialização com limiares e reversão.
• Supervisão humana decorativa. Um "humano no circuito" que carimba sob viés de automação. Evitem-na auditando as taxas de sobreposição e projetando autoridade genuína para intervir.
• IA generativa sem governança. A equipe colando dados de pacientes em LLMs públicos e confiando em saídas fabricadas. Evitem-na com política clara mais uma ferramenta aprovada e contida, com verificação humana.
• Processo paralelo e leve. Deixar a IA contornar a segurança clínica e a governança da informação porque é "inovação". Evitem-no estendendo a maquinaria existente de DCB e DPIA à IA.
• Sem inventário. Ninguém sabendo quais modelos estão no ar, sobre quais dados, de quem. Evitem-no mantendo um registro de modelos.

Modelo de maturidade#

Lista de verificação#

• A situação de dispositivo médico e a marcação de conformidade da MHRA de cada ferramenta de IA são determinadas e documentadas.
• A IA clínica passou no DTAC, foi conferida com o NICE Evidence Standards Framework e tem uma avaliação de risco clínico DCB e uma DPIA.
• O desempenho por subgrupo (idade, sexo, etnia, privação) foi visto e atende a um padrão de justiça acordado.
• A validação clínica corresponde ao nível de risco e prefere evidência prospectiva e local.
• Um humano no circuito significativo é projetado, com autoridade e informação para se sobrepor.
• A responsabilização nomeada por decisões informadas pela IA está escrita.
• A vigilância pós-comercialização, os limiares de deriva e um plano de pausa/reversão estão ativos desde a entrada em produção.
• O MLOps dá versionamento do modelo e reversão segura; a versão no ar é sempre conhecida.
• A política de IA generativa permite usos realistas, proíbe dados de pacientes em serviços não geridos e exige verificação humana.
• A governança da informação cobre os dados de treinamento, ajuste e avaliação, com limites contratuais à reutilização pelo fornecedor.
• Um registro de modelos legível por humanos registra propósito, proveniência, evidência, monitoramento e responsável.
• As tecnologias emergentes são observadas por varredura de horizonte e faseadas por avaliação controlada e reversível.

Fontes-chave#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device e o sandbox regulatório AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) para tecnologias de saúde digital (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) para a garantia de linha de base de tecnologias de saúde digital.
• NHS England / antigo NHSX — A Buyer's Guide to AI in Health and Care e a AI Ethics Initiative.
• DCB0129 e DCB0160 — padrões de gestão de risco clínico para TI em saúde (ver Tópico 1.6).
• MHRA / IMDRF — arcabouço de Software como Dispositivo Médico (SaMD) e boas práticas de aprendizado de máquina.
• The King's Fund e a Health Foundation — análise de IA, dados e desigualdades na saúde e nos cuidados.
• Ver também Tópico 1.3 — Decisões baseadas em evidências; Tópico 1.6 — Segurança clínica e gestão de riscos; Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança; Tópico 8.0 — Implantação faseada da inovação.

Referências#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics