Como preparar a empresa para IA mais capaz: mapear, limitar, pilotar

Para preparar a empresa para uma IA mais capaz, não é preciso adivinhar quando ela chega nem o que ela fará. É preciso ter processos mapeados, limites claros de dados e de ações, e ao menos um fluxo real operando com registro e responsável. Um plano de 90 dias em três blocos, mapear, limitar e pilotar, entrega essa base com evidências que você consegue verificar, sem prometer resultado.

Principais pontos

• Preparar a empresa não depende de prever a tecnologia futura. Depende de saber quais processos existem, quais dados circulam e quem decide o quê.
• O primeiro bloco gera um mapa e uma linha de base. Sem eles, nenhuma mudança pode ser avaliada com honestidade.
• O segundo bloco define o que a IA pode ver e fazer. Quanto mais capaz o sistema, mais importante é que o limite esteja fora dele, em permissões e regras.
• O terceiro bloco roda um único fluxo real, com logs, métrica combinada e revisão humana, e termina em uma decisão: expandir, ajustar ou parar.
• Cada bloco termina com entregáveis que outra pessoa consegue conferir. Se não dá para conferir, não conta como entregue.

O que significa preparar a empresa quando ninguém sabe o que vem?

O termo superinteligência costuma aparecer em debates sobre sistemas que superariam pessoas em quase todas as tarefas intelectuais. Hoje isso é hipótese, não produto que a sua empresa possa contratar. Se você quer entender onde cada conceito termina, vale ler a diferença entre AGI e superinteligência e separar o que é debate do que é ferramenta disponível.

O que a empresa realmente opera são modelos e agentes cada vez mais capazes, que leem documentos, usam ferramentas e executam passos em sequência. Preparar-se para isso é um problema de gestão, não de futurologia. As perguntas úteis são práticas:

• Quais processos eu entregaria a um sistema mais capaz, e quais jamais?
• Que dados ele poderia ver, e quais precisam ficar fora do alcance?
• Que ações ele poderia executar sozinho, e quais exigem aprovação de uma pessoa?
• Como eu perceberia que algo saiu errado, e quem reage?

Essas perguntas valem para o modelo de hoje e valem mais ainda para o de amanhã. Uma empresa que as responde por escrito está mais preparada do que uma que acompanha todas as notícias e não tem permissões documentadas.

Três referências ajudam a dar estrutura ao raciocínio: o NIST AI Risk Management Framework, que organiza a gestão de risco de IA, a lista OWASP Top 10 para aplicações com LLM, que descreve falhas típicas de sistemas com modelos de linguagem, e o texto da Anthropic sobre como construir agentes eficazes, que defende começar simples e só aumentar a complexidade quando necessário. Nenhuma delas promete resultado de negócio. Servem como base técnica.

Bloco 1, primeiros 30 dias: como mapear sem travar a operação?

O objetivo do primeiro bloco é saber onde a empresa está hoje. Mapear não é redesenhar processos. É descrever o que acontece de fato, com quem, em quais ferramentas e com quais dados.

Passo a passo sugerido:

• Liste os processos que consomem mais tempo de gente qualificada: atendimento, orçamento, conferência, cobrança, triagem, relatórios.
• Para cada um, descreva entrada, saída, responsável, ferramenta usada (planilha, CRM, WhatsApp, ERP) e onde a decisão humana acontece.
• Marque os pontos em que há dado pessoal, dado financeiro ou informação sensível de cliente.
• Escolha dois ou três processos candidatos e registre a linha de base: quanto tempo leva, quantas voltas dá, que tipo de erro aparece. Registre do jeito que a operação já mede, mesmo que seja uma estimativa da equipe, e diga que é estimativa.
• Levante o uso informal de IA que já existe. Pessoas costumam usar assistentes por conta própria, e isso faz parte do mapa.

Entregáveis verificáveis do bloco:

• Inventário de processos em uma página por processo, revisado pelo responsável de cada área.
• Lista de dados por sensibilidade, indicando onde ficam armazenados.
• Linha de base escrita para os processos candidatos.
• Relato do uso atual de ferramentas de IA, sem punição, apenas para saber a realidade.

Um critério simples de conclusão: alguém que não participou do levantamento consegue ler os documentos e explicar o processo para outra pessoa. Se não consegue, o mapa ainda está vago.

