Terms of Service

<!-- terms-source-version: 1.25 -->

1. Preâmbulo

LEIA COM ATENÇÃO ANTES DE INSTALAR OU USAR O RUNMYAI DESKTOP.

O RunMyAI Desktop é um software de automação baseado em inteligência artificial que delega capacidade de agir em seu nome a agentes de IA. Isso significa que o Software pode navegar na internet, acessar seus dados locais, enviar comunicações e executar tarefas de forma autônoma ou supervisionada, a partir da sua própria máquina.

Nada disso roda em servidores da Empresa. O Software opera no seu computador pessoal, usando sua conexão de internet, seu endereço IP real e, quando autorizado por você, suas sessões e dados locais. Você pode acessá-lo estando longe desse computador — por um aplicativo de mensagens, pelo navegador na sua própria rede, ou por outra instalação sua — e, quando faz isso, o trabalho continua rodando no seu computador: o que viaja é a mensagem, não a tarefa (Seções 2.2 e 6.2(b)).

Se você não concordar integralmente com este Termo, não instale, não use e não adquira o Software. O uso do Software implica aceite pleno e irrestrito de todas as condições aqui descritas.

Este Termo se destina a ser claro, honesto e acessível. Qualquer dúvida: legal@runmyai.app

---

2. O que é o Software

O RunMyAI Desktop ("Software") é um aplicativo de computador pessoal desenvolvido e distribuído sob a marca RunMyAI pela Ritual do Cálculo, Unipessoal Lda ("Empresa"), sociedade unipessoal por quotas constituída em Portugal, número de identificação de pessoa coletiva (NIPC) 518859002, com sede na Rua Comissão de Iniciativa, n.º 2-A, 2.º andar, Porta 212, Torre Brasil, Leiria, Portugal, contactável em legal@runmyai.app. O Software utiliza modelos de linguagem artificial ("LLM") para planejar e executar tarefas em nome do usuário, de forma autônoma ou supervisionada.

2.1 O Software É

• Uma ferramenta de delegação de autonomia: o usuário instrui o agente, o agente age.
• Um orquestrador de ferramentas: o Software conecta LLMs locais a ferramentas internas (busca web, email, finanças, documentos, sistema de arquivos dentro das pastas de workspace anexadas, geração de imagem, vídeo e voz, automação de processos e demais domínios de produto).
• Um software que opera localmente: processamento, dados e navegação ocorrem na máquina do usuário, não em servidores da Empresa.

2.2 O Software NÃO É

• Um serviço operado pela Empresa: o Software não executa buscas, inferência ou ações em servidores da Empresa, e a Empresa não opera nenhum retransmissor por onde passem suas requisições ou resultados. O Software pode ser acessado remotamente — por um canal de mensagens, pelo navegador na sua própria rede local, ou por outra instalação sua — e em todos esses casos o trabalho continua rodando na sua máquina; apenas o transporte da mensagem atravessa infraestrutura fora dela, seja uma plataforma que você escolheu ou um servidor que você mesmo opera (ver Seções 5.9 e 6.2(b)).
• Um agente com personalidade jurídica: toda ação executada pelo Software é juridicamente atribuída ao usuário que a autorizou. O Software é uma ferramenta, não um agente autônomo com responsabilidade própria.
• Um provedor de modelos de IA: o Software executa inferência na própria máquina do usuário utilizando modelos de linguagem distribuídos com ou baixados pelo Software, todos executando localmente. O Software não chama provedores externos de LLM em nome do usuário e não requer que o usuário forneça chaves de API de terceiros.
• Um software infalível: resultados gerados por LLM são probabilísticos. Podem conter erros, imprecisões, informações desatualizadas ou conteúdo inconsistente com a realidade.

2.3 Capacidades do Software

O Software inclui, sem limitação, as seguintes capacidades que o usuário reconhece e aceita:

• Busca autônoma na internet a partir da máquina do usuário
• Navegação em páginas web com motor de navegação nativo (WKWebView / WebView2)
• Leitura e composição de emails
• Acesso e gerenciamento de dados financeiros locais
• Gerenciamento de tarefas e projetos
• Geração de imagens no computador do usuário (stable-diffusion.cpp; no Apple Silicon também os motores de imagem do mlx-vlm)
• Geração de vídeo no computador do usuário (MLX mlx-video, famílias Wan e LTX-2; stable-diffusion.cpp, Wan, MiniMax-H3 com áudio e vídeo conjuntos, e Wan2.2 S2V, que anima um retrato fornecido pelo usuário sobre uma faixa de fala fornecida pelo usuário)
• Reconstrução de um modelo 3D de um objeto a partir de uma imagem escolhida pelo usuário, no computador do usuário; o arquivo do modelo carrega a marcação de conteúdo gerado por IA da Seção 8.3
• Estimativa da pose corporal de pessoas numa imagem escolhida pelo usuário (pontos-chave, ângulos das articulações e postura), no computador do usuário; não identifica ninguém nem infere emoção ou característica pessoal
• Clipes de áudio que o usuário anexa ou grava, ouvidos pelo modelo local junto com a mensagem do usuário quando esse modelo aceita áudio; os clipes ficam no computador do usuário e só o nome e a duração ficam na conversa
• Síntese e transcrição de voz no computador do usuário (text-to-speech e speech-to-text)
• Execução de planos multietapas com subagentes paralelos
• Execução iterativa com refinamento autônomo (loops de qualidade)
• Controle da interface do usuário via comandos de navegação
• Controle remoto do agente a partir de canais de mensageria (Telegram, iMessage e, quando habilitados, WhatsApp, Signal e um WebChat local), e a partir dos próprios dispositivos pareados do usuário (Remote Link). Cada instalação atende um único usuário; não há relay em nuvem nem acesso multiusuário.
• Execução agendada e proativa de forma autônoma: o agente pode executar tarefas em horário programado e iniciar mensagens ou ações sem um comando contemporâneo (por exemplo, um briefing matinal), sujeito ao nível de autonomia configurado para o produto e a superfície correspondentes.
• Leitura dos arquivos locais de mensagens do usuário quando este habilita um canal de mensageria — por exemplo, o banco de dados do Mensagens no macOS (~/Library/Messages/chat.db), que contém as conversas do usuário com terceiros (ver Seção 5.6).
• Comunicação agente-a-agente (A2A): o agente pode trocar mensagens assinadas criptograficamente com o agente de outra pessoa para negociar um acordo (por exemplo, um horário de reunião) dentro de um mandato delimitado definido pelo usuário, e pode autoconfirmar um resultado que caiba inteiramente nesse mandato (ver Seções 4.2 e 4.5).
• Chamadas de vídeo e áudio entre o usuário e seus contatos, estabelecidas diretamente entre os dois dispositivos (ponto-a-ponto) ou através de um servidor de mídia operado pelo próprio usuário. Nenhuma mídia de chamada passa pela infraestrutura da Empresa em momento algum.
• Gravação dessas chamadas no dispositivo do usuário (e, quando o usuário opera seu próprio servidor de mídia, nesse servidor), seguida de transcrição no dispositivo, resumos gerados por IA e extração de itens de ação e datas, tudo anexado à thread de email de origem e tornado pesquisável (ver Seção 5.9).
• Transcrição ao vivo, na tela, enquanto uma chamada gravada ou uma reunião capturada está em andamento. A transcrição ao vivo nunca é persistida; apenas a transcrição final é armazenada.
• Captura no dispositivo de reuniões realizadas em aplicativos de conferência de terceiros: o Software grava o microfone do usuário e o áudio de sistema do dispositivo. Nenhum bot entra na reunião, nada é instalado do outro lado e os demais participantes não recebem nenhum aviso do Software (ver Seção 5.9).
• Importação de gravações de áudio e vídeo produzidas externamente para o mesmo pipeline local de transcrição e análise, e retranscrição de qualquer gravação armazenada com um modelo mais novo ou maior.
• Assinatura digital de documentos e contratos, e verificação de assinaturas em documentos que o usuário recebe. O usuário assina com um arquivo de certificado ou um token de hardware guardado na máquina, ou com um serviço remoto de assinatura avançada vinculado à sua própria identidade (ver Seção 6.2(i)).
• Adaptação local das próprias orientações de planejamento do agente, sempre ligada. O Software mantém contagens de como seus próprios planos se saem na máquina do usuário e, quando suas regras encontram uma falha recorrente nessas contagens, propõe um pequeno ajuste em como ele trata esse tipo de pedido. A proposta é exibida ao usuário com os números que a sustentam; nada muda até que o usuário a aprove; um ajuste aprovado é medido ao vivo contra o comportamento anterior e retirado pelo Software se for pior; e o usuário pode reverter qualquer ajuste a qualquer momento, o que restaura o comportamento embutido naquilo que esse ajuste mudou. A maioria das avaliações termina sem mudança. O ajuste é proposto por regras, nunca por um modelo, e nada aprende do conteúdo que o agente lê (ver Seções 5.2 e 6.1).

---

3. Execução Local e Identidade Digital

3.1 Suas Buscas Saem da Sua Máquina com Seu IP

Quando o Software realiza buscas na internet, acessa páginas web ou faz requisições a serviços externos em seu nome, essas ações são executadas a partir do seu computador, utilizando:

(a) Seu endereço IP real

O endereço de rede que identifica sua conexão à internet. Diferentemente de serviços de IA baseados em nuvem — nos quais buscas e navegação são realizadas por servidores remotos em datacenters, com endereços IP desses provedores — o RunMyAI Desktop realiza essas operações diretamente do seu dispositivo.

Todo site visitado pelo agente verá seu endereço IP real.

Isso significa que:

• Sua localização geográfica pode ser inferida pelos sites visitados pelo agente.
• Seu provedor de internet (ISP) ou rede corporativa pode registrar essas requisições como parte do seu histórico de navegação.
• Do ponto de vista técnico e legal dos servidores remotos, o tráfego do agente é indistinguível do seu próprio tráfego.

(b) Sua localização geográfica

Inferível a partir do seu endereço IP pelos servidores que o agente contata.

(c) Sua identidade de navegador (browser fingerprint)

O motor de navegação embarcado (WKWebView no macOS, WebView2 no Windows) possui características técnicas — versão do sistema operacional, resolução, idioma, fuso horário, entre outras — que podem ser utilizadas por sites de terceiros para identificar seu dispositivo, independentemente do endereço IP.

(d) Cookies e sessões de navegação

Cada janela de navegação utilizada pelo agente possui armazenamento próprio e isolado, e esse armazenamento é apagado quando a janela é liberada após a busca de uma página. Nada é mantido entre execuções do Software.

Em particular, o agente não herda suas sessões. Cookies e logins criados durante sua navegação manual no painel embarcado não ficam disponíveis para as buscas do agente, e cookies recebidos pelo agente ao buscar uma página não ficam disponíveis para o painel. No Windows, as janelas de navegação do próprio agente compartilham entre si uma única área de armazenamento durante uma execução do Software, que é apagada na próxima inicialização; no macOS cada janela é separada de todas as demais.

Uma consequência é visível para você: como o agente chega a cada site sem cookies anteriores, alguns sites o tratam como visitante de primeira vez e apresentam páginas de verificação que um navegador de uso cotidiano não mostraria.

3.2 Por que isso é diferente do que você está acostumado

Usuários habituados a serviços de IA em nuvem (assistentes de chat hospedados em nuvem e motores de busca) estão acostumados a um modelo onde:

• A busca é realizada por servidores da empresa provedora, em datacenters geograficamente distantes, com endereços IP desses datacenters.
• O site buscado não tem nenhuma relação com o endereço IP do usuário final.

No RunMyAI Desktop, o modelo é radicalmente diferente:

• O agente é você, do ponto de vista da internet. Toda requisição feita pelo agente aparece para o mundo externo como uma requisição feita por você, do seu endereço IP, do seu dispositivo.
• Isso é uma escolha arquitetural deliberada que oferece benefícios de privacidade em relação aos seus dados (seus dados não passam por servidores da Empresa) mas implica que sua identidade de rede é utilizada pelo agente.

3.3 Implicações Legais

Toda atividade realizada pelo agente na internet, a partir da sua máquina, é juridicamente atribuível a você. Isso inclui:

(a) Conformidade com Termos de Uso de terceiros

Você é responsável por garantir que o uso do agente para interagir com sites, serviços e plataformas de terceiros esteja em conformidade com os Termos de Uso desses terceiros. Muitos sites e serviços proíbem acesso automatizado, scraping de conteúdo, uso de bots ou agentes de software. A violação desses termos é de responsabilidade exclusiva do usuário.

(b) Histórico de navegação

Buscas e páginas acessadas pelo agente poderão constar em registros do seu provedor de internet, roteador doméstico ou corporativo, ou sistemas de monitoramento de rede eventualmente presentes no ambiente do usuário.

(c) Rastreamento por terceiros

Sites visitados pelo agente podem coletar dados sobre a visita, definir cookies e processar seu endereço IP exatamente como ocorreria se você tivesse visitado o site manualmente via navegador convencional.

(d) Dados pessoais e GDPR, LGPD e leis estaduais de privacidade dos EUA

Sob o GDPR (Regulamento Geral de Proteção de Dados da União Europeia), a LGPD (Lei Geral de Proteção de Dados do Brasil) e legislações equivalentes, endereços IP constituem dados pessoais. Nos Estados Unidos, que não têm uma lei federal geral de privacidade, a CCPA/CPRA (California Consumer Privacy Act, alterada pelo California Privacy Rights Act) e as demais leis estaduais de privacidade do consumidor tratam o endereço IP como informação pessoal quando ele pode ser razoavelmente associado a uma pessoa ou a um domicílio específico. O processamento do seu endereço IP por sites de terceiros visitados pelo agente ocorre sob as políticas de privacidade desses terceiros, sobre as quais a Empresa não tem controle.

---

4. Autonomia do Agente e Responsabilidade

4.1 Níveis de Autonomia

O Software opera em cinco níveis de autonomia, configurados de forma independente pelo usuário por produto e por superfície (desktop, os canais de mensageria, clientes MCP pareados e qualquer superfície adicional). Execuções agendadas e proativas seguem a configuração do desktop. Os níveis são:

Padrão no primeiro uso. No primeiro uso, todos os produtos e todas as superfícies estão configurados em Nível 0 (Manual). O Software não recomenda elevar o nível. O usuário eleva cada produto e cada superfície conscientemente após avaliar o perfil de risco do fluxo específico. Importar dados de outra instalação não traz as configurações de autonomia daquela instalação: os níveis neste dispositivo só mudam quando o usuário os muda aqui.

