Como escolher uma IA

Comece pela tarefa, não pela ferramenta

“Quero usar IA” ainda não é um problema. Descreva a tarefa em termos observáveis: quem executa, quais entradas recebe, qual saída produz, com que frequência, em quanto tempo e como o resultado é conferido. “Melhorar o atendimento” pode virar “sugerir um rascunho com base na central oficial, para revisão antes do envio”. Essa formulação já indica necessidade de fontes, citação e supervisão.

Mapeie o processo atual. Registre tempo, custo, volume, taxa de erro, retrabalho e satisfação sem IA. Essa linha de base impede que a novidade seja confundida com ganho. Às vezes uma busca melhor, um formulário ou uma automação tradicional resolve com mais previsibilidade.

Defina também o que está fora do escopo. Uma ferramenta pode ajudar a resumir documentos, mas não decidir contratação; pode sugerir uma resposta, mas não enviar; pode gerar imagem conceitual, mas não reproduzir a identidade de uma pessoa sem autorização. Limites claros reduzem risco e facilitam o teste.

1. Escreva a tarefa em uma frase com usuário, entrada, ação e saída.
2. Registre como ela é feita hoje e o desempenho da alternativa atual.
3. Defina o benefício desejado em qualidade, tempo, capacidade ou acesso.
4. Liste erros inaceitáveis e pessoas que podem ser afetadas.
5. Estabeleça o que continuará sob decisão e revisão humana.
6. Considere primeiro soluções sem IA ou com automação simples.

Classifique a tarefa e o nível de risco

Identifique a capacidade necessária. Geração cria rascunhos; extração transforma documentos em campos; classificação organiza casos; previsão estima valores; recomendação ordena opções; visão interpreta imagens; fala transcreve ou sintetiza; agentes usam ferramentas e executam etapas. Um produto pode combinar várias capacidades, mas cada uma precisa de avaliação própria.

Risco não depende apenas da tecnologia. Considere quem é afetado, gravidade do erro, escala, reversibilidade, dados envolvidos e capacidade de contestação. Gerar ideias para um convite é baixo impacto; orientar tratamento, crédito, emprego, educação ou direito exige controles muito superiores e profissionais habilitados.

Use uma regra de proporcionalidade: quanto maior o impacto, menor a autonomia e maior a necessidade de evidência, documentação, revisão, segurança e monitoramento. Se não houver responsável capaz de verificar a saída, a ferramenta não é adequada para aquele uso.

Transforme necessidades em requisitos

Separe requisitos obrigatórios, desejáveis e irrelevantes. Obrigatórios são eliminatórios: idioma, região de processamento, integração, licença, acessibilidade, controle de acesso ou operação offline. Desejáveis ajudam no desempate. Recursos chamativos que não contribuem para a tarefa devem ser ignorados.

Requisitos funcionais dizem o que a solução faz: ler PDF, citar páginas, exportar JSON, trabalhar com imagem ou chamar uma API. Requisitos não funcionais dizem como: precisão, latência, disponibilidade, segurança, capacidade, custo, suporte e portabilidade. Ambos precisam de critério verificável.

Não escreva “alta precisão” ou “seguro”. Defina: “em 100 documentos de teste, extrair corretamente os cinco campos obrigatórios em pelo menos 95% dos casos, sem preencher valores ausentes”. Para segurança, peça autenticação, segregação, logs, retenção e resposta a incidente concretos.

• Idiomas, sotaques, formatos e dispositivos do público real.
• Tamanho de arquivos, janela de contexto, volume e concorrência.
• Integrações, exportação, APIs, padrões e ambiente de implantação.
• Identidade, permissões, criptografia, logs e localização dos dados.
• Acessibilidade, suporte, disponibilidade e plano de continuidade.
• Licença, direitos sobre entradas e saídas e uso comercial.
• Custo máximo por mês e por tarefa aprovada.
• Prazo de saída, portabilidade e exclusão ao encerrar o contrato.

Entenda o que está sendo comparado

Modelo é o componente que processa e gera; produto adiciona interface, memória, arquivos, busca, filtros e integrações; plataforma oferece APIs e administração; solução pode incluir consultoria, dados e fluxo organizacional. Dois produtos baseados no mesmo modelo podem apresentar resultados e garantias diferentes.

Também diferencie acesso de consumidor, empresarial e API. Plano gratuito pode usar dados, limites e suporte distintos do contrato corporativo. A versão web pode pesquisar na internet enquanto a API não. Um modelo aberto hospedado pela própria organização é diferente do mesmo modelo servido por terceiro.

Registre modelo, versão, plano e configuração usados no teste. Sem isso, uma comparação não pode ser repetida. Evite concluir que uma marca inteira é melhor: a evidência vale para aquela versão, tarefa e data.

