O AI Act já não é uma questão para “mais tarde”. Para muitas startups, as regras de transparência já se aplicam. O primeiro passo não é contratar uma equipa jurídica inteira: é descobrir onde a IA está realmente a ser usada, que decisões influencia e que evidências a empresa consegue apresentar.
Nota: informação verificada até 9 de setembro de 2026. Este artigo é informativo e não substitui aconselhamento jurídico.
Há dois erros comuns quando fundadores falam sobre o EU AI Act.
O primeiro é pensar que só se aplica a empresas que desenvolvem modelos de inteligência artificial.
O segundo é assumir que todas as obrigações foram adiadas.
Nenhuma das afirmações está correta.
O Regulamento Europeu da Inteligência Artificial — Regulamento (UE) 2024/1689 — entrou em vigor em agosto de 2024. Algumas disposições começaram a aplicar-se em 2025. As regras de transparência do Artigo 50, particularmente relevantes para chatbots e conteúdo sintético, tornaram-se aplicáveis em 2 de agosto de 2026.
É verdade que o Regulamento (UE) 2026/1744, conhecido como Digital Omnibus on AI, adiou partes importantes do regime aplicável aos sistemas de alto risco. Mas não adiou todo o AI Act.
Para uma startup, a pergunta correta deixou de ser:
“A nossa empresa é uma empresa de IA?”
A pergunta correta é:
“Onde usamos IA, que papel temos em cada utilização e que impacto essa utilização pode ter sobre clientes, trabalhadores ou outras pessoas?”
Uma startup que usa um chatbot, gera campanhas publicitárias, filtra candidatos, personaliza preços ou cria um produto com base num modelo de terceiros pode ter obrigações diferentes em cada uma dessas atividades.
O AI Act pode aplicar-se mesmo que a startup não esteja sediada na União Europeia
O âmbito territorial do AI Act não termina nas fronteiras da União Europeia.
Em termos gerais, o regulamento pode abranger:
- fornecedores que colocam sistemas ou modelos de IA no mercado europeu;
- empresas que utilizam sistemas de IA dentro da União;
- fornecedores ou utilizadores estabelecidos fora da União quando os resultados produzidos pelo sistema são utilizados na UE;
- importadores e distribuidores de sistemas de IA.
Isto significa que uma startup norte-americana, britânica ou africana pode entrar no âmbito do AI Act se disponibilizar um produto de IA a clientes europeus ou se os resultados do sistema forem usados na União.
O local onde a empresa está registada não resolve, por si só, a questão.
Antes de avaliar o risco, identifica o teu papel
O AI Act distribui responsabilidades conforme o papel desempenhado na cadeia de valor.
Provider — fornecedor
A empresa é geralmente um provider quando desenvolve um sistema de IA, ou manda desenvolvê-lo, e o coloca no mercado ou em serviço em seu próprio nome ou marca.
Uma startup também pode assumir responsabilidades de fornecedor quando:
- coloca a sua marca num sistema de terceiros;
- altera substancialmente um sistema;
- muda a finalidade prevista do sistema;
- integra um modelo num produto próprio e define como esse produto funciona.
Usar uma API externa não elimina automaticamente as responsabilidades sobre o produto final.
Deployer — responsável pela implantação
Um deployer é uma organização que utiliza um sistema de IA sob a sua autoridade, fora de uma atividade estritamente pessoal.
Uma startup pode ser deployer quando usa IA para:
- apoiar o atendimento ao cliente;
- gerar conteúdo;
- analisar candidatos;
- recomendar produtos;
- monitorizar fraude;
- analisar comportamento;
- apoiar decisões internas.
Importer ou distributor
Uma empresa também pode atuar como importadora ou distribuidora quando introduz ou disponibiliza um sistema de terceiros no mercado europeu.
O ponto importante é que uma única startup pode ocupar vários papéis ao mesmo tempo.
Pode ser responsável pela implantação de uma ferramenta usada internamente e fornecedora do produto de IA que vende aos clientes.
O AI Act não trata todas as utilizações de IA da mesma forma
O regulamento adota uma abordagem baseada no risco. Na prática, um fundador deve separar as utilizações de IA em quatro grupos.
1. Práticas proibidas
Determinadas utilizações são consideradas incompatíveis com os direitos e valores protegidos pela União.
O Artigo 5 cobre, entre outros casos e dentro das condições definidas no regulamento:
- técnicas manipulativas ou enganosas capazes de distorcer materialmente o comportamento e causar dano significativo;
- exploração de vulnerabilidades associadas à idade, deficiência ou situação social ou económica;
- determinadas formas de social scoring;
- criação ou expansão de bases de reconhecimento facial através da recolha indiscriminada de imagens;
- algumas formas de categorização biométrica com base em características sensíveis;
- reconhecimento de emoções no trabalho e em instituições de ensino, salvo exceções limitadas relacionadas com saúde ou segurança;
- determinadas utilizações de identificação biométrica remota em tempo real.
O Digital Omnibus on AI de 2026 também introduziu novas proibições relacionadas com imagens íntimas não consensuais geradas por IA e material de abuso sexual infantil.
Para uma startup, estas práticas não devem entrar numa fila de “compliance futuro”. Precisam de uma análise imediata.
2. Sistemas de alto risco
A classificação de alto risco não depende apenas da tecnologia. Depende principalmente da finalidade e do contexto de utilização.
Entre os exemplos mais relevantes para startups estão sistemas usados para:
- recrutamento, filtragem de candidaturas e avaliação de trabalhadores;
- decisões sobre promoção, despedimento ou atribuição de tarefas;
- avaliação da solvabilidade de pessoas;
- acesso a determinados serviços essenciais;
- educação e admissão;
- biometria;
- aplicação da lei, migração ou administração da justiça.
Um gerador de descrições de produtos não se torna automaticamente um sistema de alto risco.
Já uma ferramenta que pontua candidatos e decide quem avança num processo de recrutamento pode entrar no regime de alto risco.
O calendário atual, depois das alterações de 2026, é:
- 2 de dezembro de 2027: aplicação das principais obrigações aos sistemas autónomos de alto risco previstos no Anexo III;
- 2 de agosto de 2028: aplicação aos sistemas de alto risco incorporados em determinados produtos regulados do Anexo I.
O adiamento não é um motivo para ignorar estes sistemas. Implementar gestão de risco, documentação, supervisão humana, registos e monitorização pós-mercado perto do prazo será mais caro do que desenhar esses elementos desde o início.
3. Sistemas sujeitos a transparência
Esta é provavelmente a categoria com impacto imediato sobre mais startups.
As regras do Artigo 50 aplicam-se desde 2 de agosto de 2026.
4. Utilizações de risco limitado
Muitas utilizações correntes — produtividade, pesquisa interna, rascunhos ou recomendações de baixo impacto — podem não ser proibidas, de alto risco ou diretamente abrangidas pelas obrigações específicas de transparência.
Isso não significa ausência de responsabilidade.
Continuam a poder aplicar-se:
- RGPD;
- regras de proteção do consumidor;
- direitos de autor;
- direito laboral;
- regras sobre publicidade enganosa;
- contratos com fornecedores e clientes;
- deveres de segurança e confidencialidade.
O AI Act não substitui essas normas.
O que as regras de transparência significam na prática
Existe muita informação simplificada sobre “identificar todo o conteúdo criado com IA”. A obrigação real é mais específica.
Chatbots e outros sistemas interativos
Quando uma pessoa interage diretamente com um sistema de IA, o fornecedor deve garantir que ela é informada de que está a interagir com IA, salvo quando isso for evidente para uma pessoa razoavelmente informada e atenta.
Na prática, um chatbot de suporte não deve fingir ser um funcionário humano.
Uma indicação simples e visível pode ser suficiente:
“Está a conversar com um assistente de IA.”
A informação deve aparecer, no máximo, durante a primeira interação ou exposição. Não deve ficar escondida num documento jurídico que ninguém vê.
Conteúdo gerado por IA e marcação legível por máquina
Os fornecedores de sistemas que geram ou manipulam texto, áudio, imagem ou vídeo devem assegurar que os resultados sejam marcados num formato legível por máquina e detetáveis como artificialmente gerados ou manipulados, na medida em que isso seja tecnicamente viável.
Para uma startup que utiliza ferramentas externas, isto cria uma pergunta importante para o fornecedor:
A ferramenta aplica uma marcação técnica e o nosso processo preserva-a quando o conteúdo é editado, exportado ou publicado?
Eliminar metadados, proveniência ou outras marcações durante o fluxo de produção pode destruir um mecanismo que o fornecedor criou para cumprir a lei.
Deepfakes
Quem publica uma imagem, gravação de áudio ou vídeo artificialmente gerado ou manipulado que se assemelhe a uma pessoa, objeto, local ou evento real, parecendo autêntico, deve divulgar que o conteúdo foi gerado ou manipulado.
Exemplos relevantes:
- um vídeo em que o fundador aparentemente diz palavras que nunca gravou;
- um testemunho sintético que parece vir de um cliente real;
- uma demonstração fabricada apresentada como experiência real;
- uma imagem de produto alterada de forma que possa parecer uma fotografia fiel do produto vendido.
No caso de obras artísticas, satíricas ou ficcionais, a divulgação pode ser feita de forma adequada ao contexto, sem prejudicar desnecessariamente a apresentação da obra.
Texto sobre matérias de interesse público
Existe também uma regra para texto gerado ou manipulado por IA e publicado com a finalidade de informar o público sobre assuntos de interesse público.
Esse conteúdo deve ser divulgado como artificialmente gerado ou manipulado.
A regra contém uma exceção quando:
- existiu revisão humana ou controlo editorial;
- uma pessoa ou organização assume responsabilidade editorial pela publicação.
Isto não significa que qualquer revisão superficial elimina automaticamente o problema. Deve existir um processo editorial real e uma entidade identificável que assuma responsabilidade.
Nem toda descrição de produto exige um rótulo público
O Artigo 50 não cria uma obrigação universal de colocar “feito por IA” em todos os textos de marketing.
Uma descrição comercial de um produto, por exemplo, não é necessariamente uma publicação sobre uma matéria de interesse público.
No entanto:
- não pode enganar o consumidor;
- imagens e demonstrações devem representar corretamente o produto;
- testemunhos não podem ser inventados;
- deepfakes continuam sujeitos a divulgação;
- a empresa deve preservar as marcações técnicas aplicáveis.
A análise depende do conteúdo e da forma como é apresentado, não apenas da ferramenta usada.
Situações comuns numa startup
| Utilização | Questão principal |
|---|---|
| Chatbot de suporte | A pessoa sabe que está a falar com IA? |
| Descrições de produtos | O conteúdo é correto e não induz o consumidor em erro? |
| Imagens de produto geradas | Parecem fotografias autênticas? Existe risco de representação enganosa ou deepfake? |
| Vídeo sintético do fundador | Está claramente identificado como gerado ou manipulado? |
| Recomendação de produtos | Há perfilagem ou tratamento de dados pessoais sujeito ao RGPD? |
| Preços personalizados | O sistema pode discriminar, explorar vulnerabilidades ou violar regras de consumo? |
| Seleção de candidatos | Pode ser um sistema de alto risco do Anexo III. |
| Avaliação de crédito | Pode entrar nas categorias de alto risco relacionadas com serviços essenciais. |
| Análise emocional de trabalhadores | Pode ser uma prática proibida, salvo exceções muito restritas. |
| Assistente interno de escrita | Que dados confidenciais estão a ser enviados ao fornecedor? |
| Produto baseado numa API de IA | A startup é apenas utilizadora ou tornou-se fornecedora do sistema final? |
E se a startup usar um modelo de propósito geral?
Os modelos de propósito geral, ou GPAI, têm um regime próprio.
Se uma startup apenas utiliza a API de um modelo externo, normalmente não se torna fornecedora desse modelo de propósito geral. Mas pode continuar a ser:
- fornecedora do sistema final que construiu;
- responsável pela implantação de IA nas suas operações;
- responsável pelas promessas e decisões apresentadas aos clientes.
Se desenvolver e colocar no mercado o seu próprio modelo de propósito geral, as obrigações tornam-se mais extensas, incluindo documentação técnica, informação para fornecedores downstream, políticas relacionadas com direitos de autor e um resumo do conteúdo usado no treino.
Modelos com risco sistémico estão sujeitos a requisitos adicionais.
Para um fundador que integra uma API, as perguntas práticas ao fornecedor incluem:
- Que documentação disponibiliza?
- Quais são as utilizações previstas e proibidas?
- Como protege os dados introduzidos?
- Os dados são usados para treino?
- Como marca conteúdo sintético?
- Como comunica incidentes e alterações do modelo?
- Que informação fornece para apoiar a avaliação do produto final?
AI literacy não significa comprar um certificado genérico
O Artigo 4 exige que fornecedores e responsáveis pela implantação adotem medidas que apoiem o desenvolvimento da literacia em IA das pessoas que operam ou utilizam esses sistemas em seu nome.
Depois das alterações de 2026, a obrigação não exige garantir um nível individual padronizado. Continua, porém, a exigir medidas adequadas ao contexto.
Uma formação genérica de uma hora não resolve todos os casos.
Uma equipa de marketing precisa de compreender:
- divulgação e rotulagem;
- conteúdo enganoso;
- propriedade intelectual;
- proteção de dados;
- revisão editorial.
Uma equipa de recursos humanos precisa de compreender:
- discriminação;
- qualidade dos dados;
- supervisão humana;
- limites das recomendações automatizadas;
- contestação de decisões.
Uma equipa técnica precisa de compreender:
- limitações do modelo;
- logs;
- segurança;
- testes;
- monitorização;
- documentação e gestão de incidentes.
A formação deve acompanhar a função e o risco real.
O valor da documentação antes de existir um problema
Para startups, compliance não deve significar produzir documentos apenas para satisfazer uma auditoria.
A documentação serve para responder a perguntas operacionais:
- Qual é a finalidade do sistema?
- Que problema deve resolver?
- Quem pode ser afetado?
- Que dados utiliza?
- Que decisões influencia?
- Quando é necessária intervenção humana?
- Quais são as limitações conhecidas?
- Como medimos erros?
- Quem pode suspender o sistema?
- Como comunicamos um incidente?
- Que fornecedor ou modelo está por baixo do produto?
- O que mudou desde a última versão?
Sem estas respostas, a startup terá dificuldade em explicar o produto a clientes, investidores, parceiros ou reguladores.
Onde a Painstack entra neste processo
A melhor forma de reduzir risco não é começar por uma tabela jurídica. É começar por validar se existe um problema real que justifique construir o sistema.
É aqui que uma ferramenta como a Painstack pode ser particularmente útil.
Na fase de descoberta, a equipa pode utilizá-la para:
- estruturar a hipótese do problema;
- reunir sinais e fontes de mercado;
- confrontar suposições com evidências;
- identificar alternativas que os utilizadores já adotam;
- separar necessidades reais de funcionalidades imaginadas;
- registar por que razão uma determinada solução está a ser considerada.
Esse trabalho pode alimentar partes importantes do processo posterior:
- finalidade prevista do sistema;
- grupos potencialmente afetados;
- decisões de produto;
- riscos identificados;
- alternativas menos invasivas;
- justificação para utilizar IA;
- histórico de evidências e alterações de direção.
Mas existe uma fronteira importante:
A Painstack pode apoiar a validação, a pesquisa e o registo das decisões. Não substitui uma avaliação jurídica, uma ferramenta dedicada de conformidade ou a documentação técnica exigida pelo AI Act.
Também não deve ser usada para carregar dados pessoais ou sensíveis sem uma base jurídica e controlos adequados.
O papel da Painstack está no início do processo: ajudar a equipa a decidir o que merece ser construído e com base em que evidências.
Depois disso, entram engenharia, segurança, proteção de dados, avaliação de risco e revisão jurídica.
Um plano de 30 dias para founders
Semana 1 — Inventariar
Cria um registo de todos os sistemas de IA usados na empresa.
Para cada sistema, identifica:
- nome da ferramenta;
- fornecedor e modelo;
- proprietário interno;
- finalidade;
- utilizadores;
- pessoas afetadas;
- dados introduzidos;
- resultados produzidos;
- decisões que influencia;
- país onde é utilizado;
- contrato e política de retenção;
- data da última revisão.
Inclui ferramentas usadas informalmente pelas equipas. O maior risco pode estar numa conta gratuita que nunca passou por procurement.
Semana 2 — Classificar
Para cada utilização, pergunta:
- Somos provider, deployer, importador ou distribuidor?
- Existe alguma prática proibida?
- Pode ser um sistema de alto risco?
- Existe interação direta com pessoas?
- Gera ou manipula conteúdo?
- Produz deepfakes?
- Publica texto sobre assuntos de interesse público?
- Trata dados pessoais, biométricos ou sensíveis?
- Influencia decisões sobre emprego, crédito ou acesso a serviços?
Sistemas duvidosos devem ser marcados para revisão jurídica.
Semana 3 — Corrigir transparência e fornecedores
Implementa as medidas que já são relevantes:
- identificação visível dos chatbots;
- rótulos em deepfakes;
- divulgação em publicações abrangidas;
- preservação de marcações legíveis por máquina;
- revisão humana documentada;
- regras contra testemunhos e demonstrações fabricadas;
- contactos com fornecedores para obter documentação;
- atualização dos termos internos de utilização.
Semana 4 — Criar governação mínima
Define:
- responsável interno por IA;
- política de utilização aceitável;
- processo de aprovação para novas ferramentas;
- formação por função;
- plano de resposta a incidentes;
- periodicidade de revisão;
- critérios para supervisão humana;
- registo de alterações de fornecedor ou modelo;
- situações que exigem advogado, DPO ou especialista de segurança.
O objetivo não é produzir burocracia. É garantir que alguém consegue responder, com evidências, pelo uso de IA na empresa.
As coimas não devem ser o único motivo para agir
As infrações mais graves, incluindo determinadas práticas proibidas, podem atingir máximos de 35 milhões de euros ou 7% do volume de negócios mundial anual, dependendo das regras aplicáveis.
Outras violações podem chegar a 15 milhões de euros ou 3%, e o fornecimento de informação incorreta ou enganosa às autoridades pode chegar a 7,5 milhões de euros ou 1%.
O Artigo 99 prevê um tratamento dos limites aplicável às PME, incluindo startups, pelo qual a coima não deve ultrapassar o menor dos limites percentuais ou fixos relevantes.
Estes são limites máximos, não valores automáticos. A avaliação considera fatores como gravidade, duração, cooperação e dimensão da empresa.
Ainda assim, o maior risco inicial para muitas startups pode ser comercial:
- perder um contrato empresarial;
- falhar uma diligência de investimento;
- não conseguir responder a um questionário de segurança;
- descobrir tarde que o produto foi construído para uma finalidade de alto risco;
- ter de reconstruir o fluxo de dados ou supervisão humana.
Compliance bem feito não é apenas defesa contra uma coima. É parte da preparação do produto para clientes mais exigentes.
Conclusão
O EU AI Act não exige que todas as startups criem imediatamente um departamento jurídico.
Exige algo mais básico: que saibam onde utilizam IA, qual é o seu papel, que riscos estão a introduzir e que informação devem dar às pessoas afetadas.
Para muitos founders, as prioridades são claras:
- Identificar as utilizações de IA;
- Eliminar práticas proibidas;
- Cumprir as regras de transparência já aplicáveis;
- Preparar os sistemas que poderão ser classificados como alto risco;
- Formar as equipas conforme a função;
- Exigir documentação aos fornecedores;
- Registar decisões e evidências desde o início.
A Painstack pode ajudar a responder à primeira pergunta do produto:
Existe evidência suficiente para construir isto?
O AI Act obriga a responder às perguntas seguintes:
Como será utilizado, quem pode ser afetado e como demonstramos que atuámos de forma responsável?
Nenhuma ferramenta isolada garante conformidade.
Mas uma startup que valida o problema, documenta decisões, conhece os seus fornecedores e desenha transparência desde o início está melhor preparada do que uma empresa que tenta reconstruir tudo depois do lançamento.
Fontes oficiais
- Regulamento (UE) 2024/1689 — EU AI Act
- Texto consolidado do AI Act após as alterações de 2026
- Regulamento (UE) 2026/1744 — Digital Omnibus on AI
- Artigo 50 — Transparency obligations
- Comissão Europeia: aplicação e fiscalização a partir de 2 de agosto de 2026
- Guidelines on Transparency of AI-generated Content
- Code of Practice on Transparency of AI-generated Content
- AI Literacy — Questions & Answers
- Painstack


