Projeto de IA na empresa: riscos que o GP precisa levantar cedo

O termo de abertura chegou com o título "Assistente inteligente para atendimento" e um cronograma de seis meses. Fases de levantamento, desenvolvimento, testes e implantação, como em qualquer projeto de sistema. O sponsor está animado: viu uma demonstração e quer algo parecido rodando antes do fim do ano.

Você lê o documento e algo incomoda. Não há uma linha sobre de onde vêm os dados, o que acontece quando a resposta estiver errada ou quem decide o que é "errado". O plano trata o projeto como se fosse construir um formulário novo.

Esse incômodo é o ponto de partida certo.

Onde projetos de IA costumam tropeçar

Em um sistema tradicional, você define uma regra e testa se ela foi cumprida. Se o cliente digita o CPF, o sistema valida; se valida errado, é defeito. Em projetos que usam IA generativa ou modelos de aprendizado, o comportamento é probabilístico. O sistema pode responder bem na maioria das vezes e, de repente, inventar uma informação com total segurança, o que se chama de alucinação de IA.

Isso muda quase tudo: como se escreve o critério de aceite, como se testa, como se comunica avanço e, principalmente, como se gerencia risco. Quando o projeto é conduzido como software comum, os problemas aparecem tarde, normalmente na homologação ou depois da implantação, quando corrigir custa caro e a confiança do sponsor já foi gasta.

Por que esses riscos ficam escondidos no começo

A demonstração vende uma certeza que o projeto não tem. O sponsor viu a ferramenta funcionar em um exemplo escolhido e saiu convencido de que o resto é implementação. É uma reação compreensível: ele tem pressão para mostrar inovação, e a demonstração deu uma imagem concreta do resultado.

A equipe técnica, por sua vez, pode estar empolgada com a tecnologia e subestimar o trabalho com dados, que é menos interessante e mais demorado. E as áreas de negócio muitas vezes não sabem que precisam participar, porque acham que "é coisa da TI".

O GP também tem sua parte. É confortável usar o modelo de plano que você já conhece. Levantar riscos que ninguém pediu pode soar como pessimismo diante de um projeto que todos querem que dê certo. Só que ficar quieto agora é o que transforma risco em problema mais adiante.

O erro de copiar o plano de sempre

O caminho mais comum é usar o cronograma em cascata de um projeto de sistema, com uma fase de testes no fim e um aceite baseado em "funciona ou não funciona". O resultado é previsível: os testes revelam que o sistema acerta muito, mas erra em casos que o negócio considera graves. Ninguém tinha combinado qual erro era aceitável, então a discussão vira briga entre áreas.

Outro erro frequente é deixar dados, privacidade e uso responsável para "depois que a solução estiver pronta". Nesse ponto, descobrir que a base não pode ser usada daquela forma significa refazer boa parte do trabalho.

Os riscos que valem uma conversa logo no início

Organize o levantamento em blocos, cada um com uma pergunta que precisa de dono:

1. Dados: os dados existem, têm qualidade suficiente e podem ser usados para esse fim? Quem é o dono deles? O artigo sobre dados do projeto em ferramentas de IA ajuda a pensar nessa frente.
2. Comportamento: qual erro é aceitável e qual é inaceitável? Em que situações um humano revisa?
3. Uso e impacto: quem será afetado pelas respostas do sistema? Existe risco de tratamento injusto ou de dano a alguém?
4. Conformidade: segurança da informação, jurídico e compliance já avaliaram o caso de uso?
5. Valor: qual problema de negócio o projeto resolve e como se saberá se resolveu? Sem isso, o business case vira uma promessa vaga.
6. Dependência: o projeto depende de um fornecedor ou de uma tecnologia externa que pode mudar de comportamento, preço ou disponibilidade?
7. Adoção: as pessoas que vão usar o sistema confiam nele o suficiente, ou confiam demais?

Leve essa lista para uma oficina curta com equipe técnica, negócio, segurança e jurídico. Saia com riscos registrados, donos e uma resposta a cada risco relevante. Depois, mantenha a lista viva com a mesma gestão de riscos na prática que você usaria em qualquer projeto, com atenção redobrada aos blocos de dados e comportamento.

Quando o sponsor reage ao levantamento

Se o sponsor achar que você está criando obstáculos, reposicione a conversa: os riscos não são motivos para parar, são o que separa um piloto que impressiona de uma solução que se sustenta. Mostre que levantar cedo é mais barato.

Se a equipe técnica disser que os riscos de comportamento serão resolvidos "ajustando o modelo", peça que isso vire uma hipótese com prazo e critério. "Ajustar" sem métrica combinada pode durar para sempre.

