Governança de IA: marcos, programas e carreiras.

O AI Act, Regulamento (UE) 2024/1689, é a primeira lei horizontal abrangente sobre inteligência artificial. Ele alcança organizações dentro e fora da União Europeia quando colocam sistemas de IA no mercado europeu ou quando o resultado dos seus sistemas é usado na UE, o que inclui muitas empresas brasileiras. As obrigações se aplicam em fases, e o calendário de parte delas, sobretudo para sistemas de alto risco, foi alterado em 2026 por um pacote de mudanças pontuais conhecido como Digital Omnibus. Como essas datas mudaram, este guia não as repete: confira sempre o texto consolidado mais recente no EUR-Lex antes de planejar com base num prazo.

A UE não está sozinha. A ANPD e as autoridades europeias já aplicam a LGPD e o GDPR à IA, estados norte-americanos estão aprovando leis específicas e o Brasil discute um projeto de lei próprio para IA. A direção comum é clara: obrigações proporcionais ao risco, transparência para as pessoas afetadas, supervisão humana e responsabilização documentada.

Reguladores são só um dos públicos. Clientes corporativos fazem cada vez mais perguntas detalhadas sobre IA antes de assinar: quais modelos são usados, para onde vão os dados, se os dados do cliente servem para treinar modelos, como as saídas são testadas e quem é avisado quando algo dá errado. O fornecedor que responde com evidências fecha negócios; o que responde com uma página de marketing os perde ou aceita cláusulas desfavoráveis.

Antes da IA generativa, a maioria das organizações tinha alguns poucos modelos construídos por especialistas. Hoje, quase todo colaborador pode usar um chatbot, um assistente de código ou um recurso de IA embutido no software de escritório. Isso leva o risco de IA do time de ciência de dados para a organização inteira: dados confidenciais colados em prompts, fatos alucinados em documentos de clientes, dúvidas de direito autoral sobre conteúdo gerado e novas superfícies de ataque, como a injeção de prompt. A governança precisa chegar a quem nunca vai treinar um modelo, e é por isso que o letramento em IA virou um controle de governança por si só.

O regulamento não regula a "IA" como tecnologia. Ele regula usos e gradua as obrigações conforme o risco que cada uso cria para a saúde, a segurança e os direitos fundamentais. O resultado costuma ser descrito como quatro níveis, mais um regime separado para modelos de uso geral:

O nível depende da finalidade pretendida, e não do modelo: o mesmo modelo de linguagem pode estar num assistente de redação de risco mínimo e numa triagem de currículos de alto risco. Por isso um inventário de IA com classificação de risco por caso de uso é a base da conformidade.

As obrigações se prendem a papéis, então a primeira pergunta jurídica sobre qualquer sistema é "qual é o nosso papel?". O regulamento define vários operadores:

• Fornecedor (provider): desenvolve um sistema de IA ou um modelo de uso geral, ou manda desenvolvê-lo, e o coloca no mercado ou em serviço com o próprio nome ou marca. Carrega a maior parte das obrigações de alto risco. Veja fornecedor.
• Implantador (deployer): usa um sistema de IA sob sua autoridade numa atividade profissional. Um banco que usa um modelo de crédito de terceiros é implantador. Veja implantador.
• Importador e distribuidor: trazem sistemas de fora da UE ou os disponibilizam no mercado, com deveres de verificação.
• Mandatário: pessoa estabelecida na UE nomeada por um fornecedor de fora da UE.
• Fabricante de produto: coloca no mercado um produto regulado que tem um sistema de IA como componente de segurança.

Os papéis podem mudar. Um implantador que coloca o próprio nome num sistema de alto risco, faz nele uma modificação substancial ou muda a finalidade de um sistema a ponto de torná-lo de alto risco pode ser tratado como fornecedor, com todas as obrigações correspondentes. Áreas de compras e de produto precisam saber disso antes de personalizar a ferramenta de um fornecedor para um uso sensível.

