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:

1. avaliação offline com casos históricos;
2. modo sombra no fluxo real, sem executar ações externas;
3. 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.

RFP: verificar impeditivos antes de comparar valor e sustentação

Restrições e segurança

Pergunta de avaliação

A proposta atende às restrições obrigatórias de dados, acesso e alçada?

Evidência esperada

Requisitos obrigatórios explícitos, matriz de acesso, controles e logs verificáveis.

Uso na decisão

Verificar antes da comparação: requisito impeditivo ausente não pode ser compensado por economia.

Problema e aderência

Pergunta de avaliação

Entendeu unidade, perda, exceções e saídas exigidas?

Evidência esperada

Mapa, premissas e matriz de requisitos atendidos, parciais e não atendidos.

Uso na decisão

Comparar cobertura real do trabalho, mantendo lacunas como descoberta.

Arquitetura e implantação

Pergunta de avaliação

Fontes, memória, ferramentas, responsabilidades e dependências formam um sistema coerente?

Evidência esperada

Diagrama, responsabilidades, cronograma e marcos de aceite.

Uso na decisão

Comparar viabilidade e obrigações de empresa e fornecedor, além da demonstração.

Qualidade

Pergunta de avaliação

Os testes representam casos comuns, exceções, falhas e ações proibidas?

Evidência esperada

Plano e conjunto de avaliação com resultado esperado e erros impeditivos.

Uso na decisão

Comparar critérios de aceite; meta contratual exige base, não apenas resultado desejado.

Sustentação e economia

Pergunta de avaliação

Quem opera e mantém; quanto custa com consumo, revisão e mudanças?

Evidência esperada

Modelo operacional e planilha de premissas de custo total e variação.

Uso na decisão

Comparar continuidade e unidade válida entregue, além de licença e implantação.

Portabilidade

Pergunta de avaliação

Como trocar componentes ou fornecedor e encerrar o serviço?

Evidência esperada

Plano de saída com responsabilidades de migração e encerramento.

Uso na decisão

Comparar dependência e capacidade de transição sob condições documentadas.

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:

1. entendimento do problema;
2. escopo atendido e exclusões;
3. solução proposta;
4. arquitetura e integrações;
5. requisitos atendidos, parciais e não atendidos;
6. plano de descoberta e implantação;
7. avaliação e critérios de aceite;
8. segurança e governança;
9. equipe e responsabilidades;
10. suporte e manutenção;
11. cronograma com dependências;
12. preços e premissas;
13. riscos e decisões pendentes;
14. referências e evidências;
15. 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.