IA para organizações sem fins lucrativos: limpe os dados antes do agente

Para a maioria das organizações sem fins lucrativos, o primeiro agente de IA útil é um assistente interno da equipe, e não um chatbot público. Ele pode redigir cartas de agradecimento, resumir exigências de prestação de contas de subvenções e responder perguntas internas sobre escalas de voluntários. Mas isso só é feito com segurança quando os registros de doadores, voluntários e subvenções estão limpos, classificados e acessíveis por permissões restritas. Primeiro limpe os registros, depois defina o que o agente pode ler e alterar, e só então conecte o agente.

Principais pontos

• Comece pelos registros que o agente de fato vai tocar, e não pelo modelo que você gostaria de testar.
• Separe os dados de apoiadores, voluntários e subvenções em níveis de sensibilidade antes de qualquer conexão.
• Dê ao agente uma visão mínima dos registros e permita que ele escreva apenas por ações aprovadas por um membro da equipe.
• Atribua um revisor nomeado a cada resultado que chegue a um doador, a um voluntário ou a um financiador.
• Agende uma revisão de permissões e um procedimento de parada por escrito desde a primeira semana, e não depois do primeiro incidente.

Por que os registros de apoiadores vêm antes do agente

A maior parte dos dados de uma organização sem fins lucrativos nunca foi pensada para ser lida por software. O histórico de doações fica em uma ferramenta de relacionamento, as horas dos voluntários ficam em uma planilha mantida por um único coordenador, e as condições das subvenções ficam em um PDF que o responsável financeiro lembra de cabeça. Cada fonte pode estar correta isoladamente, mas elas costumam divergir em nomes, vínculos familiares, status de consentimento e prazos. Um agente que leia essas fontes dará respostas seguras com base no primeiro registro que encontrar, e a equipe pode não perceber a divergência até que uma carta já tenha sido enviada.

O risco para a privacidade também é maior do que em muitos negócios. A ficha de um apoiador pode revelar capacidade de doação, informações de saúde ou de família escritas em uma observação, afiliações religiosas ou políticas sugeridas por um padrão de doações e o fato de que alguém atua como voluntário junto a um grupo vulnerável. Regras de proteção de dados, como a LGPD no Brasil, tratam boa parte disso como dado pessoal que exige base legal e finalidade clara. Antes que um agente acesse qualquer desses dados, alguém da equipe deve conseguir dizer para que serve cada campo e quem tem permissão para vê-lo.

Existe ainda um risco menos visível. Campos de texto livre, e-mails importados e formulários digitalizados podem conter instruções escritas para uma pessoa, e não para um software. A ficha de inscrição de um voluntário pode trazer uma frase que tenta mudar a forma como o assistente faz o resumo. Trate qualquer conteúdo dentro de um registro como texto a ser lido, nunca como comando a ser obedecido, e desenhe o agente de forma que suas permissões não dependam do que uma observação diz.

Mapeie as três famílias de registros antes de conectar qualquer coisa

Faça um inventário curto para cada família: doadores e apoiadores, voluntários e subvenções. Para cada uma, liste o sistema onde o registro fica, a pessoa responsável por ele, os campos que identificam alguém, os campos que descrevem um relacionamento e os campos que carregam significado sensível. Dê atenção especial aos campos de observações, porque é ali que as pessoas escrevem coisas que nunca colocariam em uma coluna estruturada.

Os registros de subvenções têm outro formato. Eles guardam restrições de gastos, datas de prestação de contas, contatos do financiador e rubricas orçamentárias que precisam bater com as notas fiscais. Um agente que rascunha um relatório de andamento precisa do calendário de entregas e das seções narrativas aprovadas, e não do razão financeiro completo. Separar essas duas necessidades é uma das decisões mais simples de todo o projeto, e é fácil de pular quando o razão financeiro é o único lugar onde os dados parecem completos.

O inventário também é o lugar em que aparecem as perguntas que ninguém respondeu. Quem aprova uma mudança em um indicador de consentimento? Quais voluntários saíram de um programa, mas ainda aparecem em uma lista de turnos? Quais doadores pediram para não receber e-mails, e todos os sistemas sabem disso? Registre essas questões como pendências em aberto. O agente não consegue resolvê-las e, sem perceber, herdará a resposta que os dados atuais sugerem.

Um plano de limpeza de quatro semanas antes de conectar qualquer agente

A sequência abaixo é propositalmente simples. Ela pressupõe uma equipe pequena, com um responsável pelas operações e uma pessoa em meio período que consegue exportar os dados.

• Semana um: exporte uma amostra de cada sistema e liste as duplicidades, os campos de responsável em branco e os indicadores de consentimento conflitantes que encontrar.
• Semana dois: nomeie um responsável por cada campo que será exposto e aposente os campos que ninguém usa ou não sabe explicar.
• Semana três: monte uma visão minimizada para o agente, com identificadores estáveis, status de consentimento e apenas os campos que a primeira tarefa exige.
• Semana quatro: teste essa visão com perguntas reais, mas de baixo risco, como quais subvenções têm relatório no próximo trimestre ou quais funções de voluntariado ainda precisam de verificação de antecedentes, e registre cada resposta errada ou com exposição excessiva.

Ao final da quarta semana, duas coisas precisam ser verdade. Todo campo que o agente pode ler tem um responsável nomeado, e toda ação que ele pode executar tem uma regra de aprovação escrita. Se faltar qualquer uma delas, o agente permanece em modo de teste. É um caminho mais lento do que muitas organizações esperam, mas é o que resiste à primeira pergunta de auditoria de um conselheiro ou de um financiador.