Se o uso informal apareceu, esse é o momento de começar uma regra clara. O artigo sobre política de uso de ChatGPT na empresa detalha o que costuma ser permitido, restrito e proibido.

Bloco 2, dias 31 a 60: como limitar dados, ações e responsabilidades?

No segundo bloco, a empresa decide o que a IA pode tocar. A lógica é que o limite não deve depender do bom comportamento do modelo. Ele deve estar em permissões, credenciais e regras de fluxo. Isso importa mais conforme os modelos ficam mais capazes e mais persuasivos, porque um sistema que consegue agir tem que ter um teto de ação definido por quem o opera.

Passo a passo sugerido:

• Classifique ações em três grupos: o agente pode fazer sozinho (consultar status, redigir rascunho), o agente propõe e uma pessoa aprova (enviar proposta, alterar cadastro, conceder desconto) e o agente nunca faz (apagar dados, mexer em pagamento, decidir sobre pessoas).
• Aplique o princípio do menor acesso. Cada integração recebe só as permissões do fluxo piloto, com credenciais próprias que podem ser revogadas. O guia da OWASP sobre autorização é uma boa referência de conferência.
• Defina o que o agente lê e o que não lê. Dados sensíveis ficam fora do contexto, ou entram minimizados.
• Verifique a base legal e os deveres da LGPD para o fluxo escolhido, incluindo informação ao titular e eventual transferência de dados para fora do país. A página da ANPD é o ponto de partida oficial, e o artigo sobre o marco legal da IA no Brasil ajuda a saber o que acompanhar.
• Escreva o plano de intervenção: quem pode pausar o agente, como, e em quanto tempo ele volta a operar depois de um problema.
• Nomeie um responsável por fluxo. Sem nome, a responsabilidade se dilui.

Entregáveis verificáveis do bloco:

• Matriz de ações com os três grupos acima, assinada pelo responsável da área.
• Lista de integrações e permissões concedidas, com data de revisão.
• Registro das decisões sobre dados e base legal, revisado por quem cuida de privacidade ou jurídico.
• Procedimento de pausa testado ao menos uma vez, com resultado anotado.

Um teste honesto para este bloco: se o agente fosse enganado por uma mensagem maliciosa dentro de um documento ou e-mail, qual seria o pior que ele conseguiria fazer com as permissões atuais? Se a resposta incomoda, reduza permissões antes de seguir. O material da OWASP sobre prevenção de injeção de prompt descreve esse tipo de risco.

Bloco 3, dias 61 a 90: como pilotar um fluxo real com segurança?

O terceiro bloco coloca um único fluxo para funcionar de verdade, com escopo pequeno. A palavra importante é um. Vários pilotos simultâneos produzem barulho e nenhuma conclusão.

Passo a passo sugerido:

• Escolha o fluxo com melhor combinação de dor real, dados controláveis e risco baixo. Respostas a dúvidas frequentes, triagem de solicitações ou rascunho de documentos costumam ser candidatos melhores do que decisões financeiras.
• Defina a métrica de sucesso antes de começar, com a equipe, e escreva também o que seria sinal de parar. Exemplo de formulação: tempo até a primeira resposta correta, ou quantidade de retrabalho por pedido, comparados com a linha de base do primeiro bloco.
• Prepare casos de teste com situações reais anonimizadas e situações difíceis. Teste primeiro em ambiente isolado, com dados simulados. O artigo sobre testar agentes de IA com mocks e sandbox mostra como fazer isso sem risco.
• Ative registros de cada decisão: o que entrou, o que o agente respondeu ou propôs, qual ferramenta usou, quem aprovou. Os conceitos de observabilidade da OpenTelemetry ajudam a pensar em logs, métricas e rastros.
• Mantenha uma pessoa revisando as saídas no começo. Reduza a revisão apenas quando os registros mostrarem estabilidade.
• Marque revisões semanais curtas para olhar erros, casos escalados para humano e reclamações.

Entregáveis verificáveis do bloco:

• Piloto documentado, com escopo, métricas e critérios de parada.
• Conjunto de casos de teste e resultados de cada rodada.
• Registro de decisões do agente acessível a quem audita.
• Relatório final comparando a linha de base com o observado, incluindo o que não funcionou.

O fim do terceiro bloco é uma decisão: expandir, ajustar ou parar. Parar é um resultado legítimo. Um piloto que mostra que o processo não é bom candidato economizou investimento.

