Olá pessoALL,

Se você já trabalhou em qualquer empresa com mais de 10 pessoas, conhece aquele projeto que ninguém quer pegar. O painel administrativo interno. Aquele com 20 abas, 50 filtros de busca, paginação que quebra e um botão de "Exportar CSV" que nunca funciona direito. O time de suporte reclama que é lento. O time de produto reclama que é feio. E os desenvolvedores? Reclamam que gastam semanas inteiras adicionando um filtro por CEP que três pessoas vão usar.

Sim. Eu também. Já construí painéis com 30 abas que ninguém usava. Aqui na AzureBrasil, passamos por isso com clientes e internamente, e o padrão se repetia: semanas de desenvolvimento, deploy na sexta-feira, e na segunda o time comercial já pedia "mais um filtrozinho". Aquele painel nasce desatualizado.

Até que paramos pra questionar: por que estamos construindo telas para dados que as pessoas só querem perguntar?

O Imposto Invisível de Cada Tela

Existe um custo escondido que eu chamo de "Imposto da UI". Cada informação que você quer expor num painel interno cobra um pedágio do seu time de engenharia.

Quer adicionar um filtro por cidade? Frontend: criar o dropdown (2 horas). Backend: adicionar o WHERE na query (1 hora). QA: testar se não quebrou a paginação (2 horas). Total: 5 horas pra mostrar uma coluna de dados.

Agora multiplica isso por cada pedido que o time de negócios faz. "Quero ver os top 5 clientes por faturamento." "Quero filtrar por período." "Quero agrupar por região." Cada pergunta vira um ciclo de desenvolvimento completo: endpoint novo, componente novo e mais um deploy.

Para times pequenos, esse imposto é brutal. Você gasta 70% do tempo de engenharia movendo pixels numa tela interna enquanto o produto principal fica parado.

E o pior? O painel fica desatualizado no dia do deploy. Porque o time de negócios já pensou em três perguntas novas que a tela não responde.

Ferramentas low-code resolvem? Resolvem parcialmente. Mas você continua construindo telas que ninguém pediu. O Retool, o Appsmith — todos diminuem o tempo de construção da UI. Porém o problema de fundo permanece: cada pergunta nova exige uma tela nova. Você trocou o React por drag-and-drop, mas o modelo mental é o mesmo. Alguém precisa antecipar todas as perguntas possíveis e pré-construir as respostas visuais.

E se ninguém precisasse antecipar nada?

A Mudança: APIs São a Nova Interface

A ideia é simples, quase óbvia quando você ouve: em vez de construir telas, exponha APIs e functions. Deixe um agente de IA ser a interface entre o usuário e os dados.

O conceito por trás disso é o Text-to-SQL combinado com function calling. Você define o schema do banco de dados uma vez — tabelas, relacionamentos, colunas permitidas. O agente recebe uma pergunta em linguagem natural, gera a query SQL, executa contra o banco e devolve a resposta formatada. Sem dropdown. Sem paginação. Sem botão de exportar.

A diferença na prática:

Para ferramentas internas, onde o padrão de uso é alta intenção, alta frequência e pouca paciência, o agente ganha de lavada. O time comercial não quer explorar dashboards. Quer uma resposta. Rápido.

Plugar o ChatGPT direto no banco resolve essa parte, certo? Mas vamos ser honestos: segurança, governança e experiência do usuário não-técnico ficam completamente de lado. Você não pode dar a senha de produção pra um modelo de linguagem. E o pessoal do financeiro não vai abrir o terminal pra fazer perguntas.

A solução de segurança é a mesma que usamos em qualquer acesso a banco: Read-Only roles e views sanitizadas. O agente recebe uma credencial que só permite SELECT. Colunas sensíveis — senhas, CPFs, dados de pagamento — ficam escondidas atrás de views que expõem apenas o necessário. O modelo não consegue ver o que a view não mostra. Não é confiança no modelo. É arquitetura de acesso.

Até aqui, tudo isso funciona num demo. A pergunta é: como transforma isso em algo que o time comercial realmente usa no dia a dia?

Na Prática: Como Fizemos na AzureBrasil

Aqui na AzureBrasil, vivemos esse problema antes de pensar em solução. Nossos clientes pediam painéis internos. Nós construíamos (e reclamávamos, como todo mundo). Eles usavam por duas semanas e voltavam pedindo "mais um relatório". O ciclo não parava.

Quando começamos a testar agentes de IA conectados a APIs internas, o resultado foi imediato: o time de suporte de um cliente parou de abrir chamados pedindo relatórios e parou de esperar o time técnico montar uma query. Eles simplesmente perguntavam. "Quantos tickets abertos essa semana?" "Qual cliente tem mais chamados em aberto?" "Me lista os pedidos do mês passado com valor acima de R$10.000." Respostas em segundos, sem ninguém do time técnico envolvido.

O problema era que não existia uma camada corporativa decente pra entregar isso. Não dá pra mandar o diretor financeiro usar uma API via Postman. E uma caixa de chat genérica, sem governança nem controle de acesso, não sobrevive numa empresa séria.

Foi daí que nasceu o powerOmni. Construímos primeiro pra nós mesmos e pra nossos clientes. Depois percebemos que o padrão se repetia em toda empresa que atendia: times não-técnicos precisam de dados, mas não precisam de telas. Precisam de uma interface conversacional que respeite permissões, registre tudo e funcione nos canais que já usam — Teams, WhatsApp, web.

O backbone do powerOmni é o Microsoft Azure AI Foundry. Ele orquestra os agentes e gerencia o grounding nos dados do cliente, sempre respeitando as políticas de segurança da organização. Da nossa parte, cuidamos da camada de experiência corporativa: a UI onde o usuário conversa, o controle de acesso por perfil e os conectores com as fontes de dados.

Parece que estamos eliminando a UI, né? Mas na verdade estamos evoluindo ela. De cliques pra conversas. De telas estáticas pra respostas sob demanda. O usuário final não precisa saber que tem um agente, um modelo de linguagem e uma API por trás. Ele só precisa perguntar e receber a resposta certa, no canal que já usa, com a permissão que faz sentido pro perfil dele.

Sabe aquele filtro por CEP que mencionei no começo? Com essa abordagem, ninguém precisa construí-lo. O usuário simplesmente pergunta "me mostra os clientes da região sul" e recebe a resposta.

Conclusão — Pare de Pagar o Imposto da UI

Se o seu time de engenharia gasta mais tempo construindo telas internas do que evoluindo o produto, o problema não é falta de gente. É o modelo. Aquele painel com 20 abas que mencionei no começo? Ele existe porque ninguém questionou se uma tela era a melhor forma de responder uma pergunta.

Três lições que tiramos desse caminho:

1. CRUD interno é commodity. Escrever lógica de Create, Read, Update, Delete pra painel administrativo é trabalho de baixo valor. Se o schema do banco está bem definido, um agente consulta sem código novo.

2. APIs são a nova UI pra ferramentas internas. A velocidade de expor uma API não se compara com a de construir uma tela. Combine isso com uma interface agentic e você entrega respostas em segundos pro time de negócios — sem ciclo de desenvolvimento.

3. Segurança não é opcional — é arquitetura. Read-Only roles, views sanitizadas, logs de auditoria. Não importa se a interface é um painel React ou um agente de IA: o controle de acesso aos dados precisa existir na camada de dados, não na camada de apresentação.

Se você quer ver como isso funciona numa plataforma pensada pra empresas, dá uma olhada no powerOmni.

Pare de construir admin panels. Libere seus engenheiros.

[]s e até a próxima