Política de Privacidade

A Inteleduc é um ecossistema tecnológico voltado para instituições de ensino, com soluções pensadas para aproximar escolas, profissionais, alunos e famílias ao longo da trajetória educacional. Esta política se aplica aos sites públicos, às plataformas web, aos módulos internos e a eventuais aplicativos mobile que integrem o ecossistema.

No checkout analisado, identifiquei o site público em Next.js, o blog, o formulário de captação, o carregamento de pixels e integrações externas de navegação. Não encontrei, neste repositório, código de aplicativo mobile próprio; por isso, qualquer referência a app precisa de validação específica.

Os campos institucionais obrigatórios continuam pendentes de confirmação formal: [RAZÃO SOCIAL], [CNPJ], [ENDEREÇO], [E-MAIL DE PRIVACIDADE] e [ENCARREGADO PELO TRATAMENTO DE DADOS].

Dependendo do fluxo, a instituição de ensino pode definir a finalidade e as condições de uso dos dados de alunos, responsáveis e profissionais, enquanto a Inteleduc fornece a infraestrutura, os módulos e os recursos contratados para a execução dessas finalidades.

Em algumas operações, a Inteleduc também toma decisões próprias, como segurança da plataforma, administração contratual, suporte, comunicação comercial e proteção contra uso indevido. Já em fluxos pedagógicos, de saúde ou de acompanhamento, a repartição de responsabilidades precisa ser confirmada caso a caso.

Este checkout não permite afirmar, de modo automático, que a instituição é sempre controladora e a Inteleduc sempre operadora. Essa classificação depende do fluxo real e deve receber validação jurídica antes da publicação final.

Dados de identificação e contato. O site coleta, no formulário de interesse, nome, e-mail e perfil informado pelo visitante. Em módulos do ecossistema, podem existir também nome completo, CPF, data de nascimento, matrícula, fotografia, endereço, telefone e vínculo entre alunos, responsáveis e instituições.

Dados acadêmicos e institucionais. O próprio posicionamento do produto indica tratamento de matrícula, turma, frequência, avaliações, atividades, documentos, históricos e registros pedagógicos. Esse tipo de dado aparece como parte da continuidade entre captação, gestão, desenvolvimento e saúde.

Dados profissionais. Para professores, coordenadores, gestores, colaboradores e profissionais autorizados, o ecossistema pode envolver cargo, função, unidade, turmas, permissões e registros de atuação. Esses elementos precisam permanecer limitados à necessidade de cada perfil.

Dados de saúde e dados sensíveis. Os materiais institucionais mencionam o pilar de Saúde e o acompanhamento de situações como convivência, inclusão, saúde emocional e necessidades específicas. Isso pode incluir alergias, medicamentos, laudos, observações psicológicas e informações de acompanhamento especializado, mas a existência e a extensão desse tratamento devem ser validadas antes da versão final.

Dados técnicos. No site público, o repositório confirma o uso de página visitada, rota, estado de introdução no navegador, scripts de telemetria, identificação técnica do pixel e consultas ao blog. O código também mostra que o conteúdo editorial pode ser consumido a partir de servidores externos.

Conteúdos inseridos pelos usuários. O fluxo de captação envia nome e e-mail para identificação no pixel e abre uma conversa no WhatsApp com mensagem gerada a partir do nome e do perfil escolhido. Em outros módulos, podem existir mensagens, observações, documentos, imagens, vídeos, áudios e anexos, o que precisa de validação separada.

O site público confirma três frentes claras de coleta. A primeira é o formulário de interesse da home, que pede nome e e-mail. A segunda é a telemetria do pixel, inicializada em pixel.inteleduc.com, que recebe a página visitada e a identificação do lead quando o visitante decide continuar a jornada. A terceira é a navegação do blog, consumida pelo servidor da aplicação.

O repositório também confirma o uso de localStorage com a chave inteleduc:intro-seen:v1 para não repetir a introdução entre navegações. Não encontrei uso explícito de sessionStorage nem configuração própria de cookies no código analisado.

O carregamento do pixel ocorre via script externo, e o site envia a página atual e o estado do visitante para esse fornecedor. Como o comportamento detalhado do pixel pertence ao serviço externo, qualquer afirmação sobre cookies do fornecedor, retenção ou treinamento precisa ser validada na documentação do próprio serviço.

A aplicação também consulta o blog público em blog.inteleduc.com e aceita mídias remotas em domínios de armazenamento publicados na configuração do Next.js. Isso mostra uso de serviços externos, mas não comprova que esses serviços recebam dados pessoais do usuário final além da navegação normal.

