Conformidade com a SB 53 da Califórnia: Um Guia Prático para a Lei de Transparência em IA de Fronteira

Em 29 de setembro de 2025, o governador da Califórnia, Gavin Newsom, sancionou o Projeto de Lei do Senado 53, a Lei de Transparência em Inteligência Artificial de Fronteira (TFAIA), tornando a Califórnia a primeira jurisdição dos EUA a impor obrigações vinculantes de segurança, transparência e relato de incidentes aos desenvolvedores dos sistemas de IA computacionalmente mais intensivos. A lei entrou em vigor em 1º de janeiro de 2026 e, nos últimos seis meses, remodelou silenciosamente a forma como os maiores laboratórios de IA e uma lista crescente de desenvolvedores de modelos de nível médio documentam riscos, publicam frameworks de governança e informam os reguladores sobre cenários de risco catastrófico.

Se a sua organização treina, faz o ajuste fino (fine-tuning) ou modifica substancialmente modelos de fundação — ou opera grandes clusters de computação nos quais outros desenvolvedores confiam — a SB 53 é agora a lei de IA mais consequente que você precisa entender nos Estados Unidos. Este guia percorre quem está coberto, o que você deve publicar, como funciona o prazo de 15 dias para o relato de incidentes críticos, quais obrigações de denúncia (whistleblower) se aplicam e como traduzir o estatuto em um programa de conformidade operacional.

O Que a SB 53 Realmente Regula

Ao contrário das leis de IA para o emprego que estão se espalhando estado por estado (como a Lei Local 144 de NYC ou a Lei de IA do Colorado), a SB 53 não regula ferramentas de contratação algorítmica, modelos de subscrição de crédito ou sistemas de triagem de inquilinos. Ela visa uma categoria muito mais restrita: modelos de fundação de fronteira treinados em escalas computacionais extraordinárias e os cenários de risco catastrófico que podem derivar deles.

A lei situa-se na interseção de duas tradições regulatórias. Da lei de segurança do produto, ela empresta a ideia de que as empresas devem publicar avaliações de risco e notificar as autoridades quando os incidentes se materializam. Da lei de regulação financeira, ela empresta a ideia de que os maiores players carregam ônus de divulgação mais pesados do que os menores. O resultado é um regime hierarquizado construído em torno de dois limiares.

O Limiar de Computação de 10^26 FLOPs

Um "modelo de fronteira" sob a SB 53 é definido como um modelo de fundação treinado usando mais de 10^26 operações de inteiros ou de ponto flutuante, incluindo a computação cumulativa de ajustes finos e modificações subsequentes. Este limiar está deliberadamente alinhado com o gatilho de relatório da Ordem Executiva Federal 14110 (agora revogada) e o nível de IA de propósito geral da Lei de IA da UE, de modo que a maioria dos grandes laboratórios dos EUA já sabe se o ultrapassa.

O que às vezes passa despercebido é que o estatuto conta a computação cumulativa de modificações a jusante. Se você pegar um modelo base que foi treinado próximo ao limiar e continuar o pré-treinamento, fizer ajuste fino por aprendizagem por reforço ou fundir pesos com outro modelo, você pode levar um derivativo ao status de fronteira, mesmo que nenhuma execução de treinamento individual tenha cruzado 10^26 FLOPs. Catalogar cada modelo base, cada ajuste fino, cada destilação e cada fusão de pesos — e rastrear os FLOPs consumidos em cada etapa — é agora uma disciplina de escrituração essencial.

O Limiar de Receita de US$ 500 Milhões para Grandes Desenvolvedores de Fronteira

Um "grande desenvolvedor de fronteira" é um desenvolvedor de fronteira cuja entidade e afiliadas ganharam mais de US $500 milhões em receitas brutas anuais no ano civil anterior. O teste de receita é consolidado: empresas controladoras, subsidiárias e afiliadas sob controle comum são somadas. Uma pequena startup de IA que levantou uma rodada de financiamento de um bilhão de dólares, mas ganhou US$ 40 milhões em receita real, não é um grande desenvolvedor de fronteira; um conglomerado de tecnologia de capital aberto com uma pequena divisão de IA que ultrapassa o limiar de FLOPs quase certamente é.

A diferenciação importa porque os grandes desenvolvedores de fronteira carregam as obrigações mais pesadas: publicar um framework de IA de fronteira, realizar avaliações de risco catastrófico, enviar resumos trimestrais de risco de uso interno ao Escritório de Serviços de Emergência da Califórnia (Cal OES) e manter um canal interno de denúncia anônima. Desenvolvedores de fronteira menores — aqueles acima do limiar de FLOPs, mas abaixo do limiar de receita — ainda devem publicar relatórios de transparência e relatar incidentes críticos de segurança, mas não estão sujeitos ao regime completo do framework.

