RFP para agente de IA: como montar os requisitos

Uma RFP ruim transforma fornecedores diferentes em preços incomparáveis

A empresa decide buscar um agente de IA e envia um pedido curto: integrar ao CRM, automatizar o atendimento, consultar documentos ou apoiar o financeiro. Cada fornecedor interpreta o objetivo com sua própria arquitetura. Um oferece licença. Outro propõe desenvolvimento. Outro inclui diagnóstico, integração, operação e suporte.

As propostas chegam com nomes, prazos e preços diferentes. A liderança tenta comparar telas e funcionalidades porque o pedido original não definiu a unidade de trabalho, o resultado esperado, as exceções nem as responsabilidades depois da implantação.

Uma RFP, sigla de request for proposal, organiza a contratação antes da demonstração. Ela descreve o problema operacional, delimita o trabalho, expõe dependências e estabelece como as propostas serão avaliadas.

O documento não precisa fingir que todas as decisões técnicas já foram tomadas. Ele precisa deixar claro o que a empresa sabe, o que ainda depende de descoberta e que evidência permitirá avançar.

Quando vale usar uma RFP para agente de IA

Uma RFP ajuda quando a contratação envolve várias áreas, sistemas críticos, dados sensíveis, fornecedores concorrentes ou investimento que exige governança formal.

Ela costuma ser útil quando:

mais de um fornecedor será comparado;
o agente precisará consultar ou alterar sistemas;
existem ações externas, como enviar mensagens ou criar registros;
a qualidade precisa ser demonstrada com casos reais;
segurança, privacidade ou conformidade afetam o desenho;
licenças, consumo, infraestrutura e suporte compõem o custo;
a solução continuará operando depois do projeto;
a empresa precisa registrar critérios de seleção e aceite.

Para uma descoberta curta com um único parceiro, uma solicitação de proposta enxuta pode bastar. Mesmo nesse caso, problema, escopo, resultado, dados e responsabilidades devem permanecer explícitos.

A RFP fica prematura quando a empresa ainda não escolheu que perda pretende atacar. Nessa situação, o trabalho inicial é diagnóstico e priorização. O guia sobre como priorizar investimentos em IA ajuda a comparar oportunidades antes de financiar uma solução.

Comece pela unidade de trabalho

“Implementar IA no atendimento” permite interpretações demais. “Classificar chamados recebidos por e-mail, reunir o histórico do cliente e encaminhar cada caso para a fila correta” delimita uma unidade de trabalho.

A unidade é o objeto que atravessa o processo. Pode ser:

chamado triado;
lead qualificado;
reunião preparada;
pedido validado;
documento revisado;
título conciliado;
proposta aprovada;
cadastro atualizado.

Descreva a unidade com exemplos e fronteiras. Informe onde começa, qual desfecho conta como conclusão e que situações ficam fora do primeiro escopo.

Para um agente de triagem, por exemplo:

entrada: mensagem, identificação do cliente e anexos;
saída: categoria, urgência, resumo, fila e informação faltante;
conclusão válida: caso registrado na fila correta com evidência;
fora do escopo: responder reclamações graves, assumir compromisso financeiro ou encerrar caso sem revisão.

Essa definição orienta arquitetura, prazo, avaliação e preço. Também impede que uma demonstração de conversa seja confundida com o processo concluído.

Estrutura recomendada da RFP

Uma RFP útil pode ser organizada em doze blocos.

1. Contexto da empresa e do processo

Apresente somente o contexto necessário para o fornecedor entender o trabalho:

área responsável;
objetivo do processo;
usuários envolvidos;
volume aproximado;
canais de entrada;
sistemas atuais;
principais perdas;
restrições relevantes;
responsável pela contratação.

Evite transformar essa seção em apresentação institucional. O fornecedor precisa entender a operação que será alterada.

2. Problema e linha de base

Descreva o que acontece hoje com evidência disponível. Exemplos:

chamados aguardam classificação;
vendedores gastam tempo reunindo histórico;
pedidos retornam por dados ausentes;
documentos exigem conferência repetitiva;
exceções chegam tarde ao responsável;
decisões ficam sem registro.

Inclua a linha de base quando existir:

