Termos e condições técnicas

1. Objeto e escopo

Este documento descreve o Saturn Studio ("a Plataforma"), o componente de orquestração de workflows em nuvem da Suite Rocketbot: capacidades funcionais, limites técnicos, restrições operacionais e responsabilidades por módulo e plano. O Saturn não é comercializado nem faturado como produto independente: é contratado exclusivamente dentro de um plano da Suite.

2. Workflow Builder

Construtor visual no-code para desenhar flows por drag-and-drop, com lógica condicional, laços, transformações de dados e integração com serviços externos. A quantidade de flows é ilimitada em todos os planos (sujeita aos limites práticos de execução do plano). As funções personalizadas em JavaScript estão disponíveis a partir do Standard (modo limitado) e com capacidades avançadas no Corporate — seu uso é responsabilidade do Cliente, o provedor não garante o comportamento desse código.

3. Integrações

Catálogo com mais de 500 apps e componentes padrão em todos os planos, webhooks de entrada, conector nativo a robôs RPA Rocketbot, capacidade de Human-in-the-Loop e conexão com LLMs de terceiros (todos os planos). Apps personalizados estão disponíveis de forma limitada no Standard/Enterprise e avançada no Corporate; os Apps Enterprise (conectores a sistemas corporativos especializados) são exclusivos do Corporate. Quando um flow envia informações a um modelo de IA externo ao ambiente Rocketbot, o tratamento e a segurança dessas informações ficam sujeitos aos termos do provedor desse modelo — a Rocketbot não se responsabiliza pela segurança dos dados já transferidos para fora de seu ambiente.

4. Motor de execução

Processa as instâncias de flows administrando concorrência, tempos de execução, filas, prioridades e arquivos. É o componente mais sensível aos limites técnicos do plano:

O tempo máximo por flow é um teto rígido: uma execução que o atinja é encerrada pela Plataforma. Ao atingir o limite de processos simultâneos, novas solicitações entram em fila até a liberação de capacidade.

5. Monitoramento, governança e segurança

Inclui histórico de execuções, logs detalhados e dashboards de analytics, com retenção FIFO conforme o plano (para necessidades de retenção maiores, o Cliente deve exportar logs periodicamente sob sua responsabilidade). Os audit logs de ações administrativas estão disponíveis em todos os planos.

2FA em todos os planos; SSO com Google/OAuth em todos os planos e Active Directory exclusivo do Corporate; armazenamento cifrado de segredos a partir do Standard (inexistente no Entry 1, portanto o uso produtivo com credenciais sensíveis não é recomendado nesses planos); comunicação cifrada TLS e isolamento lógico entre tenants em todos os planos.

6. Suporte e responsabilidades

O suporte é definido em nível de Suite. Do Cliente: dimensionar o plano, projetar flows dentro dos limites técnicos, gerenciar credenciais e sua rotação, evitar dados confidenciais em logs, exportar evidências quando a retenção do plano for insuficiente, configurar acessos e 2FA. Do provedor: disponibilidade conforme o plano, patches sem afetar os flows do Cliente, aviso de manutenções, suporte técnico, criptografia em trânsito e em repouso, isolamento entre tenants.

O detalhamento das responsabilidades compartilhadas entre o Cliente e o provedor está descrito na matriz de responsabilidade.

7. Limitações

A Plataforma não garante o comportamento de código JavaScript ou apps personalizados do Cliente, nem a disponibilidade de serviços externos integrados. Não fornece nativamente versionamento por Git, ambientes DEV/QA/PROD separados nem integridade evidencial forense sobre logs. A precisão do AI Studio dentro dos flows está sujeita às limitações dos modelos de IA generativa e deve ser validada antes do uso produtivo.

A versão em espanhol deste documento é a versão oficial; as traduções existentes têm caráter referencial.

1. Objeto e escopo

Este documento descreve o RPA Studio ("o Studio"), o ambiente de desenvolvimento integrado (IDE) de construção de robôs RPA da Suite Rocketbot: suas capacidades, componentes, limites técnicos e condições de uso. Aplica-se a todo Cliente que utilize o RPA Studio dentro de qualquer plano da Suite. É um documento técnico e descritivo, não um contrato nem um SLA vinculante por si só.

2. Arquitetura e níveis de serviço

O RPA Studio é uma aplicação desktop multiplataforma instalada nas estações de trabalho dos desenvolvedores do Cliente: ali os robôs são construídos, testados e depurados, sendo depois publicados no repositório central para execução em produção. O acesso é autenticado contra o Orquestrador, com 2FA em todos os planos e SSO conforme o plano.