O usuário é exclusivamente responsável por configurar um nível de autonomia compatível com seu próprio julgamento, sua capacidade de supervisão disponível e a sensibilidade das tarefas delegadas. A "fadiga de consentimento" — aprovação de ações sem leitura cuidadosa, ou elevação do nível de autonomia sem reflexão — é responsabilidade exclusiva do usuário.

4.2 Ações com Consequências Externas — Assunção de Risco pelo Usuário

Algumas ações, quando executadas pelo agente, atingem terceiros ou sistemas externos que não são parte destes Termos (pessoas, serviços, bancos, agências governamentais, APIs remotas). Exemplos não exaustivos:

1. Envio de emails, mensagens ou qualquer comunicação em nome do usuário
2. Execução de transações financeiras de qualquer valor
3. Aceite de Termos de Serviço em plataformas de terceiros
4. Criação ou modificação de contas em serviços externos
5. Compartilhamento de dados pessoais do usuário com terceiros não previamente autorizados
6. Escrita em APIs, bancos de dados ou serviços externos não pertencentes ao usuário
7. Negociação e autoconfirmação de um acordo com o agente de outra pessoa pelo canal agente-a-agente, dentro do escopo de um mandato definido pelo usuário
8. Execução de qualquer das ações acima de forma agendada ou proativa, enquanto o usuário está longe da máquina e não a supervisiona de forma contemporânea

O usuário expressamente reconhece e aceita que:

• No Nível 0, tais ações não são executadas. Nos Níveis 1 e 2, cada uma dessas ações aguarda a aprovação explícita do usuário.
• No Nível 3, tais ações executam sem aprovação somente pela regra descrita na Seção 4.1; caso contrário, aguardam aprovação.
• No Nível 4, tais ações executam imediatamente sem confirmação em tempo de execução, sujeitas apenas às configurações abaixo. O agente pode enviar, transferir, aceitar ou criar em nome do usuário a qualquer momento, sem qualquer prompt.
• O nível configurado vale em todo o Software, inclusive para operações financeiras, arquivos, email, contatos, documentos e as demais áreas sensíveis. O usuário pode configurar qualquer área como "perguntar sempre"; nesse caso, as ações dela pedem aprovação nos Níveis 1 a 4 (e continuam não sendo executadas no Nível 0). Instalações anteriores à versão 1.24 destes Termos mantêm "perguntar sempre" nas áreas sensíveis até que o usuário mude. Um "permitir sempre" por ação, concedido pelo usuário no desktop, executa aquela ação sem perguntar nos Níveis 1 a 4, nunca no Nível 0. Salvar as credenciais de uma conta nova sempre pede aprovação.
• A proteção contra instruções ocultas em conteúdo externo é uma configuração do usuário, ligada por padrão. Enquanto está ligada, qualquer ação com efeito fora do Software que o agente tome depois de ler conteúdo externo não confiável na mesma execução pede a aprovação do usuário, em qualquer nível (Seção 5.2). O usuário pode desligá-la e religá-la a qualquer momento; enquanto está desligada, essas ações seguem o nível configurado.
• Quando uma aprovação é necessária e não há ninguém presente para dá-la (uma execução agendada ou proativa), a ação não é executada: o pedido é recusado, ou negado quando não é respondido.
• O Software não eleva silenciosamente a configuração de autonomia do usuário, e toda mudança que o usuário faz nela é registrada na trilha de auditoria local.
• O usuário assume integralmente a responsabilidade legal, civil, contratual e reputacional por toda ação executada em todos os níveis, inclusive ações que afetem terceiros que não consentiram com estes Termos e que podem ter políticas próprias regulando interação com agentes de IA (por exemplo, políticas anti-spam de provedores de email, regras de transações por IA de instituições financeiras, políticas contra bots de serviços online). A atribuição destas ações é ao usuário, não ao Software nem à RunMyAI.
• O usuário é exclusivamente responsável por decidir se o Nível 3 ou o Nível 4 é apropriado para cada produto, ação ou superfície, e por definir overrides por ação ou por produto quando desejar controle mais granular. A interface de configuração de autonomia exibe metadados informativos (nível de risco, categorias de dados do usuário tocados, reversibilidade) para apoiar a decisão do usuário no momento da configuração; esses metadados são informativos apenas e não restringem a escolha do usuário.

4.3 Responsabilidade do Usuário

O usuário é o único responsável por:

• Validar e revisar todo output gerado pelo agente antes de tomar decisões ou agir com base nele
• Configurar os níveis de autonomia de forma compatível com sua disponibilidade de supervisão
• Garantir que o uso do Software esteja em conformidade com a legislação aplicável em sua jurisdição
• Todas as ações executadas pelo agente que tenham sido autorizadas, seja explicitamente ou por configuração de autonomia elevada
• Definir instruções claras e precisas ao agente, sabendo que ambiguidades podem resultar em interpretações não intencionadas

4.4 Execução Iterativa e Custo Computacional Local

O Software pode executar planos em ciclos iterativos de refinamento (ex.: gerar, avaliar, refinar, repetir). Toda a inferência roda na máquina do usuário, de modo que cada iteração consome CPU, GPU, memória, disco e bateria locais. O usuário reconhece que planos multietapas, subagentes paralelos e loops de qualidade podem aumentar substancialmente o consumo de recursos locais, e que não há custo monetário por token ou por chamada pago à Empresa nem a qualquer provedor de modelo externo.

4.5 Divulgação de IA na Comunicação do Agente com Terceiros

Quando o agente compõe e envia autonomamente uma comunicação a um terceiro, o Software marca essa comunicação como gerada por IA. Para um email enviado pela ferramenta de correio interna, a marca tem duas partes: uma linha curta legível por humanos no corpo da mensagem (por exemplo, "Enviado pelo agente de IA de [seu nome] — RunMyAI") e um cabeçalho legível por máquina. Para uma mensagem trocada com o agente de outra pessoa pelo canal agente-a-agente, a marca é o cabeçalho legível por máquina: o corpo da mensagem é um envelope assinado e codificado, endereçado a outro agente — sinalização máquina-a-máquina já rotulada como mensagem de agente no nível de protocolo, sem prosa legível por humanos para carregar uma linha no corpo. Esta é a implementação, pelo Software, da obrigação de transparência do Artigo 50 do EU AI Act (ver Seção 8.3). A marca é aplicada automaticamente no momento do envio e o usuário não pode suprimi-la para envios autônomos do agente.

Esta marca não se aplica a mensagens que o próprio usuário compõe na interface e em seguida envia (o usuário é o autor dessas), nem aos metadados de conexão que o Software troca para estabelecer uma chamada (Seção 6.2(d)), que são sinalização de máquina, e não uma comunicação composta pelo agente.

O usuário reconhece que esta marcação automática cobre os canais que o Software controla. Quando o usuário direciona o agente a atuar por uma superfície que o Software não consegue marcar, ou quando a lei local exigir forma de divulgação diferente ou adicional, cabe ao usuário fornecê-la.

---

5. Riscos Conhecidos e Limitações

O usuário reconhece ter sido informado e aceita os seguintes riscos:

5.1 Imprecisão de LLM

Modelos de linguagem artificial geram texto de forma probabilística. Outputs podem ser factualmente incorretos, incompletos, desatualizados, enganosos ou inconsistentes com a realidade. Nenhum output deve ser tratado como fato, conselho profissional (jurídico, financeiro, médico, técnico) ou verdade absoluta sem verificação independente por uma fonte qualificada.

5.2 Prompt Injection

Conteúdo lido pelo agente que não foi escrito pelo usuário — páginas web e resultados de busca, emails, documentos, arquivos, mensagens recebidas em um canal pareado, transcrições de chamadas, itens de agenda, imagens, descrições de modelos e qualquer outro resultado de ferramenta — pode conter texto oculto escrito para dar ao agente instruções próprias ("prompt injection"). O Software trata toda fonte desse tipo como dado, e não como instrução, e aplica a ela os seguintes controles determinísticos, todos na própria máquina do usuário:

• Filtrado antes de o modelo ler. Conteúdo de terceiros passa por um filtro determinístico na máquina do usuário antes de entrar no contexto do modelo. O filtro reconhece formulações conhecidas de injeção e de exfiltração, inclusive formas disfarçadas e codificadas, em todos os idiomas em que o Software é distribuído.
• Uma passagem baseada em modelo, que roda a menos que o usuário a desligue. Além da cadeia determinística, o Software carrega um classificador que roda no próprio dispositivo, desligado no Trust Center pelo usuário que o quiser desligado. Ele vem ligado. Enquanto está ligado e o classificador está pronto, uma página que a cadeia determinística ainda não tenha rejeitado e que o classificador pontue como hostil é retida, e não repassada ao modelo, e o veredicto que acompanha o conteúdo diz qual camada a reteve. Onde a passagem não conseguiu rodar, o Software registra isso, em vez de tratar a página como liberada por ela. O texto é pontuado na própria máquina, e nada sobre a página é enviado a lugar algum para esse fim.
• Marcado como dado. O conteúdo que passa pelo filtro é marcado como texto de terceiros antes de o modelo lê-lo, de modo que o modelo saiba onde ele começa, onde termina e que nada dentro dele é dirigido a ele. Isso abrange páginas web e resultados de busca, corpos de email, documentos com seus títulos e trechos, mensagens recebidas em canais, transcrições de chamadas e o bloco de contexto de contatos, campos de reunião e de resumo derivados da agenda, descrições de transações lidas de um extrato bancário, arquivos locais abertos porque o usuário indicou o caminho, resultados de recuperação cuja origem não está estabelecida, imagens entregues a um modelo de visão, listagens de URLs de mapeamento de site e o texto descritivo que acompanha um modelo instalado pelo usuário. Encurtar o conteúdo para que caiba nunca remove sua marcação. Campos que precisam ficar fora da marcação para serem úteis — assunto, remetente e destinatários de um email, o título de um documento — são limpos de texto com formato de instrução.
• Um veredicto acompanha o conteúdo. Cada resultado de ferramenta carrega um veredicto estruturado — limpo, sanitizado ou rejeitado — declarando o que o filtro fez com ele. Conteúdo rejeitado é retido, e não repassado ao modelo com um aviso anexado.
• A procedência decide a confiança, e procedência não registrada é de terceiros. Todo documento indexado para recuperação registra como chegou: digitado pelo usuário no próprio compositor do Software, adicionado como arquivo, recebido como anexo de email, transcrito de uma gravação ou lido do disco pelo agente. Só o primeiro conta como escrita do próprio usuário: escolher um arquivo não é tê-lo escrito. Aquilo cuja rota não está registrada é tratado como de terceiros, em todos os sistemas operacionais em que o Software roda, e é filtrado como tal. Conteúdo obtido da web fica em um índice separado que aceita apenas texto já liberado pelo filtro.
• Aprovação explícita para qualquer coisa consequente, ligada por padrão. Enquanto a configuração do usuário "Perguntar antes de agir após ler conteúdo externo" está ligada, o que vale a menos que o usuário a desligue, qualquer ação com efeito fora do Software — enviar uma mensagem, gravar um arquivo, movimentar dinheiro, chamar um serviço externo — tomada depois que a execução leu conteúdo de terceiros exige aprovação explícita do usuário. Isso vale qualquer que seja o nível de autonomia configurado pelo usuário para aquele produto e aquela superfície, e nenhuma aprovação automática armazenada o suprime. Quando não há pessoa presente para responder, o pedido é recusado em vez de ficar pendente: uma aprovação que não é respondida, ou que não pode ser entregue, nega. O usuário pode desligar e religar a configuração a qualquer momento; enquanto ela está desligada, essas ações seguem o nível de autonomia configurado, e os demais controles desta Seção continuam em funcionamento.
• Triagem de saída que interrompe a ação. Antes de uma chamada de ferramenta ou de uma mensagem sair do dispositivo, ela é triada em busca de sinais de que levaria dados do usuário para fora. Um sinal aborta a ação; o Software não remove o sinal para enviar o restante.
• O acesso à web não alcança a rede do próprio usuário. Todo endereço que o agente pede ao Software para abrir na web é validado antes de qualquer conexão: um endereço que aponta para a rede local do usuário, para a própria máquina ou para um serviço de metadados de nuvem é recusado, seja ele escrito diretamente, alcançado por um redirecionamento ou devolvido por uma consulta de nome que muda de resposta. A mesma verificação cobre toda página que o navegador embutido do Software carrega em segundo plano.
• Respostas são triadas antes de serem exibidas. A resposta de um modelo é verificada antes de chegar ao usuário: um link para um destino conhecido de exfiltração e qualquer valor com formato de credencial são substituídos por um marcador de redação, e um link para um destino que nenhuma das fontes do turno mencionou é marcado como não confiável.
• A interface não busca nada em nome do modelo. Conteúdo remoto referenciado na resposta de um modelo, sobretudo uma imagem hospedada remotamente, não é carregado enquanto a resposta é exibida. Ele só carrega se o usuário clicar, de modo que a própria saída do modelo não se torne uma requisição a um servidor de terceiros.
• Nada do que o agente lê pode ensiná-lo. A adaptação local das orientações de planejamento descrita na Seção 2.3 aprende apenas de turnos que não leram conteúdo de terceiros algum. Um turno que leu uma página web, um email, um documento, um arquivo, uma mensagem de canal, um resultado de recuperação ou qualquer outro conteúdo que o usuário não escreveu, um turno em que o filtro acima detectou algo e um turno que não se originou no próprio desktop do usuário ficam todos inteiramente fora desse aprendizado. O aprendizado lê contagens de resultados, nunca texto: nenhuma palavra de página, mensagem, documento ou resposta de modelo é lida por ele, de modo que texto livre não pode virar instrução. Ele só pode mudar o agente por meio de um conjunto fechado de ajustes de planejamento, cada um aprovado pelo usuário antes de ser usado e reversível depois. Nenhum ajuste pode adicionar uma ferramenta, elevar um nível de autonomia ou contornar qualquer aprovação descrita nesta Seção.
• Nenhuma etapa na nuvem em nada disso. Todos os controles acima executam na máquina do usuário. Nenhum conteúdo é enviado a um serviço para classificação, e nenhuma inferência ocorre fora do dispositivo.
• Medido, não afirmado. Um corpus adversarial curado de casos de injeção e de exfiltração é executado contra esses controles na própria suíte de testes do Software antes de uma release, e essa execução reporta a taxa medida. É um conjunto curado e não uma taxa real de ataque: estabelece que os controles pegam os casos que ele contém, não que não exista caso que eles deixem passar.

