O SB1047 foi uma má ideia. Mas o mais recente SB53 do Sen. Wiener está no caminho certo, e é importante reconhecer o progresso. Aqui está o meu raciocínio. A minha abordagem para regular tecnologias novas como modelos é: não sabemos como definir uma mitigação e garantia "boas", mas saberemos quando—e se—virmos. Há duas implicações. #1. Não devemos prescrever limiares de risco ou padrões de cuidado para o desenvolvimento de modelos. Não conseguimos concordar sobre os riscos que importam, como medi-los ou quanto é demais. A única orientação para desenvolvedores, reguladores e tribunais é um conjunto de práticas incipientes determinadas principalmente por empresas de código fechado que dependem de paywalls para fazer o trabalho pesado. Fazer isso poderia inibir a inovação aberta ao expor os desenvolvedores a uma responsabilidade vaga ou aumentada pela liberação generalizada. Isso foi o SB1047 em resumo, junto com cerca de 5 equivalentes que inspirou em todo os EUA nesta sessão, como o RAISE Act em NY. Devemos evitar essa abordagem. Essas propostas são—em aspectos estreitos, mas cruciais—demasiado ambiciosas. E ainda assim: #2. Precisamos iluminar as práticas da indústria para entender melhor a diligência, ou a falta dela, aplicada por diferentes empresas. Se os desenvolvedores tiverem que se comprometer com uma política de segurança e proteção, mostrar seu trabalho e deixar um rastro documental, poderemos avaliar melhor a força de suas alegações, monitorar riscos emergentes e decidir sobre intervenções futuras. Isso é o que o Ato de IA da UE e o Código de Prática final resumem, que tanto a OpenAI quanto a Mistral endossaram, e é também a versão mais recente do SB53 do @Scott_Wiener. Se vamos regular o desenvolvimento de modelos, essa é fundamentalmente a melhor abordagem: regular a transparência—não capacidades, mitigações ou risco aceitável. Isso daria pelo menos uma jurisdição dos EUA a autoridade de supervisão de Bruxelas, e evitaria efeitos indesejados no desenvolvimento aberto. Para ser claro, ainda há icebergs à frente: > Complexidade. Seja Big Tech ou não, estas são obrigações de documentação e relatório onerosas. Taticamente falando, quanto mais complexa, mais vulnerável este projeto se tornará. > Incentivos. O relatório público obrigatório de avaliações de risco voluntárias cria um incentivo perverso para os desenvolvedores subtestarem seus modelos e fecharem os olhos para riscos difíceis. Permitir que os desenvolvedores divulguem seus resultados a auditores ou agências em vez de publicamente pode ajudar a promover maior sinceridade em suas avaliações internas. > Cavalo de Troia. A cultura hiperativa de alteração e emenda da Califórnia pode dificultar a verificação desses projetos. Se o SB53 se transformar em um projeto de padrão de cuidado como o SB1047 ou o RAISE, deve ser rejeitado pelas mesmas razões de antes. Quanto mais enfeites forem adicionados a esta árvore de Natal, mais contencioso será o projeto. > Amplitude. O projeto lança uma rede ampla com definições expansivas de risco catastrófico e capacidade perigosa. Para um projeto de "relatório obrigatório / práticas voluntárias", eles funcionam. Se este projeto fosse um projeto de padrão de cuidado, seriam inviáveis. Em suma: parabéns ao Sen. Wiener por se envolver e responder de forma ponderada ao feedback ao longo do último ano. É refrescante ver um projeto que realmente se baseia em críticas anteriores. Ainda há muitos caminhos que este projeto pode seguir—e ele evoluiu muito além da proposta original de denúncia—mas a trajetória é promissora.