# Tecnisol Ponto — dossiê funcional, técnico e de proteção de dados

**Referência:** 31/10/2026. **Revisão:** 1.0. **Finalidade:** documentação de produto, uso interno, contratos e revisão legal. Esta edição pode ser compartilhada para revisão: não contém registros reais de trabalhadores, credenciais, chaves ou localização técnica detalhada dos serviços.

O dossiê descreve a aplicação desta pasta e a infraestrutura que a atende. WordPress, hub institucional e demais aplicações da VPS são sistemas distintos: a verificação da infraestrutura compartilhada não representa auditoria completa das regras de negócio desses outros produtos.

## Sumário

1. Identificação e estado do produto
2. Arquitetura e limites de isolamento
3. Pessoas, contas e permissões
4. Catálogo das funções implementadas
5. Captura Android e sincronização
6. Tratamento, apuração e documentos de ponto
7. Administração, operação e continuidade
8. Inventário de dados e percurso das informações
9. Segurança e limites das proteções
10. Avaliação de adequação à LGPD
11. Termos, privacidade e documentos atuais
12. Funcionalidades e obrigações futuras
13. Testes, manutenção e gestão de versões
14. Critérios de contratação e entrada em operação
15. Fontes, glossário e apontamentos

## 1. Identificação e estado do produto

Tecnisol Ponto é um sistema hospedado para registrar e conferir jornadas de trabalho. O funcionário utiliza um aplicativo Android em tablet compartilhado; profissionais de RH usam um painel web; operadores da fornecedora possuem uma gestão separada.

O objetivo é conservar a captura original, permitir conferência e tratamento com autoria, apoiar escalas/calendário e produzir documentos de jornada. O produto não constitui, por si só, folha de pagamento, sistema de saúde ocupacional, consultoria trabalhista ou seleção automática da convenção coletiva correta.

Componentes principais: servidor Python/Django; PostgreSQL; API para tablets; interface web em português; aplicativo Kotlin/Compose com Room, WorkManager e Android Keystore; proxies HTTP/HTTPS; rotinas separadas de manutenção, assinatura e cópia de segurança.

O Android preparado é o **0.9.0-piloto, código 14**, protocolo 1, com base local Room na versão 4. A instalação e os ensaios físicos combinados nos dois tablets ainda não foram concluídos. O sistema anterior permanece a origem operacional durante a transição planejada.

Há código entregue para vários requisitos de REP-P/PTRP, porém faltam comprovante individual, operação completa de certificados e registro, atestado, comprovação de hora, disponibilidade e etapas externas. **Não apresentar esta edição como declaração de conformidade integral.**

### Convenção de estado

- **Implementado:** existe função no código e evidência de teste/revisão; condições de uso continuam aplicáveis.
- **Preparado:** há base técnica, mas falta integração, documentação, configuração ou homologação para uso final.
- **Pendente:** entrega externa ou técnica ainda necessária.
- **Planejado:** direção de evolução, sem disponibilidade ou prazo contratual assegurado.

Documentos históricos do projeto podem descrever comportamentos antigos. Para o diário/tratamento, a entrega de 29/10 e o código vigente prevalecem sobre descrições antigas de bloqueio diário por tipo ou escolha automática da primeira entrada.

## 2. Arquitetura e limites de isolamento

### 2.1 Componentes e responsabilidades

| Componente | Responsabilidade |
|---|---|
| Aplicativo Android | Identificar funcionário, exibir ações/relógio, persistir evento e sincronizar |
| API de tablets | Autorizar instalação/dispositivo/empresa, receber eventos e devolver confirmações |
| Painel cliente | Cadastro, planejamento, conferência, relatórios e administração autorizada da empresa |
| Gestão da fornecedora | Empresas, vínculos, suporte explícito e operações autorizadas |
| Catálogo central | Autenticação, sessões, MFA, empresas, vínculos e segurança global |
| Banco lógico da empresa | Dados de RH, jornadas, batidas, tratamento e documentos da empresa |
| Processo de manutenção | Criar/migrar bancos e executar tarefas que o web não pode fazer |
| Processo de assinatura | Assinar saídas preparadas, quando certificados reais estiverem configurados |
| Cópias e recuperação | Guardar dados/configuração e ensaiar restauração em ambiente separado |
| WordPress de materiais | Distribuir documentação; não recebe a base de RH para funcionar |

### 2.2 Separação entre clientes

O produto atende várias empresas, com um catálogo central e banco/papel próprios para novas empresas. A empresa legada importada conserva os dados de RH no banco central da instalação restaurada como exceção histórica explícita. Isso não cria autorização para consultar livremente os dados dela.

O contexto de empresa é validado no servidor a partir da sessão, do vínculo e da situação. Identificador de empresa, CNPJ ou endereço com UUID não são autorização. O contexto é separado por requisição e os formulários mantêm a empresa de origem, inclusive em abas diferentes.

A arquitetura reduz vazamentos por consultas e permissões incorretas, mas compartilha código, processo e infraestrutura. Um comprometimento do processo web ou da administração do host pode ultrapassar o isolamento lógico. Não equivale a instância física dedicada por cliente nem a alta disponibilidade.

### 2.3 Empresa, unidade e grupo