O Que Você Tem Que Publicar: O Framework de IA de Fronteira

Cada grande desenvolvedor de fronteira deve publicar um framework de IA de fronteira em seu site e mantê-lo atualizado. A revisão anual é obrigatória, e qualquer modificação material deve desencadear uma atualização em até 30 dias após a mudança.

Um framework defensável aborda, no mínimo:

Limiares de risco catastrófico e métodos de avaliação. Quais capacidades — assistência em armas químicas, biológicas, radiológicas e nucleares; ataque à infraestrutura crítica em larga escala; cenários de perda de controle de agentes autônomos — o desenvolvedor trataria como ultrapassando um limiar catastrófico? Como o desenvolvedor testará essas capacidades antes da implantação?
Estratégias de mitigação de risco. Mitigações concretas pré-implantação: treinamento de recusa, atenuação de capacidades, restrições de implantação, acesso monitorado, lançamentos graduais e monitoramento pós-implantação.
Avaliações de terceiros. Quais red teams (equipes vermelhas) externas, avaliadores e auditores avaliarão o modelo e como suas descobertas serão incorporadas?
Protocolos de segurança cibernética para pesos de modelos não lançados. Controles de ameaças internas, módulos de segurança de hardware, segmentação de rede e registro de acesso que protegem os pesos pré-implantação contra roubo.
Procedimentos de resposta a incidentes críticos de segurança. Quem decide se um incidente é reportável, como o cronômetro de 15 dias é iniciado e como a empresa se coordena com o Cal OES.
Mecanismos de governança interna. Supervisão em nível de diretoria, o papel do diretor de segurança de IA, caminhos de escalonamento e a cadência das revisões de segurança.
Alinhamento com padrões. Mapeamento explícito para o Framework de Gestão de Riscos de IA do NIST (AI RMF 1.0) e ISO/IEC 42001, que o estatuto trata como bases fundamentais.

O framework não é um documento de marketing. É um artefato voltado ao regulador que o Procurador-Geral pode usar para avaliar se os compromissos públicos da empresa correspondem à sua prática interna. Redigi-lo com o mesmo rigor de uma divulgação de fatores de risco da SEC ou uma descrição de sistema SOC 2 é a postura correta.

Relatórios de Transparência Antes de Cada Implantação

Todo desenvolvedor de modelos de fronteira — não apenas os grandes — deve publicar um relatório de transparência antes de implantar um modelo de fronteira novo ou substancialmente modificado. O relatório de transparência é um documento específico do modelo, separado da estrutura, que deve incluir:

Nome da empresa, site e mecanismo de contato para preocupações de segurança
A data de lançamento do modelo e uma lista de idiomas suportados e modalidades de saída
Usos pretendidos e restrições de uso aplicáveis
Para grandes desenvolvedores, um resumo das avaliações de risco catastrófico e os resultados, incluindo se e como avaliadores terceirizados foram envolvidos

Uma "modificação substancial" inclui atualizações de capacidades principais, adições de novas modalidades e mudanças significativas na combinação de dados de treinamento. Versões de correção (patches) e ajustes finos de segurança rotineiros geralmente não exigem um novo relatório de transparência, mas casos limítrofes devem ser documentados com uma justificativa por escrito, caso o Procurador-Geral pergunte posteriormente por que nenhum relatório foi publicado.

O Prazo de 15 Dias para Relato de Incidentes Críticos

O ônus de conformidade que mais surpreendeu os consultores jurídicos internos é o cronograma de relato de incidentes. Os desenvolvedores de modelos de fronteira devem notificar o Escritório de Serviços de Emergência da Califórnia (Cal OES) sobre um incidente de segurança crítico dentro de 15 dias após a descoberta, com um prazo mais apertado de 24 horas se o incidente representar uma ameaça iminente à segurança pública.

O estatuto define um incidente de segurança crítico de forma ampla:

Acesso não autorizado a, ou roubo de, pesos de modelos não lançados
Materialização de um risco catastrófico
Perda de controle do desenvolvedor sobre um modelo implantado
Comportamento enganoso ou evasivo do modelo que derrota as salvaguardas

Construir um processo interno defensável significa responder a três perguntas antes que um incidente ocorra:

Quem decide? Um único oficial nomeado (frequentemente o diretor de segurança de IA ou um substituto designado) deve deter a autoridade para iniciar a contagem do prazo de relato, com critérios de escalonamento documentados.
O que inicia o prazo? A "descoberta" é o gatilho. A documentação interna deve capturar exatamente quando um incidente foi descoberto, por quem e através de qual sistema de monitoramento, porque a janela de 15 dias é calculada a partir desse momento.
Como o relatório é transmitido? O Cal OES mantém um processo de recebimento confidencial para submissões de desenvolvedores. A equipe de relatórios deve ensaiar o fluxo de trabalho de submissão — incluindo a transmissão criptografada de detalhes técnicos sensíveis — bem antes de qualquer incidente real.