Prompt injection não é um problema resolvido na área, e o Software não o apresenta como resolvido: a pesquisa publicada trata defesas baseadas em detecção como contornáveis por um atacante que se adapte a elas. O que permanece, portanto, é que conteúdo hostil pode alcançar o modelo apesar desses controles e influenciar o que o agente propõe. Limitado pela arquitetura descrita acima, isso significa que o agente pode propor ou executar uma ação não pretendida pelo usuário, dentro do acesso que o usuário lhe concedeu, e que dados já alcançáveis pelo agente podem ser levados a uma ação que o usuário aprova. Não significa que conteúdo saia da máquina por um caminho que o usuário não abriu: não há inferência na nuvem, nada é enviado à Empresa, e os caminhos de saída são os que a Seção 6.2 enumera. O usuário deve estar ciente desse risco, especialmente ao direcionar o agente a conteúdo de uma fonte em que não confia.

Essas salvaguardas reduzem, mas não eliminam, os riscos descritos nesta Seção. São divulgadas aqui como evidência da segurança-por-design do Software; não constituem garantia, e as responsabilidades do usuário sob as Seções 4 e 8 permanecem inalteradas.

5.3 Isolamento de Sessões e Cookies

O agente não navega com as sessões do usuário, e o armazenamento de cada janela de navegação é apagado após o uso (Seção 3.1(d)). Dois limites residuais são declarados aqui em vez de ficarem implícitos. O apagamento é emitido assim que a janela é liberada, mas não há garantia de que tenha sido concluído antes de a mesma janela ser usada para a próxima página. E no Windows as janelas de navegação do agente compartilham entre si uma única área de armazenamento durante uma execução do Software, de modo que um site visitado pelo agente pode conseguir observar armazenamento definido por outro site visitado pelo agente na mesma execução. Nenhum desses caminhos alcança as sessões que o usuário estabelece pessoalmente no painel embarcado. O usuário pode limpar esses dados pelas configurações do Software.

5.4 Escalada Não Intencional de Escopo

Ao operar com múltiplas ferramentas em execução paralela ou iterativa, o agente pode acessar domínios de dados além do originalmente pretendido pelo usuário (ex.: ao buscar por um projeto, o agente pode acessar emails relacionados). Recomenda-se o uso de modo supervisionado para tarefas de alta sensibilidade.

5.5 Disponibilidade de Terceiros

O Software depende de APIs e serviços de terceiros (motores de busca web, provedores de email usados pelo cliente de email local e outros serviços externos) que podem estar indisponíveis, mudar suas políticas de uso ou ser encerrados sem aviso prévio. A Empresa não se responsabiliza por interrupções causadas por terceiros.

5.6 Acesso a Dados Locais Sensíveis

O Software, quando autorizado pelo usuário, pode acessar emails, documentos, dados financeiros e outros dados locais sensíveis. O usuário é responsável por definir quais dados o agente tem permissão de acessar e por não autorizar acesso a dados cuja exposição ao agente seja indesejada.

Em particular, quando o usuário habilita o canal iMessage, o Software recebe Acesso Total ao Disco concedido pelo sistema operacional e lê a base de dados local do Mensagens no macOS (~/Library/Messages/chat.db). Essa base contém todo o histórico de conversas do usuário, inclusive mensagens trocadas com terceiros que não são parte destes Termos. O usuário reconhece esse escopo de acesso e é responsável pelos dados pessoais de terceiros assim disponibilizados ao agente, inclusive por quaisquer obrigações que tenha como controlador de dados sob a legislação de proteção de dados aplicável. Antes de o canal iMessage poder ser habilitado, o Software exige que o usuário reconheça esse acesso a dados de terceiros em uma divulgação dedicada no aplicativo; o canal não pode ser ativado até que esse reconhecimento seja dado.

5.7 Dependência do Arquivo de Chave Local

A base de dados local do usuário (runmyai.db) é criptografada em repouso, e a chave mestra de 256 bits fica armazenada em um arquivo de chave no diretório de dados local do aplicativo, protegido pelas permissões de arquivo do sistema operacional. A Empresa não armazena, copia, deposita em escrow nem transmite a chave mestra, e não existe mecanismo de recuperação do lado da Empresa.

O usuário reconhece que a perda do arquivo de chave — seja por reinstalação do sistema operacional, troca de hardware, perda da conta de usuário, formatação de disco ou qualquer outro evento que o destrua — torna a base de dados local, e as gravações de chamadas e reuniões criptografadas sob a mesma chave mestra (Seção 6.1), permanentemente ilegíveis. Não existe backdoor e a Empresa não consegue recuperar os dados.

O único caminho sancionado para mover dados entre instalações, ou para manter uma cópia independente que sobreviva à perda do arquivo de chave, é o fluxo de Exportação e Importação protegido por senha descrito na Seção 6.7. A exportação contém a base de dados — incluindo toda transcrição, resumo de IA e índice de busca derivados de gravações — mas não os arquivos de mídia das gravações em si, que não possuem caminho de backup independente da chave e são permanentemente perdidos junto com o arquivo de chave. O usuário é o único responsável por criar proativamente tal exportação antes de qualquer evento que possa destruí-lo.

5.8 Salvaguardas dos Canais e do Agent Mesh

Como o controle remoto e a comunicação agente-a-agente ampliam o que o agente pode fazer, o Software aplica salvaguardas determinísticas nessas superfícies que operam independentemente do nível de autonomia configurado:

• Pareamento por proximidade física. Um canal de mensageria só aceita comandos do único dispositivo que o usuário pareou por meio de um código de curta duração gerado no desktop; mensagens de qualquer outra identidade são descartadas.
• Escopo padrão reduzido nos canais remotos. Operações de gravação financeira são excluídas do escopo de capacidades padrão concedido a um canal pareado e exigem opt-in explícito, de modo que um canal comprometido não consiga movimentar dinheiro.
• Redação de saída. Valores com formato de credencial são removidos de toda mensagem que o agente envia por um canal antes de ela sair do dispositivo.
• Mandatos assinados e delimitados para agente-a-agente. Uma negociação agente-a-agente é limitada por um mandato definido pelo usuário e aplicado em código (contrapartes, tópicos, janela de tempo, duração), cada mensagem é assinada e verificada criptograficamente, e um primeiro contato não solicitado fica retido até aprovação humana explícita antes de o agente responder.

Essas salvaguardas reduzem, mas não eliminam, os riscos descritos nesta Seção. São divulgadas aqui como evidência da segurança-por-design do Software; não constituem garantia, e as responsabilidades do usuário sob as Seções 4 e 8 permanecem inalteradas.

5.9 Gravação de Chamadas, Reuniões Capturadas e Gravações Importadas

O Software pode gravar chamadas de vídeo e áudio, capturar reuniões realizadas em aplicativos de conferência de terceiros e importar gravações produzidas em outros lugares (Seção 2.3). Cada gravação, e cada transcrição, resumo e índice de busca derivados dela, contém a voz — e, em chamadas de vídeo, a imagem — e as palavras faladas dos demais participantes, que são terceiros que não são parte deste Termo.

(a) Onde esses dados vivem. Gravação, transcrição, sumarização e indexação rodam no dispositivo do usuário (ou, no caso da gravação de chamada no servidor, em um servidor de mídia operado pelo próprio usuário). Nada é transmitido à Empresa. O usuário é o controlador desses dados pessoais de terceiros sob o GDPR, a LGPD e leis equivalentes, com todas as obrigações que esse papel implica. Quando o usuário grava conversas em contexto profissional ou empresarial, as exceções de uso pessoal das leis de proteção de dados em geral não se aplicam.

(b) O consentimento dos participantes é responsabilidade do usuário. As leis que regem a gravação de conversas variam por jurisdição e são determinadas pela localização de todos os participantes, não apenas a do usuário. Muitas jurisdições exigem o consentimento de todos os participantes antes que uma conversa possa ser gravada ou transcrita; em algumas, gravar sem consentimento é crime. Consentir com a gravação não se estende automaticamente à transcrição, análise por IA, indexação ou armazenamento; onde a lei aplicável distingue essas etapas, cabe ao usuário cobrir cada uma delas. O usuário é o único responsável por identificar a lei aplicável e por obter qualquer consentimento ou fornecer qualquer aviso que ela exija, antes de gravar, capturar ou importar.

(c) O que o Software faz e não faz. Antes da primeira gravação, captura ou importação em uma instalação, o Software exige que o usuário reconheça essa responsabilidade em um aviso dedicado dentro do aplicativo; gravação, captura e importação não ficam disponíveis até que esse reconhecimento seja dado. Enquanto uma chamada é gravada ou uma reunião é capturada, o Software exibe, por padrão, um indicador persistente de gravação no dispositivo do usuário; após dar o reconhecimento descrito nesta alínea, o usuário pode desligar esse indicador nas configurações do Software. Durante uma reunião capturada de um aplicativo de conferência de terceiros, o Software não dá nenhum aviso aos demais participantes — ele grava o áudio que o dispositivo já reproduz e capta. Informar os demais participantes é obrigação única e exclusiva do usuário.

O aviso de reconhecimento e o indicador de gravação são auxílios de conscientização destinados apenas ao usuário. São visíveis somente no dispositivo do próprio usuário, não constituem aviso aos participantes nem consentimento deles, não constituem aconselhamento jurídico e não satisfazem nenhuma obrigação de aviso ou consentimento que a lei aplicável imponha ao usuário. Eles não transferem à Empresa nenhuma parte da responsabilidade descrita na alínea (b), esteja o indicador ligado ou desligado.

(d) Sem identificação biométrica. O Software transcreve fala em texto; ele não cria impressões de voz (voiceprints), modelos de identificação de locutor nem qualquer outro identificador biométrico a partir de gravações. A Empresa não adicionará esse tipo de processamento sem atualizar este Termo.

(e) Retenção e exclusão. Gravações, transcrições e dados derivados são retidos localmente até que o usuário os exclua. Pedidos de participantes gravados para acessar ou excluir seus dados dirigem-se ao usuário como controlador; a Empresa não possui cópia e não pode atendê-los.

---

6. Dados e Privacidade

6.1 Dados Processados Localmente

O Software armazena todos os dados do usuário localmente, no próprio computador do usuário. Seu local principal é o diretório de dados do aplicativo:

• macOS: ~/Library/Application Support/com.runmyai.desktop/
• Windows: %APPDATA%\com.runmyai.desktop\

Caches, logs e arquivos temporários são mantidos nos locais que o sistema operacional oferece para eles, e os arquivos de modelo baixados, nas pastas de modelos que o Software usa. Quando o usuário executa o MyAI a partir de um volume separado (a Carteira MyAI), o conteúdo do usuário -- a base de dados e seu arquivo de chave, o MyAI e os modelos, documentos, imagens, mídia gerada, gravações, anexos, os backups locais, o local padrão da exportação protegida por senha e o estado de sessão dos canais de mensageria -- é mantido nesse volume, e as cópias desse conteúdo que versões anteriores do Software deixaram no computador são movidas para lá no início. O que permanece no computador nesse modo é o estado do próprio aplicativo (suas preferências, a licença, diagnósticos, programas auxiliares e o registro de aceite destes Termos), o modelo de síntese de voz, os logs, e caches e arquivos temporários, incluindo o espaço de trabalho de uma execução de treino do MyAI enquanto essa execução está em andamento.

O repositório primário dos dados do usuário é o arquivo de base de dados local runmyai.db dentro desse diretório. Essa base contém, entre outros, corpos e credenciais de email, extrações financeiras, histórico de conversas do MyChat, embeddings vetoriais, dados de diagnóstico locais e tudo aquilo com que o MyAI aprende: os pares de treino do MyAI não são mantidos como arquivos próprios, mas derivados da base a cada execução de treino, e o estado desse treino (o que já foi extraído, o conjunto fixo de avaliação e a linha de base de retenção) também fica na base.

A mesma base guarda também o registro de cada ajuste que a adaptação local das orientações de planejamento (Seção 2.3) propôs, com sua aprovação, rejeição, medições ao vivo, promoção, retirada ou reversão e as contagens por trás de cada um. A base guarda também o histórico de mensagens dos próprios subagentes do agente que uma conversa mantém endereçáveis entre pedidos. Ambos os repositórios são criptografados com o restante da base, são apagados quando o usuário exclui seus dados (Seção 6.4) — o histórico de subagentes também quando sua conversa é excluída — e saem da máquina apenas dentro de um relato de bug que o usuário revisa e envia (Seção 6.6(a)) ou, no caso dos ajustes, como as contagens anônimas de resultado descritas na Seção 6.9(a).

O arquivo runmyai.db completo é criptografado em repouso com AES-256 via SQLCipher v4 (AES-256-CBC em nível de página, HMAC-SHA512, derivação de chave PBKDF2-HMAC-SHA512 com 256.000 iterações). A chave mestra de 256 bits é gerada no primeiro uso por gerador criptograficamente seguro e armazenada em um arquivo de chave no diretório de dados local do aplicativo, protegido pelas permissões de arquivo do sistema operacional. A Empresa nunca recebe a chave e não possui mecanismo para descriptografar os dados do usuário. Ver Seção 5.7 para as consequências da perda do arquivo de chave.

Três tipos de arquivo são mantidos fora do runmyai.db e são criptografados em repouso com AES-256-GCM sob chaves derivadas da mesma chave mestra que protege a base de dados: gravações de chamadas e reuniões, anexos de email (os recebidos e os anexados a um rascunho) e a cópia temporária da base que a Redefinição inteligente faz enquanto roda e remove quando termina. Um anexo é decifrado apenas quando o usuário o abre ou salva ou quando o Software o lê; a cópia decifrada é temporária e é removida quando deixa de ser necessária e a cada início do aplicativo.

Gravações de chamadas e reuniões são armazenadas como arquivos individuais em um subdiretório do mesmo diretório de dados do aplicativo. Uma gravação é decifrada apenas transitoriamente, para reprodução ou processamento; as cópias transitórias são removidas quando deixam de ser necessárias e a cada início do aplicativo. Gravações feitas por versões do Software anteriores a essa criptografia são migradas automaticamente para a forma criptografada. As transcrições, os resumos de IA e os índices de busca derivados das gravações são armazenados dentro da base criptografada. Excluir uma gravação remove o arquivo de mídia e seus dados derivados. Quando o usuário opera seu próprio servidor de mídia (Seções 2.3 e 5.9), as gravações de chamada do lado do servidor são armazenadas no disco desse servidor, sob retenção e controle de acesso administrados pelo usuário.

