Como criar acordos de uso de IA para equipes

Em uma mesma equipe, uma pessoa usa inteligência artificial para gerar testes, outra para revisar arquitetura e outra evita a ferramenta por medo de errar. Sem um acordo de uso de IA no desenvolvimento, essas práticas viram critérios individuais. O limite precisa ficar visível: o que pode, o que exige supervisão, o que não pode e como tratar exceções.

Quando o uso de IA vira ruído operacional

A equipe percebe o ruído antes de nomeá-lo. Um pull request chega com uma solução aparentemente correta, mas ninguém sabe se a IA influenciou a decisão. Uma pessoa pede ao assistente para explicar um trecho de código legado. Outra cola informações sensíveis em um prompt externo. Uma terceira deixa de usar a ferramenta porque não quer assumir um risco que não foi discutido.

O acordo de uso de IA existe para reduzir essa ambiguidade operacional. Ele não substitui política de segurança, gestão de acesso, revisão técnica, orientação jurídica ou governança de dados. Também não resolve, sozinho, produtividade, qualidade ou maturidade. O papel dele é mais específico: tornar práticas e limites conhecidos o bastante para que a equipe consiga trabalhar sem depender de interpretações individuais a cada tarefa.

Esse ponto importa porque a IA tende a amplificar o que já existe na organização. A apresentação do relatório DORA 2025 descreve a IA como amplificadora de forças e fraquezas existentes e destaca o sistema organizacional como parte relevante do retorno sobre investimento. A fonte não prova que acordos de equipe garantem resultado, mas reforça uma leitura útil: se o processo é confuso, a ferramenta não torna a coordenação magicamente clara.

Por isso, acordos de uso de IA no desenvolvimento funcionam melhor quando ficam próximos do trabalho real. Eles precisam responder a perguntas que aparecem em código, produto, dados, segurança e experiência do usuário. A discussão estratégica mais ampla pode estar em um plano de adoção, como em como criar uma estratégia de inteligência artificial conectada ao negócio. Aqui, a decisão é menor e mais cotidiana: como a equipe deve usar IA amanhã, sem improvisar critérios.

O que precisa entrar em um acordo de uso de IA

Um acordo de equipe pode começar curto. Na prática, ele deve caber em uma página consultável e responder a seis decisões.

Uso autorizado: quais tarefas a equipe pode realizar com IA sem pedir autorização prévia.
Uso supervisionado: quais tarefas exigem revisão humana explícita antes de virar código, decisão ou entrega.
Uso proibido: quais dados, conteúdos, decisões ou comportamentos não podem ser enviados, gerados ou aceitos com IA.
Rastreabilidade suficiente: quando a equipe precisa registrar que a IA influenciou uma decisão.
Responsável por exceções: quem decide casos não previstos e como essa decisão fica documentada.
Gatilho de revisão: quais eventos fazem o acordo mudar.

A especificidade aparece quando o acordo orienta uma dúvida concreta. “Usar IA com bom senso” não basta. “Pode usar IA para rascunhar testes unitários de código próprio, desde que a revisão do comportamento esperado seja feita pela pessoa responsável pela mudança” já estabelece um limite operacional.

Da mesma forma, “não enviar dados sensíveis” pode ser insuficiente se a equipe não explicitar quais tipos de dados aparecem no seu contexto. Credenciais, tokens, informações de clientes, dados internos sem autorização e trechos proprietários com restrição de compartilhamento precisam ser tratados de forma mais concreta. O acordo não precisa listar todo cenário possível, mas deve reduzir a margem para interpretações perigosas.

Esse tipo de clareza também ajuda a separar acordo de uso de IA de capacitação. Capacitar desenvolvedores é ensinar critérios, técnicas e revisão crítica, tema diferente de definir combinados operacionais. Se a dúvida principal for formação, vale conectá-la a uma discussão como liderança e humano ampliado. Se a dúvida for autorização, limite e exceção, o acordo é o artefato correto.

Como separar uso livre, uso supervisionado e uso bloqueado

A forma mais simples de começar é classificar usos em três grupos: livre, supervisionado e bloqueado. Essa classificação evita dois extremos comuns: liberar tudo porque a ferramenta parece útil ou bloquear tudo porque a organização ainda não domina todos os riscos.

Uso livre é adequado para tarefas de baixo risco, reversíveis e fáceis de revisar. Exemplos: pedir explicação de um conceito técnico público, rascunhar testes para uma função já compreendida, comparar alternativas de nomenclatura, resumir uma documentação interna autorizada ou gerar ideias de perguntas para uma revisão técnica. Mesmo nesses casos, livre não significa automático. A pessoa continua responsável pelo que aceita.

