O problema do dispositivo órfão: responsabilização quando um dispositivo de cuidados com AI embebida sobrevive à sua infraestrutura de governação

O hardware médico tem ciclos de vida longos. Um dispositivo implantado pode funcionar durante dez a quinze anos. Uma plataforma de monitorização domiciliária, depois de instalada e aceite por uma equipa de cuidados, tende a persistir muito para lá da sua primeira geração de software. A pessoa cuidada constrói uma rotina em torno dela. A equipa clínica integra-a no fluxo de trabalho. A família aprende a depender dos seus alertas. O dispositivo torna-se infraestrutura: parte do ambiente de cuidados, não um produto ainda em avaliação ativa.

A infraestrutura de governação de AI colocada sobre esse hardware não tem a mesma expectativa de duração. O fornecedor que mantém a API de auditoria na cloud, o sistema de registos de consentimento, o pipeline de atualização de modelos e o canal de reporte de incidentes está sujeito às pressões de qualquer empresa de software: mudanças de estratégia, aquisição por um concorrente, esgotamento de capital, alterações regulatórias na sua jurisdição que mudam a economia da operação. A vida esperada de um fornecedor de software de saúde com AI financiado por capital de risco mede-se em anos. A vida esperada do dispositivo que ele governa mede-se em décadas.

Quando essas duas linhas temporais divergem, o dispositivo fica órfão. O hardware continua a funcionar. O agente de AI continua a tomar decisões. A pessoa cuidada continua a receber cuidados. Mas a infraestrutura institucional que tornava essas decisões responsabilizáveis: trilho de auditoria com acesso ativo, registo de consentimento com guardião humano, canal de reporte de incidentes, serviço de gestão de chaves e atualização de modelo que teria corrigido uma falha comportamental conhecida, deixa de existir.

No cruzamento do hardware

Um agente de AI baseado em hardware estabelece a sua fiabilidade através de uma cadeia de atestação: o dispositivo prova criptograficamente que o seu software corresponde ao que foi revisto e autorizado. Essa cadeia regressa a uma hierarquia de certificados mantida pelo fornecedor. Quando a autoridade certificadora do fornecedor é encerrada ou o seu domínio expira, a cadeia de atestação quebra. Um auditor, regulador ou gestor de risco clínico que pergunte “este dispositivo está a executar o que autorizámos?” já não tem mecanismo para verificar a resposta. O hardware pode estar fisicamente inalterado, mas a sua identidade verificável, aquilo que distingue um dispositivo corretamente operacional de um comprometido, dissolveu-se.

Vulnerabilidades de software descobertas após o encerramento do fornecedor não podem ser corrigidas. Uma falha comportamental na lógica de decisão de AI, uma fraqueza criptográfica no esquema de derivação de chaves, um enviesamento na calibração do modelo que empurra decisões para intervenções de menor custo: se qualquer uma for identificada depois de o fornecedor desaparecer, persistirá em todos os dispositivos instalados pelo resto da sua vida operacional. O dispositivo não tem via de atualização. A pessoa cuidada não recebe aviso. A equipa clínica não tem opção de remediação.

No cruzamento dos cuidados no mundo físico

A lacuna de responsabilização manifesta-se de forma mais aguda no contexto de cuidados. Um agente de AI que gere horários de medicação, monitoriza sinais vitais ou coordena transições de cuidados toma milhares de decisões ao longo da vida do dispositivo. Cada uma dessas decisões era, no momento da instalação, apoiada por uma estrutura de governação: um fornecedor com equipa de suporte, uma aprovação regulatória com obrigação de vigilância pós-mercado, um sistema cloud que guardava o registo de consentimento. Quando o fornecedor se dissolve, as decisões seguintes são tomadas por um agente que já não tem um principal responsabilizável por trás.

A pessoa cuidada não sabe que isto aconteceu. Normalmente não existe obrigação de notificação quando um fornecedor encerra um serviço não crítico para a segurança. A equipa clínica pode também não saber: o dispositivo continua a funcionar, os alertas continuam a chegar e nada na interface indica que a infraestrutura de governação ficou escura. A assimetria de informação é total: a pessoa cuidada confia no dispositivo precisamente porque acredita que ele é supervisionado, quando na realidade a supervisão terminou.

Quando ocorre um evento adverso: um alerta falhado, uma recomendação de dose errada, uma transição de cuidados que falha porque o agente de coordenação já não sincroniza com a rede de cuidados, a parte lesada descobre que não há fornecedor a contactar, linha de suporte a chamar ou incidente a reportar. A parte responsabilizável evaporou. O dispositivo continua em casa. O dano é real. A via de reparação está vazia.

Porque isto é estruturalmente distinto

O problema do dispositivo órfão não é o mesmo que o problema de desativação, que trata de como um agente deve ser retirado de serviço intencionalmente. Também não é o problema do ciclo de vida do hardware, que trata de atualizações planeadas e transições de fim de suporte. O cenário do dispositivo órfão distingue-se pelo facto de ninguém ter tomado uma decisão intencional de terminar a governação do dispositivo. O dispositivo não foi desativado: foi abandonado. A infraestrutura de governação não foi reformada: simplesmente fechou.

Isto cria condições de responsabilização para as quais o quadro existente de segurança de dispositivos não foi desenhado. A vigilância regulatória pós-mercado pressupõe que existe um fabricante contactável. A doutrina de responsabilidade por produto pressupõe um réu que ainda existe. A lei de garantia pressupõe um garante. Quando todos estes pontos de ancoragem institucional desaparecem ao mesmo tempo, o paciente lesado enfrenta a mesma lacuna de recurso criada por qualquer vazio de responsabilidade institucional, mas num contexto em que o dispositivo em sua casa ainda carrega as marcas de credibilidade da autorização original.

O que a continuidade de governação exige

Fechar a lacuna do dispositivo órfão exige tratar a continuidade de governação como uma obrigação de segurança do produto desde o início. Isto significa exigir, como condição de aprovação regulatória para qualquer dispositivo de cuidados com AI embebida e vida útil plurianual, um plano de continuidade de governação: acordo de escrow para logs de auditoria, guardião designado para registos de consentimento, mecanismo para enviar atualizações críticas de segurança mesmo após o fim das operações comerciais e uma entrada de registo público que sinalize quando o estado de governação muda.

Também significa que o próprio hardware deve ser desenhado para emitir um sinal verificável de estado de governação: uma atestação periódica de que a infraestrutura de supervisão do dispositivo está ativa, que o trilho de auditoria tem um guardião contactável e que o modelo não chegou a um estado de fim de suporte. Um dispositivo incapaz de produzir esse sinal deve ser assinalado à equipa clínica, não silenciosamente confiado. Silêncio num sinal de governação não deve ser tratado como garantia. Deve ser tratado como aviso.