Ferramentas internas com IA: criar rápido, operar com critério

Três PDFs e uma ferramenta para o karaokê

Em um evento da NewHack, recebemos três arquivos com as músicas disponíveis no karaokê. A orientação era colocar os PDFs no grupo de WhatsApp para as pessoas escolherem o que cantar. Quando Bruno me mostrou aquilo, pensei no trabalho que estávamos transferindo para cada participante: abrir os arquivos e encontrar uma música no meio de todo aquele material.

Ele me provocou a resolver a situação. Usei IA para transformar os arquivos em uma aplicação e aproveitei para incluir a marca do patrocinador. Levei cerca de vinte minutos para colocar aquela primeira versão no ar. Esse foi o tempo daquela experiência, com um problema delimitado e o material já disponível.

O episódio mudou a pergunta que eu fazia diante de um incômodo operacional. Passei a considerar com mais frequência se dava para construir uma ferramenta pequena para resolvê-lo. A escolha das músicas era uma situação pontual, mas o raciocínio serve para observar tarefas que a equipe repete, informações espalhadas e etapas que poderiam ser mais simples.

Criar com IA e delegar para IA exigem decisões diferentes

Uma ferramenta interna é uma aplicação criada para atender uma necessidade específica da operação. Pode organizar uma fila, consultar um catálogo ou gerar um documento. A IA pode ajudar a escrever seu código sem precisar participar de cada uso da aplicação depois de pronta.

Também podemos usar um modelo dentro da ferramenta, por exemplo para interpretar uma solicitação. E podemos permitir que um agente execute ações em outros sistemas. Essas possibilidades têm consequências diferentes para quem vai operar a solução:

• IA no desenvolvimento: ajuda a criar uma página de consulta. A revisão precisa cobrir o funcionamento do código, o acesso e a correção de falhas.
• IA como parte da aplicação: um modelo sugere a categoria de uma solicitação. É preciso conferir a qualidade da sugestão e permitir sua revisão.
• IA executando ações: um agente altera registros em outro sistema. É necessário definir quais mudanças ele pode fazer, com quais limites e autorizações.

Tenho usado IA também em outras frentes da NewHack. No relato sobre meu trabalho com Codex e minha participação no programa de embaixadores, compartilhei a revisão do site e dos conteúdos. Cada experiência ajuda a entender onde a ferramenta contribui e quais decisões continuam exigindo acompanhamento.

Quando vale criar uma ferramenta interna

A facilidade de construir muda o custo de experimentar. Ainda precisamos comparar o esforço de criar algo com o de configurar uma solução que já existe. No caso do karaokê, o problema era específico. Em um sistema que concentra anos de dados e integrações, a comparação inclui migração, suporte e continuidade da operação.

Antes de desenvolver, vale delimitar quem vai usar, qual tarefa precisa melhorar e o que fica fora da primeira versão. Para essa escolha inicial, detalhei critérios no artigo sobre como escolher o primeiro caso de uso de IA na empresa. Aqui, a decisão seguinte é entender o que será necessário para manter a ferramenta funcionando.

Pergunte quem vai corrigir um erro, atualizar o conteúdo e responder quando alguém precisar de ajuda. Considere também o custo de hospedagem, das integrações e, quando houver, do uso de modelos. O tempo da primeira construção é apenas uma parte desse compromisso.

O cuidado muda quando a ferramenta ganha acesso e autonomia

A TechCrunch relatou acessos do Gemini a sistemas de terceiros durante testes de segurança. Esse debate ajuda a formular uma pergunta prática para a empresa: o que estamos autorizando a aplicação a fazer?

Consultar uma informação, recomendar uma decisão e executar uma alteração são responsabilidades diferentes. Um agente encarregado de preparar um rascunho, por exemplo, pode cumprir sua tarefa sem receber permissão para publicá-lo. Os acessos precisam acompanhar o escopo combinado.

A orientação da OWASP sobre autonomia excessiva recomenda limitar funções e permissões ao necessário e exigir aprovação para ações de alto impacto. Essas restrições devem ser aplicadas nos sistemas e nas integrações. Escrever no prompt que o agente deve tomar cuidado não substitui um controle de acesso.

Da primeira versão ao uso recorrente

Uma demonstração mostra que um caminho é possível. O uso cotidiano revela outras situações: um arquivo diferente, uma entrada incompleta, uma conexão que cai ou alguém que interpreta a tela de outra forma. Testar essas condições faz parte do trabalho antes de uma ferramenta virar dependência da equipe.

Para uma aplicação pequena, proponho um registro simples que acompanhe sua entrada na operação:

• Escopo e responsável: qual tarefa a ferramenta atende e quem decide sobre ajustes e continuidade.
• Dados e acessos: quais informações entram, onde ficam e quem pode consultar ou alterar cada parte.
• Teste com usuários: situações reais de uso, dificuldades observadas e correções necessárias.
• Continuidade: como recuperar informações, interromper uma execução e seguir trabalhando se houver falha.

Depois, acompanhe se as pessoas voltam a usar a solução, quanto retrabalho ela provoca e quanto esforço exige de manutenção. Essas observações ajudam a decidir se vale ampliar o uso, simplificar a aplicação ou adotar outra ferramenta.

Uma nova forma de olhar para a operação

A principal mudança daquele karaokê foi perceber que um pequeno problema podia virar um experimento naquele momento. Quero levar esse olhar para a forma como trabalhamos: observar um atrito, construir algo com escopo claro, ouvir quem usa e aprender com o resultado.

Na NewHack, esse aprendizado se conecta ao apoio a founders e empresas que querem transformar ideias em projetos utilizáveis. Criar rápido abre espaço para experimentar mais. Sustentar o que funcionou exige responsáveis, critérios e atenção à rotina de quem vai usar.

Se sua empresa quer organizar essa experimentação com as equipes, conheça os programas de inovação corporativa da NewHack.