O artigo 5 lista as práticas de IA proibidas, porque o risco que criam para os direitos fundamentais é considerado inaceitável. Em resumo, ele proíbe sistemas de IA que:

• usem técnicas subliminares, manipuladoras ou enganosas que distorçam de forma relevante o comportamento e causem, ou possam causar, dano significativo;
• explorem vulnerabilidades ligadas à idade, à deficiência ou a uma situação social ou econômica específica, com o mesmo efeito;
• avaliem ou classifiquem pessoas pelo comportamento social ou por características pessoais de modo a gerar tratamento prejudicial injustificado ou desproporcional (pontuação social);
• avaliem o risco de uma pessoa cometer crime com base apenas em perfilamento ou traços de personalidade;
• criem ou ampliem bases de reconhecimento facial por raspagem não direcionada de imagens da internet ou de câmeras de vigilância;
• inferam emoções no local de trabalho ou em instituições de ensino, salvo por razões médicas ou de segurança;
• categorizem pessoas por dados biométricos para inferir atributos sensíveis, como raça, opinião política, filiação sindical, crença religiosa ou orientação sexual, com exceções limitadas;
• façam identificação biométrica remota em tempo real em espaços acessíveis ao público para fins de aplicação da lei, salvo em situações estritamente definidas e autorizadas.

Um sistema é de alto risco em duas situações: quando é componente de segurança de um produto, ou o próprio produto, abrangido pela legislação de harmonização da UE listada no Anexo I (máquinas, dispositivos médicos, brinquedos, veículos e outros) que exige avaliação da conformidade por terceiro; ou quando se enquadra numa das áreas de uso do Anexo III. Essas áreas são biometria, infraestrutura crítica, educação e formação profissional, emprego e gestão de trabalhadores, acesso a serviços essenciais públicos e privados (incluindo análise de crédito e certos seguros), aplicação da lei, migração e controle de fronteiras, e administração da justiça e processos democráticos.

Um sistema do Anexo III pode escapar do rótulo de alto risco se não criar risco significativo, por exemplo porque executa apenas uma tarefa processual restrita ou melhora o resultado de uma atividade humana já concluída. O fornecedor precisa documentar essa avaliação, e sistemas que fazem perfilamento de pessoas físicas continuam sendo de alto risco. Os fornecedores de sistemas de alto risco devem, entre outras coisas:

• manter um sistema de gestão de riscos ao longo do ciclo de vida (artigo 9);
• aplicar governança aos dados de treino, validação e teste, inclusive examinando possíveis vieses (artigo 10);
• elaborar documentação técnica (artigo 11 e Anexo IV) e permitir o registro automático de eventos (artigo 12);
• fornecer instruções de uso claras aos implantadores (artigo 13);
• projetar o sistema para uma supervisão humana efetiva (artigo 14);
• alcançar exatidão, robustez e cibersegurança adequadas (artigo 15);
• operar um sistema de gestão da qualidade (artigo 17);
• concluir a avaliação da conformidade, emitir a declaração UE de conformidade, apor a marcação CE e registrar o sistema na base de dados da UE;
• monitorar o sistema depois de colocado no mercado e notificar incidentes graves.

Os implantadores têm uma lista menor, mas real (artigo 26): usar o sistema conforme as instruções, atribuir a supervisão humana a pessoas com competência, formação e autoridade, garantir que os dados de entrada sob seu controle sejam pertinentes, monitorar o funcionamento e comunicar riscos, guardar os registros sob seu controle, informar os trabalhadores e seus representantes antes de usar IA de alto risco no trabalho e informar as pessoas quando um sistema de alto risco toma ou apoia decisões sobre elas. Órgãos públicos, entidades privadas que prestam serviços públicos e implantadores de certos sistemas de crédito e seguros também devem fazer uma avaliação de impacto sobre direitos fundamentais (artigo 27). As pessoas afetadas ganham direito a explicação de certas decisões (artigo 86).

O capítulo V regula os modelos de IA de uso geral: modelos treinados com grandes volumes de dados, capazes de executar com competência uma ampla gama de tarefas e de ser integrados em muitos sistemas. Seus fornecedores devem manter documentação técnica, dar aos fornecedores a jusante as informações de que precisam para entender o modelo e cumprir as próprias obrigações, adotar uma política de cumprimento do direito autoral da UE e publicar um resumo suficientemente detalhado do conteúdo usado no treino, segundo modelo do AI Office.

Modelos classificados como de risco sistêmico, condição presumida acima de um limiar de capacidade computacional de treino que a Comissão pode atualizar, têm deveres adicionais: avaliação do modelo no estado da arte, incluindo testes adversariais (red teaming), avaliação e mitigação de riscos sistêmicos, notificação de incidentes graves e cibersegurança adequada. Um Código de Práticas voluntário para IA de uso geral oferece uma forma de demonstrar conformidade. Para quem usa esses modelos sem construí-los, a consequência é a jusante: peça a documentação que os fornecedores agora são obrigados a entregar.

O artigo 50 vale em qualquer nível de risco. Os fornecedores devem projetar os sistemas que interagem com pessoas de modo que elas saibam que estão lidando com IA, salvo quando isso for evidente pelo contexto, e devem marcar áudio, imagem, vídeo e texto sintéticos de forma legível por máquina. Implantadores de sistemas de reconhecimento de emoções ou de categorização biométrica devem informar as pessoas expostas a eles. Quem gera ou manipula deepfakes deve revelar que o conteúdo é artificial, e textos gerados por IA publicados para informar o público sobre assuntos de interesse público devem ser identificados, salvo se passarem por revisão humana e alguém tiver responsabilidade editorial.

O artigo 4 pede que fornecedores e implantadores adotem medidas para garantir, na medida do possível, um nível suficiente de letramento em IA do seu pessoal e de outras pessoas que lidam com sistemas de IA em seu nome, considerando conhecimento técnico, experiência, educação, formação e o contexto de uso. Como o regulamento foi alterado em 2026, confira a redação atual deste artigo no texto consolidado. De todo modo, a lógica de governança não muda: ninguém supervisiona, questiona ou usa com segurança um sistema que não entende.

O regulamento não exige nenhum certificado específico. O que a organização precisa é de evidência de que a formação é proporcional aos papéis e aos riscos: quem foi treinado, em quê, quando e como o entendimento foi verificado. Veja a seção sobre letramento em IA mais abaixo.

A fiscalização é compartilhada. O AI Office, dentro da Comissão Europeia, supervisiona os modelos de uso geral; as autoridades nacionais de fiscalização do mercado supervisionam os sistemas de IA, com coordenação do Comitê Europeu para a IA. Alguns países criaram órgãos dedicados, como a AESIA na Espanha, e os Estados-Membros devem oferecer ambientes de testagem regulatória (sandboxes) de IA.

As sanções são escalonadas. As multas mais altas, para práticas proibidas, podem chegar a 35 milhões de euros ou 7% do faturamento anual mundial, o que for maior, com tetos menores para outras infrações e tratamento proporcional para PMEs. A aplicação é em fases: proibições, letramento em IA e regras de modelos de uso geral começaram antes da maior parte das obrigações de alto risco, e o calendário de alto risco foi adiado pelas alterações de 2026. Confira no EUR-Lex o texto consolidado mais recente para saber as datas que se aplicam a você.

Um sistema de gestão de IA aplica à IA o conhecido ciclo planejar, fazer, verificar e agir. A ISO/IEC 42001 usa a estrutura harmonizada comum à ISO 27001, à ISO 9001 e a outras normas de sistema de gestão, então quem já opera uma delas pode integrar o AIMS em vez de começar do zero. As cláusulas principais pedem que você:

• entenda o contexto da organização, o seu papel em relação à IA (desenvolvedora, fornecedora, usuária e assim por diante) e as necessidades das partes interessadas, e defina o escopo do AIMS (cláusula 4);
• garanta o compromisso da liderança, uma política de IA e papéis e responsabilidades claros (cláusula 5);
• planeje ações para riscos e oportunidades, incluindo avaliação de riscos de IA, tratamento de riscos de IA e avaliação de impacto do sistema de IA, e defina objetivos de IA (cláusula 6);
• proveja recursos, competência, conscientização, comunicação e informação documentada (cláusula 7);
• opere os processos e controles planejados (cláusula 8);
• monitore, meça, faça auditoria interna e análise crítica pela direção (cláusula 9);
• corrija não conformidades e melhore continuamente (cláusula 10).

O Anexo A lista objetivos de controle e controles de referência agrupados em temas: políticas relacionadas à IA; organização interna; recursos para sistemas de IA; avaliação dos impactos dos sistemas de IA; ciclo de vida do sistema de IA; dados para sistemas de IA; informação para partes interessadas; uso de sistemas de IA; e relações com terceiros e clientes. O Anexo B dá orientação de implementação para cada controle, o Anexo C lista possíveis objetivos e fontes de risco relacionados à IA e o Anexo D trata do uso em diferentes domínios e setores.

Como na ISO 27001, não se aplicam todos os controles às cegas. O tratamento de riscos determina quais controles são necessários, e o resultado fica registrado na Declaração de Aplicabilidade (SoA): cada controle do Anexo A, se foi incluído, por quê e se está implementado, além dos controles adicionais que você acrescentou. Auditores leem a SoA como a ponte entre os seus riscos e os seus controles, então ela deve ser rastreável até a avaliação de riscos, e não uma cópia do anexo com "sim" em todas as linhas.

Esta distinção gera muita confusão. A certificação ISO/IEC 42001 é concedida ao sistema de gestão de uma organização por um organismo de certificação, de preferência acreditado para esse esquema; a ISO/IEC 42006 define requisitos para organismos que auditam e certificam sistemas de gestão de IA. O certificado diz que o AIMS da organização, dentro de um escopo definido, está conforme a norma.

A certificação de pessoas é outra coisa: atesta que um indivíduo demonstrou conhecimento ou competência especificados, em geral por exame. A DPCert certifica pessoas. Nossos exames cobrem a ISO/IEC 42001 junto com o AI Act, o NIST AI RMF e a legislação de proteção de dados, e nosso esquema foi desenhado com referência à ISO/IEC 17024, a norma para organismos que certificam pessoas. Uma credencial DPCert não é um certificado ISO e não certifica nenhuma organização; ela é evidência do que o titular sabe.

• ISO/IEC 22989: conceitos e terminologia de IA, útil para alinhar o vocabulário entre jurídico, riscos e engenharia.
• ISO/IEC 23894: orientação para gestão de riscos de IA, adaptando a ISO 31000 à IA.
• ISO/IEC 42005: orientação para avaliação de impacto de sistemas de IA.
• ISO/IEC 42006: requisitos para organismos que auditam e certificam sistemas de gestão de IA.

As normas europeias harmonizadas que apoiam o AI Act estão sendo elaboradas à parte pelo CEN e pelo CENELEC. Quando forem publicadas e citadas no Jornal Oficial, segui-las dará presunção de conformidade com os requisitos correspondentes; a ISO/IEC 42001 sozinha não dá.

Em julho de 2024 o NIST publicou o NIST AI 600-1, o Perfil de IA Generativa. Ele identifica riscos exclusivos ou ampliados pela IA generativa, entre eles confabulação (o termo do NIST para alucinação), integridade da informação, segurança da informação, privacidade de dados, viés nocivo e homogeneização, propriedade intelectual, conteúdo perigoso ou de ódio, configuração humano-IA, cadeia de valor e integração de componentes, e impactos ambientais. Para cada um, sugere ações ligadas às quatro funções. Se a sua principal exposição são colaboradores e produtos que usam grandes modelos de linguagem, este perfil é um bom ponto de partida.

Na LGPD, o relatório de impacto à proteção de dados pessoais (RIPD) documenta os processos de tratamento que podem gerar riscos às liberdades civis e aos direitos fundamentais, e a ANPD pode exigi-lo. No GDPR, o artigo 35 exige uma DPIA quando o tratamento pode resultar em alto risco para os direitos das pessoas, e o uso de novas tecnologias, a avaliação sistemática de aspectos pessoais e o tratamento de dados sensíveis em larga escala são gatilhos típicos. Muitos projetos de IA se enquadram. No AI Act, certos implantadores também devem fazer uma avaliação de impacto sobre direitos fundamentais. Os três se sobrepõem bastante; um bom programa os conduz como uma avaliação coordenada, com evidências compartilhadas.

O artigo 20 da LGPD garante ao titular o direito de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, e de obter informações sobre os critérios e procedimentos usados. No GDPR, o artigo 22 dá às pessoas o direito de não ficar sujeitas a decisão baseada unicamente em tratamento automatizado, incluindo perfilamento, que produza efeitos jurídicos ou similarmente significativos, com exceções acompanhadas de salvaguardas como intervenção humana e direito de contestar; os artigos 13 a 15 exigem informação significativa sobre a lógica envolvida. Essas regras moldam o desenho das decisões automatizadas: onde a pessoa entra no circuito, o que ela de fato pode mudar e que explicação o afetado recebe.

Treinar ou ajustar modelos com dados pessoais levanta perguntas que a área de privacidade precisa responder cedo: qual base legal se aplica (muitas vezes o legítimo interesse, que exige teste de balanceamento documentado), se a finalidade original da coleta é compatível com o treino, como os titulares são informados, como a minimização de dados e a retenção se aplicam e como direitos como acesso, oposição e eliminação funcionam quando o dado está incorporado a um modelo. O Comitê Europeu de Proteção de Dados (EDPB) tratou de várias dessas questões no Parecer 28/2024 sobre modelos de IA, incluindo quando um modelo pode ser considerado anônimo e as consequências de tratamento ilícito no desenvolvimento.

Para quem só usa IA de terceiros, as mesmas perguntas vão para o contrato: se o fornecedor usa seus dados para treinar modelos, onde os dados são tratados, quais suboperadores participam e como as transferências internacionais estão cobertas. Essas cláusulas já são parte padrão da contratação de IA.

Comece com uma carta curta aprovada pela alta liderança: por que o programa existe, seu escopo (quais entidades, quais tipos de IA), quem é o dono e como ele se reporta ao conselho. Nomeie um executivo responsável e um líder do programa, e decida se precisa de um comitê multidisciplinar de IA. Escreva uma matriz RACI simples que cubra jurídico, privacidade (incluindo o encarregado), segurança, riscos, ciência de dados, engenharia, compras, RH e os donos de negócio de cada caso de uso. Muitas organizações alinham isso ao modelo das três linhas: donos de negócio na primeira linha, riscos e conformidade na segunda, auditoria interna na terceira.

Não se governa o que não se vê. Monte um inventário de IA que registre, para cada sistema ou caso de uso: finalidade, dono, usuários e pessoas afetadas, modelo e fornecedor, dados usados, decisões que influencia, o seu papel jurídico (fornecedor ou implantador; controlador ou operador na LGPD), a classificação de risco e a situação das avaliações exigidas. Inclua recursos de IA dentro de ferramentas SaaS e o uso de serviços públicos de IA generativa pelos colaboradores, e não só os modelos internos. Dê a cada registro um dono e uma data de revisão para o inventário continuar atual.

