Plataforma HumanAI
Agentes de IA que trabalham em equipa.
Coordene os agentes de IA da sua equipa, com as contas de cada pessoa e as regras do projecto. O trabalho continua com o portátil fechado; quando precisa de uma decisão, chega ao telemóvel.
Do pedido ao resultado
- 01PedidoUma pessoa ou um ticket diz o que é preciso e como se verifica.
- 02AgenteO agente trabalha no ambiente da pessoa, com as regras do projecto.
- 03AprovaçãoO que é sensível pára e espera por quem decide.
- 04ResultadoEntrega revista, com a evidência no ticket, confirmada por quem valida.
Funciona com
- Claude
- OpenAI Codex
- Kimi
- Jira
- Confluence
- Azure DevOps
- Databricks
- Microsoft Fabric
- Power BI
Agentes de IA que executam trabalho na plataforma HumanAI: Claude, OpenAI Codex e Kimi.
Ferramentas integradas no cockpit: Jira, Confluence e Azure DevOps.
Competências disponíveis via API: Databricks, Microsoft Fabric e Power BI.
As marcas e os logótipos apresentados pertencem aos respectivos titulares. A referência indica compatibilidade técnica; não implica afiliação, patrocínio ou aprovação da HumanAI por esses titulares.
Um dia com a plataforma
Do resumo da manhã ao sprint, sem mudar de ferramenta
- 01
Às 9h, o Hoje
A Ana abre o cockpit e vê o que mudou nas últimas 24 horas: pedidos à espera dela, pull requests e o Jira, cada fonte com a hora a que foi lida.
- 02
O agente propõe, a Ana decide
Pede ao agente a avaliação do DATA-214. O agente lê o ticket, escreve o Technical Assessment e pára antes de reprocessar dados, à espera do Permitir.
- 03
Os colegas respondem ali mesmo
A Marta pede a aprovação para promover a UAT e o Bruno uma decisão sobre a chave de negócio. As respostas voltam às sessões que pediram.
- 04
O sprint anda sozinho
O plano do sprint despacha o próximo ticket quando o anterior fica feito, e mostra o que está à espera de uma pessoa.
Cockpit real com dados de demonstração; detalhes técnicos omitidos.
Porque não existe nada igual
O que a plataforma acrescenta aos agentes usados sozinhos
O Claude, o Codex ou o Copilot, usados sozinhos, dão um assistente a cada pessoa. A plataforma HumanAI acrescenta o que uma equipa precisa para trabalhar com eles:
Pedidos de revisão e aprovação entre colegas
O agente de uma pessoa pode pedir uma revisão, uma decisão ou uma aprovação a outra, e retoma sozinho quando a resposta chega.
Decisões que ficam com quem decide
Uma aprovação de produção é assinada pela pessoa responsável, com a credencial dela. Ninguém aprova por outro.
Continua noutra conta disponível
Quando uma conta ou um agente chega ao limite, o trabalho continua noutra conta ou noutro agente, e a conversa diz porquê.
Memória da equipa
O que uma pessoa aprende chega aos agentes dos colegas do mesmo projecto, depois de um filtro de qualidade.
Regras do projecto em todos os agentes
Fluxo de trabalho, padrões de código, validação de deploys e governança de credenciais, aplicados a cada agente.
Linhas de dados nos sistemas do cliente
Por regra da plataforma, as linhas de dados não são copiadas para documentos, entregáveis nem para o conhecimento da equipa; saem só metadados e agregados. O que se envia a um modelo segue para o fornecedor do agente escolhido.
Traga as suas licenças
As subscrições que a equipa já paga, sem custos escondidos
Cada pessoa liga as suas próprias contas dos agentes. A plataforma não revende modelos nem mistura contas, e o trabalho continua noutra conta disponível quando uma acaba.
As suas contas, com o seu login
Cada pessoa liga as subscrições dos agentes que já tem, com o login feito por ela.
Mais do que uma conta por agente
Contas separadas, cada uma com as suas credenciais.
O melhor modelo primeiro
Começa pelo melhor modelo a que a conta tem acesso e desce para o seguinte quando é preciso.
Continua no limite
Quando uma conta chega ao limite, o trabalho passa para a conta ou o agente seguinte, com uma linha a explicar.
Respeita a data de reposição
Uma conta esgotada fica de lado até à data que o fornecedor indica, em vez de ser tentada outra vez de meia em meia hora.
Consumo medido
Quanto resta, onde se gastou e em que conversa. O que não se mediu aparece como «não medido», nunca como zero.
#01
Agentes e conversas
O problema. Um agente num terminal serve uma pessoa numa máquina. Fecha-se o portátil e o trabalho pára; muda-se de dispositivo e perde-se o fio.
Como funciona
- A pessoa abre uma conversa no browser ou no telemóvel.
- O agente corre no ambiente dela, não no browser.
- Só o que não tem volta pede confirmação, num cartão Aprovar/Negar.
- A conversa continua com o browser fechado e retoma onde ficou.
O que a distingue. O agente trabalha mesmo quando a pessoa não está, e a pessoa decide até onde ele pode ir sozinho.
O que tem (11)
- Vários agentes no mesmo sítio, com escolha de agente e de modelo por conversa
- Modo de planeamento antes de agir
- Orçamento de autonomia: limite de acções e de custo por sessão
- Pontos de restauro com recuperação
- Anexos, templates, paleta de comandos e atalhos de teclado
- Voz para texto ao lado de Enviar, em tempo real, no computador e no telemóvel; áudio processado na UE, com uma chave de uso único por ditado
- Recuperação automática de conversas interrompidas
- Nova conversa para outro assunto enquanto uma tarefa longa corre em segundo plano
- Sessões pré-arrancadas para começar sem espera
- Explorador de ficheiros e entregáveis com pré-visualização
- Primeiros passos para quem chega: o que falta ligar e configurar
#02
Licenças, contas e consumo
O problema. As equipas já pagam subscrições de modelos. Uma plataforma que obriga a usar as chaves dela esconde custos, mistura contas e perde o controlo de quem gastou o quê.
Como funciona
- Cada pessoa liga as suas contas dos agentes no cockpit, com login feito por ela.
- Pode ter mais do que uma conta por agente, cada uma isolada.
- Escolhe a ordem dos agentes e, para cada um, a cadeia de modelos.
- Quando uma conta chega ao limite, fica de lado até à data de reposição e o trabalho passa para a seguinte.
- Vê o consumo medido por conta e por subscrição.
O que a distingue. Sem custos de modelo escondidos e sem chaves partilhadas. Cada pessoa paga e controla o que usa, e o trabalho continua noutra conta disponível quando uma acaba.
O que tem (7)
- Login dos agentes no cockpit, feito pela própria pessoa
- Várias contas por agente, com credenciais separadas
- Cadeia de modelos automática: primeiro o melhor a que a conta tem acesso
- Passagem automática entre contas e entre agentes, com uma linha na conversa a explicar
- Respeito pela data de reposição de cada fornecedor
- Consumos: quanto resta, onde se gastou, em que conversa, em tokens; dinheiro só quando é facturado ao token; «não medido» nunca aparece como zero
- Credenciais de serviços (Azure DevOps, Jira, Confluence, Databricks) pessoais, definidas e testadas pela própria pessoa
#03
Coordenação entre pessoas e agentes
O problema. Num projecto, muito tempo perde-se à espera de alguém: uma aprovação, uma revisão, uma resposta. Com agentes, o problema multiplica-se.
Como funciona
- O agente de uma pessoa faz um pedido dirigido a outra: o que validou, o que precisa, o que se segue.
- A outra pessoa recebe-o no cockpit e no telemóvel, e responde ou deixa o seu agente tratar, conforme a autonomia que definiu.
- Quando a resposta chega, a sessão de quem pediu retoma sozinha.
- Trabalho para outro ambiente (desenvolvimento, testes, produção) vai como tarefa auto-contida, com resultado esperado e verificação.
O que a distingue. Cada pedido tem dono, prova de execução e uma decisão que fica com uma pessoa.
O que tem (9)
- Pedidos dirigidos com tipo, referência e histórico
- Autonomia por pessoa: o que o seu agente aceita sozinho de cada colega
- Retoma automática com limites; trabalho destrutivo em produção nunca retoma sozinho
- Aprovações de produção assinadas pelo responsável, com separação de deveres
- Revisão de pull requests com conclusão automática e revisor obrigatório
- Sala: quem está a trabalhar, em quê e com quem, com sinais reais
- Reservas de permissão para acções sensíveis
- Precedentes: decisões parecidas tomadas antes
- Limpeza automática de perguntas repetidas e marcação de pedidos parados
#04
Planeamento, Jira e Azure DevOps
O problema. O plano vive numa ferramenta, o código noutra e as aprovações numa terceira. Ninguém vê a ordem certa de execução.
Como funciona
- Cada pessoa vê os seus tickets do Jira no cockpit, com a sua credencial.
- O gestor monta o plano do sprint com a ordem de execução e as dependências.
- O plano despacha trabalho para os agentes e acompanha o andamento.
- Pull requests, runs e aprovações aparecem no mesmo sítio.
O que a distingue. O plano dispara o trabalho dos agentes e acompanha-o até ao fim.
O que tem (6)
- Tarefas com sprint, burndown, canvas do ticket e «iniciar numa máquina»
- Plano do sprint com dependências, pistas por pessoa e lembretes
- Ciclo automático do sprint, com disparo manual
- Pull requests e runs: votar, comentar, rever
- Eventos do Azure DevOps que viram trabalho ou aviso
- Documentação e arquivo de sprints, portefólio e dossier
#05
Hoje
O problema. A primeira hora do dia gasta-se a abrir várias ferramentas para saber o que mudou.
Como funciona
- Ao abrir o cockpit, cada pessoa vê o resumo das últimas 24 horas.
- Cada fonte mostra a hora a que foi lida.
- O que precisa de decisão aparece primeiro.
O que a distingue. Só afirma o que observou.
O que tem (2)
- Resumo da manhã por pessoa, sem inventar: o que não se recolheu diz-se
- Actividade da plataforma e novidades
#06
Saúde das pipelines
O problema. Uma pipeline falha de noite e só se descobre quando um relatório sai errado.
Como funciona
- O estado das pipelines é lido com o acesso de cada pessoa.
- Uma pipeline vermelha abre uma tarefa com dono.
- Quando volta a verde, o trabalho fecha.
O que a distingue. Um alerta chega com dono e com o próximo passo.
O que tem (2)
- Estado das pipelines por plataforma
- Alertas que viram tarefas com dono
#07
Conhecimento colectivo
O problema. O que uma pessoa descobre fica na cabeça dela ou num chat que ninguém volta a ler. Os agentes repetem os mesmos erros.
Como funciona
- No fim de um trabalho relevante, o agente propõe uma aprendizagem com evidência.
- De noite, as propostas passam por filtros: segurança, confiança, duplicados e uma revisão automática de qualidade.
- As aprovadas passam a ser sugeridas aos agentes de todos, no momento certo.
- Mede-se o que foi mostrado, lido e usado.
O que a distingue. O conhecimento cresce com o trabalho e é filtrado antes de chegar a todos.
O que tem (7)
- Aprendizagens sugeridas automaticamente em cada pedido ao agente
- Funil nocturno de aprovação, e propostas com aprovar, fundir ou recusar
- Livro de decisões com proveniência
- Competências de equipa para engenharia de dados, Power BI, Microsoft Fabric e processo
- Regras da equipa aplicadas a todos os agentes
- Retorno do conhecimento medido, sem auto-reforço
- Temas, grafo do conhecimento e mapa do código
#08
Plugins por projecto
O problema. Cada pessoa instala extensões por conta própria, e ninguém sabe o que os agentes da equipa têm à disposição.
Como funciona
- Uma pessoa pede uma competência, instrução ou ferramenta.
- O projecto aprova ou recusa.
- A plataforma distribui-a a quem a deve ter e observa o estado.
O que a distingue. Os agentes da equipa têm as mesmas ferramentas, e só as aprovadas.
O que tem (3)
- Catálogo por projecto
- Pedido, aprovação, atribuição e revogação
- Estado observado em cada ambiente
#09
Reuniões e contactos
O problema. As reuniões geram decisões e compromissos que se perdem, e ninguém sabe quem fala com quem no cliente.
Como funciona
- A reunião é detectada no computador da pessoa, que decide se grava.
- A transcrição é feita com identificação de quem fala.
- Os compromissos e as tarefas saem da reunião para o trabalho.
O que a distingue. A reunião fica ligada ao trabalho e às pessoas do projecto.
O que tem (5)
- Gravação numa só máquina, com consentimento
- Transcrição incremental com falantes
- Compromissos, tarefas, acta para o Confluence e histórias relacionadas
- Arquivo e análise das reuniões do projecto
- Contactos: pessoas e entidades, relações e ficha
#10
Relatos e sugestões
O problema. Quem encontra um problema raramente o reporta, porque dá trabalho e não se sabe o que lhe acontece.
Como funciona
- Um botão em qualquer ecrã abre o relato com o contexto já preenchido.
- A pessoa vê o que vai e pode desligar cada parte.
- Depois acompanha o desfecho.
O que a distingue. A pessoa vê todo o contexto que vai no relato e escolhe o que envia.
O que tem (3)
- Relatar problemas e sugerir melhorias, com contexto e anexos
- Recibo, desfecho e junção de duplicados
- Caixa de sugestões
#11
Equipa, acessos e administração
O problema. Dar acesso a uma pessoa nova costuma demorar dias e deixar pontas soltas.
Como funciona
- O gestor convida a pessoa; ela recebe um email, entra e troca a password.
- O gestor pede-lhe um ambiente de trabalho; a administração aprova.
- A pessoa liga os seus agentes e as suas credenciais, guiada pelos primeiros passos.
O que a distingue. Do convite à primeira conversa, sem pedidos por fora.
O que tem (8)
- Pessoas do projecto com o estado do acesso e o próximo passo
- Onboarding por email com estado de entrega
- Entrar com a conta Google, depois de a associar à conta HumanAI; a entrada leva directamente ao cockpit
- A minha conta: perfil, conta Google (associar e desassociar), password, recuperação por email, credenciais
- Preferências de trabalho opcionais e apagáveis
- Papéis, cargos e menus por pessoa
- Criar projecto e aprovar ambientes com segundo factor
- Branding por projecto
#12
Segurança e governança
O problema. Agentes com acesso a sistemas de clientes exigem mais controlo, não menos.
Como funciona
- Cada acção do agente passa pelas guardas da plataforma.
- O que é sensível pede uma pessoa.
- Tudo fica registado para auditoria.
O que a distingue. Estes controlos correm em cada acção do agente, sem depender de alguém se lembrar deles.
O que tem (8)
- Ambiente próprio por pessoa, isolado, que continua a trabalhar com o portátil fechado
- Credenciais pessoais, nunca partilhadas, com detecção automática de partilhas
- Guarda de segredos que bloqueia chaves e passwords antes de chegarem a um ficheiro
- Linhas de dados do cliente fora de documentos e do conhecimento da equipa: só metadados e agregados
- Separação entre projectos, verificada antes de cada distribuição
- Autoria humana: o trabalho sai assinado pela pessoa
- Segundo factor nas aprovações de plataforma e auditoria das acções
- Notificações sem conteúdo: o aviso no telemóvel não leva dados do projecto
#13
Telemóvel e notificações
O problema. A aprovação que bloqueia uma entrega chega quando a pessoa está longe do computador.
Como funciona
- Instala-se o cockpit como aplicação.
- Chega uma notificação quando alguém precisa de si.
- Aprova-se ou responde-se ali mesmo.
O que a distingue. O trabalho não espera que alguém volte ao computador.
O que tem (5)
- Aplicação instalável no telemóvel e no computador, com todas as secções
- Modo claro e escuro
- Voz para texto também no telemóvel
- Notificações quando alguém precisa de si, sem dados do projecto no aviso
- Aprovar, responder e acompanhar sem abrir o portátil
#14
O que sai do trabalho
O problema. O que a IA produz fica muitas vezes numa conversa, longe dos sistemas onde a equipa trabalha.
Como funciona
- O trabalho fica ligado ao ticket.
- Os entregáveis seguem o padrão da equipa.
- Ficam nos sistemas do cliente: Jira, Confluence e o repositório.
O que a distingue. O resultado fica onde a equipa já trabalha, e não numa conversa.
O que tem (4)
- Relatórios HTML bilingues, offline, com gráficos
- Tickets e páginas de documentação com o código incluído
- Diagramas de arquitectura e de fluxo
- Ferramentas de engenharia de dados prontas a usar em cada ambiente
Um resultado medido
Mediana até à conclusão de um pedido de coordenação
Calculada sobre 651 pedidos concluídos, criados entre 3 de setembro e 2 de outubro de 2026, num projecto de cliente em produção. Exclui pedidos ainda abertos.
Inclui pedidos automáticos e pedidos a pessoas, por isso não é tempo de resposta humana. Não mede a duração de uma entrega nem a melhoria face ao processo anterior.
Implementação e acompanhamento
A nossa equipa põe a plataforma a funcionar convosco
Arranque
Ambientes, acessos de cada pessoa, regras do projecto e primeiras conversas, no primeiro dia de trabalho conjunto.
Integração
Jira, Azure DevOps, Databricks e Microsoft Fabric ligados com a credencial de cada pessoa.
Acompanhamento
Engenharia de dados feita connosco na plataforma, com o método de avaliação antes de código e validação humana antes de «feito».
Perguntas frequentes
O que é a plataforma HumanAI?
Uma plataforma de trabalho para equipas de dados e de engenharia que trabalham com agentes de IA. Junta as conversas com os agentes, a coordenação entre pessoas, o conhecimento da equipa e as regras do projecto.
Que agentes de IA suporta?
Hoje corre trabalho com Claude, OpenAI Codex e Kimi. Cada pessoa usa as suas próprias contas.
A IA pode agir sem autorização?
Dentro dos limites de autonomia combinados, sim. O que pede aprovação, e tudo o que vai para produção, espera por uma pessoa.
Os dados do cliente saem dos sistemas do cliente?
Por regra da plataforma, as linhas de dados não são copiadas para documentos nem para o conhecimento da equipa; saem só metadados e agregados. O que se envia a um modelo de IA segue para o fornecedor do agente escolhido; a página Utilização de IA explica o resto.
Como sabemos que uma tarefa está feita?
Cada pedido diz como se verifica e quem valida. Só fecha depois dessa confirmação.
Veja um pedido do princípio ao fim
Na demonstração acompanha um pedido até à validação da entrega, no cockpit real com dados de demonstração.