Empresa representa o empregador/cliente autorizado; unidade identifica local de operação. Funcionário ativo pode usar os tablets autorizados da mesma empresa, independentemente de seu setor ou unidade de origem. O tablet atual pertence a uma empresa.

A conta contratante com vários CNPJs e um tablet compartilhado entre eles é **planejada**. Não existe seleção livre de empresas no login atual do cliente.

## 3. Pessoas, contas e permissões

Funcionário que bate ponto e usuário do painel são conceitos distintos. Cadastrar um funcionário não cria conta de RH. Cada conta cliente possui um único vínculo de empresa.

| Atividade | Administrador cliente | RH | Consulta | Gestão fornecedora |
|---|---|---|---|---|
| Consultar dados e relatórios da empresa | Sim | Sim | Sim | Só após suporte explícito |
| Cadastros de funcionários e planejamento de RH | Sim | Sim | Não | Conforme acesso de suporte |
| Férias, abonos, observações e tratamento autorizado | Sim | Sim | Não | Conforme acesso de suporte |
| Unidades, dispositivos e configurações administrativas | Sim | Não | Não | Conforme acesso de suporte |
| Criar/editar/suspender contas do cliente | Sim, com confirmação | Não | Não | Recuperação/operação específica |
| Contatos pessoais do responsável pela empresa | Administrar | Restrito | Restrito | Conforme função de gestão |
| Segurança da própria conta | Sim | Sim | Sim | Sim |
| Gestão global de empresas | Não | Não | Não | Sim, com MFA |
| Privilégio de superusuário no painel cliente | Não | Não | Não | Não durante o acesso de suporte |

A política é aplicada nas views/backend, não apenas escondendo menus. A emissão/configuração fiscal também exige permissões próprias. Não é permitida a alteração das batidas originais pelo formulário de tratamento.

### 3.1 Autenticação e recuperação

Login cliente e login de gestão têm sessões/cookies separados. MFA é obrigatório para operadores globais; clientes podem ativar/desativar o próprio fator conforme os controles da conta. A configuração inicial do fator, após login, pede o código sem repetir a senha.

Navegadores confiáveis do cliente podem durar até 30 dias e ser revogados. Não eliminam a senha nem dispensam o fator obrigatório de operadores. As sessões comuns possuem prazo configurado de oito horas e expiração ao fechar o navegador, sujeitos ao comportamento de restauração do navegador e às revogações do servidor.

Links de definição de senha são temporários, separados por área e vinculados à conta; não fazem login automático e preservam o MFA. Atualmente a emissão assistida existe; e-mail transacional e recuperação autônoma completa por e-mail não estão homologados.

Edição de outro usuário exige nova confirmação do administrador, protege o último administrador ativo e revoga sessões/navegadores do alvo. Conta interna não pode ser alcançada como se fosse vínculo de cliente.

### 3.2 Acesso de suporte

O operador não é usuário obrigatório de todas as empresas. Para abrir RH de um cliente, informa senha, TOTP novo e motivo. A autorização é vinculada à empresa, dura no máximo 30 minutos, possui aviso visível e conserva a identidade real na auditoria. O privilégio global não é aplicado às views do cliente durante esse acesso.

## 4. Catálogo das funções implementadas

### 4.1 Cadastros e organização

| ID | Função | Estado e limite |
|---|---|---|
| F01 | Cadastrar/editar funcionário | Implementado; nome, CPF, admissão, setor, cargo e situação |
| F02 | Contatos e aniversário | Implementado; finalidade e necessidade devem ser revistas pelo empregador |
| F03 | Credencial de quatro dígitos | Implementado; conserva zeros; única dentro da empresa |
| F04 | Inativação e pesquisa de histórico | Implementado; ativos aparecem por padrão; inativos por seleção |
| F05 | Importação Excel/CSV | Implementado; modelo, prévia, validação e confirmação do lote |
| F06 | Importação sem sobrescrever existentes | Implementado; não cria automaticamente contas de painel |
| F07 | Unidades | Cadastro e remoção/restauração lógica, conservando referências históricas |
| F08 | Bloqueio de remoção de unidade em uso | Implementado para dispositivos vinculados em uso |
| F09 | Tablet por local de operação | Implementado; unidade da batida é preservada |
| F10 | Contatos do responsável pelo cliente | Implementado; acesso restrito e proteção contra edição concorrente |
| F11 | Contas e perfis cliente | Criação, edição e suspensão autorizadas, sem promoção global |
| F12 | Gestão de empresas | Cadastro, situação, vínculos e provisionamento separado |

Existem **10.000 combinações** de quatro dígitos por empresa, incluindo `0000`. O cadastro também reserva credenciais inativas, sem reciclagem automática. Empresas distintas podem repetir códigos; isso não cria 20 mil códigos distintos dentro de uma única empresa. A identidade interna usa UUID; o código de quatro dígitos não é senha forte nem prova física de presença da pessoa.

### 4.2 Planejamento e calendário

