A lacuna da destilação: responsabilização quando agentes de IA são comprimidos para implantação em hardware

O termo "destilação" cobre técnicas como quantização, destilação de conhecimento, poda e fatorização de baixo posto. Todas têm o mesmo objetivo prático: transformar um modelo concebido para centros de dados em algo suficientemente pequeno para correr num bolso, numa enfermaria ou numa tomada. As técnicas estão maduras; a infraestrutura de responsabilização para a transição não acompanhou.

Um modelo grande é avaliado quanto a segurança, testado contra casos de fronteira e sondado de forma adversarial. Essa avaliação é cara e feita sobre o modelo original. Quando o modelo é comprimido para implantação em hardware, a versão comprimida é outro modelo. Em média pode parecer equivalente; nas margens, onde aparecem entradas raras e combinações novas de contexto, pode divergir de modos difíceis de prever.

Essa divergência é a lacuna da destilação. Não é defeito de uma implementação concreta, mas uma característica estrutural da relação entre capacidade do modelo, requisitos de implantação na ponta e cadeia de responsabilização.

Porque a compressão altera as margens

A quantização reduz a precisão numérica dos pesos e tende a afetar mais as regiões do espaço de entrada pouco cobertas pelos dados de treino. As representações aprendidas são mais delicadas onde o sinal de treino foi mais fraco.

Os cuidados no mundo físico são exatamente o domínio em que a cobertura escassa importa: combinações invulgares de medicação, sinais vitais atípicos e necessidades que não cabem numa classificação padrão. A compressão torna essas margens menos previsíveis. A poda tem problema semelhante: uma capacidade que parece pouco útil em média pode ser essencial para um caso estreito mas consequente.

A travessia do hardware

No hardware, agentes de IA interpretam estados de firmware, leituras de sensores e atestações. A certificação costuma avaliar essas decisões antes da implantação. A lacuna surge quando o programador certifica o modelo grande, o integrador o comprime e o operador implanta a versão comprimida sob a autoridade da certificação original.

Quando uma versão comprimida em hardware médico se comporta de modo diferente do original certificado, mesmo uma única vez, a cadeia de certificação quebrou no passo de compressão. Do ponto de vista de engenharia, a compressão é otimização. Do ponto de vista da responsabilização, é substituição de modelo.

A travessia dos cuidados

Nos cuidados, as consequências são imediatas. Agentes são implantados onde há poucos profissionais, demasiados destinatários e demasiada pressão sobre a atenção humana. Se a versão comprimida perdeu capacidade para lidar com contraindicações raras ou apresentações atípicas, perdeu exatamente a capacidade que o ambiente com poucos recursos mais necessita.

Destinatários de cuidados não conseguem inspecionar parâmetros de compressão nem comparar a versão implantada com a certificada. Não têm forma fiável de saber se a cobertura de casos raros foi preservada ou deixada para trás.

O que fechar a lacuna exige

Primeiro, paridade de avaliação: o modelo comprimido deve ser avaliado por si, não como derivado presumido do original. Segundo, proveniência do processo de compressão: técnicas aplicadas, distribuição usada, limiares de fidelidade e responsáveis pela verificação.

Terceiro, implantação limitada por escopo, com monitorização de entradas fora de distribuição e caminho claro de escalamento. Quarto, separação do passo de compressão na cadeia de responsabilização, para que seja claro se a falha pertence ao modelo original ou ao processo que o substituiu.

Um agente de cuidado que falha silenciosamente porque a compressão removeu a cobertura de que precisava não é risco teórico. É um produto implantável hoje. A infraestrutura de responsabilização para esse produto ainda não está pronta.