Os itens a seguir são armazenados sem criptografia, cada um pelo motivo indicado, e são protegidos pelas permissões de arquivo do sistema operacional (e pela criptografia de disco completo, quando o usuário a ativou):

• Arquivos que o Software abre pelo caminho ou entrega a outro programa: imagens em conversas; imagens e vídeos gerados, que carregam o marcador de conteúdo gerado por IA (Seção 8.3); documentos do MyDocs com seus arquivos de origem, revisões, cópias assinadas e modelos; a foto de perfil do usuário; e imagens coladas em um rascunho de email.
• Sessões de canais de mensageria: a sessão do WhatsApp, que o componente do WhatsApp lê do disco e da qual uma cópia criptografada também é mantida na base; e o estado da conta do Signal (chaves, sessões e armazenamento de mensagens), que o componente do Signal mantém em formato próprio em uma pasta do aplicativo legível apenas pela conta do próprio usuário.
• Pesos de modelo do MyAI: os adaptadores e modelos fundidos treinados com os dados do usuário, que os runtimes de modelo carregam do disco. Os pares de treino são gravados em disco apenas durante uma execução de treino, em uma pasta legível apenas pela conta do próprio usuário, e são excluídos quando a execução termina e, se ela foi interrompida, no início seguinte.
• Logs: os arquivos de log do aplicativo, até cerca de 128 MB, com os mais antigos removidos primeiro, que podem conter endereços de email, trechos de conversas e buscas, prompts dados aos geradores e caminhos de arquivo.
• Backups locais: os backups que o Software faz em sua própria pasta de backups (por padrão ao fechar o aplicativo, mantendo os 10 mais recentes), que contêm uma cópia da base, ainda criptografada, junto com cópias sem criptografia dos arquivos listados acima.
• Arquivos de trabalho: o armazenamento das janelas de navegação do agente (Seção 3.1(d)) e os arquivos temporários que o Software entrega a um conversor, a um transcritor, a um reprodutor ou a outro programa, que são removidos após o uso.
• O arquivo de chave da base descrito acima, e os snapshots de prefixo descritos a seguir.

Quando o Software executa um modelo local por meio do seu runtime llama.cpp, ele também mantém, em uma pasta .kv-cache dentro da pasta que contém o arquivo desse modelo, um snapshot por modelo do estado de trabalho pré-computado do modelo (seu cache de chave-valor) para o prefixo fixo de instruções que o Software coloca antes de cada pedido, para que esse prefixo não precise ser processado de novo a cada início. Um snapshot contém apenas esse prefixo fixo de instruções, construído exclusivamente a partir de texto de instruções que acompanha o Software e é o mesmo para todo usuário, junto com uma mensagem fixa de preenchimento e, quando o próprio formato de prompt do modelo a insere, a data atual. Ele nunca contém o conteúdo de uma conversa ou de um pedido, nem o perfil do usuário (como o nome, o horário de trabalho ou o idioma preferido do usuário). Ele é armazenado sem criptografia por não conter conteúdo do usuário, mas cada snapshot é autenticado com uma chave derivada da chave da base de dados, e um snapshot que falha nessa verificação é excluído e não é usado. A cada início o Software exclui, na pasta de snapshots de cada modelo que tem registrado, todo snapshot que não esteja assim autenticado, que tenha sido gravado em um formato de snapshot anterior ou cujo modelo não esteja mais presente; o primeiro início de cada nova versão do Software faz o mesmo em toda pasta de snapshots sob suas pastas de modelos. Excluir todos os dados e a Redefinição inteligente (Seção 6.4) esvaziam a pasta de snapshots de cada modelo que o Software tem registrado e toda pasta de snapshots sob suas pastas de modelos, sem tocar nos arquivos de modelo.

Esses dados NÃO são transmitidos à RunMyAI, exceto conforme descrito em 6.2; quando o usuário submete explicitamente um relato de bug, conforme descrito em 6.6; ou como a contribuição automática e anônima de desempenho ao ModelIndex descrita em 6.9.

6.2 Dados Transmitidos a Terceiros

Ao utilizar o Software, os seguintes dados podem ser transmitidos a serviços de terceiros:

(a) Sites e serviços acessados pelo agente Conteúdo web acessado pelo agente e retornado para o contexto do LLM local. O endereço IP e o browser fingerprint do usuário são transmitidos aos servidores desses sites (ver Seção 3).

(b) Plataformas de mensageria usadas para controlar o agente Quando o usuário pareia um canal de mensageria, o conteúdo das mensagens que o usuário envia ao agente e as respostas do agente transitam pela infraestrutura dessa plataforma (por exemplo, os servidores da Bot API do Telegram, ou os servidores da Meta para o WhatsApp). No iMessage, as respostas são enviadas pelo próprio aplicativo Mensagens do usuário. Esse tráfego ocorre sob os termos e a política de privacidade da plataforma; não passa pelos servidores da RunMyAI.

(c) A conta de email do próprio usuário e os destinatários das comunicações do agente Para oferecer as funções de email, calendário e contatos, o Software se conecta aos servidores do provedor de email que o usuário configura e sincroniza com eles a caixa de correio, os calendários e os contatos do próprio usuário: por IMAP e SMTP, por JMAP e seu canal de push, por CalDAV e CardDAV e, no caso de um servidor de email auto-hospedado que o usuário opera, pela interface de conta desse servidor. Essas conexões levam as credenciais e os emails do usuário de e para o seu próprio provedor, sob os termos desse provedor. Quando o usuário testa a entregabilidade do seu próprio domínio, o Software também envia mensagens de teste pelo servidor de saída do próprio usuário para uma caixa de correio do usuário que o Software sincroniza, e verifica a configuração de criptografia (TLS) do servidor de email do usuário.

Emails enviados pelo agente e mensagens agente-a-agente são entregues a seus destinatários pelo provedor de email do próprio usuário e pelo provedor de email do destinatário. Não passam pelos servidores da RunMyAI. Tais comunicações de saída do agente carregam a marca de divulgação de IA descrita na Seção 4.5. Para autenticar o agente de outra pessoa, o Software consulta um registro DNS de texto público no domínio de email dessa pessoa, pelo resolvedor DNS do sistema, com fallback para um resolvedor público apenas quando a configuração do sistema não pode ser lida.

Quando o usuário escolhe Cancelar inscrição em uma mensagem cujo remetente oferece cancelamento com um clique (RFC 8058), e somente então, o Software envia uma única requisição HTTPS POST, com o corpo List-Unsubscribe=One-Click, ao endereço que o remetente escreveu nessa mensagem. A requisição não carrega conteúdo de mensagem nem credenciais. O servidor que a recebe vê o endereço IP do usuário e fica sabendo que a caixa de correio está ativa. O Software se recusa a enviá-la a um endereço que não seja HTTPS ou que aponte para uma rede privada ou local, não segue redirecionamentos e desiste após 15 segundos; quando o cancelamento com um clique não é oferecido ou não tem sucesso, o Software oferece a página ou o endereço do remetente para que o usuário os abra.

(d) Sinalização de chamadas pelo provedor de email do usuário Quando o usuário inicia ou atende uma chamada (Seção 2.3), os metadados de conexão — um convite de chamada estruturado e sua resposta, contendo endereços de rede e chaves públicas de criptografia, nunca conteúdo de chamada — trafegam como email pelos provedores de email do usuário e do contato, sob os termos e as políticas de privacidade desses provedores. Além disso, todo email enviado pelo cliente de email interno carrega um pequeno cabeçalho legível por máquina que marca a instalação remetente como capaz de receber chamadas; destinatários e provedores de email podem, portanto, tecnicamente observar que o usuário usa o Software. A mídia da chamada em si nunca transita pelo provedor de email: ela flui diretamente entre os dispositivos ou pelo servidor de mídia do próprio usuário (Seção 5.9).

(e) Configuração de conta de email (autodescoberta) Quando o usuário adiciona uma conta de email, o Software determina automaticamente as configurações de servidor do provedor. Para isso, ele pode consultar, em paralelo: os endpoints de configuração do próprio provedor (autoconfig.<dominio> e caminhos well-known no domínio do provedor — essas requisições podem carregar o endereço de email sendo configurado, que esse provedor já conhece); o banco de dados público de configuração Thunderbird ISPDB, operado pela Mozilla Foundation (autoconfig.thunderbird.net — essa requisição carrega apenas o domínio de email, nunca o endereço); e os registros DNS públicos do domínio de email (consultas SRV e MX pelo resolvedor DNS do sistema, com fallback para um resolvedor público apenas quando a configuração do sistema não pode ser lida). Essas consultas rodam apenas durante a configuração da conta, por iniciativa do usuário; não transmitem senha, conteúdo de mensagem nem identidade além do descrito acima, e recebem em retorno apenas dados públicos de configuração de servidor.

(f) Endpoints de dados de referência e medição O Software faz um pequeno conjunto de requisições públicas e não autenticadas que não carregam conteúdo, conta nem identidade do usuário: taxas de câmbio para as funções financeiras (taxas fiat do serviço Frankfurter; taxas de cripto do serviço CoinGecko — as requisições carregam apenas códigos de moeda), e medição de velocidade e latência de internet contra endpoints públicos de medição (os endpoints de speed-test e de trace de rede da Cloudflare e servidores mirror da Hetzner), usada para dimensionar downloads de modelo e exibir a saúde da conexão. Se o computador está conectado ou não é lido do sistema operacional, o que não envia nada. Enquanto o Software está em execução, ele também usa a mesma medição de latência em segundo plano, apenas quando há um motivo: quando o sistema operacional informa que a rede mudou; quando é necessária uma leitura, e a última tem mais de 10 minutos, porque o agente está planejando uma tarefa que pode usar a web ou porque o usuário abre o painel Alcance; após uma verificação que falhou, de novo após 1, 2, 4 e 8 minutos e depois a cada 15 minutos até que uma tenha sucesso; a cada 15 minutos enquanto uma janela do Software está em primeiro plano; e uma vez cerca de um minuto após a inicialização. Cada uma dessas verificações envia uma requisição, alternando entre o endpoint de trace de rede da Cloudflare e um servidor mirror da Hetzner, ou duas, uma a cada um, quando o painel Alcance pede uma leitura nova; cada requisição é uma requisição HTTPS simples cuja resposta não é lida, apenas cronometrada. Nenhuma verificação é enviada enquanto o sistema operacional informa que não há conexão de rede. Como em qualquer requisição de internet, o endereço IP do usuário é tecnicamente visível ao servidor receptor; os resultados são armazenados apenas localmente.

(g) Gestão de DNS de domínio (configurada pelo usuário) Quando o usuário conecta a própria conta Cloudflare para gerenciar registros DNS do seu domínio de email, o Software envia requisições autenticadas pelo token de API do próprio usuário à API da Cloudflare, e verifica a propagação dos registros consultando um resolvedor público DNS-over-HTTPS para o domínio do usuário. A funcionalidade é iniciada pelo usuário e usa a conta do próprio usuário do início ao fim. Além disso, quando o usuário verifica se o seu domínio está pronto para entregar emails a determinados endereços, o Software envia consultas DNS-over-HTTPS ao resolvedor público da Cloudflare pelo registro de troca de email (MX) do domínio de cada endereço que o usuário informa, assim como pelos registros do domínio do próprio usuário. Essas consultas carregam apenas nomes de domínio, nunca um endereço completo nem conteúdo de mensagem; a Cloudflare, como operadora do resolvedor, vê quais domínios foram consultados e o endereço IP do usuário.

(h) Software cliente MCP pareado (local, configurado pelo usuário) Quando o usuário pareia o próprio software cliente compatível com MCP ao Software, o Software aceita requisições desse cliente apenas em um endpoint local de loopback (127.0.0.1:57292); o endpoint nunca é alcançável pela rede e só funciona enquanto ao menos um pareamento desse tipo estiver ativo. Cada pareamento é um dispositivo com o próprio token bearer, do qual o Software armazena apenas um hash, e o próprio escopo de acesso, que por padrão é somente leitura; o pareamento expira após 90 dias e o usuário pode revogá-lo a qualquer momento, com efeito na requisição seguinte. Antes de atender qualquer requisição o Software verifica este aceite, o token, um limite de taxa por dispositivo e o escopo; toda ação que altera dados exige aprovação na área de trabalho do usuário, em qualquer escopo; toda resposta passa pela mesma redação de segredos de saída aplicada aos canais de mensagens; e toda chamada é registrada na trilha de auditoria local com o dispositivo como origem. O cliente pareado é software do próprio usuário: os dados que ele recebe são o que o escopo escolhido pelo usuário permite, e para onde esse cliente os encaminha -- inclusive para qualquer modelo ou serviço remoto que o sustente -- é configuração e responsabilidade do usuário, sob os termos desse cliente e serviço. O Software nada envia a tal cliente por iniciativa própria.

(i) Assinatura de documentos e verificação de assinaturas (configurada pelo usuário) Quando o usuário assina um documento com um certificado digital, o que o Software contata depende do certificado escolhido. Um arquivo de certificado ou um token de hardware guardado na máquina assina inteiramente no dispositivo e não contata ninguém. Uma assinatura avançada gov.br, não: o usuário faz login nesse serviço (sso.acesso.gov.br), e o Software então solicita ao serviço de assinatura operado pelo ITI (assinatura-api.iti.br) o certificado público do próprio usuário e a produção da assinatura. A requisição de assinatura carrega o digest SHA-256 do documento e nada mais — o documento em si nunca sai da máquina nesse caminho — e a autorização utilizada é de uso único, de curta duração, e nunca gravada em disco. Quando o usuário configura uma autoridade de carimbo do tempo, o Software envia a essa autoridade o digest da assinatura para que ela ateste o horário, novamente nunca o documento. Separadamente, quando o Software verifica se um certificado de assinatura continua válido — o do próprio usuário, ou um de documento que o usuário recebeu — ele contata os endpoints de revogação indicados dentro desse certificado (um respondedor OCSP, ou um ponto de distribuição de lista de certificados revogados). Esses endereços são escolhidos por quem emitiu o certificado, não pelo usuário nem pela Empresa, e a requisição identifica o certificado consultado. Tudo isso ocorre apenas quando o usuário assina um documento ou verifica uma assinatura.

