Skip to content
AISO Learn AISO Learn - Home
Parte do AISO Group Fazer o Scorecard
Recursos / Regulamento da IA

Artigo 4.º do Regulamento da IA da UE - o que a "literacia em IA" efetivamente exige à sua equipa.

Um guia prático ao Artigo 4.º do Regulamento da IA da UE: a quem se aplica, o que significa a literacia em IA na prática, que documentação sustenta a preparação para o Artigo 4.º do AI Act, e como construir um programa que resista ao escrutínio.

Lead

A 2 de fevereiro de 2025, o Artigo 4.º do Regulamento da IA da UE entrou em aplicação. As regras de supervisão e de execução aplicam-se a partir de agosto de 2026. É curto. É vago. Aplica-se a quase todos. E colocou uma obrigação silenciosa na secretária de cada empregador europeu que deixa pessoal usar uma ferramenta de IA no trabalho.

A cláusula diz que fornecedores e implementadores de sistemas de IA devem tomar medidas para garantir um nível suficiente de literacia em IA do seu pessoal e de outras pessoas envolvidas na operação e uso de sistemas de IA em seu nome. É a frase inteira. Não define “suficiente”. Não especifica horas de formação. Não lista programas aprovados. O que faz é criar um padrão pelo qual um regulador, uma comissão de trabalhadores ou um advogado de uma ação judicial pode medir-se a si depois de algo correr mal.

Este artigo é o guia prático que gostaríamos que existisse quando os clientes começaram a perguntar-nos sobre o Artigo 4.º no final de 2024. Cobre o que a cláusula efetivamente exige - não o que oradores de conferências dizem que exige - e que documentação as organizações devem ter pronta como prova. Tem opinião onde a lei é vaga; dizemos como a lemos e porquê. Onde a lei é clara, dizemo-lo sem rodeios.

Se é responsável pela literacia em IA na sua organização e precisa de um programa defensável antes de um incidente forçar a pergunta, é para si.

O que o Artigo 4.º efetivamente diz, em linguagem simples

  • O texto da cláusula, desdobrado frase a frase
  • “Fornecedores” vs “implementadores” - qual é o seu caso
  • “Pessoal e outras pessoas envolvidas na operação” - o âmbito é mais amplo do que parece
  • O que “suficiente” tem de significar, pelos padrões da legislação UE adjacente

A cláusula é uma única frase. Leia devagar:

Os fornecedores e implementadores de sistemas de IA devem tomar medidas para garantir, na medida do possível, um nível suficiente de literacia em IA do seu pessoal e das demais pessoas envolvidas na operação e uso de sistemas de IA em seu nome, tendo em conta os seus conhecimentos técnicos, experiência, educação e formação, e o contexto em que os sistemas de IA serão usados, e considerando as pessoas ou grupos de pessoas sobre as quais os sistemas de IA serão aplicados.

Três expressões fazem o trabalho pesado.

“Fornecedores e implementadores.” Um fornecedor é a organização que constrói, marca ou modifica substancialmente um sistema de IA e o coloca no mercado. Um implementador é qualquer entidade que usa um sistema de IA num contexto profissional - o lugar em que cada empregador europeu se encontra no momento em que um colaborador abre o ChatGPT, o Copilot, o Gemini, o Claude ou qualquer funcionalidade de IA embutida numa ferramenta SaaS para fazer o seu trabalho. Se a sua equipa usa IA no trabalho, é implementador. Se também constrói ou rebatiza funcionalidades de IA, é os dois.

“Pessoal e outras pessoas envolvidas na operação e uso … em seu nome.” O âmbito é mais amplo do que os colaboradores efetivos. Alcança contratados, pessoal de agência, freelancers e parceiros que operem o sistema em seu nome. O critério não é o contrato. O critério é se a pessoa está a usar IA para fazer trabalho para si.