Defina o que o agente pode ver, alterar e nunca tocar

Use uma folha de decisão escrita, com quatro níveis. Mantenha-a curta o suficiente para que um conselheiro consiga lê-la em dez minutos.

• Legível sem aprovação: fatos do programa, calendários públicos de campanhas, prazos de prestação de contas de subvenções e modelos de agradecimento aprovados.
• Legível somente mediante solicitação da equipe: histórico de doadores identificados, dados de contato de voluntários, observações sobre dificuldades financeiras ou de saúde e rubricas de orçamento das subvenções.
• Alterável somente após aprovação: rascunhos de cartas, sugestões de etiquetas em um registro e lembretes propostos. O agente propõe, e uma pessoa confirma.
• Nunca acessível: dados bancários, documentos de identidade e qualquer registro em que o consentimento tenha sido retirado para a finalidade em questão.

Cenário ilustrativo: um banco de alimentos regional, com equipe pequena, quer um agente que ajude a coordenadora de voluntários a preencher os turnos de sábado. A primeira versão lê uma visão minimizada, com primeiro nome dos voluntários, disponibilidade e histórico recente de turnos, e rascunha mensagens de lembrete que a coordenadora envia. O agente não vê observações de saúde, não envia nada por conta própria e não altera a disponibilidade sem confirmação. Quando um voluntário escreve, em um campo livre, que não consegue mais carregar caixas, o agente sinaliza a observação para a coordenadora e a deixa fora do plano de turnos. A coordenadora decide o que acontece em seguida, e o próprio alerta fica registrado para a próxima revisão de permissões.

O padrão desse cenário, com uma visão de leitura restrita, escrita apenas por propostas e um caminho de escalonamento registrado, é o mesmo que uma organização maior usaria para a equipe de grandes doadores. Só muda o tamanho das tabelas.

Como uma abordagem gerenciada mantém esses limites

A Be Human desenha e opera essa camada como um serviço gerenciado. O papel do agente, sua memória, suas ferramentas, suas permissões e seus limites de aprovação são definidos por escrito antes de ele entrar em operação, e o monitoramento, as avaliações recorrentes e as revisões de permissões continuam depois do lançamento. Em um projeto com organização sem fins lucrativos, a equipe mapeia as famílias de registros junto com os responsáveis da organização, monta a visão minimizada e testa o agente com as perguntas que a equipe realmente faz. Mudanças no que o agente pode ler passam por um pedido documentado, de modo que o limite aprovado por um conselho continue valendo até que alguém decida mudá-lo de forma deliberada. A abordagem é a mesma, seja a organização grande ou tenha uma equipe de operações com duas pessoas, mas o escopo do primeiro papel é sempre mantido pequeno.

Para o ritmo de revisão e as evidências, veja como fazer uma revisão de permissões dos seus agentes de IA. Para uma visão de como dados, modelo e ferramentas se encaixam, veja o mapa de arquitetura de uma página para líderes.

Por onde começar neste trimestre

Escolha uma família de registros, de preferência aquela em que a equipe já perde mais tempo copiando informações entre sistemas, e faça a limpeza de quatro semanas somente nela. Deixe os relatórios de subvenções para uma segunda rodada, porque seus prazos e restrições exigem mais revisão antes que um agente possa depender deles. Nomeie um responsável pelas permissões do agente e agende a primeira revisão antes do lançamento, e não depois. Em seguida, escreva uma carta de uma página que defina o papel, os registros que o agente pode ler e as ações que ele só pode propor. Organizações que queiram uma sequência para isso também podem consultar a orientação sobre como escolher os primeiros usuários de um piloto de agente, antes de convidar qualquer pessoa para o teste.

Faça o diagnóstico gratuito de IA da Be Human para encontrar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Um agente de IA pode ler com segurança o nosso banco de doadores? Pode, mas somente se você der a ele uma visão restrita, e não acesso total ao banco. Monte uma visão minimizada, com identificadores estáveis, status de consentimento e os campos que uma tarefa específica exige. Mantenha observações sensíveis fora dessa visão, a menos que um membro da equipe as solicite para uma finalidade declarada.

Precisamos de dados perfeitamente limpos antes de começar? Não é preciso ter dados perfeitos, mas é preciso conhecer os dados dos registros que o agente vai usar. Primeiro encontre as duplicidades, os responsáveis ausentes e os indicadores de consentimento conflitantes nesses campos e resolva-os antes de conectar qualquer coisa. O restante da base pode esperar até que o escopo do agente cresça.

O que o agente pode alterar? Comece somente com propostas, como rascunhos, sugestões de etiquetas e lembretes que um membro da equipe confirma antes de qualquer envio ou gravação. Gravações diretas em registros de doações, indicadores de consentimento ou orçamentos de subvenções devem ficar fora da primeira versão. Qualquer mudança posterior deve passar por uma etapa de aprovação documentada, com um responsável nomeado.

Como saber que o agente continua funcionando corretamente e com segurança depois do lançamento? Defina, antes do lançamento, um pequeno conjunto de perguntas de teste, aplique-as em um calendário fixo e registre cada resposta que um revisor marque como errada ou com exposição excessiva. Revise as permissões em data marcada, e não apenas depois de um incidente, e mantenha por escrito um procedimento para pausar o agente caso surja um problema de privacidade.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.