
Neste artigo (4)
Auditorias de IA em Illinois a partir de 2028: análise do primeiro estado dos EUA
Principais conclusões
- Incorpore evidências de auditoria ao desenvolvimento do modelo antes do lançamento, incluindo logs, avaliações de risco, fluxos de trabalho de incidentes e aprovações de governança.
- Trate 1º de janeiro de 2028 como um prazo de produto, não apenas como uma data no calendário jurídico.
- Se você depende de fornecedores de modelos de fronteira, atualize os contratos para exigir documentação, notificação de incidentes e cooperação em auditorias.
Desenvolvedores de fronteira abrangidos devem se preparar para uma verificação externa anual, não para mais uma página de transparência vistosa.
Desenvolvedores de fronteira abrangidos devem se preparar para uma verificação externa anual, não para mais uma página de transparência sofisticada.
A entrada no calendário já não é um painel de conferência. É uma dependência de lançamento. Illinois levou a conformidade em segurança de IA do território familiar da documentação interna para o mundo menos tolerante das auditorias independentes. Isso importa porque auditabilidade não é algo que uma equipe simplesmente espalha sobre um modelo depois do lançamento. Logs, registros de avaliação, fluxos de trabalho de incidentes, aprovações de governança e evidências de fornecedores precisam existir antes que um terceiro possa verificá-los. A pergunta prática não é se os reguladores gostam de estruturas de segurança. É se o seu processo de produto consegue provar que uma delas funcionou quando era necessário.
O que Illinois realmente promulgou
Segundo a Skadden, o governador de Illinois, JB Pritzker, assinou a Artificial Intelligence Safety Measures Act em 6 de julho de 2026, tornando Illinois o terceiro estado, depois da Califórnia e de Nova York, a impor obrigações de transparência, segurança e reporte a grandes desenvolvedores de IA. A Skadden diz que Illinois vai além ao exigir que os desenvolvedores contratem um terceiro independente para auditar a conformidade anualmente. A DLA Piper descreve Illinois de forma semelhante como o primeiro estado a exigir auditorias de terceiros de modelos de IA, enquanto a Governing havia informado anteriormente que o projeto de lei exigiria que grandes desenvolvedores de IA divulgassem riscos, reportassem incidentes de segurança e se submetessem a auditorias independentes anuais.
A versão de manchete é simples: Illinois é o primeiro em verificação externa. A versão jurídica é mais estreita e mais útil: grandes desenvolvedores de modelos de fronteira abrangidos enfrentam auditorias anuais independentes de conformidade, além de uma obrigação de estrutura pública que começa em 1º de janeiro de 2028. Se o seu memorando de conformidade diz apenas que o model card está pronto, ele está perdendo o ponto.
Quem está na faixa da conformidade
A Skadden diz que a lei se concentra em uma estrutura de IA de fronteira e se aplica a um grande desenvolvedor de fronteira. A partir de 1º de janeiro de 2028, esse desenvolvedor deve escrever, implementar, cumprir e publicar de forma destacada em seu site uma estrutura que descreva sua abordagem para a gestão de riscos catastróficos. A Skadden também diz que a estrutura deve ser revisada pelo menos anualmente, e qualquer modificação material deve ser publicada com uma justificativa em até 30 dias. A Crowell & Moring enquadra a mesma lei como obrigações de transparência e segurança para sistemas de IA de fronteira, e diz que Illinois se juntou à Califórnia e a Nova York na adoção de padrões para os sistemas de IA mais poderosos.
Esse é um marcador de limite útil para construtores que não treinam modelos de fronteira, mas dependem deles. Você pode não ser o alvo estatutário direto, mas compras tem memória longa e questionário curto.
O que muda para os construtores
A Cooley descreve a AISMA como uma passagem da transparência para a verificação. Sua análise contrasta estruturas anteriores, incluindo a TFAIA da Califórnia, a RAISE Act alterada de Nova York e partes da Lei de IA da UE, que geralmente exigem que os desenvolvedores avaliem e divulguem como identificam, avaliam e gerenciam riscos de IA. Illinois acrescenta a parte desconfortável: um terceiro independente precisa verificar se o processo realmente funciona como descrito.
Traduzido para o trabalho de produto, isso significa que a evidência de conformidade precisa ser projetada dentro do sistema. A checklist de lançamento precisa ter responsáveis por avaliações de risco, cards de modelo ou de sistema, caminhos de reporte de incidentes, atualizações da estrutura pública e cooperação com auditorias. Um contrato com fornecedor que envolva um modelo de fronteira deve pedir entrega de documentação, aviso de incidentes e suporte a auditoria, não porque todo cliente seja diretamente regulado, mas porque deveres regulatórios viajam pelo processo de compras.
A DLA Piper observa que a AISMA se parece com as leis da Califórnia e de Nova York nas obrigações de transparência, com a exceção importante das disposições de auditoria. Essa exceção é onde as equipes de produto devem dedicar tempo. Uma estrutura pública é um documento. Uma auditoria é um documento mais provas, carimbos de data e hora, pessoas, controles e uma ou outra reunião desconfortável.
Onde as jurisdições agora divergem
A comparação da Cooley é o problema que os construtores vão reconhecer: Califórnia, Nova York e partes da Lei de IA da UE enfatizam avaliação, divulgação, estruturas de governança, relatórios de transparência, model cards, avaliações de risco e reporte de incidentes. Illinois mantém boa parte dessa arquitetura e, então, acrescenta verificação independente.
A Crowell & Moring diz que, mesmo sem ação federal, Califórnia, Nova York e Illinois criaram o que é essencialmente uma estrutura nacional para segurança e transparência em IA. Isso não significa que as regras sejam idênticas. Significa que um grande desenvolvedor que atende clientes dos EUA pode ter que satisfazer a expectativa operacional mais rigorosa, mesmo quando outro estado se contenta com controles autorreportados.
O centro de gravidade da conformidade está se movendo do que um desenvolvedor diz que faz para o que um auditor consegue verificar que ele fez. Para leitores que constroem com sistemas de fronteira, o próximo passo útil é chato e imediato: mapear quais evidências seu ciclo de vida de desenvolvimento atual já cria, quais evidências desaparecem em conversas de chat e quais evidências um terceiro poderia realmente inspecionar. Até 2028, as empresas interessantes não serão aquelas dizendo que recebem bem as regras. Serão aquelas cujo processo de lançamento já deixa uma trilha de auditoria.