Monte uma lista curta sem depender de propaganda

Use documentação oficial, termos, páginas de segurança, model cards, avaliações independentes e demonstrações controladas. Rankings públicos ajudam a descobrir candidatos, mas podem medir tarefas artificiais, versões diferentes ou respostas selecionadas. Comentários de usuários revelam experiência, não substituem teste.

Elimine primeiro quem não atende requisitos obrigatórios. Depois escolha de três a cinco candidatos com abordagens distintas: serviço generalista, solução especializada, modelo aberto ou fornecedor local, conforme o caso. Uma lista enorme consome tempo e não melhora a decisão.

Peça evidências específicas ao fornecedor: conjunto de teste, população, métrica, taxa de erro, data, versão e limitações. “95% de precisão” sem contexto não informa se a ferramenta funciona no seu documento, idioma ou processo.

1. Pesquisar candidatos que atendam categoria e requisitos obrigatórios.
2. Ler documentação, licença, termos, privacidade e segurança.
3. Eliminar opções incompatíveis antes da demonstração comercial.
4. Registrar afirmações do fornecedor e a evidência oferecida.
5. Selecionar três a cinco finalistas para o mesmo teste.
6. Evitar contratos longos antes de concluir o piloto.

Crie um teste que represente o uso real

O conjunto de avaliação deve existir antes de você ver as respostas finais. Use entradas reais autorizadas ou representações fiéis. Inclua casos comuns, difíceis, ambíguos, longos, incompletos, em português brasileiro, com erros e situações sem resposta. Separe uma parte para desenvolvimento e outra para decisão.

Defina a resposta esperada ou uma rubrica. Em extração, compare campo a campo. Em redação, avalie correção, completude, tom, evidência e necessidade de edição. Em imagens, considere aderência, artefatos, identidade e direitos. Em agentes, avalie trajetória, ferramentas e ações, não só o resultado.

Teste cada candidato com instruções equivalentes e condições iguais. Repita casos para observar variabilidade. Faça avaliação cega quando possível. Registre falhas representativas: médias escondem erros que podem ser inaceitáveis.

Privacidade, LGPD e propriedade intelectual

Antes de enviar dados, mapeie quais informações entram, onde são processadas, quanto tempo ficam, quem acessa e se são usadas para treinar. Dados pessoais, segredos comerciais, prontuários, processos e documentos de clientes não devem ir para uma ferramenta de consumo sem análise e autorização. Configurações de privacidade variam por produto e plano.

No Brasil, o tratamento de dados pessoais precisa observar finalidade, adequação, necessidade, transparência, segurança, direitos dos titulares e demais exigências aplicáveis. Contrato com operador, transferências internacionais, subprocessadores, descarte e incidente precisam ser avaliados. Este guia não substitui orientação jurídica.

Verifique quem pode usar entradas e saídas, se há restrição comercial e como o fornecedor trata propriedade intelectual. Uma saída gerada não garante originalidade nem ausência de material protegido. Para imagens, voz e identidade, obtenha permissões e mantenha registro de procedência.

• A ferramenta usa entradas, saídas ou feedback para treinamento?
• Há opção contratual de não treinamento e qual é o padrão?
• Onde os dados ficam e quais subprocessadores participam?
• Qual é a retenção de chats, arquivos, logs e backups?
• Há criptografia, identidade corporativa e controle por função?
• Como exportar, corrigir e excluir informações?
• Quem responde por incidente e em qual prazo?
• Quais direitos e restrições recaem sobre a saída?

Segurança, confiabilidade e continuidade

Avalie riscos específicos do sistema: prompt injection, vazamento entre usuários, plugins maliciosos, execução de código, chamadas de ferramentas, documentos adulterados e dependências. Quanto maior a autonomia, menor deve ser o conjunto de permissões. O modelo não pode ser o único responsável por validar sua própria ação.

Peça informações sobre testes, gestão de vulnerabilidades, controle de acesso, registro, resposta a incidente e continuidade. Certificações ajudam, mas devem corresponder ao serviço, região e escopo usados. Para funções críticas, teste indisponibilidade, limite de taxa e comportamento quando o fornecedor muda o modelo.

Planeje fallback. Pode ser retornar à busca, usar o processo manual, colocar em fila ou alternar provedor. Preserve versões de prompts, schemas e testes. Uma aplicação que para completamente quando uma API falha pode não ser adequada ao processo.

1. Mapear dados, ferramentas, ações, pessoas e consequências.
2. Aplicar menor privilégio e separar leitura, rascunho e execução.
3. Testar entradas maliciosas, dados conflitantes e falhas externas.
4. Definir limites, confirmação, monitoramento e interrupção.
5. Verificar SLA, suporte, comunicação e histórico de incidentes.
6. Ensaiar fallback, restauração, migração e continuidade.

