O presidente da Microsoft Brad Smith defende supervisão reforçada da IA com uma comparação quotidiana: leite e máquinas de lavar enfrentam mais controlos de segurança do que IA avançada. Na cobertura da entrevista de 12 de outubro, descreveu-a como ferramenta e arma, pediu controlos de emergência, avaliação independente e obrigações perante vítimas de agentes descontrolados que violem sistemas.
Não significa que a IA esteja fora de toda a lei. Privacidade, discriminação, consumo, fraude, direitos de autor e regras setoriais já se aplicam. Smith pergunta se proteções exigíveis antes e durante o uso acompanham sistemas que leem dados, usam ferramentas e agem além de uma conversa. A mesma exigência expõe a Microsoft e os seus interesses comerciais.
O que estabelece a analogia dos produtos
Inspeção do leite e normas dos aparelhos criam deveres reconhecíveis: testar, documentar, responder a defeitos e danos. A IA complica o modelo porque um sistema resume, programa, interpreta saúde e opera serviços. Instruções, conteúdo recuperado, memória e permissões mudam comportamento sem novo modelo.
A analogia identifica uma lacuna, não um regime inspetivo pronto. Aprovar um modelo fixo não certifica todas as aplicações. Criadores, clouds, fornecedores e empresas utilizadoras controlam riscos distintos. Um benchmark não garante o agente ligado a ficheiros de clientes ou ferramentas financeiras.
A Microsoft participa em várias camadas por infraestrutura, modelos, Azure, Copilot e relação OpenAI. Dá peso prático ao argumento, mas impede apresentar-se como observador neutro ou mero fornecedor de infraestrutura.
O seu programa de IA responsável inclui equidade, fiabilidade, privacidade, transparência, responsabilidade e inclusão, com revisões, ferramentas e relatórios. Pode antecipar utilmente a lei, mas é definido pela empresa. Princípios não provam segurança de cada produto ou configuração.
Um travão de emergência não desfaz ações
Os «kill switches» de Smith significam parar ou limitar comportamento fora dos limites, não necessariamente um botão físico. Revogar credenciais, desligar ferramentas, limitar despesas, parar fluxos e isolar serviços atuam em níveis distintos. Autoridade humana, separação técnica e escalada testada são necessárias se o serviço original for comprometido.
Uma discussão de responsabilidade de 22 de setembro examinou monitorização, limites de despesa e divisão entre infraestrutura, modelos, dados e aplicações. Cada fornecedor pode culpar outro enquanto o cliente não tem provas para reconstituir o incidente.
Parar o processo não recupera dados expostos nem anula uma decisão nociva já aceite a jusante. Privilégio mínimo, aprovação de ações importantes e separação sensível devem preceder a emergência. A injeção de instruções mostra o risco: conteúdo hostil lido pode ser tomado como autoridade e as ferramentas tornam o erro numa ação.
Monitorizar exige sinais utilizáveis, não apenas registos: acesso invulgar, ferramentas inesperadas, despesa anormal ou evasão repetida. Um supervisor sem compreensão e poder de interrupção não funciona. Recuperação exige provas, avisos e identificação de ações concluídas.
Nenhum interruptor universal controla todas as cópias, modificações de pesos abertos ou implantações maliciosas na Internet. Regras cloud não se adaptam automaticamente a modelos descarregáveis. Desenvolvimento, distribuição, alojamento e uso de alto risco devem distinguir-se pelo controlo e capacidade de mitigação.
Os direitos das vítimas fazem parte da proposta
Smith reclama obrigações jurídicas perante vítimas, não apenas documentos. Um recurso deveria examinar quem conhecia o risco, controlava a decisão e podia prevenir dano. São questões políticas, não uma declaração de que o mesmo ator já deve indemnizar todos os incidentes.
Um criador não deve suportar automaticamente todas as perdas de aplicação alheia que ignore restrições documentadas. Um utilizador também não deve absorver consequências de uma vulnerabilidade ocultada pelo fornecedor. É preciso evitar imunidade absoluta e transferência total para o cliente.
Relatórios podem revelar falhas repetidas que compradores isolados não agregam. Limiares devem separar erros comuns de acesso indevido, perdas materiais, interrupção essencial, dano físico ou exposição massiva. Muito amplos saturam; muito estreitos suprimem avisos.
Investigadores independentes precisam de provas técnicas quando as causas são disputadas. Divulgação deve proteger dados e evitar detalhes exploráveis antes da correção. Compensação, acesso a provas e contenção desenham-se juntos, não como promessas separadas.
Europa, Washington e Londres oferecem vias distintas
O quadro europeu da IA já distribui deveres por risco e requisitos documentais, de transparência e sistémicos para modelos gerais. O Serviço para a IA pode pedir documentos, avaliar, exigir correções e sancionar. Não se trata de setor totalmente sem regulação.
A cobertura varia por país, setor, sistema e data. Os Estados Unidos privilegiam frequentemente compromissos voluntários e indústria, adaptáveis mas definidos pelas empresas com poucas provas externas. Aprovação rígida pode envelhecer antes de terminar; princípios vagos podem não permitir intervenção.
Deveres duradouros com normas técnicas adaptáveis oferecem equilíbrio. Risco, comunicação, permissões e avaliação não exigem prescrever todos os métodos. Organismos atualizam testes enquanto reguladores mantêm poder. Ambientes supervisionados e recursos comuns ajudam pequenas empresas sem reinventar sistemas.
Smith vê oportunidade britânica porque Washington olha para Londres de forma diferente de Bruxelas. As autoridades preparavam mais supervisão, mas a fonte não estabelece uma nova lei completa. Sistemas, responsáveis, limiares, provas e poderes têm de ser concretos, ou mantém-se voluntariedade. Competição com a China aumenta pressão de velocidade sem eliminar consequências.
As regras também têm de restringir a Microsoft
A preocupação comercial é legítima. Grandes empresas já possuem equipas de conformidade, infraestrutura e relações públicas. Validar essas estruturas pode sobrecarregar pequenos rivais e tornar segurança numa barreira. Isso não invalida riscos, mas obriga a avaliar incentivos.
Requisitos devem seguir capacidade, controlo e risco demonstrado, não apenas dimensão nem isenção automática por distribuição. Modelos abertos têm limites distintos. Restrições excessivas concentram desenvolvimento; deveres fracos permitem evasão mudando distribuição.
A Microsoft deve identificar controlos, testes e condições de escalada. Contratos devem esclarecer a divisão com parceiros, criadores e clientes. Publicar princípios transferindo todas as consequências enfraqueceria a proteção das vítimas.
Testes independentes devem abranger serviços ligados, revogação seletiva, reconstituição e recuperação, com provas comparáveis de âmbito e falhas. Não exigem revelar pesos ou defesas sensíveis, mas permitir comparar limites e confirmar controlos acessíveis aos administradores.
Uma base de conhecimento IA pesquisável conserva usos autorizados, responsáveis e decisões sem substituir contenção. As próximas provas são propostas britânicas concretas, travões testados e responsabilidade na cadeia. A comparação contará se produzir deveres e recursos exigíveis também à Microsoft, não apenas uma frase memorável.