Defina um esquema que ligue cada caso de uso a um nível de risco e à revisão que ele exige. Combine gatilhos legais (níveis do AI Act, decisões automatizadas na LGPD e no GDPR, regras setoriais) com critérios da organização (impacto nas pessoas, escala, autonomia, reversibilidade, exposição de reputação). Mantenha-o curto o bastante para que um dono de negócio o preencha em quinze minutos. O resultado define o caminho: usos de baixo risco passam por uma checagem leve, usos de alto risco recebem avaliação de impacto completa, plano de testes e aprovação formal, e usos proibidos são interrompidos.

Um conjunto pequeno de políticas cobre a maior parte das necessidades:

• uma política de IA que declare princípios, escopo, papéis e o processo de revisão;
• uma política de uso aceitável para colaboradores que usam IA generativa, dizendo quais ferramentas estão aprovadas, quais dados nunca podem ser inseridos e como as saídas devem ser conferidas;
• um padrão de contratação de IA, com perguntas de diligência e cláusulas contratuais;
• um padrão de desenvolvimento de modelos e sistemas, com documentação como model cards, testes e critérios de liberação;
• um procedimento de incidentes de IA ligado aos processos existentes de incidentes de segurança e de privacidade.

Crie uma etapa de aprovação antes da implantação, proporcional ao risco. Nos casos de alto risco, ela deve exigir uma avaliação de impacto (combinando privacidade, direitos fundamentais e riscos próprios da IA), um plano de testes com resultados contra limites acordados, um desenho de supervisão humana, um plano de transparência para as pessoas afetadas e aprovação nominal. Registre a decisão e as suas condições. A etapa também deve valer para mudanças relevantes, como nova versão do modelo, nova fonte de dados ou nova finalidade.

Depois da implantação, monitore desempenho, deriva, reclamações e reversões feitas por pessoas. A deriva do modelo e mudanças na população atendida podem transformar em silêncio um sistema bem testado num sistema nocivo. Leve à liderança métricas simples do programa (inventário classificado, avaliações concluídas, apontamentos em aberto, incidentes, cobertura de formação) e use um modelo de maturidade para definir metas anuais.

Uma avaliação de impacto algorítmico pergunta quem pode ser afetado, como, com que gravidade e com que probabilidade, e o que será feito a respeito. Boas avaliações descrevem o sistema em linguagem simples, identificam os grupos afetados (inclusive pessoas que nunca usam o sistema diretamente), consideram mau uso e modos de falha e terminam com mitigações concretas, cada uma com um responsável. São documentos vivos, revistos quando o sistema ou o contexto mudam.

Os testes devem ser planejados a partir dos riscos identificados, e não rodados como checklist genérico. Para viés algorítmico, escolha métricas de equidade adequadas à decisão e ao contexto jurídico e teste entre os grupos relevantes, sabendo que métricas diferentes podem entrar em conflito. Para segurança, inclua ameaças próprias da IA, como envenenamento de dados, extração de modelo e injeção de prompt. Em sistemas generativos, o red teaming feito por pessoas que tentam fazer o sistema falhar é essencial e deve ser repetido quando os modelos mudam.

Supervisão humana é fácil de declarar e difícil de tornar real. Um revisor que vê centenas de recomendações por hora, sem informação nem autoridade para discordar, não é supervisão; é viés de automação com assinatura. A supervisão eficaz define o que a pessoa confere, dá a ela o contexto e a explicabilidade de que precisa, dá tempo e autoridade para reverter e mede com que frequência isso acontece. Se ninguém nunca reverte nada, investigue.

Defina o que conta como incidente de IA (saída nociva, padrão discriminatório, comprometimento de segurança, mau funcionamento grave, mau uso) e encaminhe-o por um processo com triagem, contenção, análise de causa raiz, comunicação quando exigida e lições aprendidas. Ligue esse processo aos que já existem: uma injeção de prompt que vaza dados pessoais é ao mesmo tempo incidente de segurança, incidente de segurança com dados pessoais a ser avaliado para comunicação à ANPD e incidente de IA. No AI Act, fornecedores de sistemas de alto risco têm deveres de notificar incidentes graves, e implantadores devem informar fornecedores e autoridades em situações definidas.