| ID | Função | Estado e limite |
|---|---|---|
| F13 | Jornada semanal | Implementada, com horários e vigência |
| F14 | Dias alternados | Implementados, com marco de início |
| F15 | Ciclos e 12×36 | Implementados; parametrização exige regra trabalhista conferida |
| F16 | Refeição opcional | Implementada; duração zero representa ausência desse intervalo no modelo |
| F17 | Pausas adicionais | Até seis no modelo, com repetição/exigência e contagem configuráveis |
| F18 | Pares do horário contratual | Implementados para identificação correta dos períodos |
| F19 | Escalas individuais e em grupo | Implementadas com vigências e histórico |
| F20 | Versões da jornada de referência | Implementadas por data |
| F21 | Calendário da empresa | Funcionamento semanal por período e exceções |
| F22 | Feriados nacionais e regionais | Importação/catálogo disponível; cobertura municipal limitada e revisão humana |
| F23 | Feriado e fechamento como decisões distintas | Implementado; importar feriado não dispensa automaticamente a equipe |
| F24 | Férias | Inclusão, cancelamento e proteção contra sobreposição confirmada |
| F25 | Folgas/ausências/expediente excepcional | Implementados com motivo e integração aos relatórios |
| F26 | Abono individual | Implementado, autorizado e auditado |
| F27 | Abono geral por período | Implementado com prévia, confirmação vinculada e proteção de concorrência |
| F28 | Turnos após meia-noite | Consolidação pela data inicial, conservando os horários originais |

O calendário atual é da empresa/instalação. Calendários independentes por unidade permanecem evolução. A base regional não significa cobertura jurídica automática de todos os municípios ou de futuras alterações legislativas. Consultas de relatórios não dependem de requisições externas de feriados.

### 4.3 Relatórios e conferência

| ID | Função | Estado e limite |
|---|---|---|
| F29 | Visão geral | Indicadores e acesso aos cadastros, conforme perfil |
| F30 | Filtros combinados | Períodos, pessoas e recortes disponíveis nas telas de relatório |
| F31 | Espelho de jornada | Previsto, realizado, situações e tratamento, sujeito à configuração correta |
| F32 | Marcações detalhadas | Horários e registros originais conservados |
| F33 | Faltas por dia/pessoa/setor | Implementadas; não antecipa falta de jornada ainda em andamento |
| F34 | Relatórios de abonos | Implementados, com motivos e situações |
| F35 | Prévia, CSV e PDF | Implementados compartilhando regras de cálculo e seleção |
| F36 | Observações de RH | Escopos geral, setor, cargo e funcionário |
| F37 | Consulta de inconsistências | Implementada; não apagar/deduplicar automaticamente o histórico |
| F38 | Preferências visuais do painel | Filtros e ampliação de leitura; não equivalem a auditoria integral de acessibilidade |

## 5. Captura Android e sincronização

| ID | Função | Estado e limite |
|---|---|---|
| F39 | Ativação por QR/código temporário | Implementada; autorização específica do aparelho/empresa |
| F40 | Segredo por instalação | Implementado e protegido pelo Keystore |
| F41 | Nome antes da confirmação | Implementado para conferência da identificação |
| F42 | Entrada, saída, refeição e pausas | Implementadas conforme ações e regras |
| F43 | Gravação local antes da confirmação visual | Implementada; não equivale ao comprovante fiscal individual |
| F44 | Captura offline | Implementada; depende de conservação e funcionamento do aparelho |
| F45 | Reenvio em reconexão | Implementado por callbacks/trabalho agendado e retentativas |
| F46 | Idempotência por UUID e sequência | Implementada; repetir envio não significa criar nova batida |
| F47 | Nova batida do mesmo tipo | Permitida; não deve ser descartada por proximidade ou fechamento |
| F48 | Conflitos e rejeições visíveis | Implementados, com preservação para revisão |
| F49 | Referência de hora do coletor | Implementada tecnicamente; comprovação da referência HLB pendente |
| F50 | Revogação/restauração de dispositivo | Implementadas; offline impede efeito instantâneo no aparelho |
| F51 | Recuperação do código por CPF | Somente online, em tablet autorizado e com limitação de tentativas |
| F52 | Consulta de batidas de outros tablets | Online; não conhece pendências ainda offline em outro aparelho |
| F53 | Aviso de sequência incompleta | Implementado; não bloqueia arbitrariamente uma marcação legítima |
| F54 | Quiosque e senha de saída | Implementados; bloqueio completo depende de Android gerenciado/MDM |
| F55 | Seleção de servidor antes do vínculo | Implementada, somente origem HTTPS válida e conferida com QR |
| F56 | Atualização preservando fila | Migrações aditivas implementadas; falta ensaio físico da atualização atual |
| F57 | Transição com entregas independentes | Preparação específica de migração; não é replicação automática entre bancos |

A fila mantém separadas ocorrência e recepção. Reinício ou referência vencida geram aviso e não autorizam reescrever eventos. A configuração de transição é específica para os ambientes autorizados e deve ser encerrada conforme o procedimento de migração.

Desinstalar, limpar dados, restaurar de fábrica ou trocar a chave de assinatura pode comprometer a fila/identidade. Nenhuma dessas ações integra a atualização normal aprovada.