volume por período;
tempo de ciclo;
tamanho da fila;
taxa de retrabalho;
incidência de erro;
custo operacional;
resultado comercial ou de atendimento relacionado.

Não invente precisão. Informe lacunas e peça ao fornecedor um método para medi-las durante a descoberta.

3. Objetivo e resultado esperado

Escreva o resultado em linguagem operacional. Alguns exemplos:

reduzir o tempo até a triagem válida;
aumentar pedidos completos na primeira passagem;
preparar reuniões com contexto verificável;
diminuir trabalho manual de conciliação;
reduzir casos sem próxima ação;
ampliar volume sem contratar na mesma proporção.

Separe resultado desejado de meta contratual. Se a empresa ainda não possui linha de base confiável, a primeira fase deve produzir a medida e uma hipótese de ganho.

4. Escopo funcional

Liste o que o agente deverá fazer por classe de ação:

consultar;
extrair;
classificar;
resumir;
recomendar;
preparar;
registrar;
executar;
monitorar;
escalar.

Para cada ação, informe a saída esperada e o sistema de destino. “Integrar ao CRM” fica mais claro como “localizar a oportunidade, consultar histórico, preparar próxima ação e gravar campos aprovados após revisão do vendedor”.

Inclua exclusões. Escopo legível protege a empresa de expectativa implícita e o fornecedor de responsabilidade que nunca foi estimada.

5. Fluxo, exceções e alçadas

Forneça um mapa simples do processo atual ou peça que ele seja construído na descoberta. O mapa deve mostrar:

evento de entrada;
etapas;
decisões;
sistemas;
esperas;
responsáveis;
exceções;
saída;
evidência de conclusão.

Liste casos que exigem tratamento especial. Dados conflitantes, cliente estratégico, valor alto, documento ilegível, regra ausente, baixa confiança e falha de integração são exemplos comuns.

Defina também as alçadas. O agente pode preparar uma decisão, enquanto aprovação comercial, financeira, jurídica ou de segurança permanece com a pessoa autorizada.

O artigo sobre aprovação humana em agentes de IA oferece critérios para distribuir revisão sem criar uma fila inútil.

6. Dados e fontes de autoridade

Inventarie as fontes conhecidas:

| Informação | Sistema atual | Autoridade | Forma de acesso | Qualidade conhecida | |---|---|---|---|---| | cliente | CRM | cadastro comercial | API | duplicidades ocasionais | | pedido | ERP | operação | API | campos obrigatórios definidos | | política | base documental | área responsável | busca | revisão periódica necessária | | pagamento | sistema financeiro | financeiro | API ou arquivo | janela de atualização conhecida |

Peça ao fornecedor que explique:

como identifica registros;
como trata divergências;
quais dados serão copiados;
onde contexto temporário e memória serão armazenados;
como funciona retenção e exclusão;
como mudanças nas fontes serão detectadas;
que acesso é necessário em cada fase.

A engenharia de contexto para agentes de IA ajuda a distinguir acesso amplo de contexto útil para uma unidade específica.

7. Integrações e ambiente técnico

Descreva sistemas, APIs, autenticação, ambientes de teste e limitações já conhecidas. Informe se existem:

sandbox;
limites de API;
webhooks;
exportações por arquivo;
sistemas sem integração;
autenticação corporativa;
requisitos de rede;
infraestrutura preferida;
restrições de hospedagem;
padrões de observabilidade.

Peça uma matriz de integração com operações de leitura e escrita. O fornecedor deve separar o que está comprovado, o que depende de validação e o que exigirá alternativa manual ou automação de interface.

Quando a comparação inclui hospedagem, consulte VPS, SaaS ou nuvem para agentes de IA.

8. Segurança, privacidade e governança

A RFP deve pedir respostas operacionais, não apenas declarações genéricas.

Inclua requisitos para:

identidade do agente;
credenciais separadas de contas pessoais;
acesso mínimo por ferramenta;
segregação entre ambientes;
criptografia;
retenção e exclusão;
tratamento de dados pessoais;
registro de consultas e ações;
aprovação humana;
bloqueio e interrupção;
gestão de versões;
resposta a incidentes;
subcontratados e provedores de modelos;
portabilidade e encerramento.