É oferecido em todos os planos da Suite. O único limite quantitativo próprio do Studio são as licenças de desenvolvimento por plano:

3. Editor de robôs

Ambiente visual de composição de comandos com lógica condicional, laços, variáveis e tratamento de erros, além de execução local passo a passo para teste e depuração. A quantidade de robôs construíveis é ilimitada em todos os planos; a execução em produção ocorre por meio do Orquestrador e está sujeita à cota de processos do plano. O versionamento formal dos robôs publicados é responsabilidade do repositório do Orquestrador.

4. Comandos e módulos

Catálogo de comandos e módulos oficiais mantidos pelo provedor: interação com interfaces gráficas (cliques, digitação, leitura de tela), integração com APIs, bancos de dados e serviços web, e desenvolvimento de comandos personalizados pelo Cliente. O catálogo pode variar devido a mudanças nos sistemas externos integrados; o provedor não garante sua disponibilidade permanente. Os comandos e módulos personalizados desenvolvidos pelo Cliente ou por terceiros ficam sob sua responsabilidade quanto à segurança, manutenção e conformidade normativa — o provedor não responde por erros ou vulnerabilidades introduzidas por esse código. A automação de sistemas de terceiros deve respeitar os termos de uso desses sistemas.

5. Publicação, ciclo de vida e segurança

Os robôs são publicados no repositório centralizado do Orquestrador, que gerencia seu versionamento e atualizações em produção; a promoção entre etapas (desenvolvimento, qualidade, produção) é gerenciada por procedimentos organizacionais do Cliente, que é responsável por testar os robôs antes de publicá-los em produção.

As credenciais dos robôs devem ser gerenciadas pelos mecanismos seguros da Suite (nunca em texto simples). Quando um robô envia informações a serviços externos ao ambiente Rocketbot (incluindo modelos de IA de terceiros via AI Studio ou integrações diretas), o tratamento e a segurança dessas informações ficam sujeitos aos termos do serviço externo escolhido pelo Cliente. A segurança das estações de trabalho onde o Studio é instalado é responsabilidade do Cliente.

6. Suporte

O suporte é definido em nível de Suite e se aplica igualmente a todos os produtos. Os tempos de primeira resposta são medidos em minutos do horário comercial 5×8; o atendimento 7×24 tem custo adicional em todos os planos e o atendimento por meetup é incluído a partir do Standard. O suporte não inclui, salvo acordo expresso, o desenvolvimento de robôs nem a administração das estações de trabalho.

7. Responsabilidades técnicas

Do Cliente: administrar a alocação de licenças de desenvolvimento sem exceder o plano; manter as estações de desenvolvimento seguras e compatíveis; projetar, testar e manter os robôs diante de mudanças nos sistemas automatizados; verificar a conformidade normativa de suas automações; implementar controles compensatórios de separação de etapas e aprovação de mudanças quando o produto não os suportar nativamente.

Do provedor: manter disponíveis os instaladores, módulos oficiais e documentação; corrigir defeitos reproduzíveis; notificar modificações materiais.

O detalhamento das responsabilidades compartilhadas entre o Cliente e o provedor está descrito na matriz de responsabilidade.

8. Limitações

O RPA Studio é uma ferramenta de construção; a operação em produção (agendamento, despacho, monitoramento, logs) é regida pelos T&C do Orquestrador. O provedor não garante que um robô funcionará indefinidamente sem manutenção diante de mudanças nos sistemas automatizados. O uso do RPA Studio para ações que exijam julgamento profissional, decisões regulatórias ou consentimento de terceiros é responsabilidade exclusiva do Cliente.

A versão em espanhol deste documento é a versão oficial; as traduções existentes têm caráter referencial.

1. Objeto e escopo

Este documento descreve o Rocketbot Orquestrador ("o Orquestrador"), incluindo seu módulo Xperience de formulários e portal self-service: capacidades funcionais, componentes, limites técnicos e condições por plano. Não é comercializado como produto independente; é contratado dentro de um dos cinco planos da Suite.

2. Arquitetura e Process Control

Opera sob um modelo cliente-servidor: o servidor centraliza administração, agendamento, fila e persistência, enquanto os agentes instalados nos hosts do Cliente executam os robôs atribuídos e reportam os resultados. O Process Control é a interface unificada de administração (instância única): gestão de robôs, agentes, calendários, fila, usuários, papéis, logs, relatórios e formulários do Xperience, sujeita ao modelo RBAC de permissões.

