- Comece pelo objetivo de negócio, não pela ferramenta. "Deveríamos usar IA para isso" não é um objetivo. "Reduzir o tempo de processamento de faturas de quatro dias para um dia" é.
- Priorize casos de uso considerando valor, viabilidade e risco em conjunto. O caso de uso mais chamativo raramente é o certo para construir primeiro.
- A prontidão dos dados é o bloqueio mais comum, e o que as organizações verificam por último em vez de primeiro.
- Um piloto tem escopo delimitado, um limiar de sucesso acordado previamente e um plano de reversão. Sem esses três elementos, não é um piloto: é uma entrada em produção disfarçada.
- Teste os resultados da IA contra casos extremos e entradas adversariais antes de expandir, não apenas os casos que deixaram a demonstração com boa aparência.
- A supervisão humana precisa ser incorporada ao novo processo desde o início. Adicioná-la depois entrega supervisão de nome, não na prática.
- Meça o resultado de negócio para o qual o projeto foi construído. Métricas de adoção e uso não são, por si só, prova de valor.
Adoção de IA e implementação de IA não são a mesma questão
A maior parte das orientações sobre IA disponíveis hoje, incluindo nosso próprio guia de governança de IA, trata da adoção de IA: funcionários que já usam ChatGPT, Copilot ou Gemini, e a organização precisa de um inventário, uma política e um conjunto de controles para alcançar uma realidade que já se instalou. A governança de adoção continua importante e não desaparece quando você implementa IA de forma deliberada. Mas ela responde a uma pergunta diferente da que este guia trata.
Implementação de IA é o que acontece quando uma organização incorpora deliberadamente a IA a um processo, sistema ou produto específico, em vez de deixar que os funcionários adotem ferramentas genéricas por conta própria. Exemplos: automatizar a triagem de suporte de primeiro nível, adicionar revisão de documentos assistida por IA a um processo jurídico, incorporar IA a uma funcionalidade de produto pela qual os clientes pagam. A implementação carrega todas as exigências de governança da adoção, além de uma série de etapas que a adoção não precisa: um business case, seleção de caso de uso, trabalho de prontidão de dados, um piloto, testes contra cenários de falha e uma forma de medir se funcionou.
Trate a implementação como uma sequência de etapas, não como uma única decisão. Pular direto de "escolhemos um caso de uso" para "está em produção" é onde a maioria dos projetos de IA malsucedidos realmente falha, e a causa geralmente está em uma etapa no meio deste guia, não no modelo de IA em si.
Este guia trata de um caso de uso do início ao fim, do business case a um resultado mensurável em produção. Ele não substitui a governança de IA contínua: a política, o registro de ferramentas e a supervisão de fornecedores do nosso guia de governança de IA continuam se aplicando assim que este sistema estiver em produção, e é ali que a due diligence de fornecedores, a classificação de risco e o desenho de supervisão do próximo caso de uso devem começar.
Etapa 1: Defina o objetivo de negócio
Toda implementação de IA deve começar por um problema de negócio específico e mensurável, não pelo fato de a IA existir e concorrentes falarem sobre ela. "Deveríamos ter uma estratégia de IA" gera comitês e apresentações. "Nossa equipe de suporte gasta 40% do tempo com redefinições de senha e perguntas sobre status de pedidos" gera um projeto com um início e um fim claros.
Um objetivo útil nomeia a linha de base atual, a meta e o prazo: reduzir o tempo médio de processamento de faturas de quatro dias para um dia em dois trimestres; reduzir o tempo de primeira resposta em tickets de suporte de nível 1 de seis horas para quinze minutos em um trimestre. Nomeie um patrocinador de negócio responsável por esse número, não um responsável de tecnologia dono do cronograma do projeto. O patrocinador é para quem o projeto se reporta quando o piloto entrega um resultado, bom ou ruim.
Se você não consegue formular o objetivo como um número de antes e depois com uma data, o projeto ainda não está pronto para a seleção de caso de uso. Volte e encontre primeiro o problema real.
Quem é responsável por quê
Uma primeira implementação não precisa de uma equipe dedicada de IA, mas cada uma dessas funções deve estar atribuída antes que o trabalho comece. Uma pessoa pode cobrir mais de uma função; ninguém pode ficar sem nenhuma.
| Função | Responsável por |
|---|---|
| Patrocinador de negócio | O objetivo e a decisão de avançar ou não ao final do piloto |
| Responsável técnico | A construção ou a relação com o fornecedor, e a viabilidade técnica |
| Dono do processo | O fluxo de trabalho onde o sistema de IA se encaixa, e o redesenho na Etapa 10 |
| Responsável pela governança | A avaliação de impacto, a posição quanto ao Regulamento Europeu de IA e a due diligence de fornecedores nas Etapas 4 e 6 |
| Revisor do dia a dia | A supervisão humana definida na Etapa 11, assim que o sistema entrar em produção |
Etapa 2: Identifique e priorize casos de uso
Uma vez que o objetivo esteja claro, geralmente há várias maneiras de a IA abordá-lo. Avalie cada candidato em três dimensões, não apenas uma: valor de negócio, viabilidade e risco. Organizações que pulam a viabilidade e o risco costumam aprovar o caso de uso mais impressionante em vez daquele que conseguem efetivamente entregar e justificar.
Confirme primeiro que a IA é realmente a ferramenta certa
Antes de avaliar opções de IA, verifique se uma abordagem sem IA resolve o objetivo igualmente bem. Um conjunto de regras bem escrito, um script de RPA ou uma ferramenta convencional de busca ou fluxo de trabalho costuma ser mais barato de construir, mais fácil de explicar a um regulador e mais simples de manter do que um sistema de IA, especialmente quando a lógica subjacente é realmente fixa em vez de variável. Faça três perguntas: a tarefa exige julgamento diante de entradas que variam demais para regras fixas cobrirem; o bom desempenho depende de reconhecer padrões em dados grandes e não estruturados; e o custo de uma resposta ocasionalmente incorreta de um sistema de IA é aceitável diante do que custaria construir uma alternativa determinística. Se um motor de regras ou uma funcionalidade de software já existente responde ao objetivo, use-o. Reserve a IA para os casos de uso em que a variabilidade ou a escala da entrada realmente exigem isso.
| Exemplo de caso de uso | Valor de negócio | Viabilidade | Risco | Veredito |
|---|---|---|---|---|
| Triagem por IA de tickets de suporte de nível 1 | Alto | Alta: dados históricos de tickets limpos e disponíveis | Médio: voltado ao cliente, exige reversão humana | Forte candidato inicial |
| Conciliação e codificação automatizada de faturas | Médio | Alta: estruturado, repetitivo, baseado em regras | Baixo: financeiro, mas bem delimitado e auditável | Forte candidato inicial |
| Triagem de currículos assistida por IA no recrutamento | Alto | Média: exige testes de viés e trilha de auditoria | Alto: afeta indivíduos, exposição ao Artigo 20 da LGPD | Adiar até a governança amadurecer |
| Chatbot totalmente autônomo para atendimento a clientes em questões complexas | Alto (em teoria) | Baixa: exige salvaguardas extensas, lógica de escalonamento | Alto: risco reputacional e de precisão | Não é um primeiro projeto |
O padrão que se destaca: os candidatos mais fortes para começar raramente são os mais ambiciosos. Escolha um caso de uso em que os dados já existam em forma utilizável, o processo esteja bem delimitado e um resultado incorreto seja recuperável, não impactante. Reserve os casos de uso mais difíceis e de maior valor para depois que a organização tiver uma implementação bem-sucedida e um processo funcionando.
Estime o custo antes de se comprometer
Faça uma estimativa aproximada de custo nesta fase, não depois que a construção começar. Para uma rota de compra ou de fornecedor especializado, isso significa custos de licença ou de uso, trabalho de integração e tempo da equipe para o piloto. Para uma construção sob medida, somam-se o tempo de desenvolvimento, os custos contínuos de modelo ou de API e o custo permanente do ciclo de monitoramento e revisão da Etapa 12, que não termina quando o piloto acaba. Compare esse número com o objetivo da Etapa 1: se a economia ou o valor estimado não superarem claramente os custos de construção e operação dentro de um prazo razoável de retorno, o caso de uso precisa mudar ou o escopo precisa diminuir. Uma estimativa aproximada nesta fase vale mais do que uma estimativa precisa depois do piloto, porque é esse número que determina se vale a pena executar o piloto.
Etapa 3: Avalie a prontidão dos seus dados
A prontidão dos dados é o bloqueio mais comum na implementação de IA, e o que a maioria das organizações verifica por último em vez de primeiro. Um caso de uso que pontua bem no papel pode ficar parado por meses assim que a equipe do projeto descobre que os dados em que ele se baseia estão espalhados por três sistemas, formatados de forma inconsistente ou simplesmente não existem no volume necessário.
Se a avaliação de prontidão dos dados revelar lacunas importantes, isso é uma constatação, não um fracasso. Invista primeiro no trabalho de dados, ou escolha outro caso de uso para o qual os dados já sejam suficientes.
Defina por quanto tempo os dados serão retidos
Defina um prazo de retenção para os dados que o sistema de IA processa e, quando aplicável, para os resultados e logs, antes de o sistema entrar em produção. Confirme o que o fornecedor ou a plataforma retém por padrão: alguns fornecedores mantêm prompts e resultados por um período fixo para suporte e monitoramento de uso indevido, e alguns os retêm para treinamento de modelo a menos que você opte por não participar. Quando os dados incluírem dados pessoais, o prazo de retenção precisa ser defensável em relação à finalidade para a qual foram coletados, não apenas prático para depuração. Documente o prazo e quem é responsável por sua aplicação, e revise isso como parte do ciclo de revisão da Etapa 12.
Etapa 4: Selecione a tecnologia, a arquitetura e o fornecedor
A maioria das organizações que implementa seu primeiro caso de uso de IA escolhe entre um recurso de IA nativo em uma plataforma que já usa, um produto de um fornecedor especializado e uma construção sob medida sobre uma API de modelo de fundação. Cada uma tem um perfil diferente de custo, velocidade e controle.
Uma observação sobre arquitetura
Qualquer que seja a rota escolhida, determine cedo como o sistema é montado: onde os dados ficam em relação ao modelo, se o componente de IA chama outros sistemas internos ou APIs externas por conta própria, e onde o ponto de controle humano da Etapa 11 se encaixa nessa cadeia. Um recurso nativo da plataforma geralmente já decide isso por você. Um produto de fornecedor especializado ou uma construção sob medida não, e uma arquitetura que dá ao componente de IA acesso de leitura ou escrita a mais sistemas do que o caso de uso realmente precisa é a forma mais fácil de transformar um piloto delimitado em um piloto sem limites. Mantenha a superfície de integração tão estreita quanto o objetivo exigir, e amplie depois apenas diante de uma necessidade específica e fundamentada.
Qualquer que seja a rota escolhida, as perguntas de due diligence sobre fornecedores do nosso guia de governança de IA continuam totalmente aplicáveis: onde os dados são processados, o que acontece com eles no encerramento do contrato e quais certificações de segurança o fornecedor possui. Acrescente duas perguntas específicas de implementação: qual o desempenho do produto do fornecedor em uma amostra dos seus próprios dados, não os dados da demonstração, e como é o caminho de saída se você precisar migrar da ferramenta assim que um processo depender dela.
Etapa 5: Avalie os riscos
Trate isso como uma avaliação proporcional ao nível real de risco do caso de uso, não como uma checklist a ser cumprida da mesma forma para todo projeto, independentemente do porte. Um caso de uso interno de baixo risco precisa de uma verificação mais leve do que um caso de uso que afeta clientes ou os direitos de indivíduos.
Com que frequência o sistema precisa acertar para que o caso de uso valha a pena implantar, e o que acontece quando erra? Um assistente de rascunho que erra 5% das vezes é aceitável porque um humano revisa o resultado. Um sistema de decisão automatizada que erra 5% das vezes em escala é um problema completamente diferente.
A implementação introduz uma nova superfície de ataque: uma integração de API, um chatbot que processa entradas não confiáveis, um sistema conectado a dados internos aos quais antes não tinha acesso? Os controles de segurança da seção de segurança do nosso guia de governança de IA se aplicam diretamente aqui.
O caso de uso processa dados pessoais de uma forma nova? Se sim, uma avaliação de impacto conforme o Artigo 38 da LGPD provavelmente é exigida antes da entrada em produção, não depois. Veja a Etapa 6 abaixo.
Quando o resultado do sistema afeta indivíduos de forma diferente conforme quem eles são, teste resultados desiguais entre grupos relevantes antes da entrada em produção, com uma amostra representativa grande o suficiente para detectar uma diferença significativa.
Você consegue explicar, em termos que um stakeholder não técnico ou um regulador aceitaria, por que o sistema produziu um determinado resultado? Se a resposta for "não sabemos completamente", isso limita substancialmente para quais casos de uso o sistema é adequado.
Se o sistema pode executar uma ação por conta própria, enviar um e-mail, atualizar um registro, chamar outro sistema, em vez de apenas produzir texto ou uma recomendação sobre a qual um humano deve agir, trate-o como uma implementação de risco substancialmente mais alto, independentemente de quão bem ele performe. Defina exatamente quais ações ele pode executar sem supervisão, quais ações sempre exigem aprovação humana prévia e o que acontece se receber uma tarefa que exija uma ferramenta ou nível de acesso que ninguém concedeu explicitamente. Um sistema agêntico que adquire silenciosamente mais alcance do que o caso de uso pretendia é um risco maior do que um sistema que ocasionalmente erra uma resposta.
Etapa 6: Confirme os requisitos legais e regulatórios
Confirme isso antes de construir, não depois de existir um protótipo funcional e o jurídico levantar objeções para as quais ninguém reservou tempo. Duas perguntas cobrem a maioria dos projetos de implementação: o caso de uso exige um Relatório de Impacto à Proteção de Dados Pessoais sob a LGPD, e o Regulamento Europeu de IA se aplica.
Se o caso de uso processa dados pessoais e envolve criação de perfis, decisões automatizadas com efeitos significativos ou monitoramento em larga escala de pessoas, um RIPD é exigido pelo Artigo 38 da LGPD antes da entrada em produção. Quanto ao Regulamento Europeu de IA, ele normalmente só entra em jogo se sua organização tiver clientes na UE, operações na Europa ou atender indivíduos na UE; nesse caso, avalie o caso de uso contra os níveis de risco do regulamento, especialmente quando envolver recrutamento, concessão de crédito ou outro domínio de alto risco do Anexo III. Nosso guia de governança de IA aborda tanto as obrigações da LGPD quanto a aplicabilidade do Regulamento Europeu de IA em detalhe completo, incluindo o cronograma de implementação atual.
Etapa 7: Execute um piloto controlado
Um piloto não é uma entrada em produção disfarçada sob outro nome. Ele precisa de um escopo delimitado, um limiar de sucesso acordado previamente e um plano de reversão acordado previamente, não improvisado se algo der errado.
Etapa 8: Teste rigorosamente
Uma demonstração que performa bem em um punhado de exemplos selecionados manualmente revela pouco sobre como o sistema se comporta nos casos que realmente causam problemas. Antes de uma expansão mais ampla, teste:
- Casos extremos: as entradas incomuns, malformadas ou incompletas que o processo realmente encontra, não apenas os exemplos limpos usados para construir o sistema
- Entradas adversariais: entradas deliberadamente elaboradas para produzir um resultado incorreto ou prejudicial, especialmente para qualquer sistema voltado ao cliente ou que processe entradas externas
- Cenários fora da distribuição: casos que diferem substancialmente dos dados de treinamento ou configuração, para entender como o sistema falha diante de algo realmente novo
- Comportamento de erro e reversão: o que acontece quando o sistema está incerto, indisponível ou produz um resultado de baixa confiança. Confirme que ele falha de forma segura e visível, não silenciosa
- Carga e desempenho: se o sistema aguenta o volume com que o processo em produção realmente opera, não o volume testado durante o desenvolvimento
Testes específicos de segurança para sistemas de IA
Quando o sistema processa entradas não confiáveis, tem acesso a dados internos ou pode chamar ferramentas ou outros sistemas, teste também, além dos casos gerais acima:
- Injeção de prompt: instruções embutidas diretamente na entrada do usuário que tentam sobrepor o comportamento configurado do sistema
- Injeção indireta de prompt: instruções ocultas em um documento, página web ou e-mail que o sistema lê como parte de sua tarefa, em vez de digitadas diretamente pelo usuário
- Vazamento de dados sensíveis: entradas elaboradas para fazer o sistema revelar dados, configuração ou instruções que não deveria expor
- Capacidade de ação excessiva: se o sistema tenta executar uma ação além do que o caso de uso o autorizou, diante de uma instrução ambígua ou maliciosa
- Uso inseguro de ferramentas e APIs: se o sistema pode ser manipulado para chamar uma ferramenta ou API conectada com parâmetros ou em uma sequência não pretendidos
- Recuperação além das permissões: para sistemas com acesso a documentos ou registros internos, se ele recupera e exibe conteúdo que o usuário solicitante não deveria ver
- Documentos maliciosos: arquivos elaborados para explorar como o sistema analisa ou processa conteúdo enviado, não apenas o comportamento de processamento de texto
Documente o que você testou e o que encontrou. Esse registro se torna parte da evidência para o RIPD ou para a avaliação de conformidade com o Regulamento Europeu de IA, quando aplicável, e é a primeira coisa que você vai querer ter em mãos quando algo der errado após a entrada em produção e alguém perguntar se isso era previsível.
Etapa 9: Prepare as pessoas
As pessoas que usam o novo processo ou são afetadas por ele precisam de mais do que um anúncio de uma linha dizendo que "o sistema agora usa IA".
Etapa 10: Integre ao processo de negócio
Um sistema de IA que produz bons resultados, mas fica fora do fluxo de trabalho real, não entrega o resultado de negócio. Integração significa redesenhar o processo em torno da nova capacidade, não adicionar uma etapa extra ao processo antigo.
| Fase | Antes | Depois |
|---|---|---|
| Recebimento da fatura | Aberta, lida e lançada manualmente no sistema financeiro | A IA extrai os itens de linha e os codifica automaticamente |
| Tratamento de exceções | Sem distinção; toda fatura recebe atenção manual igual | Somente faturas com baixa confiança ou incomuns vão para um revisor humano |
| Aprovação | O gestor revisa cada fatura antes do pagamento | O gestor revisa apenas as exceções sinalizadas; faturas de rotina seguem com base em um limiar fixo |
| Papel do funcionário | Lançamento de dados em tempo integral | Revisão de exceções e atendimento a dúvidas de fornecedores |
Observe que o processo redesenhado muda o que o papel humano faz, não apenas o que o software faz. Essa mudança é de onde vem o resultado de negócio, e é por isso que projetos de implementação conduzidos apenas por uma equipe de tecnologia, sem o dono do processo à mesa, costumam entregar uma ferramenta em torno da qual o fluxo de trabalho de ninguém realmente mudou.
Etapa 11: Estruture a supervisão humana para o novo processo
A supervisão precisa ser incorporada ao processo redesenhado desde o início, com uma pessoa específica responsável por uma decisão específica, não uma instrução genérica para "acompanhar de perto".
| Atividade | Papel da IA | Papel humano |
|---|---|---|
| Codificação rotineira de faturas | Extrai e codifica automaticamente | Audita uma amostra fixa semanalmente |
| Fatura com baixa confiança | Sinaliza para revisão, não avança | Revisa e aprova ou rejeita antes do pagamento |
| Novo fornecedor ou valor incomum | Sinaliza automaticamente com base em limiares fixos | Revisão manual completa, não pode ser anulada apenas pela pontuação de confiança da IA |
| Atualização de modelo ou fornecedor | O comportamento pode mudar sem aviso | Testa novamente uma amostra contra os critérios da Etapa 8 após cada atualização relevante |
| Ação agêntica ou de múltiplas etapas | Só pode executar ações da lista permitida na Etapa 5 | Aprova qualquer ação fora dessa lista antes de ela ocorrer, não depois |
Este é o mesmo princípio de design da seção sobre supervisão humana do nosso guia de governança de IA: um humano que efetivamente avalia o caso, com autoridade e informação para mudar o resultado, não uma formalidade a caminho de uma decisão que já estava tomada.
Etapa 12: Monitore e meça o resultado de negócio
Assim que o sistema entrar em produção, acompanhe dois tipos diferentes de métricas, e não deixe o primeiro substituir o segundo.
| Métricas operacionais | Métricas de resultado de negócio |
|---|---|
| Taxa de adoção entre os usuários-alvo | Mudança no número que constava no objetivo da Etapa 1 |
| Volume de consultas ou transações processadas | Custo economizado ou realocado |
| Disponibilidade do sistema e tempo de resposta | Taxa de erro ou correção comparada ao processo anterior |
| Taxa de exceções e escalonamentos | Satisfação de clientes ou funcionários onde o processo os afeta |
As métricas operacionais dizem se o sistema está funcionando. As métricas de resultado de negócio dizem se valeu a pena construí-lo. Avalie ambas em um cronograma fixo, não apenas na entrada em produção: o comportamento do modelo pode mudar, atualizações do fornecedor podem alterar a qualidade dos resultados, e um processo que funcionava bem no volume do piloto pode se comportar de forma diferente em escala total. Onde a implementação envolve um fornecedor de IA, o ciclo de governança do nosso guia de governança de IA trata da estrutura de revisão contínua na qual esse monitoramento deve se encaixar.
Seus primeiros 90 dias
Uma primeira implementação de IA parece um grande projeto, mas se torna administrável assim que dividida em etapas. A meta no dia 90 é ter um caso de uso que esteja em produção com um resultado mensurado, ou que tenha sido interrompido com uma razão clara e documentada.