O cache contém o mínimo para uso offline, como identificadores, nomes e códigos; não distribui CPF, contatos ou senhas do painel. O banco Room não utiliza uma camada adicional SQLCipher; depende da proteção do aplicativo e do Android. Segredo de autorização e configurações sensíveis usam armazenamento cifrado separado.

Câmera é usada para ler QR de ativação. Não foi identificado recurso de reconhecimento facial, gravação de áudio ou localização por GPS no aplicativo atual. Uma futura inclusão exigirá novo inventário e avaliação específica.

## 6. Tratamento, apuração e documentos de ponto

### 6.1 Implementação atual

| ID | Função | Estado e limite |
|---|---|---|
| F58 | Diário original e encadeamento de integridade | Implementados; proteção contra alteração pelo papel do web |
| F59 | Início fiscal explícito | Implementado por estabelecimento; empresa real ainda não liberada |
| F60 | NSR compartilhado entre tablets do estabelecimento | Implementado para o fluxo iniciado, sem criação retroativa para o legado |
| F61 | Identidade e metadados observados | Guardados nas novas capturas; ausências antigas não são inventadas |
| F62 | Inclusão de esquecimento | Implementada com motivo, autor e horário; separada do original |
| F63 | Desconsiderar/reconsiderar original | Implementado por registro de tratamento, sem apagar a batida |
| F64 | Cancelar inclusão anterior | Implementado com rastreabilidade |
| F65 | Fechar/reabrir período | Implementado com revisões preservadas e justificativa |
| F66 | Nova batida após fechamento | Preservada; não eliminada por estar fora de uma revisão anterior |
| F67 | Vários períodos de trabalho por dia | Implementados; ambiguidades exigem conferência |
| F68 | Regras de apuração com vigência | Implementadas; exigem base/regra trabalhista informada |
| F69 | Duração noturna e redução | Implementadas conforme política configurada; não universais |
| F70 | Diferenças e tolerâncias diárias | Base implementada; parâmetros e cenários devem ser homologados por cliente |
| F71 | Banco de horas e ausências | Lançamentos com motivo/autoria; relatório não credita saldo automaticamente |
| F72 | Preparação de AFD 004 e AEJ 002 | Implementada com validação estrutural e bloqueios de integridade |
| F73 | Assinatura fiscal fora do web | Integração preparada; certificado qualificado real pendente |
| F74 | Download final de documento fiscal | Bloqueado enquanto faltar assinatura/configuração exigida |
| F75 | Comprovante individual e acesso do trabalhador | Pendente |
| F76 | Registro de eventos sensíveis/disponibilidade | Implementação inicial e observação local; não prova de disponibilidade contínua |