Se a empresa não tiver nenhuma diretriz sobre uso de IA, proponha que o projeto comece com um piloto de escopo reduzido, com usuários internos e revisão humana em todas as respostas. Isso gera aprendizado sem expor clientes.

Se, depois da oficina, ficar claro que o problema de negócio não está bem definido, escreva isso ao sponsor com franqueza. É melhor redefinir agora do que entregar um sistema que ninguém sabe para que serve, cenário discutido no artigo sobre projetos entregues sem valor percebido.

Frases para levantar riscos sem parecer contra o projeto

"Quero que esse projeto saia do piloto e vire algo que a empresa use de verdade. Para isso, preciso de meia hora com você para decidir algumas coisas que normalmente ficam para o fim."

"A demonstração acertou bem. A pergunta que a gente precisa responder agora é: quando errar, qual tipo de erro é aceitável aqui?"

"Antes de fechar o cronograma, quero ouvir segurança e jurídico. Prefiro ajustar o plano agora do que descobrir um impedimento na homologação."

"Como vamos saber, daqui a alguns meses, que isso valeu o investimento? Se a gente não definir agora, vai ser difícil defender o projeto depois."

Sinais para acompanhar ao longo do projeto

Bons sinais: o critério de aceite está escrito em termos de comportamento esperado e tolerância a erro; as áreas de dados e conformidade aparecem nas reuniões sem precisar ser convocadas de última hora; o sponsor fala em "piloto" e "aprendizado" em vez de "lançamento".

Sinais de alerta: testes que só usam exemplos escolhidos pela equipe técnica; ausência de casos de borda no plano de testes; ninguém sabe dizer quem decide quando o sistema erra; e o cronograma não prevê tempo para revisar e ajustar depois do primeiro contato com usuários reais. Quando esses sinais aparecerem, volte à lista de riscos e reavalie com o sponsor.

Exemplo: o assistente que respondia rápido demais

Exemplo ilustrativo (situação fictícia): Roberto assumiu um projeto em uma seguradora de médio porte para criar um assistente que respondesse dúvidas dos corretores sobre coberturas. O plano tinha fases clássicas e o aceite previa "respostas corretas".

Na primeira semana, ele organizou uma oficina de riscos com TI, a área de produtos, jurídico e dois corretores convidados. A discussão revelou que algumas respostas erradas seriam apenas incômodas, enquanto outras, sobre exclusões de cobertura, poderiam gerar reclamações sérias. Também ficou claro que a base de documentos tinha versões antigas misturadas com as atuais.

Roberto levou ao sponsor uma proposta com duas opções: manter o escopo amplo e aceitar mais tempo, ou começar só com dúvidas de baixo risco, revisão humana em temas de exclusão e uma etapa de limpeza da base. Para comparar, usou critérios simples numa matriz. O sponsor escolheu a segunda. O piloto foi menor do que a demonstração prometia, mas chegou à operação com regras claras e apoio do jurídico.

O que o GP ganha olhando um nível acima

Projetos de IA expõem algo que vale para qualquer projeto: o risco mais caro raramente é técnico, é de expectativa. O sponsor imaginou uma coisa, a equipe construiu outra e ninguém combinou o que seria sucesso. O GP que antecipa essa conversa deixa de ser executor de cronograma e passa a ser quem protege o investimento da empresa.

Também há uma mudança de postura. Em vez de prometer certeza, você passa a gerenciar incerteza de forma explícita, com hipóteses, pilotos e critérios de continuidade. Essa habilidade costuma ser muito valorizada por executivos que já viram iniciativas de inovação morrerem depois da demonstração. Para conectar isso ao resultado, o artigo sobre benefícios do projeto ajuda, e o guia de IA para gerentes de projetos amplia o contexto.

Checklist de riscos antes de fechar o plano

• Problema de negócio e indicador de sucesso estão escritos e aprovados pelo sponsor.
• Dono dos dados identificado e uso dos dados avaliado para esse fim.
• Erros aceitáveis e inaceitáveis definidos com o negócio.
• Situações com revisão humana obrigatória estão mapeadas.
• Segurança da informação, jurídico e compliance foram ouvidos.
• Dependências de fornecedores e tecnologias externas registradas como risco.
• Plano prevê piloto com usuários reais e tempo para ajuste.
• Decisões de escopo registradas com dono e data.

A próxima reunião com o sponsor

Antes de aprovar o cronograma, marque trinta minutos com o sponsor só para três decisões: qual problema de negócio o projeto resolve, qual erro é aceitável e quem precisa ser ouvido antes de seguir. Leve as opções organizadas no modelo de matriz de decisão para que a conversa termine com escolhas, não com mais dúvidas.

Se essas três respostas saírem claras, o resto do plano fica muito mais fácil de defender.