SB1047 foi uma má ideia. Mas o último SB53 do senador Wiener está no caminho certo e é importante chamar a atenção para o progresso. Aqui está o meu raciocínio. Minha abordagem para regular novas tecnologias como modelos é: não sabemos como definir "boa" mitigação e garantia, mas saberemos quando - e se - as virmos. Existem duas implicações. #1. Não devemos prescrever limites de risco ou padrões de atendimento para o desenvolvimento de modelos. Não podemos 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 nascentes determinadas principalmente por empresas de código fechado que dependem de paywalls para fazer o trabalho pesado. Isso poderia esfriar a inovação aberta, expondo os desenvolvedores a uma responsabilidade vaga ou aumentada pelo lançamento generalizado. Esse foi o SB1047 em poucas palavras, junto com ~ 5 equivalentes que inspirou nos EUA nesta sessão, como o RAISE Act em NY. Devemos evitar essa abordagem. Essas propostas estão - em aspectos estreitos, mas cruciais - muito além de seus esquis. E ainda: #2. Precisamos esclarecer as práticas do setor 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 de papel, podemos avaliar melhor a força de suas reivindicações, monitorar riscos emergentes e decidir sobre intervenções futuras. Essa é a Lei de IA da UE e o Código de Prática final em poucas palavras, que tanto a OpenAI quanto a Mistral endossaram, e também é a versão mais recente do SB53 da @Scott_Wiener. Se vamos regular o desenvolvimento de modelos, essa é fundamentalmente a melhor abordagem: regular a transparência – não capacidades, mitigações ou riscos aceitáveis. Isso daria a pelo menos uma jurisdição dos EUA a autoridade de supervisão de Bruxelas e evitaria efeitos não intencionais no desenvolvimento aberto. Para ser claro, ainda há icebergs pela frente: > Complexidade. Big Tech ou não, essas são obrigações onerosas de documentação e relatórios. Taticamente falando, quanto mais complexo, mais vulnerável esse projeto de lei se tornará. > Incentivos. A divulgação pública obrigatória de avaliações de risco voluntárias cria um incentivo perverso para que os desenvolvedores testem seus modelos e fechem 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 uma maior franqueza em suas avaliações internas. > cavalo de Tróia. A cultura hiperativa de intestino e emenda da Califórnia pode dificultar a verificação desses projetos de lei. Se o SB53 se transformar em um projeto de lei padrão de atendimento como SB1047 ou RAISE, ele deve ser rejeitado pelos mesmos motivos de antes. Quanto mais enfeites forem adicionados a esta árvore de Natal, mais controverso será o projeto de lei. > largura. O projeto de lei lança uma ampla rede com definições expansivas de risco catastrófico e capacidade perigosa. Para um projeto de lei de "relatórios obrigatórios / práticas voluntárias", eles funcionam. Se esse projeto de lei fosse um projeto de lei padrão de atendimento, eles seriam inviáveis. Em suma: tiro o chapéu para o senador Wiener por se envolver e responder cuidadosamente ao feedback no ano passado. É revigorante ver um projeto de lei que realmente se baseia em críticas anteriores. Ainda existem muitos caminhos que esse projeto de lei pode seguir - e ele evoluiu muito além da proposta original de denúncia - mas a trajetória é promissora.