Como escolher um parceiro de implementação de IA para uma PME

Uma boa apresentação de IA é fácil de fazer. Uma implementação que continua a funcionar ao fim de seis meses é outra conversa.

Esta checklist ajuda uma PME a comparar propostas sem depender de demos preparadas, nomes de modelos ou promessas de produtividade.

1. O problema está definido como um processo?

A proposta deve identificar:

• onde o trabalho começa;
• quem participa;
• que sistemas e documentos são usados;
• quais são os passos atuais;
• onde existem esperas, erros e retrabalho;
• qual é o resultado esperado.

Sinal de alerta: a solução começa com uma ferramenta e não com um processo concreto.

Pergunta a fazer:

Pode mostrar o fluxo atual e o fluxo proposto, incluindo as exceções?

2. Existe uma baseline antes de começar?

Sem baseline, qualquer melhoria pode parecer sucesso.

A proposta deve definir o que será medido antes e depois. Por exemplo:

• minutos por ocorrência;
• ocorrências por semana;
• taxa de erro ou retrabalho;
• tempo de resposta;
• número de pendentes;
• percentagem de casos que exige intervenção humana.

Sinal de alerta: promessas de ROI sem explicar os dados de partida e a fórmula.

Pergunta a fazer:

Que dados temos de recolher antes do piloto para decidir se valeu a pena?

3. Está claro onde entra IA e onde entram regras?

Nem todos os passos devem usar um modelo de IA.

Extração de texto variável, classificação e preparação de rascunhos podem beneficiar de IA. Validações, permissões, limites financeiros, deduplicação e ações irreversíveis tendem a precisar de regras claras.

Sinal de alerta: o modelo decide tudo e não há separação entre interpretação e controlo.

Pergunta a fazer:

Que partes são probabilísticas e que partes são determinísticas?

4. A proposta mostra o caminho das exceções?

O processo real não é uma demo perfeita.

A proposta deve explicar o que acontece quando:

• falta informação;
• o documento não é legível;
• existem dois registos possíveis;
• o sistema externo está indisponível;
• a confiança do modelo é baixa;
• uma pessoa rejeita a sugestão;
• a ação falha a meio.

Sinal de alerta: só existe o percurso feliz.

Pergunta a fazer:

Pode mostrar um caso em que o sistema não sabe o que fazer?

5. Quem pode ver e alterar cada dado?

A resposta precisa de ser específica. "É seguro" não chega.

Peça informação sobre:

• dados enviados a cada fornecedor;
• local e prazo de retenção;
• utilização dos dados para treino;
• permissões por utilizador e sistema;
• registos de acesso e ações;
• subprocessadores relevantes;
• eliminação e exportação de dados;
• resposta a incidentes.

As condições variam por produto, licença e configuração. Por exemplo, a OpenAI declara que não usa dados de produtos empresariais e API para treino por defeito.[4] A Microsoft declara proteção por permissões do utilizador e compromissos próprios para os dados usados pelo Copilot.[3] Isto não dispensa a verificação do produto contratado, dos conectores e da configuração concreta.

Sinal de alerta: a resposta mistura políticas de um produto gratuito com as condições do produto empresarial proposto.

Pergunta a fazer:

Pode listar todos os sistemas que recebem dados e a base contratual para cada um?

6. A autonomia está dividida por risco?

A proposta deve distinguir:

• ler;
• sugerir;
• preparar;
• executar;
• executar com aprovação;
• bloquear e escalar.

Uma alteração numa nota interna não tem o mesmo risco que enviar um email, alterar um preço ou aprovar um pagamento.

Sinal de alerta: "totalmente autónomo" aparece como benefício sem limites operacionais.

Pergunta a fazer:

Que ações ficam sempre dependentes de uma pessoa e como é registada a aprovação?

7. Como será testado?

Peça um plano de testes antes da produção.

Deve incluir:

• exemplos normais;
• exceções conhecidas;
• dados incompletos;
• duplicados;
• falhas de integrações;
• permissões erradas;
• instruções maliciosas presentes em emails ou documentos;
• regressões após alterações.

Sinal de alerta: "testámos com alguns exemplos" sem conjunto de teste, critérios de aprovação ou resultados guardados.

Pergunta a fazer:

Que casos têm de passar para o piloto entrar em produção?

8. O custo total está separado?

Compare propostas com a mesma estrutura:

• diagnóstico e desenho;
• implementação;
• integrações;
• licenças;
• utilização de modelos;
• infraestrutura;
• monitorização;
• suporte;
• alterações futuras;
• formação e adoção;
• saída ou migração.

Sinal de alerta: preço inicial baixo que exclui operação, suporte e consumo.

Pergunta a fazer:

Quanto custa manter este sistema com o volume atual e com o dobro do volume?

9. A empresa consegue sair?

A implementação deve ter um caminho de reversão.

Confirme:

• quem é dono do código, prompts, configurações e documentação;
• como exportar dados e logs;
• se as integrações usam contas da empresa;
• o que acontece quando o contrato termina;
• quanto tempo demora desligar ou voltar ao processo anterior;
• que componentes dependem de um fornecedor específico.

Sinal de alerta: o fornecedor controla todas as contas e não existe documentação de saída.

Pergunta a fazer:

Se terminarmos a relação amanhã, o que fica connosco e o que deixa de funcionar?

10. Quem mantém o sistema depois do lançamento?

Modelos, APIs, formatos de documentos e processos mudam.

A proposta deve indicar:

• quem recebe alertas;
• que falhas são monitorizadas;
• prazo de resposta;
• como são aprovadas alterações;
• como se evitam regressões;
• que métricas serão revistas;
• como ficam registadas decisões e incidentes.

Sinal de alerta: o projeto termina no dia da demo.

Pergunta a fazer:

Quem verifica, daqui a três meses, se o sistema continua a fazer o que foi aprovado?

Grelha de comparação

Atribua 0, 1 ou 2 pontos a cada área:

• 0: não está explicado;
• 1: existe uma resposta genérica;
• 2: existe uma resposta específica, verificável e incluída na proposta.

Uma pontuação alta não substitui referências, uma análise técnica ou revisão contratual. Serve para encontrar perguntas que ainda não foram respondidas.

A pergunta final

Peça ao parceiro que demonstre três coisas:

1. um caso normal;
2. uma exceção;
3. uma falha de integração.

Se a proposta só funciona no primeiro caso, ainda não descreve um sistema de produção.

Traga um processo ou uma proposta

Podemos usar esta checklist numa conversa de 15 minutos. O objetivo é perceber o que está bem definido, o que falta medir e onde está o risco antes de começar.

Marcar conversa