A tese numa frase: uma política que não se consegue executar não é uma política, é uma declaração de desresponsabilização. Serve para mostrar numa auditoria e não serve para mudar o que o sistema faz na terça-feira à tarde. A diferença entre as duas coisas não é o rigor com que está escrita: é se alguém traduziu cada frase numa condição que uma máquina consegue verificar antes de deixar sair uma ação.
Uma política de uso de IA na empresa que não se consegue executar não é uma política
O padrão repete-se em todas as empresas que já passaram a fase do entusiasmo. Alguém redige a política de uso de IA na empresa — seis páginas, bem escritas, revistas pelo jurídico —, sobe-se à intranet, comunica-se por email e dá-se o assunto por encerrado. Três meses depois há agentes a escrever a clientes, a comprometer montantes e a publicar afirmações sobre o produto, e nenhuma dessas ações passa por nada que se pareça com o que diz o documento. Não porque alguém o incumpra de propósito: porque o documento nunca foi ligado a nada.
O género literário está saturado da parte fácil. Há modelos, checklists e guias sobre o que é preciso documentar: âmbito, papéis, usos proibidos, classificação de risco, responsável. Tudo isso é necessário e nenhum desses textos explica a parte que custa, que é esta: como é que aquela frase escrita em português se transforma numa verificação que corre em produção e que consegue parar uma ação. Esse salto é o trabalho a sério, e é o que quase nunca se faz.
Convém dizê-lo sem rodeios porque há dinheiro pelo meio: uma política que só existe em PDF não te protege de nada, salvo, com sorte, de uma parte da responsabilidade. Não evita o erro, não o deteta e não deixa rasto de que se tentou evitá-lo. Se o que queres é que a IA se comporte, há que baixar o documento três níveis: de princípio a regra, de regra a condição verificável, e de condição a prova.
Passo 1: decompor a obrigação em condições verificáveis
Pega em cada frase da política e faz-lhe uma só pergunta: o que teria de ser verdade, numa ação concreta, para esta frase estar a ser cumprida? Se a resposta é longa, ambígua ou depende do critério de quem olha, a frase ainda não é uma regra: é uma intenção. Há que parti-la até cada pedaço ser verificável com um sim ou um não.
Um exemplo típico. «A IA será usada de forma transparente com os clientes» não é verificável. Decomposta, transforma-se em três condições que já o são: em toda a conversa iniciada por um sistema automático, a primeira mensagem declara que é um sistema automático; em qualquer canal onde o cliente possa pedir uma pessoa, existe uma via visível para o fazer; e nenhuma mensagem afirma ou insinua que quem a escreve é uma pessoa concreta da equipa. Três condições, três verificações possíveis. O princípio original continua lá, mas agora já dá para o pôr em código.
Dois avisos sobre este passo. O primeiro: a decomposição é onde se tomam as decisões difíceis, não na redação do princípio. «Transparente» soa a que estamos todos de acordo; «a primeira mensagem declara que é um sistema automático» abre uma discussão a sério sobre marketing, conversão e tom. Essa discussão tem de acontecer, e tê-la aqui é muito mais barato do que tê-la depois de um incidente. O segundo: se uma obrigação não se consegue decompor em condições verificáveis, escreve-o também. Há obrigações que só se cumprem com critério humano, e marcá-las como tal é informação útil, não um fracasso.
Passo 2: decidir com que prova se verifica cada condição
Uma condição sem prova atribuída é uma condição que ninguém verifica. E aqui aparece o enviesamento que arruína a maioria das tentativas: se a prova é escolhida por quem a tem de implementar, vai escolher a fácil de obter, não a que de facto demonstra o cumprimento. É humano e é previsível, por isso corrige-se por desenho.
Para cada condição há que fixar três coisas: que dado a demonstra, em que momento se olha e quem responde se faltar. A prova pode ser muito simples — o texto da primeira mensagem enviada, o montante do campo da operação, a lista de fontes que o sistema usou para redigir — e quanto mais simples, melhor: uma verificação que só funciona se todo o pipeline estiver saudável não é uma verificação, é uma esperança.
O momento importa tanto como o dado. Não é o mesmo verificar antes de executar — o sistema para e não acontece nada — e verificar depois — o sistema age e tu ficas a saber. As duas são válidas e não custam o mesmo. A regra prática: tudo o que for irreversível ou visível para o cliente verifica-se antes; o resto pode verificar-se depois, desde que exista alguém a olhar para o registo e um prazo escrito para o olhar. Os mecanismos que tornam isto possível — registo, permissões com âmbito, travão de mão e auditoria — estão desenvolvidos em governação e controlo da automatização com IA; o que aqui acrescentamos é a parte de cima: o que se verifica e porquê, não com que se verifica.
Passo 3: definir o que acontece quando falha
Este é o passo que quase ninguém escreve e o único que decide se o controlo existe mesmo. Uma verificação sem consequência definida acaba sempre no mesmo sítio: um aviso num painel que ninguém abre. Para cada condição há que decidir, com antecedência, uma de quatro respostas: bloqueia-se a ação, escala-se para uma pessoa com o caso já montado, regista-se e deixa-se passar, ou degrada-se para uma versão mais conservadora da mesma ação.
Escolher «bloquear» para tudo é tão mau desenho como escolher «registar» para tudo. Bloquear tudo torna o sistema inútil e a organização aprende rapidíssimo a contorná-lo; registar tudo produz um arquivo perfeito de incumprimentos que ninguém leu. A pergunta que ordena a escolha é a do costume: quanto custa o erro e quanto tempo demora a ver-se. Erro caro e visível, escalar. Erro caro e invisível, bloquear. Erro barato e visível, registar. E uma condição extra de que toda a gente se esquece: a resposta «escalar» só é legítima se houver capacidade humana real para atender esse volume. Se escalas mais casos do que a tua equipa consegue olhar, a fila aprova-se em bloco sem leitura, o que é pior do que não ter controlo, porque ainda por cima gera um registo falso de revisão. É exatamente o problema que se aborda em supervisão humana de IA à escala.
Três exemplos concretos e baratos por onde começar
Não é preciso pôr em código a política inteira para o exercício valer a pena. Três controlos bem escolhidos cobrem a maior parte do risco real de uma empresa que começa, e os três implementam-se em dias, não em trimestres.
- Avisar que é IA. Condição: toda a conversa iniciada ou mantida por um sistema automático declara que o é na primeira mensagem. Prova: o texto enviado. Momento: antes de enviar. Falha: bloqueia-se o envio. Além de ser o correto, desde 2 de agosto de 2026 há uma obrigação de transparência europeia aplicável aos sistemas destinados a interagir diretamente com pessoas, que devem ser concebidos de forma a que a pessoa saiba que está a interagir com uma IA, salvo se for óbvio. Fonte: Comissão Europeia, Transparency obligations under Article 50 of the AI Act (Regulamento (UE) 2024/1689), consultado a 14 de setembro de 2026. Convém veres isto com a tua assessoria jurídica: o âmbito e a figura que te aplica — fornecedor ou responsável pela implementação — dependem do teu caso, e isto não é aconselhamento jurídico.
- Limite de montante que um agente pode comprometer. Condição: nenhuma ação que comprometa dinheiro ultrapassa o limite fixado por operação e por dia. Prova: o montante do campo, mais um acumulado diário. Momento: antes de executar. Falha: escala para uma pessoa com o caso montado. É o controlo mais barato de todos e o que mais gente descobre tarde, normalmente depois do primeiro susto.
- Afirmações que exigem fonte aprovada. Condição: qualquer mensagem ao cliente que contenha um dado de produto, preço, prazo ou condição apoia-se numa fonte de uma lista aprovada. Prova: as fontes que o sistema recuperou para redigir. Momento: antes de enviar. Falha: degrada — o sistema envia uma resposta sem esse dado e oferece passagem a uma pessoa — em vez de bloquear, que aqui seria exagerado.
Repara no que têm em comum: os três exprimem-se numa linha, os três têm uma prova óbvia e os três têm uma consequência diferente. Essa assimetria é o sinal de que o exercício foi bem feito. Se os três acabassem em «bloquear», é porque ninguém parou para pensar no custo de cada erro. O âmbito do que o agente pode tocar para começar é outra decisão deste mesmo exercício, e está em que permissões dar a um agente de IA.
O erro caro: deixar que a política a escreva só a engenharia
Quando a tradução de política para controlo é delegada por inteiro na equipa técnica, acontece uma coisa perfeitamente razoável e perfeitamente errada: acaba por se verificar o que é fácil de verificar, não o que a política obriga. O resultado tem bom aspeto — há regras, há registos, há painéis — e deixa de fora precisamente o que mais importa, porque o que mais importa quase nunca é o mais mensurável.
Vê-se em detalhes pequenos. Verifica-se que a mensagem não ultrapassa um comprimento, e não que não promete um prazo que não consegues cumprir. Verifica-se que a resposta cita uma fonte, e não que a fonte esteja aprovada. Verifica-se que a operação tem um montante, e não que esse montante respeita o limite que alguém decidiu num comité. Cada uma dessas verificações está correta e nenhuma é a que a política pedia.
O antídoto é de processo, não de tecnologia: a decomposição do passo 1 é feita por quem é dono da obrigação — negócio, jurídico, operações — e a prova do passo 2 acorda-se entre essa pessoa e quem a vai implementar. A engenharia tem direito de veto sobre o impossível e não sobre o incómodo. E o documento final assina-se dos dois lados, com data. Sem essa assinatura cruzada, o que existe não é uma política executável: é uma lista do que deu jeito medir.
Há uma nuance de ordem que também convém respeitar, e vai contra o que parece óbvio: a política não se escreve primeiro. Escreve-se quando já sabes o que estás a regular, e isso descobre-se a olhar para o que a tua gente já faz com a IA sem pedir autorização — o argumento completo está em porque proibir o shadow AI não funciona. Uma política redigida antes desse inventário regula uma empresa imaginária.
Como é uma política executável quando está terminada
Não se parece com um documento jurídico. Parece-se com uma tabela, e cabe numa página por cada área. Cada linha tem seis colunas: a obrigação de onde sai, a condição verificável, a prova, o momento em que se olha, o que acontece se falhar, e quem responde. Por baixo, uma lista à parte com as obrigações que decidiste não serem automatizáveis e que por isso dependem de uma pessoa, com o nome dela e a cadência de revisão.
Essa tabela tem uma propriedade que o PDF não tem: consegue auditar-se contra a realidade. Pegas numa linha, pegas num caso da semana passada e verificas se a condição foi avaliada, com que prova e o que aconteceu. Ou sai o registo, ou a linha é mentira. É um teste de cinco minutos e é a única forma honesta de saber se a tua política de uso de IA na empresa está viva ou é decoração.
E tem outra: envelhece de forma visível. Quando muda uma obrigação, muda uma linha e vê-se que controlos há que mexer. Quando o PDF muda, não muda nada, porque não estava ligado a nada. Por isso o entregável que deixamos em adoção de IA para equipas não é o documento: é essa tabela, com dono e data de revisão, e os controlos do primeiro troço já montados. O documento continua a fazer falta — tem de se poder mostrar —, mas é a consequência do trabalho, não o trabalho.