O AI Act é segurança de produto, não proteção de dado

Os cursos de nível Sênior "Conformidade: GDPR a fundo", "Conformidade: LGPD a fundo" e "Conformidade: HIPAA a fundo" regulam a mesma coisa por ângulos diferentes. Cada um mira uma categoria de dado (dado pessoal, dado de saúde) e, no caso da HIPAA, uma categoria de entidade. O AI Act europeu não faz nenhuma das duas coisas. Ele se parece mais com regulação de segurança de produto, do tipo que rege dispositivos médicos ou brinquedos, apontada para software em vez de hardware. Leve o modelo mental da GDPR para o AI Act e você pula as duas perguntas que importam.

Duas perguntas, não uma

O AI Act pergunta qual é a finalidade pretendida deste sistema de IA e que papel você tem em relação a ele. Nenhuma das duas é "de quem é esse dado". Um sistema pode não processar nenhum dado pessoal e ainda ser high-risk pelo AI Act. Um modelo que corrige provas, ou que controla o corte de segurança de um robô de fábrica, não toca em nada parecido com PHI ou com dados da GDPR. Mesmo assim, os dois estão dentro dessa regulação. Ao contrário, um sistema pode processar uma quantidade enorme de dados pessoais e ficar no nível de risco mais baixo do AI Act. Um motor de recomendação que escolhe o que mostrar a um usuário logado é um exemplo. Recomendar conteúdo não é uma das finalidades que o AI Act trata como de alto risco.

Esse é o reenquadramento central do resto do curso. O AI Act classifica sistemas pelo que eles fazem e depois atribui obrigações por quem você é em relação a esse sistema. O dado que passa por ele não decide nenhuma das duas coisas.

Níveis de risco, numa passada

O curso de nível Sênior "Conformidade: o panorama regulatório" apresentou esse formato numa visão geral. Ele preferiu ensinar o padrão do cronograma escalonado em vez de uma tabela de datas. Esse cronograma já foi revisado uma vez desde a adoção do AI Act, por um regulamento de alteração em 2026. Este curso vai um nível mais fundo nos níveis e nos papéis, e as próximas lições constroem as obrigações de engenharia em cima deles.

O AI Act classifica um sistema de IA em um de quatro níveis:

• Risco inaceitável: uma lista curta de práticas proibidas, banidas de vez. Esses sistemas não são regulados nem cercados de papelada. Eles não podem operar no mercado europeu.
• Alto risco (high-risk): o regime de conformidade mais pesado do AI Act. Ele cobre um sistema cuja finalidade está numa lista de casos de uso de alto impacto, ou que é componente de segurança de um produto já regulado em outra norma. Pense na IA dentro de um dispositivo médico ou de um elevador.
• Risco limitado, ou obrigações de transparência: um sistema não precisa ser de alto impacto para dever uma divulgação às pessoas. Chatbots e sistemas que geram áudio, imagem, vídeo ou texto sintético têm deveres específicos de transparência, mesmo quando nada mais neles é high-risk.
• Risco mínimo: todo o resto, sem obrigações específicas do AI Act. É o nível em que cai a maioria das funcionalidades de um app Rails, e dizer isso com clareza importa tanto quanto explicar os outros níveis. Um filtro de spam, um ajuste interno de ranqueamento de busca ou uma heurística de triagem de tickets não vira projeto de conformidade só por usar um modelo.

A lição 2 aprofunda o que coloca um sistema em cada um dos dois níveis mais altos. Vale acertar, porque errar em qualquer direção custa caro. Tratar uma funcionalidade de risco mínimo como high-risk queima meses de engenharia em controles de que ninguém precisava. Tratar um sistema high-risk como de risco mínimo é uma violação regulatória com multa de verdade por trás.

Papéis, numa passada

O segundo eixo é o papel, e o AI Act define vários. Um provider (fornecedor) coloca um sistema no mercado ou o põe em serviço com o próprio nome. Um deployer (implantador) usa um sistema sob a própria autoridade, num contexto profissional. Importers e distributors ficam na cadeia de fornecimento entre os dois. A maioria dos times Rails que leem este curso implanta funcionalidades de IA construídas sobre o modelo de outra empresa. Eles não são providers de um modelo de fundação. Mas a lição 3 cobre uma regra que inverte essa suposição mais vezes do que os times esperam. Um deployer pode virar provider de um sistema high-risk ao modificá-lo de forma substancial ou ao colocar nele o próprio nome ou marca. "A gente é só o cliente" não é uma posição legal permanente.

GPAI: um terceiro eixo para quem constrói ou ajusta modelos

Ao lado dos níveis de risco e dos papéis existe um conjunto separado de obrigações para modelos de IA de propósito geral (GPAI). São os modelos de fundação cada vez mais plugados direto em apps Rails. A lição 4 cobre o que um provider desse tipo de modelo deve e o nível mais pesado para modelos com risco sistêmico. Ela também cobre a parte que alcança times de aplicação comuns: como essas obrigações descem para quem constrói em cima de um desses modelos.

O que este curso cobre

1. Esta lição: por que o AI Act tem formato de segurança de produto, com níveis de risco e papéis como as duas perguntas que governam tudo.
2. Níveis de risco a fundo: o que coloca um sistema no nível high-risk, pelos casos de uso do Anexo III e pela rota de componente de segurança, e o que fica em risco mínimo.
3. Papéis e a armadilha do deployer que vira provider: provider, deployer, importer e distributor, e o erro mais caro do AI Act, o "achamos que éramos só o cliente".
4. Obrigações de GPAI: o que um provider de modelo deve, o nível de risco sistêmico e como esses deveres chegam a um time que constrói em cima do modelo.
5. Obrigações high-risk como trabalho de engenharia: gestão de risco, governança de dados, documentação, log e supervisão. Elas se ligam aos artefatos do AIMS da ISO 42001, do curso de nível Sênior "Sistema de gestão de IA: ISO 42001".
6. Obrigações de transparência, avaliação de conformidade e fiscalização: os deveres de divulgação que alcançam produtos comuns, mais a marcação CE, a base de dados europeia e quem fiscaliza tudo isso.
7. Juntando tudo: como o AI Act e a GDPR se aplicam ao mesmo sistema por motivos diferentes, e um checklist com formato de Rails.

Um aviso antes de qualquer coisa: nada neste curso é aconselhamento jurídico. Decisões de aplicabilidade e de conformidade com o AI Act cabem a um advogado que conheça o seu sistema e o seu papel em relação a ele. Este curso ensina o formato de engenharia da lei o bastante para você ter essa conversa em vez de adivinhar.