Muitas empresas estão a usar IA antes de terem decidido como a devem usar.
Isto é normal. As ferramentas apareceram depressa, são fáceis de experimentar e resolvem problemas reais. Alguém usa para resumir uma reunião. Outra pessoa usa para escrever um email. Outra testa numa proposta. Outra cola uma tabela para pedir análise.
O problema é que, sem regras mínimas, a adoção fica entregue ao improviso individual.
E improviso individual em temas de dados, clientes, comunicação externa e decisões sensíveis raramente é uma boa política.
O uso informal já está a acontecer
A pergunta não é “a equipa usa IA?”.
Em muitas empresas, a pergunta real é “a equipa usa IA de que forma, com que dados e com que validação?”.
Proibir tudo costuma falhar. Deixar tudo ao critério de cada pessoa também.
O caminho mais sensato é criar uma política interna simples, prática e compreensível. Não um documento jurídico de vinte páginas que ninguém lê. Uma página ou duas, com regras claras.
O AI Act já fala de literacia
Desde 2 de fevereiro de 2025, segundo o calendário oficial do AI Act, aplicam-se as disposições gerais, incluindo literacia em IA. O Artigo 4 estabelece que providers e deployers de sistemas de IA devem tomar medidas para assegurar, na medida do possível, um nível suficiente de literacia em IA das pessoas que operam ou usam esses sistemas em seu nome, tendo em conta conhecimento técnico, experiência, formação e contexto de utilização.
Isto não significa que todas as empresas precisem de transformar cada colaborador num especialista técnico. Significa que usar IA no trabalho exige compreensão mínima dos riscos, limites e boas práticas.
E isto faz sentido mesmo fora da obrigação legal.
Uma equipa que usa IA sem perceber limites é uma equipa exposta.
O que uma política interna deve responder
Uma boa política interna de IA deve responder a perguntas muito práticas.
Que ferramentas podem ser usadas? Que dados nunca devem ser introduzidos? Que outputs exigem validação? Quem é responsável quando uma resposta é usada num documento externo? Em que situações é obrigatório informar que houve uso de IA? Quem aprova novos casos de uso?
Se estas respostas não existem, cada pessoa inventa as suas.
E quando cada pessoa inventa as suas regras, a empresa não tem governance. Tem sorte.
A regra dos dados sensíveis
O primeiro ponto deve ser dados.
Uma política simples deve deixar claro que informação confidencial, dados pessoais, dados de clientes, contratos, documentos internos sensíveis, credenciais, informação financeira não pública ou dados de saúde não devem ser colocados em ferramentas públicas sem validação prévia.
Isto não significa que IA nunca possa processar dados reais. Significa que esse uso exige contexto certo: ferramenta aprovada, configuração adequada, base legal quando aplicável, controlo de acesso e responsabilidade definida.
Usar IA para pensar é diferente de usar IA para processar dados reais.
Essa distinção devia estar escrita.
A regra da validação
O segundo ponto é validação.
Uma resposta de IA não deve sair diretamente para cliente, regulador, candidato, fornecedor ou público sem revisão humana quando envolve factos, promessas, preços, condições, decisões ou aconselhamento.
Pode parecer óbvio. Mas é precisamente o óbvio que convém escrever.
A política deve dizer claramente: IA pode ajudar a criar rascunhos, estruturar ideias e acelerar análise, mas a responsabilidade pelo output usado é humana.
A regra dos casos permitidos
Uma boa política não deve ser só proibição. Deve dar exemplos positivos.
Por exemplo, pode autorizar usos como:
- resumir notas internas sem dados sensíveis;
- melhorar clareza de textos;
- preparar rascunhos de emails;
- organizar ideias para apresentações;
- criar checklists internas;
- transformar documentação pública em resumo;
- apoiar brainstorming.
Ao mesmo tempo, pode exigir aprovação para usos como:
- análise de dados de clientes;
- decisões de recrutamento;
- classificação automática de risco;
- comunicação externa automatizada;
- integração com sistemas internos;
- processamento de documentos confidenciais.
Isto ajuda a equipa a agir sem medo e sem caos.
O que o NIST ajuda a estruturar
O NIST AI Risk Management Framework organiza a gestão de risco de IA em quatro funções: govern, map, measure e manage. Não é uma obrigação legal europeia, mas é uma referência útil para pensar com método.
Traduzindo para linguagem empresarial: definir regras, mapear usos, medir comportamento e gerir riscos.
Uma política interna de IA é o início da função “govern”. Sem isso, qualquer discussão sobre ferramentas fica incompleta.
Como começar em 60 minutos
Uma empresa pode fazer uma primeira versão com uma reunião curta e cinco decisões:
- Que ferramentas são permitidas hoje?
- Que dados são proibidos sem aprovação?
- Que tipos de output exigem validação humana?
- Que casos de uso queremos incentivar?
- Quem aprova exceções ou novos usos?
Isto não resolve tudo. Mas já reduz muito ruído.
Depois, a política deve evoluir com a prática. Ao fim de um mês, revê-se o que funcionou, o que ficou confuso e que novos casos surgiram.
Conclusão
Antes de comprar mais ferramentas de IA, muitas empresas precisam de uma coisa menos excitante e mais importante: regras internas.
Não para travar adoção. Para a tornar segura, consistente e útil.
Uma política interna de IA não é burocracia. É proteção operacional.
Porque quando a equipa já está a usar IA, a ausência de política também é uma política. Só que é a pior possível: cada um por si.
Fontes verificadas
Fontes consultadas em 30 de abril de 2026:
- AI Act Service Desk, “Timeline for the Implementation of the EU AI Act”: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
- AI Act Service Desk, “Article 4: AI literacy”: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4
- NIST, “AI Risk Management Framework”: https://www.nist.gov/itl/ai-risk-management-framework
- NIST, “AI RMF Playbook”: https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
Free resources
If this article was useful, start with the free resources too
It is the simplest way to move from reading to testing: download a resource, try it in your own context, and decide later if you want to go deeper with the ebook.