Uso supervisionado envolve decisões que podem afetar arquitetura, segurança, dados, regras de negócio ou experiência do usuário. Aqui entram sugestões de refatoração com impacto amplo, desenho de fluxos críticos, análise de causa provável de incidentes, interpretação de métricas de produto e mudanças em regras que afetam comportamento percebido pelo usuário. A IA pode apoiar a exploração de alternativas, mas a decisão precisa ser revisada por alguém com responsabilidade técnica ou de produto.

Uso bloqueado cobre situações em que a equipe não consegue avaliar o risco ou não tem autorização para expor o conteúdo. Enviar credenciais, colar dados de clientes, aceitar código sem revisão, delegar decisão de segurança sem validação humana ou usar uma ferramenta sem clareza de tratamento dos dados são exemplos de limites que devem ficar explícitos. O bloqueio não é uma declaração contra IA. É uma forma de preservar julgamento onde a equipe ainda não tem controle suficiente.

Um critério prático é perguntar: se a resposta da IA estiver errada, quem percebe, em quanto tempo e com qual dano potencial? Se a resposta for “qualquer pessoa da equipe percebe antes de integrar”, o uso tende a ser livre. Se for “só alguém experiente percebe depois de afetar arquitetura, dados ou usuário”, o uso deve ser supervisionado ou bloqueado.

Como documentar o acordo para ele ser encontrado e confiável

O acordo não deve viver em uma conversa perdida no chat. Também não precisa virar um documento extenso que ninguém consulta. Ele deve estar no mesmo ambiente em que a equipe busca práticas de engenharia, onboarding, revisão de código e decisões recorrentes.

O DORA trata qualidade de documentação por atributos como clareza, facilidade de localização e confiabilidade, além de recomendar criação e manutenção ativa da documentação, conforme a página sobre qualidade da documentação. Essa referência não valida um formato específico de acordo de IA, mas oferece critérios úteis para avaliar se o combinado será encontrado e usado.

Um acordo confiável deixa claro:

quem mantém o documento;
quando ele foi revisado pela última vez, se essa informação existir no repositório ou ferramenta usada;
quais decisões estão vigentes;
como propor ajuste;
onde registrar exceções relevantes;
quais documentos relacionados precisam ser consultados, como segurança, dados e revisão de código.

Evite transformar o acordo em um arquivo genérico chamado “IA”. Um nome como “Uso de IA na squad de produto” ou “Acordo de IA em engenharia” facilita busca e reduz ambiguidade. Se a organização já tem uma página sobre maturidade ou governança, como maturidade em IA: como diagnosticar o ponto de partida da organização, o acordo de equipe pode apontar para ela. Mas o caminho inverso também precisa existir: documentos mais amplos devem levar a combinados práticos.

O ponto não é pedir que as pessoas confiem na IA, nem que confiem cegamente no julgamento individual. É manter o limite disponível antes da decisão.

Como transformar exceções em aprendizagem, não em improviso

Nenhum acordo cobre tudo. Ferramentas mudam, modelos mudam, dúvidas aparecem, produtos evoluem. Por isso, exceções precisam ter um caminho definido. Sem esse caminho, a equipe cria uma governança informal: quem tem mais urgência decide, quem tem mais medo bloqueia, quem tem mais influência interpreta.

Um fluxo simples de exceção pode pedir quatro informações:

qual é o caso de uso;
qual dado, código ou decisão será exposto à IA;
qual risco a pessoa enxerga;
qual resultado espera obter.

Com isso, uma liderança técnica, um grupo pequeno ou um papel definido decide se autoriza, nega ou pede ajuste. A decisão deve ser registrada quando criar precedente. Nem toda dúvida precisa virar ata, mas uma exceção que muda o entendimento da equipe precisa ficar disponível para a próxima pessoa.

Também vale separar exceção de experimento. Uma exceção operacional é uma autorização pontual para lidar com um caso não previsto. Um experimento exige hipótese testável, critério de avaliação e alguma forma de medir impacto. A Microsoft descreve sua plataforma ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos, conforme a página da Microsoft Research sobre ExP. Isso não significa que todo feedback retreina um modelo ou que toda tentativa com IA é um experimento.

Essa distinção evita uma confusão comum. Aprender com o uso de IA não é acumular histórias soltas. É transformar dúvida recorrente em ajuste do acordo, hipótese em experimento e incidente em mudança de prática. O DORA também relaciona a cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização, conforme sua página sobre cultura de aprendizagem. Isso não autoriza concluir que todo produto aprende automaticamente. Aprendizagem organizacional precisa de prática, registro e revisão.

Quando revisar os acordos de uso de IA

Revisar o acordo por calendário pode ajudar, mas a cadência sozinha costuma virar burocracia. O mais útil é combinar gatilhos observáveis. O acordo deve ser revisto quando algo muda no risco, no contexto ou no aprendizado da equipe.

Bons gatilhos incluem:

adoção de uma nova ferramenta de IA pela equipe;
mudança relevante de modelo, fornecedor ou configuração;
incidente ou quase incidente envolvendo uso de IA;
repetição da mesma dúvida no canal da equipe;
mudança no tipo de dado usado no produto;
alteração em regras de negócio críticas;
evidência de que o acordo não está sendo seguido;
entrada de pessoas novas que revelam ambiguidade no documento.

O acordo também pode mudar quando a equipe ganha competência. Um uso antes supervisionado pode se tornar livre se a equipe criou bons critérios de revisão e o risco é baixo. O inverso também pode acontecer. Um uso liberado pode ser restringido se surgirem dúvidas, falhas ou exposição indevida.

Aqui, a liderança precisa resistir a dois atalhos. O primeiro é tratar o acordo como punição depois de um erro. O segundo é tratar a revisão como ritual sem consequência. O bom acordo muda quando há aprendizado suficiente para mudar a prática.

Modelo curto para revisar acordos de uso de IA no desenvolvimento

Use este modelo como revisão rápida do acordo antes de apresentá-lo à equipe.

Uso autorizado

Pergunta: quais tarefas a equipe pode realizar com IA sem pedir autorização prévia?

Uma boa resposta cita tarefas específicas, como rascunhar testes, comparar alternativas ou resumir documentação interna autorizada. Uma resposta fraca diz apenas que o uso é permitido para aumentar produtividade.

Uso supervisionado

Pergunta: quais tarefas exigem revisão humana explícita antes de virar código, decisão ou entrega?

Uma boa resposta inclui mudanças em arquitetura, segurança, regras de negócio, dados e experiência do usuário. Uma resposta fraca presume que a revisão de pull request resolve qualquer uso de IA.

Uso proibido

Pergunta: o que não pode ser enviado, gerado ou aceito com IA?

Uma boa resposta define limites claros para dados sensíveis, credenciais, código proprietário sem autorização e decisões que a equipe não consegue auditar. Uma resposta fraca usa frases genéricas como “usar com bom senso”.

Rastreabilidade suficiente

Pergunta: quando a equipe precisa registrar que a IA foi usada?

Uma boa resposta diferencia uso trivial de uso que influencia decisão técnica, comportamento do produto ou análise de risco. Uma resposta fraca exige registro de tudo ou não exige registro de nada.

Responsável por exceções

Pergunta: quem decide casos que não estão previstos no acordo?

Uma boa resposta indica papel ou grupo responsável, prazo de resposta e como a decisão será documentada. Uma resposta fraca deixa cada pessoa resolver individualmente.

Gatilho de revisão

Pergunta: o que faz o acordo mudar?

Uma boa resposta lista gatilhos observáveis, como nova ferramenta, incidente, dúvida recorrente, mudança de modelo ou alteração no tipo de dado usado. Uma resposta fraca prevê revisão apenas quando alguém lembrar.

Exemplo fictício: acordo de IA para uma squad de produto

Imagine uma squad fictícia responsável por uma área de autosserviço em um produto digital. A equipe usa IA em tarefas de engenharia, mas percebe diferenças grandes de prática entre as pessoas. Algumas usam a ferramenta para gerar testes, outras para discutir refatoração, outras evitam qualquer uso por não saberem o que é aceito.

O acordo inicial poderia ficar assim: a equipe permite IA para rascunhar testes unitários, explicar código legado sem dados sensíveis e comparar alternativas de implementação. Exige supervisão para mudanças em regras de negócio, fluxos que afetem a experiência do usuário, decisões de arquitetura e qualquer análise envolvendo dados internos. Bloqueia envio de dados de clientes, credenciais, tokens, logs com identificação indevida e aceitação de código sem revisão humana.

A rastreabilidade também é proporcional. Se a IA ajudou a escrever um teste simples, não há registro separado além do código revisado. Se influenciou uma decisão de arquitetura ou uma regra de negócio, a pessoa registra no pull request ou no documento de decisão que a IA foi usada como apoio, qual alternativa foi considerada e qual critério humano prevaleceu.

As exceções ficam com a liderança técnica da squad e uma pessoa de produto quando houver impacto em comportamento do usuário. Quando a mesma dúvida aparece mais de uma vez, ela vira candidata a ajuste do acordo. A cada ciclo de revisão da equipe, as dúvidas recorrentes são avaliadas.

A hipótese a medir, nesse exemplo fictício, não é “a IA aumentou produtividade”. É mais específica: se o acordo reduz dúvidas repetidas sobre autorização e melhora a qualidade das discussões de revisão. Essa hipótese exigiria evidência própria da equipe, não pode ser presumida.

O próximo passo é documentar um acordo curto, classificar usos em livre, supervisionado e bloqueado, definir exceções e revisar quando houver gatilho real de aprendizado. Assim, o julgamento humano fica desenhado antes que a próxima decisão chegue.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.