Para grandes desenvolvedores de modelos de fronteira, a obrigação vai além do relato reativo de incidentes. A cada três meses (ou de acordo com outro cronograma razoável), os grandes desenvolvedores devem transmitir ao Cal OES um resumo de qualquer avaliação de risco catastrófico decorrente do uso interno de seus modelos de fronteira. Essa cadência trimestral é exclusiva da SB 53 e é a primeira vez que um estatuto dos EUA obriga laboratórios de IA a relatar descobertas contínuas de riscos de uso interno a uma agência do poder executivo.

Proteções a Denunciantes e o Canal Interno Anônimo

A SB 53 sobrepõe ao regime geral de denunciantes da Califórnia um conjunto de proteções específicas para IA que se aplicam a "funcionários cobertos" — aqueles cujos deveres incluem avaliar, gerenciar ou abordar o risco de danos catastróficos de modelos de fronteira.

Os desenvolvedores de modelos de fronteira não podem impedir um funcionário coberto de divulgar, nem retaliar contra um funcionário coberto por divulgar informações para:

O Procurador-Geral da Califórnia
Uma autoridade reguladora federal
Um supervisor direto ou outro supervisor com autoridade para investigar
Outro funcionário coberto cujos deveres incluam a avaliação de riscos

As divulgações protegidas cobrem tanto (a) a crença razoável de que as atividades do desenvolvedor apresentam um perigo específico e substancial à saúde ou segurança pública devido a um risco catastrófico, quanto (b) a crença razoável de que o desenvolvedor violou a própria SB 53.

Os grandes desenvolvedores de modelos de fronteira também devem manter um canal de denúncia interno anônimo. O estatuto exige:

Um fluxo de trabalho que permita aos funcionários cobertos enviar divulgações anônimas sobre preocupações de risco catastrófico
Atualizações mensais de status para o funcionário denunciante sobre a investigação
Briefings trimestrais para diretores e conselheiros que resumam as divulgações e resultados, com indivíduos nomeados acusados de irregularidades excluídos do público do briefing

Os tribunais podem conceder honorários advocatícios aos autores bem-sucedidos em ações de retaliação. Criticamente, o estatuto inverte o ônus da prova: quando um funcionário coberto demonstra que a atividade protegida foi um fator contribuinte para uma ação adversa, o desenvolvedor assume o ônus de provar que a ação teria ocorrido por motivos legítimos independentes.

A Definição de Risco Catastrófico

O centro de gravidade da SB 53 é sua definição de "risco catastrófico". O estatuto define-o como um risco previsível e material de que um modelo de fronteira contribua materialmente para a morte ou ferimento grave de mais de 50 pessoas, ou para mais de US$ 1 bilhão em danos ou perda de propriedade, através de um dos três mecanismos causais:

Assistência com armas. Contribuição material para a criação, implantação ou uso de uma arma química, biológica, radiológica ou nuclear, ou para uma ciberarma que cause danos comparáveis.
Conduta prejudicial descontrolada. Conduta do modelo com supervisão humana limitada que, se cometida por um humano, constituiria um crime grave que exige intenção.
Perda de controle. Perda de controle do desenvolvedor sobre o modelo, de modo que ele se envolva em conduta materialmente prejudicial.

A definição estabelece exclusões importantes. Riscos baseados em informações que já estão publicamente disponíveis, danos decorrentes de atividade federal lícita e danos em que a contribuição do modelo não é material, todos ficam fora do escopo. Essa exclusão é o que evita que riscos de aplicações cotidianas — viés na triagem de currículos, conselhos médicos alucinados, violação de direitos autorais — acionem o regime de risco catastrófico. Esses danos são reais, mas são abordados por outras leis, não pela SB 53.

Penalidades Civis e Fiscalização

O Procurador-Geral da Califórnia detém autoridade de fiscalização exclusiva. As penalidades civis podem chegar a US$ 1 milhão por violação, escalonadas pela gravidade da conduta. Não há direito de ação privada sob a própria SB 53, embora as disposições de retaliação contra denunciantes sejam independentemente exequíveis por meio de ações civis movidas por funcionários prejudicados.

Na prática, o risco de fiscalização concentra-se em três áreas:

Manipulação de limites. Empresas que estruturam ciclos de treinamento para permanecerem logo abaixo de 10^26 FLOPs enquanto entregam capacidades claramente de classe de fronteira enfrentarão escrutínio. A linguagem de computação cumulativa do estatuto torna essa estratégia frágil.
Lacunas na estrutura. Uma estrutura que lista políticas sem evidências de implementação será mais fácil de atacar do que uma que vincule cada compromisso a artefatos operacionais, proprietários nomeados e registros de auditoria.
Atrasos na notificação de incidentes. Perder o prazo de 15 dias, ou o prazo de 24 horas para ameaças iminentes, é o tipo de violação clara e documentável que os reguladores historicamente processam de forma agressiva.