Neste checkout, não localizei código de aplicativo mobile. Por isso, não é possível afirmar quais permissões ou recursos são usados em app nativo sem revisar o repositório correto.

Se existirem aplicativos mobile em outro projeto, as permissões de câmera, fotos e arquivos, microfone, notificações, biometria, localização, contatos, calendário e Bluetooth precisam ser descritas por funcionalidade, com indicação clara de obrigatoriedade, uso local ou envio aos servidores.

Enquanto isso não for validado, qualquer texto sobre app mobile deve permanecer com o marcador [VALIDAR COM A EQUIPE: confirmar quais permissões o aplicativo realmente solicita e por quê].

No site público, as finalidades confirmadas são exibir conteúdo institucional, registrar o estado da introdução, identificar visitantes interessados e permitir a continuidade do contato por WhatsApp. Essas finalidades servem à comunicação com o público e ao direcionamento comercial inicial.

No ecossistema educacional, as finalidades podem incluir criar e administrar contas, autenticar usuários, manter vínculos entre alunos e responsáveis, administrar matrículas, turmas e equipes, disponibilizar funcionalidades pedagógicas, acompanhar a trajetória do aluno, registrar atendimentos e permitir comunicação entre instituição, profissionais, alunos e famílias.

Também podem existir finalidades de suporte, segurança, prevenção de fraudes, auditoria, cumprimento de obrigações legais, melhoria de estabilidade, acessibilidade e desempenho, produção de indicadores e integração entre módulos. Cada uma dessas finalidades deve ser vinculada a um fluxo real, e não a uma fórmula genérica.

Para navegação pública, registro de segurança, proteção contra abuso e telemetria essencial, a base legal sugerida tende a ser legítimo interesse, desde que o interesse seja documentado e o impacto aos titulares seja avaliado.

Para captação de leads e continuidade de contato iniciada pelo próprio visitante, a base pode variar entre consentimento, procedimentos preliminares relacionados a contrato ou legítimo interesse, conforme o canal usado e a expectativa razoável do titular.

Para dados escolares, profissionais e institucionais, as bases legais costumam variar entre execução de contrato, cumprimento de obrigação legal ou regulatória, exercício regular de direitos, tutela da saúde, proteção da vida e legítimo interesse. Em dados sensíveis, a base precisa ser compatível com a categoria tratada.

Sempre que a decisão depender de um fluxo externo ao repositório, a política deve conservar o marcador [VALIDAR JURIDICAMENTE: definir a base legal aplicável a esta operação].

O ecossistema foi pensado para lidar com trajetórias escolares, o que implica tratamento de dados de crianças e adolescentes. Nesses casos, o melhor interesse deve orientar a leitura de todos os fluxos.

O acesso dos responsáveis depende da existência e validação do vínculo, e os perfis de alunos, responsáveis e profissionais podem ter níveis diferentes de visibilidade. As configurações devem ser protetivas por padrão, sem publicidade comportamental e sem venda de dados.

Dados escolares e dados sensíveis de menores não devem circular sem necessidade funcional. Quando o consentimento do responsável for a base adequada, ele deve ser solicitado de forma específica e compreensível.

A integração entre módulos permite dar continuidade aos processos da instituição, mas não amplia automaticamente o acesso às informações. Cada usuário deve ver apenas os dados compatíveis com sua função, seu vínculo, suas permissões e a finalidade do acesso.

O material institucional descreve uma atuação conjunta entre captação, gestão, desenvolvimento e saúde. Isso sugere que informações de um setor podem apoiar outro, mas o repositório não comprova as regras de visibilidade por perfil. Essa diferenciação precisa ser validada antes de ser afirmada na política final.

Para titulares ligados a diferentes instituições, o texto final deve afirmar separação entre bases e impedir acesso cruzado, porém essa garantia técnica precisa ser confirmada no ambiente certo.

A visão do produto mostra continuidade entre módulos, em vez de compartimentos isolados. Na prática, isso pode significar que um dado nascido na captação siga para gestão, matrícula, acompanhamento pedagógico ou saúde, desde que a origem, a finalidade e o destino continuem controlados.

A política precisa explicar quais informações podem seguir de um módulo para outro, quais usuários podem acessar o dado no destino, se há sincronização, cópia ou mera referência e como o contexto original é preservado. Nada disso está comprovado integralmente neste checkout, então a versão final deve manter a validação aberta.

O código confirma o uso de fornecedores de conteúdo e telemetria. O primeiro é o próprio blog público, consumido em blog.inteleduc.com. O segundo é o pixel da plataforma, carregado em pixel.inteleduc.com. Há ainda integrações com o WhatsApp para continuidade do contato e com domínios remotos de mídia publicados na configuração do Next.js.