O formato legal exige validação contra os leiautes oficiais e o funcionamento efetivo do conjunto. Referências: [AFD](https://www.gov.br/trabalho-e-emprego/pt-br/assuntos/inspecao-do-trabalho/fiscalizacao-do-trabalho/leiaute-do-arquivo-fonte-de-dados-afd.pdf) e [AEJ](https://www.gov.br/trabalho-e-emprego/pt-br/assuntos/inspecao-do-trabalho/fiscalizacao-do-trabalho/leiaute-do-arquivo-eletronico-de-jornada-aej.pdf).

### 6.2 Limites relevantes

A inclusão assistida oferecida na tela contempla entrada, saída e refeição; não presumir que toda ação de pausa possui o mesmo formulário de inclusão. Arquivos fiscais possuem limites operacionais de volume e recusam dados/cadastros insuficientes; não há capacidade ilimitada homologada.

Uma regra genérica de cálculo não determina a convenção coletiva aplicável. Não há seleção automática de instrumentos coletivos, pagamento de adicionais, folha completa, integração eSocial/folha homologada ou cálculo automático de todos os descontos. Relatórios e ajustes precisam de conferência do RH.

Uma cadeia de hashes detecta inconsistências no modelo examinado. Não é criptografia do conteúdo, carimbo de tempo independente nem garantia contra administrador que controle integralmente host, banco e chaves.

### 6.3 Legado

A importação conserva representação original e inconsistências. Os snapshots de transição não atribuem NSR retroativo nem afirmam que o cadastro observado na importação era idêntico na data da marcação antiga. Histórico pode ser usado para conferência e relatórios com sua origem identificada; isso não transforma o processo anterior em REP-P conforme.

## 7. Administração, operação e continuidade

O web usa papel restrito de banco; manutenção e migrações ficam fora do processo permanente. Rotinas devem preservar versões, dados e autorizações. Não existe atualização automática de código como efeito de fetch/pull agendado.

Contêineres do ponto possuem reinício automático; o web executa sem root, sem capabilities, sem novos privilégios e com sistema de arquivos somente leitura, exceto volumes autorizados e área temporária. Bancos e web não publicam portas externas diretamente. Proxies, sistema operacional e outros serviços são camadas próprias de manutenção.

### 7.1 Cópias

Há agendamento de cópia do ponto a cada seis horas e ensaio periódico de recuperação. O conjunto inclui bancos, papéis/configuração necessária, mídia e fonte versionada. Pacotes de transferência podem incluir material privado de continuidade, que nunca deve ser publicado com este dossiê.

Existe exportação manual cifrada, com chave separada e download autorizado pela gestão. A proteção depende de guardar ambos adequadamente, com a chave separada do pacote. Cópia local bem-sucedida e teste de criptografia não demonstram armazenamento fora da máquina.

Em 31/10, a restauração isolada do conjunto local mais recente passou, incluindo integridade dos arquivos, papéis e diário original. **Não há envio externo automático confirmado.** A rotina de restauração identificou expressamente a origem local.

### 7.2 Disponibilidade e capacidade

Não foram contratadas/comprovadas redundância independente, failover ou recuperação de desastre fora da VPS. Uma falha da máquina pode atingir vários serviços. A fila offline reduz dependência imediata de conectividade, sem substituir a conservação do tablet, o backup ou a infraestrutura exigida.

Não existe SLA comercial definitivo publicado. Frequência de backup é configuração de rotina, não garantia de perda máxima de seis horas: a proteção contra perda total depende de destino externo, monitoramento e teste real. Não foi feito ensaio de carga que comprove número comercial máximo de funcionários/clientes.

## 8. Inventário de dados e percurso das informações

### 8.1 Grupos de dados

| Grupo | Dados presentes ou previstos | Finalidade atual | Estado |
|---|---|---|---|
| Empregador | Nome/razão social, CNPJ/CPF, endereço e registros aplicáveis | Identificação do cliente/estabelecimento | Presente; identidade fiscal definitiva pendente |
| Responsável cliente | Nome, CPF, e-mail e telefone | Contato e administração autorizada | Presente, com acesso restrito |
| Usuário painel | Identificação, e-mail, vínculo, papel e situação | Autenticação e autorização | Presente |
| Autenticação | Hash de senha, sessões, segredo TOTP, códigos de recuperação e digests de confiança | Controle de acesso | Presente; não são públicos |
| Funcionário | UUID, nome, CPF, admissão, setor, cargo e situação | Identificação e jornada | Presente |
| Contatos/aniversário | E-mail, telefone e nascimento | Contato e recurso de aniversário | Opcionais; revisar necessidade/finalidade |
| Credencial operacional | Código de quatro dígitos | Identificação no tablet | Presente; não tratar como senha de conta |
| Jornada | Escalas, vigências, períodos, refeições, pausas e calendário | Planejamento e conferência | Presente |
| Marcações | Identificadores, tipo, horário/fuso, ocorrência/recebimento, origem, unidade e coletor | Registro original | Presente |
| Metadados do coletor | Instalação, sequência, conexão e referência de hora observadas | Rastreabilidade | Presente nas capturas compatíveis |
| Tratamento | Ajuste, motivo, autor, data e revisões | Correção rastreável e conferência | Presente |
| Ausências e observações | Férias, folgas, abonos e textos livres | Rotinas de RH | Presente; evitar detalhes sensíveis desnecessários |
| Segurança/suporte | Identidade do operador, motivo, data, ação e IP conforme evento | Investigação e controle de acesso | Presente |
| Importações | Arquivo/conferência, hash, inconsistências e resumo | Migração/cadastro | Presente |
| Saídas | Relatórios, arquivos fiscais preparados, hashes e assinaturas | Uso do empregador e fiscalização | Parcial conforme tipo de documento |
| Pagamentos | Referências de cliente/assinatura, pedido e evento de gateway | Contratação futura | Estrutura preparada; cobrança real inativa |
| Atendimento a titulares | Protocolo, validação proporcional e decisão | Exercício de direitos | Procedimento e módulo a formalizar |
| Aceite de documentos | Versão, hash, data, parte e representante | Evidência contratual futura | Ainda não implementado |

CPF/CNPJ e códigos não são fatores suficientes de autorização. Observações livres podem conter dados de saúde, religião ou filiação sindical por uso indevido, mesmo sem campo específico. A governança deve prevenir essa inclusão e tratar eventual ocorrência com restrição e análise adequada.

### 8.2 Fluxo de ponta a ponta

1. RH cadastra o funcionário ou confirma uma importação dentro da empresa autorizada.
2. Administrador autoriza o tablet; o segredo é específico e protegido no aparelho.
3. Tablet obtém o cadastro mínimo e as regras necessárias ao modo offline.
4. Funcionário informa o código, confere o nome e registra a ação.
5. Aplicativo persiste o evento antes de mostrar confirmação visual.
6. O evento é enviado por HTTPS; a API valida empresa, aparelho, identidade e conteúdo.
7. O banco conserva o original; o diário acrescenta a representação correspondente conforme o estado de operação.
8. RH confere e registra tratamentos separados, quando necessários.
9. Relatórios/arquivos são preparados dentro do contexto autorizado; saídas fiscais aguardam requisitos e assinatura.
10. Cópias preservam o conjunto operacional; envio externo ainda depende de implantação.

Não foi identificado envio de dados de RH para redes de anúncios, mecanismo de IA, biometria, GPS ou ferramenta de analytics na aplicação de ponto examinada. Isso não abrange automaticamente os cookies/serviços do site institucional, WordPress, provedor ou uma futura campanha.

### 8.3 Exclusão, correção e conservação

Inativar usuário, funcionário, dispositivo ou unidade não significa apagar seu histórico. Corrigir relatório não altera a batida original. Não existe fluxo completo de eliminação/anonimização por política de retenção nem portal de pedidos LGPD atualmente.

O atendimento de uma solicitação deve distinguir correção de cadastro, anotação de divergência, eliminação de dado desnecessário e preservação obrigatória/probatória. Não prometer apagar marcações originais mediante qualquer pedido ou por cancelamento/inadimplência.

## 9. Segurança e limites das proteções

### 9.1 Controles constatados

Autenticação, perfis, contexto da empresa, separação de sessões, MFA, suporte temporário, CSRF, validação de entradas, escape de saídas, parametrização de SQL, limites de upload/JSON, limitação de tentativas e arquivos privados protegidos.

API com autorização própria, credenciais de manutenção fora do web, registros originais protegidos contra alteração pelo papel de execução, backups cifrados disponíveis e recuperação isolada ensaiada. No Android: HTTPS com verificação de certificado, Keystore para segredo, bloqueio de tráfego HTTP, backup automático desativado e migrações conservadoras.

### 9.2 Criptografia: o que cada camada cobre

| Camada | Constatação |
|---|---|
| Senha do painel | Hash com salt e compatibilidade com legado; não armazenada como texto legível |
| Segredo do tablet no servidor | Representação de verificação, sem distribuir senha de RH |
| Segredo do tablet no Android | Cifrado com chave do Android Keystore |
| Credenciais de bancos das empresas no catálogo | Cifradas pela aplicação; a chave de operação deve ser protegida separadamente |
| CPF, nome, jornada e marcação no PostgreSQL | Sem cifragem individual de todos os campos pela aplicação |
| Segredo TOTP | Armazenado pelo mecanismo de autenticação no banco central; não anunciar cifragem adicional universal |
| Cache/fila Room | Proteção do Android e sandbox; não demonstrada cifragem adicional de todo o banco |
| Trânsito externo | HTTPS; domínio público e acesso provisório têm condições de confiança diferentes |
| Disco/volume do provedor | Criptografia de toda a infraestrutura não comprovada por contrato/inventário desta revisão |
| Backup | Rotas de cifragem implementadas; envio externo ainda não comprovado |
| Encadeamento de hashes | Integridade/rastreabilidade; não oculta os dados |

Os achados de infraestrutura, imagens e acesso administrativo constam no relatório de segurança e no anexo restrito. Ausência de avisos nas bibliotecas Python/Android não significa ausência de vulnerabilidades nas imagens ou no host.

## 10. Avaliação de adequação à LGPD

### 10.1 Papéis e decisões

Para dados de jornada tratados segundo instruções do empregador, a configuração usual é empregador controlador e Tecnisol operadora. A fornecedora também pode ser controladora de operações próprias, como administração do contrato e segurança de suas contas. O papel depende das decisões efetivas, não apenas do nome colocado no contrato. [Guia da ANPD sobre agentes de tratamento](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/Segunda_Versao_do_Guia_de_Agentes_de_Tratamento_retificada.pdf).

### 10.2 Bases legais: avaliação a formalizar

Identificar a base por finalidade, considerando obrigações de jornada, execução contratual e proteção de direitos. Não usar consentimento genérico do empregado para justificar qualquer tratamento. Interesse legítimo demanda avaliação de finalidade, necessidade e direitos; dado sensível exige análise própria, sem transportar automaticamente essa base. [Guia da ANPD sobre legítimo interesse](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_legitimo_interesse.pdf).

A inclusão de dados opcionais, como aniversário e contatos, precisa de decisão documentada sobre necessidade, acesso e transparência. São recomendações de governança a concluir, não um cadastro de bases legais já existente no sistema.

### 10.3 Matriz de adequação

| Tema | O que existe | O que falta |
|---|---|---|
| Minimização | Cache offline sem CPF/contatos; restrição de contatos do responsável | Revisão periódica dos campos opcionais e textos livres |
| Controle de acesso | Perfis, contexto, MFA e suporte auditado | Processo formal de revisão periódica e desligamento de operadores |
| Segurança de desenvolvimento | Testes, validação e verificações automatizadas | Programa recorrente com donos, prazos e triagem de imagens |
| Transparência | Documentação técnica e de produto | Avisos aprovados e disponibilizados a todos os públicos |
| Bases legais | Finalidades identificáveis pelo produto | Inventário formal aprovado por controlador/finalidade |
| Registro de operações | Eventos técnicos e de RH | ROPA organizacional com destinatários, bases e retenção |
| Direitos dos titulares | Relatórios e administração assistida | Canal, procedimento, prazos, autenticação proporcional e registros |
| Retenção | Histórico preservado; rotinas de backup | Tabela de temporalidade e descarte/anonimização controlados |
| Incidentes | Logs e eventos de segurança | Plano, responsáveis, canal e exercício de resposta |
| Contratos | Estrutura operacional documentada | Termos/DPA e contratos dos suboperadores aprovados |
| Encarregado/canal | Ainda sem comprovação formal apresentada | Definir enquadramento, ato e contato aplicáveis |
| Transferência internacional | Destino externo ainda não configurado | Conferir localização, acesso e mecanismo antes da contratação |
| Avaliação de impacto | Riscos identificados neste dossiê | Avaliar necessidade/RIPD e executar quando cabível |
| Treinamento | Orientações de uso pontuais | Política e treinamento periódico comprováveis |
| Aceite e versões | Ainda sem fluxo completo | Registro da versão, disponibilização e evidências de aceite aplicáveis |

**Situação:** há medidas técnicas de proteção, mas não foi demonstrada adequação organizacional completa à LGPD. Documentos novos não tornam os procedimentos automaticamente implantados.

### 10.4 Retenção proposta para decisão

| Categoria | Regra de trabalho a aprovar |
|---|---|
| Batidas, diário e documentos fiscais | Guarda pelo prazo legal aplicável e por retenção probatória necessária, sem apagamento arbitrário |
| Cadastros ativos | Enquanto necessários ao vínculo e às finalidades informadas |
| Contatos/aniversário | Revisão de necessidade, finalidade e término do uso |
| Sessões/tokens temporários | Expiração técnica, revogação e posterior limpeza conforme política |
| Logs de segurança | Prazo proporcional, acesso restrito e preservação em incidente |
| Arquivos de importação | Prazo de conferência e prova definido, evitando cópias ilimitadas |
| Cópias de segurança | Ciclo aprovado, com expurgo compatível com guarda legal e bloqueios de preservação |
| Pedidos de titulares | Tempo necessário à resposta, prova do atendimento e obrigações aplicáveis |

Nenhuma tabela acima autoriza descarte imediato. É necessário distinguir prazo do dado operacional, do documento legal, da investigação e das cópias; encerrar contrato não elimina essas análises.

### 10.5 Direitos, incidentes e fornecedores

Criar atendimento identificável para solicitações, confirmar a identidade com o mínimo necessário, registrar a decisão e justificar eventual preservação. O procedimento deve observar a legislação aplicável e evitar fornecer dados de terceiros. [ANPD — perguntas frequentes sobre direitos](https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes).

Na resposta a incidente, definir detecção, contenção, preservação de evidência, comunicação ao controlador, avaliação de risco, recuperação e ações posteriores. A regra geral de comunicação pelo controlador à ANPD/titulares, quando cabível, é de três dias úteis; o enquadramento e as exceções devem ser avaliados. [Canal e orientações de incidentes da ANPD](https://www.gov.br/anpd/pt-br/canais_atendimento/agente-de-tratamento/comunicado-de-incidente-de-seguranca-cis).

Documentar fornecedores, regiões e acessos. Não afirmar que todos os dados ficam no Brasil sem confirmação contratual. Se houver transferência internacional, verificar a base/mecanismo aplicável; contrato genérico de nuvem ou cifragem, isoladamente, não resolve esse exame. [Regulamento da ANPD sobre transferências](https://www.gov.br/anpd/pt-br/acesso-a-informacao/institucional/atos-normativos/regulamentacoes_anpd/resolucao-cd-anpd-no-19-de-23-de-agosto-de-2024).

## 11. Termos, privacidade e documentos atuais

O código examinado não apresenta um conjunto completo de termos de uso/privacidade com aceite versionado e prova de disponibilização, nem módulo completo de direitos LGPD. Existem documentos internos e orientação técnica. As minutas entregues junto deste dossiê são material de revisão, não contratos automaticamente vigentes.

### Documentos a organizar

1. Contrato/proposta de serviço e anexos comerciais.
2. Termos de uso com responsabilidades proporcionais das partes.
3. Aviso de privacidade do serviço e informação aos trabalhadores.
4. Contrato/anexo de tratamento de dados e suboperadores.
5. Política de segurança e controle de acessos.
6. Inventário de tratamento e tabela de temporalidade.
7. Plano de resposta a incidentes e continuidade.
8. Procedimento de atendimento a titulares.
9. Comprovação de titularidade, licenças e registro do programa.
10. Atestado Técnico e Termo de Responsabilidade.
11. Registro de alterações, homologações e entregas a clientes.
12. Procedimento de término, portabilidade/exportação e guarda.

Não anunciar certificação ISO, selo de invulnerabilidade, homologação governamental integral ou SLA ainda não contratados. Usar placeholders nas minutas até que razão social, CNPJ, canais e responsáveis sejam definidos.

## 12. Funcionalidades e obrigações futuras

| Prioridade | Entrega | Estado/dependência |
|---|---|---|
| Bloqueia adequação final | Comprovante eletrônico assinado e acesso após a marcação | Desenvolvimento pendente |
| Bloqueia adequação final | Fluxo de acesso/entrega ao espelho | Formalizar e validar |
| Bloqueia adequação final | Registro INPI, certificados e atestado | Titular e responsáveis reais |
| Bloqueia adequação final | Referência de hora comprovada | Operação/hospedagem |
| Bloqueia adequação final | Redundância/disponibilidade | Arquitetura, contratação e ensaios |
| Prioritária | Correções/hardening de infraestrutura | Conforme relatório restrito |
| Prioritária | Backup externo e restauração dele | Conta/destino/credenciais e teste |
| Prioritária | Formalização LGPD/contratual | Revisão, canais, procedimentos e execução |
| Prioritária | Reconciliação e atualização dos dois tablets | Presença dos aparelhos e corte controlado |
| Próxima fase | Publicação Play Store | Conta, pacote assinado, testes e declarações corretas |
| Próxima fase | E-mail transacional | Domínio, provedor e autenticação do envio |
| Próxima fase | Aceite versionado e histórico dos documentos | Implementar sem presumir consentimento para tudo |
| Próxima fase | Pedidos LGPD e retenção operacional | Fluxos e restrições legais |
| Próxima fase | Grupo com vários CNPJs e tablet compartilhado | Evolução de dados, permissão, API e contratos |
| Próxima fase | Cobrança real | Provedor, planos, eventos, reconciliação e homologação |
| Próxima fase | Acessibilidade completa | TalkBack, foco, contraste, ampliação, tempos e ensaios reais |
| Evolução | Calendário independente por unidade | Modelagem e regras por local |
| Evolução | Identificação adicional por crachá/alternativa | Análise de fraude, privacidade e acessibilidade |
| Evolução | Integrações com folha/eSocial | Contrato de integração e homologação próprios |
| Evolução | Recuperação por ponto no tempo e failover | Projeto de continuidade, custo e prova operacional |
| Evolução | Testes de carga e capacidade comercial | Metas e cenários representativos |

Funcionalidades futuras não estão incluídas automaticamente em qualquer plano, preço ou prazo. Integração simulada de pagamentos não é cobrança real. O eventual acesso vitalício já concedido não deve ser confundido com gratuidade universal do produto.

## 13. Testes, manutenção e gestão de versões

Nesta revisão: 305 testes PostgreSQL aprovados; verificação de migrações sem alterações pendentes; verificação de dependências Python sem inconsistências; controles do runtime aprovados com pendência externa identificada; tarefas Android aprovadas com resultados reutilizados pelo Gradle para fonte sem mudanças, somando 76 testes sem falhas/erros; lint sem erros, com avisos para revisão.

A consulta de 19 dependências Python fixadas e de 73 coordenadas Android não encontrou avisos conhecidos no momento da consulta. A análise das imagens encontrou avisos adicionais: estes resultados pertencem a escopos diferentes.

São recomendados revisão por alteração, testes de autorização, análise de dependências/imagens, restauração periódica, inspeção de acessos, controle de versões e teste físico de atualização. Dependências fixadas por versão/digest favorecem repetibilidade, mas precisam de atualização deliberada.

Não há prova apresentada de pentest independente completo, auditoria integral de acessibilidade, certificação de segurança ou análise forense de ausência de comprometimento.

### Licenças e proveniência

Foram identificados arquivos de licença para fonte tipográfica e base de feriados. Não foi identificado um arquivo geral de licença do produto na raiz. Antes do depósito/contratação, organizar titularidade do código, contribuições, cessões e permissões dos ativos de marca, bibliotecas e dados. Manter inventário/SBOM e avisos obrigatórios de terceiros. Não inferir titularidade de todos os componentes apenas porque estão no repositório ou foram usados na compilação. A conclusão desse inventário e sua revisão jurídica permanecem pendentes.

## 14. Critérios de contratação e entrada em operação

Antes de oferecer o sistema como operação plenamente adequada: concluir pendências obrigatórias; validar o conjunto real; obter documentação e assinaturas; configurar contatos; definir suporte/continuidade; formalizar tratamento de dados; treinar RH; reconciliar legado; atualizar tablets e documentar corte.

A configuração de jornadas, instrumentos coletivos e condutas do empregador continua sujeita à sua análise trabalhista. A fornecedora responde por suas entregas e obrigações, sem transferir ao cliente todas as responsabilidades técnicas que lhe cabem.

## 15. Fontes, glossário e apontamentos

Base técnica: modelos, views, formulários, middleware, configuração e testes dos módulos `core`, `portal` e `timeclock`; código Android; configuração de implantação; documentos de implementação/roadmap e evidências privadas de 31/10/2026.

Referências normativas complementares: [LGPD atualizada — Câmara dos Deputados](https://www2.camara.leg.br/legin/fed/lei/2018/lei-13709-14-agosto-2018-787077-normaatualizada-pl.html), [orientação de segurança da ANPD](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia-vf.pdf) e [página REP do MTE](https://www.gov.br/trabalho-e-emprego/pt-br/assuntos/inspecao-do-trabalho/fiscalizacao-do-trabalho/rep).

| Termo | Significado neste dossiê |
|---|---|
| REP-P | Registrador eletrônico de ponto via programa |
| PTRP | Programa de tratamento de registros de ponto |
| ARP | Armazenamento de registro de ponto |
| NSR | Número sequencial de registro do estabelecimento |
| AFD | Arquivo Fonte de Dados |
| AEJ | Arquivo Eletrônico de Jornada |
| MFA/TOTP | Segundo fator por código temporário |
| ROPA | Registro organizacional das operações de tratamento |
| DPA | Contrato/anexo de tratamento de dados |
| RIPD | Relatório de impacto à proteção de dados, quando aplicável |
| RPO/RTO | Objetivos de perda de dados e tempo de recuperação, a definir/ensaiar |

### Apontamentos

> Seção:  
> Correção ou decisão:  
> Responsável:  
> Prioridade:  
> Critério de aceite:  
> Data da próxima revisão: