1. Escopo e incorporação
1.1. Estes Termos complementam os Termos de Serviço para módulos e serviços identificados no Pedido celebrado entre a AIVYRO LTDA., CNPJ 62.210.164/0001-09, e o Cliente.
1.2. Cada capacidade contratada deverá possuir descrição suficiente de função, usuários, ações, dados, limites, dependências, suporte e condições particulares.
1.3. Habilitação técnica, código, protótipo, sinalizador técnico, demonstração ou planejamento futuro não comprova que a capacidade esteja contratada, disponível ou aprovada para determinado território e setor.
1.4. O Pedido prevalece quanto ao escopo comercial; o DPA quanto ao tratamento por instrução; e anexos específicos quanto a dados sensíveis, IA, comunicações e território, preservadas normas obrigatórias.
1.5. A descrição de capacidade deverá ser interpretada de forma funcional e sistemática, considerando entradas, saídas, limites, pré-requisitos, dependências, responsabilidades e remédios, e não como garantia autônoma de resultado empresarial. Nenhuma denominação comercial ampliará o Serviço além da especificação incorporada ou reduzirá obrigação expressamente assumida.
2. Ficha de capacidade
2.1. A ficha de cada módulo deverá identificar nome, estado real, finalidade, entrada, saída, ação, consequência, usuários autorizados, dependências e limitações materiais.
2.2. A ficha deverá indicar categorias de dados, titulares, permissões, fornecedores, países, IA, retenção, exportação, segurança, suporte, nível de serviço e unidade de cobrança quando pertinentes.
2.3. Alegação pública somente será mantida enquanto houver responsável, evidência e teste atuais; divergência material devolverá a capacidade à revisão e exigirá correção da oferta.
2.4. Ausência de ficha aprovada mantém a capacidade fora do escopo contratual, ainda que componente ou configuração exista no repositório.
2.5. A ficha de capacidade integrará o Contrato somente quando identificada no Pedido ou por referência inequívoca, com versão e data recuperáveis. Material de demonstração, screenshot, protótipo, ambiente interno ou resposta comercial não substitui especificação, mas poderá produzir os efeitos que a Lei Aplicável atribua à oferta suficientemente precisa.
3. CRM e dados comerciais
3.1. Importação, cadastro, alteração, enriquecimento, deduplicação, relacionamento, exportação e exclusão de registros observarão permissões, instruções e funções contratadas.
3.2. O Cliente deverá avaliar origem, finalidade, qualidade, categorias e autoridade sobre os dados; a Aivyro continuará responsável pelos tratamentos e controles que determinar.
3.3. Registro corporativo ou fonte pública pode conter dado pessoal, confidencial ou desatualizado e não será tratado como livre de restrição.
3.4. Dado inferido, divergente ou sem evidência deverá ser apresentado conforme sua natureza, sem conversão silenciosa em fato certificado.
3.5. Importação, deduplicação, enriquecimento, associação, normalização e mesclagem deverão preservar origem, confiança e rastreabilidade no alcance necessário ao uso. Regra automática que sobrescreva dado autoritativo deverá ser documentada, controlável e sujeita a correção compatível com o risco.
4. Alterações em registros
4.1. Operação que crie, edite, mescle, mova ou exclua dado deverá respeitar permissões e informar alcance e consequência relevantes antes da confirmação quando o risco exigir.
4.2. Automação não deverá sobrescrever valor atual com base em estado antigo sem controle de conflito compatível com o comportamento contratado.
4.3. Histórico, reversão e auditoria serão descritos por capacidade e não são prometidos universalmente por estes Termos.
4.4. Erro próprio confirmado será tratado com correção, restauração possível, comunicação e medida proporcional, sem prometer reversibilidade de efeito já consumado por terceiro.
4.5. Ações de escrita, exclusão, fusão, alteração em massa e propagação externa deverão respeitar autorização, escopo, idempotência, validação e trilha disponíveis para a capacidade. Prévia ou confirmação humana somente será prometida quando efetivamente integrar o fluxo contratado.
5. Comunicações e canais
5.1. E-mail, mensagem, voz, atendimento e outros canais dependem de conta, número, template, permissão, território, regra e limite do provedor aplicável.
5.2. A ficha indicará origem, destino, estados de envio, custos, supressão e comportamento de falha; aceite do provedor não será apresentado como entrega, leitura ou consentimento.
5.3. Retry, fila e retomada não autorizam duplicação de mensagem ou cobrança incompatível com o Pedido.
5.4. Opt-out, oposição, bloqueio e restrição territorial deverão alcançar ações manuais e automáticas no escopo aplicável sem revelar preferência de uma organização a outra.
5.5. Cada canal estará condicionado a credencial, identidade, remetente, template, origem de contato, janela, limite e regras do fornecedor e território. Disponibilidade na interface não garante aprovação do canal, entrega, leitura, resposta ou continuidade de política de terceiro.
6. Reuniões e calendário
6.1. Agendamento, convite, participação, captura, gravação, transcrição, identificação de falante, resumo e avaliação são operações distintas.
6.2. A ficha deverá informar o que está habilitado, quais contas e calendários são usados, dados tratados, permissões, fornecedores, armazenamento e retenção.
6.3. Conectar agenda ou reunião não autoriza automaticamente gravação, análise, compartilhamento ou uso secundário do conteúdo.
6.4. Alteração, cancelamento e fuso horário deverão seguir o comportamento documentado e não poderão representar evento externo como confirmado sem evidência correspondente.
6.5. Sincronização de agenda deverá distinguir intenção, convite, aceite, recusa, cancelamento, atualização e conflito. Evento pendente, falha de provider ou webhook não confirmado não será apresentado como compromisso definitivo sem indicação do estado correspondente.
7. Gravação e transcrição
7.1. O Cliente deverá determinar local dos participantes, finalidade, aviso, fundamento, consentimento quando exigido, acesso, retenção e forma de não participação.
7.2. A decisão de não impor bloqueio universal por falta de confirmação do aviso não autoriza gravar quando regra aplicável exigir condição não satisfeita.
7.3. Gravação, transcrição, diarização, resumo, score e compartilhamento exigem avaliação separada de finalidade, permissão, dado e retenção.
7.4. Avaliação de trabalhador, candidato ou outra pessoa requer análise de transparência, proporcionalidade, discriminação, revisão e regras laborais ou setoriais.
7.5. Gravação, transcrição, diarização, identificação de falante, resumo, extração e score são operações distintas. Cada uma dependerá de finalidade, aviso, base, acesso, retenção, fornecedor e território compatíveis, e a autorização de uma não será estendida automaticamente às demais.
8. Inteligência artificial
8.1. Geração, classificação, extração, previsão, recomendação, score e automação seguem os Termos de IA e a ficha específica da capacidade.
8.2. Cada recurso deverá declarar entradas, saídas, modelo ou categoria de fornecedor, destino, retenção, finalidade, autonomia, revisão e limitações relevantes.
8.3. Não se presume que todo recurso use o mesmo modelo, fornecedor, região ou conjunto de dados, nem que uma cláusula genérica autorize treinamento entre clientes.
8.4. Saídas são dependentes de dados e contexto e não garantem receita, conversão, fechamento, desempenho, causalidade, acurácia ou ausência de viés.
8.5. Copilotos e agentes deverão indicar, conforme a capacidade, se produzem sugestão, rascunho, recomendação ou execução; quais ferramentas e dados podem acessar; e onde existe revisão humana. Linguagem de interface não ocultará ação automática nem atribuirá certeza a inferência probabilística.
9. Predictive Deal e analytics
9.1. Score, forecast, tendência e indicador são estimativas produzidas a partir de dados e critérios disponíveis, e não fatos ou promessas de resultado.
9.2. Uso de dados da própria organização para previsão, calibração ou avaliação deverá ser descrito por finalidade, escopo, usuários, retenção e efeito.
9.3. Recurso que produza efeito relevante sobre pessoa natural exigirá avaliação de base, qualidade, viés, transparência, revisão e contestação conforme a lei aplicável.
9.4. Aivyro não utilizará Dados do Cliente em treinamento geral ou entre clientes sem autorização contratual específica, separada e informada.
9.5. O Predictive Deal e demais analytics deverão identificar população, janela, dados de entrada, natureza do score, limitações, atualização e uso recomendado no alcance disponível. O Cliente não deverá utilizar pontuação como fundamento exclusivo de decisão que produza efeito relevante sem avaliação humana e controles exigíveis.
10. Workflows e agentes
10.1. Workflow ou agente poderá consultar dados, criar tarefa, alterar registro, enviar comunicação ou executar outra ação somente no alcance contratado e autorizado.
10.2. A ficha indicará gatilho, permissões, destinatários, limites, dependências, ação externa, condição de confirmação e consequência previsível.
10.3. Nem toda ação exige revisão humana; onde a lei, o Pedido ou a configuração exigir confirmação, o produto deverá respeitá-la antes da execução.
10.4. Falha, repetição, cancelamento e retomada deverão informar estado disponível e ações ainda possíveis, sem promessa de reversão universal.
10.5. Workflow ou agente deverá respeitar autorização por ferramenta, escopo organizacional, limites, prevenção de repetição e estado persistido. Disparo duplicado, reentrada, retry, timeout ou compensação serão tratados segundo o contrato técnico da automação, com evidência suficiente para investigação.
11. Integrações
11.1. Conectar sistema externo autoriza somente contas, escopos, fluxos e finalidades apresentados e aceitos pelo Cliente.
11.2. Integração deverá distinguir fornecedor contratado pela Aivyro, controlador independente e terceiro escolhido pelo Cliente, com responsabilidades correspondentes.
11.3. Origem externa da falha não exclui automaticamente responsabilidade da Aivyro por seleção, configuração, integração, informação ou obrigação assumida.
11.4. Retirada de autorização deverá produzir os efeitos documentados sobre token, nova sincronização, fila e dados já importados, sem prometer exclusão automática em todos os terceiros.
11.5. A Aivyro distinguirá integração nativa, conector de terceiro, serviço contratado diretamente pelo Cliente e funcionalidade experimental. A qualificação determinará suporte, responsabilidade, proteção de dados e remédio, sem exclusão genérica por toda falha que envolva terceiro.
12. APIs webhooks e extensões
12.1. API, webhook, SDK, MCP ou extensão dependerá de disponibilidade, autenticação, escopo, limite, versão e termos técnicos identificados.
12.2. O Cliente é responsável por proteger segredos e pelo código que controla; Aivyro responde pela interface, segurança e comportamento sob seu controle.
12.3. Mudança incompatível, vulnerabilidade ou depreciação será tratada segundo compromisso de versão, urgência, aviso, migração e remédio aplicáveis.
12.4. Documentação de exemplo não constitui garantia de suporte a fluxo não identificado no Pedido nem autorização para extrair dado além da finalidade.
12.5. API e webhook estarão sujeitos a autenticação, autorização, esquema, versionamento, limites, assinatura, retry e política de descontinuação documentados quando contratados. O Cliente protegerá segredos e endpoints sob seu controle; a Aivyro responderá por controles e eventos sob sua camada.
13. Capacidade e limites
13.1. Assentos, contatos, mensagens, minutos, arquivos, armazenamento, requisições, créditos e outros limites somente vinculam quando definidos no Pedido.
13.2. Limite técnico de segurança não poderá ser usado para impor preço retroativo ou reduzir indevidamente capacidade vendida.
13.3. O Cliente deverá receber informação suficiente para prever consumo e contestar erro; a Aivyro não publicará franquia ou política de uso justo não aprovada.
13.4. Uso que prejudique terceiros poderá ser limitado de modo proporcional sob a Política de Uso Aceitável, independentemente de saldo, sem criar cobrança extra automática.
13.5. Limites poderão ser quantitativos, funcionais, territoriais, de segurança, taxa, armazenamento, retenção ou fornecedor, devendo ser identificáveis antes do uso que gere custo ou bloqueio. Medida de proteção emergencial será reavaliada e não alterará permanentemente o plano sem fundamento contratual.
14. Cobrança e eventos
14.1. Unidade, franquia, teto, consumo, reserva, excedente e compensação seguirão a Política de Cobrança e o Pedido.
14.2. Operação falha, inválida, duplicada ou repetida por erro técnico não deverá gerar consumo definitivo incompatível com a regra contratada.
14.3. Custo interno de infraestrutura será separado da unidade comercial; custo de fornecedor, mensagem ou telefonia não será repassado sem condição prévia.
14.4. Evento de produto e evento faturável não são sinônimos e deverão ser conciliáveis no registro de medição quando houver cobrança variável.
14.5. A regra de faturamento deverá identificar unidade, momento de consumo, arredondamento, repetição, falha, cancelamento, estorno e ação de terceiro. Evento técnico rejeitado, compensado ou não entregue somente será cobrado quando a condição comercial expressamente o previr e for juridicamente válida.
15. Beta pilotos e previews
15.1. Recurso experimental será identificado antes da adesão, com finalidade, dados, limites, suporte, prazo, risco e consequência de retirada.
15.2. O rótulo beta não elimina proteção de dados, segurança, confidencialidade, informação, devolução ou responsabilidade inderrogável.
15.3. Dados de produção, sensíveis ou regulados não deverão ser admitidos sem aprovação específica do piloto e controles correspondentes.
15.4. Resultado de piloto não garante lançamento, continuidade, preço futuro, compatibilidade ou conversão automática em serviço contratado.
15.5. Recurso Beta poderá ser modificado ou descontinuado com regime distinto, mas permanecerá sujeito a confidencialidade, segurança, proteção de dados, propriedade intelectual e informação. O Cliente não o utilizará em produção crítica ou uso regulado sem autorização expressa e controles compatíveis.
16. Mudança continuidade e SLA
16.1. Mudança material de função, finalidade, fornecedor, região, integração, limite ou comportamento será avaliada e comunicada conforme contrato e lei.
16.2. Correção urgente de segurança ou obrigação legal poderá exigir limitação imediata, com registro, comunicação e remédio quando aplicáveis.
16.3. Nível de serviço, disponibilidade, suporte, recuperação, continuidade e prazo somente serão prometidos por compromisso mensurável e capacidade operacional comprovada.
16.4. Retirada de capacidade contratada deverá considerar alternativa, migração, crédito, término afetado ou outro remédio conforme impacto e instrumento.
16.5. Alteração material será avaliada pela funcionalidade global e pelo caso de uso contratado, não apenas pela manutenção do nome ou de interface semelhante. Redução de limite, remoção de integração, mudança de fornecedor ou novo risco de dados poderá ser material mesmo sem eliminação da página.
17. Exportação e término
17.1. Pedido e ficha deverão identificar formato, prazo, limite, assistência, encerramento de integrações e destinação dos dados no término.
17.2. Nenhum prazo universal de exportação é criado por estes Termos; a condição deverá estar disponível antes da contratação e ser tecnicamente comprovada.
17.3. Produção, fila, arquivo, gravação, transcrição, representação vetorial, registro, fornecedor e cópia de segurança podem exigir procedimentos distintos de exclusão, isolamento e preservação.
17.4. Cobrança pendente não autoriza impedir direito obrigatório de titular nem descumprir entrega, legal hold ou preservação aplicável.
17.5. A saída deverá contemplar formatos, objetos, anexos, histórico, relações e metadados pertencentes ao Cliente no alcance contratado. Não incluirá código, segredo, dado de terceiro ou inferência proprietária sem direito de acesso, preservadas portabilidade e entrega legalmente exigíveis.
18. Território revisão e vigência
18.1. Cada módulo será avaliado conforme entidade, país, estado ou província, setor, titular, canal, dado, fornecedor, transferência e efeito relevante.
18.2. Saúde, crédito, emprego, seguro, criança, biometria, gravação, robocall ou outro uso regulado não é autorizado por estes Termos gerais. A habilitação exige previsão expressa no Pedido, anexo aplicável e controles compatíveis.
18.3. Oferta e publicidade suficientemente precisas poderão produzir efeitos legais; divergência entre marketing, demonstração, documentação e Pedido deverá ser resolvida antes do aceite.
18.4. Estes Termos vigoram na data indicada e alcançam somente capacidades efetivamente habilitadas no Pedido. Funcionalidade em código, demonstração, roadmap ou documentação não passa a integrar a contratação sem identificação e disponibilidade correspondentes.
18.5. Nova capacidade, mudança de autonomia, provider, dado, território, cobrança ou uso regulado exigirá revisão da ficha e dos documentos relacionados antes de sua oferta vinculante. O histórico deverá permitir identificar qual especificação se aplicava a cada Pedido e período.