3. Gestão de robôs, agentes e agendamento

Publicação, versionamento e marcação de robôs no repositório central; registro, monitoramento e configuração de agentes (que se registram sem limite quantitativo — a capacidade efetiva é governada pela cota de processos do plano). O agendamento admite expressões cron, disparo por webhook, por conclusão de outro robô ou pelo envio de um formulário do Xperience.

4. Fila, motor de execução e logs

A fila enfileira, prioriza e atribui execuções ao agente disponível segundo regras de tags, capacidade e prioridade (definidas pelo Cliente). O Orquestrador armazena nativamente quatro tipos de log (Robô, Processo, Usuário, Instância) com registro obrigatório do dado de entrada e do componente onde ocorreu cada erro, consultáveis pelo Control Room ou via API. A retenção depende do plano; para necessidades regulatórias maiores, o Cliente deve exportar logs periodicamente. O Orquestrador não aplica nativamente integridade evidencial forense (assinatura digital, carimbo de tempo TSA) — quando forem exigidas garantias probatórias formais, devem ser implementados controles compensatórios externos.

5. RBAC, repositório e Xperience

O controle de acesso baseado em papéis opera no nível da instância única do Process Control, com SSO Google/OAuth em todos os planos e Active Directory exclusivo do Corporate. O repositório de robôs é um armazém de artefatos (não substitui um sistema Git de controle de versões). O Xperience, incluído em todos os planos, permite formulários públicos (sem login) ou privados (com login e permissões por papel) cujo envio dispara automaticamente uma execução; não tem limite quantitativo próprio — o limite real é governado pela cota de processos do plano, e o Cliente deve projetar os formulários públicos evitando exposição de dados sensíveis ou disparo abusivo.

6. Limites por plano

7. Segurança, integrações e suporte

2FA em todos os planos; SSO Google/OAuth em todos os planos e Active Directory no Corporate. O Orquestrador é o provedor único de identidade da Suite. Comunicação TLS, armazenamento cifrado de credenciais de robôs, e criptografia simétrica autenticada (Fernet/AES-128-CBC+HMAC-SHA256) dos passos do robô no repositório, com rotação de chaves via MultiFernet. A API REST permite integração com sistemas do Cliente sob seus próprios controles de autenticação. O suporte é definido em nível de Suite, com primeira resposta em minutos do horário comercial 5×8, atendimento 7×24 com custo adicional e meetup a partir do Standard.

8. Responsabilidades e limitações

Do Cliente: dimensionar infraestrutura e hosts de agentes; em modalidade on-premise, administrar SO, rede e segurança perimetral; gerenciar credenciais e sua rotação; projetar robôs e formulários evitando exposição de dados confidenciais; manter os agentes atualizados; configurar o RBAC com privilégio mínimo; exportar logs quando a retenção do plano for insuficiente. Do provedor: disponibilidade conforme o plano; atualizações e patches; aviso de manutenções; suporte técnico; criptografia em trânsito e em repouso conforme a modalidade.

O detalhamento das responsabilidades compartilhadas entre o Cliente e o provedor está descrito na matriz de responsabilidade.

O Orquestrador não fornece nativamente ambientes DEV/QA/PROD separados dentro de uma mesma instância, nem controle de versões tipo Git sobre o código dos robôs; esses controles, quando necessários, devem ser implementados por meio de instâncias separadas ou ferramentas externas sob administração do Cliente.

A versão em espanhol deste documento é a versão oficial; as traduções existentes têm caráter referencial.

1. Objeto e escopo

Este documento descreve o AI Studio, o componente da Suite Rocketbot voltado ao processamento inteligente de conteúdo não estruturado (e-mails, documentos, áudio, imagens) e sua conversão em dados estruturados acionáveis por meio de IA generativa, NLP e OCR. É fornecido exclusivamente em modalidade SaaS: a infraestrutura opera na AWS com integração a serviços de IA do Microsoft Azure (incluindo OpenAI), e o Cliente acessa via navegador com conexão criptografada.

2. Módulos de processamento

O Email AI conecta contas Gmail, Outlook, IMAP e POP3 (via OAuth 2.0 para Gmail/Outlook), interpreta o corpo do e-mail por NLP e extrai campos definidos pelo Cliente, disparando ações posteriores. O Documents AI converte PDF e TXT em informações estruturadas sem necessidade de treinamento prévio; documentos digitalizados sem texto incorporado devem ser processados pelo Image AI. O Voice AI transcreve áudio (MP3/WAV, incluindo áudios do WhatsApp, máx. 25 MB) e extrai dados-chave da transcrição. O Image AI aplica OCR com IA em PNG, JPEG, JPG, WEBP e GIF não animado.