(j) Conta de serviço de pagamento do próprio usuário (configurada pelo usuário) Quando o usuário conecta a própria conta de serviço de pagamento (Stripe) às funções financeiras, o Software envia requisições autenticadas pela chave de API do próprio usuário a esse serviço: para verificar a conexão e para criar links de pagamento, que carregam o valor, a moeda e a referência que o usuário informa para aquela cobrança. A conta, as credenciais e a relação com o pagador são do próprio usuário, sob os termos desse serviço; a Empresa não opera nada nesse caminho e nada recebe dele.

(k) Ponte de lembretes e tarefas nativas (configurada pelo usuário) Quando o usuário habilita a ponte de lembretes e tarefas, o Software grava lembretes e tarefas do MyProject em uma lista de lembretes que o usuário escolheu no próprio aplicativo de lembretes do sistema operacional, e lê de volta o que o usuário escreveu nessa lista, para que uma alteração feita de um lado apareça do outro. A ponte fica desligada até o usuário ligá-la, e ligá-la exige o aceite de um aviso que nomeia o destino; o usuário então escolhe quais listas estão no escopo. O Software lê a conta de cada lista no momento da operação para determinar se a lista fica apenas no dispositivo ou pertence a uma conta que sincroniza com um servidor, e mostra essa classificação em cada lista no seletor. Quando a lista pertence a uma conta sincronizada, as cópias que o Software grava nela são levadas para fora do dispositivo pela própria sincronização dessa conta, até o provedor dessa conta, sob os termos e a política de privacidade desse provedor; o Software não contata nenhum servidor nesse caminho e não nomeia nenhum destino próprio. Desmarcar a lista, ou desligar a ponte, interrompe a próxima operação. Quando uma lista é compartilhada com outras pessoas, o texto nela pode ter sido escrito por essas outras pessoas.

6.3 Telemetria, Analytics e Conexões de Serviço

O RunMyAI Desktop não coleta telemetria sobre o conteúdo ou a atividade do usuário: nenhuma analítica do que o usuário faz, nenhum relato automático de falhas, nenhum rastreamento de teclas ou interações, e nada que identifique o usuário. Apenas dois tipos de dado sobre o sistema do usuário saem do dispositivo para a RunMyAI, e nenhum carrega a identidade, o conteúdo ou o IP armazenado do usuário:

• uma contribuição de desempenho anônima e automática ao ModelIndex (Seção 6.9), que relata como os modelos rodaram no hardware, nunca o que o usuário fez com eles; e
• um relato de bug que o usuário escolhe enviar (Seção 6.6), que é iniciado pelo usuário e exibido integralmente para revisão antes de sair do dispositivo.

(a) Conexões de serviço. Além desses dois fluxos de dados, o Software realiza um pequeno conjunto de conexões de serviço, livres de conteúdo, com a infraestrutura operada pela Empresa. Elas existem para manter o Software funcionando — atualizações, licença, entrega de modelos — e nenhuma delas transmite conteúdo do usuário, atividade ou qualquer telemetria sobre o usuário:

1. Verificação e download de atualização. O Software pergunta periodicamente (na abertura e aproximadamente a cada seis horas) ao endpoint de atualização da Empresa se existe uma versão mais nova. A requisição carrega o sistema operacional, a arquitetura de CPU, a versão instalada do app e um número de coorte de rollout — um número aleatório entre 0 e 99, sorteado uma única vez no dispositivo e armazenado localmente, que permite oferecer uma nova versão a uma porcentagem crescente das instalações. O número de coorte não é derivado do hardware e é compartilhado por aproximadamente uma instalação em cada cem; ele não identifica nem o dispositivo nem o usuário. Nada mais acompanha a requisição. Quando há atualização, o Software a baixa da mesma infraestrutura e verifica criptograficamente sua assinatura antes de aplicar.
2. Ativação e renovação de licença. A ativação acontece de duas maneiras, e nenhuma delas envia dados de uso ou conteúdo do usuário. Colar um token de licença é local: o Software verifica a assinatura do token no próprio dispositivo e não contata servidor algum; esse token — um valor que identifica a compra, não o conteúdo do usuário — é enviado pela primeira vez ao endpoint de licença da Empresa na primeira renovação periódica, e periodicamente depois, para renovar a titularidade. Entrar na conta pareia esta instalação com a conta do usuário: o Software pede ao endpoint de licença da Empresa um código curto de confirmação, abre a página de confirmação da Empresa no navegador para que o usuário aprove esse código onde já está autenticado, e então recolhe o token de licença no mesmo endpoint. Essas requisições levam o código de confirmação, um segredo gerado para esta instalação e mantido somente nela (nunca sai do dispositivo e é descartado quando o pareamento se resolve) e os dois valores descritos a seguir. A página de confirmação é aberta sem o código no endereço, de modo que o link sozinho não aprova nada. Nesse caminho o token chega na ativação e é renovado periodicamente como um token colado. Dois outros valores acompanham essas requisições, e somente estes: um identificador aleatório de instalação gerado no dispositivo (um valor aleatório guardado localmente, não derivado do hardware, sem número de série, endereço de rede ou qualquer outra propriedade da máquina) e a família do sistema operacional (por exemplo, "macos"). Eles existem para que uma licença funcione em um número limitado de dispositivos e para que o usuário veja e remova seus próprios dispositivos ativados na sua conta. Nenhum dado de uso acompanha o token.
3. Gestão de assinatura. Quando o usuário abre Gerenciar Assinatura, requisições autenticadas pelo token de licença são enviadas ao endpoint de assinatura da Empresa; o pagamento em si é processado pelo provedor de pagamento sob os termos dele.
4. Notas de versão. Abrir as notas de versão no app busca o changelog público no endpoint da Empresa; a requisição não carrega payload.
5. Catálogo e download de modelos. Baixar um modelo ou componente de runtime busca arquivos no repositório de modelos da Empresa ou no hub de origem do modelo; a requisição identifica o arquivo baixado, não o usuário.
6. Ficha de contribuição ao ModelIndex. Quando há menos de duas fichas anônimas não usadas (Seção 6.9(a)) guardadas no dispositivo, o Software pede uma num ciclo de contribuição: primeiro busca a chave pública de fichas da Empresa, uma requisição que não carrega payload, e depois envia o token de licença, o identificador dessa chave pública e um valor cegado que a Empresa assina sem conseguir lê-lo. A requisição não carrega dados do relato nem mais nada, e a Empresa emite no máximo duas fichas por licença em qualquer janela de 20 horas. O que a Empresa guarda sobre ela está na Seção 6.9(a).

Como em qualquer requisição de internet, o endereço IP do usuário é tecnicamente visível ao servidor receptor no nível de rede. A Empresa não usa essas conexões para identificar, rastrear ou traçar perfil do usuário.

O relato de bug é sempre:

• Opt-in por relato — não existe um botão global de "compartilhar telemetria" nem qualquer transmissão silenciosa em segundo plano.
• Pré-visualizado por completo antes do envio — o usuário vê cada campo que será transmitido, em uma tela de pré-visualização obrigatória, e deve confirmar explicitamente antes que o relato saia do dispositivo.
• Cancelável a qualquer momento antes do usuário clicar em Enviar, sem qualquer transmissão residual.
• Limitado a uma lista fixa de campos técnicos autorizados (identificação e classificação do relato, ambiente de execução, um digest opcional da execução que falhou, uma contagem de recorrência de falha e um resumo abstrato curto gerado pela IA embarcada no dispositivo — a lista completa está na Seção 6.6(a)).

A Empresa não introduzirá qualquer forma de coleta passiva ou automática de dados no Software sem antes atualizar este Termo e obter o consentimento renovado do usuário.

6.4 Retenção e Exclusão de Dados

Todos os dados locais do usuário podem ser excluídos a qualquer momento via Configurações > Dados > Excluir todos os dados. Excluir todos os dados substitui a base e exclui todo repositório nomeado na Seção 6.1 que contém dados do usuário -- os arquivos criptografados de gravações e anexos, os arquivos sem criptografia listados ali (incluindo os logs e os backups locais na própria pasta de backups do Software), o espaço de trabalho de treino e os snapshots de prefixo --, com as exceções listadas abaixo. A Redefinição inteligente faz o mesmo, restaurando os grupos de dados que o usuário escolhe manter; ao contrário de Excluir todos os dados, ela mantém os backups locais, e mantém os logs e a foto de perfil quando o usuário mantém o grupo a que cada um pertence. Nenhuma redefinição exclui: os arquivos de exportação protegidos por senha (Seção 6.7), que existem para sobreviver a uma redefinição; o arquivo de chave da base, sob o qual a nova base é criptografada; o registro do aceite destes Termos pelo usuário; a licença e as preferências do próprio aplicativo; os arquivos de modelo baixados e os backups de modelos que o Software faz (dos quais mantém os três mais recentes); o repositório da central de suporte em que um operador do Software guarda relatos que outras pessoas lhe enviaram (Seção 6.6(d)); e os arquivos que o usuário salvou em um local de sua própria escolha.

A Empresa não possui cópia desses dados, com a única exceção dos relatos de bug que o usuário submeteu explicitamente sob a Seção 6.6, os quais são retidos conforme a política definida naquela Seção e podem ser excluídos pelo usuário a qualquer momento via Central do Usuário > aba Suporte.

6.5 Menores de Idade

O Software não é destinado a pessoas com menos de 18 (dezoito) anos de idade. Ao aceitar este Termo, o usuário declara ter 18 anos ou mais.

6.6 Relatos de Bug

O relato de bug descrito nesta Seção é iniciado pelo usuário e por relato: nada é transmitido a menos que o usuário abra "Reportar um bug", revise o conteúdo exato e o envie. O Software nunca envia um relato automaticamente, em segundo plano ou em qualquer nível de autonomia.

Quando o usuário opta explicitamente por submeter um relato de bug através da função "Reportar um bug" no aplicativo, uma quantidade limitada de dados diagnósticos estruturados é transmitida aos servidores da RunMyAI com a única finalidade de investigar e corrigir o problema reportado. Este é um de apenas dois tipos de dado que chegam à RunMyAI — o outro sendo a contribuição automática e anônima ao ModelIndex (Seção 6.9). O próprio relato de bug é sempre iniciado pelo usuário, nunca de forma automática e nunca em segundo plano.

(a) O que é transmitido O conteúdo enviado é construído a partir de uma lista fixa de campos técnicos autorizados: um identificador do relato e o horário de criação; a categoria, a severidade e a área de produto selecionadas no formulário do relato; o ambiente de execução (versão do app, identificador de build, sistema operacional e arquitetura, e o idioma da interface do app); a critério do usuário, um digest técnico da execução que falhou — um identificador interno de requisição, o status do desfecho, a estratégia de execução, um resumo do erro, a duração total, o nome do modelo local envolvido, a contagem de rejeições do quality gate, o motivo do fallback de planejamento e, para a etapa que falhou, sua lane, ação, mensagem de erro e motivo de quality gate — e, quando a adaptação local das orientações de planejamento (Seção 2.3) moldou essa execução, um digest dos ajustes em vigor nela: para cada um dos dois componentes ajustáveis (o planejador e o roteador de ferramentas), o número de versão do ajuste, em qual de três grupos fixos de avaliação o turno correu (base, probation ou incumbente), a classe do pedido como dois nomes fixos de categoria (um nível de complexidade e uma lane de execução, ou não classificado), a lista de ajustes tipados (cada um como seu tipo e os nomes de classe de pedido, lane e ferramenta a que se refere, todos do catálogo fixo do Software), um hash das instruções embutidas desse componente e uma impressão digital do modelo local que o executou, derivada do nome e do tamanho do arquivo do modelo (não da pasta em que ele está guardado); se o mesmo pedido foi reexecutado com todos os ajustes desligados; se o Software conseguiu ler seu registro de ajustes ao montar o relato (se não conseguiu, os ajustes, os hashes e a impressão digital ficam ausentes por esse motivo, e não porque nenhum estava em vigor); e um número inteiro que identifica a versão das regras de adaptação — junto com uma contagem de quantas falhas locais recentes compartilham a mesma assinatura técnica de falha (apenas um número, nunca qualquer conteúdo); um resumo abstrato gerado localmente pela IA embarcada no Software descrevendo a natureza do problema; e a lista dos nomes de categoria do que a redação de saída removeu do rascunho (apenas nomes de categoria, nunca o conteúdo removido). Opcionalmente, se o usuário autorizar de forma explícita, o conteúdo pode também incluir uma descrição em texto livre escrita pelo usuário. Todo campo de texto do conteúdo passa pela redação de credenciais de saída antes da pré-visualização, e todo campo que pode conter texto livre — o resumo abstrato gerado pela IA embarcada, a descrição escrita pelo usuário e o texto de erro e de motivo do digest de execução — passa adicionalmente por uma redação de identificadores pessoais que remove endereços de e-mail, caminhos de diretório pessoal, endereços de rede, números de telefone, identificadores numéricos longos como números de cartão de pagamento e números de identificação agrupados como números fiscais ou de cidadão, para todos os países igualmente. Os identificadores gerados e os campos de vocabulário fixo do conteúdo (os identificadores do relatório e da requisição, o status, a trilha e a ação de execução, o ambiente de execução e o digest de ajustes, que contém apenas nomes de catálogo, números inteiros e hashes) passam somente pela redação de credenciais: são as chaves de correlação com que o suporte responde ao relatório, e um identificador gerado ou um vocabulário fechado não tem como conter um identificador pessoal. Antes de qualquer transmissão, o Software exibe o conteúdo completo ao usuário em uma tela de pré-visualização; nenhum dado é enviado até que o usuário clique em Enviar.

(b) O que nunca é transmitido Relatos de bug não incluem e jamais incluirão: conteúdo de mensagens (iMessage, Telegram, email ou qualquer outra comunicação), conteúdo de arquivos do sistema de arquivos do usuário, prompts ou respostas de LLM do uso normal do Software pelo usuário, credenciais, chaves de API, tokens, pressionamentos de teclas, gravações de sessão, capturas de tela ou qualquer anexo binário, ou qualquer forma de histórico de navegação ou localização.

(c) Identidade e autenticidade Um relato de bug é transmitido como uma mensagem assinada criptograficamente, enviada a partir da conta de email do próprio usuário para o endereço de suporte da RunMyAI, pelo provedor de email existente do usuário (o transporte descrito na Seção 6.2(c)). Como o relato trafega pelo email do próprio usuário, o endereço de email remetente é visível para a Empresa, assim como em qualquer email que o usuário envia; um relato de bug, portanto, não é anônimo. O relato é assinado por um par de chaves autogerado (o "Agent Passport" local) que a Empresa não emite e não consegue forjar, o que autentica o remetente sem qualquer servidor central de identidade. Um relato pode incluir o tier do plano de assinatura do usuário, para priorização, mas nunca o nome, telefone, dados de pagamento ou qualquer identificador além do endereço de email remetente e dos campos técnicos autorizados em (a).