“Nível suficiente.” É a parte que preocupa as pessoas, e com razão. O Regulamento não define “suficiente”. Não há um número mínimo de horas de formação. Não há um currículo aprovado. O padrão é calibrado pela função, pelo risco, pelo contexto de uso e pelas pessoas afetadas pelo resultado. Isto significa que “suficiente” para um marketer júnior que usa IA para esboçar publicações nas redes sociais não é “suficiente” para um especialista de RH que usa IA para filtrar currículos, e nenhum dos dois corresponde ao “suficiente” para um engenheiro que treina um modelo com dados de clientes.

Os pontos de referência mais próximos na legislação UE adjacente são as salvaguardas “adequadas” do RGPD e o descanso “adequado” da Diretiva do Tempo de Trabalho. Em ambos, os reguladores leem o padrão face àquilo que uma organização competente do seu setor deveria razoavelmente estar a fazer. O Artigo 4.º será lido da mesma forma. “Suficiente” significa defensável face a uma expectativa razoável: não perfeito, não um registo de conclusão, mas documentado, adequado à função e atualizado.

A quem se aplica o Artigo 4.º

  • Qualquer empregador cujo pessoal use uma ferramenta de IA de terceiros
  • Qualquer organização que construa ou integre uma funcionalidade de IA no seu próprio produto
  • Contratados, freelancers e pessoal de agência - porque estão no âmbito
  • A questão do pequeno empregador - há uma exceção (não, mas leia a nuance)

Se a sua organização faz alguma das seguintes coisas, o Artigo 4.º aplica-se a si:

O seu pessoal usa uma ferramenta de IA de terceiros no trabalho. É o caso mais amplo e mais comum. No momento em que um colaborador usa o ChatGPT, o Copilot, o Gemini, o Claude, o Perplexity, um sumarizador de IA dentro do Notion ou do Slack, uma funcionalidade de IA dentro do seu CRM, ou qualquer outra função baseada em IA para produzir output de trabalho, é um implementador ao abrigo do Artigo 4.º. Versão gratuita, paga, autorizada ou paralela: não importa. A utilização cria a obrigação.

Constrói ou integra uma funcionalidade de IA no seu próprio produto. Se o seu produto chama uma API de modelo, faz fine-tuning a um modelo ou envolve IA de terceiros na sua própria interface, é fornecedor para essa funcionalidade. As obrigações de fornecedor somam-se às obrigações de implementador, pelo que carrega ambas.

Recorre a contratados, freelancers ou pessoal de agência que lidam com IA em seu nome. É uma lacuna comum. O Artigo 4.º estende-se explicitamente a “outras pessoas envolvidas na operação e uso de sistemas de IA em seu nome”. Se um designer freelancer usa o Midjourney para produzir peças que entrega, se uma agência usa o ChatGPT para esboçar as suas campanhas, ou se um analista contratado usa uma ferramenta de IA para preparar os seus relatórios, a obrigação chega-lhes através de si. A literacia deles é a sua responsabilidade evidenciar.

É pequeno. Não há exceção por número de colaboradores. O Regulamento aplica-se à mais pequena consultoria em nome individual e à maior multinacional. O que muda com a dimensão é o que “suficiente” significa na prática: não se espera que uma equipa de 6 pessoas corra o mesmo programa que uma empresa de 6.000 pessoas. Mas a obrigação em si é a mesma. As organizações mais pequenas tendem a optar por evidência mais leve e pragmática: uma política escrita, um onboarding curto, um calendário de atualização e um registo simples de quem completou o quê. É suficiente, quando é real.

A conclusão prática: se alguém ligado ao seu trabalho usa IA para produzir output, planeie o Artigo 4.º como se se aplicasse a si, porque aplica-se.

O calendário - o que é aplicável quando

  • 2 de fevereiro de 2025 - Artigo 4.º e cláusulas de práticas proibidas em aplicação
  • 2 de agosto de 2025 - regras para modelos de IA de uso geral em aplicação
  • 2 de agosto de 2026 - obrigações para sistemas de alto risco e quadro de supervisão e sanções aplicam-se
  • O que o faseamento significa para o planeamento do seu programa de formação

O Regulamento da IA entrou em vigor a 1 de agosto de 2024 e ativa-se por fases. As datas que importam para o planeamento da literacia em IA:

2 de fevereiro de 2025 - Artigo 4.º entrou em aplicação. Em conjunto com as cláusulas de práticas proibidas, é a primeira vaga de obrigações a fixar-se. A cláusula está em aplicação agora. O que ainda não está em vigor é o regime formal de supervisão e sanções em torno dela: esse chega em 2026.

2 de agosto de 2025 - regras para modelos de IA de uso geral em aplicação. Afeta sobretudo fornecedores de modelos de fronteira e modelos de fundação, bem como organizações que façam fine-tuning ou modificações substanciais. A maioria dos implementadores não é diretamente atingida por esta data, mas as ferramentas a montante que a sua equipa usa vão mudar em resposta - razão pela qual um ciclo de atualização importa.

2 de agosto de 2026 - obrigações para sistemas de alto risco e o quadro de supervisão e sanções aplicam-se. É a data em que muitas equipas se ancoram mentalmente, porque traz a arquitetura de execução: autoridades de fiscalização do mercado, avaliação de conformidade para sistemas de alto risco e as sanções financeiras associadas a incumprimento. A partir de agosto de 2026, a obrigação do Artigo 4.º que está em aplicação desde fevereiro de 2025 passa a estar inserida num quadro de supervisão ativo.

2 de agosto de 2027 - algumas disposições para sistemas de alto risco já no mercado continuam a entrar por fases. Sobretudo relevante para fornecedores, não para a maioria dos implementadores.

O que este calendário faseado significa para o seu programa de formação: a obrigação está viva agora. O mecanismo de sanções ativa-se a partir de agosto de 2026. A janela entre as duas datas é o tempo para construir um programa que seja real, adequado à função, atualizado e documentado, para que, quando o regime de supervisão chegar, não esteja a começar do zero. As organizações que vão sofrer em 2026 são as que trataram 2025 como um adiamento.

O que a “literacia em IA” efetivamente exige - as quatro competências

  1. Compreender o que o sistema de IA está a fazer, ao nível necessário para a função
  2. Reconhecer os riscos e limitações que se aplicam ao seu caso de uso
  3. Saber quando é necessário o julgamento humano e como exercê-lo
  4. Conseguir documentar e explicar decisões assistidas por IA depois do facto

Eis como as quatro competências se traduzem na prática, função a função. O objetivo não é ser exaustivo: é mostrar como “suficiente” muda com o trabalho.

Jurídico e compliance. A compreensão estende-se ao modo como o modelo lida com confidencialidade, retenção e atribuição de fontes. A consciência de risco inclui citações alucinadas, deriva jurisdicional no raciocínio jurídico e fugas de confidencialidade através de prompts. O julgamento humano é o coração da função: cada output assistido por IA é revisto contra fontes primárias e contra a análise do próprio advogado antes de sair do escritório. Documentação: que matérias foram assistidas por IA, com que modelos, que revisão foi feita e o que o advogado alterou.

RH e gestão de pessoas. A compreensão inclui a forma como ferramentas de recrutamento, triagem e desempenho pontuam e ordenam pessoas, que features usam e por onde entra o enviesamento. A consciência de risco abrange proxies de características protegidas, deriva da pontuação ao longo do tempo e a fronteira entre automação de apoio e uma decisão que legalmente tem de ser tomada por um humano. Julgamento humano: cada shortlist, alerta de desempenho ou recomendação revisto antes da ação. Documentação: registos de formação da equipa, registos de uso de ferramentas de IA em decisões de contratação e um registo claro de onde fica a decisão humana.

Marketing e conteúdo. A compreensão estende-se ao modo como ferramentas generativas produzem texto e imagens, que dados de treino as alimentaram e os limites da fiabilidade factual. A consciência de risco abrange deriva da voz da marca, risco de plágio, estatísticas inventadas e obrigações de divulgação ao público. O julgamento humano é editorial: cada peça esboçada por IA é revista quanto a precisão, voz, alegações e direitos. Documentação: que peças foram assistidas por IA, que revisão foi feita, o que o marketer alterou.

