Como funciona a Iterabase

O que é

A Iterabase dá a uma equipa de operações um conjunto de colaboradores de IA que fazem trabalho real nos sistemas reais da empresa (email, documentos, portais web, pastas partilhadas e bases de dados), enquanto as pessoas confirmam cada ação com consequências. Cada cliente tem o seu próprio ambiente dedicado, com modelos alojados na UE, retenção zero de dados e um registo completo de auditoria.

A Iterabase constrói consigo os primeiros processos; depois, os seus administradores podem criar novos colaboradores pedindo à Sofia. Um colaborador lê o email que chega, desmonta os documentos, consulta portais e sistemas internos, prepara o resultado e pede a uma pessoa que confirme antes de qualquer coisa sair. A Sofia, o seu braço direito, está ao lado da equipa na aplicação e no Microsoft Teams.

Dois processos de referência mostram o que isto significa na prática:

• Do comprovativo de entrega à fatura. Um comprovativo de entrega recebido por email é associado a uma fatura na pasta partilhada do cliente, verificado com dados do ERP em modo de leitura e carregado no portal do transportador.
• Do pedido de cotação à cotação enviada. Um pedido por email com PDFs digitalizados gera pedidos de preço a APIs de transportadores, portais web e fornecedores por email; as respostas são reunidas, as regras de margem aplicadas, uma pessoa aprova e a cotação é enviada.

Visão geral

Funcionalidades

Colaboradores e processos

As pessoas decidem

• Confirmar antes de agir. Cada envio ou submissão é confirmado por uma pessoa sobre o conteúdo exato, ou pré-aprovado apenas para uma lista declarada de destinatários. Tudo o resto volta à confirmação.
• Precisa de si. Uma só lista, de todo o trabalho, com o que espera por uma pessoa: confirmações, perguntas, logins em portais e emails retidos. Cada entrada abre a sua tarefa.
• Sem repetições silenciosas. Um envio com resultado incerto fica marcado como "resultado incerto" e nunca é reenviado automaticamente.
• Atribuição completa. Cada ação regista quem a iniciou, que colaborador agiu e por que canal (browser, API, Chat, Teams).

Email (Microsoft 365 e Google Workspace)

• Receção por webhooks do fornecedor e recuperação incremental, para que nenhuma mensagem se perca depois de uma paragem; consulta periódica só onde não há endpoint público.
• Encaminhamento: as respostas são primeiro associadas ao seu trabalho (pela conversa, depois por um código no assunto, com verificação do domínio do remetente); o email novo segue a regra de início do processo; duplicados dão uma só tarefa.
• Respostas ambíguas ou de outro domínio ficam retidas para uma pessoa. Respostas tardias ficam como evidência.
• Nunca responde automaticamente. O email de saída só passa por passos de envio confirmados ou pré-aprovados.

Documentos

• Um só caminho de quarentena para cada ficheiro, seja qual for a origem: carregamento, email, runner ou ferramenta.
• Análise antivírus (ClamAV) e depois extração de texto e OCR (Apache Tika, Tesseract) como leitura de referência de cada documento.
• Emails anexados (.eml, .msg) são abertos; o corpo é convertido em texto limpo.
• Manuscritos e carimbos: os colaboradores podem ler imagens das páginas com um modelo de visão quando o OCR não chega.

Portais web

• Browsers geridos deixam os colaboradores navegar e ler portais livremente; o próprio browser bloqueia submissões e carregamentos fora das páginas de login.
• Ações com consequências só correm por ferramentas guiadas de cada portal, com as mesmas regras de confirmação ou pré-aprovação do email.
• Logins automáticos com credenciais guardadas e TOTP; as sessões são reutilizadas por conta.
• Login assistido: quando um portal pede um código por SMS ou semelhante, um operador autorizado conclui-o numa vista ao vivo do browser dentro da aplicação. Nada do que escreve é gravado, e entrar na conta errada é recusado.

Dentro da sua rede

• Runner: um serviço Windows assinado (também para Linux) que só faz ligações de saída, com TLS mútuo. É registado em Definições, Runners; parar o serviço corta tudo.
• Pastas partilhadas: leitura só dentro das pastas declaradas.
• Bases de dados e ERP: consultas SQL declaradas, parametrizadas e só de leitura; nunca SQL livre.
• As credenciais ficam na plataforma e são enviadas a cada pedido, nunca guardadas no runner.
• Portais só internos: o mesmo browser gerido pode correr no runner, mantendo as sessões dentro da rede.

Aplicações de desktop Em breve

Alguns sistemas, como o PHC ou o SAP GUI, não têm uma API prática. O runner trabalha com eles como uma pessoa faria, numa máquina reservada para isso.