Cenário ilustrativo: um piloto de triagem em uma empresa de serviços

Cenário ilustrativo, sem relação com nenhuma empresa real. Uma empresa de serviços recebe pedidos de orçamento pelo WhatsApp e por e-mail. No primeiro bloco, a equipe descobre que o pedido passa por três pessoas e que metade das mensagens chega sem informação suficiente. Registra isso como linha de base.

No segundo bloco, define que o agente pode fazer perguntas de qualificação e montar um resumo do pedido, mas não pode informar valores nem prometer prazo. Só leitura no cadastro de clientes, nenhum acesso a dados de pagamento. Qualquer menção a reclamação ou a assunto jurídico vai direto para uma pessoa.

No terceiro bloco, o piloto roda apenas para um tipo de serviço. Cada conversa gera um registro com o resumo e a decisão de encaminhamento. A métrica combinada é a proporção de pedidos que chegam completos ao orçamentista. Ao final, a equipe compara com a linha de base, lista os erros de entendimento e decide ajustar as perguntas antes de ampliar. Nada nesse cenário depende de o modelo ser mais ou menos poderoso: se um modelo melhor aparecer, o limite continua o mesmo e o teste pode ser repetido.

Como a abordagem de mapear, limitar, pilotar e transferir se encaixa?

Os três blocos seguem o método que usamos em projetos de IA: mapear o processo atual e a linha de base, limitar dados e ações, pilotar um fluxo real com logs e métrica combinada, e transferir a operação com documentação, treinamento e critérios de decisão. O quarto passo acontece depois do dia noventa: quem opera precisa saber ajustar, pausar e auditar sem depender de quem montou. Para uma visão de como esses blocos se organizam tecnicamente, veja a camada de superinteligência da empresa.

Como saber se o plano funcionou, e quando não expandir?

O plano funcionou se a empresa sabe responder, por escrito, o que a IA pode ver, o que pode fazer, quem responde por ela e como se desliga. Isso é verificável. Resultado financeiro não faz parte do critério, porque ninguém consegue garanti-lo em 90 dias e prometer isso seria desonesto.

Sinais para não expandir ainda:

• A linha de base nunca foi medida, então não há como comparar.
• Os registros não permitem reconstruir uma decisão específica.
• A equipe contorna o agente porque ele atrapalha em vez de ajudar.
• Surgiram dados sensíveis no fluxo que não estavam no mapa.
• Ninguém assume a responsabilidade pelo fluxo.

Sinais de que dá para expandir com cuidado: os erros são conhecidos e tratados, a revisão humana diminuiu porque os registros mostram estabilidade, e o próximo fluxo candidato já passou pelo bloco de mapeamento. Repita o ciclo para ele, em vez de copiar o piloto anterior.

Por fim, reserve uma revisão periódica do plano. Quando um modelo novo surgir, rode os mesmos casos de teste antes de trocar qualquer coisa em produção. A empresa preparada não é a que reage mais rápido a cada lançamento, é a que consegue testar e decidir com calma.

Perguntas frequentes

Preciso esperar a superinteligência existir para começar este plano? Não. O plano trata de processos, dados e permissões, que importam com os modelos de hoje. Se sistemas mais capazes surgirem, a empresa terá limites e testes prontos para reavaliá-los.

Quem deve participar dos 90 dias? O ideal é um patrocinador com poder de decisão, o responsável de cada processo mapeado, alguém de tecnologia e alguém que cuide de privacidade ou jurídico. Em empresas pequenas, uma mesma pessoa pode acumular papéis, desde que isso esteja escrito.

O plano serve para atendimento no WhatsApp? Serve, e é um bom candidato de piloto quando o escopo é estreito e há transferência para humano. É preciso cuidar de opt-in, janelas de conversa e dados pessoais, e o limite do que o agente pode prometer deve estar na matriz de ações.

O que faço se o piloto mostrar que o processo não é bom candidato? Documente o motivo e encerre. Isso é um resultado válido do plano, porque evita expandir algo que não se sustenta. Volte ao inventário do primeiro bloco e escolha o próximo processo com base na linha de base e no risco.

Fontes

• NIST: AI Risk Management Framework
• OWASP: Top 10 para aplicações com LLM
• Anthropic: Building effective agents
• ANPD: Autoridade Nacional de Proteção de Dados