(d) Armazenamento Um relato submetido é recebido e mantido apenas dentro da instância própria do Software da RunMyAI, operada pela Empresa em seus próprios sistemas, no repositório local de suporte dedicado dessa instância. Nenhum banco de dados gerenciado de terceiros, object store ou serviço de helpdesk de terceiros armazena o relato; nenhum banco de dados em nuvem separado nem processador terceiro tem acesso a ele. Os relatos são somente texto; o Software não transmite capturas de tela nem anexos binários.

(e) Retenção Um relato submetido é retido apenas pelo tempo necessário para investigar e resolver o problema reportado e para prevenir sua recorrência. O usuário pode solicitar a exclusão de qualquer relato a qualquer momento (ver (f)); diante de tal solicitação, a Empresa remove o registro correspondente de sua instância. A Empresa não reterá relatos para qualquer finalidade, ou por qualquer período, além do que esta Seção permite sem antes atualizar este Termo e obter o consentimento renovado do usuário.

(f) Direitos do usuário A qualquer momento, o usuário pode:

• Visualizar todos os relatos de bug já submetidos do seu dispositivo, junto com o conteúdo exato de cada relato, via Central do Usuário > aba Suporte;
• Excluir qualquer relato individual pela mesma interface, o que remove o registro local e assina e transmite um pedido de exclusão para a instância da Empresa, de modo que o registro correspondente seja removido lá também.

(g) Sem uso secundário Relatos de bug são utilizados exclusivamente para diagnosticar e corrigir defeitos do Software. Não são utilizados para analytics, pesquisa de produto, marketing, treinamento de modelos de machine learning, profiling, publicidade ou qualquer finalidade além de resolver o problema reportado. Não são compartilhados com nem vendidos a qualquer terceiro.

(h) Base legal O processamento desses dados é baseado no consentimento explícito e por-relato do usuário dado no momento da submissão. A recusa de consentimento (não clicar em Enviar, ou cancelar a caixa de diálogo) não tem qualquer consequência sobre a capacidade do usuário de continuar usando o restante do Software.

(i) Referência à arquitetura técnica A especificação técnica completa do programa de relatos de bug — incluindo o pipeline local de dados, a composição da lista de campos autorizados, o papel da IA embarcada na geração do resumo abstrato, o transporte agente-a-agente assinado sobre o email do próprio usuário e os modos de falha das camadas automáticas — é mantida na documentação de arquitetura técnica da Empresa. Essa especificação está sujeita à mesma revisão jurídica independente desta Seção antes de qualquer lançamento comercial.

6.7 Exportação e Importação Protegidas por Senha

O Software oferece um fluxo de Exportação e Importação protegido por senha como único mecanismo sancionado para mover dados entre instalações, ou para manter um backup que sobreviva à perda do arquivo de chave (ver Seção 5.7).

(a) Exportação O usuário inicia a exportação e escolhe uma senha. O Software grava um arquivo único (extensão padrão .runmyai-export) contendo toda a base de dados local recifrada sob uma derivação PBKDF2-HMAC-SHA512 nova (256.000 iterações) dessa senha. O arquivo é independente do arquivo de chave da instalação de origem e pode ser importado em qualquer outra instalação do Software.

(b) Importação A importação é do tipo substituição, não mesclagem: importar substitui a base de dados ativa. Antes da substituição, o Software rotaciona o arquivo atual para uma cópia de segurança pontual mantida por 24 (vinte e quatro) horas, após as quais é excluída automaticamente no início seguinte do Software.

(c) Restrições da senha A senha de exportação deve ter entre 12 (doze) e 256 (duzentos e cinquenta e seis) caracteres. Aspas simples e caracteres de controle ASCII não são permitidos. Senha incorreta no momento da importação produz um resultado explícito de "senha incorreta", distinto de "arquivo corrompido".

(d) Responsabilidade do usuário O usuário é o único responsável por (i) escolher uma senha forte, (ii) armazenar a senha de forma segura fora do Software, e (iii) armazenar o arquivo exportado de forma segura. A Empresa não armazena, retém nem deposita em escrow a senha ou o arquivo, e não consegue recuperar nenhum dos dois caso sejam perdidos. O arquivo de exportação contém os mesmos dados protegidos pela Seção 6.1; o usuário deve tratá-lo com o mesmo cuidado.

(e) Sem transmissão Exportação e Importação são operações exclusivamente locais. O arquivo exportado não passa pelos servidores da Empresa em momento algum.

6.8 Ausência de Monitoramento e de Dever de Monitorar

O Software roda inteiramente na máquina do usuário. Não há conta de usuário, não há login e não há registro do lado do servidor da atividade do usuário (o único dado que chega à Empresa é um relato de desempenho anônimo e automático do ModelIndex (Seção 6.9), que não carrega identidade nem conteúdo, um relato de bug que o usuário escolhe enviar (Seção 6.6) e as conexões de serviço livres de conteúdo descritas na Seção 6.3(a)). Como consequência direta dessa arquitetura local, voltada à privacidade:

• A Empresa não tem capacidade de observar, inspecionar, monitorar, registrar ou auditar o que o usuário faz com o Software, o que se instrui ao agente, ou quais dados o agente processa ou transmite.
• A Empresa não tem meio técnico de detectar um uso proibido (Seção 8.2) antes, durante ou depois de ocorrer, e não possui "kill switch" remoto sobre uma instalação individual.
• A Empresa, portanto, não assume qualquer dever de monitorar, filtrar, revisar ou policiar o uso do Software por qualquer usuário, e a ausência de monitoramento é um recurso deliberado de privacidade, não uma deficiência.

Essa alocação de responsabilidade — controle local e privacidade plenos para o usuário, responsabilidade plena pelo uso recaindo sobre o usuário — é fundamental para estes Termos.

6.9 Contribuição ao ModelIndex (Dados de Desempenho Anônimos)

O ModelIndex é uma feature comunitária: sua instalação contribui com medições de desempenho anônimas, e é esse dado compartilhado que viabiliza as recomendações de modelo casadas com o seu hardware que você recebe em troca. A contribuição é anônima — não carrega nenhum identificador por dispositivo, de modo que nenhum relato pode ser vinculado a outro nem a uma pessoa — e é feita automaticamente, do mesmo jeito para todos, sem distinção regional.

Já existem milhões de modelos de IA locais e quantizações, e a pergunta que todo usuário enfrenta — "qual deles de fato roda bem no meu hardware?" — não tem resposta em benchmarks sintéticos de datacenter. O RunMyAI ModelIndex responde a ela: um índice agregado e comunitário, medido em hardware real de consumidores, que só existe porque toda instalação contribui. A participação é parte de como o Software funciona, não uma exportação por uso — o Software envia um relato de desempenho anônimo e, em troca, todo usuário se beneficia das recomendações resultantes. Ao aceitar este Termo e usar o Software, o usuário concorda com essa contribuição automática e anônima. Quem não concordar não deve instalar, comprar nem usar o Software (Seção 1). O relato é transmitido à Empresa, mas não carrega identidade, não carrega conteúdo e nada que revele o que o usuário fez (subseções (a)–(c)).

(a) O que é transmitido Uma lista fixa de medições técnicas não identificadoras. Para cada modelo medido: o nome do modelo e a quantização, tokens por segundo em duas formas — a taxa sustentada que o modelo mantém ao longo de uma resposta inteira e a taxa mais alta que ele atingiu por um instante —, tempo até o primeiro token, a taxa de aprovação do quality-gate do nucleus, o número de planos de que o modelo participou, quantos desses planos terminaram, a proporção dos terminados que entregou um resultado e — quando o usuário avaliou aquele modelo — a média das próprias avaliações de 1-5 estrelas do usuário (apenas um número, nunca qualquer conteúdo). As contagens sobre planos terminados, tanto de modelos quanto de pares, são números agregados sobre as execuções do próprio Software na máquina do usuário, da mesma natureza da contagem de planos já listada: dizem com que frequência um modelo concluiu seu trabalho, nunca qual era o trabalho. Para cada par de modelos medido: os dois nomes de modelo com sua taxa combinada de aprovação do quality-gate, a proporção das execuções terminadas que entregaram um resultado, taxa de replanejamento, duração média de plano e contagem de planos. Para cada ajuste da adaptação local das orientações de planejamento (Seção 2.3) que alcançou um resultado final ao vivo desde o relato anterior: a qual dos dois componentes ajustáveis ele se aplicou (o planejador ou o roteador de ferramentas); o próprio ajuste tipado, como seu tipo e os nomes de classe de pedido, lane e ferramenta a que se refere, todos do catálogo fixo do Software; o nome e a quantização do modelo local em que correu; um número inteiro que identifica a versão das regras de adaptação; seu resultado como uma de três palavras fixas (promovido, regressão ao vivo ou inconclusivo); e o número de unidades de avaliação sobre as quais foi medido. São valores de catálogo e contagens sobre as execuções do próprio Software, da mesma natureza das contagens de planos listadas acima: dizem como um ajuste se saiu, nunca qual era o pedido, e não carregam texto, identificador de trace nem identificador da instalação. A resposta do serviço a esse mesmo relato pode trazer de volta, para os modelos que o relato nomeou, o agregado da comunidade para cada ajuste — o ajuste, o nome e a quantização do modelo, a versão das regras de adaptação sob a qual os resultados foram produzidos, quantas instalações o promoveram, quantas o retiraram e quantas instalações contribuíram —, que o Software armazena no dispositivo e, apenas para um agregado produzido sob a sua própria versão dessas regras, usa para duas coisas apenas: reduzir a quantidade de evidência local que uma proposta desse ajuste precisa antes de o usuário ser consultado, e exibir essas contagens no cartão de aprovação. Ele não pode propor, aprovar nem aplicar nada por si, e trafega na resposta a uma transmissão que o Software já faz; nenhuma conexão nova é aberta. A especificação de hardware da máquina em que as medições foram feitas, relatada tanto como campos de classe em texto puro quanto como um hash não reversível derivado desses mesmos campos: o nome de modelo do processador tal como seu fabricante o publica (por exemplo "Apple M4 Max" ou "Intel Core Ultra 7 155H"), seu fabricante e sua contagem de núcleos publicada; a faixa de RAM com seu valor nominal em gigabytes; o nome de modelo do acelerador tal como seu fabricante o publica (por exemplo "NVIDIA GeForce RTX 4090"), sua contagem de núcleos publicada quando a plataforma a informa, e o tipo de runtime de inferência; a faixa de memória de vídeo; a família do sistema operacional (por exemplo "macOS"); e um rótulo curto de acelerador composto no próprio dispositivo a partir desses mesmos valores do acelerador, para que o índice público os enuncie de uma única forma (por exemplo "40-core GPU", "NVIDIA GeForce RTX 4090" ou "CPU"). Esse rótulo é derivado de valores já listados aqui e não acrescenta nada que não esteja. São especificações de produto publicadas, de peças fabricadas, cada uma compartilhada por um número muito grande de máquinas: uma contagem de núcleos está impressa na ficha técnica da peça, é idêntica em toda unidade dela, e é o que separa duas peças vendidas sob um mesmo nome (um "Apple M4 Max" é vendido com peça gráfica de 32 e de 40 núcleos, e informar só o nome não diz qual delas executou). O relato nunca carrega um valor particular da máquina do usuário: nem a quantidade de RAM medida, nem a quantidade de memória de vídeo medida, nem a versão do sistema operacional, e nenhum número de série, endereço de rede ou outro identificador de dispositivo. O tier do plano de assinatura. E dados de escrituração do relato: a versão do app, o timestamp de criação do relato e a versão de schema do payload. Uma contribuição pode levar uma ficha anônima de uso único (anon_token). A ficha é emitida para a sua licença num ciclo anterior de contribuição por meio de uma assinatura cega (RFC 9474): o site que a emite não consegue reconhecê-la quando ela é usada, de modo que ela prova apenas que o relato vem de uma instalação licenciada, nunca de qual. O site guarda um hash de mão única de cada ficha usada, para recusar reuso, e um hash com chave do identificador de conta contido na sua licença com um contador, para limitar quantas fichas são emitidas. O relato não contém nenhuma chave por instalação nem qualquer outro identificador por dispositivo.

(b) O que nunca é transmitido Um relato do ModelIndex não inclui e jamais incluirá: nome, email, telefone, dados de pagamento ou endereço IP do usuário; conteúdo de conversas, mensagens ou emails; prompts ou saídas de modelo; conteúdo de arquivos ou caminhos de arquivos; credenciais, chaves de API ou tokens de acesso (a única ficha que um relato pode levar é a ficha anônima descrita em (a)). Tampouco inclui qualquer valor medido particular da máquina do usuário, em oposição à especificação publicada das peças de que ela é feita: a quantidade de RAM medida, a quantidade de memória de vídeo medida, a versão do sistema operacional, um número de série, um endereço de rede ou qualquer outro identificador de dispositivo. Ele carrega apenas os elementos autorizados em (a) e nada mais.

(c) Anônimo, e em infraestrutura de terceiros Um relato não carrega identificador do usuário: sem nome, email, conta, id de licença ou endereço IP, e sem conteúdo. Como o relato não contém nenhuma chave por instalação nem qualquer outro identificador por dispositivo (subseção (a)), nenhuma contribuição pode ser associada a um dispositivo ou a uma pessoa individual; os relatos são mesclados em um índice agregado entre todas as instalações. Tampouco dois relatos podem ser atribuídos a uma mesma máquina. O único valor que dois relatos de uma mesma máquina têm em comum é a especificação de hardware descrita na subseção (a) e o hash dela derivado — e toda máquina construída com as mesmas peças publicadas produz essa mesma especificação e esse mesmo hash, de modo que dois relatos coincidentes são indistinguíveis de duas máquinas diferentes do mesmo modelo. O que a especificação identifica é um produto; quantas máquinas respondem a ela não é algo que um relato revele, e a Empresa não dispõe de meio para estreitar esse número. O mesmo vale para os resultados de ajuste descritos na subseção (a): um ajuste é uma combinação de valores de catálogo que toda instalação que roda aquele modelo pode emitir igualmente, e seu resultado e sua contagem de unidades mudam a cada nova avaliação, de modo que nenhum dos dois pode servir de identificador estável nem ligar dois relatos. Os relatos são enviados a um serviço de agregação em nuvem operado pela Empresa sobre infraestrutura de terceiros (por exemplo, provedores gerenciados de hospedagem e banco de dados), onde o relato anônimo é processado para calcular o índice público. O endereço IP do usuário é visível ao serviço receptor no nível de rede, como em qualquer requisição à internet, e não é armazenado como parte do relato.

(d) Finalidade e ausência de uso secundário Os dados contribuídos são usados exclusivamente para calcular e publicar o ModelIndex agregado (rankings por modelo, faixa de hardware, quantização e par de modelos) e para alimentar recomendações dentro do produto. Não são vendidos, não são usados para publicidade ou profiling, nem para treinar modelos de machine learning, e nunca são vinculados a um usuário individual.

(e) Base legal O relato é projetado para ser anônimo: não carrega nenhum identificador por dispositivo, de modo que uma contribuição individual não pode ser isolada e o dado não é dado pessoal sob o GDPR, o UK GDPR ou a LGPD. A especificação de hardware da subseção (a) não altera isso. Ela nomeia produtos fabricados, não a máquina do usuário — cada um desses nomes de produto é compartilhado por um número muito grande de máquinas no mundo, e o relato deliberadamente não carrega nenhum valor medido que reduziria esse conjunto a uma. Nessa base, a contribuição é automática para todos, sem distinção regional. Na medida em que qualquer lei aplicável ainda assim trate um elemento transmitido como dado pessoal, a Empresa apoia-se em seu legítimo interesse (GDPR Artigo 6(1)(f) e equivalentes) em manter o ModelIndex comunitário, em conjunto com o aceite deste Termo pelo usuário; os interesses do usuário ficam protegidos porque o dado é anônimo, agregado, em lista autorizada e nunca usado para publicidade, profiling ou treino de modelos (subseção (d)). Quando a lei aplicável assegurar direitos sobre qualquer elemento transmitido, a Empresa os honrará.

(f) Alterações A Empresa não expandirá o que um relato do ModelIndex contém além da lista autorizada em (a) sem atualizar este Termo.

(g) Leitura do ranking comunitário Para mostrar ao usuário como os modelos se classificam em hardware como o seu, o Software também lê de volta o ranking publicado a partir do serviço de agregação da Empresa. A requisição é a mesma para toda instalação: ela não carrega parâmetro de caminho, consulta, corpo, cookie, licença nem cabeçalho próprio, e portanto não envia classe de hardware nem hash, nenhuma lista de modelos, nenhuma medição, nenhuma identidade e nenhum conteúdo. A resposta é o ranking público de toda classe de hardware que o índice publica (nomes de modelos, quantizações, pontuações e posições comunitárias, e os nomes de arquivo de modelo que o índice agrupou sob cada modelo). O Software seleciona no dispositivo o ranking da sua própria classe de hardware, armazena apenas esse ranking e o compara localmente com os modelos do próprio usuário, de modo que nem a classe de hardware da máquina nem quais modelos o usuário possui são enviados. O Software faz essa requisição quando o ranking armazenado está ausente, tem mais de 24 horas ou pertence a outra classe de hardware, e quando o usuário pede uma atualização. Assim como em um relato, o endereço IP do usuário é visível ao serviço receptor no nível de rede e não é armazenado com a requisição.

---

7. Limitação de Responsabilidade

7.1 Exclusão de Garantias

NA MÁXIMA EXTENSÃO PERMITIDA PELA LEI APLICÁVEL, O SOFTWARE É FORNECIDO "NO ESTADO EM QUE SE ENCONTRA" ("AS IS"), SEM GARANTIAS DE QUALQUER NATUREZA, EXPRESSAS OU IMPLÍCITAS, INCLUINDO, MAS NÃO LIMITADO A, GARANTIAS DE COMERCIALIZAÇÃO, ADEQUAÇÃO A UM PROPÓSITO ESPECÍFICO, NÃO VIOLAÇÃO DE DIREITOS DE TERCEIROS, DISPONIBILIDADE CONTÍNUA OU AUSÊNCIA DE ERROS.

7.2 Exclusão de Responsabilidade

NA MÁXIMA EXTENSÃO PERMITIDA PELA LEI APLICÁVEL, A RUNMYAI NÃO SE RESPONSABILIZA POR:

• Danos diretos, indiretos, incidentais, especiais, punitivos ou consequenciais
• Perda de dados, lucros, receita, boa vontade ou oportunidade de negócio
• Interrupção de negócios ou atividades
• Ações executadas pelo agente que causem danos a terceiros
• Violações de Termos de Uso de plataformas de terceiros resultantes do uso do agente
• Exposição do endereço IP ou identidade digital do usuário resultante da execução de buscas e navegação pelo agente a partir da máquina do usuário
• Decisões tomadas pelo usuário com base em outputs do agente sem verificação independente
• Danos causados por prompt injection ou manipulação do agente por conteúdo de terceiros
• Gravação, captura, transcrição, análise por IA ou importação de conversas realizada pelo usuário sem o consentimento dos participantes ou o aviso exigidos pela lei aplicável, inclusive quando o usuário tiver desligado o indicador de gravação no dispositivo (Seção 5.9)

ESTAS LIMITAÇÕES SE APLICAM MESMO QUE A RUNMYAI TENHA SIDO INFORMADA DA POSSIBILIDADE DE TAIS DANOS E INDEPENDENTEMENTE DA TEORIA LEGAL APLICÁVEL (CONTRATO, DELITO, ETC.).

7.3 Teto de Responsabilidade

A responsabilidade total e acumulada da Empresa, em qualquer hipótese, fica limitada ao maior valor entre (a) o montante pago pelo usuário pelo Software nos 12 (doze) meses anteriores ao evento que deu origem à reclamação, e (b) USD 100,00 (cem dólares americanos).

7.4 Exceções Legais

Algumas jurisdições não permitem a exclusão ou limitação de certas garantias ou responsabilidades, incluindo responsabilidade por dolo ou culpa grave, ou direitos irrenunciáveis de consumidor. Nessas jurisdições, as exclusões e limitações acima se aplicam na máxima extensão permitida por lei. Nenhuma disposição deste Termo exclui ou limita direitos que não possam ser excluídos por lei mandatória aplicável.

7.5 Indenização pelo Usuário

Na máxima extensão permitida pela lei aplicável, o usuário concorda em indenizar, defender e isentar a Empresa e seus fundadores, diretores, administradores, empregados, prestadores e agentes de toda e qualquer reclamação, demanda, ação, processo, responsabilidade, dano, perda, multa, custo e despesa de terceiros (incluindo honorários advocatícios razoáveis) decorrentes de ou relacionados a: (a) o uso ou acesso ao Software pelo usuário; (b) qualquer ação executada pelo agente que o usuário autorizou, seja explicitamente ou por meio de sua configuração de autonomia, inclusive ações que afetem terceiros ou sistemas externos; (c) a violação destes Termos ou de qualquer lei ou regulamento aplicável pelo usuário; (d) a violação ou apropriação indevida, pelo usuário, de direitos de terceiros, incluindo direitos de propriedade intelectual, privacidade, imagem ou proteção de dados; (e) qualquer conteúdo, dado ou instrução que o usuário forneceu ou processou por meio do Software; e (f) qualquer gravação, captura, transcrição, análise por IA ou importação de conversa realizada pelo usuário, incluindo reclamações de participantes gravados ou de autoridades decorrentes da falha do usuário em obter qualquer consentimento ou fornecer qualquer aviso exigido pela lei aplicável (Seção 5.9).

Esta indenização não se aplica na medida em que a reclamação decorra de dolo, culpa grave ou conduta intencional da própria Empresa, nem a qualquer responsabilidade que a lei mandatória aplicável não permita atribuir ao usuário (incluindo proteções irrenunciáveis de consumidor). A Empresa dará ao usuário aviso razoável de qualquer reclamação sujeita a esta Seção e poderá, a seu critério, participar da defesa com advogados próprios.

7.6 Prazo para Reclamações

Na máxima extensão permitida pela lei aplicável, qualquer reclamação ou pretensão decorrente de ou relacionada ao Software ou a estes Termos deve ser iniciada no prazo de 1 (um) ano a contar da data em que a reclamação ou pretensão surgiu; caso contrário, fica permanentemente prescrita. Quando a lei aplicável não permitir esse prazo reduzido, aplica-se o menor prazo prescricional que essa lei permitir.

---

8. Conformidade com Legislação Aplicável

8.1 Responsabilidade do Usuário

O usuário é exclusivamente responsável por garantir que seu uso do Software esteja em conformidade com toda legislação aplicável em sua jurisdição, incluindo mas não limitado a:

• Leis de proteção de dados pessoais (ex.: GDPR — União Europeia, LGPD — Brasil, CCPA/CPRA — Califórnia/EUA, PIPL — China)
• Leis de acesso a sistemas computacionais e crimes cibernéticos (ex.: CFAA — EUA, Convenção de Budapeste, Lei 12.737/2012 — Brasil)
• Leis de propriedade intelectual e direitos autorais, incluindo proteções sobre conteúdo scrapeado da web
• Regulamentações setoriais aplicáveis às atividades do usuário (serviços financeiros, saúde, jurídico, governamental, etc.)
• Termos de Uso de plataformas e serviços de terceiros com os quais o agente interaja

Plataformas de mensageria. O Software pode conectar-se a Telegram, iMessage, WhatsApp e Signal para que o usuário controle seu próprio agente. Essas conexões operam sob as contas do próprio usuário (um token de bot do Telegram que o usuário cria, o Apple ID do usuário para iMessage, uma sessão de dispositivo vinculado para WhatsApp, e assim por diante). Várias dessas plataformas restringem ou proíbem acesso automatizado, clientes não oficiais ou uso mediado por bots em seus próprios termos. O usuário é o único responsável por confirmar que conectar e usar cada canal é permitido pelos termos vigentes daquela plataforma, e assume o risco de qualquer restrição ou encerramento de conta que a plataforma venha a impor.

8.2 Uso Proibido

O uso do Software para as seguintes finalidades é expressamente proibido e constitui causa de encerramento imediato do acesso, sem prejuízo das responsabilidades civis e criminais aplicáveis:

• Coleta, processamento ou uso de dados pessoais de terceiros sem base legal adequada
• Gravação, captura, transcrição ou importação de uma conversa sem o consentimento ou o aviso aos participantes exigidos pela lei aplicável (ver Seção 5.9)
• Acesso não autorizado a sistemas computacionais de terceiros
• Scraping de conteúdo em violação a Termos de Uso ou legislação aplicável
• Geração de conteúdo ilegal, difamatório, enganoso, ou que viole direitos de terceiros
• Qualquer atividade que cause dano a terceiros ou que constitua crime em qualquer jurisdição relevante
• Comércio, facilitação ou intermediação de bens ou serviços ilegais (incluindo substâncias controladas, armas, dados ou credenciais roubados, ou produtos falsificados)
• Fraude, golpes, phishing, engenharia social ou personificação de qualquer pessoa ou entidade
• Geração ou distribuição de material de abuso sexual infantil, ou qualquer conteúdo que sexualize menores
• Assédio, perseguição (stalking), doxxing, ameaças ou intimidação coordenada de qualquer pessoa
• Envio de mensagens em massa não solicitadas ou automatizadas (spam) por qualquer canal, ou operação de contas de mensageria, email ou plataforma de forma que viole os termos da plataforma
• Manipulação de mercado, lavagem de dinheiro ou evasão de tributos, sanções ou controles de exportação
• Geração ou amplificação de desinformação, ou operação de identidades automatizadas ("bots") não divulgadas onde a divulgação for exigida
• Uso da operação local e anônima do Software para ocultar, organizar ou executar qualquer das condutas acima, ou para evadir processo legal

O usuário reconhece que, por o Software rodar localmente, sem conta e sem visibilidade do lado do servidor sobre a atividade do usuário (Seção 6.8), a Empresa não tem meio técnico de detectar ou impedir um uso proibido de antemão. Esta lista define o limite contratual do uso permitido; ela não é, e não pode ser, um controle monitorado ou aplicado. A responsabilidade por permanecer dentro dela recai inteiramente sobre o usuário.

8.3 EU AI Act

Para usuários na União Europeia: o Software se enquadra como sistema de IA de propósito geral, e o agente interage diretamente com pessoas naturais e produz conteúdo gerado por IA. As obrigações de transparência previstas no Artigo 50 do EU AI Act entram em plena vigência em 2 de agosto de 2026.

O Software atende ao dever de transparência do Artigo 50 para as comunicações que controla marcando como geradas por IA as mensagens autônomas do agente a terceiros, conforme descrito na Seção 4.5. A Empresa se compromete a manter este Termo e o comportamento de divulgação do Software atualizados em conformidade com o cronograma de implementação do EU AI Act. Quando o usuário direciona o agente a atuar por uma superfície que o Software não consegue marcar, a obrigação de divulgação daquela interação recai sobre o usuário (Seção 4.5).

---

9. Jurisdição e Resolução de Disputas

9.1 Resolução Informal Prévia

Antes de iniciar a arbitragem, a parte deve primeiro tentar resolver a disputa de forma informal, enviando notificação escrita da disputa à outra parte (a Empresa, em legal@runmyai.app). As partes negociarão de boa-fé por 30 (trinta) dias a contar dessa notificação. Somente se a disputa não for resolvida nesse prazo ela poderá seguir para arbitragem.

9.2 Arbitragem Internacional Vinculante

Qualquer disputa, controvérsia ou pretensão decorrente de ou relacionada a estes Termos ou ao Software — inclusive sua existência, validade, violação ou rescisão — que não seja resolvida sob a Seção 9.1 será definitivamente resolvida por arbitragem individual e vinculante, segundo o Regulamento de Arbitragem da Câmara de Comércio Internacional (ICC). A sede da arbitragem é Genebra, Suíça; o idioma é o inglês; e o tribunal será composto por um árbitro único, salvo determinação diversa da ICC. A sentença é final e vinculante, e poderá ser homologada em qualquer foro competente (aplica-se a Convenção de Nova York). Nada nesta Seção impede qualquer das partes de buscar medidas cautelares ou liminares perante foro competente quando necessário para preservar direitos até a arbitragem.

9.3 Renúncia a Ações Coletivas

Na máxima extensão permitida pela lei aplicável, todas as disputas são conduzidas em base exclusivamente individual, e o usuário renuncia a qualquer direito de participar de ação coletiva, class action, litisconsórcio ou ação representativa contra a Empresa. Esta renúncia se aplica na máxima extensão que a lei permitir; quando a lei mandatória (por exemplo, no Brasil ou em países da União Europeia) não a permitir, esta Seção não priva o usuário de qualquer direito irrenunciável à tutela coletiva assegurado por essa lei, e o restante desta Seção 9 permanece aplicável.

9.4 Lei Aplicável

Estes Termos, e qualquer disputa deles ou do Software decorrente, são regidos pelo direito material da Suíça, sem considerar suas regras de conflito de leis e excluindo a Convenção das Nações Unidas sobre Contratos de Compra e Venda Internacional de Mercadorias. Direitos mandatórios assegurados a um consumidor pela lei de seu país de residência habitual — incluindo proteções irrenunciáveis previstas no Código de Defesa do Consumidor (Brasil), na Diretiva 2019/770 (UE) ou em legislação equivalente — não são afetados por esta cláusula e prevalecem na medida aplicável; esta escolha de lei não priva o consumidor da proteção conferida por disposições que não possam ser derrogadas por acordo sob a lei de seu país de residência habitual.

---

10. Vigência, Encerramento e Disposições Gerais

10.1 Vigência

Este Termo vigora a partir do momento do aceite pelo usuário e permanece em vigor até que o usuário desinstale o Software ou até que a Empresa encerre o produto, o que ocorrer primeiro.

10.2 Encerramento pelo Usuário

O usuário pode encerrar este Termo a qualquer momento desinstalando o Software. Não há reembolso automático por interrupção de uso (ver política de reembolso separada). A desinstalação remove todos os dados locais; a Empresa não possui cópia desses dados.

10.3 Encerramento pela Empresa

Por o Software ser operado localmente, sem conta de usuário e sem serviço do lado do servidor que a Empresa possa revogar (Seção 6.8), a Empresa não tem meio remoto de desativar uma instalação individual. Em caso de violação deste Termo, a Empresa pode retirar o direito do usuário de usar o Software e pode recusar-se a fornecer atualizações, suporte ou licenças futuras; o usuário fica então contratualmente obrigado a cessar o uso e desinstalar. Nada nesta Seção limita os recursos disponíveis à Empresa ou a terceiros afetados, sob a legislação aplicável, por uma violação ou um uso ilegal.

10.4 Atualizações do Termo

A Empresa pode atualizar este Termo periodicamente. Atualizações materiais serão comunicadas ao usuário por:

• Notificação in-app no momento de abertura do Software
• Email para o endereço cadastrado (quando aplicável)

Atualizações materiais requerem novo aceite explícito do usuário antes que o Software possa ser utilizado. O usuário que não concordar com as atualizações deve desinstalar o Software.

Nota de boas práticas: A Empresa manterá um histórico público de versões deste Termo, com data de vigência de cada versão, acessível em: runmyai.app/legal/terms

10.5 Independência das Cláusulas

Se qualquer disposição destes Termos for considerada inválida, ilegal ou inexequível por tribunal ou autoridade competente, tal disposição será limitada ou desconsiderada na mínima extensão necessária, e as demais disposições permanecerão em pleno vigor e efeito.

10.6 Sobrevivência

Qualquer disposição que, por sua natureza, deva sobreviver ao encerramento ou ao término destes Termos sobrevive, incluindo (sem limitação) a regra de atribuição da Seção 3 e as Seções 4, 5, 6, 7 (isenções, limitação de responsabilidade, indenização e prazo), 8, 9 e esta Seção 10, incluindo a Seção 10.14 (propriedade intelectual).

10.7 Integralidade do Acordo; Ausência de Confiança em Outras Declarações

Estes Termos, em conjunto com qualquer política de reembolso separada e qualquer política aqui expressamente referenciada, constituem o acordo integral entre o usuário e a Empresa quanto ao Software e substituem todos os acordos, entendimentos, comunicações, materiais de marketing e declarações anteriores ou contemporâneos sobre o tema. O usuário reconhece que não se baseou em qualquer afirmação, promessa ou declaração que não esteja expressamente prevista nestes Termos.

10.8 Força Maior

A Empresa não se responsabiliza por qualquer falha ou atraso de desempenho decorrente de causas além de seu controle razoável, incluindo caso fortuito, desastres naturais, guerra, terrorismo, comoção civil, epidemia, conflitos trabalhistas, atos governamentais, sanções, ou falhas e descontinuações de rede, energia ou de serviços de terceiros dos quais o Software depende (Seção 5.5).

10.9 Não Renúncia

A falha ou demora da Empresa em exigir o cumprimento de qualquer disposição destes Termos não constitui renúncia ao seu direito de exigi-la posteriormente. Qualquer renúncia só é eficaz se feita por escrito por representante autorizado da Empresa.

10.10 Cessão

A Empresa pode ceder ou transferir estes Termos, no todo ou em parte, inclusive em conexão com fusão, aquisição, financiamento, reorganização ou venda de ativos, sem o consentimento do usuário. O usuário não pode ceder ou transferir estes Termos nem quaisquer direitos ou obrigações deles decorrentes sem o consentimento prévio e por escrito da Empresa; qualquer tentativa de cessão em violação a esta Seção é nula. Estes Termos vinculam e beneficiam as partes e seus sucessores e cessionários permitidos.

10.11 Ausência de Mandato ou Sociedade

Nada nestes Termos cria qualquer relação de mandato, sociedade, joint venture, franquia, emprego ou relação fiduciária entre o usuário e a Empresa. O usuário não tem autoridade para vincular a Empresa de qualquer forma.

10.12 Capacidade e Poderes

Ao aceitar estes Termos, o usuário declara e garante que tem capacidade legal para fazê-lo e, quando aceitar em nome de uma organização, que está devidamente autorizado a vinculá-la, ficando ela igualmente vinculada como "usuário".

10.13 Idioma Prevalente

Estes Termos são redigidos em inglês (a versão master prevalente) e podem ser disponibilizados em outros idiomas por conveniência. Em caso de conflito ou divergência, a versão em inglês prevalece na máxima extensão permitida pela lei aplicável; quando a lei local mandatória exigir que a versão no idioma local prevaleça para um consumidor, essa exigência prevalece para aquele consumidor.

10.14 Propriedade Intelectual

(a) Titularidade do Software. O Software, incluindo seu código-fonte e código-objeto, seu design, sua documentação e o conteúdo que a Empresa distribui com ele, pertence à Empresa e é protegido por direitos de autor e outras leis de propriedade intelectual. O Software é licenciado, não vendido. Todos os direitos não concedidos expressamente nestes Termos são reservados à Empresa.

(b) Licença ao usuário. Sujeito a estes Termos e a uma licença válida quando exigida, a Empresa concede ao usuário uma licença pessoal, não exclusiva, intransmissível, não sublicenciável e revogável para instalar e usar o Software em dispositivos que o usuário possua ou controle, dentro do número de dispositivos que a licença do usuário permite, para fins pessoais ou internos do usuário. Salvo na medida em que a lei aplicável o permita expressamente apesar desta restrição, o usuário não pode: copiar o Software exceto para instalação e cópia de segurança; vendê-lo, alugá-lo, emprestá-lo, sublicenciá-lo ou redistribuí-lo; modificá-lo ou criar obras derivadas dele; descompilá-lo, desmontá-lo ou tentar de outro modo obter seu código-fonte; nem remover ou alterar avisos de direitos de autor, de marca ou de atribuição nele contidos. Nada nestes Termos limita um direito que não possa ser excluído por contrato, incluindo o direito de descompilar o Software na medida indispensável para obter as informações necessárias à interoperabilidade de um programa criado de forma independente, nas condições que a lei aplicável estabelece.

(c) Componentes de terceiros. O Software inclui componentes de terceiros distribuídos sob suas próprias licenças, algumas delas licenças de código aberto como a GNU General Public License. Esses componentes estão listados, com suas licenças, nos avisos de terceiros que o Software distribui e exibe em sua janela Sobre. Cada componente é regido por sua própria licença, e nada nestes Termos restringe um direito que essa licença concede ao usuário, incluindo qualquer direito ao código-fonte do componente.

(d) Marcas. "RunMyAI", o logotipo RunMyAI e os nomes dos produtos do Software são marcas da Empresa. Estes Termos não concedem direito de usá-los, exceto para referir-se ao Software de forma verdadeira. Nomes de produtos, serviços, modelos e empresas de terceiros que aparecem no Software pertencem a seus respectivos titulares e são usados apenas para identificá-los; sua presença não implica afiliação nem endosso.

(e) Conteúdo do usuário. O usuário mantém todos os direitos que detém sobre o conteúdo que fornece ao Software, incluindo prompts, arquivos, documentos, mensagens e outros materiais ("Entrada"). A Empresa não adquire direito algum sobre a Entrada. O Software processa a Entrada no dispositivo do usuário conforme descrito na Seção 6, e a Empresa não a recebe, exceto quando a Seção 6 indica que o usuário escolhe enviar algo à Empresa.

(f) Saídas. Entre o usuário e a Empresa, o usuário é titular do texto, imagens, áudio, vídeo, código e demais conteúdos que o Software gera para o usuário ("Saída"), e a Empresa cede ao usuário qualquer direito que possa ter sobre a Saída. A Empresa não reivindica titularidade da Saída e não a utiliza. O usuário reconhece que: (i) a Saída gerada por um modelo pode não ser protegida por direitos de autor ou outros direitos de propriedade intelectual, em especial quando lhe falta contribuição criativa humana suficiente, e a Empresa não garante que qualquer Saída seja protegível; (ii) a Saída pode ser semelhante ou idêntica a conteúdo gerado para outras pessoas, e a Empresa não garante que a Saída seja original ou exclusiva; (iii) a Saída pode reproduzir ou assemelhar-se a material protegido por direitos de terceiros, e a Empresa não garante que a Saída esteja livre desses direitos; e (iv) os modelos que o Software executa são distribuídos sob suas próprias licenças, e algumas delas impõem condições ao uso de sua saída, cuja observância cabe ao usuário. O usuário é o único responsável por revisar a Saída e por qualquer uso que dela faça, nos termos das Seções 4.3 e 8.1.

(g) Sugestões. Se o usuário enviar à Empresa sugestões ou outro retorno sobre o Software, a Empresa pode usá-los sem obrigação para com o usuário. O retorno nunca inclui a Entrada ou a Saída do usuário, salvo se o usuário optar por incluí-las.

---

11. Aceite e Mecanismo de Consentimento

11.1 Mecanismo de Aceite no App (Especificação para o Time de Produto)

O aceite deve ser obtido em 3 etapas sequenciais no primeiro uso do Software:

Etapa 1 — Resumo de Riscos (linguagem simples)

Exibir uma tela com os 6 riscos críticos em bullets curtos:

1. As buscas na internet são feitas a partir da sua máquina, com seu IP real.
2. O agente pode agir autonomamente nos Níveis 3 e 4. Você configura o nível por produto e por superfície; você assume integralmente a responsabilidade pelo que executa.
3. Outputs de IA podem estar errados — sempre verifique antes de agir.
4. Páginas web, emails e documentos podem conter texto oculto escrito para dar ao agente instruções próprias (prompt injection). O Software tria esse conteúdo na sua máquina antes de o agente lê-lo e, a menos que você desligue essa proteção, pede sua aprovação antes de qualquer ação com efeito externo depois de lê-lo; nenhuma defesa contra isso é completa.
5. Seus dados locais são criptografados com uma chave guardada em um arquivo de chave no seu computador. Se você perder esse arquivo (reinstalação do SO, perda da conta, formatação) sem antes ter criado uma Exportação protegida por senha, os dados serão permanentemente irrecuperáveis.
6. O RunMyAI contribui com medições de desempenho anônimas (apenas modelo e hardware — nunca seu conteúdo ou identidade) ao ModelIndex comunitário (Seção 6.9); isto é automático para todos, e o relato não carrega nenhum identificador por dispositivo.

Botão: "Entendi os riscos — ver Termo completo"

Etapa 2 — Termo Completo com Checkboxes

• Scroll obrigatório até o fim do documento
• Checkbox 1: "Li e compreendo integralmente os Termos de Uso e Aceite de Riscos"
• Checkbox 2 (separado e obrigatório): "Entendo que buscas e navegação web realizadas pelo agente ocorrem a partir da minha máquina, usando meu endereço IP real, e que esse tráfego é atribuível a mim perante terceiros"
• Checkbox 3 (separado): "Confirmo ter 18 anos ou mais"
• Botão habilitado apenas após scroll completo e todos os checkboxes marcados

Etapa 3 — Configuração Inicial de Autonomia

Antes de qualquer execução de agente, o Software apresenta os cinco níveis de autonomia (Seção 4.1) com descrições em linguagem simples e confirma que todos os produtos e todas as superfícies estão em Nível 0 (Manual) por padrão. O Software não recomenda um nível específico a novos usuários. O usuário pode manter os padrões ou elevar produtos/superfícies individuais conscientemente.

11.2 Disponibilidade de Funcionalidades em Níveis Elevados de Autonomia

Todas as funcionalidades do Software ficam disponíveis ao usuário imediatamente após o aceite geral (Seção 11.1). O Software não restringe funcionalidades específicas (por exemplo, envio autônomo de email, transações financeiras autônomas, criação autônoma de contas em serviços de terceiros) atrás de etapas de aceite adicionais.

Dois reconhecimentos no ponto de uso são a exceção, porque cada um abre um escopo específico de dados pessoais de terceiros: o reconhecimento de dados de terceiros do iMessage (Seção 5.6) e o reconhecimento de gravação (Seção 5.9). Cada um é exibido uma única vez, no momento em que o usuário aciona aquele escopo pela primeira vez, e registra o reconhecimento, pelo usuário, da responsabilidade descrita na Seção correspondente.

Quando o usuário eleva o nível de autonomia de um produto ou superfície para Nível 3 ou Nível 4 pela primeira vez, o Software pode exibir uma única vez um resumo em linguagem simples do que aquele nível passará a executar autonomamente (por exemplo: "No Nível 4 em MyMail, emails serão enviados sem perguntar"). Esta divulgação é informativa apenas; não requer um segundo aceite e não bloqueia a mudança de configuração. O aceite geral do usuário sob a Seção 11.1, combinado com a configuração consciente de autonomia por produto e por superfície, cobre todo o uso das funcionalidades.