• Só máquinas dedicadas. A automação corre numa VM com início de sessão automático ou numa sessão remota na sua rede, nunca no PC de um colaborador.
• Uma capacidade do runner, não um segundo agente. O raciocínio fica no seu ambiente Iterabase. O colaborador observa através de capturas de ecrã e da árvore de interface da aplicação, lidas com o modelo de visão.
• As interfaces da própria aplicação, quando existem: Windows UI Automation, SAP GUI Scripting e COM.
• O mesmo modelo de segurança dos browsers. Ler e navegar é livre. Escritas, como lançar um documento ou gravar um registo, só passam por ações guiadas de cada aplicação, declaradas como escritas e confirmadas ou pré-aprovadas.
• Visível e fácil de parar. Um indicador no ecrã mostra quando a automação tem o controlo, cada ação fica num registo local de auditoria, e parar o serviço do runner corta tudo.
• Privilégio mínimo. A conta do runner não tem direitos de administrador do domínio nem direitos locais amplos, corre uma sessão por máquina, e os segredos nunca chegam ao modelo nem à evidência.

Sofia, o seu braço direito

• Uma conversa privada e contínua por pessoa, com uma persona a que o administrador dá nome.
• Consulta com as permissões da própria pessoa, nunca mais do que isso.
• Memória visível: a pessoa vê o que a Sofia guarda e pode editar ou apagar.
• Inicia processos (com confirmação) e tarefas pontuais, acompanhadas como qualquer outro trabalho. Delega pesquisa a colaboradores auxiliares só de leitura.
• Até 6 anexos por mensagem, mais referências a tarefas, processos e documentos.

Criar colaboradores pedindo à Sofia Em breve

Os administradores podem descrever um novo trabalho à Sofia e receber um colaborador pronto, feito com as mesmas peças que a equipa da Iterabase usa.

• Explique como a alguém novo na equipa. Descreva o trabalho por palavras simples, com alguns exemplos reais. A Sofia pergunta o que precisa de saber.
• Um processo legível. A Sofia prepara o gatilho (caixa de correio, chat ou API), os passos, ramos em paralelo, esperas por respostas e prazos, e os pontos de controlo de onde um reinício retoma.
• Ferramentas da biblioteca. Os passos usam as ferramentas de integração da versão e as ligações já configuradas: email, documentos, portais, o runner. Um trabalho que precise de uma ligação que ainda não existe é assinalado, nunca improvisado.
• As suas regras como Skills. Margens, tom, limites e exceções tornam-se instruções escritas que o colaborador segue, visíveis na proposta.
• As credenciais só se escrevem. A proposta declara as credenciais de que precisa; um administrador preenche-as em Definições. A Sofia nunca vê os valores.
• Consequências declaradas à partida. Cada envio ou submissão é marcado como escrita e, por omissão, exige confirmação, ou é pré-aprovado só para os destinatários que indicar.
• Aprova, e só depois corre. Nada corre até um administrador aprovar a proposta. Cada alteração é uma nova versão que revê, e a anterior fica guardada.

Microsoft Teams

• Cada colaborador e a Sofia são aplicações próprias do Teams, geradas para o cliente e instaladas pelo seu administrador do Teams.
• Os utilizadores são ligados automaticamente pelo início de sessão único do Microsoft Entra.
• Os colaboradores avisam e recebem respostas; os cartões de confirmação mostram o conteúdo exato que está a ser aprovado.
• Uma mensagem direta à Sofia é a mesma conversa que na aplicação.

A aplicação

• Hoje, Trabalho, Equipa, Sofia e Relatórios, em inglês e português europeu, utilizável no telemóvel.
• Tempo devolvido: as horas poupadas são estimadas a partir das execuções bem-sucedidas × uma referência por processo, visíveis para todos; a vista detalhada de valor é só para administradores.
• Plano e utilização: os administradores veem o plano, os processos ativos e a utilização.

APIs

• API de trabalho com chaves pessoais e de automação, com conjuntos fixos de permissões.
• API de inferência compatível com OpenAI para os sistemas do próprio cliente, com filtro de modelos e utilização medida.

Confiança, segurança e dados

Os seus dados ficam num ambiente que serve só a sua empresa, e só saem para pedidos aos modelos que nunca são guardados.

Instalação e compra

A maioria dos clientes começa no alojado; a mesma versão pode correr no seu próprio hardware.

Como começar. Construímos o seu primeiro processo gratuitamente e pomo-lo a trabalhar num ambiente dedicado em menos de uma semana; depois, corre sobre o seu trabalho real durante sete dias. Se continuar, o trabalho em pausa retoma onde parou. Se parar, nada de novo começa, não paga nada e apagamos os seus dados.

Os planos crescem com a sua equipa. Dimensionamos o seu na chamada.