O repositório também permite imagens em inteleducpublic.blob.core.windows.net e inteleducstorage.blob.core.windows.net. A função exata desses ambientes de armazenamento precisa ser validada, assim como eventual transferência internacional e os limites contratuais dos fornecedores.

Não há, neste checkout, integração confirmada com e-mail corporativo, monitoramento de erros, pagamentos ou autenticação de terceiros. Essas categorias devem constar na política apenas se forem encontradas em outro módulo do projeto.

Os materiais institucionais mencionam a Arei como parte da visão do ecossistema, mas este checkout não contém integração técnica com fornecedor de IA, endpoint de prompts ou fluxo que confirme envio de dados a um modelo externo.

Por isso, não é possível afirmar por quanto tempo entradas e respostas seriam armazenadas, se haveria uso para treinamento, se existe anonimização, se há revisão humana ou se a IA tomaria decisões automatizadas. Todos esses pontos precisam de validação separada.

Se houver IA em outro backend ou aplicativo, a política deve registrar quais dados podem ser enviados, quem processa as informações, qual é a base legal e como o titular pode contestar resultados incorretos.

O projeto analisado não traz uma política formal de retenção por categoria. O que pude confirmar é apenas o estado local da introdução no navegador e o fato de o blog público ser consultado sem retenção local permanente no front-end.

A política final precisa indicar por quanto tempo cada categoria de dado fica armazenada, o que acontece após o encerramento de conta ou contrato, como a instituição exporta informações, quando os dados saem da base principal e por quanto tempo podem permanecer em backups.

Se não houver regra documental, o texto deve permanecer com o marcador [VALIDAR COM A EQUIPE: informar a política de retenção por categoria e os critérios de exclusão].

Medidas efetivamente visíveis no código incluem o uso de conexões HTTPS nos serviços externos, a centralização do bootstrap do pixel em um componente próprio, a importação server-only para a consulta ao blog e o uso de noopener,noreferrer ao abrir o WhatsApp.

A política não deve afirmar criptografia em repouso, trilha de auditoria completa, retenção segura de backups ou segregação por perfil sem confirmação técnica. Esses controles podem existir na infraestrutura, mas não estão comprovados neste repositório.

Qualquer afirmação adicional sobre controle de acesso, gestão de vulnerabilidades, monitoramento e resposta a incidentes precisa ser suportada por documentação ou validação operacional.

O repositório não mostra um procedimento formal de resposta a incidentes. A política final deve descrever como eventos são identificados, analisados e escalados, inclusive quando houver risco relevante para titulares ou instituições.

Também é preciso validar os canais de comunicação interna e externa, o conteúdo exigido em uma notificação e os critérios para informar autoridades, instituições ou titulares.

Suspeitas de incidente devem poder ser encaminhadas ao canal de privacidade indicado nesta política até que a resposta operacional esteja formalizada.

O titular pode solicitar confirmação da existência de tratamento, acesso, correção, informação sobre compartilhamento, anonimização, bloqueio, exclusão, portabilidade, revogação do consentimento, oposição e revisão de decisões automatizadas, quando aplicável.

Em fluxos controlados pela instituição de ensino, parte das solicitações pode ser encaminhada à própria instituição, especialmente quando ela definir a finalidade do tratamento. Antes de qualquer entrega ou alteração, a identidade do solicitante precisa ser validada.

O texto final deve esclarecer que alguns pedidos podem sofrer limitações legais, contratuais ou institucionais, sem transformar isso em recusa genérica.

O canal publicado para privacidade pode ser o e-mail contato@inteleduc.com.br, já presente na página pública e no material oficial consultado. Esse canal deve ser confirmado como endereço ativo para solicitações de dados.

Os demais campos obrigatórios continuam abertos: [RAZÃO SOCIAL], [CNPJ], [ENDEREÇO], [ENCARREGADO PELO TRATAMENTO DE DADOS] e o procedimento formal de validação da identidade.

As solicitações feitas por responsáveis em nome de alunos precisam registrar o vínculo e o motivo do pedido, com tratamento compatível com a idade e a relação jurídica.

A versão vigente deve informar a data da última atualização, que nesta revisão é 30 de julho de 2026. Mudanças relevantes precisam ser comunicadas pelos canais adequados e não devem ser tratadas como consentimento automático pelo simples uso continuado do serviço.

O histórico de versões, se existir, precisa ser indicado de forma clara. Quando a mudança alterar a finalidade ou a base legal, a nova manifestação do usuário pode ser necessária.