Pôs o agente de IA em produção. Agora começam as regras
Quando um agente de IA entra em produção, o problema deixa de ser apenas fazê-lo responder bem. É preciso definir, demonstrar e rever o que pode ver e fazer, como as pessoas sabem que estão a interagir com IA, que fornecedores tratam os dados e como a operação é interrompida quando algo corre mal.
Por Reynier RiveroEngenheiro de software
Às 09:17 de uma terça-feira, o agente responde a uma cliente que quer saber se a encomenda ainda chega hoje. Para encontrar a resposta, consulta o CRM, lê a última interação e chama a API de expedição.
O cenário é hipotético, mas o padrão é realista. Durante o piloto, aquelas permissões pareciam convenientes. Em produção, transformam uma resposta automática num conjunto de decisões sobre dados, sistemas e pessoas.
A resposta parece correcta. O problema está no token que tornou tudo isso possível: o mesmo acesso também permite alterar a morada, abrir uma devolução e ler notas internas da equipa comercial.
A pergunta já não é apenas se o agente funciona. É quem decidiu o que ele pode ver, quem autorizou as acções, que fornecedor recebe cada campo, como o cliente é informado e quem consegue carregar no botão de paragem.
A diferença entre um agente demonstrável e um agente operável está nessas respostas.
A produção muda a pergunta
Um protótipo pode trabalhar com uma conta de teste, dados copiados e um operador a observar cada passo. Uma operação real não tem esse conforto: chegam mensagens ambíguas, mudam os dados, falham APIs e alguém acaba por pedir ao agente uma acção que não estava no desenho inicial.
É por isso que o problema não se resolve com um prompt mais cuidadoso. O prompt orienta o comportamento; não substitui permissões, isolamento de dados, registos ou uma política de incidentes.
Há uma diferença entre reconhecer que um agente ganhou acesso e decidir como esse acesso é governado. A questão do excesso de informação é explorada em o agente que respondia bem, mas deixou a empresa a trabalhar à mão; este artigo começa no passo seguinte: o que deve ser controlado depois do lançamento.
O RGPD dá o enquadramento de base. Os princípios incluem licitude, transparência, limitação das finalidades, minimização, limitação da conservação, integridade e confidencialidade, além da responsabilidade demonstrável do responsável pelo tratamento (Regulamento (UE) 2016/679, artigo 5.º).
Faça o inventário do que o agente pode fazer
Comece por escrever cada ferramenta como uma capacidade concreta, não como uma integração genérica.
“CRM” é demasiado vago. “Ler o estado de uma oportunidade” é uma capacidade. “Alterar o proprietário da oportunidade” é outra. “Exportar todas as oportunidades” é uma terceira, com um risco muito diferente.
Como recomendação técnica, uma matriz simples pode mostrar, para cada ferramenta, se o agente pode ler, criar, alterar ou apagar; em que sistema; para que finalidade; com que identidade; em que horário; e com que limite. Uma consulta a uma encomenda não deve herdar automaticamente a permissão para emitir um reembolso.
Use o menor privilégio necessário: separe permissões de leitura e escrita, limite o acesso por cliente ou área, defina a expiração dos tokens e considere uma autorização adicional para acções com impacto financeiro, contratual ou reputacional.
Não faça todas as acções esperar por aprovação humana. Defina, com base no risco, quais podem ser automáticas, quais exigem confirmação e quais devem estar fora do alcance do agente.
Um agente com ferramentas não é apenas uma interface de conversa. É um operador de sistemas com uma identidade, um perímetro e uma responsabilidade.
A implementação de agentes de IA e chatbots deve começar por esse perímetro. Só depois faz sentido discutir qual é o modelo mais adequado ou como melhorar a qualidade das respostas.
Mapeie os dados, não apenas os sistemas
O mapa de dados deve responder a quatro perguntas diferentes: o que o agente pode ver, o que pode utilizar para responder, o que fica guardado e o que pode ser apagado quando deixa de ser necessário.
Um nome e um número de encomenda podem bastar para responder a uma pergunta. O histórico completo do cliente, as notas internas, os dados de facturação e os anexos antigos podem não acrescentar nada àquela finalidade.
A minimização não é apenas uma decisão de base de dados. Pode ser aplicada antes de chamar o modelo, com detecção de dados pessoais, ocultação, tokenização ou selecção de campos. Pode também ser aplicada depois, impedindo que a resposta ou o registo operacional devolva informação que o utilizador não precisava de ver.
O artigo 25.º do RGPD exige que a protecção de dados seja integrada desde a definição dos meios de tratamento e que, por defeito, sejam tratados apenas os dados necessários para cada finalidade, incluindo quanto ao volume, acesso e período de conservação (Regulamento (UE) 2016/679, artigo 25.º).
Na prática, isso inclui o índice documental e a memória do agente. Um vector store partilhado pode misturar contextos de clientes diferentes. Um histórico de conversas sem política de retenção pode transformar uma resposta útil num arquivo permanente de informação pessoal.
A autorização dada numa conversa também não resolve, por si só, a base jurídica, a informação devida, a finalidade ou a conservação do tratamento previstos no RGPD (Regulamento (UE) 2016/679). É um evento da interface; a arquitectura tem de explicar o que acontece antes e depois dele.
Saiba quem trata os dados e para onde vão
Quando existe um fornecedor de modelo, uma plataforma de orquestração, um serviço de observabilidade e vários conectores, “o fornecedor de IA” deixa de ser uma descrição suficiente.
Identifique quem decide as finalidades e os meios do tratamento e quem actua por instruções. Se uma entidade tratar dados pessoais em nome de outra, o artigo 28.º do RGPD exige garantias suficientes e um contrato que especifique, entre outros elementos, objecto, duração, natureza, finalidade, tipos de dados e categorias de titulares (Regulamento (UE) 2016/679, artigo 28.º).
O inventário deve incluir subprocessadores, localização do tratamento, utilização dos dados para melhoria de modelos, retenção de pedidos e respostas, acesso de suporte e processo de eliminação. Se o fornecedor puder adicionar ou substituir outro processador, essa mudança precisa de ser tratada no quadro de autorização e informação previsto no contrato.
Também é necessário mapear transferências para países terceiros. O capítulo V do RGPD estabelece que as transferências devem respeitar as condições aplicáveis e prevê, entre outras vias, decisões de adequação e garantias adequadas, como cláusulas contratuais-tipo (Regulamento (UE) 2016/679, artigos 44.º a 46.º).
Ter um servidor na União Europeia pode ser uma boa decisão de arquitectura, mas não deve ser confundido com uma conclusão automática sobre todo o percurso dos dados. O pedido pode passar por outro fornecedor, por suporte técnico noutra jurisdição ou por uma ferramenta de monitorização diferente.
É aqui que automatização e integrações deixam de ser apenas uma questão de ligar APIs. Cada ligação acrescenta uma identidade, uma superfície de acesso, uma política de conservação e uma pergunta contratual.
Transparência sem teatro
Em regra, o Regulamento Europeu da Inteligência Artificial é aplicável desde 2 de agosto de 2026. A obrigação de adoptar medidas para assegurar um nível suficiente de literacia em IA, prevista no artigo 4.º, aplica-se desde 2 de fevereiro de 2025, nos termos do artigo 113.º (Regulamento (UE) 2024/1689, artigos 4.º e 113.º).
A formação não precisa de transformar toda a equipa em especialistas em modelos. Na terminologia do AI Act, fornecedor é quem desenvolve um sistema ou manda desenvolvê-lo e o coloca no mercado ou em serviço sob o seu nome ou marca; responsável pela implantação (deployer) é quem o utiliza sob a sua autoridade. Os papéis e as obrigações podem ser diferentes, por isso confirme qual descreve a sua operação. A formação deve, pelo menos, explicar o que o agente faz, que fontes consulta, que acções pode executar, quando deve ser escalado e como se comunica um erro ou incidente.
Desde 2 de agosto de 2026, o artigo 50.º impõe ao fornecedor uma obrigação específica de transparência: os sistemas destinados a interagir directamente com pessoas devem ser concebidos e desenvolvidos para as informar de que estão a interagir com um sistema de IA, salvo quando isso seja óbvio para uma pessoa razoavelmente informada, atenta e prudente, considerando o contexto de utilização (Regulamento (UE) 2024/1689, artigo 50.º).
O aviso deve ser pensado para o canal. Num chat, pode aparecer antes da primeira resposta. Numa chamada de voz, precisa de ser audível e compreensível. Num fluxo empresarial, pode ser necessário distinguir o agente que responde do sistema que efectivamente executa uma alteração.
O mesmo artigo distribui obrigações diferentes entre fornecedores e responsáveis pela implantação para conteúdos sintéticos de áudio, imagem, vídeo ou texto, e prevê condições e excepções próprias. Não convém transformar todas essas obrigações numa fórmula universal para qualquer agente.
Também não existe uma regra geral segundo a qual todos os agentes exigem uma AIPD. No artigo 35.º do RGPD, a AIPD é obrigatória quando o tratamento em causa assim o exige, designadamente quando for provável que resulte num elevado risco para os direitos e liberdades das pessoas; a CNPD dá como exemplos determinados tratamentos em larga escala, monitorização sistemática e profiling associado a decisões automatizadas com efeitos significativos (CNPD, Avaliação de impacto sobre a protecção de dados).
A transparência útil não é um aviso decorativo. É permitir que a pessoa compreenda com quem está a interagir, que dados estão a ser utilizados, que decisão ou acção pode ocorrer e como pode chegar a uma pessoa.
Segurança é uma função operacional
O artigo 32.º do RGPD não prescreve uma única tecnologia para todos os casos. Exige medidas técnicas e organizativas adequadas ao risco, podendo incluir pseudonimização, cifragem, confidencialidade, integridade, disponibilidade, resiliência, recuperação e testes regulares da eficácia dessas medidas (Regulamento (UE) 2016/679, artigo 32.º).
Isso pode traduzir-se em controlos concretos: permitir apenas ferramentas previamente autorizadas, validar os parâmetros antes de executar uma escrita, bloquear chamadas para destinos inesperados, separar tenants, proteger segredos fora do contexto do modelo e filtrar dados pessoais dos registos de observabilidade.
As tentativas de prompt injection também devem fazer parte dos testes. Um documento recuperado, uma mensagem recebida ou uma instrução de um utilizador pode tentar convencer o agente a ignorar as regras e a chamar uma ferramenta indevida. Um sistema de prompts bem escrito não é, sozinho, uma fronteira de segurança.
Preveja um caminho de paragem: revogar credenciais, desactivar uma ferramenta de escrita, suspender o fluxo, encaminhar a conversa para uma pessoa e conservar os elementos necessários para perceber o que aconteceu.
O registo não é um confessionário onde se guarda tudo para sempre. É uma ferramenta de controlo que deve capturar o suficiente para reconstruir a decisão sem transformar cada conversa num novo depósito de dados.
O que deve ficar registado
Um registo operacional útil pode associar um identificador de pedido, a versão do agente, a fonte consultada, as ferramentas chamadas, os parâmetros relevantes, o resultado, eventuais aprovações ou recusas e a identidade do operador que interveio.
Isso não significa guardar automaticamente o texto integral de todos os pedidos. Defina uma finalidade, um período e regras de acesso para a retenção; estes critérios devem ser compatíveis com os princípios do RGPD (Regulamento (UE) 2016/679, artigo 5.º).
A rastreabilidade serve para mais do que investigar falhas. Ajuda a detectar deriva: uma nova versão do modelo, um campo acrescentado pela API ou uma alteração no índice pode mudar o comportamento sem que ninguém edite o prompt.
Controlo é um ciclo, não uma aprovação única
Depois do lançamento, alguém tem de ser responsável pelo agente. Não apenas pelo calendário de reuniões, mas pela revisão das permissões, pela actualização das fontes, pela avaliação das mudanças e pela decisão de suspender uma capacidade.
Defina uma rotina proporcional ao risco. Reveja as ferramentas quando mudam as integrações, teste casos representativos antes de uma alteração importante e confirme que a eliminação de dados percorre os sistemas onde o agente os guardou ou replicou.
A passagem para uma pessoa deve ser desenhada como parte do produto. O agente precisa de saber quando não tem confiança suficiente, quando a pergunta sai da sua finalidade, quando a acção ultrapassa o seu limite e que contexto deve entregar ao operador sem expor informação desnecessária.
Do ponto de vista técnico, a supervisão humana e a aprovação antes de executar são possíveis barreiras de controlo, não respostas universais. O AI Act prevê requisitos de supervisão humana para sistemas de risco elevado e atribui deveres específicos ao responsável pela implantação nesses casos; isso não equivale a exigir aprovação humana permanente para todos os agentes (Regulamento (UE) 2024/1689, artigos 14.º e 26.º).
Um fluxo de baixo risco pode funcionar, como recomendação técnica, com limites, registos e revisão posterior. Uma acção com impacto elevado pode justificar confirmação antes da execução. A escolha depende do contexto, dos dados, da finalidade e do risco para as pessoas.
O controlo mais importante é aquele que continua a funcionar numa sexta-feira à tarde, quando a API muda, o fornecedor está indisponível e alguém precisa de desligar o agente sem desligar toda a empresa.
A pergunta antes da próxima integração
Antes de acrescentar mais um conector, tente responder sem consultar o fornecedor: que dados entram no agente, que dados saem, que ferramentas pode chamar, quem é responsável por cada tratamento, onde ocorre o processamento, que aviso vê a pessoa e qual é o caminho para interromper tudo?
Se alguma resposta depender de “deve estar configurado algures”, ainda não há controlo suficiente para aumentar o perímetro.
Este conteúdo é informativo, baseia-se nas fontes citadas e não constitui aconselhamento jurídico. A aplicação concreta depende do tratamento, do sector, das funções do agente e das responsabilidades contratuais; valide o seu caso com um advogado ou profissional de protecção de dados na sua jurisdição.
Se o seu agente já está ligado a dados e sistemas de clientes, a Prontavel pode ajudar a transformar esse perímetro numa arquitectura clara: permissões mínimas, integrações controladas, registos úteis e um caminho de intervenção quando o risco muda.
O serviço de que fala este artigo: Agentes de IA e chatbots que conhecem o seu negócio