A precisão de cada módulo depende da qualidade do conteúdo de origem (resolução, ruído, estrutura do documento). O conteúdo processado por esses módulos é transmitido aos serviços de IA descritos na seção 1; o Cliente deve considerar a natureza desse conteúdo, especialmente diante de dados pessoais ou informações reguladas, e obter os consentimentos necessários dos titulares.

3. Ações e saídas

Após a extração, o AI Studio pode executar ações: visualização no Data View, envio/recebimento por WhatsApp, envio de e-mail, integração com o Rocketbot Xperience para disparar automações, ou chamadas a APIs externas do Cliente (CRM, ERP, sistemas próprios). A disponibilidade efetiva de cada canal depende de o Cliente ter contratado os serviços subjacentes (por exemplo, WhatsApp Business API); o AI Studio não se responsabiliza pela disponibilidade desses sistemas externos.

4. Modelo de créditos

O AI Studio não é comercializado como produto independente: os créditos são alocados como cota anual dentro de cada plano da Suite, sem acúmulo para o ciclo seguinte. Um crédito equivale a um caractere processado pelo modelo de IA (letras, números, símbolos e pontuação). O modelo interno do AI Studio está disponível em todos os planos; a partir do Standard, o Cliente também pode conectar seu próprio modelo externo (Bring Your Own Model, por exemplo Azure OpenAI ou Amazon Bedrock).

O consumo real depende do conteúdo processado; novas tentativas causadas por erros atribuíveis ao Cliente (conteúdo malformado, configuração incorreta) podem gerar consumo adicional.

5. Segurança

Comunicação HTTPS/TLS 1.2, autenticação JWT, filtragem de tráfego via WAF, gestão de credenciais sensíveis via KMS, persistência no Amazon RDS e isolamento lógico entre tenants. Os tokens de acesso a provedores externos (Gmail, Outlook, Drive) estão sujeitos às políticas de segurança de cada provedor de identidade. Quando o Cliente conecta um modelo de IA externo (Bring Your Own Model), o tratamento e a segurança das informações enviadas ficam sujeitos aos termos desse provedor — o provedor da Suite não se responsabiliza pela segurança dos dados já transferidos para fora do ambiente Rocketbot. O modelo interno do AI Studio, por operar dentro do ambiente Rocketbot, não está sujeito a essa exclusão.

6. Suporte e responsabilidades

O suporte é definido em nível de Suite (primeira resposta em minutos do horário comercial 5×8, atendimento 7×24 com custo adicional, meetup a partir do Standard) e não inclui, salvo acordo expresso, a definição de casos de uso nem o ajuste fino de instruções de extração. Do Cliente: avaliar a natureza do conteúdo antes do carregamento em massa; obter os consentimentos necessários; gerenciar e rotacionar credenciais de conexões; validar a saída dos modelos antes de decisões automáticas de alto impacto. Do provedor: disponibilidade conforme o SLA; os controles de segurança da seção 5; notificação de mudanças materiais; documentação técnica atualizada.

O detalhamento das responsabilidades compartilhadas entre o Cliente e o provedor está descrito na matriz de responsabilidade.

7. Limitações sobre resultados de IA

Os resultados dos modelos de IA estão sujeitos a limitações inerentes: possibilidade de erro em conteúdo ambíguo, variabilidade diante de entradas semelhantes, vieses dos dados de treinamento e alucinações não fundamentadas no conteúdo de entrada. O Cliente deve implementar controles de validação proporcionais ao impacto das decisões automatizadas, incluindo revisão humana (Human-in-the-Loop) em cenários críticos. O AI Studio não substitui sistemas de gestão documental, CRM ou ERP, e suas saídas não devem ser interpretadas como aconselhamento profissional (jurídico, contábil, médico, financeiro).

A versão em espanhol deste documento é a versão oficial; as traduções existentes têm caráter referencial.

1. Objeto e escopo

Este documento descreve o Nexus, a plataforma SaaS low-code de aplicações internas da Suite Rocketbot: arquitetura, módulos, edições comerciais, limites técnicos e condições de uso. O Nexus é comercializado como componente SaaS incluído em todos os planos da Suite.

2. Arquitetura