Engenharia e produto. A compreensão inclui o funcionamento dos modelos de geração de código, com que dados foram treinados, os riscos do código sugerido e a distinção entre autocompletar e geração autónoma. A consciência de risco abrange contaminação de licenças, vulnerabilidades de segurança em código sugerido, segredos vazados em prompts e dependência excessiva. Julgamento humano: revisão de cada sugestão aceite e a prática deliberada de escrever o teste antes de aceitar a implementação. Documentação: que funcionalidades usaram assistência de IA, que modelos foram fine-tuned em código interno e o registo da revisão.

Suporte ao cliente e vendas. A compreensão abrange a forma como sumários de IA, respostas em rascunho e ferramentas de recomendação geram output e onde falham. A consciência de risco abrange afirmações erradas de política, compromissos inventados, funcionalidades de produto alucinadas e desencontro de tom com a marca. Julgamento humano: o agente revê cada resposta gerada por IA antes de enviar, sobretudo quando o cliente está numa situação vulnerável, em disputa ou num contexto regulado. Documentação: que interações usaram assistência de IA, vias de escalonamento e as edições do agente.

A forma repete-se: as quatro competências são constantes. O conteúdo e a profundidade escalam com o risco da função e com a consequência de errar.

Que documentação as organizações devem ter pronta como prova

  • Política escrita de literacia em IA - que secções tem de conter
  • Registos de formação - quem foi formado, em quê, por quem, com que materiais
  • Evidência de avaliação - como sabe que a formação funcionou
  • Registos de incidentes - quando o uso de IA correu mal e o que foi aprendido
  • Calendário de retenção - quanto tempo guardar o acima, e em que formato

Não há um formato oficial de ficheiro para o Artigo 4.º. Não há um portal de submissão. A Comissão Europeia confirmou que não é exigido qualquer registo de conclusão emitido por terceiros. O que é exigido são registos internos que, no conjunto, mostrem que uma organização competente tomou medidas adequadas à função e ao risco. Na prática, quando um responsável de compliance, um regulador, um cliente, uma comissão de trabalhadores ou um conselho de administração diz “mostrem-nos a vossa prova pronta para o Artigo 4.º”, procuram estes elementos:

Uma política escrita de literacia em IA. Curta serve, real é essencial. Deve identificar quem cobre (incluindo contratados e pessoal de agência), que ferramentas estão autorizadas, o que é proibido, onde tirar dúvidas, que formação é exigida para que funções e com que frequência a própria política é revista. Uma a três páginas, com um responsável nomeado, datada, com controlo de versão.

Registos de formação. Quem foi formado, em quê, por quem, com que materiais e em que data. O registo deve ser recuperável por pessoa e por função. Os materiais devem ser arquivados na forma em que foram entregues: se realizou um workshop, guarde o deck e a lista de presenças; se usou um módulo de e-learning, guarde a versão e o registo de conclusão. A formação fornecida pelo fornecedor é boa como parte do programa, não como o todo dele.

Evidência de avaliação. Como sabe que a formação funcionou. Não tem de ser um teste de escolha múltipla. A evidência mais forte é a revisão do produto de trabalho: a primeira peça assistida por IA de um marketer revista por um sénior; o primeiro pull request assistido por IA de um engenheiro revisto contra os critérios de literacia; a primeira shortlist de um especialista de RH com revisão documentada. O princípio: avaliação integrada no trabalho, não acrescentada por cima.

Registos de incidentes. Quando o uso de IA correu mal, o que aconteceu, o que foi aprendido, o que mudou. “Mal” tem um sentido amplo: uma fuga de confidencialidade, um facto alucinado que chegou ao cliente, um quase-incidente apanhado em revisão, uma violação de política. O registo mostra que a organização responde, aprende e atualiza o programa, que é o cerne de “medidas suficientes, tendo em conta a experiência”.

Um calendário de retenção. Quanto tempo os registos são guardados e em que formato. Cinco anos para registos de formação é um valor por defeito razoável na maior parte dos contextos UE; alinhe com a sua política de retenção mais ampla. Mantenha juntos a política, os materiais de formação, os registos de conclusão, a evidência de avaliação e o registo de incidentes para que um revisor possa ler a história do início ao fim.

É isto que um dossier de prova pronta parece. Nada disto exige um registo de conclusão de um terceiro. Tudo isto é produzível por uma organização competente que leve a obrigação a sério.

Erros comuns dos empregadores

  • Tratar o Artigo 4.º como um problema de TI
  • Confiar na formação fornecida pelo fornecedor como programa inteiro
  • Formar uma vez e nunca atualizar
  • Deixar contratados e pessoal de agência fora do âmbito
  • Não documentar - o mais difícil de corrigir depois do facto

Os cinco padrões que mais vemos quando os empregadores nos chegam a meio do programa:

Tratar o Artigo 4.º como um problema de TI. Não é. É uma obrigação organizacional que toca em política, pessoas, formação e registos. As TI podem autorizar ferramentas e proteger segredos. Não podem, sozinhas, evidenciar que o pessoal entende o que as ferramentas fazem, onde falham e quando é necessário julgamento humano. O Artigo 4.º precisa de RH, jurídico, gestão direta e TI a remar juntos. Onde fica como iniciativa só de TI, faltam quase sempre as camadas de política e de formação.

Confiar na formação fornecida pelo fornecedor como programa inteiro. A formação Copilot da Microsoft é boa. O módulo ChatGPT for Work da OpenAI é correto. Nenhum deles é um programa. A formação do fornecedor ensina uma ferramenta. O Artigo 4.º pede competência específica à função em torno do uso de IA no seu contexto, com os seus dados, contra os seus riscos. O material do fornecedor pode ser uma das peças. Não pode ser a resposta.

Formar uma vez e nunca atualizar. O texto da cláusula diz que as medidas devem ter em conta a “experiência” - e as ferramentas mudam a cada trimestre. Um programa sem cadência de atualização envelhece depressa. Defina um intervalo de atualização que acompanhe a velocidade a que as suas ferramentas mudam; para a maioria das equipas isso é seis a doze meses, não anualmente.

Deixar contratados e pessoal de agência fora do âmbito. O Artigo 4.º alcança explicitamente “outras pessoas envolvidas na operação e uso de sistemas de IA em seu nome”. Se a sua agência esboça as suas campanhas com IA e não estendeu a política de literacia a essa agência, é uma lacuna. A solução é contratual: requisito de formação, atestação de política e registo guardado do seu lado.

Não documentar. O erro mais difícil de corrigir depois do facto, porque os eventos que precisava de documentar já aconteceram. O padrão é familiar: uma equipa corre uma formação sólida, constrói capacidade real e não produz registos. Dezoito meses depois, um cliente pede prova e a organização não a consegue produzir. A documentação não tem de ser pesada. Tem de ser habitual, e tem de começar agora, não quando a pergunta for feita.

Se reconhece mais do que um destes padrões na sua organização, não está atrasado: está dentro da norma. O trabalho está em fechar as lacunas antes que alguém de fora lhe peça que o faça.

Construir um programa que resiste ao escrutínio

  1. Mapear onde a IA é usada entre funções (a maioria dos empregadores subestima isto em 3 a 5 vezes)
  2. Escrever a política de literacia em IA antes de desenhar a formação
  3. Estruturar a formação por risco-função, não por senioridade
  4. Integrar a avaliação - não como teste, mas como revisão de produto de trabalho
  5. Definir uma cadência de atualização que acompanhe a velocidade a que as ferramentas mudam
  6. Manter registos num formato que o seu responsável de compliance possa rever e um regulador possa entender