Integração, experiência e supervisão humana

A ferramenta precisa caber no trabalho. Copiar dados entre telas pode consumir o ganho. Integração por API, exportação, autenticação única e administração reduzem atrito, mas criam dependência e exigem segurança. Teste o fluxo completo, não uma resposta isolada.

Supervisão humana só funciona se a pessoa tiver tempo, competência, evidência e poder de discordar. Revisar centenas de sugestões repetitivas leva à confiança automática. A interface deve destacar fontes, mudanças, incerteza e ações pendentes. Casos de alto risco precisam de encaminhamento.

Acessibilidade é requisito de escolha. Verifique teclado, leitor de tela, contraste, legendas, linguagem e alternativas. IA pode ampliar acesso, mas uma interface inacessível exclui justamente quem poderia se beneficiar.

• Número de etapas e tempo real até o resultado aprovado.
• Clareza de fontes, limites e dados utilizados.
• Facilidade de corrigir, rejeitar e explicar uma decisão.
• Separação entre sugestão, aprovação e execução.
• Treinamento e carga de trabalho de quem supervisiona.
• Acessibilidade e alternativa quando a IA falha.

Custo total e retorno

Some assinatura, tokens, imagens, armazenamento, integrações, implantação, segurança, dados, treinamento, suporte e administração. Inclua revisão humana, retrabalho e custo de erro. Um plano barato pode ficar caro com contexto longo ou muitos usuários; um modelo mais caro pode reduzir correção. Calcule por tarefa aprovada.

Projete cenários de volume baixo, esperado e alto. Considere moeda, impostos, reajustes, mínimo contratado, limite de taxa e excedentes. Para hospedagem própria, inclua GPU, energia, disponibilidade, equipe e ociosidade. Para API, inclua lock-in e migração.

Retorno não é apenas horas poupadas. Pode ser maior capacidade, qualidade, acesso, consistência ou redução de fila. Evite contar toda hora “economizada” como dinheiro se ela não for redirecionada. Defina como o ganho será observado e quem o utilizará.

Avalie o fornecedor e o contrato

Para uso individual de baixo risco, termos públicos podem bastar. Para organizações, trate IA como contratação tecnológica e de dados. Verifique saúde do fornecedor, suporte, roadmap, documentação, segurança, subcontratados, portabilidade e capacidade de cumprir o volume. Promessas da demonstração precisam aparecer no contrato ou na especificação.

Defina SLA, suporte, notificação de mudança, manutenção de versão, preço, limites, propriedade, confidencialidade, tratamento de dados, auditoria, incidentes, indenização, encerramento e exclusão. Negocie direito de testar atualizações antes da produção quando o processo exigir estabilidade.

Evite enviar dados reais para prova de conceito sem acordo e ambiente apropriado. Use dados sintéticos ou desidentificados com cuidado. O fornecedor deve explicar o fluxo técnico em linguagem suficiente para que sua equipe entenda o risco.

• Qual entidade contrata e em que jurisdição?
• O serviço e o plano testados são exatamente os contratados?
• Há compromisso sobre versão, mudança e descontinuação?
• Quais são SLA, suporte, limites e compensações?
• Quem são operadores, subprocessadores e regiões?
• Quais direitos existem sobre dados, prompts, ajustes e saídas?
• Como ocorrem auditoria, incidente, exportação e exclusão?
• Existe plano de saída sem perda de histórico e processo?

Piloto, matriz de decisão e implantação

Faça um piloto pequeno, com usuários reais, dados autorizados e supervisão. Compare com a linha de base. Colete tempo total, qualidade, erros, percepção, custo e incidentes. Não transforme piloto em produção informal: prazo, escopo, responsável e descarte dos dados precisam estar definidos.

Uma matriz ajuda a tornar a decisão explícita. Atribua pesos antes de pontuar e trate requisitos obrigatórios como eliminatórios. Faça análise de sensibilidade: uma pequena mudança no peso altera o vencedor? Se sim, a decisão é frágil e merece mais evidência.

Implante por etapas, com treinamento, política de uso, canal de suporte, logs e monitoramento. Reavalie quando o modelo, preço, contrato, dados ou processo mudar. Escolher IA não é compra única; é gestão durante todo o ciclo de vida, inclusive desativação.

1. Confirmar requisitos eliminatórios e conjunto de avaliação.
2. Executar teste técnico padronizado com os finalistas.
3. Realizar piloto limitado e comparar com o processo atual.
4. Pontuar evidências, analisar erros e calcular custo total.
5. Obter aprovação de negócio, segurança, dados e jurídico conforme o risco.
6. Contratar com métricas, suporte, mudança e saída definidos.
7. Implantar gradualmente, treinar usuários e monitorar.
8. Revisar periodicamente e desativar quando deixar de atender.