Peça que o fornecedor descreva quem pode alterar instruções, ferramentas, fontes e permissões. Uma solução segura na implantação pode acumular risco se mudanças posteriores não tiverem controle.

9. Avaliação e critérios de aceite

Defina como a solução será testada antes da produção. O conjunto deve incluir:

casos comuns;
entradas incompletas;
dados conflitantes;
documentos difíceis;
exceções da política;
falha de integração;
tentativa de ação sem permissão;
casos que exigem escalonamento;
situações de alto impacto;
repetição da mesma solicitação.

Para cada caso, registre resultado esperado, erro impeditivo, tolerância e evidência. Métricas médias não podem esconder falhas críticas.

Peça ao fornecedor uma proposta de teste em três níveis:

avaliação offline com casos históricos;
modo sombra no fluxo real, sem executar ações externas;
produção limitada com usuários e classes de caso definidos.

O guia sobre como avaliar agentes de IA detalha casos, critérios e regressão.

10. Métricas e decisão de continuidade

A RFP deve ligar medição a uma decisão. Exemplos de dimensões:

adoção dentro do fluxo;
tempo por unidade;
volume concluído;
qualidade e retrabalho;
erros críticos;
escalonamento correto;
custo por unidade válida;
disponibilidade do processo;
incidentes;
capacidade liberada;
resultado de negócio relacionado.

Defina quem fornece cada dado e qual período será comparado. Também registre as opções ao fim do piloto: ampliar, corrigir, restringir, pausar ou encerrar.

O artigo sobre scorecard de IA para empresas organiza essas dimensões para acompanhamento executivo.

11. Implantação, adoção e suporte

Peça um plano que cubra o trabalho depois da demonstração:

descoberta;
desenho do processo;
preparação de dados;
construção;
testes;
treinamento;
entrada em produção;
monitoramento;
suporte;
manutenção;
revisão periódica;
desligamento.

Defina responsabilidades da empresa e do fornecedor. Atraso em acesso, amostra, aprovação e disponibilidade de usuários afeta o cronograma. A proposta deve tornar essas dependências visíveis.

Para suporte, peça canais, horários, severidades, tempos de resposta, escalonamento e responsabilidade por cada camada. O artigo sobre SLA para agentes de IA mostra por que disponibilidade técnica não garante trabalho concluído.

12. Modelo comercial e custo total

Solicite preços separados para:

diagnóstico;
implementação;
plataforma;
consumo de modelos;
infraestrutura;
conectores;
usuários;
armazenamento;
monitoramento;
suporte;
manutenção;
treinamento;
mudanças de escopo;
saída e migração.

Peça premissas de volume e faixas de variação. Uma estimativa sem unidade de consumo dificulta prever o custo quando o uso cresce.

Compare o custo por capacidade entregue, considerando revisão humana e operação. O guia sobre quanto custa um agente de IA ajuda a montar o envelope econômico.

Requisitos obrigatórios, desejáveis e abertos

Classifique cada requisito para evitar uma RFP que exige tudo e não prioriza nada.

Obrigatório

Sem esse item, a proposta não atende a uma restrição real. Exemplos: residência de dados exigida, integração com sistema específico, trilha de auditoria ou aprovação antes de envio externo.

Desejável

Aumenta valor ou reduz esforço, mas pode ser negociado. Exemplos: interface dentro do CRM, painel pronto ou conector adicional.

Aberto à solução

A empresa descreve o resultado e permite que o fornecedor proponha a arquitetura. Exemplos: estratégia de recuperação de contexto, combinação de regras e modelos ou mecanismo de avaliação contínua.

Obrigatórios demais eliminam alternativas úteis. Requisitos vagos demais transferem toda a definição para quem quer vender. A classificação mostra onde a empresa possui uma restrição e onde espera julgamento técnico.

Como comparar as propostas

Defina pesos antes de receber as respostas. Um exemplo inicial:

| Critério | Pergunta de avaliação | Evidência esperada | |---|---|---| | compreensão do problema | o fornecedor entendeu a unidade, a perda e as exceções? | mapa e premissas | | aderência funcional | a solução cobre o fluxo e as saídas exigidas? | matriz de requisitos | | arquitetura | fontes, memória, ferramentas e registro formam um sistema coerente? | diagrama e responsabilidades | | qualidade | os testes representam o trabalho real? | plano e conjunto de avaliação | | segurança | permissões e ações possuem controle verificável? | matriz de acesso e logs | | implantação | dependências, fases e aceite estão claros? | cronograma e marcos | | sustentação | existe dono para suporte, manutenção e evolução? | modelo operacional | | economia | o custo total e suas variações estão visíveis? | planilha de premissas | | portabilidade | a empresa consegue trocar componentes ou fornecedor? | plano de saída |

A pontuação serve para organizar julgamento. Critérios impeditivos permanecem separados. Uma proposta não deveria compensar ausência de controle de acesso com preço menor ou apresentação melhor.

O guia sobre como contratar uma consultoria de IA aprofunda perguntas comerciais, sinais de alerta e estrutura do primeiro contrato.

O que pedir na resposta do fornecedor

Padronize o formato para facilitar a comparação:

entendimento do problema;
escopo atendido e exclusões;
solução proposta;
arquitetura e integrações;
requisitos atendidos, parciais e não atendidos;
plano de descoberta e implantação;
avaliação e critérios de aceite;
segurança e governança;
equipe e responsabilidades;
suporte e manutenção;
cronograma com dependências;
preços e premissas;
riscos e decisões pendentes;
referências e evidências;
plano de portabilidade e encerramento.

Peça que dúvidas sejam enviadas em uma rodada comum. Respostas dadas apenas a um concorrente distorcem a comparação.

Erros comuns ao escrever a RFP

Descrever uma ferramenta em vez do trabalho

Exigir “chatbot com modelo avançado” direciona a solução sem explicar que resultado o processo precisa produzir.

Pedir automação completa

Autonomia ampla esconde classes de ação diferentes. Leitura, recomendação, escrita e contato externo precisam de limites próprios.

Esconder a qualidade dos dados

O fornecedor precifica uma integração ideal e encontra cadastros duplicados, documentos vencidos ou identificadores incompatíveis depois do contrato.

Tratar o piloto como demonstração

Uma interface funcionando com exemplos escolhidos não prova qualidade em volume, exceções e falhas.

Deixar suporte para depois

O agente depende de modelos, fontes, integrações e regras que mudam. Sem manutenção, a solução perde qualidade enquanto continua parecendo disponível.

Comparar apenas o valor inicial

Licença barata pode carregar consumo, revisão, integração e dependência. Desenvolvimento maior pode gerar portabilidade ou apenas transferir manutenção para a empresa. O custo total precisa acompanhar a responsabilidade.

Exigir precisão sem definir erro

Uma meta isolada de acerto mistura falhas triviais e críticas. Defina o resultado esperado por classe de caso e o que bloqueia produção.

Checklist antes de enviar a RFP

A unidade de trabalho está definida?
O início e o desfecho do processo estão claros?
Existe linha de base ou plano para produzi-la?
Escopo e exclusões estão registrados?
As exceções mais importantes foram incluídas?
Cada dado possui fonte e autoridade conhecidas?
Operações de leitura e escrita estão separadas?
Alçadas humanas aparecem no fluxo?
Segurança está descrita em controles verificáveis?
O conjunto de testes representa casos reais?
Critérios de aceite e erros impeditivos estão claros?
O custo total usa premissas de volume?
Suporte, manutenção e saída possuem responsáveis?
O formato de resposta permite comparação?
Pesos e critérios impeditivos foram definidos antes das propostas?

A RFP deve reduzir incerteza antes de comprar tecnologia

Uma boa RFP transforma intenção em um problema delimitado, uma unidade de trabalho, fontes de autoridade, classes de ação, controles e evidências de aceite. Ela melhora as propostas porque força decisões que uma demonstração tende a esconder.

Ainda haverá descoberta. Sistemas podem limitar integrações, dados podem exigir correção e exceções podem alterar o escopo. O documento precisa tornar essas incertezas administráveis, com responsáveis e marcos de decisão.

Quando problema, arquitetura e operação aparecem no mesmo pedido, a empresa consegue comparar fornecedores pelo que realmente comprará: capacidade de executar um processo com qualidade, controle e continuidade.