É o padrão Mapear -> Formar -> Evidenciar que usamos com cada cliente. É opinativo. Funciona.

1. Mapear onde a IA é usada entre funções. A maioria dos empregadores subestima isto em três a cinco vezes. Faça uma descoberta estruturada: cada equipa, cada ferramenta, cada workflow que toque em IA - autorizado, não autorizado, embutido em SaaS ou usado discretamente em contas pessoais. O resultado é um mapa de uso por função, com classificações de risco face às quatro competências. O mapa é a fundação. Erre nele e o resto do programa forma as pessoas erradas nas coisas erradas.

2. Escrever a política de literacia em IA antes de desenhar a formação. A política é a constituição; a formação é o currículo. Escreva primeiro a política para que a formação seja construída para a entregar, e não o contrário. A política é curta, sensível à função e assinada por um responsável nomeado. É também o documento que torna “suficiente” defensável: declara o que a organização decidiu ser adequado, dada a função e o risco.

3. Estruturar a formação por risco-função, não por senioridade. O sócio sénior que usa IA para um sumário semanal precisa de menos profundidade do que o associado júnior que a usa diariamente em trabalho de cliente. Estruturar por senioridade é hábito. Estruturar por risco-função é disciplina. Construa uma camada base para todos, uma camada mais profunda para funções intensivas em IA e uma camada especializada para funções em que a IA toca decisões reguladas.

4. Integrar a avaliação, não como teste, mas como revisão de produto de trabalho. A evidência mais forte de que a formação funcionou é a primeira peça de trabalho assistida por IA que cada pessoa produz, revista por um sénior contra os critérios de literacia. É mais credível do que uma nota de quiz e funciona em simultâneo como coaching no terreno. Capture a revisão no registo.

5. Definir uma cadência de atualização que acompanhe a velocidade a que as ferramentas mudam. Atualização anual é demasiado lenta para a maioria das equipas. Seis a nove meses está mais perto do certo. Despolete uma atualização fora de ciclo quando uma ferramenta importante muda, um novo modelo é lançado ou um incidente revela uma lacuna. A atualização é curta: não é refazer, é atualizar.

6. Manter registos num formato que o seu responsável de compliance possa rever e um regulador possa entender. Linguagem clara. Datados. Com controlo de versão. Uma pasta, uma estrutura, um responsável. O teste é se alguém que não conhece o programa consegue ler os registos do início ao fim e entender o que foi ensinado, a quem, quando, e que evidência mostra que ficou. Se conseguir, tem um dossier de prova pronta. Se não conseguir, tem uma pilha de ficheiros.

Um programa construído desta forma - mapeado, ancorado em política, estruturado por risco-função, avaliado no trabalho, atualizado em cadência e documentado num formato legível - é o que “medidas suficientes” significa na prática. Não é um registo de conclusão. Não é uma garantia. É uma posição defensável, que é o padrão que a cláusula efetivamente pede.

Como a AISO Learn ajuda com o Artigo 4.º

  • Team Engagement com o pacote de literacia do Artigo 4.º
  • O que está incluído (formação + política + registos)
  • O que não está incluído (validação jurídica - o seu advogado fica com a política)
  • A chamada de descoberta como próximo passo

Se é responsável pela preparação para o Artigo 4.º do AI Act na sua organização e quer um programa defensável antes que a pergunta seja forçada por um incidente, uma revisão de cliente, uma comissão de trabalhadores ou uma inspeção do regulador, uma chamada de descoberta é o próximo passo.

Ou, se primeiro quer ver onde a sua equipa está, o Scorecard de Prontidão em IA inclui uma faixa de competência do Artigo 4.º e indica-lhe o caminho mais curto para fechar a lacuna.


A AISO Learn presta formação em literacia em IA e documentação de apoio à preparação para o Artigo 4.º do AI Act. Não somos uma sociedade de advogados nem um organismo de certificação e não prestamos aconselhamento jurídico, certificação formal de conformidade, avaliação de conformidade ou garantia de conformidade regulamentar.