Elaborando um Plano de Implementação de 90 Dias

Para uma organização que ainda não estabeleceu um programa para a SB 53, a seguinte sequência funciona bem:

Dias 1 a 30: Análise de escopo e lacunas.

Catalogue cada modelo de fundação treinado, ajustado (fine-tuned), mesclado ou substancialmente modificado, com a computação cumulativa estimada para cada um.
Determine se a receita consolidada (incluindo todas as afiliadas) excedeu US$ 500 milhões no ano civil anterior.
Forme um Grupo de Trabalho de Segurança e Conformidade de IA multifuncional com membros de engenharia, segurança, jurídico, comunicações e RH.
Mapeie as práticas atuais em relação ao NIST AI RMF 1.0 e ISO/IEC 42001 para identificar lacunas.

Dias 31 a 60: Elaboração e governança.

Elabore a estrutura de IA de fronteira como um documento com controle de versão e publicamente publicável.
Construa a metodologia de avaliação de risco catastrófico, incluindo avaliações de capacidade, modelagem de ameaças e os critérios para declarar um modelo como capaz de fronteira em um domínio perigoso.
Estabeleça os controles de cibersegurança para pesos não publicados, com registros de acesso documentados e monitoramento de ameaças internas.
Estabeleça o canal de denúncia interna anônima e o fluxo de trabalho para atualizações mensais de status e reuniões trimestrais do conselho.

Dias 61 a 90: Prontidão operacional.

Realize um exercício simulado (tabletop) de resposta a incidentes que simule a descoberta de um incidente de roubo de pesos e a materialização de um risco catastrófico, praticando então os fluxos de trabalho de notificação de 15 dias e 24 horas.
Treine os funcionários abrangidos sobre os direitos dos denunciantes e o canal anônimo.
Publique o relatório de transparência para qualquer modelo no pipeline de implantação, com uma referência cruzada à estrutura de IA de fronteira.
Agende os envios trimestrais do resumo de riscos catastróficos ao Cal OES e a revisão anual da estrutura.

Coordenando com Outros Regimes de IA e Privacidade

A SB 53 não atua isolada. As equipes de conformidade devem mapeá-la em relação a:

O NIST AI Risk Management Framework, ao qual o estatuto se refere explicitamente e que fornece grande parte do arcabouço substantivo de governança.
O nível de IA de uso geral do AI Act da UE, onde a sobreposição de documentação é substancial e uma única estrutura interna harmonizada pode satisfazer ambos.
A Lei de IA do Colorado e a Lei de Governança Responsável de IA do Texas, que regulam as obrigações dos implantadores para IA de tomada de decisão de alto risco e podem se aplicar aos seus clientes a jusante.
A Lei de Privacidade do Consumidor da Califórnia (CCPA) e as próximas regras da Agência de Proteção de Privacidade da Califórnia sobre tecnologia de tomada de decisão automatizada, que se cruzam com a implantação de modelos, mas operam independentemente da SB 53.
Os compromissos voluntários do Instituto de Segurança de IA federal e qualquer legislação de preempção federal futura, que poderia mudar a base de conformidade.

Registros de conformidade precisos e trilhas de auditoria claras são essenciais em todos esses regimes — e a mesma disciplina de documentação que sustenta os relatórios financeiros sustenta os relatórios de governança de IA. Estruturas de IA de fronteira, avaliações de risco catastrófico, registros de incidentes e registros de investigação de denunciantes devem ser retidos por pelo menos cinco anos e armazenados de forma a sobreviver à rotatividade de executivos e reestruturações corporativas.

Mantenha seus Registros Financeiros e de Conformidade Prontos para Auditoria

Esteja você publicando uma estrutura de IA de fronteira, agendando envios trimestrais ao Cal OES ou se preparando para um inquérito do Procurador-Geral, a disciplina subjacente é a mesma: registros claros, com controle de versão e auditáveis. A mesma abordagem de texto simples e controle de versão que as equipes nativas de IA usam para suas bases de código funciona perfeitamente para seus livros contábeis. O Beancount.io oferece contabilidade em texto simples que proporciona total transparência e controle sobre seus dados financeiros — sem caixas-pretas, sem dependência de fornecedor e uma trilha de auditoria limpa que se combina naturalmente com a disciplina de governança que os reguladores agora esperam. Comece gratuitamente e veja por que desenvolvedores e profissionais de finanças estão mudando para a contabilidade em texto simples.