O Nexus é uma aplicação web cliente-servidor: o frontend é uma Single Page Application com o editor visual e o runtime das aplicações publicadas; o backend expõe uma REST API, orquestra a execução de queries e funções, e persiste os metadados em um banco de dados relacional. As entidades principais são: Application, Screen (com histórico de versões), AppTable, DataSource, Query, JsFunction, ApiCall e Action.

3. Builder visual e catálogo de componentes

Editor drag-and-drop sobre uma grade de 12 colunas (restrição x + w ≤ 12, sem sobreposição), com painel de propriedades, painel de ações, editor de código incorporado e pré-visualização em tempo real. A árvore de componentes é serializada como JSON e versionada automaticamente; a edição simultânea de uma mesma tela segue política de last-write-wins. Inclui mais de 30 componentes pré-construídos (layout, input, display, data, chart, media, upload e invisíveis). O componente Div admite HTML e JavaScript livres sob responsabilidade do Cliente, sujeito à Content Security Policy estrita da plataforma.

4. Data Sources, Queries e JS Functions

Os Data Sources conectam bases internas, bases externas (MySQL, PostgreSQL, Supabase, Google Sheets, S3) e componentes da Suite (Orquestrador, Saturn Studio, e um Gateway On-Premises para fontes atrás de firewall corporativo, sem necessidade de abertura de portas de entrada). As credenciais são criptografadas em repouso e o backend nunca as retorna em texto simples ao frontend.

As Queries são operações declarativas (SELECT, COUNT, INSERT, UPDATE, DELETE) com filtros parametrizáveis via bindings estilo mustache, sempre executadas com prepared statements (injeção de SQL não é possível). As JS Functions executam código do Cliente em um sandbox de servidor com acesso controlado a helpers (params, query.execute, table.list, api.execute, $user, etc.), sem acesso direto à rede, ao sistema de arquivos, nem a componentes do runtime do servidor fora desses helpers.

5. API, MCP Server e integrações com a Suite

O Nexus expõe uma REST API completa (/api/v1), endpoints externos autenticados por API Key para integração headless (por exemplo, com robôs do Orquestrador) e um servidor MCP (/mcp) que permite a clientes de IA (Claude Desktop, Cursor, etc.) criar e modificar aplicações por meio de um conjunto controlado de tools. O uso do MCP Server implica que um cliente de IA externo pode modificar aplicações do Cliente; é responsabilidade do Cliente restringir o escopo das MCP Keys emitidas e revisar as modificações antes de publicá-las em produção. Os data sources ROCKETBOT_ORCHESTRATOR e SATURN_STUDIO permitem integração direta com esses produtos da Suite.

6. Limites por plano

7. Modelo de faturamento por Actions

O Nexus fatura por Actions: uma unidade de trabalho útil executada pelo sistema. As leituras (SELECT/COUNT) e as ações puramente de UI não consomem; o consumo ocorre apenas quando a lógica de negócio é de fato executada.

O limite de Actions por mês é um limite rígido: ao ser atingido, a execução de novas Actions é suspensa até a renovação do ciclo ou o upgrade de plano — não há faturamento por consumo excedente. Novas tentativas por erros não controlados também consomem Actions, portanto o Cliente deve projetar queries e funções robustas.

8. Segurança e responsabilidades

Autenticação JWT em cookie HttpOnly (Secure, SameSite=Strict), SSO OAuth/OIDC configurável no Business e Enterprise (obrigatório no Enterprise), papéis OWNER/ADMIN/MAKER/VIEWER, Content Security Policy estrita e rate limiting em todos os endpoints. Do Cliente: dimensionar o plano conforme Actions, apps e usuários esperados; gerenciar usuários, papéis, API Keys e MCP Keys com privilégio mínimo; custodiar e rotacionar credenciais de Data Sources; validar as saídas do MCP Server antes de publicá-las. Do provedor: operar a infraestrutura SaaS; aplicar os controles de segurança; notificar mudanças materiais; prestar suporte conforme o plano.

O detalhamento das responsabilidades compartilhadas entre o Cliente e o provedor está descrito na matriz de responsabilidade.

9. Limitações

O Nexus não substitui sistemas ERP, CRM, HRIS nem sistemas transacionais de missão crítica de alto volume; não oferece nativamente relatórios avançados tipo BI nem separação forte de ambientes DEV/QA/PROD dentro de um mesmo tenant. O código das JS Functions e o HTML dos componentes Div são de responsabilidade do Cliente. As saídas geradas pelo MCP Server dependem do cliente de IA utilizado: o Nexus não garante sua correção semântica.

A versão em espanhol deste documento é a versão oficial; as traduções existentes têm caráter referencial.